Web Music ハッカソン #2 を開催しました

2014 年 1 月 18 日（土）、Web Music Developers JP と Google の共催で Web Music ハッカソン #2 を開催しました。

g200kg さんがデザインした Web MIDI API のゆるキャラ「みでゃっぴー」

近年のウェブ技術の発展の中で生まれたブラウザ上で利用できる各種 API:

• Web Audio API:オーディオをシンセサイズできる API
• Web MIDI API: MIDI を扱うことができる API
• WebRTC: P2P でオーディオ、ビデオ、データをやりとりできる API
• Web Speech API: 音声認識できる API

などを使って、丸一日で何か作り上げよう、という趣旨です。

前回は初回にも関わらず、素晴らしい作品がたくさん生まれました。その時の様子はこちらのブログポストからご覧頂くことができます。
ウェブはどこまで楽器と融合できるか？ 〜 Web Music ハッカソンを開催しました

今回も AMEI（一般社団法人 音楽電子事業協会）の協力で ヤマハ、コルグ、ローランド、クリムゾンテクノロジー 各社から楽器を持ち寄って頂き、NTT コミュニケーションズ からも WebRTC の環境を用意して頂きました。

オープニングで披露された ローランドの渡邊さんのデモがこの分野のポテンシャルをよく表しています。ぜひご覧ください。

蓋を開けてみると、参加者数は前回を超える 30+ 名に加え、各メーカーからの見学者や取材（月刊 I/O）の方も多数集まり、会場である Google オフィス Hanabi は熱気に包まれました。

デモ

お昼前から始まったハッカソンは午後 4 時半で開発を終え、その後デモタイムに移りました。今回も発表されただけで 20 を超える素晴らしい作品が生まれました。デモの様子は動画で配信しましたので、他の写真なども含めこちらからアーカイブをご覧頂くことができます。

とはいえこの動画、全部で約 2 時間 45 分あります。さすがに長過ぎますし、すべての作品を紹介するわけにはいかないので、個人的に印象に残った作品をいくつか (これでもかなり絞ってます) ピックアップして紹介していきます。(画像は動画のデモ開始位置にリンクしています)

@mohayonao さんの作られた CoffeeCollider のソースコードをリアルタイム演奏する楽器。作品はこちら by CCKB 制作委員会チーム

ヤマハの新音源 NSX1 を載せた eVY1 を使った初音ミクボイスの作品。オチが秀逸。作品はこちら (要 eVY1) by ひとりになっちゃったチーム

Twitter のアカウントで認証して 2 秒間の挨拶が残せるというサービス My-hi.net 。マウスオーバーで他の人の声を聞くことができます。 by aklaswad

缶を MIDI 楽器にしてしまった作品。 by こだま

今回のハッカソンでお披露目された g200kg こと gaito さんがデザインされた Web MIDI API のマスコットキャラクター「みでゃっぴー」の 3D モデルを WebGL 上で MIDI コントローラーで制御するというデモ。 by g200kg

今回一番派手だったデモがこちら。Leap Motion で制御するミラーボールや MIDI コントローラーと音楽に合わせて変化するビジュアライザを組み合わせた作品。 by 光の魔術師集団Xチーム

準優勝の作品。Leap Motion を使い、ジェスチャーで鳴らす楽器や音の大きさを調整するアプリです。アウトプットは Ableton Push のパッドを光らせることでビジュアライズ。動きが結構サマになってます。 by mtomasz

優勝作品はこちら。Google Spreadsheet をシーケンサーにして音楽を鳴らしてしまう Chrome Extension。表計算ソフトの参照機能を使うことでコードを表現できるところなどに注目。 by hirono

まとめ

今回実は半数くらいの方が二度目の参加でした。それだけ前回が楽しかったのだと思います。僕は残念ながら懇親会に参加できなかったのですが、おそらく今回もみなさん存分に楽しまれたのだと思います。
このハッカソンは今後も継続的にやって、徐々により音楽的な作品が作れる環境を整えられたらいいな、なんて話をしています。

次回以降の開催については、メーリングリスト か Google+ のコミュニティ にご参加頂ければ、前回・今回のイベントを中心となって企画してくれた Ryoya Kawai さんが、この分野の最新情報も含めて提供してくれることと思います。

みなさんの参加をお待ちしています。

ウェブはどこまで楽器と融合できるか？ 〜 Web Music ハッカソンを開催しました

去る 2013 年 10 月 19 日、Web Music ハッカソンというイベントを Google Japan オフィスで開催しました。これは @ryoyakawai ことヤマハの河合さん (ややこしい) を中心とした Web Music Developers JP という開発者コミュニティ主催のイベントで、初の試みです。

