perlは本当にスゲー。こんなのないかな、あるかな、と思ったら、ほとんどすでにCPANに登録されている。ほかの lightweight language の状況は知らないので比較できないけど、perlがあればほとんど用が足りてしまうんじゃないか。

てことで、QRコードの生成。

創作文芸見本誌会場HappyReadingのスマホ版を作ったことだし、スマートフォンで見てもらえるように、誘導したい、というのが目的。スマートフォンでちまちまURLを入力するのはうっとーしーんで、QRコードの出番だろう、と。

レンタルサーバーのlolipopには GD モジュールと一部の関連モジュールはインストールされているらしい。ただ、ここで肝心の、QRコードがインストールされていないので、CPANからもってきた。

CPAN http://search.cpan.org/~kwitknr/GD-Barcode-1.15/

↑これをダウンロードして解凍展開。中を見ると、何かをコンパイルするワケでもなく、ただ所定のディレクトリにコピーしてるだけの pure perl モジュール。そのままlolipopにFTPでアップロードしたら、問題なく使えた。

use GD::Barcode::QRcode；
binmode STDOUT；
print qq{Content-type: image/png\n\n}；
print GD::Barcode::QRcode->new(STRING，
    {Ecc=>M， Version=>10， ModuleSize=>2})->plot->png；

コードは、これだけ。

STRINGの部分にURLとかテキストを入れる。日本語もOKだけど、検索してみると、ガラケーはSHIFT JIS なので、文字コードを SHIFT JIS にしていることが多い。

これで、QRコードの画像 png を出力してくれるので、img タグに、このスクリプトのURLを書いておけばいい。ちょっと調べたのがQRコードの仕様。

ECC というは、エラー修復レベル。

