転職活動の振り返り
一般的な退職エントリのように、今ままでどんなことをやって、なんでやめて、次何をやるのかとかは書かない予定。
以前休職して留学に行くか考えてた時に書いたブログを読み返していて、すごくハッとした文章があった。
自分の中で仮説に仮説を重ねて、現状維持を選ぼうとしていました。
まあまさにこの状態だったんだけども、やっぱり本気で自分が悩んだ時に考えたことは、自分のために残しておくと良いなと思った。 なので、転職の際に思ったことをだらだらと書くだけにします。笑
最終的にどんな軸で選んだのか
最終的に2社まで絞りこんで、ぎりぎりまでどっちにしようか迷っていた。どっちもすごく良い会社だし、面接に関わってくれた人たちもよくて、そんな両方の会社から内定をいただけるのがありがたいと思った。
そんな中、最終的にはこの 2 つを考えて選択をした。
- より環境が変わりそうな方
- 自分が本気になれそうな方
より環境が変わりそうな方
正直どっちの会社に入っても良い経験はできそうだし楽しそうだと思ったから、だったら大きく環境が変わる方にチャレンジしたいなと思った。
どっちがチャレンジングか？みたいな観点に近いかもしれない。
ただどっちがチャレンジングかってのは、フェーズが違う会社だと結構比較が難しい気がしていて、環境が変わりそうな軸ということで選んだ。
1社は社内の新規事業部っぽい立ち位置で、もう1社はまだ創業して2年弱くらいの会社。
私自身、今まで社内の新規事業の立ち位置の部署に所属していたので、よりアーリーステージの会社の方が環境が変わるだろうと思った。
新規事業って他事業により安定しつつもチャレンジできる良い環境だと思う。その反面、今までもずっとそうしてきていたからこそ、次はそのような後ろ盾がない状況でチャレンジしたいと思った。今この決断ができないと、将来もっと歳を取ったときに、創業して2年もたっていない会社に飛び込めなくなるような気がした。たぶんそんなことはないんだろうけど。
自分が本気になれそうな方
どっちの会社に行く方が自分は本気になれるんだろうか？というのを考えた。
これは前職 (まだやめてないけど) で学んだことの1つで、ビジネスモデルの良し悪しとそこで得られる経験はイコールじゃないってのがある。もちろんビジネスモデルが優れていて、急成長しそうな会社であればそこで得られることは多くあるんだけど、結局は自分でどこまで考えて本気になって取り組めるかに行き着くと思っている。
漫画の話だけど、あひるの空で大栄の白石が峯田に対して「いるだけで上手くなるなら誰も苦労しないぜ」って言ってたのをなぜか覚えている。環境はすごく大事なんだけど、結局自分がどこまでやれるかなんだよなあと。それができなくなったから転職をしたんですよね。
じゃあどっちの会社なら本気になれそうか？と考えた際に、具体的に行動を起こしているのはどっちなんだろうかと思った。選んだ方の会社の事業領域に関しては、実際にいくつも行動を起こせていた。まあもともと興味を持ったのが勉強会だったってのはあるんだけども。
よかったこと
結果的にはピンポイントに 3 社受けて全部内定をいただけたし、どういう会社(フェーズなど)に求められるのかもわかった気がした。
また、色々と聞かれると思いここら辺の内容を復習をした。わかるつもりだったけど、人には説明できないような知識はこの機会に学習して知識をアップデートできたのはよかった。
また、自分自身の経験や考え方のようなところはこれを参考にさせてもらった。これも 0 秒思考のメモ書きで毎日考えて、理解が深まったのがよかった。
反省点
初転職ということもあって、転職をしようかと考えてから実際に面接に受けるまでに時間がかかってしまった。受けてないところも含めて、面白そうな会社がいっぱいあって、もう少し日頃から外の人と繋がりを持っておいても良いのかもと思った。前はよく Yenta で人とあったり、他の会社手伝ったりしてたけど、最近は全くやらなくなってしまったので。
あと、今後自分が採用側に立つ可能性を考えるともう少しいろいろな企業の面接を受けてもよかったのかなと思っている。
終わってみて
思ったより体力と精神力が持っていかれた。1社受けるにも、カジュアル面談、面接複数回、技術試験、リファレンスチェック、オファー面談、その他日程調整などなど。それぞれある程度は準備をしないといけないし、終わったら聞かれた内容を軽くメモしたり、自分で深掘りしたいところを考えたりもしていたので余計に時間が取られた。
結果的には良い転職ができたと思っているので、関わってくれた人たちには本当に感謝です。
JS で関数型っぽく書きたいときは、スプレッド構文を使用して配列に値の追加や連結を行う
React の勉強中にここもよく出てくるのでまとめ。
まず前提として、関数型っぽく書こうとする場合には、破壊的な関数は使用せずに非破壊的な関数を使用すると良い。
例えば特定の要素を削除する場合には、なるべく filter を使用する。
console.log([1,2,3,4,5].filter(num => num !== 1)) // [ 2, 3, 4, 5 ]
じゃあ配列に要素を追加をしたいときはどうするか？というと、あまりネットにある記事には記載されていないように感じた。
ドキュメントの配列を複製するの項目に記載されているコードもこんな感じ。
let arr = [1, 2, 3]; let arr2 = [...arr]; // arr.slice() のような動きです arr2.push(4); // arr2 は [1, 2, 3, 4] になります // arr は変更されません
これならば push せずに、スプレッド構文と合わせて追加したい項目を記載すれば良いと思う。
変更元の配列に影響を与えずにより簡潔に記載ができる。
let arr = [1, 2, 3]; console.log([...arr, 4]) // [ 1, 2, 3, 4 ] console.log([4, ...arr]) // [ 4, 1, 2, 3 ]
配列に新たに要素を追加したい場合、スプレッド構文でこんな感じにすれば良い。
const numbers = [1,2,3,4,5] const numbers2 = [...numbers, 6] console.log(numbers2) // [ 1, 2, 3, 4, 5, 6 ] const numbers3 = [6, ...numbers] console.log(numbers3) // [ 6, 1, 2, 3, 4, 5 ]
また、スプレッド構文のドキュメントを読んでいたら、配列の連結についての記載もあった。
これも concat を使用せずにスプレッド構文で連結ができるとのこと。
const array1 = [1, 2, 3] const array2 = [4, 5, 6] console.log(array1.concat(array2)) // [ 1, 2, 3, 4, 5, 6 ] console.log([...array1, ...array2]) // [ 1, 2, 3, 4, 5, 6 ]
ローカルの Docker 環境で s3 を使用したい場合には MinIO を使えば良い
触ってすらいないんだけども、MinIO を使えば良いらしいね。名前すら知らなかった。
Laradock にも入ってると。Laradock なんでも入りすぎててもはやなにがあるのかわかってない。 https://laradock.io/documentation/#use-miniolaradock.io
今度触ってみて、追記しよう。
API 設計時に迷った時におすすめな Google Cloud の API 設計ガイド
レビューをする際にも同様で、その際に自分は何を参考にしてるのか、どこを見てもらえば良い設計などを伝えられるのかなどを共有することがあるのでまとめておきたいと思いました。
Google Cloud の API 設計ガイド
よく参考にしているサイトとして Google Cloud の API 設計ガイドがあります。
2017 年に公開されたものですが、今年に入っても定期的に更新されています。
設計パターンから命名規則まで一通りの情報がまとまっており、まずはこれに目を通してもらうのが良いと思っています。
私の場合は特にこちらに関しては意識をしています。
数多くの API で長期にわたって一貫したデベロッパー エクスペリエンスを提供するために、API で使用されるすべての名前は、次の特徴を備えていることが推奨されます。
・シンプル
・直感的
・整合性
レビューをする際にも同様で、まずは直感的に理解できるか？その後に他の API や命名と整合性があるのか？もっとシンプルな表現はないのか？などを見ています。
個人的なアンチパターン
上記を実現する上で、避けた方が良いかなと思うことがあります。
とりあえず Google 翻訳で出てきたものをそのまま使う
前に他の人と話してて思ったのですが、とりあえず Google 翻訳にかけて一番上に出てくるものを採用する人がいる模様。
ちょっとしたニュアンスの違いで適切な単語は変わるので、ちゃんと比較をした方が良いです。
英単語の方もですが、翻訳に使用した日本語の方もいくつか捉え方というか候補があると思うので、日本語も適切なのか確認しつつしっくりくる単語を探す必要があります。
例えば、同じ食べ物という表現でも、食べ物、ご飯、ランチ、エサ、料理 とかとか。
自分がわからない単語を使用する
壊滅的に英単語わからない場合にはなんとも言えませんが、自分がわからないということは他のメンバーが見てもわからない可能性があります。
結局みんな調べないとわからないような単語を使用してしまうと、誰も直感的に理解できなくなります。
こちらに関しても、先ほどの API 設計ガイドの命名規則にも下記の記載があり、意識をした方が良いポイントだと思います。
多くの開発者は英語が母語ではないため、大部分の開発者が API を簡単に理解できるようにすることが、これらの命名規則の 1 つの目標です。
これが発生する場合には、日本語の表現を難しく考えすぎているかもしれません。
難しい日本語の表現から英語を考えるので、英単語がわからないなどは発生する可能性があります。
辞書の最後の方にのっているからという理由で良しとしてしまうと、
この単語ってこういう意味もあるんだという発見はここでは不要です。
ぱっと見た際に、みんなが同じような理解ができる単語を選ぶようにしましょう。
単語はたくさんあるので、もっと最適なものがあるはずです。
公開されている API を参考にする
1から全部考えるのは大変なので、ある程度他のサイトがどのように作成をしているのか確認するのもおすすめです。
私の場合は Github や Twitter などを参考にすることが多いです。
docs.github.com developer.twitter.com
そこそこちゃんとしたサイトのものであればなんでも良いのですが、普段自分が使用しているものだと理解しやすいと思います。
どういうデータが保存されていて、どんなページがあるのかがわかる方が想像しやすいからです。
JS のデストラクチャリング
よくあるこんな感じのコード、これ自体はよく使うんだけども他にも色々と使ってない使い方があったのでまとめ。
const { data } = await axios.get('/some_api')
関数の引数でも使用可能
object を引数に渡す場合で特定の key しか
特定の key しか使わない場合だったり、明示的にどの key を使用するのかわかりやすい。毎回 obj.key1 とやらなくて良いので便利。
const obj = { key1: 'val1', key2: 'val2', key3: 'val3', } const hoge = ({ key1 }) => { console.log(key1) } hoge(obj) // val1
スプレッド演算子で残りの key を全てまとめて代入
React の勉強をしていて、よく ...props としている箇所が出てきたけどこう言うことか。
const hoge = ({ key2, ...props }) => { console.log(key2, props) } hoge(obj) // val2 { key1: 'val1', key3: 'val3' }
デフォルト値の設定も可能
これも知らなかったけど、調べてたらデフォルト値の設定も可能。 API からデータを取得して key がなければデフォルト値を設定するみたいなコードを書いたことがあったので、これは使えそう。
const { key3 = 'hoge', key4 = 'val4', ...rest } = obj console.log(key3, key4, rest) // val3 val4 { key1: 'val1', key2: 'val2' }
関数の結果を後で再利用するために保持する手法をメモ化という
タイトルは正確な表現ではないかもしれない。
最近 React の勉強を始めて、React.memo とか hooks の中にも useMemo というものが出てきた。
例えば同じ引数の場合には同じ結果を返すことになるので、引数とともに返す結果をキャッシュしておくことで、毎回同じ計算をしなくて済むようになる。
再描画される際にどうしても実行しないといけない処理なんかは、メモ化することで余計な処理が実行されなくて済む。
一度メモしたものを毎回返すようなイメージは持てるので、特に理解には困らなかったけど、そもそもちゃんと メモ化 という言葉があることを知らなかった。
wikipedia には下記の定義が記載されていた。
メモ化（英: Memoization）とは、プログラムの高速化のための最適化技法の一種であり、サブルーチン呼び出しの結果を後で再利用するために保持し、そのサブルーチン（関数）の呼び出し毎の再計算を防ぐ手法である。メモ化は構文解析などでも使われる（必ずしも高速化のためだけとは限らない）。キャッシュはより広範な用語であり、メモ化はキャッシュの限定的な形態を指す用語である。
ここら辺をうまく使うには純粋関数にすることを意識する必要があるなと。
メモ化って言葉を知らなくても特に React を書く上で困ることはないかもしれない。
でも知らない単語はなるべく減らしていきたいし、使っている技術のベースとなる概念は知っておきたいと思った。