ブラウザは近年目覚ましい発展を遂げています。HTML5 というバズワードが非常に分かりやすくはありますが、現在は Chrome、Safari、Firefox といったブラウザで、オーディオを波形レベルから弄れる Web Audio API が利用可能になっています。

こちらは藍圭介さん (@aike1000) が作られたデモですが、各ツマミは実際に動かすことができ、本格的なアナログシンセサイザーとして音を鳴らすことができます。公開されてから 2 年以上経過していますが、まだ新鮮さは衰えません。

確かにすごい！・・・とはいえ、これだけだと何か足りないと思いませんか？
そう、どうせシンセ弄るなら、マウスやトラックパッドじゃなくて、フィジカルコントローラーだろうと。みんな考えることは同じだと思います。

そこで登場したのが、Web MIDI API というブラウザから直接 MIDI メッセージを送受信することができる API です。まだ標準化されていませんが、既に Chrome では flag 付きで実装されており、利用することができます。つまり、外部 MIDI 機器から Chrome 上のバーチャルシンセサイザーを実際に鳴らすことができるようになったのです。

ハッカソン開催

ここまで来れば、あとは盛り上げるだけ。まずはハッカソンだろうということで、今回は日本の MIDI 業界団体である AMEI に協力を仰ぎ、ヤマハ、KORG、クリムゾンテクノロジーの各社から楽器やスピーカーなどをご提供頂き、30名程度の参加者のみなさんと共に集まりました。

イベントの様子は主催の河合さんのブログに譲るとして、このイベントがいかに熱いものだったか、写真と動画を交えて紹介していきます。

このイベントのために用意された楽器の数々

製品化叶わず開発から 25 年の時を経て日の目を見た Dontata くん。MIDI メッセージに応じてドラムを叩きます。

マイオシロスコープを持ってきた方も。

勢い余って持ち込まれた半田ゴテ。

デモ

特に心に残った作品に絞っていくつか紹介。(画像をクリックでビデオの開始位置から見ることができます)

優勝はテノリオンと VJ を融合した作品。

こちらはちょっと意表をついた作品。マウスオーバーで効果音が鳴るブックマークレットです。

Dontata くんの勇姿。

他にもエレキ木魚ありーのテルミンありーの盛り沢山です。2 時間とちょっと長いですが、時間のあるときに飛ばし飛ばし見てみて下さい。

最後にチューターお二方のすごい作品。

@komasshu 先生はカメラに向かって口を開けるとスネアを鳴らしてくれます。

大御所 g200kg さんはホワイトボードにマグネットを置いて、自由にリズムシーケンスが組めるという作品。

今回のイベントは初回ということで、課題がたくさん残るだろうと予想していたのですが、正直楽し過ぎてびっくりしました。来年早々にも第二回を開催したいなんて話をしていますので、興味持たれた方はぜひ Web Music Developers JP に参加して下さい。忘年会とかもやるかも。

イベントの模様は Google+ イベントページにまとまっています。見れないビデオなどあったらこちらでどうぞ。

Canvas に描いた画像を png などの形式の Blob に変換する方法

canvas の DOM エレメント (コンテキストではない) から toBlob() を使う、というのが一番簡潔な回答です。が、これは Firefox には実装されているのですが、残念ながら Chrome にはまだ実装されていません。そこで下記の方法を使って png や jpeg など、任意の画像形式で Blob を作ることができます。

/***
  canvas に絵を書くコード
***/
var type = 'image/jpeg';
// canvas から DataURL で画像を出力
var dataurl = canvas.toDataURL(type);
// DataURL のデータ部分を抜き出し、Base64からバイナリに変換
var bin = atob(dataurl.split(',')[1]);
// 空の Uint8Array ビューを作る
var buffer = new Uint8Array(bin.length);
// Uint8Array ビューに 1 バイトずつ値を埋める
for (var i = 0; i < bin.length; i++) {
  buffer[i] = bin.charCodeAt(i);
}
// Uint8Array ビューのバッファーを抜き出し、それを元に Blob を作る
var blob = new Blob([buffer.buffer], {type: type});

これで jpeg 形式の Blob が完成です。type の部分を 'image/png' などに変更することで、当然ながら別の形式の画像を得ることもできます。この Blob を使えば例えば

var url = window.URL.createObjectURL(blob);

としてその画像を参照する URL を取得することができます。破棄する前に window.URL.revokeObjectURL(url) するのも忘れないで下さい。これをダウンロードするには、(破棄する前に) その URL を a タグに渡してあげます。

<a href="[blob url]" download="image.png">Download</a>

