portal shit!

Archives ページは部分的に React.js を使ってる。これを全部 React にして SPA 化してみたい。そのためには Server Side Rendering が必要。

Ruby で Server Side Rendering するライブラリでは react-rails が有名だけど、 Rails 以外で Server Side Rendering したい。

有名なやつでは airbnb の hypernova というのがあった。これ自体は Node.js で、 hypernova-ruby というクライアントからサーバーを呼び出して Server Side Rendering するというもの。なのでサーバー側に一個プロセスが増える。開発環境でも Node.js でプロセス起動したりしないといけない。仕事で Microservice には食傷気味になってきてるので趣味では Majestic Monolith™ で行きたい。

名前似てるけど Hyper-Ract というやつもあった。これは過激で JavaScript とか HTML を排除して Ruby で全部書こうぜという Opal が React 対応したもの。良いんだけど F/E の進化早すぎ問題に対応できなくなる気がする。数年後には CoffeeScript みたいになりそうな予感がある。スタンダードでシンプルなものを使いたい。

もう一個、スター全然付いてないしメンテナンスもされてなさそうなんだけど、 V8 で React 読み込んで出力するだけという簡単なのもあった。react-ruby-v8 という直球な名前。こんなので十分かもしれない。

京都であった RubyKaigi 2016 を観覧してきた。 RubyKaigi 、つくばであった 2010 がこれまでの人生での唯一の RubyKaigi で、人生二度目の観覧だった。

RubyKaigi 2010 の思い出

一度目のときは少し前に増田に上がってた勉強会ゴロ状態（受付の人と技術書を買ったジュンク堂の人と以外誰とも会話をせずに帰宅）だった。

ちなみにこのとき ESM の企業発表を見に行って、 ESM に転職したばかりの hsbt さんの姿を初めて目にした。なんか入社したばかりなのに社内ブログで暴れてて愉快、みたいな紹介のされ方だった。その後同じ会社で働くことになるとは思いもしなかった。

ESM の発表はとにかく鮮烈に印象に残ってて、ペアプロのライブコーディングだった。 ursm さんが CRM か何かの開発を実演してた。まず最初に落ちるテストコードを書いて、その後にパスするプロダクトコードを書く、というやつを初めて目にして、田舎で HTML コーダーをしつつちょっとしたプログラムを書いてた自分は衝撃を受けた。黒い画面の Vim で高速にコードを書いていく様がとにかくかっこよかった。はやくこういう感じでコード書けるようになりたい、と思ったものだった。

クックパッドの企業発表みたいのも聞きにいって、このときクックパッドもまだそんなにエンジニアの数多くなかったはずで、同じくはてなから転職してきたばかりのセコンさんが話してるのを聞いてトートバッグもらって帰った。

YAPC::Asia Tokyo 2015 の思い出

去年の夏、 YAPC で東京に行って、このときはペ社時代の知ってる人としゃべったりして無言の帰宅は避けられた。

YAPC 2015 は気がついたときには懇親会の申し込み締め切られててどこにも行けず、一人浜松町の宿泊先の近くの「とにかく安くて量が多い」と食べログにレビューが書いてある寿司屋に入って一人で寿司を食べたら寿司がねちゃっとしてて具合が悪くなったりしてた。

YAP寿司::Asia 始まった pic.twitter.com/5AI2FXedlJ

— morygonzalez (@morygonzalez) August 21, 2015

RubyKaigi 2016

今年も発表する側にまわったわけではないので一般ピープルである点は同じだったが、これまで話したことなかった人と話せたのがよかった。

取り分けよかったのが Fjord 社の komagata さんと話せたことだった。今後の Lokka の方針をどうするか開発者会議的なものを開催してババっと方針を決めましょう、という話をした。 Lokka 、思い入れがあるので積極的にメンテナンスに関わって今後も長く使い続けていきたい。

一日目

一日目は Kaizen Chat についてのブログ記事を公開するというタスクがあって、 Matz のキーノートとかはあまりじっくり聞けなかった。記事公開後に会社のブースで自分のシールを配布したりして公私混同してた。

