著作一覧 |
IEは、Last-Modifiedがレスポンスに入っている場合には、次回のリクエストにIf-Modified-Sinceを付ける。Last-Modifiedを最初に送らなければ当然送ることはできないからだ。
このときのリクエストはHEADではなくGETとなる。以前は最初にHEADを送ってきたような記憶があるが、今は304をGETに返せば良いから直接GETを寄越すのだと思う。
かつ、既定の状態だと、Last-Modifiedを送った場合は、最初の時点からキャッシュを積極的に利用する(ように見える。ETagに比較して)。
一方、Tomcat 5.5(他のバージョンは知らない)は、静的コンテンツの送信時にETagは付けるがLast-Modifiedは付けない。ETagはマルチホストのときに厄介とかいうより前に、アプリケーション的な操作を行うには便利ではないと書いて気づいたがTomcatは何を元にETagを設定しているのだろうか?(後で調べておこう)
それとは別にJEEのHttpRequest/Responseのヘッダ操作メソッドの時間の扱いの簡単さは異様。
というわけで、静的コンテンツをjspでくるんでやる。Tomcatから見ると動的コンテンツとなるのでETagは付かない。代わりに自分でLast-Modifiedを操作する。
// Content-Typeの設定など <% long lmod = File.new(target).lastModified(); response.setDateHeader("Last-Modified", lmod); if (request.getDateHeader("If-Modified-Since") >= lmod) { response.setStatus(304); } else { // If-Modified-Sinceが未設定なら-1が返るのでここに来る %> <jsp:include page="target"/> <% } %>
英語では臍(ヘソ)をベリーボタン(belly button)、つまり腹のボタンという。
これは不思議だ。
というのは、input type="button"で、お馴染みなように、ボタンはクリッカブルだからだ。
かといって、アングロサクソンには出べそが一般的とは思えない。
しばらく考えて、ボタンには服を留める機構もあることに気付いた。
もしかしたら本来はbelly button holeだったものからホウルがすっぽり抜け落ちたのではないだろうか。
そう考えると、アラビアのヘソに宝石で蓋をするスタイルや、ヘソピの意図はミッシングピースの補償のように考えられる。
漢字文化圏とは異なる発想から生じた風習かも知れない。
NetBeans 6.7に入ってくるJavaFXは、意外なところに入っていて、最初にそこに引っかかった。
以下に入っている。
c:\users\name\.netbeans\6.7\javafx-sdk\lib\shared\javafxc.jar
そこまでわかれば話は簡単だと思ったらまったく簡単ではない。
C:\test>jrunscript -cp C:\Users\arton\.netbeans\6.7\javafx-sdk\lib\shared\javafxc.jar -l javafx fx> 3 + 4 Exception in thread "main" java.lang.NoSuchMethodError: com.sun.tools.javac.main.RecognizedOptions.getJavacFileManagerOptions(Lcom/sun/tools/javac/main/RecognizedOptions$OptionHelper;)[Lcom/sun/tools/javac/main/JavacOption$Option; at com.sun.tools.javac.util.JavacFileManager.<clinit>(JavacFileManager.java:973) ...
調べたら、FAQらしい。中の人らしいA. Sundararajan's Weblogに、JavaFX固有のjavac改が必要なのにjrunscriptがオリジナルのjavacを持ってくるのが原因とか書いてある。
C:\test>jrunscript -J-Xbootclasspath/p:C:\Users\arton\.netbeans\6.7\javafx-sdk\lib\shared\javafxc.jar -l javafx
で起動成功。
リストの扱いが最近の言語っぽい。
fx> for (x in [0..5]) { println(x); } 0 1 2 3 4 5 fx> var a fx> a = [0,1,2,3,4,5,6,7] [ 0, 1, 2, 3, 4, 5, 6, 7 ] fx> for (x in [0,1,2,3,4,5,6][n | n mod 2 == 0]) { println(x); } 0 2 4 6
しかし変数を使うとうまく動かない。
fx> var seq; fx> seq = [0,1,2,3,4,5,6] [ 0, 1, 2, 3, 4, 5, 6 ] fx> for (x in seq[n | n < 3]) { println(x); } mfm:///stdin34:1: 警告:iterating over a non-sequence for (x in seq[n | n < 3]) { println(x); } ^ 注:An internal error has occurred in the OpenJFX compiler. Please file a bug at the Openjfx-compiler issues home (https://openjfx-compiler.dev.java.net/Issues) after checking for duplicates. Include in your report: - the following diagnostics - file C:\Users\arton\AppData\Loca\Temp\javafx_err_556696727745871515.txt - and if possible, the source file which triggered this problem. Thank you. mfm:///stdin34:1: 互換性のない型 検出値 : java.lang.Object 期待値 : double for (x in seq[n | n < 3]) { println(x); } ^ エラー 1 個 警告 1 個
バグレポートを出せと書いてあるから後で出そう。
ジュンク堂で、前田さん、大場さん、松田さんのトークショー。
前田さんと言えば、ついにRubyの仕様ドラフトが公開されたわけで、ご多忙のことだと思うけど、その話は出なかった。でも、RubySpecを使って1.9.2のバグつぶしに協力して欲しい(そうしないとRuby 1.9完全対応となるはずのRails3も困るよね)という話はあった。
というわけで、AWDwR3は、汽車、ディーゼル車と来て、レールが敷かれていない空へ向かって飛び立ちそうなところに来た(で、Rails3=AWDwR4では空を飛んでいるだろうという話となる)。
RailsによるアジャイルWebアプリケーション開発(前田 修吾)
蒸気機関車が煙を吐いている。
RailsによるアジャイルWebアプリケーション開発 第2版(Dave Thomas)
もう石炭じゃないよ。
RailsによるアジャイルWebアプリケーション開発 第3版(Ruby,Sam)
っていうか、レールが無いところに向かっているんだけど。
それよりもおれは、スーパーサンプルになんか表紙が似ているようなのが気になったけど。
Ruby on RailsによるWebアプリケーション・スーパーサンプル(久保秋 真)
以下、大体の内容。
で、3版になって何が変わったかというと、目次を見てもあまり変わっていない。とは言っても第2版は1.2系だが、第3版は2.2系。追加された章としてはタスクI(国際化)。でも松田さんによると不足。脚注で松田さんのプラグイン(i18n-generator)を紹介したのでそちらを使ったほうが良いかも。
第3部では第26章のActiveResourceの追加。でもいきなり使わない方法を紹介していたりしている。読むと興味深いけど。
というのは第3版のメインの著者はサム・ルビーだからだ。当然、RESTには一家言ある。
RESTful Webサービス(Leonard Richardson)
(サム・ルビーは名前はRubyだけど、むしろRESTの人だ)
それはそれとして、第21章のルーティングのテストの章が大充実でびびる。2.2系で変わったし。
というわけで、Rails3はもうすぐ出るけどアプリケーションについては2.2系とそれなりにコンパチなのでAWDwR3を買っても困らないよ。でもプラグイン作家とかは別問題だし、AWDwR3の濃いところに入り込むと当然また別の話だ。
松田さんのRails3の記事が掲載される予定のWEB+DB。
というような感じでおもしろかった。
っていうか、そもそも前田さんはRails症候群糾弾者だし。
(Railsと言えば、おれはおれの本もすごく好きだけどね)
前田修吾 普段は島根 大場寧子 3年くらいRailsをやっている。元々Java。 (一番いっぱいレビューの指摘をしたみたいだ) 松田明 フリーランスのプログラマ。100%RubyとRails。 宣伝:来月くらい。Head First Rails(O'Railey)の監訳 前田:Railsには詳しくないので詳しい話は松田さんに。 第2版を読んだ/買った人……半分強 いきなり第3版からでも問題ない 大場 第2部はあまり変わっていないが、アジャイルといえば客が上がって来たプログラムに注文を付けるような感じ。 C(Customer)を「彼女」と訳して真実味がある。 前田 第3部は膨大なリファレンスなので、必要なところだけ読めば良いのでは。 本来であれば、前半と後半の2部構成だと思うが、分冊すると売れないのではないかと思う。 ●第3版で変わったところ 目次を見るとあまり変わっていない。第2版は1.2系だが、第3版は2.2系になっている。 ●追加された章 第2部では、タスクI (国際化) ただし松田さんによれば不足。脚注で松田さんのGeneratorを紹介している 第3部では、第26章のActiveResourceを追加。ただ、最初がいきなり別の方法の紹介。あまり使ってくれという感じではない。ただ、読むと興味深い。 大場:第21章のルーティングのテストが充実してびびった。 松田:2.2系で変わったので。 ●レビューの感想 前田: 凝りすぎて(濃すぎて)バージョンが変わると動かない。 大場: 境界を泳がないとだめということを示している 松田: 表紙の画。レールから離れて飛んでってしまっている。 前田: 僕も……電車が速そうになっている。汽車、ディーゼルと来てなんか速そうだ。 前田:開発スタイルについての著者の主張が含まれているようだが。 松田:そもそも第一版はDHHとデイブトーマスが書いて、第2版は共著で、第3版はサムルビーという人で、だんだんDHHの本ではなくなってきている。 前田:元々初版もDHHはあまり書いていないということです。デイブ色が強い。 松田:DHHのポリシーは基本的には大好きだけど。Rails1はDHHで、Rails2くらいからみんな知っているし、 Rails3が早くて今月出始めるんだけどMerbとかくっついているし、ActiveRecordだけじゃないよ、という具合に黄金のレイルが崩れる。 Rails界がDHHのRailsからみんなのRailsになってきている。 というわけで、Rails3だとレールはなくなっていて、それはみんなの心にある。 前田:みんなの範囲? 松田:開発者一人一人で探してくれと。 前田:Rails3の話になっているけど、この本はRails2なので。 DHHの意に沿わないことは難しい。RDBの参照整合性制約を使おうとすると大変だし。サムルビーとかも外部キーを使いたいとか書いているけど、 DHHは対応する気はないようだし。Rails ConfでもデイブがRailsに入れて欲しいのが参照性と複合キーともう1つあるのだけど、 その後のセッションでDHHは否定していた。 大場:参照制約性は開発の初期では不要で後から入れれば良いと思う。 schema.rbは使わない。 cloneがschemaだと使っているか。 松田:FKが使えないのは信じられないけど、ひっかかるので開発をドライブしてくれない。本番前に付けるのがベストプラクティスかな。 前田:そういうプラグインを使うとバージョンアップすると動かない。 レガシーなスキーマだと使いたいと言われる。共同開発時にデータベース設計者が複合主キーでなきゃいやだとか。 松田:基本的にはDHHが主張しているレールは良いものだから、できれば1から作ったほうが良いですね。 前田:Rails3になると、無理にActiveRecord使わなくても良くなるとか。 松田:そういう感じですね。 前田:DHHとサムやデイブの考え方は違うような。migrationとか。 松田:細かいところはいろいろあって良くて、そういうの含めてRails(第3版はそういういろいろがあっておもしろい)。migrationは良く使っている。 前田:この本には外部キーがあればアソシエーションを作りましょうみたいなところがある。 大場:おかしい。呼ぶ必要がない関連を張る必要はないし。誰も使っていないhas_oneとかでがんばっているとか。 あくまでも実装という気はする。 松田:必要になったら書く。 前田:僕は最初から定義するかな。 大場:欲しいなら書けば良いじゃん。 (会場だと1:2くらいで後派が多い。) 前田:僕はあまりアジャイルじゃないのかも知れない。最初にデータのイメージがあるのかも。 大場:関連で思いついたけど、STIとかしているとSTIに絞った関連もあるし、必ずしも関係だけではないという意識が強い。 前田:雑誌を読んでいたらSTI使うなとか書いていてショックを受けた。 タイプ分岐は許せない。とするとSTI使うしかない。 大場:オブジェクト指向で継承するなら普通はSTIを使う 松田:STIは良い機能だけどデータベースがださい。テーブル名とか。 前田:マーティンファウラーの影響があると思う。 大場:STIにも問題があって、親子なら良いけど、3段とかなると途中で探しても取れないとか注意が必要。 前田:普通の継承したいときにSTIを使おうとするとはまるけど、この本にはそのへんの説明がある。 RESTについて。RubyKaigiでDHHがこれからはRESTだと言ってて、今回2.0以降、スキャフォールドが一番RESTっぽいかな。 Rails的なRESTというと、Uniform Resource Interface。 松田:RESTは技術じゃなくて思想で、RailsはRESTを一番忠実に実装したフレームワークだと思う。 で、OrileyのRestful Web ServiceでもDHHが前書きで、サムルビーが共著だし。 前田:AddonPublishing Protocol (Sum Ruby) Rest+Railsは仲がよい印象がある。 松田:前田さんはあまりRestが好きではない? 前田:リソースっぽいものをRESTで表現するのは自然だと思うけど、業務システムに当てはめる必要はないような気がします。 普通のユーザが利用するアプリケーションでステートレスとかあまり現実的とは思わない。 大場:Railsのリソースも妥協している(コレクションで増やすとRestじゃないとか言われるし)あまりがんばらなくても良いと思う。 松田:結構頑張る。Add Userではなく、Afiliation CreateだろうとDHHも言っている。 前田:APIで提供しないのならそこまではしない。 大場:それはありだと思う。 前田:プラクティカルに役立つ面と思想の2面があって、前者で十分だ。 大場:ガラスの仮面とRESTは似ている。すべては名詞側にする。 ガラスの仮面でも「ありがとう」「ごめんなさい」とか数語で寸劇するのがあって、RESTというのは言語を絞った言語表現ということで。 松田:良いまとめ。 前田:RSpec、ActiveSupport 松田:この本ではActiveSupport 前田:ActiveSupportをどう思いますか? 松田:前田さんはActiveSupportけしからんと(Rails症候群)言ってましたよね。 前田:それをみんながやるのが良くないな。標準を置き換えるのは当たり前みたいに思っていると、追っかけるのが結構大変。 Railsがやるのは良いけど、アプリケーションプログラマはそれをやってはだめかな。プラグインとか抽象化の過程で出てくるのは良い。 そうでなければサブクラス化すれば良いでしょう。 というわけで、セレクターネームスペース(1.9では実装されない)ですが、現実には手に入れられない。 ActiveSupportで思うのは、英語的に読めることを重視していて、オブジェクトがそのメソッドを持つべきかというと逆だと思う(onday.agoとか)。 大場:そんなローカルなものを入れて欲しくないとは思うけど、blank?とかは良い。 ●ActiveSupportで好きなメソッド 松田:Object#tryが大好き 前田:なんでもかんでもtryして捕捉できないのではないかと思った。 本当に良いものならRubyに取り込むべきだと思う。今のActiveSupportのAPIはRubyには文化的に合わないと思う。 ただ、Hashの機能の取り込み(Rubyっぽく)とか、今後はそういうのがあると思う。 Hash#inreferenceHash 松田:RSpec大好き。クールじゃないですか。 角谷:普通に使ってますよ。 松田:NaClはあまり好きではない? 前田:古い人たちが多いので。DSLの流れから取り残されているような感じはある。 松田:internal DSLは良いものだからみんな使おうと、Matzがキーノートで言ってた。CucumberとかRSpec。 角谷:最初は違ったけど宗派換えしたと言ってた。 前田:英語っぽい何かではなく、メソッド呼び出しとして読むから気持ち悪いのだと思う。 大場:自然な順は、RSpecの順で、assertは1回それをひっくり返していることに気づいたら戻れなくなった。 前田:そのあたりがオブジェクト指向の次なのかも。 松田:Ruby World Confferenceが松江で開かれて、1つのテーマが「松江のRuby、世界のRuby」。 そこでジェイミーケンプラというRails最大の功労者(コミット一番いっぱいしている)(前田:中田+笹田 /2のような)が言っていたのは、 「日本と世界、Railsとレガシー(Rubyコミッター)」のような対立。 そのへんは、今、いろいろ聞けておもしろかった。 前田:コミッターにはそういう人が多い気がする。 ここまでやってはいけないと我慢していたところを、Railsは踏み越えているようで嫉妬しているような。 ●Railsの進化 前田:Rails3が開発中で結構、変わるようで。そのへんを。 松田:技術評論社のWEB+DBの12月号でRails3特集を書いたのでよろしく。 かいつまむと、 ・アグノスティック(選択の自由を与える) Railsっぽければなんでも良い ← Merbを取り込んだから Rackに載ればなんでもRails (レールなんて無いよ) 前田:ジェレミーが言っていたのは、元々Railsを支持していたのはスタートアップとか早くサービスを立ち上げたい人。 MerbはRubyプログラマに支持されている。でも3では一緒だ。 松田:みんな動画を見ろと。 大場:Rails3というのは、現在のコードは割りと動くけど、それがone of 書き方となるということ? ActiveRecordを書かないRailsプログラマとかあり。 松田:アプリケーションはおそらくそのまま動くけど、プラグインとかは全滅します。 前田:この本はその点はアプリケーションだから問題ないけど、でも奥に入っているところは別。 松田:Railsはgithub、RubyはSubversion 前田:shyouheirubyは? 卜部:公式とは誰も言ってないですね。後で話しましょう。 前田:そろそろgit使わないといけないとは思う。 松田:github的なものとSubversionの何が違うかというと、みんなに開いているよというアティテュードの表明で、それがRailsが成功しているところだと思う。 Gitの持つ変更しやすさのようなものがある。 大場:個人としては、SubversionからGitに移ってGitのほうが良いなと。 前田:Gitはマージをちゃんとしてくれるところが良い。 Rubyのほうが若干保守的というか。 大場:逆じゃ怖いですね。 前田:保守的だとつまらないですよね。 松田:ドラスティックに変えたいとか思いますか? 前田:言いたいことは言わせてもらっているのでフラストレーションはそれほどないけど。いいよと言ってもらった仕様変更を覆されている。 卜部:そんな大変じゃないし、保守ブランチと新しいことするブランチは分かれているので大変じゃないです。 松田:聞いていると2倍大変そうに思うけど。 前田:RubySpecというスペックがある。それが1.9だと通らないので、1.9のバグを直すという作業と、スペックを直すという作業がある。 Rails3はRuby 1.9なので、1.9.2を頑張らないとRails3が使えないとなる。 RubySpecダウンロートしてトランクを動かして直せるところは直してください。
IronRubyとは全然関係なく、Azureの.NETとRESTでRubyとやり取りするAppFabric SDK for Ruby Developerとか、AzureでRails動かしたり(昼にはindex.rhtmlが出てたけど今は名前が引けない)とかいろいろやっている。rubyonrails.cloudapp.netではmingw版1.8.7を使ってた。
妙にきっちりと終わってしまった。もっとだらだらと続けて欲しかったような気もするが、しょうがないか。
これで、継続して買っているマンガで残ったのはへうげものと隠の王だけになってしまった。と思ったらシグルイもあった(軍鶏はどうにもならないのかな?)。
以前買ったロイヤルのリゴレットをやっと観られた。
演出については後で書くとして、ジルダがすばらしく細身でまあ、これは確かにひ弱な(でも意思がやたらと強い)籠の鳥のようなジルダにふさわしい。というか、本当に歌手なのか? というほど細身。
で、最初はオーケストラに負けているような……と思って観ているわけだが声が美しいし、技術もしっかりしているので、何も問題ない。というよりもすばらしい。
しかも3幕で書生に変装するわけだが、きれいな赤毛のショートカットでむちゃくちゃかわいい。まるで賢い女狐みたいだ。
で、殺し屋スパラフチーレと殺し屋の妹とジルダの3重唱(リゴレットの中でおれが一番好きなところ)では、嵐を打ち破るような張りのある声で実にすばらしい。
で、いったいこの人は誰なんだ? とジャケットを見るとクリスチーヌ・シェファールと最初読んでもそんな人はいない。ロイヤルだからイギリス人かな? とクリスチーヌ・シェーファーで調べてもひっかかるようなひっかからないような、はて? と顔を見ているうちに、おれはこの人のCDを持っていることに気づく。
シェーンベルク:月に憑かれたピエロ、心のしげみ、ナポレオン・ボナパルトへの頌歌(シェーファー(クリスティーネ))
これかぁ。で、ドイツ人でクリスチーネだということを知る。こういうのを歌う人なら、そりゃ技術的にはうまいはずだ、と納得する。
クリスチーネか。
クリスチアーネじゃないのな。
で、ロイヤルのリゴレットはBBCの製作なのだが、マクヴィカーの演出がどうしたこうしたと結構いろいろな人が書いている(ジャケットにもボルドでCONTAINS NUDITYと書いてあるし)ので、まあ、モントヴァ公爵の宮廷では毎日がプロミスカスモードだから普通に女性が全裸でうろうろするんだろう、とか考えていた。
で、そのくらいは全然OKと、子供と一緒に観ていたのだが、出てくる女性たちがみんなドレスをずり下げておっぱいむき出しは良いのだが、リゴレットがマントヴァ公爵の受けを狙って股間に勺杖を付き立ててピストンピストンはじめたのもまあ良いとして、ついに大臣たちがモントローネ伯爵の娘を全裸にひん剥いて乱暴狼藉もまあ良いとして、と観ていたわけだが。
大臣たちがモントローネ伯爵の娘の相手をさせるために若者を連れてきて全裸にひん剥いてちんちんむき出しにはちょっとひいた。(当然、その後、無理やり二人を重ね合わせることになるのだが、それはまあ良い。というか、いまさらどうしようもないので良いのだが、モントローネ伯爵にとっては良いはずはなく、ついに呪詛を撒き散らして悲劇を呼ぶことになるわけだ)
はて、なぜおれは全裸女性はコード的にOKで、全裸男性はコード的にちょっとぴりぴり来たのだろうか? と不思議になった。(女性は全裸でも正面から見た普通の状態では性器そのものは見えないというのはあるかな?)
もし、おれがおれではなく、女性だったら、全裸男性はOKで、全裸女性にぴりぴり来るのかな? ――そうかも知れない。ってことは、セクシャルハラスメントを受けたときに感じるものってのは、おれがちんちん見させられたときに感じたものと同じようなものかも知れない。
まあ、21世紀にリゴレットを演じるならそこまでやらなければ異化効果が無いというのはわかるわけだが(結構、精神的にはショックだったようだ)、でもBBCを観ているイギリスの人々にとっては、全然、ありふれたテレビの中の光景かも知れないわけで、ふむ、単におれが保守的なだけかも知れんな、とも思う。
いずれにしても、シェーファーのジルダは素晴らしかったし、ちょっとスーパーマンっぽいマルチェロ・アルヴァレーズのマントヴァ公爵も良い感じだし(特に3幕のリズミカルな女心の唄はいいな)、リゴレットのパオロ・ガヴァネッリもいい感じだ。坊主頭のスパラフチーレはさすがにイメージとは違うが(おれにとってはどちらかというと泥棒詩人ラスネールみたいな口ひげ男のイメージなのだ)まじめで正しく誇り高い殺し屋っぽくて良い感じ(ちょっとマトリックスが入っているのかも)。
万人にお勧めできる現代的なリゴレットだった。
!がない……
ということは、否定の時の処理を書きたければ
if (foo.bar == false) {
と書かなければならないわけで、もちろん他の言語ではあり得ない不恰好さだ。
一番スマートなのは
unless foo.bar
として、最悪でも
if (!foo.bar) {
とは書きたい。
と、ここまで書いて、もしかしたら
if (not foo.bar) {
と書けるのではないか、と気付いた。ならば悪くない。
慣れないなぁ。
extendsがあって、静的型チェックがあるため、Sequence#sortなどを使うにはComparatorをextendsしたクラスを定義しなければならないみたいだ(implementsはない)。というか、そうやったらちゃんと動いた。
が、なんでそんな面倒が必要なんだ?
と書いて気付いたが、後で次を試してみよう。
MyComparator{override compareTo:function(o1,o2):Number{…}}
もしこれで通れば適当なequalsを実装したクラスを用意すれば良いことになる。っていうか関数がファーストクラスオブジェクトなのになんでこんなとこに悩まなきゃならんのだ?
それでもオブジェクト定義式の分、Javaより書きやすい。
とりあえず、ここまでできた。
本物はもちろん、全然なめらかに動く。
とは言え、これがおれが作りたかったものかというと違うような。
Twitter APIで取り出したXMLのパースと関連する値オブジェクトには、JavaFX Twitter Client(PDA用らしい)のソースファイルを使わせてもらった。あと、JavaFXのTextBoxにはパスワード属性がないので、無理やり*を上被せするところも、同じくJavaFX Twitter Clientのソースからコピペ。
メインのソース。
(それにしてもIDE使ってツールボックスから切り張りして作るとインデントがおかしくなるけど、とりあえずas is)
このプログラムはTwitterにリクエスト出すから、アプレットとしては動かないと思う。つまりデスクトップアプリケーションってことになる。
ソースの中で好きなところは、リスト内包表記(でいいのかな?)を無理やり使って書いた(使ってみたいじゃん)friends.content = friends.content[e | e instanceof FaceNode];
のところ。
IE8でwindow.parent.document.location.href='foobar'した場合、refererにはこのコードを実行したページのuriが設定される。
IE7では最初にそのドキュメントを要求したページのuriが設定される。
refererをチェックして分岐するプログラムで引っかかった。
突然だけど、あるところでこの本をお勧めされた。
A User's Guide to Algebraic Topology (Mathematics and Its Applications)(Dodson, C.T.)
とても良い本らしいのだが、はて、おれがこれを読む意味ってあるのだろうか? というか、とりあえず短期的にはいいや(というか、読む本が1ヶ月先まで詰まってるし)。
で、中期的にみたとして、おれが読んで理解できるものか? というか、そこは学部レベル(というよりも高校出たレベルということになるかな)のところから(できればもう少し下の辺りから)独りで読み進められるような本なのだろうか? (まあ、during and after a first course in algebraic topology とは書いてあるけど、これは先生がいる場合の話じゃなかろうか)
読んだ人いたら教えていただけますか?
[ruby-list:46622]でアナウンスされたRuby-1.9.1-p376のパッケージです。
リファレンスマニュアルは2009-11-29版に更新しています。
md5checksum: 3d3ef8ecf1880f849aa6adfcc5add3c5
他に、同梱のopensslが0.9.8lに更新されました。
アスキーの鈴木さんからもらったAzureの本を読んだ。
Microsoftのクラウドコンピューティング Windows Azure入門(砂金 信一郎)
1章がクラウドの概説、2章がAzureの概説、3章が開発入門、4章が企業システムで利用する場合に考えるべき既存システムとのインテグレーションについて、という内容でポイントを押さえているとは思う。1章は知識を整理できてよかった。特に10個の課題(データをクラウドに配置すると転送時間によってメリットが相殺どころか瞬殺される可能性があるとか)の整理はポイントが高い。
1章で微妙におもしろかったのは(ミスなのかそういうものにしてしまえという割り切りなのか)、サンのCTOのパパドパウロス(と読むのかな?)がBlogで書いた、IBMのワトソンの「世界にコンピュータは5個あれば足りる」としたのは正しいよ。Google、Microsoft、Yahoo!、Amazon、eBay、Salesforceがあればいいじゃん、というのを紹介したところ。
明らかに6台(仮想的に)挙がっているのだが、一貫して「5台」と表記している。
あと、IaaS=Amazon、PaaS=Google、というのでEC2とはどういうものかわかった。一応、意味づけはできているのだな。(プライベートクラウドの定義も含めて)
4章は前半がおもしろそうだが、後で読む。
O'REILLYにJava Seb Services: Up and Runningという本がある。
Java Web Services: Up and Running(Kalin, Martin)
オライリーの動物クォリティーだけあって、良い本だ。
では、万人にお勧めできる、あるいは千人がこぞって買うか? と訊かれると悲観的な感じになる。
おもに2つの観点からだ。
この本は特にJAX-WSに焦点を当てたSOAPベースのWebサービスについて書かれている。
もし、SOAベースのシステムでSOAP連携を前提にアーキテクチャを考えるとなったら、この本は必携……となるはずだが、おれにはそうは考えられない。
つまり1つ目の観点は、JAX-WSというミドルェアを直接利用した連携にどれほどの需要があるか、ということだ。おれがこの観点から否定的なのは、IBMやMS(をインフラとしてSIするSIer)の選択肢に、JAX-WSを利用したベンダー非依存なJava中心のシステム構築というのは存在しえないのではないかと考えているからだ。
しかし本書はUSでは結構売れているとは聞く。でもそれは、比較的小規模なシステム部門であってもCTOがいて、ベンダー非依存のシステムを構築するような土台があるからではないか? あるいは巨大ベンダー非依存のシステムを構築することを特徴とする独立系ソフトウェアベンダがあるからだと考えるほうが自然だ。
2つ目の観点は、より下位のレベルで、つまり実装時点でクライアントをJAX-WSを直接利用するようにシステム開発を行うか、という点だ。もしそうであれば、本書はJAX-WSの利用(WSDLの使い方を当然含む)についてきちんと解説しているため、必携と言える。
しかし、これについても全く悲観的だ。JAX-WSを生で利用するのはおそらく趣味のレベルと評価されてもおかしくない。
本書にはWeb Serviceのセキュリティ確保手法について1章を割いている。これはきちんとしたまとめで、この章の内容程度が身についていることは常識の範疇とも言えるのだが、その反面、何も考えずにHTTPS+まっとうな認証さえ用意すれば企業システムであれば十分とも言える程度にミドルウェアは枯れてきているので、そこに学習時間を使うのは無駄と言えなくもない。(と考えている人が多数を占めているのではないかと想像する)
本書にはREST+SOAPの論点まとめ(最終章)や、JAX-WSからのREST利用についての(やや偏った)説明とサンプルもあるが、これもどうなのだろうか?
別の切り口として、企業システムを考えた場合のトレンドはクラウドで、クラウドでのストレージはKVSを前提として……と考えると、いかにもSOAPは筋が悪い。KVSを前提とした時点で、RESTに軍配を上げることができる(原理的に)はずだ。
この観点からは、(現時点での必要性からではなく)中期的な将来性からJAX-WSベースでシステム連携を考えるために本書を読むということも考え難い。
同様な理由から学生にとって魅力的な学習内容とは考えにくい。
Java Web Services: Up and Runningについて(詳細)
追記:るいもさんの全体最適化しないためのSOA(SOAP連携)は興味深い。企業内システム連携の疎結合アーキテクチャパターンの実装手段としてのSOAPという観点からは(JAX-WSへの具体的言及が多いとは言え)この本は具体性があるだけに読む意義はある。
観に行った。
いろいろ想うところはあるが、映画としてはいったいいつの時代に作られた映画かと驚くほど単調極まる編年体で、あっけにとられた。
物語としては、親父の屈折した愛情をまったく理解できない息子の間抜けっぷりに不快な気分になる。自分と妻の間できちんと役割分担ができるように考えて動いているのは傍目にも明らかな上、親父本人が抱擁する母親の不在による欠落を息子が味わうことがないように工夫までしている(ということは父親がつい弱気になって甥っ子に話すまでは隠されている)わけだが。それを利用して強者の孤独を表現しているのだとしたら、この映画作家は愚かだ。
あと、最後まで影の男として活躍しながらラストに突然目立たせられる異母兄の無視のされかた(何かで読んだ中部地方の弟妹たちのようだ)とか、語られていない部分の存在とか(あるいは単にへたな映画だというだけかも)。
というわけで、物語がどんどこ進むのでとりあえずは見ていられたが、実につまらない映画だった。
var fn = function() { ... } var x = 3; ... fn();これが、転送サイズ削減しようと空白とか改行を削除するとばしばし引っかかってエラーとなる。
var fn=function(){...}var x=3;...;fn();なんとなく、}で終わると、;がいらないような気になるからみたいだ。
_ arton [}直後の改行のほうが効いてるな(文法上も)。]
XML−JSON変換のデファクトスタンダードのBadgerfishというのがあると知って、見てみたら、消えているけど。
Badgerfishのアイディアは比較的単純で、テキスト要素には$を使い、属性には@を付ける、ネームスペースには@xmlns(@で始まるから属性のうちとも言えるのかな)を付けるという方法となっている。
確かにこれであればほとんどのXMLが機械的に変換できるだろう。何のために利用するのかはいまいちわからないけど、と考えたがそうでもなく、JavaのクライアントがJAXBでXMLをアンマーシャルしてオブジェクト化できるのと同じことを素のJavaScriptでもできるようにするためだろうな。
<year> <value type="heisei">21</value> <value >2009</value> </year>
であれば
{ "year" : { "value" : [ { "@type" : "heisei", "$" : "21" }, { "$" : "2009" } ] } }
となるのだと思う。
初耳環境変数なので調べてみた。すると、MSDNのソーシャルサービス(?)で、ファイルが見つからないのがどうしたのようなスレッドがあり、32/64ビットの話が出ている。ふーむ。
タワーレコードでルグリのトークショー兼サイン会があるから行きたいとか子供が言い出した。でもタワーレコードがどこだか知らないとかいうから、西武の子供デパートの跡だといってから、それは生まれる前の話と気づき、面倒だから一緒に行った。
で、会場の6Fに行くと、どこにもそれっぽいホールはない。はて、と思いながらうろうろしてたら、売り場の一角に20席くらい用意してあってそこに人がすでに満杯で立ち見が10人くらい。しょぼい会場だな。まるでサブウェイのコンサートだ。で、それが30分前のことだ。
でも、考えてみれば、天下のルグリに30人はねぇよな。で、30分たつとそれでも100人以上(200人近くかも)は集まっていたようには思うが、それにしてもそんなものかな。
で、たまたまテノール売り場なので、やっぱり一番人気はホセクーラかと言えば、やっぱり今でもドミンゴやパバロッティなんだな、とかホセカレーラスがやたら充実しているなとか(ホセカレーラスはおれには固いわりに勇まし過ぎて好きになれない。こいつのラボエームのロドルフォとかどこのアンドレアシェニエ状態だし、こいつのアンドレアシェニエはどこのザックス親方状態だし、いつも何か嫌な方向に外しているようにおれには感じる)
そんな中に、初見の粋な歌手のCDが目立つ。リヒャルトタウバーとか書いてあるのだが、まったく知らない。まったく知らないがある時代のよき香りがしている。クレメンスクラウスとかエーリッヒのほうのクライバーとかだ。見ると1910年代とか1920年代とかの録音でSP復刻らしい。
で、気づくと
Richard Tauber - Opera Arias(Strauss, Richard)
とか手に取っていた。
ラボエームやら乾杯の歌やらエウゲニオネーギンやらと混じってコルンゴルトの死の都があって、これは買わなければならないだろうと思ったらしい。
針音の向こう(CDなのに針音とはこれいかに)から、ポルタメントがかかったヴァイオリンが聴こえて、比較的震わせ気味の声(実は、好きではない。どれだけストレートに突き抜けるデルモナコが好きなことか)だけど、確かにちょっとした節回しとかによきものを感じる。
で、ルグリはジーンズに白いシャツにグレーのプルか何か着てひょいひょい出てきて椅子に腰掛けて、割と高めの声でへらへら喋っていて実に良い感じだった。
最近は日本のお客さんも現代のものを観たいように思うからどうしたのようなことを言っていたけど、その実、マッツ・エックとかを演じられるとは思っていないだろうな。おれが呼び屋でも、マッツ・エックの(チャイコフスキーとかならともかく)ロルカのやつとかを演じたいといっても断るだろう。(でもギャラ次第かも。集客× で考えれば良いわけだから)
2月の公演では、特にカナダの新人ダンサーが注目だよ、とか言っていたので、あとで名前を見ておこうと思った。
タワーレコードには良い思いでがあって、NYに公演に行ったときタワーレコードに入ったらパリでは売っていないような作品がたくさんあっていっぱい買って帰ったとか。傍で聞いているとそういう時代もありましたなぁという感じではあるけど、本人はリップサービスというわけでなく何となくタワーレコードでトークショーというシチュエーションを楽しんでいるようには感じた。
当日買うとサインと握手をもらえたはずだが、子供は映画を観た時点で買ってしまったため、ちょっとしょんぼりしていた。まあ、握手というのは不思議なものだな。
フロイスを買おうと、アマゾン。
大は小を兼ねるから、最初、Lを買おうと思った。
I'mD (アイムディ) シャワーチェア Revolc レボルク L ホワイト REVLW(-)
すると、
自分は185cmの長身で足も結構長い(笑)のですが、これはあまりにも高さがありすぎで落ち着いて座れませんでした。
とか
Sはイス用に、Lをテーブルにして洗面器を乗せてお風呂で使ってます。
……大は小を兼ねるってこたなさそうだ。
が、
高さも丁度良くリラックスしてシャワーが浴びれて大満足です。
はて、どういうことだろうか。
と思ったら
実家の両親用に購入しましたが、しゃがまないで済む高さ、
ああ、なるほど、と納得。
久々にマルチスレッドで同期するプログラムを書いていたのだが、ある程度パターン化できているように思う。しかし、よりうまい方法もありそうにも思う。また、間違えている可能性もある。そこで、2つほど並べてみる。また、3番目として実際の問題についても書いておく。どのように構成すればよいかを考えてみるとなかなかおもしろい(僕はおもしろかった)ので、それについてはとりあえずどうしたかは省略するので考えると良いと思う。
以下では、3つのスレッド(実際にはより多数あると考えてよい)を使って示す。1は元の状態を利用して実行している先行スレッド、2が状態の変化A→Bを検知して自身および後続のスレッドに新たな状態を利用させるスレッド、3は2より遅れて実行されるため最初から新たな状態を利用するスレッドである。+は実行の開始地点を、*は状態変化の検知からその状態への遷移までの区間を示す。また、()はその状態の利用区間を示す。
1. ある時点で状態が変わり、その後はその状態を利用する場合。
スレッド1 +------(-----------------)-----> スレッド2 +------(***--------------)-----> スレッド3 +------ (-----------------)----->
この場合は、先行する1に対しては同期を行わず、3に対しては遷移後の状態を利用させる。
Object lock; State state; ... void local() { State localState; // 実行中参照する状態値 synchronized(lock) { if (A → B) { state = B; } localState = state; } ... }
1. ある時点で状態が変わり、その後はその状態を利用するが、同時に複数の状態で実行してはならない場合。
スレッド1 +------(-----------------)-----> スレッド2 +------(* **--------------)-----> スレッド3 +------ (-----------------)----->
同時に複数の状態のスレッドが実行されてはならないため、2は先行する1の状態参照区間が終了するまで状態変更を待たなければならない。スレッド2が待ち状態に入るため、スレッド3も明示的な待ち状態を作る必要がある。
Object lock; boolean changing; int running; State state; ... void local() throws InterruptException { State localState; synchronized(lock) { while (changing) { lock.wait(); } if (A → B) { changing = true; try { while (running > 0) { lock.wait(); } state = B; } finally { changing = false; lock.notifyAll(); } } localState = state; running++; } try { ... } finally { synchronized (lock) { running--; lock.notifyAll(); } } }
状態変更を検出するのは同時に1スレッドのためbooleanを利用するが、先行スレッドは複数存在するためカウンターを利用する。
2と3の停止理由は異なることから、異なるモニターを割り当てることは可能であり、かつ意味的には整理されるが、プログラムは煩雑になる。したがって単一のモニタを共用すべきと思う。
3.(ここからがおもしろい)2のプロセスが複数存在し、すべてのプロセスに同期が必要な場合。たとえばクラスタリングされたサーバで実行されているサーバアプリケーション。
いずれのプロセスが状態変化を検知するかはわからない。したがって、すべてのプロセスは対称的に動作する。
どこで何回通信を行うかと、通信を受信したスレッド(スレッド4)はどのように動作するかが問題となる。
例) プロセスa スレッド1 +------(-----------------)-----> スレッド2 +------(* **--------------)-----> スレッド3 | +------ |(-----------------)-----> プロセスb | スレッド1 V +------(-----------------)-----> プロセスbではまだスレッド1(以前の状態)が実行中
すべてのプロセスを対称的に実装した場合、状態変更の通知のコンテンション(プロセスaからプロセスbへの通知と、プロセスbからプロセスaへの通知が同時)が発生し得ることに注意が必要。
休みなんで、子供と何度目かのクライバーのこうもりを観る。観ながらいくつかの疑問を調べる。
まず、トカイワイン。最初家の中で歌いながら飲むし、オルロフスキー公爵のところでも飲む。
検索するとWikipediaで正しそうな説明を見つける。ハンガリーのワインだというような歌詞が出てくるからそうなんだろう。
次にネズミちゃんを捕まえるための懐中時計。取り出すとキーンという不思議な音がするので、たぶん、催眠術のことなんだろうと思うわけだが(2幕ではハンガリーの伯爵夫人の目の前でぶらぶらさせる)、はて、懐中時計=催眠術という決まりごとはこうもりの時代にもあったのだろうか? (たぶん、あったのだろうと考えるのは、フロイトを持ち出すまでもなくウィーンは精神の怪しい世界のメッカだからだが)、というかおれの記憶では子供ころ見た映画(チャップリンかアボットかそのあたりだと思うのだが)で寝椅子に横たわった主人公に医者が懐中時計をぷらぷらさせるがあったような気がするのだが、出自がわからない。
でもまあいいや、Erotic Hypnosis Swinging Pocket Watch Hypnotic Inductionなんていうのもあるし、「きみを催眠術にかけてみせよう」っていうようなナンパ術が19世紀末のウィーンでは普通にあったんだろう(女性は、時計が18金か24金か、誰が作ったやつか、で術にかかるかどうかを決めることができるしな)
そしてシャンパン。どう観ても、シャンパンの輸入業者から握らされて作ったCMだろ、これ。が、わからない。シュトラウス2世はシャンパンポルカも作っているから単に好きなのかも。あと、シャンパンの歌の中で修道士が鼻の先を赤くするという歌詞が出てくるが、単なる赤ワインだと他の部分と合わないので、当時のウィーンでは黒ブドウの皮を混ぜて赤くしたシャンパンを飲んでいたりしたのかな? とか。
最後にハンガリー。なぜ、ハンガリーが強調されるんだろうか。アウスグライヒ化でオーストリア=ハンガリー帝国が成立したのが1867年だから、(原作は1851年と1872年らしい)1874年の作品にはそういった政治的な影響もあって、ハンガリーをいっぱい出してくるのかも。特に刑務所長のフランクがチャルダーシュに異様に反応したりするのは、こちらには見当がつかないが名前や職業から明らかなギャグになっていたりするのかな、とか思う。
でもそういったことは知っていたからと言って実はどうっということはなく、クライバーをはじめとした音楽家(役者や舞踏家も出ていると思うが)が、ヨハンシュトラウス2世の実に愉快な作品を(別れのシーンで脚が勝手に踊るところとか見事なものだ)すばらしく楽しく演奏していて、それで十二分なのであった。
出た、困った。
IMEはXPデフォルトの2002とVisio導入時に入れてしまった2007(Office)。
最初はOS道連れで固まってたのだが、2007削除でWordだけに被害範囲を絞れた。が、いくら辞書を修復しても新規に作成してもハングする。
再度2007を入れて(コントロールパネルの言語設定)2007の辞書を作り直したら復旧した。
本当にPCは難しい。というか2003がひどいというか。
オープンなシステムで成功しているところを潰すには3つの方法がある。
1つはよりオープンなシステムを作ることで相対的にクローズにしてしまうこと
2つめはクローズが正しいという価値観の転倒を起こすこと
3つめが同じ土俵で勝負すること
3番目は普通で2番目は革命だ。ということから一番簡単なのは1番目ということになる。
……というところまで考えてみたらなんのことなくハロウィン文書と同じ結論になってしまった。さてWeb Socketsか。
ソフトではなく、ハードな手段も取り得るかも知れない。NWGN?
あるいはオープンなものの中にクローズな領域を作るという方法もあるなぁ。グレートウォールか。
突然、シルクロード大作戦というのを考えてみる。ノルマンディーから青洲までを横に繋ぐユーラシアバスのようなものだ。欧州−ロシア−インド−中国。
電話は止まっているのに回線は生きてるのか。物理的にはそりゃそうだが、よくわからんシステムだなぁ。
夜、空は雲で覆われていたのだが、今日、初めて気づいたことがある。
赤坂の上空はピンクっぽいし、新宿の上空は明るいし、六本木の上空は紫っぽい。
雲が下の世界からの光を映しているのだった。
しばらくして赤坂や六本木のほうは他と同じように単なる薄ぼけた闇に変わったのだが、新宿だけは変わらない。
子供の頃から不思議だったのは、オリオン座は良くわかる(少なくともベルトの3つ星までは。吊る下げた剣は見えはしないが)のに、あるいは冬の大三角は結構見ることができるのに、北斗七星や北極星は見えないことだ。(それでも遥か以前には見た記憶はあるのだが、小学生高学年以降は見えた覚えがない)
昨日の風景から、どうもそれは北西から北にかけて新宿と、さらにそれに続く池袋や、遥かな関東平野の北部が連なって、天を照らしているからではないかと気づいた。
南は、それなりに都市は続けど、すぐに東京湾になってしまう。北とは全然光量が違う。
おそらくそれが原因なんだろう。
ふと、寝転んで空を見上げて気づいた。
普通に立って上を見るのとは、見える星の数が全然違う。
真上のみを見ると、目に入る光が少ないからではないか、と考える。
もし、そうならば、東京で天体望遠鏡を屋根につけている連中は、当然のようにただのカッコだけだと思っていたのだが、その範囲が絞れることから、それなりに観測できているのだろう。
アバターを観に埼玉の山奥へ車を走らせる。
kawabataさんがツイッターで、まともに見るなら菖蒲町しかないと呟いていたので、そういうものかと思ったからだ。
駐車場が6000台とか、想像も付かないようなことがホームページに出ていたので、一体、どんなとこかと思ったら、びっくり仰天。
埼玉の山間に突然長方形のばかでっかな建物が横たわっていて、しかも中に入ると、いきなりアメリカのショッピングモール(それもビッグな部類の)がそこにあった。そこらにあるショッピングモールとは桁が違う。横浜のランドマークの全長を使ってショッピングモールにしたようなものだ。どれだけ広いかと言えば、東の端の店への距離が、西の端に近いあたりに出ている看板で「360m先」となっているくらいだ。ってことは、駐車場を抜きにしても全長500m近いはず。しかし、買いたいものがあるかと問われると、ちょっと首をひねらざるを得ないような。でも、ちょこちょこと買い物したりしてみたり。
それはそれとして、いくつか不思議な構成に気づく。
まず、客単価が高そうな店が1Fの中央付近に固まっていること。2Fや3Fでも比較的、そういう傾向がある。一番、大衆的なフロアが2Fで、3Fがそれに続く。
駐車場への車の分散のための戦略かなとか考える。
で、映画館がとんでもないシネマコンプレックスで、12面くらい持っている。どうりでとんでもない数の映画の看板が出ているはずだ。
で、アバターだが、中央の予約席はほぼ満杯(というか最後の3席を確保したわけだが)で、中央後部以降はほぼ満杯、でも前列のほうは比較的空いているという、つまりみんな3Dを堪能しに来ているのだな、という調子だった。
それにしても、以前の3D映画につきものの「飛び出す」という形容が一切使われていないことに、えらく納得した。これは「飛び出す映画」ではなく、「映画」なのだな。
アバターの2重構造がおもしろい。
映画の中では、人造生物(人間のDNAと現地人のDNAを融合させて造ったというような説明だったような)を人間がアバターとして操作する。
映画の外では、(人間のモーションを抽出したらしき部分と、計算でつないだような部分と、完全にアニメーションとして描いた部分が混ざっているように思える)CGが人間のアバターとして演技する。
The ART of AVATAR ジェームズ・キャメロン『アバター』の世界 (ShoPro Books)(ピーター・ジャクソン(序文))
何故モラージュ菖蒲か? ――iMAX3Dだから。かつ、川崎と異なり音響もIMAXデジタルサウンドだから。アバターを観るということ自体が、歴史的体験なんだから万全の態勢で望もう。
時間はモラージュ見学(別の映画を観るのもありだな)で潰せるので、予約出来ないなら午前中に行って現地で直ぐに席を確保しよう。
駐車場は、映画待ちの間にモラージュ見学で往復する事を考慮すると映画館に近いブルーがおすすめ。グリーンにした(久喜から12号で行くと入りやすい)ため、2往復になって疲れた。広いよ。
眼鏡がペコペコしてる――言ったら替えてくれた。
クラシックハイライトを見たいとか言い出したので、テレビをセットアップした。
ランランという名前のピアニストのおもしろさにしびれまくる。バルトークのソナタはもちろん、手垢にまみれまくった英雄ポロネーズがかくもリズミカルでスリリングだなんて。
今度日本に来たら万難を排して行く。
ジェズイットを見習え |
_ ムムリク [なるほど。「ぼく」を見つけたわけですね!]
_ arton [続編が出ていることに気付いて読んだら、ブレーキが効かずにさあ大変みたいなことになっていて、何か心境の変化があったのか..]