[blob url] の部分が先程作った Blob の URL、image.png の部分がダウンロードしたもののファイル名になります。Blob が必要なければ canvas.toDataURL('image/png') を直接 href 属性に渡してしまうのもアリです。

超カンタン！HTML5 で GIF アニメを作る方法

知っている人は知っている方法だと思いますが、実際にやってみたのでメモ。

※ デモの画像はこちらからお借りしました。特にライセンスが記述されていなかったのですが、問題があれば差し替えます。

ライブラリは jsgif というのを使わせて頂きました。

手順はライブラリを読み込み、画像をひとコマ分ずつcanvasにロード、ライブラリに追加。終わったらバイナリからgifファイルを生成、という感じ。

もう少し詳しい解説は以下。

1. LZWEncoder.js NeuQuant.js GIFEncoder.js を読み込む
2. 適切なサイズの canvas を用意
3. GIFEncoder からエンコーダを作る
   var encoder = new GIFEncoder();
4. アニメーションの時間間隔などを encoder に設定
   encoder.setRepeat(0);
encoder.setDelay(100);
encoder.setSize(120, 120);
5. 一コマずつ書き始める
   encoder.start();
   1. canvas に絵を書く
      canvas.drawImage(img);
   2. encoder に canvas のコンテキストを追加することで一コマを追加
      encoder.addFrame(ctx);
6. 書き込み終了
   encoder.finish()
7. encoder からバイナリを吐き出して、Blobを作る
   var bin = new Uint8Array(encoder.stream().bin);
var blob = new Blob([bin.buffer], {type: ‘image/gif’});
8. Blob から URL を作って表示 (revoke を忘れずに)
   var url = URL.createObjectURL(blob);
var image = new Image();
image.src = url;
image.onload = function() {
 URL.revokeObjectURL(url);
};

デモはこの辺に。

※ このデモは Firefox 推奨です。Chrome では img.onload で実際に画像が読み込まれない場合があるというバグのせいで、アニメーションが一部抜けたりしてしまいます。画像を読み込むのにAjaxを使うなどの回避方法はあるのですが、このデモでは可読性を優先して画像をsrcから読み込む方法を採りました。ただ、僕のコードにバグがある可能性もあるので、その場合はこっそり教えて下さい :)
こっそりじゃないけど Google+ で教えてもらいました。完全に僕の勘違いでした。お恥ずかしい・・・。

ソースコードはこちら。

参考：

• JavaScript

• pure JavaScriptでアニメーションGIFを作る

Chrome でもう大量のタブに悩まされない Project Tab Manager 2.0 リリース

昨年夏に公開した Project Tab Manager という Chrome Extension のバージョン 2.0 をリリースしました。2.0 での変更点は下記の通り：

• 新しい UI。より直感的で使いやすくなりました。
• タブの状態を追跡するようになりました。プロジェクトとして保存さえしていれば、気軽にウィンドウを閉じて構いません。いつでも閉じた時の状態に復元可能です。
• Chrome 再起動時にウィンドウとプロジェクトが自動的に関連付けられるようになりました。以前はマニュアルで関連付けなければなりませんでした。
• キーボードナビゲーションが可能になりました。
• オプションがクラウドに保存されるようになりました。自宅や会社で共通の設定が利用できます (要 Chrome サインイン)。
• サマリー機能が拡張されました。自分がどのプロジェクトにどれくらい時間を費やしたのか、2 ヶ月まで遡ることができます。

Project Tab Manager 知らなかった！という人がほとんどだと思うので、ゼロから書いてみます。

Project Tab Manager が解決する問題

元々、仕事上コンテキストスイッチ (プロジェクトごとに頭を切り替える) がかなり頻繁に必要なため、それを少しでも楽になるようにと作ったのが Project Tab Manager でした。予めタブをセットにして保存しておき、手軽にひとつのウィンドウとして呼び出せる、というのが Project Tab Manager の基本コンセプトです。

こういう人にぜひ使って欲しいです

• Chrome のタブが常に 100 個近く開いている
• そのせいで Chrome だけでかなりメモリを消費している
• 仕事中に Twitter や Facebook (もちろん Google+ も！) を見ちゃって気が散る

Project Tab Manager (以下 PTM) を使えば、常に必要最低限なタブのみを開いておけるので、今やっている仕事への集中力が高まり、Chrome の消費メモリが減少し、彼女ができます。

興味を持った方は、まずは Chrome Web Store からインストールしてください。

Getting Started

以前のバージョンではせっかくインストールしてもらったのに使い方がわからないという方が結構いました。ので 2.0 からヘルプを用意したのですが、日本語ヘルプを書くのがめんどいのでここに書いちゃいます。

PTM をインストールしたらまず下記を行なってそのパワーを実感して下さい。