今年の RubyKaigi は懇親会の枠が大きかったおかげで申し込みそびれるということにならなくてよかった。

オフィシャル懇親会で Fusic 社の k1low さんと初めてゆっくり話をした。Fukuoka.rb で顔を合わせることあっても一緒に酒飲んだりする機会なかったので RubyKaigi に来て初めてじっくり話すという感じだった。

ヒトデさんとその愉快な仲間たちの皆さんとも話して、 shikakun はオリジン弁当ばかり食べてるくせにやたら調理器具を持っていて不可解だとか、風呂蓋付きの浴室がある部屋にすんでいていけすかないという話をした。

Twitter で 8 年くらい前にハゲクラスタとしてわいわいやってた send_ さんとも再会できて、お互い帽子をかぶった状態でいまの仕事の話をしたりした。

オフィシャル懇親会のあとは、ヒトデさんオーガナイズの二次会に参加させてもらった。デンエンという物価が崩壊してる飲み屋に行ってタワーから注いで飲むビール飲みまくった。クックパッド社の著名エンジニアの皆さんと対面に座ったけど人に自慢できるような OSS とかなくて雑魚いので自己紹介に困ったが、とりあえずこういうアイコンのものですと言ってシールを見せたら「あ、なんか見たことある」という感じになったのでシール便利だった。

二日目

朝一番の Justin Searls さんのリファクタリングについての発表がとにかく面白かった。

RubyKaigi 2016, September 8..10, Kyoto, Japan #rubykaigi

September 8..10, Kyoto, Japan

rubykaigi.org

去年 YAPC で GitHub の人が話してた sicientist と似てるけど、リファクタリング前後のコードで A/B テストをする gem の紹介。新しい方のメソッドが例外投げたら rescue して古い方のメソッドを実行するというのが面白かった。本番にも安心して投入できるとのこと。

三日目

午前二番目に tkawa さんの HTTP クライアントについての発表聞いた。 HTTP クライアント乱立しててひどい、 API をラップしてリモートサーバー側のクラスを再現するような異常なクライアント多くて、 REST API とは一体何なのか状態だ、みたいな話だった。言われてみれば確かにそうかもしれない。独自の API クライアント作ることなく、 Rack が Rack Middleware を use して拡張していくみたいに、 HTTP クライアントの側でも Middleware を use していくのがよい、そこで Faraday ですよ、という話で、あ、 Faraday ってそういうことを目的にしてたんだと膝を打った。

午前中最後の Chris Arcand 氏の発表が面白かった。

RubyKaigi 2016, September 8..10, Kyoto, Japan #rubykaigi

September 8..10, Kyoto, Japan

rubykaigi.org

Ruby のコードを解析して呼ばれてないメソッドを調べる、という発表だった。実際に Rails プロジェクトとかで使うのは大変そうに見えたけどいまから君のプロジェクトに投入できるよ、 Rails もダイジョブみたいなことを言ってた気がするのでスライド見直したい。

最後のセッションの前、一日目のデンエン会で知古を得た pastak さん見かけたので uiureo さんを紹介してもらって話をした。 uiureo さん、初対面だけど話しやすくて好青年な感じだった。 r7kamura さんとも少ししゃべらせてもらってよかった。

飛行機の時間の都合があったのでクロージングまでは残らず、最後のキーノートの途中で離席して帰途についた。ホールを出ようとしたところで滑り込みで会場にやってきた元同僚の hisaichi551 さんと邂逅して自分のシールを何枚か雑に渡した。ゆっくり話がしたかった。

京都での開催について

京都での開催良かった。個人的には福岡からだと東京に行くよりも京都の方が近いので移動が楽で良い。首都圏からの大多数の参加者も京都に宿泊して参加するので夜通しどこかで RubyKaigi 関連の飲み会が開かれてる感じで祝祭感あった。夕方から観光したりできて海外からの参加者も満足度高いのではないかと思う。京都国際会館のインフラも素晴らしかった（施設、庭園、食事内容）。スポンサーの提供で振る舞われたお弁当おいしかった。

