卜部昌平のあまりreblogしないtumblr

俺はLindaたちがなにをあそこまで思いつめてRailsGirlsを始めたか完璧には理解していない(し、そもそも「完璧な理解」って存在するのか?)が、ひとつ理解しているのは、RailsGirlsはべつにRailsやりたい女子じゃないという点だ。Railsはたまたまそのへんに転がってたからチョイスしただけ。本当のゴールは女性へのツールとコミュニティの提供を通じて、在野の女性のアイディアを実現する事にある。不勉強で日本の事情はよく知らんけど、本家はそういうことになってる。だから本当にRailsGrilsのRailsってのはウィキリークスのWikiくらいどーでもいいんですよ。今後たとえばRailsいけてなくねってことになったらRails捨ててexpress.jsなりに移っても、RailsGirlsのミッションはいささかも揺るがない。

RailsGirlsってのはアファーマティブアクションですよ。たとえば性別逆転して「男性優先、女性は男性同伴のみの場合のみ可であるRailsBoys」とか考えてごらんなさい。だいぶ醜悪な事態じゃないですか。ということはつまり、そこにジェンダーによる構造的なギャップがある。だからこそ解消しようとするのは重要で、そのための具体的なアクションというのはあるよねってこと。ともかくもRailsGirlsが成立してる背景には女性が性別により不利益を被る構造というものがある。なきゃただの男性差別ですよ。俺はRailsGirlsに(単独では)参加資格ないけど、それはわざわざRailsGirlsに参加するまでもなくすでに俺が十分に社会から恩恵を受けているからで、だから俺なんかよりもっとRailsGirlsに参加すべき人が参加すべきという理論で、これはまったく正しい。

大変残念ながらそのへんがJS Girlsでは後退してるように見えるんだよな。

わりと色々調べてみたけど結局JS Girlsがなにをどうしたいのかが分からんわけです。どうやら男性は困ると言われていることは分かるんだけどね。じゃあ女性があつまって何したいの? キラキラしたいだけなの? というのが見えてこない。たんに盛り上がればいいの? それおらが村にも嫁さ来てくんねえかなとどうちがうんだ?

勘違いしてほしくないのはべつにだからJS Girlsやめろとかじゃないですよ。大いにやればいいとおもう。ただちょっと今のままだと「たんに男性を排除してる」ようにしか見えないぞと。きっとダイバーシティって排除とは真逆の方向だと思うんで。もっとちゃんと広報すべきなんじゃないですか。外野からは観測できないところではそういう議論あるかもしれないけどさ。今後どういうふうにしていきたいのかっての、ちゃんと公表しといてくれたほうがいらぬ誤解を生まなくて済むよ。

http://www.homes.co.jp/cont/rent/rent_00002/

そろそろ本棚追加しないとなー、でもそのためにはまず家がなー、とか思って賃貸物件見てたらこのページに突き当たって怒髪天を突く勢いでもはや本棚どころじゃねえ。年収400万が最低ラインってどうなんだよ。それ以下は相手にもされないってのか。

http://doda.jp/guide/heikin/2012/age/ このへんでも見やがれ。これは「額面」年収だ。だから額面400万ってのは手取りでもっと少ねえんだよ。32でも中央値額面400万とかで半数が400万行ってねえぞコラ。20代の過半数は客ですらねえってのかコラ。どうなんだよ。

最初にめどい言い訳をせねばならぬ

俺は江島氏ともきょん氏とも面識はないですが、お二人ともが俺のことを知ってることを俺も知ってる程度には狭い業界であり。どちらかに肩入れしたいわけではないです。喧嘩したいわけでもないです。

普段あまりここでは言及しないですが俺は今の仕事としてはテストを書いたりテストを実施したりする係をしてノリクチをしのいでおり、いわばテストは本業ですので、テストに言及することは今現在の同僚に対して意図しない受け取られ方をする可能性があるので困るので、それもあって普段はここではあまりテストの話はしないわけだが、だからと言って沈黙を破ってテストの話をするのが同僚に対して含みがあるというわけでもないです。

とはいえ俺は大学等で真面目にソフトウエア工学の講義を受講したことがなく、経験と勘と昔取った杵柄だけで食ってるので、そういう意味では若干の後ろめたい気持ちもある。

で、テストって何なん

俺が現職に転職してきて一番びっくりしたのはなんといっても、俺は会社に一円たりとも入れてないのに会社からは俺の口座に何十万も給料が振り込まれてくるっていう驚愕の事実なわけですよ。なんじゃこりゃと。それまで前職では受託開発でしたからね。受託開発ってのは、人月単価だから、俺が働くことによってある程度毎月会社が儲かって、それが俺の給料の原資になるわけです(そこには入金まで数ヶ月のディレイがあるがまあそれはテクニカルな話で本質的ではない)。だから、俺の給料がなぜ払われてたかっていうと、それは俺と直接連動してお金が動いてたからや。明確ですね。でもテストはそうじゃない。俺がどんなに頑張って休日返上で働いても会社としては一銭も儲からない。じゃあなぜ俺の口座には給料が途切れることなく振り込まれているのか?

俺は嫌でも、テストの意味と価値に関して深く静かに思いを馳せずにはいられない立場になってしまったわけです。

テストで腹は膨れない

まあつまり、テストやったから儲かるとかないわけですよ。だから、きょん氏が「テストやらない理由がどこにあるか分からない」とか書いてて、正直はあ?って思う。そんなもん食えないからに決まってるでしょ。俺は社内で常にテスト書こうよって言いつづけてて、テスト書く理由を説いてるのに、テスト書かない理由がないってのは、だいぶ別世界に思えました。またこの部分は俺ときょん氏ですら見解の相違があるのに、起業家である江島氏とおれら従業員の断絶は多分相当あるだろうと思います。

で、じゃあ、テスト全然やんないですかっていうと、それはそれで違いますよね。テストエンジニアこのあたりを攻めるべき。なぜテスト書くのかと。

我々が必要としているのは止まらないソフトウエアじゃない。止まらない業務だ。

テストって、ものすごく巨視的な見方をすると投資なわけですよ。

テストをすることであらかじめバグを見つけておく。運用中にバグを発見した場合の機会損失と運用コストをあらかじめ避けることができる。

だいたいここに収斂してくるイメージがある。だから、ぶっちゃけバグがあろうがなかろうが儲かってないプロダクトをテストしてもあんま意味ないっす。前提としてprofitableなプロダクトがあり、それの運用コストを圧縮したいねってときにテストは有効。

あとweb屋の場合はバグが出ちゃっても機会損失がまださほどでない瞬間にとっとと直すって戦略はありうるわけですよ。その点はリコールで会社が傾くような自動車の制御ソフトとかとは大いに違う。だからテストする費用対効果ってのはweb屋に限って言えば、だいぶシビアというのはその通りでしょう。

まあ上にも書いたとおり俺はソフトウエア工学の専門教育を受けてないのでこの項目はめっちゃ外してる可能性も結構あるのだが。

回帰テストを書け

運用コストの圧縮という面でいちばん重要なのは回帰テストです。一回テスト書けば毎回有効ってことにすればコスト圧縮は積分で効いてくる。だから本来は回帰テストを書きましょうねってのが一番重要で、たぶんそこはボトムラインとしてみんなやったほうがいい。あとになるほどスルメみたいに効いてくるからね。