1. 新しいウィンドウを開く
2. 何かウェブページを開く
3. PTM のアイコンをクリック
4. プロジェクト名を入力して保存する
5. 以上

これでこのウィンドウにプロジェクト名が付きました。以後このウィンドウで開くあらゆるタブは、いつでも状態を復元することができます。以下を試してみて下さい。

1. 先ほど開いたウィンドウにいくつか新しいタブを開き、ウェブページを読み込む
2. ウィンドウごと閉じる (タブをひとつひとつ閉じるのではなく、ウィンドウ自体を閉じて下さい)
3. PTM のアイコンをクリックして今閉じたウィンドウのプロジェクトを開く

元のタブの状態が復元されましたか？これが Project Tab Manager のパワーです！

その他の使い方

ブックマークを保存する

• PTM では、プロジェクトを保存するとブックマークが作られます。また、プロジェクト保存時に含まれなかったタブも、以後は復元可能になります。必要に応じてプロジェクト内のタブ名横に表示されるスターアイコン (Chrome のブックマークと同じ) をクリックして保存しておけば、後から再度開くことが可能です。頻繁に使うページはブックマークしておきましょう。
• 先ほどのブックマークとは、本当に Chrome のブックマークのことです。Bookmark Manager を開いて “Project Tab Manager” というフォルダ (デフォルト) を探してみて下さい。保存したプロジェクトがフォルダとして、タブがブックマークとして保存されていることがわかると思います。
• これにより、Chrome for iOS や Chrome for Android からでも必要なブックマークにアクセスできるのが特徴です。

プロジェクトを編集する

• プロジェクトの並べ替え、名前変更などは Bookmark Manager で行なって下さい。PTM 自体に編集機能はありません。

プロジェクトを削除する

• プロジェクトの削除は PTM のポップアップから行えます。プロジェクト名右のゴミ箱アイコンをクリックするだけです。
• 間違えて消しちゃった！という場合でも大丈夫。”__Archive__” というフォルダに移動されているだけです。Bookmark Manager で戻してあげるだけで復活します。

プロジェクトを関連付ける

• バージョン 2.0 から Chrome を再起動してもウィンドウの関連付けが自動復元されるようにはなりましたが、場合によっては外れてしまうこともあるでしょう。そんな時はプロジェクト名横のピンアイコンをクリックして関連付けて下さい。

Lazy Load とは

• 複数のタブをまとめて開こうとした時に長時間かかること、ありますよね？PTM の特徴のひとつとして Lazy Load という機能があります。これにより、プロジェクトで大量のタブを開こうとした時でも、アクティブなもの以外は読み込まなくなり、時間が短縮され、リソースをほとんど食わなくなり、彼女ができます。
• Lazy Load されたタブのタイトルには “*” がプレフィックスされます。
• オプションで Lazy Load を無効にすることもできます。

オプション

• オプションでは下記を設定することができます
  • プロジェクトを保存するブックマークの場所
  • プロジェクトを保存するブックマークの名前
  • Lazy Load の有効・無効

Summary 機能

• PTM ポップアップの時計アイコンをクリックすることで、どのプロジェクトにどれくらいの時間を費やしたか、まとめを見ることができます。
• この記録は 2 ヶ月保存されます。「今月どのプロジェクトに一番時間使ったのかな？」「あー俺 Twitter ばっか見てるわ！」なんてことに便利かも。

キーボードナビゲーション

• 慣れてくると、PTM ポップアップを開いた後、キーボードで操作したいという人は少なくないと思います。
• 検索、その後 “tab” で絞りこまれたプロジェクトを選び、”return” でプロジェクトを開くことができます。
• PTM ポップアップを開くこと自体も、ショートカットすることができます (Chrome の標準機能) “chrome://extensions” を開き、一番下の “Keyboard shortcuts” からお好みの設定を行なって下さい。僕は “Ctrl+p” にしてます。

最後に

バグを発見した場合、機能要望がある場合はこちらからリクエストしてください。開発者の方は直接 github から contribute して頂けると嬉しいです。

Google の Developer Advocate とはどんな仕事なのか？

僕の仕事は Google の Chrome Developer Advocate です。
Google Japan では先週 (2013 年 4 月) からこの Chrome の Developer Advocate を募集開始しました。他にもGoogle+、YouTube、Android など同種の担当者も募集しているのですが、よく聞かれるし、リクエストもありましたので、この機会に Developer Advocate がどんな仕事をしているのか、ご説明したいと思います。

Developer Relations とは

