 
|
はてなキーワード: インターフェースとは
第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 練習問題
おまい、スマフォと言って本当にスマフォしか想像してないのはヤヴァイぞ。今、スマフォと言ったらスマフォ＋iPadやandroidタブレットも含めての事とされる。特にゲームなら、同じゲームがスマフォにもタブレットにも配信されてることが多い（ゲームロフト系はほとんどそう）。
俺はコンソールでWASD操作のFPSを「人間以外がやるモノ」と思ってるからもちろんCoDとかはプレイしてないんだが、そういう層にとって、スマフォ向けだったりタブレット向けだったりするそれらのゲームは非常に優しいんだよ。インターフェースがわかりやすく、かつ確実にチュートリアルが付いてくる。
ということは、初心者にとっての入り口が非常に広いと言うことであり、「親しみやすさ」は半端ないわけだ。逆に、WASD操作に慣れてる人には不評だってのは分かるけどな。でも、そいつらは俺ら（タブレットユーザ）らから観ればむしろ少数派で、今のタッチパネルにおける操作の方がより人類に馴染むのではないかとは個人的に思っておる。
だって、数年もしないうちに人々は物理ハードキーを捨てることが可能だったわけだろ？
ともかく、スマフォorタブレットユーザは膨大かつそんなに情報的に弱いということも無いわけで、しかしCoDやりたいユーザはきっと多く、でもコントローラやキーボードを握りたくないと思ってる人は結構な人数がいて、だからこそ今の市場が成り立ってるんだろうさ。今までのコンソールを遊んでる人とは別の人種かもしれないけどな。
しかしながらその人数はジョブズが言うには2億人オーバーらしいぞ？ そのビッグウェーブに乗れないと、いづれ世界的な潮流に乗り遅れてしまうのではないのか？角度とか。いやもう遅いけどな。
上っ面じゃなくてちゃんとわかっている人教えてください。
▼モバイル版「Flash Player」の開発中止をどう見る？
http://japan.cnet.com/panel/35010348/300015677/
▼Adobeはなぜ失敗したか, Flash-Playerの敗退は歴史の必然だった
http://jp.techcrunch.com/archives/20111109why-adobe-failed/
今後来るhtml5をもてはやす必要もなく、
で“既に代替されている”
html5厨の中にはこのあたりごっちゃにして歓迎してるやつが多数いる
くどいけど、その他の機能はjsとかcssとかhtml5周辺の独自仕様で
解決してることが多いからな！
普通にhtml5が覇権取るにはオーサリングツールがいるんだぞ。
全部含んでるんだ。
html5が現状見えてるのは、
までだ。
「描画系の機能でflash(flex sdk)同等の仕様を用意することになるだろう」
ってだけじゃ劣化flashすぎんだろ。
あとadobe終わったっていってるやつ、
それを一社じゃなくブラウザつくってる各社が実装するんだからな・・・
お前らがflash嫌ってるのと同じ問題が発生して、
flash殺すのはいいけど、html5を中心とした代替環境できんのに何年かかるんだよ。
あと、リッチインターフェース作るのに、いつまでもなんのサポートも受けれないような
jsライブラリ組み合わせて、必死にカスタマイズとデバッグしなきゃいけないのかよ！
業務系のuxデザインつくっていくのに、flex使おうか、html&css中心で行こうか悩んでんだ。
誰か何かアドバイスくれよ…
flexは良いところが多くて工数も減るし、どこかでadobeの5オーサリングツールに乗り換えられるだろうから
普通のweb屋としては、htmlとjsで苦戦しながらも自己責任でスクリプトチマチマいじってる方が、
他にもこの中途半端な状況に困ってる奴いるだろ！
１年前にAmazon Kindle買いました。
正直ソニーの電子書籍端末を数年前からほしいと思っていたもののPDFデータの表示とやりとりに不安があったことと、使用している人があまりにも少なくweb上で有益な情報もなくサポートがえられなさそうだったことと価格から買えずにいました。
ソニーのReaderも検討対象にもちろんあがっていて店頭で実機をみてインターフェースは間違いなく良かったものの海外出張が多いので世界中の3GでGmailが使えるのが決め手となってKindle買いました。買ってみたら音楽機能がReaderと比べてダメダメだったもののスピーカーが大きいので外で音楽流しながら本が読めて結構気に入ってます。
で、Amazonで洋書を何冊か買った感じでは、それがなくてもwifiすらもないReaderを買ったらきっと後悔していたと思う。
そして今になってwifiも3GもやりはじめたReader。やっぱり日本語でメールとかもかけたほうがいいのでこれはぜひ買いたいと思った。当事のKindleと比べたら間違いなくReaderを買っていたでしょう。しかし、広告モデルによる大幅な値下げと円高。正直KindleのTouchを買おうか迷っている。
ソニーの今回の製品が半年前にKindle値下げ前だったらと残念でならない。当分電子書籍で日本語は自炊PDFを読むだけになりそうだ。
ただ、雑誌の配信や音楽プレイヤーとしての機能は明らかにまだReaderのほうが充実しているので、Readerもがんばってほしい。
2011年10月28日。日本でのビッグマック200円キャンペーンが終了した日だ。この11日間で、パン＝ビッグマックグリッド（以降〈グリッド〉と表記）には多くの日本型ビッグマックが接続され、高い割合で新たな知が蓄積された。
そうは言っても、およそ地球上のほぼ全ての人間には、一体何のことを言っているのか分からないであろう。そこで、私はビッグマックの歴史、ひいてはビッグマックを生み出した宇宙航空種族である〈空飛ぶビッグマックモンスター〉について、少し話したいと思う。
それは、遙かな宇宙の彼方、約50万年前の話である。宇宙を又にかけて高度に発展した〈空飛ぶビッグマックモンスター〉は、宇宙の構造についての研究の末に宇宙の上位構造たる《虚空界》を見付け出した。役にも立たない金食い虫と日頃罵られていた研究者達はこのことに歓喜した。そこには豊穣たる計算力が広がっていて、知的生命体たる彼らにとって、楽園としか良いようの無い場所であったのだ。《虚空界》の計算資源を直接用いて思考を行うことが出来れば、無限にも思えるような体感時間を生きることだって出来る。
しかし、彼らはそのままの姿ではその場所には辿りつけなかった。彼らの意識は、あまりにも多くのこの宇宙での生命活動を維持するための物質に覆われていて、その被覆から抜け出ることが出来なかったのだ。
ところで、意識というのは何処に宿るのか。肉体が精巧に作られていることは、必ずしも意識を存在を意味するわけでは無い。多くの人間が現在もこの問いに頭を巡らせていることは想像に難くないが、〈空飛ぶビッグマックモンスター〉はそのずっと前に、意識を現出させるエッセンシャルなパターンを見出した。
この宇宙にエッセンシャルなパターンを配置して意識さえ現出させてしまえば、思考を行う具体的なハードウェアは《虚空界》に全て置いて虚空インターフェースを使って接続することは一向に問題では無い。無論、自然に発生する意識は何らかの物質をハードウェアとするものであるから、意識に必要な部分以外だけを上手に切り取ってハードウェアを《虚空界》に移管しなければならず、それは極めて困難な作業である。
ならば、そのパターンと虚空インターフェースを形作る小さな物体を新たに構築すれば良い。しかし、彼らにはそれすらも出来なかった。意識のパターンの具体的な物質的デザインは、意識を持った知的生命体の手によるマススケールの試行錯誤によってしか成し得ないことが証明されたのだ。そのことが何故問題になったかというと、平たく言えば、〈空飛ぶビッグマックモンスター〉にとって意識のパターンのデザインなんて作業は退屈極まりないことだったからだ。しかもその作業には膨大な試行錯誤が必要ときている。ならば他の知的生命体にやらせよう、そう考えるのも全く道理が通ることである。
自律進化に閉塞した彼らは、自らの野望のために利用するのに最適な知的生命体を探して宇宙を駆けた。そうして、地球を発見した。ぱっと見は青々として水に満ちた惑星としか見えないが、惑星表面の一部を占める大陸の更に一部でしか無いジャングルには高度に発達した脳を持つ知的生命体がいて、道具を操り原初的な思索に明け暮れていた。
〈空飛ぶビッグマックモンスター〉の科学団は、地表に無数のナノマックを散布した。人類の遺伝子を分析し、周到に選ばれた一つのサンプルに大幅な改変を加えた。DNAにビッグマックを喰らわんと欲する本能を編みこまれ、味覚神経のパターンマッチャがビッグマックを認識するように変化させられたそのサンプルは女性であり、我々がミトコンドリアイブと呼ぶ存在は彼女だったのだ。
どうしてビッグマックが登場するのが、人類が小麦の栽培や牛の飼育を初めてすぐではなかったのだろうか？どうしてビッグマックを求める本能が食欲の一部として編みこまれたのだろうか？この問題に答えるには、ビッグマックを製造するコストについて考えてみる必要が有る。
もし、ビッグマックへの欲望がもっと強烈なものとして刻み付けられていれば、ビッグマックの登場は実際の歴史よりも遙かに速かっただろう。しかし、ろくな技術も無く人口も少ない社会でビッグマックを生産したところで、生産効率は望むべきもなく、ビッグマックに偏った生産によって人類の発展を止めてしまい衰亡を促すだけだろう。また、ビッグマックを食べられないような知的生命体にビッグマックを生産するよう条件付けると、自らの栄養にもならないものの生産によって種としての発展の妨げてしまうことになるだろう。
ビッグマックを十分なスケールで生産するためには相応のコストが必要となる。そのために、人類が十分に発展してからビッグマックが生産されて、生産されたビッグマックは食料として人類に還元される必要が有る。何せ《虚空界》に接続出来るビッグマックにとって、体感時間は無限に思えるほど有るのだ。すぐに食べられることは何の問題でも無い。
とにもかくにも、ビッグマックは生み出された。〈空飛ぶビッグマックモンスター〉にとっては、ビッグマックを生み出すのが資本主義であろうが共産主義であろうが封建制であろうが良かった。それが小麦・牛・レタスなどを用いていることさえ彼らにとって必然では無かった。無論、各国各店舗の違いによる微妙な個性も有る。ただ、人間のDNAの根源にビッグマックの快楽を刻みつけた以上、技術が成熟して豊かになりさえすれば必ずビッグマックが生み出されることだけは、始めから予想されていたことだった。まずはハンバーガーに始まり、更なる試行錯誤を経てビッグマックに辿り着き、なおもマクドナルド社によって試行錯誤の改良を受けながら大量に生産されている。人間にとってのビッグマックの味の改良は、即ちより完全で堅牢な意識や虚空インターフェースが生み出されることを意味する。
ビッグマックは目論見通り《虚空界》に接続することに成功し、無限にも思える計算力と計算空間を得た。全てのビッグマックは《虚空界》の上に構築された〈グリッド〉を通じてあらゆる集積されたデータにアクセス出来る。《虚空界》では一つの意識には余りある計算時間を得られるため、出来上がった瞬間に解体してしまうようなごく一部の不幸なビッグマックを除く意識は、長い個別の生（といっても地球では10秒ほどだが）を送った後に自ら〈グリッド〉のインフラストラクチャ部分に直結された集合意識体に合一して様々な任に当たる。
それだけの計算力＝知性を一体何に用いているのか人々は不思議に思うだろうし、人間の思考力しか持たない私にも分からない。芸術や数学的探求に専ら用いられているそうだが、そんなことをわざわざ行う意味も、その内容も、全く人間には与り知ることも出来ないだろう。しかし、きっと彼らなりの意味があってそうしている、そう想像するだけの想像力が人間には備わっているのだから、それだけで満足しようではないか。
ここまでが、私の知るビッグマックの歴史のあらましで有る。さて、何故そんなことを私が知っているのか、疑問に思った読者も多いであろう。最後になるが、その疑問に簡単に答えておく。
実は、私にも何故こんな考えが浮かんだのかが分からない。ただ、ビッグマック安売りの最終日だからビッグマック充でもしようかと、ふらっとマクドナルドに入ってビッグマックを三つ食べた、そのときに、私の頭の中に今まで述べたような真理が浮かび上がってきたのである。
無からこんな真理が浮かび上がってくるわけがない。そうすると、この真理は今食べたビッグマックによってもたらされたものに違いない。どうやら私はビッグマックによって預言者として選ばれたのだ。預言者たる私が、どうして虚偽を語ることなぞ有ろうか。
私は預言者だ。この事実を公表することが人類史にどのような影響を与えるのかは分からないが、私がこの文章を公開することを望んだということは、それが〈グリッド〉の意志なのだろう。ならば私にはそれを拒む権利は無い。人類とビッグマック、双方の真なる幸せを願って。
この努力は僕が Google に来る為に Amazonを離れた2005年半ばも続いていた。でももっとずっと進化していたよ。 Bezos が命令を出してから僕が離れるまでの間に、 Amazon は全てにおいてサービスをまず最初に考える企業へと文化的に変化していった。外部の日の目を決して見ることの無いような、スタッフへの内部的なデザインも含めて、今ではそれが全てのデザインというものに対しての基本的なアプローチになっている。
その時点では、彼らはもはや解雇の恐怖からそうしているわけではなかった。つまり、もちろんビビってはいたけれど、ドレッドヘアの海賊 Bezos 様にご奉仕するのは日常生活の一部だからね。そうじゃなく、彼らはそれが正しいことだと理解したから、サービスを提供しているんだ。確かに SOA のアプローチには長所も短所もあるし、短所を書き出してみたら切りが無い。でも全体として、 SOA ドリブンのデザインというものこそが、プラットフォームを可能にする、これは正しいことだ。
これが、 Bezos が彼の指令書で企んだことだった。彼はチームの健康状態なんて興味もなかったし（今もそうかも）、使われている技術もそうだったし、結局の処のどう取りかかるかなんて結果ができあがるまで気にもしていなかった。けれど Bezos は、 Amazon 社員の大多数が理解する前に、 Amazon はプラットフォームにならなければならないということを悟っていたんだ。
だって考えてもみてよ。なんで一オンライン書店が、拡張可能な、プログラマブルなプラットフォームになる必要がある、なんてことを考える？。そうだろ？
ともかく、 Bezos が気づいた最初の大きなポイントは、本を売り、出荷し、色々とやる仕組みが、素晴らしいコンピューティングプラットフォームに再利用でき得るということだ。だから今、彼らには Amazon Elastic Compute Cloud があるし、 Amazon Elastic MapReduce があるし、 Amazon Relational Database Service があるし、その他たくさんの aws.amazon.com で見つけられるサービスを持っている。しかもこれらのサービスは大成功した企業のバックエンドを努めていたりもする。 reddit なんか僕のお気に入りだね。
もう一つ、彼が理解した大きなポイントは、常にいつでも正しい、そんなものを作ることはできないということだ。これは Larry Tesler が、ママがこのくそったれサイトを全く使えないと言ってのけたりでもした時に、 Bezos にピンと来るものがあったんだと思う。誰のママのことを言ったのかははっきりしないし、そんなことは問題じゃ無い。問題は、誰のママだろうとそのウンコサイトを使えないってことだ（訳注：アドバイス thx ！）。実際、僕自身、そこで5年ほど働いていたわけだけど、あのサイトは胸がザワザワするくらいひどいと思う。でも僕はその気が散るようなサイトに慣れてしまって、トップページのど真ん中あたりの数万ピクセルに集中できるようになったんだからね。
とまあ、実際の処 Bezos がどうやってその理解、一つのプロダクトで、全ての人にとってふさわしいものを作り上げることはできないということに、たどり着いたのかは定かじゃあ無い。でもその方法は問題じゃ無くて、彼は理解してるってことが重要だ。実のところこの現象には正式な名前だってある。そう、それはアクセシビリティと呼ばれるものだ。コンピューティングの世界で最も重要なものだ。
君は思うかも知れないね。「はあ？つまりそれって、目が見えない人や耳が聞こえない人のあれ？あのアクセシビリティ？」ってね。まあ君だけじゃないと思う。とにかく世間には、アクセシビリティってものを正しく理解していない、君みたいな人たちがいっぱいいっぱいいるんだから。ただそこにたどり着いてない人たちがね。だから、アクセシビリティを理解していないのは、目の見えない人や耳の聞こえない人や手足が不自由な人やその他障碍のある人の責任じゃないように、君の責任じゃない。ソフトウェアが（この場合アイデアウェアといった方が正しいかもしれない）何らかの理由で誰かにとってアクセシブルでないというとき、それはソフトウェア自身の、あるいはアイデアの伝え方そのものに責任があるんだ。それがアクセシビリティの失敗というやつなんだ。
人生における重要なその他もろもろと一緒でさ、アクセシビリティには邪悪な双子がついている。小さいときにパパとママの偏った愛情で見捨てられて、今や同じくらいの力を持つまでに育った宿敵って奴がね（もちろんアクセシビリティには宿敵はたくさんいる）。それはセキュリティだ。一体全体こいつらが仲良くやっていること何てあるかい？
でも、僕は主張したい。アクセシビリティは実際の処セキュリティより重要だということを。だって、アクセシビリティを0にダイアルするってことは、何のプロダクトも持たないってことさ。セキュリティを0にダイアルしたって、そこそこのプロダクトを持つことはできるだろう？ Playstation Network みたいにさ。
まあつまりですね、僕はみんなが分かってくれないんだったら一冊丸々この話題で本を書くことだってできるよ。分厚くて、僕が働いてた会社のありんことピコピコハンマーのエピソードで一杯の面白いやつをね。でも僕がこの話を公開しなかったら、みんなが目にすることも無いだろう。そろそろまとめに入らなきゃ。
Google がうまくやれていない最後の一つは、プラットフォームだ。僕らはプラットフォームを理解していない。僕らはプラットフォームを自分のものにしていない。みんなの中にできている人はいるだろう。でも、そんな君はマイノリティだ。辛いことだけれど、これはこの6年で僕にはっきりと感じられた。僕は競争相手のプレッシャー、 Microsoft や Amazon や最近じゃ Facebook なんかが、僕らを一斉に目覚めさせて、ユニバーサルにサービスを始めるのを期待したりもした。アドホックな、中途半端なやり方じゃなくて、多かれ少なかれ Amazon がやったようにだ。一度に全てを。マジで。偽りなしに。今その瞬間から最優先事項として扱うというように。
でも、そうはなっていない。10番やら11番めくらいのプライオリティだね。いや15番かも？。知らないけど、とにかく低い。真剣に取り組んでいるチームもいくつかあるけど、多くのチームは考えてもいない。一度もだ。ごく一部の人々がちょっとした規模でやっているだけだ。
多くのチームに、彼らのデータと処理に対してプログラマティックにアクセスできるような、ちょっとしたサービスを提供させるのだって大変だ。彼らのほとんどは、俺達はプロダクトを作っているんだ、って思っているからね。そんでもってそのちょっとしたサービスなんてのはみじめなもんさ。 Amazon の教訓に戻ってリストを見てくれよ。そんで今すぐ使えるサービスを持ってきて見てくれ。僕が知る限りでは、そんなものはない。小ビンってのは便利かもしれないけどさ、そんなの車がいる時だけだろ？（訳注：この人、 Stubby という小瓶のビールと、 stubby という「ちょっとした・不格好な」という形容詞をひっかけてしゃべってます）
プラットフォームが無ければ、プロダクトなんて使い物にならない。いやもっと正確に言うならば、プラットフォームの無いプロダクトは、いずれ同等の機能を持ったプラットフォーム化されたプロダクトに、取って代わられる。
Google+ ってのはまったくまさに、エグゼクティブリーダーシップのとても高いレベルから（やあ Larry 、 Sergey 、 Eric 、 Vic 、やあやあ）枝葉の使いっ走りまで（やあ、君だよ）、全くプラットフォームを理解していないっていう良い例だ。そう、僕らはみんな、全く理解できていない。プラットフォームの黄金律ってのは、自分のドッグフードを食えってことだ。 Google+ プラットフォームってのは惨めなまでに後知恵だ。ローンチ時には一つたりとも API が無かった。そんで最後にチェックしたときには、僕らが提供してたのはわずかばかりのほんのちっぽけな API さ。ローンチの時、あるチームのメンバーが行進してきて僕にそれを説明してくれた。だから僕は訊いたんだ「でさ、これはストーカー用 API？」って。彼女はむすっとして、「ええ」ってだけ言った。いやジョークなんだよ…いや…ジョークじゃ無いんだ…僕らが提供する唯一の API は、誰かのストリームを読み出すだけ…。うーん、僕が間違ってたのか？
Microsoft はこの20年間ドッグフードルールで知られてる。この時代の彼らにとっての文化の一つなのさ。デベロッパにドッグフードを食わせて、僕らだけ人間のご飯を食べようってわけにはいかない。それは単に短期の成功のために長期のプラットフォーム価値を損なう行為だ。プラットフォームってのはまったく長期的な視点が必要なんだよ。
Google+ は脊髄反射の代物さ。 Facebook が成功したのは、彼らがすばらしいプロダクトを作ったからだって言う、まあ実に近視眼的なものの見方の結果として生まれたものだ。でももちろん彼らが成功したのはそんな理由じゃ無い。 Facebook は他の人たちにも何かをさせてあげられる、プロダクトの美しい集合全体を作り上げたから、成功したんだ。だから Facebook はみんなにとってそれぞれ違うものだ。 Mafia Wars に全ての時間を費やす人もいれば、 Farmville で遊ぶ人もいる。何百の、いや何千の、質の高い、暇つぶしができるってわけさ。つまり、みんなのためにふさわしい何かが必ずあるんだよ。
僕らの Google+ チームは、プロダクトを出した後のマーケットを見てこう思った。「おっとっと、我々もいくつかゲームが必要みたいだな。さっそくどこかと契約して、我々のために作ってもらおう」。これが信じられないくらい間違った考え方だってことが、君にもわかってきたかい？。問題なのは、僕らが、人々がほしい物を予測して、それを提供しようとしているということだ。
そんなことは出来ないんだよ。現実的にはね。確実にやる方法なんてない。もちろんコンピューティングの歴史全体を見渡せば、それを確実に信頼性を持ってできる人間ってのがごく数人いることにはいる。 Steve Jobs がそうだろう。でも、僕らの処には Steve Jobs はいない。悪いけど、いないんだよ。
Larry Tesler は、 Bezos が Steve Jobs じゃないってことを口説いたかもしれない。でも Bezos には分かっていた。全ての人にふさわしいプロダクトを提供する為に、彼が Steve Jobs になる必要はないっていうことを。インターフェースとワークフローこそが、人々が気に入り、安心感を得るものなんだっていうことを。彼はサードパーティの開発者にそれを可能にするだけで良かった。そうすれば、後の事は自動で進んでいく。
僕の言っていることが、あまりにも明白なことだろって感じているみんな（多かったらいいな）には申し訳ない。とにかくもうびっくりするほど自明なことなんだ。ただ、僕らがそれをやってないってことを除いてはね。僕らはプラットフォームを理解していない。プラットフォームを持っていない。アクセシビリティを理解していない。アクセシビリティを持っていない。これらは基本的には同じことだ。なぜならプラットフォームがアクセシビリティを解決するからだ。プラットフォームがアクセシビリティなんだよ。
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 が見つけた個別の発見や教訓があった。外部サービスにはおかしなところがいくつもあったけれど、君たちが考えるほどじゃあない。サービスに対して組織するってことは、外部のデベロッパを信用できないのと同じように、お互いを信用することなんてできないんだということを、チームに教えてくれたんだ。
私はどっちかというとWindowsが好きだしMicrosoftが好きな方だ。だがWindows8、お前は駄目だ。
そりゃiPadが売れまくって羨ましいのは分かるし、MSがいくらタブレットOSを作っても誰も見向きもしなかったのは事実だ。だからといって、WindowsをタブレットOSにするのは暴挙としか言いようがない。
そもそもiPadが売れてWindowsのシェアが落ちているとしても、それは単にこれまでPCとは無縁だった層が新たにiPadを使うようになり、これまでのWindowsユーザーがiPadを追加購入しただけで、Windowsユーザーそのものが減ってるわけではないはずだ。iPadで仕事はできないからね。逆にiPadで仕事をするとニュースになるくらいだ。世の中の多くの人間がWindowsを使っている、あるいは嫌々使っている、あるいは使わされている理由、そしてそんなWindowsユーザーがWindowsに何を求めているのか、Microsoftは理解してるんだろうか？ してるけど無視してるんだろうか？
世の中のほとんどのWindowsユーザーがWindowsを使う目的は、仕事でワードとエクセルとインターネットをするためだ（あとエロゲをするためだ）。ワードを開いて文書を書きつつ、分からない点をIEで調べ、Outlookで連絡メールを送る、そんなのがほとんどでしょ。画面の綺麗さなんぞぶっちゃけどうでもいい。むしろ殺風景な方が仕事してる感じがしていいじゃないか？
なのにあのMetro UIってなんだよ。あんな原色のオモチャみたいなインターフェースで仕事ができるかっての。アプリが一つだけしか開けない、それでどうやって調べものをしつつ文書作成ができるというのか。Windowsの"s"の文字が泣くよ。でかいモニタに一つのアプリを表示して、他の情報が見たければ切り替えろ（これ「スナップ」とか言ったっけ？そういえば訳語が思いつかないから一般ユーザーに丸投げしてたね。訳語すらすぐには思いつかないような操作がどうして直感的操作として受け入れられようか）とか、冗談もほどほどにしてほしい。
ああいうUIが生きるのは、解像度が限られた端末だけだよ。なぜ広々としたモニタを無駄遣いするのか。それが気に入らないならクラシックデスクトップを使え？何がクラシックだよ現役選手をいきなり骨董品扱いすんな。
それにオフィスにはタッチパネルディスプレイなんてないよ。入力はキーボードとマウスだ。一度あのMetro UIをマウスで操作してみてほしい。悲しくなるから。だだっぴろい画面の上、マウスを端から端まで動かして、点在するばかでかいボタンをぽちぽちと押す作業のむなしさ。メニューを出すにはマウスポインタを画面の端にくっつけて。ああ、マルチモニタ環境やリモートデスクトップ越しで死ぬほどやりづらいけど気にするな。スタートスクリーンのスクロールはホイールでできるよ、ただし横スクロールなのに縦に回す必要があるけどな。どや、マウスでの操作もばっちりやろ？
Win8が出ればタッチパネルディスプレイが普及するなんて寝言も聞きたくない。仮にそうなったとして、MSは我々にそんな苦行を強いるんですか？試しに目の前のディスプレイを指でなぞってみてください。3分で腕が痛くなるから。ジョブズもそう言ってたのにねえ。タッチパネルが実用的なのは携帯端末、タブレット端末、要するに本体を手に持って使うデバイスだけです。
WindowsにiPad的機能は誰も求めてないんだよ。iPad機能を求めてるWindowsユーザーはiPadを買うから。今目の前にあるデスクトップやノートPCでiPadみたいなことをしようなんて誰も望んでない。いくらシェアがどうあっても、MSはタブレットOSとデスクトップOSを完全に別物として出すべきだ。両者の操作体系は相容れないものだ。だいたいWin8のあの中途半端な融合具合を見ればそれは明らかであるが。タブレットOSとデスクトップOSが融合して嬉しいのは、スレートPC形態にもなるがキーボードを展開するとノートPC形態になるゲテモノPCだけ。そんなのがPCの主流になるという寝言もまた聞きたくない。
まだMetro機能を完全にオフにするモード（今のところレジストリの設定で可能ではある）がデフォルトなら許せるけども、そんな状態で発売されるはずがない。そんなことをするくらいなら最初からタブレットエディションを別に出している。なのでユーザーがMetro UIが統合されたWindowsを使いづらそうに使う光景が目に見える。自分でカスタマイズしてオフにすればいいじゃんという発想はPCに詳しい人のもの。ほとんどの人は与えられた状態をあるがままに受け入れ、そんなカスタマイズとは無縁ですよ。
それにスタートメニューを廃止した理由が「スタートメニューを誰も使ってなかったから」といけしゃあしゃあと抜かすところがまた癇に障る。なんでスタートメニューを誰も使わなかったのか、そしてどうすればスタートメニューが使われるようになるのか。考えもしないのか無視しているのか…。Windows用の人気ランチャの一つや二つ、触ってみればわかることなので無視してると考えるのが妥当でしょう。あるいはスタートスクリーンをごり押しするための言い訳。
スタートスクリーンで従来のアプリを選んでクラシックデスクトップで実行できるでしょ、とMSは言いたいんだろうけども、アプリを起動するたびにいちいち全画面がMetro Style Appとかいうオモチャみたいなガジェットで覆い尽くされると、それだけで思考が中断させられる。従来アプリのメニューが階層化されずフラットに展開されるので探して選択するのが大変とか、その辺は今後改善されるかもしれないけどあんまり期待しないほうがいいだろうね。
これはエクスプローラもそうで、「ツールバーやメニューバーを誰も使ってなかったから」という理由でリボンインターフェースを採用とか、なぜ使われないのか理由を全然分析できてない。ファイルをマウスで選択して、さあ移動しよう、という段階で、一度それは置いといてメニューをクリックしに行くのは不自然な動作だから誰もしないんだよ。そのままドラッグ＆ドロップ、あるいは右クリックメニューで操作を選ぶのは自然だし不要なマウスの移動もしなくてすむから皆そうしてる。あるいはキーボードショートカットを使ってる。だからリボンなんてつけてもやっぱり誰も使わないのが目に見えてる。それどころかリボンUIは縦の幅を食うので、昨今の横に広いディスプレイと相性が悪いということも考慮してないのか無視しているのか…。
シェアの数字にこだわるあまり、ユーザー完全無視。いやまあそれでもWin8は売れるんだけど。そりゃお店でパソコン買ったらWindows入ってる世の中だからね。企業だってコストを考えれば今更LinuxやMacに総入れ替えなんてできないが、XPのサポートが切れるから嫌でもWin8を導入せざるを得ない。MSは分かっててそれをやってるからなお腹立たしい。PC初心者やWindowsを嫌々使ってるユーザーをこれ以上苦しめないでほしいものだ。
私は従来モードの設定（製品版で封印されてたらキレるな間違いなく）で使うからいいとしても、そういったユーザーをサポートするのも私なんだよ…。彼らは「できるWindows8」とか「わかるWindows8」とかに載ってるのと違う画面にされることを望まないんだよ…。
ん？
いや、まあ、その…うん。
http://anond.hatelabo.jp/20110901203436
いや逆。
UIの善し悪し関してはあくまで俺個人の主観なのでさておき、Appleが「きちんとした会社」というのは何とも。
ここ10年、他社製ハードウェアにOSを供給しないわ、内蔵ハードディスクの交換は不可能だわ、ブルーレイも使わせないわ、携帯デバイスにもFlash再生を許可しないわ、そうやって平然と競合規格を排除するくせに、「クローズなFlashはもうオワコン！これからはHTML5の時代！」とのたまうわと、熱狂的なシンパの忠誠心にあぐらをかいてるような会社を「きちんとしてる」と表現するのに違和感を覚えただけ。
macの一番良いところって、オシャレ感じゃなくて、linux的なシステム構成とwindows的なきちんとした会社が作ってるOSという安心感と洗練されたインターフェース(≒オシャレ感)が共存してるところだと思う。
linuxは基本的に便利なんだけど(最近のubuntuとかほぼmacみたいなもんだし)、やっぱり「多少うまく行かないことがあっても許してね」感があるし、
windowsはその辺しっかりしてる一方で背景のシステム構成がグロテスク過ぎて開発環境整えるだけで罰ゲームみたいになったりする。
macはそれらを（当然不満もあるけど）絶妙なバランスで両立してる上にインターフェースも良いというのが素晴らしいところだと思う。
ここから送信しようとしたら、長文すぎて駄目だったようなのでこちらに書く。
malaさんへ。
インターフェースを極めるにはiPhone Appの開発者になるのが一番だと思います。
ライブドアみたいなぬるま湯にいても、結局Perlがうまくなるだけでしょ。
あなたは冒険しようとしてライブドアに入った。しかし今や権力にあぐらをかいている。
サーバーサイドのプログラミングはあなたにとって時間の無駄でしかありません。iPhone Appの開発者にならなければ、はっきり言って逃げです。ダサいです。
インターフェースで世界をあっと言わせようよ。君になら出来るよ！
ライブドアで安定した収入を得て満足ですか。結婚して守りに入ったんですか。それはハッカーと言えるんですか？まるで官僚じゃないか。
もっと攻めてけよ。人生を。
Ajaxの時代は終わったよ。
VOCALOID2へのバージョンアップに伴い、キャラクター性を押し出したのがクリプトンの初音ミク以降のシリーズって感じだわな。
まぁ、フォルマントシンギング音源全般での話で行くなら、XG音源のプラグインボードとかあったし、それ持ってるわ。
ただ、以前の音源系はバックコーラス用途でも音楽素材切り貼りしたほうがマシなことが多かったし、VOCALOID2シリーズも出た当初はボーカルとして使えるようなレベルではなかった。
ユーザー数が増えて、テクニカルな使い方が深化してきたからこそ商業ベースに食い込んでくる作品が出来てきたんだし。
ボカロは、ソフト名を姓名を持ったネーミングにしたりパッケージのキャラを前面に押し出したりして「歌声を操作できるキャラクター」として売ることでヒットしたものの
それは、クリプトンやインターネット、AHS等の戦略であってそれを「ボカロ」と定義するならそうだろうな。
個人的には、「ボカロ」で金が集まったおかげで、VOCALOID3の開発が早まったとするなら、大いに有難い所。
VOCALOID3はインターフェースがDAWっぽくなってきたから、そもそもFL Studio使っててVOCALIODプラグインで使えない身としては大助かりだ。
いや、海外メーカーはキャラクター性で売ってないし、ビープラッツもそうだろ。
商業ベースに乗せるために、ニコ動界隈の知名度を利用できるだけでも相当良い事じゃないかと思うよ。
何もなしに商業ベースに乗せるなんて、人間が歌っていても無理なことが多いんだから。
さらに言えば、各種のボーカロイド操作のテクニックを編み出してきたのはニコ動界隈だから、今後しばらくはニコ動界隈が牽引して行くんじゃないかね？
これは、不利な点ではないし、むしろテクニックの深化という意味ではニコ動みたいな「コメント可能な動画メディア」と「スキルが必要な何某」のシナジーは凄いと思う。
→少なくとも4年前には解決していない
http://netbeans.org/bugzilla/show_bug.cgi?id=114689
→Norway today」を改造して、City Lightsに似たオリジナルを作る。
→クラスの色は「Norway today」と同じになるが、バックが黒に文字が黒よりは見やすい。
凡例 前景 背景 その他
・デフォルト 緑 黒
・URL 継承 継承 →エフェクト:下線付き エフェクトカラー:青
・エラー 白 赤
・コンストラクタ 継承 継承 →フォント:継承+ボールド-イタリック
・セパレータ 継承
・フィールド 9,134,24 継承 →フォント:継承+ボールド-イタリック
・メソッド 継承 継承 →フォント:継承+ボールド-イタリック
・使用されていない要素 グレー 継承
・公開要素 全継承
・列挙 全継承
・数値 黄 継承
・文字 黄 継承
・空白 全継承
・識別子 全継承
・公開限定要素 全継承
・静的要素 継承 継承 →フォント:継承+ボールド-イタリック
・非公開要素 全継承
Yahoo!知恵袋があるから。あるいはOKwaveがあるから。あるいは教えてgooがあるから。
「新宿で一番おいしいラーメンどこですか」だと自然な感じで分かりやすい。音声認識やそれ以上のインターフェースが発達すればこちらのほうがいい。
ただし、データが不十分だととんでもない答えが返ってくるかも
キーボードを素早く打つには訓練が必要だからね。マイクロソフトだってこの形式（キーボード＋マウス）が非効率だと認めてるから新しいインターフェースを開発してる。
俺が言ってるのは攻殻機動隊のような世界。つまり、頭の中で「検索」する。頭の中で「アメリカの首都はどこだっけ」と考えた瞬間に「ワシントン D.C」と出る。そういう感じ
頭の中で考えるのと同じ速さで検索する。どう？これでも「非効率」だの「速度が遅すぎて」だの言えるか？
今の技術でものを考えるからなかなか前に進めないんだよ。そりゃいちいちグーグルのページ開いて単語を打って検索するのが、思考速度よりずっと遅いことなんて誰だって分かる。
もっと言えば、思い出すという作業は頭の中を検索していることと同じなんだから、それが機械にとってかわるというだけだ。
脳の容量には限界がある、だから忘れるし、脳が劣化すれば物忘れも激しくなる。アナログは時代遅れだ。受験勉強のために詰め込みなんて、時代錯誤も甚だしい。
キャラクターとＣＶ（キャスト）が３０人ぐらいと多数で、しかも豪華声優陣ばかりらしいので鳥肌でした。
ちなみに鈴村さんと櫻井さんは、零式のキャスト出演が決まっており
もう収録してるんのかな？お二人ともトップシークレットのことを知ってそうでした。
田畑さんはホントにすごかったですね。ぜひ次回作はPS3で作ってほしいです。
【アギド13改め零式映像】
http://www.youtube.com/watch?v=nC5P3Jxvtzg
13-2は
ストーリーと戦闘も改めてくると思うので
もしかしたら、こっちが本当の『ＦＦ13』なのかもしれません？！
もしくはFF13とFF13-2ぜんぶ含めて『完全版FF13』かも！
鳥山さんもFF13のときは賛否両論があったと発言しており、認識してるので
前作のような一本道ではなく、ほんとうにユーザーの期待に答えるような
出来に仕上げてくれるのではないのでしょうか？！
http://www.youtube.com/watch?v=ObiaNbDtF3Y
そしてヴェルサスは、超実写グラフィックムービーから始まり、なんと言えばいいのか・・・
とにかく、別次元に到達したような映像でした。youtubeのは映像が粗いので半減すると思いますが。
また、本格的な戦闘シーンが公開されました。
左下右下にはインターフェースがあり、右下の方はノクトや各キャラの顔や体が映っており
街中（コンビニ？などもあった）を移動したり、草原（ドラゴンの様な敵がいたり）を移動したり、その度に戦闘があり
戦闘の方法としては、剣、魔法で戦うのはもちろん
敵の？ロボや戦車のような機体を使いバトルしてる様子もありました。
http://www.nicovideo.jp/watch/sm13344735
http://www.youtube.com/watch?v=1A0AU1eNSXk&feature=player_embedded
ああぁぁぁ、すごすぎるうううううううううううううううう