いてづきブログ

情シスでやってみたことの備忘録

お取り潰し

それは前回の記事を書いた翌営業日のこと

 

上司「この事業は撤退する判断をしました。部署は解散となります」

 

( ゚д゚) ・・・
 
(つд⊂)ゴシゴシ
 
(;゚д゚) ・・・!?

 

というわけで部署が解散になりました。当然、チームも解散です。

本当にこの前日に上記のふりかえりブログ書いたばかりだったのであまりのタイミングに笑えてきてしまって、あとで上司に「なんで笑ってたの…(ドン引き)」という反応をもらいました(実話)

 

というのが3ヶ月前の話。

 

現在3プロダクトでマネージャーのマネごと(権限はない)をしつつ2つくらいのプロダクトでコードを書くみたいなことをしてます。
プロダクト多すぎってレベルじゃねーぞ!!!

 

こっちはこっちでいろいろ大変になってたのでいろいろ直したりしてましたがブログ書こう書こうと思ってたら時間が経ってしまったのでそれは次の記事で。

 

 

転職して3ヶ月でやったこと・起こったこと

気づいたら転職して3ヶ月が経過していました。
一応3ヶ月は試用期間ということで一部の会議に参加できなかったり時々研修入れられたりしながら過ごしていました。

 

3ヶ月が経過して一部の会議にも参加が許可されそして特に試用期間中に問題があったとかいう話も聞かされていないのでこのままこの会社で働き続けることができそうです。
今回はコロナの影響で4月から完全リモートになったり業績への影響も少なからずあるはずなので万が一みたいなことあるかもなって少し身構えていたけどなんとかなったようです。

 

続きを読む

Webpackでディレクトリ下の画像ファイルを動的に読み込む

今担当しているサービスが画像を追加するたびにソースにも画像ファイル名を記述しないといけない記述になっていて、それは面倒なので特定のディレクトリ下にファイルを追加したらコード自体には一切手を加えずにできるようにしたい。

 

結論から言うと下記の通り(TypeScript)

function App() {
  const importAll = (r: __WebpackModuleApi.RequireContext) => {
    return r.keys().map(r).map(image => { return image as string });
  }

  const images = importAll(require.context('./assets/images', false, /\.(png|jpe?g|svg)$/));

  return (
    <>
      {images.map(image => <img src={image} key={image} alt={image} />)}
    </>
  );
}

webpack.js.org require.context()で読み込むファイルを探すディレクトリと正規表現を指定して対象ファイルのパスを取得できる。


RequireContextの戻り値がanyなので、return r.keys().map(r) の部分だけで見ると unknown[] となっている。
今回は画像を読み込んでいるためsrcに突っ込むために更にmapしてstringにしている。

参考記事

https://qiita.com/proudust/items/d716957e243f9e019fda

https://qiita.com/jkr_2255/items/d23e66323857d3189a00

実践TypeScript ~	BFFとNext.js&Nuxt.jsの型定義~

実践TypeScript ~ BFFとNext.js&Nuxt.jsの型定義~

  • 作者:吉井 健文
  • 発売日: 2019/06/26
  • メディア: 単行本(ソフトカバー)

休み明け用メモ

レビュー指摘が多くてリリースが遅れることを「プランニングで決めなかったから」と言われて、そうはならんやろと思ったので考えをまとめておく

じゃないと休みの間中考えてしまいそう

 

まず、プランニングで決めなかったからと言って明らかに負債になるコードをマージするのはよくない(特に緊急な課題でもないし)

 

なぜプランニングで漏れたのか
→このくらいなら理解してると思ったから?

 

そもそもレビュー指摘されないようなコードを最初から書いてレビューに出せばいいのでは?
→このくらいは自分で考えて到達してほしいと思うが、それを各自の努力に委ねることはできない(博打と一緒だから。趣味ならともかく仕事である以上、品質・納期は守れるように努力するべき)*1
→まずこのレベルから予め周知しておく必要があるレベルであることを認識する

 

アクション?
→プランニングで逐一何をどこに書くか決める?
→どのようなことをどこに書くのかの方針を先に共有する?

 

お気持ち
→苛立ちが発生するということはそこに問題がありそうということなのでそれはいいけど苛立ちをそのままぶつけるのは勘弁してほしい
→ぶつけられる側もしんどいし、ぶつけたからといって問題は何も解決しないので

 

*1:個々人だけのやり方だと効率が良かったり良くなかったり本人の資質みたいなところもある。だから少なくとも仕事で使う部分は仕事中に担保したいというお気持ち

フロントエンドとバックエンドをチーム分けするのは合理的なのか

11月からプロジェクトが変わって、引き続きReactNativeでアプリ開発する仕事をしてるわけですが、今回のプロジェクトもアプリ側(フロントエンド)チームとサーバーサイド(バックエンド)を分けるチーム構成で進めている。

 

一つ前のプロジェクトもそうやってチームを分けていたけど、イマイチしっくりこないというか無駄が多かったなと感じたので書き残しておく。
フロント/バックの分け方としてはこんな感じ。

  • フロント/バックでリポジトリは別
  • それぞれのチームのみレビュー(承認)権限がある
  • それぞれのチームのタスクのみを担当する

 