上記一連のお仕事ですが、すべて Google 内の Developer Relations チーム (以下 DevRel) という部署に属します。おそらく Google の中でも、開発者の皆さんが一番接触する機会の多いチームではないかと思います。DevRel はさらに Chrome や Android といった、プロダクトごとのチームに分かれています。

業務内容は名前から想像できる通り、Google と外部開発者との関係を築いていくことを中心としています。職種は Program Manager、Developer Programs Engineer、Developer Advocate、Technical Writer などがありますが、僕が担当しているのは Developer Advocate です。
Advocate という言葉だけで仕事の内容がピンと来る人はほぼいないと思いますが、学校で教わるような単語ではないので当たり前ですね。他社で言うところの Evangelist が一番近い仕事かと思います。それでも分からない方には、「Google のテクノロジーを外部の開発者の方にも使って頂けるよう啓蒙活動する仕事」という説明をすることが多いです。

Developer Advocate という言葉の由来はこんな感じ：
Evangelist という言葉は元々宗教の伝道師に使われる言葉です。しかし Google で Evangelist に類する仕事が作られた際、開発者の方に一方的に伝えていくだけでなく、対話やフィードバックから Google 自身も学び成長していくという意味を込めるため、Advocate という言葉が選ばれました。

以下、具体的な仕事内容に触れて行きますが、本記事は僕が担当している Chrome 周辺について述べているものであり、他のプロダクトについては必ずしも当てはまらない点を予めご了承下さい。今取り組んでいる仕事の一部を怒られないであろう範囲で書いてみます。

啓蒙活動

DevRel の仕事は、「Google のプロダクトをプラットフォームとしたアプリを使ってもらいたい人のお手伝いをする」のがメインです。Chrome に関して言えば、「Chrome をプラットフォームとしたアプリ、つまりウェブサイトやウェブアプリを制作する人を手伝う」言い換えると「Chrome だけでなく HTML5 を含めたウェブ全体、特にフロントエンド周りを盛り上げる」というのがミッションになります。非常にざっくりしてますし、はっきり言われたことはないですが、僕は勝手にそんなイメージを持って仕事しています。

講演

おそらくこれが一番業務として目立つ部分だと思いますが、外部で開催されるイベントで講演を行います。内容は大抵 Chrome の技術を紹介するものか、HTML5 の機能を紹介をするものです (ちなみに最近は HTML5 より Open Web Platform、OWP という言葉を使う機会が多いです)。当然資料も自分で作成するので、事前のインプットがかなり必要ですし、ある程度質問も想定して準備をするため、結構な時間が割かれます。地方で講演する場合は出張も伴います。

ソーシャルメディア

ブログや Google+、Twitter などのソーシャルメディアを使って最新の情報を流します。これは見られている方も多いと思います。

HTML5Rocks

HTML5Rocks の記事を書いたり、サイトのメンテナンスをしたりします。HTML5Rocks 自体がオープンソースですので、Pull Request も受け付けていますし、記事のレビュー、それから日本語の翻訳を頂いた場合のレビューもしたりします。

Google Developers Live

毎月YouTube Liveを使って生放送しているウェブ番組が Google Developers Live (GDL) です。ご覧になったことがある方はご存知だと思いますが、ゲストを呼んで技術セッションをして頂く内容です。スタジオの準備などは手伝ってくれるスタッフがいますが、その他の部分、ゲストの手配や内容の選定、番組の司会進行などはすべて自分でやります。アメリカとイギリスの GDL では、ゲストではなく Advocate が直接セッションをやっていますが、日本では今のところゲストの方にお願いしています。

せっかく作ったコンテンツをどう広げていくか考えるのも、Advocate の仕事です。過去にこんなブログ記事を書いたこともありました。これは見てくれる方々にとっても、コンテンツを作っている我々にとっても嬉しい、良案だったのではないでしょうか。

StackOverflow

フォーラム的な場でのサポートも業務のひとつです。日本語であれば Google Groups を使った質問の回答なども行なっていますが、グローバルでは StackOverflow を公式にサポートの場にしています。Google Code ではなく github にオープンソースのコードを置いてしまうところもそうですが、Google の (というより DevRel の？) 自前のシステムに拘らないところとか、合理的でよいと思いません？

コミュニティ

DevRel は全世界で 200 名程度 (日本では現在 4 名) しかおらず、スケーラビリティが重視されます。そこで、外部コミュニティの一部となってテクノロジーを盛り上げる場面も多々あります。

Google Developers Expert

ご存知の方は多いと思いますが、Microsoft でいうところの MVP のような、優秀な外部の開発者を認定する Google Developers Expert という制度があります。GDE の皆さんとの情報交換も重要なお仕事です。

