 
|
はてなキーワード: アルゴリズムとは
これは、「事務職リーマンがwebサービスを作ってみた話」のトラックバックに対するトラックバックです。
もちろん、この手のアルゴリズム処理に「完璧」は存在しません。
ですが、拾った結果の品質を数百個ばかり、サンプリングで調査した範囲では、商品サイズを拾える商品のうち、９割を大きく超える率で、正しいサイズを拾えていますので、
もちろん、検索できる商品数が尋常じゃないので、サイズ抽出をミスっていそうな商品を狙い撃ちで探すと、結構見つかったりはしますが。
ちなみに、上記の「商品サイズを拾える商品」という表現には、レトリックがありまして、結構、楽天ではサイズが画像のみで記載されている商品もありまして、そういうものは、当然、検索できない商品となっています。
まあ、これは仕方が無いところです。
サイズは、正しくサイズを拾えるよう、複数の書き方パターンでサイズ候補を抽出しています。
おおまかには、
・幅×奥行×高さ（単位センチ）・・・・・・XX × YY × ZZ
の２パターンで、このパターンを軸に、さまざまな派生に対処しています。
この派生（というかノイズ要因）が滅茶苦茶いろいろなパターンであって、相当手を焼きました。
実はこれも、簡単そうに見えて、結構、面倒なところでした。
・サイズ記載部分から遠く離れた部分に（単位：ミリ）とか書いてある場合がある
など、さまざまなパターンがあり、結局、サイズ記載箇所の前後を見て、距離などから重み付けを調整して、サイズ単位を拾っています。
また、そもそもサイズ単位が記載されていない（意外とよくある）場合は、サイズ値の大きさを見て推定したり、（例えば、家具カテゴリのサイズ表記に小数点があれば、それはきっと、ミリではなくセンチだろう、など。）全く見当が付かん、というときには、決めで処理したり、仕方なくあきらめたり・・・といった処理をしています。
サイズを拾うだけでは、梱包サイズとか、引き出し内寸とか、ノイズが多いので、これらは、重み付けを行い、一番重み付けが高いものを外寸サイズとして拾っています。
この辺の重み付けは、ある程度、作りこんでいますが、もちろん、完全ではないので、今後のブラッシュアップが必要な部分です。
こちらは、型番等で誤反応を起こしやすい、W/D/Hでの記載サイズのレーティングを少し下げて対処しているのですが、初めのほうにトラックバックを頂いた方もご指摘されているとおり、それでもある程度引っかかっちゃいます。
タイトル中の型番を検索外すとかの手も無くはないのですが、型番って意外と本文中にも多くて、例えばテレビ台とかで、本文中にテレビ型番をズラズラ列挙されて、それが反応した時もあります。
一応、異常値についてはレーティングを下げたり、サイズ数値取れずで処理はしています・・・みたいなところではありますが、検討すべき改善箇所です。
ex)「幅800×奥行400×高さ100センチ」の棚・・・など。
こちらは、最終的なサイズ数字を見て、「サイズ単位の書き間違い・拾い誤り推定」の判定を入れておりまして、判定に抵触したサイズについては、正しいと思われる単位に変更・救済しております。
もちろん、フォローにも限界があったり、フォローを行って二重遭難する場合もあるんですが、検証してみたところ、ほんのわずかな二重遭難よりも、誤り救済を行ったほうがはるかに結果がよかったので、処理を入れてます。
ただ、結論から言うと、サイズ情報に対する、楽天市場側の動きはほとんど無いと読んでおります。
なぜなら、圧倒的にニーズが高く、ハードルも低いと思われる、送料込み価格検索すら、彼らは実現できてないからです。
恐らく、楽天側では、出店側に登録させる情報を、いじりたくないと思っているのではないでしょうか。
しかも、サイズ情報は、楽天が扱っているほとんどのジャンルの商品にとっては、それほど重要性の高くない情報です。
ごく一部のジャンル向け以外は重要性の高くない追加の登録情報なんて、楽天はあまり実装したくはないのではないでしょうか。
・・・と、そういう読みをしてますし、さらに、読みが外れて楽天が対応を行ったとしても、別に私は片手間でやっているだけなので、それほどペナルティが大きい訳ではありません。
以上、カグサイズのページ処理の内容部分の説明でした。
それではー。
----------
あんまり関係はないんだけどこの記事を受けて。
■Google＋が作る「繋がりによる検索の世界」が侵食するSEO,SEMのこれから
googleが目指すべきは、facebookではなく「はてブ」だと思う。
その先を目指してくれ。
そのクラスタによるキュレーションを反映した検索結果じゃないか。
ざっくりいってしまえば
に応える検索。
今は意外にこれが難しい。
その記事のタイトルっぽいワードをいれてもさっぱりあがってこないのな。
ここがうまくいけば、ブクマしてても、し忘れててもどっちにしてもgoogle検索で
その記事にたどり着くという遷移ができる。
google+が向かうべきは、「だれもがまずそこにログインする」ような
コミュニケーション重視のSNSじゃなくて、+1しておいてあとで読むとか
記事に対する軽いコメントや議論ができる、まさにはてブのような機能とか、
使いやすいオンラインブックマークとしての機能に、ソーシャル要素をがっちりと盛り込む
ことじゃないか。
「webページに対する言及や、キュレーション()を前提としたコミュニティ」
NAVERまとめ()みたいなページつくれる機能をいれてもいい。
・+1スクリプトレットに、はてブ、facebook、twitter等への投稿機能をもたせて展開
・ブックマークの傾向により、暗黙クラスタを形成する(google様ならできるだろ)
このあたりのアルゴリズムは本領のはずなのでなんかうまいこと考えてくれ
・その結果が検索結果に反映されると言いはる
これで勝てる。
今のブックマークは昔と違って、「よく行くサイト」とかじゃなくて、
「あとで読む」「だれかと共有しよう」とかそんな理由で気軽にされるものなわけで、
それと検索結果への反映はものすごく親和性が高くて、そしてこれはgoogleにしかできない。
だいたい目的がコミュニティの形成ではなくて、最終的には検索を使ってもらうことなわけだ。
なんでGoogle Bookmarksをこんな状態で放置しているのかｗ
個人的には、検索結果に顔がでてきて、この人も+1してますってのはまぁわかるんだけど
リマインドしようにも、これを書いた人（＝自分）の学力だと読めない本だったから無理。無理ゲーだった。
第一章
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
プロコン！プロコン！プロコン！プロコンぅぅうううわぁああああああああああああああああああああああん！！！
あぁああああ…ああ…あっあっー！あぁああああああ！！！プロコンプロコンプロコンぅううぁわぁああああ！！！
あぁクンカクンカ！クンカクンカ！スーハースーハー！スーハースーハー！いい匂いだなぁ…くんくん
んはぁっ！プロコン・トップコーダーたんの黒色の髪をクンカクンカしたいお！クンカクンカ！あぁあ！！
間違えた！モフモフしたいお！モフモフ！モフモフ！髪髪モフモフ！カリカリモフモフ…きゅんきゅんきゅい！！
GCJのプロコンたんかわいかったよぅ！！あぁぁああ…あああ…あっあぁああああ！！ふぁぁあああんんっ！！
コドフォも人気安定してきて良かったねプロコンたん！あぁあああああ！かわいい！プロコンたん！かわいい！あっああぁああ！
蟻本も発売されて嬉し…いやぁああああああ！！！にゃああああああああん！！ぎゃああああああああ！！
ぐあああああああああああ！！！プロコンなんて現実じゃない！！！！あ…レーティングもアルゴリズムもよく考えたら…
プ ロ コ ン ち ゃ ん は 現実 じ ゃ な い？にゃあああああああああああああん！！うぁああああああああああ！！
そんなぁああああああ！！いやぁぁぁあああああああああ！！はぁああああああん！！コンテストアリーナぁああああ！！
この！ちきしょー！やめてやる！！現実なんかやめ…て…え！？見…てる？プロコンちゃんが僕を見てる？
コドフォのプロコンちゃんが僕を見てるぞ！プロコンちゃんが僕を見てるぞ！
トップコーダーのプロコンちゃんが僕に話しかけてるぞ！！！よかった…世の中まだまだ捨てたモンじゃないんだねっ！
いやっほぉおおおおおおお！！！僕にはプロコンちゃんがいる！！やったよMizayanov！！ひとりでできるもん！！！
あ、蟻本のプロコンちゃああああああああああああああん！！いやぁあああああああああああああああ！！！！
あっあんああっああんあtourist様ぁあ！！リ、リンゴ58！！最強最速アルゴリズマーぁああああああ！！！Petrぁあああ！！
第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 練習問題
基金訓練、今は求職者支援制度に名前が変わったみたいですけど、そこの講師をやめたというか、会社ごとやめて転職しました。
何の講師をやっていたかというと、今をときめく(?)Androidの講師です。
転職先にも少しなれてきて、今までのことを振り返って書き留めてみたのですが、せっかくなので発表することにしました。もともと僕だけが読むメモのつもりで書いたので、読みやすい文書ではないですがご容赦のほど。
Androidの講師になるまでは、Javaのサーバーサイドのエンジニアをやっていました。
お客様のところに常駐し、システムの一部ではあるけど、自社メンバーだけで上流行程から担当し、僕はそのチームリーダーでした。
プロパーの方でも仕事がないような状況で、それでも僕らのチームは半年ほどは細々とメンテなどの作業をやっていたのですが、最終的には契約終了になってしまいました。
自社に戻って、何をするのだろうと思っていたら、Androidの講師をやれ、といわれました。
Androidは、暇だった時期に少し動かしてみて、簡単なアプリなら組めるようになっていたのですが、人に教えるほどの技術はありません。しかも準備期間は1週間ほどしかありませんでした。
ビデオ教材と教科書が用意されていて、それに従っていれば最低限の講義はできるのと、最初のうちは純粋なJavaの講義だったので、前半をやっている間に講師はAndroidの勉強をしよう、という、何とも乱暴な計画を立てたのでした。
ほぼ定員いっぱい近い受講者の方が集まったのですが、スキルが全くバラバラです。
JavaやC#,C,C++の経験者がいるかと思えば、人差し指だけでキーボードを打っている方もいます。
講義の最初のうちはコマンドプロンプトを使うのですが、教材には説明がなく、最近の人は知らないだろうと思って説明書を作っていたのですが、まさかコピーペーストのやり方から説明することになるとは思っていませんでした。
それでもやる気のある方はまだましで、どうみても給付金目当てとしか思えない、やる気のない方が何人もいます。
こちらも準備不足の中、生まれて初めて「先生」と呼ばれる仕事を始めることになりました。
基金訓練を始める前は「きちんと技術を教えられるかな」ということばかり気にしていたのですが、講義の運営の方が問題続出でした。
いかにもやる気のない方々は講義中もトイレだ電話だといって抜けてしまう、講義中に当てても「わかりません」しかいわない、かといって質問もしない。当然課題も期限までに出さないので0点しか付けようがません。
そういう方でも、こちらから無理にやめさせたりすることはできないので、何とか講義だけはでてもらっていました。
けど、それがよくなかったようです。
まじめに受講されている方々から「金をもらって受講しているのにあの態度は何だ」「入校条件（キーボード入力）すら満たしていないのではないか」「講義のペースが遅すぎて時間が余る」などの苦情があがり、まじめな方から「就職が決まった」などの理由で辞めていってしまいました。
後に残った、やる気のない方々と、講義を続けていくしかありませんでした。
１度目の皆さんが修了し、2回目の講義を行うに当たって、前回の反省点を改善すべく、いろんな手を打ちました。
最後の手は、会社に怒られるのではないかと正直不安でした。実際辞めていく方が増えたのですが、こういう方は「家業が忙しくなったので手伝う」「体調が悪くなったので療養する」といったもっともらしい（？）理由で辞めていったので会社から怒られるようなことはありませんでした。
むしろ受講生の方の中から、積極的に他の方にアドバイスする方が増えたため、スキルの低い方からも「質問をしにいける人が(講師以外にも)大勢いたのでよかった」といってもらえるようになりました。
今回は、終了後の受講生の方どおしの打ち上げ会に呼んでいただきました。おおむね好評だったのだろうと思います。
未経験だけど、求職者支援制度を利用してプログラマになりたい方向けに、こういう人がプログラマに向いている、こうした方がいい、という条件を挙げてみます。
プログラムの勉強ははっきり言って辛いです。やりたいことが明確になっていないと、なかなか続かないです。
僕は「写経」と呼んでいるのですが、サンプルプログラムを実際に打ち込んでみて、エラーがあれば自分で修正する
という「訓練」をやらないと基礎が身に付かないです。そもそもキーを打つのが苦手、という人はきっぱりあきらめましょう。エラーの原因を自分でぐぐって調べられないような人も、この業界には向いていないです。
いき当たりばったりではなく、最初に手順・段取りを考えてから作業を始める方が向いています。
講義でも、課題作成に何日もかかる課題があるので、何も考えずに適当にやっていると期限までに終わりません。
「きりん、うさぎ、あひる、かば、4つの動物で仲間外れは？」みたいな問題が苦手な人は、向いていないと思います。
単に「読める」ではなく、課題を理解し、既知の技術で解けるものと未知のものに分けたり、繰り返し処理や、複数の似たような処理を一つにまとめるといった作業ができるかどうかです。
さっきの抽象的な考えもそうですが、今までそういうことを意識してやっていない、という方が多いと思います。そういう人は、しんどい思いをすると思います。
「ＡとＢという方法がありますが、ここではＡについて説明します」と講師がいったら、Ｂは自分で調べましょう。習ったプログラムを少し変えてみてどうなるか試してみましょう。それがうまくいかなかったとしても、経験というプラスが残ります。
講師の言うことが理解できたと思ったら、自分で応用問題を考えて、プログラムを書いてみましょう。もしそれが期待した結果にならなければ、どこかで理解が間違っている可能性が高いです。
先ほどの「試してみる」もそうですが、BLOGで実施すると、それをみた方からコメントやアドバイスをもらえることもあります。
いきなり何十行もプログラムを書いて動かなかったとしても初心者はまず動かせるようになりません。少し書いて、動かして動作を確認し、また動かして、を繰り返す方が結局早く完成します。
ちゃんと動く「プログラムの断片」を増やすことは、後で同じようなプログラムを書くときに、「断片」をそのままコピーして使えるようになると言うことです。
一度プログラムを書き始めたら、まずやることはプログラムを完成させて動かしてみることです。プログラムを書いている途中で、同じような処理があるからforで書きたいとか、メソッド化したいとか、思うかもしれませんが、プログラムの初心者はまず動くプログラムを書いて、それができてからきれいに書き直しをした方がいいです。
すぐに解けない課題は、書いて残しておきましょう。書いて整理することで、解けることがあります。今は解けなくても、後で見返して解けることがあります。
特に図に書く、という作業は意識的にやった方がいいです。講師に質問するときも、口で説明するより、図に書いた方がずっと通じやすいことがあります。
自分ができたことで他の人が詰まっていれば、アドバイスしてあげましょう。助けてあげると言うだけでなく、他人に説明すると言う作業は、自分自身の理解をより深める作業でもあります。
もちろん自力で最後まで解くことが重要な課題もありますが、そういうときは講師がそれとなく言ってくれるはずです。
とりあえずアプリを書いたら、同じ講義を受けている人や講師に見せて感想をもらいましょう。
アイコンを書くのが苦手なら、イラストが上手そうな人を見つけて、書いてもらったり、書き方を教わったりしましょう。
訓練を受けているのは同じような環境の方ばかりなので、相手だって同じことを考えているはずです。
紙のノートに講義内容を書いたり、テキストの余白にメモしている人がいますが、それは講義の内容を聞いて即理解できる人が、聞いたことを忘れないためのやり方です。
わからない人は、わかるようになるまで、何回でもノートを書き直した方がいいです。わかったことを継ぎ足して、表現を見直して、時には冗長な表現を削って、自分だけのオリジナルのテキストを作るつもりで書きましょう。当然書くのは紙のノートではなくパソコンをつかいます。
プログラミング以外の世界でもプロや、プロ顔負けの技術を持つセミプロ、ハイアマチュアといった方は自分の作品を世に出すときに恥ずかしがったりしません。不安はあっても、それを上回る意欲を持って、どんどんアプリを書いて、マーケットに載せましょう。
ひょっとすると業界の習慣よりあなたの意見の方が正しいこともあるかもしれませんが、未経験の人が言っても周囲はたぶん聞いてくれません。「私はずっとこのやり方でやってきたしこれからもやる」という意見はひとまずおいておいて、まずは周囲に認めてもらうようにしましょう。
余りに差がありすぎて自信をなくすと逆効果ですが、技術を身につけたければ自分より優れた人から学ぶのが一番です。コミュニティーや勉強会にも積極的に参加しましょう。
2010/05/16 23:40
こんにちは。昨日会った者です（これで特定するには情報不足だけど、まあわかるよね）。
で「幅優先探索でやる」という方針自体はいいと思うし、データ構造の作り方も基本は押さえていると思います（斜め読みしかしてませんが）。
ただ、コーディングの発想が「C で作る」という大方針から見て、少しちぐはぐな印象も受けます。データ構造の設計や操作の部分、汎用のライブラリを作ろうというのならあれでもいいと思うのですが、わざわざ汎用のライブラリを使わずに自分で専用の道具を一から作ろうというのなら、問題の性質を考慮して能率良くやることが大事です。
ところが、ここに載っているコードを見ると、見かけが C らしくなく、C++ や Java の劣化版のような印象を受けます。記法（マクロを大文字化しない、ルーチン名を大文字で始めるなど）だけの問題ではなく、データ構造の設計思想が「C で書く」という方針と矛盾しているように見えます。
もう少し具体的に言うと、そもそも C というのは現在 Web 系の世界などで流行のスクリプト言語類とは逆で、汎用言語でありながら低レベル（ハードウェアに近い）処理が簡単にできることに特色があります。つまり、組み込みを想定してプラットフォーム非依存のコードを書いたり、ハードウェアの特性を考慮して低レベルな最適化をやりたいというときに適しています。
そこでこの問題ですが、これを C でやるということは、処理速度や使用メモリ量の最適化が要求される状況、つまり迷路の大きさが途方もなく大きいような状況を想定すべきです。もっと言ってしまえばこの問題、たとえば画像処理などで似たような発想が要求されることがあります。このため、どうすれば時間のかかる処理を切りつめることができるかを考えてやらねばなりません。
このプログラムの場合、時間のかかる処理の代表格である malloc() が大量に使われています。これはいかにもまずいです。このような大量データを処理する場合の定石は、あらかじめ必要なだけメモリを確保しておいて、自分で割り当てることです。具体的には、必要と想定される量だけメモリを配列の形でどかっと確保しておいて、配列のインデックスをポインタ代わりに使います。そして、足りなくなったら倍々のような感じでメモリを realloc() してやればよいのです。
なお、そのような観点で言って、木の各節点の子の数は高々 4 （スタート地点が内点でないとすれば 3）であることを使っていることはよいと思います。ここで「子のリスト」とかを作ってしまっていたらこれはもうアホもいいところですから（容量の節約にすらなりません）。
そんな感じでしょうか。
とにかく、この手の問題は、アルゴリズムさえわかっていれば可読性もヘッタクレもないので、「短く書く」というような表層的なことよりも、何が求められているのかをよく考えて、柔軟に設計思想を考えることが大事だと思います。
2010/05/17 13:54
Oさんですね。専門的なコメントありがとうございます！cで書くと言いつつObjective-Cっぽい発想で書いていました。マクロの命名もその影響で、関数はImage Magickなどに似た命名規則になっている気がします。mallocを使いすぎると時間がかかるということは全然意識していませんでした。今度作るときはメモリ管理を自前で用意する発想を取り入れてみたいです。参考になるコメントありがとうございました！
Action Script は 3 からかなりしっかりしたクラスベースの OO だよ。
JS も馬鹿みたいな使い方しないでちゃんとしたスタイルで使えば OO だし、全てがハッシュというオブジェクトだし、関数もオブジェクトだしその辺わからないと JS をつかっててもコピペプログラミングに終始して面白くないから結局 OO 理解しないといけない。prototype.js や jQuery やの中身とか読んで理解できるくらいになるには。
Perl だって悪しき過去の遺産が残ってるから OO じゃないイメージが一部にあるけど、モダンな Perl は OO だよ。CPAN にあがってるまともなモジュールは殆ど OO スタイルだし、もっとモダンなスタイルの環境でもいける。モダン Perl や Moose あたりで検索してみるといい。今からやるなら OO しかないけど、初心者は昔のうんこを踏みがちだよね。JS も同じ事が言えるけど。
JS や Perl というゆるい LL は OO を理解していなくても一応使えるってだけで、それじゃマスターには程遠い。あと言語仕様でやっちゃいけないことを縛っていないから、しっかりした開発をやるには 規約もしっかりしないといけない。 初心者は最初からいい出会いをするわけじゃないから、誤解が多いのかもしれない。
JS と Perl はレガシースタイルが残ってる例としてあげたけど、LL でも Python や Ruby はもともと OO スタイルしかない。だから、自分でやってることを理解してないと過去のうんこを踏む可能性のあるゆるい LL よりは、どうやっても綺麗にしかかけない Python は初心者向けだと思う。知り合いが何でも良いからプログラミングやってみたいと言い出したら GAE で Python 弄らせる。
ぶっちゃけ LL でもいまどき OO を避けて通るなんて無理。
プログラミングスキルは、本質的には言語に依存しない。 (よほど糞な言語を使うのでなければだが) OO への理解やアルゴリズムの理解ってのは LL か巨大な言語かに依存しない。絵を描くのに道具によって慣れの差はあっても画力は道具を変えても持ち越せる共通した力だというのに似ている。一つの言語をちゃんとある程度マスターすれば、他の言語の習得はとても早い。たとえ最初にやる言語が LL でもね。別の言語をやるときに壁になるのは関数型かそうでないかくらいのパラダイムの差がある場合だけど、JS や Perl でさえ 関数型で使うようなテクニック を実装できるし使いどころがあるから、やっぱり共通点はあって、～だから～を学ばなくていい、なんてのは上達したいなら殆どない気がする。
まあ、午後２がなくなってるだけで段違い。
（オチ無し注意）
近年中国製品に押され気味の中なんとか頑張ってる陶器産業でなりたっているド田舎に生まれる。
田舎だから学校や進路は引越しなどがなければ中学まで必然的に決まる。少子化社会もあって、1学年保育園から中学までをほぼ同じたった50人程度の中で過ごしてきた。
みんな顔馴染みで互いが互いをかなり知っていてドロドロの関係だった。
自分の場合は両親が子供にあまり投資したくない類の人間だったので、服は近所から貰ってきたお古のものだったし、クラスで流行っていた何かについて話題に乗る事もできないし、勉強ができない割りに近所にある数少ない塾にも通わせてもらえなかったから全ての時期を「可愛そうな子」「近づいてはならない人」として扱われた。
10年近くもぼっち生活で、はっきり言って虐められていて苦痛だったし、親の方も母の家系がカルト宗教で父が「それに子供を巻き込むな」と制止していたのもあって結構な頻度で喧嘩が続いていたから精神状態も荒んでいて誰とも関わりあいたいと思わなかった。
中1の頃、ネットが開通した。
それまで独力でどこに行っても手に入らなかった理工学系の書籍をamazonで購入できるようになった。
当時人工知能にあこがれて森北出版の「強化学習」を買ったり、基礎的なアルゴリズムを勉強しようと「アルゴリズムイントロダクション」「アルゴリズムデザイン」を買ったりした。
今と比べると些細な情報しかなかったものの、技術情報もネットでぼちぼち調べる事ができるようになった。
学校での成績は悪かったが、情報工学に対して自分なりに勉強するようになった。無論、終わった人として扱われる学校になんて行きたくなかったから引きこもり不登校児にになった。
それでも自分は諦めたくなかった。自分が見出した情報工学という桃源郷を手放したくなくて、「学校に行くから」「（提示された以上の成績を）取るから」としつこくPCをせがんで型落ちながらもその都度PCを手に入れた。
何度も裏切る内に親も諦め、何も言わなくなった。
高校は2つ向こうの市にある遠い定時制に進んだが、案の定DQNばかりでトイレで薬物を吸っていたり平気で授業を妨害したり先生も何も言わなかったりで絶望して1ヶ月で辞めた。
そこから5年間、何度も自分の人生は終わってるんじゃないかとか、いつ死のうか思案を巡らせながら引きこもって過ごしてきた。
生まれてから20年が過ぎた。金がない。学校にも行けない。働き口なんてない。人脈もない。何もかも終わっていると思って現在も生きている。
長年引きこもっているせいで親に精神科へと通院させられているが、とうとうそこで障害者2級の認定を受けてしまった。年金の6万5千円の内5万は生活費として親に取られている。
最近、twitterで技術系に詳しいリア充共をFollowして観察している。
寝て起きて食事をしてはてブのトップページかTwitterのタイムラインを覗いて一日を過ごしている。精神が安定してきたらプログラミングもしているがあまり芳しくない。
女子中学生を名乗るスパムメールが来て釣られてみるかと会いに行ったら本当に女子中学生だった話。あるいは日本の将来やばい。
ありのまま起こったことを話す。女子中学生を名乗るスパムメールが来て釣られてみるかと会いに行ったら本当に女子中学生だった。何を言っているかわからないと思うけれど、自分でも何が起こったのかよく分からない。とりあえず詳しい経過を書いてみる。
一昨日(9/23)の深夜、一通のスパムメールが来た。簡単に「友達になりませんか？」と。普通ならそこで削除して終わりなのだけれど、他のスパムメールと決定的に違うことがあった。送信者のアドレスが@docomo.ne.jpだったのである。
ほぼ釣りか巧妙なスパムだと思ってスルーしていたけれど、ふと「どちらさまですか」と返信してみるとすぐに「XXX（以下、仮にハルカとする）っていいます。中３です！！」と返事が来た。
99%釣りと思ったけれど、遊んでみるかとメールを続けてみた。全力で釣られるのが紳士の努めである・・・
こういったスパムの場合、考えられるのは次の３つのいずれかだろう。
おそらく 2. だと思われるが、綺麗に釣られることで盛り上がるかなあとそれなりにメールを続けてみた。すると、いろいろ不審な点がでてきて、3. が急浮上してきた。
まず、メールの書き方が拙い。もし釣りであれば、もっと話を膨らませようとしたり、こちらの墓穴を掘ろうとするだろう。自分から、「メル友になりませんか♡」と書いてきたのに、話を膨らませる気がなさそう、「部活はなにやってたの？」と聞くと「卓球をやってました。」と答えるだけ。普通、相手にも同じ質問を返すか、そこでの話をしようとすると思う。あと一部、文脈がない、質問してもそれに答えないこともあったり。マウンテン・ティムがブチギレるレベル。それでも、なんとかメールを返すとちゃんと返事をくれる。返事は早くチャット状態だった。
そしてやたら地名が生々しい。話の流れから愛知県に住んでることがわかったのだけど、そのあと、「いまはヒルズにいます」と言ってきた。六本木ヒルズのことで東京にいるのかと思い聞いてみると、ヒルズXXというローカルなショッピングセンターのことだった。
ここからおそらく、女子中学生かどうかはともかく、かなり本物と言うか素人的ななにかじゃないかという推測が立てられた。
このときは夜神月くんが偽物だろうと思いながらもデスノートを試してみたら本物だったとわかってしまったような心境。だったと思う。
その日の夜、友達と飲みながら話をしていたら、もっとメールしてみようということになって、いろいろ送ってみることにした。その中で、なんでこのアドレスにメールしたの？（どこかで見つけたの？）と質問するとはぐらかされてしまった。そのあとに文脈がわからないまま写メ見せてください☆と来て何人かで写っている写真を「この中のどれかだよ！XXXちゃんの写真も見たいな」と送ってみた。すると自分の送った写真にはなんのコメントもせずに３人で写っているプリクラを送ってきた。幼い、明らかに女子中学生・・・。念のため書いておくと自分はロリコンじゃない、けれどもし相手がこの写真に写っている1人なら、どういう経緯で自分にメールを送ってきたのか、中学生の間でなにが流行っているのか、すこし興味が湧いてきた。
そのあと、その３人で写っている中でどれが私だと思いますかと聞かれて、半ば適当に答えるとんぜか見事に正解、その流れと怖いもの見たさとお酒の勢いで「これは会いに行かないといけないな^^」とキモいメールを送るとむこうもまんざらじゃなさそう、「でも会わないほうがいいですよ」とも言ってきたり、なぜか身長と体重を聞かれたり、そのあとに年齢を聞かれて、話をしているうちに、ほんとに翌日会うことになってしまった。
会う場所は、名古屋駅にしようと連絡するとよくわからない、と来た。それもそうか、と思うと「あの...お母さんがヒルズXXXにしなさいって言ってるんですけど...大丈夫ですか？」と返信。お母さん現る・・・！？
相手のホームグラウンドに行くのは美人局的なリスクもあって恐怖もあったけれど、なんとかなるかと勢いを大事に約束を取り付けて、おやすみとメールをクローズ。
なお、自分の意志だけでなく、一緒に飲んでいた人の後押しとカンパがあったことも書き加えておく。
翌朝、いつもの仕事の時間より早く起きて新幹線に乗る。片道１万円以上、なかなか痛い出費だけど、取材費と割り切る。
ただ、約束の11時のまえ、2時間くらい前からメールをしてみたけれど返事がない。まだ寝ているのか、やはり知らない男の大人に会うのは怖くて切ったのか、と不安になる。ゆったり勉強しようと思っていた休日とお金を遣ってる分、なんとか会わないとと思いつつも会えなくてもそこを観光してその県で仕事をしている先輩とごはんを食べることが出来ればそれでいいかなと思えてくる。
待ち合わせの時間を過ぎても返事がなく、別に連絡をとっていた現地の子に連絡をとってお昼を食べることになり騙されちゃったよと言っていると急にメール「すいません汗汗 お母さんの買い物付き合っててもうすぐ帰るんですけど時間かかりそうです汗汗汗」
お母さん同伴！？
と思いつつ、まあここまで来たしお母さんと話してもよいかなあと（なぜか）思えて、一緒でもよいよと返信してみた。メールを続けるとハルカちゃんはお母さんに自分と会うことになったと言ってしまい、当然反対されたということ、でも抜けて会いにいける、となって会うことに。
わりといそうな、ちょっと日に焼けていて服装もそんな気を遣ってはいなさそうだけど伸ばした髪はちゃんと手入れしてそうな感じの子。顔つきは地味目で、そしてすごい痩せている。
まだ子ども。なんでこんなメールをしてきたのか気になるのでいろいろ話を聞いてみる。
まわりから援助交際を疑われるかも知れないけれど、手をつないだりするわけでないし親戚のお兄さんが遊びに来たように見える、はず。
ただ、これは間違い。あとから分かったのだけど、その田舎のショッピングセンターは地元の人が遊んでばかりで、知っている子もぱらぱらいたそう。知っている人、友だちに知らない大人の男と一緒にいるところを見られてもなんとも思わない、むしろ自慢する風でもあることにふとした空恐ろしさを感じる。
驚くべき内容が多くて衝撃を受けたのだけど、うまく表現できないので箇条書きしてみる。
で、このあとプリ機（プリクラのことらしい）でプリクラ撮って少し話して、ペットショップ見てそろそろさようならとしようかなと思っていた、けれど・・・
高1のお姉さんも、デートするのにはアピタかこのショッピングセンターしかないらしく、遭遇してしまった。
しかも男連れ。彼氏（？）はどうみて40歳くらい。なにが起こっているのかワケガワカラナイヨ。
ただ見た目はちょっと格好悪いおっちゃんだけど話してると地元の景気を憂いていたり、新しいプリ機とかわからないけれど高校生と一緒にいるといろいろ勉強になると語るなど意外とまとも。気まずくてちゃんと話せなかったけれどまた話みたい、かも・・。
お姉さんはモテてる、と聞いた割にそう顔立ちがいいわけでないし、かわいらい格好をしているわけでない、ただ、先ほどのハルカちゃんの話の影響からか色目を使われているような気がしてしんどかった。
そしてフードコートで美味しくない山盛りのフライドポテトを食べてだらだら話をした。さっきまですごくたくさん話してくれたハルカちゃんもお姉さんの前ではあまりしゃべらない。謎の空気が気まずくて話も盛り上がらない。そして4人でプリクラ撮って、自分の気力が萎えて解散。ああ、禍根を残してしまった・・・。
最後はなんかいきなりキスしたりエッチとかはありえないけどキスマくらいなら・・みたいなことを言われて衝撃。けれど正直、文脈も分からないし飽きてきたのでよくわからない。はいはいワロスワロスみたいな感じで聞いてさらっと別れた。たぶん、もう二度と会うことはないだろうな・・・
そうして傷心したまま、名古屋駅で麺や六三六を食べてシルバーウィーク最終日の激混み新幹線で帰宅。
第1章 並行プログラミングとGHC (上田和紀) 1.1 はじめに 1.2 ターゲットを明確にしよう 1.3 はじめが大切 1.4 GHCが与える並行計算の枠組み 1.4.1 GHCにおける計算とは，外界との情報のやりとり(通信)である 1.4.2 計算を行う主体は，互いに，および外界と通信し合うプロセスの集まりである 1.4.3 プロセスは，停止するとは限らない 1.4.4 プロセスは，開いた系(open system)をモデル化する 1.4.5 情報とは変数と値との結付き(結合)のことである 1.4.6 プロセスは，結合の観測と生成を行う 1.4.7 プロセスは，書換え規則を用いて定義する 1.4.8 通信は，プロセス間の共有変数を用いて行う 1.4.9 外貨も，プロセスとしてモデル化される 1.4.10 通信は，非同期的である 1.4.11 プロセスのふるまいは，非決定的でありうる 1.5 もう少し具体的なパラダイム 1.5.1 ストリームと双方向通信 1.5.2 履歴のあるオブジェクトの表現 1.5.3 データ駆動計算と要求駆動計算 1.5.4 モジュラリティと差分プログラミング 1.5.5 プロセスによるデータ表現 1.6 歴史的背景と文献案内 1.7 並行プログラミングと効率 1.8 まとめ 第2章 様相論理とテンポラル・プログラミング (桜川貴司) 2.1 はじめに 2.2 様相論理 2.3 時制論理 2.4 多世界モデル 2.5 到達可能性と局所性 2.6 純論理プログラミングへ向けて 2.7 Temporal Prolog 2.8 RACCO 2.9 実現 2.10 まとめと参考文献案内 第3章 レコード・プログラミング (横田一正) 3.1 はじめに 3.2 レコードと述語の表現 3.3 レコード構造とφ-項 3.3.1 φ-項の定義 3.3.2 型の半順序と束 3.3.3 KBLとLOGIN 3.4 応用――データベースの視点から 3.4.1 演繹データベース 3.4.2 レコード・プログラミングとデータベース 3.4.3 いくつかの例 3.5 まとめ 3.6 文献案内 第4章 抽象データ型とOBJ2 (二木厚吉・中川 中) 4.1 はじめに 4.2 抽象データ型と代数型言語 4.2.1 抽象データ型 4.2.2 代数型言語 4.2.3 始代数 4.2.4 項代数 4.2.5 項書換えシステム 4.3 OBJ2 4.3.1 OBJ2の基本構造 4.3.2 モジュールの参照方法 4.3.3 混置関数記号 4.3.4 モジュールのパラメータ化 4.3.5 パラメータ化機構による高階関数の記述 4.3.6 順序ソート 4.3.7 属性つきパターンマッチング 4.3.8 評価戦略の指定 4.3.9 モジュール表現 4.4 おわりに 第5章 プログラム代数とFP (富樫 敦) 5.1 はじめに 5.2 プログラミング・システム FP 5.2.1 オブジェクト 5.2.2 基本関数 5.2.3 プログラム構成子 5.2.4 関数定義 5.2.5 FPのプログラミング・スタイル 5.3 プログラム代数 5.3.1 プログラム代数則 5.3.2 代数則の証明 5.3.3 代数則とプログラム 5.4 ラムダ計算の拡張 5.4.1 ラムダ式の拡張 5.4.2 拡張されたラムダ計算の簡約規則 5.4.3 そのほかのリスト操作用演算子 5.4.4 相互再帰的定義式 5.4.5 ストリーム(無限リスト)処理 5.5 FPプログラムの翻訳 5.5.1 オブジェクトの翻訳 5.5.2 基本関数の翻訳 5.5.3 プログラム構成子の翻訳 5.5.4 簡約規則を用いた代数則の検証 5.6 おわりに 第6章 カテゴリカル・プログラミング (横内寛文) 6.1 はじめに 6.2 値からモルフィズムへ 6.3 カテゴリカル・コンビネータ 6.3.1 ラムダ計算の意味論 6.3.2 モルフィズムによる意味論 6.3.3 カテゴリカル・コンビネータ理論CCL 6.4 関数型プログラミングへの応用 6.4.1 関数型プログラミング言語ML/O 6.4.2 CCLの拡張 6.4.3 CCLに基づいた処理系 6.4.4 公理系に基づいた最適化 6.5 まとめ 第7章 最大公約数――普遍代数，多項式イデアル，自動証明におけるユークリッドの互除法 (外山芳人) 7.1 はじめに 7.2 完備化アルゴリズム 7.2.1 グラス置換えパズル 7.2.2 リダクションシステム 7.2.3 完備なシステム 7.2.4 完備化 7.2.5 パズルの答 7.3 普遍代数における完備化アルゴリズム 7.3.1 群論の語の問題 7.3.2 群の公理の完備化 7.3.3 Knuth-Bendix完備化アルゴリズム 7.4 多項式イデアル理論における完備化アルゴリズム 7.4.1 ユークリッドの互除法 7.4.2 多項式イデアル 7.4.3 Buchbergerアルゴリズム 7.5 一階述語論理における完備化アルゴリズム 7.5.1 レゾリューション法 7.5.2 Hsiangのアイデア 7.6 おわりに 第8章 構成的プログラミング (林 晋) 8.1 構成的プログラミング？ 8.2 型付きラムダ計算 8.3 論理としての型付きラムダ計算 8.4 構成的プログラミングとは 8.5 構成的プログラミングにおける再帰呼び出し 8.6 おわりに：構成的プログラミングに未来はあるか？ 第9章 メタプログラミングとリフレクション (田中二郎) 9.1 はじめに 9.2 計算システム 9.2.1 因果結合システム 9.2.2 メタシステム 9.2.3 リフレクティブシステム 9.3 3-Lisp 9.4 リフレクティブタワー 9.5 GHCにおけるリフレクション 9.5.1 並列論理型言語GHC 9.5.2 GHCの言語仕様 9.5.3 GHCのメタインタプリタ 9.5.4 リフレクティブ述語のインプリメント 9.6 まとめ
（2012年1月書き直し。文章が長いという意見が多く見られたので箇条書きでまとめ直した）
第1章 有限オートマトン D.Perrin：橋口攻三郎 1. 序論 2. 有限オートマトンと認識可能集合 3. 有理表現 4. Kleeneの定理 5. 星の高さ 6. 星自由集合 7. 特殊なオートマトン 8. 数の認識可能集合 第2章 文脈自由言語 J.Berstel and L.Boasson：富田 悦次 1. 序論 2. 言語 2.1 記法と例 2.2 Hotz 群 2.3 曖昧性と超越性 3. 反復 3.1 反復補題 3.2 交換補題 3.3 退化 4. 非生成元の探求 4.1 準備 4.2 生成元 4.3 非生成元と代入 4.4 非生成元と決定性 4.5 主錐の共通部分 5. 文脈自由群 5.1 文脈自由群 5.2 Cayleyグラフ 5.3 終端 第3章 形式言語とべき級数 A.Salomaa：河原 康雄 1. 序論 2. 準備 3. 書換え系と文法 4. Post正準系 5. Markov系 6. 並列書換え系 7. 射と言語 8. 有理べき級数 9. 代数的べき級数 10. べき級数の応用 第4章 無限の対象上のオートマトン W.Thomas：山崎 秀記 序論 Ⅰ部 無限語上のオートマトン 記法 1. Buchiオートマトン 2. 合同関係と補集合演算 3. 列計算 4. 決定性とMcNaughtonの定理 5. 受理条件とBorelクラス 6. スター自由ω言語と時制論理 7. 文脈自由ω言語 Ⅱ部 無限木上のオートマトン 記法 8. 木オートマトン 9. 空問題と正則木 10. 補集合演算とゲームの決定性 11. 木の単項理論と決定問題 12. Rabin認識可能な集合の分類 12.1 制限された単項2階論理 12.2 Rabin木オートマトンにおける制限 12.3 不動点計算 第5章 グラフ書換え：代数的・論理的アプローチ B.Courcelle：會澤 邦夫 1. 序論 2. 論理言語とグラフの性質 2.1 単純有向グラフの類S 2.2 グラフの類D(A) 2.3 グラフの性質 2.4 1階のグラフの性質 2.5 単項2階のグラフの性質 2.6 2階のグラフの性質 2.7 定理 3. グラフ演算とグラフの表現 3.1 源点付きグラフ 3.2 源点付き超グラフ 3.3 超グラフ上の演算 3.4 超グラフの幅 3.5 導来演算 3.6 超辺置換 3.7 圏における書換え規則 3.8 超グラフ書換え規則 4. 超グラフの文脈自由集合 4.1 超辺置換文法 4.2 HR文法に伴う正規木文法 4.3 超グラフの等式集合 4.4 超グラフの文脈自由集合の性質 5. 超グラフの文脈自由集合の論理的性質 5.1 述語の帰納的集合 5.2 論理構造としての超グラフ 5.3 有限超グラフの可認識集合 6. 禁止小グラフで定義される有限グラフの集合 6.1 小グラフ包含 6.2 木幅と木分解 6.3 比較図 7. 計算量の問題 8. 無限超グラフ 8.1 無限超グラフ表現 8.2 無限超グラフの単項性質 8.3 超グラフにおける等式系 8.4 関手の初期不動点 8.5 超グラフにおける等式系の初期解 8.6 等式的超グラフの単項性質 第6章 書換え系 N.Dershowitz and J.-P.Jouannaud：稲垣 康善，直井 徹 1. 序論 2. 構文論 2.1 項 2.2 等式 2.3 書換え規則 2.4 決定手続き 2.5 書換え系の拡張 3. 意味論 3.1 代数 3.2 始代数 3.3 計算可能代数 4. Church-Rosser性 4.1 合流性 4.2 調和性 5. 停止性 5.1 簡約順序 5.2 単純化順序 5.3 経路順序 5.4 書換え系の組合せ 6. 充足可能性 6.1 構文論的単一化 6.2 意味論的単一化 6.3 ナローイング 7. 危険対 7.1 項書換え 7.2 直交書換え系 7.3 類書換え 7.4 順序付き書換え 7.5 既約な書換え系 8. 完備化 8.1 抽象完備化 8.2 公平性 8.3 完備化の拡張 8.4 順序付き書換え 8.5 機能的定理証明 8.6 1階述語論理の定理証明 9. 書換え概念の拡張 9.1 順序ソート書換え 9.2 条件付き書換え 9.3 優先度付き書換え 9.4 グラフ書換え 第7章 関数型プログラミングとラムダ計算 H.P.Barendregt：横内 寛文 1. 関数型計算モデル 2. ラムダ計算 2.1 変換 2.2 計算可能関数の表現 3. 意味論 3.1 操作的意味論：簡約と戦略 3.2 表示的意味論：ラムダモデル 4. 言語の拡張 4.1 デルタ規則 4.2 型 5. 組合せ子論理と実装手法 5.1 組合せ子論理 5.2 実装の問題 第8章 プログラミング言語における型理論 J.C.Mitchell：林 晋 1. 序論 1.1 概論 1.2 純粋および応用ラムダ計算 2. 関数の型をもつ型付きラムダ計算 2.1 型 2.2 項 2.3 証明系 2.4 意味論と健全性 2.5 再帰的関数論的モデル 2.6 領域理論的モデル 2.7 カルテシアン閉圏 2.8 Kripkeラムダモデル 3. 論理的関係 3.1 はじめに 3.2 作用的構造上の論理的関係 3.3 論理的部分関数と論理的同値関係 3.4 証明論的応用 3.5 表現独立性 3.6 論理的関係の変種 4. 多相型入門 4.1 引数としての型 4.2 可述的な多相的計算系 4.3 非可述的な多相型 4.4 データ抽象と存在型 4.5 型推論入門 4.6 型変数をもつλ→の型推論 4.7 多相的宣言の型推論 4.8 他の型概念 第9章 帰納的な関数型プログラム図式 B.Courcelle：深澤 良彰 1. 序論 2. 準備としての例 3. 基本的な定義 3.1 多ソート代数 3.2 帰納的な関数型プログラム図式 3.3 同値な図式 4. 離散的解釈における操作的意味論 4.1 部分関数と平板な半順序 4.2 離散的解釈 4.3 書換えによる評価 4.4 意味写像 4.5 計算規則 5. 連続的解釈における操作的意味論 5.1 連続代数としての解釈 5.2 有限の極大要素と停止した計算 6. 解釈のクラス 6.1 汎用の解釈 6.2 代表解釈 6.3 解釈の方程式的クラス 6.4 解釈の代数的クラス 7. 最小不動点意味論 7.1 最小で唯一の解を得る不動点理論 7.2 Scottの帰納原理 7.3 Kleeneの列と打切り帰納法 8. プログラム図式の変換 8.1 プログラム図式における同値性の推論 8.2 畳込み，展開，書換え 8.3 制限された畳込み展開 9. 研究の歴史，他の形式のプログラム図式，文献ガイド 9.1 流れ図 9.2 固定された条件をもつ一様な帰納的関数型プログラム図式 9.3 多様な帰納的関数型プログラム図式 9.4 代数的理論 9.5 プログラムの生成と検証に対する応用 第10章 論理プログラミング K.R.Apt：筧 捷彦 1. 序論 1.1 背景 1.2 論文の構成 2. 構文と証明論 2.1 1階言語 2.2 論理プログラム 2.3 代入 2.4 単一化子 2.5 計算過程―SLD溶融 2.6 例 2.7 SLD導出の特性 2.8 反駁手続き―SLD木 3. 意味論 3.1 1階論理の意味論 3.2 SLD溶融の安全性 3.3 Herbrand模型 3.4 直接帰結演算子 3.5 演算子とその不動点 3.6 最小Herbrand模型 3.7 SLD溶融の完全性 3.8 正解代入 3.9 SLD溶融の強安全性 3.10 手続き的解釈と宣言的解釈 4. 計算力 4.1 計算力と定義力 4.2 ULの枚挙可能性 4.3 帰納的関数 4.4 帰納的関数の計算力 4.5 TFの閉包順序数 5. 否定情報 5.1 非単調推論 5.2 閉世界仮説 5.3 失敗即否定規則 5.4 有限的失敗の特徴付け 5.5 プログラムの完備化 5.6 完備化の模型 5.7 失敗即否定規則の安全性 5.8 失敗即否定規則の完全性 5.9 等号公理と恒等 5.10 まとめ 6. 一般目標 6.1 SLDNF-溶融 6.2 SLDNF-導出の安全性 6.3 はまり 6.4 SLDNF-溶融の限定的な完全性 6.5 許容性 7. 層状プログラム 7.1 準備 7.2 層別 7.3 非単調演算子とその不動点 7.4 層状プログラムの意味論 7.5 完全模型意味論 8. 関連事項 8.1 一般プログラム 8.2 他の方法 8.3 演繹的データベース 8.4 PROLOG 8.5 論理プログラミングと関数プログラミングの統合 8.6 人工知能への応用 第11章 表示的意味論 P.D.Mosses：山田 眞市 1. 序論 2. 構文論 2.1 具象構文論 2.2 抽象構文 2.3 文脈依存構文 3. 意味論 3.1 表示的意味論 3.2 意味関数 3.3 記法の慣例 4. 領域 4.1 領域の構造 4.2 領域の記法 4.3 記法上の約束事 5. 意味の記述法 5.1 リテラル 5.2 式 5.3 定数宣言 5.4 関数の抽象 5.5 変数宣言 5.6 文 5.7 手続き抽象 5.8 プログラム 5.9 非決定性 5.10 並行性 6. 文献ノート 6.1 発展 6.2 解説 6.3 変形 第12章 意味領域 C.A.Gunter and D.S.Scott：山田 眞市 1. 序論 2. 関数の帰納的定義 2.1 cpoと不動点定理 2.2 不動点定理の応用 2.3 一様性 3. エフェクティブに表現した領域 3.1 正規部分posetと射影 3.2 エフェクティブに表現した領域 4. 作用素と関数 4.1 積 4.2 Churchのラムダ記法 4.3 破砕積 4.4 和と引上げ 4.5 同形と閉包性 5. べき領域 5.1 直観的説明 5.2 形式的定義 5.3 普遍性と閉包性 6. 双有限領域 6.1 Poltkin順序 6.2 閉包性 7. 領域の帰納的定義 7.1 閉包を使う領域方程式の解法 7.2 無型ラムダ記法のモデル 7.3 射影を使う領域方程式の解法 7.4 双有限領域上の作用素の表現 第13章 代数的仕様 M.Wirsing：稲垣 康善，坂部 俊樹 1. 序論 2. 抽象データ型 2.1 シグニチャと項 2.2 代数と計算構造 2.3 抽象データ型 2.4 抽象データ型の計算可能性 3. 代数的仕様 3.1 論理式と理論 3.2 代数的仕様とその意味論 3.3 他の意味論的理解 4. 単純仕様 4.1 束と存在定理 4.2 単純仕様の表現能力 5. 隠蔽関数と構成子をもつ仕様 5.1 構文と意味論 5.2 束と存在定理 5.3 隠蔽記号と構成子をもつ仕様の表現能力 5.4 階層的仕様 6. 構造化仕様 6.1 構造化仕様の意味論 6.2 隠蔽関数のない構造化仕様 6.3 構成演算 6.4 拡張 6.5 観測的抽象化 6.6 構造化仕様の代数 7. パラメータ化仕様 7.1 型付きラムダ計算によるアプローチ 7.2 プッシュアウトアプローチ 8. 実現 8.1 詳細化による実現 8.2 他の実現概念 8.3 パラメータ化された構成子実現と抽象化子実現 8.4 実行可能仕様 9. 仕様記述言語 9.1 CLEAR 9.2 OBJ2 9.3 ASL 9.4 Larch 9.5 その他の仕様記述言語 第14章 プログラムの論理 D.Kozen and J.Tiuryn：西村 泰一，近藤 通朗 1. 序論 1.1 状態，入出力関係，軌跡 1.2 外的論理，内的論理 1.3 歴史ノート 2. 命題動的論理 2.1 基本的定義 2.2 PDLに対する演繹体系 2.3 基本的性質 2.4 有限モデル特性 2.5 演繹的完全性 2.6 PDLの充足可能性問題の計算量 2.7 PDLの変形種 3. 1階の動的論理 3.1 構文論 3.2 意味論 3.3 計算量 3.4 演繹体系 3.5 表現力 3.6 操作的vs.公理的意味論 3.7 他のプログラミング言語 4. 他のアプローチ 4.1 超準動的論理 4.2 アルゴリズム的論理 4.3 有効的定義の論理 4.4 時制論理 第15章 プログラム証明のための手法と論理 P.Cousot：細野 千春，富田 康治 1. 序論 1.1 Hoareの萌芽的な論文の解説 1.2 C.A.R.HoareによるHoare論理のその後の研究 1.3 プログラムに関する推論を行うための手法に関するC.A.R.Hoareによるその後の研究 1.4 Hoare論理の概観 1.5 要約 1.6 この概観を読むためのヒント 2. 論理的，集合論的，順序論的記法 3. プログラミング言語の構文論と意味論 3.1 構文論 3.2 操作的意味論 3.3 関係的意味論 4. 命令の部分正当性 5. Floyd-Naurの部分正当性証明手法とその同値な変形 5.1 Floyd-Naurの手法による部分正当性の証明の例 5.2 段階的なFloyd-Naurの部分正当性証明手法 5.3 合成的なFloyd-Naurの部分正当性証明手法 5.4 Floyd-Naurの部分正当性の段階的な証明と合成的な証明の同値性 5.5 Floyd-Naurの部分正当性証明手法の変形 6. ライブネスの証明手法 6.1 実行トレース 6.2 全正当性 6.3 整礎関係，整列集合，順序数 6.4 Floydの整礎集合法による停止性の証明 6.5 ライブネス 6.6 Floydの全正当性の証明手法からライブネスへの一般化 6.7 Burstallの全正当性証明手法とその一般化 7. Hoare論理 7.1 意味論的な観点から見たHoare論理 7.2 構文論的な観点から見たHoare論理 7.3 Hoare論理の意味論 7.4 構文論と意味論の間の関係：Hoare論理の健全性と完全性の問題 8. Hoare論理の補足 8.1 データ構造 8.2 手続き 8.3 未定義 8.4 別名と副作用 8.5 ブロック構造の局所変数 8.6 goto文 8.7 （副作用のある）関数と式 8.8 コルーチン 8.9 並行プログラム 8.10 全正当性 8.11 プログラム検証の例 8.12 プログラムに対して1階論理を拡張した他の論理 第16章 様相論理と時間論理 E.A.Emerson：志村 立矢 1. 序論 2. 時間論理の分類 2.1 命題論理 対 1階述語論理 2.2 大域的と合成的 2.3 分岐的 対 線形 2.4 時点と時区間 2.5 離散 対 連続 2.6 過去時制 対 未来時制 3. 線形時間論理の技術的基礎 3.1 タイムライン 3.2 命題線形時間論理 3.3 1階の線形時間論理 4. 分岐的時間論理の技術的基礎 4.1 樹状構造 4.2 命題分岐的時間論理 4.3 1階の分岐的時間論理 5. 並行計算：その基礎 5.1 非決定性と公平性による並列性のモデル化 5.2 並列計算の抽象モデル 5.3 並列計算の具体的なモデル 5.4 並列計算の枠組みと時間論理の結び付き 6. 理論的見地からの時間論理 6.1 表現可能性 6.2 命題時間論理の決定手続き 6.3 演繹体系 6.4 モデル性の判定 6.5 無限の対象の上のオートマトン 7. 時間論理のプログラムの検証への応用 7.1 並行プログラムの正当性に関する性質 7.2 並行プログラムの検証：証明論的方法 7.3 時間論理による仕様からの並行プログラムの機械合成 7.4 有限状態並行システムの自動検証 8. 計算機科学における他の様相論理と時間論理 8.1 古典様相論理 8.2 命題動的論理 8.3 確率論理 8.4 不動点論理 8.5 知識 第17章 関係データベース理論の構成要素 P.C.Kanellakis：鈴木 晋 1. 序論 1.1 動機と歴史 1.2 内容についての案内 2. 関係データモデル 2.1 関係代数と関係従属性 2.2 なぜ関係代数か 2.3 なぜ関係従属性か 2.4 超グラフとデータベーススキーマの構文について 2.5 論理とデータベースの意味について 3. 従属性とデータベーススキーマ設計 3.1 従属性の分類 3.2 データベーススキーマ設計 4. 問合わせデータベース論理プログラム 4.1 問合わせの分類 4.2 データベース論理プログラム 4.3 問合わせ言語と複合オブジェクトデータモデル 5. 議論：関係データベース理論のその他の話題 5.1 不完全情報の問題 5.2 データベース更新の問題 6. 結論 第18章 分散計算：モデルと手法 L.Lamport and N.Lynch：山下 雅史 1. 分散計算とは何か 2. 分散システムのモデル 2.1 メッセージ伝達モデル 2.2 それ以外のモデル 2.3 基礎的概念 3. 分散アルゴリズムの理解 3.1 挙動の集合としてのシステム 3.2 安全性と活性 3.3 システムの記述 3.4 主張に基づく理解 3.5 アルゴリズムの導出 3.6 仕様記述 4. 典型的な分散アルゴリズム 4.1 共有変数アルゴリズム 4.2 分散合意 4.3 ネットワークアルゴリズム 4.4 データベースにおける並行性制御 第19章 並行プロセスの操作的および代数的意味論 R.Milner：稲垣 康善，結縁 祥治 1. 序論 2. 基本言語 2.1 構文および記法 2.2 操作的意味論 2.3 導出木と遷移グラフ 2.4 ソート 2.5 フローグラフ 2.6 拡張言語 2.7 その他の動作式の構成 3. プロセスの強合同関係 3.1 議論 3.2 強双模倣関係 3.3 等式による強合同関係の性質 3.4 強合同関係における置換え可能性 3.5 強等価関係上での不動点の唯一性 4. プロセスの観測合同関係 4.1 観測等価性 4.2 双模倣関係 4.3 観測合同関係 4.4 プロセス等価性上での不動点の唯一性 4.5 等式規則の完全性 4.6 プロセスの等価性に対するその他の概念 5. 双模倣等価関係の解析 5.1 等価性の階層構造 5.2 階層構造の論理的特性化 6. 合流性をもつプロセス 6.1 決定性 6.2 合流性 6.3 合流性を保存する構成子 7. 関連する重要な文献
ソーシャルゲームはイノベーション。だがイノベーションは、すべてのユーザーが接続された単一のサーバーを使う、マルチプラットフォーム、マイクロトランザクション、コレクション中心のゲーム性、ゲームマネーとリアルマネーの最小限の垣根、スマートな課金システム、ゆるやかなコミュニケーションではない。ソーシャルゲームのコア技術。だがゲームや伝統的なオンラインゲームやウェブサービスなどが実現済み。だが人類史上ソーシャルゲームだけが実現した特徴。人間とボットが混在してもボットの存在が気がつかれない革新的な環境。ボットが人間に擬態して人間とゲームをプレイしてゲームを盛り上げるSF近似の環境が実現。ソーシャルゲームではユーザー同士の人間的なコミュニケーションを極限まで減少することでこれを可能に。革新的なことにもかかわらず不思議に語られない。すごく残念に思う。私が語ろう。
#
ボットは、パソコン MMO では周知の事実で違法がはびこっている。これから話すことは少し違う。ソーシャルゲームのボットは、ゲームメーカー自身によって開発された。ボットは、普通のユーザーには区別がつかない。仲間やあなたの競争相手のいくつかはボットと考えるのは簡単。多くの人が疑問に思う。人間とボットの区別がつかないはずがない。セカンドライフとパソコンのMMOのような環境でボットが人間のフリをするのは大変困難。MMOはすべてのプレーヤーの動きをリアルタイムに見ることができる。すべてのプレイヤーがどのように動作するかを誰もが見ることができる環境では、特異な行動パターンは際立って目立つ。ほぼ同じアクションが繰り返されるならすぐにボットとわかる。ありえない動作もすぐにわかる(超高速移動、不可能なタイミングの攻撃を続ける、など)。MMOのボットのためのチートツールは不自然ではない動きの再現に苦労。NPCキャラの移動は不自然。同じ場所しか歩かない。不自然に遠回り。隙間に入って抜け出れなくなるなど。人間の操作する自然な移動は非常に困難な技術。ボットが人間とパーティを組んで行動するのは不可能。ボットは会話できない。MMOはキーボードと共にある。ゲームのチャット機能も充実。チャットをするのは当たり前。完全な無言のユーザーは不自然な存在。協調行動は全く取れない。すぐにボットが露見するであろう。
#
対照的にソーシャルゲームでは人間とボットを区別する機能が軽視。あるいは未実装。他のプレイヤーの行動は目立たない。気がつかない。他のプレイヤーにあまり興味を持たないことでボットことに気がつかない環境。他のユーザーが何をしているのか分からない。ユーザーの仲間は行動記録を閲覧できる。ユーザーと対戦したユーザーとの試合結果は見ることができる。それは非常に断片的。ボスを倒した、ダンジョンをクリアした、などの結果しかわからない。他のユーザーのプレイの状態を把握することはできない。ソーシャルゲームでは装備の着替えを繰り返しているユーザーがいても誰も気がつかない。MMOで装備の着替えを繰り返しているユーザーがいたらすごく目立つ。ソーシャルゲームでは異常な行動パターンをとっていても問題にならない。目立たない。ボットにとても都合が良い。ソーシャルゲームでは移動に必要もない。移動はリンクのクリックだけ。人間らしい移動アルゴリズムは不要。ソーシャルゲームでは会話がとても軽視。他ユーザーへのコメントや掲示板がある。しかしあまり活用されない。ゲームに協力する戦略性が必要が薄いため。またキーボードが使えない。ずっと無言のユーザーも珍しくない。会話がとても少ない。ボットの理想的環境。ソーシャルゲームは最低限のコミュニケーションで成り立つことに最適化。それは同時にボットが人間に擬態することにも最適化。結果的にボットが人間に擬態できる環境が生まれている。結論。リンクをランダムクリックするだけでもボットが完成。それは不自然なゲームプレイが予想される。だが他ユーザーは気がつかないであろう。
#
ボットを活用しているのは違法ユーザーではない。ゲームの開発会社が用意している。運営している。言い換えればハック不要。無制限にデータベースへのアクセスが可能。実際にゲームを操作する必要ない。データベースに記録を行えば良い。SQLだけでボットを作ることが出来る。例えば、"ナンバーワンのユーザーの敗北を増やす"SQLの次の2行で実現することができます。余談。MySQLのサブクエリ限界は非常に気に入らない。「SELECT userid FROM usertable ORDER BY gold DESC LIMIT 1;UPDATE usertable SET lose=lose+1 WHERE userid=xxxxxx;」これは不十分。たかだか敗北数を増やすだけ。正しくは対戦相手と対戦ログもゲームルールに合わせた形で記録。データベースに勝敗結果を記録するプログラムが必要。これはゲームのプログラムに元々存在している。流用するだけで良い。PerlやPHPで実装されているだろう。対戦結果の偽装は簡単。
#
ソーシャルゲームはSNSプロフィールページと連動。ユーザーの顔画像クリックでプロフィールページに遷移。プロフィールページの偽装が必要。プラットフォーマーは己のSNSのデータベースへのアクセスが可能。ランダム名前で自動大量生成することは容易。ボットのプロフィールページを用意することは容易。ボットユーザーは、日記を書くことなく、まったくの無言で、熱心にゲームをプレイ。そのような特徴は正規ユーザーにも珍しくなく違和感はない。参入メーカーはSNSプロフィールページを大量に作成できない。正規プロフィールページを使い回す。その場合には、ゲーム上のH氏とG氏ののSNSのプロフィールが互いにV氏で同じ人に。これは異常。しかしユーザーは他ユーザーのプロフィールの対応を全てチェックしたりしない。発見される確率はとても低い。
#
閲覧者はボット開発の容易さには納得したと信じる。まだボットの必要性と活用には納得していない。これからの話しで納得できる。
伝統的ゲームは開発者の感覚を基準にゲームバランスを決定(マーケティングの無視を意味しない)。ソーシャルゲームはユーザーアクティビティに基づいて、科学的な分析でゲームバランスへのアプローチを決定。これはユーザーアクティビティのサーバーログが蓄積されるために可能。ユーザーアクティビティの分析結果がゲームバランスに反映。例。チュートリアルの進行状況50%で停止しているユーザーが多数いるという分析結果。その箇所のチュートリアルは高い障害ことが想定される。対策。その箇所を平易に修正。その箇所を短縮。その箇所を除去、など。結果、チュートリアルの進行状況50%で停止するユーザーは激減。課金でも分析は重要。課金アイテムのバナー画像を表示する例。ランダム分割したグループAユーザとグループBユーザに別々のバナー画像を見せる。しばらく続け、結果的により課金が多いグループのバナー画像がより最適。繰り返すことでより効率的なバナー画像が完成。
#
ゲームパラメータは簡単にデータを調整できる。しかしこれは不十分。人間同士のプレイの分析に適応できない。例。「開始直後に他のユーザーと対戦し3連敗したユーザーの70%はそれ以上プレイを続けない」という分析結果があると仮定。これはゲームパラメータでは解決できない問題。開始直後のユーザーは誰もが同じ強さ。ゲーム内で最弱。パラメータの調整とは別問題。解決策はボットの利用。開始直後のユーザーより弱いボットを用意。開始直後のユーザーはボットに優先的にマッチング。ボットの内部パラメータは開始直後ユーザー以下だかユーザーにはユーザーと同程度のパラメータに見せる。ユーザーは確実に勝利できるので3連敗してゲームを辞めてしまう可能性は激減。またユーザーは自分と同程度のパラメータの相手に勝利したと信じている。プレイを継続するモチベーションに繋がる。ソーシャルゲームプレイ中の人は確認推奨。理論上ユーザー全体の対戦での勝利数と敗北数は一致。上位のユーザーは勝利数のほうが多く下位のユーザーは敗北数が多い。コアユーザーでないのなら敗北数が多いのが正しい。もしもあなたが下位ユーザーにもかかわらず勝利数のほうが多いのであればあなたはボットに感謝する必要がある。逆の例:ロンチ直後のランキング上位にはボットを置く。それがないと初期ユーザーはすぐ上位到達。同ボットはゲーム人口が大幅に増加したら不要になることがおおい。
#
課金でも分析結果にボットを適用するのは重要。例。「課金未経験でしばらく連勝を続け宝物のコンプリートまであとわずかのユーザーに突然強力な一人のユーザーが連日攻撃し続け宝物を奪いにきたときユーザーは課金アイテムを購入して防衛する可能性が高い」という分析結果があると仮定。ユーザー心理は、今をしのげば他ユーザーには連勝を続けられると考える。今だけでもと課金を行う。これを再現するボットの開発は容易。データベースを検索して課金未経験でしばらく連勝を続け宝物のコンプリートまであとわずかのユーザーを発見。そのユーザーと対戦可能で勝利できるパラメータのボットを検索。ボットは前もって様々なパラメータで大量に用意しておくのは当たり前。発見したボットでユーザーと対戦し対戦結果をボットの勝利でデータベースに書きこむ。これでユーザーが課金する確率が飛躍的に高まる。課金未経験ユーザーに課金を経験させることは実に重要。一度同様のボットプログラムを開発したら後は全自動で継続的に動作するのは当たり前。分析とボットの組み合わせアプローチ。日本ソーシャルゲームの驚異的課金率の施策の1つ。
#
このようなパターンはユーザーアクティビティを分析することで無限に発見することが可能。ゲームの盛り上げと収益の最大化に大きく貢献。あと1つ例を。課金未経験ゆったりプレイユーザーにボットが仲間申請。ボットはゲームを情熱的にプレイ。課金も積極活用。仲間ゆったりユーザーにボットのプレイ結果がどんどん伝わる。多くのソーシャルゲームでは仲間のプレイ状況は断片的にユーザーに知らされる。中のプレイ状況は大きな刺激。仲間に影響されてよりプレイが活発に。「ユーザーのプレイ頻度は一番プレイが頻繁な仲間のプレイに近づいていく」分析結果への対応。地味であり効果は直接でないが確実にある。ボット数の効率化の観点から、1つのボットで100人以上のユーザーと仲間になるのが望ましい。ゲーム内の仲間人数制限をボットに限り解除。ユーザーがボットのプロフィールを見たときにボットことが露見すると冷めてしまう。表向きは仲間人数制限を解除していることが露見しないように。
#
伝統的なRPGゲームではユーザーの進捗状況に応じて十分な強度の仲間と敵を提供します。これとソーシャルゲームのボットは近似している。ユーザーモチベーションを上げるのが目的のは同じ。RPGのモンスターと敵はユーザーもコンピュータのAIの操作ことを知っている。それでも十分楽しいが。しかしそれが人間ならもっと楽しい。そこでMMO。しかし人間は己もプレイヤー。ユーザーに合わせて適度なパラメーターで楽しさを演出などしない。そこで人間に擬態したボット。ユーザーに合わせてゲームを盛り上げる。ユーザーは人間だと信じているのでモチベーションも最高に。あらゆるゲームの問題点が完璧に解決されている。ボットの役目はユーザーの退屈に刺激を与えること。ゲームがボットだらけ必要はない。賢いボット利用を。このようなボット効果はソーシャルゲームのユーザー間のバランスを調整しモチベーションを維持するために非常に大きいです。ボットはほとんど話題にされない。技術情報に積極的な企業もボットは不思議と話題にしない。結果。ソーシャルゲーム開発会社も知らないところが多い。ボットを利用するソーシャルゲームはむしろ少数派。ゲームパラメータ調整だけでは限界がある。ユーザーアクティビティのログ解析はハイレベルだが本当に重要です。ログの分析に基づいてボットが適切なアクションを残すことでユーザーを興奮させるのでゲームに活用してください。また歴史の人間とコンピュータの黎明期以来、初めてボットと人間の見分けがつかない世界の技術革新を達成したことに多くの技術系ユーザーは興味を抱くであろう。ソーシャルゲーム会社は技術者を積極採用中。その一端はより優れたボット開発。興味があるなら是非応募を。ソーシャルゲームの一層の発展を願う。
#
やった後にしなきゃよかったなんて思うくらいならやんなきゃよかった
VS.
やらずに後悔するならやった方がマシ
いずれも個人の、狭い認識から継ぎ接ぎした事例と分析なので、広く一般的に通用するわけでもなければ書き手自身に意味のあるものとなるとは限りません
意義や結論を導ききる気は多少はありますがさして信念というものを持たない（保てない）ため
既にやったことに対して、その行為の意義の無さや無常観、もとより始めからそうなることの予感をえていた様子
もうこころからの後悔と、二度とそれをしないことへの決意じみた卑屈さがあります
転じて、後者では未だ結論がでていない事物に対して拙速に取り組もうとする、これから事を成すものの、挑戦者の態度です
彼/彼女は自身や自らを取り囲む環境に対し、現在を事を成す時と定めます
それが未知なるものに対峙する態度として、或いはそれが分かりきったこととして
それが唯一の正解というべきものにせよ、誤りであると気づくための数ある道の一つにせよ
と、ここらで飽きました。
ここで対立する2項はあらかじめ不可分なもので、それをひらいた切り口は、単純に行為をした、前後に分断されているだけだと云うこと。
どちらにもそれなりに合意できる同機と反芻する点があって、それを比較してみたかっただけなのだとわかりました。
（いつもの如く、有意義な結論を探し出すのに飽きた。といってはもったいないけれど）
ただ、両者のような態度のどちらも取り込んでおけば、やることなすことを、同じことを同じように繰り返し続けることはなくなるのではないかという淡い希望を持ちます。
2度はやるまいと思った事を2度とやらない。かつ、未知なること(言い換えると、新しいこと)に対する試行を続けること。
これらの指針/原則に従い行いを繰り返しすことが洗練された方へ向かう手段ともいえる。
（他にもありそうだし、なんかのアルゴリズムで言うところの局所解に陥る可能性も充分ある。）
今日はもういいや。つかれた。
アフィリエイトで月30万円以上稼ぎたい方向けの見せ方テクニック
http://anond.hatelabo.jp/20110828172558
上記の記事、読みましたか？
大体月30万円ぐらいを達成できたら、次にあなたがするべきことは、
いかにして、楽をして稼ぐかの段階を模索していくことになります。
楽に稼ぐなんて胡散臭いと思うかもしれませんが、要は人を雇うということです。
記事であればライターの方に書いてもらう、あなたにプログラミングの技術がなければ技術のある方に頼むということ。
稼いだお金を溜めこむのではなく、その利益の一部を人に投資することが次の段階になります。
これをケチる方は、ずっと自分で製作していかなくてはならず、仮にアフィリエイトでの利益が
想像すると分かるかもしれませんが、働きながらコツコツとアフィリエイトサイトを作って、
月30万円を獲得した方が、ある日、Googleのアルゴリズムなどで、月20万円にまで落ちたらどうなるか？
これ、ビックリするぐらい、やる気をなくす方が多いのですね。恐らく、今まで作って来た努力が全部無駄になったかの
ような錯覚に陥るからだと思います。この燃え尽き症候群を、甘くみないほうが良いです。
やる気を失い、一度アフィリエイトの世界から足を洗ったものが、再挑戦するのは相当つらいです。
また、1からのスタートですからね。このパターンで成功した方には、お会いしたことはありません。
さて、人を雇うとなると、すごく難易度が高いかのように思われるかもしれませんが、
例えば、以下のような外注サイトを活用すると良いです。はてなブックマーク数も多いですよね。
@soho
Lancers
例えば、Lancersの「仕事一覧→ネーミング・ライター→記事・コラム」を見てみて下さい。
http://www.lancers.jp/work/search/idea/writing
色々と、頼んでいる方がいるでしょう？
つまり、このような外注サービスを駆使して作っていくことが、楽して稼ぐための道になります。
例えば、30万円の内、まずは3万円をライターを雇うことに使ってみる。
人とのやり取り、書いて欲しい記事を伝える技術、その過程で色々なことを学んでいくでしょう。
もちろん失敗もあるかもしれないけれど、全て投資代として考えれば安いものです。
そして、なるべく自分は指示するだけで済むようなポジションへと移動していけば良いのです。
人を雇った分のお金で、さらなる利益を生めば、そのお金をまた次に投資していく。
あなたに何かのアプリを作る技術がなくても、お金があれば作って頂くことも可能でしょう。
月30万円レベルになったら、そのお金を維持するにしろ伸ばすにしろ、
必ず人を雇ったほうが良いです。あとは、飽いた時間に遊んだり次なる戦略を練っていけば良いのです。
注文を受けてから、せっせと服を作り、メールでやりとりして、しかも車で自宅まで届けに行くなんて
しませんよね。大きく儲けるなら、あなたがデザイナーであろうと工場に発注する必要があるし、
世の中、至るところに仕組みが組み込まれていて、成り立っているわけです。
仕組みに投資しないものは、楽して稼ぐことができないと、ハッキリと言っておきましょう。
あー、あと、月100万円を稼いでいます！月100万円を稼ぐ方法をお教えします！などの、
情報商材は、買わないようにしましょう。確かに月100万円稼いだかもしれませんが、
そのような方って意外と広告費や人件費やその他雑費で、お金を数十万円使っていたりして、実際の利益はスズメの涙ですよ。
つまり、実際の利益がないから、そのような商材で儲けようとするのです。
本屋で売っているアフィリエイト本、ネットで手に入る無料の情報、
また、色々な方のアフィリエイトサイトやネットショップを読み込んでの勉強などを活用すれば、充分です。
例えば、あなたが小さな会社の代表だとして、いつか金持ちになりたい楽をしたいと考えているのに、
ずっと自分で営業することにこだわっていたら、お金なんて稼げないし楽な日は来ないです。
月1万円からでも良いです。儲けの分は、誰かを雇って、自分は仕組み作りに専念するという成功体験を
少しずつ重ねていってみてください。
そこまで来れば、「楽をして稼ぐ」という意味が分かってくるかと思います。
楽をして稼ぐと言いましたが、月30万円にいくまでには、地道な努力ですよ。その段階まで、楽なんてありません。
楽をしようとして、胡散臭い情報商材や有料のメルマガとかに、ハマらないようにね。あれ全部、何の役にも立たないから。
ん、役に立つって書き込みを見た？そのリンク自体が、アフィリエイトリンクになっていないっすかね？つまり、ネズミ講。
以上っす。