あまり声を大にして言っていなかったが、Engineering Managerになってからのほうが学習意欲が増して技術力が伸びたのではないかという自負がある
— ohbarye (@ohbarye) 2019年3月26日
もう半年以上前だが、このツイートにそこそこFavが付いたのでもう少し丁寧に考えや経験を補足しようと思った。
僕が観測する界隈ではエンジニアがマネジャーになることに対するネガティブな印象として「コードを書けなくなる」「技術力が落ちる」といった意見を聞くことが多いので、いち反例として個人的な経験を挙げてみる。*1
*1:無論、一般的に「コードを書けなくなる」「技術力が落ちる」ことになるケースが多いというのは重々承知している。
これは個人的なブレイクスルーの話、自分の技術力は今でもたかが知れているというのは承知の上で過去と現在を相対的に比較して技術力が伸びたという話なのであしからず。
半年以上前にReactのContextとHooksで日本語のふりがな入力を支援するコンポーネント書いた - valid,invalidという記事を書いたが、このときは何もわかってなかったということがわかった。
長々とContext, Provider, useReducerあたりのことを書きましたが、同じことは以下の十数行のcustom hookで実現できた。
import historykana from 'historykana'; export const useKana = (fieldNames: string[]) => { const [history, setHistory] = useState({}); const [kana, setKana] = useState({}); const setKanaSource = ({ fieldName, inputtedValue }) => { const newHistory = inputtedValue ? [...history[fieldName], inputtedValue] : []; setHistory({ ...history, [fieldName]: newHistory }); setKana({ ...kana, [fieldName]: historykana(newHistory) }); }; return { kana, setKanaSource }; };
stateを更新するロジックは大した複雑性もないのでuseReducerは不要。stateを更新するにはdispatcher相当のcallback関数を自前で書いてユーザーに提供すればよし。
ライブラリを使う側の気持ちとしても今だったらContextじゃなくふつうにcustom hookを使いたいと思う。
import React from 'react'; import ReactDOM from 'react-dom'; import { useKana } from 'react-use-kana'; const App = () => { const { kana: { lastNameKana }, setKanaSource } = useKana(['lastNameKana']); return ( <> <input type="text" onChange={e => setKanaSource({ fieldName: 'lastNameKana', inputtedValue: e.target.value }) } /> <input type="text" value={lastNameKana} /> </> ); }; ReactDOM.render(<App />, document.getElementById('root'));
React hooksのテストってどうやって書くのかな？と思ってHooks FAQ – Reactを見ると@testing-library/react-hooksを見つけたので試してみた。今回はJestと併用。
基本的にはReact Testing Libraryと類似のAPI（actとか）が使える…と思ったらreact-test-rendererに依存しており、そこからexportされているだけのようだった。
React Componentのテストのときと同様にactにはユーザーインタラクションのいち単位を記述する。今回は一文字ずつの入力をインタラクションとして定義したく、ループ内でactを呼ぶようなテストになった
import { renderHook, act } from '@testing-library/react-hooks'; import { useKana } from '../useKana'; test('returns kana based on user input', () => { const { result } = renderHook(() => useKana(['lastNameKana', 'firstNameKana']), ); expect(result.current.kana).toEqual({ lastNameKana: '', firstNameKana: '', }); // Emulates to input a user's last name [ 'や', 'やｍ', 'やま', 'やまｄ', 'やまだ', '山田', ].forEach(value => { act(() => { result.current.setKanaSource({ fieldName: 'lastNameKana', inputtedValue: value, }); }); }); expect(result.current.kana).toEqual({ lastNameKana: 'やまだ', firstNameKana: '', }); });
今回書いたreact-use-kanaはnpm registoryに公開し、react-kana-providerはnpm deprecateした。
buidersconは2017年に初めて参加したときにとても刺激を受け、そのおかげで2018年に自分が登壇やOSS活動がんばる気力になったぐらい、（勝手な）思い入れがあるカンファレンス。今年で3年連続の参加になる。
全部で9本のセッションに参加し、その中でも特に"Discover something new"したもの、心が動いたものは以下の3つ。
コンパイラをつくってみよう - builderscon tokyo 2019
これは自分の今の気持ちに刺さったので#builderscon 「コンパイラをつくってみよう」に触発されてRubyでも書いてみた - valid,invalidにも書いたようにすぐ実践してみた。
DQNEOさんの発表に触発されてアレのRuby版のコンパイラ書いてみる
— ohbarye aka 広島の粗大ゴミ (@ohbarye) August 30, 2019
一歩でも自分の知識が深まるような実践に繋がってよかった。
形式手法による分散システムの検証 - builderscon tokyo 2019
形式手法に関する事前知識はほとんどなかったけれどもその概要から実践的なモデルケースの解説まで非常にわかりやすかった。自分もやってみようかなという気持ちになった。
形式手法のこと何も知らなかったけど分散システムの検証というケーススタディがとてもわかりやすくて面白かった。開発以前の設計段階から検証ができるという嬉しさも理解した / “形式手法による分散システムの検証 #builderscon / builderscon tokyo 2019 - Speaker Deck” https://t.co/UwnPT9PQkd
— ohbarye aka 広島の粗大ゴミ (@ohbarye) August 31, 2019
これまで「形式手法はソフトウェアテスト手法の一種かな？」ぐらいの雑な認識で実装の間または後ぐらいに位置づけられると勝手に思っていたのだが、開発/テストを待たずにシステムの設計を検証できるものということがわかってよかった。設計自体へのレビューと捉える方が自分にとってはしっくりきたし、実用したいと思えた。「常に、生産過程のなるべく早い時点で誤りに気づかなければいけない」*1ので設計時点で齟齬に気づきたい。
もしもハッカーの「サイバー攻撃日誌」が読めたら - builderscon tokyo 2019
これは…かつてなくワクワクするセッション。
サイバー攻撃をセキュリティ診断として実施する会社いわば「いろんな会社を攻撃する仕事」があるというので「一企業の中にもそういう部門があるぐらいだし、まぁそれはありそう」というぐらいの印象だったのだが、実際にプレゼンが始まってみるとその本格度の高さに終始ひきこまれた。技術的についていけないことがあるだけでなく、ソーシャルハッキングなどの人的側面からの攻撃も多分に有効であるということがわかり、自分ではまったく守りきれる気がしない…。
内容は公開できないとのことだが、「（クラッカーとして）二要素認証は攻めづらいので嫌い」の一言は持ち帰って拡散しても良さそう。
あらかじめ書いておくと、どちらも自分にとってのbuildersconの価値を毀損するほどのものではないです。
前夜祭で最後席付近のスタッフ(?)の私語の声が大きく、登壇者のプレゼンがたびたび聞こえなくなるほどだった。これがそこそこつらかったのと、そのとき体力気力があまりなかったこともあって前夜祭は中途で抜けて帰った。アルコール入っている人ぽくて怖かったのと、前夜祭ってお酒飲みつつ盛り上がるものでしょと言われたらそれまでなので直接言えなかったけど、その場で一言いえばよかったかなぁ。
また、こちらは会場の都合もあるので言いがかりに近くて申し訳ない…が、温度調整でダメージを受けました。
#builderscon #bcniwa の端っこに席に座ってたら冷房きつくて体が冷えてお腹痛くなってしまったので皆さんも気をつけてください
— ohbarye aka 広島の粗大ゴミ (@ohbarye) August 30, 2019
イベント側提供のランチもとてもありがたいが、せっかく普段行かない土地に行くのだからその土地でしか食べれないものを食べたくなってしまうので、その土地でしか食べれないものを食べました。
どちらも本当に素晴らしかったので北千住に行くことがあれば再訪するぞ!!
*1:『HIGH OUTPUT MANAGEMET』に書いてあった気がする
builderscon 2019 で @DQNEO さんが コンパイラをつくってみよう / How to make a compiler - Speaker Deck という発表をされていた。ライブコーディングの緊張感と会場の一体感もすごかったが、そのうえ自分はプレゼンの中で言及されていた想定聴衆にストライクだったためとても楽しんだ。*1
「どの言語でどの言語のコンパイラを書いてもよい」「学んでから作るのではなく作りながら学ぶ」という言葉が刺さったのでさっそくRubyで実装してみた。今回の発表のために用意されたレポジトリのcommit logを一つ一つ読み、bashからの実行を小さく小さく繰り返しながら進めること1時間半ほどで、四則演算ができる程度の極小コンパイラが書けた。
実は過去に『RubyでつくるRuby ゼロから学びなおすプログラミング言語入門』を読んでRubyインタプリタ実装についてわかった気持ちになったことがあるのだがそちらではtokenizeやparseの実装はスキップしていた*2ので、今回その辺をかじることができて足りなかったピースがハマった感覚があってよかった。*3
また、発表の質疑応答にて「次に何を実装するのが良いでしょうか？」という質問に対し「if、for、関数あたり」とのこと。まさに同書の知識＋未知の部分で学びが多そうなので続きをやっていきたい。
その他の感想：
*1:発表に関するまとめはクラスメソッド社の [builderscon 2019 レポート] コンパイラを作ってみよう #builderscon ｜ DevelopersIO が詳しい
*2:書籍のやり方に従うとminruby_parseというgemを使うことになる。もちろん自分で書くチャンスも無限にあるがそのスキルがなかった
*3:よかった…が、こういうの皆さん大学でやってきているのかな〜、はぁ〜〜〜と思うと改めてビハインドを感じるのでやっていくしかない
弊社社員@pankonaは社内いちXRに熱い気持ちがある男（美少女）。購買申請を出した。
VRは今のところ弊社の事業とはまったく関係ないのでこれはもうだめかもわからんねと思ったが予想外の角度の予算でOculus Questを2台買えた。
活用を推進するVR番長としての役割を任命された@pankonaはマネジャー@ohbaryeにVR 1-on-1を挑むのだった。
恥ずかしながら@ohbaryeはQuest初体験なのでインストラクションされつつ、2人で密室でゴーグルをかぶる状態でスタート。
途中トラブルがありながらも仮想世界にDIVE。すると…やだ、オフィスが突如マイホームに！？
そんな驚きもつかの間、マイホームに美少女（男）が突如現れてどうなっちゃうの…って、おれも美少女になってる〜〜〜！？
テックカンパニーなんだからテックを使った試みをしていこう
