  |
はてなキーワード: ストリームとは
処理系は次の要素から成る: 南山まさかずプログラム、インストラクションポインタ（プログラム中のある文字を指す）、少なくとも30000個の要素を持つバイトの配列（各要素はゼロで初期化される）、データポインタ（前述の配列のどれかの要素を指す。最も左の要素を指すよう初期化される）、入力と出力の2つのバイトストリーム。
南山まさかずプログラムは、以下の8個の実行可能な命令から成る（他の文字は無視され、読み飛ばされる）。
Hello, World!を出力するコードは以下のとおりである。
ままままままままま愛南まままままままま南ままままままままままま南ままままま山山山さ死南か南ままかまままままままかかまままか南さか ささささささささささささか山ままままままままかささささささささかまままかささささささかささささささささか南ま
元増田だ。
実は最近のトレーラーハウスがかなり進歩してきているみたいなんだ。
greenz.jpやスモールハウスムーブメントで検索してみれば分かる。
エアストリームも実はかなり好きだが、丸い屋根だと閉塞感がありそうなので、平行四辺形みたいな形したやつが好きだ。
神奈川県の鎌倉か千葉県あたりに置けば、あのあたりはそこそこインフラも整ってるし物価も安いしで何とかやっていけるんじゃないかと睨んでる。
オレはプラント屋なので、電気も配管もばっちこいだ。太陽光パネルも置く予定だ。小型ボイラーの設計も考えている。
ある程度知識が出来たら、ＩＴ屋に鞍替えして種銭作れないか、とか思ってワクワクしてる。ワクワクしてるだけだが。。。
一番なのは固定資産税がかからないことや、維持費の関係だ。現代は家を持つことが消費になっている。
あと二十年くらいしたら中古ハウスの流通市場が熟しはじめているころだと思うので、トレーラーハウスも安くなるはず。
会社の社宅をどうしても出なきゃいけなくなるときがきたら、転職して別の寮付の会社にいくか
あせって家買ったり馬鹿高い家賃を払うよりもトレーラーハウスをオレは選択する。
ただし、風呂問題をどう解決するかが目下の悩みだ。プロパンはやはり高いからな。。。接続式ガス管ソケットを自前で開発して特許申請取りたいなとか妄想してる。
まあ、気にせずフォークして公開したら？
あと、bitbucketならプライベートリポジトリ作れるし、気が変わったら公開したい程度もののはそっちにおいておくのも手かもよ
インターネットが拡張した概念と電子によって構成されたバーチャルと
ネットだって人間によって構成されたリアルだと言う人はいるかもしれない。
でも、あの時は違った。
バーチャルのケーブルの先に繋がった人間もまたバーチャルだった。
この感じを説明するのは難しい。
今のようにストリームが思考を運ばなかった時代。僕らのやりとする情報は、いつも痕跡だった。
物語の登場人物達が現実にいないことが当たり前なように、リアルとバーチャルは分断されてることが当たり前だった。
リアルな人間もいた。彼らは既成概念に縛れることを望みダサかった。
一部のダサい人間の愚行だと思っていたが、インターネットはそれを許さなかった。
ある時なんてあったのだろうか、気が付けばネットはリアルの拡張現実でしか無かった。
僕が幻滅した既成概念にとらわれたダサいリアル達に、インターネットの世界は埋め尽くされた。
それどころか、バーチャルの幻想で醜く拡張された醜悪な臭いをまき散らすリアルだらけになった。
そんな醜悪になったインターネットでも、常に対流しないと吐き気がするストリームの中にでも、バーチャル時代の名残はあった。
それを辿ると、あの時の幻想の残滓がみつかる。そして懐かしくなる。幻想はまだあるだと信じたくなる。
でも、そこれこそ幻想だった。別にアナルセックスだからじゃない。
かつて電子の妖精と呼ばれたそれは、タンブラーで尻画像を収集するマシンとなりながらも、幻想のアーカイブになると信じていた。
だが、違っていた。それは尻画像じゃなかった。画像にはうつらないケツの穴だった。
そのケツの穴はブラックホールのように僕らの幻想を飲み込んでいた。
それでもブラックホールは座標となるだろう。
最近、ネット上のあらゆる所で起こっているアンチアフィリエイト活動、彼らの言動そのままを記すこととする。
「アフィリエイターは寄生虫、ヤクザ、ネットの癌です！ 早く死んでくれたまえ！」
「いつまで邪魔な広告を貼るつもりだよ？ アフィつけるなら閉鎖させてやろうか？」
聞くに堪えないこれらの罵詈雑言は一般サイトの管理人に絶え間なく聞こえてくる言葉である。
本来、有料サービスでないサイトで金銭や個人情報を要求していないにも関わらず、
彼らはサイトに広告が掲載されているだけで『被害者意識』が強く生まれてしまうという。
その表情は興奮に満ちていた──。嫌儲(アフィリエイトを嫌う人達の俗称)のオフ会で取材をしてみると、
自分たちの行動原理は、彼らの弁でいえば“正しいインターネット上”。嫌儲民と自称し、インターネット
で仲間を集めて日々、アフィリエイトをつけているサイトと戦っているという。
どういった素性の人たちなのか。詳しいジャーナリストがいう。
「当初は貧しくて仕事がない若者が中心でしたが、最近では普通のサラリーマンや公務員、主婦、中学生から高齢者までと幅広い層が
参加しているようです。彼らはみな自分たちは“被害者”だという共通認識を持っています。アフィリエイターは不労所得が月に何百万もあり、
彼らにステルスマーケティングなど流行やネットストリームを牛耳られており、今のネットはアフィリエイターに支配されているといった情報を
インターネット上で入手して、それが真実だと思い込んでいる。その“奪われたネット”を取り戻すために正義の活動をしていると信じているのです」
嫌儲民には自分たちが情報やサービスを享受しているという意識はない。
むしろ“自分たちが欲しいモノは誰かが無料で奉仕してくれるのが当然”と思い込んでいるのだという。
.
全ての求人が、必須条件として「JavaまたはPHPでの開発経験があること」の求人で、
ほぼ同じ求人内容に応募していることになる。提出している書類も同じ。
株式会社Ｇｎｚｏ
株式会社Aiming
株式会社FFRI
まあ、理不尽な理由ばかりで、人を選り好みしている上記の会社は「人手不足」って言葉は絶対使うなよ。
特に、サイボウズ株式会社の「スキルは申し分無いけど、転職回数が多すぎるからうちではお断り」という仕打ちは
一生恨んでやる。
株式会社f4samurai
株式会社CyberX
特に株式会社コロプラは圧迫面接を受けた、「なぜ、あなたのくらいの評価する実績の無い人が我が社を応募したのですか？」「なぜもっと実績を作ってから我が社を応募しなかったのですか？」「なんで、あなたは我が社の面接を受けているのですか？」って相手を完全に侮辱している態度をよく出来るなと関心してしまう。二度とお前の会社のアプリは使わない。
全社とも不合格理由が「スキル不足」。面接の時にはスキルに関してはなにも指摘されなかった上に、一次面接ではスキルの筆記試験や確認があったのに、
「スキル不足」だとさ。一次面接官が見落としていたのかそれともバカなのか、そもそもスキルに関しては応募書類に事実全てを記載しているので、書類選考で落とせよ。
まだまだ書きたいことはたくさんあるけど、会社名を晒してやる。
みなさんが、２ちゃんねるを今でも見るのはなぜでしょうか。
みなさんが、ニコニコ動画から一歩引いたのは何時ごろでしょうか。
ソーシャルサービスの先駆けであり、最も世界で何度も終わったと言われたサイトですが終わりません。
以前より終わった感がありますがmixiより終わっていません。
２ちゃんねるを観測していたとき、ネットコミュニティとしての文化の終焉に何度も出会えました。
２ちゃんねるは、時代によって中心となる板が代わり、中心が動くことを繰り返すことで不死性を持った謎のサイトです。
一番最初は、開始１年目ぐらいでしょうか。その時代の中心は、ロビーといわれる場所でした。
ロビーとは、日常の違和感を一般的な問題化することで、無駄にしゃべりあうための場所です。
基本は今のニュース速報の様なものを考えて貰えば良いですが、取り扱う視点の広さは比べ物になりませんでした。
この時代を知っている人は、有名固定（笑）とか、その辺が懐かしい人もいるかもしれません。
さて、そんなロビーもだいたい一年ぐらいでダメになりました。原因は、マンネリ。
抱え込むネタの広さがマンネリとくだらなさを加速させました。今の嫌儲みたいな感じです。
嫌儲以上にひどい部分は、慣れ合いです。
元々は斬新な視点を提供できる人達でしたが、割に合わない思考を放棄するようになり
顔出しても知ってる固定同士でどうでも良い挨拶と雑談を繰り返すようになりました。
そんな感じでロビーは特筆するような最終回もなく、気が付いたら端にいる板になるようになりました。
その時代の結論は、慣れ合い禁止でした。
内輪ネタによる安易なコミュニケーションは、興味の無い他人にとっては「見てほしい」ネタでしかなく、「見たい」ネタではないわけです。
これを経験してる人やこの血を受け継ぐ人達は、内輪ネタや身内性に吐き気を催すように調教されています。
ちょうど良いので話は変わってmixiです。
「見てほしい」ネタと「見たい」ネタのバランスに対して、革命的な答えを提供したのがSNSです。
mixiのようなソーシャルネットワークサービスは、「見てほしい」ネタでしかない内輪ネタを
興味のある人に限定公開することで、「見たい」ネタに昇華させたのです。
好きな人のおならの臭いなら嗅ぎたい。それがSNSの本質であり、勝因でした。
でも、強引に近づけてしまった距離感が、結果的に息苦しくなり、若者のSNS離れを呼びました。。
mixiなので、四行ぐらいでどうでもいいです。
２ちゃんねるの歴史に戻ろうかと思ったのですが、飽きました。mixiのせいです。
ネタのマンネリ化を防ぐために、外部の時事性に依存したニュース速報。
VIP。作り出すことに徹した姿勢や、「見たい」を拡散したまとめサイト、慣れ合いの回帰。
ひろゆきが「まとめサイト」に対して好意的なのは「見たい」を拡散する効果なんですね。
２ちゃんねるの不死性は、少なからずひろゆきの空気の読み方も影響してたと思います。以前は。
で、最近話題のはてなブログのマーケティングは「見てほしい」を拡散してるんですね。
「見てほしい」を「見たい」に「見せかける」ツールとして利用されたのが、はてなブックマーク。
そこには「見たい」人達が集まる。なのに「見てほしい」人達を流れにのせる。
そんな風に利用されれば、反感を買うのはあたりまです。どちらの彼らのせいでもありません。
「見たい」の正体は、コンテンツです。Web2.0とかそんな時代でもそこが大事でした。
そして、コンテンツがマンネリ化した場合、その打開策として利用されるのが
「見てほししい」の無理やりなコンテンツ化です。
なぜかって？新しいコンテンツを作るより、人の欲望を見える化する方が簡単なんです。
ユーザー同士の関連テーブルを作れば終わりです。
それを体現したのが、ニコニコ動画です。ここまで読んだ人には書かなくても伝わる気がします。
で、なぜここまでモチベーションがあがらないかというと、このネタ10年前にみたとか地獄のミサワレベルだからです。
本来その先に時に生まれた異端児のストリーム論があるのです。Twitterですね。
そのネタもかなり古いですが。ストリームコミュニティの衰退を定義化されてるのはまだ見たことない気がします。
まだ、衰退してないからか？
なんでこんな古いをネタを書いたかというと、はてなブログから、すんごい古臭い匂いがするんですね。
「見てほしい」「見てほしい」文化。下手すると、テキストサイト時代のレベル。
なんつうか、うちらの世界によるtwitterの隔離閉鎖理論が、コミュニティ論そのものを衰退させて
古臭い「見てほしい」論に回帰したように感じるのは、僕の観測範囲の狭さでしょう。
時代遅れのブログでどうするか、無理やり考え出した古臭さこそ、nextネットコミュニティのはてなブログ。
なんかすんごい古い感じの、時代遅れな感じで、ループモノは飽きた。
昔なら衰退のトリガになる「見てほしい」のコンテンツ化が、この時代にどうなるか、というのはなんか少しだけ見守りたいけど。
どっちかという、こんなマンネリ論より、新しいコミュニティ論が見たいです。
下を読んでて思いました。
こんばんは。27歳のニートです。
ひょんなことからエロサイトを作ったら結構デカいサイトになったのでそのことについて書きたいと思います。
巨乳動画ストリーム
http://kyonyudouga.com/
さすがにニート生活にも飽き、何かやりたいなと考えた時にアフィリエイトを思いつく。
実はアフィリエイトについては以前から知っていて実際にやったこともありました。
しかしその時は全く稼げず、またその時は他にやることもあった為すぐにやめてしまいました。
腰を据えてやったらどうなるだろうと思い、再度アフィリエイトを始めることにしました。
どんなサイトを作ろうかと考えた時に真っ先思いついたのがエロサイトでした。
アダルトサイトはアクセスを集める手法としてアクセストレードと呼ばれる
他のアダルトサイトと相互にアクセスを送り合う手法が主流です。
そのため他サイトの画像リンクが増え、とても使いにくいものになっています。
画面をずっとスクロールさせないとコンテンツに辿り着けなかったり、ひどいところは騙しリンクもあります。
当初は私もアクセストレードメインで集客をしており、サイトは画像リンクだらけ。
ごちゃごちゃしていてコンテンツの位置もわかりにくいというお世辞にも良いサイトとは言えませんでした。
そしてアクセストレードというのは結局のところ自サイトのアクセス数により送れるアクセス数に限界があるため、ある程度のところでアクセス数が頭打ちになります。
実際のところ私のサイトも1日3万PV程度で頭打ちになりました。
そのためやる気を無くし半年程放置して2ちゃんまとめブログを始めました。
そこで２ちゃんまとめブログ運営で得たノウハウをエロサイトの方で実行したことろこれが上手くいきました。
これは一般サイトでは当たり前のことなのですがエロサイトは大手サイトでさえ非常にわかりにくい構成のサイトが多いです。
一方で２ちゃんまとめブログは大手サイトほど他サイトへのリンクも少なくわかりやすい構成になっていました。
なので思い切って画像リンク等を全て外し、わかりやすいデザインに変更しました。
②多更新にする
そこで私もエロサイトに多更新を取り入れ1日に1～3回更新だったのを１日24回、1時間に１回更新というスタイルに切り替えました。
③表示速度の改善
エロサイトはとにかく重たいところが多いです。
それは①で書いた通り画像リンクが異様に多いからというのもあるのですが動画共有サイトを利用したエロサイトは誰でも簡単に作れるため
その辺りがかなり適当なところが多いのです。
CSSspriteの使用やCSS,JSファイルのminify等ページの表示速度に関する施策を行っていないところがほとんどです。
無料ブログで運営しているエロサイトはスマートフォンページをしっかり作っていないところがほとんどです。
ほぼ広告ページとしてしか使用しておらず、コンテンツと紛らわしい広告を載せていたり、
コンテンツがあっても共有サイトのプレーヤーのサイズをスマホの画面サイズに合わせていないなど
そこで私はスマートフォンページのテンプレもしっかり作り込み最適化させました。
これらを実行した結果、ページ数が増えるに従い検索からのアクセスが右肩上がりで増え
PCページ40万PV/日、スマホページ20万PV/日というサイトに成長しました。
アクセスが増えた後いくつかの動画配信サイトとサンプル配信提携をすることが出来ました。
これには凄く驚きました。こんなことがあるのかと。
SEO施策はググれば出て来るような基本的なことしかやっていません。
SEO業者も利用していませんし、今のところこのサイトしか持っていないので自演リンクも一切やっていません。
SEOについてもエロサイトは基本すら出来ていないところが多いのでそれだけでライバルと差をつけることが出来ます。
ちなみに私のサイトはビッグキーワードでアクセスを集めているのではなく(一応「巨乳」で4～7位くらいですがそのワードでの流入は少ないです)
ロングテールってやつですね。
ロングテールは検索順位の変動にビクビクせずに済むので良いです。
やはり無料ブログでは出来る事に限界があり、エロサイトとはいえ良いサイトにしたいという思いがあったからです。
wordpressでの運営経験もなくサーバー関係のスキルもないので移転にはかなり苦労しました。
我ながら良いサイトに仕上がったことと移転を期に今までの足跡を残そうと日記を書きました。
jwplayer
Sidr(スマホ)
001 Prime Strategy Translate Accelerator
Contact Form 7
Count Per Day
Exec-PHP
Head Cleaner
Infinite Scroll
Multi Device Switcher
Quick Comments
Search Everything
Search Regex
WP-PageNavi
WP-PostRatings
WP-PostViews
多分これが一番気になるところだと思います。
アフィリエイトという観点からもスマホページの重要性がわかりますね。
あとcookieを利用したブックマーク機能も実装したいです。
エロだけじゃなくて一般サイトやWEBサービスも作りたいと色々模索しております。
どうしようもないクズニートでも頑張ったらこれぐらいのことは出来ました。
ニートでも頑張れば出来るんだ！と思って頂けたら幸いです。
-----------------------------------------
03:59追記
たくさんのブックマークありがとうございます！
とても嬉しいです。
確かに見やすくて使いやすいな。
けどリンク切れ報告フォームはなくていいの？実際他のサイトでそれが有効に使われてるのかはよくわからないが…
カテゴリ分けがシチュエーション別とかもあるといいなーと思ったけどこれ以上多くすると大変かな。あまり項目を多くするとまた見にくくなるかもしれないし。
リンク切れ報告フォームは以前は置いていたのですがあんまり報告してくれないんですよねｗ
自動でリンク切れをチェックするシステムを導入する予定なのでそちらで行います。
シチュエーション別もFC2の時はタグを利用してリストを作っていたのですが
FC2はタグをエクスポート出来ないのでwordpressではなくしちゃいました。
出来ないことはないのですが手作業でタグを登録し直さなければならないので…
それだけのスキルを身につけたらどこかに就職できそうだｗ
WordPressテーマは何を使っているんだろう？
-----------------------------------------
25日02:13追記
えーと下の方でステマだとおっしゃっている方がおりますがそのサイトの製作者と私は別人です。
私はRubyなんて使えません。
こういう事を書くと余計に怪しいと思われてしまうのでしょうけども。
ステマというのは運営者や製作者、その関係者が”利用者のフリをして”モノやサービスを薦める行為の事です。
運営者や製作者自身が「こういうのやってるんですけどどうですか？作ったんですけどどうですか？」と紹介するのはステルスではないただの宣伝です。
上でも書きましたが我ながら良いサイトに仕上がったので見てもらいたいなと思ったのです。
見てもらって感想を聞きたいなと。
エロ動画サイトってアクセスが多くてもコメントもほとんど付かないし感想を聞く機会がほとんどないんですよ。
でもFC2ブログだとさすがに恥ずかしいのでね。
wordpressならまぁ見せても恥ずかしくはないんじゃないかと思いまして。
この日記はたくさんブックマークされましたけどサイトの方はほとんどブックマーク増えてません。
結局この日記を書いた主な理由はただの自己満足と自己顕示欲ですね。
最近、ネット上のあらゆる所で起こっているアンチアフィリエイト活動、彼らの言動そのままを記すこととする。
「アフィリエイターは寄生虫、ヤクザ、ネットの癌です！ 早く死んでくれたまえ！」
「いつまで邪魔な広告を貼るつもりだよ？ アフィつけるなら閉鎖させてやろうか？」
聞くに堪えないこれらの罵詈雑言は一般サイトの管理人に絶え間なく聞こえてくる言葉である。
本来、有料サービスでないサイトで金銭や個人情報を要求していないにも関わらず、
彼らはサイトに広告が掲載されているだけで『被害者意識』が強く生まれてしまうという。
その表情は興奮に満ちていた──。嫌儲(アフィリエイトを嫌う人達の俗称)のオフ会で取材をしてみると、
自分たちの行動原理は、彼らの弁でいえば“正しいインターネット上”。嫌儲民と自称し、インターネット
で仲間を集めて日々、アフィリエイトをつけているサイトと戦っているという。
どういった素性の人たちなのか。詳しいジャーナリストがいう。
「当初は貧しくて仕事がない若者が中心でしたが、最近では普通のサラリーマンや公務員、主婦、中学生から高齢者までと幅広い層が
参加しているようです。彼らはみな自分たちは“被害者”だという共通認識を持っています。アフィリエイターは不労所得が月に何百万もあり、
彼らにステルスマーケティングなど流行やネットストリームを牛耳られており、今のネットはアフィリエイターに支配されているといった情報を
インターネット上で入手して、それが真実だと思い込んでいる。その“奪われたネット”を取り戻すために正義の活動をしていると信じているのです」
嫌儲民には自分たちが情報やサービスを享受しているという意識はない。
むしろ“自分たちが欲しいモノは誰かが無料で奉仕してくれるのが当然”と思い込んでいるのだという。
http://www.news-postseven.com/archives/20130625_195941.html
けんもうより
ネットで増殖するアフィリエイト嫌い 共通するのは1円も損していないのに『被害者意識』が異常に強い
一人住まいにはテレビはおいてないのだが、あればまあ見るんだろう。
しかし、この前実家に帰ったとき、ついにテレビを見ることができなかった。
ボタンがたくさんあるのも、ビデオとテレビとチューナーのリモコンがどれがどれだかよくわからなくてキレそう。
ボタンとか、電源とモード切り替えとチャンネルと音量と、あと番組表、それにアロー＆決定ボタンぐらいでいいじゃん！あとは画面に出せばいいじゃん！
リモコンとか1個にしてよおおお。
あと、地デジになったらテレビがすぐ映らなくてキレそう。なんなのあれ。ていうか全体的にもっさりしすぎ。きびきび動きなさいよ！！
あと、番組表のフォントが読みにく過ぎてキレそう。しかも画面がデカすぎてすごい見づらい。サイズぐらい選ばせてよ！
先日の日経に、
「法学部人気急落」という記事があって、明治学院大学とか東大とかが取り上げられていた。
日本の文系大学の中で、法学部は「文系の花形、主流派」的扱いを今までされて来て、
「あぐらをかいていた」が、人気急落で、受験生相手に法学部の魅力のアピールに努めざるを得なくなった、という記事。
そもそも、なぜ日本では法学部が主流で、文系の花形扱いされているのか？
これは推測だが、今の日本の文系大学の多くは、明治時代の「法律学校」創設がルーツだったからではないか？
経済学部とか文学部とか社会学部とかは「後発の学部」なので、大学内では傍流だったんだろう。
もっと突き詰めれば、「なぜ明治時代には法律学校が多く出来、経済学校は少なかったのか？」
という疑問に行き着く。
これも推測だが、当時の日本のGDPの大半は農業生産GDPであり、
つまり農業経済が大半、個人農業が大半であって、企業・資本の経済行動を
要するに、経済学がさほど必要なかった、経済学が必要なほど経済が成熟してなかった、ということ。
他方、近代化のために法律制度を整え、また列強に対抗し不平等条約を改訂するために
「法治国家」をアピールする必要があったため、経済力以上に「法律力」を身につける必要に迫られたため、
農業国であっても法律学校を整備する必要があった、そういうことでは？
しかし、現代みたいに、GDPの殆どが企業の生産活動で成り立っている社会では、
文系のメーンストリームは「法学部」じゃなく「経済学部」であるべきなんじゃないか？
もっとストレートに言えば、東大法学部じゃなく東大経済学部、文一より文二の方が主流になる社会でないと嘘である。
そらのやえがみやメガネのあれは
正史として「炎上マーケティング失敗例」みたいに記録されてるけど全然そんなんじゃない。
追及した側もされた側も一致であれは炎上マーケティングだった、ということに「してしまった」だけ。
追及する側がなんでそうしたのかって言うと
そらの一味の悪質さをまとめやすくて宣伝しやすいのがその説明だったから。
そらの一味がなんでその間違ったレッテルを受け入れたかって言うとチャチなプライドで初動を誤ったから。
えがみやめがねを心の無い守銭奴モンスターみたいに言ってる人が結構居たけど実態は全然そんなこと無くて
彼等二人とも「面白い人でありたい」「面白い人として一目置かれたい」みたいな自己実現欲求はすげえ強かった。
彼らがなんとかタイムズで目立ちたがり的アクションをするとき、半分はカネやＰＶ目的でも
もう半分は真面目に「これならどうだ、面白いでしょ」って真面目だった。
でもその度に「くそつまんねえ」「スパムやめろカス」っていう心無い罵倒を浴びて、
「真剣に面白がってもらおうと思って駄目だっただけなんです」とか真面目に釈明するより
「はいそうです金目当ての炎上マーケットですよ！ばれたかー！」って言う方が彼等としてはプライドを守れた。
「ひどい喧嘩でＰＶ稼ぐ」っていう炎上マーケティングの一環として処理されちゃったけど、ちょっと考えて欲しい。
別に悪口じゃないが、フランチェスコさんってそこまで有名人か？
割り切って喧嘩に巻き込んで炎上ＰＶ稼ぎするならもっといくらでもネームバリューのある人はいる。
つまりあれは「意図的な炎上狙い」とか「ＰＶ狙い」とかじゃなくて
本気でカッとなってああやってただけで、
そらののとこに持ち込んだのも単に引っ込みが付かなくなっての流れの上のこと。
発端やりとりだけ抜き出すと
メガネのフランチェスコへの絡み方が唐突過ぎると言うか脈絡不明すぎて
「喧嘩を売るために喧嘩を売った」ように見られたんだけど、実は全然違う。
あのときフランチェスコは「裏を取るのはライターとして当然（もううろおぼえ）」みたいな自分の仕事関連の呟きをしてたんだけど
メガネはその数日前にソースが無茶苦茶なフカシ記事書いて壮絶に突っ込まれて何回目かのプチ炎上してたのね。
だからメガネの中では数日前から一続きのアクションだったわけあれは。
「わざとクソみたいな記事や内容の無い記事ばっかり書いてる」
みたいに言われてたけど酷い誤解で、
当人はいたって本気で記事を書いてるだけだった。
その証拠に
記事が心無いモヒカンに突っ込まれまくってズタボロプチ炎上するたびに
相手論陣の中で一番頭や口喧嘩の弱そうな相手をtwitterから探し出して
そいつだけを脅したり問い詰めたりして謝らせて
「一勝一敗」みたいな格好を作るのがメガネの恒例行事になってた。
数日前の「ソースでたらめなクソ記事書きやがって」っていう袋叩きの心の傷が癒えてなかった。
だからちょうどソース主義者の中で気や喧嘩が弱そうな奴をtwitterで探してたんだと思う。
パッと見で「女→気が弱い→ちょっと脅せば泣きが入る」っていう雑な計算が組みあがっちゃった。
あのアイコンをよく見ればコワい面構えとか謎の斜め上見ポーズとか、ヤバい相手なのが察知出来ると思うんだけど
彼はそういう細かい神経が絶望的に発達してない人だった、面白くない記事量産からもわかるとおり。
「あれ、これはおかしい」「チョロい女でも若い女でもない」と気付いたっぽい反応をしてて
戦線撤収に動き出す速度は遅くなかったんだけど
彼のフォロワーや友人は「強いメガネさん」という虚像のフォロワーなので
「あの喧嘩広げましょうよ」みたいなストリーム放送出演の誘いを断れなかったんでしょう。
そらのもあんなのがＰＶになるとの計算でメガネに話振ったんじゃなくて
「付き合いのあるメガネさんが無名の女に生意気な口答えされてるからお手伝いしてポイント稼ごう」ってだけだった。
で、ああなるともう一味全体として、
プライドや虚像を保つためには「ＰＶ狙いの炎上マーケットだった」ってストーリーを受け入れるしかなかった。
「小さいプライドのために喧嘩吹っかけて相手間違えてエラい事になりました」はそれよりずっとかっこ悪いから。
http://anond.hatelabo.jp/20120521121033
長くなったけど、
万が一迂遠なそらの一味擁護みたいに機能してもあほらしいと思って当時は書けなかった。
自分から炎上マーケですなんて言うのは大抵プライドや意地で言ってるのばっか。
家入一味だって別に炎上で稼ごうと思ってたわけじゃなくて感情的になってる（or親分をフォローして点数稼ぎしようとしてる）だけ。
実在して上手く回ってる炎上マーケってのは今でも2chまとめブログぐらいじゃね？
B-CASカードがお祭り状態なので技術的なことをネットに転がっている情報から調べてみました。
もし間違いがありましたら後学のため教えてください。。
http://gigazine.net/news/20120518-b-cas-card/
・B-CASカードにはKm(マスターキー)というカード毎固有の暗号鍵が含まれている
・放送波から流れてくるTS(トランスポート・ストリーム)にはEMMとECMというというパケットが含まれている
・ECMはすべてのB-CASカードに向けて投げられるパケット
みたいな
- この情報はB-CASカード内にあるRAMエリア「契約情報」にコピーされる ★1
- EMM自身にはB-CASカードID(6Byte)が非暗号化されて入っている
・ECMには日時情報とKs(スクランブルキー)が含まれている
- 日時情報と上記「契約情報」でACL(アクセス・コントロール)を行なっている ★2
と、いうことで★1と★2において★1の契約情報を偽造できればたとえばwowwowを契約していないのに
契約できていることになりそうです。ただ問題は★1の部分はEMMで更新されるということ。
単純にB-CAS内のRAMエリアを書き換えても時間がたてばEMMで元に戻りそうです。
参考:
http://oshiete.goo.ne.jp/qa/3456801.html
http://blog.goo.ne.jp/ikedanobuo/e/8b59ccca2dac45f02a5ae15815fb4a75
http://www.marumo.ne.jp/db2012_5.htm#12
http://www.marumo.ne.jp/db2007_c.htm
EMMデータには暗号化されていない部分にカードID番号(6Byte)
http://www.arib.or.jp/english/html/overview/doc/2-STD-B25v5_0.pdf
知らなかったのですがB-CASカード内にはCPUが入っているそうです。
そのCPUがEMM/ECMのパース、暗号の復号、「契約情報」エリアの管理を行なっているようです。
今回は特定のB-CASカードに含まれるそのCPUが特定され、ファームを書き換えられるようにしたそうです。
ファームを書き換えさえすればEMMの「契約情報」をRAMエリアの「契約情報」にコピーさせる処理を
よって今回突破されたことをまとめると、
・特定のB-CASカードにはRAMエリア書き換え、CPUファームを書き換えるバックドアが設けられていた
・特定のB-CASカード対応の改造版ファームを作る猛者がいた
ということのようです。
以下は興味。
各B-CASカード宛てにパケットを送るなんて現実的じゃないよね？どうやってるんだろう？
特開２０００－１２５２７２ 【発明の名称】放送システムでのメッセージ伝送方法
http://www.j-tokkyo.com/2000/H04N/JP2000-125272.shtml
TSにはハッシュキーのみ含み、データはB-CAS内に予め保持しておくそうです。
確かに契約パターンはそんなに多くはないだろうからこれでいけそうですね。
EMMもひとつのTSパケット中に何個か含めることができるそうです。
いや、場所が箱でやってることがダンスとか旧世代クラブ文化チックなので広義の意味で「クラブ文化のいちストリーム」くらいにはなるだろうけど。
あれって実質やってることはコミケでしょ？ ちょっと変形してるだけで。
コミックマーケットご存知ですか。ＯＴＡＫＵがＪＡＰＡＮＩＭＡＴＩＯＮとか萌えマンガとかエロゲでぶひぶひ息を荒げるイベント～みたいに思われてる節がありますが、あれ原点は同人誌の即売会であって、「売り手と買い手は対等」の精神が特徴であるとして耳目を集めたり集めなかったりしてます。
キャッチフレーズは「コミケに『お客様』はいない」です。コミケに来る人間は作品への愛があるという点でみんな同類にして仲間であり、仲間同士助け合い協力しあってコミケなるイベントを作り上げようという姿勢です。
それが昨今はクラブの箱に入ってきてるだけなんじゃないでしょうかね。
だとしたら旧クラブ世代とは決定的に毛色を違える部分があるので、なんつうか、新世代のお行儀のよさを取り入れて旧世代が進化する、みたいな構図になるか微妙な気がします。
新世代クラブユーザーがお行儀がいいのは彼らのルーツがＯＴＡＫＵという無理解にさらされながらも常に適応の道を探らざるを得なかった連中にあるからであって、「自分らの文化を理解しない外部の目」がある程度内面化されているからです。
旧世代クラブユーザーって外部の目をシャットダウンする「箱」の中で育ってきたんでしょ。
アニメとかマンガとかの「何か」を楽しもうと思って集ってるというよりは、そこがコミュニティそのもの、居場所そのものとして機能してるからやってくるんじゃないですか？
「自分はナンパしないけど友達はナンパ大好き野郎で一緒にいると面白いからいつもつるんでる」みたいな人は、ナンパ大好き野郎が居なくてつまんなくなったクラブに行くでしょうか。
新世代はそこに機材があって音漏れしなくて自分の最萌えをありえない爆音で流してくれる上に人目をはばからず踊っても文句言われないから来るのであって、クラブ文化やコミュニティ性を愛してるかっつうと……みたいな感じがする。
旧世代、最悪単に駆逐されちゃうだけなんじゃないか？ 「発展」するだろうか。
第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 練習問題
この努力は僕が 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 になる必要はないっていうことを。インターフェースとワークフローこそが、人々が気に入り、安心感を得るものなんだっていうことを。彼はサードパーティの開発者にそれを可能にするだけで良かった。そうすれば、後の事は自動で進んでいく。
僕の言っていることが、あまりにも明白なことだろって感じているみんな（多かったらいいな）には申し訳ない。とにかくもうびっくりするほど自明なことなんだ。ただ、僕らがそれをやってないってことを除いてはね。僕らはプラットフォームを理解していない。プラットフォームを持っていない。アクセシビリティを理解していない。アクセシビリティを持っていない。これらは基本的には同じことだ。なぜならプラットフォームがアクセシビリティを解決するからだ。プラットフォームがアクセシビリティなんだよ。
第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 まとめ
