コミットメッセージの最初の空行までが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仕様を読むと、これらを行わない理由が赤字で大きく書いてある。
接続失敗の理由を開示してはいけない、というのは特定のシチュエーションの場合、と限定してあるのだが、この一文
A server that did not complete the opening handshake (e.g. because it was not a WebSocket server).が示す範囲がよくわからなくて、これがもし403とか返した場合も該当するなら、サーバーはHTTPエラーコードを返さなくてはいけないがブラウザはエラーコードを握りつぶさなくてはいけない、ということになる。実際API仕様にもHTTPステータスを受け取れるとは書いてないし、そういうもんだと言われればそれまでだが、実際のところ困る。
Unexpected response code: 403という文字列がエラーコンソールに出てくるけど、javascriptからは拾えなそう。
一体どうすれば良いのかわからず、原本 http://tools.ietf.org/html/rfc6455 および http://www.w3.org/TR/websockets/ と、そこから辿れる旧バージョンを参照した。以下の様な時系列で変更が行われた模様。
プロトコル仕様に以下の記述がある。
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
プロトコル仕様から記述1が消える
プロトコルレベルでは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
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
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
旧記述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
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
現在の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.
記述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
現在の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.
というわけで、プロトコル仕様ではhandshakeのレスポンスはHTTPとして扱う方向になっているが、API仕様ではこれを無視する。将来的に統一するならAPI仕様が変更される。というのが現状のようです。接続失敗の理由をスクリプトから隠す件については結局良くわかりませんでした。MLはgoogle先生が最初に教えてくれた周辺しか読んでないので、他にも色々議論があったのかもしれません。
実際どう対処すればよいか。少なくとも現時点のブラウザの実装がエラーコードを隠蔽してしまう以上、サーバー側の実装をするときにhandshakeの結果をHTTPで返しても無駄な気はする。handshakeしてから即closeするか、またはエラー診断用のHTTPのエンドポイントを用意するとか。うーん。
勤怠表提出の自動化などが目的で、持ち歩いているラップトップのWi-Fiの接続先をログに取るようにしていたのだが、結構ログが溜まってきたので視覚化してみた。
OSXでは接続しているSSIDなどの情報は以下のコマンドで取得できる。
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -I今回は、ログファイルをパースして、グラフっぽいHTMLを書き出してみた。これもcronで一日一回生成してscpでサーバーに投げるようにした。オフィスのネットワークやモバイル(wimax/iPhone)など接続先にあわせて色分けしたので、時期や季節によって行動パターンが違うのがわかって面白いと思う。寒くなると冬眠するがごとく活動時間が短くなっている様がよくわかりますね(震え声
ちなみに2011年3月の空白期間は、ラップトップのロジックボードがやられて起動不能だった+修理期間で、地震は直接の原因ではなかったりする。
11inch 全部盛り USキーボード。人生初のUS配列。
Lionでperl/node.js/coffeeScriptあたりの開発環境を整える際の自分用メモ。(一部追記あります。)
前回の記事で書いたsonificatorの開発が思いの外面白く、勢い余って買ってしまった。コンピュータで作曲や音声合成を行うための理論が網羅的に解説されている大著。
コンピュータ音楽―歴史・テクノロジー・アート
Curtis Roads 青柳 龍也 後藤 真孝 
「訳者らあとがき」によれば原著は1996年とのことで、実に15年前の内容。記述が古い箇所が多いことも否めない。例えば、現在のDAWのようにMIDIイベントとオーディオ波形が並んで表示されているシーケンサー画面について「グラフィカルな表現は、純粋な MIDI データとオーディオ波形間の時間的な対応を見るのに便利である
」と解説してある。 まだ同時には再生できなかったのだ!
理論的な部分での充実度は尋常ではなく、多くのシンセサイザーやエフェクターの原理から、グラニュラーシンセシスの理論的背景まで、自分には十分すぎる範囲がカバーされている。殆どの場合、今でも不足を感じることは無いと思う。
十年くらい前に音楽系のプログラミングに凝っていた時期があって、その時に図書館で借りて頑張ってひと通り読んだ。ここ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の良いところですね。この土日も仕事とも言語とも関係なく、好きなコード書きたいという気持ちが、今の僕には溢れてます。
通常、MTのパッケージはシステムレベルにインストールされません。そのため、lib/ とextlib/ へのパスを実行時に追加する必要があります。
例えば、EntryオブジェクトをDumpするワンライナーは以下のようになります。
$ perl -Ilib -Iextlib -MMT -MData::Dumper -e 'MT->new; print Dumper(MT->model("entry")->load(42))'
また、プラグインごとのlibディレクトリへのパスは、MTのインスタンス作成時に動的に追加されます。そのため、MTのプラグインを開発中、コンパイルチェックをしたい時などに直接実行する事ができません。
$ perl -Ilib -Iextlib -Iplugins/MyPlugin/lib -c plugins/MyPlugin/lib/MyPlugin.pm
長いですね。
そこで、以下のようなモジュールを、perlのパスの通った場所に設置します。
package T;
use strict;
use warnings;
use lib qw( lib extlib );
use MT;
BEGIN { MT->new };
1;
名前は、T.pmです。これで
$ perl -MT -MData::Dumper -e 'print Dumper(MT->model("entry")->load(42))'
$ perl -MT -c plugins/MyPlugin/lib/MyPlugin.pm
などと、perlにMT専用オプションが追加されたような錯覚を覚える事が出来ます。
Gollumは、githubのwikiエンジンのコア部分がオープンソースとして公開されたものです。軽量なWebServerとして動作するので、ローカルマシン上で起動してすぐに、ブラウザ経由でwikiページの閲覧や編集が可能になります。使用感をメモしておきます。
$ sudo gem install gollum $ git init my_wiki $ cd my_wiki $ gollum
これで、デフォルトでポート4567にウェブサーバが起動するので、ブラウザでlocalhost:4567にアクセスしてすぐにwikiページの作成が可能です。
gollumはストレージとして、一般的なDBエンジンではなくgitを利用しています。ブラウザからページを追加してみるとわかりますが、wikiページがファイルと一対一で対応するという直感的に分かりやすい構造になっています。ワーキングコピーでそれらのファイルを直接編集してgit commitすることでwikiに反映させることもできます。
githubのwikiもgitリポジトリとしてアクセス可能になっているので、githubからwikiをガバっとcloneしてローカルマシン上のGollumで確認しながら大量にページ追加作業をし、まとまったところでgithubにpushといった形でのgithubと連携することで、かなりの作業の効率化が可能かと思います。
オマケ的な利点として、画像などのファイルを直接git addする事でリポジトリに含めて管理、参照するといったことも挙げられます。(現時点ではGithubのwikiにはファイルアップロードのインターフェースがないので)
必要なライブラリをインストールする事で、以下のマークアップフォーマットを利用できます。フォーマットはwikiページごとに設定できます。
また、github 独自拡張のwiki内リンク記法が利用できます。
ワーキングコピーではなくgitリポジトリそのものを見ているので、ファイルベースで作業した場合、git commitするまで反映されない、ということに気づくまで小一時間はまった。
Happy new year! Happy Github!
ということで、Movable Type のリポジトリがgithubに移行してとても楽しみなのですが、コミットログにFogbugzのケース番号書いてあってもWebから見たときにリンクにならないので不便です。のでとりあえずChrome extensionでなんとかします。
https://github.com/movabletype/ 以下で、コミットログからfogbugzのcase番号らしきものを拾って、近くにリンクを追加します。だけです。もっと良い方法をご存知の方教えてください。
一週間経ってしまいましたが、MTDDC HOKKAIDOのまとめ。