福井行

日記

IngressのField Testがあるので福井に行ってきた。 Field Testは国内でも数か所で実施されるのでどこに行こうか結構迷ったのだけど、結果としては福井で正解であった。なんだか、自分でも思った以上に福井と縁があったので、終始それを感じて楽しめたのである。

さて、まず福井につくなり駅の階段で迎えてくれるのが永和システムマネジメントの広告である。Rubyといえばesm, esmといえば福井が本社なので、最初からそこはかとない安心感と親近感を覚えさせてくれる。

次に、階段を降りたところにいるのが見慣れた恐竜博士の像。ながらく表参道で働いていたのだけれども、昼休みによく歩いたあたりに福井のアンテナショップがあって、その前にも恐竜博士がいたものだった。見慣れた姿を本場で見ることができて感激する他ない。

聞けば、福井駅には恐竜博士があと3体いるそうな。改札口をでたところにも確かに居た。他にもえちぜん鉄道福井駅にもいるのを後に発見するが、残り1体は所在がわからなかった。

さて、メインのField Test中にポータルを周る際には福井のエージェントのかたがたとご一緒できて(途中ではぐれたけど)、とてもありがたかった。なんとかメダルを獲得できたけれども、時間内に3000m歩くという項目はかなりギリギリだった。記録上は3017mとなっている。

天気にも恵まれて適度に曇って暑すぎず、良いIngress日よりだったように思う。FT福井の中の人には改めて感謝したい。

FT福井の翌日、この日は当初からあちこち見て回るつもりでいた。さて福井といって思い出すのは福井県民が活躍する『ミカるんX』であろう。いやかなり偏った見解かもしれないけど、あの作品のファンなので。そういうわけで聖地巡礼としてソースカツ丼を食べて、恐竜博物館に行かなければならない。

恐竜博物館については良い評判を聞いていたものの、実際にはその期待をもはるかに上回った。常設展示場にはいるとすぐに圧倒的な物量の化石骨格標本が目に入る。よく見渡せば古生物学だけに限らず地質学全般の展示もあり、標本の種類も解説も凝っており、完全に堪能しようと思ったら1日ではまるで足りないことが分かってくる。 残念ながらそこまで時間はないのでめぼしいところだけ見たものの、ぜひまた来たいものである。

Ingressポータルを巡りながら勝山駅まで歩き、えち鉄で福井に戻る。

ソースカツ丼はヨーロッパ軒を薦められたので、その晩に行ってみた。

時間管理研修の話

ある社内研修の一コマだった。 私は受講対象者ではないんだけど、良く覚えていない謎の理由によりオブザーバーとして参加していた。 ちょうど講師が「重要でなく緊急でもないもの」「重要でないが緊急のもの」「重要だが緊急でないもの」「重要で緊急のもの」って例の話*1をしていたときだった。話がだいぶすすんでそろそろ次の話題に行こうかというところで、はたと気づいた。私を含めて参加者の半分ぐらいがラップトップを開いてメールやSlackをチェックしながら聴いている。これはどうしたことだろう。

この手のメールチェックってのは往々にして「重要でないが緊急なもの」か「重要でも緊急でもないもの」だ。少なくとも私がやってたのはそうだった。 そこで、その場で参加者に訊いてみた。「私も含めてみんなメールチェックしてたけど、それって重要で緊急なものですか?　もしそうだったらお忙しいところ参加頂いていて大変申し訳ないんだけど、全員がそうって訳でもないんでは?」 すると、全員が「重要でないが緊急なもの」をやっていた。

一方で研修なんてものはおおよそ緊急でなく、でも会社はそれが重要だと思ってなけなしの研修予算と研修時間枠を使って投資している。つまりこれは「重要だが緊急でないもの」だ。 仮に参加者が「こんな聞き飽きた話はくだらねー」と思っていたとしても、会社はそう思ってないのだから、ならば速やかに「この研修くだらねー」という適切なフィードバックを与えるのは重要な仕事だ。

なんということだろう。我々は「重要でないが緊急なもの」より「重要だが緊急でないもの」を大切にしよう、という話をまさに聞き、うんうんそうだよなと思いながら、最後の最後まで疑問を持つことなくその逆をやっていた。つまり今まさに間違った優先順位を付けて、「重要だが緊急でないもの」について成果を出してなかった。

おそらくこれこそが、「重要だが緊急でないもの」に時間を割こうという話なんだろう。この話はきちんと説明されれば当たり前のことを言っている。漫然と聞いていたら誰もそこにさしたる疑問を抱かない。ただし、それを我がこととして引きつけて考えるには集中が必要だ。どんなに当たり前の話に聞こえたとしても、それを理解するの思考リソースを割く必要を感じなかったとしても、受講した時間から真に価値を引き出すためにはそれを真剣に考えることが必要だった。

