 
|
はてなキーワード: プロトコルとは
割と親しいけど、思ったことを何でも言い合える程の仲ではない友人なんかとメールのやりとりが続いたとき、
「そろそろ切り上げたいなー、けど相手は返事の意志があるみたいだしこっちから切るのは嫌だなぁー。」
と考えながらもその意思を伝えることができず、うんざりして一人で疲れてしまった経験はないだろうか？
そこから更に「相手も同じ事を考えているのでは？」という葛藤を抱きながらも返信を止めることはできず、
実際相手も似たように感じていて、互いに不毛な労力(精神的なものだったり、実際の時間だったり)を
費やしていたという経験をしたことはないだろうか？
俺はある！自分自身でも！まわりで話を聞いたことも！
この問題によって世間全体でいったいどれほどのリソースが浪費されているのだろうかっ！？
そしてこの徒労感を解消することはできないのだろうか？
■目的
メールをしている相手に「君が返事するなら僕は応じるけど、君が返事を止めても悪く思わないよ！」
という意志を相手にやんわりと伝え、お互いがお互いの返信を止めてくれるのをジリジリと待つような状態を回避する。
■望まれる成果
終わらないやり取りに「もう返信しなくてもいいだろうか？」と気をもんだり、
更に状況が悪化した際の「あいつとのメールは疲れるんだよな！」といった負の感情が増すことを抑える。
■方法
１．やり取りをしている片方が、メールちょっと疲れたなと思ったらタイトルの先頭に「@」を付ける。
■補足
・表記の場所を本文にしないのは相手がルールの存在を知らなかった時に感じるストレスを考えて
・気づき易さでは@より★なんかの方が優れていそうだが、一応文字の汎用性を考えて@で仮置き
以上！
http://www.google.co.jp/intl/ja/policies/privacy/preview/
Google は、すべてのユーザーによりよいサービスを提供するために情報を収集しています。その内容は、お客様の使用言語などの基本的情報から、お客様にとって最も役に立つ広告やオンラインで最も重要視している人物などの複雑な情報まで、多岐にわたります。
お客様からご提供いただく情報 たとえば、多くの Google サービスでは、Google アカウントのご登録が必要です。ご登録に際して、氏名、メール アドレス、電話番号、クレジットカードなどの個人情報の提供をお願いしています。Google が提供する共有機能をすべてご活用いただく場合は、公開される Google プロフィールを作成していただくようお願いすることもあります。これには、名前や写真などを掲載することができます。
サービスのご利用時に Google が収集する情報 Google は、ご利用のサービスやそのご利用方法に関する情報を収集することがあります。たとえば、Google の広告サービスを使用しているウェブサイトにアクセスされた場合や、Google の広告やコンテンツを表示または操作された場合です。これには以下の情報が含まれます:
端末情報
Google は、端末固有の情報（たとえば、ハードウェア モデル、オペレーティング システムのバージョン、端末固有の ID、電話番号などのモバイル ネットワーク情報）を収集することがあります。Google では、お客様の端末の ID や電話番号をお客様の Google アカウントと関連付けることがあります。
お客様が Google サービスをご利用になる際または Google が提供するコンテンツを表示される際に、サーバー ログ内の特定の情報が自動的に収集および保存されます。これには以下の情報が含まれることがあります:
お客様による Google サービスの使用状況の詳細（検索キーワードなど）
電話のログ情報（お客様の電話番号、通話の相手方の電話番号、転送先の電話番号、通話の日時、通話時間、SMS ルーティング情報、通話の種類など）
端末のイベント情報（クラッシュ、システム アクティビティ、ハードウェアの設定、ブラウザの種類、ブラウザの言語、お客様によるリクエストの日時、参照 URL など）
お客様のブラウザまたはお客様の Google アカウントを特定できる Cookie
現在地情報を有効にした Google サービスをお客様がご利用になる場合、Google は、お客様の現在地に関する情報（携帯端末から送信される GPS 信号など）を収集して処理することがあります。Google は、たとえば、お客様の端末のセンサー データから提供される近くの Wi-Fi アクセス ポイントや基地局に関する情報など、他にもさまざまな技術を使用して現在地を判定することがあります。
固有のアプリケーション番号
サービスによっては、固有のアプリケーション番号が割り当てられています。この番号とお客様のインストール情報（オペレーティング システムの種類、アプリケーションのバージョン番号など）は、お客様が当該サービスをインストールまたはアンインストールする際に Google に送信されることがあります。また、当該サービスが Google のサーバーに定期的にアクセスする際（自動更新の際など）にも送信されることがあります。
Google は、ブラウザ ウェブ ストレージ（HTML 5 など）やアプリケーション データのキャッシュのようなメカニズムを使用して、収集した情報（個人情報を含む）をお客様の端末にローカルに保存することがあります。
お客様が Google サービスにアクセスされると、Google はさまざまな技術を使用して、情報を収集して保存します。その際、Google からお客様の端末に一つまたは複数の Cookie や匿名 ID を送信することもあります。広告サービスや他のサイトに表示される Google 機能のように、Google がパートナーに提供しているサービスの利用の際に、Google が Cookie や匿名 ID を使用することもあります。
引用終わり
2012 年 3 月 1 日に発効
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
リマインドしようにも、これを書いた人（＝自分）の学力だと読めない本だったから無理。無理ゲーだった。
第一章
1
意味論的に透明なシステムと結びついた心の概念および計算機モデルを意味する。
この主義の限界を
2
チューリングの形式化が持っている特徴
(1)物理的組織によってではなく、記号操作の形式的特性によるメカニズムの集合全体を包括
(2)そのメカニズムがいかにすれば十分に明確化された問題すべてに取り組むことができるか示している
(3)万能チューリングマシンを定義する方法を示している
⇒ 素材は重要ではなく、形式的特性が能力を原理的に保証している
フォン・ノイマンがコンピュータを設計し、1960s、ジョン・マッカーシーがLISP（プログラム言語）を開発。
⇒ 研究開発が可能に
A・ニューウェルとH・サイモンが物理記号システムという概念を提出
⇒理論的に自覚化・明確化される
3
・物理記号システム
①適切に操作可能なトークンに対して任意に意味を割り当てることができるシステムであり、
②正確にプログラミングすればこの割り当てられた意味論的内容と細かい点においても一致した仕方で行動すると信じられるようなシステム
by 1976 ニューウェル & サイモン
・強い物理記号システムの仮説
SPSS strong-physical-symbol-system
「標準的な記号アトムのフォン・ノイマン型の操作を行っている仮想機械は、一般的な知的行為を実現するための直接的かつ十分な手段を持っている」
①仮想機械
そのプログラムに我々が命令を与える機械を模倣させるような「機械」
・記号を割り当てる
・変数を束縛する
・記号列の複写、読みとり、修正
等々
③標準的な記号アトム
④一般的な知的行為を実現するための直接的で必要かつ十分な手段
そうした機械は、それを支えている特定のアーキテクチュア（その基盤になっている他の現実的もしくは仮想的機械から）まったく独立に真に知的でありうるのであり、逆に言えば他のアーキテクチュアや機械をシュミレートすることなく真に知的でありうる
４
このような主張（標準的なLISPのアトムのごちゃごちゃした操作が、知能や思考の本質を構成しうるという見解）が、ニューウェルとサイモンのものだとできる動かぬ証拠は、彼ら自身の実践。
彼らの仕事の特徴（例:BACON）
・規則あるいはヒューリスティックス（発見的手法）の直列的（経験則を用いたも多少は運が左右する⇔体系的）適用に依存している
・そうしたヒューリステイックスの大部分が、かなり高いレベルで意識的に内省可能
・選ばれた課題領域を扱う
BACON:一連のデータから科学的法則を帰納する（ケプラーの第三法則、オームの法則）
・BACONが取り組んだデータをフォーマット化下のは、人間の労苦
・BACONは十分に構造化された課題にしか取り組めない。
ケプラーの第三法則は見つけられても、ペトリシャーレのカビとバクテリアの関係からペニシリンを発見する事はできない
・BACONが展開する知識とヒューリスティックスは、人間のプロトコルや実験記録に大いに頼り、われわれが自分自身の思考について内省する思考のレベルからかなり直接的にコード化されたもの
⇒この種の思考は原初的で瞬間的なプロセスの上に後から被せられたもの。理解するということを具体的な例で説明する事には役に立たないであろう
サイモン等は、人間の思考のすべてがただ一つの種類の計算アーキテクチュアに依存すると信じている。
しかし、筆者は違う考えを持つ。サイモンとラングレイの仕事では、洞察のひらめきといったタイプの認識を表現できない。
心は、多くの仮想的アーキテクチュアからなる複雑なシステムであると考える
知的課題や、感覚運動的な課題のような、なめらかに無意識的に行われるものは無視されている
５
古典的システムは記号アトムの使用に頼り、コネクショニズムはこれを避ける。
古典主義者:意味論的に透明なシステムの構築に対して、方法論的にコミットしている人々
STS semanttically transparent system
「システムの振る舞いについての記号的な（概念レベルでの）意味論的記述と、システムの形式的な計算活動の内的に表現された対象についての投影可能な意味論的解釈との間にきちんとした写像関係の記述が可能な場合にのみ、そのシステムは意味論的に透明であるといえる」
きわめて大ざっぱにいえば、あるシステムかSTSと見なされるのは、そのアルゴリズムの記述（レベル2）における計算の対象が、概念的レベルの用語で表現されたその課題の分析の記述（レベル1）と同型である場合である。
（レベル１:計算理論:（高い抽象レベルにおいて）どのような関数が計算されるかについての考え
レベル２:表現とアルゴリズム:それを計算する（具体的な）方法
レベル３:インプリメンテーション:現実の機械において計算がいかにして肉体あるいはシリコンなどで実現されるか）
（１）古典的理論は――コネクショニズムはそうではないが――統語論と意味論を組み合わせた記号システムを仮定している
（２）もし何らかの種類の構造化された表現が利用可能であれば、それらの表現についての計算操作を、その構造に鋭敏に反応するかのような形で規定できる。
もしそのような構造が存在していなければ、（すなわち、どんな記号表現も存在していなければ、）計算操作を規定することはできない
◎要するに、古典的システムは、統語論的に構造化された記号的表現を仮定し、そうした表現の構造によって、それに適用される計算操作を規定するものである
第二章
１
ドレイファス:古典的認知主義の問題は、人間の常識的な知識を表象として再現し表現しようとする形式主義の妥当性
サール:形式的なものと志向的なものとの間に、あるいは統語論と意味論との間にギャップが認められる
この二つの種類の懸念について検討する。
２
「あなたの持っているのはそんなにいいボールじゃないわ。それを私にちょうだい。そしたら私、このキャンディーをあなたにあげるわ」
この言葉を理解するために、ミンスキーちとパペートは膨大な概念のリストをあげる。
ウィノブラードのSHRDLUでは不十分。
・フレームは、常識がうまく対処している偶発的出来事のすべてをカバーしているとは思えない（バースデーケーキに立つ黒いローソクに、フレームは対処できるか？）
・フレームからフレームへの移行を促す規則（メタフレーム？）をいつ適用すべきか、システムはどうやって知るのだろう？
ドレイファス:互いに関連しあった特徴や可能性のすべてを、文脈に依存しない事実や規則によって形式的に把握するという課題には際限がないのではないか
３
・ドレイファスの二つの主張
（１）身体問題
「このシャンプーが目に入らないようにご注意ください。もし入った場合は、ぬるま湯でよく洗ってください」
コンピュータは、身体、欲求、感情、共通言語や社会習慣も持たない。だからコンピュータは、この文章が何を洗うように言っているのか理解できない
（２）コード化
人間は自分たちを取り巻く状況がどんなものかを絶えず感じ取ることができる。
このノウハウは、何らかの知識表現言語によって、一種の知識として表現できるものなのだろうか？
AIプログラム（＝言語）が知識を表現する仕方が、現実の課題に対して根本的に不適合だと懸念する。
４
「強いAI仮説」を、サールは批判する
強いAI仮説:適切にプログラムされたコンピュータは、文字通り認知的な状態をとり、その際プログラムは人間の認知を説明するものとなる
Schank and Abelson 1977の、「ストーリーを理解するという志向的活動をシミュレートしているかに見える特別なプログラム」に対して、「中国語の部屋」を使うことで批判する。
サール:形式的に区別される要素に対する計算操作を行っているだけでは、どんなコンピュータも〈理解する〉ことはできない。したがって、そのような計算操作を規定するプログラムが、心の固有の性質について何かを示すこともあり得ない。
具体例:英語話者が英語を理解することと、中国語の部屋の操作者が中国語を「理解すること」の比較
「人間は何も理解していなくても形式的な原理に従うことができる」
以下、サールの誤りについて論じる
５
サールに対する仮想反論「脳シュミレーター説」
脳シュミレータ説：あるりプログラムが中国語を理解する実際の中国人の形式的な構造をモデル化したと仮定すると、そのときそのプログラムは間違いなく真の中国語の理解を構成したことになる
↑（サールの再反論）
（１）脳の形式的な性質は志向性を構成しない（三章にて説明）
（２）脳の形式的な性質が志向性を構成しないのは、ある種の素材だけが思考を支えることができるからである
↑（アナロジー）
光合成：光合成の形式的な記述を手に入れても、素材が違えば光合成は再現できない
では、思考をもたらすような脳の物理的性質とは？
：外因的および内因的な刺戟に対して脳に大規模な変動が引き起こされること
↑（コメント）
『中国語の部屋』が大規模な構造的変動を必要としないシステムなら、中国語の部屋による反論は無効
６
微視的機能主義
機能主義は、心的状態の本質を、
入力、内的状態の変換、出力からなるプロフィールと同一視した。
（適切なプロフィールを持つシステムはどんなものであれ、その規模や性質や構成要素にかかわれなく、当の心的状態を実現するであろう）
↑（批判）
（中国国家脳のような）心的状態を実現する見込みがないようなシステムも、「入力、内的状態の変換、出力」のプロフィールを持つシステムへと組織することは可能であるよように思われる。
こうした極端な寛大さは、機能主義の立場を掘り崩してしまいそう
・問題は、「入力、内的状態の変換、出力」の系列をどこに位置づけるか
×大まかなレベルに位置づけ
⇒感覚質の欠如、極端な寛大さ
△ライカンの「小人機能主義」
○微視的機能主義
・機能主義の批判はゲシュタルト盲に陥っているのでは Lycan 1981
：機能的な構成要素があまりにも大きい、極度に小さい、それらしくない等であるために、そうしたものからなるシステムに志向性を帰属させるという考えに抵抗するということ
（ライカン「小人機能主義」
：機能的な下位システムは、それがエージェントのために何をしているかということによって同定される）
微視的機能主義
内容や目的に関連づけからはかけ離れた用語で
記述しようとするもの
・諸関係が得られたとき、システムには大規模で柔軟な構造的変動が引き起こされ、またそれによってさまざまな創発敵的性質が得られるようになる
第三章
１
２
「民間心理学」
：自分や他人が、信じたり、希望したり、恐れたり、欲求したりしているということについての日常の理解
民間心理学は、行為・運動を説明するときに、信念や欲求という表現を用いる
「民間心理学は、人間の行動に先立つ内的原因についての素朴で原初的な科学」
３
（１）民間心理学は、偏狭な、特定の人々に限定されたような理解しか与えない。
民間心理学は、子供や狂人や外国人を前にすると、まごついてしまう
（２）民間心理学は停滞したまま、なにも生み出さず、長い間ほとんど変化も進化も発展もしていないところが他の諸科学と異なる
（３）民間心理学は、これまでのところ科学の主要部分にうまく統合されていくような徴候をまったく示していない。残念なことに民間心理学は自然を神経生理学的ないみで妥当な要素にまで分割することには関心がないようである
最近の分析哲学
：頭の状態に関する科学理論というゲームと、民間心理学というゲームを比較することが、そもそも不適当なのではないか
４
Daredevil believes that Electra is dead.
Mary hopes that Fermat's last theorem is true.
のthat以下を、心的状態の内容と言う。
心的状態が考えられる傾向
：われわれの心理学的状態が、本質的に、周囲の世界がどのような状態にあるのかということによって決まるのではなく、
われわれにとってどのように見えているかによって決まる
↓（言い換え）
我々の意識や無意識に何らかの形で影響を与えられないものはどんなものであれ、
本質的に我々の心的状態の正確な限定に関わることはあり得ない
⇒我々の心的状態が現に持っているような内容を持つものは、われわれ自身のあり方ゆえであって、
知られていないかもしれないような周囲世界の事実とは関わりがない……☆
・双生地球……☆に対して疑いを投げかける
双生地球で、「海に水がある」と発話される。
地球A：海にH2Oがある
地球B：海にXYZがある
この違い以外は同質だとする。
すると、
地球上の発話と双生地球の発話は、それぞれH2OがあるかXYZがあるかによってその真偽が決まる
（たとえば、地球Aの海にH2Oがなくて代わりにXYZがあるとしたら、地球Aでの発話は偽になる）
⇒
もし意味が真理条件を確定するのだとすれば、
自然種に関する表現（水、金、空気など）を含む陳述の意味は、
単に主体の限定的に規定可能な状態に言及するだけでは十分に説明できない……☆に反して
二つの選択肢
（１）心理学的な内的要素（地球の話し手と双生地球の話し手に共通）と、
世界関与的な外的要因（仮定上、二つの地球を越えて不変ではない（H2OとXYZ））の両方によって内容が決まるとする、意味と信念に関する合成説
（２）そういったケース（地球と双生地球のケース）は
〈心的状態の純粋に内的でまったく心理学的な要素（☆のこと）〉という観念にさえも疑いを抱かせるものであると考えることもできるだろう
プティ と マクダウェル
「頭の中にあるものが、心の状態と因果関係を持っていることは疑いがない。
しかし、
〈頭の中〉にあるものが心の状態に対して構成的関係にあると考え必要があるのだろうか？」
筆者
：あらゆる内容が根本的に世界に関与している（選択肢（２））ということが判明したとしても、
そのこと自体は必ずしも〈認知科学は心の理解に深く（ことによると構成的にではないかもしれないが）関わる研究である〉という主張を覆すものではない
その主張に対する仮想反論と、それに対する再反論をHornsbyは行った。
仮想反論
：「「行動傾向（心性はこれに随伴して生じるとされる）が二者の間で異なるためには、
内的構成に違いがなければならない。」
という考えを保持すべきである」とするならば、
心的内容は限定的に規定されねばならない（自然種を指示しない）
（「「行動傾向（心性はこれに随伴して生じるとされる）が二者の間で異なるためには、
内的構成に違いがなければならない。」
という考えを保持すべきである」までが、プティとマグダウェルの、「頭の中にあるものが、心の状態と因果関係を持っていることは疑いがない」に対応する。）
仮想反論の詳細
：仮定①：
二人の動作主の心的状態は、彼らの行動傾向に何らかの違いがある場合にのみ異なる
（そこに赤いボールがある、と信じなければ、ボールを投げようとは思わない）
仮定②：
行動が異なる（すなわち、行動が異なる）ためには、内的な物理的状態に何らかの違いかなければならない
結論：それゆえ、心的状態に対応する内的な物理的状態に何らかの違いがなければ、心的状態が異なるということはありえない
「（民間心理学的な心的状態を帰属させることは、限定的内容のみに関わることであるという）結論は、深刻な疑義にさらされることになる。
限定的内容といっても、それを妥当な概念として了解できるかは明らかではない」
なぜなら、
「民間心理学的な内容を（物理的状態に？）帰属させることは、身体的な動きを規定するような頭の状態についての独我論的な研究から引き出すことができるような切り口とは
まったく違った切り口で現実を切り取ることであるように思われる。
その具体的理由として、
ボールをひろうことは、「そこにボールがあると私は知っている」という心的状態と関連するが、そのときの細かな指の動きはそのような心的状態と関連するものではない。
５
筆者
：広域的内容を伴うによ伴わないにせよ、
頭の中で起こっていることに関することに関する科学的カテゴリーや分類に
きちんと還元されるなどということは
とてもあり得ないように思われる。
・民間心理学は、科学的心理学と同じゲームを行ってはいないかもしれない
→
世界を記述しない信念であり、なおかつ
ある人が同じ考えを抱いているといえるような別のケースに投影可能な述語が（科学的記述の上には）存在しないことも可能
６
民間心理学の道具立て（信念と欲求という概念によって、命題的態度を帰属せさるという道具立て）を用いて、心的状態を二者が互いに帰属させあうという日常の慣習（傍点）の目的は？
：
他人の頭の内的状態を追跡しようと試みることによって、
その人の身体の動きを予測し説明するための手段
民間心理学の主要な目的
：
世界の中で活動している仲間たちの行動を、（傍点開始）我々が（傍点終わり）理解できるようにすること
（予測したい対象であり主体である）われわれの仲間たちの四つの特徴
①世界に対する感受性、すなわち感覚や生得的な原書的概念の道具立てをわれわれと共有している
②世界をわれわれと共有している
③彼らは我々自身のもっとも根本的な関心と必要の大部分を共有している
④彼らの思考の有用性は、
（我々自身の思考と同様に、）
彼らが世界の実際の有様をたどっていることと関わっており、
彼らの思考作用が、世界の実際の有様に十分適応していると我々が（進化論的な理由から）考えるような目的と関わっている
この特徴があるので、
「～したい」という欲求さえ同じであれば、
・民間心理学は、脳の状態の違い（that かなり目の粗い、行動上の違いとしては現れてこないような）に対しては、敏感に対応しないように設計されている
・民間心理学は、個人の間の差異を覆い隠し、
さらには種の間の差異さえも覆い隠してしまう（長所であっても短所ではない）
７
筆者の見解
：私の見解では、われわれが信念を帰属させるのは、
行動の全体に一種の解釈の網をかぶせることによってである。
……関連する行動を可能にするものとしての、
根底にある物理的あるいは計算論的な構造がどのようなものであれ、
そうした構造における自然な区分に、網の結び目（すなわち信念と、欲求の特定の帰属）が
対応している必要はない。
――
ということは、Davidson（全体論者）に対するFordorの批判は、筆者の意見にも当てはまるのではないか？
<Fordor>
意識の全体論というのは、
「命題的態度の同一性――特に志向的内容――が、その認知的連関の全体によって決定される」
という考え方。
これに、Fordorは懐疑的。
（命題pの認知的連関というのは、主体がpの意味論的評価、すなわちその真偽の決定に関係するすべての命題のこと）
われわれは、信念や志向的状態を共有している。が、そのとき、すべての命題（認知的連関）を共有しているとは思えない。
信念は、その内容をそれぞれ別に持つ。
：信念がその状態を獲得するのは、脳の状態が逐一、世界と因果関係を結ぶことによってである。
「ある生物が『牛』という概念を持とうと持つまいと、その生物は『馬』という概念を持ちうる」
</Fordor>
筆者
：Fordorの間違い
全体論は、もしそうであれば、人間の心の理解が芋蔓式に進んでくれるのにという、いわば願望。
Fordorが軽蔑したものの通りに進んでくれるかは別問題。
Fordor：バラバラになったブロックを一つの全体に組み合わせるやり方が、全員同じになるはずがない。
筆者：一つのブロックの組み合わせ全体を理解するために、各人が別々のやり方でバラバラにしている
全体論という言葉の使い方が違うから、Fordorの批判は筆者には当てはまらない（という、批判をかわすための節）
７
一章３節での、チャーチランドによる民間心理学批判に、今では応答できる。
（3）に対して、
民間心理学の関心事は、他の主体の顕著の行動パターンだけを可能な限り効率的に分離することである。神経科学とつながることを目的とはしていない
（1）に対して、
民間心理学の道具としての適用範囲は、仲間。狂人の理解は、そもそも目標としていない
（2）に対して、
なので、その中核部分が時間的および地理的な次元を越えて相対的に恒常的であり続けてきたことは驚くべきことではない。
整理。
民間心理学には、きちんとした定義がある。
これまで「民間心理学」として使われてきた言葉の、新たな用語法：「素朴心理学」、「メンタリズム的な理解」
８
因果関係と、構成的関係の区別
構成的関係
：
研究の主題と何らかの形で密接に結びついているということ
因果的に関係
：
因果的に関係している様々な要素は、それほど密接に思考と結びついているわけではないので、
それらの要素を差し引いてもそれによって思考という観念そのものが存続しえなくなる
ということはない。
（チェス盤がなくなっても、チェスの続きは打てる。石を駒に見立てたり、口頭で）
９
・消去主義的唯物論：民間心理学が、心に関する科学に対して歪んだ影響を及ぼすのではないか。民間人は自分自身の心を知らないと、消去主義的唯物論は思っている
↑
（構成的関係）
↓
心
科学と心とを結びつける構成的関係。その得難さが二つのスタンスの対立を生んでいる。が、どちらの立場も同じく、認知という地形に同じ隆起とくぼみを見ている。
では、構成的関係とは何か。
構成的関係←→因果関係
構成的関係：研究の主題（この場合は心）と、何らかの形で概念上密接に結びついていること
因果的関係：因果的に関係している様々な要素は、それほど密接に思考と結びついているわけではないので、それらの要素を差し引いても、それによって思考という観念そのものが存続しえなくなるというひとはない
（駒はなくてもチェスは打てる）
Permalink | トラックバック(0) | 15:30
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
トラバの反応がつまらん。もう少しわかりやすく書くべきだったか。反省。
肝心の問題についての議論はどうしたよ。「子供がうるさい問題」だよ。
このまとめだけだと「大人が子供に暴言はいて許されるか」問題じゃないか。そんな結論分かってる部分はどうでもいいんだよ。
未だにこの問題で万人に共有されている常識があるなら、問題なんてそもそもおこってないだろ？
うるさいと感じた時、どう対応すべきか、それについて受け手側はどう受けるか。
どうやれば一番衝突時のショックを減らせるかというクッションの構築とか
どうすればスムーズに話がススメられるかっていうプロトコルの設定が礼儀であり常識の役割だろ？
全然できてねーじゃん。この状態で「常識」を語るのって、そりゃお前の意見の押し付けに過ぎねーだろうが。
というかさ、何これ。
gnt カスが。お前の心の平安と、子供が歌う自由を天秤にかけるつもりかよ。
誰であろうとも「子供が歌う自由」を制限していいはずがない。公共？ 迷惑？ クソ食らえ
子供に寛容を通り越して子供様憐れみの例状態になってる奴とか見ると何考えてんのか分からん。
子供は犬か。なん歳児を想定してるんだよ。そして、そもそも抗議の自由しか無いとか何考えてんの？
禁煙ファシストに飽きて、今度は子供様ファシズムに傾倒中なの？ナチなの？死ぬの？
どうせこういう子供の味方みたいなコメ書く奴に限って、しつけやら教育の行き届いてない厨房にはマジギレするんだろうがよ。
まず子供でも何でもバスで歌うのはありなのか？ 無しだと思わないか？
で、基本的にはだめだけれど、子供だから許してやれよって話になるなら、線引きが必要だろ？
「子供」なんて曖昧な言葉でいうなら、そりゃ成人するまでこどもだぜ？親にとっては、そいつは一生子供なんだぜ？
「子供だからゆるしてやれ」っていう曖昧な理屈付けは百害あって一利なしなんだよ。
基本的に教育はその親がやらないといけない。
その親は教育の指針として、ある程度社会で合意がとれた条件を参照する必要がある。
んだから、そこで他人ごとだからといって「子供だから許してやれ」みたいな曖昧な話をしてるのは馬鹿げているにも程がある。
そういう無責任な発言を大人がしていると、参照するべきものがない親はそれぞれにマイルールを適用してしまう。
よそに対しては大人だろうが子供だろうが容赦なく厳しいくせに、自分の子には甘甘みたいな間違った親が今の時点でも沸きまくってるだろう？
いい大人が自分に責任がないと思って、「子供」というものを曖昧に捉えて、無責任になんでもありの状態を作っちゃダメだろ？
それはまず親にとっては途方に暮れる様なことだし、最終的には子供にとっても良くないよ。
話が拡散しすぎてたたみきる途中で飽きた。もうちょいテーマ絞りなおしてから書き直します。
久々にこういう「わかりやすい小物」の老害を見て興奮しちゃったんだけど、元記事も消えちゃったみたいでテンションが上がらなかった。
http://b.hatena.ne.jp/entry/togetter.com/li/210527
今テキトウに考えただけ。
多分はてなの皆さんは私よりこの問題について深く考えていらっしゃると思います。
私の意見に対する批判というよりは、老害に対する皆様方の意見を伺いたいと思います。
ここで述べるのはネットにおける「わかりやすい老害」の話です。
年だけは喰ってるから偉くなったのだと勘違いして若者に対してわかったような口を聞くアレのことです。
能力も権力を持ち、既得権益をまもるために政治力を駆使している真の老害についてはよくわかりません。
「懐古主義（建設的要素が少なく、ただ過去＝自分を賛美するだけにとどまる」
「世代の分離を強調する（若者を突然変異のように扱い、原因も若者に押し付ける」
「ワナビー（自らの現状が不遇であることを正当化するためにただ現状を否定したいだけ」
などの特徴があると思います。
ちなみに老害を設定するということは「若害」もあると思います。「世代の分離」については特に。
基本的に老害という言葉がネットで人気なのは、基本的にその反対を意識しない馬鹿が多いからでしょう。
リアルにおいては老害の方が「重要度（影響力）が大きい」ために問題になりますが、
ネットのように、どちらにしろ現実に影響を及ぼさないことを前提とした純粋な議論においては「若害」も吟味されるべきだと思います。
一般に老害の意見は、それを下支えするロジックがおかしいため滑稽に見えるわけですが、
おそらく自分のロジックを点検するという習慣がない。おそらくフィードバックを受ける習慣がないのだと思います。
それらしいことを言って、言いっ放しで満足してしまう。
老害と呼ばれるのは、一般にこういう傾向を持つのが中年以降の男性に多いからだと思います。
自分より立場の弱いものに、具体的には部下や家族に一方的に自分の意見を押し付けることができる。
あるいは同じレベルの仲間内で何度も同じ議論を繰り返している内に、無条件で自らの意見が受け入れられる錯覚をしてしまう。
などの積み重ねがあり、その「内輪感覺」「支配者の感覺」をフラットなネットに持ち込むことで裸の王様ぶりが浮き出るということなのだと思います。
１：自分の体験一点主義
２：主張の背景が薄い
５：人の意見を否定する際の理由が安易なレッテルや抽象的な表現になる。
（たとえば上の「２」とか。自分で書いてても批判になってないと思う。
曖昧な表現やよく考えられていない安易なレッテルはすぐに循環論法に陥る。
うちの課長が好む老害ロジックは「若者は自信がない」であるが、
若者から「安心できる環境ではない」「頼れる人がない」というと
それは「キミタチはプライドが高くて他人に弱みを晒さないだけ」といい、
「プライドが高いのではなく、そういうプロトコルがない」というと
「それはキミタチが自信がないからだ」となる。
実際はこんな単純ではないが、
自分が主張した理由に対する反論を５回繰り返す間に循環が起きるロジックはたいてい老害による偏見と考えて良い。）
６：安易に箇条書きでまとめを作ってしまうやつも老害の一歩手前
多分、プロフィール公開がないネットにおいては２０代の私が書いたことでも「老害」に当てはまる可能性は高い。
このセリフ使う奴はダメだと言われるけど、本当に「自戒を込めて」
とにかく、肯定でも否定でも、問われているのはその意見ではなくて、その意見を述べるときの自分の底力なのだな、と。
Google エンジニアの Steve Yegge 氏、Google+ への懸念を漏らす
http://japan.internet.com/busnews/20111013/8.html
で記事になってたけど、原文とちょっと要旨が変わっちゃってサービスへの警鐘みたいになってしまってたので、全文訳してみた。くそ長い。お暇な方どうぞ。
（2011/10/19 08:14）ありがたい誤訳の指摘をいただいたので3カ所修正。
Stevey の Google プラットフォームぶっちゃけ話
僕は6年半ばかり Amazon にいて、それから今はそれと同じくらい Google にいる。この二つの会社について強く感じることは（しかもその印象は日々強まるのだけれど）、 Amazon は全てにおいて間違っていて、 Google は全てにおいて正しいということだ。そう、やりすぎな一般化だけど、驚くほど正確だと思う。いやもうとにかくね。百、いや二百のポイントで二つの会社を比較することが出来るだろうけど、僕が正しく覚えていれば、 Google はそのうち三つを除いて優れている。実にある一点に関してはスプレッドシートを書いたんだけど、法務部が外に出すなって言うんだ。リクルーティングは惚れ込んだみたいだけどね。
つまり、まあ簡単に言えば、 Amazon の人事採用プロセスってのは基本的に欠陥品なんだ。だって、チームがチーム毎に、自分達のために人を採用するんだぜ。だから、色々平均化の努力はしてるみたいだけど、採用基準はチームによって信じられないくらいバラバラさ。そんでもって作業工程ってのも腐ってる。ソフトウェア信頼性工学なんてお呼びじゃないし、エンジニアに何でもやらせようとするんだ。コーディングする時間もないくらい。もちろんこれもチーム毎にバラバラで、要するに、運次第ってところ。施しやら困った人を助けるのやら、コミュニティに貢献するのやら、そんなのはもってのほか。ばかにしに行くんじゃなけりゃ、近寄るべきじゃないね。それにまた施設も染みだらけの壁に囲まれた箱みたいな家畜場で、装飾やらミーティングエリアなんてものには一銭も使ってない。給料やら福利厚生なんてのも最悪だ。まして最近じゃあ Google やら Facebook っていうライバルがいるのにね。社員特典なんてものも見たこと無かったな。採用通知の番号を照合して、ハイ終わり。コードベースも悲惨そのもの。エンジニアリング基準ってものがないんだから。チームによっては個別にがんばっていたくらいかな。
公平に言えば、彼らは良いバージョン管理ライブラリシステムを持っていた。これは僕らもまねるべきだし、僕らのところには同様のものが無い、良い pubsub システムもあった。でも多くの部分で彼らが使っていたのは、ステートマシンの情報を RDBMS に突っ込んだり読み出したりするだけのくそみたいなツールの塊だった。僕らならただでも欲しくないようなね。
僕が思うにその pubsub システムとライブラリ管理システムが、まさに Amazon が Google より優れている三つのうちの二つだ。
早期にリリースして、狂ったようにイテレートするってのも彼らのうまいところじゃないかって言うかも知れない。けど逆もまたしかり。彼らは早期にリリースすることを何にもまして優先する。品質保持やらエンジニアリング規則、その他長い目で見たら重要になってきそうなものはみんな後回し。そんなだからたとえ市場で競争相手よりアドバンテージがあったとしても、結局ちょっとしたことをやるのにも問題を起こしちゃうよね。
でも、一つ、そんな政治的な、思想的な、技術的なへまを補うだけの、彼らが本当に本当にうまくやってることがある。
Jeff Bezos は悪名高きマイクロマネージャーだ。彼は Amazon の小売りサイトの1ピクセルまで管理する。彼は以前 Larry Tesler を雇った。 Apple の主任科学者で、たぶん世界で最も有名で尊敬される HCI エキスパートさ。そんでもって、 Jeff は Larry が言ったことを、 Larry が辞めるまで3年間無視し続けた。 Larry は大規模なユーザビリティ研究もやっただろうし、少しの疑いの余地も無く誰もそのひどいサイトを理解できないってことをデモしたに違いない。けれど、 Jeff は1ピクセルたりとも動かさせはしなかった。トップページにぎっちりつまった内容の1ピクセルたりともね。それらはまるで何百万という彼の貴重な子供達なのさ。けれど Larry はそうじゃなかった。
マイクロマネジメントが Amazon が僕らよりうまくやっている三つ目ってわけじゃあない。つまり、まあ、彼らはうまくマイクロマネジメントをやっていたと思うけど、それを強みって言いたいわけじゃ無い。まずは何が起こっているかみんなに理解してもらうための文脈を準備しているだけさ。僕らはこれから、公衆の面前で、 Amazon で働きたけりゃ私に金を払えと言ってのける男について話すわけだからね。誰かが彼に反対したときは、彼は彼の名前入りの小さな黄色いポストイットを手渡して、誰が会社を動かしているかを常に忘れさせまいとする。思うに彼は全くの… Steve Jobs なのさ。ファッションとデザインセンス抜きのね。 Bezos はとんでもなく頭が切れる。誤解しないで欲しい。彼の前じゃ、普通のコントロールフリークなんてヤクが極まったヒッピーみたいなもんだよ。
それである日 Jeff Bezos が指令を出した。まあ彼がいつもやってることなんだけど。その度にみんなはピコピコハンマーで叩かれるありんこみたいに走り回るんだ。でもそのある一度、2002年かそのくらいのことだったと思うけれど、彼は指令を出した。とんでもなく巨大で、目の玉が飛び出るほど重たいやつを。普段の指令が頼んでも無いボーナスに思えるようなやつを。
彼の巨大な指令はこんな感じだった。
1)この時点より、全てのチームはサービスインターフェースを通じて全てのデータと機能を公開すること。
2)各チームは各々そのインターフェースを通じて通信しなければならない。
3)その他の全てのプロセス間通信は許可されない。ダイレクトリンク、他のチームのデータソースから直接データを読むこと、メモリ共有モデル、バックドア、全てを禁じる。ネットワーク越しのサービスインターフェースを経由した通信だけが許可される。
4)使用する技術は問わない。 HTTP 、 Corba 、 Pubsub 、 カスタムプロトコル、何でも良い。 Bezos は気にしない。
5)全てのサービスインターフェースは、例外なく、外部に公開可能なようにゼロから設計されなければならない。すなわち、チームは全世界のデベロッパに向けてインターフェースを公開することができるよう、設計し、計画しなければならない。例外は無い。
6)そうしない者は解雇される。
7)ありがとう！良い一日を！
ハハ！。ここにいる君たち150人ちょっとの元 Amazon 社員ならもちろんすぐにおわかりの通り、7番は僕が付け加えたジョーク。 Bezos は間違いなく君たちの一日なんかに興味ないからね。
それでも、6番は、本当だった。だからみんな一生懸命会社に行った。 Bezos は、さらに上級のチーフ熊ブルドッグであるところの Rick Dalzell に率いられた数人のチーフブルドッグを雇って、成果と進行を監視させた。 Rick は元レンジャーで、陸軍士官学校出身で、元ボクサーで、元 Wal（ごにょごにょ）Mart で拷問のような削減をやってのけた人物で、デカくて愛想の良い、「堅牢なインターフェース」という言葉を連呼する男だった。 Rick は歩き回り、「堅牢なインターフェース」について語り回り、そして言うまでも無く、みんなはいっぱいの進展をし、 Rick にそれを知らせた。
それからの数年間、 Amazon 内部はサービス指向アーキテクチャに姿を変えていった。その変化を形にしている間に、彼らは非常に多くのことを学んだ。 SOA に関する学問や論文は当時もいくつかあったけれど、 Amazon のとんでもない規模からすれば、そんなもの、インディ・ジョーンズに向かって「通りを渡るときは左右をよく見るんだよ」って言うくらいの意味しかない。 Amazon の開発スタッフはその途上でとにかくたくさんの発見をした。そのほんの一部をちょっぴり挙げると、こんな感じだった。
とまあこれらがほんの一例。他にもたくさんの、おそらく何百の、 Amazon が見つけた個別の発見や教訓があった。外部サービスにはおかしなところがいくつもあったけれど、君たちが考えるほどじゃあない。サービスに対して組織するってことは、外部のデベロッパを信用できないのと同じように、お互いを信用することなんてできないんだということを、チームに教えてくれたんだ。
自分のこれまでの経歴と年齢からかんがみて、期待されている「仕事」というのは想像がつく。
しかし、それは、わたしのしたいことではないのだ。いや、できることではないのだ。
これまで仕事に対して不真面目だった。作業はまじめにこなしてきた。スキルも経験も積ませてもらった。それは今での充分商品価値があるだろう。それは会社、大勢の同僚に感謝している。
が、しかし、仕事に対して不真面目だったのだ。会社の目的に対して自分の役目を決定し、それをどのように売り上げに変換するのか。そのために必要な、会社に求めるものは何なのか。それぞれの期間でどのような出力を行い会社に対して答えるのか。
自分はこれまで言われたことをしてきただけだった。指示された作業を指示された期間内に指示された品質で完了させていく。それだけしかしなかった。会社が掲げる、同僚たちが共有している、目指している目標に対して自分のコミットメントを定義していなかった。ただ作業をこなしているだけで同僚だと勘違いしていた。自分ですべてを定義してそして達成する「仕事」をしていなかった。
だから今急にそれを求められてまったく対応できていない。まるで転職したかのように社内の制度が判らない。作業をする前の仕事をどのように規制にのっとって完了すればいいのかわからない。
ソースコードレベルの決定はその理由も添えて出力できるのだけれども、レイヤーが変わっただけでなにもできない。プロトコルがさっぱりわからない。
これまでわたしに指示をくれた人たちを思い出す。技術的知識差から彼らを内心あざけっていたのを思い出す。
でも彼らはわたしよりよほど「仕事」をしていたのだと、いまさら思い知らされた。
今日も一日精神安定のためにソースを書いた。夕方ごろにつまらないゲームが自分のアンドロイドケータイで動いた。ちょっと新しいことを書いたのだが、それが無事に動いた。
でも、それは今の「仕事」に何の役にも立たない。
ソースコードと向き合って何日も過ごしたあの日々はもう戻ってこないだろう。どうしていつまでもそんな日が続くと信じていたのだろう。もう４０近いのに。
開発終了といってもずいぶん前から更新は止まっていたわけで、明確に開発終了が宣言されただけで公開終了になるわけではない。
しかし FFFTP といえば FTP クライアントの定番なので、ネット上で様々な意見が飛び交っている。それについて思うままに書き散らかしてみる。
みんなが「ホームページ」なるものを持ち始めたころ、ファイルをアップロードするのに使ったなつかしい思い出がある。BlogやWikiのようにオンラインで編集できる時代になったことへの感慨も含むのか。
もちろんFTPがプロトコルとしてセキュアでないことは言うまでもないが、いまだに業務で使わざるを得ないことがある。LAN内の転送なら速度は最強かもしれないし、FTPのミラーサーバは世の中にごまんとある。短絡的に「オワコン」の一言で片付けられる問題ではないだろう。
ほとんどのユーザはお客さん気分であることを再確認し、「FreeBSD への貢献」をたたき込んだ自分とは違う人種だと思った。
もともとFTP以外の通信プロトコルを想定して設計していないだろうから難しいように思う。ただ、ユーザは動いているプログラムの中のことなど考えない。
モチベーションが低下する理由ってたくさんあるなぁと。長続きしているオープンソースプロジェクトはすごい。
書いてみて思うのは、「まあそんなに面白くないな、おれの文章」ってこと。
いくら社会が大変で「ああしたほうがいい、こうしたほうがいい」と言っていても、文章に魅力がなければ伝わらない。
それは言葉の力というのを過小評価しているせいだと、ふと思ったわけで。
この文章が受け入れられるためには、受け入れてもらいたい人たちに向けて、その人達のプロトコルを使って書かなければいけない。
おれが書いている文章はひとりごとの域を出ない。自分の考えをそのまま書いているだけだから。誰にも受け入れられない。
そしてもうひとつ。もし誰かにこの文章が届いたとして、その人になんらかのアクションを取ってもらわなければ意味が無い。
ふーん、で済んでいい文章というのは、書かなくても同じ。
一番は感動させるとか笑わせるとか、反省させて明日からの行動を変える、とかそういう類のやつかな。
その次は、悲しい思いをさせるとか、怒りをかきたてるとか、そういうやつ。
次はブクマさせるみたいなやつ。
そのどれにも当てはまらない文章は書いてて意味が無い。そして、そういう文章の一つがこれ。
まあいいんだ。精神状態がこんな感じでは、書きたくても書けるわけがない。
とにかく、書く感覚さえ失わずにいれば、いつかまたちゃんとした文章が書けるようになる。
たぶん。
ワールド・ワイドなウェブ上のコンピューターネットワークでハイパー・テキスト・トランスファーをプロトコル方式で
音声バイナリ。128kbps 44.1kHz ムービング・ピクチャー・エクスパーツ (MPEG) 音声ファイルが東京ポッド許可局
-----
「聴いてみっと、インタレスト、インターネットのゲットーで行う The無節操 つっこみ高ボケ低の世間に
悪性のエンターテイメント ミニマルかマキシマムか突き詰めれば０点か 真っ赤なズポーツカー
現象ピックアップ、言語カットアップ、セッションビバップ、汁はタッパ、ユーモアの人 マキタスポーツ」
-----
「わかります、わかりますそれ、ウサギ飼う心優しきなりすまし詐欺 愛の手差し伸べる合いの手病
ガムいる？いらない 半信半疑 プロレス、プロレス、プロレさないときＯＬ気分 オヤジジャーナル
過去フラッシュバック 鶴田バックドロップ 見立てはポップ 見かけはキュート ザワッとウィットの人 プチ鹿島」
-----
「女は感情 男は理屈 理屈以外になにを信じればいいの オンリーな論理は孤独ロンリー 大切な人1000年後の友だち
ソシュールのルールでシュール考える BL パクられる 論をセットアップ データバックアップ 議論ヒートアップ
-----
「ポストゼロ年代の現在、私たち人類は科学と技術の発展により。エネルギー資源の限界、生態系の崩壊、道徳の退廃、
限界、崩壊、退廃、Technostress、to the breath, yeah!
network architecture 密室的に消費され続けるギフト化する物語、我々人類が住む、地球というamenity space where?
いったいどこへと向かおうとしているのでしょう。これからはじまる気になる show!」
http://diamond.jp/articles/-/13644
うまく言えないけど、今の上司って張り合いがないんだよね。
こっちが頑張っても、頑張らなくてもろくな反応かえってこないというか。
全くそういうことには興味がなくて、別のプロトコルで動いてる気がする。
最低でも、部署内でのコミュニケーションに意義を感じるためには、
こちらが何かしたら、それに対して本人の反応が返ってくる人じゃないとなぁ。
例えば上司になにかホウレンソウしても、やれ人事部がどうとか、会社の方針がどうとか、そういう反応しか帰ってこなくなったら、
実際、私の先輩が会社やめる時、課長にじゃなくて、そこすっ飛ばして関西総務部と統括部長に相談してたし。
もう上司って全くそういう役割を果たせてないし期待もされてないと思うんだ。
飲み会をガス抜きの場だって言ってる上司の方、ガス抜きは誰がどういうふうにやるんですか？
なんか前向きなことを語れるの？それともあなたがこちらの不満をその場だけでも受け止めらるんですか？と。
不満を述べたら「そういうのは酒がまずくなるからやめようよ」とか言う人が飲みニケーションの重要性を語るか普通？
だいたいなんかスローガン掲げたと思ったらまっさきに自分が破るしさ。
それでいて、部下に対しては「これからは～していこうって言ったよね」とか真顔でいうわけで。
張り合いがないを通り越して、まともに相手をしていると頭の中がぐちゃぐちゃになってしまう。
あーこの人アレじゃね？ピトーに操られてるカイトさんみたいな奴じゃね？って思うと悲しくなるからあえて避けてる。
ところが、こっちが相手して欲しいときには全然こっちのことを気にかけてくれないくせに
こっちが避けると、すごい勢いでにじり寄ってくる。しかもいちいち口実がないと寄れないせいか、細かい小言みたいなことをいってくる。
なんなんだろうなー。
自分でもガキだと思いますすんません。他の人との間だとこういうガキっぽいことはあんまり言ってないつもり。
でも、なぜか、上司との付き合いにおいては自然とガキっぽくなってしまう。
大人になりたい。
http://msdn.microsoft.com/en-us/library/bb266520.aspx
AQS:Advanced Query Syntax
これまた難しい問題やなあ。
祖父はどうだったんだろうな。増田にも弔って欲しかったんじゃなかろうか。
死んじゃったなら、自分の葬式に誰が参加してくれているかなんて、祖父自身で観測できるわけなんて無いけども。
だからこそ。
自分の死後、自分の事がどう扱われるかを自分で観測できないからこそ、「葬式」というプロトコルを設け、それに心を預け、誰もがそれに従ってくれる事を期待し、そうして、生きている間を安心して過ごせるんじゃなかろうか。「おいらいつ死んでも、みんながプロトコルに従ってくれるなら寂しくないね」ってなもんだ。
うーん
コミュニケーション力が低く、「名刺」や「時候の挨拶」「家柄」「スポーツ新聞」といった旧時代のコミュニケーションプロトコルに頼らないとコミュニケーションができない日本人の間にインターネットを普及させるために、彼らは何かしがの役には立ったのだろう。
彼らは率直に話し、お互いのプロフィールについては聞かなかった。よく冗談をいい、話のほとんどが冗談であっても、困っている仲間に金や食料を差し出したり、自分のベッドを分け与えたりした。非常にインターネット的だ。
選挙の人気取りで大臣がよくわからず決め、大学教授が道楽で計画を立てて半官半民企業が方眼紙エクセルで設計する日本のインフォメーション・テクノロジーのなかで、彼らは底辺のIT土方やコンテンツ土方を生業にしていたようだ。少ない給料から接続費を払い、せっせとコンテンツをダウンロードしたり、ニッチなコンテンツを制作したりしていたのだろう。それも非常にインターネット的だ。インターネットの片隅に、匿名とコピーと非合法の固まりのような場所があるのはかまわない。
facebookは学歴と職歴で相手を判断し、テレビを見てテロップの笑いどころできちんと笑う人に向けたサービスなのだ。
いくら超特急で細胞の継代をやれと言われたとはいえ、あのやり方はあんまりだった。おかげでシャーレは半分コンタミするわ、頑張ってた筋芽細胞たちは培地をいきなり変えられて筋管形成するわ、中には一番うまく分裂していたときに死ぬことになる細胞がいるわ、俺は最悪なことをやった。俺がやったのは昼食に納豆を食った手でFBSの不働化だった。んで俺の昼食は納豆ばっかりだし、めちゃくちゃ醸されてて実験後に変なコンタミが多発してインキュベーターがカビるわで、結果的に俺が食った納豆のせいで研究室が継代し続けてきた細胞株は壊滅した。なんせバチルスをFBSにばらまいたんだからな。俺が納豆ダイエットにはまる以前はもっと清潔な雰囲気があったぜ。みんな俺にコンタミさせられたときは苦痛だったはずなんだよ。だけど俺の実験前の食事は、コンタミの原因菌を明らかにし、一瞬醒めた目で見られたが、いったん細胞が全滅してしまうと何も感じなくなるように絶望が広がるから、みんなこのあとどうしようかという最悪の現実を考えないようにしている。言ってみれば強すぎるストレスで笑ってしまうように、実験中の細胞が全滅してしまうと苦痛があまりなく、むしろ細胞周期に合わせて夜中に継代する必要もなくなってよかったねと思い込んでる。しかし細胞たちは確実にバチルスに殺された。納豆ダイエットはやめたほうが賢明だ。実験前は発酵系の食品を避けて、確実に手洗いしろ。アルコールを吹きかけて殺菌だ。これは実験プロトコルだ。
オブジェクトのシリアライズツールであるプロトコルバッファについて書きます。
Protocol Buffers 本家
http://code.google.com/apis/protocolbuffers/
XMLはもう不要!? Google製シリアライズツール「Protocol Buffer」
http://journal.mycom.co.jp/articles/2008/07/18/protocolbuffer/index.html
Protocol Buffers (Protocol Buffers の内部解説記事。とても参考になります)
http://dodgson.org/omo/t/?date=20080712
プロトコルバッファは異種言語間でオブジェクトのやりとりをするための規格です。
独自の言語によりオブジェクトのインターフェースを規定することで、多言語対応を行っています。
例えばこんな感じ。
package tutorial; message Person { required string name = 1; required int32 id = 2; // Unique ID number for this person. optional string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { required string number = 1; optional PhoneType type = 2 [default = HOME]; } repeated PhoneNumber phone = 4; } // Our address book file is just one of these. message AddressBook { repeated Person person = 1; }
以上のようなprotoファイルから各言語のソースコード、または何らかのデータ操作ライブラリを使いオブジェクトの処理を行います。
googleによってC++, Java, Python用のライブラリが作成されましたが、他の言語に対応したサードパーティー製のライブラリがいくらでもあるので、実質的にほぼすべての言語で使えると言っても過言ではありません。
数字が多きければ大きいほど、長いバイト長で保存されます。ただし、負数の場合は符号ビットが立つ関係で、ほとんど常に変換後のバイト数が最長バイト数(10)になってしまいます。フィールドの型をsint32, sint64で宣言しると、各数値にzig-zags変換が行われるため、負数であってもその値の絶対値で使用バイト数が決まるようになります。
バイナリに保存されるデータは各メッセージのID/型/値のみです。なので、同じ定義の二つのメッセージ型は、プロトコルバッファ上では全く同じように扱うことが出来ます。例えば、片方からシリアライズしたデータを、もう片方の型でデシリアライズすることが可能です。
またオブジェクトを連続でシリアライズ/デシリアライズすることもできます。
すでに存在する継承関係のあるクラスを、Protocol Buffersでシリアライズ/デシリアライズしたい場合は次のようにします。
(ソースコード中になぜか日本語が書けないので、コメントはすべて英語になっています)
message PbBase { require int32 id = 1; require int32 value = 2; require Derived derived = 10; // - Point !!! } message PbDerived { require string string_value = 1; }
継承元のメッセージの定義に、継承先のメッセージを持たせます。Baseを継承するクラスをシリアライズ/デシリアライズしたい場合は、PbBaseメッセージを中心に処理を行うことで、比較的簡単に処理を実装することが出来ます。
例えばこんな感じ
Base *Base_DeserializeFrom(PbBase &amp;pbobj) { // Arrange the classes which inherits from Base. if (pbobj.has_derived()) { return new Derived(pbobj); } else ... } class Base { ... virtual void Base::SerializeTo(PbBase &amp;pbobj) { // Set the fields of 'pbobj', } ... }; class Derived { ... virtual void Base::SerializeTo(PbBase &amp;pbobj) { PbDerived *derived = pbobj.mutable_derived(); Base::SerializeTo(pbobj); // Set the fields of 'derived', ... } ... };
protoファイルを以下のように書くと、メッセージの扱いが非常に難しくなります。
message PbBase { require int32 id = 1; require int32 value = 2; } message PbDerived { required PbBase base = 1; // - Here is the point !!! require string string_value = 2; }
.NETでオブジェクトの永続化によく使われる、この二つのクラスの違いについて書きます。サンプルコードなどは書きませんので必要ならリンクを参照してください。ずいぶん古いネタだけど、許してね。
全体的に速度が重要な場合か永続化するオブジェクトが単純な場合はXmlSerializerを、それ以外の場合はSoapFormatterを使うのが良いと思う。なるべく短いコード量で行きたいならSoapFormatterの方がベター。
あと、細かいことだけどTypeConverterは便利なので使うべし。シリアライズ不可能な小さなクラスとか特に有効。
めも
SK
ハフィル使用も徴収
Employee（てんぷらり）村内
IDPはNP
International Responseが比較的早く、また数も多いのが特徴
こんなに援助が殺到して果たして捌ききれるのだろうかと心配するくらい。
responseだけではなく、平時のCBDRMも。
災 害応急対応調査
災 害応急対応調査については、4月27日、29日にフ省の３つのパ イロットサイト村落にて、インタビューを実施した。水文気象局にてケ ツアーナ対応関連資料を収集した。
１． 活動の内容
・フ省の各パイロットサイトを訪問し、関連するリーダー格の住民から聞き取り調査を行った。
・フ省水文気象局において、警報文書の伝達について聞き取りを行った。
２．活動の成果
・Quan gAnコミューンのAn Xuan地区、Huong ThoコミューンのKimNgoc村、La Khe Bai村において、それぞれインタビュー調査を実施した。ケ ツアーナの被災から9ヶ月以上も経過していたため、記憶が薄れていることが心配されたため、個別面談方式はとらずに、ワークショップ形式で、お互いの発言に触発されるかたちで思い出してもらうように促し、自由に思い出してもらいながら、インタビューを進めた。目上の人間に遠慮して発言が出ない懸念もあったが、実際には多くの人が活発に発言していた。上位の行政レベルについては、フエ省DARDのCPからプロジェクト承認が降りない段階で新しい活動に予算をさけないことを理由に活動範囲の縮小を求められた。
3地区での調査を終え、現在、クァンナ 省に移動し、対象サイトの文献のレビューと準備をしながら、同時並行で今回3地区の取りまとめを進めている。調査者として率直な第一印象をいえば、対象コミュニティにおける強さとしては、過去の類似調査報告でも明らかなように、応急対応時の人々の結束力、助け合いの精神などがあげられる。避難のオペレーションなどの行動が適切なリーダシップによって迅速に実施されるため、人的被害はほとんどなく、事前に決めた役割分担などの計画性・実施能力において優れている。また家屋の仮復旧・環境の修復・片付けなどリカバリー段階における人材の豊富さなどがあげられる。
他方、対象コミュニティにおける災害脆弱性の中心問題は、情報インフラの不足、情報の不正確さ、家屋構造の弱さ、およびそれらに対する問題意識の欠落にあることが伺われた。例えば、ある村落では、避難所の屋根が老朽化しているのを知りつつ、計画で避難所に指定しているケースがあり、結果としてほとんどの村民が当該指定場所に避難せず、大半が近隣住宅に避難していた。台風により毎年のように省内で数１００件の家屋倒壊が発生しているにもかかわらず、公助として解決策が十分にとられておらず、村落のリーダーが年次計画にもとづいて、暴風に備えた家屋の補強などを指示するにとどまっているようである。コミュニティが自らの脆弱性をどのように評価しているかは、防災計画策定にあたり重要な要素であるが、今回調査した地域にかぎっていえば、被害評価等を通じて、住民らは問題の所在を事実として把握しているにもかかわらず、原因分析というステップになかなか至っていないようにみえる。全体として、それらの問題に対する抜本的な解決を検討するなど、長期的な戦略を防災計画にフィードバックしている証拠がみあたらず、毎年の計画がとくに重点トピックもなく自動的に更新されている模様である。各人がやるべき業務分掌は周到に決めているが、目標管理的なマネジメントに乏しいといった印象である。これらはフ省PCSFCの報告書においてもDistrictレベルの報告書でも同様であり、いかなる事後報告書においても、プロトコルとして決まった様式にもとづいてなされるため、被災の結果だけは表示されるものの、原因の考察や将来必要な対策について公式に言及されることがない。
３．次２週間の予定
クァン ム省パイロットサイト２箇所、クァンガ 省1箇所において、コミューン事務所、住民や関係団体から聞き取り調査を実施する。
そもそも浅田とキムをやたらに（当人たちがしていないのにも関わらず）年と背格好が似ているからといってライバル視して煽るマスコミの論調が気に食わないのだが、もっと気に食わないのはいまだに「技術の浅田、表現力のキム」と日本のメディアが煽っていることだ。
そら確かに、技術力で上回る浅田に、表現力のあるキム、そして二人は同じくらいの背格好で、同い年！という構図はいかにも漫画チックで面白げだが、その面白げな演出のために事実を曲げるのは言語道断だろう。
浅田選手は実は（といってもフィギュアファンには常識だが）表現力も凄い。PCS（厳密には違うがかなりおおざっぱにいえば芸術点的なもの）の今季最高得点は浅田である。今回のGPF（グランプリファイナル）でも、なぜだか日本のマスコミはやたらに「ヨナがミスしたおかげで浅田が勝った、浅田はノーミスなのにキムよりちょっとだけしか上じゃなかった」「ノーミスだったら多大な表現力の差でヨナの方が勝つ」的なことにしたがっているのだが（これはもう、物凄く不思議だ。自国の選手がアウェーで優勝し、女子史上初の3A（トリプルアクセル）×2を決めてきたというのになぜこういう論調にしたがるのだろう。男子の小塚が初めてGPS（グランプリシリーズ）で台にあがったのに、ほぼスルーなのも気になるし、あれほどマスコミが煽ってきた4S（4回転サルコウ）を安藤がチャレンジし、DG（回転不足のこと）こそとられたものの着氷したというのに（個人的には安藤はもう4Sを目指さないほうがいいと思うが）スルーしているのも謎だ）、GPFでの二人のPCSの差はほとんどないのである。またヨナがミスして浅田はほとんどミスなかった、的構図も誤りであって、浅田はSP（ショートプログラム）でもFS（フリースケーティング）でも減点の非常に大きなミスをしている。ただそのミスは、減点が大きいわりに素人目にも、いや、荒川静香や伊藤みどりというプロにでさえもわからなかったようなものであるため一見目立たなかっただけだ（要はDGである。それに加え、FSでは、転倒そのものより、それによりコンビネーションジャンプが単独になってしまったことが痛かった。今のルールでは下手をすると転倒よりわずかなDGの方が痛いのだ）。素人が浅田の演技を見て「ノーミスなのに」と思うのはまあ仕方ないが、マスコミがそれでどうするのだろうか。
まあとにかく、結論として、浅田は実は表現力もかなり優れたスケーターである。海外ではむしろ、技を褒める前に表現力の方を褒め称えられていたりする。浅田は、表現力もトップクラスの上、スピンやスパイラルやステップもレベルが高く、その上にジャンプの凄さ、またスタイルも抜群によく（フィギュアスケート選手として。この点はキム選手も同じ）、メンタル面も優れている、奇跡のような選手なのだ。
メンタル面の強さは凄い。今シーズン初めのフランス杯で、あれだけgdgdになっておきながらも、わずか2週間でジャンプの調子を整えてきたという凄さ。普通なら有り得ない。また昨シーズン足を引っ張ったロングエッジのルッツを、僅か1シーズンでしっかり矯正して来て、加点までもらえるほどのジャンプにして見せた凄さ。驚異的だ（ジュニア時代からずっとそういう癖だったものを矯正するのは勿論難しいことだ）。なんと苦手だったサルコウまで飛んでいる。
月曜日のとくダネというニュース番組で、こともあろうに「3Aを二度飛んだのに、結局ミスをしたヨナとたいして差がない！浅田は実力不足が否めない！その差はヨナの妖艶な表現力にある！」といった論調で報道がなされていたのだが……これには正直文字通り開いた口が塞がらなかった。何度も言うが、PCSはほぼ変わりない。というか、昨シーズンの世界選手権では浅田の方が上である。
キム選手は確かにトップレベルのスケーターでありそれには間違いないが、事実を捻じ曲げてまで、優勝した自国の選手を「実力不足」だと言うのは最早、何がしたいのか分からない。ピーコに至っては「二人の私服のファッションセンスに差がある」というような事を言い出し、アナウンサーは「二人のCM契約数の差」を話し出し、小倉はそれらにいちいち暗い顔をしては「真央ちゃんはまだ力が足り無い……」と嘆き……本当に何がしたいのか意味不明な番組であった。アウェーで自国の選手が優勝したのに何故かお通夜ムードである。
まあしかし、確かに浅田も重大なミスをしたとはいえ、女子史上初、伊藤みどりも成し遂げなかった3A×2を成し遂げた業績の割には点が伸びなかったのは事実である。表現力もいいというなら、一般視聴者にとっては更にわけがわからなくなることだろう。一体何がダメなのか？そこは2年くらい前から変わってきた今のフィギュア界の不可解なルールが関係しているのだが話すと長くなるので割愛する（キムヨナもジュニア時代からほとんどやっていることは変わりがないのに急に浅田に勝てるほどに点が伸びだしたのもルール改正と同時だ）。
あと日本のマスコミはやたらにGPSを重視し、まるで世界選手権と同格のように扱っているが、フィギュアスケート界では大会の格としては世界選手権＞＞＞＞GPSである。というかここまでGPSを盛り上げているのは日本と韓国くらいだ。別に盛り上げてくれるのはいいが、フィギュア選手の毎年の最終目標は常に世界選手権であり、GPSはその前座的役割、今季のプログラムの経験値を上げるような場である。今回など、浅田選手は相当に高難度なプログラムを入れているため、これはもう世界選手権で完成してくれれば御の字、といったところだった。正直フランスでの演技を見て、GPSはヤバいかなと思っていた（のだが、あの回復……驚異的だ）。あまり、全ての試合に勝つように煽るのもどうかと思う。国内大会で力を使い果たして世界大会でバテるのでは意味がないのと同じだ。
まあ、とはいえもうマスコミには必要以上に浅田をアイドル化してほしくない、安藤の二の舞にさせたくないという気持ちもあるのでそう着目されても困るのだが。浅田・中野の3Aや安藤の4Sは、本っ当に難しい技で、今のルール上はチャレンジしてもたいしたうまみはないばかりか、リスクばかりが伴う。大技煽りもマスコミにはやめてもらいたい。高橋の4回転2度や、小塚の4回転も同様である。特に安藤の4Sはもう煽らないで欲しい。今回まさかチャレンジしてくるとは思わなかったが、4Sとプロトコルに出て、DGだったものの着氷したのには驚いた。あれだけでもかなり凄いことなのだが、どうしてこういう時に限って取り上げないのだかな。まあ、これを期にもう安藤の4Sには注目しないのであれば、それはそれでいいのだが。安藤は4Sに固執せずとももともとレベルが高いのだから、点数的にも怪我的にもリスキーなだけでうまみのないあの技はもうやらないほうがいい。