Home > develop Archive

develop Archive

Google Codeで管理していたコードをgithubへ移行する

最近は仕事でgitを使うケースがSubversionと比べて圧倒的に多いので、個人的にGoogle Codeでホスティングしていたコードもgithubに移すことにしました。

git-svn

移行作業にはgit-svnが必要になります。MacOSXでgit-svnを使うには、git-coreをmacportsで入れるときに、+svnのvariantsをつけてインストールしてあげるとOK。ぼくはすでにgit-coreをインストールしていたので、次のようにしてインストールしなおしました。

sudo port deactivate git-core
sudo port install git-core +svn

作業用ディレクトリの作成

作業用の適当なディレクトリを作ります。

mkdir ~/Desktop/git
cd ~/Desktop/git

authors.txtの作成

次のような内容のauthors.txtを作成。(no author)はGoogle Codeの初期設定で、名無しさんがtrunk, branches, tagsを作成しているようなので、この2行が必要になります。左辺はGoogleアカウント名、右辺はgithubに登録した名前とメールアドレスです。

ryo katsuma = ryo katsuma <katsuma@gmail.com>
(no author) = ryo katsuma <katsuma@gmail.com>

移行用レポジトリを作成

githubで移行用のレポジトリを作成します。作成はここから。

移行

ここまでくるとあとは簡単。

git svn clone -s -A ./authors.txt http://svn_repo.googlecode.com/svn repo
cd repo/
git remote add origin git@github.com:katsuma/new_repo.git
git push origin master

まとめ

Google Codeからgithubの移行は、実作業はauthors.txtを用意するくらいで、全体としてそんなに複雑なものではなかったと思います。 ちなみに今回の作業を通してTokyo-Joggingのコードを全部githubに移しました。 コード管理はもちろん、サイト全体の操作性なんかもGoogle Codeと比べてgithubの方が優れていると思うので、移行して正解だったかなーと感じています。

楽天テクノロジーでLT&デモをしてきました

少し前の情報になるのですが、楽天テクノロジーカンファレンスTokyo-JoggingネタのLT&デモを行ってきました。

当日は、WiiリモコンだけじゃなくてバランスWiiボードと、最近対応したヌンチャクのデモも行いました。やや古いネタではあるものの、大勢の方に実際に体験いただいて、アドバイスや意見などいただけて楽しい時間を過ごすことができました。

ただ1つ残念だったのはデモブースに常駐してないとダメだったので、他の方の発表がまったく聞けなかったこと。。楽しそうな話いっぱいあったのでそこが残念でした。と、思ったら発表内容はUstreamで残っているみたいなので、あとで確認したいとおもいます。

また、ありがたいことにデモ投票では3位(!)の結果をいただけることになりました。LTでは時間切れになっちゃって消化不良だったわけですが、デモで実際に体験いただけたのがよかったのかなとおもいます。

最後に、貴重な場所と機会を提供いただいた楽天株式会社 開発部の方々、どうもありがとうございました!

githubで新しい環境から自分のレポジトリにpush

小ネタだけど、少しハマってたネタについて。

githubの「自分のレポジトリに最初にpushしていたマシンとは別」のマシン上でgit cloneでデータを取得して、そこで編集、変更を反映するためにpushしようとしたらエラーになりました。

$ git push
fatal: protocol error: expected sha/ref, got '
*********'

You can't push to git://github.com/user/repo.git
Use git@github.com:user/repo.git

*********'

