 
|
はてなキーワード: セキュリティとは
http://togetter.com/li/254721を読んで、ブコメにまとめるには量が多いので、こっちにまとめる
「生活保護受給者に「社会権」を持たせる必要はない」とか普通に若者が言うしTwitter外でも言う人いますからね。私の周りにも・・・。このような「生活保護バッシング」の今を見てると生活保護を受けてる人の就労は極めて難しいと思うよ。逆にこの状況をみると即時就労する気もうせるのも納得。
そういえば、pukumaだかなんだか忘れたけど、どっかの研究員だかが同じような主張してたなあ
誰かが何かの権利を持っていないことを指して、権利を「与えられていない」と言うか、権利を「奪われている」と言うかでニュアンスがだいぶ違ってきますね。
「権利と義務はバーター」っていう言葉、まあ間違ってはいないけど、「社会権や生存権は納税、勤労、教育の義務とバーター」っていうと変だよね
私ね、思うんだけど、生活保護って労働制にしたらイイと思わない？ 1日自転車どれだけ片付けたとか、駅などの公衆の掃除とか。 病気で動けない人以外は参加させるって言うのかな。そしたらそこから社会復帰のキッカケになるかも。
これ自体はベーシックインカムあたりの落とし所のひとつにはなりそうだなあと思う。というのも、そういう制度を導入するにあたって、勤労の代わりになるものは何かさせないとたぶん反発する人は絶対に折れないから。
思い方の問題なので、その人間の生い立ちなどにも関係します。 そこから逃げて、痛い現実を受け入れられない甘えが思考にあるのです。
こういう思想って受験とか他のところでも散見されるよね。特にセンター試験を受けずに入ってきた人らに対しての見方は近いんじゃないかな。「俺たちはこんなに睡眠時間削って勉強して試験に臨んでいるのに、なんなんだあいつらは」みたいなね。ちなみに僕は部活して帰ってきてからの一時間ぐらいの勉強時間だけで旧帝入りました。でも今は親のすねかじりだけどね。甘え乙
というか、根性と気合がないと健常者にすらなれないジャパンマジジャップ。
真の健常な日本人ならB29見てから竹槍余裕でしたってことっすよ（16連射）
精神疾患は甘えって言ってる奴は会社で「なんであいつ休みなんだよ！何も進められないじゃねーか！」とリスク管理していない確率９０％
甘えって言ってなくても今の企業ってそんなもんじゃないかなあ 僕がバイトしてた小売は夕方バイト一人とかザラ。代わりいないよ。インフルエンザでも出勤しよう
差別されるのは「される側が悪い」論ですな。
いじめられるのは理由がある。レイプされるような服装してるからだ。万引きされるようなザルセキュリティなのが悪い（ぷんすか
その人は病院ですよね？
僕はウナギだ
ってのはあほらしいけど、「日光を浴びてビタミンDを生合成しましょう！」というと違和感がない。違和感はないが、こういう勝手にできるものを「しましょう！」だなんて言われても鼻くそほじりたくしかなりようがない。そういえばこの人福山雅治が「生活保護は甘えじゃない」って言ったら折れるのかなあ。ただイケ壁殴
いるよ。というか100％除菌できないのになんで売り物にしてるんだ！という意見さえあるよ。小売怖いよ。
Webシステムとは縁遠い事務職のリーマンが、ある日思い立って、ニッチな用途の検索エンジンサービスを作ってみたので、ちょっと書いてみようと思います。
ちなみに、検索エンジンといっても、googleカスタム検索とかのお茶濁し系じゃなくて、apache Solrというオープンソース検索エンジンを、VPS上で動かしているという、それなりに本
気度の高いものです。
なんで素人がそんな物騒なものを動かす羽目になったかは、後述。
やりたい構想みたいなことを思いついたのは、もう6、7年前ほど前のこと。初めて独り暮らしを始めたときに、ひどく不便を感じたことがあり、こんなサービスがあったら便利だなあ、
ちなみにその妄想をふと高校の同期に話したとき、そのサービスはどこにあるのか？！と、えらくがっつかれたのを、覚えてます。まあ、俺と同じく偏執狂の奴だったからだと思います
が。
ただ、しがない事務職リーマンということもあり、当然、技術も無く、そのときは、やるならこんな名前のサービス名だろうなあ、とか、そんな妄想レベルで、話は終わっていました。
そんな感じで、5年ほど月日は経ち、なんとなくリーマン人生の流れも見えてきたところで、以前、妄想していたことを、ふと思い出しました。
5年も経ったら、さすがに自分が考えたようなこと、誰かがやっているだろうと調べてみたところ、意外なことに、競合になるようなサービスは存在せず。ちょうど異動があって、少し時
間が出来たこともあり、じゃあ、着手してみようかと思い立ちました。
やりたいことは、大手サイトの情報検索。ただ、商品ページ内の特定情報、それも、商品ごとに正規化されていない表記を、正規化して抽出する必要があったので、大手サイトの既設API
だけではとても実現不可能でした。
まあ、だからこそ、5年間、誰もやろうとしなかったんでしょうが。
ということで、とても一発では解決できなさそうな内容だったので、自分でなんとか実現できそうな機能に細分化して、各個撃破していくことにしました。
随分と考えた結果、
以上に区分できると考えて、これらを各個撃破していくこととしました。
また、技術もなく、プログラミングも出来ず、ましてやlinuxサーバのお守りをしたことなんて当然ないので、インターネット上に置くサーバですべての処理を完結させるのではなく、イ
ンターネット上に置くリソースは最小限に留め、できる限り、勝手がわかる自宅のwindowsパソコンで処理を行うことにしました。
ちなみにさらっと結論だけ書いてますが、ここまで至るまでに、いろいろと調べ続たり、考え込んだりしていたので、思い立ってから3ヵ月は掛かってます。。。
さて、やる方針を決めたあと、はじめに着手したのは、要の検索エンジンサーバです。
いろいろとググって調べて、mySQLというやつか、apache Solrというやつかに絞りましたが、結局、Solrを使うことにしました。
MySQLのほうが実績は多そうだったのですが、Solrのほうが検索専門で、滅茶苦茶動作が速いらしいということ、MySQLでも出来るが特に速度が遅いらしい全文検索機能も使いたかったこ
と、あとファセット機能がジャンル絞りこみに便利に使えそうだったので、というのが理由です。
ちょうどSolr本が発売されていたこともあり、それを参考に、自分が使うように設定ファイルを変更していきました。
しかし、初めは設定ファイルの内容も意味不明な上に、私の書き方も雑なのか、少しいじっただけでまったく動かなくなる。結局、設定ファイルを一文字ずつ変更しては動作検証、とい
った始末で、進捗は地を這うよう。ある程度思い通りにSolrを扱えるようになるまで、3ヵ月以上掛かったでしょうか。。。
さらに、検索エンジンのフロントエンド（Solrの検索結果を、htmlに変換するプログラム）も書かなければならない。プログラミングが出来ない人間には、これが本当に辛かった。
Solr本に、いろんなプログラミング言語でサンプルがあったのですが、迷った末に、わずか数行なら書いた（≒コピペした）経験があるという理由で、javascriptを苦渋の選択。
しかし、選択はしてみたが、基礎が本当に無いから内容がサッパリ頭に入ってこない。こちらも、わかるところから本当に1文字ずつ変えていくといった手探り状態。
プログラミングについては、今回のためだけだから、といった理由で、一切基礎をやらずに着手したのが裏目に出たのか、サンプルのソースをモノにして、書き上げるのに、ゆうに半年
以上。本当に時間が掛かりました。
さらに、Solr周りで計9ヶ月間ハマっていた頃、忘れもしない、kanzen21のおっさんが彗星のように現れて、衝撃を受けることになります。
大手サイトのページをクロールして検索エンジンを作る手法は、私と考えていた構想の枠組みとまさに「完全に一致」な訳で。。。
図書館事件に注目していたのも同じで、あまりの一致具合に衝撃を受けっぱなしでした。
その後の成り行き等も含めて、興味深く観察させて頂き、本当に参考になりました。
そんな感じで紆余曲折もありましたが、ようやく難題だった、プログラミング関連に目処が立ってきたので、あとはクローラと肝心のデータ処理です。ここからは、勝手知ったるwindows
まず、クローラですが、専用のクローラをwindows用に探してきたり、それを設定するのも大変なので、今回はテレホーダイ時代に使っていたような、フリーのweb巡回ソフトを利用する
こととしました。指定のhtmlをダウンロードしてくるだけなので、別に変に新しいものに手を出す必要もないので。
また、ダウンロードしてきたhtmlファイルについては、これまたフリーの日本語処理ツールでcsv方式に加工することにして、処理ルール部分を相当に作り込みました。
このあたりは、全体を通して見てもキモの部分なんですが、ある意味、ちょっとしたパズル感覚だったので、プログラミング言語の部分と違って、かなり楽しかったです。
あとは、msdosのバッチファイル（これは前から知っていた）で、これらの処理を繋ぎ、cygwinのcurlとかいうツールで、連続して検索エンジンサーバにcsvファイルをアップロードする
仕組みを作りました。
検索エンジンサーバには、容量は少ないが、安くて高性能という、今回の用途にピッタリだった、さくらのVPSを借りて設定。CentOSのサーバ構築ホームページを見ながら、サーバとか
Solr管理URLとかにセキュリティを掛けて、こちらも素人ながら、意外とすんなり設定。
ホームページは、vpsサーバに相乗りさせるのではなく、別にさくらのレンタルサーバを借りました。apacheの設定方法等を習得する必要がありませんし、vpsのリソースをapacheと分け
合う必要が無くなるので。ホームページのhtmlファイル、cssファイル等も調べながら設定し、画像も準備しました。
あと、構想を思いついたときに妄想していたサービス名の.comドメインは、すでに他者に取得されていたのですが、どうも使っている風にも見えなかったので、whoisで出てきたメールア
ドレスに連絡して交渉し、幾ばくか払って買い取りました。
結局、足かけ18か月。ようやく完成。
楽天市場の家具を、幅x奥行x高さ(家具サイズ)で検索できる、楽天市場・家具カテゴリ専門の検索エンジン
この商品数規模（データ収録約30万アイテム）で、1センチ単位で家具のサイズ指定検索が可能な手段は、商用サービスも含めて、ほかには存在しないと思います。
kanzen21と違って、エロじゃないから華はないけどね。。。
ちなみに冒頭で少し書いたきっかけですが、就職して独り暮らしを開始したときに、新しい家にピッタリサイズの家具が欲しかったのですが、これが楽天で探すのは至難の技でして。
楽天で家具を探してみようと思った人には判っていただけると思うのですが、楽天では、価格では範囲指定やソートができても、サイズでは検索出来ないんです。
これは、楽天では、商品のサイズ情報は商品の自由記述欄に記載することになっているためで、商品ごとにサイズの記載方法がバラバラのため、検索が事実上、不能となっています。
家電製品とかに関しては、種類が少ないこともあり、メーカーのホームページとかでサイズを確認した上で、商品型番で検索すればいいので、それほど問題にはならないのですが、家具
って、種類が非常に多く、型番もあったり無かったりで、家電のようにサイズを調べることができません。
・・・ということで、カグサイズでは、楽天の商品ページにいろいろな書式で書かれているサイズ情報を拾って解析して正規化し、範囲指定やソートして検索ができるようにしています
。
また、単に寸法サイズを拾うだけでは、梱包サイズとか引き出し内寸とかも引っ掛かってしまうので、それらは出来るだけ排除して、商品の外寸が優先して引っ掛かるよう、アルゴリズ
ムを調整しています。
単位（センチとミリ）に関しても、商品ごとにバラバラ（単に単位だけでなく、商品説明のどこに"センチ"とか"ミリ"と記載しているかについてもバラバラです。）なので、サイズ表記
の前後の状況をみて、正しいと思われる単位で拾うようにしています。
あと、変わった使い方としては、欲しい家具の価格比較みたいなこともできます。
家具は、同じ商品でも、店ごとに型番が違ったりすることがよくあり、簡単には価格の比較が行いづらいジャンルの商品です。
しかし、型番は違っても、同じ商品なら原則、サイズは同じですから、欲しい商品とまったく同じサイズで検索をかけると、同等商品があるのかどうか比較しやすい・・・といった使い
方もできます。
と、そんな感じで、しがない事務職リーマンが作ってみた、ニッチな用途の検索webサービスを、サービスインさせて頂きました。
一般に公開されていて、誰でもアクセスできる情報でも、ニーズが有りそうな切り口の条件で検索性を高めれば、新しい価値を創造できるんじゃないかという実験です。
もしよろしければ、ぜひ、使ってみてくださいー。それでは！
----------
嫁に行くのも大変だが、婿に行くのはもっと大変だと思う。
紀宮さまと結婚した黒田さん（黒田さんは婿入りじゃないけど）はすごい。
もう立ち食いそば食べたり、コンビニで肉まん頬張ったりできないと思う。
少なくとも窓口業務はさせたくないでしょ。
あんまり偉くさせるわけにもいかないし、かといって下っ端にいられても困るし。
出来ることなら言葉を発してもらいたくもないな。
ふとした拍子に東電や鳩山菅をdisったりされたらどうしようって思うもん。
適当な名ばかりのポストを与えられて、どうでもいい仕事をたった一人で淡々とこなして、定時まで時間を潰したりって感じじゃないだろうか。
イメージとしては、一人で資料室にこもって資料整理を任されてる人みたいな、ほぼ辞めさせたい人に対する仕打ちのようなのを想像してるんだけど。
私生活で発散させりゃいいんだろうけど、俗な遊びは難しいだろうし、かといって目立った贅沢もできないだろ？
お金の使い道と言ったらセキュリティとプライバシー対策ばかりで、ちっともエンジョイできない人生。
食べ物も洋服も趣味の物も、セキュリティとプライバシー対策がしっかりした店でしか買えないんじゃないの？
本人はユニクロだとか紳士服の青山でいいと思っていても、いろいろ考えると結局は皇室御用達の仕立屋でしか買い物できないとかさ。
最近は、女性向けの同人活動ということで、pixivをメインとした活動もされるようになった。pixivのランキングで女性向けのイラストが入っていたり、一部の方が大衆の不快にしてしまう行為をしてしまうけれど、女性向け同人として、pixivは同人活動においてなくてはならないものとなっている。pixivでの活動自体は、2年前ぐらいからはあったが、現在、さまざまなジャンルのアンソロジーの企画ページを見ると、参加者の一覧での参加者ページのリンクがpixivだけになっていることが多い。もう、同人活動のメインとして、pixivがメインなのだ。
実際、pixivはあくまでもSNSサイトであって、ホスティングサービスでないのは事実。Facebookを市のサイトとして全面移行しようとした佐賀県武雄市と同様に、腐女子がpixivを作品を展示できるホスティングサービスと勘違いしているのも事実。
もし、pixivがなくなったらどうなるんだろうか。一からHTMLを学んで、レンタルサーバーを借りて、ホームページを作ったり、FC2ブログで似非サイトを作ったりするんだろうか。
私自身、pixivは、信用できない企業だと思っている。画像データがIDCフロンティアのデータセンターから配信されているのはいいのだけれども、メインシステムがpixivのオフィス、つまり、データセンター向けでない普通のビルにあるらしい。何かpixivオフィスであれば、サービス停止ということもあり得るし、セキュリティ的にもよろしくない。pixivブログのサービスもそのうち停止してしまうらしいし、需要があるのかわからない「ショーケース機能」（有料で一定タグを宣伝できる）をリリースしたみたい。
これらから、pixivはWebサービス提供者として信用できない企業だと思う。ホスティングサービスとしてのpixivに期待する腐女子もあれだが。しかし、pixivには安定した運営と、利用者の声を反映した運営をお願いしたい。というか、現在のpixiv運営だと、コラージュ騒動のときと同様に、何かあったときにうまく収めることができるのかわからない。
第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 練習問題
ほとんどの理由は「事前に準備しとけ」で終了する内容だな。
あとは面接官や企業の好みに関わるところだから、どうでもいい感じ。
正直な話、ここに書いてあるようなスマホをちょちょいと使ったくらいで通る面接なら、スマホなくても通るだろ。
一般的に、会社の方針でスマホをシステムとして導入してるなら、会社が支給する。
そうでないと、システムのセキュリティ上問題が出たりするからな。
製造番号やら、端末ＩＤやらキッチリ控えて、アクセス制限するのが一般的。
過去数日間にわたって放出の3つのレポートは、GoogleのAndroid OSは、現在のマルウェアの主要な標的であることを主張して...あなたが心配ですか？
http://www.bcpowerbattery.co.uk/bc-sony-digital-camera-battery.htm
だから、解決策は何ですか？私は3つの可能な解決策を参照してください。
GoogleはAndroidマーケットをクリーンアップし、ユーザに安全なもの（これは、マルウェアが寄生かもしれない"別の"マーケットプレースからユーザーを保護することはありません）
他の会社が介入し、彼ら自身からユーザーを保護するソフトウェアを提供
http://www.iibattery.com/nikon-digital-camera-battery-iigl.html
Windows 7 - Firefox 8.0 - Norton Internet Security(NIS) 2011 の場合。
（xはバージョン番号）
1. NIS - 設定 - その他の設定 - 製品セキュリティ で「Norton製品の改変対策」を「OFF」にする。
2. C:\ProgramData\Norton\{0C55C096-0F1D-4F28-AAA2-85EF591126E7}\NIS_xx.x.x.x\
・coFFPlgn_xxxx_x_x_x → coFFPlgn_xxxx_x_x_xOLD
・IPSFFPlgn → IPSFFPlgnOLD
※WindowsXPでは C:\Documents and Settings\All Users\Application Data\Norton\{0C55C096-0F1D-4F28-AAA2-85EF591126E7}\NIS_xx.x.x.x\ (未確認)
元に戻したい時は、リネームしたフォルダを戻して「Norton製品の改変対策」を「ON」にする。
なお、OSを再起動するとフォルダが強制的に作成されるようなので、その都度2.の実施が必要。
C:\Program Files\Mozilla Firefox\extensions\
セキュリティ専門家がPSNに対して怒っているのはネカマがバレたから？
http://blog.esuteru.com/archives/5310454.html
【Vita終了のお知らせ】 情報セキュリティ専門家「PSVitaにPlaceEngineを載せたら、集団訴訟のターゲットになる」
http://jin115.com/archives/51825887.html
【ゲハ脳の恐怖】 セキュリティ専門家の高木先生ブチギレ 「ふざけるな糞野郎。どこのライターか名乗れよ」
http://jin115.com/archives/51826098.html
SCE、PSNの利用規約を改訂 ＆ トロフィー情報等の公開の可否をユーザーに選択させる仕組みを検討
http://jin115.com/archives/51826170.html
トロフィー情報問題でPSNの利用規約が改訂！ゲームプレイに関係した情報の開示可否も検討
http://blog.esuteru.com/archives/5366930.html
-------------------
リアル雑談で高木先生の話題を振って「ああ、ネカマのｗｗ」という反応を示す輩がいたら、そういう輩とは距離を置いた方が幸せになれる。
2.2や2.3の更新は専らパフォーマンス向上なので更新されなくて困るというのはどちらかというと利用者視点だなぁ。APIも追加されてるけどこれがないと困るってものは正直無い。もちろん旧版据え置きのものはセキュリティFixのバックポートだけはちゃんとやって貰わないと困るけどね。
開発者視点で言えばAndroidはバージョンごとの互換性がかなり良好なので1.6か2.1をターゲットにしていればまず平気。2.2サポートとかいちいち考えてる人いないと思うよ。2.1ターゲットで作れば動くし。むしろ問題児は3.xで、その流れをくむ4.xも不安の種。
1.6～2.3まではほぼ完璧な上位互換だったのでメーカーもさほど気にせず追従してこれたのだけど、2.3→4.0は構造が大幅に変わっており互換性を保つための機構もあるにはあるがアップデートすると動作がおかしくなるアプリはそこそこ出ると思われる。これは「アップデートしたらアプリが動かなくなったぞ」というクレームに繋がるので、特に日本のメーカーは嫌がる。
断絶感で言うと、1.6がWindows2000、2.1～2.3まではWindowsXPと各サービスパック、3.xがVista、4.0がWindows7、ってイメージして貰うといい。
iOSはiPhone/Touch/iPadだけで下手するとAndroid以上に互換対応が面倒だったりするしメジャーバージョンごとに壮絶な互換性破壊が起こっているんだけど、一斉アップデートなので旧版の一斉切り捨てが可能という点はやはりアドバンテージ。これまではiTunesからしかアップデートできないせいでアップデートしないユーザも考慮が必要だったけど、今後はOTA配信になるのでそれすら気にしなくて良くなった。
逆に4.2に放置されたユーザは今後AppStoreで4.2対応アプリを手に入れることすら困難になっていって涙目だとは思うけど、開発者視点からすればAppleが切り捨てたバージョンは切り捨てて良い(というか切り捨てるしかない)のでやっぱ考え方として楽。
affected そういうシステム
● 動いているネットワークには触るな。
● 配線図を信用するな。
● 特権権限のパスワードが「password」の機器は誰もログインしていない。
● 冗長構成は動かない。
● 機器触っている時に「あっ。」って言う人は信用するな。
● しばらくアラームが来ない場合、何らかの問題が起きている。
● ググれ。
● 再起動は命がけでやれ。
● バックアップは戻らない。
● 素人は素直に申し出ろ。
● 手順書も読めない
● 手順書は読めるが作れない
● 手順書がないと作業できない
● だいたい手順書が間違っている
● 早業で障害対応したのに怒られる
● 飲み会の日は夕方障害発生
● コンフィグを保存し忘れる
● デフォルトオリジネートは消える
● 堅い名前をつけても誰も呼ばない
● MUAにこだわる
● キーボードにこだわる
● OSにこだわる
● そのスイッチのせいでSTP走って混乱
● 攻撃だそれフィルタと安易に言う奴が多い
● それはだいたい管理職
● 攻撃されている顧客には連絡が取れない
● DNSのことは知らない
● 経路交換は政治だ
● 落雷に敏感だ
● 生き字引みたいな人が居る
● その人のデスクはだいたい汚い
● 椅子の座り方をしらない
● 椅子を並べて寝るのが上手い
● ラックの間で昼寝する
● 光ケーブルの受光は目で確認しちゃう
● DC電源が怖い という話が怖い
● 低レイヤの事は以外としらない
● ケーブルは埋め殺す
● 埋め殺されたケーブルが多くてケーブル撤去できないのでそのケーブルも埋め殺す
バージョン2.1.8で実装された「reflected script inclusionに対する保護」機能で上記エラーが出る場合
about:config の
noscript.xss.checkInclusions を false に変えるか
noscript.xss.checkInclusions.exceptions に許可したいドメインを入力する
セキュリティ対策めんどくさい
って、言ってる人。
正当な目的の影で不正な用途に個人情報の利用などを行っているケースについては判別不能だと思うんです。
今回のDolphinのようなアプリをAppleが審査していたらrejectできていたか？
できていないと思います。
もしAppleの審査スタッフがセキュリティ研究者だったとしても、同様の漏れは大量に出るでしょう。
「Appleの審査はセキュリティ確保のためである」というのは勝手な思い込みです。
Androidの(特有といっていい)問題というのは、
・検索ノイズとなるアプリ(アイコン変わっただけ、プロダクト名変わっただけ)が大量にあること
・それを利用して悪意のあるアプリを低コストで大量生産し、紛れ込ませることが容易に可能
このあたりだと思います。
つまり、変なものに手を出さなければ、他プラットフォームと同程度の危険度になると考えます。
審査有になった場合のデメリットはメリットよりも大きいと私は考えています。
無料でリモートワイプとロックができるアプリを探す（Android）
（セーフサーチオフ：15件、弱：15件、中：13件、強：6件）
（セーフサーチオフ：59件、弱：56件、中：55件、強：9件）
https://market.android.com/search?q=wipe+and+lock&c=apps&price=1&safe=2&sort=0&so=1
https://market.android.com/search?q=%E7%B4%9B%E5%A4%B1&c=apps&price=1&safe=1&sort=0&so=1
https://market.android.com/search?q=Anti-Theft&c=apps&price=1&safe=2&sort=0&so=1
（ユーザーレビューが1,000以上の上位は、「wipe and lock」の結果に含まれる）
http://www.f-secure.com/ja/web/home_jp/protection/anti-theft-for-mobile/download-free
AVG, F-Secure, Android Lost, Bitdefender Mobile Security, DroidDream Cleaner, Phone Locator, ESET Mobile Security
米袋騒動の件に対するJAくまもとからの抗議文に対するブクマページ。
http://b.hatena.ne.jp/entry/www.ja-kumamoto.or.jp/news/topics/2011/10/1430
＞買う方は×なんて見ねぇw
＞そもそも福島になんでJA天草の袋が有ったり、売っていたりするのか。
自前の袋に詰めた米は流通させるなと？もしくは流通した袋は全部自分たちで回収しろと？
バカの提案が実現したら米の値段はねあがるな。
＞農家の当たり前は一般人の当たり前じゃないことを知ってほしい
なぜ（素人の画像だけ見て脊髄反射しかできない）あなたに配慮する必要があるの？
＞せめて県外には流通させない措置取るとか出来ない？
店頭に並んでるような10kg詰の袋で農家から出荷されてると思ってるんだろうか。
東京に住んでたら米食えなくなるな。
あげてったらキリないけど、なんで自分が素人だとわかっていながら意見を垂れ流せるんだろう。
ジャンルは違うけどAndroidのスパイウェア騒動だったりつい最近HOTになってるdocomoのIMEI垂れ流し
問題だったりとかいうプライバシーやセキュリティ周りで無知に基づく寝ぼけた意見を
twitterで垂れ流したりするとひろみちゅ先生からのRTの後にフルボッコにされたりします。
今年冬以降に発売されるandroid端末のメディアプレイヤーはHTTPヘッダのUser-Agentおよび拡張ヘッダにIMEI番号が含まれるということが分かり、騒動となった。
カレログ、applogに続きNTTドコモが参戦？ - http://togetter.com/li/202490
NTT docomo IMEI垂れ流し問題 http://togetter.com/li/202536
http://www.nttdocomo.co.jp/service/developer/smart_phone/service_lineup/music_movie/index.html
（魚拓）http://megalodon.jp/2011-1019-1834-56/www.nttdocomo.co.jp/service/developer/smart_phone/service_lineup/music_movie/index.html
こう記述されている。
Android端末の一部機種では、音楽・動画コンテンツを再生するためのメディアプレイヤーをドコモがプリインストールします。
メディアプレイヤーがプリインストールされる機種は2011年度下期モデル以降の主なAndroid端末となります。
ユーザエージェント
メディアプレイヤーがHTTP通信を行う際のUser-Agentヘッダは以下となります。
User-Agent:＜SP＞DOCOMO/2.0＜SP＞[AAA](MP;[BBB];Android;[CCC];[DDD]);imei:[xxxxxxxxxxxxxxx];networkoperator:[yyyzz]＜CR＞＜LF＞
＜SP＞：半角スペース
[]以外は固定値
AAA：機種名
xxxxxxxxxxxxxxx[15桁]：IMEI
yyy[3桁]：Mobile Country Code
HTTP通信時の拡張ヘッダ付加情報
メディアプレイヤーがHTTP通信を行う際は、以下の拡張ヘッダが付与されます。
x-dcmstore-imei:＜SP＞ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ＜CR＞＜LF＞
＜SP＞：半角スペース
xxxxxxxxxxxxxxx[15桁]：IMEI
ケータイ用語の基礎知識http://k-tai.impress.co.jp/cda/article/keyword/43518.html
によれば、
とある。
端末に固有の番号であるという認識でよいだろう。パソコンで言うMACアドレスのようなものだ。
重複する部分もあるが、いくつかの問題が含まれているように思える。
twitterで見られた反応をいくつか整理してみた。
これが最も大きい問題。twitterでIMEIってつぶやいている人の大半はこれを問題視している。
IMEI番号をそのまま送信している。
すなわち、コンテンツプロバイダ(CP)Aにも、CP-Bにも同じ番号が送信されている。
CP-AとCP-BでIMEI番号を突き合せて、収集した情報をリンクさせることができてしまう。
IMEI番号は端末に紐付けられている。
したがって端末を買い替えない限り番号は変わらない。
これが問題。
10年以上前から同じことが繰り返されているため、空間的時間的に広い共通IDを使うことの「何が問題か」知りたいなら過去の事例を参照するとよい。
等
高木浩光氏による行動トラッキングの歴史と境界線についての備忘録 http://togetter.com/li/197732
インターネットにおけるIDとトレーサビリティ(2003年)高木浩光氏 http://www.nic.ad.jp/ja/materials/iw/2003/main/ipmeeting/panel-takagi.pdf
Tracking Cookie - Symantec http://www.symantec.com/ja/jp/security_response/writeup.jsp?docid=2006-080217-3524-99
まだIMEI送信機能付きandroid端末が発売されていないので、どういう実装か不明のため、これは想像上の懸念だ。
このIMEI番号送信機能は、おそらくDRMに利用することが目的の一つだろう。
特定の機種でのみ購入した音楽が再生できる機能が組み込まれている可能性がある。
その場合、機種変更をするとIMEI番号が変わるために購入したコンテンツを利用できなくなる可能性がある。
あるいは一人で二台以上の端末を所有する場合、どちらか一方の端末でしかコンテンツが利用できない可能性もある。
実際、iPhoneにおいて似た事例が発生していた。認証にUDID（端末固有ID）を用いていたアプリが機種変更ののちに使えなくなる事例があった。
また、それまで利用していた端末をオークション等で販売する可能性もある。
その場合、端末の新しい所有者が、古い所有者の購入したコンテンツを利用できてしまう可能性もある。
ただしこれらは想像上の懸念だ。
UserAgentまたは拡張ヘッダに記述されたIMEI番号をもとに認証を行うサイトの出現が懸念される。
参考：かんたんログインの事例 http://www.atmarkit.co.jp/fsecurity/rensai/keitaiweb02/keitaiweb01.html
そもそもIMEI番号の取得はかんたんだ。
友達が不用意にその辺に放置した端末で「*#06#」と入力すれば取得できてしまう。
送信される番号はどのサイトに対しても共通なので、他のサイトで使うことができる。
そしてなりすましも容易だ。
とか。
ぼくよくわかんない＞＜
プライバシに関する専門家でもないので、補足訂正おねがいしまーす。
あと、この問題を扱うに当たって、何を「個人情報」だとするのかとらえ方が人によって違うことに注意したほうが余計な労力を使わなくて済む、と思いまーす。
この努力は僕が 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 になる必要はないっていうことを。インターフェースとワークフローこそが、人々が気に入り、安心感を得るものなんだっていうことを。彼はサードパーティの開発者にそれを可能にするだけで良かった。そうすれば、後の事は自動で進んでいく。
僕の言っていることが、あまりにも明白なことだろって感じているみんな（多かったらいいな）には申し訳ない。とにかくもうびっくりするほど自明なことなんだ。ただ、僕らがそれをやってないってことを除いてはね。僕らはプラットフォームを理解していない。プラットフォームを持っていない。アクセシビリティを理解していない。アクセシビリティを持っていない。これらは基本的には同じことだ。なぜならプラットフォームがアクセシビリティを解決するからだ。プラットフォームがアクセシビリティなんだよ。