だがこれが意外にねえ。ホワイトボックステストをやってると内部構造べったりに書いちゃってねえ。とくにC1カバレッジとか見だしちゃうととたんにねえ。「この分岐をこっちに通るようなテスト書かなきゃ」とかなっちゃうんだ。でもそれは本末転倒なのですよ。何と戦ってるのかわかんなくなっちゃう。これは俺もよくやってしまう失敗で、ひじょうに自戒的なのだけれど。

そういうテスト、ばかだなって言うのは簡単だけど、そもそも完璧な人はテスト書かなくてもそもそもバグ出さないって話もある。だからテスト書くってのはばかをおのずと内包してるので、それに向かってばかって言っても虚しさしか残らんという点は指摘しておくべきかなと思います。

テスターは最初のユーザー

テストしてると「あれこのプロダクト、クソじゃね?」っていう瞬間はやっぱありますよ。はばかられるので具体例はあげないけどさ。そういうのって本当に重要で、ようするに品質って何かって話。テストやってるとよく品質保証とか言うけどさ、それで実際やってるのって仕様と実装の乖離を見てるだけってのがほとんどじゃん。悲しいことに。でもさあ、もとの仕様がクソってるのってやっぱあるですよ。そういうときクソ仕様と乖離のないクソ実装が仕上がってQA終わり!っての、違うと俺は思う。

これようするにフィードバックの話ですけど、テストする段階まで来ちゃってるときに、これやっぱクソだわーっての声に出して言えるかどうかって大きいと思うんですよ。テスターはそのプロダクトを使う最初の人でもあるわけで。UXのおかしさとかに気付ける最初の人でもあるわけじゃないですか。そういうのきちんと拾っていければ、ただの防衛的なコスト圧縮だけじゃないテストによる価値の創出っての、ありうるんじゃないかと思います。ただのバグならエラー検知で発見できるかもしれないけど、リターンレートの低さの理由とか、そういうのですよ。離脱しちゃったユーザーに聞きようがないじゃん。

三行で

卜部って口だけ野郎でどうせたいしたもん書けないんでしょ? [1] [2]

→ 見せてやんよゴラァ

→ ごらんの有様

教訓: 陰口は本人に聞こえない所で。さすがに名指しはまずい。

どういうパッチか

Rubyのオブジェクトサイズを変更(大きく)する。そのことにより第一義的にはCPUキャッシュミスヒットが削減される。副次的作用として大きくなった余剰の領域にデータを詰め込めるので中間構造体を減らしてメモリアロケーションが最適化される。それらの総合的な結果として全体に高速化する。

前史

とはいえこのアイディア、べつに最近涌いて出たものでもない。というか、俺がまだ大学院でNetBurstと戯れてたころの発想だから、かれこれ7～8年物だな。しかもこの間べつに秘密にしてたわけでもなくて、Rubyのオブジェクトって素数幅でいくなくね?ってのは、わりと口頭では折に触れて言ってたので、聞いたことがある人もいるはずかと。あ、じゃあそんなに長期にわたってなんで放置してたの、というと、1.8やってたからです。ええ。

でもね、実はこれ7～8年前だとまだ明確な理由があってNGだった。というのも当時はまだオブジェクトってスカスカで、いろんなところに隙間があいてたの。とくにFloatはひどくて

struct RFloat { struct RBasic basic; double float_value; };

こうですからね。後ろ側が全然使われてない。これを、今回提案のように8word幅にすると、double(64bit)一個保持するのに64バイト確保することになってしまって、本来のデータの8倍ですよ。これはさすがに無駄いと言わざるを得ない。

この問題はささださんがflonumを導入したことにより解決のめどがついた。また当時問題視されていたBignum等も、後ろの余ってる所にデータが詰め込めるなら詰め込むっていうのが、主に田中さんにより実装されていて、今ではRubyのオブジェクトは、例外もある(Fileなど)が、意外に後ろの方までつまっている。このため、オブジェクトを大きくすることはそれらのつめる系のやつにとってもプラスになるはずという目論見があった。

実装

コアのコンセプトはそれこそ128秒で書けた。ちゅうてもまあ、7～8年と128秒ってのが実状だけどな。でもこれでハッピーかと思うと、そでもない。なんでかちゅうとですね、俺のしらん間にRGenGCとか入ってて、なんも考えずにオブジェクトいじるとぶっ壊れるんすよ。しかもRGenGCって世代別だから、壊れ方として、ライトバリア足りてない→markおもらし→生きてるオブジェクトが回収されちゃう系の壊れ方で。これはいかんかった箇所と死ぬ箇所が全然別になって超辛い。しかも俺のしらん間に入ったがゆえにRGenGCとか俺がよくわからん。しかもドキュメントない。というのをまずソース読むという作業が必要でやばかった。

プルリク読むと迷いもなくいっぱつがきで書いてるように見えますけど送信までにめっちゃrebaseしまくってます

Hash

オブジェクトでかくなる副作用でポインタ何個ぶんも隙間できるからハッシュの中身展開してそこに突っ込もうぜっていう話。前述のつめる系のやつと同系なのだが、これまではオブジェクトのサイズが小さかったためあまり意味がないということで実施されてこなかった。これが実はベンチマークの面ではいちばん効いてる。ようするにRubyってハッシュのアロケーションでわりと時間食ってたと。これは実際やってみて分かったことなので自分でも驚いた。

その他の細かいネタ

Githubはrubyの2級市民であるにもかかわらず最初にgithubに投げたのは完全に意図的。RubyにおいてはML読んでる奴はたくさんいるが、コードまで読む奴はほとんどいない。が、にもかかわらず、ごく少数のコードまで読んでくれる人は絶対いる(今回で言えばEric Wongが読んでくれた)。MLでどうでもいいPR合戦をするのはそういう本当に大切にしたいメンバーとのやりとりにとって邪魔ゆえ、あえてPRはMLの外でやるという戦略だったわけ。これはうまくいったと思う。今のところMLは密度の濃い議論ができている。

Valgrindでヒーププロファイルとれるじゃんと思ったところまでは正しかったが取るだけ取ったものを出力する方法がないのは閉口した。スクリーンショットしかないというのはいかがなものか。

VAIO Pro 11買った。

周囲の少なくない割合のVAIO Xオーナーが雪崩をうって買いに走ってるのをみてそうなんだろうなーとは思ってたものの、まあ、Sonyですからね。半年くらいは様子見るのは当然ですよね。

使用感など

とりあえずわくわくしながら電源入れて、次に口をついて出た台詞が「死ねよ」だったことは特筆しておいても良いのではないかと思いました。いや、だって、本当に電源切る方法がまったく分からないんだもん。電源ボタン押すと電源入るでしょ? なのにそこからもう一回電源ボタン押しても切れないんだよ。あほかと。省電力だからって言ってウォシュレットが一回始めたら水止まんないとしたらどう思います? そういう基本的な、本当に基本的なことですよこれは。結局ぐぐって解決したけど、電源の切り方っていう紙っぺら一枚添付してくれてもいいんじゃないの? そういうのこそ「デザイン」なんじゃないのかね? まあSonyが悪いことなのかは分かりませんけど、ファーストインプレッションは最悪から数えた方が近いとおもいます。

