出力先、いろいろ。
日記を書かないにもほどがあるのでヒトのエントリをダシにして一本書くという暴挙。
なにかしらを書く先をつらつらとまとめてみますよ。
思ったことを適当に書き散らしてますが、特に役に立つようなことは書いてないですね。同期性が弱いチャットみたいな感じ。
Google Docs
公開しない内容をメモしておくのに使ってます。が、FOXNOTE with GDOCが同期してくれなくなっちゃってちょっと疎遠に。新機能を有効にしたからこけるのかな。
PCからのみ書くならいいんですけど。
カケラの樹
手前味噌ですが。アプリの設計とか、長くて論理構造がはっきりしてる文書のストアに使用。
モバイルビューが欲しい欲しいと思いながらもなかなか手が回りません。
こうして並べると、短い思いつきをばらばら投げる先と、長文をどかっとまとめる先の、間を埋めるソリューションが欲しいですね。
サービス情報用twitterアカウントができました
「雨上がりの青空を探して」ブランドのサービスやそのほかの作品情報を発信するtwitterアカウントを作りました。
http://twitter.com/yumenosoranet
メンテ情報などを速報的に流したり、不定期に作品紹介などを流します。
どうぞご利用ください。
現在のウチでの標準。
ころころと変わり続けてますが、開発に使うフレームワークやライブラリなど、こんな構成で標準にしようとしてます。
- Ruby on Rails 2系
- Prototype.js
- Script.aculo.us
- Blueprint CSS
- Kitaguchiプロフィール認証
- KitaguchiフルテキストサーチAPI
個人開発なのでその場その場で使いたいフレームワークを使ってもいいんですが、そうやってるとどうしてもあとの保守がやりづらくなるので構成をあわせておいた方が結果的に楽ですね。
ちなみに現状はこんな感じ。
| App | Web App F/W | JS F/W | CSS F/W | Auth | FTS |
| Ashiyagawa(カケラの樹) | ○ | ○ | ×(Yahoo! UI) | ○ | ×(未採用) |
| Okamoto(読書びより) | ×(Sinatra) | ○ | ×(Yahoo! UI) | ○ | ○ |
| Shukugawa(カゼノキレハシ後継) | ○ | ○ | ○ | ○ | - |
読書びより、カケラの樹をGoogleアカウントにてご利用の方々に重大なお知らせです。
サービスにログインできない問題が発生しております。詳細は以下の記事をご覧ください。
http://ame-services.g.hatena.ne.jp/yune_kotomi/20100215/1266250849
舞台を変えて、もう一度。
Google Buzzは、かつてGmailがメールに起こした革新の再現になるかもしれない。
文字通りGmailに統合されているからではなく、取り巻く環境の類似点に関するお話。
かつてGmailが実現した新機軸と言うのはいくつもあります。まず、その大容量。それを生かして、昔はこまめに手元の端末にダウンロードして貯めておくものだったメールはGmail上に貯めておくものになりました。他にも、端末のメーラで読み書きするものだった物が今ではどこからでも、ブラウザ上で快適に読み書きできるように。
そういった革新の中で、目立たないながらも快適なメールライフのために非常に重要な機能があります。それは、spamフィルタ。
昨今の例を引くまでもなく、当時すでに迷惑メールは大きな問題になっていました。メーラの中には迷惑メールフィルタを備えたものがいくつも出ており機能していましたが、そんな中登場したGmailのspamフィルタは非常に高精度でした。これは単にGoogleの技術力が高かったからだけではなく、多数のユーザから報告される迷惑メールを片っ端から学習してフィルタリングに使えたことが大きな要因。
この高精度なspamフィルタによって、完璧ではないながらもGmailは「メール」をspamの少ないツールへと押し上げたのです。
翻って今度のBuzzに目を向けてみましょう。位置情報を結び付けた一言や、Picasaと統合されて投稿写真も一覧できるなどの機能は他のあまたあるレビュー記事に任せます。
ここで注目したいのは、Twitter統合と“buzz“のパーソナライズ。先ほどのメールとGmailの話に当てはめると、前者がメールで後者がspamフィルタにあたります。
Twitterはまだ、かつてのメールのようにspamの大群に埋もれる水域には達していませんが、「マーケティング」や「ビジネス」を合言葉に参入してくる人たちが増えるにつれてそのSN比は次第に低下しつつあるのも事実です。さらに、いくらフォローしている相手でも常に自分が読みたいメッセージを投げているわけでもなく、ノイズとなるメッセージが流れてくることもどうしてもあります。
そこにBuzzがもたらすのが、パーソナライズされたbuzzの配信。これはユーザが要らなそうなのを畳んだり消したりしてくれる機能を含んでいるから、spamフィルタとしても働く。加えて、興味ありそうなbuzzをレコメンドしてくれるのは新たな発見に繋がる。
Gmailがメールのspamを駆逐したように、Buzzはマイクロブログからノイズを除去し、新しい気づきをプラス。これはそんな可能性を秘めたプロダクトだと思う。
私の増える城。
カケラの樹のAppEngine移行に失敗し、続いて読書びよりの移行にも失敗したわけですが*1、これはとてもまずい傾向だって思ってた。けど、この記事を読んで認識が変わった。
スケールアウトからスケールアップへの回帰:Kenn's Clairvoyance - CNET Japan
この記事を読んで改めて考えると、現行インフラをそのまま使い続けるのも確かに悪くないと思えるように。ウチのケースで置き換えて考えると、現在運用中の各サービスがサーバの性能限界を越えて止まったことはない*2。現状の成長曲線を見る限り、性能限界に到達するのはまだまだ先な上に、時々行われるLinodeの増強を考慮すると、到達しないかもしれない。もし到達したにせよ、コントロールパネルからリソース追加を行えばしばらくは事足りる。
ならば、AppEngine移行にかけるリソースで新規プロジェクトを回した方が得策。
AppEngineとかのキャッチアップは続ける。新規開発なら今までの物を使い回そうとしてこけることもないだろうし、運用の楽さは魅力的。これから先伸び続ける分野だろうから、そこから目を背けるのは技術者としてもありえない。ただし、既存の移行は考えないでいこうかなと、思った。
年始のご挨拶。
あけましておめでとうございます。本年も殊海夕音と『雨上がりの青空を探して。』をよろしくお願いします。
今年も開発予定は盛りだくさん。まず、コード名"Okamoto"のAppEngine版読書びよりへの移行。今までウチのインフラでサービスしていた読書びよりが、ついにGoogleのインフラに乗るようになる。これによりサービスの安定性が格段に向上するとともに、機能性、操作性も向上する予定。開発自体は去年のうちにほぼ完了していて、あとは本番環境での品質検証が済み次第移行開始。
続いて、コード名"Rokko"の、八会咲木陰の改修プロジェクト。これは主に通信機構の入れ換えをするプロジェクトで、完成すれば通信の安定性が格段に向上する。併せて、デザインの調整も加える予定。
続いてはAshiyagawaプロジェクト、カケラの樹のAppEngine 移行。これは前年の後半に一度頓挫したプロジェクトで、今回はOkamotoプロジェクトで得た知見を生かして再チャレンジ。
ここまでは既存のプロジェクトを発展させる案件。それに加え、新しいものもどんどん作っていきたい。
現在構想中のMikageプロジェクトはその中核として力を入れていきたい案件。詳細はまだ公表できる段階にないですが、今までに培った技術の集大成に新規要素を目一杯盛り込んで、ようやく実現できるかどうかという野心的なものになる。
と、今フィックスしているものだけでもこれだけある。今年はどんな一年になって、何ができるのか。願わくば、良い一年となりますように。
