  |
はてなキーワード: アーキテクチャとは
http://b.hatena.ne.jp/entry/hotentry.hatenablog.jp/entry/2013/11/05/182712
はてなが身内によるブクマを禁止してるどころか、ソーシャルとしての可能性にかけてみた。なのは当たり前なんですよ。
お前らの記事が単純に
つ ま ら な い か ら
に帰結するんですね。
もはやダブルスタンダードどころじゃない。
俺らは仲間内でも面白い記事ブクマするけど、お前らは仲間内だと糞記事ブクマするからやめろ。
このジャイアンスタイルは、本質的に間違ってない。というか、君らも心当たりあるから謝罪とかしちゃったね。
というより、自称情強のはてばかブックマーカーが日夜戦い続けてる普遍性という「理不尽な空気」そのものなのよ。
ブラックの恩恵を受けながら、ブラックを批判する。そういうダブスタこそブックマーカーの本質なんだよね。
理論が間違ってるなら、誰かに責任なすりつけて批判とか出来るから。はてなというアーキテクチャのせいとか。
なに村人に謝罪回りしてるの？
いや、違うんだよね。
君らは、本来はてななんてどうでもいいと思ってる。
はてなを動かす人達のアホくさい宣伝を「利用」しようとしただけ。
それを「利用」したら、なぜかほかのユーザーに叩かれた。
理不尽だ。でも、よい。だって。君らの目的は、はてなじゃない。
ともだちの空気読んではてぶを利用しようとして怒られたら
ともだちの空気読んではてぶに謝罪する。
一番慰めてくるのは、アクセスログの人数なんですけどね。
iPhoneは常にオンラインだから、PassbookでQRコードのほうが優れている。という考え方なんだろ。
所詮NFCはNFC対応チップが店側に必要だからな。店舗の導入コストがかかる。
QRコードとiPhone側でのオンライン認証の組み合わせなら店側は既存のバーコードリーダーだけでいける。
アーキテクチャー的に優れているのはPassbookなんだが、果たしてどうなることか。
NFCをiPhoneに組み込むコストそのものは、大したことはないが
iPhoneがNFCに対応することでNFCインフラが世界に広まってしまい、それによりNFC陣営に力を与えることにより
将来Appleが決済インフラ的な優位度から言ってNFC陣営に対して不利になることを考えるとNFC導入が進むかどうか。
下見て思った。
http://mizchi.hatenablog.com/entry/2013/09/25/190313
知識が離散して蓄積されてない気がする。
シングルページスタイルのJavaScriptWebアプリケーションのアーキテクチャ
JavaScriptMVCライブラリを利用するよ！
とりあえず今回は、乱立する名称候補たちを紹介
HTML5って言いたいだけのJavaScrtipt使ったスマホのアプリフレームワークとかも呼ばれたり。
HTML5とか言われる前にJavaScriptアプリケーションやるとこれになってた。
アーキテクチャとしては、もっとも正解の名前なのだが、NET系界隈でしかきかん。
ASP.NET MVC Single Page Applicationは、キー要素がかなり詰まってて、参考になる。
このあたりのやろうとしてる奴は一度触っておくが吉
JavaScriptMVCライブラリ、AMD等の依存モジュール管理とか
英語ソースだと結構ポピュラーな感じの名前だが、指針的な匂いでアプリケーションとは言わない感も。
日本でも一時期、大規模Javascript開発とか言われてたが、Bakcbone.jsって名前に変わった。
Node.jsと被るために、このアーキテクチャの説明にはあんまり使われない。
動物本の、
「ステートフルJavaScript MVCアーキテクチャに基づくWebアプリケーションの状態管理 」
原題は、「JavaScript Web Applications」
これだけで、どのぐらい困ったか分かる感じ。
ちなみに、JavascriptMVCアーキテクチャの解説本としてはありなので読むが吉
といっても、10年ぐらい前からXHRとHTMLとDOMでほげるのは
実はあんまり変わってない。
Java界隈から出したかっただけ。oracleが呼んでた気がする。
Struts死んだけど、JSFでやるの？JSF無理筋だから違うフレームワーク作るの。
JSFみたいな抽象化使い始めると、コボルみたいにJava世界に閉じそうだけど大丈夫なの？
このあたりのライブラリ使えば、簡単にこのスタイルのアプリ作れると思ってるでしょ？
ライブラリの名称なのだが、背負ってるものは、大体この界隈全て
だけど、使えば、この界隈のアプリが簡単に作れるかというと、そうでもない。
あまちゃん評論などに呑み込まれたのでは。。RT @tkira26 批評空間とか読んでやけにとんがったブログ書いたりする若者が昔はたくさんいたものだが、今そういうインテリ予備層ってどこに行ったのだろ。社会学もスター不在な感じだし。そういうのかっこ悪いという反知性主義が勝利したのか。
https://twitter.com/hazuma/status/379425536172240896
頭いい／頭悪いとメジャー／マイナーは本来まったく異なっていて、「マイナーだけど頭いい」世界があるとみなが信じていたからこそ思想や評論は成立したんだけど、ゼロ年代半ばに若手評論家が「結局勝ち組がいちばん頭いいでしょ、大事なのはメジャーっす」と言い出したので評論は自滅したんですよね。
https://twitter.com/hazuma/status/379426402115674112
しかし、ニコ動でも初音ミクでもあまちゃんでもAKB48でも艦これでもなんでもいいけど、すでに大衆が万歳して受け入れているものを難しい言葉でごちゃごちゃ評論するほど滑稽なものはないわけで（マスコミ的には使いやすいけど）、そりゃ評論は死ぬよなあと。最近はしみじみ思いますね。
https://twitter.com/hazuma/status/379426928316268544
あと、同じように、評論界では「しっかりシステム作ればあとは自動的匿名的におもしろい作品は出てくるんだから、アーキテクチャについて考えるほうが作品より刺激的」とかいう風潮が現れたわけだけど、それなら評論なんか書いてないで起業すればいいじゃんと。ここでも評論は死んだよね。
https://twitter.com/hazuma/status/379427504366174208
評論家って、ほんとうは、メジャーな作品についてテレビに出てごちゃごちゃ語るひとではなくて、世の中に知られていないマイナーな才能を見つけこっそり育てたり愛でたりするひとのことを言うんですよ。そういう評論家は本当にいなくなったね。
ここ10年のBtoBの成果は、共通の技術基盤という妄想のために用意された
複雑大規模で、完全に閉じてて、他には誰も使えないEclipseで動く謎のゴミ。
自分達でも持て余して、パッケージ導入とか、結局Strutsスクラッチ開発だったね。
まあ、商売ネタとしては成立してたけど。
Struts1のサポートが切れる蓋を開けた時の状況は、笑いどころか失笑でした。
だからってBtoCも凄かったわけじゃない。
そこで事件が起きる。Railsの登場。
ビジネス的には、あんまりインパクトはなかったこれだが、歴史の転換を説明するのには便利。
Railsのアーキテクチャは、エンタープライズのアーキテクチャパターンを程よい感じに取りこんでいる。
Perlパクりから始まって、Javaのクラスパクッて、Railsも速攻パクった。
最近は、所謂関数系言語と分類されるパラダイムも最速でパクてる。
そんな感じで、RailsからパクッたフルスタックのMVCフレームワークが一気に広まる。
そしてこれらのフレームワークは、金魚のフンSierにとって銀の銃弾だったStrutsを、
鼻で笑えるもので、Strutsでドヤ顔してた彼らは、この時点からPHPerからも見下される存在になった。
エース開発リーダーさん。そろそろDIコンテナあたりは使えるようになった？
Javaの方が良いとか言うなら、せめてそのぐらいはフォローしたら良いんじゃないですかね。。。
ただ、これは結果から見たもので、本来の本当の流れは、ネットの普及にある。
BtoCの市場が巨大化し、パイが増えて、それだけ技術者も集まった。
優秀な人材がプロダクトを作れば、優秀なプロダクトが生まれる確率もあがる。
みんなで作れば凄いものが作れるという勘違いは、決してしないように。
これはアーキテクチャにも影響して、その方向性を決めるようになった。
SOAPは、優れていなかったわけじゃない。ただ単に閉じた世界すぎた。
RESTは、実用的なアーキテクチャなんてほとんど無い。ただみんなが適当にやってたのに名前付けただけだ。
だいたい今はそんな感じで
今後はアーキテクチャはBtoCが主導するだろう。
そこの社内SEさん。技術キーワードが凄いからって発注しちゃだめよ。
まともなもんが返ってくると期待しちゃいけない。
BtoBは、この鈍行の間、何もしなかったわけじゃない。
たった数パーセントの稼働率を上げるために、何十倍の時間や金をかけてきた。
彼らは、そういった品質に命をかけてきた。
設計書の文字のタイポをレビューすると、単価計算で１万円以上は余裕でする。
世界最高のMMOと言われるだけあって、WoWの影響はそんなに凄かったってことか。
件のリンクでは「良く出来てるにも程があるけどかかってる金も尋常じゃない。真似できない。」なんて書かれているけど、実際にはその後のMMOの仕組みを大きく変えてしまったみたいだし。
ちなみにECOのサービス開始は2005年、しかしベースが劣化ROと言われたほどRO的システムらしいので、アーキテクチャとしてはせいぜいゼロ年代初頭～前半期のMMOなんだろう。
そう考えると「お前は10年前の話をしているのか？」と怪訝に思う人間がいるのも頷ける。
その後ゼロ年代半ば頃に登場したWoWの、ユーザにも運営にも多大なメリットをもたらす、まさにWin-Win()な新しいシステムが主流になったことで、ROやFF11みたいな仕様を踏襲しているタイトルは「もはや古いゲーム」と見なされると。
しかしそうすると、それだけの名作が日本で殆ど知られていないし、依然としてプレイの敷居が低くなっていないのが何とも残念に思える。
もちろん日本鯖はないし、今更そんな鯖が作られる可能性は皆無にせよ、日本語UIは色々あるみたいだし、それに今は序盤が無料化されたというけど、あのバタ臭さ半端ないアバターがなあ・・・ゲームを通して目にするものが感覚的に合わないのは結構躊躇させられるというか。
そんなことするより、ジャイロ積んだほうが速いだろ。
カーブ区間は必ず線路が傾くんだから、傾き検知して傾きに応じた速度以上が出ていたらブレーキングすればいいだろ。
もっといえばブレーキングの必要性すら無い ブザーで十分。運転手が気がつけば減速できる。 ジャイロとブザーだけなら滅茶苦茶安価でレトロで、すぐに導入できる。
そんで、危ないところは工事して 手前から線路傾けとけよ。得意だろ鉄道会社。
※急カーブの場合は安全に曲がれるように 路面を傾けるよに線路を敷設する
自動車じゃなくて電車なんだから、集中管理したりGPS管理したりする必要性はない。線路から直接路線情報を読み込んだほうがはるかに速い。
↑のソフトならiPhoneでもおそらく作れる。速度情報さえわかれば、速度連動も出来る。 非常に安価に導入できる。 もうちょっとアーキテクチャーを工夫すれば結構いけんだろ
現在の以前を参考に動作する官僚機構のようなお役所仕事では立ちいかなくなった。
つまり、官僚機構その物にメスを入れて刷新できるような政治家が必要だが
政治家が頼っているシンクタンクもまた官僚機構だし、電通に代表されるようなメディア系企業は先端のバズワードは知っているが実際には設計できず
電通やシンクタンク系のIT企業には、国家レベルの大規模設計を刷新する（過去のアーキテクチャーに依存しない）のは難しい。
結論から言って、現状 構造改革は進まず もうどうしようも無くなって、全部破壊して焼け野原からスタートしようぜ
みたいになるまで、システムは腐敗を続ける。
なにせ、いまの安倍政権が頼ってるシンクタンクも結局は官僚機構と同じエリート機構なので、同じ官僚機構の刷新は難しいだろう。
政治家が調整型ではなく主導型になればまた話は別だが、そんなことが出来る人間は外資に行けば数千万のお金と、世界レベルの仕事を任されるので政治家にはならない。
よって、あー、どうしようねと。
PS3の設計がそもそもの混乱の始まりだね。いくらデバイスハブ構想があっても、まず本体を普及させないとダメ。そして本体普及させるのに必要なのはゲーム。Cellはあまりに扱いにくいし、本体価格などもあって、PS3は思うように売れなかった。PS2時代はPS2にだけソフトを供給すれば良かったけど、海外だとXbox360の方が売れたし、日本だとPS3の方が売れてるから海外でも売ろうとするとマルチにするしかない。すると、PS3のCellアーキテクチャはただの足枷。しかもWiiの方がさらに売れたから、Wiiをハブってたサードはさらに苦境になってる。その結果としてソーシャル(笑)に逃げてしまってますますゲームが作れない悲惨なことになってる。PS4はその反省をふまえて作りやすいゲーム機にしたけど、もうダメだね。ソニーがなくなるのがゲーム業界を救う一番の方法だな。
あ、まず前提として、
はたして貴女を幸福にするかどうか、それはまた別問題だけれど。
ＩＴ系の超かしこい男なども多く、
多くっつーかIT系でないのにプログラミング大好き男っていうのは超かしこい学生（まぁこれは有望株）か研究者系なんか、
あとはまったくかしこくもないクセに頭いいつもりして「Lispやってます（ｷﾘｯ ハローワールドくらいですが」とか言っちゃうアホしかいないわけで、
したがって、釣り師たる女たちにとっては、
なかなかあなどれない釣り場です。
では、プログラミング大好き男に「どの言語が好き？」と訊ねられたとき、
まず最初に、その男がCOBOLのようなタイプのレガシーコードと
あとはC/C++、そして（TechEdに参加するほどではないけれど）VisualBasicが大好きな、
貴女はかれの目を見て、微笑みとともに質問など無視して、こう言いましょう、
「わたしが、仕様書を作ってあげる♪」
これこそまさに必殺の答えです。
そこでプログラミング大好き男が、えへへ、とやにさがったならば、
貴女は、ひそかに、「コピペ量産しやすい技術的ポイントを抑えた仕様書」あたりを
ひそかに練習しておきましょう。これで成功まちがいなしです。
しかし、ここでは、もう少しハイブロウな（？）いわゆるプログラミング好きの男の
落とし方をお伝えしましょう。
「わたしは、JVM上のScalaが好き。
型推論もあるしラムダ式やクロージャもスクリプト言語みたいに書けるの、豊富な組み込みのコレクションメソッドはいつも便利だし、
XMLリテラルもCaseクラスによるパターンマッチもTraitベースのMixi-inも、大好き♪」
もしも貴女がそう答えたならば、
かれの貴女への恋心は、
２０％増量になるでしょう。
なぜって、Scalaは、
コンパイルは遅いながらも、そこがまた
ちょっぴりメモリを多く積めばいい富豪プログラミングみたいなふんいきをかもしだしていて。
質高くふるまっていて、なおかつ、
JVM上で動くくせにJavaが「やるやる」と言ったまま実装してなかったラムダ式と仮想拡張メソッド、型推論を実装した功績もあって。
したがってScalaこそは、
本来なんの接点もないまったく縁もゆかりもない別々の世界に生きている、
インタプリタ言語大好きな綺麗系ＯＬと、玉もあれば石も混じっている、そんなプログラミング大好き男たちが、
この世界で唯一（いいえ、JVM系列のJRuby、Clojure と並んで唯三）遭遇しうる場所です。
●
では、参考までに、危険な回答を挙げておきましょう。
プログラミング大好き男に「どの言語が好き？」と訊ねられたとき、
「MicrosoftのVisual Basic for Applicationが好き♪ 週３回は Excelでコーディングするの。」
特にOfficeは平凡ながら、ま、無難にまとめてあるものの、
しかし、「新UIのリボンUI！」「メトロUI対応！」とかなんとか無意味な自慢を吹聴し、
VBAはさらにプログラミングについての謬見を撒き散らした罪がありますから、プログラミング大好き男にとっては天敵なんです。
ティーガー戦車乗りのオットー・カリウスは「ティーガー乗りなら誰でも片側の履帯がはずれ僚車に牽引されて帰ってきた経験を持つはずだ」 って言ったけど
社内SEかSIerなら誰でもクソみたいな前任者が書いたクソみたいなExcel-VBAコードを直した経験があるはずなんです。
また、もしも貴女が「PHPが大好き♪ あたしが書いたPHPのWebサイトが、さくらサーバに７件あるよ♪」
と答えたとしても、同様の効果をもたらすでしょう、
なぜって、PHPは、１９９０年代にはWeb系を目指す人にとっては簡単で要件を満たすWebサイトが簡単に作れる輝きの道だったものの、
しかし２０００年代そうそうから、セキュリティ関係の問題で転落し、
いまや、あの貧弱な言語能力では、Rubyの魅力に遥かに及びません。
（注１）
「わたし、.NET FrameworkのC#が好き、フォームアプリでも書くけど、
最高に好きなのはASP.net♪ SQLServer連携も、ajax control toolkitもすっごくおいしいの。」
と、答えたとしたらどうでしょう？
なるほど、貴女の趣味は高く、
たしかに.NET Frameworkは、C# が cool であるのみならず、
.NET Framework上で動く F# や IronPythonやIronRuby、マネージJScriptも最高においしいんですけれど、
しかし、貴女の答えを聞いて、プログラミング大好き男はきっとおもうでしょう、
（なんだよ、MS信者な女だな、カネかかりそう）って。
（注２）
貴女が、プログラミングが大好きで、言語の名を挙げるにしても、
たとえば、JavaScript(node.js)ならば安心でしょう、
なぜならば、JavaScriptは、かけだしのプログラミング初心者にもマニアにもともに愛されるめずらしい言語で、
貴女がその名前を挙げても必ずしも、(jQueryがやっとの初心者と思われることはあっても)あなたがプログラミング言語おた宣言をしているとは受け取られないでしょう。
むしろ「へぇ。ちゃんとprototypeは使ってる？」と聞かれたら「当たり前じゃない。むしろnode.jsでいいMVCフレームワークが分からないんだけど…」と話を振ってみましょう。
男は嬉々として、３０個くらいのnode.jsのフレームワークを教えてくれることでしょう。（まぁどれもどれで帯に短し襷に長しなんですが）
あるいはRighno上で動かしたコードをnodeへ移植する話とか、CoffeeScript、甚だしきはClojureScriptを振ってみてもいいかもしれません。
しかし、たとえば、世界が（つーか竹内先生とポール・グレアムが）誇る超絶関数型言語の名作、Common Lispにせよ、
selfと書きまくることと海外で使われてることに定評のあるPythonにせよ、
バージョンアップごとに言語仕様が変わり、かなり素敵なものではあるもののobsolatedな罠にはまりやすいRubyにせよ、
まったく読めない$_だらけで頭悪い仕様をリセットしてPerl6にする（そしてまた全く読めない）Perlにせよ、
気さくなクジラ飛行机さんがふるまう素敵においしい日本語プログラミング言語のひまわり・なでしこにせよ、
基地外トリッキー言語の代表BrainFxck・Glass・Missa・WhiteSpaceにせよ、
ましてや貴女が、「Haskellが大好き♪ わたし、プロジェクト・オイラーの問題もうほとんどHaskellで、解いちゃった♪」
と答えたならば、どうでしょう？
これはかなり博打な答え方で、
なるほど、Haskellは、純粋関数型でありつつも副作用のある操作が行える超絶名言語ゆえ、
あなたがそう答えた瞬間、プログラミング大好き男がいきなり超笑顔になって、
「へぇ、やっぱりHaskellなら大抵の問題は４行以内くらいで解いちゃった？」とか言いながら
鼻の下がだら～んと伸びちゃう可能性もあるにはありますが、
しかし、逆に、（なんだよ、この女、プログラミングおたくかよ）とおもわれて、どん引きされる可能性もまた大です、
なぜって、必ずしもプログラミング大好き男がプログラミング大好き女を好きになるとは、限らないですから。
男たちは、女を導き高みへ引き上げてあげることが大好きゆえ、
もしも貴女が、「Haskellが大好き♪」なんて言ってしまうと、
そこにはもはや、男が貴女に圏論のモナドを教育する余地がまったく残されていません、
したがって貴女のその答えは、
プログラミング大好き男の貴女への夢を潰してしまうことに他なりません。
ま、ざっとそんな感じです、貴女の目にはプログラマーたちはバカでスケベで鈍感に見えるでしょうが、
しかし、ああ見せて、プログラマーはプログラマーで繊細で、おざなりに扱われると傷つきやすく、ローカル変数の名前一つにも気を使い、女と自分の将来に夢を持っています、
貴女の答え方ひとつで、プログラマーの貴女への夢は大きくふくらみもすれば、
一瞬で、しぼんでしまいもするでしょう。
●
では、スキットを繰り返しましょう。
「わたしは、JVM上のScalaが好き。
型推論もあるしラムダ式やクロージャもスクリプト言語みたいに書けるの、豊富な組み込みのコレクションメソッドはいつも便利だし、
XMLリテラルもCaseクラスによるパターンマッチもTraitベースのMixi-inも、大好き♪」
そして、その瞬間、プログラミング大好き男の目がらんらんと輝いたなら、
貴女はこう重ねましょう、
「それからね、いま、わたしが使ってみたいWebアーキテクチャは、
Play Framework、素敵なリアルタイム嗜好のアーキテクチャって噂を聞いたから。
あなたのお暇なときがあったら、わたしをPlayへ連れてって♪」
これでもう完璧です。
PlayFrameworkと、Play（遊ぶ・じゃれる）のダブルミーニングでかれの股間も刺激しちゃえます。
そうなったらこっちのもの、
デートの日には、ペアプロ用に Happy Hacking Keyboard をばっちり決めて、かわいい下着をつけて（注３）、
github.comの通販で売ってるoctcatのTシャツか、facebookの「いいね！」ボタンがムネのところにあるTシャツ、 あるいは初音ミク（ないし彼のお気に入りのアニメキャラ。北米ならMyLittlePonyで鉄板なんだけど）のコスプレを着てゆきましょう。
その日から、プログラミング大好き男は貴女の虜になるでしょう。
注１：
（と、書いたもののPHPの現状をよく知りません。グローバル変数だらけになるのとか旧ASPみたいなもんなのかなぁ。count($array); とか書くのアホと思うがpythonも同じだった）
（あと、マジで単機能とかTwitter連携とか診断メーカー的なのでもPHPで７つも作ってる女子居たら付き合いたい）
注２：
もっとも。objective-Cなんていう言語をやることに比べれば個人で行う程度なら金のかからない手法もなくはないのですが。
注３：
プログラマーにとっての「かわいい下着」と、女性にとっての「かわいい下着」の定義にずれがあるので注意。
半数くらいのプログラマーはしましまぱんつが可愛いと思ってる気がするので、妙齢の女性が着用するには抵抗あると思うが、ボーダー柄のコットンショーツ（ただしキャラ絵のは除く）とか、
過度でないていどにフリルがついたものがオススメ。また、色は、レッドだとプログラミング大好き男は引いてしまう（だってそれはコンパイルエラーのときの色だ）ので、薄ピンクかホワイト、薄ブルー、せめて黒（に差し色でピンクとか）あたりに留めたい。
補記：
元ネタ： http://tabelog.com/tokyo/A1301/A130101/13002457/dtlrvwlst/3464106/
補記２：
「プログラマー」か「プログラマ」かの問題については、特に意味は無いが前者を採用した。
補記３：
言うまでも無いけど、ネタです。
新たなアーキテクチャーを創設するくらいならオープンソースの分散並列(OpenMP-MPI)のハイブリッド(CPU-GPU)数値処理ソフトウェア開発に力を入れたほうがいい。
少なくともオープンソースで動くOpenMP-MPI CPU-GPUの基本的な数値計算ソフト(特に行列計算)は世界最先端の研究内容。こういったソフトを毎回アーキテクチャーごとに作るのは金の無駄だし、x86-x64環境で動くようにすればいい。
現状の数値シミュレーションなんてKrylov methodなどの行列処理が主な作業なんだから、それを汎用アーキテクチャで使えるようにしたほうがいい。CPU-GPU＋OpenMP-MPIで動く行列処理のソフトがあればそれが汎用の処理として使えるんだからくそみたいにコンパイルがめんどくさいアーキテクチャを作るくらいなら、汎用で使えるオープンソースのソフトを作れよ。
そんなコードがTrilinosなんだけどね。
http://anond.hatelabo.jp/20130223090512
三行でまとめると
PSのビジネスモデルを振り返ってみるのだが、この切り口から行くとPSはSONYの半導体戦略、そしてSONYは製造業と言う性質とと切っても切れない関係がある。
利用上の注意
なおすべて妄想となっておりますので、これを真に受けて被った損害などについては一切責任を取れません。皆様におかれましてはその旨ご了解のうえご覧いただけますよう、よろしくお願いいたします。ご協力頂けない場合につきましては、いい歳こいたアラフォーの髭ヅラ男が涙目になると言う非常にウザイ状況が発生することとなり、誰も得をしません。ご理解とご協力をお願いいたします。
SONYがゲーム機を一緒につくろうと言って任天堂に近づいたものの交渉が決裂してできあがったのがPSであったわけだがこれが大ヒット。
さらにPSでは、内部で使われている半導体を自社設計・自社かそれに近いFabで作る事によって
など副次的な効果もあり、さらに「SONYの旗艦」といったイメージを作り上げることができた。この他に、CD-ROMを手がける部門や、SONYのCDプレス工場部門等々、PS景気により、直接的なPSによって生み出される効果以外に、PSという揺るぎない需要が存在する事で、設備投資などに積極的になれたといった効果がうまれた。
初代は始めどこまで意図されいたかは不明だが2台目ではそれらの経験が生かされる事となりより強化された。まず一番は半導体工場で有り、旺盛なその需要と、それによって得られた利益を投資に回し新プロセスを開発、シュリンクすることによって最終的な黒字を目指すことで赤字で販売をスタートすることとなる。
ゲームハードは赤字でも、ソフトが売れれば黒字。こんなの当たり前だろ、と言う話であるが、総合情報機器メーカであるSONYでは少し事情が異なる。これは、ソフトウエアライセンス事業による利益によって、間接的に半導体生産の設備投資を補填すると言う形を意味する。もちろんそれ以外にもSONYの製造部門にもPS2が赤字でも販売すると言う行為によってもたらされる間接的な利益が流れた。
ご存じの通り、PSは我が愛する芸術品たる至高のゲーム機Dreamcastを完膚なきまで叩きのめし世界最高の企業セガをプラットフォーム業から引きずり卸しパチンコ屋に買われる所まで追い込む等大成功をとげた。そしてゲーム機生産により、SONYの製造業部門を引っ張っていくという当初の見込みは大成功した。
PS3の時代になると、パソコンの旺盛な需要の元、急速に進化した集積回路は、プロセッサの新規開発コスト、さらに半導体のプロセス開発に必要な資金が膨大に膨らむという現実に、様々な企業が立ち向かうよう時代が来ていた。世界の巨人たるIntelと、それ以外という構図が生まれ、世界中でFabの統廃合が進んでいた。
その中で目をつけられたのがゲーム機という存在である。パソコンに対抗できるほどの膨大な需要を生むゲーム機は、薄利という性質を持ちながらも数が出るため、生産設備を拡大しやすくプロセス開発の資金を捻出する事に有利であった。さらにSONYは、ゲームハードウエアが、当時のパソコンなどに比べて圧倒的に高い性能を持っていなければ存在価値が無い、と言う観念を持っていた。これはかつて任天堂がもっていた思想であった。
さらにIBMなどの思惑とも一致、開発がされたのがCell B.E.であり、この存在がPS3を生んだ。そう、ここまで来てSONYは、半導体のためにゲーム機をデザインしたのである。
もちろんこの説にはいろいろな異論はある。しかし俺は順序としては、ソニーグループ全体の長期的な戦略にPSが生む半導体工場の増設という戦略が大規模に組み込まれていたのは間違いないのでは無いかとみている。そこで完成したマシンは、化け物であった。現在まで続く潮流であるGPGPU的な動作もこなすCell B.Eがもたらす高性能と、高い拡張性を備え、既にゲーム機では無いとまで言わしめるものができた。この性能は当時の最新鋭コンピュータを大幅に上回るものであった。
しかし……。GPGPUの概念は早すぎた。性能を引き出すことが、当人であるSONYでも難しかったのである。そしてこれはミドルウエアや開発ツールの乏しさにも繋がる。そのためスタートアップに失敗した。この失敗は、PSがゲーム機として優れていなかった、あるいは、他者装置に負けた、と言う意味で失敗では無い。製造業としてのSONYが、自社の思惑通りに事を運べなかったと言う事での失敗である。
結果SONYは、PS3の需要を当て込んだ生産設備をリストラ・売却するなどの対処をを迫られる。さらに韓国勢などの追い上げ、AV市場の急速な変化、SONY本体の体力の低下、パソコンの高速化などにも影響を受けることになる。
PS3そのものは、OSの改良、ミドルウエアや開発ツールの向上などにゆっくりではあるが立ち上がってきたが、製造業としてのSONYがPS3に期待した効果は得られず、ハードウエア屋、製造業がみた夢はここに破れた。
さらに時代は動き、集積回路は、Intelがプロセスで1世代以上先を行き、それ以外はすべて後から追うという構図が完全に定着してしまった。SONYも、SONYの半導体と言えば、集積回路ではなく画像素子、と言う時代が来て久しい。世界中で半導体製造業者の統廃合は進み、国内半導体産業は衰退した。新プロセス開発の難易度や、集積回路の大規模化から来る開発コストの上昇はいかんともしがたくなっていた。
ゲームが必要とするスペックはもはや飽和している。少しでもリアルに、少しでも高性能にと言う方面はすでにマニアのものだけになってしまい、それら需要だけで、そのとき販売されているパソコンを上回る高性能チップを開発、載せるコストを満たすことはできなくなっていた。具体的に言えば、ウルトラハイスペックの、GeForece GTX SLIクラスにも勝ちうるGPUを、専用設計でオーバーヘッドを極力少なくすることができるとはいえ新規設計することが難しくなっていたのである。さらにはゲーム機業界ではスペック競争を離れた任天堂がWii、あるいはDSを生み出し、ケータイ、そしてスマフォとと言う存在がカジュアルゲーム市場をかっさらうようになった。特に日本では据え置きゲーム機がリビングルームに置かれ、パーソナルな空間に置いてゲーム機は携帯ゲーム機になったのである。
そして決定的だったのが、ゲームエンジンの躍進と越境であろう。従来はゲームエンジンや製作環境はゲーム会社の門外不出のものであった。しかしそれらが会社を通じて流通し始め、さらには専門業者も現れるようになったのである。
家庭用ゲーム機と言えば、ゲーム機の性能を引き出すためにソフトごとにアセンブラで最適化チューニングを施す。それを行っても常に動作が一定になることがメリットとして、パソコンに比べてゲームは常に一定の動作をすることが担保できるためにゲーム製作に専念することができた。しかし、パソコンは十分に高性能になった。家庭用ゲーム機も十分に高性能になった。その結果、チューニングを行わなくてもそこそこの画面が作れるようになってきたのである。そこで余った能力はゲームエンジンのオーバーヘッドを許容するようになり、ゲームエンジンの躍進に繋がった。さらにゲームエンジンはプラットフォーム間の差異すら吸収し始めた。あるゲームエンジンを採用すれば、あまり手間をかけること無く、パソコン版、PS版、XBOX版、Wii版と複数プラットフォームで出せるようになったのである。これは、ゲームエンジンが新たなるゲーミングプラットフォームとして君臨する可能性を示唆していた。
しかし、チューニングなどといった、ユーザとは直接関係の無い部分に手間をかける必要が無く、作ったゲームがどこでも動く。これはクリエイタとしては非常にありがたい事なのでは無いか？
ビジネス書に出てくる例えがある。ユーザはねじ回しが欲しいのでは無い。ねじを回したいのである。同じように、客はゲームがしたい、もっといえば楽しいことがしたいのであって、別にゲーム機が欲しいわけでは無いのである。クリエイタはゲームを作りたいのであって、ゲームハードウエアを使いたいわけでは無いのである。ここに合致したのがクロスプラットフォームなゲームエンジンであり、そしてこれらはクリエイタに作りやすい環境を提供し始めた。さらにゲームエンジンは新たに現れたライバルである、タブレット/スマートフォンにも対応している。
しかしゲームエンジンの躍進は、プラットフォームビジネスの崩壊を意味したし、PS3は性能を引き出すには高いレベルの専門的チューニングが必要であった。しかしゲームエンジンはそこにコストを払う事を選択せず、PS3は高い性能を持ちながらも、それ以外のあまり高性能ではないプラットフォームとほぼ同等、せいぜい高解像度のテクスチャーに入れ替えられた程度のゲームしか提供されない、と言った事が発生するようになっていた。
そしてPS4が出た。
PS4は有り体に言って、x86-64アーキテクチャのコンピュータに、OpenGL/CL対応のGPUを搭載した、本質的にはそこらのパソコンと変わらない構成である。
さらに言えば、最新のCorei7+GeForce GTX…と行かなくとも、そこらのパソコンに較べ、性能は高くない。しかし、根本的にゲーム専用機が持つ、汎用パソコンには無い特徴
を備えている。さらには、GPUを扱いにくくする要因の一つとして上げられる、GPUとCPUのメモリ転送をほぼ考えなくて良いと言う仕様を打ち出してきた。これはCellとCPUのプログラミングが分断され、非常に開発を困難にしていたPS3の反省をダイレクトに生かしてきたと考えられる。これはAMDが出していたコンセプトだ、と話題に上がるが、あくまでもパソコンの話であって、ゲーム機の分野では少なくとも、PS2がプログラミングが困難な部分を、高速なバスで繋ぐことで隠蔽するよな仕様であったように記憶している。
さらにx86-64アーキテクチャにしたことで、ゲームエンジンがPC向けエンジンの次に、素早くPSにも対応できる素地を整えた。Power向けに施す必要のあるチューニングを不要にしたのである。従来はパソコンで開発されたクロスプラットフォームのゲームは、パソコン向けと、家庭用ゲーム機向けの2種類作られた。そして家庭用ゲーム機向けは往々にして、ターゲットとなるハードウエアの中で一番性能の低いところに合わせたデータで作られた。平たく言えばPS3の方がXBOX360よりもはるかに映像表現は優れているのに（※ただし使いこなせれば） XBOX360との差異はテクスチャやムービーの解像度程度の違いだけになってしまう事を意味していた。しかしx86-64にしたことで、家庭用ゲーム機向けに統一してダウングレードされたデータからPS版を生成させるのではなく、パソコン向けのデータから生成させた方が早いと言う状況を作り出し、他の家庭用ゲーム機にくらべてアドバンテージを得ようとしているのでは無いだろうか。これはPS VitaがARMを採用したことも同じ事である。
さらに、SONYは、PSVitaから進めてきた戦略として、自社による強力にプラットフォーム感の差異を吸収するミドルウエア群…これはゲームエンジンと読んでも良いのかも知れないが…を提供してくるだろう。x86ならば従来の資産を生かすこともできるし、世の中に出ているコンピュータ向けのライブラリも利用できる。急速に開発しやすい環境を立ち上げているのではないだろうか。これはゲームエンジンにより脅かされる、プラットフォームビジネスへの対抗措置でもあるだろう。
これにより「雑事に捕らわれること無く、ゲームの楽しさ・表現そのものに専念する」と言うクリエイタの夢を叶えるハードウエア、それがPS4であろうと思う。
平たく行ってしまうと、自社の半導体商売が死んだことにより、その死絡みから解き放たれたPSは、クリエイタ主導でゲームを作ると言う根本に立ち返って作ったのがPS4だ、と言う話である。
しかしこれだとハードウエア、製造業の夢はどうなってしまうのだろうか？そしてユーザは別にクリエイタの夢などはどうでもいい。下手をすると高性能なハードウエアを所有していると言う欲を満たせなくなる分だけこちらの方がまずいかも知れない。それをどうカバーするのか？と言う話になる。
SONYは、次世代戦略として明らかにソフトウエア重視に舵を切っている。SONYは今、収支から見ると製造業では無く金融業であるが、その次に利益を生み出しているのは音楽・映像ソフト部門とゲーム部門である。
まずはここを潰してしまっては会社として立ち行かなくなる。それはまずい。ではどうするかというと、従来の「製造業としてのSONYを強くするために、PSの需要を利用する」のではなく「コンテンツ・製造複合体としてのSONYの核にPSを据え、関連商品を生み出す形で恩恵を得る」と言う形に舵を切ってくることになる。PS3でも一部行われているが、たとえばPSのリモートプレイを可能にするパソコンやタブレット、PSを再生装置としてコンテンツを供給できるメディアサーバといった具合である。
しかしこれらに対応させるために大切なPS本体の魅力を失わせては困ると言う事は強く意識されなければならないし、意識されていくだろうと思う。
ユーザの夢は、将来的には作りやすいゲームプラットフォームが生み出す新しいコンテンツという形で満たされることになるだろうが、直近では、ソーシャルへの展開という形で示されていると思う。将来的にはいかにコンテンツを集められるかと言う事にかかっている。が、ぶっちゃけていうとユーザから見たら、これほど夢の無い話は無いと言わざるをえない。
今回発表されたタイトルのデモなどは実際にはチャンピオンで有り、実際にプレイして得られるのはPS3とそれほど感覚的に、革新的に良くなったと感じる部分は薄いと思う。この点で、PS4は、PS3と実働コンテンツはそれほど変わらないと思っている。マイナーバージョンアップ程度。パソコンがWindows XPで評価が固まったようなものである。これはおそらく次に発表される新型Xboxでも同じだ。任天堂は少し別格の応えを出したが苦戦している。
かつてセガが出した芸術品とも言える至高のゲーム機、DreamcastはOSにWindows CEを搭載した。プロセッサこそ独自であったがそれは当時のWIndows CEではあたりまえであり、むしろそこにWindowsと言う汎用のソフトウエアを利用したことで非常にゲームが開発しやすく、PCゲームが移植しやすい環境を作り上げた。それらはアーケードのnaomiプラットフォームや、ワンチップで埋め込まれたパチンコなどで今でも生き続ける。
任天堂がWiiUでコントローラに画面をつけDreamcastに追いついたように、SONYは、PS4で作りやすいゲーム機という点で追いついたと言える。
またしてもセガは早すぎた。時代がセガに追いついていなかったのである。Dreamcastはその名の通り「夢を投げる」存在であったのだ。
最初に言っておくと、増田はSCEが嫌いな方でPS3もVitaも持っていない。
そんな増田だが、PlayStation4発表でのハードウェアに対する誤解の数々を見てちょっとばかり怒りを覚えたので少し書いておく
いきなり「何が違うんだ？」と思う人や「何も違わないだろ？」と言う人も居るかも知れない。
だが後半を語る上でもこれは重要な話なので省略しないでおく。
最近のPCは当たり前のように64bitのメモリ空間を扱えるようになった。
この増田を読んでる人でも64bit OSを使っている人は少なくないはずだ。
これをもたらしたのは、x86 CPUを作ったIntelではなくx86互換CPUを作っていたAMDである。
じゃあIntelは何をしていたのかと言うと、64bit CPUを作っていた。x86を完全に捨てて。
Intelは「IA-64」という64bit CPUを開発して商品も出していたが、これは現在ではほぼ完全に消えている。
確かにIA-64は64bitをネイティブで扱えて「x86の古臭い負債」が全く無かった。しかし、現実世界はx86で作られた既存のソフトウェアを求めたのだ。ゲーム業界でも似たような話を聞いた気もする。
それに対して、AMDは「64bitを扱えるx86」を作ってしまった。これが「AMD64」であり、現在業界標準としてx86-64と呼ばれているものである。
知っての通り、x86-64は現在のIntel CPUでも対応している。AMDが作った命令を使わされる事になったIntelは何を思っただろうか。逆に、これまでIntelの命令を使ってきたAMDは何を思っていたのだろう。
PS3に搭載されていたCellは、非x86でスカラプロセッサのPowerPC CPU（PPE）と、複数のベクトルプロセッサSPEを組み合わせたヘテロジニアス（非対称）プロセッサだった。（スカラ、ベクトルについてはググろう）
スカラプロセッサが得意な処理、ベクトルプロセッサが得意な処理を両方とも高速に実行できる。それがCellの目指した「夢」だった。
スカラプロセッサとベクトルプロセッサのプログラム最適化は全く別の概念で、プログラマーにとっては野球とサッカーを同時にやらされるような物である。
しかも、スカラプロセッサとベクトルプロセッサの間でデータの交換もある。野球とサッカーのキャッチボールて。
スーパーコンピュータ「京」もスカラとベクトルの合わせ業で池田某氏に何度も叩かれるほどの超絶難産だった事は記憶に新し…いっけ？
それが原因でPS3の性能を最大限に引き出したソフトはほとんど存在せず、こともあろうにXbox360とのマルチソフトが溢れる結果となった。（ちなみに増田は360も持ってないのでエルシャダイをプレイ出来ていない、問題だ）
それに対し、PCの世界ではPS3・360が発売してしばらく後に新たなヘテロジニアスコンピューティングが生まれていた。
CPUに比べて進化が止まらないGPUをベクトルプロセッサの代わりとして使う試みだ。
GPUはスパコン用のベクトルプロセッサやCellのSPEと違い、最近のどのPCにも搭載されているので量産効果で割安というメリットがある。
DirectXのバージョンも2桁に突入し機能が増えるにつれて、「もうこれで計算すれば良いんじゃね？」となったわけだ。
結論から言うとこの試みは無茶苦茶ヒットした。近年開発されたTOP500スパコンでGPUが使われていないものを探すのが難しくなってきたし、
最近はPhotoshopなんかの比較的身近なツールもGPUコンピューティングに対応してきてヌルヌル動くようになっている。
しかし、そんなGPUにも欠点はある。「CPU・メモリから絶望的に遠い」のだ。
IBMが発明しMS-DOS・Windowsが動くことで爆発的に普及した今のPCは、GPUを外付けにすること前提で設計されていた。
DirectXやOpenGLのような例外を除いて、基本的に現代のOSはCPUとメインメモリでソフトを動かすように出来ている。
GPUも、一旦メインメモリ上でGPUのRAMに載せるためのデータを生成し、CPUから「GPU動かすよー」という命令を出さなければ動かせないのだ。
これはGPUにとって致命的すぎる欠点だった。これが原因で、遅さを跳ね返せる最新のミドルレンジ・ハイエンドのGPUでなければ逆にCPUより遅くなってしまうケースばかりだ。
現実的な理由で始まったGPUコンピューティングがぶち当たった現実的な壁である。
このGPUの欠点を克服する方法について、AMDはかなり前（少なくともGPUコンピューティングが流行るより前の2007年以前）から取り組んでいた。
GPUコンピューティングが遅いのはCPUから物理的に遠いため命令を送る時間が掛かり、メモリの扱いも異なるせいである。
CPUからGPUに命令を送る遅延を無くし、CPUのメモリとGPUのメモリを交換する時間も減らせばGPUコンピューティングのデメリットは消え失せる。
夢のある話だ。
しかし、AMDには発想と設計技術はあったがカネと製造技術はIntelと比べて絶望的に劣っていたため、
初めてのCPUとGPUを統合したプロセッサはIntelに先を越されてしまった。（IntelのGPUが絶望的に遅いからって実質出てないなんて言っちゃダメだ）
これにはAMDもかなり堪えただろう。けれどもAMDは戦略を曲げなかった。
IntelのGPUが絶望的に遅いのでほとんど意味は無かったが、少なくとも前世代のIntel GPUに比べると格段に実効性能が上がっていたのだ。CPUとGPUを近付ける統合には間違いなく意味があったということである。
AMDはCPUとGPUを同じチップにするだけでは無く、メモリ「アドレス空間」も一緒にする道を目指した。
こうなるとCPUの使っているメモリがGPUから直接扱え、GPUの使っているメモリがCPUから直接扱えるようになる。
これが実現するとCPUとGPUが完全なヘテロジニアスコンピュータに一歩近付くのだ。
2011年にやっとAMD初めてのCPU＋GPUであるAPUを出せたが、メモリアドレス空間はまだ別々だった。
2012年になってもメモリ空間は別々のままだったが、AMDはARM（iPhoneやAndroidやWindows Phoneに載っているARMである）と合同でHSA（ヘテロジニアス・システム・アーキテクチャ）を推進すると発表した。
世の中の現実的な人々は笑った。「アーキテクチャだけを作ってもハードとソフトが出てこないんじゃ話になりませんよ」と。
同じ2012年、AMDは2013年中にHSAの第1世代製品を出すとだけ発表し2012年は終わった。
そして2013年2月21日（米国時間20日）、Sony Computer EntertainmentはPlayStation 4を発表した。
Cellはコケてしまったので載らない事は誰もが知っていたが、載っているハードウェアに一部の人が驚いた。
―HSAである。PC用のHSA対応APUがまだ正式発表されていない中で、なんとHSAを載せてきた。（2013年末発売だから当たり前だというツッコミは止めろ！）
CPUはx86-64のJaguar 8コア（ちなみにPC向けJaguarは4コアまでだ）、GPUはRadeon HD 7800相当でPS3と違いガチで1.8TFLOPS（理論上1秒間に計1.8兆個の小数点を含む計算を実行可能）のスペックを持つ代物だ。
このCPUとGPUは8GBのGDDR5メモリを共有して動作する。8GBと聞くと最近のPCから考えると少なく聞こえるかも知れないが、（わたしのメモリは16GBです）
GDDR5とはGPUの描画計算を速く済ませるために作られた超高速メモリであり、ご家庭のDDR3メモリとは比べ物にならない速さが出せる。
実際の所PS4がHSA対応かは正式発表されていないのだが、PC向けJaguarはHSA対応と発表されており、SCEもPS4をAPU（CPU＋GPU）と呼んでいてこの変態メモリ構成とすると、発売までにクッタリでスペックダウンしない限りHSA確定と見て良いはずだ。
また、PlayStationはこれまで一度もx86系CPUを採用した事が無く、これが最初（で最ｇ）のx86採用機となる。
Intelが初代Xbox（Celeron搭載）であっさり諦めたx86のゲーム機市場制圧の夢を、AMDが思いもよらぬ形で果たしたのだ。
これまでPCでしか発売されてこなかったDiabloが、x86-64のPS4向けに初めてコンシューマ版を発表した事もx86-64の採用が決してつまらない事ではなかった証だろう。（Diabloと戦うハメになるサードの方々にとっては非常につまらないが）
CPUとGPUの”フュージョン”…（HSAは以前はFusionと呼ばれていた。そういえばドラゴンボールの映画も今年やな…）
AMDが長年の間見てきた夢が、PS4で初めて現実世界に現れることになる。（※ただし次世代XboxもHSA採用でPS4より先に発売したりしない世界線に限る）
こんな馬鹿らしいほど夢が詰まったマシンを「x86搭載だからPCみたいで夢が無い」という一言で切り捨ててしまう人に増田は絶望した。
でも、それってユーザーの夢にどう繋がるの？
性能の引き出し易さがPS3と比べて格段に良くなるのでPS3版ラストレムナントや人喰いの大鷲トリコのような非情な現実が減る。以上。
http://www.yamdas.org/column/technique/hatenablog.html
なお、タイトルに PART I とあるが、このネーミングはメル・ブルックスの『珍説世界史 PART I』にちなんだもので、PART II 以降は存在しない。つまり、あなた（ソフトウェア企業）が絶対すべきでないことは、Joel Spolsky にとってこの文章に書かれることだけなのだ。それは何か？
まぁ、そんなわけないんだけどね。
「最近のはてなの体たらくへの失望感に名前を付けたい」というだけの文章にマジレスするのも我ながらどうかと思うし、気持ちは分からなくもないんだが、最近は「はてブ」以外全く使ってない俺でも、長年お世話になってきたはてなに対してそれなりに愛着というものがあるわけで、ディスられるばかりの流れに少しばかり反抗を試みたい。これは、それだけのエントリだ。
というわけで、以下に書くのは、技術の話でも倫理の話でもない。どうか気軽に読んでほしい。
実例を挙げる。
今やワールドワイドな影響力を持つ勝ち組ソーシャルサービスのTwitterだが、彼らは、ここ数年でバックエンドの大半をスクラッチから完全に書き換えた。しかも、RubyからJavaへと、使用言語すら変更してしまった。
http://d.hatena.ne.jp/teppei-studio/20110709/1310168002
もう一つ。Tumblrも、LAMPアーキテクチャからJVMベースへ切り替えた。その過程で、Twitterがオープンソース化した技術を取り入れたりもしている。
http://blog.kyanny.me/entry/2012/02/19/002256
『「古いコードはクズだ」というのは錯覚だ』というJoelの意見は、一面では正しいが、他の面では間違っている。なぜなら、あるソフトウェアに求められていること（要件）は、時間と共にどんどん変化するからだ。
書き直そうが、書き直すまいが、一番ダメなソフトウェアとは「ユーザの要求に応えられないソフトウェア」だ。規模や環境の変化によって古い技術の技術的限界に直面したり、ビジネス環境の変化に追随する必要が出てきたのなら、「スクラッチから書き直す」のは立派に一つの選択肢だ。
はてなダイアリーの最初のバージョンがどういうものかは俺もよく知らないが、おそらく「LAMP」がエッジなキーワードとして持て囃されていた頃に書かれたプロダクトなんじゃないかな（間違ってたら突っ込みを）。それから時代は下り、Ruby on Railsに代表されるCoCなフレームワークの登場を経て、今や大規模分散や非同期を前提としたアーキテクチャが当たり前の時代。当然改修はしているだろうけど、MySQLを職人芸で負荷分散していた時代からは大分遠いところに来たのは間違いない。
何より、はてなダイアリーといえば「はてな記法」とカスタマイズの自由度の高さがウリだったわけだが、これらの存在が、今や機能追加や改良の妨げになっているとしても不思議じゃない。
はてなブログ開発の動機として「今どきの技術で、最初からやり直す」というのがあるのは間違いないが、それは「スクラッチからの書き直し」だから悪手なのだろうか。結局のところ、レガシーコードのメンテナンスを続ける場合と比べてどちらがより低コストか、という話の結論によるとしか言えない。
はてダのソーシャル要素といえば「トラックバック」と「idコール」と「キーワードリンク」だったわけだが、全部Twitter（とTogetter）に持っていかれたよね、という話。
だから、「はてダver.2」や「ブログ2.0」を望む声が大きいのは理解できるけど、ぶっちゃけ、そんなもんに開発リソースを突っ込んでも勝ち目なんか無い。んで、それに代わるアイディアを持ってる奴はどこにもいないと。だから、既存コードの改良ではなくスクラッチから書き直し、スモールスタートでフィードバックを受けながら方向性を考えていく、という方向性はそんなに間違っていないと思う。
ただ、現状を放置すると「それTumblrでできるよ」という話にしかならん、というのはその通りで。それ以外だと、もしgithubがblogサービスを始めたりすると、かなり客を持っていかれるのではないかという予感はする。いっそのこと、Tumblrのデッドコピーから始めるのが一番早いのかもしらんね。
少し別の話を。
これは、Twitterのgithubレポジトリだ。上でも書いた通り、Twitterはサービスをスクラッチから書き換えた。で、その過程で開発した内部向けのフレームワークを、どんどんオープンソース化している。彼らが、内部の技術をきちんと体系化して再利用可能にしていることの証左と言える。
一方、はてなのgithubレポジトリ。正直、サンプルとかプラグインばかりですね、と。
色々と理由はあるんだと思うが、一つ思うのは職人芸頼りで自分たちの技術を体系化するという部分が弱いんじゃないか、ということ（はてな発のオープンソースで広く使われてるのって何かあったっけ？）。
先ほどから散々「書き直していい」と主張しているが、誰かが言っていた通り、技術の本質を捕まえきっていない状態でフルスクラッチをやっても、失敗する可能性は高い。はてなブログがどちらなのかは、中の人にしか分からないことだけど。
はてなが経営的にあまり状況がよろしくない、という推測はおそらく当たっているのではないかと思う。
タイムラインで、誰かが「まっとうな方法で収益化する方法を真面目に考えるべきだった」と言っていたのを見た。それをしていれば、今回のような事態を招くことは無かったのだろうか。
だが、「まっとうなビジネスモデル」とは何だろう。実際問題として、ここ最近成功しているネットサービスのビジネスモデルで「ターゲティング広告」と「マスなユーザベースから抽出したビッグデータを解析して売る」以外で何か有力なものはあっただろうか。FacebookにせよTwitterにせよ、収益化の原動力はユーザ行動解析だったりするわけだ（彼らがオープンソース化に積極的なのは、インフラ技術が差別化の源ではない、という面もある）。
まぁ、あとはガチャだが、どちらにせよ現状では高木先生の逆鱗に触れるようなものしかないよね。
そんなわけで、それらに代わる第四のマネタイズモデルを思いついた人は、ぜひ近藤さんに教えてあげると良いんじゃないかな。あればだけど。
今後はてながどうなるかは分からないけど、一つ希望したいことがあるとすれば、故伊藤計劃氏のダイアリーがこの先も保全されることを望みたい。
それは、エントリを全て魚拓しろ、という話ではもちろんない。彼の生前に書かれたエントリは、当時の「はてな」という生態系を構成する一部でもあるわけで、そこから切り離して文章だけをアーカイブしてもあまり意味がない。
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 が見つけた個別の発見や教訓があった。外部サービスにはおかしなところがいくつもあったけれど、君たちが考えるほどじゃあない。サービスに対して組織するってことは、外部のデベロッパを信用できないのと同じように、お互いを信用することなんてできないんだということを、チームに教えてくれたんだ。