あとね、MBAと比べてこんな微妙に幅が違うわけですけど、 わざわざこれだけ横幅削ってまでキーボードピッチを狭くした理由が一切理解できない。なんなの? マゾですか? 誰も喜んでないでしょこれ。もっと何センチも削れるならキーピッチ狭いのもやむなしだけど、これだけじゃあ意味ないよ。幅をMBAと同じまで広げて普通のフルピッチのキーボードを載せなさいよ。わざわざ使い辛くしてどうするの。

よかったさがし

液晶は綺麗ですね。これは毎回思う。他社は本当にもっときれいな発色のパネルを使うべきです。このパネルは最大輝度だと個人的にはちょっとまぶしすぎるのだけど、そこから輝度を落としていったときの黒とか白とかのへんがとても違和感なく暗くなっていくのは、とても気味が良いです。

予想に反してUbuntu 13.10一切何の抵抗もないままに最初のトライで入ってしまった。拍子抜けです。まあその後Ubuntu固有のクソiBus問題とか色々あるのでこれはこれでクソなのだが、それこそマシンと関係ない話で。

Haswellよいですね。速くなった感じは一切しないが消費電力はpowertop(1)で見てても明らかに低くて。逆に言うと低消費電力のわりには速さに不満を感じませんね。

個人的にはUSB3.0のUSBメモリで速いやつと遅いやつって、言うほど速さ変わんないなーって思ってたけど、マシン変えたらこのマシンでは結構速いって売ってたUSBメモリは速かったというのは印象深かったっす。

あとまあ、やっぱ軽いのは正義ですね。

これから買う人へ

このびっくりするほどぺらいキーボード(まあXもそうでしたよ)からも分かるとおり、Sonyという会社に頑丈さを求めてはいけません。ThinkPadやLetsNoteと同じ使い方をするとものすごい勢いで物理的にぶっ壊れることが容易に想像できますので、他の何をおいても一切漏れなく絶対買うべきなのは「延長保証」です。それも破損をカバーしてるやつです。金額的に、一年で捨てても構わないって人は少ないはずです。そこをけちらないように。

前回の続き。

前回の時点では「git blameが密になっているところはきっと活発に編集されていたに違いない」という仮説があったわけですが、これは本当のところは、よくわからない。なぜかというと、blameというのは地層のように降り積もったコミットの表面に露頭してるところしか見せてくれないわけです。本当に活発に更新されていたかを知るには、ようするに地質平面図じゃなくて地質断面図が必要なわけ。分かりますよね。

で、それはどうやって作ればいいかというと、gitには便利なgit log -pという、こういうとき便利だけど普段は使い道のなさそーなコマンドがあって、これは生のdiffをすべてだらだらと表示してくれるわけですよ。で、diffからblameを再構成するにはdiffの+行をひたすら集めてくればいいわけだけど、その時-行も一緒に覚えておいて、あるコミットでどのコミットが上書きされたかを覚えておくことができる。そのようにすると、blameっぽいけど地層の底の方を見通すことができるコマンドというものが作成できる。

たとえばこういう出力が得られます:

いかにも更新頻度の高そうな行がどのへんかがちゃんと可視化されているのが分かりますね。

で、これだけでも結構興味深くて、たとえばeval.cで結局どこが一番ホットな箇所だったかといえばすばりここということがわかって、これはとても納得感が高い。つまり、作ってる我々からしてみても「ここは大変だった」と思える箇所なわけで、けっこうな妥当性があるんじゃないかと思いますね。なのでこれはこれで便利に使えるツールに仕上がるのではないかという気がする。

ただまあ、やっぱ図にしてみたいですよね。前回同様に。で、やってみるとこうなる。明るいほど高頻度の編集です

これ、ぱっと見で画像が暗いと感じると思うのですが、ヒストグラムがひじょうに興味深くて、全体の50パーセンタイルが一回しか更新されてないのですよ。二回以下だと76パーセンタイル。まあこれだけで絵づらは決まったようなもんです。

なので実はrubyの実装においては実は、だいたい半分はいっぱつ書きで動いてるといえる。もちろん、コメントとかも含んでるから、実際はもう少し精査しないといけないだろうけれど、それでもかなり予想より多いですね。びっくりです。

ゼロ年代のやつはマヨネーズ色の本に書いてあるよ。

あ

IRC (あいあーるしー) 「教養チャンネル」とも「衒学チャンネル」とも呼ばれる。ほとんどのタイミングで日本史か中欧史か仏教史か英語史の話をしている。たまにRubyの話題になると逆に違和感が…

ISeq (あいせく) RubyVM::InstructionSequence のこと。長いので誰も正式名称で呼ぼうとしない。

rubyスクリプトのいくつかある表現型の中でもっとも低レベルな表現。現在、rubyスクリプトからISeqを生成する機能は公開されているが、そのようにして生成したISeqを実行する機能はセキュリティ上の懸念から(作られてはいるが)封印されている。→ AST

ID (あいでぃー) 型。rubyレベルでいうSymbolにほぼ相当するもの(ちょっとだけ違う)。objcプログラマーはこれを見てVALUEと混乱しないように。

assn (あさしん) IRCで彼らがアサシンと呼んでいるものは暗殺者のことではなくアソシエーションの略なので、びっくりしないこと。たまにジャーゴンであることを忘れてIRCの外でも使ってしまい、通じなくて恥をかく。

Qundef (あんでふ) Qは黙字。実装上はQtrue, Qfalse, Qnilと並ぶruby第4の即値定数だが、実装詳細として頑なに表舞台に出てくることを拒んでいるため、rubyスクリプトから見かけることは非常にまれであり、見かけたときにはほぼ間違いなくバグなので、バグ報告しよう。

Emacs (いーまくす) 過去のある時点においてrubyはEmacs Lispでどこまで変態な文法が処理できるかの挑戦として作られたという事実がある[1]。現在でもEmacs上では正しくシンタックスハイライトされるが他のエディターではされない、というケースはまま見受けられる(特にネストしたヒアドキュメントが鬼門)。rubyのへんな文法はたいていEmacsのせいと思ってよい。

1.8 (いってんはち) 輝かしい先駆者にして現在まで落とす影も大きい。なお現在のrubyに対する1.8に相当するポジションとして、1.8にはPerlという存在があった。

iter (いてれーたー) rubyが出たばかりのころこんな機能がある言語はかなりマイナーなものに限られていたが、今となってはC++ですらラムダリテラル構文がある。rubyのようなイテレーターというアイディアは十分に業界に浸透したといえるだろう。必ずしもrubyだけの功績ではないとは思うが、まったくrubyと無関係ってこともないはずだ。

Windows (ういんどうず) てか実のところWindows専用アプリでもないにも関わらずこれほど力を入れてWindows対応がなされているものって、なかなか見ないよ。本当に。頭が下がります。ただ、ユーザー定義したライブラリとかで対応が残念な事があって、そのため結局総体としては残念なことになってしまうって場合はまま見受けられるので、その点残念。

英語 (えいご) われらの共通語。

Encoding (えんこーでぃんぐ) 抽象概念「文字」の抽象的な「列」である「文字列」を具象としてビットパターンに落とし込むための符号化方式、にrubyが名前をつけたもの。rubyではそのような符号化を一意に定めず、文字列ごとにそれぞれ別の符号化であることを許容している。こういうのをCSIというそうだ。

なおASCIIという符号化方式との間にある種の互換性がないような符号化はrubyでは二級市民として差別されている。

