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

What is nil? No matter. What is nil? Never mind.

"What is nil?" is mysterious question in Ruby. You may answer like "nothing", "nothing exists", or "NULL". Brian, the founder of Rubinius, wrote his thoughts around Lonely operator.

CRuby developers sometimes discussed about nil for example [ruby-dev:29374] nil.to_s. The thread is talked about the behavior of nil.to_s.

The use case of &.

Ruby solves real problem. Ruby's complexity is come from the complexity of the real world. When Ruby adds a new feature, it should be designed for real use case. For example Lonely operator (and the ancestor Object#try! of ActionSupport) are designed for below:

<% if current_user && current_user.premium? %>
  Hi,<%= current_user.name %>, we offer a new campaign!
<% end %>

Rails programmers often write a template like this. In this case, current_user is nil when the user is not login yet; it's actually valid status.

Some people try to define NilClass#method_missing like Brian says. "The Hopelessly Egocentric Blog Post" is a good article about the idea. I summarize the article: don't try it. Rails developed Object#try/try! from the experience. Ruby agreed the conclusion and added &..

The use case of dig

The use case of Hash#dig and Array#dig is JSON from REST API. For example following Redmine's REST API (full result),

{
    "issue": {
        "id": 11537,
...
        "assigned_to": {
            "id": 13,
            "name": "Yukihiro Matsumoto"
        },
        "subject": "Introduce \"Safe navigation operator\"",
        "done_ratio": 100,
        "created_on": "2015-09-18T09:29:09Z",
        "updated_on": "2015-12-05T07:58:25Z",
        "closed_on": "2015-12-05T07:58:25Z"
    }
}

You can get matz by json.dig('issue', 'assigned_to', 'name') without suffering issue doesn't exist or it is not assigned anyone.

Traceable nils

I don't have a use case for this because I don't have an experience suffered to explore where a nil come from. When I hit "NoMethodError: undefined method `...' for nil:NilClass", it usually come from models. It doesn't need to trace. Or if people hit a trouble the issue is how the nil come from, not where the nil is born, I imagine. Anyway such experiment is interesting. I watch the reaction by developers.

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世紀の正常な判断能力を持った人間A pragmatic programmerならば、ユートピアを探し求めることは諦めて、OS Xこそが現実的なデスクトップUNIX環境だと認め、林檎の木の下で日々を暮らし、1日17回だったり2週間に1度、現実的なサーバー用UnixであるLinuxサーバーにdeployして生活の糧を得るものだ。

 しかし、やはり人はユートピアを求めてしまうものだし、正常な判断能力を失ってしまったプログラマプログラマにはよりにもよってWindows上にそれを求めてしまう頭の不自由な人interixやcygwinで懲りない人もいる。この記事はそうした人に向けた、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すら入っていない上に、聞きかじったpacmangccを入れようとすると無数に現れる候補に途方に暮れてウィンドウをそっと閉じると思うのですが、Git for Windows SDKならばそんなことはありません!リンク先からexeを拾ってきていつものようにNextを連打すれば、必要なものはだいたいあらかじめインストールしてくれます。とはいえ、Rubyのビルドに必要なものが全て入っているわけでは無いので、pacman -S autoconf bison rubyしましょう。

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のユースケースを得たかった

あと、AmazonGoogleMicrosoftと戦って、その戦う武器がOSSってのがよいですね。OSS派の旗を降ろせる条件がめちゃくちゃ厳しいのがよいです。

ちなみに今心配なことは、みんなも気にするであろう英語・アメリカ関連なんですが、まぁ長期的な日本の経済状況を考えるとリスクヘッジのための投資ですかねぇ。

  • 英語(TDは、創業者は日本人だけど外資なのだ)
    • 読み書きはどうとでもなるけど、会話きびしい
    • なお、東京社内は日本語会話でした
  • シリコンバレー研修(シリコンバレー企業にはしばしばある)

なお、わたくしのミッションは入社エントリ書き…は終わったので、次はfluend for Windowsらしいです。わたしが新しいことやるとヤクの毛刈りでものすごい時間かかるんだよなー。

というわけで、ヤクの毛刈り等で相談するであろう皆様、その他この記事をご覧いただいた皆様今後ともよろしくお願いします。

Visual C++ 14 と Ruby その2

Ruby

というわけで、Rubyに普通にマージして良さそうな修正は既に入れてしまいつつ、workaroundをPull Request #884 として載せておきました。なんか妙にstack over flowしますが、おおむねtest-allも動きます。
また、Microsoft Connectにfeedbackも書きました。(なお、ここで言及されている事情についてはusaさんの日記が詳しい)
さて、どうなることやら。