私的な 2015 年技術的な振り返り
Published: 2020-01-21 03:06:25


**自分のことだけではなく会社的な話も一部含む**

Pocket のログを見てたら今年は結構狭い技術の中で生きていたことがわかった。

## Erlang/OTP

ほとんどの時間を Erlang を書くことで過ごしていた気がする。 WebRTC を主にやっていたことから様々なプロトコルを実装したし、たくさんのバグを踏んだ。

Erlang が 1 プロセスでできる処理性能が秒間 5 万リクエスト程度とそんなに高くない事から、ほかの言語への移動も色々検討していた。 [CTO](https://twitter.com/szktty) に Rust を試してもらったり、知り合いのミドル系の人に相談したりしても、結局は Erlang を頑張る方が良いと思う。という回答を多く頂いた年だった。

結果的に Erlang ばかり書いていた気がする。来年も同じようになるのだろう。

Erlang は暗号部分が遅かった (EVP 非対応な暗号が多い) のは OTP 19 で改善されるようだ。rebar3 や公式のパッケージマネージャーも出てくる。

ただ ErlangVM の性能と I/O 部分が遅いのは今後も課題の一つだろう。

来年は Golang を眺めつつも Erlang に全力で投資する年になりそうだ。

Erlang に関しては別途もう少し掘り下げて振り返った。

[私的な 2015 年 Erlang/OTP 振り返り - Qiita](http://qiita.com/voluntas/items/51058b7e5dade64640fb)

## Rust

Golang にパターンマッチがないので、嘆いていたら Rust が良さそうということで、自分で調査するのはちょっとコストが高そうなので周りを巻き込みつつ調べてもらった。

結論としてはラーニングコストが高すぎるという所に落ち着きそうだ。自分のやりたいことがネットワークミドル、ここに対しての Rust は実績がまだあまりない。

システムプログラミングを目標としていることから性能を取るのであればかなり魅力。ただしラーニングコストが自分の脳みそでは高そうという印象は否めない。

いったん距離を置いてみるのが良さそうだ。2015 年内に決着できて良かった。

## Golang

Google の投資は半端ない。さらに周りに Golang 使いが多い。これはとても良い環境だ。特定用途のツールやアプリを作るにはとても良いと感じている。

実際自社パッケージ (OSS) を Golang で作ってみたがクロスコンパイルは強烈だし、複数人数での開発も特に問題なかった。とても良い言語だ。

公開前提の製品を作って行く場合は今後も積極的に使っていきたい。

## Lua

実案件に対して大規模な Nginx + Lua 投入で色々ノウハウがためられた。Nginx + lua 用のテストツールを作ったりと EtoE の部分でも投資できた。EtoE の部分は py.test + requests で実装して、うまくいった。

Erlang + Lua の可能性を去年見て、今年こそ何かに投資しようと思って色々作ったりしたが本番までは持って行けず。残念。

来年は組み込み言語として Erlang と組み合わせて、もっと積極的に使っていきたい。

## JavaScript

自社サービスを作り、自社パッケージのライブラリを作るために色々手を出した。ただ自分は書いてない。

- [Babel](https://babeljs.io/) + [React](https://facebook.github.io/react/) をベースとした
- [rackt/redux](https://github.com/rackt/redux) はクソ過ぎてリリース後、速攻で [mizchi/flumpt](https://github.com/mizchi/flumpt) に置き換えられてた。

余りよくわかってないのでコメントは控える。

## Electron

今年は Electron が自分の中では技術的に一番面白かった、といっても書いたことないし、ドキュメントを読んだだけ。

社内のツールとして WebSocket GUI クライアントを作ってもらったり、センサーデバイスの判定ツールを作ってもらったり。Electron はとても良かった。

セキュリティ問題がささやかれたりしているので、今後どう進んでいくのかはまだわからないが、 HTML5 のフル機能が使えて、HTML/CSS でデザインできる。この GUI プラットフォームは本当に強いと思う。

今後も Electron を使った何かを作っていきたい。

## WebSocket

Erlang で製品を書くことが多いので、 WebSocket との相性がとても良い。デバッグログは全て WebSocket 経由で流す仕組みを取っている。Electron でも苦なく WebSocket を使えることから積極的に使う。

JavaScript 書く側は状態を保持し続ける事からなかなかやっかいそうだったが、まぁ頑張って欲しい。

今後もサーバ側からの Push に対しては WebSocket を使っていきたい。

## WebRTC

もう相当詳しい方だと思う。ただ、まだまだ未知なことが多くてどんだけだよと思ったり。おかげで Firefox と Chrome (webrtc 部分限定) のソースコードを読む習慣ができた。

来年前半は WebRTC との戦いが続くだろう。そろそろ落ち着きたいがこれから Simulcast とかあって落ち着かせてもらえなさそう。

WebRTC に関しては別途もう少し掘り下げて振り返るかもしれない。

## MQTT

AWS IoT が出て、MQTT という言葉がまぁそこそこ聞こえるようになってきた。去年 MQTT 3.1.1 の機能をほとんど実装してしまったので特に今年は安定化以外はやることなかった。

MQTT は色々課題は残るがとても良いプロトコルだ、サーバの実装を考えなければ。

来年は MQTT x WebRTC を使ってうまく何かやっていきたい。

## Docker

自社サービスが Docker で運用されていないので、正直運用周りでの知識がないのが残念。ただプロダクトのパッケージングに Docker を早い段階で採用した。

これはかなりよかった。docker-machine への切り替えも docker toolbox が出る前に切り替えていたので違和感なく docker toolbox へ移行できた。

docker network が出てきて、今後はもっともっと docker な感じになっていくのだろう。

自社での使い方はパッケージングとテスト用のモック代わりとして使っているが、今後は自社サービスのデプロイなどにも使っていきたい。

docker-compose と AWS ECS の設定ファイルが互換性がある、これはとても大きい。ローカル環境は docker-compose でさくさくと立ち上げるし、そのまま本番へイメージを置き換えてデプロイも可能になる。

自動化のコストを減らせるかを Docker が色々な方面から解決してくれている気がする。

## QUIC

正直ほとんど追いかけられてない。 TLS + TCP over UDP の需要は今後増えてくるとみている。来年は少しでも QUIC に触っていきたい。

WebRTC の DataChannel が似たようなことを SCTP over DTLS over UDP で実現しているが、層が厚すぎる。QUIC over UDP はとてもいい選択肢だろう。

[QUIC and WebRTC DataChannels - Ian Swett - YouTube](https://www.youtube.com/watch?v=mIvyOFu1c1Q)

こんな話も出てるくらいなので、今後の動向に期待したい。

## BitCoin

気にはなっていたけど、いまいち追いかけてなかったのを年末に色々読んだ。改ざん不可能な取引履歴の仕組み、本当に面白い。新しい技術というよりはアイデアで解決して言ってる。

来年は少しブロックチェーンを触っていこうと思った。