configure.in (おーとこんふ) 「「「移植性を確認するプログラム(C)」を生成するプログラム(sh)」を生成するプログラム(M4)」という、少々常軌を逸した営み。あるいは穢れを一身に引き受けてプロジェクトの他の部分を清く保ってくれているとも言える。

Makefile.am (おーとめーく) rubyにはない。理由はautomakeが生成したMakefileがgmake依存だから。逆にいうと、rubyのMakefile.inは驚くべきことに、gmakeにもbmakeにもnmakeにも有効なとてもポータプルなものである。

PoLS (おどろきさいしょうげんそく) Principle of Least Surprise, 驚き最小の原則。一時期よく設計方針として言及されていたが、あまりに誰も彼もが安易に使ってしまったので現在は嫌われている。少なくとも「誰にとっての驚きか?」という部分の曖昧さが指摘されている。

objspace (おぶじぇくとすぺーす) → heap

か

拡張ライブラリー (かくちょう -) なんだかんだでrubyの設計者はCプログラマーだったということである。現在のrubyはCで拡張ライブラリーを書くことが容易になることを主眼として設計されている。主眼、である。Cさえ諦めればおよそありとあらゆる部分がより速く、あるいはよりシンプルに、再設計できる。しかしそうはなっていない。少々の速度よりも「Cで拡張ライブラリーを書くこと」のほうを優先しているからだ。

型 (かた) rubyでは変数には型がないが値に型がある。一方、Cでは変数に型があるが値には型がない。Javaでは変数にも型があるし値にも型がある(しかも一致するとは限らない)。このように言語によって型の性質が異なるため、一般的に言って型とは何か、というのは突き詰めると難しい問題を孕んでいる。rubyにおいては、値が型を持つ、というところまではだいたい合意が取れている。が、具体的にそれは何か? というのは議論が分かれる。メジャーな意見としては「それはクラスだ」というものと、「それはダックタイプだ」というものがある。

完全言語の探求 (かんぜんげんご - たんきゅう) 必読書。→ バベル17

企業 (きぎょう) コミッター数ではNaCl (matz shugo gotoyuzo nari takaokouji)が、コミット数ではHeroku (matz nobu ko1 ayumin)が、他より頭一つ抜き出ている。

Git (ぎっと) 正直、

信者うざい

Subversionで困ってない

Windows対応がひどい

といったところ。

基本ブロック (きほん -) 途中で分岐がないような一連のプログラム素片。途中で、というのは、最初と最後にあってもよいという意味であり、通常は基本ブロックといえば最初に他の基本ブロックからの条件分岐で入ってきて、一本道でいくつか処理をして、最後に条件分岐かreturnで他の基本ブロックへと抜けていくような構造である。大きなプログラムを複数の基本ブロックに分割してからそれら同士の関係を有向グラフとして処理するのがプログラミング言語処理の常套手段だ。

ところがrubyでは事情が異なる。例外があるからだ。つまり例外が起こるような任意の場所は基本ブロックの途中には出現できない。この制限は思いのほか強く、メソッド呼び出しなどほとんどの操作は例外を発生しうるので、rubyにおいては基本ブロックというのはたいてい単一の操作しか含まないようにしかできない。

クズポイント (くずぽいんと) コミッターに付くポイント。計算方法はバグ管理上、何件のバグがその人にアサインされているか。多い方がよい(その人の責任を表す)という意見と少ない方がよい(その人の几帳面さを表す)という意見がある。

Quine (くわいん) 自己複製プログラム、つまり自分自身を出力するプログラム。ある種のパズルとしてGolfなどと似た要素がある。が、rubyのQuineは短く書こうと思うとすごく短いやつでも書けてしまうのであんまり面白くない。どちらかというと字面の面白さなどを狙う方がよく見かける。

計算量 (けいさんりょう) Rubyistならずともプログラマーであればプログラムの書き方とかより先に最低限理解しておくべきもの。有り体に言えば「スケーラビリティー」をもうすこし学術的に厳密にしたような概念であり、厳密な部分をさておくとすれば(しないほうがよいが)、概論を追うのは本当に容易だ。にもかかわらず今年も多くのプログラマーが計算量を理解しないまま実践に投入されてゆく。嘆かわしい限りである。

言語 (げんご) 自然言語とか人工言語とかそういう分類を越えたところに言語の面白さはある、と思う。

コミッターに必要なもの (- ひつよう -) rubyコミッターなんて

神聖ローマ皇帝をシャルルマーニュからフランツII世まで順にそらんじることができなくてもなれるし

ヘイムスクリングラやベオウルフを読んだことがなくてもなれるし

EsperantoやfrançaisやKiswahiliやΚοινὴやLatinaやLogibanや文言文やसंस्कृतम्が読めなくてもなれるし

amd64やia64やmips64やppc64やsparc64のアセンブラーが読めなくてもなれるし

pthread_cond_timedwait(3posix)のRATIONALEを読んでなくてもなれるし

LALR(1)パーザーを手書きできなくてもなれるし

application/x-www-form-urlencodedを目で見てデコード後のエンコーディングを推定できなくてもなれるし

なんだ、簡単じゃん。

もう少し真面目に言うと、rubyコミッターになるには、そりゃ、持ってたほうがいいスキルはたくさんあるけど、最低限必要なのは、

rubyコミッターになる理由

これだけですよ。マジで。

Golf (ごるふ) コードゴルフとも。少ない打鍵数でプログラムを書くパズル。愛好家はゴルファーと呼ばれる。rubyにはゴルフ用ruby実装gorubyがついてくるように、ゴルフとの親和性は高めである。

さ

3PI (さーどぱーてぃーいしゅー) 3PIと書いてあっても3×πで9.5くらいか?と思うと全然関係なくて、3rd Party's Issue == だれか他の人が怪しいよ、ということ。あるいはライブラリーのユーザーからのバグ報告に対して、「まずライブラリー作者にライブラリーが悪いかどうかを切り分けてもらってください」といったニュアンスのもとに発効される場合もある。

サピア・ウォーフの仮説 (- かせつ) 人間はものを考える時に使ってる言語にひっぱられて考え自体が変わってしまうんだよ(大意)、という仮説。仮説というくらいだから何ら証明されたものではないが、SFの世界ではもはや真説を通り越して定説に近く、この説を採用する例はオーウェル「1984」を嚆矢として、ディレイニー「バベル17」、チャン「あなたの人生の物語」、伊藤「虐殺器官」など枚挙にいとまがない。

もちろんrubyに関係する人物はもれなくこの仮説を篤く信奉している。

GC (じーしー) Garbage Collection. まあ今時あるのが普通。rubyのものは非compaction非copying非exact非generational非parallel型と分類できるGCで、この非○○という部分を回避できれば勇者。ただし現在のアルゴリズムはそれなりの経緯でこのチョイスになっているわけで、そう簡単に変えられるわけではない。

.gdbinit (じーでぃーびーいにっと) rubyのソースコードに付いてくる。使うとrubyのデバッグがしやすくなる。

GVL (じーぶいえる) GILとも。Global VM Lock。嫌われもの。だがパフォーマンスを犠牲にしつつもみんなを[BUG]から守ってくれてるんだぞ。もっと感謝すべきだ。

