| 著作一覧 |
ひさびさに原宿で飯でも食うかとうろうろしてたら、チェコ料理の店の看板を見つける。チェコ料理というのは食ったことがない。したがって、そこに入る。
で初見だけど間違えようがないひなぎくを観ることになったのであった。
おしゃれな女の子二人が、モンタージュの合間におどけたり飛び跳ねたりうろうろしている。プラハの春の国なのだな(まだ、春は来ていないが、その到来を呼び寄せるためのお祭り騒ぎなのかなぁとか思うと、実は物悲しい)。最後は、なぜか労働に目覚め、テーブルの上で、幸福って言いなさい、というセリフ。終わりが見えていたのかも。それは見えるだろう。ブレジネフが1964年、ひなぎくが1966年、プラハの春が1968年。また、パラジャーノフの同時代人、同体制人というのがすけてみえるコラージュのオンパレード。
味付けは好みに合う。ビールは飲まないからわからないけど、ビールも売り物のらしい。ジャガイモのお好み焼きというかオムレツというかに、ピクルスのソースがかかっていておいしかった。
客単価は2000円程度なので、あまり気軽に入れるというわけではないが、そのわりに月曜日にはチェコアニメの日なんていうのがあったり、おもしろい。カエルの台所用品とか。
RjbがimportしたJavaのクラスをRjbはObjectとして持っている。
require 'rjb'
jstring = Rjb::import('java.lang.String')
p jstring # => #<Rjb::Java_lang_String:0x2f0490>
だから、newメソッドは他のクラスと異なりインスタンスメソッドとなっている。
p jstring.method(:new) #=> #<Method: #<Rjb::Java_lang_String:0x2d0334>.new> p Array.method(:new) #=> #<Method: Class#new>
そのため、newメソッドに介入して作られたJavaオブジェクトのプロクシにメソッドを追加したりできる。
module RjbAddon
def java_class
self._classname
end
end
jstring.instance_eval do
alias :org_new :new
def new(*args)
pxy = org_new(*args)
pxy.extend RjbAddon
pxy
end
end
hello = jstring.new('hello')
p hello.to_string # => "hello" /* Java method */
p hello.java_class # => "java.lang.String"
ここで、RjbのJavaクラスのnewメソッドに介在してメソッドを追加する汎用の仕組みを考える。
module RjbAddon
def java_class
self._classname
end
def self.mixin(jclass, &proc)
jclass.instance_eval do
alias :org_new :new
def new(*args)
pxy = org_new(*args)
pxy.extend RjbAddon
pxy
end
end
end
end
RjbAddon.mixin(jstring)
RjbAddon.mixinに追加のブロックを与えて、そこで定義したメソッドを組み込ませたい。
RjbAddon.mixin(jstring) do # こう書けるようにしたい。
def say_hello
puts 'hello'
end
end
hello = jstring.new('hello')
hello.say_hello # => 'hello'
しかし、次のようにmixinメソッドを定義してもうまくいかない。
module RjbAddon
...
def self.mixin(jclass, &proc)
jclass.instance_eval do
alias :org_new :new
def new(*args)
pxy = org_new(*args)
pxy.extend RjbAddon
pxy.instance_eval do
proc.call # => tried to create Proc object without a block (ArgumentError)
end
pxy
end
end
end
end
instance_evalの中でスコープが変わる(通常のブロックとは違うわけだ)ので、procという仮引数が見えなくなるからだ。
そこで、RjbのJavaオブジェクトのインスタンス変数としてみる。
def self.mixin(jclass, &proc)
jclass.instance_eval do
@user_new = proc
alias :org_new :new
def new(*args)
p @user_new # => # 見える
pxy = org_new(*args)
pxy.extend RjbAddon
pxy.instance_eval do
p @user_new # => nil ここのselfはpxyなので見えない
@user_new.call
end
pxy
end
end
end
そこで外ざしできるようにする。
def user_initialize(proc) # 外ざし用メソッド(ミキシンする)
instance_eval do
proc.call
end
end
def self.mixin(jclass, &proc)
jclass.instance_eval do
@user_new = proc
alias :org_new :new
def new(*args)
p @user_new
pxy = org_new(*args)
pxy.extend RjbAddon
pxy.user_initialize @user_new # 外ざし
pxy
end
end
end
しかし、これもうまくいかない。
p hello.say_hello # => in `method_missing': Fail: unknown method name `say_hello' (RuntimeError)
与えたprocのselfがmainのままだからだ。
しょうがないので、ミキシンメソッド呼び出し時に与えるブロックでselfを取れるようにしてみる。
module RjbAddon
def java_class
self._classname
end
def user_initialize(proc)
instance_eval do
proc.call self # instance_eval内のself
end
end
def self.mixin(jclass, &proc)
jclass.instance_eval do
@user_new = proc
alias :org_new :new
def new(*args)
pxy = org_new(*args)
pxy.extend RjbAddon
pxy.user_initialize @user_new
pxy
end
end
end
end
RjbAddon.mixin(jstring) do |x| # xはプロクシ自身
def x.say_hello # 自身の特異メソッドなので利用可能
puts 'hello'
end
end
...
hello.say_hello # => hello
しかし、mixinメソッドにブロックを与えて、そこにプロクシのselfが渡されるのは気に食わない。(def x.say_hello と書くところ)
どうすればmixinメソッドに与えるブロックのselfをそのまま作成されたプロクシのselfとできるだろうか?
子供がえらくおもしれぇから観に来いとかいうので行ったら、二つの塔のメイキングを観ていた。
massive(MASSIVEかも、というかWikipediaにも書かれてた。アバターにも使われてるのか)とかいう二つの塔用に作った3DCGのフィギュアリングとシミュレータの合体のようなプログラムのことをいろいろ喋っていて(当然、システムの画面やら操作画面やら、実際のシミュレーション映像とかも見られる)、その中で、戦闘シーンに使えるか実験的に1000vs1000のバトルをやらせてみた、というところだった。
10vs10では観られなかった現象として、1000vs1000でやらせたら、遠くへ逃げ去る兵士が何体か出てくるというのを再現させてた。
ピーター・ジャクソンが笑いながら喋る。「すげーシステムだ。本当の戦争みたいに、1000人の敵を前にすると、こりゃやばいと逃げてく奴がいるんだぜ」
実際は(とエンジニアが語る)、単に目の前の敵に向かって至近距離まで走るようにプログラムしてあったため、1000体をランダムに配置すると位置関係で真横(敵が視界にない)を向いて配置されてしまう兵士が何体かあったということだった。
にしても、ランダムにプロパティを変えると、それによって髪のなびき方まで変わるから、カメラの直前を通過してもCGらしく観えないとか、えらくうまくできていて、感心した。これが10年前の技術なのか。
ロード・オブ・ザ・リング 二つの塔 スペシャル・エクステンデッド・エディション [DVD](イライジャ・ウッド)
(スペシャルエディション ——実際はそれだけならばまだ良いがトリロジーなわけだが——を買ってやったおかげで、目の保養ができた)
その一方で、
・半壊した大聖堂のモデル(リアル3D模型)は、作ってから壊した。そのほうが最初から半壊した模型を作るよりも早くて安い。
・投石器で石をぶつけて塔が壊れるシーンは、模型を使った(最初はCGでやろうとした)。砕ける岩とか舞い上がる埃とか、実際に模型でやってみたら、さすがにこれをCGで作るのは無理だとわかった。
とか、リアルものの教訓もおもしろい(当然、これも映像が入る)。
これは、技術的に映画本編(無論おもしろい)よりもむしろおもしろかった。
で、つくづくおれがピーター・ジャクソンをすげぇ/おもしれぇと思うのは、メイキングまで含めたビデオを作っておいてそれで商売するというマネーメイキングのうまさということではなく、そういった映画作りの技術的なこと(失敗とかも含めて)を異様なまでに記録してそれを見せようとしていることだ。おそらく感覚としては、オープンソース(とは違うわけだが、かといってプロプラエタリ技術のエバンジェリスムというものでは無いし)の開発者に近いものがあるのではなかろうか。
たとえば、単なるメイキングとは別に、自分達で本編に対して茶々のようにも取れる解説「ここを、こう撮影したのは、これこれという理由で、今観ると、これこれというやり方もあるけれど、この時点ではこれこれ」を音声で入れていたりとか、まるでコーディングインスペクションの前に自分でソースを解説しているようなものだ。こいつも滅法おもしろい。
子供が飯を食いながら流しっぱなしにしているので、今度はロードオブザリングのメイキングを観る。
ロード・オブ・ザ・リング ― スペシャル・エクステンデッド・エディション [DVD](イライジャ・ウッド)
っていうか、これは才能あふれるスタッフたちを紹介するための作品なのだな。
ニュージーランドってのは不思議なところだ。ピータージャクソンが映画を作る、本気で作ると言い出して、アートディレクタに仕事を任せると、そこらじゅうからアーティストがうじゃうじゃやって来て、すごい勢いでデザインして模型を作って服をデザインして作って、タペストリーをデザインして作って、武器をデザインして作って……製作が始まる。
トールキンの挿絵画家の2人を手を尽くして招聘するところとか、まるで水滸伝みたいだ。一人は既に仙境に入って電話も通じなかったとか(ハウじゃないほう。さっそく名前は忘れているが)。
オライリーの高さんからRubyベストプラクティスを頂いたので、ぱらぱら読んだ。妙に読みやすいので、それでもほとんど読んだようなつもりになってしまえるのはなぜだろうか。
これは妙な本だな。
まず、これはRubyとは何か? を説明した本ではない。そういう本ならキリンの本がある。
次に、この本は、〜を書くにはどうすればいいんだ? ってときに紐解く本でもない。そういう本なら白地に青い本がある。おれが持ってるのは赤地の本だけど。
そういうときには〜ライブラリを使えっていうような本でもない。
Ruby 逆引きレシピ すぐに美味しいサンプル&テクニック 232 (PROGRAMMER’S RECIPE)(島田 浩二)
ある種の技術を解説するためにRubyを使った本でもない。
Rubyで作る奇妙なプログラミング言語 ~Esoteric Language~(原 悠)
リファクタリング:Rubyエディション(Jay Fields)
高橋さんがあとがきを書いていて
中・上級者向けのRubyプログラミングに関する解説書である。
と定義している。
これってでも不思議だな。Cにはベストプラクティスなんてなくて、あるのは、記述すべきプログラムに対して最適な書き方だけだし、(ほとんどの)Javaにはベストプラクティスなんてなくて、あるのはどうでも良いコーディング標準だけだ。
しかし、Rubyには(高橋さんの後書きによればPerlにも)ベストプラクティスがある。
ベストプラクティスってのはなんだろう? イディオムのようだがイディオムではなさそうだ(たとえばRubyのイディオムならば、val ||= INIT_VALUEとかある)。もう少し考え方(設計方針というか)が含まれているように見える。かといってデザインパターンではない。もっと遥かに具体的だ。
Rubyベストプラクティス -プロフェッショナルによるコードとテクニック(Gregory Brown)
まあ、でも帯を読むと角谷さんが正鵠を射た軽いフレーズを書いていて
Rubyっぽいコードの書きかたと考えかたが詰まってます。
と、っぽい書き方/考え方=ベストプラクティスとしているみたいだ。そんな感じだ。
しかも、こないだ中田さんのコードを見ておれが学んだことが、ちゃんと出ていたりして。
&blockとinstance_evalを組み合わせると、任意のオブジェクトのコンテキストでブロックを実行することができる。
—P.54
ちぇ、あの時、すでにこの本は届いてたんだよな。でも封は切ってなかったのだった。
というわけで、比較的最初のほうで、こういった実際に利用するし、しかしあっというまに迷路に入り込むような書き方の方法が説明されていたりするわけだ。
つまり、ベストプラクティスが必要な言語ってのがあって、それは、いろんな書き方ができるから、ではこういうこともできるはず、とやってみるとうまくいかなかったりして、しかし、確かにその「できるはず」は正しく、方法さえ知っていればできる、そういった言語、つまり柔らかくていくらでも伸びしろがあって、使いこなせばどうにでも自在にやれる言語の場合、その方法を知るには、処理系のソースを読むか、どこかからその自分がやりたいことをやっているソースを持ってきて読むか、そういった実際的な学習が必要な言語、なのだろう。で、Rubyはそういう言語なわけだ。(と一度、この日記をコミットしてから、実は「はじめに」を読んでいないことに気づいて読んでみたら、同じようなことが書いてあった)
で、少なくともおれがあの時知りたかったことは説明されている。つまり実用的な本なのは間違いない。
ところで、脚注におそらく高橋さんが付けたらしい #!/usr/bin/env rubyという書き方はお勧めしないというのが、説明抜きで出てくるけどなぜだろう? Linuxのenvだと-Kuとか付けるとエラーになるからかなぁ。
しかし、カニといえば、子供はカニ座なのだが、星座の物語がギリシア神話にあると知って、大喜びでカニ座の物語を読んで、あまりの唐突な出現と退場のふがいなさにショックを受けていた姿を思い出す。
昨日、逆引きレシピをアマゾナイズ(日記に書影を貼ること。今、湧き出た言葉)していて気づいたのだが、この本は不幸だ。
Ruby 逆引きレシピ すぐに美味しいサンプル&テクニック 232 (PROGRAMMER’S RECIPE)(島田 浩二)
1241位 ─ 本 > 暮らし・健康・子育て > クッキング・レシピ
どう考えても、フェアな勝負じゃない。
このジャンルの競合たちは、たとえば
なんだかよくわからないけど、これが今は1位だし、
こんなフォトジェニックなのとか。本屋で平積みになってたら、そりゃハッピーママライフのほうに手が伸びるだろう。
しかし、ハッピーママライフって相当不気味な語感だなぁ。ハッピーなママライフなのか、ハッピーママなライフなのか。ハーピーなママとか(諸星大二郎とか、山岸涼子的ななにかだ)。
というか、『すぐに美味しいサンプル&テクニック 232』って、どこに書いてあるんだろう? 手元のやつにの表紙にはないんだけど(良く見たら輪の中に書いてあった)。
でも、レシピブックのほうは、同じ土俵で勝負していなくて、Rubyとソフトバンクだけなんだよな。
コンテキストを無視して、自分の知っているコンテキストのみで何かを語ろうとすると、同じく自分が知っているコンテキストのみで語る人と用語がコンフリクトして建設的とは言えない状況が生まれる。
というわけで、なんとか渡しについて、ある程度知っていることを並べて、どういうコンテキストではどういう言い方があるかをまとめてみる。
| コンテキスト | 用語 | 参照 |
|---|---|---|
| Haskell |
| Programming in Haskell Chapter 12 Lazy Evaluation |
| VB |
| Argument Passing ByVal and ByRef |
| Java | The effect of this is to assign the argument values to corresponding freshly created parameter variables of the method. | 15.12.4.5 Create Frame, Synchronize, Transfer Control |
面倒になったからやめたけど、ようするに、Haskellのcall-by-valueを「値渡し」と訳して、VBのByRefを「参照渡し」、ByValを「値渡し」と訳した場合に、HaskellコンテキストではVBの「参照渡し」というのは「値渡し」なので、そりゃあ言葉が通じないよなぁ、ということ。あと、Javaの言語仕様には"call by"や"call-by"という言葉が出てこないのは、すべて値渡し(VBの意味でもHaskellの意味でも)なのでそういう用語が必要ないからだろう。
日本語版Wikipediaの評価戦略は英語版のEvaluation strategyの翻訳みたいだ。戦略(言語の設計/実装戦略だな)だけにたくさんある。
追悼。
世界には何種類かの人々が住んでいる。
予知能力を持つ神官を頂点とする王国。
科学技術と合理性を尊ぶタウリッシュと呼ばれる集団。
辺境の部族。
乗り物は竜。人々はどうやら宇宙のかなたから来たらしい。
そして火山が噴火し、大陸がばらばらになる夢を大神官が見る。人類を生き残らせるためには、神託、デマ、原始宗教、権力、軍事力、大衆芸能、科学、なんでも利用して、とにかく人々を散り散りにし(生き残る可能性がある場所がどこなのかはわからない。したがって、人々が固まって暮らしていること、それがリスクとなる)なければならない。
そのためのプロジェクトチームが結成され、科学と魔法、芸能と権力(世俗の権力の頂点に立つ(つまり王)弟との確執のため、なかなかこれが利用できないのだが、最終的には協力が得られるのだが、頭では理解しているのだが、国民に納得させるための理由が欲しい王と、予知能力で終末が来るのが見えているだけに理屈抜きの説明しかできない大神官と、地質調査などから終末を推測した結果理屈のみで説得にくるタウリッシュが、なかなかうまく協力できない(結論は一致しているのだが、立場の違いからなかなかすり合わせができない)おもしろさとか)と蛮力によって、人類は散り散りになる。
途中、大神官は宇宙のかなたから飛来した先祖のことを考える。かれらは基本的に予知能力を持たないゆえに迫害され、宇宙のかなたへ逃げることを考え、そして実行したのだった。(しかし、稀に予知能力を持つ子供が生まれるため、それを安全装置として大神官とする。その安全装置のために人々が科学に蓋をした上で地理的に狭い範囲で生活する国家システムが結果的に作られてしまったことが、終末を前にして問題となる)
無限のエネルギーを暗黒のかなたから生み出す、あるいは何もないところへ生き残るために進む、そういった考えは、未来を見ることができないからこそ可能なのだ。
そうよ、と踊り子が語りかける。先を見ることができないから、あきらめないのよ。やってみなければわからない。
この作家の作品の大きな特徴は、そこが少女マンガなのかも知れないが、この踊り子の存在で、大神官のことを好きだからその預言を信じる、好きだから大神官のことを助ける、という理屈抜きの勇猛果敢な行動力にある。その一方でタウリッシュの描き方にこの作家のもう1つの面を見ることもできる。
最後、大神官と踊り子は竜にまたがり、どこかへ飛び去る。
圧倒的な迫力、複雑な(したがってリアリティを持つ)社会システム、きれいな画、説得力のある物語。おれはこの作家の作品はすごく好きだった。今でも好きで、プチフラワーコミックが相当手元にある(だがワン?ゼロだけは見当たらない)。
以前買ってそのままだった本を読む。
冷血殺人 (実録・ヨーロッパ殺人シリーズ)(ジョン ダニング)
ヨーロッパで起きた殺人事件をまったく猟奇的だったり扇情的だったりせずに、むしろ警察視点で犯人を見つけるまでを描くのだが、現実の犯罪だけに推理的な要素のかけらもなく、淡々と犯行と動機が描かれるだけの作品で、これがさっぱりおもしろくないのだが、なんでこんな本を買ったんだろうか?
たぶん、その頃観た強烈な映画(まったく題名が思い出せないが、スミスみたいな人の名前だったような。たぶんパルコパートⅢで観たはず)の印象から、冷血殺人に興味を持ったからだろう。にしても、犯行は冷血かも知れないが、というか冷血だからこそ、機械的に殺人した事例ばかり。日本の殺人事件とはちょっと違うような(福岡のほうの金目当てで家族皆殺しにした事件がおそらく近いかも知れない)。横溝的な要素がかけらもないというか。
で、本題はそういうことではない。
どの事件も最後は、「あまりの事件の冷血さゆえに陪審員は情状酌量の余地なしとして終身刑を決定した」のような感じで締めくくられている点にある。あー、おそろしい。一生を牢獄で過ごすなんて。
でも、そのうち、はて? と疑問に感じた。なぜ死刑じゃないんだ? 極刑を選択したと読めるのだが。
で、さらに何作か読むうちに、合点した。ヨーロッパだから最高の罪は終身刑なのだ。
そこで、最初に感じた終身刑に対する嫌悪感と、死刑ではないことに対する疑問のアンビバレンツに、ふと気づく。
おれは、残りの人生を牢獄に閉じ込められるなら、むしろ死ぬほうがましだ。したがって、死刑と終身刑という選択は、自由か生命かという選択だ。自由がないなら死んだほうがましだ。それが嫌悪感の正体だ。
一方、日本では悪いことをすればするほど死刑となる。つまり極刑は終身刑ではなく死刑だ。したがって、その常識と照らし合わせてなぜ死刑じゃないのか疑問に感じたのだ。
なぜ、日本では極刑が終身刑ではなく死刑なんだ? これは不思議だ。
理由を考える。
制度的な欠陥によるのかも知れない。たとえば仮釈放という制度(さらにさかのぼれば、法治を徹底することがなく、権力が代替わりによって移動する、恩赦という制度、おそらく中国あたりから持ち込まれた)に由来して、終身刑が事実上、完全なる自由の剥奪とは限らないから、その選択が成り立たない。
あるいは、この国(中国や北朝鮮も死刑があるから東アジアと言うべきか(韓国については知らない)。中央と西アジアについては知らない)においては、自由のほうが生命より価値がない。
さらに、制度的欠陥という意味では、捜査、逮捕、裁判が不正なものだというコンセンサスがあるため、殺されてはおしまい、生きていれば正義がなされる可能性がある、ということから、死刑のほうが極刑ということなのかも知れない。最悪であるな。
いずれの仮定においても、アジア的専制を根底に見ることができる。あらためてウィットフォーゲルの慧眼には恐れ入る。
にしても、自由が安いのが理由だとしても制度的な不正が理由だとしても、いやなことだな。
捜査、裁判に不正が入る余地をなくし、自由の価値を教育し、そして極刑を終身刑とすることで、仮に不正ではない誤りにより冤罪が行われた場合の復権を確保することが、肝要だろう。
同僚の子供が4月から高校だというので、その話をしていたら、いやぁ最近の子供にはついてけないなぁとか言い出した。
なんで? とか聞いたら、いきなり入学式の後から友達同士で遊びに行くんだよ、とか言い出す。
いきなり友達を作れるのか、すげぇな、とか言ったら、そこじゃないと返された。
入学が決まった時点(ってことはまだ中学生のときってことだな)で、ミクシィで同じ学校に入学する子を探して連絡を取り合っていたらしくて、いきなり入学式がオフ会なんだよ。
なるほどなぁ、枯れた(というかそれほど新しくないというか)技術をうまく使っているんだなぁと思ったが、そういえば、こっちの子供もteacup(一体、いつの時代だ)を使ってチャットしたりしてるな、と思い出した。
たぶん、最初に始めた子の親が、自分達が使ったツールを教えて、その子が回りに勧めるという順に使われるのかも知れない。
あれ、ということはファッションの20年サイクルとかも、実は親の好みが単に次々(もう1個「々」が付くかも)世代に伝わって復活するということなのかな、とか考えた。
ファッションのサイクルよりも、テクノロジーサイクルのほうが短いのは、古び方が早いからかも知れないな。
いやぁ、やべーこと書いたかと一瞬クラクラしてしまったが(おれも18歳以上という規約だったように思い出したからだが)、あらためてミクシィの利用規約読んだら、満15歳ってなってた。
というわけで、中学3年生が高校デビュー前にミクシィで段取りってのは規約的にも問題ないようだ。
ネトレプコがやってくるというので、土曜日に子供とチケットぴあとeplusの2段構えでチケット獲得競争に参加した。
マスネ:歌劇《マノン》 [DVD](ネトレプコ(アンナ)&ビリャソン(ローランド))
おれはeplus、子供はぴあだ。
狙いは当然、Dといきたいところだが、さすがに数が少ないだろうからCということで始めた。
だいたい、来日オペラの場合、ほとんどの席がS、そしてAで、これがクソミソ一緒になってほぼすべてだ。
どうせ細部はオペラグラスで観ることになるわけだし、値段は数万円以上違うのに見易さに差はなかったりするので、CとかDとかを普通のオペラ好きは狙うことになる。SとかAは、基本的に寄付のようなもので、10年に一度オペラというすなるものでも観てみようという人用なのだ。したがって、自分で席を買う人はCやDを狙うし、もともと数がないのであっという間に売り切れる。
一瞬、おれが先行してCを2枚確保できそうになったが、子供と確認とかしていたら、コミット後にかすめられていた。楽観ロックはすばらしい。
というまにCはなくなってしまい(というか、Dは最初に受付画面が表示できた時点からなかったわけで)、Bか、子供のぴあかに明日がかかってきた。
しかし、子供の担当のほうをみると、混雑メッセージが表示されていて、一生懸命リロード攻撃をしているが、状況がまったく変わらない。ぴあ、スレッド数が少ねぇな、しょうがないので清水の舞台から墜落してeplusでBを確保して、今後のいろいろな予算がふっとんでしまった。
それにしても、子供がいくらリロードしても変わらないのはおかしいな、と思い、よくみるとアドレスバーには、……/punk.htmlと出ている。あれ、punkってpunctureのことか、とかの指摘より前に、そのURLはどうみてもグローバルな静的リソースをさしているとしか読めない(ぴあは素直なURLなので動的ページはjspになっているし)。そこでリロードしても、すでにリダイレクトされた後だからまったく意味がないんじゃないか。
「おい、ちょっと、前に戻るボタンを押してみろ」
とかやってページを戻して受付ボタンを押して、瞬時にpunk、前に戻ってから受付ボタンを押して瞬時にpunk、前に戻って受付ボタンを押してしばらく考えてチケット選択画面——そこにはさすがにDはなかったが、まだCが残っていて、数万円の衝撃を受けた。ぴあ、やってくれるな。というか、eplusが素直な実装過ぎなのかも。というか、担当を逆にしておけばよかったが後の祭りだ。
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)(山本 陽平)
というわけで、リダイレクトされた先でしつこくリロードというのは、どういう意味なのか、どうしてかくもURLが、つまりアドレスバーの視認が重要なのか、Webのアーキテクチャを子供にレクチャしようかと思ったが、数万円の衝撃で頭がくらむぼんだったのでまた今度。
おれはオペラが好きだ。トゥランドットのDVDだけで3枚あるし、コルンゴルトの死の都のレーザーディスクもある。
映画も好きだ。1900年はVHSとレーザーがあるくらいだ。
というような具合であるが、これがやっかいだ。
ちょっとマリーの亡霊のシーンを視て、続けてラパロマの山上のシーンをみて、続けて叔父さんのところでデニーロがサンズ(名前忘れた)とはしゃぐシーンを観たいとする。
映像マッシュアップだ。全ての素材をおれは所持している。
しかしこれがやっかいだ。
つまり、おれはiPodの映像バージョンが欲しい。
映画やオペラを通して観たら、後で部分再生するためにタグ付けしたい。
ふむ。欲しいソフトはあるな。
うん、これは良いまとめだと思う。
ところで、イントラだとちょっとクールなURIというわけにはいかんな、というか、RESTfulとは言えないことになるなぁという例を考えた。というよりも逆で、RESTfulなURIをそろそろ利用してやろうかと考えたのだが、ちょっと難しいなという結論となったというか。
Webサービスでやるという前提の以下のような処理を考える。
・認証する
・会員(当然、個人情報に対する一意識別子だ)の情報をくれ
・おらよ
ここでURIに、/members/id としようかと考えたのだが、いや待て、このidは個人情報の一意識別子だ。POSTするデータそのものはイントラSSLで暗号化されるとしても、URIはむき出しだよな。これはやはりよろしくない。URIはやはりそこら中でむき出しにならざるを得ないからだ。
というわけで、これはメッセージボディに入れることになる。
うむ。
はてなブックマーク(と妙なフルスペスで書いてみたり)を眺めてて、上にあがってるから韓国に何を学ぶ というのを読み始めて面倒になってやめた。基礎研究への投資を控えて……といってもどこかが基礎研究しなければならないのは当たり前の話で、こういうのは先行して資本を蓄えたところのある意味義務のようなものだ。というかそれなしでは世界が回らない。
そういえば、中国の日本のうまくいっていないところを学ばないようにしようという論説の翻訳(これはおもしろかったので読んだ)を引いていて中国に学べるかもとか書いているようなブログもさっき読んだ(が、もうどれかわからないからアンカーなし)。
こういうの、どっかで見た覚えがあるな。
ジャパン・アズ・ナンバーワンのころだ。
アメリカがやることがうまくいかず、ふらついていて、いろいろ困ってたときに、あのへなちょこで言いなり君だった落日の帝国日本がなんか最近ぶいぶい言わせているぞ。おれたちもしかしたら間違ってたのかも。日本に学ぼうそうしよう。
で、実際に学んだそうで、シックスシグマとかそういうのが出てきたりして、それがウェルチ一家以外で成功したかどうかは知らない。ただ、そういう事例からこねくり出したメソッドを唱える口先だけのところにお金を払う貧すれば鈍するところは消えてなくなり、そこが持っていたマネーが他のところに回って結局元に戻ったり(そしてまた落ち込んだり)。余分なことをしなかったところのほうがむしろ今でも生き残っていたり。
落ち目になると、それまで小ばかにしていたところの動きを真似たくなるようだ。
子供は海に行くと波が寄せたり返したりしていると上っ面を見て考えるらしいが、実際には同じところを上がったり下がったりしているだけだ。それは海に浮かんでいるものをみればわかるわけで、確かに同じところを上下するだけだ。もっともミクロでは波打ち際では確かに往復しているし、マクロでは干満によって移動するわけだが、しかし身の丈の範囲では単なる上下運動だ。
マクロの動きは変えられない。原因を取り除くには月をどうにかしなきゃならないわけだし、しかもそいつは実際には手が届かない。かえる場合にはユニバーサルにやらなければならないわけで、それをローカルな方策で変えられるように言い出しているやつがいるとしたら、それは詐欺師というものだ。
ミクロの動きはこけおどしだから、ちょっとした堤を作ればさらわれる心配はない。だから、こいつにはその場その時の対応がある。したがって、こちらはそれなりに方策が取れるし、取るべきだろう。
重要なのは身の丈のところだよな。で、ここは単に浮き沈みがあるだけのことだ。むしろせっかく沈んでいるときには、そのまま底のほうを探ってみると何かおもしろいものがさらに下に沈んでいるのを見つけられるかも知れない。
Haskellers Meeting 2010 Springに行ってきた。
最初が和田先生の『私はemotionally functional programmer』という挨拶で、単なる自分語りのようでありながら、その実、日本での関数型プログラミングのちょっとした歴史のようになっているところがおもしろかったのではないかと思う。というか歩く日本のコンピュータ史。
次がSimon Peyton-Jonesさん(MSRの人)の『Haskellが放つ並行処理の刺客STM』についてで、当然のように英語オンリーなのだがパワポが見やすくて、えらくわかりやすいプレゼンだった。一瞬、おれの英語力が異様にパワーアップしたのかと勘違いしたが、そうではなく、Simonの発音と間の取り方、パワポに書かれた強調点と強調点の間をつなぐ喋りがうまいからだと気づく。
つかみが、langpop.comとかからとってきたHaskell小話で、次が並行処理の難しさについて学部生ネタ。というか、研究者ってブログ界でもそうだが学部生レベルという言い回しが好きだな。
で、atomicは並行処理の難しさを学部生レベルにするんだよ、というところから本題に入るのだが、続きはまた後で。
Haskellは並行処理のために3種類のフォーム(どう訳せば良いんだ?)を持つ。
1つは、Explicit Threadsで、forkIOとかSTM(本題)。
1つは、semi implicitで、Deterministicとか、Pureなやつでparとseq。
最後は、Data parallel。
parとseqというのは、並行というよりも並列処理かな。
f x = a `par` b `seq` a + b
where
a = f (x - 1)
b = f (x - 2)
プログラミングの世界では30年の長きに渡り、ロックと状態変数による並行実行制御を行ってきたけど、これって競合、デッドロック、起こし忘れ(notifyAllを呼ぶべきなのにnotifyにしたために停止したままのやつがいるというのが典型だろう。というわけで、Effective JavaだとnotifyAllを使えというようなアドバイスになるわけだが、わざわざオーバーヘッドを招く方法を勧めなければならないところが30年の歴史というわけだな、と俺様が注)、極悪非道なエラーリカバリー、とろくでもない方法だ。
データベースの連中はもっとスマートだ。cとdはおいておくとして、AtomicとIsolationならできるじゃん。
ってわけでSTMだ。
で、STM(Software Transactional Memory)は、とりあえあずTLSに変更分をログしておいて、最後にメインメモリにフラッシュするときに他のスレッドによって変更されているかどうかチェックしてだめならエラーとする。楽観ロックだ。
atomicを単位としよう。
ところが、atomicの返り値をIO ()としたら、atomicの漏れが生じる可能性がある。(atomicそのものはクリティカルセクションだからだ)
型で解決するのがHaskell流。というわけで、atomicはSTMを取り、atomic以外はSTMを扱えないようにすれば万全で、atomic漏れは起きない。
さらに3個のアイディア。
retryは、atomicを最初からやり直す。汚染したのはTLSだけだから問題なし。(atomic内のatomicのretryは上位atomic自体をretryさせる、ということに聴こえた)
orElseは、atomicが失敗したら代替として実行する関数。ステートメントじゃないよ。だからorelse :: STM a -> STM a -> STM a、美しい!(Haskellerには美しいらしい)。
最後はalways。これは説明がなかったような。聞き逃しただけかも。
論旨は明快、内容は合理的、プレゼンは緩急自在でジョークを交えて飽きさせない、えらくおもしろかった。
もっともatomicが成立するのは、Haskellが関数型だから実行時間というものを別次元としてよけておけるから、可能なのかな? とは思った。
ビューティフルコード (THEORY/IN/PRACTICE)(Brian Kernighan)
Simon Peyton-Jonesさんはビューティルフコードの24章(美しきかな、並列)の著者らしい(が、おれはこの本は読んでいないので知らないが、アマゾンで目次を読めるので見ると、「簡単な例:銀行口座問題、STM、サンタクロース問題、Haskellにおけるリフレクション、結論」となっているので今回のプレゼンは、これのさわりの部分なのかも)。
で、次は山本和彦さんの、Mighttpdの3つの約束(俺様用HTTPD、モジュラリティの確保、Apacheより速くLightyには負ける)がどうなったかというプレゼン。HaskellではStringは[Char]だから遅いのでByteStringを使うってことと、Haskellのselectはユーザスレッドだからカーネルスレッドよりオーバーヘッドが小さくて軽い(はず)、でやってみたけど、Apache prefolkよりは速かったがworkerより遅かった(でも、prefolkのベンチ結果が遅すぎるのでちょっとベンチ結果自体が怪しい)、でプロファイリングしてみたら、selectが遅いのが主因だ。というわけで、Eventを早く取り込めというのが結論。あと、Haskellのselectはselect 1024の壁があるからprefolkを使ってc10kしたとか。
山本さんと言えばLIST遊びを持っているのでサインしてもらおうかと思ったが雨降ってたし面倒なので持っていかなかったのだが、つい会場でプログラミングHaskellを買ってしまったのでサインをもらった。
プログラミングHaskell(Graham Hutton)
原書を持っている(し、完読した)のでいらないよーと言ったけどオーム社の中の人に、「いやいや、山本さん書下ろしの関数解説がついているのは日本語版だけ」とそそのかされたのでつい買ってしまった。
で、最後は山下nobsunの、IO ()だと型みてもなんだかわからないから、=>で意図を示せるようにしたい提案(たぶんに、simon用プレゼンのような。サンタ問題の書き換えとかもプレゼンに含まれていたし)。もう少しHaskellに詳しいとおもしろいのかも知れないが、ぶっちされた感はある。が、問題意識はわかったような気はした(気のせいかも)。
子供が小遣いでナルニアのDVDを買うとか言っているので、そんなにおもしろいわけでもないからやめとけよ、とか言ったのだが結局買って観てる。
が、台詞がおかしい。
聞くと、監督と主演の子供たちによる実況解説らしい。そういえば指輪物語にも入ってたな。後でみたら最初の時点で「このトラックの内容については映画会社の責任は無い」というテロップが入るのでちょっと引っかかったが、それは別の話だ。
で、これが滅法おもしろい。理由は特に次女役の子供が本当に子供だからえらく言ってる内容が子供っぽいところ。具体例は難しいがたとえば、最後大人になった4人が馬で駆けているシーンで、「あのオレンジの服はわたしのお姉さんなのよ(えっへんというニュアンス)」とか。そのどうでも良いえっへんぶりが、自分のお姉さんがいかにすごいのかの根拠のない自慢になっていて、いやぁ実に素直でどれだけ家族に愛されて育ったかが手に取るようにわかる。(というのが演出だとしたらそれはそれですごい)
ナルニア国物語 第1章:ライオンと魔女 [DVD](ジョージー・ヘンリー)
で、これってメタデータなのだが、それを商品/製品に組み込んでいる点が妙におもしろく思う。こういう製作者によるツッコミというのは今は標準なのだろうか。
習ったのに忘れてしまったので書けない。
確か、ルートの中にxyを入れた場合、これはルートxとルートyの積になる。ここでx=-2、y=-2と置いた場合xyは4、ルート4は2となり、これはルート2とルート2の積である。これはおかしい。つまり、ルートの中にxyを入れた場合、これはルートxとルートyの積になるという前提は誤りである。
としては、いけないんだよ。だから、ルートの中には絶対に負値を入れてはいけない決まりがある。決まりだよ、決まり。変だよね。
というようなことを教えてくれたので、似たようなことを小学校でもやっただろう、と指摘する。
x/y=zであるとき、x=zy が成り立つ。しかし0には何をかけても0だからyが0のときxが0となるzは無数にある。zが無数にあるということは0/0を求めることはできない。これはyを0としたことが原因である。したがって、yに0を置くことはできない。とか言っているうちに怪しくなってきたので困った。xが0のときすべてのyについてzが0となるというのは何もおかしくないのはなぜだろう。
スラドの何かを眺めていたら、大東島というのに対する言及があって、はてなんのことやらと、とりあえずぐぐるしたらウィキペディアかが出てきて、それでも嘘は少なそうなので、いろいろ考えた。
というのと、子供がなんだかローマの歴史に興味をもったおとかいい出したものの、やる夫で学ぶパックスロマーナとか書いてやっている暇はないから、モンタネッリのやつを貸してやった。
(簡潔にして明快、読みやすく愉しい、これぞ読書の醍醐味のような本。中央公論社は実に良い仕事をすると思う。それにしてもアマゾン評もやたら高評価なのばかりだな。みんなの意見はあながち間違ってないようだ。一人だけ、これは歴史学者による歴史書ではないというそれはなんというか鳥肌実の芸を観てこれは政治家による政策論議ではないというようなことを書いているやつがいるけど、歴史というものを根本から理解していないようで不思議になる)
が、なぜか食卓に出しっぱなしになっていたので、つい飯を食いながら四読目くらいをしていて、ハンニバル後のローマの状況が、ある程度かさなる。
ローマのほうは、ハンニバル後、ばかみたいな覇権を握ったために、地方(ったって、スペインや北アフリカとかも含む)から安価な農産物がばかばか輸入できるようになった。このためローマの農産物の価格は極端にデフレとなり、結果的にローマを守ってきた軍団の元であるイタリア農民の没落がすごい勢いで進行、食えないので土地を手放すやつが続出、当然、その土地を買い捲る権勢が登場、権勢はしかしローマで経営するだけで郷士とはならない、かくして地方の極度の衰退が始まる。
つまり、ローマは植民地経営に失敗して、本土を衰えさせた。にも関わらずローマ人はおいしい食い物を安価にたらふく食えるので問題点に気づくのが遅れた。
一方、大東島は(というか薩摩藩がそうだったように)正しい植民地経営を行う。具体的には、必需品は作らせず、砂糖特化の農業経営を行わせる。農民は必需品(米、ミソ、醤油、衣類、なんでもだ)をすべて植民地外からの供給にたよらざるを得ず、つまりは植民地経営者の思いのままになる。
キューバが、いかに砂糖キビ依存から抜け出すために苦労したかとか、コンゴといえばベルギー、ベルギーといえばチョコレート、カカオ依存の農業からどれだけ(ということもないかも。要は必需品を確保した上で輸出品を作れば植民地は独立を保てる可能性があり、逆に本土では植民地からは奢侈品のみを輸入すれば本土の労働市場を破壊しなくても済む)。
そこで、日本はどこかの植民地か? とまず考える。
とりあえず米は取れる。野菜も取れる。でも野菜は中国からの輸入に相当押されているなぁ、というか、米の輸入を認めないのはそこを生命線として押さえているのだな、となんとなく想像がつく。自給率がどうこうという話ではない。
それほど状況は悪くはないな、と考える。
でも最初に書こうと思っていたのは、プログラミング言語とそれのジャンルの話だったのだ、と自分のためにメモ。
前から、類推とか、たとえ話ってやつについて、仮説を持っている。
あれのことだ。「たとえ話はかえってどうしたこうしたうだうだ」とか、「ストリクトな用語を最初からきちんと教えるべき」とか、と、その反対。
で、最近(といってもここ数年)の観察から、おそらくこの分水嶺が20代と30代の間にあるように気づいた。
もちろん、ストリクト、反たとえ話が、若いほう。類推に頼ったり、雰囲気後に頼ったり、たとえるのが、経験があるほう。
つまり、それはまさに経験の問題なのであった。
30代近くなったり、それを越えたあたりでは、仕事というものについて数年以上が経過しているからだが、教科書+先生から学ぶことよりも圧倒的に経験や実作業を通して学ぶことが当たり前になってくる(実際には、小学校に上がる前は、そうやって学んできているわけだが、就学前というのはおいておいても良い)。
その結果、経験や実作業を通じて学んだことからの成功体験も増えてくる。その効率の良さや、通じやすさ、応用の利き方を身をもって知ってくるのであった。それに加えて、それだけの知的経験による蓄積があるために、圧倒的な効率性をもって概念を丸掴みして、判断できるようになってくる。したがって、ストリクト、反たとえ話の非効率性(そこにその用語や理屈そのものを記憶する手間が必要となる)が逆に学習の障害となる。
必要性の観点からは、総合的な視点で考える必要が出てくるってのも理由のうちだろうな。そのため、狭い領域の深堀に必要となるストリクトな知識や用語は逆に邪魔になるのかも知れない。
とは言え、明らかに間違った俗流用語の使い方はやめといたほうが良いとは思うではあった。
まあ、個人差もあるだろうな。
そういや、子供のころプラモデルって実在した戦車とか軍艦とかだったな。
青島文化教材社 1/32 スペースクラフトシリーズ No.1 小惑星探査機 はやぶさ プラモデル(-)
みんなプラモと略称してたが、きっと今ではプラと略して、その略だとプラスティック消しゴムと区別がつかないだろJK、みたいなコメントがついたりするのだろう。昔で良かったね。つまり、「モ」が付くのがミソなのだから、ウィキペとかケータイデとか略してれば良かったののだろう。日本のマックに対してマクドってことはこの件については大阪は昭和30年代の言語文化が残っているということだな。
新国立劇場。あまりオペラブッファって好きではないのでスルーしようとしていたら、神々の黄昏のとき、ポスター見て子供が観たいというので行った。そのときにボックスオフィスでBが3Fの1列目で手に入ったからってのもあるけど。
オズのような流しのいかさま商人ドゥルカマーラがチェネレントラのときにお父さんをやったブルーノ・デ・シモーネで、今回も芸達者。このコアクマ(え、変換できないのか)めの歌詞を一回だけブリッコと翻訳して唄って受けを取っていた。
しかし特筆すべきはネモリーノのジョセフ・カレヤで、びっくりするほどいい声で、最初の登場シーンではびっくりした。が、残念、おれにはやっぱりドニゼッティは退屈で、途中で死にそうになったけど。
顔はおっかないが、実に良い声。イタリア(マルタだそうだけど)の歌手っていいよな。
アディーナ役のタチアナ・リスニックは写真でみるとただのおばさん(若いはずなので写真がまずいのだろう)だが、歌って演技していれば、確かに、才気あふれる小悪魔っぷり。それにしても、「わたしは薬なんていらないわ。だって、わたしは持ってるもん。それは、わたし。わたしのかわいい顔よ。わたしに見つめられたらどんな男だってメロメロよ」なんていうばかばかしい歌こそ、まさに大衆芸能なんだが、舞台を観に来ているのは紳士淑女の諸君なわけで(おれもそうなのか)、オペラって本当におもしれぇな。
で、つくづく思うのはオペラブッファはCDとかレコードで聴けばそれはつまらなくてうんざりするしろものだが(モーツァルトがどれだけ別格かということだ)、舞台で観るとそれは本当に愉しい。
あと、与那城敬という人のベルコーレも実に立派なものだった。
実のところ、愛の妙薬というのは筋は知らなくて、プログラムを買って読んで、ベルコーレってのは色男で滑稽な笑いを取る役(軍人だし)だが、実は恋敵を死地に送り込むような冷徹な計算をする悪いやつのような説明を真に受けていたのだが、少なくとも演出と対訳と演技からは、気持ちのよい戦争と女性が大好きな色男で、恋敵といえども金に困っていれば軍隊に誘ってやって、仲間を増やして楽しもう(こいつは前代未聞だぜ、恋敵を仲間にするなんて、だって軍隊愉しいからさ、というような歌を気持ちよく歌う)、というような役回りに見えて、どうしてこうまで異なるのかと奇異の念を持った。
演出は、文字と書物をベースにしたもの。カーテンが文字なのだが、Gは右下2箇所のみ、YとWは存在しない。最初縦三本がHかと思ったがHは一箇所だけあった。
モンモウ(おい、これも変換できないぞ)文メクラ(これも変換できないが、どうやって入力したらよいんだ? IMEパッドかな)文盲(音読みでやっと入力できた)の主人公(入隊申込書のサインを一瞬ためらう(当然、ちょっと戦争行くのを躊躇するのかと思わせて)やいなやベルコーレに「×でOK」と言わせるくらいだし、アディーナが本を読むのを尊敬して眺めていたりする)だから文字と書物なのか、実際書物はトリスタンとイゾルデ(イゾテッテ)だけど、それとも文字と書物こそが魔術なのか、まったく深い意図はないのか、いろいろ意味づけを考えさせる記号そのもの(文字はそれ自体が記号だ)というメタ構成であると同時に、建物にもテーブルにも自在に利用できる便利な大道具でもあるという実用性を兼ね備えたおもしろい舞台芸術。
気のせいではないと思うのだが、Snow Leopardになってから、Bluethoothでモデム接続が失敗するようになった。というよりも、一度も成功しなくなった。Ubuntuのほうはだませば使えるのだが、時々失敗する。
なんか面倒になってきたので、S01SHからD25HWへ乗り換え。
で、S01SHは余生をPDAとして使おうかと思ったが、どうも使いにくい。キーとかポインタデバイスとかそれなりにあるのだが。しかもSIMを抜くと(考えたら当然のような気がするが)単なるWiFiも使えないし。ネットワークが使えないS01SHってのは、Handspringよりも使えないマシンだな。Operaを動かしている状態のケータイよりももさもさしているし。
日付をみていろいろ処理するプログラムの動きがおかしいとレポートがくる。
変だな、テストもしたはずだが……と、いぶかしく思いながら試したら、通ったはずのテストが通らない。
年月日だけ取り出すのにCalendar#setで時刻をゼロクリアしてるわけだが、フィールド指定にCalendar.HOURを使ってた。グギガギゴ
import java.util.*;
...
Calendar c0 = Calendar.getInstance();
Calendar c1 = new GregorianCalendar(c0.get(Calendar.YEAR), c0.get(Calendar.MONTH), c0.get(Calendar.DATE));
c0.set(Calendar.HOUR, 0);
c0.set(Calendar.MINUTE, 0);
c0.set(Calendar.SECOND, 0);
c0.set(Calendar.MILLISECOND, 0);
if (c0.getTimeInMillis() == c1.getTimeInMillis()) {
System.out.println("午前だよ");
} else {
System.out.println("午後だよ");
}
自分で調べる方法を説明した上で、当然その説明に対する実習という意図からその説明以降は自分で調べろと書いてあるわけだが、その意図を汲んでもらえないということは、おそらく書き方がよろしくないのかも知れない。だがそのような意図まで指図されたら(さらには調べればわかることに貴重なページ数を割かれていたら)うっとおしく思うのではなかろうか、とおれは思うのだがなぁ。
損得の問題じゃないんだよね?
それを所持することに喜びがあるのだよね?
その感覚は持たなければわからないんだよねこれが、だよね?
であれば、ぜひとも家も買ってみるといいと思うよ。こればかりは持ってみなければわからないからね。
紀元前2世紀
・ルシタニアのヴィリアト、ローマの侵攻を食い止める。
15世紀後半
・アフォンソ5世はカスティリャの王位を狙うもののトロの戦いに敗れ頓挫。
・細川政元、足利清晃を擁立して京都を制圧、下克上が始まる。
〜16世紀初頭
・ヴァスコ・ダ・ガマ、インド航路を開拓。
・(内にこもる)
16世紀後半
・種子島に漂着し南蛮貿易始まる
・セバスチャン王はモロッコ遠征を強行。アルカセル・キビルで壊滅的敗北を喫す。セバスチャン王戦死。
・豊臣秀吉(関白)は朝鮮遠征を強行。
18世紀初頭
・宝永地震(日本史上最大)、49日後に富士山噴火
18世紀中ごろ
・リスボン大地震
19世紀中ごろ
・ポルトガル内戦
・明治維新
20世紀前半
・軍事政権成立
21世紀初頭
・社会党が民主化以降初めて単独過半数を獲得
#セバスチャン王の無体なモロッコ侵攻が時期的に似ているので他にも共通点があるかと思ったが、それだけだった。というか、ヴァスコ・ダ・ガマがいない点が大きい。
オリヴェイラの映画を観に岩波ホール。
ジェズイットを見習え |
Before...
_ arton [>* aliasを使うとorig_newが無限再帰になる 確かに(試した: `org_new': stack le..]
_ なかだ [Methodで保存するならalias不要]
_ arton [そりゃそうか。]