満足せる豚。眠たげなポチ。

ログの解析で Ruby を使っているんだけど、二時間かかって死ねる。繰り返し呼んでいる Time.parse がボトルネックみたいなんだけど、どうにかならない？って依頼が来た。

Time.parse は柔軟性ありまくりで便利すぎるから、そりゃ、速度は諦めないとねーと思いつつ、対応案でこんなのを出してみた。

t = "2007/11/28 15:30:28.015".split(/[\/ :.]/)
Time.utc(*t)

t = "2007/11/28 15:30:28.015".split(/[\/ :.]/)
usec = t.last.to_i * 1000
t.last.replace usec.to_s
Time.utc(*t)

無事、劇的に改善。

そういえば、DateTime.strptime てのもあったなーと思い試してみると、むしろ Time.parse よりも遅かった。

ついでに、実行速度といえば VM だよね。ということで、CRuby と JRuby と YARV で比較してみたところ、CRuby と YARV だと少しだけ YARV が速い。JRuby は大体その二倍程度の時間がかかった。

さらに、おまけで JRuby のバグ(?)発見。

t = "2007/11/28 15:30:28"
DateTime.strptime(t, "%Y/%m/%d %H:%M:%S")

が、失敗する。

Amazon.co.jp の値付けが狂っていて、あまりにけしからんので衝動的にエントリ。すでに全部持っている自分涙目。

後のバンド名にもつながる中村一義の 100s. 超名曲・キャノンボールは必聴。一人でしみじみ聴くとホロリと来る名曲が多い。

100s

posted with amazlet on 07.11.29

中村一義 HYAKU-SHIKI
EMIミュージック・ジャパン (2002/09/19)
売り上げランキング: 10147

amazlet.com で詳細を見る

同じく中村一義の（このスタイルでの）最高傑作 ERA. メロディの良さで名高い中村一義の中でも最も美しいアルバム。

ERA

posted with amazlet on 07.11.29

中村一義 サー・E.エルガー
EMIミュージック・ジャパン (2000/09/06)
売り上げランキング: 9843

amazlet.com で詳細を見る

アルバムの総合力では NUMBER GIRL のオリジナルアルバム最高傑作と言っていい、SAPPUKEI. それぞれの曲を考えると、SCHOOL GIRL BYE BYE の方がいいとか、そもそもライブアルバム聴かずに NUMBER GIRL を語るなとか色々意見はあるのだろうけど、録音と曲のテンション、曲自体のクオリティ、アルバムとしてどうか、という視点だとこのアルバムの完成度は異常。NUMBER GIRL を代表する名盤。

SAPPUKEI

posted with amazlet on 07.11.29

NUMBER GIRL 向井秀徳
EMIミュージック・ジャパン (2000/07/19)
売り上げランキング: 38200

amazlet.com で詳細を見る

くるり・岸田繁も絶賛の湯川潮音。湯川潮音の作品としては、「紫陽花の庭」か「逆上がりの国」を推したいのだけど、このアルバムのコストパフォーマンスの良さはすばらしい。岸田繁提供の「裸の王様」の名曲振りに震えたら、ぜひ「エデンの園」や「キルト」のような本人作曲にも注目してみてほしい。James Iha が曲提供＆演奏で参加しているのも、The Smashing Pumpkins 好きにはうれしい。しかも、どこを切っても Iha らしいメロディだし。

湯川潮音

posted with amazlet on 07.11.29

湯川潮音
EMIミュージック・ジャパン (2006/01/25)
売り上げランキング: 4528

amazlet.com で詳細を見る

極めつけはこれ。フルアルバムで \1,500 と元々破格なのに、さらに安くなって \1,260 だそうな。最高傑作との声もあるアルバムがこの値段でいいのかね。Syrup 16g らしい、そして良い意味で邦楽ロックらしいアルバム。

HELL SEE

posted with amazlet on 07.11.29

syrup16g
コロムビアミュージックエンタテインメント (2003/03/19)
売り上げランキング: 5657

amazlet.com で詳細を見る

最後に番外。これは持ってない。そして、買おうか真剣に悩んでしまった。安いなぁ。

やしきたかじん(1)

posted with amazlet on 07.11.29

やしきたかじん
ビクターエンタテインメント (2005/06/30)
売り上げランキング: 28897

amazlet.com で詳細を見る

単に言語自体への興味から JavaScript 本を読んだ。いい塩梅に気持ち悪くて、とても好きなかんじだった。手元にあったのがなぜか今さらの第３版だったので、第５版を買ってやろうか悩み中。

ちなみに突然 JavaScript を知りたくなったのは、るびまの石塚圭樹さんの Hotlinks でメソッドがファーストオブジェクトじゃない云々のところを読んで、なんとなく。

今年は Haskell, Smalltalk, JavaScript と浅いところでは色々読んだので、このまま勢いだけで年末までに On Lisp を読もうと企み中。

ruby-dev:32258 のまつもとさん発言から。

個人的には慣れれば分かるような 気はしますが、デザインにおいて「慣れれば」というのは危険な因 子だったりします(どんなに悪いデザインでも慣れればなんとかな るから)。

そして、Enumerable#drop てのがあるのか。Enumerable と Array, String あたりは一度 1.9 の動作を全部確認してみないとダメだな。

ruby-dev で Array#tail が提案されているけど、たしかに head/tail は欲しいなぁ。再帰を書くときに一々独自実装とかめんどすぎる。

今は dup して呼び先で shift で head 部と tail 部に分けて、みたいなことをしてるけど、first/rest か head/tail が入るなら、そっち使いたい。

