_ OSC2008-do

OSC2008-do に参加してきたので、感想。*1

今回は日本Rubyの会の高橋会長もかけつけてくれた。

動的言語をフレームワークへ ― マイクロソフト 荒井 省三さん

.NET DLR の話。

プレゼンマシンが MacBookPro だったので 「お！」と思ったが、OS は Windows Vista だった。 そりゃそーだよね、、、

DLR は言語を作るための基盤。現在、 IronPython と IronRuby と JavaScript のプロジェクトが進行中。

IronRuby はつい先日 Rails が動くようになったらしい。

あと、JavaScript で定義した関数を、Python から呼び出す なんてこともできるらしい。 まぁ、この辺は Java で定義したメソッドを JRuby から呼ぶ ってのと似てるな。

Ruby勉強会@札幌 特別編 ― 島田 浩二さん/設楽 洋爾さん

まぁ、内輪ネタなので割愛w

とにかく RubyKaigi と jpmobile は素晴らしいの一言に尽きる。

異端のWebフレームワークSeaside ― 梅澤真史さん

個人的には本日のメインイベントその1。 前々からずーっと生で見てみたかった Seaside をやっと 見られた。

一応、WebObjects の経験があるので、継続渡しとかは 全く驚かなかったけど、 Web ブラウザ上で コンポーネント名を表示して、Webブラウザ上で CSS の設定をしたり、Web ブラウザ上でクラスブラウザを 表示したり、ソースコードを表示したり、ソースコードは 表示するだけじゃなくWebブラウザ上で編集して それがすぐにアプリに 反映されたり(デプロイのし直しとかアプリの再起動とか 一切不要)、エラーが起きたら Web ブラウザ内にスタック トレースが表示され(ここまではフツー)、そこから Squeak のデバッガを起動してすぐにデバッグできたりとかは あまりにすごすぎてかなりポカーンとしてしまった。 (でも、これに似たようなのを昔 WebObjects + Groovy で 鈴木さんがやっていたというのを風の噂に聞いたけど、 どの程度 Seaside に近いものができていたのだろう)(追記：鈴木さんから光速でコメント頂いた。ありがとうございます、鈴木さん。EOInspectorか )

いやー、これはすごいね。本当に見られて良かった。 梅澤さんに大感謝。

あと、オブジェクトの広場で7月から Seaside の連載が 始まるってことで、めちゃめちゃ楽しみ。長期連載にして欲しい。

ネットワークの自由、その現状とこれから ー MIAU 津田 大介さん

インターネット界隈での著作権とか言論の自由とか 言論が自由とはいえ、不必要な誹謗中傷や有害な情報から ユーザーを守る仕組みとか についての事件や法律の歴史、そして、今後どんな活動を していくべきか。

優れた技術がおかしな理論やおかしな法律によって つぶされてしまうことがあるので、 技術者はこういった法律や世論などにも関心を持つべき。

GCC Hacks ー 若槻俊宏さん

個人的メインイベントその2。

GCC のフロントエンドのソースってのは、 Ruby のソースコードとちょっと似ていて非常に面白かった。 例えば、C で思いっきりオブジェクト指向しているところとか、 「関数を定義するための関数」なんてものがあったりとか。

後、中身の思想は思いっきり LISP なのも面白い。

普段なかなか触れる機会がない(触れようと思えない)GCCを こんなに解説してくれて本当に感謝！すごく面白かった。