これは以前 Google API Expert と呼ばれていたもので、元々日本発のプログラムが、昨年から全世界共通のプログラムになりました (Naoki Ishihara と Fumi Yamazaki のおかげです！)。ちなみに僕も入社前は OpenSocial の API Expert でした。 

コミュニティとのお付き合い

日本の DevRel で Chrome 担当は僕だけですので、当然やれることは限られてきます。そこで、上記 GDE を含め、志を同じくする開発者コミュニティと協力し合い、時には一部となってお手伝いをするのも重要な仕事です。コミュニティを盛り上げるために何ができるか考えるのは、かなり楽しいです。

イベント運営

コミュニティのお手伝いの一環として、Google の会場や設備を提供し、人員としてお手伝いするのも重要なお仕事です。勉強会などのイベントを開催する、プロダクトに関わるエンジニアに講演してもらう、など。2011 年には html5j とコラボで Chrome+HTML5 Conference を開催しました。Chrome Tech Talk Night は既に 5 回を数えています。6 月には Test The Web Forward というイベントの開催も予定しています。

パートナー、インプット、Hacking、etc

実際はもっと雑多な仕事がありますが、上記に分類されない仕事としては主に以下のようなものがあります。

パートナーとのお付き合い

オープンな一般開発者向けの仕事が占める割合はかなり大きいですが、表からは見えないパートナー向きの仕事もあります。何かプロダクトを作ってもらうための交渉をすることもありますし、コンフィデンシャルな情報を含む技術的問題を受けて、Chrome 自体の機能を改善したりといったこともあります。技術的にパートナーとの間を取り持つのも、Developer Advocate の重要な役割です。

インプット

ここまであまり技術的な話がなかったですが、もちろん最先端の技術力も求められる仕事です。インプットなしにアウトプットなどできる訳もありませんので、常に最新情報にキャッチアップしていることが求められます。

Hacking

理屈だけインプットしていても仕方ありませんので、実際の開発も行います。大きなものを作る機会はそれほど多くありませんが、技術の啓蒙に直接繋がるデモや、社内向けのツールを作る場合もあります。

今まで作ったものとしては、東京の Chrome エンジニアチームが担当している範囲のものをテーマにして、WebSocket、Forms、最近は FileSystem 関連のデモも。後は趣味と実益を兼ねて Chrome Extension や Chrome App を作ったり。コードは github で公開しています。
基本的にプロダクションレベルのコードを自分で書くことはないですが、同僚の中にはパッチを送り続けて WebKit (今は Blink ですが) の committer になっちゃった人もいます。

Chrome Experiments

また、過去に話題になった Chrome Experiments の中には日本発のものもあることをご存知でしょうか？例えば先日発表された World Wide Maze もそう。ああいったプロジェクトにテクニカルなサポートを行うのも、Developer Advocate が担当します。

エンジニアとのやりとり

Google 東京オフィスの Chrome エンジニアチームはそれなりの規模です。先述のように、 WebSocket や FileSystem、Forms、WebComponents周りなど、主に OWP 機能を実装しています。W3C や IETF のサイトに載る標準仕様を自分の手で書いている人も少なくありません。そんなエンジニアたちと外部開発者の橋渡しをするのも、僕の仕事です。GDL や講演を通じてエンジニア自ら啓蒙してもらうこともあれば、外部開発者のフィードバックを届けることもあります。

仕事の楽しさ

日常業務は上記のような感じです。ただ、これはあくまで僕の例であって、Developer Advocate 全員に当てはまるものではありません。同じ Chrome DevRel のメンバーは、本社のある Mountain View を中心に、日本を含めて世界 7 カ国に散らばっていますが、それぞれに得意分野を持ち、異なる仕事をしています。

Google では、仕事は与えられるものではなく、自分で作り出していくものです。そのため、人によってやってることが全く違うのは、ごく自然なことなのです。いいと思ったことは何でもやれるし、それでもちゃんと評価もしてもらえる。

僕が過去にやった思い出深い仕事をふたつ挙げます。
ひとつは、2011 年の GDD での Developer Link です。2 つのセッションやキーノートなどに加え、企画から制作、パートナーとの交渉まで含め、イベント当日までにサービスを完成させるべくプロジェクトをリードしました。コードも一部書いてます。

もうひとつは現在進行形ですが、Web Music Developers Japan の活動です(仕事というより趣味ですが)。元々音楽好きでブラウザでシンセサイザーが作れる Web Audio API に大興奮していた身としては、それを通じて開発者はもちろん、過去であれば無関係だった業界の有名人と関われたりするのは、役得だなあと思います。Web MIDI API が登場してくれば、今後ますます面白いことをしかけていけるんじゃないかとワクワクしています。

難しい所