何だこれー!と自分のレポジトリなのになぜエラー??と思ってたら、cloneするときのURLには"Public Clone URL"と"Your Clone URL"の2種類あることを知りました。僕は前者をずっと使ってたのですが、こちらが「公開用URL」後者が「自分専用の(pushをがんがんする前提のURL」という感じなのかな。

と、いうわけでもういちど次のような手順でcloneすると無事、別環境でもpushできました。

git clone git@github.com:katsuma/config.git
(編集)
git add .
git commit
(コメント追記)
git push

今回はこちらの記事を参考にさせていただきました。ありがとうございます!

(参考)githubからローカルにコピーするところまで

はじめてのCarbon Emacs

僕はエディタに今までそこまで拘りがなくて、Windowsで作業をするときは秀丸かEclipseを利用することがほとんどでした。 と、いうのも僕にとってエディタは

  • シンタックスハイライト
  • そこそこの精度の自動補完
  • タブ化

くらいが実装されていればよく、JavaだったらEclipseでもちろんよくて、それ以外の言語を書くときも秀丸で十分満足いく設定を実現できていました。(なので、よく言われるvi対Emacsの戦争には関わることは無かったのですね)

Macでのエディタ

とはいえ、最近は家ではもちろん、仕事でも作業をMacで行うようになり、さてエディタをどうするか、という話を本格的に考える必要が出てきました。いままでMacでもいろんなエディタを試してきたものの、秀丸的なポジションのしっくりくるものを見つけることができずにいました。

そんな中、仕事ではEmacsを使ってる人が多そうだったのでずっと導入しかけてはやめてたEmacsの導入を試みてみました。 Emacsは(超ありがちな理由ですが)ずっとキーバインドやその操作方法に慣れなくて導入しては止め、の連続だったのですが、さすがにそろそろどうにかするか、と。

また、素のEmacsでもいいのかもしれませんが、Carbon Emacs がインターフェース的に良さそうだったので、これを利用。 いろいろ試行錯誤しながら、こんなかんじにカスタマイズすると初心者でも結構使いやすくなってきました。

Emacs setting

  • フルスクリーン
  • 背景を透過
  • メニューバーを隠す
  • タブ化
  • 行番号表示
  • 編集中の行をハイライト
  • Mac標準のキーバインドを有効
  • Optionキーをメタキーに
  • Shiftキー+矢印で範囲選択
  • ビープ音を消す
  • 対応する括弧を光らせる
  • 自動補完を有効

これくらいを有効にすることで、初心者でもかなり使いやすくなりました。

雑感

特に、Mac標準のキーバインド、Shiftキー+矢印で範囲選択を有効にするだけで、普通のエディタと使い勝手はほぼ一緒になりました。コピペやカット&ペーストもCommand+αでOKです。この上で、ファイルを開く+保存、ウィンドウ分割、行頭や行末移動くらいのコマンドさえ覚えておけばとりあえずまったく問題なく使える感じ。 さすがにこれくらいのコマンドはすぐに覚えられますし、標準の移動系などのコマンドももちろん同時に使えるので、僕のようなキーバインドで悩んでいた人も、Mac標準のキーバインドから少しづつ移行していけばいいのかな、と。また、自動補完も秀丸と同じくらいの精度ではさくさく動かせますし、HTMLタグの補完もOKです。

あと、個人的によかったのがフルスクリーンでの表示。これをすることで、モニタにエディタ以外に何も表示されなくなったことで集中力がかなり上がった気がします。エディタ以外に視界に入るものが無いということは非常に効果的です。 また、背景を透過させておくことで、IMやブラウザが気になってもアプリケーションを切り替えることなく同時に視界に入れることができるのは、当たり前ながら相当使い勝手がいいなぁと感じました。

ただ、このあたりの下りは使いこなしてる方からすると「こいつほんとゆとりの使い方だな。。」と突っ込まれそうな感じはムンムンするのですが、それでもとりあえず使ってみる、という視点でいくと最初はこんな感じでどうか許してください、という思いです。。

ちなみに、これらの設定はgithubに上げてみました。もっとこうしたほうがいい!なご意見があり ましたら是非教えていただければと思います。

最後に

RubyやRails系の補完周りの設定をもう少しいじってみたいのですが、まだうまくいっていないものが多いです。このあたりはまだ研究中ですね。

モダンブラウザでAppletを扱うときに知っておくこと

[09/04/07 16:00 追記] embedでの呼び出し結果の表に誤りがあったので訂正しました。

世間ではiPhone OS3.0で騒がれていますが、そんな中メインストリームとは逆行してJava Appletについていろいろ調べていました。

情報が少なすぎる

世間的にはJava Appletの話なんて枯れすぎてる話題なので、いくら調べても2000年過ぎの情報ばかりが大半です。「ただしこの方法ではNetscape4.0以上の環境では。。。」とか言われても困るわけです。今どきのWebアプリケーションらしくJavaScriptと連携させるにはどうすればいいんでしょうか。そもそもappletのロード方法1つとってもSafariやChromeなんかのモダンブラウザに対応したロード方法とかまったくわかりません。あとJava Runtimeのインストールチェックなんてどうすればいいのでしょうか??疑問は尽きません。

そこで、今回これらの情報、

  1. JavaScriptからAppletを呼び出す方法
  2. AppletからJavaScriptを呼び出す方法
  3. モダンブラウザに適したAppletのロード方法

について調べてみたのでまとめておきたいと思います。

Java Runtime のバージョンチェック

そもそもAppletを実行できる環境であるかどうか、を判定する必要がありますが次のようなロジックで確認をすることが可能になります。

  1. Applet側でRuntimeのバージョン情報をpublicなフィールドに格納しておく
  2. JavaScriptから1.のフィールドを参照する
  3. 参照に失敗、または参照先の値が不正な場合はRuntimeがない、と判断。参照先に値があった場合はその値がバージョン情報

次に、JavaScriptとの連携を考えるわけですが、ここでは「JavaScriptからAppletのメソッドを呼び出す」「AppletからJavaScriptの関数を呼び出す」の2パターンがあります。まず、前者の方から考えていきましょう。

AppletからJavaScriptを呼び出す

こちらは非常にシンプルで「document.{$AppletをロードしたHTML要素のid}.{$appletにおけるpublic修飾子のメソッド、またはフィールド}」でアクセスすることができます。たとえば次のようなAppletがあるとします。

import java.applet.Applet;

public class VMInfo extends Applet {
  public String jreVersion = "";
  public void init() {
    this.jreVersion = System.getProperty("java.version");
  }
}

また、次のようにappletタグでappletをロードしておくとします。

<applet name="app" code="VMInfo" mayscript="true" archive="plugin.jar" width="430" height="200"></applet>

このとき、JavaScriptからAppletのjreVersionフィールドにアクセスする場合、

document.app.jreVersion

で、アクセスが可能です。ここでのappはapplet要素のname属性値になります。非常に簡単ですね。

また、FlashのExternalInterface経由でJavaScriptからFlashのメソッドにアクセスする場合、IE系はdocument経由、それ以外のブラウザはwindow経由でFlashの参照を取得するなど、参照の取得方法は異なります。ところが、Appletの場合はIEでもFirefoxでもChromeでもすべて同じ「document経由」で参照を取得する、というのは1つのポイントになります。

AppletからJavaScriptを呼び出す

先ほどとは逆に、JavaからJavaScriptのメソッドを呼び出す方法について考えてみます。方法としては、

  1. JSObjectを利用する方法
  2. 共通 DOM API を介してアクセスする方法

の2種類の方法が存在します。ここでは単純な1の方法を紹介します。

JSObjectクラスのメソッド群を利用すると、HTML ページの DOM へのアクセスが容易になります。JSObjectを利用する場合、次のjarファイルをクラスパスに通しておく必要があります。

{$jdk}\jre\lib\plugin.jar

plugin.jarにクラスパスを通すと、netscape.javascript.JSObject を利用することが可能になります。JSObjectはstaticメソッドでglobalなwindowオブジェクトの参照を取得します。windowオブジェクトの参照を取得すると、あとは任意のJavaScriptのコードをeval()で実行することが可能になります。たとえばwindow.alert()を呼び出す場合は次のようなコードになります。

import java.applet.Applet;
import netscape.javascript.JSObject;

public class VMInfo extends Applet {
   public void init() {
  JSObject win = JSObject.getWindow(this);
  String jsContext = "alert()";
  win.eval(jsContext);
   }
}

要はActionScript3におけるExternalInterface.callのようなもの、というイメージで良いと思います。JSObectのAPIについては、こちらのドキュメント にまとまっているので、さらに詳しく知りたい方はご参照ください。

ここで1つポイントとして、JSObjectを利用してappletとJavaScriptとの連携を行うときは、appletをロードするときのHTML要素に対して「mayscript」属性を追加しておく必要があります。属性値はtrueにでもしておけばいいですが、実際は属性が存在すれば問題は無いようです。このあたりの話は「JavaScriptを使用するアプレットの単体テスト」で述べられていますので、ご参考ください。

ロード方法

さて、appletのロード方法についても、パッと考えただけでもいろんな方法が思いつきます。

  1. appletタグでロード
  2. objectタグでロード
  3. embedタグでロード

Flashのような発想をすると、objectタグとembedタグの組み合わせでロードするのが本筋のような気もしますが、とりあえずこれまでで述べてきたJavaScript連携のコードを含んだAppletのロードを全パターンで試してみました。

対象となるAppletのコードは次のようにしています。 appletがロードされると、JREのバージョン、およびベンダ情報を取得し、JS側のVMInfo.notify()を呼び出します。(Java→JavaScript呼び出しの確認)

import java.applet.Applet;
import java.awt.TextField;
import netscape.javascript.JSObject;

public class VMInfo extends Applet {
    
    public String jreVersion = "";
    public String jreVendor = "";

    private TextField versionField;
    private TextField vendorField;

    public void init() {
        this.jreVersion = System.getProperty("java.version");
        this.jreVendor = System.getProperty("java.vendor");
        
        this.versionField = new TextField(jreVersion, jreVersion.length());
        this.vendorField = new TextField(jreVendor, jreVendor.length());
        
        add(versionField);
        add(vendorField);
        
        // callback
        JSObject win = JSObject.getWindow(this);
        String jsContext = "VMInfo.notify({\"version\":\"" + jreVersion + "\", \"vendor\":\"" + jreVendor + "\"})";
        win.eval(jsContext);
    }
}

検証するJavaScriptの関数VMInfo.norifyは次のように用意しておきます。構造は単純で、Objectを引数に受け取り、alertで確認しています。

.

<script type="text/javascript">
 //<![CDATA[
        var VMInfo = {
            notify : function(info){
                var version = info.version || "";
                var vendor = info.vendor || "";
                window.alert([version, vendor]);
            }
        };
 //-->
</script>

あわせて、JavaScript→Javaの呼び出しの確認として、次のようにAppletのプロパティを直接参照してみます。

<script type="text/javascript">
//<![CDATA[
      alert(document.app.jreVersion);
//-->
</script>

呼び出し方法は実はこれではダメ

当初、この組み合わせでいろいろ試していたのですが、実はOperaだけJavaScript→Javaの呼び出しで失敗することが多くて(undefinedが返る)、さてどうしたものか、と悩んでいました。それ以外のブラウザでは正確にAppletのプロパティにアクセスできるので、アクセス方法は間違ってることは無さそう。OperaはAppletへのアクセスはサポートしてないのかな、、と思ってたときに、そういえばAJAXまわりの話題でOperaはロードのタイミングが他のブラウザと比べておかしい、みたいな話題を見たことをフと思い出しました。「もしやappletがロードし終わる前にアクセスしようとしてる?」と思い、プロパティへのアクセスをwaitをかけてズラしてみました。

<script type="text/javascript">
//<![CDATA[
      var d = document;
      setTimeout(function(){alert(d.app.jreVersion)}, 3000);
//-->
</script>

ビンゴ!

setTimeoutでアクセス時間をズラしてあげることで、Operaでもアクセスが可能になりました。やはりOperaはAppletへのプロパティアクセスが他のブラウザよりも早く(?)行われていたみたいです。本当は3000ms決め打ちじゃなくて、一定回数試行した方がいいのですが、とりあえず今回の実験はこの方法を取る事にして、いろんなappletロード方法の組み合わせと比較してみたいと思います。

ちなみに、今回試したブラウザの細かなバージョンについては、IE 7, Firefox 3.0.8, Safari 3.2.2, Opera 10.00 alpha, Chrome 2.0.171.0となっています。すべてWindows XP上での動作確認です。

パターン1 : appletタグでロード

まずは一番シンプルでレガシーな方法。

<applet name="app" code="VMInfo" mayscript="true" archive="plugin.jar" width="430" height="200"></applet>

結果は次の通り。

Browser 表示 JS→Java Java→JS
IE7
Fx3
Safari3
Opera10
Chrome2

全部OK! レガシーな方法はモダンブラウザでもちゃんと動くようです。

パターン2 : objectタグでシンプルにロード

次にobjectタグでロード。ただし、オプション情報はすべてobject要素の属性に設定するシンプルなロード方法にしてみます。

<object id="app" classid="java:VMInfo" archive="plugin.jar"
mayscript="true" type="application/x-java-applet" width="230"
height="100">

結果は次の通りとなりました。

Browser 表示 JS→Java Java→JS
IE7 × × ×
Fx3
Safari3 ×
Opera10 ×
Chrome2 × ×

この形式だとIEだと表示すらしてくれませんでした。JSからの呼び出しもなかなかうまくいかない模様です。 むしろシンプルな方法だとobjectタグを利用した場合、IE以外のブラウザでも表示してくれるのは新しい発見でした。

パターン3 : objectタグでparamタグと組み合わせてロード

次にparamタグと組み合わせてobjectタグでロード。

<object id="app"
classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="230"
height="100">
<param name="code" value="VMInfo"
/>
<param name="archive" value="plugin.jar" />No
applet
</object>

結果は次の通りとなりました。

Browser 表示 JS→Java Java→JS
IE7
Fx3 × × ×
Safari3 × × ×
Opera10 × × ×
Chrome2 × × ×

これも面白い結果。object/paramの組み合わせ方法はやはりAppletの場合でもIEしか有効では無い模様です。

パターン4 : embedタグでロード

次にパターン2,3とは逆にembedタグのみでロードしてみました。

<embed code="VMInfo.class" width="230" height="100" name="app"
type="application/x-java-applet;version=1.6"
pluginspage="http://java.sun.com/javase/downloads/ea.jsp" />

Browser 表示 JS→Java Java→JS
IE7 × × ×
Fx3
Safari3
Opera10 ○(*) ○(*)
Chrome2

こちらは、IE, Opera以外は総じて良い結果になりました。 Operaは、JavaScriptからJavaの呼び出しにおいて、「○」としましたが、不安定なことが多く成功したりしなかったり、ということが繰り返されていたことを注釈として付け加えておきます。

まとめ

モダンブラウザにおいてもJavaScriptからAppletの呼び出し、AppletからJavaScriptの呼び出しなど、言語間の連携は可能であることが確認できました。また、Appletのプログラムは、その呼び出し方法によってブラウザごとでまったく挙動が異なることが分かりました。特に気にしなければappletタグで呼び出すのが最も安定した呼び出し方法で、IEのみでロードをさせたいときはFlashと同じくObject/paramタグの組み合わせで呼び出すのがベストなようです。

さて、今回はここで終わりますが実はappletの呼び出し方法はappletタグでの呼び出しはベストな解ではありません。

  • Java-pluginがインストールされていないときの自動プラグインインストール
  • appletのキャッシュコントロール

などを考えたいときに、もっと凝った方法を取る必要があります。この話は次回に書いてみたいと思います。

Tokyo 2.0でmeeting24.tvを発表してきました

毎月行われてるWeb2.0的なサービスの紹介イベント、Tokyo 2.0 で、弊社のWebミーティングシステムのmeeting24.tvの発表をしてきました。内容として新しいもの好きな海外の方をターゲット、ということで技術ガリガリな内容ではなく、敢えてネタ度高めな構成にしてみました。

当日の様子はUstreamの録画から確認することが可能です。8分30秒過ぎくらいから出てきます。

英語で発表するとか学生のころの学会以来。。。まー前半のグラフのところと後半のダウ平均価格のあたりの下り、思ったよりウケててよかったです。あと、だいぶプレゼンも慣れてこれたのが個人的にはよかったですね。

PoundでReverse Proxy環境を構築してHTTPとRTMPTを共存

(2009/03/04 22:55追記) typesterさんから

mod_proxyでできるんじゃないのかな

なコメントをいただきましたが、ご指摘とおり、mod_proxyだけでも共存は可能だと思います。今回は試験的な意味もこめてPoundを使って環境構築をしましたが、おいおいmod_proxyも試してみたいと思っています。(ここまで追記)

Wowza Media ServerなんかのRTMPサーバは、標準の1935番ポートへの接続ができないクライアントのために、HTTPでカプセル化した通信(RTMPT)を受け付けるために、80番ポートでの待ち受けが可能です。(さらにSSL化した443番ポートでの通信RTMPSなんかもあります)

ただ、1台のマシンでWebサーバと共存させる場合、80番ポートが競合するのでこのままではうまく共存できません。そこで、Reverse Proxyを利用してHTTP, RTMPTそれぞれのアクセスを別ドメインへのアクセスとして、自身のHTTP, RTMPT待ち受けポートを80番以外のものにしてあげると共存が可能になります。たとえば、ポート番号をReverse Proxy=80, HTTP=81, RTMPT=82なんかにして、Reverse ProxyがHTTP, RTMPTをそれぞれのサービスに振り分けてあげればいいわけですね。

さて、こんな環境を構築しようと思って「Reverse Proxy何にしよう?Squidとか使えば言いわけ??」と思って@kawatasoに相談したところ、「それPoundでできるよ」とアドバイスをもらいました。Poundは初めて使ったのですが、単純なReverse Proxy環境を構築するにはものすごく簡単に実現できました。と、いうわけで今回はその構築メモを残しておきたいと思います。環境はFedora9です。

Poundのインストール

まず、Poundのビルドに必要な次のものをインストールします。

$sudo yum -y install openssl-devel
$sudo yum -y install pcre-devel
$sudo yum -y install google-perftools-devel
$sudo yum -y install rpmbuild

Poundはソースのrpmが公式サイトにあります。

これをDL後、ビルド、インストールします。

$ sudo /usr/bin/rpmbuild --rebuild pound-2.4.4-1.src.rpm
$ cd /usr/src/redhat/RPMS/i386
$ sudo rpm -ivh pound-2.4.4-1.i386.rpm 

インストールしたら、サービスにも登録しておきましょう。

$ sudo /sbin/chkconfig pound on

mod_rpafの導入

いきなりPoundの話でもいいのですが、その話はもう少し後にしましょう。

Reverse Proxyを導入すると、Apacheのログがクライアントからのアクセスではなく、全部Reverse Proxyからのアクセスになってしまってしまいます。これは、ログとしては好ましくないので、まずはこれを回避します。方法は簡単で、mod_rpafを導入すればOKです。

Apacheのモジュールのインストールは、apxsが必要になりますが、これはhttpd-develがインストールされてある必要があります。

$ sudo yum -y install httpd-devel

その上で、ソースを公式サイトからDLしておきます。

$ wget http://stderr.net/apache/rpaf/download/mod_rpaf-0.6.tar.gz
$ tar zxf mod_rpaf-0.6.tar.gz
$ cd mod_rpaf-0.6

その後、Makefileを修正します。Apacheは2.x系が入っていることとします。先頭のAPXS2の実際の場所を指定してあげます。

APXS2=/usr/sbin/apxs

その後、Apache2.x系用のmake, make installを行います。

make rpaf-2.0
sudo make-install-2.0

ここで、mod_rpafを有効にするため、/etc/httpd/conf.d/ にrpaf.confの名前で次の内容のconfファイルを作成しておきます。ここでは、Reverse Proxyの場所を指定していますが、Reverse Proxyは同一マシン上に存在している前提で、127.0.0.1の自分自身を指定しておきます。

LoadModule rpaf_module modules/mod_rpaf-2.0.so
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1

Poundのログの場所を修正

Poundのログは標準では/var/log/messagesに出力されるので、messages がどんどん肥大化してしまいます。そこで、/var/log/pound に出力されるように変更します。

Fedora9では標準でrsyslogが起動しているかと思いますので、/etc/rsyslog.confを編集します。

# *.info;mail.none;authpriv.none;cron.none; /var/log/messages を
*.info;mail.none;authpriv.none;cron.none;local1.none /var/log/messages # に変更

# 以下の行も追加
local1.*                                  /var/log/pound

その後、rsyslogを再起動しておきます。

$ sudo /etc/init.d/rsyslog restart

Apacheの待ち受けポートの変更

/etc/httpd/conf/httpd.conf で、次のように待ち受けポートを変更しておきます。今回は81番ポートに変更します。

#Listen 80 これを次のように変更
Listen 81

RTMPTサーバの待ち受けポートの変更

Wowza Media Server では、/usr/local/WowzaMediaServer/conf/VHost.xmlを編集します。

 <HostPort>
         <ProcessorCount>4</ProcessorCount>
         <IpAddress>*</IpAddress>
         <Port>80</Port>
         <SocketConfiguration>
                 <ReuseAddress>true</ReuseAddress>
                 <ReceiveBufferSize>24000</ReceiveBufferSize>
                 <SendBufferSize>65000</SendBufferSize>
                 <KeepAlive>true</KeepAlive>
         </SocketConfiguration>
         <HTTPProvider>
                 <BaseClass>com.wowza.wms.http.HTTPServerVersion</BaseClass>
                 <Properties>
                 </Properties>
         </HTTPProvider>
 </HostPort>

の箇所をコメントアウトを外し、ポート番号を80 → 82に設定しておきます。

Poundの設定

やっとこさ、Poundの設定です。今回は、HTTPの通信はwww.katsuma.tv, RTMPTの通信はrtmpt.katsuma.tvとしてアクセスを受け付けることとします。実際のApacheは81番, RTMPサーバは82番ポートでの待ち受けを行っていることを想定しています。(DNSの設定は別途行っておく必要はあります)

ここでは、/etc/pound/pound.confを次のように書き直します。(pound.confは念のためバックアップしておくことをおすすめします)

User "nobody"
Group "nobody"
RootJail "/usr/share/pound"
Control "/var/run/pound/ctl_socket"

LogLevel    3
Alive       60
Daemon      1
LogFacility local1

# Main listening ports
ListenHTTP
    Address 0.0.0.0
    Port    80
    xHTTP   1
End


# Catch-all server(s)

# Apache
Service
    HeadRequire "Host: .*www.katsuma.tv.*"
    BackEnd
       Address 127.0.0.1
       Port 81
    End
End

# RTMPT
Service
    HeadRequire "Host: .*rtmpt.katsuma.tv.*"
   BackEnd
       Address 127.0.0.1
       Port 82
    End
End

Service
    BackEnd
        Address 127.0.0.1
        Port    81
    End
    Session
        Type    BASIC
        TTL     300
    End
End

上から読むと、そのまま理解できるかと思います。ListenHTTPのディレクティブでProxyとしては80番ポート待ち受け、Serviceディレクティブで内部サーバ(ここでは自分自身ですがもちろん他のサーバを指定することは可能です)のリクエスト先のホスト情報、サーバアドレス、サーバポートを指定します。

先頭のLogLevelは次のとおりです。

  • 0 - no logging
  • 1 - normal log
  • 2 - full log
  • 3 - Apache combined log format
  • 4 - Apache combined log format without virtual host

LogFacilityについては、先に書いたrsyslogとの兼ね合いですね。その他の情報についてはman poundを見られるのが一番よいかと思われます。

サービスの再起動

これで全部準備は揃ったので、全サービスを再起動します。

$ sudo /etc/init.d/httpd restart
$ sudo /etc/init.d/WowzaMediaServer restart
$ sudo /etc/init.d/pound start

これで、HTTPとRTMPTを1台のマシンでハンドリングさせることが可能になりました。

まとめ

今回は実質Pound以外の設定のほうが面倒なことが多かったかと思いますが、Pound自身の設定は簡単だったと思います。HTTPサーバとRTMPTサーバの共存、という形で設定を行いましたが、もちろんHTTPサーバの負荷分散という形での利用もOKです。(むしろそっちの利用方法のほうが今どきっぽく正しいはず)

参考

手軽なロードバランサ Pound を導入してみました

Key-Value Store勉強会に行ってきました

greeさんで開催されたKey Value Store勉強会に行ってきました。

時間にして4時間超え、内容も国内のKey-Value Storeなソフトウェアの最前線の話ばかりで相当なボリューム。以下、メモってたのを残しておきたいと思います。(誤字、脱字、内容に誤りを含むものなどありましたらお伝えください)また、発表者の方やプロダクトについて、ざっくり調べてURL見つけられたものについてはリンク張っています。

森さん / 末永さん  

  • groonga
    • Sennaの後継エンジン
      • 融通が効かないのがSennaのデメリット
    • スコア算出式のカスタマイズなど
    • Sennaの転置索引
    • 索引の構成部品を自由に組み合わせて使える
    • APIもいろいろ
      • QL
      • DB
      • Low Level
    • memcached互換のkey-value store
    • バイナリのみ対応
      • 計測
        • クライアント memstorm-0.6.8
        • memcachedと同じくらいの性能
        • valueサイズが小さいとほとんどかわらない
        • valueサイズが大きくなると少しパフォーマンス悪くなる
    • DB的な使い方もできる
      • Scheme以外の言語バインディングもできる(はず
    • 名前の由来
      • ブルース音楽の発祥地(?
    • Sennaともあんましかわらない(はず

山田浩之さん (LuxIO)

  • IBM, Yahoo, MetaCast
  • LuxIO (ラックスIO)
    • データベースマネージャ
      • C++
      • B+tree,
    • 分散はなし
  • ほかに不得意なことがすこし得意
  • 分散検索エンジンLuxの内部データベースとして開発
  • 普通のB+-tree
  • 特徴1
    • mapped index
    • index部を全部mmap
      • index部を実メモリより小さいシステムが対象
  • 特徴2
    • 長いvalue
    • 4Gまで
    • node size(page size)をこえたvalueも余計なオーバーヘッドなしで扱える
  • 特徴3
    • 効率的なappend
    • paddingなしでLinkedListのデータ構造
  • SSDに向いてる?
  • 使い道
    • key-valともに小さいデータで構想なアクセスが必要な場合
    • 実メモリ以下のデータベースという制約あり
    • 大きなvalueを扱いたい場合
    • 大きなvalueをどんどん追記したい
  • 向かない処理
    • 削除が多い処理
    • 小さいデータをたくさんリンク
      • seekのオーバーヘッドが大きすぎる
    • Read,Writeの激しいアプリ
  • 分散はたぶんしない
  • Hashはつくるかも
  • read lockはなくしたい
    • 読み込みを重きをおく
  • 単純に作ってみたかった
  • 名前の由来
    • リッチな検索エンジン
    • 某シャンプーからとった(←ウケた

平林さん (TokyoCabinet / TokyoTyrant)

  • Tokyo-Cabinet の歴史
  • 全文検索システムSnatcher
    • Namazu、スニペットつき
    • GDBMをベースにした転置インデックス
  • 計量データベースライブラリQDBM
    • cat mode, B+木対応のGDBM
  • 全文検索システム Estraier
  • 全文検索システム HyperEstraier
  • mixiの検索機能
    • 外部システムからHEベースへ
    • この成長ペースだと破綻するのは必須。。。
  • Tokyo Cabinet
    • モダンなQDBM
      • C99, Pthread, mmap pread/pwrite...
      • win32互換を破棄
    • でも検索機能にはあんまり使ってない
      • HEからTokyo Dystopiaにおきかえたもの
      • 主にデータマイニングで利用
      • HWのスペックあがってきててメモリ豊富なマシンでうごかせばHEのままでいい
  • ハッシュデータベース
    • static hashingによる単純化
  • データフォーマットの効率化
    • BER圧縮、アラインメントとビットシフト
  • フリーブロックプール
    • ベストフィットアロケーション
  • メモリにのればmmap, それ以外はpread
  • ページキャッシュとBTree索引
    • LRU削除キャッシュ
  • 多機能
    • 順序を維持、カスタム比較関数
    • 範囲検索、カーソル
  • Trick
    • 格納時にページ単位で圧縮可能
    • 投機的探索
    • 並列性はテーブル全体のrwrite
  • そのほか
    • レコードに複数のカラム
    • スキーマ不要
    • 250万qps
  • Tokyo Tyrant
    • TCのネットワーク対応
      • ローカルのマルチプロセスでもDB共有に利用
    • 並列化
      • スレッドプール
      • epoll. kqueue, evenports利用
    • 各種プロトコル
      • 独自バイナリ、memcached互換、HTTP互換
    • 抽象データベース
    • 60000qps
    • これから
      • 並列分散処理の時代?
      • TC/TTは1台あたりのスループットを最大化する技術
      • 1台あたりでできることは増えてる

岡野原さん (Key-valueの効率的格納)

  • 興味分野
    • データ圧縮、自然言語処理、全文検索
  • 文字列のキーを利用していろんな値を格納したい
  • 方法1
    • 木による格納
    • キーに対してtrieなどの木構造を構築し、木の接点、葉に値を格納など
  • 方法2
    • ハッシュによる格納
  • 木によるキーの格納
    • 各枝に文字が付随、つなげるとキー
    • 値は接点の先
  • tx : 木の簡潔h町減による木の簡潔な表現によるtrieライブラリ(09/02/22 修正。thx myuiさん)
    • キー集合をコンパクトに格納し操作可能
    • 元のサイズの約1/2 で格納
    • 10億くらいのキーでものる
    • select, rankの組み合わせで定数時間で探索可能
  • ハッシュ
    • Cuckoo Hashing
    • 1から作り直す確率は非常に低い
    • 全体の平均計算量はキーの線形倍で

前坂さん

  • mixi, R&D
  • memcached
    • LRU
  • 最近はARCアルゴリズムがあつい??
    • Patentされてる
  • Key/Value,
    • Value=Object
    • 1MB以内なら何でも扱える
  • RDBMSもキャッシュできるよ!
    • MySQL
      • QueryCache
    • 採用するには厳しい理由
      • オブジェクトの粒度をコンとトールできない
      • テーブル更新でデータがinvalidate
      • マシンをこえたメモリ容量がつかえない
      • フラグメントが発生しやすい
      • キャッシュを共有できない
      • ロードバランサは?
      • 一貫性のないキャッシュ配布
  • Facebook
    • 28TB
    • 独自の改良
    • Shared Buffer Pool
    • Stats Global Lock  の除去
    • TCPからUDPへの移行(cacheだし)
    • 通信パケットのバッチ
    • 秒間20万クエリ(!!!!←すごい)
    • 変更しすぎたのでとりこまれなかった
      • 一部はとりこまれる予定
  • 最近の話
    • バイナリプロトコルでno-replyが加わった
    • エラーはかえす
    • CASに固定で8byteもわりあてていいの?
  • 11211はmemcachedのポートとして公式に決定された

安井さん(repcached のなかみ)

  • KLabの方
  • memcacpedにレプリケーション機能をつけたもの
  • 案1 マルチスレッド
    • スレッド作成
    • キューをつくってセットされたデータを入れる
    • メリット
      • 本体への影響がすくなそう
      • 比較的簡単
    • ただし、、
      • アクセス数が多いときに問題発生
      • 忙しいときにレプリケーション処理が追いつかない
      • キューがあふれる
      • memcachedのレスポンスが悪くなる
  • 案2 シングルスレッド
    • libeventを利用
    • ハンドラを登録しておくとコールバックしてくれる
    • 自分でselect(2), poll(2)とかしなくていいのでらくちん
    • set/addのついでにrepl
      • プロトコルの処理中にレプる必要
      • どうしても応答時間が長くなる
  • 案3 Pipeにキーを書き込むように変更
    • だいぶよくなった
    • やっぱりリクエストが多くなれば素のパフォーマンスよりもすこし悪くなる
  • 今のところ2台までの構成
    • 1台だけレプリケーション?
    • 3台使わないといけないシチュエーションがまだない
  • 利用用途
    • PHPのセッション管理
    • 某SNSのアバターの着せ替え機能のセッションなど
      • OKおすまで

たけまるさん

  • Kai = Dynamo + memcached API / Erlang
  • Dynamoの特徴
    • amazonの裏
    • 分散したkey-val
    • 高い分散透過性
    • ショッピングカートでも使われてるらしい
    • 高い可用性
      • ロックなし、いつでもかきこめる
      • Eventually Consistant
        • 3レプリカ
        • Consistent Hashingで選択
          • ベクトルタイムスタンプを比較
          • 古いデータを上書き
        • 結果的に整合性がとれる
    • 分散透過性
      • 分散していることの隠蔽
        • P2P
      • 透過性が高いと管理コストが低下
      • 場所、移動、障害
    • memcachedのAPIだけだとすこし不十分、、、
      • なんだけども、とりあえずサポート
    • Erlangの使いどころ
      • 分散システムの適している
      • アクターモデルが便利
        • 共有メモリがなく安全
        • プロセスが軽い
        • Copy on write的にメッセージングパッシングを効率化
      • そこそこ速い
        • Java未満、LL以上
      • 弱点は正規表現がだめ
  • Kai
    • Dynamo + memcached API / Erlang実装
    • 開発者の本籍地から命名
      • 検索しにくい。。
    • Kaiの性能
      • 約10000 qps
    • Erlangの備え付けのストレージがボトルネックっぽい
      • TCとか使えばいい?
    • 某ポータルサイトで試験中らしい

上野さん (分散メディアストレージ的ななにか)

  • 株式会社Fillotの方
  • 配信をメインターゲット
  • ブロードバンドメディアの配信基盤
  • Cagra
    • 1000 speakers confで古橋さんとペアプロでつくった
      • amazon dynamo like zero-hop DHT
        • consistant hashing based
      • zero conf
      • single thread
    •  商用版を作成中
      • 独自アルゴリズム
      • multi thread / FSM
    • リセットした理由
      • 商用化
      • アーキテクチャの限界
        • fiberアーキテクチャ
        • TCPチューニング重要
          • パフォーマンスが4桁あがった
          • read/writeは計画的に
      • アルゴリズムの限界
        • 人気の集中
        • 非対称ノード
          • Virtual node増減させる?
          • LC-VSS by Godfrey et al.
          • 大量のノード前提
        • データ局所性
          • DHT => すべてをぶちこわす。。!
            • 似たようなコンテンツもバラバラ
          • 検索どうしよう?
        • 少数ノード系
          • 最近の論文だと大規模系を対象にしすぎ
          • 昔の論文のほうが数十ノードを対象にしていて実は役立ったりする
    • これらの問題を解決すべきアルゴリズムを改良中

古橋さん (kumofs, kumo fast strage)

  • えとらぼ株式会社のプロジェクト
    • 小さいkey-valueを大量に保存
    • 永続化させたい
  • 名前
    • 雲は落ちない!(会場でおおお!という声)
  • 特徴
    • replicationは3つ
    • サーバおちても動作
    • サーバを追加してスケールアウト
    • 低遅延
  • 機能
    • set, get, delete
  • 性能的にはmemcachedよりいい
  • 応答速度はmemcachedよりすこし遅い
    • set
      • 非同期にすることで速くなる
    • ハイブリッドP2P型
      • Gateway
        • ローカルホストに
        • memcachedのプロトコルで扱えるように
      • Manager
        • サーバ一覧を監視
        • GatewayやServerに通達
    • ハッシュ空間は2つもっている
      • 古いバージョン(rhs)と新しいバージョン(whs)
    • 困った
      • 再配置で大量のトラフィック
      • Managerの分断問題
      • Gatewayを中継するのはオーバーヘッド?
      • deleteが一貫性を保証しない
      • バックエンドDBにTC

西澤さん(ROMA)

  • ROMA
    • 複数マシンから構成されるP2Pを利用した
    • Ruby実装のkey-value store
    • Key : 4~6KB
  • 社内クラウド
    • 高負荷な状況であっても十分高速なデータアクセス
  • Pure P2Pで自律的にノード管理
    • Consistent Hash(環状)
  • 各ノードが環全体のノード情報を保持
  • クライアントが環情報を保持することも可能
    • ROMAに始めてアクセスしたときにクライアントは環序湯法を取得
  • クライアントとRoma間は独自プロトコル
    • Java, Rubyで実装
    • 開発者に分散を意識させない
  • データPUT時に、ノードは左右のノードにレプリケーションされる
    • データは3つ存在することになる
    • クライアントはレプリケーション完了まで待つ
  • 障害がなくてもPUTレプリケーション失敗するときがある
    • ノードが忙しすぎるときとか
  • マスターがPUT成功したらクライアントにはPUT成功を返す
    • PUT失敗した隣接ノードはdirty flag
    • dirty flagは自然に解消される
  • ノードの参加、脱退が自由に可能
    • 各ノードはじわじわ情報を伝搬させていく

首藤さん

  • Overlay Weaver のデモ
    • オーバーレイ上でのDNS
  • PC1台で15万くらいのノードをシミュレーション
  • 性能重視
    • no-hop
    • 全ノードが全ノードを知る
  • スケーラビリティ(P2P由来)
    • multi-hop
    • 小さな経路表O(log n)以下
  • XML-RPC, memcachedプロトコル
    • memcache対応のためにあえて1つだけしかvalueを返さない、とか
  • クラウド上の技術コンテストがあるのでぜひ参加してください!

藤本さん

  • Flare
  • memcached互換
    • delete key expire_date(!)
      • 実装していない
    • 勝手拡張も
  • Diskに書き込み(メモリ上じゃない)
    • TCベース
    • Slaveの数だけenque
  • set → getですぐに取得できない場合にset syncコマンドがある
  • proxy機能も
  • 2000 qps
    • greeの足跡で使ってる
      • mixiの足跡でTTを使っていると信じていた(←某記事は少し間違ってたみたい)

まとめ

メモ読み返しただけでも相当濃い内容でした。同時にこの分野のトレンドはざっと見渡せた感じ。印象深いのはTokyo Cabinetを最下層のストレージに使って、その上でいろんな展開をしている、というトレンドはありそう。あと岡野原さんや首藤さんたちの学問的なアプローチからの視点によるKey-Value Storeの話も面白かったです。ハッシュ関数のトレンド(!)なんてあるんですねー。

ボリュームがあったからかもしれませんが、久々にインプットが相当多い勉強会でした。企画、司会をされた太田さん、場所を提供いただいたgreeのみなさん、どうもありがとうございました!

はじめてのgithub

いろんなBlog巡回してると、どこもかしこもgit, gitなのでアカウントだけ作って放置してたgithubで昔に書いたちょこちょこしたコードをコミットしてみました。

さすがにはじめてのgitは戸惑うことばかりだったので、メモを残しておきたいと思います。

gitのインストール

作業OSはMac OSXです。ソースからもインストールできますが、管理しやすいようにMac portsでインストールしてしまいます。

sudo port -d sync # 同期
port search git # cogito, git-core, stgit, cgitあたりがあるはず. git-coreを選択
port variants git-core # オプションを確認, 今回はgitweb, svnを指定
sudo port install git-core +gitweb +svn

これで

$ git version 
git version 1.6.1.2

なんかの表示になるとインストールOKですね。

gitのglobal設定

まず、名前とメールアドレスの設定をしておきます。

$ git config --global user.name "ryo katsuma"
$ git config --global user.email katsuma@gmail.com

githubでアカウントを作成

ここからサインアップ。とりあえずFreeのプランでいいと思います。

gravatarでアカウントを作成

gitを使うだけだとここは飛ばしてもいいのですが、githubのアカウントのアバター画像を何か設定したい場合はgravatarのアカウントが必要になります。たしかいろんなサイトでアバター画像を設定するの面倒だから共通化しようよ、みたいなサービスだったかと思います。(実際はgravatar使えるサービスってあまり目にしないのですが。。。)gravatarのアカウント作成はここから。

アカウントを作成したら「My Account」> 「Add an Image」から画像を追加。追加後に「G」「PG」「R」「X」の4つの中からRatingが選択できるようになっているので、ここで「G」を選択しておきます。「Global」というわけで、どのWebサービスでも利用できる、という意味ですね。

ここで、Ratingを選ぶ画面が出てこない場合は、画像の追加からやり直しておきましょう。実際、僕はGravatarのアカウントだけ作って放置してたら処理がおかしくなてどうやってもRatingを選択できませんでした。 そこで画像の追加からやり直したら、うまくいきましたので。

さて、githubのアカウント設定ページに戻ってみましょう。サムネイルの画像がちゃんと表示されてあればGtavatarの設定はOKです。

SSH公開鍵をgithubに登録

githubにpushするときに、SSH公開鍵を登録しておく必要があるようです。公開鍵は自分のホームディレクトリで

$ ssh-keygen

で、$HOME/.ssh/の箇所にid_rsa.pubの名前で作成されます。この内容をコピーしておいて、githubのaccountのページの「SSH Public Keys」の箇所で登録しておきます。(Titleは適当でOK)

レポジトリを作成

まず、github上で管理したいプロジェクトのレポジトリを作成します。githubにログインした状態でトップページの「Create a Repository」から作成します。とりあえず今回は「Rubyでブックマークカウンタの修正スクリプト書きました」のMTBookmarkCounterのdelicious用修正スクリプトをpushするレポジトリを作りたいと思います。レポジトリ名は「MT Delicious Bookmark Counter」で作成することにします。

githubにpush

作成後はレポジトリにpushする方法が表示されるので、基本的にはこれに習うことにします。

まず、ローカルでpushしたいファイルがある場所に移動します。その後、

git init

で、作業ディレクトリの初期化を行います。

git add delicious.rb simple-json.rb

で、コミットしたいファイルを登録します。

git commit -m 'first commit'

で、実際にローカルにコミットします。ここではコミット時のコメントが「first commit」になっているわけですね。

git remote add origin git@github.com:katsuma/mt-delicious-bookmark-counter.git

で、リモートレポジトリに登録します。ここでは「github:{githubのユーザ名}/{githubで管理したいレポジトリ名}」になっています。ここでのレポジトリ名は、さっきgithub上でレポジトリを作成したときに表示されているはずなので、それに従います。

git push origin master  

で、実際にgithubにpushされます。ここで、SSH公開鍵の設定などに不備があるとエラーになります。特にエラーメッセージが表示されない場合は、pushできているはずなので、確認してみましょう。たとえば今回のレポジトリだと、このようにアクセスできるはずです。

まとめ

実際は作業をしている中で公開鍵まわりでエラーがよく出て、なかなかpushするのに手間取っていました。ただ、コミットはものすごく簡単にできるので、手元で気軽にバージョン管理するにはかなりよさそうです。

とりあえず僕の方針として、大きめのプロジェクトなんかはGoogle codeなんかでホスティングして、小ネタなんかはどんどんgithubにpushしていくことにしたいと思います。あと、.zshrcとか設定ファイルなんかをpushしておくのもいいかもですね。

Gmailのビデオチャットで利用しているCodecはH.264(っぽい)

Gmail上で本日付でビデオチャット機能が追加されました。これ自体はGoogleだったらいつかはやるだろうな、と思っていたので特に驚かなかったのですが、そんなことよりも利用しているCodecが何なのか?の方が個人的に気になりました。

映像はブラウザ上で再生されるのですが、どうやらFlashPlayer上で再生されている模様。(右クリックでポップアップされるメニューがいつものアレ)ただ、画質がすごく綺麗。Flashでライブストリーミングをやったことがある人だったら分かる人もいるかもしれませんが、ほんとありえない綺麗な画質。念のため補足しておくと、Flashで利用できる映像ストリーミングのCodecは次の種類があります。

Codec 導入されたFlashPlayer
Sorenson Spark 6
On2 TrueMotion VP6-E 8
On2 TrueMotion VP6-S 9.0.115.0
H.264 9.0.115.0

この中のSorensonのCodecがFlashPlayerでカメラデバイスから映像を拾ってストリーミングするときに利用できるCodec。これは特に軽さを重視したCodecで、お世辞にも綺麗な映像とは言えないものの、マシンに大きな負荷をかけずにストリーミングを行うことが可能。UstreamStickamUtagoe Live100なんかでライブを行うときもこのCodecを利用することになります。

ただこれだとプロユースというか、まともな高画質のストリーミングを行うことは無理なので、負荷が大きくなっても品質のいい配信をしたい!なんてときはVP6やH.264のCodecを利用してストリーミングを行うことになります。この場合はブラウザからのストリーミングは無理で、AdobeのFlash Media Live Encoderなどの専用ソフトを利用したストリーミングとなります。

で、やっと本題なのですが、今回のGmailでのビデオチャットはFlashを利用しているのでSorensonのCodecを利用すればインストールレスでチャット可能なはずなのに、わざわざプラグインのインストールを必要としています。つまりこれ専用のEncode処理をクライアント側のプラグインで行っている、ということ。かつ、FlashPlayerで再生可能、ということでVP6かH.264のどちらか。。。とは言ってもさすがにH.264のDecode処理はまだ重いしな。。。なんかを考えてオフィシャルGmail Blogを読んでいると次のような記述がしれっと書かれていました。

And in the spirit of open communications, we designed this feature using Internet standards such as XMPP, RTP, and H.264, which means that third-party applications and networks can choose to interoperate with Gmail voice and video chat.

via Say hello to Gmail voice and video chat

おおお、というわけでこのCodecはどうもH.264っぽい。やけに綺麗と思った理由はこれだったのですね。あとinternet standardという理由からVP6は却下になったんでしょうか。

あと、気になった点としてこのチャットの利用帯域。今日@ishidaと遠隔地でテストしていたのですが、その利用帯域をメモってくれていました。

gmail videochat up:800~1000kbps/down:600~800kbps

via Twitter

普段、Sorensonでのストリーミングばかり見慣れている自分としては、「Flashのストリーミングは映像での利用帯域は代替250kbps前後」という感覚が強かったのでこの利用帯域はちょっとびっくり。でも映像のクオリティを考えるとこのレートでも低い値なのかもしれません。

また、CnetでCPUリソース食い過ぎてる!という話が出ていましたが、これもH.264のソフトウェアエンコードをしていることを考えると、納得できそうな話です。

まとめ

Flash Playerの前提条件や実験結果からの推測などを総合して考えても今回のビデオチャットの利用CodecはH.264と言えそうです。また、僕が知る限り、ブラウザ起動でできるH.264ストリーミングは多分今回が初事例。と、いうわけでしれっと始まったGoogleのビデオチャットはいろいろと面白い話が潜んでいるようです。

開発合宿をしてきました

FILM developers camp

大学時代の同期の友人たちと一緒に11/1〜11/3の二泊三日、伊東で開発合宿をしてきました。よくありがちなWebサービスを集中的にがー!っと作るやつですが、今回は仕事でのWeb系開発経験者は参加メンバー7人中3人。あとはIT系とは言えまったく違う仕事、というわけでなかなかの面白い合宿になりました。了解とってないので名前はふせつつ、メンバー構成を言っておくと

  • 僕(恵比寿で働くWeb屋)
  • 恵比寿で働くASer
  • 某大手サイトのエンジニア
  • ITコンサルタント
  • 某外資系CPU屋
  • 某外資系OS屋
  • 某インフラ屋

と、まー「これだけいろんな方面の人間集めたらなんとかなるだろう」というお役所的視点で集まったメンバーと言っても過言では無いくらいのバラエティに富んだ構成になりました。世間でにわかに流行りがちな開発合宿でも、こんなメンバーでWebサービスを立ち上げようとするのはなかなか無いのでしょうか?

合宿までの道のり

まず、「何を作ったか?」ということについてですが、残念ながらまだローンチまでは辿り着けなかったので(ローカルで動くレベルで精一杯だった)、とりあえずこの段階では伏せておきたいと思います。ただ、数ヶ月前から何度も実際に顔を合わせてディスカッションをして決めたものだったので、それなりにニーズがあったり自分たちで作り上げたいものであった、とだけ言っておきたいと思います。今回は参加者が7人とやや多かったので、3人+4人の2グループに分けて2アプリを作ることにしました。

次に開発言語+フレームワークについて。これは決め方に結構悩みました。僕はPHP+CakePHPに慣れているので、これを選ぶとそれなりにアドバイスもできるし、サクサク開発は進む事になるはず。一方で、せっかくなんで全然違う言語やフレームワークを学んでみたい、という思いもあったり。特にRailsをやってみたいなーとは強く思ってました。ただ、他のメンバーで「軽くPythonを仕事で触ってるからできればそれを。。」という声もあったりで、なかなかいい決定打も無く、結局

  • Python/Django
  • PHP/CalePHP
  • Ruby/Ruby on Rails

から3択のあみだクジで決めることにしました。ちなみに、くじにはこれを利用しました。

「Rails!Rails!!」と、心の中で叫ぶ中、無情にもクジは「Python/Django」に、、、w。

と、いうわけで開発はDjangoに決定。まぁ、Google App Engineでも動くようだし、これはこれでメリットもあるのかな、と前向きに捉えました。

合宿の風景

合宿は伊東の山喜旅館で。ここ、結論から言うと開発合宿用として「かなりいい!」です。まず、開発に必要なもの、あると便利なものがこれでもかと揃っています。今回、僕たちは以下のものを借りました。

  • Wi-Fi
  • 長机(3つ)
  • 全員分のパイプ椅子(7つ)
  • 電源タップ(2つ)
  • ホワイトボード

以上のものは元々の料金でコミコミです。あと、必要ならばプロジェクタも追加料金で貸してもらえるようですが、今回は利用しませんでした。特によかったのがホワイトボード。これ地味にあって大正解です。一番上の写真でもあるとおり、グループごとにサービスのイメージの詳細を詰めていく絵を描くのに非常に役立ちました。合宿をされる方はここポイントにされたほうがよさそう。

そもそも、ここを選んだ理由としてトップページに

企業研修・ゼミ・合宿・営業会議・企画会議・経営会議・各種組合会合・開発合宿

と、ずばりそのキーワードで迎えてくれている点。実際、開発を行うのにはもってこいの場所だったと断言できます。今回は「ゆったりプラン」で頼みました。朝、夕ついて(ごはんも文句なし)一泊8,400円は満足度高いですね。

強いていうなら「お風呂の温度がやや低い」と、いう難点もあるのですが(笑)それでも総合点はかなり高い点を付けることができそうです。もう、 温泉街の旅館やホテルは、この「開発合宿」をサイト内に入れておくは時代的+SEO的にもよさそうです。

で、開発は実際にはこんな感じで1部屋に7人集まって2、2、3の3つの机に別れて真ん中にホワイトボードを置く感じで開発していました。

FILM developers camp

FILM developers camp

FILM developers camp

キメキメの友人Kですw

食事情

旅館のごはんも思っていたよりおいしかったです。旬の魚を中心にボリュームもあるのでかなりの満腹。軽くビールでほろ酔い。

FILM developers camp

で、それ以上に特筆すべきは五味屋というお店の「ねごめし」前段階で「1時間は並ぶ」と聞かされるくらいの人気店で、実際それくらい並んだのですが、まーこれがうまい!海鮮丼をだし汁をかけていただく味は、近くに寄った際にはぜひぜひ!という感じです。一緒に食べたアジの叩き〆アジ(2008.11.6 10:40修正)もおいしかったなぁ。

FILM developers camp

開発風景

で、肝心のDjangoですが、僕はCakeを結構長く触っていた分、その違和感が最後までぬぐえなかったのが本音。最終的にはJavaScriptばっかり書いてて、Pythonのコードは6行くらいしか書かなかったと思います(笑)(実際、jQueryでごりごりUIいじる必要もあったので、これはこれで役立っていた、と思い込んでいます。)

一番の違和感は、static file(css, js, image...)を扱う仕掛けが標準では用意されていない点。たとえばCakeだと、app/webroot以下に入れたファイルはstaticファイルとして、リクエストに対してそのまま返してくれるわけですが、Djangoはこれらのファイルは別サーバに置くか、urls.pyでうまくルーティングさせてあげないといけない点。しかも後者は「あくまで開発用として利用してください!」と本番では推奨されていない点。これを最初知らずに1、2時間つぶしたのが痛かった。。。

逆に、他のメンバはこういうフレームワークを使ったのは初めての人が多かったので、「これは便利!」みたいな印象だった模様。対照的な印象を持ったことは、これはこれで興味深かったですね。実際、言語をまたいでフレームワーク比較をすることはなかなかありそうでないので、僕自身もいい経験にはなりました。

あと、ソース管理はGoogle codeのSubversionを利用しました。オープンソースとして公開されちゃうわけですが、手っ取り早くSubversionの環境を手に入れるにはここが一番早そう。実際ここの導入においてはメンバもそんなに困ってなかった模様。単純に分担作業をする上で、マージを行いやすくするためにも、この選択は正しかったなと思います。

ただ、肝心のローンチがまだ完了していないので、近いうちにまた集まってどういう風にすすめて行くか詰めていく予定です。公開できればそこそこ便利なものになる。。はずです。ローンチの際はここでも紹介したいと思います。

おまけ

最後に、合宿までのマイルストーンのメモ。なかなか異業種の人たちが定期的に顔をあわせて集まるのは難しいのですが、こんな日程で集まっていました。開発合宿をされる方はご参考に。

  • 2008年8月24日(日)

    Pre-Work:上位のアイデアの詳細機能の要件定義

  • 2008年9月13日(土)

    要件決定・技術選定

  • 2008年10月4日(土)

    技術・勉強会

  • 2008年10月18日(土)

    設計

  • 2008年11月1日(土)~3日(月)

    合宿

あらかじめ経験者のみでメンバーが成り立っている場合は、もうちょっと短期間でオンラインのみでサクサク話が進むかもしれません。今回は未経験である上に、特殊なメンバー構成でもあったので、前準備に時間をかけた方だと思います。

Utagoe Live100

Utagoe Live100 (closed beta)

ここ最近ずっと取り掛かりだった新しいライブコミュニケーションサイト「Utagoe Live100」をクローズドベータの形でオープンしました。

「RSSリーダを突き詰めるとライブ映像もaggregateできるものになるはず」なコンセプトのもので、一気に数百くらいのライブ映像を集約していこう、というものです。いまは本サイトから配信しているものだけを集約している形になりますけど、ゆくゆくは他のライブサービスのサイトもsubscribeできる形にしていきたいかな、とおもっています。ずっとつけっぱなしで気づくとポコポコと再生されてくるので、ライブ映像版Twitterみたいなイメージをとっていただいてもいいかもです。

で、いったいどんなサービスなものかと言うと、昨日サイボウズラボで「有名米国ブロガーを集めてプレゼン大会!」みたいなものがあったのですが、そこでの様子を録画していただいていた方がいらしたのでそれを拝借。6分過ぎくらいから流れているのがそれです。


Utagoe Demo from Kristen Nicole on Vimeo.

また、takesakoさんがスライドショーをニコニコ動画にアップしていただいています。

多数の動画をGoogleMapのように見立てて自由に動かせるインターフェースにしたり、一気に多数の映像を再生するために、フレームレートを動的に変更したりといろいろ実験的な試みが多いものになっています。Webレイヤー全部とFlashのベースを僕が作って、FlashのUI部分や細かな調整をishidaがかっこよく仕上げてまとめてくれました。ishida++ 

で、「Live100」といっているだけあって、ハードの設備上、Maxユーザ数を100人に限定している・・・状態なのですが、興味ある方は僕にメールくだされば招待状おくりますので。ちなみに僕のメールアドレスはここからどうぞ。これもハードの設備が増強されていくに従ってLive200, Live300とサービス名が成長していく、という裏テーマもあったりするのはここだけの話ですよ。

あと今回いちばんテンション上がったのはMashableに掲載されていた点。Kristen Nicoleさんもイベントにいらっしゃったみたいですけど、早速記事にしていただきました。

Video: Live from Tokyo Demo. Utagoe is RSS, Chat and Streaming

まだまだ実験的な試みが相当多いサービスですが、これからゆっくり成長させていきたいと思っています。

Twitterのロゴの色が濃くなったのを元に戻すCSS

どうもTwitterのロゴの画像がいきなり今日変更になった模様。色味が少し濃くなったみたい。ただTwitterにどっぷり漬かった生活では、こんな少しの変化も違和感を覚えて仕方ないです。

なので、ユーザCSSで少し書き換えてやることで雰囲気を元に戻してやりました。Stylishで次の設定を追加。

h1>a>img{
-moz-opacity: 0.6;
}

スタイル適用前

スタイル適用後

透明度を変えただけだけども、雰囲気は前の感じに戻った(気がする)。

builder technology に参加してきました

builder technology

Cnet主催のbuilder technologyに参加してきました。昼過ぎまで家で仕事をしていたので、途中参加。以下、ざっくりまとめ。

Mozilla とオープンウェブ / クリストファー・ビアードさん

  • 前半はmozillaの組織に、Fxなどについて
  • 今年は携帯用Fxの開発も頑張るよ
  • 国別ユーザ比率はFXはUSで29%, ドイツで13%, フランス6%, ポーランド4%...と続き、日本では2%
  • 後半はmozilla weaveについて
  • 3月に0.2をリリース予定。サードパティがいじれるようになる予定。
  • 「xulrunnerの立場ってどうなの?」な質問が出てたけど、答えがよくわからなかった。うまくはぶらかされたかというか、、、
  • Prismはxulrunnerベースに、Fx3もxulrunnerベースに、みたいなことを言ってたけど、結局Prismもxulrunnerもいったいどうしていきたいのかは謎

「イマドキ」へ至る道、お見せします / 沢田 正氏さん

  • niftyのオープン化について
  • about meは半ばノリでOpenIDをはじめ、いろんな認証サービスに対応した
  • 流れにのっておかないと、みたいな。他のサービスのユーザが囲え込めるかもしれないし、的な
  • でもIdPになるのはこの時点でリスクがあると判断したそうな。
  • まだまだ参考事例が少なかったので、実装はかなり困ったみたい。手探り状態で実装が続いた
  • 現在のabout meのOpenID経由でアカウント作成しているユーザは、新規会員の全体の1%程度。
  • 他社の認証サービス経由ではYahooが一番多い。→ユーザ数が絶対的に多いから仕方ないんでしょうね
  • まだまだOpenID導入したからよかった!な展開では無いそう

イマドキなWebアプリケーションの作り方 / 宮川達彦さん、米持幸寿さん

  • 全体的にお二人の会話はあまりかみあってない模様w
  • オープンソースどんどん出しますよ、どんどん使いますよ、な柔軟な姿勢のSixApartさん側と、オープンソースとは「投資」であり、ここから何かが生まれてくる畑のような存在で、、と確固たる理念をしっかり持っていIBMさん側とで、全体的に噛み合いそうで噛み合ない
  • コンシューマサイド側 / エンタープライズ側のそれぞれのオープンソースに対する姿勢、という意味になるのかな、それぞれが「いや、こうやって関わるのが当然でしょ?」な空気が出てたの、ある意味面白い。
  • IBMではオープンソースプロジェクトのカタログのようなものがあるそう。このプロジェクトはランクAだから利用してもよい、みたいな。基本的にIBMがまったく関与していないプロジェクトについては、プロダクトに組み入れられることは無いそう(MySQLとか)

どうも今晩は。XMLDBです / 小野雅史さん

  • XMLDBて動いてるの見たのはじめて。JSでデータをひっぱってくるデモを見た
  • 結局まだよくわかってないんですけど、XMLDBてサーバサイドで複数ドキュメントをまとめて操作できるxPathて考えていいんでしょうか??

移動

  • id:zigorouさんと、そのお知り合いの方とで移動
  • ここで相当迷う迷う。僕もそもそも方向音痴ですけど、あの場にいた人たちはみんななかなかアレな感じですねw
  • zigorouさんより後に出てたそうなtakesakoさんの方が早く到着してた

オープンソースプロジェクト「WebKit」のご紹介 / 永松正人さん

  • WebKitベースでSafariはできてるよ、な話
  • 正直すこし前までKHTMLとWebKitの違いがよくわかってなかった
  • WebKitベースのブラウザ用デバッガでDoresoraDroseraなるものがあるらしい
  • Firebugみたいなかんじ。ブレークポイントとか設定できてた。ちょっと使ってみたい
  • WebKitベースの、、と言いつつも実際はSafari3以外はまともに使えないみたい
  • 質疑応答で「Safari1,2の利用者がまだ結構いるんですけど」に対して「3にアップデートしてください」で片付けてたのが笑った。Appleとしては最新の環境にしていないのはダメ、のようで。

Lightning talks

  • Macとプロジェクタの相性が悪くてトラブってた。プロジェクタ再起動で復帰。
  • Cnet?のおねーさんのPCも利用していたみたいだけど、定期的にでてくるニュース表示アプリみたいなのとシュールな壁紙が人気をさらってた
  • Opera9.5はなかなか面白そう!videoタグみたいなのも、使えるようになるそうな
  • リアルタイムに動画の色調をJSで変化させたり、ASでもちょっと難しそうなことをサクサクやってたのが印象的
  • OpenID 2.0は追いかけきれてなかったのでダイジェストが聞けてよかった
  • まだ1.1なサービスしか受けたことないので2.0のよさを実感してないけど、早く使ってみたいけど、今のIdPも2.0に対応してくれるのかな??(という疑問は的を射てるのかな、そもそも)
  • YappoさんのPlusenでのプレゼン、inputは携帯のKeyEventを取ってたの??
  • Mobile + GISS + Twitterはたしかに相性はいいだろうに。ついついツイッター使ってみます
  • 「つい間違えて英語で資料作っちゃいました」が地味にウケた
  • FlexでFastladderのUI作ってた
  • UIとロジックがうまく分かれてるからパーツ組み合わせできるのがいい
  • takesakoさんは飛び入りで参加ながら5分ジャストで終わらせる相変わらずの芸術的なプレゼン
  • 最後はperlなのかgifなのかjsなのか何だかすごいことになってた

とりあえず写真をFlickrに上げてみました。雰囲気はこのあたりでざっくり分かるんじゃないかな、と思います。(問題ありそうな写真はご一報を)

身内勉強会でECMAScriptについてしゃべってきました

大学時代の友人たちを中心にFILM(Future IT Leaders Meeting, 名前だけはでっかくw)という名前の勉強会をやっていくことになりました。この連休の初日にウチの会社で第一回目が開かれたのですが、普段LLを触らない人たち向けにJavaScript / ActionScript(ECMAScript)についてしゃべってきました。

身内をネタに入れこんだものではあるのですが、そのとき話した資料を公開しておきます。(少し前に言っていたS6で作った資料はこれでした)

あと相当グダグダな映像ですが(w)そのとき話してる様子も公開しておきます。WebCam+画面ではなく部屋全体の様子を録画したものなので、何話してるのかよく分からないかと思いますが、こんな感じでグダグダと話していた、な様子を感じ取ってもらえればと思います。

しかし見直してみるとあまりにグダグダ話してるなぁ、、と思います。資料に無いYSlowの話もかなり話してるし。次回はもっとシャキシャキ話そう。。

WEB+DB PRESS Tech Meetingに行ってきました

WEB+DB PRESS Tech Meeting

WEB+DB PRESS主催のWEB+DB PRSESS Tech Meetingに行ってきました。ついでにその流れで懇親会にも。以下、ざっとメモです。

OpenID Comments for MTを導入しました

以前からこのBlogはコメントスパムが激しくて、それがゆえに人力で全部削除して、、、とかなりアナログな運営をしていました。先日もスパムコメントと間違えて大量のありがたいコメントを間違って削除してしまうミスを犯したり、、、orz と、いうわけでそんな凡ミスを防ぐためにも、今回OpenIDの認証サービスを導入してみました。コメント欄に次のようなフォームが表示されていると思います。

openID signin

ここから自分のOpenID URLでサインインをしていただくと、次のようなコメント入力欄が表示されます。

comment by openID

MTはデフォルトでTypePadの認証を利用することができますが、ほかのBlogサービスをご利用の方などにはちょっと敷居があるなぁと思ってコメント欄は完全に開放していたのですが、これで割とオープンな技術での認証ができるんじゃないかな、と思います。コメントスパムの変化についてもみていきたいと思います。

なお、今回はMTのプラグインの「OpenID Comments for MT」を利用してのですが、せっかくなのでその導入メモを残しておきます。

zshのプロンプトを見やすい配色にする

最近、開発環境をcoLinux+Fedora7+zshな感じに移しました。経緯はWEB+DB PRESS Vol.40の「Linux定番開発環境」のコーナーではてなの伊藤直也さんが紹介していたことから。特にzshは前から気になっていたのでこのタイミングで導入をば。

感想としては「これは慣れたらそうとう便利そう!」

かゆいところに手が届くという話は聞いていましたが、

  • 「ディレクトリ名の入力だけでcdできる」(プログラマブルな補完機能)
  • 「ディレクトリスタックを保存」
  • 「コマンドのスペルチェック」

なんかはかなりイィ感じ。これはもっともっと使いこなしたいと思います。

で、唯一「うーん」と思ったのがプロンプトの表示項目+配色について。なんかあまりにも味気ない感じです。。プロンプトに改行も入っていないし、見づらい感じにあるなすし。

zsh

と、いうわけで伊藤直也さんの公開されている.zshrcにそれっぽい配色を加えたものを作ってみました。(作ってみました、というほどでも無いですが。。)

あなたの音感は何点?-ケータイ鼻歌音感ゲーム「はなワザ」

はなワザ

本日、ハナ歌音感ゲームサイトの「はなワザ」をオープンしました。

最近、携帯電話やffmpegの話をここでよく取り上げていたわけですが、全てはこのサイトのためだったわけですね。。いやー普段携帯サイトに慣れていない人間が、初めてマジメに携帯サイト作りに取り掛かったわけですから、なかなか苦労しました。

サイトの仕掛けはいたって単純で、

  1. サイトにアクセスして指定曲をクリック
  2. メーラが立ち上がるので「メニュー」や「添付」からムービーカメラを起動
  3. メロディを口ずさむ
  4. そのままメール送信
  5. 結果メールが返信されるのを待つ

と、これだけ。いたって単純!

今のところ、ひたすら高得点を目指すアスリート競技な「はなワザ★グランプリ」、ひたすらストイックにはなワザ力を上げることを目指す「はなワザ★道場」の2つのメニューです。個人的にはグランプリの方が好きなんですけども、ユーザさんの動向を見ていると道場の方が圧倒的に人気のようです。道場は結果メールではなワザ師範からシュールなオケージョンアドバイスももらえるので、それがいいんかな、、と思ったり。

また、おかげさまで各ニュースサイトさんにもかなり取り上げていただいています。主なものを抜粋させていただくと

  • CNET Japan: あなたの音感は何点?--ケータイ鼻歌音感ゲーム「はなワザ」
  • ITmedia: あなたの "鼻歌" 採点します--ケータイ向け鼻歌音感ゲーム「はなワザ」
  • ケータイWatch: 楽曲検索技術で「鼻歌のうまさ」を判定する携帯サイト
  • ASCII.jp: ウタゴエ、鼻歌を採点する音感ゲーム "はなワザ" を公開
  • 読売: あなたの音感は何点?--ケータイ鼻歌音感ゲーム「はなワザ」
  • Venture Now: ウタゴエ、携帯電話向けに鼻歌音感ゲーム「はなワザ」の提供開始
  • mixiニュース: 楽曲検索技術で「鼻歌のうまさ」を判定する携帯サイト
  • @Press: ウタゴエ、世界初携帯電話向け鼻歌音感ゲーム 『はなワザ』(hanawaza.jp)の提供開始 ~元祖鼻歌検索技術による、「ハナウタ エンタテインメント」の提供~

個人的にはITmediaに(かなり偶然的に)自分の名前が載ったことが嬉しかったですねぇ。ついにITmediaデビューですよ。

で、せっかくなんで技術的な話も少し。

もごもごガジェットを作りかけた

もごもご

もごもごがAPIを今日から公開開始しました。で、Twitterの(オレオレ)ひとことガジェットがそこそこ人気だったので、もごもごも作ろうと思ったのです。まずはおなじみのもごロボを切り出して、それっぽい吹き出し画像を作って、ここに最新のもごもごを流し込もう。。。!と思ったのですが、実はこのもごもごAPI、少しTwitterと仕様が違うようで。

FedoraにRed5をインストール

某プロジェクトのテストサーバ環境が他のプロジェクトと混在して、いろんなライブラリが入り乱れ始めて気持ち悪くなってきたので、自分のローカルマシン(WindowsXP)のVM Player上にFedoraをセットアップし、その上でテスト環境を構築しました。入れたもの、セットしたものはこんな感じ。

  • httpd
  • mysql(-server)
  • php
  • samba
  • Java
  • ant
  • Red5

その上でRed5のインストール方法をメモっておきます。最近Web上でもこれをとりあげている人が増えつつあるのですが、やはりまだまだ日本語の情報は少ないので、つまらない情報でも無いよりはあったほうがいいでしょうし。以下、Fedora5上でのインストール方法のメモ。

lab.katsuma.tv

lab.katsuma.tv

blog.katsuma.tv/workspace に置いていたものは全部lab.katsuma.tvに移しました。はてブされてることも無かったので、誰も困ることは無いかと思いますが、念のため。

しかし、今回、久々に生のHTMLを一杯いじったのですが、テンプレートシステムが無いと不安で仕方ないですね。。もう、1度あの味を味わうと生でゴリゴリ書く気が進まない。Smartyをここにも入れようかなぁ。

Apache上でPHPが環境変数を認識できない

ここ数日、PHPの開発でかなりハマってたことがありました。ハマり内容はこんな感じ。

  1. ある共有ライブラリhoge.soをphp.iniのextension_dirに設置
  2. php.iniにextension=hoge.soを指定
  3. 環境変数LD_LIBRARY_PATHにhoge.soのフルパスを指定
  4. ターミナルからhoge.soを必要とするスクリプトfoo.phpを実行(php foo.php)すると、正常に動作
  5. でも、Webブラウザからのアクセスによる実行だと、hoge.soが読み込まれず、エラーが発生

要するに、Apacheの実行ユーザとして、環境変数LD_LIBRARY_PATHが読み込めていないor認識できていない、という問題です。これApacheの実行ユーザを「apache」以外の別ユーザ、たとえばkatsumaにした上で、katsumaユーザでターミナルから実行しても正常動作で、あくまでもブラウザから実行するとNG、という現象だったので、もう打つ手無し、、でした。しかも、google検索してもなかなかそれっぽい記事が出てこなかったので、あきらめかけていた。。のですが、そんなときCTOの助言もあり、何とか回避することができました。

SSL証明書発行会社比較

SSL証明書について調査してみました。今更ながら初めて知ることも結構あったり。EV SSLとか正直知らなかったよ。久方ぶりの調査内容は、せっかくなのでまとめなおしてみたいと思います。全部Webをクロールすれば分かることなのですが、なかなかこういう情報ってまとまってないものですし。 以下、個人的なメモ含の備忘録です。

(*) 主観的な情報はほぼ排除してWebから分かる客観的な事実のみをまとめています。「で、結局どうよ?」な話はまた別で。。

エディタのフォントをメイリオにしてみた

editor.jpg

このBlogのフォントをメイリオを指定したと同時に、エディタのフォントもメイリオにしてみました。思ったより見やすくていい感じかもー。

デブサミ2007に行ってきました

1週間も経っちゃったのですが、先週の水曜日にデブサミ2007に参加してきました。1日だけの参加でしたら、非常に有意義な1日でした。

簡単ではありますが、参加したセッションについて振り返ってみたいと思います。

文章からキーワードを抜き出すAPI: KOSHIAN

なかなか面白そうなWebサービスを見つけました。

[ 文章からキーワードを抜き出すAPI: KOSHIAN ]
http://blog.zuzara.com/2006/12/10/171/

面白いなぁと思ったのは前処理に形態素解析器を利用していないそうな。
僕はこの辺りの専門家でもないですが、ChaSenやMeCabが有名な形態素解析ツール、というくらいは心得ていました。が、このサービスは複数の情報源の組み合わせ、中でもWikipediaを多く利用しているることが、いわゆるマッシュアップな感じで面白みを感じます。

で、早速使ってみました。こんな文章をinput。

さて、僕は今日も今日とてパンをむしゃむしゃ食べながら開発をしていたわけだが、夜になってからは別部屋でミーティングをしていたわけだな。雑談ベースでわいわいやりつつも、なかなか面白いアイディアがまとまったわけなのでしたとさ。

結果のXMLはこんな感じ。

Google Gadgets作りました

このBlogのサイドバーにも表示されていますが、昨日ここでも書いたLive4用のGoogle Gadgetsを作ってみました。

Live4 by Looc.jp
地味にBlogに貼るときの説明ページを見つけるのになかなか苦労しました・・・
以下、リンクです。

Google Developer Seminor

半蔵門で開かれたGoogle Developer Seminorに行ってきました。
内容はGoogle Maps, Google Gadgets, Google Desktop Gadgetの各APIの使い方。Google Maps APIは一度使ったことがあったものの、そのGadget系のAPIは全く触ったことがなかったので、仕事の小ネタ集めのためにも参加。

以下、簡単なメモです。


Googleの野望がアツすぎる

06121101.jpg

これは必見!Google帝国の壮大なマスタープラン!より。

Googleの今後xx年間の壮大な計画がMaster Planとして本社内に巨大なホワイトボードに掲げられているらしいです。
ザっと読む限りこれは相当アツい。

以下、気になったキーワードを抜粋。

Index of all entries

Home > develop Archive

Search
Feeds

Return to page top