追記(20140124): paizaさんから景品のロックスター30本頂きました!ありがとうございました!

最近話題のpaiza主催のコーディングコンテストにチャレンジした。
キャンペーンの設定では、野田さんはコードの書ける社長令嬢とのことで、つまり社長の名前も野田さんなのであり、色々な意味で悶々としてしまいますね。

以降、ネタバレ含む真面目なアルゴリズムの話になりますので、自力でチャレンジしたい方はご注意ください。

やりたいことの半分も出来てないけど、連休終わってしまうので出来たところまでDemo。Webサーバーのアクセスログをリアルタイムで監視して、リアルタイムで音にして聴いてみよう、しかも音楽的な感じで、という試みです。

https://github.com/aklaswad/statechno

ビデオにキャプションつけるやりかた分からなかったので、何をやっているかわかりづらいかもしれませんが、以下のような流れのデモです。

  1. 起動するよ
  2. 音が出るよ
  3. アクセスが増えると盛り上がるよ
  4. エラーも拾うよ
  5. アタックされると多分こんな感じだよ
  6. upstreamが死ぬと多分こんな感じだよ
  7. 監視サーバーごと死ぬと多分こんな感じだよ
  8. Pdのパッチだよ
  9. アクセスが減ると寂しいよ

基本的にtechno_nekoさんと話してた流れで「perlで音楽で遊びたい」->「だがperlでオーディオそのものをいじるのはしんどい」->「オーディオ部分はOSC経由でPdにまかせてしまったほうが良い。最近Pdが熱い。」->「だったらperl側はperlが得意な領域で頑張ると面白いのでは」ということで、アクセスログをOSC経由でストリームして、なんかアクセスガンガン増えてるとツマミ右に回していくような感じでどうかな、ということで作ってみました。

構成としてはPerlスクリプトがログファイルというか標準入力をリアルタイムで監視して、1step(120msくらい)ごとにまとめてOSCで送信、Pdで受け取ってシンセサイズする、という流れになってます。

YAPC::Asia 2013 行ってきた。

  • Posted on
  • by

今年もYAPC::Asia参加してきました。

チケット

このブログで書いてなかった気もしますが、ただ今PeaTiXで働いています。受付が上手くいっているかなどドキドキしてました。
名刺カードに「チケットの文句は俺に言え!」と小さく書いて、「優しく」と書き足し、更に名刺で隠していたチキンがこちらになります。

前夜祭

前夜祭に参加するのは初めて。さらに、飛び入りでLTして来ました。PeaTiXのアプリ絡みで前日の朝までに起こった出来事を、アップデートのお願いも兼ねてお話ししようと思ったのが前の日の夕方。当日に急いでスライド作って練習して行ったのですが、去年のLTソンの雰囲気と全然違って、飛び入り出来るか超ギリギリな感じで焦りました。
そして、改めて自分はあがり症だなあと。あんまり記憶がありません。練習の時に平均5分10秒とかだったのに、雰囲気的にも巻き巻きな感じなので、超早口になってしまいました。

なんですかねー。本当に慣れないです。この後まじで胃が痛くなって、今もまだ痛いです><。でも、他の人と話すきっかけとかにもなって、やってよかったです。

初日

午前中は寝坊+ちょっと仕事などで出られず、午後から。なんかどの会場も満員な感じで、どうしようと思いつつぼんやりしたり前職のボスと話したり、techno_nekoさんと遭遇して、perl+oscで音を鳴らすデモを見せてもらったりしてました。そして、結構面白そうなアイデアをいただき。。。

懇親会は登録していなかったので、Hub.pmに参加。頑張っていろんな人に話しかけたりしました。
そのうち懇親会組や大人の人たちが雪崩れ込んできて大変な騒ぎに。帰るタイミングを見失って飲み過ぎてしまった感があります。どのくらい飲み過ぎたかというと記憶がスワップファイルからかろうじてサルベージできるくらい。charsbarさんに音楽とはみたいな話を力説していたような。。。

二日目

午前中は二日酔いでかなり辛い感じ+前日に思いついたアイデアに手を付け始めたら止まらなくなり、午後に会場に移動するもBOF会場で黙々とコード書いてました。とりあえずある程度形になり、techno_nekoさんにdemo見て貰うところまで出来たのでよかった!
その後はLT~クロージングまで見て、胃が痛いので家に帰りました。

まとめ

  • 頑張って人前で喋った
  • 人と話すと新しいアイデアを貰える
  • LT以外のトークひとつも見てない\(^o^)/

