読者です 読者をやめる 読者になる 読者になる

ほとラボ

It works!

ServerlessConf Tokyo に参加したけど残念だった

前々から楽しみにしていた ServerlessConf Tokyo に参加したけど、1時間も経たずに帰ってしまった。

tokyo.serverlessconf.io

ちなみに前日のワークショップはとても面白かった。

金曜日の疲労感でとても濃いワークショップを4時間やったらとても疲れてしまって、朝起きることが出来ずに昼から参加したのだけれど、行ってみたらイベント運営の不備みたいなものが目についてしまってどうしてもコンテンツに集中することができなかった。

受付がない

カンファレンスと言えば、会場に着いたら受付をしてスポンサーノベルティを貰って着席する、というイメージがあったのだけれど、ServerlessConf では「受付どこかな」と探しているうちに発表部屋に着いてしまった・・・。

遅れて参加したから受付なくなっちゃったのかな・・・。 「見逃した」ということはなさそう、「受付はない」という感じだった。

これ、仮にも 3000 円するイベントだよね? そんなにすんなり入れちゃって大丈夫なの???

「金払ってなくても入れる」って金払った人に失礼だと思うんだけども。

「Amazon Cognito 使ってどうのこうの」云う前にまずは会場の認証をどうにかしたほうがいいのではないか。

なぜこの会場にしたのか

会場が、技術系カンファレンスをやるには向いてないとしか言いようがない。

まず 電源 も Wi-Fi もない ということ。

エンジニア向けのイベントって参加者が PC 広げて Twitter で実況とかするのはよくあることだし、そういうところから「イベントが盛り上がってる感」が醸成されると思うんだけども、それが極めてやりづらい会場だった。

2時間程度のイベントなら バッテリー + テザリング 使えばいいという話だけど、丸一日あるカンファレンスだとそうもいかない。「Twitter 実況がしたければモバイルバッテリーをご持参ください」という世界観なのか。せっかく盛り上げるチャンスなのにそれはもったいなさすぎないか。

もうひとつは、会場の構造が微妙 ということ。

写真を見てもらえばわかるが会場が縦長で、後ろの方に座るとまあ見にくい。 特に両端の席に座ると上の構造物でスライドの一部が隠れてしまって見えない。

「電源 Wi-Fi がない」「会場の構造が微妙」のどちらも許容できなくはないし「会場の質」はイベントの本質じゃないとはいえ、技術系カンファレンスを開催するにはあまりに不適切じゃないだろうか。本来楽しめたはずのコンテンツが全く楽しめなくなるような会場がチョイスされてしまったのは非常に残念だった。

最後に

前日のワークショップは面白かったし、発表資料も読んでいてとてもタメになったし、コンテンツの質が高いだけに本当にもったいないイベントだった。

サーバレスな技術にはすごい興味があるのでまた同様のイベントがあったら参加すると思う。 次回はもっといいイベントになることに期待したい。

ISUCON 6 予選に出て 0 点だった

f:id:hoto17296:20160918092910j:plain

今年も ISUCON 予選に出場したけど、最終スコアは 0 点だった。

写真はあまりの不甲斐なさに食べた地獄谷麻婆豆腐

3回目の出場で、練習会も開催して、当日までの準備もバッチリ整えてやった結果が 0 点というのかなりヘコむ事態。

blog.hotolab.net

事前にやったこと

  • Slack にプライベートチャンネルを作る
  • Azure に慣れる
  • NewRelic と Mackerel のアカウントを作る
  • 事前に「Node でやろう」と決めておき、プロファイルの仕方などを調べておく
  • Azure でインスタンスのクローンするの大変そうだったので1インスタンス内で全員作業することにする
    • そのため、インスタンス外にリポジトリは作らなかった

午前中まではよかった

  • 開始30分前に全員集合
  • インスタンスを立てるのは難なくクリア
  • サービスふたつあるし、isupam とかいう謎サービスも動いてるし、お題「マイクロサービス」っぽい
  • Node 実装、どうせ Express だろうと高を括っていたらまさかの koa
    • Node の初期実装がバグっていたのもあって「ここで頑張るのはやめよう」と判断し、Ruby に切り替え
  • NewRelic と Rack::Profiler 入れてベンチマークを回してみる
    • まあどう見ても htmlify がボトルネック