総合的な感想

RubyKaigi 、海外からのスピーカーの発表はどうやってよいコードを書くかとかリファクタリングとかの話が多い。日本人の発表者の人は Ruby を開発する方の話が多い。（ Ruby コミッターのほとんどが日本人だから）。なので Ruby 本体の開発に興味ない人（ Ruby 開発者ではなく Ruby ユーザーなプログラマー）はぽかんとすることが多いかもしれない。自分は結構ぽかんとしてた。

あと今回多いと感じたのが Concurrency についての話だった。どうやって Ruby で並行性を上げるかという話。 Thread は難しいので素人は手を出すな、ということはわかったけど Ruby 3 の Guild というので素人でも Concurrent なプログラムが書けるようになるかどうかは今ひとつわからなかったので資料を読み直したい（ reuibld.fm の Episode 158 を聞くと良い復習になりそう）。 Ruby 3 に並行処理の使い勝手が向上する前に、他の言語で並行処理について学んで準備をしといた方が良さそうだと感じた。

2010年の勉強会ゴロ状態のときに比べれば、何人かの人と話したりシールを配ったりすることができて、有意義な時間を過ごすことができたと思う。ただアイコンの気持ち悪さで認知されるよりも書いたソフトウェアの知名度で認知される方がよいので、カンファレンスに行って自己紹介するときに「○×というソフトを作ってます」と言えるようになりたい。仕事だけじゃなく、オープンソース活動もやっていけるように頑張りたいな、と気持ちをあらたにした会でした。

公私混同してる pic.twitter.com/nlrFCMOPXb

— morygonzalez (morygonzalez) September 8, 2016

Rails 、初心者にとってもよいフレームワークだと思う。いろいろ学びがある。ただ、なんとかスクールとかで金払って習うのではなくて、 DHH が書いてる『 Rails によるアジャイル Web アプリケーション開発』を読むのがよいと思う。あの本はコラム欄に Rails の裏側の思想とかが書いてある。なんとかスクールで習うのだと最速で Twitter クローンを作るだとか、 Rails の使い方しか身につかないのではないかと想像する。なぜ Rails はその様に作られてるのか、その裏側にある考え方は何か、まで合わせて学べばかなり色んなことが勉強できる。 Rails を使うようになって 5 年くらいになるけど、いまだに毎日発見がある。

http://david.heinemeierhansson.com/2012/rails-is-omakase.html

david.heinemeierhansson.com

Rails とかで例外が発生したときに Slack に通知するやつ作った。 exception_notification という便利 gem のプラグインとして動く。

GitHub - morygonzalez/exception_notification-slacky: Notify exception to slack channel

Notify exception to slack channel. Contribute to morygonzalez/exception_notification-slacky development by creating an account on GitHub.

github.com

実は ExceptionNotification 本体に SlackNotifier あるんだけど、通知内容があっさりしてて自分たちのユースケースには合わなかった。 IRC 使ってた頃は同僚のスーパープログラマー @udzura さんが作った exception_notification-ikachan を使ってて、それと同程度のエラー通知が来るのを Slack で実現したかった。

世の中には Airbrake のような便利なサービスあって、エラーの統計情報とか取ってまとめて通知してくれたりするものもあるけど、甘えてはいけない。エラーが即 Slack に通知されることで、バグを放っておくと Slack のチャンネルがてんやわんや状態になって業務に支障が出るのでバグを直すインセンティブが生まれ、ソフトウェアの品質が向上していくのである。

関わっているサイトの Rails のバージョンが 3.2.20 から 4.1.8 に上がった。自分は割と傍観していて他の人が主にバージョンアップしてたんだけど、いくつかはまりポイントがあって自分も Pull Request 送ったりしたのでやったことを書いときます。

1. session に注意