コミットメッセージの最初の空行までがsubjectです。最初の一行、ではありません。

subjectは、git log --onelineとかgit log --format="%s"とかした時に使われます。なので、

Clean up my room
* Wash whole dishes
* Mop the bathtub
* Throw away magazines

このようなコミットメッセージの書き方をすると、自分の中ではsubjectと本文がわかれていても、

$ git log --oneline
988f5e7 Clean up my room * Wash whole dishes * Mop the bathtub * Throw away magazines

こんな風につながって一行になってしまいとても読みにくいです。

今度から気をつけましょう > 自分

WebSocketを使ってゴニョゴニョしているのだが、handshakeの失敗時のエラーをどう扱うべきなのか、よくわからない。WebSocket Protocol の仕様と WebSocket API の仕様で書いてあることが違う。
protocol仕様を読む限り、サーバーはhandshakeを拒否する場合適切なHTTPエラーコードを返さなくてはいけない、と書いてある。が、クライアント側のウェブブラウザ上のjavascriptでそれを期待しているとエラーイベントからはHTTPエラーコードは受け取れない。WebSocketの異常終了コード1006が固定でセットされている。

そこでAPI仕様を読むと、これらを行わない理由が赤字で大きく書いてある。

  • オープンリダイレクタが設置されたサイトで脆弱性になるので、handshakeのレスポンスはHTTPとして扱わない。
  • 悪意あるスクリプトに攻撃の準備としてネットワーク環境の調査に使われるのを防ぐため、接続失敗の理由をスクリプトに通知してはいけない。

接続失敗の理由を開示してはいけない、というのは特定のシチュエーションの場合、と限定してあるのだが、この一文

A server that did not complete the opening handshake (e.g. because it was not a WebSocket server).

http://dev.w3.org/html5/websockets/

が示す範囲がよくわからなくて、これがもし403とか返した場合も該当するなら、サーバーはHTTPエラーコードを返さなくてはいけないがブラウザはエラーコードを握りつぶさなくてはいけない、ということになる。実際API仕様にもHTTPステータスを受け取れるとは書いてないし、そういうもんだと言われればそれまでだが、実際のところ困る。
chromeのコードもはっきりそうなっているっぽくて( @gtk2k さんに教えていただきました。ありがとうございます。 )、101以外のHTTPステータスを受け取っても、特に個別の動作はしないし、エラーイベントのどこを探してもHTTP statusが見つからない。リダイレクトもしない。Unexpected response code: 403という文字列がエラーコンソールに出てくるけど、javascriptからは拾えなそう。

一体どうすれば良いのかわからず、原本 http://tools.ietf.org/html/rfc6455 および http://www.w3.org/TR/websockets/ と、そこから辿れる旧バージョンを参照した。以下の様な時系列で変更が行われた模様。

WebSocket Protocol hybi-05以前

プロトコル仕様に以下の記述がある。

  • 記述1 ユーザーエージェントは、一部のシチュエーションではエラーの理由をスクリプトに伝えてはいけない
  • 記述2 handshakeのレスポンスとして101以外を受け取った時、WebSocket接続を終了する
User agents must not convey any failure information to scripts in a
   way that would allow a script to distinguish the following
   situations:

http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-05#section-7.1.1

If the status code received from the server is not 101, the client
      MUST fail the WebSocket connection.

http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-05#section-5.1

WebSocket Protocol hybi-06 February 25, 2011

プロトコル仕様から記述1が消える

ietf のメーリングリスト 28 Mar 2011

プロトコルレベルではHTTPをサポートするべきという方向に話が進む

(超意訳)これ(オープンリダイレクタの問題)って俺達の問題じゃなくてWHATWGの問題だよね。リダイレクトや認証機能が無しなんてやってらんないから入れちゃおうぜ。もしブラウザが当面リダイレクトをサポートしないって事になってもOK。後でブラウザ側の挙動だけ変えれば済むなら楽だし。

I don't think it is "our problem".     I think it is a "W3C/WHATWG
HTML-5 WG problem".

This is essentially an API issue for the browser websocket object.
There are plenty of ways around this (adding optional follow
redirects, exposing redirect responses etc. etc.),   but I think it is
the W3C and WHATWG HTML-5 working groups that should be where such
matters are decided.

As a web developer I really rather not have to go without redirection
and other common auth methods - and I take responsibility for my
servers not being open redirectors..... but would understand if the
W3C/WHATWG decided not to support these features - at least initially.