周囲がハイレベルで、正直ついていくのに必死です。技術的にも、仕事のやり方的にも。
加えて、上記のような仕事が常に同時進行している感じなので、時間配分や集中力の管理も難しい部分です。

それに拍車をかけるのが、Regional (本社から離れている) であることです。Chrome DevRel で日本担当は僕だけですので、チームメンバーとのコミュニケーションは基本メールか Hangout。Hangout は便利ですが、テクノロジーで時差は超えられません (今だと日本の朝 9 時が本社の 17 時、日本の 17 時が London の朝 9 時)。メールは文字情報だけなので、相手の表情は見えないですし、空気が伝わって来ません。

そこで出張ということになる訳ですが、今度は対面コミュニケーションに苦労します。言語そのものというよりも、自分の性格だったり、カルチャー的な部分の方が大きいかもしれませんが、話が長くなりそうなので、この辺はまた別の機会に。

環境

これまで何社か渡り歩いてきましたが、働きやすさという意味では群を抜いて快適な会社です。無料のランチ (実は朝食と夕食もある) が取り沙汰されることが多いですが、産休は父親 (Paternity Leave)、母親 (Maternity Leave) ともに取ることができますし、休暇も柔軟で、まとめて 1 ヶ月休んじゃう人も少なくありません。チームでのコミュニケーションを充実させるためのアクティビティも頻繁にありますし、社内ではしょっちゅう Tech Talk や部活動が行われていて、とてもよい雰囲気です。こればっかりは、入ってみないとわからないと思います。

求めている人材

Chrome DevRel で募集している人材は 先日も書いたように、「英語、日本語が堪能で交渉力、技術力、講演、イベント開催に自信のある方」です。この言葉の意味が今回の記事で少しはお分かり頂けたのであれば、書いた甲斐があったというもの。

もちろん、ここでの話はあくまで「僕の場合」であり、新しく担当する方に同じような仕事をして欲しいと思っていませんし、むしろその人なりのやり方を生み出して欲しい、生み出すべきです。

自分で仕事を作り、こなしていける人。コミュニケーション能力が高く、色んなことをグイグイと、楽しみながら前に進められる人に来てもらえたら、嬉しいな。

その他の職種について

今回は主に僕と一緒に仕事してくれる方をターゲットに、仕事内容について説明しましたが、最後に DevRel で募集しているものを、他の職種も含めてご紹介しておきます。

Developer Advocate - Chrome

こちらが今回紹介した僕と同じ仕事です。

Developer Advocate - Google+

僕と同じ Developer Advocate で Google+ を担当します。

Developer Advocate - YouTube

こちらも Developer Advocate で YouTube を担当します。

Developer Programs Engineer - Android

Developer Programs Engineer は Developer Advocate よりもテクニカル寄りな仕事です。パートナーやコミュニティとのコミュニケーションよりも、コードを書いたりオンラインサポートをしたりするのが中心になります。ちなみに昨年末米国に転籍となった Takashi Steveland Matsuo は現在 AppEngine の DPE です。

Program Manager

こちらは米国に転籍した Fumi Yamazaki が以前担当していた仕事です。Program Manager は特定のプロダクトを持ちません。日本の DevRel の代表者としてチームをまとめ、予算、コミュニティ、イベントなどの管理を行います。高い交渉能力と英語力、リーダーシップが必要とされます。
というわけで、皆さんからの応募をお待ちしております :)

関連記事

• Google の Developer Relations について
• 渡米することになりました

プロジェクトごとにタブを管理できるChrome Extension "Project Tab Manager" を公開しました

かなり前から自分で欲しいと思っていた Chrome Extension を、ようやく Chrome Web Store で公開することができましたのでご紹介。

なぜ？

Chrome のブックマークの思想はとてもシンプルです。一度星を付けたら(ブックマークしたら)、基本的には Omnibox (URLバーのところ) から数文字打つだけで候補に出てくる、という極限までスリム化した使い方を想定しています。そのため、ブックマークはカテゴリに分けて整理して使いたい、という方にとっては痒いところに手が届かない部分もあるかもしれません。僕自身もそう感じるひとりです。

ブックマークの整理というと、僕も以前であればカテゴリーで分ける使い方がメインだったのですが、それだと探すのが面倒だし、結局検索してしまったり、直接URLを覚えて入力してしまうことが多々ありました。そこで最近は、カテゴリごとではなくプロジェクトごとにフォルダを作って、必要なブックマークを集めるという使い方をし始めていました。こうしておくことで、必要な時に必要なページをまとめて開く、といった使い方ができるからです。仕事柄複数のプロジェクトを同時並行で進めることが多いので、頭を整理しやすくなりますし、開いているタブの数を減らす効果も得られます。
ただ、このやり方だとプロジェクトに後からブックマークを追加しにくいとか、プロジェクトの一部だけど最初から開かないようにできない、とか、不便な点も少なからず残ります。そこで作ったのがこの Project Tab Manager 。完全に上記の使い方に最適化された Chrome Extension です。