名前はここに関してはどちらもそういうもんだと受け止めるからあんまり違和感ないかな。議論自体は面白いからどんどん紛糾してほしいけどw

それにしても、パッケージの人たちはなんであそこまで業務システム開発の世界を嫌うのかね。過剰反応というか。

それでも彼らはぼくの現場を変えてくれないので、自分自身で変えてくのです。

これ、必読。

業界の重鎮とやらに惑わされるヒマがあったら、一歩でも前に進むために何をするかを考えたい。

山ほどあるサブセットから, どうやって適切な妥協点を選べばいいのだろう. 絡まりあったプラクティスをときほぐして本質に迫る根気と,サブセットの善し悪しを判断するクライテリアを K は持っていた.

http://www.dodgson.org/omo/t/?date=20071103

誤解を恐れずに言えば、業務システムの開発において一番面白いのは実はここだ。

プログラミングとは、忠実に正確にまじめにシステムを動かすためのコードを書く作業ではない。

本当のプログラミングとは、コードの力を駆使して問題自体を解消してしまうような仕組みを創造するプロセスだ。その対象が身内なこともあれば、顧客なこともあるだろう。その意味で、「業務システム開発はクリエイティビティを発揮できない」なんていうのは、「私は無能です」と宣言しているようなものだ。

SIer を雇い入れてシステムを開発するときの根本的な誤りは、大人数のまじめで正確な作業をするコード書きを導入すれば問題の解決に結び付くと考えていることである。その場合の最もよい結果は、問題を自動的に処理し続ける大きなシステムができあがるというものだ。問題は残り、問題の処理を手伝うようなシステムが残る。問題のパターンに変化が生じるとシステムも変化を強いられ、根本的な解決は図られないままメンテナンスを続けるはめになる。しかも、大抵の場合、その構造に問題があることは誰一人として気付かない。

コードが世界を変えるのは何もあちらの業界だけではない。業務システムだって、アプローチが正しければコードの力で世界を（ビジネスを）変えることは可能だ。ただ、そのためには従来とは正反対のアプローチが必要になる。少人数の怠惰で優秀なプログラマを投入して問題自体を解決するような仕組みを作り上げる。問題は解消し、次に作るシステムは別の課題へ注力できる。

ここでも DRY の原則は有効だ。繰り返し同じ問題を扱うのは止めよう。あなたが（あるいはあなたの顧客が）年間で同じ作業を繰り返しているとしたら、それはきっと何かが間違っている。作業が発生する要因自体を叩いて、新しい問題に取り組もう。そのためにコードの力を使おう。

そして、そのために必要になるスキルセットは問題解決のための基礎的な分析力と解決策を考えるときの引き出しの数であり、人を巻き込んで味方を作っていく力であり、その仕組みを現実化するためのコードを書く力であると思う。

最後に、同じ文脈で過去におもしろいと思った文章を引用しておく。

で、自動化ができるかどうかにかかわらず、手順の確立 っていうのは大切だよっていう話。確立された手順って いうのは、みんなで共有できる知識なわけ。

もちろん、その知識をコード化するのが、自分らプログラマ にとって一番いいんだけど。でも、そうできないことも ある。そんなときは文章にするしかないんだな。だから、 手順を確立するっていうのは、その確立された手順を 文章にすることが含まれてるわけ。くどいようだけど、 文章よりコードのほうがいいんだけどね。

http://www.jitu.org/~tko/cgi-bin/bakagaiku.rb?bakaid=20071029

やがてくる未来ではソフトウェアの生態系がかわると私は信じている。その生態系を、ここでは 馴染系ソフトウェア (Situated Software) と呼ぶことにしよう。特定の場面や文脈のために設計されたソフトウェアのことだ。馴染系ソフトウェアを作る方法は、いわゆるウェブ学派(かつて私がプログラミングを勉強した場所)のやりかたとは対照的だ。ウェブ学派はスケーラビリティや汎用性、完全性を美徳としてきた。

私の生徒達はウェブ学派の流儀をあっけらかんと無視し、それでいて面白いものをつくっている。ここ一年ずっと、私はそれが気になって仕方がなかった。

馴染系ソフトウェア

K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものもある. 試行錯誤の中には, はじめうまくいかないように見えたものもある.でも調整を重ね次第に様になっていく. 気がつくといつも何かがよくなっている. 目の前の問題が次々と片付いていく感覚. K の前で開発は加速し, コードの質は上がり, 技術的困難は片付き, チームは進化していった.

http://www.dodgson.org/omo/t/?date=20071103

分野は違うけど、まぁ、こういうことだよな。

この夏キネ旬から刊行されたムック内の監督インタビューに以下のコメントがあってひどく共感しました。

「･･･（業界の）若い子はまず映画を観ない。映画も観なきゃ本も読まない人が大半です。それで、演出家だのシナリオライターになりたい、って、もう笑止千万ですよ。自分の引き出しの中身を増やしもしないで、『いつか羽ばたく日』を夢想しているんだから世話ないです（笑）。引き出しの中身は、それまで見てきた作品の数に素直に比例するから、数を観てないとまずアイディアを出せない。（中略）･･･情報がたくさんあったところで、必要な情報を選ぶ能力は養ってないし、どれが面白いかを選別する目が養われていない。目の前にある仕事が忙しいんだろうけど、せめて己の無能くらいは自覚してほしい人たちがたくさんいます（笑）」

http://d.hatena.ne.jp/kaoru1107/20071007

良いものはどんどん見た方がいい。悪いものも頭を使いながら見てみたら捨てたもんじゃない。本当にそう思います。