therubyracer considered harmful
要約
therubyracerはやめてexecjsからnodeコマンド使え。
解説
Rails 3.1 で Asset Pipeline が導入されて以来、Gemfileにgem 'therubyracer'と書く人も増えたのではないでしょうか。しかし、それがどの程度のリスクを背負っているのか自覚のない人も多いように感じます。
平時はChrome由来のJavaScriptエンジンであるv8を手軽にインストールできてスーパー便利なtherubyracer.gem & libv8.gemですが、その潜在的なリスクには震えるものがあります。最初にこれが世を騒がせたのは3年前のクリスマス前のことだったでしょうか。
v8
この問題の背景には、本質的に「v8のビルドは難しい」という点があります。雑にバージョンを選ぶとビルドが通りません。そもそもがChromeのためのものだからなんでしょうか。リリースする前に個別にパッチ当ててるんですかね。
libv8.gem
上記のような邪悪を封じ込めたのがlibv8.gemです。libv8.gemがインストールされていれば、楽に利用することが出来ます。バイナリのlibv8.gemが既にあれば楽ですが、時々ありません。例えば、2016年1月8日現在、El Capitan用のバイナリgemはありません。
自分でgemを作る場合は自分でv8もビルドするか、–with-system-v8でbrewなどから入れたv8を使うかを選ぶ必要があります。前者は言うまでもなく大変なのですが（2016年1月8日現在、正常にビルドが通りましたが3分かかりました）、後者もv8とlibv8のバージョン依存問題に加え、一度libv8.gemを作ったあとでうっかりbrew updateするとバイナリgemが壊れることがあります。
therubyracer.gem
therubyracerはlibv8への激しいバージョン依存があります。昔はプラットフォームによって正常にビルドできるlibv8のバージョンが違うのにtherubyracerがそれぞれ別のバージョンになっていてGemfileどう書けばいいんだ…とか泣いてた記憶があるんですが、さすがに今はそういうことはないのかな。
まとめ
以上の通り大変なので、この問題につっこんでいくことは特段の必要性が無い限り避けるべきです。（特段の必要性というのは、たとえば細かいJavaScriptコードを何度も繰り返し実行する必要がある、とかです）RailsのAsset Pipeラインの場合、execjsを用いてnodeコマンドを叩くことが出来ます。nodeコマンドならどのプラットフォームかによらず、いつでも簡単に新しいものを入れられるので安心安全です。無駄な仕事を減らして高い生産性を保ちましょう。
RubyとGit for Windows
序
人は誰しも理想郷を求めるものだし求めてしまうものだろう。「最強のUnix環境」、これもまたそうしたユートピアの一つである。
21世紀の正常な判断能力を持った人間ならば、ユートピアを探し求めることは諦めて、OS Xこそが現実的なデスクトップUNIX環境だと認め、林檎の木の下で日々を暮らし、1日17回だったり2週間に1度、現実的なサーバー用UnixであるLinuxサーバーにdeployして生活の糧を得るものだ。
しかし、やはり人はユートピアを求めてしまうものだし、正常な判断能力を失ってしまったプログラマにはよりにもよってWindows上にそれを求めてしまう頭の不自由な人もいる。この記事はそうした人に向けた、2015年末での状況を述べたものです。
さて、アベノミクス以来の円安もあり、2015年に大きく生活環境が変わった人も多いと思いますが、Windows上でのUnix環境にとっても2015年は大きな変化のあった年でした。OpenSSH for Windowsは話題性の割に正直どうでもいいのですが、Git for Windowsは福音と言っていいでしょう。
そもそも昨年くらいからMinGW64の安定、MSYS2の登場とパッケージマネージャpacmanの移植など、Unix on Windows業界は活気づいてはいました。しかし一方で勃興期にありがちな「結局どれとどれを入れてどう設定すれば正解なのかわからん」という問題を抱えていました。
Git for Windows SDK
さて、Git for Windowsの何が福音かって、彼らはgitのビルド環境をきちんと整備してGit for Windows SDKとして別リポジトリで公開しているところなのです。
意気揚々とMSYS2単体を入れた人は誰しもその3秒後gccすら入っていない上に、聞きかじったpacmanでgccを入れようとすると無数に現れる候補に途方に暮れてウィンドウをそっと閉じると思うのですが、Git for Windows SDKならばそんなことはありません！リンク先からexeを拾ってきていつものようにNextを連打すれば、必要なものはだいたいあらかじめインストールしてくれます。とはいえ、Rubyのビルドに必要なものが全て入っているわけでは無いので、pacman -S autoconf bison rubyしましょう。
追記
OpenSSLのライブラリはどこから入れるんだというご質問を頂きました。それは Git for Windows SDK ではなく、LibreSSLのDLLを取ってくるのが現代では一番簡単です。詳しくは RubyをWindows上でVisual C++でビルドする をご覧ください。
ruby
Rubyのビルドは特にトラブル無く通るはずです。MSYSに慣れていない人はインストール先の指定がMSYSでのパスではなく、Windows側のパスであることに注意しましょう。
調子に乗ってtest-allを走らせるとそうそうにこけますが、これは読者の宿題としておきます。Enjoy debugging Ruby and MinGW!!!
Ruby 2.3.0 released
Ruby 2.3.0 Releasedでした。皆さんお疲れ様でした。
リリーススケジュールとしては今回は例年になくぐだぐだで、リリース直前までブランチを切らなかったのも1.9系の仕様が安定した1.9.1以降では異例のことです。もっとも、これはCIが整備されたことで形式的なブランチ作成による隔離無しのリリースエンジニアリングが可能になったのだと肯定的に評価していきたい。
preview1が出てから盛り上がるという人の性の理解が足りていなかったのは反省点で、来年は夏くらいには出したいですね。（今回、夏頃にはまだ目玉機能が入っていなかったという事情もあるのだが）
来年は、mingwのCIや、CIをコミットごとに走らせる仕組みが欲しいです。
Ruby会議2015
Ruby会議2015 1日目
朝
家で Ruby 2.3.0-preview2 のsvnタグを打ってから優雅に会場に到着し、オープニングでリリースを行う予定だったのだが、雨で時間ロスしつつ会場へのラストワンマイルで迷ったため、焦ってしまっていまいちいい感じにならなかったのが残念だった。 そもそもこの手の公開なんちゃらの類では出演者は観察されるアリになりきって何が起ころうともありのままをみせることが正義だという認識が足りなかったのがよくなかったので、今度はリリースに際して何をしているかへろへろと見せるのが正しいのだろうと思いました。
Matz
2020年までにRuby3というのがびっくり。まぁ、バージョニングはCRubyにいくつかあるMatzの専権事項の一つではある。しかし、個人的にRuby3は高速化だけじゃなく、型とMVMも入っていて欲しいなぁ。
haml
闘争本能に身を任せてコードを書くってとてもいいことだと思うんですよ。 そういう純粋な心をずっと持ち続けて欲しいと思いました。
JIT
Rubyの実行系を改善しようという試みはこれまで何度か行われてきた。
TRICK
いい感じのネタが思いつかなかったので観客でした。正規表現でSAT解く
夜
ESM Drinkup に入れなかったよぅと泣いていたら、しばたさんがうなぎに連れて行ってくれたので、中止のはずだったUnagiAwardが唐突に開催されました。 厳正なる議論の結果、今回は r50412 dln.c: check incompatible libruby を実装したなかださんに決まりました。おめでとうございます！ なお、本人は件のESM Drinkupで呑んでいたので欠席でした。
Ruby会議2015 2日目
kosaki
世界のこさきさんによる、Linux上でのデバッグ記法紹介でした。 最近ついにLinuxはprofilingやtraceの機能が豊富なことに気付いてしまったので、高速化するときはLinuxを使うことにします……。
/\Atest.*unit\z/
知られざるRubyのテストを巡る長い戦いについての話。100% compatibilityとかひどいはなしでしたね……。 さておき、紹介されていたRuby自信のためのテストライブラリtest/lib/ですが、envutil.rbとかはコアをテストするためには何が必要なのかの知見が詰まっているので、なんかそういうのを作る人(誰?)にはとても良いと思います。
fake.rb
なんか2.3だとビルド中にfake.rbを生成する際にerb.rbを読めなくてこけるという問題があってhsbtさんが追いかけていたのだが、原因も再現条件もわからなくて困っていたのです。なので、再現する環境を求めていたのですが、ついにRubyKaigiで再現できたという方を見つけたのでそらさんと調べていました。そらさんがrbenvの問題だという所まで突き止めたので見てみたら、なんかクロスコンパイルのため?にWindowsでしか作っていなかったfake.rbを2.3からUnixでも作るようになったのが原因で、rbenvの最近のバグを踏んだのだとわかったのでPRなげた Remove leading `:` by eagletmt · Pull Request #836 · rbenv/rbenv · GitHub
つづきはいつかかくかもしれない・・・
Treasure Data に入社しました
今日から Treasure Data で働くことになりました。
前職が一段落して（退職エントリ）転職を考えた時に、ちょうどtagomorisさんが何社も回った末にTreasure Dataに決めていたので、TDにしました。
…
もちろん物事を決めるときに理由はいくつもあるわけでして、
- OSS開発者として暮らしやすそう
- Twitterを勤務時間中にできるとかそのほかもろもろ
- 知り合いの有無
- 何を目指しているかわかりやすい
- 目指しているところが不明瞭だと迷走しやすい気がする
- これからの成長の余地が大きそう
- Ruby開発に際してビッグユーザーであるTreasure Dataのユースケースを得たかった
あと、AmazonやGoogle、Microsoftと戦って、その戦う武器がOSSってのがよいですね。OSS派の旗を降ろせる条件がめちゃくちゃ厳しいのがよいです。
ちなみに今心配なことは、みんなも気にするであろう英語・アメリカ関連なんですが、まぁ長期的な日本の経済状況を考えるとリスクヘッジのための投資ですかねぇ。
- 英語（TDは、創業者は日本人だけど外資なのだ）
- 読み書きはどうとでもなるけど、会話きびしい
- なお、東京社内は日本語会話でした
- シリコンバレー研修（シリコンバレー企業にはしばしばある）
- tagomorisさんの記事でだいぶ心配が減りましたが、アメリカから日本のネトゲやるとどのくらい遅延が出るか心配です
なお、わたくしのミッションは入社エントリ書き…は終わったので、次はfluend for Windowsらしいです。わたしが新しいことやるとヤクの毛刈りでものすごい時間かかるんだよなー。
というわけで、ヤクの毛刈り等で相談するであろう皆様、その他この記事をご覧いただいた皆様今後ともよろしくお願いします。
Visual C++ 14 と Ruby その1
Microsoft Visual Studio 2015 CTP6がでましたね。VS14ではVisual C++ Runtimeに大きく変更が入るそうで、とてもイヤな予感がしますから、ちょっと様子を見てみましょう。
Azure使いの人はMicrosoft Azure virtual machine galleryにあるVisual Studio Ultimate 2015 Preview on Windows Server 2012 R2を使うと手間が省けます。そうでない人は頑張ってインストールしましょう。インストールの際はGitを一緒に入れておくとbison.exeやsed.exeが一緒についてくるので楽です。
インストールが終わったら早速VS2015 x64 Native Tools Command Promptを起動してとりあえずcl.exeを叩いてみるわけですが、なんと起動しません (上記Azureでの場合)。cl.exeはVisual C++ 2015 再配布可能パッケージに依存しているのに、なんと愚かなことに普通はこれがインストールされないんですね。C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\1033\vcredist_x64.exe にあるので、インストールしましょう。 (注: RCでは直りました)
気を取り直してrubyのソースコードを取ってきて、win32\configure.batを実行です、失敗します。これはランタイム名とバージョンを検出するツールwin32\rtname.cmdが見事に上記の変更を踏んだからですね。前向きに直して次に進みます、失敗します。よく見るとverconf.mkの \ の後に余計なスペースが入っています。これはnmake14をいじって壊したようです。困りますね。
まじめに対応するのもばかばかしいので、C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\nmake.exeを適当においてお茶を濁しましょう。 (注: RCでは直りました)
つづく