実装力が低かった午後

  • 毎回 htmlify するのどう考えても無駄なのでどこかにキャッシュするしかない
    • htmlify 済みの文字列を MySQL にカラム増やして突っ込めば良さそう
    • エントリが増減する度にすべてのデータを更新する

ここまでは誰でも思いつくはず

DB 初期化

エントリが増減すると初期データのレコードが更新される → 初期化処理が「id:7101 以降のデータを削除する」だけではダメ

MySQL の初期データを作って /initialize 時に5秒以内にツッコめばいい、ということになる。

  • mysqldump : 軽く5秒以上かかるので無理
  • xtrabackup : MySQL 5.7 で動かずに困惑
    • 今思えば MySQL を 5.6 に下げればよかったでは

どっちもうまくいかなかったので「MySQL のデータファイルを直接置き換える」という力技で突破

Unicorn 再起動

  • MySQL を再起動すると Ruby からのコネクションが切れる
  • コネクションが切れたときの貼り直し方がわからない
  • /initialize 時に Unicorn を再起動しよう
  • Unicorn が自分自身を再起動させるとうまくいかない
  • 初期化用の別アプリケーションを実装して、/initialize のアクセスをそっちに流す
  • 初期化用アプリケーションが MySQL と Unicorn を再起動する

なんか・・・コレジャナイ感が漂ってきた・・・

MySQL が死ぬ

再起動はできたものの、initialize 後に MySQL が死ぬ現象に戸惑っていたところで時間切れ

反省

  • 初期化処理に時間かけすぎた
    • 初期かそんなちゃんとやらなくてもベンチマーク通った気がする
  • 1インスタンス内で全員が作業するの良くない
    • 検証したくなる度に「いまブランチ切り替えていい?」って気にしなきゃいけないの無駄
    • 多少時間使ってでもインスタンスは複数立ち上げるべきだった

他にも色々と試みてたけどそのへんは他のメンバーが書いてくれるはず

まとめ

  • ISUCON 4 は何もわからないまま終わった
  • ISUCON 5 は頑張ってチューニングした箇所が大してボトルネックじゃなくてスコアが上がらなかった
  • ISUCON 6 はボトルネックの見極めまではできたが、実装力の低さと時間配分ミスから爆死 ← NEW!

少しずつ成長してはいるけど、まだ決勝行ける実力ではない・・・

はーーー 悔しさ〜〜

謝辞

今年もとてもおもしろい問題でした、運営の皆様ありがとうございました!

ISUCON 練習会をするために InfluxDB + Grafana でポータルサイトを作った

9/17,18日に迫る ISUCON 6 予選に向けて、某若手エンジニアコミュニティで参加者を募って ISUCON 練習会を開催した。

お題は今年の出題者である pixiv さんが社内 ISUCON を開催したときの AMI を活用させていただいた。

inside.pixiv.net

やってみた結果については同じチームだった sota1235 さんがまとめてくれているのでここには書かないが、まあここままだと決勝進出はまず無理だしもっと予習を頑張らないといけない。

ポータルサイト使えない問題

本番の ISUCON ではポータルサイトが用意されていて、ベンチマーカーを実行すると自分のチームのスコアがページに反映され、また他チームのスコアもリアルタイムで確認することが出来る。

しかし ISUCON 終了後に練習用 AMI が公開される際にはポータルサイトの AMI は公開されない。一人で予習復習する分にはポータルサイトは必要ないのだし、そりゃそうだ。

しかし今回の練習会のように複数チームでわいわいやるのであれば、本番さながらに他チームのスコアがリアルタイムで見れたほうが間違いなく楽しい。こうなったら自分で作るしかないので、試行錯誤を重ねてそれっぽいものを作った。

1行もコード書きたくない

まず思いつくのは、愚直に「スコアを MySQL か何かに保存して Google Charts のようなグラフ描画ツールで表示する Web アプリケーションを開発する」こと。 ただこれは極力やりたくない。 超汎用的な手段で無理矢理解決しにいっている感じがあって、面白くもなんともない。