However, we should make the protocol such that if/when the API does
support these features, then it will only be an in browser change and
not an update of the protocol.

http://www.ietf.org/mail-archive/web/hybi/current/msg06954.html

WHATWG のメーリングリスト Mar 29 2011

APIレイヤでHTTPを理解するかは先送りの方向に

(超意訳)(HyBiのスレッドではHTTP使う方向になってるぜ、という話を受けて)オープンリダイレクタの問題はセキュリティ上の大穴だという意見に同意だ。httpが犯した過ちとそこで起こった問題を繰り返すべきではない。この問題は先送りにして、当面APIレベルではリダイレクトには対応しない、という方向で。

I absolutely agree that redirects are a big source of security
problems. If we are going to support them for websocket then I think
we need to learn from the mistakes of http as to not repeat the
problems that occurred there.

(中略)

But I'm totally fine with punting on this for the future and just
disallowing redirects on an API level for now.

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/031079.html

WebSocket Protocol hybi-07 April 22, 2011

記述2部分が変更 101以外はHTTPとして処理する

If the status code received from the server is not 101, the client
      handles the response per HTTP procedures.  Otherwise, proceed as
      follows.

http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07#section-5.1

WebSocket API r1.210 May 24, 2011

旧記述2相当の内容がAPI仕様に引越し

Block redirects in WebSockets (whatwg r6148)
+    When the user agent validates the server's response during
+    the "establish a WebSocket connection" algorithm, if
+    the status code received from the server is not 101 (e.g. it is a
+    redirect), the user agent must fail the websocket
+    connection.

http://dev.w3.org/cvsweb/html5/websockets/Overview.html#rev1.210

WebSocket Protocol hybi-08 June 7, 2011

handshake失敗時にサーバーはエラー理由をHTTP error codeで表現しなさい、という記述が登場

 If the server does not wish to
          accept this connection, it MUST return an appropriate HTTP
          error code (e.g. 403 Forbidden) and abort the WebSocket
          handshake described in this section.

http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-08#section-5.2.2

WebSocket Protocol RFC6455 PROPOSED STANDARD December 2011

現在のhandshakeのレスポンスの扱い protocolバージョン

Any status code other than 101 indicates that the WebSocket handshake
   has not completed and that the semantics of HTTP still apply.  The
   headers follow the status code.

http://tools.ietf.org/html/rfc6455#section-1.3

WebSocket API r1.271 Jul 11, 2012

記述1相当の内容が一年五ヶ月ぶりにAPI仕様として復活。

Clarify what codes are exposed in case of error, since this text was mysteriously removed from the RFC at some point. (whatwg r7175)
+   User agents must not convey any failure information to scripts
+   in a way that would allow a script to distinguish the following
+   situations:

http://dev.w3.org/cvsweb/html5/websockets/Overview.html#rev1.271

WebSocket API W3C Candidate Recommendation 20 September 2012

現在のhandshakeのレスポンスの扱い APIバージョン。 赤くて目立つようにHTTPは混ぜるな危険とwarning。

When the user agent validates the server's response during the "establish a WebSocket connection" algorithm, if the status code received from the server is not 101 (e.g. it is a redirect), the user agent must fail the WebSocket connection.

Following HTTP procedures here could introduce serious security problems in a Web browser context. For example, consider a host with a WebSocket server at one path and an open HTTP redirector at another. Suddenly, any script that can be given a particular WebSocket URL can be tricked into communicating to (and potentially sharing secrets with) any host on the Internet, even if the script checks that the URL has the right hostname.

http://www.w3.org/TR/websockets/#the-websocket-interface

というわけで、プロトコル仕様ではhandshakeのレスポンスはHTTPとして扱う方向になっているが、API仕様ではこれを無視する。将来的に統一するならAPI仕様が変更される。というのが現状のようです。接続失敗の理由をスクリプトから隠す件については結局良くわかりませんでした。MLはgoogle先生が最初に教えてくれた周辺しか読んでないので、他にも色々議論があったのかもしれません。

実際どう対処すればよいか。少なくとも現時点のブラウザの実装がエラーコードを隠蔽してしまう以上、サーバー側の実装をするときにhandshakeの結果をHTTPで返しても無駄な気はする。handshakeしてから即closeするか、またはエラー診断用のHTTPのエンドポイントを用意するとか。うーん。

When and where my laptop was running?

  • Posted on
  • by

勤怠表提出の自動化などが目的で、持ち歩いているラップトップのWi-Fiの接続先をログに取るようにしていたのだが、結構ログが溜まってきたので視覚化してみた。