Rails 4 から Flash メッセージ（ログインしましたとか）を格納する session のオブジェクトが普通の Hash になってる。 Rails 3 ではこれは FlashHash とかいうやつ。

Rails 3 から Rails 4 へのアップグレードで一旦 Rails 4 を出してやっぱりやめて Rails 3 に戻したりとか、ロードバランサーに Rails 3 と Rails 4 で動くサーバーを混ぜてリクエスト捌いたりするとまずいことになる。

Rails 4 のサーバーで session 出来た人が次にリクエストしたときに Rails 3 に当たるとログイン後とかに session に残っているメッセージを消そうとする処理とかで NoMethodError が発生して落ちてしまう。しかもたちが悪いことに Rack 層で死んでしまったりするから皆さんよく使ってると思われる ExceptionNotification とかで気づくことが出来ない。これはつらい。

対処法としては Hash クラスをオープンしてモンキーパッチするというのがある。こういうの。

Rails 4 FlashHash Upgrade Gotcha

We upgraded an application from Rails 3 to Rails 4 this week and came across an interesting gotcha which I haven’t seen documented anywhere. As we rolled out the Rails 4 version of the app we split…

jasonneylon.wordpress.com

↑のだと #alert とか #notice が呼ばれたときにエラーになるので自分は以下のようにした。

# NOTE Rails 4 と Rails 3 を混ぜて使うと Hash#sweep が見つからなくてエラーに
# なるようなのでモンキーパッチします。
# 参照: http://jasonneylon.wordpress.com/2014/08/27/rails-4-flashhash-upgrade-gotcha/

class Hash
  def now
    Rails.logger.warn "Stubbing now during upgrade"
    {}
  end

  def keep
    # stub keep for upgrade purposes
    Rails.logger.warn "Stubbing keep during upgrade"
  end

  def sweep
    # stub sweep for upgrade purposes
    Rails.logger.warn "Stubbing sweep during upgrade"
  end

  def alert
    Rails.logger.warn "Stubbing alert during upgrade"
    self[:alert]
  end

  def notice
    Rails.logger.warn "Stubbing notice during upgrade"
    self[:notice]
  end
end

ただこれもパーフェクトではなくて、何もしないように上書きしているだけなのでログイン後のメッセージとか削除後のメッセージが消せなくなったりする。それでも 500 エラーになるよりかはましなのでどうしても Rails 3 と Rails 4 を混ぜて投入したいみたいときなんかは有効。

2. 絵文字に注意

Rails 3 の頃は ActiveRecord が絵文字を DB に保存することが基本的になかった。ユーザーが POST してきたフォームの中に絵文字が含まれてたら絵文字のところでテキストをぶった切って DB に保存するような挙動だった。しかし Rails 4 からは ActiveRecord は絵文字を素通りさせるようになってしまったので困ったことになる。

絵文字を DB に保存するためには、 MySQL の場合は DB のテキストエンコーディングを utf8mb4 というやつにしてないといけない。ただの utf8 だと保存時に Mysql2::Error: Incorrect string value というエラーが出て DB に保存できない。emojimmy のような gem を使えば utf8mb4 でない DB でも使えるけど、 stores_emoji_characters :column_name を忘れずにモデルに定義しないといけない。たとえば購入時に購入した製品のスナップショットを注文テーブルに取るような DB 設計だと、製品テーブルのカラムは stores_emoji_characters してたとしても注文テーブルのカラムを stores_emoji_characters し忘れていて死亡、というような悲劇が起こり得る。

いまはスマートフォンの時代で、ユーザーが入力してくるフィールドには必ず絵文字が含まれると思っておいた方がいい。スマートフォンをメインで使ってる人たちは開発者が想定しないようなフィールド（名前の敬称とか）に平気で絵文字を使ってくる。下手すりゃ住所や名前にも絵文字を入れて送ってくるかも知れない。アスキー文字しか受け付けないようなフィールドは JavaScript やサーバーサイドでバリデーション行ってると思うけど、マルチバイト文字列を受け付けるフィールドの場合はせいぜい長さくらいしかチェックしてないと思う。チェックを入れて絵文字を弾くことも可能だけど、スマートフォンの時代の流れに反しているしユーザーを失うことになりそう。これから新規でサービスを作ってデータベースに MySQL を使う場合はエンコーディングは utf8mb4 にしておいた方がいい。