個人的にはフロントとバックが分かれていることで余計な作業が発生しているように感じている。少なくとも(アプリの大部分を占める)単純な機能についてはそう思う。

 

例えばバックエンドからユーザー情報を取得してその内容を画面に表示するようなユーザー詳細画面を作るとする。
フロント側は画面のレイアウトを、バックエンド側はユーザー情報を返すAPIをそれぞれ作ることになると思う。(既にフロント↔バック間の通信の仕組みは出来ているとする)

フロント側はAPIができていないのでまずはモックあるいはダミーデータで画面を作ることになる。
これらは最終的に消されることになるのでまずコレが無駄。

 

次にいざ結合してみると様々な問題が発生する。
例えば、

  • 表示に必要なデータが取得されていない
  • データの型が決まっていない(stringなのかnumberなのか)
  • データがないときはnullなのか空文字なのか

ひとつひとつはもちろん大したことじゃないしすぐ直せる。

…と思うだろうけどフロント/バックが分かれている時の修正の流れはこう。

  1. 修正してもらう
  2. バックエンドチーム内でレビュー(指摘したフロントエンドの人はレビュー権限なし
  3. マージ・デプロイ
  4. フロントとの結合再確認

フロントエンドの人にレビュー権限ないからバックエンドチーム内で更に別の人にレビューしてもらう時間を取る必要があるし、もしも修正方針のコミュニケーションがうまくいってなかったらもう一度このやり取りをする羽目になる。

 

そこはしっかりコミュニケーション取って決めておくところだろとかというのはごもっともだけど、経験則になってしまうけどそれでもやっぱり漏れや認識のズレは発生するしほとんどの人は「ちょっと言って直してもらえばいいことでしょ」と思っていると思う(実際は待ちの時間がかなり発生するわけだが)

 

 

とはいえ、たとえチーム分けをしない形にしたとしてもフロント/バックそれぞれのアーキテクチャとかについてはそれぞれの分野で得意な人・できる人がやる感じになっていくだろうし、ある時点ではスキル・知識的にフロント/バックどっちかのタスクをやることが多くなることもあると思うけどそれは別に構わないと思う。価値を届けられないよりはずっといい。

 

実際、今のプロジェクトはバックエンドが遅れ気味になった*1ためフロントチームの自分とかもバックエンドの機能実装をするようになっている。

1機能がフロント、バックエンドそれぞれの結合で完成するものならそれを分割するのはそれだけコストがかかることだなと感じた。

 

 

世の中ではこうやってチーム分け事例がたくさん紹介されているので、こういう問題をどう対処しているのかとても気になるところ。

 

 

*1:アーキテクチャ周りの調査が多かったとか、稼働の問題とかもあるけど

炎上プロジェクトに放り込まれて感じたこと

前回からの続きです。

 

何回も書き直してぐしゃぐしゃになってしまったけどとりあえず公開する。
振り返り的なことは別記事で書く。


まとめようと思ったけどうまくいかなかったので、あくまで自分視点で感じたことを書いていこうと思います。

中には自分がうまく理解できていないだけだったり単に能力不足だったりというのもあるかも知れません。

 

  • 散逸する情報
  • 知らない仕事が降ってくる
  • 技術以外興味がないメンバー
  • 上司に怒られる(のではないか)ということへの恐怖
  • デザイナーとの意思疎通が辛い
  • 協力会社のマネージメント

 

続きを読む

React + Sinatraを試してみた

経緯

ポートフォリオはクライアントサイドだけで作ったのでサーバサイドと連携したものも試してみたいなと思った。

以前サイゼリヤ1000円作ったときにSinatraが手軽でいいなと思ったので、SinatraAPI作ってReact(というよりはaxios)で叩くことを試してみた。

SinatraJSONを返すAPI作成

require 'sinatra'

before do
  response.headers['Access-Control-Allow-Origin'] = '*'
end

get '/' do
  content_type :json
  { key1: 'value1', key2: 'value2' }.to_json
end

たったこれだけ!超短い。
CORS設定しないとネットワークエラーになってしまう。CORSについては別の機会にちゃんと勉強する(勉強するとは言ってない)


axiosで叩いて表示

import React from "react"
import "./App.css"
import axios from "axios"

class App extends React.Component {
  state = {
    key1: "",
    key2: ""
  }

  handleClick = async () => {
    try {
      const response = await axios.get("http://localhost:4567/")
      const data = response.data
      this.setState({ key1: data.key1, key2: data.key2 })
    } catch (e) {
      alert(e)
    }
  }

  render() {
    return (
      <div className="App">
        <button style={{ width: 200, height: 35 }} onClick={this.handleClick}>
          Sinatra呼び出し
        </button>
        <p>{this.state.key1}</p>
        <p>{this.state.key2}</p>
      </div>
    )
  }
}

export default App

クライアント側。ボタンをクリックしたらaxiosでSinatraからJSONを取得して、結果をstateに入れて表示する。それだけ。

state = {
  key1: "",
  key2: ""
}

stateの中身について上記のコードかconstructorかで宣言してあげないとkey1なんてないよと怒られてビルドできない。

所感

CORSのところと上記のstate周りでちょっとハマったけど、予想通りとても簡単にできた。素晴らしい。


ソース

github.com