久しぶりに年末にふりかえりのエントリが書けるかな。頑張ってみよう。

クラウドとよくできた通知システムとしてのチャットを取り入れた

昨年度から production 環境のクラウド化、リポジトリを社外ホスティングに移行、チャットシステムを入れ始めた。具体的には AWS S3, GitHub, Bitbucket, Slack, Sqale, EngineYard, Heroku, Papertrail, SendGrid, Redis Cloud, NewRelic, CircleCI, Codeship, DNSMadeEasy 辺り。S3 だけは以前から使ってたかな。今年はいろいろ噛み合って動き始めた感じ。

いちばんの動機は自分の仕事の中での「サーバ管理系の雑務」の割合を減らすことと外注と組めるようにすること。¹

もう一つの欲としては「この地域でもこういう面白い道具使って仕事してるとこあるんだぜ」というアピールなんだけど、これはまだうまくいってないので、それ以外の成果を書こうと思う。

いちばんうまくいってるのはゼロから自分の手で立ち上げた Rails プロジェクトで、これについては先日の CircleCI のエントリもそうだけど、GitHub, CircleCI, Heroku, Slack, NewRelic がバッチリ連携できてて非常に快適。気に入ってるのは以下の設定。

メール通知を完全にゼロにはできていないけど、日常的に「自分以外の人の動き」「アプリの負荷が上がった」「アプリのエラーが増えた」などが比較的小さな負荷で見えるようになった。

以前のサーバでは log からお手製の swatch みたいなやつを仕込んだりしてたけど、メールより断然スマホアプリと連携できて通知の on/off を細かく制御できる Slack が楽。できることが増えたので管理系の雑務自体が減ったかどうかで言うと実は微妙だけど、以前より全体の状況はつかみやすくなっていて、この部分が2015年最もライフチェンジングだったように思う。

この辺りは Kanazawa.rb の meetup では話題に出してはいるんだけど、日常的にこういうの使ってる会社はこの辺じゃあまりないので、工夫を共有するみたいなところまでは行ってないのが残念。ぶっちゃけると言語の話よりこういう話の方が好物ではあるので、みんながガンガン使えるようにおれが事例を作ってやるぜ。

そういや JAWS x Hokuriku.NET x Kanazawa.rb 合同勉強会でこの辺りの発表した資料上げてないけど、どういう理由で上げてないんだっけ。あぁ、たぶん単純にものすごく大変な時期だったんだろう…。

Kanazawa.rb x Hokuriku.NET x JAWS-UG北陸 : ATND

クラウドを前提にしたWebアプリの楽さと難しさ

とにかく環境の構築、スタートが楽、だけど作法は守ろう

というわけで、世界あるいはトーキョー的には今さらな感はあるけど、自分の中ではクラウド化というのが2015年のいちばんホットな話題。

実際には PaaS でやりますという決定だけして自分でやってないやつ、途中まで自分でやったやつ、立ち上げは自分でやって、移行を他の人にお願いしたあとにチューニングがまた自分の手元に戻ってきたやつなど、いくつかある。

いちばんライトなやつはポチってアプリ作ってポチってリポジトリ作って、bundle install と push しておしまい、みたいなやつで、これは本当に楽になったなーと感じた。サーバに何が入ってて、とか何も気にしなくていい。.ruby-version と Gemfile.lock で決まる。Capistrano の設定も要らない。さすがにカップラーメン作るよりは時間掛かるけど、こんなんでいいんすか、という楽さ。

もちろん、そんな楽なものばかりではなくて、どれも一長一短というかうまくいっているところとそうでないところがあるんだけど、Heroku + Rails で動いているものが今のところいちばん「環境」としては楽。

とにかく環境が portable なのがとてもよい。development と production では middleware は割と違うんだけど、ちゃんと抽象化されているので production でしか動きませんということがほぼない。（なくもない）

12factor 的には当たり前の話なんだけど、これが実は当たり前じゃあないんだ。

というのも、いわゆる「本番での動作しか想定していない」という作り方をしてしまう人はやっぱりいる。結局その辺は PaaS か否かは関係ない。具体的には

• 秘密情報がハードコーディングされてる
• 画像アップロード周りで S3 の URL をそのまま DB に書いちゃう
• Nginx の設定に依存したコード書いちゃう
• reverse proxy の動作に依存したコード書いちゃう
• メール周りが SendGrid にベッタリ依存してて development や test で困る

それでいて

• ストレージが揮発することを忘れたコードを書いちゃう

2015 年だよー。Rails 登場から10年だよー。こんなことやったらテストの自動化も deploy の自動化も難しくなるじゃん、と自分は思うんだけど、そもそもそんな考えがないんだ。社会は厳しい。

こうなっちゃうと何が起きるかというと、単に PaaS はいろいろバラついてて制限が強くて面倒な環境だってことになっちゃうんだね。違うよ、そこは世界の優秀な人が書いたフレームワークがお守りをする部分で、自分で工夫して書いちゃダメなんだよ。自分で工夫して書いた部分がボトルネックになるのであって PaaS が悪いんじゃないよ。

確かにね、「ある程度から先の領域」に入ったら自分で工夫しなきゃいけないところは出てくる。でもほとんどのコードは過去の自分のやり方ではなく、世界の先達の作法に従った方がマシなんだ。だからちゃんと世界を知りなさいという話に尽きる。自分の過去、自分が今思いついたこと、隣の同僚、そういうレベルだけで仕事していいのはごく一部の人なんですよ。