signal (しぐなる) どこからかやってくるなにか。ただし問題はどこから、ではない。どこにくるかと、いつくるかだ。シグナルはこの2点に関して非常に困った特徴を備えている。また、それは考えなしに設計したから困ったのではなくて、どちらかというと人類の智慧では現状が限界、といった趣き。

なおrubyにおける実装方針は参考になると思われるので解説しておく。signalには付随するhandlerとmaskという資源があり、ハンドラはプロセス固有でマスクはスレッド固有だ。そこでrubyではほぼすべてのスレッドはすべてのシグナルをマスクしており、シグナルを受け付けるスレッドを同時にたかだか一つに制限している。このスレッドのことをシグナルスレッドと呼び、専用スレッドだった時期もあればメインスレッドが兼務していた時期もある。さらにハンドラはタイミングの問題があるので、来たことを記録するだけのとても簡素なものになっている。シグナル固有の複雑な処理はあとでゆっくり行われる。これはカーネルにおける割り込みの処理(upper half/bottom half)などと似ているとも言える。

仕様 (しよう) 仕様とは何か? 近年rubyはISO化の経緯から仕様に対する理解が進んだ。

まず de jeur standard としての仕様がある。ISO30170 / JISX3017 が該当する。

次に de facto standard としての仕様があり、これは現在であれば rubyspec などがある。rubyの実際の実装もこれに含む。

そして最後に、みんなの心の中にある「こうなってたらいいなー」の総体としてのrubyのあるべき姿、とでもいうべきものがある。これを漠然と仕様と呼ぶことがある。

1と3が同じならよかったのかもしれないが、現実には異なるので、得体の知れない3ベースで会話が進むことがあり、気が抜けない。しかし3がないと2のバグが発見できないのでまったくなくすのも無理である。

真偽 (しんぎ) 何をもって真とするかは大別して

真の値trueと偽の値falseがある。それ以外はそのどちらかに変換してから真偽判定する

偽の値falseがある。それ以外は全部真

というパターンが多いが、rubyはそのどちらでもない、少々珍しい判定方式である。

Symbol (しんぼる) 文字列のような見た目をしているが実態はどちらかというと整数である。そもそも1.6くらいまでSymbolクラスは存在しなかったし、Symbolを文字列っぽくしようという過去の試みは失敗に終わった。Symbolという概念がLispから由来していることに疑いの余地はないが、じゃあLispのSymbolは何が由来なのかというのは、rubyistたちの間ではすでに失伝してしまっており、よくわかない。人工知能だからシニフィアンとかシニフィエとかあのへんと関係あるのかなー、と漠然と思う。

人狼BBS (じんろうびーびーえす) 説得ゲーム。他の人狼系ゲームと違ってロールプレイは程々でみんなガチ勝利を目指している点が特異である。ruby界隈に経験者多し。rubyにおけるSFと並ぶ二大基礎教養と思われる。

人狼BBSは日本語専用なので当然海外ではそのものは行われないが、それでも海外rubyistにおいても人狼系ゲーム熱は熱い。RubyConfなどで夜中に集まって車座でオフライン人狼をやる集団が目撃されている。

ZSUPER (ずーぱー) ほとんどすべての局面でrubyにおける括弧は演算子優先順位などの統語論には影響するが意味論には影響を与えない。ところが唯一、superにおいては、 super() と (super) では意味が異なる。このような例は他にはない。この、後者のsuperの用法から出来上がってくる意味論のことをZSUPERと呼ぶ。

スタック (-) 普通の言語と違ってrubyは実行時コンテクストにおけるスタックが一本ではない。RHGでは七本がリストアップされており、その後実装の変遷にともない本数は上下している、というか誰も把握していない。

正規表現 (せいいひょうげん) rubyの正規表現エンジンは現在のものになるよりも前からずっとNFAとよばれる種類のものである。このクラスのエンジンは正規表現の書き方によっては指数時間計算量で走る。そのため正規表現が(人間が生きてる間には)止まらない、という現象が起こりうるが、これは正規表現の書き方が悪いのである。ちなみにrubyの場合のようなバックトラックがあるNFAエンジンはNP完全なので、計算量を本質的に下げる方策はない、と多くの専門家が信じている。あと、正規表現を実行する前にわるい正規表現かどうかチェックすればいいじゃないか、という発想は、チューリングマシーン停止問題なので、輪をかけて難しい。眼力によるデバッグしかない。

select (せれくと) システムコール。あまりに使い方が難しいためLinuxでは select(2) のマニュアル自身に加えて select_tut(2) というチュートリアルが別途用意されているほどである。なおPerlのselectはシステムコールのselectの機能の他に出力を選ぶ機能もついていて輪をかけてイミフ。

Rubyにおいてはファイルディスクリプタは「読み込めるようになるまで読み込まない」「書き込めるようになるまで書き込まない」という方針である。なんでかというと読み込めないのに読み込もうとするとブロックするからだ。そしてブロックしてほしくない。このため、読み込めるかや書き込めるかの確認のために(UNIXにおいては)selectが使われている。

即値 (そくち) いまいち定義が怪しいリテラルに比べて、即値に関してはいわゆるVALUE埋め込みオブジェクト、すなわち TrueClass FalseClass NilClass Fixnum Symbol のインスタンスということでおおむね衆目が一致している。

た

大クラス主義 (だい - しゅぎ) rubyのクラス階層に関してしばしばこのように形容される。たとえばデータ構造のスタックとキューと配列は、それぞれ別とすることにもそれなりの妥当性があり、実際にC++などそのように分かれているが、rubyでは全部ひとまとめにしてArrayクラスだ。

タイマースレッド (-) rubyにはGVLがある。ではそのロックはいつ開放するのか、というと、タイマーで定期的に開放させるということになる。そのためのタイマーが動いているスレッドがタイマースレッド。OSレベルのスレッドであり、rubyスクリプトからは観測することができない、はずなのだが、ときどき影響が出ることがある。たとえばちょっと前のNetBSDでforkできなかったりとか、こいつのせい。

tagged pointer (たぐどぽいんたー) ポインターと同じサイズで、かつ、そのメンバーうちの少なくとも一種類はポインター型であるような共用体のこと。中身がポインターかどうかを判定するのにタグとよばれるビットを使うことからこの名前がある。rubyの場合( → VALUE)、LSBがタグであり、これが立っているものはポインターではない。

多言語 (たげんご) 難しいものの代表。難しくした犯人はバビロニア人。

他言語 (たげんご) Rubyistは意外に他言語について詳しい。単にそういうの好きな人達だからというのもあるだろうが、やはり他山の石として他言語にあるバグrubyにもないかとか他言語の新機能がrubyにも適用できないかとか研究すべき部分が多いということと、あわよくば他言語にてrubyを実装できないかと虎視眈々と伺っているからでもある。ただし最後の意味ではJVM系の言語はすでにJRubyがあるため、あまり興味を引かないようだ。

執筆時点では特にD言語およびGHCによるruby処理系に期待が高まる。

多値 (たち) 様々なモデルが提唱されたが結局どうなったんだろう。

deoptimization (だつさいてきか) プログラムを最適化する際に、最適化しやすい便利な夢(たとえばプログラムの途中でメソッドの再定義は起きない、とか)を見ながら最適化する、と、最適化しやすい夢なんだから当然最適化が効く。で、その夢から醒めるような事態が発生した時に、やおら正気に戻って真面目に再計算しなおせば、その再計算はペナルティとしても、とりあえず夢が見つづけられている間は幸せなんじゃないの、という戦略。あるいは、概ねのプログラムは夢から醒めるような変な事はしないからだいたい幸せなんだけど、万が一そうじゃないときにも一応遅いながらもちゃんと動きますよ、とも言える。この「遅いながらもちゃんと動きます」のことを脱最適化という。