基本的な使い方

インストールして頂くと、Omnibox の右側に Extension のボタン (フォルダの形をしたアイコン) が表示されます。これをクリックすると、何もプロジェクトが登録されていない状態の Project Tab Manager が開きます。

プロジェクトを登録するには、「新しいプロジェクト」に名前を入力して保存するだけ。今開いているウィンドウのタブがまとめてプロジェクトに保存されます。これを繰り返すことで、ウィンドウごとにプロジェクトが管理できるようになります。

次にプロジェクトを開きたい時は、プロジェクト名をクリックすれば、新しいウィンドウが開き、すべての必要なタブがまとめて開きます。ポイントのひとつは、この時にアクティブなタブだけが実際にウィンドウをロードするところ。別のタブを選択すると、そこで初めてページがロードされます (レイジーロード機能)。こうすることで、たくさんのタブを開いても、実際に使い始めるまでの時間は短縮できます。もちろんこの機能は設定でオフにできます。

Project Tab Manager からプロジェクトを開くと、プロジェクトのブックマークと共に、現在開いているまだブックマークしていないタブのページもグレーで表示されます。マウスオーバーした時に右側に表示される + をクリックすれば、そのタブのURLをプロジェクトに追加できます。
既にあるブックマークにマウスオーバーした場合は、四角形と✕が表示されます。四角形はアクティブ・パッシブを切り替えるもので、パッシブ (薄い青) にしておくと、プロジェクトの一部にはなりますが、プロジェクトウィンドウを開いた場合にタブとして追加されません。なので、必要な時だけ開く扱いにできます。✕をクリックすると、ブックマークは削除されます。

Project Tab Manager の特徴のひとつは、これらのブックマークがネイティブ機能のブックマークとして保存される点です。設定を見て頂くとわかりますが、デフォルトでは「その他のブックマーク」に「Project Tab Manager」というフォルダを作って、その下にプロジェクトごとのブックマークが作られることになります。こうすることで、Chrome Sync を利用してさえいれば、Chrome for Android や Chrome for iOS からでもプロジェクトのブックマークを利用可能です。外部のサーバーに保存されるといったことはありません。
また、Project Tab Manager 自体の編集機能は最低限に留め、表示順を変更したり、削除したりといったことはネイティブのブックマークマネージャーから行うことができます。

Project Tab Manager のもうひとつの特徴は、各プロジェクトにどれだけの時間を費やしたのかをあとで振り返ることができる点です。ウィンドウの右上に表示される時計アイコンをクリックすると統計画面が開き、どの時間帯にどのプロジェクトウィンドウを使っていたのか、どのプロジェクトに何割くらいの時間を割いたのかを確認することができます。

各プロジェクト名にマウスオーバーした場合は、ピンアイコンとゴミ箱アイコンが表示されます。ピンアイコンはウィンドウにプロジェクトを紐付けます。こうすることで、このウィンドウはこのプロジェクト用ですよ、ということを Project Tab Manager に教えることができます (ここはできれば自動化したい部分)。これは統計機能で必要になります。
ゴミ箱アイコンは、プロジェクトを削除するのではなく、アーカイブします。ブックマークの中に __Archives__ というフォルダがあるのですが、そこに移動されるだけですので、必要な時に元に戻すこともできます。

技術的な部分

この Extension は元々素の JavaScript で作ったものだったのですが、HTML5とか勉強会での講演のために、AngularJS ベースに変更しました。おかげでコードは格段に整理できましたし、AngularJS に興味がある方には面白いものだと思います。ソースコードはこちらで公開しています。
AngularJS とは Google のエンジニアも関わっている JavaScript のフレームワークで、他のフレームワークとはちょっと違ったアプローチが体験できます。詳しくはまた別の機会にブログを書きたいと思っていますが、興味のある方は先述の HTML5とか勉強会で僕がやったライブコーディング込みの講演のビデオが参考になると思います。15分程度ですのでぜひご覧頂ければと思います。

フィードバック求む！

リリース直前に手を入れた部分でいくつかバグが出ているようなのですが、まだ整理できていない状態です。バグを見つけた方はぜひ github に issue として登録して下さい。また、機能面でもフィードバックを頂けると嬉しいです。

Project Tab Manager で皆さんの生産性が少しでも上がればと思います。

Special Thanks to Shinsuke Okamoto for icon designs.