そんなもの作ったのか、という感じ。バイナリ表現という 時点であれ。当時、WAPのためにデータを圧縮したかったらしい。 しかし、こんなバイナリ表現をビデオや音楽コンテンツ、電子書籍の 配布にも使おうなんて、明らかに間違っている。まるで ビデオの再生ボタンの操作をするプログラムのためにアセンブラを 使うような感じ。一般的に言えば、携帯電話の画面に 表示されたボタンやアイコンを押すのに、細い針を使って、 正確にアイコンの左上3ピクセル目を押す、ような感じ。 要するにムダにむずかしい。なんというか、根本的に ガラパゴスというか。ひきずっているからガラパゴスなのか、 ひきずりたい人がそんなにいるのか、というか。

ビデオや音楽を配布するときはブロードバンドなんだから、 そんな圧縮使わないで。ということ。

" wsp-30-apr-98.pdf"によれば、左端のビットが1のときは 続きがある、という意味。0のときは、そのオクテットで 整数は終わり。そういうわけで、何バイトでもエンコードできそうだが、 4バイト(32bit)まで。なぜ4バイトでやめる ... 。それだけなら 圧縮しなくていいでしょ、とに。

エンコードは、右端から7bitづつとりだして、ヘッダをつけていく。 デコードは、8bit目のフラグを見てuintvarの羅列を取り出したら、 各オクテットの8bit目を捨てて右側7bitをとりだし、整数の右端へ 詰めてパックする。

uintvarが1バイトなら、7bit表現、2バイトなら14bit、3バイトなら21bit、 4バイトなら28bitしか表現できない。何かそういうハードウェアの レジスタかアドレスバスか何かがあったのか？ じゃなくて、 IrDAとかBluetoothでも使っているOBEXやTCP/IPの拡張ヘッダで使われている continueフラグと同じだった。しかし、それ整数でやる？しかも4バイトまで、 だけで。

GET /foo?var=valというリクエスト行と、GETで送った ボディは同時に送信することができ、サーバでも同時に 受信できる。GETだからボディがない、ということもない。 POSTでも、リクエスト行に/foo?var=valと書けば、 CGIの環境変数QUERY_STRINGにvar=valと入ってくるし、 HTTPボディを標準入力から読み込むことができる。

で、結局GETとPOSTの違いは、GETは何度やっても同じURL なら同じ結果が返ることがある、読み取り命令で、 POSTは毎度書き換えが起こる命令でキャッシュしては いけない命令、ということ。

Google Developers Conference参加申し込みで 出題された問題。OAuthの公開鍵を使った3-legged認証ではなく、 共有鍵を使って鍵つきダイジェスト認証をする、著者不在の 2-legged(足)な認証をする。devquizという比較的簡単な問題 なのだけれども、いままで使ったことがないので練習のつもりでやってみた。 自分でGoogle Apps premierを使っていれば、利用したかもしれないが、 そうでもないし。3-legged OAuthを見て、あーめんど、と思って 敬遠していたのもある。

自分の理解のために、手でseed作成とHMAC-SHA1ダイジェスト作成を コーディングしていたが、どうもうまくいかない。しかたなく PythonのコードやPHPのコードを探してみると、いくつかあるが 今回のGoogleのdevquizのようにPOSTで、realmをつけて、Authorization ヘッダで認証する、というコードがない。Pythonのマニュアルの 読み方を調べる直前で、PerlのOAuth::Liteがいい、というのを見て やってみると、関数に引数を与えるだけであっさり認証が完了した。

#!/usr/bin/perl 

use 5.0.8;
use strict;
use warnings;

use Data::Dumper;
use OAuth::Lite;
use OAuth::Lite::Consumer;

my $consumer = OAuth::Lite::Consumer->new(
  consumer_key		=> 'YOUR_CONSUMER_KEY',
  consumer_secret	=> 'YOUR_CONSUMER_SECRET',
  realm			=> 'devquiz',
);

my $response = $consumer->request(
    method  => 'POST',
    url     => 'http://gdd-2010-quiz-japan.appspot.com/oauth/YOUR_CONSUMER_KEY',
    params  => {
        hello => 'world'
    });

if ($response->is_success) {
    print Dumper($response->decoded_content);
} else {
    warn $response->status_line;
}

PerlのOAuth::Liteは、nonceを自動的に生成し、time()も自動的につけてくれる。 デフォルトはPOSTのAuthorization:ヘッダの、HMAC_SHA1でそろっている。

というわけで、手でコーディングしていたダイジェストの問題は以下のとおりだった。