Akrの^C原則 (たなかさんのしゅみ) ユーザーがCtrlキーとCキーを同時押しした瞬間にフォアグラウンドなプロセスは可及的速やかに死ね(大意)、というルール。これを達成するため、rubyではすべての操作は^Cに関係なく可及的速やかに処理が終了するか、そうでなければ^Cで中断可能であるように設計されている。

しかしこれはかなり厳しい条件であり、たとえばrubyの場合Mutexがブロックしているのであっても^Cで中断できる。つまり、Mutexをlockしようとした際にlockの呼び出しが戻ってきても、必ずしもロックが取れているとは限らないということである。これは強烈。こんな特性のMutexは他の言語にはない。

AST (ちゅうしょうこうぶんぎ) Abstract Syntax Tree, 抽象構文木。 rubyスクリプトを意味を保ちつつ、構造体が複数連なった形式に変換したもの。構文木というくらいだから木の形をしている。1.8まではこれを直に解釈していた。現在はASTからさらにISeqへと変換する。

定数 (ていすう) rubyには定数と呼ばれるものはあるが、少々警告が出る程度で何事もなく再代入できるのであり、まったく定数としての責務を果たそうとしていない。しかも逆に普通のローカル変数のような見た目をしているのにどう頑張っても再代入できない変数、などというものもrubyには存在する。rubyはいいかげんだ、とみなすか、そんなのでもそれっぽく運用できているあたり人間の方がいいかげんだ、とみなすか。

独語 (どいつご) Eigenclassなどの用語からrubyコミッターはみんな独語が読めるかのような錯覚を受けるが、実はそうでもない。ただ独語圏内から無活用独語とでもいうしかないような謎の英文(現地ではそういうのを Denglisch と呼ぶらしいぞ)でバグレポートが来ることはたまぁーにある。

特異クラス (とくい -) rubyではあらゆるすべてのオブジェクトは通常の意味のクラスの他に、そのオブジェクトだけをインスタンスとするようなクラスを持ち得て、これを特異クラスと呼ぶ。ところでrubyではクラスもオブジェクトである。だから特異クラスもオブジェクトだ。すなわち特異クラスにもクラスがあり、また特異クラスの特異クラスがある。特異クラスの特異クラスもクラスだから、以下無限に続く。

TravisCI (とらびすしーあい) 最近、rubyでも使ってるCIツール。githubと連携してくれるので便利。

な

名前 (なまえ) 名前重要といいつつrubyの場合は実は実装上ローカル変数は配列で管理されているのであまりたくさん(数十万個とか)名前があると変数の検索に時間をとられてパフォーマンスが悪化する。なにごともやりすぎはよくない。

native thread (ネイティブスレッド) ふつうのスレッド。nativeとわざわざ言うからにはnon-nativeなスレッドも当然存在する。それのことをgreen threadと呼んだりする。

NODE (のーど) データ構造。ASTのメモリ上の表現である。オブジェクト (→ RVALUE) と同じサイズであり、1.9の途中のタイミングまではRVALUEと一緒に混在してた(→ heap)。なのでビットパターンにある種の互換性があり、rubyのGCは今でもNODEを理解する。しかしながらNODEは一度作ったら滅多に減らないという特徴がある(ASTなんざそう頻繁に書き換えない)。これを毎回GCがスキャンするというのはコストがだいぶ無駄である。という理由により現在はheapからは隔離されている。

は

parser (ぱーざー) 魔窟。ruby 1.0が出たころのruby 2.0の目標としてパーザーと評価器の刷新、があったはずだが、評価器はYARVが入ったものの、parse.yに関してはついに秘伝のタレを継ぎ足しつづけて20年だ。底のほうでどんな虫が繁殖してるか分かったもんじゃない。また、理解している人間が少ないので数人欠けるとやばい。後継者の養成は急務といわざるをえない。

Bug (ばぐ) → 仕様

[BUG] (ばぐ) ruby処理系がなんらかの理由でそれ以上正常動作しつづけることができなくなった時に、断末魔として出力する内容に含まれている特徴的な文字列。転じて、ruby処理系がそのような状況に至ること。「[BUG]った」など。

RHG (はっきんぐがいど) 「Rubyソースコード完全解説」という名前で出版されたが皆ハッキングガイドと呼ぶ。UNIXにおけるLions' Commentaryのようなものである。よい本。今となっては情報が古いのが難点。また、よいからと言って売れたわけでもないらしいというのが悲しい。現在古書としてプレミアがついている。

patch (ぱっち) モンスターから手に入れるもの。

バベル17 (- せぶんてぃーん) 必読書。 → 完全言語の探求

VALUE (ばりゅー) 型。Cレベルにおけるrubyの値の表現。だいたいポインターだが時々違う。→ tagged pointer → 即値

RVALUE (ばりゅー) データ構造。VALUEがポインターである場合は(ぶっこわれてなければ)その指すポインターの先はRVALUEだ。そしてRVALUEのホモジニアスな配列がheapだ。RVALUEは伝統的に構造体であり、ポインター5個ぶんのサイズで、先頭からポインターひとつぶんの領域が管理領域、その次がクラスへのポインター、残りがクラス固有のデータである。この仕組みは正直にいって古く、現代のプロセッサ・アーキテクチャから見ればいけてない。キャッシュラインの幅で割り切れないからだ。典型的なケースであるamd64アーキテクチャでLLP64の場合、RVALUEは40byteとなるが、1word減らして32byteとするか、3word増やして64byteとするのが現代的には妥当といえる。

heap (ひーぷ) rubyコア用語としてはheapとはrubyオブジェクトプールのことである。この用法は特殊なのでruby以外では通じない。実装上はrubyオブジェクトはheapとよばれる単位でOSから確保され、これを少しずつ切り売りしていく。なくなったらGCが走る。GCの結果heap上のすべてのオブジェクトが回収された場合、OSに返すこともある。このような管理機構はobjspaceと呼ばれ、rubyスクリプトからは定数ObjectSpaceとして見える。

bigzero (びっぐぜろ) Bignumのインスタンスで値が0のもの。というと、みんな最初は「えっ」という顔をするのだけれど、BignumとFixnumというのは実は互いに素ではない。というかBignumはFixnumの真のsupersetである。とくに0付近の、0, 1, -1 といった代表的な値は、Fixnum, Bignum, Float, BigDecimal, Complexのいずれでも表現可能といえる。

Fixnum (ふぃくすなむ) VALUE埋め込みオブジェクト。いくつかの点でその他のrubyオブジェクトとも、あるいはJavaなどのプリミティブ型などとも異なった振る舞いをする。

Fixnumの幅は必ずしもintptr_tと同じではない。同じではない例としてWin64が挙げられる。したがって変にFixnumの幅を仮定したプログラムを書くと変なことが起こる。そのようなプログラムはrubyスクリプトとしては稀だが、拡張ライブラリーとしてはありえる。