21世紀という便利な時代なんだから、きっと他にもっとこのニーズに最適化された解決策があるはずだ、と思う。 エンジニアだからこそ、安直にプログラミングで解決しにいってはいけない。 「送られてきたデータをグラフで表示する」くらいのシンプルなニーズであれば、1行もコードを書かずに解決したい。

あと思いつくのは Mackerel にスコア飛ばすくらいだけど、無料プランだとホスト5台までだから5チームまでしかできないのかー、でも有料プランを使うと1ホスト(チーム)あたり1800円かかってしまって現実的ではない、という感じでコスト的に除外。

そんなことをあれこれ考えてるうちに、時系列 DB を使ってみようと思い立った。

時系列 DB の機運

時系列 DB はその名の通り時系列に沿ったデータを取り扱うのに特化した DB。 用途が限定的だ思うかもしれないが決してそんなことはない。 よくよく考えると多くのデータにはタイムスタンプがついていて、それを可視化しようとなったら時系列に沿ったグラフを表示することが多いので、時系列 DB が活用できる場面は思っていた以上に多い。

時系列 DB にもいくつも種類があるが、今回は

  • 簡単に扱えそうだから
  • 比較的新しいっぽいから
  • オシャレっぽいから

という雑な理由で InfluxDB を使ってみることにした。

趣味プロダクトだし、ダメだったらそのときに次の手段を考えればいいんや。

他の時系列 DB についてはこんな感じ。

  • Elasticsearch
    • fluentd → Elasticsearch → Kibana でログ可視化、という話はよく聞く
    • 単純なデータのグラフを表示する程度のニーズで使うには複雑すぎる
    • そもそも時系列 DB じゃないし
  • RRDtool
    • 枯れてる(らしい)
  • Graphite

詳しくは: 時系列DB・可視化のいまむかし - Qiita

今回は用途が小規模かつ1日だけだったので、可用性だの何だのということは一切考えていない。 長期的にメトリクス監視をしたいなどの場合はもっといろいろと検討した方がいいと思う。

ポータルサイトでスコアを集計する仕組み

  • 競技の参加チームにはベンチマークサーバにスクリプトをひとつ入れてもらう
    • ベンチマークを実行する際にはそのスクリプトを実行する
    • スクリプトを実行すると、ベンチマークが実行されると同時に InfluxDB のサーバへデータが送信される
    • そのスクリプト: ISUCON/bench.sh at master · ngineerxiv/ISUCON · GitHub
  • InfluxDB のデータは Grafana でリアルタイムに可視化される

f:id:hoto17296:20160904205703p:plain

実際の様子

触ってみた感想

InfluxDB は導入・設定も簡単だったし、スキーマレスだし、データ構造がシンプルだし、とっつきやすいことこの上なかった。

Grafana は InfluxDB のみならずいくつもの時系列に対応していて便利。 InfluxDB がシンプルな分を Grafana のリッチさがカバーしていて、良い組み合わせ。

InfluxDB / Grafana ともに公式ドキュメントがちゃんと書かれていて、導入方法とか書こうと思ったけど特に書く必要もないかなと思った。

まとめ

  • InfluxDB + Grafana で ISUCON 練習会のポータルサイトを作った
    • シェルスクリプトちょっと書いたけどほぼ「コード書かずに」作れた
  • InfluxDB も Grafana もとっつきやすくて便利

Gotanda.js #5 in TORETA を開催しました

f:id:hoto17296:20160903160548j:plain

昨日 Gotanda.js #5 を開催しました。

gotandajs.connpass.com

Gotanda.js のイベント会場は毎回違う場所でやっていて、今のところ

  1. モバイルファクトリー
  2. ガイアックス
  3. freee
  4. Retty

(敬称略)

という感じでやっています。 同じ会場でやらないみたいな縛りはないんですが、毎回違うと五反田のいろいろな企業を知れていいですね。

第5回の今回はトレタさんのイベントスペースをお借りしました。 会場提供ありがとうございました。

toreta.in

今回も雑な感じで LT 会がはじまります。

