グリー株式会社に入社しました - naoyaのはてなダイアリー
昨日は退職の挨拶にブックマークや Twitter などで多数のコメントをいただきました。改めて、自分がたくさんの人に支えられていることを実感し、自分は幸せ者だなと感じました。本当にありがとうございます。 いただいたコメントで「次はどこへ」というご質問を多数いただきましたので、報告させてください。 本日より、グリー株式会社で働きます。 グリーのサービスのビジョンは「インターネットを通じて、世界をより良くする。」というメッセージに集約されています。 インターネットが本格的に世の中に普及してすでに10年以上の年月が立ちますが、まだまだ、それが秘める体験は世の中の人々に届いていないと感じます。ここ何年かの間に、ブログや SNS、ソーシャルゲーム、ソーシャルメディアなどの大きなトレンドがあって、その中で各サービスがその体験を補完する形で立ち上がってきました。 これから10年20年、自分がやるべきこと
退職のお知らせ - naoyaのはてなダイアリー
本日8月31日をもって、はてなを退職しました。 入社は2004年9月1日でしたから、今日でちょうど6年です。6年間の間に、はてなブックマークをはじめとする各種サービスの企画開発やディレクション、インフラの構築、技術チームのマネジメント等々、色々な経験を積むことができました。その一方で、なかなか自分の思うようにはサービスを成長させる、会社を伸ばすことができず自分の力量不足を感じる毎日でもありました。その足りない能力と経験を埋め合わせる日々が、成長を促してくれたとは思います。 この6年は、はてなという会社が、個人あるいは家族のような繋がりから組織に変っていく過程でした。会社というものが何なのかを全然知らなかった自分が、Webサービスの開発と運営に、組織がなぜ必要かというのを体で知ることになりました。なかなかに得難い経験でした。 遠回りもありましたが、はてなは組織になりました。新サービスは日々ユ
はてなブックマークの作り直しについて - naoyaのはてなダイアリー
id:naoya:20080320:1206009912 でも少し触れましたが、京都に来てからはてなブックマークの作り直しをしています。どういう意図を持って作り直そうとしているかを述べておきます。 まず大前提として、今のはてなブックマークに追加したい機能、変更したい仕様、本来追加するはずが途中で頓挫したものが結構な数で山積みになっています。それを実現するための基礎作りです。 追加したい機能、変更したい箇所 おそらく新システムの最初のリリース時には、それほど大きく変わった、という印象にはならないかと思います。長く続いているサービスですし、インタフェースや使い方もリリース当初からそれほど大きくは変わっていません。既存システムからの極端な変更は歓迎されないだろうと思っており、まずはオリジナルが持っていた機能をしっかり再現することが重要です。 ただし、既存システムでも問題と思っている箇所は改善して
はてなブックマークのコミュニティについて - naoyaのはてなダイアリー
はてなブックマークからは毎日のようにいままでは知りようがなかったすばらしい記事やニュースを得ています。こうして日記を書いた後にたくさんのフィードバックをいただいています。コメントのないブックマークでも、その一つ一つがとても嬉しい。そこに人がいる、という感じがします。はてなブックマークを作って良かった、と思います。 一方、はてなブックマークでの厳しい一言で人が傷ついたりしているのを見かけます。誰かがちょっと間違ったということを指摘するのに、バカとかアホとか、そんなことを書く必要は本当にあるんだろうか、自分の思う正しい回答を丁寧に示すだけでよいのではないか、と思います。 人間の感情なので、色々思うことは止めようがない、とも思います。また一方で、それを外にストレートに出さないよう理性を働かせるのもまた、人間のあり方だと思います。 コメントを見て「身から出た錆だ」と思ったこともあるし、僕自身も自覚
naoyaのはてなダイアリー - さくらインターネット移行記#1
先日のライブドアのテクノロジーセミナー(http://d.hatena.ne.jp/naoya/20061214/1166063145)でも少し触れたのですが、はてなのサーバーは今後さくらインターネットのiDCでホストすることになりました。 複数の iDC を検討しましたが、最終的にさくらインターネットに決めた理由は回線品質の高さと回線が低価格である点でした。 はてなのようなコミュニティ中心のサービスは、お金の面では、どうしても回線コストと収益の間にアンバランスが生じがちです。ショッピングサイトや各種メディアのようなコンテンツに比べてマネタイズが難しい、というのがその主な理由です。 例えばはてなのトラフィックの多くははてなダイアリーの日記へのアクセスで占められていますが、基本的に個人の日記にははてな側からは広告を掲載しないポリシーでいます。そのためトラフィックを多数必要とされる箇所で収益を
naoyaのはてなダイアリー - SixApart の Vox - コメント欄
MovableTypeやTypepadの開発元として有名なSixApartが現在開発中のMovableTypeに代わるブログとして開発中なのが「Comet」だったわけですが、名前を「Vox」に変えるそうです。 誰かがマジレスしとかないとみんなが勘違いしたままになっちゃいそうなので、マジレスしづらいであろう中の人に代わって言っておくと Comet 改め Vox は Movable Type の次世代版/代替ではないんじゃないかな。Six Apart の blog プロダクトとして、 単独でインストールできるため足回りが良く高機能な Movable Type Movable Type の高機能性よりもお手軽さを重視したい人のための ASP としての TypePad という二つの柱があって(加えて雰囲気的にははてなダイアリーに近い LiveJournal もある)、ここに 例えば家族間で利用した
eijiro.pl 改 - naoyaのはてなダイアリー
市販のソフトなども色々あるようですが、英辞郎そのものの辞書データが、1980円というリーズナブルなお値段でダウンロード可能なのですね。英辞郎のホームページから入手可能。 ただ、あくまでもデータだけなので、辞書として検索するためのビューワーが必要になります。 英辞郎のデータが 1,980円で手に入るとはなんということでしょう。Goodpic さんおいしい情報ありがとう。 そういえば英辞郎と言えば宮川さんが昔 Hack した eijiro.pl なんてのがあったなあと思い出しました。(http://bulknews.net/lib/columns/02_eijiro/column.html) これは alc のウェブページをスクレイピングしてコマンドライン用に整形するスクリプトです。短いスクリプトですが、英和/和英を自動判定したり、対話型でヒストリがあったり、less や lv などのページャ
インタフェースの話 - naoyaのはてなダイアリー
一つ前のインタフェースの話。いろいろフィードバックをいただきました。ありがとうございます。 >
naoyaのはてなダイアリー - Jemplate で JavaScript でもロジックとビューを分離する
JSON を Template-Toolkit で展開する Jemplate という記事を書いたんですが、Jemplate を使うと何がいいかってのをもう少し詳しく書いてみます。 Jemplate は TT で JavaScript 上の JSON を展開できるんですが、それだけ聞いてもしかすると「これで普段サーバーサイドでやってるテンプレートの展開をクライアントサイドに持って行けて負荷がクライアントに移ってウマー」っていうのが使いどころのようにも思えちゃいますけど、そうじゃない。検索エンジンに引っかからなくなったりとか、アプリケーションの使い勝手が悪くなったりとか色々弊害があります。 そうじゃなくて、Jemplate は JavaScript のためのテンプレートとして使います。 試しに Catalyst で簡単なアプリケーションを作ってみました。ちょっと動かしておく環境がないのでソース
JVN のシステムの話 - naoyaのはてなダイアリー
誰（どの組織）が書いたか不明（JVN編集者が書いているようにも読めなくもない）なのは、システムに問題があるのではないか。署名欄でも設けたらどうか。自由書式だからこういう輩が出てくるのだから、記入様式を用意したらいいのに。 それ書いたの僕なわけですが。 マニュアルとか、フォームのそばにある説明を見ても「CERT/CCへの情報提供(任意)」だっけかな、そんな一文が書いてるだけで何を書いたらいいか分からないのですよ。そこに書いて欲しい具体的な内容があるなら具体的にどういうことを書くかとか、そういうのがないと分からないですね。 あと、このシステムの位置づけというのがいまいち理解できてなかったり。(もちろん、脆弱性情報を安全な経路で教えていただけるのは大変ありがたいことです。 ) それを修正した後に僕らが JVN のシステムを使って決められたフォーマットであれやこれを入力するのは何かしらの義務なんで
naoyaのはてなダイアリー - つぶやき - Web 2.0 の世界とデジタル・デバイド
Web 2.0 で重要とされる考え方は色々あって(yohei-y:weblog: REST -> AtomPP -> blog -> Permalink -> RSS/Atom -> Remixing (Ajax/Microformats/Folksonomy)で図式化されて説明されているのでその辺も参照)、そのいくつかはすでに具体的に実現されているものがある。REST的な考え方、Permalink、フィードによるメタデータの syndication、Webservices API、tagging による Folksonomy、microformats、user script (Greasemonkey や Trixie、Turnabout etc..) による Content Remixing... などなど。 つらつらと眺めてみると、そのうちの幾つかをのぞき、いまのところ実現されている
naoyaのはてなダイアリー - microformats って一体何だ?
にわかに盛り上がりを見せている microformats。Technorati が最近注力しているので有名で、Web 2.0 のディスカッションの中でもときおり出てくる重要な要素らしい。アルファギークな人たちも、近頃は microformats について触れることが多くなってきました。 が、僕は頭が悪いんだろうか、いまいち何のことだかよくわからなくって困ってたので、ここで少し腰を据えて、色々見て回り勉強中です。まだ細かいところがもやもやしてはいるものの、ようやくその実体が掴めて来た感じです。 「microformats とは何か?」と言われると、その答えはズバリ About microformats というエントリーに書かれているのですが、これを理解するよりまず具体例から入った方が分かりやすい。現在 microformats と呼ばれているもののうち、すでに実用段階に入っているものがありま
ブックマーク件数取得APIをリリースしました。 - naoyaのはてなダイアリー
exist API を使えば HTML をスクレイピングするより高速な実装が可能ですが、それでも一画面に 50 件検索結果があったりすると 50 回 exist API を叩くことになって HTTP のオーバーヘッドが大きいでしょうし、サーバー側も SQL が 50 回走ったりして嫌なので、前から考えてた複数 URL を与えてブックマーク数をまとめて取得する API を作ってます。来週にはリリースしたい。 ということで、はてなブックマーク件数取得APIをリリースしました。相変わらず名前がださい。JSON版とかMD5で問い合わせられるようにとかはまた後ほど。 はてなブックマークはそんなにサーバーの台数もまだないので、連続リクエストはすこし間隔あけてもらえたりすると助かります。 そうそう、こういう API を AtomPP で実装するとしたらどんな感じなんだろう。そもそもうまくフィードで定義で
XML-RPC なブックマーク数取得 API - naoyaのはてなダイアリー
id:kusigahama さんが http://d.hatena.ne.jp/kusigahama/20051207#p1 で Google の検索結果にはてなブックマークのブックマーク数を表示する Greasemonkey を、はてなexist APIを使って実装してます。GJ。 exist API を使えば HTML をスクレイピングするより高速な実装が可能ですが、それでも一画面に 50 件検索結果があったりすると 50 回 exist API を叩くことになって HTTP のオーバーヘッドが大きいでしょうし、サーバー側も SQL が 50 回走ったりして嫌なので、前から考えてた複数 URL を与えてブックマーク数をまとめて取得する API を作ってます。来週にはリリースしたい。 はてなブックマークには AtomPP があるので、AtomPP でうまく実装できたらなあと思ってたんです
naoyaのはてなダイアリー - del.icio.us に関するつぶやき - その2
弾さんからツッコミをもらったので、返答しておく。 「警鐘」って、なんか小さくても堅実にやって来た町工場が大企業に札束でひっぱたかれて身売りみたいな印象があるけど、少なくとも今回のそれは違うよ。だって、どうみても始めから大企業に売りつけるために作った会社だもん。 警鐘っていうのは「ニュータイプウェブ企業は自社で売り上げ上げて食ってくあるいは IPO するとかってのは無理っぽい、みんな買収目当てでやってんだよね」って世間の人が言い始めるかもしれないよっていう点ですよ。もし、そういう人たちが言うようにこれから先のウェブ企業に買収しかゴールがないってのは、全然夢がないし、そういう意見ばかりが目につくようになってほしくない、そういう意味。 で、del.icio.us が端から買収目当ての会社だったかもしんないじゃん? っていうのはその通りだと思わせる点は弾さんが挙げてくれてる通り。 このとき Blo
del.icio.us 買収に関してのつぶやき - naoyaのはてなダイアリー
del.icio.us が Yahoo! Inc に買収されたのは、こういう新しいタイプのウェブアプリケーションを作っている企業 (もうなんとか 2.0 とかいうのはやめた) にとっては一つの朗報かなと思う。価値のあるアプリケーションを作っていれば、ちゃんと目をつけてくれる人が出てきて、ゴールを用意してくれるという意味で。 一方で、警鐘でもあると思う。Bloglines、Flickr、del.icio.us のような、注目を集める新しい企業(サービス)のゴールが、やっぱり買収されるしかないんじゃないの? という見方に拍車がかかりそうだから。そして、買収されてゴールを迎えられるのは Bloglines、Flickr や del.icio.us のような、世界でも指折りのアプリケーションじゃないといけない。華々しいアーティストの成功の裏には、膨大な数の屍があるというのと同じ話で。 個人的には、
直交する技術から複数のものを学ぶ - naoyaのはてなダイアリー
一年前に CNET でインターネット時代のエンジニアの価値という記事を書いたのですが、それと関連する、先週 Binary 2.0 カンファレンスや PofEAA 読書会に行って来て、感じたことを書いてみたいと思います。 まず、Binary 2.0 カンファレンスに行って来て感じたことというのが、先日ちょっと述べたとおり、ソフトウェア開発の世界は多様化していて、それぞれのレイヤの間で断絶がある、ということ。断絶というとちょっとネガティブな印象があるので、それぞれ違うレイヤというかカテゴリの技術の関係を、直行する技術カテゴリ、とでも言ってみます。 Binary 2.0 カンファレンスでもうひとつ発見があったのは、ローレベルレイヤを極めているバイナリアンは、どことなく数学的にコンピュータにアプローチすることに長けている人たちというイメージだったけど、それはちょっと違うということ。もちろん、それに
naoyaのはてなダイアリー - 大規模サービスを展開する企業が陥るジレンマ
このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。 一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。 はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュー
MVCフレームワークにおける Web API 実装 - naoyaのはてなダイアリー
ちょっと前に miyagawa さんが 12 Things I dislike with Sledge という(数字で始まる Web つーぽいんとおーチックなタイトルで) Sledge の次期バージョンへの要望なんかを書いてます。この中で 10. REST な API や Basic 認証、XML-RPC、Atom などをうまく処理できない と、Sledge における Web API (XML-RPC/AtomPP) のハンドリングについての言及がありました。これからの MVC フレームワークに求められる必要条件の一つとしてこの Web API を処理しやすいかどうかというのは重要な気がします。 フレームワークに Web API 用の API が載っていて、その扱いが容易かつプロトコルの実装を知らなくても使えるようなアーキテクチャになっていると、開発者が Web API を公開するための敷
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Yahoo! Japan の Search API オープン - naoyaのはてなダイアリー
