  |
はてなキーワード: トレランスとは
ダテコーの事をよく知らない人や見下したい人ばかり寄ってたかってると感じる。
ダテコーは、ネトゲでいう、「ちょっとLVも装備も足りてないけど変わった攻略法を試したいから付き合ってくれる人募集！」ってシャウトしてるPTリーダーみたいな人だと思う。ネットで叩いてる人は、その「ゆるい募集」を見ずに入ってきて、自分では絶対にPTを立てないけれど、入ったらリーダーの指揮とかメンバーの振る舞いの至らなさに悪態をつく、他人への要求が高すぎる人と被って見える。ダテコーがやっていることは、メジャーで洗練されたビジネスライクな効率PTとは違う性質のもの。仮にてさぐれ部活もの以上の大ヒットを当てたとしても、ひねくれ者のダテコーは大手制作会社のような作品は作らない気がする。自分の信じる「ゆるさ」や「面白さ」を表現するために、永遠にチープでマイナーなもの、悪く言うとキャスト・スタッフや視聴者の好意に甘えた、アットホーム感のある作風にこだわりそうだと私は感じる。そして、そういうスケールアップをあえてしない道は、茨の道だけれどもアリだと思っている。
ダテコーはバウンスィという制作会社を経営してるけど、アニメ業界の人はほぼいない。カネがなく(資本金350万だよ)、テレビ業界とコネがあり、メンバーは構成作家や演出家、音響技術者くらいの10人少々。アマチュアレベルのMMDに手を加えた3Dモデルを動かす人形劇アニメにもかかわらず、大手アニメと肩をならべて放送枠をとっている零細ベンチャーみたいなもの。だから大手制作会社と同様の条件でやろうというのは無理ながらも、キャストを含め作風に共感してくれるスタッフの好意と熱意に支えられて、もがいているチャレンジャーという立ち位置。しかも彼はツイートしてるように、キャストに約束した給料は不払いせずきちんと払ってるし(あくまで大手制作会社とくらべて安いから申し訳なく思ってるって事だろう)、自身は会社設立以来1年間無報酬でやっていて、貯金もほぼないそうだ。局で作家をしていたころは一般サラリーマンの3倍ほど貰っていたらしいが、テレビ局の構成作家は3000万稼いで一人前という世界から身を引いた方なので、ベンツを乗り回してみたいなネットの噂で僻んでも仕方がない。ともかく、稼いでいるのに金払いをケチる悪い人間、という風評は悪意的だと思う。
彼を追ってきた人なら分かると思うけれど、実際はクソ真面目で、言われてるような声優アドリブ芸や内輪ネタに頼りすぎた作風を良しとせず、脚本や音響などスタッフ達がきちんと仕上げて編集する作品作りにこだわっている人。だからこそ、現場がそういうディレクションを軽視して「やっぱ声優さんすげーわ任せるわ」ってなるたびに怒って監督をやめている。職分を超えて、声優の負担を増えさせる不健全な状況には敏感な人だ。実際BDのノーカット版などをみた人ならば、編集はじめクリエーターたちのすごさが伝わっていると思うし、最終回の作り方などには、彼の美学を感じさせられる。
あのツイッター発言についても、本意と違う悪意的な捉え方ばかりされていると思う。本意としては、自虐的ながらも、「ウチは普通のとこと違うし当然売れないもんだから、普通のビジネス感覚でやってくる人とはお互い良くない、俺たちはファミリーが欲しかったんだけど残念だ」くらいのことだと思う。私は別に条件が合わなかった相手をdisる意図はないと感じたし、その条件が合わなかった人のことを指して「技量がない」と言っているようには思えなかった。このへんはネットで西野さんが炎上してた時にも私は思ったんだけど、みんな悪意的に捉えすぎている。「ダセー」だとか「お金の奴隷」は西野さん自身に向けられた言葉だし、自分がお金にこだわって可能性を閉ざすやり方を一部改めたからといって、お金(対価)を大切にする普通の人たちを貶す意図は感じなかった。むしろ、西野さんにも石舘さんにも、普通の人達に対して理解を示す言葉があった。それすらも乗り越えて、それを用意周到な言い訳とみなし、煽られたように捉えてしまいカチンとくる自意識過剰な人が多すぎるように思う。自分の労働ぶりを自虐的に捉えている人がそれだけ多いのかもしれない。
ともかく叩いてる人らは彼を典型的なアニメ業界の監督だと思って、「こういう奴がいるから業界は…」と感じているようだけれど、ここまで語ってきた文脈を捉えてもらえれば、ピントがずれていることが分かると思う。業界の薄給問題でほんとに叩くべきなのは大手制作会社で、彼のようにテレビ業界とのコネとアイデアで飛び込んだベンチャー社長みたいな人を叩いてたら、余計に業界は健全化しないと思う。カネはないけどツテとキャストやスタッフの好意に上手に甘えつつ、アニメ業界に切り込んで新しいカタチを提案していく、そういう立ち振舞は資本力のある大手には許されないけど、ベンチャーとしては参入が許容されてしかるべきだ。そういう遊びを許容しないと、市場に新しい風は生まれない。もちろん、労働法の範囲内でだけど。そこは実際にはおそらく問題ないのに、彼が自虐的な言い方をしすぎるせいで、問題のある労働が行われていると勘違いさせている。新しい風と言ったけど、低予算のMMDアニメだとか、リアルタイム3D人形劇の先鞭をつけたのはダテコーだし、実際人を選ぶけどファンはついてるわけだよ。キャストだって、弱小ゆえの至らなさやダサさをネタにして監督をイジる事は多々あれど、ツンデレというか作品も監督も基本愛しているように思う。そういう文脈を捉えてない人や、一般企業で安くこき使われてる人たちの怒りが、ダテコーというアニメ業界を代弁できないイレギュラーな存在に矛先を向けてしまった。本来アニメ業界の大企業のおエライさん方に向けるべき正論を、辺境の霧の中にぶちこんで無駄にしている感じがする。ダテコーの言うことは、クリエイティブの、しかも不安定なベンチャー分野で通用する、熱意の方向性に関する局所的な話なのに、クリエイティブ業に携わることも、ベンチャーにジョインする人脈や熱量とも無縁な性質の勤め人たちから、「一般常識」で殴られている感じが、見ていて本当につらい。
堀江貴文さんなどもそうだけれど、内面がクソ真面目すぎるせいで強い思想をもち、世間から見ると変わったことをやっていて、世の「普通」に一切媚びない人種の方々は、無頓着だからすぐに炎上してしまう。何に無頓着かって、自身のやってきた文脈を一切とらえずに一般論に基づく感情で殴りかかってくる人たちに「誤解」されないための言葉選びや長ったらしい自己説明をまったくしない辺り。そういう異能たちが、出る杭だと叩かれてノーマライズされる方向に圧力が掛かるのは悲しいことだ。
それはさておき、私はダテコーのような新興の弱い買い手が、背伸びをせず等身大の報酬しか出せないけども、その弱さを隠蔽せず、詐称せず、そして契約を強要せずにいる姿勢はとても誠実だし、ホワイトだと思う。「ウチは小さいから相場ほど報酬あげられないけど本当にいいの？考え方に賛同してくれるとかじゃないとやってけないよ？」と正直に言った結果、断られ続ける。それは愚痴りたくもなるけど、むしろ倫理的には賞賛されるものだと思う。取引は双方の合意があって成立する。そのことを売り手(被雇用者)に常に自覚させ、選択権を与え、冷静に賢い判断をしてもらうことは重要なこと。売り手側が考えるまでもなく、お利口な買い条件しか提示しない、良い所しか見せない企業ばかりだと、判断能力が育たなくて恐ろしいし、画一的でいびつ、非現実的だと思う。経済的に未熟な企業から、成熟した企業まで、さまざまあっていい。経済的に未熟な企業はどうしても無い袖は振れない、これを理解せずに「相場を払えないなら経営するな」という人ばかりだと、誰もPTリーダーをやらなくなる、もとい起業しなくなる。もう少し、柔軟性があってもいいはずなんだ。「ボッタクリでも時と場合によっては買うぜ」って人が稀にいるのと同様、「多少安売りしてでもこの会社この人とならコラボレートしたい」という希少な人の存在を、「賃金」のポリコレ棒で生まれる前に消滅させてしまってはいけないと思う。最低賃金だとかダンピング防止みたいな例外はあるものの、基本的には、どんな値段をつけるのも自由であるべきで、そっちの基本部分の方を甘く見ている人が多いように感じる。ボッタクリにも理由があり、存在価値がある。だから絶対悪ではない。自分が買い手の場合にそういう考え方ができるのなら、自分が売り手(被雇用)側になったときに同じ考え方ができていいはずだ。自由状態でこそ市場は成長するし、人間としても取引に多くを学び、成長していくんだと思う。市場の失敗が起こるとしたら、大体は倫理にもとる行い、ズルをしている場合。産地を偽ってボッタクリ価格を正当化している、とかね。そういう訳でもなければ、一方的にすべての企業に「十分な(平均並の)支払い」を求めるのは、経済理解に暗いがゆえに計画経済的な発想になっている人なのかなと思わせる。イラストレーターの買い叩きとかクラウドワークス的なのが批判される時、企業にもっと払えと言う人がその無理筋ぶりに無自覚なのと同じで。
話を戻すと、彼を叩いている人たちは、経済的に未熟な企業を許さないんではなくて、ダテコー側が倫理的に未熟な企業だと思いこんで叩いているようだ。もちろん倫理的に未熟な企業ということなら、市場の失敗をもたらすから零細でも大企業でも許容されるものではない。ただ、その判断をするのはネットの野次馬ではなく、労基署とか公的機関だけれどね。今回のダテコーの件の場合、ダテコーの側は経済的には未熟な企業だけども、倫理的には叩かれるほどの問題はないと思う。若い零細クリエリティブ企業としてはむしろ身分相応で卑屈すぎるくらいで。これがワタミのような余裕のある大企業で、そのくせ相手に判断させる余裕も与えず洗脳に近いことをして雇用するのだったら大問題となって然りだけれど。
あと、叩いている人たちに感じた疑問がもう一つあって。そもそも、一企業が、従業員を養う責任を負うのが当たり前のように思われているけど、重すぎると思う。そういう考え方をしていると、日本の労働環境はいつまでたっても全体的にブラックなままだと思う。企業はおのおのの身の丈にあった、妥当な配分を労働者に与えればいい。それで足りない場合、国が負担する。それはナントカ手当だったり、ベーシックインカムだったりしてもいいけど。そういう考えが前提になってほしい。経営者だって人間だし、完璧ではないし不安定な存在だ。会社が小さいうちは、自分の人生ですら支えられるか分からない。経営者も若い事が多いし。だからもっと柔軟に、雇用区分だとか時間を変えてワークシェアを進め、流動性を高めて、一企業に人生を預けるようなとんでもない常識を変えていかないといけないと思う。労働をフォールトトレランスな分散型に。
他人に求めすぎる悪態ネトゲプレイヤーがPTにありつけなくなる問題の解決策は、PTリーダーに対する期待値を下げること、あるいは気楽にPTを立てれる空気をつくることだ。そういう考え方が出来る人が少しでも増えて欲しいと思う。人生はしょせん、すべてがごっこ遊びで、全ての人がなんらかのロールを演じているにすぎない。お仕事も、特に日本人のお仕事は、お仕事ごっこだ。そんなに崇高に考えて、他人に崇高さを求めてもどだい無理なんだ。もちろん、実際に崇高度が高くて「強い」企業の横暴には敏感になって良いけれど、相手の顔が見えないネットだからこそ、相手ももしかしたら弱い人間なのかも、と想像することはとても大事なことだと思う。慈しみを。神のご加護を。
もし、これが増田だから本人乙とか関係者乙と穿った見方をする人がいたとしたら不本意なので、一応自己紹介すると、私は中部地方に住む32歳職歴なしのニート(家事手伝い)です。
目覚まし時計の電池が切れていて設定時間にアラームが鳴らず冷や汗を書くことがなんどかあり、まじで心臓に悪いので冗長化した。
・目覚まし時計①のアラームを起きたい時間の10分前にセット。目覚めの暖機運転。
②と③は最後の警告としてのアラームなので、これがなったら「絶対に」起きる。
また、②と③のアラームの設定時刻は下手にずらさず同じにしておく。
ずらしてしまうと後になる方を信用して二度寝する可能性があるため。
仮に片方が鳴らなくても可用性を維持できる。
追記:
ブコメ見た。乾電池で動くタイプの時計以外にスマホのアラームもまぜておくと安心度が増しそう。
あと、怖いなと思うのが全て電波時計タイプで統一してしまうこと。事例あるのか知らないけど電波障害かなにかで一斉にずれたらと思うと・・・
第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 練習問題