WebAssembly 入門 @pine613

JavaScript から WebAssembly を呼び出したり、WebAssembly から JavaScript を呼び出したりする話。

Vue.js The Progressive Framework @kazupon

Vue.js の重要なコンセプトである Progressive Framework についての話。

フロントエンド辛い問題に陥らないためにはアプリケーションの複雑性と向い合って適切な技術選択をする必要がありますね・・・

個人的には、Progressive Framework の5段階の領域のうちビルドシステムが最後のレイヤーにあるのが不思議だなー、と思いました。

Vue.js 0.12から2.0.0への移行 @nekobato

タイトルの通り、Vue.js のバージョンアップをした話。

「これ本当はやっちゃダメなんだろうな」と思ってた所は動かない

という言葉が印象的でした。

Introducing WebVR API 1.0 & A-Frame Updates @ikkou

ご近所 Meguro.es や VR Tech Tokyo でお馴染みの ikkou さんの、ブラウザから VR が出来る WebVR API の話。

個人的には昔遊んでいた LeapMotion で VR コンテンツが作れると聞いてまた遊ぶしかないな・・・!という気持ちになりました。

APIドキュメントにまつわる試行錯誤 @mizuki_r

API Blueprint から Controller は作れるのか、という人類の限界に挑戦(?)した話。

Apolloを使って、React-Reduxの世界にGraphQLを持ち込む @chuck0523

www.slideshare.net

React / Redux から GraphQL を使うための Apollo の話。

すごく丁寧に紹介されていて、GraphQL 触ったことない自分でも Apollo 使えば出来そうな気がしてきました(出来るとは言っていない)

QRコードwebアプリ作ってみた @tommie

Sails.js を使って QR コードをメモ的に使えるような Web アプリを作ったという話。

おもむろに QR コードが印刷されたシールを配りはじめるという斬新な LT でした。

FLIP Our Animations @ktsn

アニメーションのライブラリである FLIP とフロントエンドの各種フレームワークを組み合わせて使ってみた話。

多かれ少なかれそれぞれのフレームワークに躓きポイントがあり、やっぱアニメーション難しいな〜〜〜という感想でした。

次回は 12 月・・・?

今回もたくさんの方にご参加いただきましてありがとうございました!

次回 Gotanda.js #6 は 12 月に開催される予定です。 乞うご期待〜〜〜

100000000000000ジンバブエドル手に入れた

f:id:hoto17296:20160820134454j:plain

16日に26歳になったのだけれど、ウィッシュリストに入れていた100兆ジンバブエドルを id:arata3da4 が贈ってくれた。

ジンバブエドルとは南アフリカ南部のジンバブエで2015年まで使われていた通貨。 2009年には年間インフレ率 2億3000万% に達するなど驚異的なハイパーインフレに陥った。 ちなみに100兆ジンバブエドルは日本円に換算すると 0.34 円とのこと。

ハイパーインフレに至るまでの経緯は以下のカスタマーレビューが詳しい。

100兆ジンバブエドルの経緯

めちゃくちゃな政治をするとこういうワケのわからないことになるぞ・・・という戒めとして(?)大切にしたいと思います。

Angular と React の違い

Anguler 2 ハンズオンに参加してきた。

connpass.com

今まで React ばかり触っていた自分にとってはなかなか刺激的だったので、ハンズオンをやってみて思ったことや、懇親会でサポーターの方と話していたことについて書いていく。

なお、Angular 1 は触ったことがないので「Angular 1 との違い」については触れない。

免責、というか言い訳

React についてはそれなりに理解しているつもりだけど、Angular に関しては本当に「1日触っただけ」の経験値でこのエントリを書いているので・・・その点あらかじめご承知いただきたい。 わかりにくい表現や間違い等があったらご指摘いただけると嬉しい。

Angular 2 はフルスタックではない

「Angular はフルスタック」という言葉をよく耳にしていたので「フルスタックフレームワークこわい」と身構えていたものの、Angular 2 を触った感じでは別にそんなことはなかった。Angular 1 には Controller があったらしいので、おそらく Angular 2 からはフルスタックではなくなったということなんだと思う。

