2018年も最終日。環境も、自分も動いた、動かした1年。お疲れ様でした!!
転職、というのが一番大きかったけど、ブログを移行したり、FitbitのClock Faceを公開したり、ウェブサイトを最初から作ったり、Cookpadでレシピを公開し始めたり、大きいことから小さなことまでやってたんだな〜、と振り返り中。悩みは多い1年だったけど、よい1年だったかな。体重も維持できてるし。
来年は今年よりもパフォーマンスが出るように更に精進していこう。

関係ないけど、公開しているClock Faceが300名の方、50カ国で利用してもらえてることが分かった。小さなことだけど、こういうのすごく励みになるね。

本年も多くの方に本当にお世話になりました。ありがとうございました。
2019年もよろしくおねがいします。

よいお年を!

whenever(myself.anything_happen()).then {
  continue
}

2018年4月末くらいに買ったFitbit Versa向けにClockfaceを作って半年経ちました。 インド、英国、オーストラリア、米国のユーザから「サマータイム入ってね〜!」とか、「タイムゾーン追加して!」とかいろいろと要望いただき、 1つ1つ対処していて、そろそろUX的なツッコミも入るようになりました。なんですが、Fitbitはエコシステムとしてまだインストール数とかの情報の開示を してもらえないので、どれくらいの方に使ってもらえているのか把握できず、なんとかしたいな〜、と思っていました。
そこで、単純にAnalyticsを入れてしまいました。

導入

1からコード書く必要あるのかも?と思いきや、検索したらズバリなのがありました。

Fitbit OS上のアプリ向けっぽいのでClockfaceで動くのか?という不安はありましたが、特にハードルなく導入完了してしいました。

  • npm install
  • AnalyticsでTracking IDを取得
  • AppとCompanionでimport
  • トラックしたいところで動作させる

非常に簡単でした。

これで、どれだけ使われているのか分かる、かな?
まだレビューですが、リリースできるようになるのを楽しみにしてようと思います。

fitbit-google-analytics/app.jsdebugをExposeして欲しかったな〜。

var analytics = {
  debug: debug,
  configure: configure,
  send: send
};
export default analytics;

こっちもfitbit-google-analytics/companion.js

var debug = false;

2018年12月21日に「Web Music Developers Meetup 3」を開催しました。
20名ほどの参加者の中から、10分のLTが6つ行われ、LT後には質問、ノウハウ等が活発に飛び交う、 楽しく、そして有意義なMeetupになったように思います。 ご参加くださった皆様、そしてLTの準備、発表をしてくださった皆様、お疲れ様でした!!

LTの内容の紹介

LT-1 : @toyoshim さん

Web Audio/MIDIの標準化について&今後のChromeとWeb Music系のAPIに関して、のお話。

  • W3Cの年次会議であるTPACにて話さた内容に関しては、Web Audio V2では現在のAPIよりも低レイヤのAPIをサポーする方向で進むこと、Web MIDI APIに関してはMozillaがFirefoxに実装を行って2019年1月にはリリースする目標感をもっている、という表明があったとのこと。

  • W3CにAudio Community Groupができました。Audio WGよりももう少しカジュアルなグループなので気になる方はご参加ください。

  • Chromeは外部デバイス接続に対してのPermission(「GPS使っていいですか?」みたいダイアログ)は適切な場面で出せるようにする、という方向で進んでいる

  • Web MIDI API on Chromeに関しては現状はWeb MIDI APIでSystemExclusiveのメッセージを扱う場合にのみ限定してPermissionの許可が必要であるのが、今後はWeb MIDI APIを利用するときにはメッセージに関わらず必ずユーザに許可を求めるように変更されるだろう。その影響もあり(もちろん世の中的な流れもあるが)、Web MIDI APIが使えるプロトコルはHTTPSのみとなる。Chrome内部的には「SystemExclusiveを使う」というフラグは持ち続けることになるとは思う(今後の話なので未確定)。

LT-2 : @gcchaan

Web MIDI APIさわってみた、というタイトルでWeb Socketと使ってリモートでMIDI機器を制御してみたお話。

  • システムを作ってみて、Web Socketでワリとスピードが出てるから演奏にも使えそうなことが判明した

  • ついでに、画面に楽譜に表示された和音を鍵盤から時間内に抑えるゲーム、も作ってみた

Creators’ HubのJSONの形式を使えば、他のアプリとも会話がしやすくなるかも?というアドバイスが会場からありました。

LT-3 : @dorayaki0

abc記法(abc.jsを使って)を使って楽譜をリアルタイムに記入していくアプリケーションのお話。

楽譜をリアルタイムに鳴らしたいけど実現が難しい・・・という@dorayaki0さんの悩みに対し、会場から「ExtentionならBackground Pageを作ってそこにEvent投げたらいけそう」という解決策が出されていました。

