著作一覧 |
まだ、鈴虫にこだわってんだが、違うような気もするが、多分、御岳山の邯鄲を聴く会で元多摩動物園の矢島先生の話にあったんじゃないかなぁ。なんか、とんでもなくい爺さんで、ロン先生が本当にいたらこんな感じかなとか。でも、本そのものを見た気もするからやっぱり違うかも。
その時は、結局、雨が降ってて、邯鄲(ちなみに、読みはカンタン、アクセントはカとタにあるので、「簡単」とは異なる。エルジェのタンタンの発音に近い)の声は聴けなかったのだが、その分、矢島さんの話を聞くことぐらいしか楽しみは無いわけで。
例えば(嘘が混じってるかも)
−−都会でも虫の声は聞こえるが、あれはほとんどが中国から来たやつ。声がでかいので、あればかり聞こえる。実際には、昔ながらの日本の虫もいるんだが、聞こえないね。どうしてそうなったかというと、街路樹の幹に住むから、地面に住む在来種と棲み分けができている。ただ、寒いのに弱いので、このあたり(御岳の上)には来られないんだよね。
−−平べったい(上下から押しつぶした感じ)のがコオロギで、薄い(左右から押しつぶした感じ)のがキリギリスの一族。
−−鈴虫の場合、毎秒?回擦り合わせる。
と、こうやって書いてみると、いかに忘れてしまうものか。
あぁ、でも、やっぱ、このへんだな。江戸時代に虫を飼うのが爆発的なブームになって、それはなぜかというと、飼い方のハウツーが確立したから、なんてのは読んだのではなく聞いたんだし、こんなこた、ここでしか聞けない。と、思う。ようこそ課外授業へ、ってのもあるから、そっちかも知れないな。
6/30の会話
「明日から値上げだけど買い置きとかした?」
「忘れた。でも、あれててJTだけでしょ? だからラークに鞍替えしようかと」
「そうだったっけ?(わからんから黙っておこう)」(で後で確かめたら税金の変更だから外国タバコも影響されるんじゃん)
7/1
で、本当にラークに変えてたんだが、6/30までの値段を知らなければ(だって買ってないわけだし)やっぱり値上げしてないと信じてるのかも。
美しきコモンズというわけではない。
地下鉄駅の広告を見て、ちょっと、違和感を覚えたのでメモ。
コピーは、「もっとフランス」とか、とにかく「フランス」になりたいワタシを訴求。
しかし、写真に写る店はGAP、車はベンツ。街並みは、ベージュ基調の石造り。これは、ヨーロッパ風、マンハッタン風、ようするに、没個性西欧風。すなわちビジュアルは、コスモポリタンのワタシあるいは、ニューヨーカー風の軽みを持つワタシを訴求。
可能性としては、GAPのみが店頭の撮影を許可したというセンもある。しかし、2つの人形(左)でも、パイプのお化け(右)でも、坂道(極右)でもない、没個性な街頭風景で、目立つ固有名詞がすべて非フランスというのはあまりに変だ。
#GAPをフランスのブランドだと考えているとか? まさか。少なくても写真家や代理店はともかく、クライアントがそんなことを知らないはずがありえない。また、ベルコモンズはGAPに箱を貸していないから、あえてGAPを風景に入れてやる義理はない。入れたくて入れたのだ。
結論:今や、おふらんすは、その国名のみが、ブランドである。少なくても、青山界隈では。
あっ、これはいい。ブレーンストーミングと組み合わせると、非常にはっきり見えてくる。と実感。
やっぱ、紀伊国屋だよ。ついでに岡田史子も買ってしまう。まぁ、そういうお年頃だ。
読んだ。それほど感慨はない。そもそも「踊りたいのに」とかってのが1のほうに入っていると誤解してたからってのもあるが、おそらく、豚の存在が緩衝材になって、話にゆるさを持たせているからだろう。まあ、こうなれば、意地でももう1つの世界のほうの残りも読んでみようと言うものだ。
会社のProxyで弾かれる。なんのキーワードなんだか。って言うか、今月は見られないでFA?
広告対象はベルコモンズそのものではなく、サンドウィッチ屋さん。建物の色は白。ベルコモンズが駅と契約している広告スペース(下部にベルコモンズと表示されている)らしい。サンドウィッチ屋の名前が写真の左上にはめ込まれている為、それは単に風景の1部としての看板と思ったようだ。
80'傑作集というのに収録されていたので買った。……どうもXDayという作品が自分にとって特別みたいだな。
多分、aml関係か、ク$$$ソじゃないかな。これが引っ掛かると面倒なんでパディングを入れたが。話にならないので正規に申請。
JDBCのAPIドキュメントはデストラクタの実装のこととか書いているが、Oracleはそんな面倒を見てくれない。
class JdbcHandler implements InvocationHandler { private boolean closed; Object obj; Throwable stack; private JdbcHandler(Object o) { obj = o; stack = new Throwable(); } public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { String name = method.getName(); if (name.equals("close")) { closed = true; } else if (name.equals("executeQuery")) { return createProxy(method.invoke(obj, args)); } else if (name.equals("prepareStatement")) { return createProxy(method.invoke(obj, args)); } else if (name.equals("createStatement")) { return createProxy(method.invoke(obj, args)); } try { return method.invoke(obj, args); } catch (Throwable t) { throw t.getCause(); } } }で、こんな風に使う。
private Object createProxy(Object o) { JdbcHandler j = new JdbcHandler(o); list.add(j); Object pxy = null; if (o instanceof ResultSet) { pxy = Proxy.newProxyInstance(o.getClass().getClassLoader(), new Class[] { java.sql.ResultSet.class, oracle.jdbc.OracleResultSet.class, }, j); } else if (o instanceof PreparedStatement) { ... } else if (o instanceof Statement) { ... } else if (o instanceof Connection) { ... } return pxy; }で、適当な時点でチェックする。
for (Iterator i = list.iterator(); i.hasNext();) { JdbcHandler j = (JdbcHandler)i.next(); if (!j.closed) { System.err.println("detect jdbc resource leaking !"); j.stack.printStackTrace(); } }
Hybrid Tea。芳香があるTea系から異種交配によって作られた。いわゆる薔薇は、これ。
なんとなく、花びらの先端が外を向いているし、巻きが甘く感じる。なんの略かは忘れた。フロリデンとかなんとか。
友人の結婚式に行く(7/5)。帰りにSAP屋さんになった友人からいろいろ話を聞く。
書き直した後から、この記述自体に注釈を入れるテスト。つまりこのブロッククォートはこの記述自体のメタデータ。C#を使え。ページの果ての最後の最後で、これは極論と言っても、釣られる人には遅すぎる。
と書き始めた。ただし、構造体がオブジェクト指向でない(継承に問題がある)というのはわけがわからない。コンポジションを知らないわけではあるまいし。また、これが意味を持つのは、ref,in,outといった引数への方向指定があるからだという点や配列(コレクションではなく)をきれいに無視しているのも変だ。っていうか、10も出すんだったら、引数の方向指定を入れろよな。用例がバカ過ぎ。 結局、実際にコードを書いたことも想像することもできずに、なんかの資料を元にまとめただけなんだろう。
ここまでが読後の印象#便利/不便、頭をつかわずに済む/済まないの観点からは、C#のこのあたりの仕様は間違いなく便利である。しかし、ユースケースを正しく把握していないこういう能書きが出てくる点を考えると、やはり難解な=排除すべき仕様かも知れない。
読後の印象を受けてまじめにあるべき姿を考えて見ている。次に、メタデータだが、XDocletとか見ると必ずしもソースに含めるべきかどうか疑問を感じ始めているので、手放しで賛成はできないな。むしろ、ソースと別立てで配備指定時に実行コンテキストに合わせて記述できるということが望ましい点が多いからだ。という結論になるのは、この筆者が、例としてEJBの配備記述子を挙げているからで、ここでもメタデータが意味を持つユースケースを正しく認識できていないと考えられる。もちろん、所詮、釣りなんだから、正しく認識した上で、あえて無意味な例を挙げるという深慮遠謀の可能性が0ということもない。
書いてから、内容を補完しようと読み直して追加しているうちに新たな視点=筆者の深慮遠謀が見えてきている。まあ、読んで損したというのが実感かな。
この部分は、最初に書いた結論の部分。
最終的な結論。
bash-2.05$ diff -u ../nm/namazu-2.0.12/configure configure --- ../nm/namazu-2.0.12/configure 2002年 9月 3日 (火) +++ configure 2003年 7月 7日 (月) @@ -5615,7 +5615,7 @@ LTVERSION="6:0:3" -ALL_LINGUAS="ja ja_JP.SJIS es fr" +ALL_LINGUAS="ja ja_JP.PCK es fr" echo $ac_n "checking for ANSI C header files""... $ac_c" 1>&6 echo "configure:5621: checking for ANSI C header files" >&5次に、
cd po cp ja_JP.SJIS.gmo ja_JP.PCK.gmo cp ja_JP.SJIS.po ja_JP.PCK.poする。これは当てずっぽうで根拠は無い。
でも、やっぱり変則だな。SJISのテキストを処理するために、kakasi -isjis -oeuc -wして、mknamazuの文字コードをeucにしてもうまくいかないし、kakasi -isjis -oeuc -wして、mknamazu -L jaもだめ。かといって拡張子plを読む気にもならないし(とは言え、OS判定を無視してsjisに変更と、nmz/忘れた.cで、LANG判断にja_JP.PCKの追加は試してみた)、1度、全部eucにして実行すればOKなんだが、あまり嬉しくはない。
って言うか、これ以上、鯰とたわむれるのは時間切れだ。
8月いっぱいは子供の夏休みだし、今はまだ「遊べ〜」とか可愛いこと言ってくれるから、行かないと言い切ったその日に帰ってみれば、実はそのあたりに子供がキャンプに行く予定と知って、「昨日のは嘘でした〜」とはやっぱり言えないなぁとか。
別段、make clean, makeと動くんだがなぁと思いながらよくよく見れば、.NET Framework 1.1ではなく、1.0が動いてる。
c:\progra~1\microsoft.net\ には1.0が入っているが1.1は入っていない。??? どこにあるんだろう(もちろん、%Windir%\microsoft.net\framework\v1.1.4322に入ってるのは知ってるがSDKのこと)。
あと、青木さんからJayの動作が変わったらしくパーサが生成できないと聞かされたことを思い出す。そろそろMonoを入れてみるか……と言いながら、あまり興味が湧かないのも事実。
昔、プログラミングはひじょーに、コストが、時間的にも人的にもかかった。思い出してみれば、コーディングシートと呼ばれる80桁の紙に、延々とプログラムを鉛筆で書いていくこと約3〜10日、パンチ屋さんに渡して3〜7日、カードの山を受け取って1時間くらいかけてマシンに入力して、コンパイルしたりなんなりして、プリンタのキューに入って長いときには3日以上経過してやっとプリントが出てきて、そこからパンチミスによるコンパイルエラー(ようするに文法エラーになるから)を拾い出して、30行くらいなら自分でカードを打つが、それを越えたら、またシートに書いて、パンチ屋さんに出して……
このフェーズ(物理的と言っていいのかな? な実装フェーズ)は、抽象的な記述で済む定義−仕様−設計フェーズより、現実的に時間が必要だ。したがって、ここの時間を短縮するためには、設計フェーズが重要となる。紙上の設計を紙上のプログラムに忠実に再現していかなければ、効率が悪くなるからだ。イテレーションなんて考えられない。
この作業は、現在なら1日もかからない。
しかも、ほとんど1発作業の当時と異なり、編集−コンパイル−実行 サイクルのイテレーションは幾らでもやれる。
さらに重要なことは、設計自体にはデザインパターンのような型が、実装にはイディオムのような型が、存在するということだ。イディオムは言語の固定が重要だが。
このことは、設計というフェーズの不要化を意味している。
仕様をもとに、デザインパターンを適用して、実装をその場で行っていくことができるからだ。
時々、思うのだが、この時代を知っている人間で、僕のように現役でプログラムもがしがし書く人ってどの程度いるんだろうか? (僕の経験が他の企業より10年遅れた場所にあるから、+10しないとだめだろうけど。カードを打ってる横で、VTAMでやっつけてるのを見て羨ましかったりしたわけだし)
作業内容の変化は、プロセスの変化にならなければおかしいじゃん。
というわけで、プロセスの変化をどんどん進めて、そろそろ現実に追いついてきたようだな、と感じる、今日この頃だが、習慣というのを変えさせることは非常に大変だったり。しかし、人はやすきに流れるから、だいじょうぶだろう。
不正アクセスというのは、不正アクセス行為の禁止等に関する法律の第3条の2だよ。オープンソースじゃないけど、オレ様不正アクセス定義でISPに電話で話している記述を見た瞬間に気分が悪くなったのでAC。
この点に関しては肩が触れただけで、暴行を振るいやがってと脅す絵の中のお兄さん(暴行のオレ様定義)と変わらない。なんとなくというコンセプトを愚弄されたように感じたんだろうとは思うが。それは、オレ様臭を漂わせているお兄さんにわざわざ肩を触れたという行動に、オレ様への挑戦と感じて暴れるお兄さんと同じだな。言葉の使い方に関しては。
が問題なのは、それが広く使われることで、開き直りに利用可能になってしまうことだ。って言うか、TBCとかも最初は不正アクセスという呪文を唱えてたが(しっかり設定ミスが疑われているとも書かれてしまっているので相当良心的な記事だが、一般紙はどうかな?)。
/universal_readable/
おっ、ディレクトリ丸見えじゃん。
/universal_readable/customers.xsl
なんだこのファイルは?
……
「弊社のWebサーバーに何者かが不正アクセスを行ったため……」違う。
あとは、インフレ効果だろうな。なんでもオレ様不正アクセスで済むんだったら、そりゃ楽だろう。しかも同情されたりして。
ジェズイットを見習えで検索かけて来た人は、何を探していたんだろうか? って言うか、出典は出せるけどね。
_ arton [って言うか、ソーシャルの基本だろ。いや、オレはそれがイヤなの。]
1.1rcのまま突っ込んじゃおうかと一瞬考えたが、まあ、リリース版にしとけってことでやってみたら、いきなり、GenericDataSourceのClassNotFoundExceptionを喰らってActionServlet#initでこけてしまう。
<dataSource type="oracle.jdbc.bpool.忘れたCacheImpl">で、typeの上書きしてるし、DataSourceConfig.java見ても、Genericなやつは単なる文字列定数としてしか定義してないし、なぜ返るかはわからない(ことは本来ないんだが、調べる前にログを消しちゃったし、再現させるのは簡単だが、それほど閑でもない)。いちいちlegacyなんて名前のjarをWEB-INF/libに入れるのもイヤンな感じだし、面倒なんでlegacy.jarをshared/libに突っ込んでこの件は2週間ほど忘れることにする。
これなんか、名前付けの勝利だろうな。ClassLoaderってそのものズバリ過ぎて、多分、AppDomainと比べるとイメージが湧かないと思うのは、こっちの想像力の不足かも知れないが。
文章力があり、分析能力(自己に対しても)がある人間が、会社をやめた理由を書いて公開する。だから、本来、非常に個人的な視点からしか書かれないような内容が、強い普遍性を持つ。しかも、それを読むことができる。どう考えても世界は前進しているなぁ。
if (ds instanceof GenericDataSource) { ((GenericDataSource) ds).open(); }ここで指定していえるGenericDataSourceは、org.apache.struts.util.GenericDataSourceで、このクラス自体は、struts.jarに入っているので一見問題なさそうに見える。 が、しかし、
public class GenericDataSource extends org.apache.struts.legacy.GenericDataSource {お〜い、実装継承しているよ〜。 これじゃあ、何のため、legacyパッケージに切り分けたのか訳ワカメちゃん。 では、どうすれば良いか考えてみる。 やりたいことは、GenericDataSourceというクラスをlegacyとして、排除したいが、そのクラスを利用しても良いし、利用した場合には、GenericDataSource#openを呼び出す必要が(多分、そこまで調べない)あるということだ。 この場合は、
pakcage org.apache.struts.util; public interface GenericDataSource { public void open(); }として、legacyのほうで、
public class GenericDataSource implements org.apache.struts.util.GenericDataSource {とすればいいんじゃないか? これなら、実際にlegacy GenericDataSourceを使う必要がなければ、クラスローダの手をわずらわ必要もないし。 と、ここに書いてもしょうがないが、Googleしても話題になってないとこ見ると、こんなとこに引っかかるのは、僕だけなのかな。というわけで、特にBugtrackとかに報告しなかったりして。
TomcatのCrossContextを使ってみようと考えた。
/aと/bは互いに異なるコンテキスト(しかし同一JVMを利用している)。
歴史的諸事情からclasses/hogeが、/a/WEB-INF/classes/hogeと、/shared/classes/hogeで重複している。
この状態で、/a、/b基本的に、問題なく動いている。
ここで、/aから、ServletContextの属性に、hoge.xを突っ込んむ。なおhoge.xは、hoge.h.xインターフェイスを実装している。
/bで、getServletContext().getContext("/a")して(これをやるには、server.xmlのContextタグにCrossContext="true"を付けてやる必要がある)/aがServletContextの属性に設定したhoge.xのインスタンスを取得する。
この状態、/bで取得したオブジェクトは、
System.out.println(o); --> hoge.x#3476
とかになる。そりゃそうだろう。
しかし、o instanceof hoge.h.x はfalseになるし、
hoge.h.x x = (hoge.h.x)o;
は、ClassCastExceptionで飛ぶ。
仮説1)そういうもの。コンテキストが異なれば、obj.getClass().equalsが偽となる(そりゃ、確かにクラスローダが異なる)
仮説2)そういうもの。しかし、クラスローダがどちらもWEB-INF/classesローダまたはsharedクラスローダで合致していれば問題ない(この場合、位置から見てもローダが異なる)
仮説3)そんなことすることがバカ。コンテキストをまたがった場合は、リフレクションを利用してリモートプロクシ作ってやる必要がある。(.netのクロスAppDomainはこれだな)
仮説4)インターフェイスはそうだが、クラスは特別にうまく動く仕組みだ。
仮説5)CrossContextを認めるだけでなく、さらにセキュリティ設定が必要(たとえば、Classのインスタンスが異なるのは当然としても、==でチェックかequalsでチェックかとかが変わるとか。っていうか、equalsの実装はどうなってんだろう? ==と同じだから、これは違うか)。
仮説6)CrossContextは、問題があるので使うべきではない。(確かに一理ある。バージョンが異なる場合とか。それで気付いたが、.NETで複数バージョンを利用した場合も、リモーティングはやばそうだな)
仮説7)とりあえず、2週間は放っておいて、同一コンテキストで動かせ。これは仮説じゃないな。
#ゴルゴダクロス(タイガーマスク)
仮説2。ただし、両方をsharedに統一。両方がWEB-INF/classesの場合は、なんとなくだめそうな気がするがそこまで試す必要がないので、ここまで。
好きな言葉に、犬が吠えても歴史は進むというのがある。もしからしたら歴史は続くかも知れないが。はるか昔に、確か、日共の御用学者か御用ジャーナリストかどっちかが、(南京大虐殺だと思うが)保守側の御用学者か御用ジャーナリストの書いた、幻モノか何かに対して、そうレッテルを貼って吠えたんだと思う。あるいは、(当時のモノ言いとしての)トロツキストに対して吠えたのかも知れない。どちらにしても、側から側へのレッテル貼りなので、それそのものはどうでも良いことだ。
しかし、言葉としての「犬」「吠える」「歴史」というのが、「月に吠える」というような詩的な語感ではない、妙なリアリティを持って結合しているのが気に入って、好きな言葉になった。
昨日のデジクリに、十河さんが書いていて(この人の死ぬほど感傷的な−を意識して書いているようでもあり−エッセイはなんとも言えない読後感があって辛いのだが)、そこにアンドレ・ジイドからカポーティが教えてもらった「犬は吠える。しかし、キャラバンは進む」という砂漠の民の言葉から、カポーティの「犬は吠える」の題が取られた、と書かれていた。
カポーティについては、いろいろ思うところもあるが、知ってる人は知ってるように、80年ころはティファニーを除いてほぼ全滅状態になっていたため僕も「犬は吠える」は読んだことがない。そこで、それは知らなかった。
で、多分、砂漠の民が出典で、そこからカポーティ経由で御用学者(またはジャーナリスト)が、より直截的な表現にしたものを僕が目にしたということだろう。思わぬところで、オリジナルが見つかるというものだ。
もっとも、「萬犬虚に吠える」というのもあるし(こっちは右側の誤用学者モドキの著、むしろ、「番犬虚に吠ゆ」じゃないかとか。番犬が吠えたのは教科書問題で、萬犬が吠えたのも教科書問題でバランスが取れてる)、しかも、なぜか、関連して「幌馬車隊に……」とすっかり西部劇になってしまったモノイイ(多分、カポーティ=米国人のキャラバンという言葉の意味から、ジイドを無視して幌馬車隊に転化したんだろう)が見つかったり(砂漠の駱駝幌馬車隊を日本語化するなら隊商というべきだろう)、楽しい。何が楽しいかといえば、側に関係なく使える便利な言葉で、多分、みんなが好きな言葉だということが見えるからだ。
ただし、腐れ学者モドキが、なぜ腐れているか、モドキなのかは、せっかく犬に吠えさせても、これっぽっちも、自省が見えないところにある。単に「犬が吠えても……」と言えば、そこには「お前は犬だが、おいらも犬だ。ばかですねぇ」という味わいがあるが、「萬犬」といっちゃうと、「俺様人間様が、世間に巣食う全ての犬共に」ということになってしまうからだ。まあ、番犬と萬犬は排他な存在だからしょうがないが、どうして、こういう言葉を選ぶのかは興味深い。
単に「犬」を使えば、それは対象かも知れないし、その言葉を発した側かも知れない。「犬は吠える」という本なら、著者が犬かも知れないし、取り上げた内容が吠えている犬についてかも知れない。仮に著者が徹底的に相手を罵るつもりであっても、読み手にはどうとでも受け取れる。「強い力に対して犬が一所懸命に吠えてますね(暖簾に腕押しとか、誤用での流れに棹差すとか)」または「そうは言ってもそれは犬が吠えてるだけですなぁ」か。普通は、それを狙う。なぜ、狙うかと言えば、相手を犬と言う呼ぶのは、まともな人間はやってはならないことだからだ。したがって必ず、自分にも跳ね返るような仕掛けを設けなければならないのだ。
しかし、「萬犬」と複数にしてしまえば、そこに著者は含まれない。本気で、相手を犬扱いしてるんですな。
ようするに、人間様を犬呼ばわりしているわけで、腐れとかエセとかモドキとか番犬とか呼ばれてもしょうがないというわけで。
つまり、犬が吠えるという言葉からは心象がはっきり形成されるというわけで、それくらい、犬が吠えるのは近所迷惑だということだ。もっとも犬を飼っても歴史は進むわけで、どうでもいいんだが。近所に居なければ(+自分で飼うのでなければ)、ということだろうけど。と矮小化してみたくもなるが、実際の心象はまた違うんだな。
裏の畑で吠えて大判小判がざっくざっくざっくざくなら、より幸せだ。
利益じゃなくても、初めて何かしてお金を得られたら、でもいいんだけど、フツーは嬉しいよね? 違うかなぁ。どうでもいいけど、ここでは嬉しいもんだと仮定する。
だったら、どっかにその嬉しさってものを書いときたいやね。
というわけで、3月くらいに360円くらいの時買った富士通株2000株ほど、550円くらいのときに売却して利益を得た。初めて(投資信託含め)、証券会社から渡した以上の金額を得たのでメモしておく。
賞与の激減額の補填として、これで夏休みの旅行ができるだろう。
そこには14〜15歳の先輩(達)が待っている。で、お前は12歳だからお前がすべてやったってことだよな、それ以外のこと喋ったらどうなるかわかってるよな? まあ、テストの成績がいい優等生だから、そんなことは知ってるよな?
が、絶対に0%とわかるまでは、少なくても長の字が付く人間が、情動的でかつ煽動的なモノイイをすべきではなかろう。世の中には可能性とか不可知とか闇とか知らない人間もいるはずだから。
人間様を犬呼ばわりするのは、まともな人間のすることではない。では、水に落ちた犬はどうか? これは自他ともに認めるようにハナから力量が違い過ぎているので、逆に人間としてしまうと、危険が待っている可能性があるからだろう。例え話でしかモノを語れない時代や背景には、それなりの語り方があっても許容されるとは思う。
われら遠くより来たりて遠くへ去るのだ。わかるか?
オペラが観たい、とても観たい。どれでも良いというわけではなく、選べるんならプッチーニがいいな。それも初期のやつ。でも、マルコムマクラーレンのが聞きたいわけじゃない。
どうして、そう思うのかといえば、多分、こないだ名探偵コナンで、オペラが出てきたからだろう。クラシック好きの教授が殺されているのに、流れていた曲がオペラだったからコナンは疑問に思う。−−思うか? 普通はオペラもクラシックだろ。いや、クラシックは古典派じゃん。とは言うものの古典派にはモーツァルトも含まれるし、魔笛やフィガロを忘れちゃいけない。
それはどうでも良くて、オペラが観たい。ベリズモがいい。特に、やっぱりプッチーニだ。ベリズモと言えば、結局、カバレリアルスチカーナとパリアッチョがプッチーニの露払いで、プッチーニはベリズモといった派というか側を越えた天才だから、永遠に不滅だろう。多分、200年くらいは。
200年と言えば、1900年から既に100年を越えた。1900年はベルディの死を嘆くパリアッチョから始まる。ベルディはあまり好きではないが、それでも女心の唄を口ずさむことはできる。取りとめも無く鉄のズビスコを思い出す。あれは、王者のためのアリアで、ポーランド第2世代の監督の作品。荒野を逃げ出すシーンだけははっきりと覚えている。あと、女心の唄を歌わせるとこ。違う曲かも。
ベリズモの功績の1つに1時間以内でカタを付けるようにしたというのがある。2時間ドラマより1時間ドラマのほうが見やすいように、集中力の持続には限界がある。1時間で終わらせるベリズモは先見の明があった。別に関係は無いだろうが、未完に終わったドビュシーのエシャー家の崩壊と、バルトークの青髯公の城の2つの20世紀初頭の代表的な2作は、やはり1時間ものだ。ここには幸福な手とかを含めても良いかも。ヴォツェックだって比較的短い部類だ。
オペラが何より、オペラなのは、その語感だ。オペラという語感があって、はじめて、浅草オペラ、ピストルオペラ、うたかたのオペラ(確か歯車)、演劇、映画、音楽、そんなものが生まれてくる。
でも、実は、考えたのは、ブランキ殺し上海の春だったりする。しかも、オペラだと思っていたら、実はキネマだったりする。キネマとオペラ、大正、昭和、モボとモガ、それはつまりは、モダーンの象徴、ということか。
そう言えば、黒テントを最後に見てから20年近く経つんだな。最後に見たのは品川で、演目は三文オペラだった。それで、佐藤信のことを思い出したのか。客の年齢層が無闇に高くて、隣の隣の隣くらいの客が連れに、「なんだよ、じじいばかりが観にきてるな」「もう終わりだな」と声高に放言してるのに、居合わせた客全員(そう、僕とその連れも含まれるし、そもそも30人くらいしか客がいなかったような)、思わずうなずいたもんだ。そして、それで打ち止めにしてしまったが、今でも、揺れて見せたりしてるんだろうか。
それでも時たま、モリタートが口をついて出てくることもないわけではない。そいつは鮫だ、鮫にゃ歯があるだったか、桃色紐を七つに巻いてだったか。
御覧よ、御覧、首が飛ぶ
妻がぴちょんくんを育てきってしまった。結構、おもしろそう(って言うか、でっかな頭をふりふりしながらキューキュー鳴くのが可愛いって言うか)なので、僕もやることにしよう。
しかし、JavaScriptを有効にしなけりゃならないってのは面倒だな(Flash使ってるんだから、JavaScriptはいらんのじゃないかい?)。それに、ネスケの対応が4.7って、気持ちはわからんでも無いが、頼むから7.1を推奨してやって欲しいなぁ。まあ、確認してくれなくても、7.1で動いているからいいんだが。って言うか、自分たちも、4.7ではスタイルシートをオフにしてくれなんて注釈を書くのは面倒だったろうに……
それに、パスワードをニックネームと言い換えるのって、おそらく、お子様にはうまい方法かも知れないが、ちょっと微妙だろう。大体、ニックネームがパスワードだと一切気付かないまま登録してしまう人間のほうが多そうだ。利用規約へのリンクは小さいし、平易な書き方(「快適すきすき!ぴちょんくん」のご利用にあたって)が逆に、利用規約やプライバシーポリシーへのリンクとは気付きにくいと思われるし。
とは言え、ゲームをクリアして、かつプレゼントを要求して初めて、メールアドレス以外の個人情報を入力させるというのは、良心的かも知れない。が、横から見ていた限りではこれについても、ちょっと微妙な点はあるな。記入時点でプライバシーポリシーへの参照ができないように見えたからだ。まあ、それは僕が育て終わって、かつ、プレゼントに応募したくなったら確認してみよう。
_ あ [なるほど]
全然近所じゃないが、イトーヨーカドーに行って、ついでに子供に服を選ばせたら、薄々感づいてはいたが、天才てれびくんの女の子たちが着ているような服を選んでみせる。
もしかして、あのコみたいなのがいいのかな? と、何人かうろちょろしている子供から、それ系のコを示すと、大きくうなずく。
−−OKOK、それは1番嫌いなタイプだが、しょうがない。時代は回転しつつ進んでくってのはおいらの信条だ。認めないわけにゃ、いかんだろう。って言うか、イトーヨーカドーだと、せいぜいそのあたりしか選択肢が無いってのも事実だし。
大雑把に分類すれば、おサイケ−ヒッピーがあって、(何も無いカーペンターズの時代があって)、パンク−ニューウェーブがあって、ダブ/スクラッチ経由でラップ−ヒッポホップがあって、後は知らない二人は若いがあって、そろそろそのあたりに差し掛かって来たんだろう。まあ、いいかー。
とか、言いながら、自分じゃサディスティックミカバンドとか聴いてたりするんだからわけわかんねぇなぁ。(って言うか、なんか一緒に歌ってるからなんで知ってるのか聞いたら、どうも天才てれびくんでも使ったみたいだな)
ついでに、子供用パンツ売場を一緒に見たり。たまたまかも知れないが、ちょっと妙な傾向があったのでメモ。100cm、120cm、140cmとあるんだが、100cmだと、パンダモチとかウサウサとかの柄なのに、120、140となるとアニメものになったりする。ちょろい想像だが、100cmくらいだと女親が買うから可愛さで、それよりでかくなると本人の意思が働くからキャラクタものになるのか、それとも、マーケティング調査から、120cmよりでかくなるとカワイイものからキャラクタものへ嗜好が移るのか。
そう言えば、幼稚園の頃は男女区別なくポケモンだが、小学生になるとポケモン好きな女の子は少数になるみたいだし(男はデジモンが主流になるとか、遊戯王とか)。
すっかりジェンダー刷り込み態勢が整ってるみたいで、いささかげんなり。
待ってる間、皆様の声のQ and A6月号というガリ版刷り(のはずは、今はないが)みたいな冊子を眺める。
Q: パンティーを忘れることが多いので、紙パンティーを売って下さい。
A: (というような声が多いのは重々承知だが、売店を維持するのは大変だからというような趣旨)ご自宅からお持ちください。
寸評:そんなもんなのか?! (妻に聞いたら、そんなものだとか)としたら、プール帰りのおばさんのうち何人かは、パンツ無しなのか?
Q: 鼻水がプールに浮いている
A: マナーを守らない人がいて困りますね。1時間にいっぺんは掃除するから勘弁ね。
寸評:子供の小便、大人の鼻水……鼻水? 事実らしくて気分が悪くなる。浮いてるのか……
Q: 食堂に弁当持ち込んで食ってる不届き者がいる。追い出せ。
A: 区民用施設で、食事を取っても良い場所を食堂に制限しているんだから、そんなことはできない。でも、食券を購入した人を優先することはやぶさかじゃないから、昼間のゴールデンアワーは遠慮するように張り紙をする。
寸評:……
Q: 土日は職員がいないのをいいことに、備品を片付けない不届き者がいる。職員はいつも見張ってろ。
A: そんな無茶な。できるだけ警備員に巡回させるようにするが、お互いマナーを守るようにしてくれ。とりあえず張り紙をする。
寸評:……
Q: シャワー室で石鹸を使う不届き者がいる。追い出せ。
A: 衛生を保つことを制限することはできない。石鹸の使用もシャンプーの使用も自由です。
寸評:どーして、こうも、他人の行動の制限を、施設側に押し付ける(しかも、制限する必要も規則もなさそうなことばかり−しかし、見張られてなければ備品を片付けないって、そんな民度が低い人間が世の中に存在するのか?)要求があるんだ? そりゃ、鼻水は……
やっと開通。しかし、大量破壊兵器がヒットしたわけじゃないようだ。
大して閑になったわけでもないのに、なんとなく面白そうなので、いきなりCSS使いまくってみようと考えた。多分、HikiやtDiary(順序が逆だ)のテーマをいろいろ見ているうちに、自分でもやってみたくなったらしいが、それを仕事でやってしまうのは特権のうちだ。
で、はまりまくった。バカですな。
しかも、途中で、フレーム使うかわりに、StrutsのTiles使ってみようとか、余計なこと始めたために、全然、仕事が進まないったらありゃしない。
って言うか、どうせIE限定なのに、ついWindowsマシンを動かすのが面倒で、SolarisでNetscape7(6はやっぱり馬鹿げて遅いし、4.7はCSSがまともに動かないのはいずこも同じ)で見てくれの検証してたために、作り直すはめに陥って、独りデスマーチ(と言っても金曜一日のつもりが、月、火の3日になったってだけだが)。といっても、しょせん、コアじゃない部分なんで、明日には終わる目途も立ったからまあいいや。
・ネットスケープは、文法エラーがあるとその定義の以降を無視するが、IEはその定義だけを無視する。
例)
div.dove
{
margin-top: 10px;
backgrond-color: #ffffff; # タイポ
float: left; # Netscapeは無視する/IE6は有効
}
しかも、256色しか出ない安物のグラフィックカードを使ってるもので、微妙な色は元々出ないから大して気にしてなかったから、まったく気付いてなかったとか。そのため、そういうもんだと思い込んで、ごちゃごちゃ複数の相矛盾した定義を入れまくってて、IE6で見たら、ぶっ飛び状態なのだった。
で、このテのバグを潰すのに半日(って言うか、気付くのに半日)。
さらに、実際に有効じゃないスタイルがあって、チェックしたり。後、スタイル区切りの;忘れってのも意外と多くて、コンパイルエラーの表示が欲しいとこだったり。
これが専業だと、さらにIE5、5.5……とチェックしてく必要がきっとあるわけで、そりゃ、フラッシュに転んだり、ネスケ無視したりするのも、生産性考えたらしょうがなさそうな気もするな。
こいつは適当に切り上げて、後はRubyでスクリプト書きまくる、と。
そしたら、スマートクライアントを導入。
作付け面積あたりの収益がでかければ、マンションを農園にすることができるわけか! で、毎日、水を撒きに出勤する、と。
元々、バージョン間の互換性なんてろくに考えてない(というより、互換性を重視してない)会社だから、さすがにそれは無いと思うけど、IEだけで5,5.5,6とチェックしなきゃならないんだから、それ自身がネスケを葬り去るための仕掛けだったり。
#レンダリングエンジン自身がCOMのコンポーネントのはずだから、Windows updateで、同一処理するようにできるんじゃないか? それとも既にそうなってるのかな。
そっかな? 1に勤勉、2に謹厳(本当はもう一回勤勉と書こうとしたんだが、なぜか、BじゃなくてGを打ってしまったが、意味的にはそれなりに正しそうだからそのままだ)というイメージなんだけどな。
たとえば、ワードパーフェクトが、ワードパーフェクト足りえたのは、ユタ州ならではの手厚いサポートを顧客に提供したからだ、とかを何かで見た覚えがあるし。
#まあ、おいらは、anti-christだからどうでもいいんだが。なんか、誤解しているんじゃないかと思うんで、なんとなくここに書いて見る
なんか、誤解を招きそうな表現だな、と感じる。
There's a kid in a script
God on pc in his hand
He's been learning all the codes
and he's writing all the methods
Today you bought a new language
Tried it on for web
Now you see the world through
Different colured editor
.
They're not writing
They're not playing
They're just having (fun)
Adventures in modern programming
...
昨日入ったイタリア料理店のタバスコ(は商品名、一般名は唐辛子ソース? それとも唐辛子酢?)が、ちょっと変わっていたのでメモなんだけど、今頃、書いてるため、ほとんどすべての固有名詞を忘れてしまった。
なんだ、1番有効な商品名は覚えてたじゃないか。
手にして、舐めての意識の流れを再現してみる。
・激辛、世界で一番辛いってわりには、全然辛く無いじゃん。
・見たこと無いなぁ、世界は広いってもんだ。
・原産国ベリーズ? いったいどこの国だ? (これは忘れてた)
・英語の能書きを読む。
・マリーシャープスおばさんの秘密のレシピか。ケンタッキーおじさんみたいだな、っていうか、タバスコもマクネーリさん(はSun)の秘伝のレシピのような。
・ベリーズってのはアメリカ合衆国じゃないけど、なぜ、アングロサクソンな名前(マリーシャープス)なんだろう。
・例えば、ハードオンのジェイソンヤングとか、ジャッキーチェンみたいな現地名から派生した英語名とか?
・でもウォーカーはニカラグア人じゃなかったっけ? いや、アメリカ国籍のままだったかも。っていうか、我が物顔で歩くなよ。
・じゃあ、早川真理かいな。っていうか、なんで早川がシャープなんだろう。
・上のステップで、早川真理と日本語化したために商品名を記憶できていたというのが正解。実際、リンク先を見つけるのに、早川真理→マリーシャープと逆変換した。
・しかし、全然、辛くないんですが。
・むしろフルーティ。
・ニンジンベースだからだよ。
・だから赤いのかな?
・着色料とかは使ってないようだ。
・どうして緑のタバスコ(ハラペーニョベース)は着色料を使うんだろ。
・緑は長持ちしないのかも。すぐ萎れるしな、ってのは関係ないだろうけど。(ほうれん草と、ニンジンを保存する場合のことを想像しているようだ)
・しかし、赤とか緑とか、毒だよね、色が。子供に触らせないためだろうか?
・青もやだね。そういや、サントリーが猛毒色のソーダのシリーズ出してたけど、どうなったんだろ。
・って言うか、全然、辛く感じないんだがなぁ。
・甘味のあるニンジンと唐辛子の組み合わせというのがミソのような。
・アバネロ(リンク先ページのうんちくに由来。商品にはハバネロとカタカナで書いてあったはず)が世界一辛いというわけで、マリーシャープス自体は辛くない。なぜなら、マリーおばさんの秘伝のレシピでニンジンをベースにしているから。で、ファイナルアンサーですな。
リンク先を眺めてからの追加分。
・実際に舐めたのはファイアリーホットだ。確かに、辛くないんだよね。
・サボテンが入ったやつがいいな。
太陽が昇るからだ
西の空が赤い
太陽が沈むからだ
渡河の最中、太陽が昇りきる頃、舟が沈む
(中国の黄色い大地)
11時45分頃がいいね
(サティ)
午前8時、9時の太陽のようにはつらつとしている
面倒だな。
デリゲート:VS.NETでWindows Form使う場合には(ほとんど)意識せずにイベントの通知を受けられるから、とても便利に見える。
VS.NETでイベント受信メソッドをIDEから生成すると次のようになる。
// これはForm#InitializeComponentに自動で追加
this.button1.Click += new System.EventHandler(this.button1_Click);
// このメソッドが追加
private void button1_Click(object sender, System.EventArgs e)
{
// ここが記述個所
}
もし、マウスの状態に関する情報を得たければ、これではだめで、Button#MouseDownイベントを使わなければならない。
// これはForm#InitializeComponentに自動で追加
this.button1.MouseDown += new System.Windows.Forms.MouseEventHandler(this.button1_MouseDown);
// このメソッドが追加
private void button1_MouseDown(object sender, System.Windows.Forms.MouseEventArgs e)
{
// ここが記述個所
}
で、これが何を意味するかと言えば、Buttonオブジェクトを利用する側にとっては、なんにも考えなくても(選択は必要だが)良いということだ。イベントへデリゲートを登録する部分はシュリンクされて隠された部分に自動生成されて、直接イベント処理の記述個所にカーソルが来るし。
しかし、Buttonクラスを実装する場合には、必要に応じて各種引数を持ったイベントの実装が必要だということになる。それはあたりまえだ。ただし、それらは、同じクラス内のバラバラのイベントとして実装することになり、多重継承ができないC#の場合、ほとんどの場合、ばらばらに複数実装することになる。
インナークラスの場合だと、呼び出し側はこんな感じ。
button.addMouseListener(new MouseListener() {
public mouseClick(MouseEvent e) {
...
}
....
});
エディターを使って直接記述することを考えると、このほうが楽なのは、イベントのレシーバの登録と受信メソッドの記述が同時に同一個所でできることだ。IDEを使う場合は、後述。
実際は、どうでも良いことなんだが、デリゲートの記述でVS.NETがサポートしてくれないタイプのやつははっきり言って、面倒だ。たとえば、非同期デリゲートは嫌いだ。だって面倒くさいから。
private delegate void FooHandler(int arg);
private void Foo(int arg)
{
Console.WriteLine(arg * 3);
}
...
new FooHandler(Foo).BeginInvoke(3, null, null);
非同期デリゲートを使う局面というのは、放り投げっ放しのワーカスレッド起動みたいなのがほとんどだから、呼び出し地点で何を行うかの記述が見たいはずなのに、デリゲートとメソッドの定義を外部に置いた上で、実際の呼び出しの記述を行うことになる。
いっぽう、無名インナークラスの
final int arg = 3;
new Thread(new Runnable() {
public void run() {
System.out.println(arg * 3);
}
}).start();
は、楽だ。
やはり、デリゲートの主眼は、IDEベースでの開発しやすさにあるんじゃないかと思う。
実際、JBuilderでEventListenerを実装させてみると、VS.NETでデリゲートを使用したのと同じようなコードの生成となる。
// 自動生成
button.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
button1_actionPerformed(e);
}
});
....
void button1_actionPerformed(ActionEvent e) {
// ここに記述
}
地獄のForteの場合(個人的にはお金があるのでJBuilderを購入してるんだけど、と言ってもバージョン6で打ち止めたが、会社はお金がないのでForteのコミュニケーションエディションだったりして)、外出ししないため、修正不可な部分にモーダルダイアログで直接埋め込ませる(だからヘルプの参照もできないし、インテリセンスも存在しない)ので、まだJBuilderのほうがましだが、なんか無駄なコードに見える。
で、どうでも良いと思ってるのは、結局、ユースケースが違うんだよね。
C#でのユースケース:
プログラマ →VS.NETで開発する プログラム
Javaでのユースケース:
プログラマ →エディターで開発する プログラム
だから、C#でIDEが利用できない局面では面倒だし、JavaでIDEを利用したい局面では地獄のようにイライラする、というだけのことだ。
コンテキスト、コンテキスト、コンテキスト。
これはとっても大事なことで、COM+まで、存在しなかった。MTSとCOM+の最大の差はコンテキストの有無だ。さあ、一緒にコンテキスト踊りを踊りましょう(by ドンボックス。PDCの講演から記憶をたよりに超訳)
……
でたー。どっちもSolaris9(リリース日付けが違う), Oracle9i(微妙に違う), J2SE 1.4.2, Tomcat 1.4.24。かたっぽは384MBで永遠に(多分。48時間耐久までは確認)動く。かたっぽは、1Gなら8時間動き、いきなり落ちる。256MBなら30分動き、いきなり落ちるか、またはGCが始まったきり、戻ってこなくなるかだ。VirtualMachineErrorさえ無しだよ、おい。
1.4.1の時、JITがおかしくなる(1万回くらいメソッド呼び出しを挟んでループする個所の呼び出し先で自動変数の取り違えが発生する−−多分、インライン展開のバグだと推測したが、1.4.2βで解消していたから投げなかった)強力なのがあったが、こんだのも厄介だね。
1.かたっぽは、384MBで永遠に動くんだから、こっちの世界のリソースリークが原因とは考えられない(って言うか、JVMより上の仕業ならOutOfMemoryErrorを喰らうだろう、普通)。
2.OracleのJDBCドライバーが違うから、多少、臭い。しかしthinだからJVMより上の世界だしなぁ。って言うか、OK側と交換しても変わらないよ。
3.GCの結果表示からは食い尽くしに見える。これについてはプロファイラで確認するしか無いが、1.からあまり期待はできないな。
あと、リロードさせまくってるとzip.soでシグナル10ってのも出てきた(が、こいつはリロード無効に本来はするから無視だ)。
とIE3のころから決まっているが、Netscape7のCSSで書いたことが、どうも嘘くさい。
;忘れで以降を無視するパターン、タイポで以降を無視するパターンは確実にあったはずだが、こんな単純なタイポでは再現しない。っていうか、そんなもの再現させてどうするんだと思わないでもないが。
もちろん、CSSそれ自体がキャッシュされている可能性は否定できないから、できる限り書き換えるたびに明示的に色を変える部分を作るとかやったんだが、わけわか状態なのは、相当アドホックに調べていったからだな。
#考えたらフォントが違うからどうにもならない部分ってあるわけだよね。
とりあえず、やっぱり、忘れることにしておこう。
dbox見てたら、ネスケが!マークを出しているのに気付く。
なんだろうと思ってクリックしたら、
次のWebサイトからのポップアップを許可
サイト
www.btm.co.jp
www.citibank.co.jp
www.mizuhobank.co.jp
www.smbc.co.jp
www.ufjbak.co.jp
って、おいらは、そんな設定をした覚えは無いぞ。
って言うか、りそなは蚊帳の外とか、シティバンクはなかなか愉快そうですなぁ、とかあるが。
設定ダイアログの「プライバシーとセキュリティ」−「ポップアップウィンドウ」−「許可されているサイト」ですか。
とりあえず、btmを削除して、btmのサイトに入っていろいろいじってみるが、Q&Aのポップアップとか普通に飛び出してくるしなぁ。
自動でポップアップするのを殺してあるだけで、クリックした結果としてポップアップするのはOKなのだった。その時点で!マークが表示されるということだ。
でも、ポップアップをブロックするということを考えると、Javascriptの動作を見てるはずだし、実際にどうやっているか見てみると
window.open(Link ,"BTMpop_qa","toolbar=yes,location=no,menubar=yes,status=no,scrollbars=yes,面倒なんで省略
で、まあ普通だ。っていうか、全ての引数を記述するんならlocation=yesにできるよ。というわけで簡易引数を利用するからアドレスバーが出ないというこの指摘はちょっと違うかも知れない。が、この指摘そのものは、そうやって流行が作られたのかも、という推測だから、今となってはどう呼び出そうが関係なく、location=noとするのが流行だ、と言ってるわけで別段、矛盾があるわけじゃない。
それはそうとして、なぜ、ポップアップするんだろう? と、JScriptを殺してあるIEで見ると普通に開いたりして。
<a href="qa/index.htm" target="BTMpop_qa" ……(省略)
なるほど、onclickが無効なら無効でtarget指定でリンクをたどるようになってるわけね。
ご苦労さまなことだなぁ。
しかし、考えたら、このシコミは馬鹿げてるよ。ベリサインの証明書を仕込んであるのと同じかなぁ、と一瞬、だまされそうになったけど、全然、違うじゃん。
証明書を仕込むのは、証明書を確認に行かなくても済むというか、CAがオフラインであっても有効だし、期限が切られている。(あぁ、でも、このへんの知識は不足しているな、嘘かも知れない)
でも、銀行のポップアップ許可を仕込んでやる必要なんて、どこにもない。っていうか、btmだと、JavaScriptが殺されてても動くように考慮してあるくらいだ(というか、こういう無駄なことに金を使ってるわけで、IT業界にとってはありがたいことかも知れないが、税金を払う立場としてはこの連中にこういうところに投資をして欲しくはないな)から、最初からシンプルに作れば、それでいいんじゃないだろか。それを余分なことしてるから、ブラウザー側でそれを助けてやるっというのは、なんだかなぁ、と評価されてしかるべきだろう。(しかも、デフォルト無効機能で、それを有効にしても、実は仕込みがある、という2重の安全弁というかなんちゅうか)
垂直ソフトウェアではむしろ、タイルウィンドウ(オーバーラップトではなく)を使うほうが、作業者にわかりやすい、という定説がある。オンラインホームバンキングも、同様に考えるべきじゃなかろうか。つまり、ポップアップを使うこと自体が的外れなんじゃないか、という意味だ。
#やっぱ、結論としては、別アプリケーションとすべきだと思うんだが、通信先が確認できる(というか、ポップアップでURLバーを隠すってのが問題となっているということは、実は、既に確認できない状態がまかり通っているわけだが)というブラウザーのメリットが失われるというのが難点となるんだろうか(多分、ならない。通信先を送り元サーバと限定する機構にバグがあるかどうかのみが問題であり、仕様として通信先の制限が規定されている)。
というわけで、東京タワーに行った。
子供の誕生日で何が食べたいか訊いたら焼肉屋で焼ネギだというから(まあ、他にもいろいろあるわけだが)連れてって、帰り、大体21時30分くらいかな、なんとなく道路が空いていたから、昔、好きだった(子供が。僕もそうだが、大体、子供は好きなもんだ。理由はまあいろいろ考えられるが、オレンジ色の非日常性とかが1番の理由かも)トンネルでも通るか、とちょっと青山墓地を通り過ぎて、ハリウッド化粧品の下を潜り抜けた。
踏み切りと言えば代々木で、トンネルと言えば六本木(龍土町というのが正しいかも)だ。まあ、大木戸ってのもあるが。
そこは、今や六本木ヒルズだが、そんなものには目もくれず、赤羽橋の5サ路(サの字はなんだろう? 辞書ひくの面倒なんでカタカナだ)を左斜め向こうへ折れて、東京タワーを下から眺めるとこへ出る。
でっけぇなぁ。
で、突然、思いついて、駐車場が営業してるのを確認して、1度、飯倉のとこで左折して、ようするに一周して、中に入った。
駐車代は600円。まあ、そんなもんだ。
それから、次々と金を払ったり、エレベータに並んだりして、展望台に入る。そういや、誕生日の人にはプレゼントがあると書いてある。しかし証明書が必要だそうだ。大人には免許証とかあるんだが、小学生にはそんな気の利いたものは無い。だから、素直にあきらめる。健康保険証を携行する習慣がありゃいいんだろうが。
エレベータが1分かけて、展望台へ着く。
暗い。
ああ、外を見るためには、ガラスの内側は暗くなけりゃな。
カップルがたくさん。でも、少しは、家族連れもいないわけではない。
海を見たがるんで、お台場の観覧車とレインボーブリッジであたりをつけて指差してみても、良くわからないようだし、実際、良くわからない。
しょうがないので、予定調和に、特別展望台へ行く。大体250メートルってとこだ。
また、金を払い、エレベータを並んで待つ。良くわからないが、大阪女と関東男のカップルが目立つ。意外と静かなので、喋る声が良く聞こえるからだ。
さすがに、良く見える。海はただただ暗い。ようするに海だ。かっては威勢を誇ってった貿易センタービルは見る影も無い。あのあたりが竹芝桟橋で、あっちが日の出埠頭と子供に教える。なんだか良くわからないようだが、それでもそれなりに楽しそうだ。
新橋が妙に明るい。新橋色とは無縁に黄色が目立つ。その手前には不気味な森ビル(かな?)が2つ。シムシティ2000のビルみたいだ。すごく犯罪が多そうな感じだね。
赤羽橋の5サ路が気持ちよい。三田へ向かって長く伸びるし、周りが比較的暗いから車のライトでガンビー君みたいに見える。
もっともそう見たのは子供で、東京タワーのマスコットの名前を覚える気もなかったから思い出せないが、にそっくりだという言ったからだ。僕は、ヒトデに見えたのだ。
そういや、ロバートワイアットにヒトデを歌った歌があったような気がする。高校生のころ、友人が「ほらヒトデってさ……(ニヤリ)」と言うんだが、現在にいたるも、全然、ヒトデ?? なんだが。
妻が、あの黒い広々は何かと訊くので、浜離宮だと答える。本当に黒い。昼は緑で夜は黒か。そこら中に、そういう黒い穴があいている。実際、東京には意外なほど緑が多いものだ。
霊友会が黒い。増上寺が黒い。宗教だから黒いのか? 愛宕山も十分に黒い。電波を飛ばしていたから黒いのか? いや、何より、東麻布の上あたりが真っ黒だ。あそこは一体なんなんだ? ロシア大使館から狸穴、東麻布にかけては普通に街の様相を呈しているのに、246の分岐した(名前はなんだ? 首都高の下の通りだが)道側からロシア大使館まで、真っ黒だ。
気になって地図を今見ている。麻布永坂町? なんにも無いぞ。さらに調べると、超高級住宅街で、衆議院議長公邸があったりすることがわかる。まさに死んだ町だ。人間がそこに存在する証明がそこには無い。
#それに比べて東麻布ってのは、まるでガオロンセンだな。十番から赤羽橋までの距離をちらちら左を見ると、ところどころの切れ間から向こうが見えるんだが、その怪しいことと言ったらありゃしないし。だが、実際に訪れることは無いのだ。多分、妙に坂があるからだろうし、実際、怪しいんだろう。
突然、黒岩涙紅を主人公にした山田風太郎の短編を思い出すが、確か、このあたりが舞台だった。
展望台の1階が帰り道だ。真下を見ることができるガラス張りの床がところどころにある。子供と二人で、下を眺めて高いなぁ、とか言ったり。だが、妻はガラスの上に乗るのを嫌がる。怖いから。でも、そりゃ変じゃないか? ある意味、強化ガラスの床のほうがわけのわからぬ新建材の床より丈夫なんだぜ。それに覗き込んで下を見ても平気なわけなんだから、高所恐怖というわけでもあるまいし。
そう思ったが別に口には出さない。実際に目に見えるものと、目に見えないものでは、本当は目に見えないもののほうが恐ろしいのだ。そこで自分が地上150メートルという場所に剥き出しの鉄骨に辛うじて支えられて立っているという事実に気付く。
だが、それだけのことだ。
外に出ると、なんだかわけがわからないが、路上に座り込んで眺めている連中が目に入る。なんなんだろう? なぜ、中に入らず、眺めているのか。そりゃ確かにでっかいし、中に入ればそのでかさは見えなくなる。でも、中に入って見なければ見えないものもあるのだ。でも、まあ、そういうのもありだろうなぁ、と思いながら、帰るのであった。
っていうか、金曜日だから7/18だが、サンドウィッチ屋の広告を誤読していたことに気付いた。っていうか、2週間してから見なおしたというわけで、普段いろんなものを見過ごしていることが良くわかる。
Encore plus France(もっとフランス)っていうコピーは、「あなたのおフランスをもっともっと」っていう意味じゃないんだろう。「フランスが足りない」という意味なんだ、きっと。
だから、GAPとベンツなんだ。それで、おフランスを補給するために、うちのサンドウィッチを食いねぇ呑みねぇっていうストーリーなんだろう。野菜が足りないからマヨネーズかけて野菜を食え、っていうキューピーの広告と同じようなコンセプトだ。
でも、それは日本で使う広告じゃないやね。
たとえば、別の国、たとえばソマリアでもベリーズ(カリブ海の国だとわかった)でもなんでもいいけど、の駅に、「もっと日本!」っていうコピーで、GAPとプジョー(別にヒュンダイでもなんでも良いが、ようするに日本車じゃないやつ。GAPが出てるからアメリカ以外がいいな)の街角の写真と、寿司屋(でも写真はカリフォルニアロールだったり)の食い物の写真を入れたポスターを貼って、それで意味が通じるのか? 通じるわけないだろ。
仮に何歩か譲って、件のサンドウィッチ屋がフランス資本で本国の広告をそのまま持ってきたと仮定したとしても、意味がわからな過ぎじゃないかな。
しかし、通勤時間ってのは、くだらないなぁ。
今日は、科学技術館で万華鏡作り。
椿の葉みたいに肉厚のを使う。ヘタ(と葉っぱでは言わないか)の部分を少し大きめに千切って、そこを内側にして巻いて行く。できたら、多少、平たく延ばす。
それを口に挟んで鳴らす。この時、唇は内側に巻き込むほうが良い。鼻の下を伸ばして、唇が外から見えない状態にするのがミソのようだ。
その状態で、強く吹いて音を出す。どうも口の内側に入ったほうが振動して鳴るみたいだ。したがって、葉巻をくわえるような感じにしてはならない。むしろ、外にはほとんど出ないほうが良い。
うまい子は、ブーブー比較的低い大きな音をすぐ出せる。どうにか鳴らすことができたが、そんなに簡単ではない。
うひゃー、楽ちん楽ちん。
少なくてもIDEを利用したWindowsプログラミングに関しては、TCW(OWL1), BCW(OWL2), MFC1(ぷっ), MFC2以降、WTL、C++Builder, AWT, SWING(JBuilder, Java Workshop(AWTだったかも), Forte)とは比較できるレベルじゃないし、プログラミングそのものについてはVBと比較できるレベルじゃない。
あまりに圧倒的だ。
電源が落ちてた。
クロンボ。たまたま見つけた山崎カオル氏のサイトから。
馬鹿でも丁でもとかもこれと同じようなもんだろうな。
(良く読んだら「黒坊主」ってのが安土桃山時代にあるってのも書いてあった)
いたら、思い出した小話。出典は忘れた。
国連がインターネット上で意見を募集した。
「食糧不足問題についてどうか自由に意見をお聞かせください」
しかし、まったく意見は集まらなかった。
アフリカの人々は「食糧」という言葉の意味がわからず、
西欧の人々は「不足」という言葉の意味がわからず、
南米の人々は「どうか」という言葉の意味がわからず、
東欧の人々は「自由」という言葉の意味がわからず、
アジアの人々は「意見」という言葉の意味がわからず、
そして、北米の人々は国連を知らなかったからだ。
思い出した。高橋悠治経由でMahdi Elmandjra(カタカナで書くとどうなるんだろう)だ。
using (Bitmap b = new Bitmap(640, 480)) // たとえばVGAサイズ
{
using (Graphics gr = Graphics.FromImage(b))
{
gr.Clear(Color.White); // 背景を白にしてみる
// いろいろ描いて見る
gr.DrawLine(Pens.Black, new Point(0, 0), new Point(639, 479));
.....
gr.Flush();
}
// 別にImageFormat.JpegならJpgで出力されるけど。
b.Save("d:\\home\\arton\\test.png", ImageFormat.Png);
}
だめだめ。
何がって、GraphicsPath#AddString。フォントがすごく汚い。
一方、Graphics#DrawStringはばっちりだ。
おそらく、原因は、StringFormatとlayoutRectの指定方法にあるんだろうとは予測できるんだが、Fontをそのまま利用できるだけに、見てくれが思い通りになるGraphics#DrawStringのほうがはるかに使い易い。
ただし、なんでもPathに突っ込めるから、APIはGraphicsPathのほうが使い易いし洗練されていると思う。
<IMG SRC="data:image/png;base64,.....">
ネスケ7.1は表示できるが、IE6はだめぽ。
HKLMHKCR\MIME\Database\Content Typeには、image/pngは登録されているし、ファイルならちゃんと表示される。
もうちょっと試して見るが、どうしてこう、いつも期待を裏切ってくれるのか?
ちなみに、RFC(2397 The "data" URL scheme)は1998年にはもう出ている。
Jpegでもだめだ。Jpegもだめなら、だめなんだろう、きっと。ActiveXコントロールをサポートしたりするより、こういう基本的なところをちゃんとやってくれよう。ネスケでも表示できなければ、こっちのバグだと思うんだが、あっちは表示できるんだよね……
s = ''
File.open(ARGV[0], 'rb') do |x|
s = x.read
end
data = [s].pack('m').gsub("\n", "")
s=<<EOD
<html>
<body>
<img src="data:image/png;base64,#{data}" ALT="IE使ってますね!">
</body>
</html>
EOD
puts s
というわけで、画像の動的生成はC#で簡単にできる。
しかし、HTMLにそのまま吐き出すことは今のところ無理ぽ。
しかし、事情があってサーバー側にファイルとして出力するわけにはいかない。しかも、IEは拡張子を見る腐れ仕様の持ち主だから、<IMG SRC="hogehoge.aspx&postできないじゃん。まあクッキーをうまく使うしかないだろうな。">がうまくいくかはわからんし(Content-Typeを見ないということはさすがに無いだろうから、これが有力候補だけど)、何しろ拡張子だからaspxを仮想的にPNGにするってのも問題ありそうだ。
って言うか、IE独自のDHTMLタグとかでdata:の代替がありそうな気もするなぁ。
大した話ではなく、単に
private void Page_Load(object sender, System.EventArgs e)
{
Response.ContentType = "image/png";
Response.BinaryWrite(makeImage());
Response.Flush();
}
とするだけ。いくらIEでも、拡張子がASPXでもContent-Typeは見るようだ。
やっとわかった。RFC1866 (Hypertext Markup Language 2.0)の8.2.1だ。URIやMIMEの資料を見ても出てないはずだ。
The default encoding for all forms is `application/x-www-form-
urlencoded'. A form data set is represented in this media type as
follows:
1. The form field names and values are escaped: space
characters are replaced by `+', and then reserved characters
are escaped as per [URL];
RFC2397で言及されているAでのURLの長さ制限についてちょっと見てみようか(ブロードバンドじゃ気にする必要は無いとは思うけど、10K越えてるわけだし)と思って読んでいたら見つけた。以前、読んだはずだけど、完全にこの文書そのものを忘れていたようだ。
[WebMethod] public void Foo(String xmlSerialized) { StringReader stm = new StringReader(xmlSerialized); XmlSerializer ser = new XmlSerializer(typeof(Bar)); Bar b = ser.Deserialize(stm); ...としてしまえば簡単なんだが。っていうか、バイナリシリアライズ+Base64とか、直接バイナリのPOSTとか、手段はたくさんあるんだが、自動生成縛りなんでそうはできない。結局、マニュアルならソース共有で構わないんだが、自動生成だと1度WSDLが噛むから別扱いになってしまう。
[Serializable] [XmlRoot] // ← これがミソ public class Bar { .... } public class Service { [WebMethod] public void ComeOn(Bar b) { ...
紀伊国屋で約10000円だが、アマゾンなら吹き矢の嵐をかわしながら44$だ。これなら船で山を越えても大丈夫。しかし、紀伊国屋で買ったわけで5000円近いお布施を国内産業に払ったってことになる。
しかし、読み始めて思ったが、別に読む必要は無いんだな、これが。しかし、書かれた知識はともかくとして、それを記述する能力ってものが差として厳然とあるようだ。
特に序文に書かれている、narrativeとreferenceという切り口は重要だ。もちろん、こういうスタイルの本はよくあると言えるんだが(たとえばGoFデザインパターン)、
人間の脳の働きというか思考をソフトウェアで記述する試みがAIならば、ビジネスをソフトウェアで記述する(ためのモデル化の段階の)試みがエンタープライズアーキテクチャで、多分、AIと同じように、バベルの塔だろう。
にもかかわらず、非常にエキサイティングなのは、それがまさにバベルの塔だからに違いない、と思う。
ただし、この本は名前のとおり、エンタープライズアーキテクチャについての本じゃなくて、エンタープライズアプリケーションのアーキテクチャパターンの本だけど。
もちろん、バベルの塔を作るためには、権力、資材調達、労働力調達、資金調達、労働力配分、設計、資材選択などなどなどなどなどなどなど、もろもろもろもろもろもろの活動があり、だから、神を怒らせたわけだろうが、要するに人間様が人間様であるために1番重要なもののひとつがそこに収斂しているわけだ。収斂するっていうのは、集約するってのとは違う。
かも。紀伊国屋で思った。日本がロボットの国じゃなければ、ロボットスモーなんてタイトルは付かないだろう。やりたいこと、やらなければならないこと、がはるかに少なければ、この本読みながら、スモートリを作りたいなぁ。分身!(快楽篇の変身!のように)
というか、これ、高専対抗とかNHKで良くやってる(わけないが、たまに見るTVがそんなのだから、「よく」とか形容しちゃうんだろうな)あれの公式ガイドなんだろか?
MINDSTORM本も目立つ。あとなんかおもしろそうだったのが、忘れちゃった。
微妙に意味は違うんだが、ファウラーの(ここは署名が無いからファウラー自身のパートだろう)レコードセットパターンを俺定義したもの(と最初に微妙に違うと書いていながら付け加えておく)がやっぱり正解だろう。
最初にクラスから値オブジェクトを導出してXMLシリアライゼーションの対象とするアプローチより、XSDでスキーマを決定して単純にレコードセット化するほうが、VS.NETでの開発は遥かに高効率だ。
どうも、頭の中でモデル化するとき、操作を中心に考えてしまうからクラスで考えてしまうんだが、その方法はうまくいかない。あとから分散を意識した時点で無理矢理になってしまう。つまんねぇな。
逆に、データオリエンテッドにスキーマを決めていくと、ぴったり嵌る。
あーそうか、だから、MSがDOAを持ち出すのは、必ずしもユースケースドリブンに対抗するためではなく、VS.NETを中心にした開発戦略に合致するからなのか。
スキーマからモデルを作っていくと、操作はどうしても外付けになるというか、操作を考えてもしょうがない(実現手段が無いから)。
重要なのは、OOかどうか、DOAかどうか、分散か、集中か、ではない。まったくない。
おもしろいかどうかだ。
が、それはおいておくと、いかに正しいかだ。
が、それもおいておいて、(なんか、重要なことは、すべて、ビジネス的に意味がなかったり、不可能だったりする)、開発効率と運用効率と、実現された処理の現実性(すべて合わせてROIってことになる)だ。
My apologies to those who like Smalltalk, Delphi, Visual Basic, Perl, Python, Ruby, COBOL, or any other language. I know you think you know a better language than Java or C#. All I can say is I do, too!読者層を考えた順序のようだな。 Smalltalkが1番なのは出自から当然だろう。どうも、エンプラ開発は、噂と違ってアメリカでもDelphiは強いんだろう。VBも当然だ。そしてスクリプト三国志がきて、COBOL。でも、JavaとC#じゃなきゃ現実じゃないよね。 って言うか、このおっさんは、独特の文体/言及を持つところが好きだな。
IMG SRCがCGIと言えば、Webバグだが、こういうこともまあ、あるかも知れないなぁ。
Smalltalk, Delphi, Visual Basic, Perl, Python, Ruby, COBOLプログラマーなら、JavaやC#のコードくらい読めるだろうとか。VBerとCOBOLerには無理か。
[XmlInclude(typeof(Foox))] // ←ミソ class Foo { virtual public string Seven { get { return null; } set { throw new NotSupportedOperation("are you sure?"); } } } class Foox : Foo { string[] seven; override public string Seven { get { return seven; } get { sevent = value; } } }では、ちゃんとFooのプロクシにstring[] のインスタンスが生成される。
インターフェイスのスタブの自動生成がサポートされている。これ、2003じゃないVS.NETにもあったかな?
ないんじゃないかな。: Ixxxxと書いた瞬間に「タブを押せばスタブを生成する」と薄いグレーでヒントが表示されたけど、これは初めて見た気がする。
これは、無茶苦茶、楽だ。(他のインターフェイス継承を持つ言語の統合環境は知らんけど)
Nunit試そうと思って忘れてた。
以前から気になってた北新宿から方南通りを中野のほうに山手通りを渡ったとこにある店に行った。
港ダックと北京ダックと2種類あるんで、何が違うか訊いたら、港ダックってのは骨付きだそうだ。興味を惹かれたら、何か察したらしく、しきりにお勧めは北京ダックだと言う。とりあえず、お勧めにしたがうが、あれは何かありそうだ。だって食うに耐えない代物ならメニューに書くはずがない。きっと、通好みだとか(で、それを食べて気に入らなければ、それはこちらが普通であって通でないというだけの問題だからこちらの問題だ)なんとか。
で、食べたら、うまかった。皮の焼け具合とそこからくる香りが口に合った。もっとも子供は、この店のはあまり好きじゃないから、皮を残すから肉だけ食べると言う。認める。でも、肉も食べたいから、皮だけ食べることは拒否する。それでも結構、食われてしまった。確かに、ダックダックしたダックかも。
もともと子供は水なんだが、店の人が、脂っこいの食べた後は熱いほうが良いね、と子供にも茶を持ってくる。
鴨にはなるなと、あの時、鴨は言ったか? 会田鴨。
コネクションのキープアライブが、矛盾してるんだよな、ははは。
って言うか、RSTやFINを受けたことを、上位に判定させないクラス構造が腐れてるだろう。(java.netもそうだったような。非同期メソッド使えば判定可能なのかな?)
やっぱりな。
[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://tempuri.org/")] public enum GraphicsUnit { ///これ自身は、enumだから、整数として利用可能。したがって、プログラム内で、World, ....
GraphicsUnit g = World + Pixel; // 実際にはGraphicsUnitでは複合化はしないと記述しても問題ない。これが、複合化enumだ。 しかし、SOAPパケットを見ると
<Unit>Point</Unit>と、文字列として記述される。これは、XSD仕様から正しい。 ようするに、C#のenumの仕様が腐っているのが原因だ。 もちろん、気持ちはわかる。 強い型付けをしたい場合に複合が必要な場合はある。
void SetFontSylte(FontStyle s); foo.SetFontStyle(FontStyle.Bold + FontStyle.Italic);しかし、これはXSDのenumeration(xsd:restriction base="xsd:string")で表現できない。
<!-- こうは書けない --> <style>Bold+Italic</style>したがって、複合化されることがあるenumをXmlSerializationする場合のベストプラクティスは、以下のような定義だ。
[serializable] class Foo { private EnumHoge hoge; // 分散用publicプロパティではintにする。 public int HogeValue { get { return (int)hoge; } set { hoge = (EnumHoge)value; } } // 非分散のアクセスにはこちらを利用する。 // もし、publicアクセスが必要なら、このクラスはプロクシ生成用の // 値オブジェクトとして、別にホンモノを用意するしかない。 internal EnumHoge Hoge { get { return hoge; } set { hoge = value; } } }これだと、XMLシリアライゼーションは、HogeValue要素で行われるため、整数値として複合化された値が利用されるからだ。
見識。でも、次で導入されるんだっけ?
多くのユースケースでは、FontSylte.Bold + FontStyle.Italicな型強制が有効だから、C#の選択が悪いとは思わない。それが、Webサービスと合わない部分があるということだが。
rufeinさんと、joesaisanさん、どうもありがとうございます。当然のことながら、はてなアンテナを開発された方と、tDiaryのリンク元機能を実装された方(たださんかな)。世界を広げるのに役立たせていただいてます。
_ 上のほうで「複合化」とか書いているが、正式にはビットフィールドとして扱うことが可能な=フラグ属性が付いた列挙ということのようだ。
Soapプロクシジェネレータがこの属性値を見た場合、シリアライズ時に自動的にintへ変換する(かつXSD上はxsd:intとする)というのが理想的な対応になるだろう。
HTTPSでなぜ可能かは、パケット自体を見て見るしかないが、何しろHTTPSだからなぁ。サーバー側にフィルタをかまして、HttpRequestから直接読めばいいんだろうが、いささか面倒なんで謎のまま放置しとこう。予想1:HTTPSならバイナリシリアライゼーションを利用している(どうせ可読性は無視できるんだし−が無茶だろうからありえないだろう)、予想2:想像もつかない単なるバグ。
それより、放置後のタイムアウトが気になる。どうしようかなぁ。
おかしいな。24歳過ぎても、まだ出てかないな。
ちぇー、バグで永遠にプレイできるのかと期待しちゃったのに(そんなにやる気はないけど)。結局、25.8?歳でお別れになった。
オプトインなのは好感が持てるし、プレゼント応募なんで住所を入れさせるのは当然として、年齢もゾーン区切り、職業もたった6種類と、考えてみたらファッション性があるわけでなし、相当大雑把なくくりなのは商品特性から当然かも。また、単価が比較的高いから、薄く広くマーケティングを行う必要もないとか、いろいろ有利な点もあるのだろう。
それでも約2週間の育てゲームでお別れがあれば、一抹の幽愁があるのは事実。
雨粒坊やが空に帰る、NHKファンタジーの雨だれをなんとなく思い出したり。
なんとなく、飛ばし飛ばし読む。
こういうのって、この世界だけの話なんだろなぁ。たとえば、みねろうさんちにNet::HTTPいっしょに作りましょうって押しかけるとか、まつもとさんのとこにいきなりRite合同で作りましょうって押しかけるとか、たださんとこにtDiary……なんてのは、いささか考えにくいのは、少なくても一定の技術的な振るいがあるからだろう、と思う。としたら、そもそも同人ってのはそんなに敷居が低いのか、それともやはり敷居は厳然としてあるのに、勘違いしやすいのか、なんなんだろう。
多分、勘違いしやすい、のだろう。上の状況がありえたとしても、ほとんど、それこそ江戸時代とかの、親方おいらを修行させてやってつかぁせぇのノリにしかならないのに対して、こっちのは対等なつもりに見えるからだ。でさらに後が怖いと。
とは到底思えない日が続くので、気分はまだ6月。しかし、着々とその日は近づくのであった。
public class GeneratedSpecialized : SoapHttpClientProtocol { ... } ... for (;;) { using (GeneratedSpecialized s = new Specialized()) { s.Url = "http://...."; s.WebMethod(); } // 暗黙にs.Dispose()が呼び出される。 Thread.Sleep(300); // 相手IISのセッションタイムアウト時間 }とした場合、相手からのRSTを受けているにもかかわらず、同一ソケットを利用して2度目のリクエストを出している。
public class ProxyProxy : GeneratedSpecialized { protected override WebRequest* GetWebRequest(Url u) { return WebRequest.Create(u); // 常に作り直し } }うまく行くだろうなぁ、と思うが、なんだかなぁ、という感じ。
************** 例外テキスト ************** System.InvalidOperationException: XML ドキュメントを生成中にエラーが発生しました。 ---> System.InvalidCastException: 指定されたキャストは有効ではありません。 at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriter1.Write13_Register(Object[] p) --- 内部例外スタック トレースの終わり --- at System.Xml.Serialization.XmlSerializer.Serialize(XmlWriter xmlWriter, Object o, XmlSerializerNamespaces namespaces, String encodingStyle)Flag属性enumとは関係ないようだ。なんでだ?
protected override WebRequest GetWebRequest(Uri uri) { HttpWebRequest wr = (HttpWebRequest)WebRequest.Create(uri); if (last) // 連続してリクエストを出す場合、最後のリクエストのみ設定 { wr.KeepAlive = false; } return wr; }結局、まともにHTTPと付き合う必要がある。ちなみに、HttpWebRequest#Connectionに対して"Close"を代入すると例外になる(MSDNに明記されている)ので、KeepAliveプロパティを利用する。
わかった。と思う。バッファリングの最中に、シリアライゼーションが完了したと思って、誤って送信してしまうからだ。Content-Lengthが良く見るとおかしい。
その結果、500なレスポンスがHTMLで戻ってくるから、デシリアライゼーションに失敗しているというのが、InvalidCastExceptionなんだろう。
試す気は無いが、LifeTimeServiceのデフォルトの有効期間が5分らしいので、これで引き伸ばすというテもあるようだ。
でも、この場合、SoapClientProxy自体をdisposeしてnewで作り直すようにコードしているわけだから、仮にうまく動いてもこれは変だと思う。
今日動かしたら動いた。条件がまったくわからないので、完全に忘れることにする。
どうして、2003だと早いのだろうか、というような話を聞く。
無実だったこっちをまともに試してみる。
結論: 最初に出会ったビットだけがリクエストに乗る。つまり、使えない。というわけで、これが原因でInvalidCastExceptionにはならないものの、設定値が正しく送られるとは限らないのでintでくるむ必要はある。
磨り減ってくのは、多分、1日にできる何か、ってことかなぁ。睡眠時間を充電時間と考えて、1日あたりに使用可能な容量が消耗するんで、真夜中の油(逆に日本語がわからない表現)を使う気力がなくなるってことです。
#これが仕事(カタカナの「ビジネス」ってやつ)でなければ、あー、今日も一日ハックしたぜ、って感じで爽快かも知れないけどね。どーしても仕事は仕事と割り切る部分が無いわけじゃないから、爽快ってのとは微妙に違うんだけど。
いやぁ、柄にも無く育てようと考えると片端から巣立ってしまう罠。むしろ、やる気がこそげ落ちかけていそうな(=本来やる気ががある)あたりが、きちんとやってくれました。って言うか、その人が本来持っている能力を本人が自由に引き出すことを可能にするためのシステムでしょう。まあ、逆も真だったりするわけですので、戦死者もいたりはします。って言うか、さらに一段、抽象度を上げて書かなきゃいかんなぁ。
#実際に動き出した後に、どれだけ後腐れが無いかが、本当の勝負所。とは言え、サイコロ自身は既に投げ終わってるわけで。
ジェズイットを見習え |
_ b [バーカ]
_ arton [まさに虫の声だな。]