他にも script/rails が bin/rails に変わってること忘れてて rails runner なバッチ処理が動いてなかったとか、 paranoia.gem の Rails 4 対応バージョンで物理削除のときに呼び出すメソッド名が変わっててはまったとかいろいろあったけど大きなところは上の session と絵文字だった。開発環境で使ってるときには気がつかず本番に出すまで気がつきにくいという意味で非常にやっかいな現象だと思う。

これから Rails 4 に上げる皆さんは頑張ってください。応援しています。

Rails の E2E テスト、ずっと Capybara + Poltergeist （PhantomJS）でやろうとしてたけど結局うまくいかなかった。

つらいポイントいろいろあって、 SSL 通信が必要なアクションでリダイレクトが発生してうまく動かないとか、 RSpec の use_transactional_fixtures オプションが利用できなくなるため Database Cleaner とか使う必要あったりとか、Parallel Test するときだけ通らないテストケースあったりとか、高速なマシンを使うときだけ落ちる、 Jenkins でだけ落ちる、といった問題が出てきたりする。

この手の問題、 sleep を入れたりとか mutex 化したりとか場当たり的な対応でテスト通すようにできることはできるけど、 unit テストのようにずーっと通る状態を維持し続けることが難しい（上に書いたように特定の端末でだけ落ちたりする）。おまけに何をやっても RackTest を使う場合に比べてテストが遅くなる。 Pull Request ビルダーでテストが実行し終わるまでに 15 分とかかかったりする。良くない。

かといって JavaScript のテスト書かない訳にはいかない。 JavaScript いっぱい使っててテストがないのはやっぱり不安が大きい。結局、JavaScript のコードを DOM べったりな状態から切り離して、サーバーサイドの Rails アプリケーションの挙動は request spec なり controller spec なりでテストして、 JavaScript のテストは JavaScript で行うのが良いような気がした。どうしてもエンドツーエンドテストやりたかったら Selenium 使うしかない気がする。これはスピードはあきらめて、 Pull Request ビルダーとかでビルドするときはテストやらずに、 master ブランチの定期ビルドとかでぶっ壊れてないか試す、みたいな方法が良いと思う。

もうこれ以上、エクセルにスクリーンショット貼り続ける訳にはいかないんだ。

Rails のログファイルを tail -f で見たいんだけど余計なものはフィルタリングして表示されないようにしたかった。最初は以下のようにしてみた。

⚡ tail -f log/development.log | grep -v -e ‘asset|Cache|Rendered’

これだと条件にマッチする行は表示されなくなるけど改行が削除されずに空行がたくさん表示される。これでは見やすいとは言えない。以下のように sed で空行を削除するようにしてみた。

⚡ tail -f log/development.log | grep -v -e ‘asset|Cache|Rendered’ | sed -e ‘/^$/d’

しかしこうすると必要な情報まで表示されなくなってしまう。 tail ではなく cat とかでやると望んだ通りになる。 tail -> grep -> sed の流れだとうまくいかないぽかった。

“tail grep sed” でググったら以下のような記事を発見したので試しに grep に —line-buffered オプションを渡してみた。

grep, awk, sed でバッファしない方法 | TECHSCORE BLOG

こんにちは、TechscoreBlogのログ閲覧が日課になっている河野です。ログをtailでリアルタイムに見ているときに、grep, awk, sedと組み合わせることがあります。ところが、特にオプシ...

www.techscore.com

⚡ tail -f log/development.log | grep -v -e 'asset|Cache|Rendered' --line-buffered | sed -e '/^$/d'

これで望んだ通りの出力になった。便利。