著作一覧 |
あまり同意できない(「あまり」がつくのは、100%じゃないから。というか、僕はなんにしても100%ってのは好きではない)。
関数呼び出しの()もそうだが、特に
しまいにゃ attr_accessor とかが設定されてるインスタンス変数まで、関数的メソッドのように呼んでたりするからブチ切れそうになる。アットマーク一つすら書くの面倒かよ。
の箇所。
面倒かどうかではなく、常にフックを入れることを念頭におけばそういうコードになるはずだ。
特に、メンテナンスフェーズ以降(つまり話が逆なのだ)。
以下、Javaで示す。こういった方法については、言語は選ばないと思うので、JavaはそうかもしれないけどRubyは違うということはないと僕は考えている。
public class Foo { State state; public Foo() { state = State.Start; } public State getState() { return state; } }アクセサを呼ぶというのは、上記のクラスのメソッドの中で、
void bar() { if (state.doSomething()) { state = state.nextSate(); } else { state = StateFactory.create(state.getErrorCode()); } }と書かずに、
void bar() { if (getState().doSomething()) { setState(getState().nextSate()); } else { setState(StateFactory.create(getState().getErrorCode())); } }
と書いているということと読める。Rubyと異なり、Javaはアクセサがゲッタ/セッタメソッドだということが明示されているので良いということかな? と書いているうちに思ったので、C#に変えてみたり。
State state; public State State { get { return state; } set { state = Value; } } void bar() { if (State.doSomething()) { State = State.nextSate(); } else { State = StateFactory.create(State.getErrorCode())); } }
なぜ、メソッド呼び出しのオーバーヘッドがあるにも関わらず自インスタンスのフィールドのアクセスにもアクセサを経由すべきなのだろうか?
それはメンテナンスフェーズにおいて、以下の状況が常にあるからだ。(逆になさそうだったり、モジュールの入れ替えとかになんの障壁もなければどうでも良いといえば良い。とはいえ、入れ替えって結構神経質にならざるを得ないから、修正は少なくすませたい)
状況)
時々エラーになって異常終了とか、ログ吐いて死んだりする。しかし、開発環境ではまったく再現せず、資料採取も現場状況から頼み辛い。
結局、こういう場合、実機に仕込むことになる(のが許容される場合については、だけど)。
で、多くの場合、予想もつかないステートに陥っていたり、予想もつかない入力があったりすることが原因で、それをどこぞのルーチンが掴んで問題となるのだ。したがって、入出力の監視が重要。
そのため、迂遠ではあるけれど、まずは
public State State { get { // スタックトレース(呼び出したメソッドの特定のため) // と現在の値をログ return state; } set { // スタックトレース(呼び出したメソッドの特定のため) // と現在の値と次の値をログ state = Value; } }
Rubyなら
#attr_accessor :state # 1行で済むならコメントアウトでもよいかも def state=(val) # ログ @state = val end def state # ログ @state end
と修正したモジュールを実機に送り込む。ログを吐く分、若干効率は落ちるが、ロジックそのものには影響がないことが、diffによって明白(差分がアクセサだけであることがだれの目にも明らか)な、特別版である。
これが、直接フィールドをいじくっているとさあ大変だ。
もちろん、すべてがすべてアクセサを利用するわけではない。だが、まさにいつか誰かのソースで問題が起きたり、忘れた頃の自分のソースに問題が起きたときのために、ここぞというフィールドについてはアクセサを利用する。
と、僕はアクセサを使うなぁ。(と同時にアクセサ原理主義は大嫌いなので、基本はパッケージプライベートで、privateは基本的に利用しないのでもある。スコープの広さとか、クラスのサイズとかに依存してそのへんはいろいろ)
追記:簡潔さと柔軟さ。sumimさんのコメント。上のコードからも垣間見えるけど、言語によって簡潔さが十分にサポートされるようになってきたため(フィールドの直接アクセスと見た目が変わらないC#(3.0だとフィールドの記述そのものが不要化される)、直接アクセスよりさらに手数が少ないRuby)、柔軟さの勝利かと思いきや、新たな論点が生まれてきたようで興味深いという話。そうやって論点が必ずでてきて、その摩擦熱で少しばかり前進するってのが人間のおもしろいところ。(根っこは同じじゃないと思うな。マクロはユーザー定義なので記述した人固有の知識。それに対して言語の機能は共通の知識)
で、結局、バランスといっても人それぞれ、読みやすい/にくいも人それぞれ(だって、出身言語で(x,y,z)と書いてあるとタプルだと思っちゃう人だと、メソッド呼び出しに()が付いていると読みにくいかも知れないよ)なので、結局、あるソフトウェアシステムを構成しているソースについては統一を取っておいて、それに慣れようぜ、とやるしかないのかも。
で、その規約に対する意識がドイツ風(車線厳守、速度自由)か、アメリカ風(車線自由、速度厳守)(と、さっそく援用したり)、万能魔人村章風(風の吹くまま気の向くまま)とかいろいろあるのでさあ大変だったりするのだが。
#突如思い出したnobsun語録。「だってRubyのメソッドの引数はタプルだから」……ってことは()を付ける派か。
簡潔さの例
柔軟さの例
いいなぁ。
というわけで、「午年」(と実際に手書きの漢字でタイトルが出てくる)。ジム ジャームッシュとのコラボレーションというより、バビロン出身のストレンジャーな映画監督に孤高のロックンロール野郎が漢を叩き込むストーリーとも言える。途中にはさまるニールヤングの息子が書いた絵が映画になるシーケンスとか(絵で描いた汽車が動き出すんだけど、汽車と映画の歴史にまた1ページと言っても良い美しさ)。またインタビューが強烈で、田舎のオヤジが集団で、都会出身のオシャレな若造(じゃないんだけど、年齢差があるのでそう見える)に、おめぇのようなチャラい業界の小僧にはわかんねぇだろうが、いっちょ教えてやるからよく聞けよ、みたいな感じで、それをあのくそ生意気そうなジャームッシュが神妙に拝聴しているのがいい感じ。
イヤー・オブ・ザ・ホース [DVD](ジム・ジャームッシュ)
(突然わかったというか、別のほうのにちゃんと書いてあるのに気付かなかった。)
妙な生き物だけど、こいつらがいない世界というのは味気ないだろうな。
僕の目はネコの目、暗い夜道にきらりと光る
僕の目はナマコの目、じっと空を見上げてる
……
僕のマナコはナマコのマナコ、駒の独楽が狛に困。
……
全然違った(10年振りくらいにiTunesから流れてきた)。
あーきみがすきだーよー
にゃーぎゅうにゅうもすきーごーごー
ついでにおなかもごーろごーろ
月からはるばる地球にやってきたとして、アリゾナやサンディエゴあたりの砂漠を眺めて、郷愁を感じたりすることはあるのだろうか?
10代の頃(今でもそうだが)、中央高速を新宿へ向けて走ってきて、京王プラザが見えてくると(水道どおりのガスタンクあたりから)、ああ、戻ってきて嬉しいな、と感じたり、あるいは246をずっと上ってきて赤坂見附のところで(実際には金王神社を上ったあたりで、やっと帰ってこれたぜ、みたいに感じたわけだが、人によっては、向こうに山、(多分畑があって)その手前に民家、その手前に道路っていうような風景にほっとしたりするのだろうか。
ごく子供のころ、羽田空港に近づいて巨大なネオンが林立するところで妙にわくわくしたものだが、今でも首都高の高樹町から芝公園まであたりの光景にはわくわくするのだが(こないだ、パシフィコ行くのでひさびさに通って再確認)、この風景がもたらす幸福感は、万人に共通の感覚なのだろうか? 風景に依存するのだろうか、記憶に依存するのだろうか、それとも造形と構図に依存するのだろうか?
∀ガンダム MEMORIAL BOX 1 [DVD](朴ろ美(「ろ」は「王」に「路」と書きます).高橋理恵子.村田秋乃.青羽 剛)
ここまで勧められて無視するのは無理だよなぁ。
その話とは直接は関係ないのだが、
特に劇場版(つまるところはダイジェストであり、テレビ風にいうと総集編ってやつ)だから目立つのだが、映像作品に向いたものと、文字作品に向いたものがあるとして、こういう作品は別の表現方法に向いてるんじゃないかと思った。その表現方法(メディア)が何かはわからないが。
---以下風呂敷がたためなくなったのでメモだけ
文字作品のよいところは、その不連続性にある。
たとえば、ある特定の単語、言い回し、描写、会話が気に入ったとする。そこで本を置き、いくらでも反芻して、敷衍させたり、想像したりできる。つまり時間軸がない。それをうんと利用しようと考えればコルサコフやバラードもそうか、マラルメも、構造を一度ばらばらにして、再配置できる。
ところが、映像作品の場合は、そうではない。
(音楽はどうだろうか? 少なくても純粋音楽の場合、もともと普通の人間には縦軸を完全に分離できないことから、また少し異なるように思う。構造を完全に把握するには、スコアの読解が必ず必要となるので、演奏はスコアのプロトタイプとしての意味しかなくなるからだ)
おお、良いシーン、と思って、そこでちゃかちゃかまきもどして見直したり、ポーズしたりというようなメタな見方が可能なのは、2回目以降ではないだろうか。しかももともと、劇場で1度見ることを前提としているので(ただし演劇と異なり、同時に複数個所で上映するという、多重性は考慮されている)、実際には寸断して見るとそれだけで印象が異なる。(追記:テレビ作品は、再放送というかたちで複数回の視聴を考えることができるし、現在はビデオの販売という形式も可能なので、この時点で元の作品からは切断されている)
いや、例外はあって、あらかじめモンタージュを意識、と書いて気づいたが、カメラ=万年筆というのは、写実だけではなく連続性に関するものを含むのかな、スナップショットであれば断続だし。
なぜ、ロメールは音楽を使わないのか(少なくても教訓シリーズより前は)とか。音楽が連続性を支えているからだと思う。なぜ、ゴダールがずらして入れたり、混ぜ合わせたりするか、とか。
いつでも映像作品を見るというのは、すさまじい集中力を必要とする。入ってくると同時に、音と構造と構図と位置と言葉と目線や物語、時間のようにその中に複数存在するベクトルといった要素を分析しなければならないからだ。
しかも、そのうち1つにでも異常があれば、そこを再検査することになる、とやっているうちにも次に進んでしまうし、バッファはせいぜい数秒分しか取れない(というか、他の人たちはバッファがおれよりでかいのかも知れない)。処理が追いつかなければ昏睡してしまうし、処理すべき内容がないと退屈して寝てしまう。そのバランスは難しいだろう。
それだけに映像作品には、あまりに大量のコンテキストは詰め込むことができない。
よく利用される手法は物語に神話を利用することだ。この場合、物語に関するすべてのコンテキストは既知のものですむため、観ている最中に意識する必要はない。手が自然にプログラムを打つように、手が自然に魚をさばくように、反復練習の結果として、無意識のうちに処理できるからだ。この手法を利用すると、映像から意識しなければならない要素を減らせるので、より精緻な見方を与えることが可能となる。ギャング映画や、ポルノ映画、西部劇、ミュージカルのような、大衆娯楽作品にこそ優れた映画が出現する道理だ。ひとつの理由として、これらの作品は、物語を意識しないですむため、批判の対象として正しく観察できることが考えられる。単純に分母が大きいのですぐれた作品が入りやすいということかも知れないが。
Javaという言語とかの話ではなく、Java界隈という言い方が正確かな。
どうにも前から気に入らないところがあって、そしてどうもそこに良くない点が集約されてるような気がしてならなかったのだが、keisukenさんのところを読んでいて、なんとなくわかったような気になった。
つまりJakartaの存在ということだ(※)。
次のやりかたが単に古いだけということはありえるかも知れないが。
新しい技術を利用してシステムを開発するにあたって、とりあえずは数名で先行して動くわけで、その過程で、練習をかねたりして細かなツールやらユーティリティやらを作っていき、それがチームの道具箱に入っていく。それがあらゆる意味でのベースのインフラとなる。サンプルソースにもなり、拡張の練習、更新方法の練習、変更した場合の影響の実験(というか死にそうになったり)、バグパターンの発見もあったりするわけで。新人には、使い込むうちに錆が浮いてきたやつのメンテか、そのへんを参照してよりベターなデザインのユーティリティを作らせてみたり。かくして、この道具箱の中のソース群は生きたコーディング規約であり、チームの文化の根源となる。
そういう順番でやってきているので、そういうものだと思っているし、それは良いプラクティスだと考えているのだが、どうもJava界隈ではそう考えられていないのではないだろうか、ってことだ。
新しい技術を利用してシステムを開発するにあたって、とりあえずは数名で先行して動くわけで、その過程で、どっかのレポジトリを検索してユーティリティを取ってくるのか?
もちろん欠けているものや、そこまで手が回らないもの、あるいは時間が不足しているという理由から、借りてくることはある。具体例だと、特殊なクラスローダはStrutsから抜き出したし、javacの呼び出しはJasperから抜き出した。プールは最初はcommonsを使っていたようだが、途中から、独自のものに切り替えたみたいだ(ここは担当してなかったので良くわからないが)。
道具箱の中が、他人の作ったものばかりで、仕事ができるんだろうか?
Javaの開発はユーティリティクラス作成からはじまる
いや、メインフレームの時も、SYSVのときも(sh、C、いろいろ)、Windows 3.0(C++だな)の時も、COM(C++とVB)、ASP、CE、Java、Ruby(Cライブラリとの互換スクリプトがたくさん)、ASP.NET、常にユーティリティクラスの作成から始めているが、それは特殊なのだろうか?
#なんか特殊な気がしてきたから、どうでもいいや。
※もちろん、Jakartaプロジェクトが、commonsを持っていることは当たり前のことだし、それを公開していることも良いことだ。そうではなく、たかがcommons程度のものをブラックボックスとして当然のように借りてくるところ(いや、解剖学的にソースをすべて確認して、その解析結果をチーム内で共有してとかやってるところもあるだろうから、それなら結果は同じだとは思うが、そんなことするより作ったほうが良いとは思うが)。なんか、練習もなしにいきなりでっかなシステムを組み始めてひいひい言っているんじゃないか、と思えてしまうところだな。もちろん、それ以外に道具箱の中に山ほど作らなければならないものがあって、それで満載されていて、脇のポケットにcommonsも入っているということもあるだろうから、それはそれで良いのだが、でも粒度的にも、必要度からも、処理の難易度からも、ちょうど自分達の練習で作るべきものをcommonsで代替させているんじゃないかなぁ、と感じるところがあるのであった。はいはい、車輪の再発明ね。
追記:多分、誤解はされてないようだけどkeisukenさんがうんぬんってことではないです。ネガティブな意味での「ユーティリティクラス作成からはじまる」というのとcommonsの合体技が、漠然と感じていたcommonsマンセーなJava界隈に対する不快感をうまく表してるな、ってことで。JavaのAPIについては、1.4からの参入だったことと、stdioやlibcとの比較になりやすかったという点から、ほとんど天国でしたね。Rubyとかは別問題だと思っているし(あの面倒くささも固さのうちというか)。
ときどき面倒になるので、言語(とりあえず、英語、仏語、台湾語、韓国語、イタリア語、ロシア語あたり)を指定しておくと勝手に翻訳してくれるといいな。原文を読みたければ、どちらにしても、元記事を参照すれば良いのだし。
ダグラス・サーク コレクション DVD-BOX 1 (僕の彼女はどこ/心のともしび/天の許し給うものすべて) [初回限定生産](チャールズ・コバーン)
ダグラス・サーク コレクション 2 (初回限定生産) [DVD](ロバート・スタック)
なんとびっくり、こんなものが。
まずは、最優先でこっちを買う。というか予約する。
9月になったのに子供の夏休みの宿題のために、プラネタリウムに行く。というか、五島プラネタリウムが消滅して久しいし、六本木のは単なるムードだけみたいだし(解説を元にレポートしなきゃならないらしい)、未来館は飽きた(というほどは通ったわけじゃないが、ちょっと新味に欠ける)。
で、いろいろ調べたら、夏休みが終わったもんで軒並み休業してしまったりしていて(本命は武蔵野のやつだったのだが)。残っているのは川崎かお台場か。
で、お台場のソニーのやつに行った。
最近のプラネタリウムの例に漏れず、11等星まで表示とかだから、子供のころのプラネタリウムみたいに、どっかの砂漠から眺める地表からの最高の星空ではなく、大気圏外からの最高の星空というやつで、つまりはエンタープライズだの大和だのから眺める景色ってのはこんなんなんだな、とか思うと実に不思議な感じ。
とりあえずはシリウスから始まって冬の大三角経由でカノープス、そのまま南天に入って、ケンタウロスのαで、ああ、あそこから自分を疑うアンドロイドが細身で妙にねじれたナイフとともに裏山に到着するんだな、とか考えているうちに南十字星、でまた北天に戻って、アルクトゥルス、スピカ、北斗七星で春の大曲線の紹介。
そいういえば子供の頃みた五島プラネタリウムだと弁士が、懐中電灯(ってこたないだろうが)のポインタで空を示して解説すると、青白い線で描かれた星座の絵が星に重なって神話の説明とかやってたもんだが、今のは違うなぁとか思い出してみたり。
で、多分、そこまでが常設の説明かな。
で、惑星の話になり、太陽の光を反射してやはり一等星として見えるというから金星とかになるかと思うと、妙に暗い星がポイントされる(このプラネタリウムでは注目すべき星の周りを青白い輪が囲むのである)。
あれが一等星か? と疑問に感じるのだが、多分、そうなんだろう。
でクローズアップして土星となる。ああ、なるほど。
最初はガリレオが、それまで戦争の道具として水平に見るものだった望遠鏡を垂直にすることで天体が見えるということを発見したという(本当か?)話で、はじめて土星の輪が見つかった。とはいえ、解像度の問題で、耳のある星と観察されたというような図付きの話。それから70年たって、望遠鏡の精度が上がってはじめて輪と認識される(誰だかは忘れた……後で調べなおしたら記憶違いのようだ。40年後にホイヘンスが輪、さらに10年後にカッシーニが隙間を見つけている)。
なんであんな不思議なものが、と人類は土星に興味を持ちまくって、数100年、ついにカッシーニを飛ばして近くで見てみようということになった。と畳み込む。おもしれえ。
で、カッシーニがスィングバイを繰り返していよいよ土星に到着するところで、思わず泣きそうになってしまったり。遠いし時間がかかるよ。はやぶさもそうだが、宇宙を航海する姿というのは、実にそそられるものがある。
で、奇妙な衛星の紹介。交互に軌道を変える2つ組だの、いろいろ。タイタンへの(名前忘れた)地上探査機が降下中に撮影した写真の組み合わせで海やらの地形の様子とか。
さらに、輪がA,B……とF(記憶違いらしい。実際にはGまである)まであって(発見順の付番と実際の位置の関係が興味深い)、外側のは3重ラセンになっていて、2つの衛星が両脇を通るとか、20万キロ(だっけかな?)の円周に対して200メートルの厚みとか。輪の中で見える姿のシミュレート映像とか。(200メートルってどう考えても薄すぎて、いかに微妙なバランスがとれているかということだなぁ。確か木星にも環があって、それが地球からはまさにその厚み方向しか見えないので、つまりは見えないというようなことも言ってたのを思い出した。あと、環の生成に関する2つの説、衛星と遊星の衝突と、もうひとつが土星の生成時の残りだったかな? 2つ目の説は曖昧)
いや、実におもしろかった。他に錯覚に関する科学技術館のダイジェストみたいな展示とか、デジタルおもちゃ群とか(ソフトウェア的には単なる積み木にして、かわりに積み木の組み立ては空間把握デバイスを使うmodulobeみたいなやつとか)いろいろあって、大人500円、小人300円ってのは安いな。解説員(学芸員なのか?)も多いし。
というわけで、ソニーを少し見直したり。
デザインの決定権を持っているのだから、自分のofficeという言い方もするけど、個室を与えられているはず。
その自分のための個室に連中を入れさせちゃだめだよ=1人で決定せよ。ということでは。
すると、Homerは、home workを意味することになりそうな。つまり、就業時間いっぱいは、連中のおしゃべりに付き合わされることになるので、実際の仕事は家に持ち帰る羽目になると。
最終的な決定をくだすときは、彼らをオフィスから締め出すこと。そうしないと家でやらなきゃならなくなっちゃうよ。
とか。
"Homer", a piece of work done outside of normal working hours, normally cash-in-handのことだと思うけど、cash-in-handが通じない(でもnormallyじゃなければありのような)ので、見当はずれかも。
要領を得ないというかあたりさわりがない障害報告のようだなぁと思ったら、コメントのおかげで意味が出てきている。
「主語マイクロソフト……」だから、まったく期待せずに読んだら、そういうことだったのか。
(例によって経由地がわからない)
ソースを自動生成するとすると、一連の流れとしてコンパイルがあってもそれほどおかしくはない。いずれにしても、人間が手を加えるとしたら(仮に完全なソースが生成されるとして、後述)、ジェネレーションギャップパターンを適用するだろうし。
仮に、自動生成がうまく働かなかったとすれば、コンパイルによって、クラス名やメソッド名、定数の定義ミスや、あるいは生成されたソース内の変数の組み立ての問題を見つけることができる。
もちろん、型の定義ミスも。
これらは、人間がソースを書いた場合よりも、コンパイルされない元ネタを人間が提供することと、機械的な組み立て処理が入ることから、自動生成されたソースにこそ、役に立つのではないか。
と考えれば、それほどおかしくはないかな。
今頃、休暇をとってたりして。
で、つい手元にあったもので、読むつもりはそれほどなかった(ってのは、Windowsプログラミングの極意でものんびり読むつもりだったからだ)、ドーキンスの『神は妄想である』を読み始めてしまった。
このじいさん、よほどうんざりしているらしく、章を追ってシニカルになってくる。
さて、道徳的な観点からして、イエスが『旧約聖書』の残忍な鬼畜よりもかなりまともになっているのは否定できない。(第7章)
あるいは、楽しんでいるのかも。旧約聖書を(目的は、聖書から人々は道徳を得ていないことを立証するためであって、それは筋が通っている。もちろん、内容を取捨選択することは、ドーキンスが反論の対象としている聖書主義者の「人が神によらずに道徳律を決めることは不可能」に対する否定になるのだから(もし、人間が道徳的かそうでないかに基づいて聖書の内容を取捨選択するのであれば、それは結局、人が神によらずに道徳律を求めていることになる)、それは完全に道徳的である必要がある)適当に開いて、矛盾と虐殺と不道徳を散々示したあと、ついに、ヤハウェイは鬼畜扱いだ。
というか、日本人でよかったよ。アメリカはおそるべきだ。有権者の50%がノアの箱舟を史実として受け止めているとか。それがどういう意味を持つのかということだ。
いや、7章を読んで、はじめて理解したことでもある。なぜ、ホモセクシュアルや中絶、避妊について、キリスト教原理主義者が戦うのかについて、彼らの言葉をひいて説明しているところ。あの連中は、それらを黙認すること=ソドムのように業火に焼かれること、洪水に飲まれること、厄災を招くことと信じているのか。冗談としか思えない(冗談としか思えないのだが、どこまで本気にして読んで良いのかなぁ。少なくても牧師その人たちは信じてないとは思うが)。が、カトリーナ台風の後のロバートソン牧師の説教(それについては単なる噂かもとは書いているが、にも関わらず、他の類似な言質も示している)などから示される事実は事実なのだろう。アメリカってのはおっかない国だな。自分が巻き添えを食らってヤハウェイの怒りに直撃されると頭から信じていれば、そりゃ排斥し、差別し、反対するだろう。本当に、そんなに野蛮な連中なんだろうか? (だからこそ、ドーキンスはこの本を無神論者や、不可知論者、理神論者のために、書いたということになるのだろうけど。もっとも不可知論者=日和見主義者、理神論者=敗北主義者、扱いだけど)
ポジティブな面からは、淘汰による漸進的設計という考え方は興味深い(クレーンという例えを、スカイフックという例えに対置させている。いきなりビルの上にクレーンが到達するわけではない、ブートストラップのことだな)。というか、ソフトウェアが完成に向かう姿に「進化」という言葉を利用する理由はそこにあるのかも。
結局、ドーキンスがここで書いていることは、オッカムの剃刀(という言葉は出てこない)の使い方なようだ(悪魔の証明をしているわけだから)。この精緻な宇宙、2つの並走する衛星に挟まれた3重螺旋の土星の輪なんてまさにそうだ、を作り、あらゆる生命を作り、かつ個々人の祈りを聞き届け、他の神を信じると怒り狂い、災厄を起こし、かつ人を助けて……などという複雑に複雑をすべての生物と星の数だけ乗じたような唯一神が存在すると仮定するより、存在しないと仮定するほうが、確からしい。(というような意味において、アニミズム(Googleはえらい。もしかして、抜きにWikipediaがトップだ)に属する多神教は別扱いで、あくまでも、一神教、特にキリスト教原理主義者(と、おまけのようにタリバンのようなイスラム教原理主義者、多分、ちょっとしたガス抜きのためではないか)にターゲットを絞った論議だ)
あとは、第4章の「意識を高める」についての論議かな。historyは差別的なのでherstoryと呼べというフェミニストのもの言いから、ばかげているにも関わらず、多様なものの見方、感じ方の存在を意識するようになることの重要性ということだ。(他の例として宇宙飛行士が恒星間飛行の間に、「いまごろ地球は春なんだよな」という例をあげている。南半球(北米用の本なので)を意識しているか、という問いかけ)
何かを意識するようになるということは、別に言葉の選び方に限定した問題ではないだろう。絶対禁煙要求者(herstory並の主張かどうかはともかく)のあれこれとかを知ったあとは、多分、ねこねこ先生もそれが苦痛だと感じる人の存在を意識せざるを得なくなるというようなことだな。意識することによって、その主張を受け入れる/入れないとは別に、少なくても、後ろめたさという人間精神の発露を招くわけだし。
で、自然淘汰という考え方も、そのような意識を高める武器なのである、とつながる。たとえば、漸進的設計、フィードバックを取り入れた改良、というようなことを考えるのも、その一例か。
結局、この本の実利的な意味は、おそらく北米で原理主義者からの進化論教育排斥運動に対抗する必要がある人たちに対して、対話(というか反対)のためのフレームワークを提供することなのだろう、と思う。
追記:8〜10章を読んで気が滅入ったような、興奮したような。なるほど、ドーキンスが時間をかけてわざわざ一冊の本にするわけだ。ベーコンの国ですら、イドラがいっぱいというか、普遍的な問題を含んでいるんだろうな。
_ Saisse [確かに自動生成と静的な言語のコンパイル(というよりもインクリメンタルコンパイル)は相性がいいですね。ジェネレーション..]
「プログラムが好き」とあった場合に、どのようなものを考えるだろうか。
まず、間違いないのは、プログラムを書くのが好き、ということだろう。おそらく、これは外せないと思う。ただし、現時点の大多数において、という点で。
男もすなる日記の頃、みんなですなってる中に、鑑賞に耐えうる「日記という名前の作品」というメタなことを考えてすなってハックしたやつもいたけれど、日記文学ってのはほとんど偶然の産物で(蜻蛉日記の作者が作品として公開することを前提としてたかどうか、とか)やはり家でひっそりとすなるものなんだろう。
というのが、現状のプログラムというものではないか。ここではプログラムというのは、実行可能なファイルやCDにパッケージされたソフト「ウェア」のことではなく、記述対象の部分をさしているわけだが。
日記をすなる男たちのウェアは、政略結婚にまつわる動きや税収体制や官僚機構や都市計画としてそれなりに今の日本の礎になっているけれど、日記そのものはどこかで塵埃に帰してるわけだ。
一方、男もすなる日記の作者は、すなりぐあいを読者に提示することが目的だった。
これをプログラム(上の意味から、それはソースコードの意味)を公開することに対応づけられるかも。
重要な点は、男もすなる日記には、男がすなる日記と異なり、都市計画の具体的な案件や情報合戦や対案をつぶすための陰謀や、税収を上げるための秘策やら、そういったIPに守られた部分は入れられないということだ。そのようなIPは塵埃に帰した男がすなる日記には書かれていたにしろ。しかし、それらの日記はしょせん塵埃に帰すに等しい表現でしかない(発掘された場合には、内容は問われるだろうが、表現は(文字や語彙、文法の研究対象というさらにメタなレベルを除けば)問われないだろう。
表現と内容は異なるレベルに属する。ビューとモデルか。
ソースコードを公開するのであれば紀貫之のようにありたいな、ということを「プログラム力が落ちる」から考えた。
プログラムが好き、というのは、できあがったウェアよりも、そのすなり具合を愛でる感情なのだ、ということ。
ときどき、そういうことがある。
むしろ、よくないなぁと考えているものに対してそれをやってしまうことのほうが(複雑な気分になるせいで印象が強いからだろうけど)多いようにすら感じる。
だいたい、そういうことをやってしまうときというのは、相手のものの見方を信用/尊重しているためだということのほうが多いかも。それだけに、それはアンフェアであるから、少なくてもフェアに判断できるように、誤った先入見をどかしてくれ、という方向で行われる。
というわけで、スラドにわざわざ書きこんでマイクロソフトの擁護をしたりはしないのだが、人によっては「それは違うだろう」とやってしまうときもある。だいたいそういう場合、やっているうちに、しかしアンフェアな物言いされてもしょうがないなぁとか後悔しはじめたりもしてくるのだが。
でも、それは生命の危機がないから、フェアネスを発揮できるとも言える。
フェアネスを確実に理解しているにもかかわらず、川に落ちた犬をフェアネス精神を発揮して岸にすくいあげてから説教をくらわすなんて愚者の行動だ、落ちたらこれさいわいと石をぶつけて殺してしまえ、とわざわざ書かなければならない状況の過酷さというのは、過去の歴史であってほしいと思う。
ジゼルを見てきた。思いっきり不愉快な物語に、とびきりにすてきな振り付けの舞踏。
おつむの軽さが体の軽さと等しいふわふわしたジゼルをユカリーシャ(とマニアの人たちは呼ぶらしい)が演じていて、見事なものだった。
見慣れたからか、それとも振り付けや音楽が良いからか、白鳥の湖に続いて、白いバレエの部分でも退屈せずに惹きこまれた。
アダンの曲も単体で聴く気にはなれそうもない、バレエのためのバレエ音楽だが、起伏が激しく狩の唄が気持ちよく、演奏も良かったように思う(管の響きが、五反田のくぐもった音響に逆に心地よかったり)。
ジゼルとアルブレヒト(急の代役のデュッセルドルフの人)は最初はなんか息があってないように感じたけど、2幕ではすばらしかった(と思う。ちゃんと判断できるほど、まだバレエの技巧とか見方とか知らないし)。
それにしても、無闇と疲れそうな忙しいバレエだな。
にしても、物語はどうにも不愉快で、なんでヒラリオンが殺されなきゃならないのか、とか、まあいろいろ思う。ヒラリオンのヒラは平民の平だからだろう、としか思えない。
初演は1841年。7月王政の最中だから貴族制は廃止されたとはいえ、労働者と農民の敵による支配体制だから、きっと見ている連中はアルブレヒトに肩入れして、「よっしゃ、もう一押し、それ押し倒せ」とか言いながら見てたんだろう。
ふと気付いたが、日本語でのアナウンスはおれがすべきなのかと思い出した(一応、メンバーになってたりします)。クォートした部分は、おれの翻訳。そうでない部分はおれのまとめ。
(追記:裏庭のほうに清書版を置きました。RubyDotNet)
----
IronRubyの影になって、ちょっと見えにくくなっていますが、現在、QUTのRuby.NETはQUTからスピンオフして、New BSDライセンスのもとに公開開発体制にはいってます。
Ruby.NETのゴールは、Matzと仲間達が開発したRubyとの完全な文法互換性です。われわれは、Rubyを他の.NET言語と協調して.NETコンポーネントを開発する仲間に加えたいと望みます。さらに標準かサードパーティ製かを問わず、他の言語で開発された.NETプラットフォーム上のコンポーネントやリソースへのシームレスなアクセスの提供も考えています。また、Monoを含むCLI実装のサポートも計画しています。
ランタイムライブラリの一部は、オリジナルRubyのCのソースをそのまま利用しています。われわれは、ソースコードをオープンソースコミュニティに対して開いたものとしたMatzと仲間達に、感謝します。われわれもそれにならって、新BSDライセンスのもとにわれわれのソースコードを開いたものとします。
Visual Studio 2005をお持ちであれば(Express Editionでどうかは不明)ソリューションファイルが、あるいはMonoの開発体制にあればMakefileが、それぞれ付属した完全なソースコードがレポジトリから入手できます。
特殊なツール:QUTの(多分オープンソースではない)PE File Reader/Writerなどのツールが必要ですが、これらも配布物に含まれているため、上記の条件を満たしていれば開発へ参加できます。
Visual Studio 2005の要件:完全な開発を行うには、Visual Studio 2005 SDK v4.0以上のインストールが必要です。これは配布パッケージのビルドの過程でVisual Studio拡張をビルドするからです。したがって、Vistaで実行する場合には、Visual Studio 2005を管理者権限で実行する必要があります。
●特徴:
・現時点では比較的透明なクラス構造、整理されたパッケージ
・インタプリタ(rbファイルを動的にロードして実行)、コンパイラ(rbファイルからCLR用EXEファイルを生成)の両方を持つ
・Ruby 1.8.2 互換な文法
・言語エンジン、フロントエンド、Visual Studio組み込みウィザード、配布プロジェクト、など、Visual Studio 統合を意識したソリューションパッケージ
●ダウンロード
ただし、Subversionが利用できるのであれば、
svn checkout http://rubydotnetcompiler.googlecode.com/svn/trunk/ rubydotnetcompiler
からチェックアウトするほうが良いでしょう。
●ビルドの仕方
Mono:ためしたことがないのでうまく動くかわかりませんが、Makefileがルートにあるので、それを見てください。
Visual Studio 2005: srcディレクトリのRuby.NET.slnをVisual Studio 2005に読み込んでフルビルドしてください。もし、Visual Studio SDKがインストールされていないと、配布パッケージのビルドなどが成功しません。この場合、ソリューションの中から、RubyRuntime、RubyCompiler、Rubyの各プロジェクトを個別ビルドすることで、Ruby.NETを生成して、直接作成されたRuby.NETを利用しても良いでしょう。
●実行方法
配布パッケージも生成されますが、ヴァーチャルPC環境などのようにいざとなったら破壊できる環境でない限り、GACに対するインストールも行われるので、単に、binディレクトリにPATHを通したコンソールを利用するほうが良いと思います。
●Railsについて
RailsをMonoで実行することをモチベーションにしているメンバーもいるように思う(MLすべてに目を通していないので漠然とした印象)ことと、ToDoリストにRailsのポーティングが乗っているので意識はしています。
●IronRubyとの関係
現時点ではオリジナルのパーサの提供という関係だけではないかと思います。したがって、QUTのオリジナルRuby.NETから見て、直系の子供がRuby.NETで、IronRubyは異父弟なんじゃないかな。
C:\rubydotnetcompiler>ruby class String def add(s) self + s end end s = 'aaa'.add 'bbb' puts s s.instance_eval("def x(s); s + self + '!';end") puts s.x('hello') ^Z Warning: String is a Ruby built-in class, interop class not generated aaabbb helloaaabbb!で、
C:\rubydotnetcompiler>rubycompiler a.rb Warning: String is a Ruby built-in class, interop class not generatedと、上のソースをコンパイルして、
C:\rubydotnetcompiler>cd bin (僕は、GACに登録していないので、カレントディレクトリに一式揃っている必要がある) C:\rubydotnetcompiler\bin>copy ..\a.exe . 1 個のファイルをコピーしました。 C:\rubydotnetcompiler\bin>dir a.exe ドライブ C のボリューム ラベルがありません。 ... C:\rubydotnetcompiler\bin のディレクトリ 2007/09/08 12:31 16,384 a.exe 1 個のファイル 16,384 バイト ... C:\rubydotnetcompiler\bin>a aaabbb helloaaabbb!と、コンパイルしてEXE化できる。
協力のお願い。
現時点での欠落(拡張ライブラリが存在しないことなど)とは別に、文法上の非互換や異常を発見された場合は、Issuesへの登録をお願いいたします。このとき、単純化した再現コードを付けていただけると助かります。
#どっかにHow to contirubteがあったはずだけど見つからないなぁ。
なんていうか、secondlifeの人はえらいなぁ。おれが考えるのはこれ+みんなの考えも教えて、という態度って(この場合は※)すてきだ。
※ 宗教戦争があるじゃん。で、それを避けるために、おれはこう思う、従え、っていうムハンメッドみたいな方法もあるだろうけど、それだと自分が見落としてる良い考え方を教えてもらう機会も切り捨ててるよね。まさにこの場合は、これがスマートだな。
子供が、読め読めうるさいので、読んだ。
なぜか、オースティン。おもしろかった。
どうも、パイレーツオブカリビアン観て気に入ったキーラナイトレイの映画を見たかったらしいのだが、ほったらかしといたら、妻が昔買ったらしい岩波文庫を読んで、そうとうおもしろかったらしい。
18世紀の終わり(1790年代)に書かれた小説(出版は1810年代らしい)だから、日本では本居宣長とか小林一茶とかの時代だ。まじかよ。いや、馬琴と三馬はいるけど。
以前、嵐が丘の本当の登場人物の年齢がミドルティーンなんでぶっとんだが(これは1847年で、19世紀中頃)、すべて悪いのはハリウッドと英国演劇だ。あの連中が、いっきに年齢を10歳くらいかさあげしたのだった。
(ちゃんとミドルティーンっぽい少年少女が激しい愛憎劇を繰り広げる正しい映画)
(少年ではなく、かろうじて青年、ほとんど中年じゃないのかのヒースクリフで誤ったイメージを植え付ける作品)
有名人ではフランケンシュタインの怪物を書いたシェリー夫人に結局はなることになるメアリゴドウィンがシェリーとくっついたのが16歳、親にばれてヨーロッパへ駆け落ちしたのが17歳、スイスで暇にまかせてフランケンシュタインの怪物を書いたのが19歳なわけだが、別にシェリー夫人というよりメアリーがとびぬけて早熟な不良少女だったわけじゃなくて、そういう時代であったのだ。オースティンが高慢と偏見を書いたのがだいたい21歳のころか。
というわけで、高慢と偏見には、貧乏な紳士(郷氏って感じか)のだいたい15、17、19、21、23の5人の特徴的な娘たちが出てきて、本当のお金持ちの貴族と恋愛する。で、15と17は、兵隊好きで、結局15歳は口ばっかり達者な男(次女も惹かれたりするのだが)と駆け落ちするおまけつき。
(キーラナイトレイは1985年生まれだそうだから、21歳の役にぴったりだな、というわけで無理のない映画化であろうが、ダーシー卿の役者は何歳くらいなのだろうか)
高慢と偏見 [DVD] FRT-186(アン・ラザフォード/メアリー・ボーランド/グリア・ガースン/モーリン・オサリヴァン/ローレンス・オリヴィエ)
(明らかに年齢設定が異常な古典映画)
で、この小説は何がそんなにおもしろいのかというと、主役であり小説世界の観察者の目となる次女(つまりオースティンと同年齢)のシニカルな人物分析と、これまたシニカルな親父と、やはりシニカルなダーシー卿(次女の相手)といった合理主義者たちと、はっきり馬鹿として描かれている母親、三女、四女、五女、隣家の夫婦、ダーシー卿の親戚のメック婦人のような役回りの人(名前忘れた)、愚物という言葉がふさわしい親戚の神父(この男の愚物っぷりの描写たるや鬼気迫る勢い)、好意的に描かれている叔父さん夫婦と長女と隣家の娘、嫌なやつとして描かれている長女の恋の相手の妹達(ただし相手に対してはニュートラル)、といった主観的な書き分けが絶妙なところだ。パーティーの席上で母と四女、五女、三女が馬鹿丸出しで大騒ぎするところの描写っぷりとか、見事の一言に尽きてそれでおしまいになりそうなほどで、頭の悪い人の会話の特徴の出し方とか行動パターンとか、びっくりするくらいに的確。本当に頭が悪そうに読める。
長女の名前が作家と同名のジェーンで、次女が作家と同年齢というあたりから、こうでありたい自分としての長女と、こうである自分といった書き方なのかも。すると幸福な結婚をするのが長女と次女で、しかもそれぞれの相手が異なる性格(長女の相手は社交的で良い人、次女の相手は無愛想だが賢い人、ただしどちらもお金持ち)というのが、一歩ひいて読むと実に小娘小説なのだが、厭味がないはなぜなんだろうか、そのへんの書き方のうまさが才能というものなのかも。絶妙。
それにしても、親父の描写が面白すぎる。美人っぷりにまけて結婚したものの(子供が5人というのは他の登場人物に比べて多いのだが、それはそれぞれ特色ある姉妹を出すための方便で深い意味はないのだろうけど)、妻の頭の悪さにうんざりして、もっぱら賢い次女とだけ会話するだけで普段は書斎にこもってなんか本を読んでたりして。で、次女が結婚してしまったもので、本来出不精なのにしょっちゅう娘夫婦のところに遊びに行くとか。というか次女が長い旅行に出かけていて帰ってくると大喜びするので、次女がははぁ、話が通じる人間が家にいなくてうんざりしてたなと悟るとか。書き方がやたらと好意的でおもしろい。
で、ダーシー卿がお金持ちという点以外では、あまりの無愛想っぷりと社交性のなさにみんなの顰蹙をかいまくり(当然、次女も最初は嫌っている)のが、次女に恋したせいで人間的に成長するとか。
愚物の代表の親戚の神父は、親戚の中で男だというだけで親父が死んだら妻が生きていようがなんだろうが、家督を相続するという当時のイギリスの制度とか(だから頭が悪かろうがなんだろうが、母親や四女、五女の生き方はしょうがなかろうという気にもなってくるのではあるが)、
というところで、小娘小説といえば、11世紀の初頭の1001年には大部分が書かれていたといわれる源氏物語を調べてみる。すると、紫式部がどうも979年頃に生まれたということは、書き始めはやはり20になるかならないかあたりの頃ということになる。藤原道綱母(これまたイギリスの相続制度に劣らずひどい名前だ)が蜻蛉日記を書き始めたのが18歳あたりで10世紀の中頃。現代人だと新井素子のデビューが17歳、近代だと尾崎翠が18歳という感じ(しかしオースティンの系譜はむしろ少女漫画のほうではないかという気もする)。
一方、枕草子は清少納言がだいたい30歳あたりの作品らしいので、ちょっと桃尻語で良いのかという疑問もある。むしろ、高慢と偏見とか、嵐が丘とか、フランケンシュタインの怪物といったイギリスの古典こそ桃尻語訳がふさわしいのではないかとか。
#!/usr/local/bin/ruby -Ks require 'open-uri' require 'cgi' require 'iconv' class GooDic class NulLog def write(s) end def close end def flush end end class Entry def initialize(title, desc) @title = title @desc = desc end attr_reader :title, :desc end def initialize @log = $DEBUG ? File.open('log.txt', 'wb') : NulLog.new @entries = {} end def add(word) query = CGI::escape(word) s = '' items = [] open("http://dictionary.goo.ne.jp/search.php?&kind=all&MT=#{query}&PT=webtu&from=webtu", 'Referer' => "http://search.goo.ne.jp/web.jsp?MT=#{query}&STYLE=web&IE=UTF-8&from=gootop") do |h| h.each_line do |line| @log.write line begin s << Iconv.conv('sjis', 'euc-jp', line.strip) rescue s << line.strip end end end @log.flush s.gsub(' ', ' ').scan(/<h2 class="ch04"><span>(.+?)<\/h2>.+?<div.+?>(.+?)<\/div>/) do |title, cont| items << Entry.new(remove_tag(title), remove_tag(cont)) end @entries[word] = items end def [](key) @entries[key] end def size @entries.size end def each(&proc) @entries.each &proc end def remove_tag(s) s.gsub('</li>', "\n").gsub(/\[<a.+>\]/, '').gsub /<.+?>/, '' end end if __FILE__ == $0 if ARGV.length == 0 STDERR.puts 'usage: ruby dic.rb word [more words ...]' exit 1 end dic = GooDic.new ARGV.each do |word| dic.add word end dic.each do |k, c| c.each do |e| puts '----------------------------------------' puts e.title puts '----------------------------------------' puts e.desc end end end
コンソールが利用する文字コ−ドはシフトJISと前提(Windows用なので)。
VC#の本と出版時期が同じだからだろうけど、アスキーからもらったので読んだ。えらくおもしろい。
Windowsプログラミングの極意 歴史から学ぶ実践的Windowsプログラミング!(Raymond Chen)
どのくらいおもしろいかといえば、
例)行末文字がCR+LFなのはなぜか
RFC0821……すべてCR+LFを行末シーケンスとして指定していることがわかる。
これは正しい。NVTの仕様だからだ。
そこで、実際の問題は、「なぜCP/M、MS-DOS、Win32がCR+LFを行末文字として使用するのか」ではなく、「なぜほかの人はこれらの仕様書に逆らい、ほかの行末文字を使用することにしたのか」である。
で、考察。
あるいは、
例)Altキーを押すとキャレットが点滅しなくなるのはなぜか
これは、「ファイル名を指定して実行」での話だが。
というような、Windows3.0あたりからの(行末コードについてはCP/Mからなわけだと言いたいことが上の引用からわかる)永遠の互換性に縛られた世界で、リバースエンジニアリングしてハックしまくっているアプリケーション群のために互換性を確保してやったり、「おとりの[画面のプロパティ]」を用意してやったり、いんちきベンチマークの間引きに対処してやったり、Windows98のCDにTweakUIを付けてやったらサポートがえらくたいへんになったのでSP2から外したりとか、なんでも悪いのはマイクロソフトのせいにするライターとか、タスクバーを知ったかぶってトレイと呼ぶ(他のチーム、マスコミ、ユーザー、ISVのデベロッパー)連中を罵ったり、嘲ったり、嘆いたり、まあ大変である。
だが、おまいらがExcel専用のAPIをこっそり用意して(しかも隠していたり)、最初にプリロードをして起動速度を稼いだりしてたのは、知っているのだが(いや、それは私のせいではないという声もどこかで聞こえた気もするが……というように曖昧にMSのせいにする人たちを呪ってみたり)。
というわけで、なにがプログラミングの極意かといえば、C++の多重継承をした場合のvtblが、複数のインターフェイスを持つCOMのオブジェクトのレイアウトや、その多重継承のどのvtblを選択するかのずらしかたといった技術ネタも少しばかり混ぜながら(スタックを追っかけてコードのエビデンスを調べるのがばかげているということを書いている部分はおもしろい)、悲憤慷慨しまくるとても愉快な本。
成分分析すれば、
・ISVのデベロッパーがくずなせいで、おれたちが困る。10%
・ISVのデベロッパーがくずなせいで、おれたちが悪モノ扱いされる。10%
・ISVのデベロッパーがAPI説明書を読まずに、アルファ版のサンプルをそのまま利用しているので、おれたちが困る。5%
・マスコミがくずなせいで、おれたちが悪モノ扱いされる。10%
・ユーザーがばかなせいで、おれたちが悪モノ扱いされる。10%
・ユーザーが知ったかぶりなせいで、おれたちが困る。10%
・他のチームがくずなせいで、おれたちが困る。10%
・前任者がくさった仕様を残したせいでおれたちが困る。10%
・NTの連中が変なこだわりを持つから、おれたちが困った 5%
・ほかのOSの連中がどろぼうだから、おれたちは騙してやった 2%
……
・こんな技術を使っているから、参考にするといいよ。1%
というような感じ。ただし、役には立たないが、どうして困るのかの解説は基本的には技術的な話(↓のような例外もあるけど)なので、滅法楽しい。理屈がある分だけ、ただの悪口と違っておもしろさ100倍増。
Lunaの壁紙は最初、赤い砂丘をデフォルトにしようとしたら、尻に見えるというクレームがついたので、急遽差し替えた、本当にユーザーはくずだ、というような話とか。
つまり、技術書というよりは、Windowsの虚々実々をネタにした、良いAPIや良いUIはどうあるべきかについての本だ。というわけで、ジョエルの本に近い。ただし、経営的な観点はまったくないけど。
なぜ、CoTaskMemAllocではなく、SHGetMallocというのがあるか、どう内部的に使われているのか、といったくだらないアイディア(当時のPCは4Mしか積んでいないとか言い訳てんこもりだが、ここらへんではCOMチームがばかだから後先考えずにばかでかいライブラリを作りやがったというような罵り(もちろん、どの場所でも直接罵ってはいないが、眼光紙背に徹すればそこらじゅうにでっかな文字で「おれたちは悪くない」と書いてあるのが読める)がないのがちょっと不思議。せいぜい「OLE32DLLをメモリに読み込んでさんざんな目にあっていた。こうした厳しいメモリ状況では、4KBのメモリを失っただけでも目立った。」と軽く流している程度)について得々と説明してみたり。まあ、そうやって4MBのマシンの8MBをOSが使っているせいで、実際におれのようなISVの開発者がどれだけ楽しいプログラミングができたかについては、その楽しみを罵ることで報いてくれているわけで、(今となっては)実に愉快だ。
Swingアプリケーションのように、積極的にJavaのThreadを使いまくる必要があるときは別だが、Rjbをつなぎとして利用する方法がある。
いや、もちろん、RubyとJavaのつなぎ(ブリッジ)なのだから利用する方法も何も、そのもののように読めるかも知れないが、それは空間上のつなぎの意味で、ここで言うつなぎは、時間上のつなぎだ。つまり、JRubyがより高速化されるまでのつなぎ、という意味。
hfuさんの次のエントリーは、同じプログラムのRjb版とJRuby版について書かれたもので、両者の使い分けの参考になる(どうもありがとうございます)。
CRuby + Rjb + Geotools は JRuby + Geotools に比べて2倍くらい早い場合がある
同じような例として、フィボナッチ音楽(JRubyで動くかどうか試してないので嘘が書いてあるかも知れないけど)では、rjbのrequireに成功するかどうかで使い分ける例を示している(2007-08-08 _ フィボナッチミュージック(続))。
これらを見ると、RjbとJRubyの相違は、利用したいJavaのクラスのロードの部分に差が集約されていることがわかる(ロード後の動作で異なるソース記述が必要となる場合については、指摘していただければ対処します)。
フィボナッチミュージックのRjb/JRuby切り分けの仕組みをhfuさんのプログラムに適用することを考えてみる。
JRubyの環境では、rqeuire 'rjb'は失敗し、CRubyの環境では、require 'java'が失敗することを利用する。ここでは、JRubyまでのつなぎなので、主となるライブラリをjavaとしよう。
まず、直接これらをrequireする代わりに、環境に応じてJavaモジュールをセットアップするアプリケーション固有環境設定ライブラリに処理を切り出すことにする。
ここでは、そのプログラムをgeoinit.rbという名称にしてみよう。(9:54修正。なんか勘違いしてた)
#geoinit.rb begin require 'java' class FeatureReader module Java include_class 'java.io.File' include_class 'org.geotools.data.shapefile.ShapefileDataStore' end end class FeatureWriter module Java include_class 'java.io.File' …… end end rescue LoadError require 'rjb' class FeatureReader module Java File = Rjb::import('java.io.File') ShapefileDataStore = Rjb::import('org.geotools.data.shapefile.ShapefileDataStore') end end class FeatureWriter module Java File = Rjb::import('java.io.File') …… end end end
そして、元のプログラムでは、
require 'geoinit'
として、どちらを利用するかの詳細については隠ぺいする。
まとめると、Rjbを利用するか、JRubyを利用するかを、環境に依存した特殊な処理と考えることで、差の部分をアプリケーションのメインの処理から分離し、隔離する。アプリケーションのメインの処理では、どちらが利用されているかについて依存させないようにする。
このとき、Rubyの場合、オープンクラスという特徴を利用して、特別なラッパオブジェクト(プロクシ)は作らないですませるようにする。単に分離した初期化モジュールの中で、クラス定義式を直接記述できるからだ。このようにしておけば、独自のRjb/JRubyラッパが不要となるので、プログラムの見通しと風通しが良い状態に保てる。
ゴドーを待ちながら (ベスト・オブ・ベケット)(サミュエル・ベケット)どうも、上のリストを眺めているとDRYじゃなさ過ぎで気分が悪い(hfuさんのコードではなくて、おれのコード)。
次のようにしたほうが良いな。
#geoinit.rb begin require 'java' def jimport(cls) include_class cls end rescue LoadError require 'rjb' def jimport(cls) nm = cls.split('.').last module_eval "#{nm} = Rjb::import('#{cls}')" end end class FeatureReader module Java jimport('java.io.File') jimport('org.geotools.data.shapefile.ShapefileDataStore') …… end end class FeatureWriter module Java jimport('java.io.File') …… end end
jimportメソッドは、JRubyの場合は、include_classメソッドで、Rjbの場合であれば、与えられた完全修飾クラス名のクラス名を定数として指定されたクラスをimportする。
マンガを買おうと本屋に行っていろいろみたが、あんまりぴんと来るものがない。
そこに、復刊ドットコムでみごと復刊とか書いた本があって、それに便乗したのか同じ作家の本がいくつか平積みになってる。なんだこりゃ?
で、そのうち、2冊ばかり買ってきて、読んだ。うーん。
こういう表現者もいたのか、と少なからぬ驚き。少女漫画なのかな? 少女漫画なんだろうな。絵本のようであり、塗り絵のようであり、レトロなようであり、モダンなようであり、おされなような、どろくさいような、新鮮なような、陳腐なような、表現っていうのは、おもしろい。
(コマ割りが解体されているため時制が崩れかけてぼろぼろになる一歩手前で踏みとどまっているという感じかな。その崩壊一歩手前の危うさが世界全体の雰囲気を醸し出しているような)
初出はプリンセスって、ナイルの娘や、エーベル少佐の雑誌だよなぁ(おれの知ってる時代では)。そこにこういうのが入り込む余地があるのか。で、思わず出版社を確認して、やっぱり秋田書店だなぁと納得したり。
いずれにしても、おれは、捨てられたぬいぐるみや箱の中の仔猫の話には弱いのだ。
#で、子供に貸してやったら、おれが気付かなかったプーさんに気付いたり。というか耳が黒いからクマだとは思わなかったが、確かにそうだ。
で、そんなこた、どこにも書いてないが、よくよく考えてみたら、天国というのは、哀しみに包まれた場所なのではないか?
残された人間が哀しいのであれば、行ってしまった人間は残された人間が不在なゆえにやはり哀しいはずだ。
たぶん、こっち(復刊ドットコムもの)も買うだろう。
で、残った人間が地獄行きになったらどうなんだろうか? 不在は永遠のものになるわけだな。
というわけで、天国は待ってくれるをルビッチが作るわけなのか、と納得してみたり。気楽に口やかましいおばさんは地獄に落とされていたが、ルビッチは好きだ。
それにしても、DVDを天国で検索すると、とんでもないことになっていろいろ楽しい。みなさん、天国が好きなようだ。
特に、こいつは気になる天国。
「建設会社に務める田丸は大変な空想家で仕事も失敗ばかり。とうとう守衛に格下げされた彼は、機密書類を盗まれさらには産業スパイの疑いを掛けられてしまう。 」という不幸な男を、日本の虹を掴む男、タニーケイが主演してるというだけでそそられる。
おや、ボリスカーロフも出ていたのか。
向井さんの「アルゴリズムを知らない子ども達」を読んでから、あらためて「マシン語を知らない子ども達」を読むと、ちょっとしたいびつさを感じなくはない(微妙な感触)。
理屈の上では、向井さんの書いていることのほうが(2者択一ならば)同意できるのだが、どうもそのようには世の中は動いていないように思える(計算機学科でどういうカリキュラムをやっているか、ということではなく、ビジネス分野で仕事をしているプログラマについて)。そのため、明らかにまずどちらが来るべきかでいえば、向井さんのやつのほうが先にあるはずなのに、すぐに言語とかの話になってしまうように思う。LLだ、HLだってのも同じことだ。まあ、とっくに通り過ぎた地点だという場合もあるだろうけど。本当にそうかな?
そういえば、最近、これについてなんひっかかる物言いを見たな、と思ったら、通りすがりの罠だった。
すでに偉い人が考えたアルゴリズムがあり、普及した実装があるのだから、それを使うというのは、効率的だ。自分で考えるのは無駄ですよ。ふむ、無駄ね。
ビジネスであるから、効率は重要だ。
言葉の意味だが、効率性と合理性というのは異なる概念で、後者は再生産性をもたらすが、前者はその瞬間にのみ意味をもつ。
魚を与えるか釣り方を教えるか問題である。釣り方には待つことや、場を選択することも含まれる。これは漁だけではなく猟にも応用できる可能性がある。合理的に考える力、という力を与えられるということである。一方、魚を与えるということは、欲求を満たすが、力を与えないということである。
これを称して、孔明の罠と言う。
力を与えることを避けるために、無駄ですよ、と甘言で誘う。みんな無駄は嫌いだ。一番、無駄が嫌いなのはSIerだ。必要なのは頭数なので、力をもつものは一握りで十分だ(と考えていた(現在進行形ならば「る」)節がある)。
同じ言葉でも、立場が違えば意図は変わる。
404氏の口から出る場合、それは花畑にはいろんな花が咲いてるほうが望ましいから、すでに咲いている花を植えるのはやめておけ、というような意味になる。どちらかと言うと元の話は、花じゃなくて、堆肥にするための雑草を植える行為についてだと思うので、ちょっと違いそうだ。
でも、プログラマの頭数を揃える立場にある、あるいはその立場に属する者の口から出る場合、それはお前らは考えなくても良いから、言われたことをやるだけにしてくれ、という意味になる。だって、考える人は価格が高いから非効率的じゃん。それに、もう君らに魚をあげる気はないんだ。ちなみにこの漁場一帯への立ち入りも禁止するから、あとは勝手にやってね。ばいばい。
つまり、彼らはどちらも合理的な行動を取っている。わなをしかける側はそういう考え方ができるということだ。見習うべきことである。
ソートを考えるのがいやなら、ショート(む、意図せず韻を踏むことになったな)コーディングを考えるのもいいよ。
回り回ってマシン語が必要になるとか、面白い本が売れると別の面白い本が出やすくなるだろうとか、いろいろ。言葉は葉だから重ねることもできるし、カゲリの術にも使える。
結局、復刊されたアシカな人たちのマンガも買ってしまった。読んだ。子供にやった。
さすがに、ちょっとうんざりした(中2病に最適というか、逆にこういう本を読んで中2病に罹患するのだな)。まあいいや。楽しめた。
岡崎京子のコマと、ベタと、人の位置関係を更にずらして、かつ人の代わりに比較的かわいい絵柄のアシカにすることで、印象を柔らかめにしたという感じかなぁ。
誰が書いてたか忘れたが、卒業白書を、この映画を観た中学生が10年くらいたってから、ああ良い映画を観たなぁ、みたく評価するんだよな、とか評してたのと同じような印象を持たないわけでもない。だから、復刊ドットコムで、しかも復刊にこぎつけられた、ということかも。
どうってことないのだが、なんか大人っぽい微妙な感情(乾いた絶望までいかない穏やかな諦観)が表出されているのを感じることができるからだろう。あと表現が少しばかり風変わり方向に繊細な点とか。
ゴダールのエピゴーネンだという点が、岡崎京子を感じさせる点だ。
説明抜きの引用に次ぐ引用。説明抜きなために、その引用が引用だと認識できた場合に、強い共感を読者に与えることができる。引用が引用を生むので誤読してもそれが正しい読み方となりえる。したがって、世界は知識に比例して深く広くなる。引用を触媒として内的宇宙を開く。
コーヒー&シガレッツ【廉価2500円版】 [DVD](ケイト・ブランシェット)
ドライブインのネオン塔の下で出会った黒い天使アシカと白いアシカのコンビ。
トーベ・ヤンソンのムーミン 楽しいムーミン一家 BOX SET 上巻 (3000セット限定プレミアムグッズ付き) [DVD](高山みなみ)
妹を助けに行った両親が目の前で潮に流されるのを、気付かずに失ってしまって、ウサギに恋するアシカ。
パラソルに吹かれて鯨の背中に救われた子供を捜す父親アシカ。
老いた結婚詐欺師と、自動車泥棒。養蜂。
自動車泥棒というと、勝手にしやがれとかリモザン(題忘れたとか)、いろいろ映画史的な記憶。
養蜂からは、エリセ。
かって一度だけスポットライトを浴びた野球選手。
少しずつ登場あしかが、パートナーを変えながら出たり入ったり。
ショーガール
カクメイ
日本からの荷物を待つ病弱な少年
鉄腕アトム Complete BOX 1 [DVD](手塚治虫)
顎が欲しかったロボット
わたしは真悟 (Volume1) (小学館文庫)(楳図 かずお)
中国から来た少年あしかはどこから来たのだろう?
互換性レイヤーのバグを突いて、fooしてbarしてbazするという誤ったサンプルコードが、自称エキスパートの手によって雑誌などで紹介されてしまった。この呼び出しだと、機械語にして2ステップが省略されることになり、結果的に1実行あたり1マイクロ秒をわずかに下回る速度を稼ぐことができるというのだ。
この本来12秒かかる処理を1マイクロ秒速くするために(なんと結果はやはり12秒になるのだが、誰も気づかなかったのだろうか)どれだけのコストがかかることになったかを説明しよう。
こうなると、本来のAPIが正しい結果を返すことにすると、既存のコードがすべて動かなくなる。実際、きわめて有力なユーザー企業の技術担当者に対して行ったアンケートでは、この動作が変わることになれば、バージョンアップは絶対に行わないという辛らつ極まりないものだったのだ。
これを回避するには、呼び出し側のプロセステーブルのオフセット8バイト目からのポインタが示すアドレスの7バイト目が0x8eであれば、以降barをポイントするジャンプテーブルの飛び先をnoopに置き換えれば良い。しかし、C++リンカー開発チームの連中は、異なるバージョンに同一のシグネチャを与えるという高度なテクニックを発揮してしまったために、本来のbarを呼び出すべき実行ファイルについてもプロセステーブルのオフセット8バイト目からのポインタが示すアドレスの7バイト目を0x8eにしていたのだ。なんてこった。
かくして、現在も本来のAPIを呼ぶ代わりにfooしてbarしてbazすることで代替する、というわけである。これが1マイクロ秒の代償とはなんとも皮肉なことである。
Windowsプログラミングの極意 歴史から学ぶ実践的Windowsプログラミング!(Raymond Chen)
(もちろん、文章はイメージです)
hfuさんのgeotoolsの実装で興味深い結果が。
読み間違いかも知れないけど、Javaのプリミティブ型クラスを返して、プリミティブ型クラスを受け取るオブジェクトに対する操作が主(かつ大量)になるため、JRubyが2倍遅いというのは、内部的なプリミティブ型クラスからRubyの型への変換に取られているらしい、ということ。
たしかに、Method#invokeを利用するときには、仮にプリミティブであっても、一度プリミティブ型クラスのオブジェクトに変換しなければならないから、Ruby側で特に操作をしないのであれば、プリミティブ型クラスのオブジェクトのままJavaからRuby、RubyからJavaへ動かしたほうが効率的だ。そうでなければ、JavaからRubyへの過程で変換して、さらにRubyからJavaへの過程でも変換することになる。(このとき、メソッドシグネチャとのマッチングに余分なコストもかかりそうに思う)
逆に、プリミティブ型クラスのオブジェクトをRuby側で操作しまくるのであれば、Rubyの型に変換されているほうがよほど効率的だし、ユーザビリティも高そうに思う。
でも、思うに、Javaでインターフェイスを決めるとき、わざわざ戻り値をプリミティブではなくプリミティブ型クラスのオブジェクトを選択した時って、その返送値は直接消費されるのではなく、一度コレクションへ格納するというような場合を想定することのほうが多いのではないだろうか。(というか、個人的には相当インターフェイスを決めたけど、プリミティブではなくプリミティブ型クラスを返送するメソッドとか、引数に撮るメソッドとか切った覚えがない。僕の感覚がどこまで一般的かはわからないけど、仮に一般的なインターフェイス決定にしたがっていると仮定すれば、わざわざプリミティブ型クラスのオブジェクトを返すというのは、そのままスルーすることを想定した場合に限定されるのではないだろうか。たとえばコレクションへ格納して後から取り出してまた送り込む場合とか)
というわけで、もしプリミティブ型クラスのオブジェクトのRubyの型への自動変換が、強制的なインターフェイスならば、JRubyの人は再考したほうが良いかも。と、今度、takaiさんに会ったら伝えよう(ここに書いても召還できないだろうしなぁ)。
そうすれば、hfuさんの例では、JRubyでもCRubyと同等の速度になる可能性があるように思う。(この場合、Rjb側から受けたプリミティブ型クラスのオブジェクトを一度Rubyの型に変換しているために、遅い方向で同等の速度になったわけだから)
OCamlの教科書読んでいるのだが、手元に処理系がないので、しょうがないのでGHCで例題を解いてるのだが、ストールしてしまった。
やりたいことは2つの関数の作成。
元の例題の実行例を書くと
let test1 = add_to_each 1 [] = [] let test2 = add_to_each 1 [[2]] = [1; 2]] let test3 = add_to_each 1 [[2]; [2; 3]] = [1; 2]; [1; 2; 3]]これはこう書いた。
ate n [] = [] ate n (f : t) = ((n : f) : ate n t)
期待通りに動く。
次の例題。
let test 5 = prefix [] = [] let test 6 = prefix [1] = [[1]] let test 7 = prefix [1; 2] = [[1]; [1; 2]] let test 8 = prefix [1; 2; 3; 4] = [[1]; [1; 2]; [1; 2; 3]; [1; 2; 3; 4]]
なんか、やっかいそうだけど、上で定義したate関数を使うってことはわかるので、とりあえず、最初に次のように書いてみた。
pref [] = [] pref (f : t) = (f : ate f t)ロードすると
*Main> :load test.hs Compiling Main ( test.hs, interpreted ) test.hs:60:24: Occurs check: cannot construct the infinite type: a = [a] Expected type: a Inferred type: [a] In the first argument of `ate', namely `f' In the second argument of `(:)', namely `ate f t' Failed, modules loaded: none.
アトムがほしいのにリストを寄越しているというエラーだと思うのだけど、なぜそうなるんだ?
というわけで、エラーメッセージを消す方向で、
pref [] = [] pref (f : t) = (f : ate (head f) t)
でも、これが正しく動くわけがない。
で、いったいなぜコンパイルが通らないのか混乱したということでした。
で、ateの引数とprefの引数というヒントのおかげというよりは、落ち着いて、まずはpref関数の枠組みを作って……とやっているうちに、できた、ということで。なんてトップダウンと正直なところ思ったけど。
Rjb::primitive_conversionというモジュールの擬似属性を追加。
Rjb::primitive_conversion = true を実行すると、以降、プリミティブ型クラスのオブジェクトが戻された場合、Rubyのネイティブ型に変換します。
読んだことのない古典を読むことにして、まずは、マーク・トウェインあたりかなとか。
子供のころ、トムソーヤの冒険を読み始めて、あまりのつまならさに嫌気がさして投げた覚えがあるのだが、それから幾星霜、ハックリベリーフィンを手に取った。どっかで、アメリカの図書館からの排斥のことを見かけて、それがむしろごく最近だということに興味を覚えたってこともある。
いきなり、「僕」が状況分析しながら、いろいろ話し出すもので、あれ? ハックルベリイフィンとトムソーヤのほかにワトソン君のような冷静な観察者がいるんだっけ? と不思議に思いながら読むと、なんということはなく、フィンその人が語り手だった。が、むしろこれは良い訳だと思う。この作品は、冷静な観察とそれに対する分析、内省の繰り返しだから、「おら」だの「おいら」だのの語り口調だったら、違和感があっただろう。
最初の2ページくらいをとにかく読んでいくと、すぐにこの語り手のことが好きになり、あっという間に作品世界に入り込むことができた。こりゃ、傑作だ。確かにマークは良いトウェインだ。
とにかく、いろいろ読まずに伝聞で想像していたのとはずいぶん違って、フィンは全然野性児(なんだろうと想像してたわけだ)じゃなくて、親がいてさえ子は育つ(安吾)を地でいくまともな観察者で、未亡人に敬意をはらっているし、少なくても20までの数は掴んでいるし、読み書きもちゃんと勉強したおかげで本も読める。
ハックルベリィ・フィンの冒険 (新潮文庫)(マーク・トウェイン)
その一方で、図書館から排斥される理由もわからないではない。
まず、はじまってわりとすぐに、親父が延々と自由市民となった黒人をこきおろす大演説があるのだが、読んでいて不快になるほど、とにかく延々とこきおろすので、気分が悪くなる。
出版時には読んで溜飲をさげる人とか、あるいは大笑いする人(たとえば、当時の有名な反動家の大演説のもじりになっているとか)とかがいたのかも知れないけど、そのへんのコンテキストが失われているから、まったく笑えもしなければ気分もよくならない。ひたすら不快だ。こんな連中のために鹿鳴館で屈辱外交してたのか、という感じだ、つまり、過剰感がありすぎる(この過剰感は親父大活躍の冒頭と、トムソーヤ大活躍の終盤の特徴だ)。
そして、最後のほうになると、ジムの救出がメインテーマになるだけに、ハックルベリイが自分の意識の中に築き上げた奴隷と人間の明確な区分けに、いたたまれない気分になってくる。もちろん、ハックルベリイは地獄に落ちることを宣言して壁を崩すのだけど、それは崩すというよりはせいぜい亀裂を入れる程度なので、21世紀の現在からは、大騒ぎするわりにはまったく何も変わっていないという点にいたたまれない感じになるのだろう。
で、それをおれは、まだ他人事な歴史として読めるのだが、直接の子孫がこれを読むと、すでに蒙を啓かれているだけに、内心忸怩たるいやな気分になるのではないかなぁといらぬ想像もしてしまう。ハックルベリイほどの冷静な観察者、因習に縛られていない自由な精神の体現者ですら、奴隷を人間として扱うということに、恐ろしい罪悪感を感じてアンビバレンツするわけだから。同じ人間たる狼と狐のコンビ(ピノッキオとハックルベリイとどっちが先行しているんだろうか)に対して持つある種の連帯感よりも、厳然とした差が書かれていて、まったく子供と旅の良い相棒になった第3者が所有しているため飼い主に返す必要がある犬を、いざ返す段になって駄々をこねている、という書き方になっている。結局は、ここで問題になっているのは所有権の否定が許されるかどうか、という点に過ぎない。実際にはそれほど単純ではないが、同じ所有権の否定でも、野菜を盗むこととは異なる次元の問題(野菜は自分の夢をしゃべったりはしない)とはしているのだが、それでもやはり犬のような書き方になっているのが、読んでいて感じるいやな気分の源泉なんだろう。
自分の先祖が直接おかした愚行を突きつけられると、なかったことにしたがるってのは、普遍的な感覚なのかもな(もし、その感覚がなければ、単に言葉使いの問題だけだったら、排斥を断固拒否できるのじゃなかろうか)。
それから、ハックルベリイが、未亡人とその妹の信心にえらく疑問をもっていろいろ実験して、どうも信心ってのは奇妙なもののようだと意見を表明するあたりとか、論理の組み立て方が素直なので、原理主義的にはあまり子供に読ませたくはないだろうなぁとか。
賢明な女性が家に閉じ込められているありようとか、教養もあり親切で尊敬できる一家の復讐についての愚かしさとか、おそらくまとも(らしく描写されている)なシェイクスピア劇にはこれっぽっちも興味を持たないが、ご婦人と子供はお断りの劇には押し寄せる人々とか、疑わしきはリンチにかけようと待ち構えている人たちとか、いろいろ観察しながら冒険は続く。
すべてがうんざりするのは、トムソーヤが出てきてからで、いったいこれはなんだろう? トムソーヤが飛びぬけて異質なんだろう、とちょっと驚く。それまでの話の、ハックルベリイの物語の進め方ががらりと変わるほどトムソーヤが物語を爆発させるので、一瞬わけがわからなくなるが、そこを通り過ぎると、トムのペースに対してハックルベリーがワトソン君としていい程度に抑制を利かせるので、またおもしろく読めるようになったけど。
印象的なシーン。筏にハックとジムが寝っ転がって空を眺める。すごい星空。あれはどうやってできたのかを話し合う。ジムは誰かが作ったのだろうと言い、ハックは自然にできたんだろうと言う。なぜならば、あれだけの数のものを誰かが作ったと考えるのは現実的ではないようにハックは考えたからだ。それに対してジムは、あれは月の子供なんだと言う。そこでハックは自分の考えのほうが正しいとは思うが、もし月の子供だというのが正しければ、蛙が一回あたりに実にたくさんの卵を産んでそこから山のように子供が孵る、といった知見から、あり得ないことではないので反論するのはやめとこう、と考えるというようなところ。
未踏の報告会でメモした内容(後半、メモがへたってるなぁ)。
登場の背景 Linuxは脆弱 rootを取られると終わり(無制限のアクセス)。一般ユーザーの昇格が抜け道として存在 OS上のレイヤーでがんばるのは限界 ウィルスチェック→更新、抜け ファイアウォール 許可したポートからはアクセス可能 SELinux NSAが開発/公開 OSレベルでアクセス制御機能を強化 不正アクセスの被害を最小限に封じる 2.6標準搭載 (デフォルトでOFF) SELinuxが提供するもの ・アクセス制御 (rootであっても回避不可能) リファレンスモニター ・ラベルベース (タグベースみたいな感じ) (攻撃による被害を最小限に封じ込める) ラベルによってアクセス制御モデルが異なる →情報フロー制御 (ラベルを属性として利用) LSM(Linux Security Module) kernel 2.6以降 LSM準拠実装であれば、Kernel本体の修正が不要(本体へのパッチの適用が容易) セキュリティサーバとAVC(Access Vector Cache) リファレンスモニター高速化 セキュリティサーバは、セキュリティポリシーを探索してアクセス可否を決定(遅い。ポリシーは数10万のオーダー) キャッシュのヒット率(99.5%以上。高速化は数倍以上) TE(Type Enforcement) SELinuxの基本機能 セキュリティポリシー:デフォルトすべて拒否 プロセスに関連付ける RBAC(Role-Based Access Control) ユーザーごと 内部ではTEが使われる MLS プロセスのルールがポリシーのラベルを含む場合のみ実行可能 セキュリティコンテキスト タイプ、ロール、機密度、カテゴリ
良く見たら終わるのは20時なのか。なんかえらく長いな。
購入順序が6-4-5-7-8-9-10-11-1-2で、どうやら1と2が増刷されたらしくてこないだ手に入ったわけだが、それにしても、冗談か何かの間違いだろうというくらい、1巻の絵のへたくそさに驚く。もし最初から買ってたら、最初の1冊で捨てたのじゃなかろうか。
まったく、手を使う職業ってのは、経験を積むのが重要だなぁ。(口を使う職業とか、足を使う職業でもみな同じかも)
_ ma2 [ベルセルク読んでると『デビルマンもこれぐらいの画力で描いていてくれたらなあ』とか思います。]
プレゼンとしては最悪だったが、コンテンツとしては、TBSのが一番うまかったなぁと思い返す。
素材が使いやすい(その素材の権利の所有問題もからみそうだ)ってのと、その素材のこれまでの見せ方のいろいろがわかっているからだろうけど。
具体的には、野球中継のあらゆる箇所にタグを打ち、そのタグからばらばらに引っ張り出すというその出すためのUIとか、そのタグそのものとか。
Expression Encoderにちょっと興味を持ったのはそういうところ。
それに対して、単に手数が増えて待ち時間が多くなるだけの仮想店舗とかは全然だめな予感。
で、やはり気になったのは、帯域消費とかなのだが(1.0は動画配信が目玉)、どう考えてもフラッシュに対するFUDとしか思えない(しかも、よくよく思い返せば、それがフラッシュに対する比較とすら言ってないので、だまされるこちらが悪いような、というか、そもそも何に対しての比較なんだろうか?)理由がわからないお話とかかな。
結局、中はないようだ。
で、買って読んで、子供にやった。
で、肺の中に咲く蓮(上巻でも言及されてたが)に子供が興味を持ってるようなので、カーロフじゃないボリスのヴィアンを貸してやる。
全集版の伊東守男訳がすぐに出てきたので(書影は文庫版)、そっち。
だが、おれは、この伊東守男訳は嫌いだ。言葉の選び方ががさつで、しかも意味が通じないところがところどころある。
学生の頃、アテネに通っていたわけだが、そこでジャックなんとか(さすがに苗字は覚えてないな。プドゥーとかだったような)が、生徒達に、まともなフランスの小説を一冊やるから、おめぇら1人1人読みたいやつを挙げてみろとか言われて、バルザックとかモーパッサンとか古典ばかり出てくるわけだが(あるいは逆にロブグリエとか。サガンもいたかな?)、そして思うにそれはもっともなことなのだが、おれは今思うに赤面ものでもあるのだが、好きなものはしょうがないので、ボリスヴィアンのアンダンの騒乱が読みたいとか言ったわけだ。
そのアンダンってのは、知らないが、ボリスヴィアンは最高だ。君が彼を挙げてくれておれはハッピーだ。もちろん、日々の泡をやろう、ということになった。そりゃそうだよな。でもおれがアンダンの騒乱を好きだというのはしょうがない。でもジャックの気持ちはわかる。もし、おれが日本語学校の教師で、生徒に日本の本を一発やるからお前ら上げてみろと言ったら、村上春樹のパン屋襲撃とか言い出すやつがいるような状況だろう。他の生徒のことも考えたら、パン屋はないよなぁ、というわけで厚さも手ごろで知名度も高いところで風の歌を選ぶというような感じかな(でもおれが好きだったのはピンボールだけど)。むしろ時代的には、織田作之助の六白金星とか言い出す生徒がいて、織田作之助はいいねぇ、でもやるなら夫婦善哉ですな、という感じのほうが近いか。
で、その頃には、新潮社版はすでに絶版か版元品切れになってたはずで、全集版の伊東守男を読んでたのだが、意味がわからないところが結構ある。ところが、原書をジャックの解説付きで読むと、実にクリアにわかっていくのであった。結局、読んで意味がわからないところは、そういう特殊な表現なのではなく、単なる誤訳なのだった(特に印象的だったのがスケートリンクでの大虐殺のあたり)。というのもあって、早川版はちょっと辛い。それにおれの受ける印象では伊東訳は右岸っぽい。
だいたいにして、題が問題だ。desはjoursにかかるんだから、うたかたの日々ではなく、日々のうたかただし、それにうたかたではなく泡じゃなきゃならない理由がある。少なくても現在の日本語では、石鹸のあわぶくをうたかたと表現することはない。泡は泡だ。
トムとジェリーのジェリーが台所の流しで泡まみれになって遊ぶシーンがある。でもこの泡は石鹸の泡じゃなくて、窓から差し込む陽光の泡だ。で、陽光も日々も同じ言葉だ。したがって、題は日々の泡でなければならない。
はじめてボリスヴィアンを手にしたのは、そのころからさらに4年くらいさかのぼる。高校生の頃だ。図書館におれが大嫌いなペイネの絵を使った本があって、ペイネは大嫌いだが、題名があまりに奇妙なので手に取らずにはいられなかったのだった。それが日々の泡。
(書影は文庫版。よくぞ復刊してくれました、という感じである)
これはびっくりした。言葉を使ってこういう表現ができるのか。サルトルやカミュではない、まったく別の方法による実存主義文学ってやつだ。えらく気に入って手元に置いておきたかったが、その時点ですでに入手できない状況だったのだが、その後、なんの勘違いか早川が全集を出したので、そちらを買い出して、結局、手元には伊東訳のうたかたの日々になったのであった。しかし読むたびに、こんなんだったかな? と疑問は膨らむばかり。で、原書を読む機会を得て、うたかたは弾けることになった。
で、それからしばらくして、流行通信か何か読んでたら、私の本棚みたいなコーナーで、プラスティックスの佐藤ちかが、「日々の泡」とか書いてて、なんか恥ずかしくなったのであった。だって、日々の泡は売ってなくて売っているのはうたかたの日々なんだから。でも、まあ、そういう内容の本ではあるなぁとも思った。
そういえば、ボリスヴィアンのシャンソンに、僕はスノッブってのがあったなぁ。ああ、そんな感じ。いやだね。他人にスノッブと言われたら、もうスノッブじゃない。そういうスノッブのアイテムなのか。まあ、確かにそうだな。それが、このプラスティックから受ける印象か。
で、なんとなくそのまま本棚の奥に埋もれて数10年が経過したころ(新潮文庫版は、思わず買ってしまったが読み返さなかったなぁ。で、こっちを子供にやろうと思ったら見つからない)、突然、マンガ版が出る。
うひょーはずかしー、しかも岡崎京子だし。と思いながらも、つい買ってしまって、こちらはちゃんと読んだり。しかしもう読んでも特に思うところも無く。というか、これは伊東守男をさらに劣化させたバージョンにおれには感じる。すでにスノビッシュですらない(なんか、相乗効果が望めそうなのにも関わらず、かえって潰しあってしまったような。というか言語表現をどう絵で表現するかの難しさってのはあるだろうけど)。まあ、それは良いことのような気もするけど、高校生の頃、初めて新潮社版を手にしたときの驚嘆からはずいぶん遠くへ来てしまったものだ。
というわけで、高校生の頃に読んどいてよかった。
船を建てるも、中学生か高校生の頃に読めば、もっと幸福だったろうな。
チェリーが歌う、ドゥドゥドゥは、ワイルドサイドを歩け。
ロバンソンはこれかなぁ?
GASPARD ET ROBINSON ガスパール~君と過ごした季節 ガスパールキミトスゴシタトキ [DVD](ジェラール・ダルモン)
多分、ファスビンダーは関係ないとは思うが、おれはファスビンダーが好きだ。
戻り値の型がjava.lang.Objectかつ実際の型がjava.lang.StringかつRjb::primitive_conversionが真の場合に、RubyのString型のオブジェクトに変換するようにしました。
その他、Javaのメソッド呼び出し時に、型がRubyのBignumでかつint64の範囲の場合、ゴミをJavaに与えていたのをjava.lang.Longに変換することと、変換できない場合は例外をスローする修正の追加(テスト中に気付いた)。
x64 Linuxで、Doubleのコンストラクタ呼び出しに限りなく0に近い値が与えられていた良くわからない現象の対応。(x64のdoubleも64ビット幅だと思うのだが128ビット幅なんだろうか?)
無責任な放言ではあるが、コードに求められるものが、
* オブジェクト指向はテストしづらいから使うな
* ひとつの長い流れにしたほうが見通しがいい
* エンジニアに個性なんて必要ない
* 本格的なコードは書くな、ステップ数を短くしろ
で、かつ、給料とか諸条件が良かったりして、まだやめないで済ませたい場合にはどういう方法で折り合いを付けることができるだろうか、考えてみる。
すると、ここで求められているコードは、まさに単純な自動生成向きなこことに気付く。
だらだらコードを機械的に吐き出していけば良いように見えるからだ(最後の条件が2番目の条件と矛盾しているようにも思うけど)。
ジェネレーションギャップ用のスタブも不要だし(というか、オブジェクト指向言語の特性を生かさなければ、ジェネレーションギャップパターンは適用するのが難しいから、逆に向いていることになる)、常に最初から生成して行けば良い。真に重要な定義ファイルを確保しておけば、いつでも再生産できるので、それで良いのだ。
実際のところ、納品物と開発するものが同一である必要はないのだから(等しい必要はもちろんあるのだが)、そんなことを試してみるとおもしろいかもなぁ、とか思った。
確か、以前角谷さんが用語が持つアフォーダンスというような記事を書かれていたのを読んだ覚えがあるのだけど、アフォーダンスとsite:kakutani.comでは見つからない。
確か内容は(まったくの記憶違いかも)、assertを表明すると訳すか、検証すると訳すかについてだと思うのですが(書いていて自信がないけど、もしかしたらBDDに関することかな? だとすると以下は見当外れで、僕が自分で勝手に考えただけか、あるいは自分で咀嚼しきった何かなのかも)。もし、出典をご存知のかたは、ツッコミで教えていただけないでしょうか?
英辞郎でassertionをひくと、名-1として主張、表明といった定義があって、名-2にはコンピュータ用語としてプログラムの形式検証における成立条件 という書き方をしている。
テストプログラムの、assertEquals(0, foo.getCount()) を実行するということは、fooの動作を検証しているといっても間違いではない。というか、実行しているときは表明しているのではなく、検証している。
では、テストプログラムを書いているときはどうだろうか?
assertEquals(0, foo.getCount());
と記述した時点では、foo#getCountが未実装の場合さえある。したがって、この行を書いている瞬間は、まさにfoo.getCount()が(その直前のプログラムの記述にしたがって動作している限りにおいて)0を返すというあるべき振る舞いを表明しているとしか表現しようがない。
テストプログラムは、すると2つの状態を持つ。記述時点での表明と、実行時点での検証だ。
したがって、assertionを表明と訳すか、検証と訳すかは、どちらを主とみなすか、の差だ。プログラマはまずプログラムを実行する人よりも前にプログラムを書く人である。したがって、assertionは検証ではなく、表明であるべきだ。
というような感じ。
#わかりやすさ(表明っていう日本語は普通の日本人の語彙には入ってないとおれは信じる)と、説明ゼロ(同じ理由から)で意味を通せるので、「検証」と訳して突っ走りながら、ふと振り返って考えて、やはり「表明」であるべきだろうか、とちょっと迷っているので、ご意見もツッコミ歓迎です。
いやまあ、おれもその意味では配布パッケージのメンテナンスをしてるわけだが、 mputさんのある意味恒例のdis。
(追記:メンテナンスとサポートの微妙に似て違う点をずらしてメンテナンスに振ったところが技のようだ)
今、アマゾンでサーチ対象をAmazon.co.jpにして「レトロスペクティブ」で検索すると、5点ひっかかる。
トップは、
(なぜ?)
最下位は
(増村保造は、好きな作家だけど、こんな本も出てるのか。大映で妙な題材の仕事をずっとやらされてた際物の人という印象もあるけど、逆にそのせいで独特な語り口を持ってた)
でも、それが書きたかったわけじゃない。ので、続く。
ミッションクリティカルな現場って、インターネットへアクセスできなかったり、アクセスできたとしてもポート80かつGET以外のリクエストを弾くから、電話以外ではどうにもならないとは思うが、もう少しゆるいところであれば、実はすでに行われているというのを見たことがないわけでもない(OKWaveとか@ITとかじゃないよ)。
見たことがあるのは、互助的なものだし、はしにもぼうにもかかわらない人からのSOSではないけど、ああいうやり取りを見ると、必ずしも未来永劫無理ということはないだろうな、と感じる。もうちょっと職能分離が進むかして(普通の会社の話。つまりやれているところ!=普通の会社 ではやれているわけだから)、専門家ネットワークのようなものが機能すれば良いわけだろう。
要するに、インセンティブは、ESRが発見したものがそのまま利用できるからだ。
追記:趣味の金はどこから来るのか。
それが、削減した教育コストであったり、専門職に対する定期的な研修(と、これも教育コストか)から来るということです。
今でも教育コストをかけている企業も多いかも知れませんが、職能分離がすすむということは、その職能を維持するためのコストの負担を個人に求めるということであり、代わりに直接的な費用としてではなく、回線と時間によって払われるということになるのでしょう。端的に言えば1人を雇う(かつ8H220Dフル稼働も無いことになるが、もともと時間で雇うという考え方から外れる方向にあるということもあるわけで)ことで、その裏側に多数存在する専門家ネットワークも一緒に導入できるということかな。
転職したときに、持ち出せる脳みその中身を企業が金を払って身につけさせる時代って、とっくに終わってると思ったけど、まだそうでもないのかな。(書いてて思ったが、それは減価償却と考えるのかな?)
#長文をPOSTしているということは、そういう時間ということですね。
追記:最後の1文を見逃してました。趣味ってなんでしょうね? 契約に縛られていない行動、という意味で僕は使ってますね。契約に縛られていないということから、直接の責任を持たない(しかし、ソフトウェアについては免責条項は明確に趣味ではないものでも持っているので、そういう性格のものだと言えなくもなさそうだ)、ということです。倫理で律せられる行為、というと一番しっくりくる。
さらに追記:うん? なんか誤読されてるようだな?
僕がOSSサポートを見たのは、本当に傍観者として見たということなのだが。そういうのって、ircとかchatとかで流れてるじゃん。で、そのやり取りを見ていて、おお、若い人たちはすばらしい世界を作りつつあると感銘を受けたのだった。
why,whyとないている。
The site is based on cutting-edge, open source programming frameworks such as Ruby on Rails for collaborative website development.
と書いてある。でも、such as って、「Railsなどの」であって、全然別のcutting-edgeを使ってるのかも。たとえばルビーじゃなくてWebサファイアとか。
via るいもさんの日記
とつぜんだけどおれは6月2日が一番好きだ。やっぱり緊張感があるよね。
いや、おれがさがしてたのはこれじゃないんだが(検索語:アジャイル)、
RailsによるアジャイルWebアプリケーション開発 第2版(Dave Thomas)
DHH本の第2版が予約可能になってる。これはDave Thomasはからんでいないのかな?
角さん(と表紙には書いてあるし)からいただきました。どうもありがとうございます。まあ、大体読んだ。これはいい。
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き(Esther Derby)
どちらかというと、直接は役に立たない(Howto本じゃない)が、読めば考える元になり(思想とか思索とか、というよりカタカナでパースペクティブがあり)、いろいろ深堀りするためのきっかけとなる書籍でおなじみのオーム社同時代開発者叢書の最新刊。訳者は、ぶりきじゃの角さんで、しかもジョエル本を訳された青木さんの厳しい突っ込みが入りまくってさらに磨かれたという本。
で、僕はこの本にはいろいろ教えられた。今までのやつより(チャドファウラーのインド本はガイドと銘打った実用書の体裁を取っているけど)現実への適用可能性はすごく大きい。というかプラグマティックプログラマーズの本棚シリーズだから当然なのだが。
まあ、読めば話は早いが、最初にレトロスペクティブとはどういうものかのパースペクティブがあって、それからアクティビティ集(レシピ集というか、お題集と考えればよいかも)がえんえんと続く。実用書っぽく、2〜3ページくらいの単位でテーゼがあって、ハウツーがあって、事例を再構築したと思われるケーススタディがある(で、1アクティビティ)。ミーティングのお題パターン本といっても良いかも。(あえて僕はミーティングというニュートラルな書き方をしている点に注意)
で、最初のパートで、レトロスペクティブなミーティングとは何か、何のためにやるのか、どういう手法でやるのか、その意義は、ゲインは何か、といったことが説明される。そうか、ミーティングってそういうものなのか、いや、こうであるべきだ、と教えられる。特に最初に全員に口を開けさせることとか、当事者意識を与えるための種々の方策とか、一時的な離脱についてとか、思い当たる節がいろいろあるだけに、ここに書かれていることは大筋でまったく正しいのだろう(逆に言うと、どこがアジャイルなのか、という疑問が出てくるかも知れないけど、それについては後述)。
可能ならば、つまり自分がリーダーのロールで開催しているミーティングを持っているのなら、読む価値は現実的なご利益つきであるし、参加者の立場であれば少なくても自分にとってミーティングのひと時の価値を高めることができる可能性があるし、たった一人プロジェクトであっても何に着目して考えるかについての大きな示唆となる。
上で、自分がミーティングをリードする立場であれば、と書いたけど、いきなりこの本を読んだ次のミーティングからこのスタイルをとるのは、自意識があればちょっと難しいかも知れない。だっておそらくそれまでとは違うスタイルになるから、参加者からこいつ悪いものでも食ったんじゃないかと思われる可能性があるし、そう思われなくても、そう思われるだろうな、と自分が意識してしまう可能性がある。だから、少しずつ、やるべきことを咀嚼して少しずつ導入していくか、さもなければ開き直って全員にまずこれを読めと与えて読ませて、こういうやり方でやりましょうと合意を取ってやるか、ということになるかも。
あと、まあ、違う考えも同時に載っているので、むしろ良いのだが、僕はレトロスペクティブとカタカナにしたのは正解だと思う。もちろん、それは人によって受ける印象は違うわけだが。
僕にとってレトロスペクティブという言葉は、1. ファッション(デザイン)用語の「レトロ」の正式な言い方、2. 美術館の特設展のお題の2種類で、後者について、たとえば
・トスカニーニ大回顧展
・トスカニーニレトロスペクティブ
・トスカニーニふりかえり
と並べれば、(3番目のはこの場合、意味がないおまけだけど)、1と2の差は明らかだ。1の場合は、おお、そんな人もいましたな。こんなことをしたのですな。という過去のものを過去のものとして楽しむための名前だ。でも2は違う。過去にいたそんな人がどのような人でどのような作品を残し、それによってでは現在のわれわれはそこから何をどう広げていくのか、という広がりを与える(もちろんパースペクティブという雰囲気が似たカタカナとの語感による連想がはたらくせいかも知れない。あとレ(リ)スペクトを重ねて読んでしまうという点もあるかも)言葉だからだ(漢字による意味の固定化を免れるというのがカタカナの一番のご利益で、洋モノを和モノより上に見るバイアスを刺激するという俗説は間違いだと思う)。
それから、これが一番感銘を受けた点なのだが、とにかく暗黙知を徹底的にくだいて形式知化する(40近いアクティビティカタログももちろんそうだが、第1章のあるべき姿の提示がすごい)姿勢が見事だ。しかもそれがアジャイルという価値観(アジャイルの価値観って、結局は人間を人間として処遇することで、人間の能力――機械には不可能なもの――を発揮させるということに尽きるんじゃないか)で貫かれている点だ。
どうもありがとうございます。
前号から妙につまった間隔で出てきた気がするけど、それは前号が遅れたからなのかな。
あ、しまった。Ruby.NETがBSDライセンスへ移行したってのは、Ruby関連ニュースなんだから、たれこめば良かったのか。
初めてFUDというかデマを飛ばされた。むかむか。まあ、初めて気付いただけで、他にもあるのかも知れないが。
じゃじゃめん食いに行こうと思ったら雨が強くて迷う。
最近、車の中ではこれを良く聴く。というか、一貫してずーっと聴いている。もっともiTunesから仕入れてCDへ焼いたオーケストラルマヌーバーズインザダークのベストとかも聴いてるけど。シカゴ、ポリーニ、アバード。
一方、家の中ではこっち。ボストン、サーキン(ピーターのほうのゼルキン。この演奏時はまだゼルキンだったのかも)、小澤(追記あり。嘘だった)。もっとも、家の中ではトスカニーニとかも聴きまくっているので、こればっかりというわけでもないけど。
バルトーク:ピアノ協奏曲第1番&第3番(ゼルキン(ピーター))
もちろん、スピーカーも違うし、再生機器の違いによる音の違いってのはあるにしても、それにしても、同じ協奏曲1番がどうしてこれほど違う曲になるのか。
同じアメリカの交響楽団、アメリカから見て異国から来た黒髪の指揮者。もっともポリーニのは多分80年代だろうけど、サーキンのは60年代と20年の時間差があり、東部と中部の差も大きいんだろうかな。
ボストンの響きはあくまでも柔らかく、どれだけ金管が鳴り響こうと、柔和な顔を崩さない。一方、シカゴは劈く(なんだこの漢字は)ように鳴り響く。オーケストラの音だけだとボストンのほうが好みだ。
これはオーケストラの音の違いなのだが、少なくてもおれがイメージとして持つピアニスト側の音色の違いと同じに感じる。硬質なポリーニに対して軟質なサーキン、もっともどっちもクリアなのだが。アバドとポリーニだと感じるスリルなせめぎ合いが、サーキンと小澤だと玄妙に融合した感じとなる。その代わり、サーキンは時々だれる。もともとゆっくりめなテンポを取っているのだが、それが(かんじょ楽章、変換しない。かんじょも間違った読みなのか? う、えんじょか。どっちにしても変換されないが)緩徐楽章になると相当辛くなる。緊張感があまりないのだな。というか、全体的にそういう演奏だ。ほわほわした柔らかさで取り止めがないようにも感じる。にも関わらず音の美しさは相当なもので、確かに登場時の新即物主義に慣れた人たちには斬新だったかも知れない。
ポリーニのほうが好きだが、サーキンもいいな。第3番の冒頭とか。遠くのほうで思い出しながらどんどん速度を上げていくところ。でも繰り返しているうちに遅くなったりまた早くなったり、しているうちにオーケストラが追いついてくる。
シェーンベルクがおまけのように入っている。嫌いな作曲家どころかむしろ好きな作家ではあるけれど、バルトークに比べるとずいぶんとつまらない(BGM的に聴いていると。まじめに聴くと高密度なため、すさまじく面白いのだが、疲れる)。
ボストンというと、学生の頃に読んだロバート・B・パーカーを思い出す。ドーナッツ、駐車違反と、石畳。船を建てるには、自ら羽をもぎとった天使あしかのBパーカーってのが出てくるが、ここから取ったのだろうか?
初秋 (ハヤカワ・ミステリ文庫―スペンサー・シリーズ)(ロバート・B. パーカー)
初秋から入って、それなりにはまって数冊読んだが、だんだんうんざりしてきた。頭の良い人が、チャンドラーに上手にお色気とか人種のかかわりとかそれなりに時事的な状況ネタとか、いろんな要素をうまく詰め込んで、感傷をフレーバーにして、もっともらしい説教を垂れて納得させるというようなスタイル。
でも、それはシリーズの同工異曲を短期間に読んだからなのかも。あらためて初秋とか読むと、また味わい深かったりするんだろうかな?
追記:あっと、びっくり。良くCDのジャケットを見たら、小澤−サーキンはボストンではなくシカゴだった。信じられない。この後のショルティ時代に変わったのか、それとも純粋に指揮者の違いなのか(いや、音色にとっては録音技師の違いってのもあるだろうけど)、全然別物だというか、おれにはボストンとのコンビの音と同じに聴こえる。で、不思議に思って調べると、この録音時点では、まだ小澤はボストンには就任していなくて、結構、シカゴとコンビを組んでいたのであった。ということは、この音は交響楽団の音ではなく、小澤の音だということだ。
作曲家と作品番号という絶対的で不変なURIがある。
それに対して演奏家というユーザーエージェントを通してアクセスする。URIは変わらないがフェッチできるのはあくまでもリプレゼンテーションであって、コンテントそのものではない。
コアが変わるとx.y.zのyを上げるという決まりではあるけれど、コアのパッチレベルがあがっているだけなんだから、次は4.1.110のほうが良いのではないか? というようなのってどこに書けば良いのだろうか。
なんか野次馬として行く都度、ROM-BASICの命令を連呼しているようで不思議である。
ジェズイットを見習え |
Before...
_ arton [確かに見ると魅力があったし(ファーストガンダム見てからガンダムはナノシールドしてたのだが、ちょっと発掘されたらしい)..]
_ きむら(K) [トミノ作品のダイジェスト映画は、絶対的に尺が足りないので どうしても一見さんお断り的な感じになってしまうのは どうし..]
_ arton [あと、登場人物が多彩で背景がしっかりしているから、ダイジェストだと辛いのかも知れませんね。 趣味か、は22話です(羽..]