 
|
はてなキーワード: APIとは
「ステログ」って、今回問題になったＰＲ会社による火消しステマなんじゃないだろうか。
というのは、ステログは、「レビュー数が少なくて、高得点をつけてる人」をあぶり出してるんだけど、食べログもさすがにそんな作戦にはとっくに対処していて、そういう場合は点数が上がらないように、もともと作られてるんだよね。つまり「ステログ」であぶりだせるのは、素人による「自作自演」だけなんだ。プロモーション会社が有料で引き受けて、巧妙に点数を上げてるような事例、つまりレビューを数多く投稿していて点数に大きな影響を持つユーザを事前にじっくり作っておいて、そのユーザに高得点をつけさせるような作戦は、華麗にスルーされてしまうんだ。
もちろん、そこまで悪意なくておもしろ半分にやってるだけかもしれないけど、一番注意した方がいいのは「ガチヤラセ？？」って赤文字だけ見て喜んでる人ね。それ、ステマに騙されてる可能性は高いと思います。
そもそも。
「食べログ」って、レビューを書き込んだユーザーの「レビュー書き込み数」とかを単純に返すAPIとかないので、「ステログ」の会社は、自社製のクローラでデータ収集してるんだろう。ま、それは別に悪いことじゃないんだけど、そんなクローラまで作ってる会社が、食べログの採点の仕組みの基本を知らないってのは腑に落ちない。
あんまり関係はないんだけどこの記事を受けて。
■Google＋が作る「繋がりによる検索の世界」が侵食するSEO,SEMのこれから
googleが目指すべきは、facebookではなく「はてブ」だと思う。
その先を目指してくれ。
そのクラスタによるキュレーションを反映した検索結果じゃないか。
ざっくりいってしまえば
に応える検索。
今は意外にこれが難しい。
その記事のタイトルっぽいワードをいれてもさっぱりあがってこないのな。
ここがうまくいけば、ブクマしてても、し忘れててもどっちにしてもgoogle検索で
その記事にたどり着くという遷移ができる。
google+が向かうべきは、「だれもがまずそこにログインする」ような
コミュニケーション重視のSNSじゃなくて、+1しておいてあとで読むとか
記事に対する軽いコメントや議論ができる、まさにはてブのような機能とか、
使いやすいオンラインブックマークとしての機能に、ソーシャル要素をがっちりと盛り込む
ことじゃないか。
「webページに対する言及や、キュレーション()を前提としたコミュニティ」
NAVERまとめ()みたいなページつくれる機能をいれてもいい。
・+1スクリプトレットに、はてブ、facebook、twitter等への投稿機能をもたせて展開
・ブックマークの傾向により、暗黙クラスタを形成する(google様ならできるだろ)
このあたりのアルゴリズムは本領のはずなのでなんかうまいこと考えてくれ
・その結果が検索結果に反映されると言いはる
これで勝てる。
今のブックマークは昔と違って、「よく行くサイト」とかじゃなくて、
「あとで読む」「だれかと共有しよう」とかそんな理由で気軽にされるものなわけで、
それと検索結果への反映はものすごく親和性が高くて、そしてこれはgoogleにしかできない。
だいたい目的がコミュニティの形成ではなくて、最終的には検索を使ってもらうことなわけだ。
なんでGoogle Bookmarksをこんな状態で放置しているのかｗ
個人的には、検索結果に顔がでてきて、この人も+1してますってのはまぁわかるんだけど
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サービスを、サービスインさせて頂きました。
一般に公開されていて、誰でもアクセスできる情報でも、ニーズが有りそうな切り口の条件で検索性を高めれば、新しい価値を創造できるんじゃないかという実験です。
もしよろしければ、ぜひ、使ってみてくださいー。それでは！
----------
先日「Flashエンジニアが今後10年食べていくには？」というテーマを元に
Flash に精通した Web 技術者達のディスカッションが行われる催し物があった。
http://www.publickey1.jp/blog/11/flash10.html
この記事だけでは内容が省略しすぎているため
時間があれば是非録画の模様もみていただきたい。前半初頭は音量が小さいので注意。
こういった催し物は面白いなと、私はとても楽しく見させていただいた。
http://www.ustream.tv/recorded/19073524
http://www.ustream.tv/recorded/19074357
ディスカッションでは Flash だけではなく HTML5 についても触れている。
ディスカッションの感想をディレクションや営業を行なっている知人に聞いたり、
ネット上の反応を見てみたところ以下のような意見がいくつかあった。
「『Flash が好きな人』だけではなく HTML5 派の人との対談もあればよかった」
「Flash 派の人の話だから HTML5 が使えないという話はいまいち参考にならない」
『Flash 派』『HTML5 派』という くくりで考えてしまう人は
まだまだ多いと実感する。
パネリスト達は
過去から現在までに様々なプログラミング言語を利用し、あらゆる技術に精通している。
Flash という表示媒体/環境開発がベター(時にはベスト)だと考え、
Flash をよく扱っている、という旨を話している。
最後の締めとして
Flash よりも優れたものが登場するのであればそちらに移行するでしょう、
とも言っている。
これだけの説明があったのに
ディスカッション内で触れた HTML5 に対する否定的な話は、
『Flash 派』とやらのポジショントークだと目に写ってしまったのだ。
Java やら C やら objective-c やら perl やら php やら
サーバサイドからスマホ用ネイティブ言語を用いてのアプリ制作まで
色んな事やってます、と言っても
現在世の中には HTML5 を推し、合わせて Flash を否定する記事が結構出回っている。
技術者が話す専門的な用語の飛び交う話よりも
HTML5 vs Flash 的な読みやすい記事に耳を傾けてしまう人はいる。
Apple 製品を好む人は「ジョブズがそう選択したのだから」と
なおさらこういった記事に目を向けてしまう。
「Flash vs HTML5 の話にのせられてしまうのは、よくわかっていない人だ。」
ディスカッション内では、
ネット上の煽り記事を読み不安に思ったクライアントから連絡を受け
きちんと状況をゼロから説明するハメになってしまった、という内容があった。
似たような状況になっている人もいるのではないだろうか。
当方周辺では、
「Flash は駄目だ」「Flash でなくても HTML5 ならできるはずだ」
「HTML5 は Flash の代わりになるものだと言われている」と
クライアント、あるいは仕事先の関係会社から耳にする機会が増えてきた。
技術者の及ばないところで
ベターではない技術が選択、あるいは勧められてしまう やっかい性。
その記事は世間の目には届かない。
TV CM でバンバン流れている iPhone や iPad では Flash を見ることができない
という状況に乗じた
勘違いを正すためには、今までよりもより一層
あるいはメッセージを発信するよう心がけていかねばならないと感じる。
パネリスト達のような
Flash を扱う事が可能な技術力を持ち合わせている人にとって
Flash が終わろうが、代わりの技術が HTML5 やらその他何になろうが
大した影響はない。
『プログラミング』についての話をしてみる事にする。
「世にあらゆるプログラミング言語があるが
「何か一つ言語を習得し
『Flash の事は全く知らないがプログラミングプロフェッショナルの人』
が近くにいるならば是非上記について伺ってみてほしい。
その通りだと答えてくれるはずだ。
他の言語で作ったものを Flash のプログラミング言語に移植することも容易いのだ。
ここで上記三行の「他の言語」を「JavaScript」に置き換えてみてほしい。
HTML の DOM 操作に必要な言語は JavaScript である。
言語は、Flash ならば ActionScript、HTML5 ならば JavaScript を用いる。
画面描画は
あるいは用意されている描画用 API を ActionScript で呼び出し、
あるいは用意されている描画用 API を JavaScript で呼び出す。
Flash と似たような技術として Java Applet や Shockwave があるが、
これらも一緒で
言語を変え、その技術に合わせた描画を行う処理を記述するだけだ。
Web 技術者が何かに属していて、何かには属していないかのような区別の仕方は
的がはずれている事を なんとなく感じていただけただろうか。
仕事に対し、あるいは表現したい事に対し、ベターな選択を行うだけの事なのである。
環境や表示内容に合わせ両方を採る選択もあるだろう。
パネリストの中に ActionScript が好きだ、という人がいた。
これは別に
Flash が好き(製品のファン)だから ActionScript が好き、と言っているのではない。
ActionScript が優れたプログラミング言語だと判断しての発言なのだ。
HTML5 を選択するだけの事であり、
その別の技術を選択し、
Flash より優れた技術が登場しなければ Flash を使い続ける、
ただそれだけの事なのである。
もう少し突っ込んだ話をすると
Flash のプログラミング言語である ActionScript(ActionScript 1.0)と
HTML 表示制御を行う言語 JavaScript は 実は同じ言語仕様である。
『ECMAScript』という単語で調べてみてほしい。
「Flash と HTML5 は対立するもの」と考えていた人、
あるいは ActionScript や JavaScript を触れたことがない人にとって
「え？そうなの？」と思う人もいる事だろう。
JavaScript は大規模開発に向いていない、という話は聞いたことがないだろうか。
同様の言語仕様である ActionScript 1.0 はこの問題を解決するため
ActionScript 2.0 から ActionScript 3.0 へと進化していった。
Flash は開発がし易い、という話がよく挙げられるが
その理由の一つがこれである。
現行の JavaScript と ActionScript 1.0 は ECMAScript 3 準拠に対し、
ActionScript 3.0 は ECMAScript 4 準拠である。
言語として進化しているものを Flash は採用しているので
開発は抜群にし易い。
ECMAScript 4 準拠の JavaScript も登場する日もあったかもしれなかったのだが、
ECMAScript 4 標準化が白紙、
ECMAScript 4 は無かったことになってしまったのだ。
ActionScript 3.0 で作成したプログラムが
ちなみに JavaScript は大規模開発に向いていない、という事に対し、
最近では Google が新言語 Dart というものを開発している。
位置づけとしては ActionScript 2.0 に近いと比喩した人もいる。
ActionScript 2.0 はコンパイル時 ActionScript 1.0 に変換されて出力される。
Dart も同じく JavaScript 変換機能を持つ。
先の事は誰にもわからない。
HTML5 が成長するとは必ずしも言えない。
技術者は身を持って知っている。
表示と動作の差異、技術者はずっと苦しめられてきている。
めんどくさい。コストがかかる。
HTML5 も同じ道を辿るのでは、と言われてしまうのも仕方がない。
実際に HTML5 の各ブラウザの実装具合はバラバラである。
Flash はといえば、
今でも 10年以上前のスクリプト言語 (ActionScript 1.0 よりも前の言語)で
Flash が動作するブラウザがいつまで携帯に搭載され続けるのか、
まだ誰にもわからない。
今後も当面携帯向け Flash を作り続ける事になるのかもしれない。
携帯向け Flash は一つの容量が小さいというのが救いである。
IE6 対応 HTML サイト制作にせよ、携帯向け Flash 制作にせよ
状況に応じて何を選択するかを判断できるほどの技術力を身につける事
選択する技術に何ができて何ができないのか、
どの技術を組み合わせるとよいのか、
自ら判断できるようになった時、一人前の Web 技術者になったと言えるだろう。
一つ何かをモノにしてしまえば前述の通り移行は容易い。
それを極めるくらいまでとことん勉強してほしい。
続けていくと見えてくるはずだ。自信という名の悟りの道が。
気になった点をいくつか。
現状の HTML5 の実装具合のバラバラさに対し、
「(HTML5の)表示の差分を埋めてくれる何かが登場するかもしれない」
と言う発言があった。
言った当人も会場にいる人達も、きっとこう思っただろう。
「それってなんて Flash Player？」と。
「あれはやめたほうがいい」という発言があった。
勝手に注釈するのであればこの発言は
「Flash で作られた重たい Web を HTML5 でまた再現するつもりなの？」
という皮肉であろう。
これは規模じゃなくて難易度の話だろ
難易度の話をするならCで言うポインタの理解なりの例えがあるんじゃないか？
javaだとなんだ、、、オブジェクト指向なコード書けることか？
元増田に話しとくとjavaで開発するにもHadoop、strutsやらのフレームワークや
jspなどなど色々ある
Androidアプリはその中じゃそんなに難しい部類ではないと思う
別の言語使ってもAPIやらフレームワークやらOSやら言語以外の知識と理解は山ほど必要だ
別の稼ぎ口があってプログラマが向いていないと思うなら、今なら遅くないから
引き返したほうがいいな
似たように苦しむ事が多いが腹をくくってる
数式処理しか分からないけど、maximaとかmathematicaで検索するといいよ。
特にmaximaは無料で扱える数式処理ソフトだし、mathematicaは高機能でアカデミックな場で利用されている上にp2pに流れている（絶対に違法ダウンロードとクラックはするなよ！）。
API制限があるけどmathematicaの派生でこっちを利用するのも手。積分もできるよ。http://www.wolframalpha.com/
英語、国語のテスト自動生成はテンプレート文を組み合わせたり穴埋め問題生成みたいな労力は掛かるけど単純な課題に使用するんだと思う。
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が切り捨てたバージョンは切り捨てて良い(というか切り捨てるしかない)のでやっぱ考え方として楽。
今月も増田への投げ売り堂の10月の結果と雑感を書き込みます。今日は長めになりそうで。
| 項目名 | 10月 | 9月 | 増減 |
|---|---|---|---|
| ユニークユーザー | 4524 | 1983 | +2541 |
| ページビュー | 18736 | 8777 | +9959 |
| 平均ページビュー | 1.40 | 1.60 | -0.20 |
| 平均滞在時間 | 2.47 | 2.59 | -0.12 |
| 新規訪問数 | 27.45% | 29.90% | -2.45％ |
詳細はいつものように以下の Analytics の PDF に書いてあります。
今月は引き続き Amazon の仕様変更の対策と若干の機能追加に終始しました。
Amazon の仕様変更も殆ど問題無く修正でき、エラー等もありませんでした。
フィギュアだけ対応してたのですが、DVD・BDとゲームも対応をしました。
特撮DVD・BDは「keywords」ゲームは「Node」でそれぞれ10ページづつ商品を辿るようにしています。
ゲームはさほど商品の差は感じませんでしたが、DVD・BDは商品数が1/4くらいに・・・。
個別ページで Amazon レビューを確認できるようにしました。
とはいえ、API からそのまま iframe に張っているだけなのでいつでも出せるような機能で
今回の仕様変更で出品者情報が殆ど取れなくなった分、他の商品の情報を載せようと思い設置しました。
一応予定しているのが「アニメDVD・BD」復活と「PC関連商品」を新たに追加し
cookie で保存の表示商品を切り替えるオプションを設置する予定です。
API制限云々があるおかげでこういう話が出てくる
私も有料化自体に反対するわけではないが…断言しよう、絶対に"面倒臭い"ユーザが増える
こういう場合に挙げられるのは大抵"お金を払っていない層"だと考えがちだが、真に面倒臭いユーザはむしろ金を払っている側である
既に無料有料ユーザが住み分けられているコミュニティを見れば明白だ
・乞食が～とか言い出す
・上のような話題が一通り出て落ち着いたら、課金ユーザが思い出話としてネタ化する
・ネタ化したら課金ユーザ無敵、無課金ユーザは一切口を出せない状況に追いやられる
最終的には先細りして終了
そんでもって、 Microsoft は持っている。僕同様、みんなも知ってると思うけど、なんと驚くべきことに、 Microsoft はそれをよく理解していない。実に。でも彼らは、純粋に、偶然、プラットフォームを提供するビジネスから始まって成長してきたから、プラットフォームを分かっているんだ。彼らはその領域で30数年やってきた。 msdn.com に行って、少しの間ブラウジングしてみればわかる。もし見たことが無ければ、驚く準備をしておいた方が良い。なぜならそれがとてつもなく巨大だからだ。何千の、何千の、何千もの API コールがある。彼らは巨大なプラットフォームを持っている。実際の処大きすぎて、全く統率が取れていないけれど、少なくとも彼らはやっている。
Amazon は自分のものにしている。 Amazon の AWS （ aws.amazon.com ）は途方も無くすばらしい。行ってみてご覧よ。クリックして回ってみるんだ。全く恥ずかしくなる。僕らはこれらのひとかけらも持ち合わせていない。
Apple も、明確に、自分のものにしている。彼らは基本的にクローズな選択を、特にモバイルプラットフォーム周りでしているけれど、アクセシビリティを理解しているし、サードパーティ開発者の力もよく分かっていて、自分たちのドッグフードを食べている。それでさ、わかるだろ？。彼らは実に見事なドッグフードを作る。彼らの APIコールは Microsoft のそれに比べて実にクリーンで、ずっと昔からそれを維持している。
Facebookも持ってる。だからこそ心配になるんだ。ぐうたらな僕をここまでして書かせた理由はそれだ。僕は元来ブログするのも、プラスする（って言うのかどうか知らないけど）のも嫌いだ。そもそもGoogle+はぶっちゃけ話をするのにはひどい場所だけど、とにかくやらなきゃならない。Googleに成功して欲しいと思ったらね。で、僕は成功して欲しい！。まあ要は Facebook が僕を呼んでいるし、きっとそっちでやるほうがずっと楽なんだろうけど、Google は僕にとって家だし、だからこういう家族同士のお節介焼きのようなことをやっていこうよと言ってるわけだ。（訳注：この辺の訳怪しい。トラバで指摘いただいたのがすてきだったのでまるっと差し替え！。"アドバイス" thx ！）
Microsoft と Amazon 、それに Facebook （たぶん。実際僕はよく見ていないんだ。だってすごく落ち込むからね…）の提供するプラットフォームに驚いた後に、 developers.google.com に行ってちょっとブラウズしてみて欲しい。ね？大きな差だろう？。まるで君の5年生の甥っ子が、巨大で強力なプラットフォーム企業がもしリソース的に独りの小学5年生しか人を割けないって時に作るようなものをデモしてみなさい、なんていう宿題でもでっち上げたみたいな感じだよ。
どうか悪く思わないで欲しい。 Developer relations チームが、これを外部に提供できる形にするためにとんでもない努力をしてきたってことを僕は分かっている。僕が知る限り、彼らはとにかくケツを蹴り上げつつけている。なぜなら彼らはプラットフォームを理解しているからさ。プラットフォームに対して実に冷淡で、しかも時には敵対心さえあらわにされるような環境の中で、彼らは英雄のように努力している。
僕は率直に、 developer.google.com が外部の人にとってどう見えるかを説明しているだけさ。全く幼稚に見えるだろう。 Maps API は一体どこにあるっていうんだ？。いくつかはなんだかよくわからないラボプロジェクトとやらに入っている。で、いざたどり着いてみれば、そこにある API は全くけちな代物だ。まさに本当の意味でドッグフードだ。オーガニックなんかとは無縁だね。僕らの内部 API に比べれば、まるで不格好な別物だよ。
Google+ についても、悪く思わないで欲しい。到底彼らだけが違反者ってわけじゃない。文化的なものが絡んでいるんだ。僕らが内部でやってることっていうのはさ、基本的には、惨めでマイノリティなプラットフォーム部隊が、無敵で予算も自信もたっぷりのプロダクト部隊に多かれ少なかれ負け続けている、そんな戦争なんだよ。
ゼロから構築したプログラマブルなプラットフォームになるべきなんだってうまく気づいたチームってのはみんな弱者さ。 Maps や Docs なんかが思い浮かぶ。 Gmail もなんとなくそっちの方に進みはじめたように見える。でも彼らがそのために予算を獲得するのは実に難しい。なぜなら、それは僕らのカルチャーじゃないんだ。 Maestro の予算なんか、 壮大な Microsoft Office プログラミングプラットフォームの足下にも及ばないちっぽけなものだ。ふわふわ毛皮のうさぎちゃんと、 T-Rex の対決みたいなものさ。 Docs チームだって、このスクリプティング機能が無ければ Office に太刀打ちできないってのはよく分かっているんだ。でも残念なことに、予算が付かない。つまりさ、そうじゃないとは思うんだけど、現状 Apps スクリプトが Spreadsheet だけで動作して、 API の一部としてキーボードショートカットすらない。まさにチームが愛されていないって思うしか無いよね。
皮肉にも、 Wave は偉大なプラットフォームだった。冥福を祈りたい。でもプラットフォーム的な何かを作るっていうことは、そのまますなわち成功を意味するって訳じゃあ無い。プラットフォームにはキラーアプリが必要だ。 Facebook そのもの（つまり、 wall やら friends やらなんやらというデフォルトの機能）が、 Facebook プラットフォームのキラーアプリだ。そして、 Facebook アプリが、 Facebook プラットフォーム無しで成功できると結論づけるのは、深刻な誤りだと僕は思う。
みんなは、外の人たちが Google は傲慢だって言い続けているの、知っているよね？。僕は Googler だ。だから、みんなと同じように、外の人たちがそう言っているといらいらとする。僕らは全般的に見て全く傲慢じゃ無い。僕らは、まあ、99%は傲慢じゃない。僕はこの文章をこう始めた（遠い記憶をさかのぼってよ）、 Google は「正しいことだけをする」って表現した。僕らはよかれと思ったことだけをしている。だから、人々が僕らが傲慢だって言うときは、まあ大抵彼らを雇ってあげなかったときか、僕らのポリシーに不満があるか、まあそんなようなところじゃないかな。彼らはそれで気分が良くなるから、傲慢だ傲慢だと言っているんだろう。
でも、もし僕らが、僕らは全ての人に対して完璧なプロダクトをデザインする方法を知っているだなんて、そんなスタンスを取るんだとしたら、僕を信用してくれて良いと思うけど、結構そういう話を聞くんだけど、僕らは飛んだ間抜けになる。それを傲慢って言ったり、無邪気さって言ったり、なんて言ってもいいけど、結局の処、それは愚かさに他ならない。全ての人にとって完璧なプロダクトなんて、無いんだ。
デフォルトフォントサイズを設定できないブラウザについて話してこの話題を締めくくろうか。アクセシビリティへの侮辱ってやつについて語ろう。つまり、いずれ僕は年を取って、ほとんど目が見えなくなる。事実そうだと思う。僕は人生でずっと近視だったし、40歳にもなれば今度は近いものが見えなくなる。そうなればフォントの選択ってのは生死を分ける重要なポイントだ。それは君を完全にその製品から追い出してしまう。ところがどっこい Chrome チームってのははっきりと傲慢だから、彼らはゼロコンフィギュレーションプロダクトなんて言ってて、まったく厚かましくも、もし目が見えなかったり耳が聞こえないなりなんなりするなら、お前はファックユーだぜってなもんだ。残りの人生、全てのページを表示する度に Ctrl-+ を押せって言うんだよ。
これは彼らの問題じゃ無い。みんなの問題だ。僕らが徹底してプロダクト企業だということが問題だ。僕らは広くアピールするプロダクトを作った。例えば検索がそうだ。そのあまりにもひどい成功が、僕らの目をくらませてしまった。
Amazon もまたプロダクト企業だった。だから。 Bezos にプラットフォームの必要性を理解させるのには、外部の力が必要だった。その力ってのはどんどんと蒸発していく利幅だった。彼は追い詰められて、脱出方法を考えなければならなかった。でも彼の持ちえたものは、エンジニア達とコンピュータの群れだった。そこからどうにかマネタイズするには…？。結果論だけれど、そうして彼は AWS にたどり着いたわけだ。
Microsoft はプラットフォームとして始まった。だから彼らにはたくさんの習慣があった。
でも、 Facebook は…、彼らは僕を不安にさせる。僕はエキスパートではないけれど、でも、彼らは最初プロダクトとしてスタートして、そしてそれをうまく成功につなげていたことは確かだ。だから、彼らがどうやってプラットフォームへと変革を遂げたのか、僕にはわからない。それは比較的昔のことだったろうと思う。 Mafia Wars のようなものが現れる前に、彼らがプラットフォームにならなければならなかった時よりもずっと昔。
たぶん彼らは僕らを見て、こう自問したのかも知れない。「どうやったら Google を倒せる？。 Google に足りないものはなんだ？」
僕らが直面している問題はとても大きい。僕らがキャッチアップを始めるには、めざましい文化的な改革が必要だ。僕らは内部的にもサービス指向なプラットフォームを持っていないし、同じように外部的にもそうだ。この「自分のものにしていない」感じは、まさに会社全体を覆う風土病だ。 PM は分かってない。エンジニアも分かってない。プロダクトチームも分かってない。誰も分かっていない。たとえ一個人で分かっている人間がいたとしても、もしそれが君だとしても、僕らがそれを総力を挙げて緊急事態として扱わなければ、これっぽっちも意味が無いんだ。僕らはプロダクトをローンチして、それを後から魔法のように美しい外部拡張可能なプラットフォームに成長させられる、そんなふりをし続けることを、やめなければならない。何度もやって、だめだったじゃないか。
プラットフォームの黄金律「自分のドッグフードを食べろ」はこう言い換えることができる。「プラットフォームから始めろ。そしてそれをなんにでも使え」（訳注："アドバイス" thx ！）。後からちゃんとやるなんて不可能だ。少なくとも、簡単には無理だ。 MS Office をプラットフォーム化した人たちに尋ねてみればいい。あるいは Amazon をプラットフォーム化する為に努力した人たちに。遅れてしまえば、正しく立て直すのに10倍の苦労が必要になるだろう。ごまかしはできない。内部アプリが特別な優先アクセスを受けられるようなバックドアを秘密に仕込むなんて、どんな理由があっても不可能だ。難しい問題から、まず最初に解決しなければならないんだ。
僕は遅すぎると言いたいわけじゃ無い。けれど、待てば待つほど、致命的な遅れへとどんどん近づいてゆく。
この記事をどう纏めて終えればいいか、正直よくわからない。言うべきことは全て言ったと思う。この記事はできあがるのに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 になる必要はないっていうことを。インターフェースとワークフローこそが、人々が気に入り、安心感を得るものなんだっていうことを。彼はサードパーティの開発者にそれを可能にするだけで良かった。そうすれば、後の事は自動で進んでいく。
僕の言っていることが、あまりにも明白なことだろって感じているみんな（多かったらいいな）には申し訳ない。とにかくもうびっくりするほど自明なことなんだ。ただ、僕らがそれをやってないってことを除いてはね。僕らはプラットフォームを理解していない。プラットフォームを持っていない。アクセシビリティを理解していない。アクセシビリティを持っていない。これらは基本的には同じことだ。なぜならプラットフォームがアクセシビリティを解決するからだ。プラットフォームがアクセシビリティなんだよ。
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 が見つけた個別の発見や教訓があった。外部サービスにはおかしなところがいくつもあったけれど、君たちが考えるほどじゃあない。サービスに対して組織するってことは、外部のデベロッパを信用できないのと同じように、お互いを信用することなんてできないんだということを、チームに教えてくれたんだ。
いつものように増田への投げ売り堂の9月の結果と雑感を書き込みます。今日は長めになりそうで。
| 項目名 | 9月 | 8月 | 増減 |
|---|---|---|---|
| ユニークユーザー | 1983 | 690 | +1293 |
| ページビュー | 8777 | 3086 | +5691 |
| 平均ページビュー | 1.60 | 1.89 | -0.29 |
| 平均滞在時間 | 2.59 | 1.33 | +1.26 |
| 新規訪問数 | 29.90% | 31.79％ | -1.89％ |
詳細はいつものように以下の Analytics の PDF に書いてあります。
ごらんのとおり、アクセス数とユーザー数が伸びていますが、それ関連で色々やったこと。
リリース後にすぐに載せたんですが、そこまで効力が無く・・・。一回沈んだらそのままな感じなので仕方ない感じでしょうか。
これが一番やり方としてはダメですが、一番伸びた大きい要因でした・・・。
12日以降に定期的に投げ売り堂の URL をそれなりに関係があるかもしれないところに張って・・・。
申し訳ないと思いつつ、手っ取り早く広める。というのは素人にはやっぱりこれが一番なのかなと再確認をした感じです。
そもそも手っ取り早くな事を考えているのが甘いんですが。
今月の10/26から適応される、Amazon Product Advertising APIの仕様変更
の対策を全くメールを見てなかったので失念していて、ItemPage をガッツリ使っているこちらとしては、このままでは存続自体が危ない感じなので対策をしました。
まずはフィギュアだけなんですが、ItemSearch の際に KeyWords を使って複数検索をかけるように変更しました。
・「1/4」などのスケール
・「PVC」などの素材
これによって、ItemPage が400→10件に減らされても品揃えは遜色ないように出来ました。
DVD・BDとゲームもあるんですが、もう少し工夫をして今と同等にしようと思います。
しかし今回の API 仕様変更は困る人が多いんだろうなぁ・・・。
この辺で詳しくは述べてますが、料金は抑えることが出来そうです。
今月はサービスに直結する対策を色々とやりました。
サービスの拡張はやれなかったですが、存続の危機になりかねない事だったので色々と勉強になって結果良かったなーと思っています。
これから株を始めたい人がチェックすべきサイト５選というサイトを見かけた。
自分は株売買は7年前から続けていて、同じテーマで書きたくなった。
Webじゃなくて購読すること。
株価欄を毎日ざっとみていくとよい。毎日見ると上がり続ける銘柄、下がり続ける銘柄に気づく。
●日経新聞の景気指標欄
毎週月曜日発行分（休刊日なら火曜日）に日経の真ん中辺りに挟まっている。
日本、アメリカ、ヨーロッパ、アジアのマクロ経済の数字が新聞1ページ分に並んでいる。
一見何気ない数字の羅列だが、相場の空気を読むために必要なマクロの数字がこれだけ小さな
スペースに圧縮されているのを他にない。1〜3月期の日本の実質GDPはいくらか？、というのは
自分は毎週切り取って保管している。
あとこの景気指標欄の読み方だけ解説した書籍がある。
週刊誌。毎週読んでるけど、ここに載ってた割と新しい会社買って結構な利益出たことが2回あり。
特集と、キーマン（特に社長）のインタビューを中心に読んでる。
東洋経済でもダイヤモンドでも良いと思うけど、そこはまぁ個々人の趣味でお願いします。
証券会社の取引ページにログインすると四季報が見られるところもあります。
売買したい銘柄はこれで探す。
上の四季報とは別に、各会社のシェア、関係がグラフィカルに書かれていて分かりやすいです。
●相場の格言集
上がりすぎた銘柄はそのうち下がるし、下がりすぎた銘柄はそのうち上がる。
迷ったときに読むと頭を冷やせる。
株価見られるサイトは色々あるが、日経のところは適時開示速報（リンク先の左下にある）も載る。
適時開示速報で会社がリリースする決算短信や業績修正が出るのでこれでチェックする。
業績で株価が大きく動く。
上級者向け。
適時開示速報をRSSで取得できる。チェックする銘柄が数十件あると、いちいち
文書をチェックするのは面倒。これ使うとRSSで更新があったときだけ通知してくれる。
株始めるなら50万円は欲しい。ただし当面使わない余裕資金を充てること。
自分は30万ちょっとで始めた。銘柄には最低購入単位があり50万円をこえる銘柄も
あるが、これはミニ株等（最低購入単位以下で株を買える）を使えば解決する。
といった話題がネットで飛び交っていたが、
その二択で悩むようなら大企業選ぶべきだ。
といった比較であるが、これはどちらが有利といった話ではない。
ゆえにライバルだらけ。
B社は仕事がなくなるか、あるいは値下げせざるを得なくなる。
ベンチャーの競合は、数百社が敵だったりする。
大企業はオトナなので、「これ以上値下げしたら儲からないから」
という線を必ず引くが、ベンチャー数百社の中には、
身を守ることになり、お金につながっているのだ。
会社が潰れたらアウトじゃん、とデメリットを考える人もいるだろう。
「どこでも使える技術＝国語＋ロジカルシンキング」を教えるからだ。
適切な返答をする。これさえあれば職に困ることはない。
Ajaxが出始めたのは6年前、JQueryは5年、node.jsは2年だ。
数年前はSQL+memcachedが騒がれていたのに、今はNoSQL一色だ。
成長したと言えるのだろうか。
ベンチャーは、余裕がない。
連続になる日もある。
最大2年間の休職を許したりする。これならば、
病気になっても戻ってこれる可能性が高くなる。
大企業はつまらない仕事だらけで、ベンチャーは楽しい仕事だらけ、
というイメージで話している場合があるが、本当にそうだろうか。
自社サービスで楽しいことをやっている会社はほんのわずかである
ということを忘れてはいけない。
受託開発もこっそりやっていたりする。
現在はパチスロのCGを作っているのをあなたは知っているだろうか。
数年後、多くは潰れているか
開発終了といってもずいぶん前から更新は止まっていたわけで、明確に開発終了が宣言されただけで公開終了になるわけではない。
しかし FFFTP といえば FTP クライアントの定番なので、ネット上で様々な意見が飛び交っている。それについて思うままに書き散らかしてみる。
みんなが「ホームページ」なるものを持ち始めたころ、ファイルをアップロードするのに使ったなつかしい思い出がある。BlogやWikiのようにオンラインで編集できる時代になったことへの感慨も含むのか。
もちろんFTPがプロトコルとしてセキュアでないことは言うまでもないが、いまだに業務で使わざるを得ないことがある。LAN内の転送なら速度は最強かもしれないし、FTPのミラーサーバは世の中にごまんとある。短絡的に「オワコン」の一言で片付けられる問題ではないだろう。
ほとんどのユーザはお客さん気分であることを再確認し、「FreeBSD への貢献」をたたき込んだ自分とは違う人種だと思った。
もともとFTP以外の通信プロトコルを想定して設計していないだろうから難しいように思う。ただ、ユーザは動いているプログラムの中のことなど考えない。
モチベーションが低下する理由ってたくさんあるなぁと。長続きしているオープンソースプロジェクトはすごい。
職場で英語話すことは一切要求されないけど、最新の技術やサービスのこと調べるのに英語読めないと話にならない。高校時代は英語赤点だったけど、社会人になってから必要に迫られて読んでいるうちに、読むだけならあまり困らなくなった。
ちなみに低学歴。田舎の公立小中高卒。今は高校でもっと真面目に英語の授業うけて置くべきだったと後悔してる。ただ当時の英語の授業がいいものだったのかはわからないので、授業がダメと感じたら独学で英語を勉強したい。田舎の貧乏家庭だったので塾や習い事なんてありえなかったけど、こんなに英語が必要だと知って子供の頃の自分に戻れるなら、小学生から図書館に通うなりして勉強したい。
まず言語やソフトウェアのリファレンスが英語オンリーなことが多い。日本語があっても誤訳が多かったり古いバージョンの翻訳しかなかったり、Webサービスの API の仕様書は英語しかなかったり。
流行ってるWebサービスや技術が英語圏から来る。Twitter だって 4sq だって過去グーグルラボにあった技術だってまず英語しかなかった。日本語サービスは一年後なんて珍しくないし、サービスでさえそうなんだから、技術関係の文書や仕様書は英語しかないのがざら。何かトラブルあって解決法探したら日本語での情報は皆無で英語でならあるなんてしょっちゅうだし。
ちょっと方向性は違うけど、英語だからって避けてると勿体無いネットゲームもある。当然そういう所でバグ報告や要望あげるには英語書けないといけない。知り合いには学校では全然ダメだったが UltimaOnline や EQ や MtG で英語を覚えたってやつが結構いる。チャットとはいえ英語全然ダメってところからネトゲ内の英会話に困らないくらいの英語力になる人がいるのが実践の面白いところ。
このネット使えて当たり前の時代、日本語での情報量 ＜＜＜＜＜＜＜＜＜＜＜＜ 英語での情報量 なので、英語避けてると全ての情報量において損する。だから直接英語に関係ない仕事でも英語全くダメというのはそれだけ損する。
大げさにいえば情報格差。最近の例でいえば、エジプト、今ならリビアの状況なんか英語圏のメディアのサイトではリアルタイム更新で情報量もすごいのに、日本だと全然報道されねーとかよくある。大震災の時でさえ英語圏のメディアの方が図とか写真とかすごくね？って事があったのは記憶に新しいと思う。
世の中には、英語わからなくても困らないゲームでも UI が英語なだけでプレイできない、インストールの途中で日本語選べるのに言語選択までが英語だから怖くてインストールしない、仕事で DropBox 使いましょうってなったのに英語だから使えないとダダこねる、英語だけのサイトに飛ばされたら何かいてるかわからないから全部危険なサイトに見えてすぐブラウザ閉じるので仕事に必要なソフトウェアを SourceForge から DL してくれない、なんていう人が本当にいる。
みんなも知っての通り、前々から2chなどでヤフー知恵袋が『Yahoo!バカ袋』『Yahoo!知恵遅れ』とネタにされています。
たとえば
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1252778297
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1315883
こんな質問するのは一体何者なんでしょうか。
おもしろいので、こういう質問を集めるサイトを作ってみました。
知恵袋のURLをコピペで登録するだけのシンプルなサイトです。
サイトの名前は『ヤホーおバカ袋』となっていますが、最初は『Yahoo!キチガイ袋』でした。流石にヤフーさんに怒られるかなと思って控えめにしましたwww
ぜひみんなもおもしろい質問をのっけていってください^^
Yahoo知恵袋APIはOAuthを使って書き込みなども出来ますが、今回は記事の内容を取得するだけだったので楽でした。
ひとまずAPIを叩いてXMLを見て、あとは配列にして...と簡単にとれました。
環境はApache+PHP+MySQLを使っています。よくあるあれです。
jqueryも使っています。jqueryプラグインはすごく豊富でajaxを使ったフォームもtwitter風のメッセージバーも超簡単に設置できました。
あと、cssはyahooのcssﾌﾚｰﾑﾜｰｸを使っています。yahoo css gridsが便利で、http://developer.yahoo.com/yui/grids/builder/ これを使えば土台が簡単にできました。。
デザインはアイコン載っけりゃいい感じに見えるので、http://photoshopvip.net/ からテキトウに見つけます。
読んでくれてありがとうございました^^!
せっかく作ったので、誰かに教えたくて。。。
ぜひ使って、おもしろい質問を共有しましょう^^
要望あればぜひぜひください。
とりあえずテンプレ化しといたよ
ウェブに携わる人間には常識だけど、HTML5は何でも出来るスーパーヒーローではない。
どちらかというと、○○の○○とか、○○の○○とか、○○の○○とかの方が近い。知らないやつはググれgoogle:○○○○
HTML5の真骨頂は、昨今のリッチなインターネットコンテンツを、非常に簡潔にスマートに記述できるところにある。複雑な事をすれば凝った事もある程度できるけど、得意分野じゃない（標準APIが機能不足だし、JavaScriptの言語仕様が複雑な処理に向いていない）。
ブラウザだけでここまで出来る、とか、
Flashはもういらない、とか、
ってのは、○○だって○○○○れば○○○○○○ようになるし○○はもういらない、って言ってるようなもん。○○に○○○○のなら筋違いだ。生い立ちも素質も違うのに、どうして代替となりうるのか（プログラムと人間を一緒にするのが暴論なのは百も承知）。
HTML5とFlashにはそれぞれ得意分野があるし、淘汰される形で対立しうるものではない。にもかかわらず、ブコメ見てて、いまだにFlash氏ねHTML5マンセーな意見が支配的なのが痛すぎる。
Jリーガー（現役）版
ウェブに携わる人間には常識だけど、HTML5は何でも出来るスーパーヒーローではない。
どちらかというと、柏の明神とか、ガンバの橋本とか、甲府の伊東輝とかの方が近い。知らないやつはググれgoogle:いぶし銀。
HTML5の真骨頂は、昨今のリッチなインターネットコンテンツを、非常に簡潔にスマートに記述できるところにある。複雑な事をすれば凝った事もある程度できるけど、得意分野じゃない（標準APIが機能不足だし、JavaScriptの言語仕様が複雑な処理に向いていない）。
ブラウザだけでここまで出来る、とか、
Flashはもういらない、とか、
ってのは、伊東輝だってシュート力つければゴール決められるようになるしハーフナーはもういらない、って言ってるようなもん。橋本に年間10ゴール以上を求めるのなら筋違いだ。生い立ちも素質も違うのに、どうして代替となりうるのか（プログラムと人間を一緒にするのが暴論なのは百も承知）。
HTML5とFlashにはそれぞれ得意分野があるし、淘汰される形で対立しうるものではない。にもかかわらず、ブコメ見てて、いまだにFlash氏ねHTML5マンセーな意見が支配的なのが痛すぎる。
いや、あなたの言ってることは合ってるし、自分も基本的に同じことを主張したつもりだが。
を、わざわざ砕いて”リッチなインターネットコンテンツを、非常に簡潔にスマートに記述できる”と文系チックに書いたのに、なぜ、わかりにくいバズワードで言いなおすのか。
そもそも「セマンティックな記述」って意味がわからない。文章の意味構造を記述できるようにして外見と分離する事を指すのなら、それは「非常に簡潔にスマートに記述できる」という事じゃないのか（さすがにあいまいに書きすぎてるとは自分でも思うが）。「実現できることが格段に増えた」事は、リッチなインターネットコンテンツを記述できるって事じゃないのか（意味構造を記述によって検索エンジンに適した情報になるってメリットは、論旨がブレるので書いてない）。
その当たり前の事ができなかったHTML4。HTML5になればできるようになるとでも言いたいのなら、あなたもネットに向いてない。
問いかけてる以上、答えがあるようなので、ぜひ模範解答をご教授頂きたい。「無限の可能性があります」という厨二病な答えしか思いつかない。
ちゃんと書いたつもりけど、代表格は2D描画。あと複雑な処理（クラスのおかげ）。ブラウザ間OS間の互換性。ネイティブなXML処理。プリミティブな音ストリームの操作なんてのもある。
現状、Flashを必要としてるのは何処？ 誰？
Flashを必要としてる人なんていないと思ってる。ただFlashの方が制作環境とかも含めて使いやすいから使ってるだけのこと。
いやいやいやいや。iPhoneで表示されない広告に何の意味があるのか。ゲームは一理あるけどFlashは外部コントローラに対応してない。3Dなら現状Unity。一概に言えない。