fairness (ふぇあねす) 単にfairnessと言った場合は大抵、スレッド間のコンテキストスイッチの公平さに関して言っている。これを本当に公平にしつつちゃんと物理コア数に対してリニアにスケールさせるのはマジムズい、らしい。

仏語 (ふらんすご) 仏語話者の人は独語話者の人たちに比べて結構違和感のない英文でバグ報告してくる気がするなあ。なんでだろう。

flip-flop (ふりっぷふろっぷ) rubyで一、二を争うへんな機能(もう一個は → once)。意図的にプログラムを難読化する目的か、ワンライナーで使われる。「rubyから削りたい機能」という話題で毎回必ず提案される(読めないから)が、flip-flopで実現できるものをflip-flopなしで書くのがひじょうに面倒なので、毎度却下されている。

ところでまったく同じものがPerlにもあるのだが、Perlでflip-flopが特別へんな機能という認識の人は少ない気がする。なにがこの差を生んでいるのか。

flonum (ふろなむ) VALUE埋め込みオブジェクト。最近導入された。64bitマシンにおいて整数と浮動小数点数とポインターはマシンレベルで全部幅が一緒だ。だからそれらを共用体として一緒に扱おうというのはある程度妥当な発想ではある。ただ浮動小数点数には余ってるビットとかは(常には)ないので、ある64bitのなにかが整数か浮動小数点数かの判定をどうするかが若干トリッキーではある。rubyのflonumの方式はささださんが一本論文を書いた程度には新規性のある方式。

BASERUBY (べーするびー) rubyのソースコードは一部、名状しがたいレシピファイルのようなものから機械的に生成されているが、その生成機構もrubyで書かれているので、再生成しようと思えば完動品のrubyが必要になる。このときに使うrubyのことをBASERUBYと呼ぶ。普通に生きている限りはよほどのことがないかぎり再生成は不要で、したがって普段は問題にはならない。普通ではない、再生成が頻繁に必要なタイプの人間は、普段から十指に余るrubyバイナリーに囲まれて暮らしているような人種であり、これも問題にならない。

Concurrentとparallel (へいれつとへいこう) なんかよくわからんということだけは確かだ。

母衣小 (ほろしょう) 松江市立母衣小学校。これといって何の変哲もないただの小学校だが、NaCl本社をその校区に含むという点が少々特殊である。ちなみに上は二中→東高。

本屋 (ほんや) rubyistたちが本気を出すとジュンク堂書店池袋本店の総合売上ランキングが歪むくらい売れる。あれはただの書店というより、ほとんど兵站。

ま

matzruby (まっつるびー) 昔そういうブランチがあった。今はもう放棄されている。

micro benchmark (マイクロベンチマーク) プロパガンダ以上の意味はない。とはいえプロパガンダだからやらなくてよいというものでもない。

MVM (まるちぶいえむ) 昔あったブランチのひとつ。一つのrubyプロセスの上で複数の処理系を走らせることで、プロセスよりも細粒度だがスレッドよりは粗粒度な並行実行を実現しようとしていた。一応諦めてないことになってるが、だいぶ放棄ぎみ。

M17N (まるちりんがらいぜーしょん) 昔あったブランチのひとつ。名前のとおり多言語化を目的としていた。現在は放棄済みで、実現しようとしていた機能はもう取り込まれている。→ 多言語

malloc (まろっく) mallocに一家言持つ人は多いが残念ながらrubyではmallocが少々速くなったところでさして意味はない。GCがあるうえにGVLもあるから、mallocが一般的に想定しているマルチスレッドアプリケーションのメモリ確保戦略とはまるで違うのだ。

miniruby (みにるびー) rubyをコンパイルするためにrubyが必要なので、rubyのコンパイルでは初段としてまずはブートストラップのために最低限の機能だけをもったrubyのサブセットを作成する。これがminiruby。動的リンクモジュール機能を欠くため、あらゆる必要な機能が単一バイナリーに詰め込まれており、そのため実は最終的にできあがるrubyよりでかい。なおminirubyを作成するにもrubyが必要で、それはBASERUBYと呼ばれる。

メソッド探索 (- たんさく) rubyで一番か二番目に重い処理。他のボトルネック(ファイルIOとか)をどんどん改善していくと最後にこれが残ることが多い。

rubyのメソッド探索は動的、つまりメソッド名や引数からどのメソッド実体を呼ぶかコンパイル時には決められない。じゃあ実行時に一回決まればあとは同じかというと、そうでもなくて、呼び出すメソッド実体がどんどん変わっていくことがよくある。もちろん、変わらないことの方が全体としてはよくあるので、一回でも探索したメソッド実体はキャッシュされている。が、どんどん変わるようなやつがいるとキャッシュがどんどんパージされていってヒット率が下がり、パフォーマンスが悪化する。メソッドキャッシュのinvalidateアルゴリズムが本来残っててもいいキャッシュエントリまで消してしまっていることはよく指摘されるが、じゃあどれが本来残っててもいいのか、というのを判定するのはそう容易ではない。後から検証したら不要な操作でしたね、というのと、操作を行う前にそれが不要かどうかを判定するというのでは、難しさが全然違う。

メソッド呼出し (- よびだし) rubyで一番か二番目に重い(中略)これが残ることが多い。

rubyのメソッド呼出しは動的、(中略)変わっていくことがよくある。ということはつまり、メソッド呼び出しのインライン展開ができないということである。rubyにおいては 1+2 のような常識的に考えて 3 だろそれは、みたいな状況でも律儀にメソッドを呼び出す。このオーバーヘッドが積み重なって無視できないペナルティになるのだ。

vm_exec_core() (めいんるーぷ) rubyのメインループは一個ではない。というのも、C関数と入り乱れる事があるからだ。なんらかのrubyのコードがメソッドを呼び出したときにそれがC関数に帰着することが良くある。しかしそのC関数の中から(yieldしたりして)またrubyのコードが実行されるというのも、これまたよくある。そのときにrubyでは、Cスタックを巻き戻してメインループに戻るようなことはせずに、メインループの中から伸びたCスタックの上にさらに新しいメインループを開始する。面倒なことをしていると思うかもしれないし実際面倒だが、もとのメインループに戻るのよりはまだ簡単なのだ。このようなことが積み重なって、ある瞬間のrubyにはメインループが何個もあることになる。

や

YARV (やるう゛) というコードネームがあったのさ。一時期言わなかったけど最近またYARV言うようになってきたのはなぜだろうね。

yield (以ーるど) よみづらさに定評がある。

ら

羅語 (らてんご) rubyコミッターはみんな羅語が読めるかのような錯覚を受けるが、実はそうでもない。というかせいぜい羅語のフレーズは読めても、羅語の作文ができる人はいないと思われる。

LSP (りすこふのちかんげんり) Liskov's Substitution Principle, リスコフの置換原理。サブクラスに関する設計指針として有名だが、rubyではユーザークラスにおいて必ずしもLSPを強制しない。rubyでは変数に型がないので、変数への代入によるダウンキャスト・アップキャストが行われないからだ。rubyにおいてはキャストのような操作は常にオブジェクトのコピーが生成され、bitcastやreinterpret_castとよばれるものはない。したがって、暗黙のうちにあるオブジェクトが別のクラスとみなされるということがない。そのため、LSPは、依然としてとても有効な設計指針ではあるものの、かならずしも言語側で強制する必要がなくなっている。