アウトドアなど汚れ・破損が激しそうなところで使う場合には Hレベル(修復30%）、などなど修復できるレベルがあるので、それを指定する。

ModuleSize というのは、文字通りセルサイズ。

ひとつひとつのセルのサイズを指定できる。

Version・型番というのはセル構成＝セル数。

１～40まであって、大きいほど記録する文字数が増える。

て、ウチみたいな素人ヨタ話のブログを見るより、開発者の一次情報を確認しましょう。

QRコードドットコム

画像を生成して表示するのに、ほんの少し時間がかかるので、サイトではajaxを使ってスクリプトを呼び出すようにした。情報としては、URLとサークル名、本のタイトル。

スマホのQRコードで読み取って、URLに飛ぶとその本のページが開く。おお、これは便利だ。便利なはずだ。きっと。だがしかし。

QRコードの活用例として、流通の現場で商品の確認とか、製造の現場での商品トレースとか、バス停で時刻表とか、有効に活用されている。たとえば、WEBへ誘導するのに、チラシや名刺にQRコードがプリントされていたら便利。だけど、サイト上にQRコードを表示して、さてそれってどうなの？PCでサイトを見ていて、そのページをスマートフォンでも見てみたい、というリクエストがそんなにあるとは思えない。

QRコードが使えるのでとりあえずつけてみました感が漂う。

WEBサイト上にQRコードが表示してあって、こいつは便利だぜ、待ってたぜ、という事例があったら、ぜひ教えてください。

jquery mobileは、一度ページを読み込んだらいつまでどこまでDOMを保持管理してるのかが、複雑に入り組んでいる。サイトに着地して、ページのヘッダまでを読み込んだら、あとはbody部分のDOMの書き換えでページ表示している。リンク、というか、ページの取得は ajax が基本。そのために、id属性などは、ページに一意ではなくて、サイトで一意にしておいて、DOMまわりのトラブルを避けることが推奨されている。ajaxとidなどのプロパティは密接だからねえ。

このあたり「jquery mobile ポケットリファレンス」の Chapter20 ページイベントに図があって、ちょっとわかりやすい、かも。

ハマったのでメモしておく。とほほ。

やりたいこと。

JSONで連想配列のペアを渡して、そいつをevalで読み込みオブジェクトにして、キーを作って値を取り出す。ありがちで、よく使われるシチュエーションだ。なのに、どうにもこうにも見えてこないんで、小さくテストをしてみた。

var data = {key1:val1， key2，val2}； というJSONのデータ

まず、evalの書き方でハマった。WEBを探すと、evalに渡す時に、変数を()で括る必要がある、という記事を多数見かけたので、やってみたら、missing after elements だかのエラー。

var obj=eval(data)；

と、なんの細工もせずにシンプルに書いたら、これでOKだった。()で括る必要があったり、”の展開を考えたり、ラベルが問題？とか右往左往した。ネットの２次情報を呪文状態で使っちゃだめですよ、てことだな。１次情報に当たるべし、だった。

さて、次のハマり。

var str = "key"；

var num = 1；

var key = str + num；

どの値が欲しいのか、てことで、こんなことは当たり前にある。

変数の key を作ったんで、さて値の取出しだ、と

obj.key

とかやったら undefined

for(var k in obj){

alert(k)；

}

でオブジェクトを確認すると、当然 key1 はある。添え字とか、オブジェクトとか、値の取出しとか、グーグル様にすがった…これもevalの書式と同じことだった。基本部分をちゃんと読め、だ。おれ。

obj[key]

とやればいいだけだった。上記以外にも、セミコロンを最後に忘れてたり、JSONの中のダブルクォートをどうしようかとか（結局わからず、JSONのデータ中で使われてるダブルクォートはシングルクォートにした）

ほとんど半日潰れたようなもんだぞ、ううう。

とりあえず。これが解決したので、創作文芸見本誌会場HappyReading のスマホ版リニューアルに向けて立ち読み動作の目途が立った、かな。

ここんとこ同じことばかり言ってアレだけど。jquery mobile は文句のつけようのないデザインフレームワーク。ネーム、絵コンテ、下書きまでやったら、残りのペン入れ、仕上げをやってくれるのだ。でもさすがに、それにはお約束事があって、jquery mobile のお作法では、リンクでページの読み込みや、ajaxの挙動にクセがある。

テキトーにページを読み込んだりajaxでコンテナを書き換えたりできるんだけど、それをしちゃうと、デザインフレームワークを生かせない。jquery mobileが提供してくれているデザインは、スマホに特化したもので、それはスマホの特性、画面、UIを考えて作られたデザインだ。考えらえたデザインを捨ててまで、自前のオリジナルjavascriptを組み込むのは愚の骨頂。デザインとjavascriptと、どちらのコストが高いか、比べるまでもない。

てことで、今、ajaxでいちいちページごとにサーバーに来て取得していた立ち読みテキストを、JSONで一度に取得してあとは、javascriptで document.write するだけ、に変更中。iphoneのヒラギノで見る縦書きにぞっこん、なので、モチベーションは高いのでありました。

創作文芸見本誌会場HappyReadingをはじめとして、わたしの作って公開しているサイトのあちこちに、文章を縦書き表示するページがある。いや、やっぱり小説は縦書きじゃなきゃ困る、昭和なもんで。

ブラウザでいえば、IEが以前から独自拡張で縦書き表示ができていた。

2010年ぐらいから、amazon の kindleがくる、すわ黒船来襲か！？というの踊らされ、あちこち見て回ってると、今なお、epub 、電子書籍のための規格決めで紆余曲折中らしい。少子高齢化じゃないけど、「日本語圏」って、世界的にはマイノリティになるんだろうな。

てのはともかく。

今日時点、ざっと検索したところ、webkit系のブラウザは writing-mode を実装していて、日本語の右から左へ流れる縦書きとか、アラブの右から左に流れる横書きなどに対応している（safariとかchromeですね）

わたしのサイトの縦書きは無理やり。幅1emのブロック要素にテキストを流しこんで、それをfloatで右から並べてる。ハイフンやかぎかっこなどは回転させて、句読点は位置を調整している、んだけど、しょせん横書きのフォントを縦に並べてるだけなので、フォントの環境によっては（プロポーショナルフォントなどで表示されてしまうと）全体がふにゃふにゃ波打つし、調整しきれない句読点なんかがハミ出していて、よろしくない。

で、safariで以下のスタイルシートを試したところ

font-family:"HiraMinProN-W3"， "@ＭＳ 明朝"， serif， sans-serif；
direction:ltr；
unicode-bidi:bidi-override；
-webkit-writing-mode:vertical-rl；
writing-mode:vertical-rl；

きれいな縦書き表示。縦書きフォントを使ってるので、妙な歪みもないし、iphoneで見ると、ヒラギノ明朝はきれいだし。

ブラウザの対応状況が微妙なので、PC版のサイトでこの表示は難しいけど、スマホ版なら問題なさそう。こっそりスマホ版で試してみる、かな。

右側が今やってる無理やり縦書き、左側がsafariによる縦書き。ガタつきなど、その差は見てわかると思う。

いや、本当に。先日も同じことを書いたんだけど、jquery mobileを使えば、ほとんど何も考えることなくスマホ対応できる。スマホアプリと見た目も変わらないんじゃないか、これ。

フレームワークというと、phpだとcakePHPとかsymphonyとか、perlもCatalystとか、定評のあるフレームワークがあって webアプリ開発のコスト軽減になっている。という話。たしかに規則・お作法さえ理解して、その通りにスクリプトを書いていけば、あえて書かなくてもいいことがたくさんあるっぽい。ひとつのことを決めて書けば、それに付随するもろもろまで書いたことになる。

で、この jquery.mobileだ。

先日ちょっと触っただけで、踏み込んだことは言えないんだけど、自作のブログ（http://t2aki.doncha.net/mobile.pl）とお言葉データベース（http://t2aki.doncha.net/mobile_books.pl）をスマホへの移植に使ったレベルで言うと。

これはデザイナーのかわりをしてくれる、デザインのフレームワーク。

わたしは、データをごそごそ加工したり引っ張り出したりする部分に関しては、好きだし面白くて、データをあれこれいじってる時は時間を忘れてやってる、いわばデータヲタク。さらに、シムシティじゃないけど、使う側のことを考えて、サイトの動線やUIを考えて想像するのも楽しい。

サイトを作っていてうんざりするのが、そこから先。

ボタンが1pxズレてる？んなぐらい、いいじゃん。

アイコンがジャギってる？んなの気にしないって。

どうしてロゴの位置はここなの？なんとなくだ。

というのは、まるでダメ。

デザインの神さまは細部に宿るし、デザインはいちいちちゃんと説明できる理屈がある。データとかサイトの動線などとは別のレイヤー・別次元。そこんとこ、苦手なんだよねえ。

漫画でいうと、データを用意する・サイトの動線などの骨格・設計を決めるところは、絵コンテ、下書き。これでは完成してないし、読者は見向きもしてくれない。ここから先、デザインワーク＝ペン入れ、仕上げがあって初めて希求力のあるサイトになる。

同じ情報を画面上に表示しても、1pxにこだわったサイトと、そこがぬるいサイト（たとえば、ページを移動したら1pxだかで画面が揺れるとか）では、「ぱっと見」の印象が違う。この「ぱっと見」は大事で、WEBを見ていて、そのサイトを「読む」に値するかどうかを判断するのは「ぱっと見」（そこまで、こだわるんか、というのは、なにをサイトに要求するのか、てことなので、また別の話。ここでは、そこ、こだわるところだろ、て話）

てことで、jquery.mobileだ。こちらが書いたラフ画を、一気に仕上げまで持って行ってくれるスグレモノで、感謝感動。専属のデザイナーをひとり雇ったようなもの。スクリーンショットのページなんて、わたしはなにもしていない。テキストをセンタリングするために1行～3行ほどcssに書いただけ。これをいちから書いたら、と思うとぞっとする。リストの区切り線とか、ボタンの影とか、テキストの位置とか、こんなのをcssで書けとか言われたら、いらいらしながら一週間がかり。jquery.mobileのおかげで、移植は各々実質1日で、なおかつ、スマホネイティブアプリのような画面のできあがり、となる。

で、javascirpt は、油断してたらすっかり主流でこんなことまでできるのか！？という存在感。クライアント側でなにをやったところで、信用できないし、結局はサーバー側でやるよね、と思ってたわたしが悪かったすまんかった。

html5になると、web storageとか。javascript がデータベースまで手に入れてるらしい。すごく今さらだけど、javascriptも勉強しなきゃいけないんだなあ。うううむ。