かなりマニアックな内容なのに、ものすごいいっぱいの 聴講者が来ててしかもみなさんずっと熱心に聞いているように 見えたのだけど、この人達はいったいどういう層なんだろう(^^; ってのが若干疑問だった。

懇親会＠アサヒビール園

肉うまかった。

梅澤さんとお話できて嬉しかった。

二次会＠坐わたみ

sumim さんや高橋会長からいつものように面白い話を いっぱい聞かせてもらって超楽しかった。

_ amazonplot.rb の ECS4 対応パッチ

Amazon ECS3 が3月いっぱいでサービス廃止になり、 ECS4しか使えなくなったので、 amazonplot.rb (mingplot) を ECS4 に 対応させてみた。

amazonplot_ecs4.patch

っていうか、ググっても「使えなくなったー」という声を 全然見つけられないのだけど、もしかして使ってるの俺だけ？(^_^;)

使い方

Amazonの「トークン」はECS4では廃止になり、代わりに 「Access Key Id」というものが必要になりました。

なので、 --token には TOKEN ではなく、 AccessKeyID を指定してください。

% amazonplot --token=AMAZONTOKEN -o /home/yourname/survey 12345678
　↓
% amazonplot --token=AccessKeyId -o /home/yourname/survey 12345678

感想

REXMLでXpathというのを真剣に使ったのは初めてかもしれん。

"Offers/Offer[Merchant/Name/text()='Amazon.co.jp']/OfferListing/Price/Amount"

で、Merchant/Nameの中身が'Amazon.co.jp'に一致する Offer の /OfferListing/Price/Amount を取得、とか。

Xpathって結構複雑なことできるのね〜。

_ 大学新入生に超おすすめ 日本人の英語 (岩波新書)

日本人の英語 (岩波新書)

この本は素晴らしい。マークピーターセンさんが、 長年日本で暮らし日本人が書いた英語の添削などをするなかで、 日本人の英語にありがちな間違いを指摘してくれる本。 (一部、「ほんとかな〜？」と信じられない記述もあるんだが)

こんなことが書いてある。

冠詞関係

冠詞重要

英語は数に対してものすごく厳密に述べたがる言語。 冠詞(aとかtheとか)重要。日本人は冠詞を「名詞のオマケ」ぐらいにしか 考えていないようだが、ネイティブにとっては むしろ名詞の方がオマケぐらいの勢い。

I introduced the coach of my tennis club
to an ex-wife of my brother.

何気なく訳すと「私は私のテニスクラブのコーチを 私の弟の離婚した妻に紹介した」だが、 この文から読み取れることは他にもある。

まず、the coach と書いていることから my tennis club にはコーチが 1 人しかいないことがわかる。 もし、my tennis club にコーチが複数いるのなら、 a coach(たくさんいる中の1人) と書く。

次に、an ex-wife と書いていることから、弟は少なくとも二回離婚している ことがわかる。もし、一回しか離婚していないのなら、 the ex-wife と書く。

指し示すものが明らかになってない「the」は厳禁

何の前触れもなく指し示すものが明らかになってない状態で the を 使うのは「あの件だけどさ〜」と突然話しかけられるのと同じで、 どの件の話なのか全くわからずネイティブはものすごくイライラする。

前置詞関係

in と on の感覚の違い

Get in the car!(車に乗れ！)
Get on the train!(電車に乗れ！)

のような in と on 使い分けがなぜ起きるか。

in は中に入り込んで対象物と比較的密に関わる イメージで、on は対象物との接触が平面的で あまり深く関わらないイメージ。

つまり、car の方は、車に乗ってその車の運転に 何か影響を及ぼす可能性がある(密な関わり)から in。

train の方は、ただ自分は荷物として運ばれるだけで 「乗る」という行為に関してはその電車と 深いつながりが起きないから on。

out と off

out と off は in と on それぞれの逆。

Clean out your desk!(机の中を綺麗にしなさい)
Clean off your desk!(机の上を綺麗にしなさい)

around と over

回転軸が垂直なのか水平なのかの違い。

She turned around.(彼女は振り向いた)
She turned over.(彼女は寝返りした)

時制関係

日本語は時制の表現が曖昧だが、英語は時制の面も 非常にきっちりと表現したがる言語。

Before I went to Beijing, I studied Chinese.
(北京へ行く前に、中国語を勉強しておいた。)

Before I go to Beijing, I am going to study Chinese.
(北京へ行く前に、中国語を勉強する予定である。)

の前者(went)において、日本語では「北京へ行った前に」とは 決して言わない。

過去形と完了形

My sister studied English.
(私の妹は英語を勉強した。(そして今は勉強していない))
My sister has studied English.
(私の妹は英語を勉強した。(そして今その効果が持続している))

この辺り、

• 過去形
• 現在完了形
• 現在完了進行形
• 過去完了形
• 過去完了進行形

を数直線を使ってそれぞれの違いを非常にわかりやすく説明してくれる。

未来形(未来完了形)なども同様。

関係詞関係

関係詞を上手に使った文章は非常に洗練された印象を受ける。

制限的用法と非制限的用法の違い

制限用法と非制限用法の区別をしっかりしましょう(アメリカでも 乱れている)。

制限的用法(コンマなし)：
The Nobel Prize which I received last year was a
great honor.
(他にもノーベル賞を受賞したことがあって)
前に受賞したやつはともかく、今回のものはとても光栄でした。

非制限的用法(コンマあり)：
The Nobel Prize, which I received last year, was a
great honor.
私が去年受賞したノーベル賞はとても光栄でした。

制限的用法の方は、他の物の存在も暗示され、 たくさんあるなかで「○○な物」という限定をする意味になる。

非制限的用法の方は、単純に先行詞にもうひとつの説明を 付け加えるのみ(たくさんある中のコレという暗示を行わない)。

発音するときは「コンマあり」の方はコンマのところで 一息置く。

先行詞が曖昧にならないように配慮する

His solutions to a number of problems that he found 
were very creative.

だと、「彼が見つけた」のが「solutions」なのか「problems」 なのかがハッキリしない。

solutions を彼が見つけたのであれば

The solutions that he found to a number of problems
were very creative.

problems を彼が見つけたのであれば

His solutions, to a number of problems that he found,
were very creative.

とするとハッキリする。

受動態

日本人は論文などに受動態を使い過ぎだが、 受動態は著者が自分の書いたことに対しての 責任を回避しているような印象を与えるので、 能動態で自信を持って力強く書くべき。

ダメな例：
The following results of this experiment were obtained:...

良い例：
We obtained the following results in this experiment:...

また、受動態にすると主語と述語の距離が離れてしまって 意味がとりにくくなるという観点からも受動態は控えるべき。

副詞

特に

同じく日本人の論文には "Especially, ..." という 表現が多いが、Especially にはコンマで後に続く文 に仕切られた、自立した「句」として働く使い方は存在しない。

したがって

日本人は「したがって」の意味で "Accordingly, ..." とか "Consequently, ..." と 書く人が多いが、半分以上は不自然。

Accordingly の語源の accord は　"to be in harmony with"(調和する) という意味なので、「〜に応じて」「〜に相当して」などの 「ある状態に合わせる」という意味に使うことが多い。

Consequently は「ある状態の当然の結果として、何かの状態になる」 の意味。 as a result と同義。

"Therefore, ..."は論文に向いているとはいうものの 少し堅すぎる（重苦しすぎる）。

so は、かなりくだけている。「だからさ」に近い。ので、論文などの 堅い文章には不向き。

Since、Because は論文向き。

as は意味が曖昧になる(〜しながらの意味の場合もある)ので、 使わない方が良い。

thereby は論文にはふさわしい。「この特定の行為によって」の意味。

thus も論文で良く見かけるが「このようにして、こうして」の意味。

hence は論文にとてもふさわしい。「ある状態によって」の意味。

といった具合に、「ネイティブの感覚」というのをしっかり 日本語で説明してくれる素晴らしい本。

大学の初期の段階で読んでおきたかったと非常に後悔している。 英文を読み書きするする際、これらの知識を知った状態と 知らない状態では、英語の上達度／理解度に 大きな差が生まれる気がする。

日本人の英語 (岩波新書)

この春、大学に合格した新入生はぜひ読んでおくと良いと思う。

_ はじめての構造主義

はじめての構造主義

もう一つ、特に「理系」の大学一年生におすすめしたいのがコレ。

哲学の入り口として非常に良い。

数学と芸術（遠近法）の関わりとか、 文化人類学とか言語学などとの関わりが見えてくる本。

私は社会人になって、ITの仕事をするようになって オブジェクト指向の抽象化とかモデリングというものを 勉強しているうちに構造主義にたどり着いた(といっても オブジェクト指向とは関係ありそうな無さそうな、、、) のですが、構造主義のことを大学の早い段階に知っていたら、 大学での勉強がもっともっと奥深く面白いものに なっただろうに、と非常に後悔している。

ので、ぜひ大学生に読んで欲しい。

_ RESTful Web サービス 感想

RESTful Web サービス

Rails2.0 が REST を前面に打ち出して来て、 勉強の必要性を感じたので、 RESTful Web サービスをこじんまりした読書会で読んだ。

ほぼ4章ずつにわけて4回の読書会。

えー、、、悪い意味でかなり笑わせてもらった。

まず訳文が日本語になってない箇所が非常に多いし、 言ってることもちぐはぐだ。

監訳者まえがきの最後に

原書ではAPPという表記だったものを、本書ではAtomPubという用語で
統一しています。

とか

監訳にあたっては、特に訳語については非常に気を使いました。

という前フリがあり、p.51の一番下の監訳注にも

原著出版時点では「APP」が一般的だったが、その後「AtomPub」
が公式なものとなったため、本書では「AtomPub」で統一している

と更に念を押しているのであるが、ペラッと1枚めくって、 次のp.52のいきなり2行目に

APPは、実際のサービスというよりはサービスを構築するための
命令セットなので...

とあれほど何度もAtomPubで統一すると書いて来たものをAPPと 書いてあって大爆笑させてもらった。

また、原文も結構笑える状態のようだ。Amazon.com のレビューを見ると 「編集者はVacationに行ってたんだろう」とか 「この1/3ぐらいにまとめられたよね」みたいな感想があり、 実際に読んでみて全く同様の感想を抱いた。

• RESTとROAの違いがわかりにくい。
• 自分が言っていることを後で根底から覆すような箇所が何回か出てくる。
• RPC とか SOAP のことをボロクソにけなしておきながら、けなす根拠に乏しかったりRESTで置き換えようとして「ここは置き換えられないのでSOAPが必要」と書いてあったり。
• サンプルとして出てくる Rails のコードが不正確(トランザクションが必要なところでトランザクションを使ってない、とか)。その他、「これ絶対動作確認してないだろ」というコードがいっぱい。
• 地図サービスを設計するところでは場所の「種別」のデフォルト値が「遺跡」(p.136)

というわけで、この本を読むのはかなり難易度が高いので、 どうしても REST について深く勉強する必要がある人にしかおすすめできない。

サラッとポイントだけ押さえたい人は、 監訳者の山本陽平さんのPDF資料 とか Web+DB Press Vol.42の特集がおすすめ。

で、勉強して学んだこと、感じたこと。

• REST は「アーキテクチャスタイル」で、ROA は「アーキテクチャ」。ROA は　REST を実装するガイドラインの一つにすぎない。
• HTTP の GET,POST,PUT,DELETEという決まったインターフェースに処理をマッピングし、HTTPのエラーコードという決まった形で処理の結果を返す、という方法は確かにインターフェースが統一されて美しいし、インターフェースが統一されることによってRailsやRestletのような統一的な内部設計のアプリケーション／フレームワークの構築も可能になる（ただし、このインターフェースの枠組みに収まらないような状況もゼロではないと思うので、そのときちょっと無理矢理な感じになりそう）
• Webページを作ると自動的にRESTfulなWebサービスもできちゃいます、という Rails のアプローチはなんか間違っている気がする。Web ページには Web ページの、Web サービスには Web サービスの使いやすいインターフェースというのがそれぞれ別々に存在するはずなので、Web サービスが RESTful だからといって、それにひきずられて Web アプリまで無理矢理 RESTful な URL 設計にする必要は無いと思う。
  • 例えば、Web ページには「入力確認」みたいな画面が挟まることがあるが、Web サービスにはそんなものはない
  • Web ページには SEO 対策として URL へいろいろ工夫をすることがあるが、Web サービスにはそんなものは必要ない
• こじんまりとゆるふわな読書会楽しいし、読みにくい本も笑い飛ばしながら何とかがんばれる。

Web+DB Press Vol.42

_ Javaのうるう年のバグ？

会社で commons ftpclient を使っているシステムがありまして、 こいつが今日動かなくなってたんです。

で、調べたら、commons ftpclient のバグらしく、 こんなパッチを見つけました。

<URL:http://svn.apache.org/viewvc?view=rev&revision=631284>

FTP でファイルのリストを取得したときに、

Feb 29

みたいなタイムスタンプ文字列が返ってくる訳ですが、 こいつをうまくパースできずにエラーしていたらしい。

Feb 28

はパースできるのに

Feb 29

がパースできないってどういうことだ？と不思議になり、 ちょっと追試してみましたが、結局のところこれは SimpleDateFormat のバグ（仕様？）ってことに なるのかなぁ？

SimpleDateFormat sdf = new SimpleDateFormat("M d");
sdf.setLenient(false);
Date date = sdf.parse("2 28");
System.out.println(date.toString());

このコードだと、

// => Sat Feb 28 00:00:00 JST 1970

という文字列が返って来て(1970年ってのはどうなんだ？という のはさておき)問題ありません。

しかし、うるう日である 2/29 をパースしようと 以下のようなコードに変えた途端に、

SimpleDateFormat sdf = new SimpleDateFormat("M d");
sdf.setLenient(false);
Date date = sdf.parse("2 29");
System.out.println(date.toString());

ParseException ですよ。

ちなみに、Format を "y M d" などにして、

parse("2008 2 29")

だと、例外は上がってこないみたいです。

1970年2月29日って日付を作ろうとして、1970年は 閏年じゃないから、この日付は間違いだねー、ってことで 例外をあげてるんじゃないかと思いますが、、、

これを使って、日付を作ろうとすると、いちいち自分で 「今日の日付を求めてー、年の部分だけ取り出してー、 パースしたい文字列に年をくっつけてー」というお膳立てを してあげないと、意図通りの日付を作ってくれないわけです。

非常に使いにくすぎですね。

Java をお使いの方は気をつけてください。

ちなみに、Ruby だと、「今年の」2/29 としてオブジェクトを 作ってくれるので、こんな問題は起きません。 しかも、フォーマットの指定とかしなくても空気を読んで、 なんとなくパースしてくれますし。

Rubyのtime.rbは、ものすごく空気の読める子。

$ irb
>> require 'time'
=> true
>> Time.parse("Feb 29")
=> Fri Feb 29 00:00:00 +0900 2008

と、いうわけで（？）。

JavaからRubyへ