リテラル (-) コンパイル型言語と違ってrubyにおいてはリテラルという概念は曖昧だ。たとえば多くのコンパイル型言語では文字列はリテラルの代表的なものだが、rubyだと "string#{rand()}" のような例はいくらでも作れる。

例外 (れいがい) 1.8までは例外はbeginでコストがかかりrescueではほとんどノーコストだったが、1.9移行で逆転し、現在はbeginはほとんどノーコストだがrescueが重い。つまりrescue節に実際に入ってこなければ、beginやrescueが書いてあったとしてもさしてペナルティーにならないということである。意外に最近でも1.8のくせを引きずったスタイルを見かける。気をつけよう。

Rails (れいるず) べつにrails嫌いじゃないですよ。好きでもないけど。

Railsの人たちにとってrubyがないとrailsが成立しないけど、rubyにとってrailsなくてもべつにrubyは成立する、という非対称さから、rails側から見るとrubyの開発は冷淡に見えるのかなあ、とは思われる。しかしrubyの側から見ればべつにrailsだけを特別どうこう思っているというわけではない。

Redmine (れっどまいん) rubyのIRCでredmineと言ったらそれはプロダクトのことではなくてredmineを使って動いている bugs.ruby-lang.org (旧アドレス redmine.ruby-lang.org)のことである。

long (ろんぐ) Cの整数の一種。昔からrubyのさまざまな箇所でlongを悪用して整数じゃない意味で使ってる部分がある。1.9の期間を通じて、それらは徐々に intptr_t や st_data_t に置き換えられていった。ただ、時々まだ残ってる。そのためソースコードでlongが出現する箇所をいじる際にはある種の緊張感がある。

わ

Visualizing git blame

Git には git blame というコマンドがあり(他のツールでも同様の機能は提供されている)、これを使うことでソースコードのどこを書いたのが誰か、という情報がline-by-lineで取得できる。この情報は行単位なので一次元の情報だけれど、適切な空間充填曲線に乗せることで二次元にマッピングできて、それに適当に作者ごとに色をつけるということをやってみると色々楽しい。そのスクリプトはひじょうにstraight-forwardな記述だとこういった感じになる。上の絵はruby 1.8.7に対する実行結果で、ChangeLogとかのあきらかに面白くないファイルは除外してあるからまあ、そのままの結果ではないけれど、これを見ると色々な思いが去来する。

Ruby 1.8.7 は多数の開発者が手を入れており、少数の支配的な貢献者といったような存在をみいだすことができない

あえてアマゾンのリンクは貼らないので会場で会おう

たのしいRuby 第四版

これを買うべき人: 全員

ひとこと: ついにRuby 2.0の時代が本格的に始まったことを宣言する決定打的一冊であり、必携。今後「情報がないから2.0は不安」などとうそぶくことはこれで不可能になった。

テストから見えてくるグーグルのソフトウエア開発

これを買うべき人: テストを日常的に書いている人と、テストを書く習慣がない人

ひとこと: これはずばり俺が読みたいので買います。こちらからは以上です。

白と黒のとびら

これを買うべき人: 「記号と再帰」がおもしろかった人

ひとこと: まあなんていうんですかね、形式言語とか好きな人って結局そっちに道を踏み外しちゃうきっかけってテングワールだったりするわけじゃないですか。だからこういうふうに攻めてくるのって変化球のようでいて実はど真ん中だと思うんですよね。

型システム入門

これを買うべき人: RHGがおもしろかった人

ひとこと: 久々に本気手加減なしの全力投球本が来たってところ。これに「入門」とつけるセンスはさておき、内容はといえば大学院レベルなので流し読みではなかなか辛い。そういうのが好きな人にはたまらない。ええ。1章だけですでに価格分の価値はあります。

講座ＩＴと日本語研究4　Rubyによるテキストデータ処理

これを買うべき人: 俺とうささん

ひとこと: 数ヶ月か1年くらい前にIRCで話題にしてた本! なぜ入荷している… これはRubyプログラムとして読むべきものは書いてなくて、日本語研究が好きかどうかでしかない。なので好きな人だけ買えばいいです。

プログラマの考え方がおもしろいほど身につく本

これを買うべき人: じつはプログラマこそ読むべき

ひとこと: 俺が知ってる中でこれにもっとも近いのは「エレガントな問題解決」あと「いかにして問題をとくか」。ようするにプログラマの考え方とは、そういうことだと分かる。そして意外に実践されていないので、ぜひ身につけるべき。

インフォメーション

これについては山形浩生の書評があるので自分が何か付け加える必要性はあまり感じない。

進化するアカデミア

これを買うべき人: 表紙に騙された人

ひとこと: 進化と呼ぶべきかは分らないが、敷居は確実に低くなってきてるよね。研究で食べようとさえ思わなければいいだけで、すごい時代になったもんです。

その他

https://www.facebook.com/bovensiepen/posts/10200155061579359

どうなんですかねえ。まあぶっちゃけ、この本にツッコミを入れることが容易な種族はいる。たとえば「プロセスがfork(2)するときにPOSIX semaphoreをsem_wait(3)してたらそのセマフォはどうなってまうの？」とかそういうの(実際書いてない)ね。けど、それって、そういうの目ざとく気がついてしまう人、はっきりいって対象読者じゃないというべきだろうなあ。LinuxとBSDのカーネルコミッターの皆さん、セプキャン講師陣の皆さん、未踏スーパークリエーターの皆さん、お疲れさまです。おまえらはお呼びじゃない。

でね。俺もどっちかというとお呼びでない側っぽいので、色々考えた。昔はCで書くしかなかったサンプルコードがRubyで書いてあるというのはよいですね。なにがよいかってCほど煩瑣じゃないから、本質的な記述(だけとは言わないまでも)の割合が大きくて、いわゆる密度が高い気がする。なのでページ数のわりに内容薄い印象は受けない。高速道路理論ってやつだな。この本で学べるところまでいけば、まあRubyでプログラム書く上では標準的と言ってよい理解度なのだろうし。

もちろん上に書いたように、抜けてる箇所は多々あって、それは自力でmanを読んだりしてなんとかする必要がある。ただ、この本を最後まで読めばmanを使う体力は得られるだろうとは思いました。あとは原著は実は3部作だったりするので、全部通して読めばもう少し理解が深まるとかはあるのかもしれない(が翻訳されるかは…売れ行き次第なのかも)。

というわけで率直な感想を言えば「目次見て知らなそうな事が書いてそうなら、買いじゃないっすかね」とかそういう感じ。これと同様の知識を得るためには一番の近道ではありそうに感じました。

Heroku使いなさいよ。

10年前、たしかに、自宅サーバでApacheでCGIでPerlっていう時代がありました。でもさすがに今それはないわ。10年前それやってたサイトのほとんどが結局メンテナンスコスト払えなくて鬼籍に名を刻んだ。あるものはクラックされ、あるものは更新が止まった。そういう歴史の流れですので。今更OS標準だから偉いとか偉くないとかさすがに。ありえんです。

ああ、おまえらがプロのシステム管理者なら(つまりサービス提供側なら)ちょっと話は違う。システム管理者のくせに贔屓の言語とか持っちゃいかん。本当に。どんなシステムでも同様に管理できないようではプロ失格。Perlが来たらPerlでRubyが来たらRubyを鼻歌歌いながら管理できないようでは、半人前です。猛省すべき。