 
|
はてなキーワード: メモリとは
ガチでメーラとWordとExcel,パワポ（しかも2003（笑））、teraterm、FFFTP位しかつかわねーからさ
あいつら本気でXP(笑）、メモリ1GBで足りてるとか思ってるからタチがわりーわ。
・コードがかける若手SE（笑）がEclipseとかMySQL、Oracle,Chrome,Firefox,IE,Java,.netと使うからある程度スペックが欲しい。(と言っても今時の５万で買える普通スペックで良い。。）
↓
・若手が新しいPC寄越せと要求
↓
・年食ったコードがかけないSE（笑）はOffice2003（笑）位しか使わないし、めんどくさいから要らないと抜かす
↓
・先輩がいいって言ってるのにお前らが要求するのか？とか言って取り合わない。
↓
・ほんとに必要な最前線の若手にまともなPCが行かない、その結果朝にパソコン起動してメーラとEclipseが起動するのに１５分かかる環境の出来上がりｗｗｗ
一方部課長以上の役職には全員Androidタブレットが支給され
お飾り部長には組織移行都度に新PCが卸される（結局何してるかもしらんがｗOfficeとIEしかつかわねーくせによｗｗｗ）
そりゃ社員がセットアップするし、何も入ってねぇから環境移行もし易いもんなｗｗ
もちろんAndroidタブレットはメール確認するくらいにしか使わないｗｗｗ
iPadやAndroidタブレットのブラウザ、メールをちょこっと触った位で最新になったと思い込むめでたい老害達。
そのHTML5とサーバサイドの開発するのは俺たち若手SEなんだがなｗｗｗｗ
でも結局使わないし飽きて部長のタブレットは机の中に入れっぱかおきっぱ。
クラウドクラウド、SalesforcrSalesforce
クソウォーターフォール維持しながらスピード感がとか寝言ぬかしてんじゃねーぞｗｗヴォケが。
上の承認が～承認が～って要件定義が～ってお前らクソ共の承認があってスピードも何もねぇだろうがｗｗｗ
その上テストドリブンしようとすると、要件が固まってないだろ！とか抜かすし、殺すぞ。
結果アホ共が思いつきで言い放った言葉は忘れない
SalesForceのパンフレットに開発は１月を目処に実装する、みたいな文言を間に受けて
え？じゃあ、プロトタイピングとかテストドリブン型とかでやるの？とか聞くと、
いや、客の要件をしっかり聞いて要件をしっかり洗い出して～上司の承認をしっかりと得て手戻りがないように～とか抜かすｗｗｗｗｗｗ
おい、お前それ今までとかわらねーじゃねーかｗｗｗｗｗ
あーいうのは少人数チームで全員が開発者としてプログラムが十二分に書けて仕様書とかの書類を最低限にして
要件定義や決定権限の大部分を現場に委任して優先順位の高い項目からを集中してやるから出来るのであって
日本のほとんどのアホSI企業の典型的なコードの書けないExcel書くだけの御用聞きSE（笑）なんて邪魔以外の何者でもないｗｗｗ
そんなゴミSE（笑）が多くを占める会社で出来る事じゃねーんだよｗｗｗｗ
あーいうゴミ共は居るだけでどーでもいい好みでの文句をグダグダいうから余計に作業が遅くなるｗｗｗ
こういうクソみたいなことばっかりやってるから古い日本企業はダメなんだよ、ゴミどもが、さっさと潰れろ。
そして俺はクソSI業界を見限ってソーシャルゲーム業界に転職準備をしているのであった（完）
http://anond.hatelabo.jp/20120207005408
まなめはうす恐るべし
ちなみに私のPCのスペックはPen4 1.6Ghz メモリ1GB HDD 30GBです。
これでメインはJavaのStruts2とSpring Eclipse3.7で組んでます。
これより低い奴出てこいや…
とりあえず一部間違えていたので訂正ｗｗｗ
１．HDDは37GBでした。ごめんなさい、実際に見てみたら間違えてました。でもいつもSVNチェックアウトするときとかデカイzipを落とす時はいつも何か消してからしています。
２．ケースはチェーンで鍵がかけられているので開けられません(^p^)よって自分での拡張は不可
後、時々あった。
PGなんてのはゴミがやる仕事だからそんなの気にかける方がゴミ
とか
とか
コードを書かなきゃいけない時点で大手ではない
ちなみにT○SとかI○M、NT○の人もコード普通に書いてたよ。
ってか書くとこは書くでしょｗｗ
んで上みたいな考えの人はそれで構わないでしょう。
そうやって思っててコードやプログラム部分なんてどうでもいい。
フロントエンドやバックエンドが発達しても設計書レベルや提案レベルに落としこむ場合に実コードの知識なんて影響しない思うならそれでどうぞって感じ
いつまでも何でもバッチ処理（笑）にこだわる人も良くいますしねｗｗｗｗ
私からしたらいつまでコードの書けないSE（笑）が成り立つか逆に聞きたい位ｗｗｗ
ま～コードがかけないSE（笑）からいつも馬鹿にされてるのを知ってるから、コードがかけるSE（笑）はどんどん逃げてっているんですよね～
わざわざプログラム（笑）とか馬鹿にされてまで居るものじゃねーよｗｗｗ
現在どんどんSI業界から出来る人が率先して辞めてるからｗｗｗ
ただでさえ人材不足のクソSI業界にいつ影響が表面化するか（もうしてるか？）楽しみですNE!
私は先に役に立たない大量の船頭しかいない泥船から抜け出しますｗｗｗ
戻って来ることもないでしょう！多分！
それではアデュー！
ああ、今じゃあメモリ2GBで32bit WindowsってんでもうDisられちゃうんだなあ。
おじさんの新入社員のころはWindows2000用のソフトウェアをWindows MEのメモリ128MBのマシンで開発しろって言われたよ。
VC6はそりゃあもう遅かったねえ。
しまいにゃHDDの基板上のチップがパッケージ不良で大規模回収になって、ロットが対象のものだって発表される直前にクラッシュしたのさ。
おじさんがその会社にいたくなくなったのはそれが最初だった。バックアップ用のHDDもなければ、CVSなんて便利なものも無かったから、自腹で購入していたノートパソコンにこっそり移していなければ、ソースが全部クラッシュしていたところだったなあ。
そういやCVS使いたいって言ったらなんか知財の関係の人に申請書を出して許可を得なくちゃいけないとかで面倒くさすぎて諦めたこともあったなあ。ie以外のブラウザも禁止だったなあ。アレも禁止コレも禁止って言った割にはcode redとか感染しまくってて笑えたなあ。
そうなんだよな～ぶっちゃけ偉い人に新しいパソコンとかタブレットとか渡しても無駄だろ。
老害がこれ会社から貰ったんだよ、とか言ってる前にメインプログラマに支給してるPCを新しくしろやｗｗｗ
俺なんてEclipseでJava開発しまくりStruts2,Springとかフレームワークバリバリなのに今時Pen4の1.6Ghzでメモリ1GB、HDD30GBの10年前のデスクトップでやれとか言われてんだぞｗｗｗｗ
マジでクソ老害共に与えたAndroidタブレットの代金で新しいノートPCでもよこせやｗ
クソ老害マジしねよ。
いや、横だがメモリ２Gって １G２枚ってことじゃね？
さすがに、何時の時代だよって話だろうかと。
あと DevPartneerとかPurifyとか使わんの？ プロファイルとかかけないの？って話もあるな。
コードが数百万行超えた時のインテリセンスとかどうすんの？とか。
メモリなんてどんだけあっても困らんし
某社内でのソフトウェア技術者について書きたくなったので書いてみる。
まず、そもそもプログラミングは下請け or 子会社がやるものという認識。それを、最近本社でもソフトウェア技術者を採用し始めたけど、やっぱり低く見られがち。プロジェクトの開発リーダーは必ず電気回路の人だし、外部との折衝もやらせてくれない。工場の製造用ソフトだってハードウェア技術者が無理して書いてる。
周りのプログラマーのレベルも低いよ。自分の周りがそうなだけかもしれないけど、C言語以外できない人多いし、ポインタはおろか struct と union の違いも認識していない。環境がローレベルなのか、仮想メモリとかいう考え方もない。 Windows しか使ったことない人ばかりだし、簡単なコンパイルエラー直すだけで数時間がかり。バグ管理はもちろん Excel。ヘッダファイルの define 一覧が Excel に表としてまとめられていて、手動で同期取ってたりする。
あとパソコンに対する考え方が古いよね。未だにCADを17インチディスプレイで書いてるし。今年会社で導入標準モデルになってるパソコンはメモリ2GB, HDD 320GB しか積んでない。マシンに投資するのは無駄という考え方が伝わってくる。スペックアップを主張しても「昔はもっと遅かった」で終了。
デスマーチを避ける考えもないかな。デスマーチを乗り越えたのが武勇伝として語り継がれる。俺何日も徹夜したえらい、みたいな。
そんなくせして、「Apple は大した技術力がないけど、アイデアがよかったから iPhone や iTunes がヒットしてる」と言ってる。まずいね。
第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 練習問題
オタクは何を以ってオタクとするか。PCに大変詳しい人、最近の深夜アニメをほぼ全部録画して観ている人間。コスプレイヤー、同人作家。サブカルチャーにどっぷり漬かってるのもある意味そうかとは思う。
では、昨今のPCに大変造詣が深い方にMSXやSHARP X1の話、X68000に搭載されていた音源であるYM2151の話。PC-98時代のコンベンショナルメモリがどうだのこうだの、なんて話をしてもきっとわかってはもらえまい。多分。そういった人を捕まえて「お前はPCオタクを名乗るのか。だがMSX TurboRの存在を知らずに何がPCオタクだ」等と罵倒した所で意味はない。知ってたら偉いってモンでもない。
「まどマギ」でも「IS」でも「Aチャンネル」でも「いろは」でもとにかく深夜アニメなら任せとけ。という方に「激走！ルーベンカイザーって田中真弓のアニメデビュー作なんだよな」等という話をしたり「今度の冬コミでナベタケのアニメ楽曲のデータベースをまとめて発表してみようと思うんだ」という事を言っても、ノってくれるかと言えば人それぞれだが、テンションがあがる人がそんなにいるとは思い難い。
同じ「PC」や「アニメ」というカテゴライズ話であるが、多分フィールドは違う。
「オタクはこうである。こうでなければならない」というのはないのだな、と思う。
リア充はどうか？「リアルが充実している人」という意味はあるものの、「彼女がいる人」「リアルが忙しい」等と言い換えられる事もある。
では、何を以って「リアルが充実している」とするか？
「彼女がいる」というステータスは確かに10～20代男性にはポジティブな意見が多いかとは思う。
だが、「彼女がいる」だけで、もう１年近く連絡が取っていない冷めた関係であったり逆に毎日50回位携帯に着信があり「電話出てよ」等と大泣きされている留守電が毎日の様に入っていて、しまいにゃ「もう死ぬ」と言われての自殺騒ぎで精も根も尽き果てて「リアルで忙しい」人達は果たしてリア充なのか？
何がリア充で何がリア充ではないか？「リアルが充実している」というものは曖昧な言い方であり、明確な定義はないと思う。
長々と話してきて、何が言いたいかというと、[こういった言葉に明確な定義はないし、考えるべきじゃないのだろう]という事。
うん。君よりはすっごく詳しいよ。
どんな言葉を選ぶかで、大体わかる。
俺にも君の言葉遣いだけでよっくわかってるよ
「裁判にかけること」ができれば、当然「罪に問うこと」もできる。
結果は、前にも書いたけどわからない。
おーい。
お前の日本語力について答弁してくれよ、なあなあ。
＞榎原広里
＞死んでくれとは言わない
＞一生お前を恨んでやるから
↑これ罪に問えるの？
に対してえ、
『「何をするかわからない」などと暗に加害行為をすることを告げる場合でも成立する。』脅迫罪として申し出ることは可能じゃないかな。
っていうお答えはあ、
どういう国語力に基づいてるのお？
って聞いてんだよ。
元の発言に無い部分を付けたしまくったうえに「申し出ることは可能」っていうのはあ、
話の噛み合い方として何点ぐらい？
そらさずに答えてごらんｗ 君の論理力を測ってあげるからあｗｗｗ
お前がこんな意味不明な返答した理由もわかってるよ。
いっしょーけんめいおぼえた脅迫罪の要件をご開帳するのに一生懸命で
問題文のほうを忘れちゃった
だろｗ
お前みたいなのは大変よくいるタイプで、んもー、見飽きてるの。
国語や論理や記憶力がどれも芳しくなくて脳のメモリも足りないのに
使えてない知識や研究室（）の話で威嚇を始めるところまで、
まあ頑張ってくれよなあ。
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を使いすぎると時間がかかるということは全然意識していませんでした。今度作るときはメモリ管理を自前で用意する発想を取り入れてみたいです。参考になるコメントありがとうございました！
というか、今まで傾かなかった理由は何だと思ってる？
プレイステーションやセガサターンなんて、CPUは20MHz前後、メモリ2～3MBとかだよ？
そんなミドルクラス以上のPCを持ってて、それをきちんと運用できてる人なんてごく僅かだよ。
そもそも自分のPCがどの程度の性能なのかすら分かってない人の方が多い。
一方コンシューマでは、据え置き気に比べて絶対性能が微妙な携帯機が威力を発揮しているなど、ゲームそのものに求められる描画能力が昔程重視されなくなっている。
重視されなくなったんじゃなくて、それなりのHD画質が「あって当たり前」になったってだけ。あって当然なクオリティだから誰も求めない。
今更ゲームにステレオ2ch音声を声高に求める人なんていないでしょ。
よく考えてみ。
あなたが想定する、「PC(Windows用)ゲームを買う人」ってどんな人？
性別、年齢層、家族構成、生活スタイル、職業、なるべく細かく想像してみ。
その上で、そういう人間がこの国に何百万人といて、そのうちの何十万人かが、現行のゲーム機やその他の娯楽を差し置いてまでPC(Windows用)ゲームを買う状況って、現実に有りうると思う？
ウェブ上で、読んだ後非常にモヤモヤする文章を見つけることがあります。この言葉にならない感覚は一体何なのか…書くことで言葉に変換して正体を突き止めたい！
ということで以下に絶好のサンプルを引用し、モヤモヤしないと思う文に脱臭してみたいと思います。
20才の頃、お金も無く、良くてユニクロ、下手するとジャスコで服を買ってた。いや、ジャスコでは正確には買っていない。帰省した時に、親が僕の服装のみすぼらしさを不憫がって、近くのジャスコに夕ご飯の買い物に行ったついでに、安売りの服を買って恵んでくれてただけだ。当時、今で言う「リア充」は、わざわざバイトして、そのお金で好きな服を丸井や伊勢丹で買って、お洒落少年をやっていた。リア充爆発しろ、とはこのことだ。当時の僕は、バイトしてまで服を買う程ファッションに興味が無かったし、そんなお金が有ったら、少しでも出たてほやほやの初代Pentiumマシンのメモリを増やしたかった。
【脱臭後】20才の頃はお金がなかったのでユニクロで服を買っていた。親が僕の服装を見かねて夕飯の買い物ついでにジャスコで安売りの服を買ってくれることさえあった。当時のおしゃれな友達はアルバイトしたお金でデパートの服を買っていて、妬ましかった。一方僕はそこまでおしゃれに興味がなく、服よりもPCの部品を買いたいと思っていた。
※20才の頃はユニクロやジャスコの服を着ていた。だけでも良いと思いますが、お金のなさの強調にジャスコは外せない一方で、親の話を入れてさすがにジャスコで買うほどはダサくなかったと言いたいのだと考え、残しました。親に対する「恵んでくれた」という表現は、卑屈なうえ親を小馬鹿にするようで、反感を覚えました。後半、あえてネットスラングを使ったり、Pentiumマシンという単語をわざわざ出すことにあざとさを感じました。できれば、PC部品の方が欲しいのにも関わらず服を買う友人を妬ましく思う心理にもう少し詳しい説明がほしいです。両方同程度に欲しいが自分はアルバイトでそこまで稼ぎきれなかったというもどかしさで、苛立っていたのでしょうか。
25才の頃は社会人3年目。デパートにはバーゲンなるものが有り、その時期だと安くお洒落な服を買える事をやっと発見した僕は、なけなしのボーナスを手に、デパートで服を買う様になった。しかし、その頃同世代のリア充は更に先に行っていて、バーニーズやVIA BUS STOPとかの、やや高級なセレクトショップで服を買っていた。デパートで買うDCブランドの服は、自己主張が強く、どことなくDQN感が漂う時も有ったが、リア充達がセレクトショップで買う服は、大人の余裕に溢れていて、僕はそこにファッションのスキルの差を感じざるを得なかった。
【脱臭後】25才、社会人3年目になる頃にはボーナスも入り、デパートのバーゲンがお得なことに気づいて、デパートで服を買えるようになった。しかしその頃、おしゃれな友達はもっと先を行っており、高めのセレクトショップやで服を買っていた。デパートのブランドはこれ見よがしでかっこ悪い気もして、おしゃれな友達に対し相変わらず劣等感を覚えた。
※「なるものが有り」「やっと発見」「なけなしの」等がうるさい印象を受けました。後半は単に劣情を述べていると思うのですが、固有名詞や言い回しでおしゃれに精通していると強くアピールしているように感じられ、鬱陶しく思いました。
30才になると、そこそこお金も出来て、時代もバブってくる事になる。この年代になってやっと、ストラスブルゴやアリストクラティコみたいな通っぽいセレクトショップで買うようになり、欧州の古いメゾンのオーナーデザイナーが来日しての採寸オーダー会みたいなのをチェックして買ったり、ディオールやドルチェ&ガッバーナなど、自分のスキニ―な体型でこそ生きる服を多く揃える店によく行って、しまいには自分の担当が出来たり、いつしか服の買い方に関する変な劣等感は無くなった。
【脱臭後】30才になると収入がずっと増え、通好みのセレクトショップの服やヨーロッパのデザイナーのオーダーメイドを買ったり、超高級ブランドに通い詰めてお得意様扱いしてもらえるようになり、劣等感を克服した。
※この部分は特に鼻についたため、思い切って大幅に割愛しました。特にこれ見よがしなファッション用語が嫌らしいと思いました。
その頃、手練れのプロ独身みたいな洗練された女性と知り合った。外資系企業に勤め、日本版SATCみたいな感じの子だった。ある時彼女は、服を買いたいときはニューオータニに行くと言っていた。余り意味が分からなかった。少なくとも、これまで僕が経験してきたプライスタグともろもろの質が正比例するマッチョな世界とは違う軸の話なのだろうとは感じた。正直、服を買いにホテルに行くのは、想像力の範囲外の事柄だったので、その言葉に対し、僕は極めて曖昧な返事をした覚えがある。
【脱臭後】その頃、外資系企業に勤める独身の、非常に洗練されたおしゃれな女性と知り合った。彼女は服を買いたいときはニューオータニに行くと言っていた。当時はホテルで服を買うなど考えてみたこともなく、彼女の真意もわからず、曖昧に返事をするしかなかった。きっと、高い服ほどおしゃれに違いないという僕の考え方とは次元が違う話なのだろうと思った。
※「プロ独身」とはどういう意味なのか、ぜひ説明してほしいです。「プライスタグともろもろの質が正比例するマッチョな世界」という表現も、何度も読み返さないと意味がわかりませんでした。高尚な雰囲気を醸し出そうとしすぎだと思いました。
そして、35を少し過ぎた今、やっと彼女が言っていた事が何となくは分かる。確かに、オータニやオークラは服を買いに行くには快適な場所だ。静かで、邪魔されず、店員は控え目な一方、二回目の訪問なのに僕が前に買ったものと、何とどういう軸で迷ったかを覚えてくれている。古いホテルに入っている、いつも客が入っていないアパレル系のお店は、なぜ成立しうるか長年の疑問だったが、プロ独身女性みたいな「お金のある、うるさ方」が太い顧客なのだろう。こういう人は服はもう十分に持っている。だから、服そのものだけが買い物の目的では無く、服を買うプロセスにもこういう人はスペシャルを求め、そのプロセスを消費している。そうすると、単に服の品揃えが良い店より、自分の好みを知っている店、静かに買える店、客筋がいい店、みたいな所の評価が上がり、結果的に高級ホテルに入るに相応しい接客レベルのお店が、その種の人々に刺さることになる。
【脱臭後】そして今、35才を少し過ぎて、彼女の言った事がわかるようになった。ホテルに入っているアパレルショップは静かで、店員も控えめで、落ち着いて服を選べる。そのうえ一度の買い物でも、次に行ったとき前回どの服を迷ったかまで覚えていてくれる。なぜホテルのアパレルショップはいつも空いているのに商売が成り立つのか、長年疑問に思っていたが、お金持ちで服にこだわりがある少数の独身女性が単価の高い買い物をするために赤字にならないのだろう。そのような客層は服はもう十分に持っており、服そのものよりも服を買う過程を楽しみ、消費している。このため品揃えの良さよりも、接客レベルの高さを求めて店を選ぶことになる。
※「太い顧客」という表現が一般的ではなかったため、少々無理に直してしまいました。「お店が刺さる」という言い方は、変ではないのでしょうか？
服を買うという行為の目的は服だけでは無い。オフィスワーカーは弁当が好きでコンビニで弁当買っている訳じゃ無いってことと同じだ。コンビニは、「少しでも長い昼休みの自由時間」「同僚との面倒な連れランチを断る口実」を弁当という形で500円のプライスタグ付けてオフィスワーカーに売っているのだ。モノじゃなくて、イミを売る時代とは、人口に膾炙した言葉だが、きちんとその意味合いを理解すれば、正しくビジネスチャンスを捉えられる。コンビニは、より安くより美味しいお弁当を作るのではなく、より長い昼休みを提供し、より判りやすいランチを断る口実を提供する為に、オフィスワーカー向けの定時デリバリーサービスでも始めた方が、ビジネスチャンスは拡がる事だろう。外食に行って戻る45分を、コンビニで買って戻る15分にしたい人は、それが気軽にデリバリーされて0分に出来るなら、もう500円余計に払ってくれるに違いない。身の回りで、愛妻弁当とか手作り弁当とか持ってきている人種は、本当に妻や料理を愛しているのだろうか、顔を思い出して考えてみよう。節約という人は居るだろう。でも、単に一人でランチを食べたいだけという人も結構居ないだろうか？そうだとしたら、そこに市場がある。
【脱臭後】服を買う行為の目的は服だけではない。会社員は弁当が好きでコンビニ弁当を買うわけではなく、昼休みに少しでも長く自由時間を得るためや、面倒な同僚とのランチを断る口実のために、500円払って弁当を買いに行くのである。よく、物ではなく意味を売る時代と言われるが、きちんとその意味合いを理解すればビジネスチャンスにもなりうる。コンビニは、より安くより美味しい弁当を作るだけでなく、上記のような理由で弁当を買いに来る会社員のために、定時の弁当配達を始めるべきである。外食に行って戻る時間をコンビニで節約したい人は、配達弁当でさらに時間を節約できるなら、500円の弁当でも1000円で買ってくれるに違いない。愛妻弁当や手作り弁当を持ってきている人も、多くは妻や料理を愛しているのでも、ただの節約でもなく、単に一人でランチを食べたいだけなのではないだろうか。そうだとしたら、そこに市場がある。
※平易な文に直してみると、「配達で500円弁当を1000円で売る」「弁当持参派の多くは一人で食事をしたいだけ」とは随分無茶な気がしてきました。また、「物ではなく意味を売る時代」という言葉と、この最後の段落は、実は無関係なようにも思えます。配達弁当を買う人は、弁当と同時に時間を買っているのではないでしょうか。
誰でも自分の臭いはわからないといいます。ニンニクも食べてしまえば臭くない。私の文章も、どなたかによって脱臭可能に違いありません。
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 が見つけた個別の発見や教訓があった。外部サービスにはおかしなところがいくつもあったけれど、君たちが考えるほどじゃあない。サービスに対して組織するってことは、外部のデベロッパを信用できないのと同じように、お互いを信用することなんてできないんだということを、チームに教えてくれたんだ。