話がそれた。要はちゃんと楽するための作法を知れということです。

楽するための作法を守っていないとどんどん開発速度は落ちていく

のだから。

例えば本番でしか動かないコードをコミットしたら「ローカルではちょっと書き換えて動かす」みたいなアホな手間が生まれる。一度入れたらその後ずっと開発コストは上がった状態になるし、まずミスる。「S3 が動いていれば ok」というコードにすると開発用の S3 が欲しくなる。逆に面倒になって画像が絡む部分はローカルではテストしなくなる。

開発コストを上げて品質を下げている原因は環境じゃない、開発者の姿勢とスキル。

これも2015年によく感じたことの一つだった。

まぁ、開発者のやる気を削いでしまう環境はあるかもしれない。残念ながら。でもそれを言い訳にして改善をしないのなら、そこを辞めた方が結果的にプロダクトを受け取るユーザーはハッピーになるんじゃない？ 君のコードは何のためにあるんだ。アホな組織のためにあるのか？

また説教くさくなった。いかんいかん。

構築は楽だけど IO のコストが見えるようになる

いろいろ楽になったけれど、PaaS は基本的に何もかもバラついているというのは事実で、環境の構築と再現は楽だけど、アプリは常に IO との戦いというのが見えるようにもなってくる。

Heroku + Rails のアプリの中の一つは徐々に

• ストレージを S3 に追い出す
• 開発環境を Vagrant Box に
• Ruby, Rails のバージョンアップと Heroku 移行
  • 開発環境を生 OS に（必要に応じて Foreman / Dotenv）

と変化させていった。いびつになってしまっている部分もあるけど、Rails と便利 gem のおかげで特に環境の切り替えがとても有効に使えていて、移行も比較的スムーズに行えたと思う。実際にはこのリポジトリを GitHub に置いて Heroku 化するダンドリだけ自分でやって移行作業は別な人にお願いしたんだけど。（並行して自分は何やってたかというと、全然違うプロジェクトが動き始めてそっちの設計と打ち合わせに掛かりっきりになっていた。）

今年の日記がぽっかり空いてるのはその時期で、これが実際に動き始めたら AWS の us-east と ap-northeast って遠い²なーというのが最初の課題。それまでもなんとなく S3 使い始めてから遅いなーと思ってたけど、サーバが海外に行っちゃってから遅さがいろいろなところで爆発＆管理系の要件が妙に重くなってきて、正直 Heroku めっちゃ遅いのでは？と思ったけど、単に実装がまずいだけだったという結論が出るまで、あれこれ試行錯誤が続いた。

最終的には

• S3 への無駄な通信が生まれないように手直し
• 妙に asset（特に画像）が多く、しかも cache の効かない書き方だったのは CDN に丸投げ
  • 今はどんどん画像をなくすようにしている
• えいやで全部書き換えてた DB のレコードを必要なものだけに絞る
• クリティカルなものからバックグラウンド処理に移行（Sidekiq の dashboard かっこいい）

みたいなことをやってた。あとは jpmobile をちょっと独特な使い方してて、それが Ruby と Rails のバージョンアップ時に悪さして、GC 止めたり元に戻したりと、

とにかく NewRelic をよく見ていた時期だった。

サーバ管理をしなくて済むように PaaS にしたらアプリもインフラも見るようになってた。一周回って元に戻る。

とは言え、「探る方法がポチだけで用意できて、しかも分かりやすい」「解決策がある」というのがいちばんの救い。その分、仕組みを考えるに当たって以前より広い視野を求められるようになった。そこはよい機会と捉えている。

次点

• PHP で packagist を使ってライブラリ公開
• Google Apps Script を使って管理画面をゼロから作らない

これも以前より方法の幅が広がった話。詳細は割愛。

その他

• PowerAssert を production で(?)使い始めた
• Mixpanel を一部で入れたり Google Analytics の staging 環境を用意したり、この辺はまたの機会に。
• Browserify と Mithril の実験。これを Rails 以外にも展開できると面白そう。
• 本を読む時間が全然なかった。WebAPI, Mithril とあとは縦書きの本を少々。

でも実は技術じゃない課題がどんどん膨らんでいく…。考えられる人が足りない。（足りないのは己の能力か）

今後の課題

今後はとにかく布教活動かなぁ。今のやり方はハマればすごくいいと思うんだけど、知らない人と組むことはできない。とにかく手が足りないので外部と組む必要があるけど、求めているのは「ちょっと Linux サーバ立てられます」みたいな人じゃない。ところが PaaS の経験のある人が地方にはとても少ない。pull-req を merge しただけで deploy できる環境があるって実感できてる人が少ない。ついでに言うと REST とか resource とかトランスパイラとか React系のフロントエンドの動きとか、ね。

まぁ東京のまねごとをしてるので東京に頼めばいいんじゃないの？という話になるかもしれないけど、予算がね…。ううう…。

布教の話はあんまり言うと全部自分が教える系になりかねないので、それは避けないといけない。じゃあどうやって盛り上げていくのかを考える必要はありそう。

あとはハードウェアまで含めた新しいことをやっていきたいなーなんてことを思いながら最近になってようやく RasPi とか Arduino とか調べてた。たぶん自分がやりたいことにいちばん近いのは Intel Edison Kit for Arduino なんだけど、もうちょっと手軽なものからちょこちょこと遊んでアイディアを膨らませていきたい。