LT-4 : @sasacci

「BLE MIDI on Web Bluetooth」と「VJで家の設計図をグリグリ回した」という2本立てのお話。

  • Web BluetoothでBLE MIDIのChracteristicに7772E5DB-3868-4112-A1A9-F2669D、Serviceに03B80E5A-EDE8-4B33-A751-6CE34EC4C700を指定したらウェブブラウザとBLE MIDI機器とを簡単に接続できる(Macだけかも)

  • Web BluetoothはBLE MIDIとして接続されるだけなので、受け取ったメッセージはParseする必要がある

  • VJ仲間の方のご自宅が3DデータであったのでThree.jsで扱って、VJ素材としてグリグリ回した話

Roland社のAerophone GOを持ち込んでのBLE MIDI on Web Bluetoothのお話で、写真は16進数のMIDIメッセージをネタに会場とやり取りをしているところ。

LT-5 : @tadfmac

簡単にIoT機器作りたいじゃん、というお話。

  • 簡単にIoT機器を作るにはMIDIで有線接続がいいぞ!

  • MIDI機器を作るにはmocolufaがいいぞ!

  • UI作るならブラウザがいいぞ!ブラウザはChromeでしょ。

途中からディスプレイが映らなくなるというトラブルがありました。

LT-6 : @xsoundjs

MediaElementAudioSourceNodeと映像フォーマットのお話。

  • 普段は自己紹介しないけど今回は関連するのでしちゃいます!↓

  • hls.jsのComitterしてます!

  • MediaElementAudioSourceNodeで音を横取りして加工できる。
  • 横取りすると映像とズレが生じることがある。

  • MediaElementAudioSourceNodeを使うと、その瞬間にVideo Element側の音はMuteされる。

  • MediaElementAudioSourceNodeは現状ではChrome限定っぽい?

スポンサー

今回のMeetupは私の現所属である株式会社デジタルハーツにスポンサーをしていただききました。飲み物、ピザを提供いただきリラックスした形のMeetupすることができました。サポートしてくださった皆様に心から感謝を申し上げます。
ありがとうございました!

なお、IT系の勉強会、Meetupに対して、会場のご提供が可能なケースもるかもしれませんので、そのときはご相談ください。

おわりに