実際 Angular がやっていることは、コンポーネントを定義してそれをレンダリングするということだけ。

ビジネスロジックを担当するオブジェクトをコンポーネントに依存性注入(DI)する仕組みが用意されているものの、注入するオブジェクトそのものは開発者がよしなに設計・実装しなきゃいけないし、Angular 本体はプレゼンテーションロジックに徹しているといえる。

HTTP やルーティングの仕組みもあるが、あれは「Angular が公式で周辺モジュールを用意している」という程度のもので、Angular 本体 (angular/core) とは切り離して考えることが出来る。

Angular 本体がやっていることといえば、ユーザーが DOM を触らなくても済むようにプレゼンテーションロジックをラップするということ。

あれ? これ React とだいたい一緒じゃん。

Angular 1 のことは知らないが、少なくとも Angular 2 は責務が小さくまとまっていていい感じに設計されていると思う。 Angular 2 はフルスタックではない。

DOM 操作つらい問題に対するアプローチの違い

じゃあ Angular と React は何が違うのか。

そもそもが「SPA をやろうとすると人間が DOM にパッチを当てに行くのが辛すぎる」という課題があって、両者ともその課題を解決しようとしているが、そのアプローチの仕方が全く違う。

  • React は「ページ遷移 → サーバから新しい DOM を返却」という、「昔の Web の一連の流れ」をすべてブラウザ上で完結させることで解決する
  • Angular は「DOM のパッチ操作は全部フレームワークが面倒見るわ」という方法で解決する

という感じ。

それに伴ってコンポーネントの表現の仕方も異なっている。

  • React ではコンポーネントを命令的に記述する
    • 更新のたびに呼ばれる render メソッドを実装する
  • Angular ではコンポーネントを宣言的に記述する
    • 表示したい DOM のカタチを記述するだけで、あとは Angular がよしなにやってくれる

全く違う方法で同じ課題を解決しようとしていて面白い。

その他の違い

以上に書いたことが Angular と React の最も大きな違いだと思った。

その他には「React はブラウザ以外での用途*1もあるが、Angular はブラウザに特化している」などの違いがあるが、些細な事だと思う。

総じて感想

  • Angular と React は「やろうとしていることは同じ、アプローチが全く違う」という印象で面白い
  • 個人的には Angular に「なんか気持ち悪そう」という偏見を持っていたので、実際に触ってみて「Angular ええやんけ!」ってなった
  • Angular は最近だいぶいい感じになってきた*2とのことで「いまが Angular 始めどき!」という感じ

*1:サーバーサイドレンダリングや React Native など

*2:公式のルータ(v3)がようやくマトモに使える出来になってきた、など

はてなブログに引っ越した

昔はブログのメンテが好きで自分で様々なツールを使ってブログを作っていたものの、最近は面倒くさくなってしまってとうとう はてなブログ Pro に登録してしまった。

Jekyll からの移行

こないだまでは Ruby 製のブログフレームワークである Jekyll を GitHub Pages で動かしていたのだけど、Jekyll で書いた記事をはてなブログに移行するのがかなり面倒で、Selenium WebDriver を使った自動投稿スクリプトを書いて移行した。

github.com

この辺の話はまた後日詳しく書こうかと思う。

というかはてなさん是非 Frontmatter な Markdown ファイルからはてなブログに移行できる機能作って欲しい。

課金してモチベーションを上げる

はてなブログ無料でも使えるのになんでわざわざ Pro なのかというと、「課金してるんだから」ということをモチベーションにしてブログを書くためだ。

ブログって (コメント機能を Disqus とかでやってしまえば) 静的なウェブアプリケーションだし、全然無料の静的ファイルホスティングでも運用できるんだけど、放置しがちになってしまった。課金しておくことで、自分の中のケチな精神が「そろそろブログ書けよもったいないだろ」と勝手に煽ってくれる。高校生がギター買うときにちょっと無理してでも高めのギターを買うことによってモチベーションが長続きするのと同じような話だ。

人間生きているうちは色々なことを考えるもので、それをアウトプットせずに忘れ去ってしまうのはもったいないと思うし、がんがんアウトプットしていきたい。