2018年を振り返る
この記事はカヤックOBが綴るアドベントカレンダー「ex-KAYAC Advent Calendar 2018」の11日目の記事となります。
この一年何してたか
- Lobi Tournament @ KAYAC（〜7月）
- IoT device platform @ SmartDrive（9月〜）
本記事は技術エントリではなく、一年の振り返りと今更転職報告を兼ねたものです。
Lobi Tournament @ KAYAC
前職で最後に関わっていたのは、PvPタイトルでの大会作成・運営を支援するLobi Tournamentというプロダクトでした。このプロダクトでは2017年3月頃から僕の鶴の一声でドメイン駆動設計の勉強と実践に取り組むことを決め、開発メンバーで当時思いつく限りの手法を試しまくるDDDの大実験場と化していました。
敢えて機能単位でサブコンテキストの分割を行い、コンテキスト間の繋ぎ込みのためのACLの実装方法を試したり、集約を跨ぐが結果整合性が伴えばよい処理はドメインイベントとしてアーキテクティングしてみるとか、IDDD本内の付録以外のことは曲りなりにも手を出してみたつもりです。
プロダクトはLL言語（Perl!）なのに同じチームの後輩がinterface的な役割を持ったクラスを定義したことがあり、流石にそれはtoo matchだとは思ったんですが、おかげでオニオンアーキテクチャについて理解が深まったという一面もあります。
あとLobi Tournamentは前年からGraphQLの採用も始め、GraphQLのtype定義とDDDにおける集約はだいぶ親和性高いなぁ、と使いながら思ってました。GraphQLはqueryだけでなくmutationも使っていて、普通にRPC的に使ってました。subscriptionは構想まであったけど手が出せなかった（その前に僕が転職した）です。
何故か最終出社後に「最後に何か話してくれ」と言われたので、Lobi TournamentでDDDやGraphQLを採用した経緯なんかを話しつつ「まず先人たちのレールに乗っかって、その上で自分たちなりの手法や取捨選択をすればいいのでは」という話をしました。
僕自身、DDDに触れるまでソフトウェア設計の守破離の「守」すら知らなかったようなものなので、DDDやClean Architectureのような「前提知識」があると、アーキテクティングや設計時に何かを判断する時に本当に助けになる、ということを身を持って知ることができました。
ただ、何でもかんでもうまくいってたなんてことはなかったです。特にレイヤードアーキテクチャはある程度事前知識がないとキャッチアップが難しく、いくら「ここでこう書いてるようにやればいいよ」と言ってもなかなか思うように進まなかったということは何度もありました。また、僕と周囲のDDDに対する温度感も違っていたりして、独りよがりだということを指摘を受けて今では反省しています。
なお余談ですが、DDDの勉強を始めて半年くらいの時点の知識というか思いの丈を以前エントリにまとめてました。
この記事で触れてる某Mカリに行った後輩（というか自分にとっては先生ですね）には今でも感謝してます。
DDDを勉強してある程度自信がついたことで、「この会社でまだ学ぶことがある」から「学びたいことはどこでも学べる」という気持ちに切り替わったというのは、転職に至る大きな原動力になりました。
（転職活動中にとあるDDDを実践してる会社さんに伺って話をしていて「DDDのこと、結構分かってそうですね」と言ってもらえたり、4月に開催されたDDD交流会にて、結構いい感じで他の参加者と話が出来たのが自信になった）
IoT device platform @ SmartDrive
何年か前くらいからぼんやりとゲームや広告とは無縁の事業に関わることに関心を持ち始めていて、IoTもそうした「別の関心ごと」の一つでした。
「カヤックだったら何でもできるじゃん」みたいな意見はあるとは思いますが、そろそろ事業部間異動はいいかなー、外の世界も見てみたいなー、という思いが強くなって転職するという道を選びました。去年末からいくつかの転職サイトでの活動を少しずつ始め、お声がけいただいた会社の中から興味の湧いた会社何社かに話を聞きに行き、そのなかで一番お互いに手応えが良く9月に転職したのがSmartDriveでした。
SmartDriveではGo(Gin)とRuby(Rails)で事業が展開されています。が、僕はどちらも業務でまともに書いたことがなかったので、正直よく入社できたよな、と我ながら関心してしまっています。
あﾞっ・・・！？
— 賭博就職録 キャリアカウンセラーカイジ (@black_kaiji) 2018年11月1日
Perl…？
このエンジニア…
面接での「使える言語は？」の質問に…
答えてきおった…
Perlと…！！
使わん…！Perlなど絶対に……！
ほら見ろ…CTOの顔もひきつっている…
いやさすがに
使えるはず…他の言語も…
多少は…
「Perlだけです」
ぐががっ！
採用……見送りっ…
使える言語はマジでこんな感じだったけど見送られなくてよかった〜〜〜〜😂
面接等は終始和やかだったと思っています！
実際のところはオファーを提示される前に体験入社を一日行っていて、そこで実際に動いているコードを触らせてもらってました。そこで出されたお題に対してPRを作るというものだったので、実際のコーディング能力も採用時に把握されています。
体験入社の制度はいいですね。採用側が相手の能力を見ることができるだけでなく、エントリーした側もどういうコードで実装されているのかを確認できるので、入社後に初めてコードを見て「なんじゃこりゃあ！」という事態を避けることができると僕は思っています。そういえば、SmartHRさんでも体験入社の制度が整備されているそうですね。
→ エンジニア向けの体験入社制度ができました - SmartHR Tech Blog
現職は正直なところ、ここまで至れり尽くせりではないですね。。。ただ、「体験入社」という仕組み自体はもっと広まってもいいのかな、と思っています。
因みに、カヤック時代と比べて生活がどう変わったかと言うと。。。
- 通勤時間
- めっちゃ伸びた（1時間半〜2時間弱）
- 暇なので本読んだりポッドキャスト聞いたりする時間にあててる
- 早く帰ろうと思ったら満員電車に重なり、遅く帰ると妻にも迷惑がかかるというちょっと板挟み的な状況
- オフィスアメニティ
- WeWorkさまさまです！
- 空調はちょっと残念かも
- ドリップコーヒー、ティーパックが（ほぼ）飲み放題
- 蛇口から出る水が恐らく浄水
- 昼になったらビールサーバーが解禁になる
- 帰り際に一杯飲んでから、なんてことができる
- WeWorkさまさまです！
- 飯事情
- そこそこ美味く、そこそこ安い店が多い
- ただ、僕は普段は弁当。。。
- 弊社では毎週水曜日はケータリングサービス使って社員数人でのグループランチを美味しく戴いてます
- 周辺環境
- 職場の空気
- 口調が穏やかな人が多いからか、近くで会話しててもそんなに気が散らない
- 多分、僕はうるさい。。。
- times文化が強い
- 口調が穏やかな人が多いからか、近くで会話しててもそんなに気が散らない
いつぞやのグループランチ www.instagram.com
現職でもDDD関連の勉強というか情報収集や実践は続けています。
最近新機能開発に携わっていたのですが、既存実装に影響がないことを条件にClean Architectureの採用をシニアエンジニアに許可もらったので、ドメイン層はDDDを意識してモデリングを行い、RepositoryやUseCase等の層はClean Architectureをだいぶ意識して実装しました。
Clean Architecture 達人に学ぶソフトウェアの構造と設計
- 作者: Robert C.Martin,角征典,高木正弘
- 出版社/メーカー: KADOKAWA
- 発売日: 2018/07/27
- メディア: 単行本
- この商品を含むブログを見る
この新機能実装については、折を見てどこかで触れる予定です。
また、とりあえずこれでGoでドメインモデリングを伴う実装に対して実績が出来たので、まず社内で知見を共有していきたいと思います。
Ergo42が遂に組みあがりました
承前↓
問題点の絞り込みと対処法について
twitterに細かく情報をのっけて行く形だとちょっとあれだな、と思ったので、一旦ブログに現状をまとめてみたところ、作者のBiaccoさんに読んでいただくことができました。
読んでいただきありがとうございます！おおお、対処できそうなんですね。僕ももうちょっとPro Microの近辺のはんだ付けは見直してみたいと思います。
— Taiyoh Tanaka (@ttaiyoh) 2018年7月24日
ありがとうございます！やってみますー
— Taiyoh Tanaka (@ttaiyoh) 2018年7月24日
半田をつけたり外したりしてテスターをあててみましたが、導通は確認できませんでした。。。他のピンでも導通を試してみたので、恐らく教えていただいたところで合ってそうに思いました。
— Taiyoh Tanaka (@ttaiyoh) 2018年7月24日
Pro Microを一度外した時に傷ついてたのかな。。。あとは基盤の外でワイヤリングするとかでしょうか
家にあったワイヤを使ってキースイッチのピンとPro Microを繋いでみたところ、一列全部のキー入力が確認できました！なので、ちゃんと半田付けして完成させます。色々アドバイスいただき、ありがとうございました！！
— Taiyoh Tanaka (@ttaiyoh) 2018年7月25日
実際のワイヤリングはどのようにやったか
当初はこのようなワイヤリングで導通させていましたが、いざケースのネジを締めて少し使ってみると、部分的にスイッチの半田が圧迫されるのか、キーが効かなくなってしまいました。 あれこれ考えて、もっと簡素化できる方法を思いついたので、バージョン2のワイヤリングをやってみました。
これなら圧迫もなく、無事に全部のキー入力が確認できました！因みにこの黄色いワイヤは、元々はブレッドボード用の硬いジャンパーワイヤですね。持っててよかった。
そして。。。
うおおおお #Ergo42 pic.twitter.com/l8ZplUiHyQ
— Taiyoh Tanaka (@ttaiyoh) 2018年7月25日
慣れないながらもちゃんと打つことができて、感動ですね。。。
キーマップについて
デフォルトのキーマップは、初めて分割キーボードに手を出した自分にとっては結構使いやすかったです。
でもやっぱり、自作キーボードに手を出した以上はもっと自分の好みを反映したいな、と思ったので、以下のキーマップを作成しました。
gist957d0e08b81c69d0c1cdda621f7debc4
当初は7列をフルに使うことを想定していて、妄想ではこういうキーマップを当初想定していました
が、いざこれを書き出して打ってみると、１列目と７列目のキーを押すのはだいぶしんどいと気づき、あえなく撃沈。
しばらく色々試していて見えてきたのは、特に僕の場合、意識せずに伸ばせる指の範囲は６列分までだということでした。
これを踏まえ、以下のようなルールを作ってみました
- Tab, Ctrl, Shiftは内側に、そして左側に１つずつあればいい
- ESC, LGUIは使用頻度が低いか、Tab, Ctrlとの組み合わせで使うことが圧倒的に多いので外側でいい
- Dvorak配列も試してみたいので、Dvorakで明確に配置されているキーは必ず上３行の中に収める
- META / SYMBで記号が打てならそちらに任せる
- 無理にデフォルトキーマップの全キーを埋める必要はないだろう
- 矢印キーはvimキーバインドに倣って「←↓↑→」の並びに
- 手首に近いところにはよく使うキーは配置しない
これらを実際の配列に落とし込んだのが上記のキーマップです。
backspaceを右手親指で扱うというのはだいぶイレギュラーかも。でもまあ、しばらく使っていたら段々慣れつつあります。
qwertyとdvorakを共存させるにあたり、２点ほど気を付けたことがあります。
- META / SYMBよりレイヤ番号を低くする
config.hに#define PREVENT_STUCK_MODIFIERSをつける
の記事より、定数を定義しておくことでmodifierキーのロックを防ぐことができます。また、dvorakのレイヤ番号をqwertyを配置しているdefault layerの次に低くしておくことで、default layerのキーを引き継げるだけでなく、上のレイヤのキーを利用することができます。なお、上記キーマップではqwerty→dvorakへの変換ですが、dvorak→qwertyに戻す際は、METAからソフトウェアリセットをかければいいようにしています。
ファームウェアへの書き込みについて
自作キーボードを組み立ててる方々はMac使いが多く、Windowsでの情報が少ないように感じたので、自分のやったことと所感を載せておきます。
始めに書いておくと、僕はWSL（Windows Subsystem for Linux）とqmk toolboxを併用しています。
なぜMingwでの環境構築がおススメされているかというと、makeコマンド一発で（make ergo42/rev1:<keymap>:avrdude と入力すれば）ファームウェアへの書き込みまで行うことができるからです。
ただ、僕は諸々の開発環境をWSL上で既に作ってしまっているので、今更Mingwで環境を作り直すのが面倒くさく、こういう方式を採ることにしました。
その場合、 make ergo42/rev1:<keymap> とmakeの引数を調整すれば、WSL内でビルドまではやってくれます。あとはqmk toolboxでのhexファイルの読み込み先をビルド先に指定すればよいです。
最後に
特に僕みたいに初めてまともな電子工作をする人にとって、既製品を買うのに比べてだいぶお金も労力もかかってしまうのは間違いないです。
が、作りきった時の達成感は尋常じゃないですし、自分にとって必要なものだけがまとまっているキーボードというのは格別ですね。
因みにこのエントリは当然ながら、Ergo42+上記の自前キーマップで書いております。書いてるうちに少しずつキー入力の速度が上がってるのがなんか面白い。
いやそれにしても、キースイッチの押し心地はいいし、キーキャップの色は自分で好きなように変えられるし、配列に不満があれば変えればいいし、分割キーボードは肩回りの負担が確かに少ないし、これはちょっとハマりそうですね。。。！
Ergo42を組み立てています（そしてどうやら失敗しています）
[追記 2018-07-27] 組みあがりました
[/追記]
最近突如として自作キーボードに興味が出てきて、電子工作のスキルなんて全然ないのに道具を揃えてErgo42を組み立ててみることにしました。 （作者のBiacco42さん、ありがとうございます！）
組み立て手順については、qiitaにある組み立てログを参考に作業を進めていました。
ただ、Pro Microの右側の取り付けで盛大にミスをしてしまい、左側と同じ付け方をしてしまいました。 （チップやLEDが見える方を上側にしてしまった） なので慌ててスプリングピンヘッダを切って無理矢理取り外し、Pro MicroもAmazonでほぼ同じものを購入し、正しい向きにした状態で改めて装着しました。
そんなこんなでキースイッチを全部半田付けしていざ試してみたところ、右側のキーボードの左から2番目の縦一列（デフォルトのキーマップで言う「U」「J」「M」「'」）のキーが全て効かない状態になっております。。。 以下、自分なりにトラブルシュートを行ってみました。
- ４つのスイッチを全部差し替えてみましたが、特に挙動に変化はありませんでした
- テスターで導通チェックをしてみましたが、絶縁状態にはなってないようでした
- ダイオードの向きも問題ないようです
- 右側のファームウェア書き込みのついでにいくつかキーを打ってみて、やはり当該のキーだけ打てませんでした
- 左側との連係ミスとは考えづらい
となると、あと考えられるのは
- Pro Microを外した時に必要以上に強い力がかかった
- 目視する限り、基盤には影響はなさそうでした
- ニッパーでスプリングピンヘッダを外す時に一部エッチングが削れてしまったというのはあります
- 半田と半田ごての扱いが未熟でPro Microを痛めた
ですかね。。。 自分のスキルを差し置いて希望だけ書いておくと、Pro Microを使ったキーボードで縦一列が使えなくなる、というのがよくある失敗パターンとしてあって、何かをやり直したら解決する、だといいなぁ。 そうじゃないとしたら、もう1セット買って右側を作り直すしかなさそうですね。。。
左側は全キー問題なさそうなので、キーキャップまで全部着けました。パステル系のキーキャップを買ったので予想通りかわいい。
この左から二番目の縦一列が全滅です。因みにキースイッチはkailh pro purpleです。打ち心地いいですねこれ。
右側のPro Microを上から見たところです。
右側のキーボードを基盤裏から見た図です。
Docker for Windows 18.03で/var/run/docker.sockがマウントできなくなってた
sqsdの最近のアップデートについて
以前「作った」と書いたsqsdについて↓ taiyoh.hatenablog.com
最近これのバージョンアップを頻繁に行っている。
Release v0.0.4 · taiyoh/sqsd · GitHub
v0.0.3～v0.0.4の差分
社内のgoの達人方にレビューしてもらい、channel capacityを導入したところコードの見通しがものすごく良くなったので、v0.0.4として一旦リリース。
workerに送るqueueをchannelによってブロックできるようにすることで、余計なmutex等を入れずに安全にqueueをworkerに送れるようになった。
このシーケンス図を同僚に見せたところ、「これは producer-consumerパターン で書くといいですね」というコメントをもらう。
Release v0.0.5 · taiyoh/sqsd · GitHub
producer-consumerパターンは自分の中で咀嚼が必要だったので、一旦保留。
そろそろログ周りを整理したかったので、このQiitaの記事を読んで hashicorp/logutilsを入れることにした
この時点では構造化ログまでは必要ないと思っていて、ログレベルが調整できればいいと考えていた。
Release v0.5.0 · taiyoh/sqsd · GitHub
producer-consumerパターンがやっと自分の中で咀嚼できたのでリファクタリングを開始。やってみたところ、今までJobという名前のstructがqueue自体の保持だけでなくconsumerの責務も負っていることが分かったので、それを分離したところ、それだけでほぼproducer-consumerパターンといえる組み方ができてしまった。あとはそのデザインパターンを適用していることを示すためにJobやWorkerという言葉は避け、producerやconsumerという言葉を使うことにした。
デザインパターンの適用をはっきり見せることができたので、βクオリティということを示したいのでバージョンを思い切って上げることにした。
Release v0.6.1 · taiyoh/sqsd · GitHub
SQSのqueue urlの構築をパラメータから行うようにしてしまったため、例えばローカルで開発する時など、awsに飛ばないようにしなくてはいけない。
そのため、強制的にURLを指定できるようにもした。
また、実際にプロダクトに投入される時のことを想像したとき、万が一workerの起動が遅かった時、queueの取得が先に行われてしまうとvisibility timeoutが発生してしまうのではないか、ということに気づいた。その解決策として、producerの起動前にhealthcheck用のエンドポイントにリクエストを行い、その時のレスポンスコードが200を返したときにworkerの準備ができたとみなすことにした。それが済むまで、SQSへのqueueの取得は行わない。healthcheckに対してはexponential backoffアルゴリズムに従ってリトライを行い、これが規定の秒数に達しても200が返せないときはsqsdごと落とすようにした。この挙動はconfに healthcheck というセクションが定義されている時のみ行われる。optionalとしているが、なるべく定義した方がいいのでは、と考えている。
Release v0.7.0 · taiyoh/sqsd · GitHub
queueの取得の性能について以前からぼんやり気になっていたので調べていたところ、上記URLに答えが書いてあった。（当然金はかかるが）ガンガンリクエストして取りに来てくれ、ということのようなので、遠慮なく一度に複数リクエストを投げられるようにした。v0.0.4の時にchannel capacityの対応を入れていたおかげで、投入部分は何も気にすることなく対応できたのがとてもよかった。
取り急ぎどうしても必要そうな更新は終わったつもりだが、これからまだまだ必要な機能実装はあるかもしれない。直近ではログの構造化を考えている。
また、イケてない箇所は優しくissueをいただけますと :pray:
「エンジニアリング組織論への招待」を読んだ
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
1章の「get wild and tough」でいきなり引き込まれ、2章で自分がメンタリングされている気分になっていた。読んでるだけで気分がよくなってきたので、自分が今まず欲しているのはこれなのかもしれない。これらを序盤に持ってくるあたり、「まずは自分のスタンスを変え、個々人間の情報の非対称性をなくしていくことが重要だ」と言われているように感じていた。3～４章ではチームビルディングやアジャイル・そしてそこから派生したプロジェクトのイテレーション手法について触れているが、どれもやはり「個人の情報の非対称性が少ない」というのが前提に立った話のように僕は捉えた。裏を返すと、情報の非対称性に対処するという基本的な部分の努力が払われないままリーンやアジャイル、スクラムといった手法を取り入れても、ただ恰好だけ真似しただけで早晩破綻するだろう、とも受け取れる。事実、自分たちのチームのスクラムの体制は半分くらい崩壊しかかっている。導入した当時は「今必要だからスクラムを導入するしかない」と思っていたつもりだったが、今振り返ると、その前にやることがあっただろうと思える。
結構注意しなくては、と思ったのは、4章後半～5章にかけて「適切に権限移譲せよ」と書いてあったのだが、これを微妙な形で適用して結局「プリンシパル・エージェント関係」に陥らないかというのが心配になった。それを抑制するために、まずは個々人間で情報の非対称性を減らし、メンバーが増えてきたらチーム間の合意のためのプロトコルを作って、という形を適用していくのがいいのではと思うが、恥ずかしながら自分にはそうした世界を実感したことはない。
とりあえずこの本は目から鱗が落ちまくってるので、読み終わる前からすでに事業部の何人かにパワープッシュしている。「不確実性を減らす」というエンジニアリングの本質ができる環境を作りたい。
「GraphQL over WebSocket Protocol」という仕組みが提案されてるらしい
というのをたまたま調べものをしてる時に見つけた。 github.com
（以下このプロトコルは GoWP と書きます）
GoWPだとどのクエリでもWebSocket通信上でできるように、ということが想定されているが、何より主眼に置かれてるのはsubscriptionへの対応ではないだろうか。
コネクション確立からクエリの登録までのプロトコルが明文化されているので、そうした足回りは対応ライブラリがあれば任せられそうというのがいいな、と。
例えば、golangでのGoWP対応ライブラリは以下のようなのがある。
これを見つけてから、
subscriptionでストリーミングしたいデータはHTTP通信で外から登録チャンネル毎に受け渡せる- 部外者に見せたくないデータが誤って流れるのを防ぐために、ユーザを指定できるようにしてもいいかも
- アプリケーション上でのIDはJWTで受け渡してAuthenticateのタイミングでライブラリ上でコネクションIDとマッピング
なんてことができるプロキシサーバがあるといいかも。。。と妄想が一気に膨らんだところだった。
ただ、恐らくまだGraphiQLが対応してないので、今までと同じような開発体制が組めないというのはデメリットとしてありそう。
あと、ユーザ指定して任意のメッセージをサーバから送りたい、というための仕組みとしては kuiperbeltが既にあるので、そもそもserver pushの土管が用意できればいいだけなのにそこまでGraphQL使わないといけないのかとか、色々考えることはある。
