退職エントリです(この文言を書いてみたかっただけ)．7ヶ月くらい長期インターンシップとしてお世話になった株式会社Moffを退職しました．
先に書いておくと，辞めた理由は，研究活動が本格的に忙しくなりそうというのと，任されていたタスクがある程度区切りが見えたからです．負の感情で退職したわけではないので，勘違いしないでよね1．
今回の記事ではどれだけお世話になって，この半年でどれだけ強くなれたかを
- 技術的側面
- 技術以外でいろいろ感じたこと
の二本立てで書いていこうと思います．長いです．長いので以下の目次で興味のあるトピックを読むことを推奨します．当然ちぎちゃんのファンの方は全部読むと良いです(?)
馴れ初め
今年の2月頃に，もうそろそろ実践的なアルバイトをしたいなぁと唐突に思い立って就職活動(?)をTwitterではじめました． bioとスクリーンネームだけを変えるだけの荒い募集をしたらありがたいことに複数の会社からお声掛けを頂きました．Twitterすごい
その中で最も興味を持ったかつ，丁寧に社とのマッチ具合の高さを初手のDMで説明してくれた，更には私自身のスキルセットをかなり評価してくれていた会社に話を聞きに行って，面談の後その場で来週から行きますと伝えました．
圧倒的スピード感です．
待遇とか，環境とかそういうのも大事なんですけど，もうほぼ第六感でここなら圧倒的成長と裁量を与えられる予感がしたので，そういう指標に頼って就活するのもありです．何より，がちんこの新卒就活みたいなのじゃないので失敗してもとっとと辞めればいいだけの話と適当に考えてました
技術的にやったこと
やったこと概要
技術要素
SDK改良
Swiftが思ってたよりもつらいなぁという気持ちで書いてました．KotinやScalaの基本的に式みたいな概念に慣れまくっていたせいか，tryやifが式でないことに若干のつらみを思いながらもコードが書けてよかったなぁ．ReactiveXへの理解もここでかなり深まり，後にSyncPodのAndroid版のactioncable周りをRxにラップするところでめちゃくちゃ役に立ちました2．
具体的にはライブラリ側ではlistenerとして実装されているものをすべてsubjectとして再定義してあげ以下のようにstreamを流してあげる必要があるということです．例はsubscriptionが生きているかどうかのlistenerに対してstreamを発行しているSyncPodでのコード例です．これに加えて例えば新規chatが来たら元のライブラリではlistenerに登録した特定のメソッドが呼ばれますがこれをハンドルしてFlowableにしてアプリケーションに返してあげるなど✌Rx満載✌にできたのはmoffでのSDK改善の経験があったからだと思います．
return Completable.create { emitter -> subscription?.onConnected = { emitter.onComplete() manageEnteredStream.onNext(true) startRouting() } subscription?.onRejected = { emitter.onError(CannotJoinRoomException()) consumer.disconnect() } subscription?.onFailed = { emitter.onError(it) consumer.disconnect() } }
また同時にRxで動作させることの難しさの部分も見えました．元のコードがRxのstreamによって様々な処理が実装されていると当然，追加する機能もRxを用いて実装するほうがSDK全体の見通しがいい上に実装コストが落ちる可能性があります3． しかしながら，そのように実装していくとAを管理するstream，Bを管理するstream，Xという機能のcallbackが呼ばれたら発行するstreamといって，どんどんstreamの数が爆発しがちです．特にライブラリで作られていない機能をRxで作ろうとするとsubjectが増えるなぁと思いました．subjectはpub/subの双方ができるのでどういうタイミングで何が流れてくるのかを用心深く考える必要があります．
さらには，BLE周りの知識も別件でちょくちょく求められることがあったので，ここで一度整理できてよかったです．Central，Peripheralってなんだよ？みたいなBLE初心者は脱却できたかなぁ．
データ蓄積・分析基盤構築
AWSに本格的に触りました．AWSをその前に触ったのは 去年の夏 以来だったり，そもそも知識がかなり薄かったのでここで本格的にサーバレスなアーキテクチャやその他AWSの基礎知識や基本構成みたいなのを体で学んでいきました．
具体的に使用したサービスは，
いわゆるインフラ屋さんなことをするのは初めてで，オンプレじゃない分かなり楽ではあるんですが，それでもやっぱり大変なことが多かったです．基本的にググりまくってAWS documentやクラスメソッドさんの記事を斜め読む仕事をしていました．コードを書く機会が減ってちょっとつらい気持ちのときもありました．
ElasticBenastalkにはそれなりにはまって，.ebextensionsに書いた内容が確率的に呼ばれないというバグ(?)らしきものを見つけたりして楽しかったです．(未だにWebConsoleでNetwork Loadbalancerが指定できないのはなぜ？)
また，それに関連して日本語でも英語でも(?)まともに記事がなかった気がしたので，Qiitaの記事を書いてみたりしました．実はQiitaあんまり好きではないんだけどね
また，fluentd周りの知見を得たのもこのプロジェクトでした．fluentdはログ・メッセージの収集を確実に行うための仕組みをもったミドルウェアです．fluendのプラグインにPRを出そうとしてcloneして，そのまま忘れてしまったり，READMEのリンクがおかしかったのでPR出してみたりしました．なにげにこういうことをするのは初だったのでちょいと緊張しました．
ここでの私の最も大きな貢献は，テスト環境をちゃんと作れたことです(多分)．テストが存在しなかったのでそれを書きつつ，AWSの各サービスで動いているものをdockerに乗っけてそれでもってテストするというフローを作れたのはよかったです．その後機能更新するときにテストが走っていると，自分のやったことが活かされていて嬉しい気持ちになります．
また，負荷テストやベンチマーカーを作成して作ったシステムの数値評価をするスクリプトも書けたので良かったです．
それ以外にも
- ログを落とさずにデータレイクに流すにはどうすればいいか？
- ログが消滅した時にどこで落ちたかをきちんと探れる構成なのか？
- コストはどうなのか？
といった普段は一ミリも気にしないようなことを考えながら基盤構築するのは難しい半面，とてもためになりました．だいたい自分の出す意見には穴があっておもしろかったです(?)
気が向いたら，ここで学んだ構成とかを記事にしたいです．
IoT機器接続基盤の設計・実験的実装
このトピックは僕主導で行いました．Web上で大量の機器を管理したいというニーズはいろんな場面でこれから増えてくると思います(例えばedge computing)．そこでなるべく多くの処理をweb上で管理して設置するThingへのメンテナンス負担を下げたいと思うのが世の常だと．これを解決するひとつのプラットフォーム例としてAWS IoTがあると僕は思います．
AWS IoTのみを使って管理するには限界があるというのが現状です．基本的にThing同士やAWS IoTへのやり取りはMQTTベースで行われます(一部はAPIがありHTTPリクエストできます4 )．MQTTベースであるのはメリットとデメリットがあります．
メリット
- topicを用意すればstreamデータが扱える．
- 軽量
- topicに対してSQLlikeにfilterを掛ける事ができる5．
デメリット
- topicベースで考えないといけない．
- MQTTの規格自体では品質保証を0から2で指定できるが，AWS IoT上では最上位の品質である2を使うことができない．
- 確実にメッセージが届いたかどうかわからない．また，レスポンスがない．
これは明らかにfrontから触るのには限界があります．一番つらいポイントとして，確実にレスポンスとして返ってきてほしいリクエスト(なんらかの要求リクエストみたいなもの)と，多少損失してしまってもいいからとにかくstreamデータとして渡したいもの(センサデータを垂れ流すとか) を一つのプロトコルで解決しようとしているところです．これは特に前者が辛いことになってしまいます．そこで，以下のように要件を変えて解釈することにしました．
すべてのデメリットを吸収する仕組みをAWS上で作成し解決する．
つまり，AWS IoTのプラットフォームをwrapするような仕組みをAWS上に作るということです．これはできればサーバレスに作りたかった6．インターンでは最終的に以下のようなものを提案しました．
こうすることで，front側にはAPIとして提供しつつ，上のツラミポイントを吸収できました．インターンではこの構成に則ってデモを行ったりしました．よかったです．
上の成果以外にも，例えば，Lambda@Edgeを試したり，Greengrassを試したり， Jobを試したり，とIoTの機能は一通り触ってどういう構成にするのが最もいいのか？というのの調査に尽力しました．上の構成が最善手なのかは未だにわからないですが，現時点では結構気に入っています．
気が向いたら，ここで得たIoTの知見を記事にするor発表したいです．
技術以外に感じたこと
メンター編
メンターさんとしてctylさん についていただきました．実はインターンのお誘いをもらったのもctylさんでした．一緒に仕事をする上で的確に，適切にコミュニケーションを取る姿勢には本当に感謝でいっぱいです．僕自身，昨年の夏から課題に感じていた，伝えなければならないことを正しく言語化できないの問題をいち早く察してくれていたようにも感じます．そのお陰で以前に比べてコミュニケーションが大分上手になったと自負しています．
会社の雰囲気編
雰囲気は最高です．個人がそれぞれに仕事をしつつもきちんとチームとして連携する姿は週数日しかオフィスに行かない自分でも肌で感じていました．インターン生も多く，強い人だけでやっていこうというよりも，インターン生を育てつつ成長していくという感じがしました．ここらへんはインターン中にインタビューされた記事で諸々喋っている気もします．
また，最後のフィードバックではいろいろと褒めていただき，自分の自信にもすごく繋がりました．強いエンジニアに認められると自信がすごく付きました．
また，公式の開発者・エンジニア向けの資料は以下です．Moffに興味のある方はいかの記事をみてみるとよいんじゃないでしょうか？
今後
今後しばらくは研究活動に重きを置いた生活をしたいかなと思っています(そうしないと卒業できなさそう)．ただ，10:0で研究にフルコミットしたいわけでもなくて，9:1くらいでは細々と開発も続けたいと思っています．そういう選択はおそらくMoffでもできたのかもしれませんが，まだ自分自身冒険したいという思いや，Androidを書きたいという気持ちもあって今回は辞めるという決断をしました．
そういう意味では長期インターン・アルバイトに来ないか？というお声がけはいつでもお待ちしています．(それなりにスケジュールは話し合う必要はありますが．．．．)
以上，長くなりましたが退職エントリという名の備忘録でした．
スッ (・ω・)⊃ wishlish