• seedにはPOSTの送信データであるhello=worldを含めること
• Digest::HMA_SHA1のb64digest()メソッドは、Base64エンコードらしきことを するが、文字列の末尾のパディングをしないため、認証が通らない。
• MIME::Base64のencode_base64()メソッドは、Base64エンコードをするが、 より大きなデータの処理を想定しているため、デフォルトで文字列の 末尾に改行コードを追加する。末尾の改行が不要なときは encode_base64($digest, "")のようにしなければならない。
• realmはoath_なんとかのseedには入れない

mixiの説明は、Googleの説明資料の日本語訳になっていてわかりやすい。 が、PerlのOAuth::Liteを使えば、seedに関連する半分以上の説明は理解しなくてもよい。

PerlのJSON.pmはutf8(1)とutf8(0)を使い分けないと文字化けするとの指摘あり。 このへんもPHPやPythonではどうなのか？という疑問あり。 "json utf8"でGoogle検索すると、トップにこの指摘ページの候補が 表示されるところに問題が。以下のように指摘されている。

JSON->new->utf8(0)->decode($string)　⇒ OK!
JSON->new->utf8(1)->decode($string)　⇒ エラー！
JSON->new->utf8(1)->decode($octets)　⇒ OK!

「エラー」というのは、JSONのdecode()を呼び出すと、 decode()の内部でエラーになり、Perlスクリプトが終了してしまう。 utf8 フラグがある文字列$stringをdecode()したとき、 結果として返るハッシュ内の文字列はutf8フラグがあった。 utf8フラグがない$octetsのdecode()は試していない。

• 同じ日付内の日記記事は、あとから書いたもの(記事番号が大きいもの)を先に表示するようにした。 といってもこのルールは2008年ごろ以降の話。それ以前の日記は あとから書いたものの記事番号が小さくなっていた。そのため、 以前の記事は検索エンジンから見ると記事が追加れるたびに インデックス番号が変わってしまっていた。現在は同じ日付内の 記事のインデックス番号は変わらず(削除されて欠番が詰められることがあるが)、 新しく追加された記事が、その日の先頭に来るようになった。
• 一部関数をライブラリ化。よく見るといくつもコマンドを作っていた。

• ブラウザで利用できるフォントにはttf, woff, svg などがあり、日本語フォントも増えてきた。
• FireFox, Chromeでは @font-face というCSS命令が使える。IEは9からなので現行IEバージョンは全滅。
• 日本語では文字数が多いので @font-face命令の unicode-range属性を使うことで、利用したい 文字の範囲を指定して、ダウンロードするフォントデータの量を 小さく限定できる。
  • かな漢字=U+3000-9FFFF, U+ff??
  • 欧文文字=U+000-5FF, U+1e00-1fff, U+2000-2300
  • かな漢字第一水準=** jis-1 ** (?)
  • かな漢字第二水準=** jis-2 ** (?)
• フォントのダウンロード参照先が別のドメインの場合はCORSが使える。

関連して、 @font-face Kit generatorというツールもあった。フォントを アップロードしたあと、ブラウザでフォントをダウンロードするときの フォントの形式やヒンティングの追加、カーニングの削除、CSSコードなどを 合成するらしい。unicode-rangeらしきものが見当たらない。

フォントのロードとCSSの指定も含めて、JavaScriptを使って 2行追加すればよいだけになっているのは使いやすい。CSSセレクタも あってよい。 自分のサイトのCSSセレクタは真っ白で何も表示されなかったが。

自分の場合、通常の日記記事の見出しに使おうと思ったが 通常の日記は自分にとっては実用性が高いのでデコもじにせず、 1行だけ書いたoneliner記事だけをデコもじにしてみたのが次の画像。

だらだらした緑の背景は自分が描いた画像。フォントは 「まる字」に置き換えられている。font-size: 240%で 表示した。字詰めを変更した覚えはないのだが、ひらがなの間が 離れていて、じつに間抜けな感じ。ほかのメイリオで表示したフォントが 滑らかに表示されているのに、ギザギザしてしまい、読みにくい。

W3C-FOと呼ばれる形式に従って、PDF/PostScript/PCL/Print/PNGなどに 変換するという。紙のようなばらばらに別れた表示エリアに 分割してレンダリングすることを強く意識しているように見える。 が、EPUBなどの電子書籍形式が見当たらない。まずは紙、 プリンタ、ということなのだろうか。

しかし、「Nパ」って何かと思ったら「NTTパーソナル」のことだった。 あぁなつかしい。古すぎて略称がわからない。

「今年もやりますYahoo Japanインターネットクリエイティブアワード」の バナー広告の右側に縦に並んだ「作品募集はじまりました」 以降、6個の枠が縦一列に一度に表示されてしまい、バナー広告の 表示エリアをはずれて下方向に2枠はみ出ていた。リロードしたら 直ったので、何かの都合でダウンロードが途切れていたらしい。