不定期にこんな形のMeetupを開催していく予定です。
これからの Web について真剣に議論する「次世代 Web カンファレンス」のWebMusic(#nwc_music)のセッションがあります。そちらもお楽しみに!

リンク

2018年10月31日をヤマハ株式会社への所属の最終日とし、2018年11月1日から所属を改め、次なるステージに踏み出します。

TL;DR

次のステージに踏む出すことを決断しました。

「持ちうる力を絞り出し、今までとは違った形で世の中に貢献したい」

という想いを強く抱いたのが決断の理由です。

ヤマハ株式会社に所属中に携わった仕事と活動

簡単に振り返ってみようと思います。ヤマハ株式会社には2005年4月から13年7ヶ月間お世話になりました。しかし、実は中核事業である「楽器製造」に直接関わったことはありませんでした。もしかすると、だからこそ多くの経験をすることができたのかもしれない、と振り返っています。

2005年7月〜2012年2月

入社後、浜松での研修直後にインターネットのビジネスを企画、開発、運営していた部門に配属されました。ヤマハ株式会社の技術系としては当時は数少ない東京駐在でした。

この初期配属の経験が、働き方、技術的な考え方の底辺になっているように思います。部門長(当時は視野も狭く最も偉い方という認識でした)の強い想いがあり、 その想いを実現すべく、困難を乗り越え1つ1つ形にする、というのが当時の働き方でした。前例がない場合はゼロから作り上げる、ということも経験させていただきました。 大きな会社ですので、特に「ゼロから作り上げる」というのは貴重な経験だったと思います。

実務では部署内のネットワークの運用・管理、自部門が社内向けに提供するサービスの企画・開発・運営を行いました。 それらと並行してヤマハオンラインメンバーという一般顧客向け(B2C)のサービスを提供するアカウント基盤の運用から少しづつウェブサービス(システム)について教えていただきました。 その後はヤマハオンラインメンバーと新サービスとの連携、決済方法の新規追加の開発などを経て、 ヤマハオンラインメンバーのサイトリニューアルの開発(特にフロントエンド)の担当を行い、 更にそこで集めた顧客データを外部サービスを利用して集計を行う仕組みの企画、開発を担当しました。 本格的なウェブシステムの構築、また外部サービスが提供するAPIとの連携はこの時が最初だったように思います。 この時の経験は現在ではハッカソン等のコーディングイベントで気楽に外部サービスを使う土台になっています。 またこの期間中、社会的にウェブサイトの脆弱性に対する意識も高くなった時期でもあり、脆弱性に関しての研究もしたりしました。 海外現地法人が開発、保守、運用するシステムとのアカウント連携を経験したのもこの時期です。

構築していたウェブサイトに関しては、2005年にはAjaxを使ったGoogle Mapのようなインタラクティブなサービスが登場していましたが、 毎回サーバに対して次に表示するHTMLをリクエストし、それを受け取りブラウザに表示するというレガシーなタイプのウェブサイトでした。 ただし、その裏側は今どきのAPIを駆使したウェブサービスと遜色のない仕組みになっていたと記憶しています。

2012年3月〜2015年12月

この期間の初期の1年9ヶ月は(静岡県)浜松で勤務をするという生活の変化を経験しています。

そして、ここにきて直前まで「苦手」としていたJavaScriptをふんだんに使わざるを得なくなるという事態が発生します(汗)

ミッションは「Web Audio APIを使ってウェブブラウザ上での楽器に関連するウェブアプリの可能性を探る為のプロトタイプを作る」というものでした。 (Web Audio APIはウェブブラウザ上で音声を生成、加工する為のAPI(機能)でブラウザの仕様を標準化しているW3Cで議論されています)

ここでJavaScript一色な毎日へ突入しています。 当時、相談できる人が周りにはいなかったので@agektmrさん、@ebidelさんが 公開していたWeb Audio APIを使ったアプリのコードを読みまくりました。UglifyまたはMinifyされていたコードを人力で読んでたこともありました。 毎日毎日読み込んだ結果、約1〜2ヶ月後には自分のアイデアのアプリが書けるようになっていたと記憶しています。

時を同じくWeb MIDI APIというAPIの提案がされました。 ほぼ全ての電子楽器に搭載されているMIDIを使って、電子楽器をブラウザから操作、また逆に電子楽器からブラウザを操作できるようにする目的での提案です。 (MIDIとには複数の意味がありますが、Web MIDI APIで扱われるのはその中のプロトコルです)

また、ブラウザ界のLegendaryな方 @cwilsoさん、 それからGoogle Developer Advocate(Chrome)の@agektmrさん、 ChromiumのコミッタとしてWeb MIDI APIを実装してくださっている@toyoshimさんと密にに繋がり始めたのもこの頃です。

名実ともにウェブと音楽の距離が近くなり始めたこともあり、@agektmrさんのお声がけで当時から日本でWeb Audio API使いとして有名だった皆さんが集まり Web Music Meetup桜ヶ丘 椿堂で開催され、 翌日2012年10月12日に「ウェブ&音楽&楽器好き」が集まれる場としてWeb Music Developers JP を設立しました。この出来事が公私共にワクワクが始まる原点だった、と振り返っています。(写真:自分自身のデップリぶりにびっくりww)

ここから外部に向けたWeb Audio/MIDI APIの普及啓蒙活動をコミュニティの皆さんと共に行うようになります。 そして普及啓蒙活動の1つとしてブラウザと音楽系APIを使うWeb Music ハッカソンを企画するようになります。 振り返ってみると、日本で5回、上海で1回、その他Meetupを何度か開催することができています。ハッカソンはGoogleさん、AMEI(一般社団法人 音楽電子事業協会)、そしてその他開催側のみならず参加者の皆様のご協力の下で開催することができ、Web Musicを日本で盛り上げることができていると思っています。ご協力、そして参加してくださった皆様には本当に感謝しかありません。

これからも変わらずコミュニティの活動は続けていきますのでよろしくお願いしますね!

忘れられないのが、この頃に大人の科学さんから発売された「歌うキーボード ポケット・ミク」です。 外部からポケット・ミクを操作するソフトウェアの開発で関わらせていただきました。 何気にポケット・ミクは世界で初めてWeb MIDI APIを正式採用した製品 です。 ポケット・ミクの外箱には私の名前を個人名で入れていただいております。 その後、ヤマハ製のrefaceでもWeb MIDI APIを使った アプリケーションの開発を担当しました。このときはWeb ComponentsのラッパーであるPolymerも使ったりと新しいチャレンジを積極的に行っていました。

ソフトバンクさんのPepperにVOCALOIDで歌ってもらうアプリを開発したのもこの時期です。

W3Cでの活動を積極的に行っていたのもこの頃です。

2016年1月〜2018年10月

「米国に行ってくれ。販社じゃなくて、シリコンバレーだけどね。」

まとめると、こういった内容の辞令をChrome Dev Summit 2015から帰国直後の11月21日に東京ミッドタウンで行われていた 慶応大学のORF(Open Research Forum)で 当時の上司@yukio_tadaさんに伝えられたところからはじまります。 (2015年まではChrome Dev SummitはGoogleさんのキャンパスで開催だったのか?!すっかり忘れてた。)

ヤマハ株式会社では「米国に行く」という辞令では大抵はカリフォルニア州 ブエナパークにある販売子会社となるのが通例ですが、 そこと区別するための「販社ではなく」というのがついたという形です。ヤマハ株式会社の技術系としては数少ない米国駐在でした。

この期間の仕事のミッションに関しては割愛します。しかしながら公私共に本当に内容の濃い2年9ヶ月でした。 この期間の出会いには本当に感謝しかなく、そしてそこから得たモノのインパクトはもちろんとても大きいです。

ただ、ここで1つ最も主張したいことがあります。それは

「シリコンバレーにいたことが今回の決断の直接の要因ではない」

という点です。「影響がなかった」「影響は小さい」とは言えませんが、飽く迄も直接の要因ではなく、要因の1つでしかありません。 特にそこだけはここでアピールしておきます。

次なるステージ

さて私の今後はというと、テスト・デバッグを行っている 株式会社 デジタルハーツ に2018年11月1日からジョインします。 第二創業期を迎えている非常にエキサイティングなステージにある会社です。そんな環境で私自身新たな方向に向かい、また持ちうる力を絞り出し全力で世の中に貢献していく所存です。

おわりに

ヤマハ株式会社には約14年と非常に長い間お世話になりました。ありがとうございました。 更なる発展を外から見守らせていただきますし、協力できそうなことがありましたら協力は惜しみませんのでお声がけください!

私は、そこまで柔軟な考をもっておらず、どちらかというと保守的だったと思います。 しかし自らの体験を通して感じた感覚、出会った方々からの刺激でいつの間にか考え方が以前よりも柔軟な方向へと変わっていったのだと思います。 見方を変えれば「周りに流された」のかもしれません。見る角度によって解釈はいかようにでもできると思いますが、私自身はこれで良かったのだと納得しています。 10年くらい前の自分に「10年後は退職エントリを書いてるぞ!」と伝えたら、どれほど驚くことか考えなくとも想像することは容易です。 こんな小さな私事ではありますが「考えたことすらなかった状態」の主人公になってしまうと「絶対」というのはあり得ないんだなと強く感じています。 特にいろいろな側面において変化の激しい現代においては尚更かもしれません。 そんな中で私自身はこれからも例外なく変化するであろう時代に柔軟に対応できる柔軟な考え方を持ち、また体力をつけ、 感じるがままの方向に進めるように努力していきたいと思います。

なお、今回のこの大きな決断にあたり貴重な時間を割いて相談に乗ってくださった皆様、アドバイスしてくださった皆様、また応援の言葉をくださった皆様、 ご心配くださった皆様に、この場を借りて心から感謝を申し上げます。本当にありがとうござました。 今後も本気で一歩一歩前にがんばって進んでまいりますので、何卒、引き続きよろしくお願い申し上げます。

お知らせ

勤務地は新宿(ちょっと西側だけど)になります。今までと変わらずお声がけいただけるとうれしいです!

Web Music Developers JPの管理人も続けますので、今後ともよろしくです!

どうしてもスパムを消費してくて&現実逃避に「スパムにぎらず」を作ってみたときの感想です。

おにぎらず

「おにぎり」とは手を使って握るから「おにぎり」で、「おにぎらず」はその調理過程の「にぎる」を「にぎらない」スタイルにした料理。2015年くらいからジワジワと流行りだして、2018年9月現在ではその熱は冷めたように感じている。
今回はこれを参考にしてスパムにぎらずを作ってみた。

スパムにぎらずを作ってみて

結論として、白いごはんは酢飯にして、甘めの玉子焼きが合うように思う。スパムは軽く火を通すくらいかな。

そして一番感じたのが「ネーミング」。個人的には「おにぎらず」はもったいないネーミングな気がした。
その理由は、作ってみておにぎりよりも手間がかかることが分かったから。この「おにぎらず」って、 お寿司の海苔巻きとおにぎりの間のジャンルだろうと気がついたのです、手間も、見た目も。
調理の手間から言うと海苔巻きのが手間がかかり、おにぎりは比較的楽ちん。なので、この「おにぎらず」というのを名前から 「おにぎり」の一種と理解をして調理をすると、その手間からギャップを感じ、作らなくなると思ったのです。
だからもう少し海苔巻きを連想できる名前のがよかったのかな〜、なんて感じました。
心理的にも「おにぎりに近い調理ができた!」というより「海苔巻きに近い調理ができた!」というほうが満足度も高いですよね。
そしてスパムを入れたからかもだけど、酢飯にしたほうがおいしかったです。スパムの塩辛さがより緩和されました。

まとめ

「おにぎらず」は「海苔巻き」を調理すると考えて調理したほうが満足度は高い!
命名ってとても難しいけど、かなり大事なんですよね。