せっかくもらってきた子犬だが、諸般の事情のため、返すことになった。 夕べ夫婦でいろいろ話し合った末のことだ。
予想してなかったことだが、 結果として無責任に引き取ったと言われても仕方がないと思う。 残念だ。
子犬を一番かわいがっていた次女は、登校前に 大泣きしていた。私自身はかわいい次女を泣かせる結果になったことにショック。 一日落ち込んでいた。
元の飼い主は、いやな顔ひとつせず引き取ってくれたそうである。 「むしろ嬉しそうだった」とは引き渡した妻の弁。 向こうは寂しいと思っていたのだろうか。
子犬が座っていたタオルとかを見ると物悲しい。 本当に残念だ。
整数についてあつかった先月に引き続き、 今月は浮動小数点数について。
とはいえ、私の苦手どまんなかなので、 えらい苦労する。あらかじめテーマを決めていて 下調べをしていてこれだからなあ。
基本的に「What Every Computer Scientist Should Know About Floating-Point Arithmetic」をベースにしようと思っていたのだが、どうもそこまで到達できないかも。
ところで上記論文の日本語訳、以前は公開されてたと思ったけど、 今は見当たらないなあ。
プログラミング言語関係の特許というのはめったにないのだが、 これは珍しい例。
英語のクレームの読み方は良くわかんないんだけど、 要するに「空白を含む予約語を許す特許」のような気がする。
うーん、これってほんとに新規性があるの?
なお、これが提出しただけなのか、成立したのか、よくわかんなかった。
日経Linux用に資料探しをしていて行き当たったページ。
Francisco J. Santistive 氏の論文 "Robust Geometric Computation (RGC), State of the Art" は,幾何演算の分野における浮動小数点演算の安定性について扱っている。
http://citeseer.ist.psu.edu/santisteve99robust.html
この論文の導入部分において,浮動小数点演算の誤差が非常に深刻な事態を招いた例が,二件ほど紹介されている。
最初の例は, 1991 年の湾岸戦争での出来事だ。米軍の兵舎を狙って発射されたスカッドミサイルをパトリオットミサイルによって迎撃しようとしたところ失敗し,結果として 28 名の兵士の命が失われた。米国会計監査院 (GAO) の調査によれば,起動からの経過時間を計測する部分に演算誤差が混じっていたために迎撃に失敗したとされている。
もうひとつの例は, 1996 年に起こったアリアン5ロケットの事故だ。
http://www.around.com/ariane.html
http://www.cas.mcmaster.ca/~baber/TechnicalReports/Ariane5/Ariane5.htm
アリアン5ロケットは,欧州宇宙機構 (ESA) が10年近くの歳月と約70億ドルの費用を投入して開発した待望の商用ロケットだった。しかし,このロケットは離陸から1分も経たぬうちに,約5億ドル相当もの機器を積載したまま,爆発して塵屑と化してしまった。
記事によれば,事故の原因は,慣性基準装置 (IRS) 内にあるソフトウェアが,水平方向の速度値を 64 bit 倍精度浮動小数点から 16 bit 整数値へ変換していた(!)ことにあるとされている。この変換は離陸から約 30 秒後にオーバーフローを引き起こし,装置を停止させてしまった。慣性基準装置の停止はブースターの制御を失わせ,制御の破綻は機体の崩壊を引き起こし,最終的にはそれを検知した自爆装置が作動し,爆発という最悪の結末を迎えることになってしまった。
浮動小数点数、恐るべし。
B00097D8YO
中学生のお姉ちゃんたちは休日だというのに部活だということで、 残った息子と末娘を連れて実家へ。
実家の母は、妹がプレゼントしたという 『B00097D8YO』にはまっていた。
「やってみろ」とのことだったのでチャレンジ。 脳年齢判定では 最初は42歳、数回繰り返してようやっと36歳くらい。
トレーニングでは、いくつかのものでロケット級という判定を得たものの、 残りは総じて自転車級程度。かなり脳が硬化しているらしい。 LLなんか作ってて、楽をすることにかまけているからだろうか。
確かに楽をするために人一倍努力していることは認めるが。
まあ、周囲からどう見られているかどうかはわからないが、 私の教会でも
のようなIT化が進んでいる。決して最先端というわけではないけど、 まあ、それなりにテクノロジーをキャッチアップしているということで。
どうやらRastインデックスデータベースが壊れたようで、 メールのインデックス作業が時々刺さるようになった。 こうなると当該プロセスをkillするしかないので、 なかなか具合が悪い。しょうがないので 意を決してRastインデックスを再生成することにする。 インデックス生成が遅いのがRastの欠点の一つなので なかなか躊躇していたのだが、こうなればしょうがない。 GWの休みを利用してやってしまうことにする。
数えたらメールは17万通ほどあった。 さて、何時間かかるか。
B000EPFDMQ
中学生は今日も午前中は部活。
午後は『B000EPFDMQ』を 家族で鑑賞する。吹き替え派と字幕派で対立があったりもしたが、 そこはそれ、妥協して。
楽しかった。長い原作をよく刈り込んでいる。 あまり破綻もしていないようだ。 末娘がぐずるので最後までは見れなかったんだけど。
後で見返さないとな。
中高生の時に「オイラーの等式」で感動したスタッフが過半数を超えていない会社は「Web2.0企業」とは言えないルールってのはどうよ?
まぁ数学が苦手だと自称しているRubyの開発者でも、おそらく中高生の時に感動したのではないかと想像。
数学苦手を甘く見てはいけない。
私がオイラーの等式を最初に見たのは 大学3年のとき石塚さんの『オブジェクト指向入門』の脚注でだったし、 その時だって「ふーん」ていどで感動はしていない。
いや、すいません、自慢しているようで、 結局、自分の馬鹿をさらしてるだけですね。
完了。なんとまる1日半かかった。 大量文章への適用にはもう一桁は早いといいなあ。
珍しく中学生の部活もなく、 みんなで出掛ける。
堀川遊覧というのは、松江城のお堀になっている川を 船でめぐるというもの。かなり街中だし、堀川ってそんなにきれいな川じゃないし、 と思って、いままでずいぶん長く松江に居るのに乗ったことはなかったけど、 「今年のGWは少しは観光らしいことをしよう」との目標を達成すべく 挑戦してみた。
結果としては、予想外によかった。思ったよりも景色もよかったし、 愛想のない船頭さんも、それが逆によかったり。
また、歴史情緒のある町並みも車に乗って通り過ぎるのとはまた違う視点で感じられた。これはお薦め。1周約45分。
ところで、乗るときに認証されなかったけど、これってチケット買ったら、1日乗り放題なのかなあ。
ゴールデンウィークも事実上終わり。 っていうか、たいした活動もしていないのにすっかりくたびれてしまって 今日はお休み。お昼寝したり。
ほんとは原稿のことがだいぶ気になるんだけど。
夕食後、家族でBookOffへ。 いろいろと見て回るが、結局だれも何も買わずに帰る。 子供たちもそれなりに楽しんだようなので、まあ、いいか。
先日、友人が遊びに来たときに紙の上に数字を並べて遊んだのが好評だったのだが、 目で判別するのが面倒だったので、Rubyスクリプトを作る。 ついでに1から10までの任意の桁数で遊べるように。 30分ほどで完成。60行。
すると、息子が「ぼくもそれ使いたい」と言う。 が、WindowsでRubyスクリプトをワンクリックで起動する方法が分からず。 というか、Cygwinターミナル以外からWindowsでRuby動かしたことってないよな。 結局、そこでつまずいてしまった。
Windowsは難しすぎて使えない。
私がUnix系に過剰適応してるだけだけど。
司会。
一人の人の証が印象的であった。 最近バプテスマを受けたこの人は 「私は教義よりもむしろ教会の人の人となりを見て教会に入りました。 聖書についてはこれから勉強します」とのこと。
それって、すごく嬉しいことだが、同時にちょっと恐いことでもある。 私たちの行いが教会やキリスト教を代表していることになるからだ。
夕方、次女がふらふらになっている。 そんなにしんどいなら断食しなくてもいいよ、と言ったのだが、 一度決めたから、と聞かない。
決意が堅いのは尊敬に値するけど、 そんなに無理をすることも無いような気もする。 あと、半日でそんなにふらふらになるようでは 本当に飢餓が来たらどうなるんだろうか。
(追記) 元々この「にっき」では教義的な話をしないつもりでいたのですが、コメントでは質問されるままにかなり難しい話を書いてしまいました。しかも、私の至らなさで前提を共有しない人にはかえって混乱を招いたり、誤解を増長したりする返答になってしまったようです。不愉快に感じた方がいらっしゃればおわびします。コメント欄は削除することにします。 以後、教義的な点について話したい、指摘したい、などの人がいれば、コメント欄ではなく私信でお願いします。
講習会はサラリーマンコスプレ、という話であったが、 正直くたびれたスーツしか持ってない。 毎日曜日、教会にはスーツを着ていくのだが、 そのまま子供の世話したりするので、 けっこう汚れたり傷んだりしてるのだ。
というわけで、スーツを買おうかなあ、と思っていたのだが、 なかなか時間が取れず、とうとう出発日になってしまった。
で、スーツ購入。なんだか泥縄で恥ずかしい気がする。
その後、東京へ移動。 くたびれたのでそのままホテルに移動。原稿を書く。
昼食時に妻に「夕食は吉野家の牛丼でしょう」と言われた。 今は吉野家、牛丼出してない、ということは置いといて、 そういうチープな食事が好きだということを見ぬかれている。
で、結局実際の食事はどうなったかというと、 コンビニのおむすびでした。もっとチープだ。
手作り感あふれるロボガレージのロボット。
高橋さんのロボットは「人間が感情移入できるツボを全部押さえていきたい」という。「ツボの数は動かないものよりもさらに多いだろうけど、それを押さえていったら、完璧に普及するんじゃないかな」
この「ツボを全部押さえたい」という感覚は言語設計にもつながる気がする。 プログラミングが楽だと感じる「ツボ」はたくさんあって、 それを全部押さえていきたいと思ってる。
数値化できないし、なかなか難しいんだけど。
10時から発売して、11時半までには全部売り切れたとか。 「買えなかった」という人、多数。
売りに出したのはあまり多くなかったはずだから、なかなか入手しにくかったのだろう。 机の数を減らしたり、人の密度を高めて、追加発売について検討中。
また、これで予約した人でも1週間以内に購入しなかった場合には また販売に回されるから、1週間後(16日)が狙い目。
「%w(Complex Number).reverse」というエントリにおいて、弾さんに指摘された。
(数学苦手)という割には、BignumをNativeにサポートしていたりするのだから面白い。
RubyがBignumをサポートしている最大の理由は ioctl用の定数が32bit目がonになっているものがあるため、 31bit Fixnumでは表現できなかったことである。 数学は全然関係ない。
このためだけに、えらい苦労してBignumを実装したわけだが、 完全に手段と目的をはき違えてる気がする。
ゆうぞうさん講師により淡々と進む。
RadRailsかっこいい。 IDE好きな人がいるのも分かる気がする。
事前に漠然と想像していたのとは違う進み方をしたり、 今後に向けてテキストを若干修正した方が良いと感じるところもあった。 しかし、心配していたほど進度の違いによるトラブルは起きなかった。 先に進んだ人も、AWDwRを読んだり、いろいろ手元で試したりしてたみたい。
講習会会場に戻り、懇親会へ。
いろいろな人がいて楽しい。 講習会における懇親会は心の壁を薄くするのに役立つので 効果的だったように思う。
当所最終日に行おうという話だったが、 最終日終わったら帰りたい人もいるだろうと2日目夜に変更した。 でも、今考えると、お互いによく知り合った方が学習効果が高くなりそうだし、 初日の夜のほうがよかったかなあ。次回はそのように提案しよう。
Martin Fowlerによる「仕事にRubyってどうよ」という話。 bliki_jaによる和訳あり
言語として好き、趣味のプログラミングにRuby、ってのはもう珍しい話ではなくなったが、 じゃあ、仕事にも使おうというのは、新し物好きのアメリカでも障害はある。 で、最近のトレンドでRubyを改めて評価してみると...。
MartinがRubyファンであることを割り引いても、一読の価値はあると思う。
ビジネスユーザとコミュニティをサポートでつなごうという試み。
うまく行くといいなあ。 「なんとかExchange」とか、軌道に乗らなかった試みは多いから。 結局、今まではコミュニティをドライブする力に欠けたんだと思うんだよね。 コミュニティの求心力とか、コネクションの強さとかに関係するんだろうか。
にいるのだが、実際は内職で原稿を書いている。
やっぱ浮動小数点数なんてテーマを選ぶんじゃなかったなあ、
と公開後悔することしきり。なんか、さんざん苦労して書いたあげく
読者から「間違ってます」なんて指摘を受けるんじゃないかと。
一番苦労するのは、誤差の実例で、 教科書的な例題だとfloatを使って誤差を出しているんだけど、 RubyのFloatは内部的にはdoubleを使っているので
と悩ましい限りだ。
ま、良い例題が見つかってしまえば後は楽ってのは原稿書きの常だけど。 で、いつもうまくいっているわけではないというのが、悩ましい*1。
*1 「いつもうまくいっているわけではない」が「いつもうまくいっていない」か「いつもうまくいっている、というわけではない」のいずれであるかが大問題なのだが....聞かないで。
localeの問題で自前で実装を準備したstrtod(3)だが*1、どうも精度が悪いらしい。プラットフォームによっては有効数字が16桁出ないでmake testでエラーが出るようだ。本来は10進18桁近くあるはずなのにな。
試してみると、その辺に転がっているフリーのstrtod(3)実装は軒並み精度がその程度しかない。見るとPythonは内部でシステムのatod(3)を使っている。Perlは自前みたいだけど、あいかわらずソースが読めない(Perlの場合は、VMSなどIEEE754でないシステムにも対応していてifdefが多いせいでもある)。
で、結局、数値を下9桁とそれ以上とに分割し、それらを独立に計算した後、 最後に加算することで精度を確保した。加算で発生した誤差が拡大するから、 加算→乗算、ではなく、乗算→加算の順序で計算しなければならないのだった。
付け焼き刃だが、勉強になった。
*1 localeによっては小数点がカンマだったりするので
体調が悪いので早く休もう、と思っていたのに、寝たのは3時くらいだった。 どうしてこう一人では生活が管理できないのか。
ちょうど東京にいるから、ということでTech総研から取材を受けるためにリクルートへ。
で、うっかり、新橋で降りるべきところを銀座で降りてしまい、 一駅分歩く。かばんが重い。交番で地図を見ならが「遠いなあ」とつぶやいたら、 横にいたおじさんが「若いんだから、歩く歩くっ」ですって。
もう、そんなに若くないんですけど。童顔だけど。
で、取材。先日調べていたChasmの話とかも含めて、なんかぐだぐだとしゃべったけど、 記者のヒトがうまくまとめてくれるのかなあ。 カメラマンに写真を撮ってもらうという経験が恥ずかしい。 掲載は6月末だとか。
Tech総研とはTech Bingの後継のWebマガジンだそうだ。 いつの間にかTech Bingなくなってたんだねえ。 そういえば以前に聞いたことがあったような(すっかり忘れている)。
応募次第などについて。とっくに決まっているはずだったんだけど、 ちょっと作業が遅れているみたい。でも、まあ、重大な問題もなく進みそうだ。
後はどれだけの人が応募してくれるかだ。
我々は君の応募を待っている。 と、よしおかさんも言っている。
今回は上野の某ホテルに4泊したのだが、
なんとかならないものだろうか。ならないかな。
娘の自転車がパンクしたということで、 ずいぶん久しぶりにパンク修理をした。 ゴム糊がぜんぶ揮発していて新しいのを購入する必要があったり、 トラブルもあったが無事修理。
しかし、最初チューブを出して全部水につけても穴を発見できず、 かなりあせった。虫ゴムなどが悪いのかと思ったが、 そこも異状はないようだ。
ふと思って、空気を強めに入れたらはじめて空気がもれだしてきた。 試しに入れた弱い圧力では穴がふさがっていたらしい。
これから得られる教訓は「ストレステストのストレスは十分に」か。
ちなみにエントリタイトルはブラックジャックの『弁があった』から。 Dr.キリコのお父さんが出てくる回ね。
ラベリングの話。
「Digital Rights Management」というと「私の権利」が守られるような印象があるが、 実際に守られるのは「コンテンツホルダの権利」であって、 私の権利はむしろ制限される。
これはよくあることで、「活用」と「利用」とか、「希少」と「異常」とか、 「普通」と「凡庸」とか、 言い換えるだけでえらい印象の変わる言葉はいくつもある。 安易なラベリングには気をつけよう。
詭弁のガイドラインに含めるべきだな。
さりげなくポジティブなイメージの言葉を使う。
「権利」と「保護」というポジティブな言葉を組み合わせる(誰の「権利」か明示しない)ことで、 ユーザから権利を奪うことを目立たせなくする。
さりげなくネガティブなイメージのある言葉を使う。
「普通でない」を「異常」と呼び、 「異常だから悪い」と展開する。
今日は車二台で教会に来たため、 妻子は早くに帰ってしまう。 残された私は打ち合わせとかをしてたら ずいぶん遅くなってしまった。
出張やら家族の体調不良やらでずっと打ち合わせが出来てなかったからね。
疲れた。
帰ろうと思ったら、若い人たちが黒板に漢字を書いて読みを当てる遊びをしていた。 漢字検定に挑戦した高校生がいるとかで(何級か聞き忘れた)、 難しい漢字が頻出してた。
「向日葵」とかならともかく、 「仙人掌」とか「女郎花」とか読めないよ。 あと、「蛭」は読めたけど、「孑孑」は忘れてた。
「ハッカーズライフ」は、キャズムについて書こうと思っていたのだが、 どうもストーリー的に流れが自然でない。ので、泣く泣くキャズムの話は削り、 オープンソースのマーケティングという話をすることにした。
昔はマーケティングって大嫌いだったんだがなあ。 こんな記事を書く日が来るとは。
キャズムについては来月にでも書こう。
『Programming Ruby』翻訳第2版の原稿チェック。
意外とたくさんチェックする項目があるものだ。 っていうか、第1版と違って(英語の)第2版はほとんど私は手を入れてないからな。 原書の間違いも結構残っているような気がする。
日本語版はより正確になっていると思う。
まだまだ作業は残っている。
「メインストリームになってうれしいの?」というのは、 「Ruby(Rails)もっと普及させなきゃ」という助言に対する私からの標準的な返答なのだが、 そのDHH版。基本的に同感。
彼のストレートな性格ってうらやましく思えるときもある。
やっと応募要領が確定。特に審査基準の明文化が大きい。
が、じゃあ客観的かというと難しくて、 過去の経緯からだとやはりインパクトが重視されちゃうよなあ。 昨年も言語処理系が応募されて、私は応援したんだけど、 インパクトと独自性に弱くて大賞には届かなかった。
言語は地味だからなあ。「この言語でしかできないなんてことはほとんどないし、 その割にデザインは難しいし。 「なでしこ」みたいな別にインパクトという手もあるけど。
結局は周辺ツールも含めたインパクトということなんだろうなあ。 でも、言語好きは、正直、周辺ツールなんて興味ないんだけど。
W-Zero3をやや大きくしたようなXPマシン。 すごい魅力的だけど、Linuxでは使えないだろうなあ。
羽生社長のプレゼン。技術者流動化論者の私としては、 我が意を得たり、という内容。
それはそうと、 羽生社長って、なんていうか、...近くにいるとすごい「圧力」を感じる人だよね。 人間の持つキャパシティの問題なんだろうか。
鳥取県の片山知事がおっしゃったとか。
実は山陰両県は明治時代には合併されていた(その時の名称は「島根県」)、 が、冷静に考えると鳥取県の東側と島根県の西側とじゃ 現在でも移動にゆうに5時間はかかる(最短で)。合併が長続きしなかったのも無理はない。
かなりバーチャルな行政にでもしないと、 現実的ではないだろう。
それは最近よく言われている道州制でも同じことだが。
週刊コミックモーニングの読み切り42ページ。
2700万年におよぶ歴史を描くSFマンガ。ひさびさに歯ごたえのあるマンガを見たような気がする。 思わずモーニング買っちゃったよ、何年ぶりだろう。
しかし、この作者のboichiって人、 意外とあちこちに書いているのね。絵柄がいろいろなので識別できてなかったよ。 最近、作者名とか頭に入らないので画風だけで認識してるもんなあ。
先日、とあることで千葉先生とメールのやりとりをしていたら
海外のアスペクト指向コミュニティで「Rubyはアスペクト指向を取り込まないのか」という話が出ている。「Matzはアスペクト指向が好きでないのか」と。
と聞いたのだそうだ。
4774125814
いや、別にアスペクト指向が嫌いなわけではないけど、 CLOSのようなメソッドコンビネーションはともかく、 かなりの部分はアプリケーションドメインの機能のように思います、提案歓迎、 というように返答しておいた。
「それはそれとして、千葉先生の本でも読んで勉強しておきます」と言ったら、 「では、贈りましょう」ということで、今日届いたのだった。 もともと買うつもりだったので、ちょっとラッキー。
で、読む。やはりアプリケーションドメイン機能が言語に入り込んできている印象はぬぐえない。 もうちょっと整理すると、アプリケーションドメイン機能を実装するのに 必要十分な機能が抽出できるような気がする。
でも、それって単なるメタオブジェクトプロトコルじゃないかという気もするな。
朝から某ベンチャーファンドのファンドマネージャの人とSkypeで話をする。 カリフォルニアは夕方頃かな。
で、この人がえらいRubyに乗り気で、かえってこっちが身構えてしまう。 私ってばビジネス向きじゃないし、もうかりそうな絵も書けないんだけど、 「自覚している点」がますます評価が高かったらしい。
うーむ。
いずれにせよ、業界の内側の話とか、普段聞けないような話も聞けて (私にとっては)大変有意義な話であった。
「今後ともよろしく」で終わった1時間強であった。
その後はメールインタビュー用の原稿書き。
オープンソース・ネタだそうだが、 Rubyとか「オープンソース」という言葉が存在する前から 開発しているから表現が難しい。 結局、ほとんどフリーソフトウェアという表現で乗り切ってしまった。
まあ、先方には満足していただけたようだ。
妻が美容院に行きたいというので、 子守りをすることになる。 まあ、これまでも子育てに関ってきたわけだし、 すでに3人(以上)の赤ん坊を見て来た以上、 とりあえずなんでもできる、はず、なのだが、 半日面倒を見たらぐったり疲れてしまった。
理由は以下のいずれか(あるいは全部)だろう
すぐ近所で4月からずっとやっているのだが、なかなかゆっくり見る機会はなかったので、 家族を引き連れて。娘たちは中間試験の勉強があるとか言ってたのだが、 「息抜きも必要」だとかでついてきた。
うーん、なかなかおもしろい。 これがアートというのもなんだろうか。
引っ越した人とか、引っ越す人とかがいるため、 補助組織の会長会が入れ換え。 で、かなり規模が大きくなったので、 あっちの人にこれをお願いして、 こっちの人にあれをお願いしてと、 根回しに1ヶ月以上かかった。
今日で好評になったので一段落...というわけにはいかないが、 少し気が楽になったのは本当だ。
組織運営が面倒なのは会社組織でも、任意団体でも、宗教団体でも変わらないような気がする。
えーと、オープンソース時代の宗教について。
いや、宗教が人間の内面を扱うものである以上、 その運営が時代を反映するのはある意味当然なんだけど、 ここまであけすけに「オープンソース」を取り込んでくる宗教があるとは、 新興宗教の世界は奥が深い。
一昔前ならこういうのは日本から出てきそうな気がしてたんだけど、 「オウム」以降は宗教はもっぱら評判悪いからねえ。 「宗教である」というだけで「カルト呼ばわり」されちゃうし。
Java 5.0に追加されたcompare-and-setによってノンブロッキングデータ構造を実現する話。
compare-and-setが標準的に手に入るってのはいいなあ。 これってポータブルには実装できないものの代表格だものなあ。
という話をしていたら、(会社説明会の面接で松江にきていた)おごちゃんに、 ある程度ポータブルなものならあるはずだよ、とか聞かされる。 だが、彼はそれ以上のポインターを持っていなかった。 検索しても引っかかないんだよなあ。
これがあれば、Rubyもスレッドセーフにできるかもしれないのに。
情報希望。
ある程度名前が「売れてしまった」せいか、最近、仕事の依頼が多い。
まあ、「原稿書いてください」くらいなら、分量がたいしたことなければ ほいほい受けてしまうのだが、なかには躊躇するものもある。
たとえば、O'Reilly Networkから来た以下のようなもの。
200行くらいのプログラムをサカナに「コードの美しさ」について語ってください。 2000ワードくらい(もちろん英語で)。
ここまでなら、どうということはない。しかし、次の部分を読んで驚愕した。
他にも何人かに頼んでいます。 すでに引き受けてくださった人にはBrian Kernighan, Guy Steele, Diomidis Spinellisなどがいます。あなたも引き受けてくださるとありがたいのですが
えーと、こんな有名人の中でなにをしろ、と。
日経Linux 7月号初校を校正。 今回は39行もオーバーしたので削るのに奔走する。 しかし、いつもながら、日経の編集の人はプロの仕事をするなあ。
「カズオ」ってのは数独のことなんだね。 数独についてはRubyQuizのネタにもなっていて、 少し知ってはいたんだけど、こんなに注目されていると走らなかった。
で、ルールは知ってても遊んだことはなかったので、実際にやってみる。 ksudokuをインストールして遊んでみると....これは面白いわ。 あっという間に時間が過ぎてしまう。
Ruby2では、引数リストについて修正を加えようと思う。
具体的な変更点は以下の通り。
つまり、
def foo(a,b=1,*c,d) p [a,b,c,d] end a1=[9,8,7] a2=[6,5,4] foo(1,2,*a1,3,*a4,5) # => [1,2,[9,8,7,3,6,5,4],5]
という感じ。
ただ、問題が二つ。
取り掛かる前には「やればすぐ」と思ったのだが、 特にyaccが難物で、全然進まない。
今年もGoogle Summer of Codeの季節がやってきた。 で、タイトルの記事は「単なるバラマキではないか」という批判。
まあ、それはそれで当たっていないとは言えないが、 ばらまいているのは私企業Googleのお金であり、税金ではないので ばらまかないよりはばらまいた方が良い。その上でより有効に活用する方向で考えていきたい。 生存率を高める方法とかね。
今年はRubyCentral Inc.もメンターに参加している。 当選者リストは[ruby-talk:194367]。
Alexander Stephen Bradbury: Automated Wrapper Generation for Information Extraction
Mentor: Austin ZieglerGregory Brown: Ruby Reports
Mentor: David PollakKevin Clark: mkmf for Rake
Mentor: Caleb TennisRobert Figueiredo: A Ruby Rule-based toolkit
Mentor: Kirk HainesBenjamin Gorlick: Improved style and extendable interactive documentation system for Ruby and Rails
Mentor: James Edward Gray IIFlorian Gross: ruby-breakpoint GUI client
Mentor: Patrick HurleyIlmari Heikkinen: Pure-Ruby OpenGL GUI widget system
Mentor: Ryan LeavengoodJeffrey Hughes: Port Ruby to Symbian OS
Mentor: Dibya PrakashJason Morrison: Code Completion with Type Inference for Ruby Development Tools project
Mentor: Christopher WilliamsGabriele Renzi: New Administration subsystem for nitro
Mentor: Bryan Soto
どのくらいがものになるのか、楽しみである。Symbian OSとか「本当にできるのか」って感じだけど、もしかしたら、と思わせてくれる。
えーと、なんというか。
ソースコードの公開と脆弱性には関係がないし、 どちらかというと「オープンソース化して見つけてもらえて良かったね」というような気がする。
しかし、それよりなにより、「中小だから」と開き直ったように取れる態度はいかがなものか。
なぜこのような程度の脆弱性の対応ができていないのかと思われた読者もおられるだろう。だが、これが中小企業の実態なのではないだろうか。今回のような脆弱性といった問題は、大企業であれば事前に講習などを行い準備することも可能だろう。だが当社のような中小企業では、脆弱性について勉強する時間もお金もないのが現状なのである。
これが本心からなのかどうだかは知らないが、 下手な言い訳は、しない方が好感が持てる。
ところで、この「ながさきITモデル」(特許申請中?)だが、 CIOが全体設計を行い システムを小分けにして中小に発注することが肝になっているように思えるが、 これって設計者がよっぽどえらい人でないとDRY原則に反したシステムしかできないような。
また、「オープンソース」と言いながらCurlに依存してしまうところも あまりうれしくない。
まあ、Curlの選択については設計者のポリシーなのだろうから、 こちらが口出しできることではないのだが、 DRY原則の適用をいかにするのか、また、設計者の力量に大きく依存してしまう「モデル」を いかに昇華させていくのかが今後の課題のような気がする。
Rubyによる高速WebサーバーMogrelの開発者、Zed Shaw へのインタビュー。
個人的に一番感銘を受けたのは、実はインタビュアーであるPat Eylerの経歴
Pat Eyler is an Infrastructure Engineer for the LDS Church by profession, a Ruby geek by choice, and a writer by night. He enjoys reading, cooking, spending time with his family, and helping to build the Ruby community.
同じ教会の人だとは知ってたけど、フルタイムで教会職員をしているとは知らなかった。 実は、教会公式サイトでもRubyが動いていたりして。
さて、第三者にはどうでもいい話は置いといて、 インタビューを読むと彼が速度と信頼性についてきちんと考えていることがわかる。 ちゃんと測定、ちゃんとテスト。これにまさるツールはない。
いや、老後のことを考えると子供がいて、 その子が面倒を見てくれるというのが理想ではあるが、 それを理由に結婚したり出産する人はあまりいないような気がする。
それを考えると、この文章の説得力が急に下がる気がするのはなぜだろうか。
いや、子供はかわいいけどね。
RubyGemsの原作者(というか発案者)でもあるRyan Leavengoodがまとめた Google Summer of Codeに(Ruby関連で)参加する人へのアドバイス。
他の応募(未踏とか)でもある程度あてはまりそう。
えーと、結局どっちになるんだろう。傍観者にはよく分からない。
しかし、もし、ヨーロッパがソフトウェア特許を認めない方向になったとすると、 ヨーロッパ諸国は、近い将来「オープンソース開発のメッカ」になる可能性はあるな。
もともとオープンソースに熱心な人は多いし、 英語が障害にならない人が多いみたいだし、 これでソフトウェア特許を心配せずに開発できるとなれば、 わざわざヨーロッパに引っ越して開発するという人も出てくるような気がする。
話に聞くとアメリカからヨーロッパへの引っ越しってのは、 それなりにあるようだし。
あと「メッカ」になりそうな土地としては南アメリカがある。 あそこもオープンソースに熱心な土地柄らしい。 一回行ってみたい気がするなあ。
遠いけど。
PicasaのLinux版が出た、という話題。
Windows版は妻のPCで使っているが、 結局はEXIF情報を参照して日付ごとにディレクトリに自動分類するスクリプトの方が使い勝手がいいという。ソース手に入らないし。
ただ、それだと日付以外の分類ができないので、
とかがあれば、ひっくり返りそう。 以前、KinbadaとかいうKDEプログラムがあって結構頑張ってたんだけど、 debianパッケージが提供されなくなって使わなくなっちゃった。
Picasaはソース公開されていないが、 Linux版はWineを使って動作しているようで、 Wineそのものにかなり手を入れて、かつその修正は本家に還元されたらしい。
そのような貢献は望ましいことだと思う。
Wikiはノイズが多いし、役に立たない、という話題。
そういう側面があることは認めないでもないけど、 それってば否定的な面の見過ぎじゃないかなあ。
たとえば、
だと、メリットがデメリットを上回るような気がする。 やっぱり集団の力を少しずつ集めることができるシステムは強いと思う。
元気玉とか。
集まる。食べ物も集まる。こんなに食べ物の豊富なポットラックは見たことないかも。
ワード評議会なのでいつもより早い時間に教会へ。 子供たちは末娘の子守りをしてくれた。助かるなあ。
日曜学校。今週は私が代理教師。日曜学校の教師なんて久しぶり。 範囲は「ヨシュア記」。旧約聖書は文化的な隔絶が大きいのもあって みんなあんまり知らないところだ。 私自身も勉強になった。
とはいうものの、あまり準備する時間が取れず、 時間配分もあまりうまくいかなかったように思っているのに、 教師の人たちから「よかったです」と言われると、 嬉しいような、不本意なような。
教会から帰った午後、子供の自転車の練習につきあう。 やっと乗れるようになったらしい。
歴史的に見るとyieldを使うのが先にあって、&block (ブロック引数)でオブジェクトとして受けとり、callメソッドで呼び出すのが後から登場している。 記法的に考えると後者の方が優れている(現在の実装では、効率は前者の方が少しだけ良い)。
しかし、ブロック引数を使うとエラーの出力が良くないのが欠点である。 つまり、
def foo1 yield end def foo2(&block) block.call end foo1 # => in `foo1': no block given (LocalJumpError) foo2 # => in `foo2': undefined method `call' for nil:NilClass (NoMethodError)
どちらもエラーには違いないが、メッセージが直接的に意味するところを考えると 前者の方が優れている。
で、1.9ではこうしようかなと考えている
すると、こうなる。
def foo1 yield end def foo2(&block) block.yield end foo1 # => in `foo1': no block given (LocalJumpError) foo2 # => in `nil.yield': no block given (LocalJumpError)
「foo2」が表示されないのが惜しいが、まあ、だいぶマシになったのではないだろうか。
ガーベージコレクションの大統一理論。 だいぶ古い論文(2004)だが、最近改めて読み直したので。
一方にルートから生きているオブジェクトをトレースするtracing gcがあり、 他方に参照数を数えることにより、死んだオブジェクトを発見するrefernce counting gcがある。この二者は「物質」と「反物質」のように相対する関係であり、 片方を改善するテクニックには、かならずそれに対応する他方を改善するテクニックが存在する。結局は組み合わせにすぎない、という理論。
将来、誰も知らなかったようなGC手法が登場する可能性は低いことを示しているが、 逆に状況に最適なテクニックのセットを発見するための、理論的な背景にもなるので 非常に有用のような気がする。
左側の一番奥の歯(親知らずは抜いているので、その手前)が ときどき痛むので歯医者に。本当は医者や歯医者のたぐいは好きではないのだが、 歯は自然に直らないので(いや、厳密には再石灰化とかあるけど)、あきらめて。
レントゲンを取ってもらった結果
のだそうだ。うーん、歯磨きはそれなりに頑張ってたつもりなんだが。
で、金属をはがすのにえらい苦労した。 また、はがした後は簡単な詰め物があるだけなので、 食事の際にしくしく痛む。今まではときどき痛むだけだったのになあ。 薮をつついちゃったなあ。
えーと、これはどこのファッション雑誌なんでしょう。
DHHカッコつけすぎ。あるいはカッコよすぎ。
ま、表紙についてはおいとくとしても、 Linux JournalでこのようにRubyが大々的に扱ってもらえるというのは Railsのおかげに違いない。 私にとってもありがたいことだが、 動的言語への世間の理解が進んだということでもあるので、 プログラミング言語の世界全体への貢献であるともいえないことはない。
正直なところ、脆弱性対応ってのは面倒なことが多い。
XSSみたいに比較的簡単なものはすぐに直せばそれで終わりだけれど、 DoS(Denial of Service)のようなものは、
などを考え出すと大変めんどくさい。 しかも、Rubyのようなプログラミングの下のレイヤーのツールへの脆弱性レポートってそんなのばっかりなんだよな。まあ、一番多いのは$SAFE=4によるサンドボックスに対するものだけど。 そのたびに「こんなの作るんじゃなかった」と思ってしまう。
で、JPCERT/CCの仕事に否定的というわけではないのだけど、 「発見してくれてありがとう」、「でも、面倒を増やしてくれて本音では嬉しくない」というのが、開発者としての偽らざる気持ちである。FSIJが協力することで、この辺の「開発者のジレンマ」をすくいあげてくれるようになったら、いいなあ。無理かなあ。
実引数リストに複数のsplat演算子を置く修正を実装。 NODE_ARGSCATをネストさせることでパーサーの修正のみで完了した。