転職して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の型定義~

休み明け用メモ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

前回からの続きです。

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

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

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

React + Sinatraを試してみた

経緯

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

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

SinatraでJSONを返す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

React + Material-UIでポートフォリオサイト作った

仕事でReact（正確にはReact Native）を使っているのでお勉強がてらポートフォリオサイトを作った。

iteduki.github.io

案外さっくり作れたつもりだったけどコミット履歴を見ると10日はかかった模様。
平日1日1時間程度+休日なのでだいたい15時間程度くらいだろうか。

まずはいろんなポートフォリオサイト見て回ってコンテンツをひねり出し、さらに最初の1,2日はTypescriptわからん、Material-UIわからんという感じで格闘していた気がする。
Material-UIを選んだのはcssフレームワークの中で、前職辞める直前に一瞬React触ったときに使ってたような気がするなというだけで選んだ（本当に使っていたかは定かではない）

実際に作ってみて、cssの知識全然足りないなって思った。
やろうとしたレイアウトがうまくできなくて諦めて変えるみたいなことをしていた。仕事では許されないやつ。css勉強せねば…。

まだデザインとかほぼ素のままなのでもう少しいじってみるつもり。
それとgh-pagesだと毎回deployめんどいのでCIにしたい（明らかに先にやっとくべき事案）

ただ、なんだかんだ言って慣れてしまえば結構書きやすいなと思った。redux使ってないとかはあるけどｗ

あと、Typescriptはコンパイル時点でエラーがあると教えてくれるのは便利だなと思った。JSだと実行したときにタイポに気づくとか日常なので。

それにしても、2019年にもなってなんで自分のWebサイト作ってるんだろうなぁなんて思ったのでしたｗ

Reactビギナーズガイド ―コンポーネントベースのフロントエンド開発入門