  |
はてなキーワード: ビッグデータとは
2005年に突如現れたRailsによって国内でRuby利用者が急増したのがPerl滅亡への第一歩となった。書きやすさに作者がとことんこだわって作られたRubyの魅力を一度知ってしまうとPerlの古くさく読み辛く書き辛い文法に誰もがうんざりし始める。
Ajaxで再発見されたJavaScriptのブームもPerl終焉に若干ながら貢献している。ブラウザというPerlが全く手を出せないジャンルの王者JavaScriptの持つ華やかさに誰もが憧れ、そして手元のPerlの古くささに反吐が出始める。不器用で不細工なところも含めて愛していた女房とつつましく送っていた人生に、突然ぴちぴちのボイン女子大生が転がり込んで来たようなものである。
iPhone市場が本格的に立ち上がり、Perlとは全くの無関係であるスマホアプリ全盛期がやってきていよいよPerl滅亡へのカウントダウンが始まった。そして極めつけはソーシャルゲームバブルである。ここでもPerlとかいう言語は全くの蚊帳の外で大絶賛凋落中。
Perlなんぞ全くお呼びでない世界の話。段々とwebテクノロジーの世界に高度な数学的知識を持ったアカデミック層が跋扈しはじめ、専門学校でプログラミング言語を学んだだけの人間がハッカーなどと名乗ると恥ずかしい時代になってきてきた。
遂にPerlにとどめを刺したのはPythonである。守備範囲は当然ながらPerlと駄々被りで読みやすく書きやすく世界的なシェアもうなぎ上り。完全にPerlが不必要な世の中になってしまった。
2005年までのPerlはまさに我が世の春を謳歌していたが今や目も当てられない惨状でプログラミング言語のシーラーカンス・COBOLとすら比較され出す始末。昔Perlの人として売り出していたハッカーも、いつのまにかPythonの人になっているケースも海外では多い。10年でここまで時代は変わる。今のメインテクノロジーも明日は我が身だ。小手先の技術に乗っかってモダンだのハッカーだの聞こえのいい言葉を汚い口でまき散らして消えて行ったPerlエンジニア達の死を無駄にしてはいけない。変化の速い時代に生きる我々に必要なのは本質を学ぶ事だ。コードの書き方とかどうでもいいんだ。もっと10年20年たっても色あせない情報工学を身につけなければならない。
統計の世界には Garbage in, garbage out という格言がある。これは、「ゴミのようなデータを使っていくら解析しても出てくる結果はゴミばかりだ」という意味
相関と因果は一致しない 女性平均寿命 NHKの放送受信契約数
「相関が無い事の証明」は可能か - Interdisciplinary
期待された発電量が得られず、消費電力が発電量を大幅に上回ることを説明しなかった
視聴率10パーセントの時の誤差は±2.4ポイント、視聴率20パーセントの時の誤差は±3.3ポイントである。
1)犯罪者の98％はパンを食べている
4)パンは中毒症状を引き起こす。被験者に最初はパンと水を与え、
後に水だけを与える実験をすると、2日もしないうちにパンを
異常にほしがる
6)18世紀、どの家も各自でパンを焼いていた頃、
平均寿命は50歳だった
例えばフォーブスの世界長者番付にランクインするような億万長者が1万人の市に引っ越してくれば
平均年収はつり上がってしまうが、年収の中央値はほとんど変わらない。
これを読んで思ったこと、またはその反応に対して思ったこと。
http://d.hatena.ne.jp/yomoyomo/20130228/bigdataisdead
Web2.0からクラウド、ビッグデータまで、様々なバズワードが生まれ、おっさんたちを虜にし、また一部からは揶揄される状況が繰り返されている。当然ビジネスの上でも、これらのバズワードは多用され、一部では本質的に意味のある事業が進んでおり、また一部では知的ゴロツキの餌となっているのが現状だろう。
このようなバズワードに対し、一般的な反応は大きく分けて2つだ。「我が社もビッグデータ事業だ。その方が時代に乗っていて格好いいだろう、ぐはははは」と「またバズワードか。食傷気味だ…一年で何回聞くことになるんだろう…」である。
ここで、問題にしたいのはバズワードの対象自体が有用か有用でないかではない。基本的に正しく捉えればクラウドもビッグデータも有用だ(だからこそ、バズっているともいえる)。では、なぜこれらのバズワードが飛び交う時に、嫌な気分になったり、攻撃的になったりする人たち(自分含む)がいるのだろうか。
考えてみたのだが、バズワードは言葉自体がもつ情報量が圧倒的に少ないことに起因するのではないか？ということだ。これはバズワードの定義が曖昧ということとは異なる。そうではなくて単語が発言されるときにその単語がもつ情報量の問題だ。通常の会話ではある単語が発言されたときに、その人の知識量やバックグラウンドを示す単語があればその人の能力をある程度推測することができる。
卑近な例だが「Excelだと100万行以上あると開けないですよね」という発言があると少なくともこの人は100万行のデータを扱ったことはあるんだなという情報が受け手は得られる。技術的会話とは本来そういうもので、その人の発言する技術用語である程度の技術力を推測するものだろう。いや、コード書かせてみないとわからないだろ、というツッコミはおいてください。あくまで最低限の推測、例えばこれまで付き合いのない企業間での打ち合わせのような場合でのスクリーニングの状況を想定してほしい。
このとき、バズワードによって、なんかよくわかってない人も「ハドゥープでノーエスキューエルでアレですよ」みたいな発言をするようになると、これまでどちらかというとマイナーで技術者かどうかを識別する単語につかえていたHadoopや統計手法名をまた一から考え直さなきゃいけなくなる。一番最初のスクリーニングの仕方をこちらが変える必要がある。それが激しくめんどい。だから、バズワードは嫌いだ、という思考を自分がしていることに気がついた。
というわけで、ビッグデータうんぬんにイライラしている方々、この仮説は如何でしょうか？
蛇足だが、なんでこの思考に辿り着いたのかというと、あまり親しくない他社との打ち合わせ時に相手がビッグデータ、ビッグデータと連呼するので、ほんとに技術力があるのか(またはほんとにビッグデータに関心があるのか）よくわからなかった。そこで、関心あるならそれなりにビッグデータに関する情報もフォローしているはずだという仮説のもとでユバタスについて話題を振ってみたところ、ユバタスどころかPFIも知らなかった。世の中そんなもんである。
日経によれば、スマホの健康管理アプリの、人気１位・３位・４位は女性の「月経周期管理アプリ」
（例：ルナルナ）なんだそうだ。
女性が「惜しげもなく差し出している」というのもなんだか面白いが、
これって、一種の「ビッグデータ」だよね？
日本女性の健康状態とか、ある程度分かっちゃったりするのでは？
「女性が数人共同生活していると、互いの月経周期が近似する」との学説があるが、
別に共同生活していなくても、日本全体でも、「１月５日は月経の女性が多い」
「１２月２０日は排卵日の女性が多い」のような傾向が、ある程度現れるかもしれない。
日本全国の傾向もあるだろうし、あるいは
「今日は北海道エリアに月経女性が多い、四国エリアに排卵日女性が多い」
「今日は２０代女性に月経女性が多い、３０代女性に排卵日女性が多い」
「それがどうした？」と言われるようなデータだが、これって、女性向けの商売している会社にとっては、
直接的な商品（生理用品）はもちろん、ダイエット食品や化粧品、
下着や通販売上なども、月経周期と売行が相関するだろうから、そういう商品の販促に役立つ。
あるいは、社会的大変動と、月経周期との相関関係もわかるかもしれない。
「３・１１の影響で、女性にストレスが加わり、月経周期が長くなった（短くなった）」のように、
従来だったら、そういうデータ解析はまず不可能であったが、
「女性自ら個人情報を差し出している」のだから、それを活用しない手はない。
できるわけねーだろ。ケインズの名言を1000回音読することをお勧めする。
あとビッグデータ（笑）という単語のイメージだけで妄想するのはやめて、少しでいいから自分の手を動かせ。
http://anond.hatelabo.jp/20120511124327
論点1,論点2について。
レアケースとして、難病、特殊な性癖等、それ単体で自分で珍しい属性と思えるよって個人の特定が発生するという話になっています。人に寄っては「自分はそんな特殊な属性なんか持ってないその他大勢だから問題ない」と考えている人がいるかもしれませんね。また、武雄市市長は
僕が言っているのは、「５月６日２０時４０分、４２歳の市内在住の男性が、「深夜特急」「下町ロケット」「善の研究」」を借りた。」ということそのものについては、個人が特定できない
と述べています。(http://hiwa1118.exblog.jp/15827483/)これを見て「この程度の属性ならば個人情報は特定できない。安心だ」と思っている人も多いかも知れません。
が、実際にはそんなこと無く、普通の属性の人でも、いくつかの条件を組み合わせていくと簡単に個人が特定できるよと言う話をします。図書館側から、CCCに対して、上記武雄市市長が挙げている情報が渡ると仮定した場合、ある程度の行動に法則性がある人であれば、かなりの確率で個人の特定ができます。
例えば、
これらはみな高確率で本人の特定が可能です。
簡単に言うと
これらはそれぞればらばらには該当する人間は多数います。しかし、これが組み合わさると（さらに5月6日20時40分に図書館を利用、タイムスタンプ情報が組み合わさると）どんどん対象は絞り込まれていきます。非常に尖ったそれ単体で個人を特定できる様な属性がなくとも、複数の属性が一致する人というのは少ないため、さらにそれを通常のTカード利用履歴データと照合すると、本人の特定ができてしまうと言う事です。
なお、私も武雄市の市政の問題と言うより、プライバシーやセキュリティの問題にのみ関心があるので、以下は架空の市「武雌市」を舞台としておきます。
武雌市立中学校に通う武雌太郎君(14)は、学校帰りに図書館に寄ることがあります。両親共に仕事が夕方シフトの仕事で帰宅も遅く食事も遅いので帰宅途中にあるファミリーマートで軽食を買って帰るのが日課です。
ある日、太郎君は図書館で本を借りました。この場合、図書館から出て行く情報は、仮に以下の様になるとします。
△月○日16時32分、14歳の市内在住の男性が、『暗黒神話体系シリーズ クトゥルー 第1巻』『這い寄れ!ニャル子さん(1)』を借りた。
次に彼はいつものようにファミマで買い物をします。するとこちらは以下の様な情報が記録されると思われます。
△月○日16:48分
会員IDxxxxxxxxx
購入品目
当然ながら後者のファミマの利用履歴にある会員IDを照合すると、登録時に申告した個人情報、氏名や年齢、住所、電話番号などと結びつきます。
この時、『時間16時台で、年齢14歳男性、武雄市内または周辺で使われたTカード履歴』と言う、図書館から得られる範囲の条件でTカードの利用履歴からデータを引き出してみます。利用状況にも寄りますが、この時点で確率的にそんなにたくさんが引っかからないと思われます。まず武雌市の14歳男性は国勢調査によると約300人でした。さらにこの中から、16時台に武雄市周辺でTカードを利用した人というのはどれだけのいるのでしょうか。
さらに「クトゥルーとニャル子さんを借りている事から、彼はオタクが好むアイテムを購入している可能性がある」としたとき、ヴァイシュスバルツ（アニメ・ゲームなどのキャラクターを題材にしたカードゲーム）を購入しているので引っかかります。こうなると、ほぼ間違いなく誰が借りたか特定ができてしまうでしょう。このオタク属性等と言うのはレアな属性でもなんでもありません。またこの他、例えばここで車好きでもいいし、スポーツ好きでもかまいません。そう言うありふれた属性で良いのですが、年齢と性別、時間と地理という条件が重なると、絞り込みの条件になって、特定がより簡単になっていくのです。
次に彼がまた同じ行動をとったとします。
図書館で本を借りて、ファミマで買い食いして以下の履歴が残りました。
△月×日16時28分、14歳の市内在住の男性が、『暗黒神話体系シリーズ クトゥルー 第2巻』『這い寄れ!ニャル子さん(2)』を借りた。
△月○日16:48分、会員IDxxxxxxxxx
購入品目
この時、前回と同じ条件『時間16時台で、年齢14歳男性、武雄市内または周辺で使われたTカード履歴』でTカードの利用履歴情報を引き出します。さらに、これを以前の記録の中から、ほぼ同一の行動パターンをとっている人物を引き出してきます。すると、ほぼ一人が浮かび上がってくるのではないでしょうか。
この時点で逆のアプローチが可能になります。つまり『会員IDxxxxxxxxがファミマを利用するとき、同一の属性の人物が同じ時間帯で図書館を利用している場合、高確率で同一人物である』と言う事が言えるようになります。これでファミマで利用が合った時、図書館から出された情報を検索すれば彼の利用履歴が作れる事になります。
さらに何回も似たような行動を繰り返します。するとどんどん彼の行動パターンができあがっていきます。行動パターンの積み上げにより太郎君を特定するための情報がどんどん積み上がっていきます。こうして積み上がった情報から、例えば彼がファミマを利用しなかったとしても特定が可能になっていくでしょう。「16時台に、同一シリーズのニャル子さん4巻を借りている。履歴から照合すると高い確率で会員IDxxxxxxxxの情報である」と判断することができる様になっていくのです。
武雌市内にある和平電機につとめている女性、小町花子さん(29)。在所は隣接する小町町で、勤務先の和平電機は毎週火曜日がノー残業デー、定時で退社する日と決まっています。協定でいつも1時間程度は必ず残業があるお仕事ですが、この日は17時に退社できるので、いつもこの日に用事を済ましています。
彼女は節約上手なのでポイントカードの提示を忘れません。Tポイントカードも例外ではなく、たくさんポイントを貯めるためにあちこちでポイントカードを使っていました。勤務先のある武雌市の図書館も利用しています。
この条件の場合、上記太郎君の場合のパターンでも特定が可能ですが、実はさらにそれより一発で特定ができてしまう可能性があります。それは、普段が彼女がTカードを使って作り上げた、行動パターンがあるから。
花子さんの利用履歴では、最近カメラのキタムラで高価なカメラを購入している情報、地元のTSUTAYAでカメラ関連の本を購入していたりする履歴があると、花子さんは最近カメラにはまっているようだ、と言う事が見えてきます。またガストではドリンクバーは2つのことが多いだとか行った情報から2人暮らしである事、一度名義を変更していることから結婚している事、ウエルシアでは愛犬用の用品をよく買っている事、などから犬を飼っている事、等々、どんどん情報が見えてきます。
△月×日17時20分、29歳の小町町在住の女性が、『デジタルカメラ入門 -2- 愛猫、愛犬を撮る』『なぜか夫婦がうまくいく3つの習慣―二人の危機を救う本』を借りた。
この時Tカードのデータベースから『デジカメ好きの30前後の女性、ペットを飼っている。既婚者』という検索条件で検索した場合、花子さんのTカード利用情報からの情報と、図書館の利用履歴の両方が抽出される事になります。
ここから、小町町の住人の29歳女性、と言うカテゴリで見ると、ほぼ間違いなく同一人物の情報だという事が分かる事になります。ちなみに小町町に在住する29歳女性は国勢調査によると約40人でした。
ここで彼女のTカードの情報には「図書館利用者である」という属性が蓄積される事になります。この後は豊富に蓄積された情報を元に、彼女の図書館利用履歴のトラッキングは比較的簡単に、高精度にできることになります。
武雌市に在住の、武雌和也さん(41)は、最近母親が難病にかかってしまいました。何しろ情報が無いのであらゆる手段を使って調べています。Yahoo!で検索して見たりしているのですが、欲しい情報が見つからりません。普段は全然利用していませんが、思い立って図書館に行ってみることにした。図書館では興味深い話を見つけましたが、情報が若干古いのでさらにYahoo!で検索をして新しい情報も仕入れたりもしています。ちなみに和也さんは、普段は奥さん任せでほとんど買い物などはしない人です。
和也さんの場合、ほとんどTカードを提示する機会は無い人ですので情報が少なくて照合などできないように見えます。が、ここで出てくるのがYahoo!IDです。和也さんは以前、Yahoo!で趣味の釣りの道具を購入したことがありました。その時、市が図書館カードとしてアピールしていた時に惰性で作ったTカードと結びつけを行っていました。
それによって、Yahoo! IDにTカードの情報が結びついている状態になっていたのです。
実はこのように、Tカードというのは非常に広範囲に利用域が広がっています。一度しか使ったことが無くても、使用した時に別のIDと結びつくような形になっているのであれば、TカードのIDそのものを利用しなくても、芋づる式に情報がつながってしまうと言う事が起きます。
Tカードは絶対に図書館以外で使わない、と言うのが一番シンプルです。図書館専用のTカードと、図書館以外のTカードを別けてもあまり意味がありません。Tカードによって記録されるデータベースに、図書館以外の部分で乗るような事をしてはいけません。従って、今、Tカードを利用している人が、図書館でTカードを利用し、尚且つTカードと図書館のデータを結びつけたくない人は、どちらかあきらめる事が必要です。図書館をあきらめるか、Tカードの利用を停止するか、どちらかになります。すでにTカードを利用しながら、結びつけたくない人は、図書館にて利用を開始する前に、一度CCCに個人情報保護法に基づく情報削除を依頼しておくことも忘れてはいけません。
おそらくこれらの指摘に対しては
情報分析については、コンピュータの大容量化、高速化によって不可能ではなくなりつつあります。近頃「ビッグデータ」処理システムなどを用いることによって実際に行われています。
これが「容易に」と言えるかどうかと言う事になるのですが、個人的な見解としては容易だと言って良いと思います。完全にデータベース上だけで照合が完結できてしまうと言う時点で、後はリソースの問題であるからです。コンピュータのリソースなどは数年もたてば倍にと言った世界です。そして毎回膨大なデータを処理しておかなくても、あらかじめデータをあらかじめ整理してあれば、許可を受けた店舗のマーケティング担当者レベルでも情報を引き出せるようになるでしょう。さらに言えば、観覧したい個人がすでに決まっていて、本人を知っている場合（標的を絞っている場合）はもっと簡単に情報を引き出せます。そこにダイレクトに個人を特定するID（名前も含む）が含まれているかどうかは関係ありません。
また情報を際限なく結びつける事を許さないので問題ない、と言う話についてはまず、Tカードの利用規約がすでにそれを許す形になっていることがあります。もちろん企業の内規等でそれができないようにしている可能性はあります。しかし、そこは行政が直接的に知る事も、コントロールする事もできません。何しろTカードの加盟店は膨大ですのでそれら全てに行政が行うべき情報保護に対する規律を求める事ができるのか、と言うと不可能でしょう。
であれば、共通的にTカードの規約を変更する等が必要になるでしょう。また技術的な原則論を超えて、特別な条例を作ってそれによってCCCを縛る事をするだとか、そういった政治的解決法はあります。しかし裾野が広いだけあって、規約だけでは駄目で、実際には不可能な形にしておかないと不十分である、と私は思います。
これはプライバシー問題の特殊さ、難しさが絡んでいます。プライバシー問題の難しさは、観覧された時点ですでに侵害が発生しており、さらに原状回復が不可能である（予防しかない）事、さらに発覚しにくいためです。
ちなみにこれは、公共サービスをそのような民間ベースのID認証に付け加えると、毎回このような情報の取り扱いについて問題が発生していくことになりますし、それらが適正に処理されているかの確認は行政側が行わなければなりません。住基ネットの住民票コードが民間利用禁止されているのもこう言った難しい問題があるからです。
次に「これらの事は民間ではすでに当たり前である」という話もあります。何を今更、と言う事ですね。これは全く持ってその通りで「俺はそうであっても気にしない」と同じような立場になります。しかし、事問題が行政サービスに関わる事であると言う事を忘れてはなりません。また、気にする気にしないと言う話は本質的には個人情報かどうかには直接関係はしないと思います。
もはや落としどころとしては、Tポイントカードを単なるユニークなIDが振られたカードとしてのみ図書館で利用する形にするしかないと思います。情報の流れを一方通行にする。図書館側からは一切CCCに情報を渡さない事ですね。
ではポイントの付加はどうするのか、と言う事になりますが、これはあきらめるか、さもなくば独立したシステムでポイントを加えるしかないでしょう。これでも「このIDは図書館を利用した」という情報は発生することになります。これも解釈によっては個人情報ですが、独立したシステムにすることによって、情報を渡したくないからポイントをつけない、と言う選択肢も可能にするべきです。当然Tカード以外のカードでも利用可能になっていないといけません。
こうなると「図書カードとTカードを別々に持つ必要がない」程度しかメリットが残りませんが仕方が無いでしょう。
最後に。セキュリティ論じゃないところに踏み込むと…正直CCCが戦略を誤ったとしか思えませんね。Tカードの話なんか出さなけりゃ良かったんですよ。あとポイントも。分かり易いメリットのつもりで市長に売り込んで、市長がそれを大々的に宣伝してこうなったのです。本を買わずにレンタルで済ます層の情報に商売としてのうまみがそれほどあるとは思えませんし。CCCグループはTSUTAYAを始めとした幅広い販売チャンネルから得られるPOS情報に、自前の取次MPD、流用出来るノウハウなども多数持っているんだからそっちで責めれば良かった。その上で競争入札に入れば良かったんですよ。
確かに「Tカードを全面に出さなければならなかったと言う事は、その他のメリットがなかったためでは？」と言う話はありますけど、それならば他の既存の業者を選んだ方が市のためになるわけですから今より悪い事にはならないはずです。
最近はやりのビッグデータでもてはやされている大規模分散処理にマジで興味ない。びっくりするほど興味がない。
あれを楽しそうにやってる方々は何が楽しいと思ってるんだろう。
こんな書き方しておいて教えてくれる人がいると思うんならコミュニケーション能力がなさすぎだよ。
『分析対象のデータ量は年間約100ギガバイト、約2億レコードに及び...』
この数ヶ月「ビッグデータ」という造語をIT系雑誌でよく目にするが
こういう分析が対象だったわけか（少なくとも大いに含まれてるだろう）。
ネットを利用するときに気をつけたいこと - ぼくはまちちゃん！(Hatena)
http://d.hatena.ne.jp/Hamachiya2/20120228/social
情報は紐付く
最近東日本の元国鉄の会社でCMやってるんだけどちょっと腑に落ちないんだ。
要は「ビューカード一体型suicaにすりゃ、便利だしポイントたまりまっせ。」とよく聞こえる。
でもこれをやることで、定期券に記載されている名前と年齢と電話番号以外にも様々な情報がsuicaにひもづけられてしまうことに気がついて欲しい。
尊敬する高木先生がPASMO関連でakkyよろしく派遣できていたサポセン素敵女子をいじめていたそのころ、ペンギンの会社は紐づいた情報で水を売っていた。
JR東日本子会社が2億件のビッグデータで商品開発、「移動中に飲む水」訴求 - ニュース：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20120125/379281/
VT-10では単品・時間別売り上げが把握できるのに加え、Suica（スイカ）などの電子マネーカードを利用した場合は、カード固有番号（IDi）を基にリピート購買の回数が分かる。さらに、Suicaポイントクラブ会員（約140万人）については、入会時に登録された性別や年代、居住エリア（郵便番号）を把握できる。
（VT-10ってのは、自販機についてる黒くて大きい方のカード受信機ね。）
Suicaポイントクラブなら上記の情報が紐付く。ビューカードならさらに信用情報まで紐付けることが可能だ。約款には書いてないかもしれないけど、改定されちゃったらできる。約款なんて読まないし。
この記事では水だったかもしれないが、Suicaは最近どこでも使えるから行動範囲や趣味嗜好までペンギンにはお見通し。悪用なんて、しないよね？
・どうしてあの家電量販店はカードを提示すると10%ポイント還元されるけど、よくわからんクレジット付きカードへのアップグレードを提案するのだろうか？
・どうしてコンビニでもどこでも青と黄色のカードがあるか聞かれるのだろうか？そしてどうしてあのカードは免許書の提示がないと入会できないのだろうか？
コードのメモリのフットプリントという意味なら、CPU内部にキャッシュがあるCPUについてはコアなアルゴリズムをキャッシュの中に乗り切るようにすることによって高速化はする。これは効果があるがあまり適用されるケースがない。
次に一般的に言われるデーター構造の利用効率だが、これは実はこの分野は大富豪的プログラムでいい。理由はメモリのハード的特徴。メモリは中途半端に７０Mとか９０Mにするほうが難しい。６４M１２８Mのほうが簡単。
だから、増やし方は2倍 2倍。が簡単。エルピーダが逝ったように廉価販売の嵐というのも相まって、OSが256ぐらいつかうからという理由で512M積むというのも当たり前になってきてる。
残念ながら100M級でメモリが空いていれば データー構造で詰まるということはないだろう。
確かにメモリをけちれば消費電力が下がるが 設計上 メモリをケチる構造はCPUに負荷がかかるのでCPUの消費電力のロスのほうが大きいと考えるのが今風。
それにデーターを圧迫するのは大抵は画像や音声や動画などのコンテンツ。
データが圧迫するのはビックデーター系だが・・・これまた、ビッグデーターで処理という流れのほうが大きくて もしくはSQLの固有技術やサーバーの設計技術という話になってきてプログラム単体の話からそれてくる。
だいいち、どちらかというとメモリ利用効率じゃなくてCPU効率だしな。
最後に残るのは組み込みのマイコン級CPUだが、もはや別次元すぎる。
というわけで、メモリに関しては富豪的プログラムでいいと思うよ。量のあるデーターに対して ざるくバケツソートとかそういうことじゃなければ。
ただ、それも仰るとおりCPUが速くなれば、バッテリーが進化すればすべて解決。あとは、誰にでも簡単にプログラムできるようになって、高レベルプログラマが今より不要になる。栄枯盛衰だね。
だから、CPUのことを時にするのばバカだといわれれば、まぁ、世界規模で見ればそのとおりだ。
消えろってうん、ごめん。
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にせよ、収益化の原動力はユーザ行動解析だったりするわけだ（彼らがオープンソース化に積極的なのは、インフラ技術が差別化の源ではない、という面もある）。
まぁ、あとはガチャだが、どちらにせよ現状では高木先生の逆鱗に触れるようなものしかないよね。
そんなわけで、それらに代わる第四のマネタイズモデルを思いついた人は、ぜひ近藤さんに教えてあげると良いんじゃないかな。あればだけど。
今後はてながどうなるかは分からないけど、一つ希望したいことがあるとすれば、故伊藤計劃氏のダイアリーがこの先も保全されることを望みたい。
それは、エントリを全て魚拓しろ、という話ではもちろんない。彼の生前に書かれたエントリは、当時の「はてな」という生態系を構成する一部でもあるわけで、そこから切り離して文章だけをアーカイブしてもあまり意味がない。