「バックグラウンドで思考する」ってやりかたもあるが、そのために必要なフォアグラウンドタスクはアルキメデスの昔から典型的には入浴とか散歩とか落ちものゲーとかそういうやつで、メールチェックや定例会議ではない。 「重要だが緊急でないもの」にきちんと取り組むには、「重要でないが緊急なもの」を明確に排除して存分に取り組む時間を意識的に作らねばならない。

我々は、図らずもその意味を研修の中で実証したのだった。

*1:ビジネス書で引用されすぎていてどこが元ネタなのかよく把握してなかったんだけど、今調べた限りでは『7つの習慣』なのかな?

ブロックによるRuby内DSLの起源

ruby

言語内宣言的DSLを構築するRubyの能力がいつからできたものなのか、ふと疑問に思った。

この手の記法で一番古くからあるものとして思いつくのはTk bindingだが、これはいつ頃からあったんだろう。 そう思って古いRubyを見てみた。fj.sourcesにて最初に世界に向けて流されたというruby 0.9.5を見てみると、sample/tkhello.rbに次のような例が既にある。

TkButton.new {
   text 'hello'
   command proc{print "hello\n"}
   pack('fill'=>'x')
}

MatzがLispを意識していて1LispでDSLが盛んに構築されていたことを考えると、これはMatz単独の発明ではないかもしれない。でも、この時点で既にブロックというRubyの機能を用いて宣言的にものを記述するという発想はあったことは分かる。

たとえブロックという制御構文を自作するための記法があったとしても、宣言的語彙を構築するという意思がなければAPIはこんな感じの筈だからだ。

TkButton.new {|btn|
   btn.text = 'hello'
   btn.command = proc{print "hello\n"}
   btn.pack = {'fill'=>'x'}
}

ChefやVagrantfileやRSpecといった現代のDSLを知っているとすこし物足りないのは確かであるものの、基本的な形はRubyが最初に一般に投稿された1995年の時点で完成していたことが分かる。

ただし、この発想が更に一歩進んで臨界点を超えて広まり出すにはRakeを待つ必要がある。そして、最後の部品である表現能力のさらなる探索はRSpecによってもたらされたと言うべきであろう。

  1. そもそもRubyにはMatzLispというあだ名があったわけだけど、割とあとのほうになるまで、nilが空配列と同等に扱われるケースが広く残っていたりというあたりが思い当たる。↩

Corporate Reliability Engineering

最近、SRE - Site Reliability EngineeringのアナロジーとしてCorporate Reliability Engineeringというのを考えられないかみたいな話を社内でしている。

SREは伝統的なシステム運用チームの仕事を再定義したものだ。SREはシステムの安定だけを至上目的にするのではなく、際限なく増え続ける運用タスクを真面目にこなすことを目的にするのではない。開発チームを巻き込んで適切なシステム安定度を見いだし、より少ない手間でシステムを安定運用するための開発を自ら行なう。運用のルーチンワークに費やす時間を全体の50%に抑えるように努力する。そして残り50%で今後もその配分を保つ為の開発や、更に上を目指すための仕組み作りを行なう。

同じ発想は業務システムや社内セキュリティ、更にはコーポレート部門にも適用できるのではないか。つまり、業務システムを運用して社内業務を回すとか社内セキュリティを保つ業務、あるいは人材を募集したり経費を処理したり業務についても、際限なく増え続けるタスクを間違いなくこなすことを目的にしないやり方があるのではないか。 相対する部門と共同でより少ない手間で適切なエラーレートを保って回していく仕組みを作り続けるのが重要で、それに時間の50%を使うべきではないか。

うちの会社はWeb系スタートアップ文化から出発している一方で、急速に規模を拡大している関係上で管理すべき物はしっかり管理する必要に迫られている。そこで、管理が物事を堅苦しくしたり管理コストが線形以上のオーダーで爆発したりしないためには、SREの思想が必要なんではないか、という話を最近している。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

はてなブログに引っ越した

ここ何年か自作のブログシステムrhianoletheでブログをホストしていたが、とうとう耐えきれなくなったので、はてなブログに引っ越した。 主なリソースについてはすべて旧URLからのリダイレクトを提供しているつもりだが、取りこぼしがあったらアクセスログを見ながら適宜修正していこうと思う。