OSXでは接続しているSSIDなどの情報は以下のコマンドで取得できる。

/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -I

この結果をパースして、SSIDに変化があったらファイルに追記するという簡単なperlスクリプトを、cronでぶん回しているだけ。接続先のSSIDのバリエーションなどはたかが知れているので、SSIDに対応した処理も行える。自分は、日付が変わってから最初にオフィスのネットワークに接続したらfoursquareでチェックインするようにしてる。のでスクリプトに直接APIKeyなど書いてあるので公開しません;)

今回は、ログファイルをパースして、グラフっぽいHTMLを書き出してみた。これもcronで一日一回生成してscpでサーバーに投げるようにした。オフィスのネットワークやモバイル(wimax/iPhone)など接続先にあわせて色分けしたので、時期や季節によって行動パターンが違うのがわかって面白いと思う。寒くなると冬眠するがごとく活動時間が短くなっている様がよくわかりますね(震え声

ちなみに2011年3月の空白期間は、ラップトップのロジックボードがやられて起動不能だった+修理期間で、地震は直接の原因ではなかったりする。


11inch 全部盛り USキーボード。人生初のUS配列。
Lionでperl/node.js/coffeeScriptあたりの開発環境を整える際の自分用メモ。(一部追記あります。)

前回の記事で書いたsonificatorの開発が思いの外面白く、勢い余って買ってしまった。コンピュータで作曲や音声合成を行うための理論が網羅的に解説されている大著。

コンピュータ音楽―歴史・テクノロジー・アート
Curtis Roads 青柳 龍也 後藤 真孝
4501532106

「訳者らあとがき」によれば原著は1996年とのことで、実に15年前の内容。記述が古い箇所が多いことも否めない。例えば、現在のDAWのようにMIDIイベントとオーディオ波形が並んで表示されているシーケンサー画面について「グラフィカルな表現は、純粋な MIDI データとオーディオ波形間の時間的な対応を見るのに便利である(p 608)」と解説してある。 まだ同時には再生できなかったのだ!

理論的な部分での充実度は尋常ではなく、多くのシンセサイザーやエフェクターの原理から、グラニュラーシンセシスの理論的背景まで、自分には十分すぎる範囲がカバーされている。殆どの場合、今でも不足を感じることは無いと思う。

十年くらい前に音楽系のプログラミングに凝っていた時期があって、その時に図書館で借りて頑張ってひと通り読んだ。ここ5-6年はソッチ系のことを殆どやっていないので、大分忘れてしまった。素人の手習いに過ぎないが、また頑張って読もうと思う。当時は手元に置いておきたくてもあまりに高くて手が出なかったが。。。いや、今でも十分財布に厳しいぞ。もとを取るためにもsonificatorはしばらくいじり続けたいと思います。

YAPC ASIA 2011行ってきました。

cho45さんのWAFの話とか、普段書いているコードに直結するような話で興味深い話も多かったのですが、それ以上に、techno-catさんやHaruka Kataokaさんの音楽関係のトラックにとても刺激を受けました。そういえば、自分がプログラムを始めたきっかけって、テクノとかエレクトロニカとか、そんな音楽やりたくてじたばたしているうちに片足突っ込んだのがはじまりだったよな、ということを思い出したりして、まあ、いわゆる初期衝動?に立ち返ったような気持ちになりました。

で、この一週間モンモンとしているうちに、今やるならWeb Audio APIだよななどと思いつつ色々いじってたら、こんなのが出来ました。

すべてJavaScriptで書かれていて、Web Audio APIを利用してブラウザ上でリアルタイムに動作するプログラムで、DOM構造をそれっぽい音楽に変換して演奏します。ブックマークレットから起動できます。最近のchromeでしか動きません。今のところ、いわゆるIDMとかエレクトロニカといった感じの音にチューニングされてます。ちょっとした画像効果付きなので、そっち系統の音が好きな方は、好きなサイトで実行して放置すると良い感じなんじゃないかと思います。

自分のお気に入りは、Facebookのウォール部分です。予め先の方までAutoPagarizeしておいて垂れ流すと、とても気持ち良いです。みなさんも試してみてください。

Perlのパの字も無いところに落ち着きましたが、言語に拘らずいろんな方向に刺激を与えてくれるのもYAPCの良いところですね。この土日も仕事とも言語とも関係なく、好きなコード書きたいという気持ちが、今の僕には溢れてます。