耐えきれなくなったのは、この数年のwebフロントエンドの発展と私の専門領域の乖離が原因だ。まず第一に、数年というもの私が専門にしてきたのはバックエンドだった。 一方、この期間においてデバイスの多様化やフロントエンド技術の発展がめざましく、こちらはこちらで専門化が進んでいったため、もはや個人が片手間に商用水準のフロントエンドをこなせる時代ではなくなってきている。少なくとも私には無理になってきたし、そこは私にとって重要な注力領域ではなくなった。

そういうわけなので、しばらくはてなブログでやっていこうと思う。 それにしても、はてなブログはカスタムドメインのHTTPS対応がいつできるようになるんだろう。

Jsonnetでwebアプリケーションの設定ファイルをテスト可能に

ソフトウェア開発

最近、Jsonnetを用いてwebアプリケーションをデプロイする際に適用する設定群をテストしようとしている。

今やInfrastructure as a Codeと言われて久しく、アプリケーション配備の基盤構成もその上で走るwebアプリケーションをどうやって設定するのかもコードとして書かれるのが一般的になった。 それらはコードとして書かれているのでバージョン管理可能であり、テストも可能である。だから何かが間違っていれば実際に配備する前に気づくし、それでも間違えていれば差し戻せる。

「どうやって設定するか」はコードになった。では「何が設定されるか」はコードになっているだろうか。やっている人もいるだろうけれども、そんなに簡単な話でもない。 実際Chefで設定ファイルを扱う際は templates なり files なりが第一の選択であるとは思うが、これらはよほどヘルパーメソッドを充実でもさせない限りそこまでモジュール性を提供してくれない。

そこでJsonnetなのである。詳細は 別記事 に譲るが、JsonnetはJSONやINI形式の設定ファイルを生成するための純粋関数型言語である。これを用いれば、たとえば運用環境ではログローテーションを合わせて設定するが開発環境ではしない、といった差異を抽象化しておいて複数のアプリケーションに一貫して適用することができる。最近試みているケースでは、あるアプリケーションの設定 config が与えられたとき、次のように書くと開発環境の設定を出力する

util.environment.dev(config)

これを運用環境用に差し替えるには次のようにする。

util.environment.live(config)

開発環境と運用環境の設定は同じ config から派生しているので、ユーティリティ関数が生成する差異を除いて両者が一貫していることが保証される。 また、 util.environment.dev や util.environment.live がしっかり書かれてテストされている限りにおいて、特定のアプリケーション用設定でうっかり運用環境用の何かを設定し忘れるということもない。

さて、ここでユーティリティ関数群をしっかりテストしなければならないという問題が発生する。そこでJsonnet用のunit testライブラリ JsonnetUnit を書いた。

アプリケーションの実装をテストするのは当たり前だ。どうやって設定を適用するかをテストするのも当たり前だ。今後は、どんな設定が書かれるか、運用環境と開発環境で何が違っていて良いのかをテストしていきたい。

情報技術による変革の道のりを思う

www

祖父母と話していて、ちょっと調べて本を読んで考えれば分かることに対してなぜいつまでも堂々巡りの思考を巡らしているのだろうと思うことが良くあった。 学生時代に工場生産や農業にかり出されてあまり教育を受けられなかったというのはあるが、それにしても祖父は戦後に大学を出ている。時代的な教育の問題だけとも考えづらい。

しかし、よくよく考えてみるとちょっと調べるために私が使うのはインターネットの情報だ。書籍は書籍の価値があるので同様に情報源とする(今は過渡期で境界が曖昧とは言え、やはり書籍の形に手間暇掛けてまとめ上げた有料情報ならではの価値というのはある)が、それにしたって書籍に到達するのはweb上の書評経由であることも多い。入手経路も半数はAmazonからだ。これらを通じて学んだ情報や考え方、情報の取捨選択の方法に基づいて私は考えている。

これらはどれも祖父母が持っていない物だった。自分が何を知らないのか俯瞰しようとすれば、いくつもの紙の書籍を図書館で読むしかない。しかしこれらはちょっとした話題についての検索効率ではwebに満たない。司書に検索支援を頼もうにも我々がwebで検索するほど気軽にできることではないし、地方の図書館員に占める司書資格者は多くないし、そもそも足が悪くてはそうそう図書館にも行けない。webがなくては、webのみならず書籍や雑誌にすらろくにアクセスできない。情報を得るための情報や情報を抽出するための情報からも隔絶されていく。

ほんの二十数年ほど前まで、インターネット技術は一般的ではなく、社会の殆どはこんな状況だった。知らない間に我々はずいぶん遠くまで来たようだ。