この前新しく借りたKagoya Cloud。今日このサーバでnslookupコマンドを実行しようとしたら、やっぱりここでもインストールされていなかった。もはやnslookupなんて時代遅れでdigなのかね、と思って調べたらdigもnslookupもbind-utilsパッケージに含まれてるんじゃん。
「パッケージ全部入り」とかでインストールすれば当然入るんだろうけど、そういうことは常識的に考えてやらないので、普通にインストール（どういうパッケージ構成なのかは知らないけれど）すると、CentOSでは、5系から6系になって、bind-utilsはインストールされない方向になったのかなー。
タイトルは当たり前なことを言っているだけだが、ウェブでも適用できるっていうメモ。
最近はJavaScriptでアプリケーションを作ることが多いのだけれど、データ処理をサーバサイドでせずクライアントサイドで実行させたほうがいい場合もあるよね、と思っている。重い処理をサーバで実行すると仮定して、リクエストが増加するとすぐにサーバの応答速度が劣化しそうだ。例えば、利用者が増えた場合もそうだし、ちょっとした操作でサーバと通信してその都度サーバ側で処理をさせる場合などがある。
これを一切やめて初回アクセス時に、データを全てダウンロードさせJavaScriptでまかなっちゃうほうがサーバへの負荷が少ないなぁ、と思い始めた。しかしその際、一旦データを全てダウンロードさせるわけだから、当然データ量が大きくなってしまう。つまり初回アクセス時の応答速度に難が生じるわけだ。
で、やってみたこと。データはJavaScriptのJSON形式でサーバからブラウザに送出するわけだが、このときJSONデータ（ファイル）をzip圧縮して渡してしまう。JSONデータは単なるテキストデータだから、うまくすれば転送するデータ量が10分の1くらになる。ただし単にzip圧縮して、それをコールしてもブラウザはそのデータを解釈することができないからエラーになっちゃう。そこで.htaccessで一工夫。
AddEncoding x-gzip jgz
zip圧縮したデータ（ファイル）は、とりあえず拡張子jgzとつけておいて、エンコーディング指定をしてやる。たったこれだけで、ブラウザは自分で適切に解凍し、解凍したデータをJSONとして扱ってくれる。すごく便利。
おそらく他にも適用できるんじゃないかと思う。cssとか画像とか。また暇があったら試して見ることにする。
安価なSSLでも十分事足りるということで、最近はもっぱらラピッドSSLを利用している（代理店はwww.sslbox.jp）。今日キーとCSRを作成して申請しようとしたところ、変なエラーが出てその先に勧めなかった。
CSRのコモンネーム「 UTF8STRING」と入力されたコモンネーム「********」が異なります。
意味不明。そもそもCSR作成時にコモンネームで「UTF8STRING」なんて入力するわけ無いじゃん。運営元のネットオウルがミスしたんじゃないの、とか思いつつ、急いでいたのでお問い合せフォームからサポートに連絡した。今までと違うことはOSがCentOS5系から6系に変わったこと。ひょっとしてそれが何らかの影響を及ぼしているのかもしれないということで、いちおう検索をかけてみたらひっかかってきましたよ、奥さん。
/etc/pki/tls/openssl.cnf
上記ファイルにある以下の記述変更で対応できた。
#string_mask = utf8only
string_mask = nombstr
「nombstr」って要は「マルチバイト文字列はありません」 ってことですかね。この変更をしてその後、キーとCSRを再作成して無事申請することができた。
これは、CentOS6の問題かね、それともCentOS6のデフォルト状態で作成したCSRに対応できていないネットオウルの問題かね。そういうのを知る意味でも、次回は他の代理店でSSL申請してみようかな。
Macでファイルを圧縮する際、ファイル上で右クリックすると「”○○を圧縮”」というメニューがあり、それを選択するとzipで圧縮される（という理解をしている）。
で、MacOSは現在Unix系OSであるから、コマンドプロンプトを表示させてそこでgzipコマンドを発行しても同様に圧縮してくれる。
「どっちにしてもzip圧縮でしょ」とか思ったらどうも別物ができるようだ。あるファイルを両方の方法で圧縮すると、微妙に圧縮後のサイズが異る。テキストファイルで開くと、その中身も違うようだ。
重たいjsonデータを圧縮してやり取りしようと思い、右クリックからファイルを圧縮して使おうとしたけどどうしてもうまくいかなくて、それでたまたま「手動でやったらどうなるんだろ」とか思ってやってみたらこちらではうまくいったので気がついた。
今、忙しいので詳細は調べないけれど、Macで右クリックからの圧縮を実行する場合でトラブルが起こったら気にしてもいいかもしれない。
仕事の関係でGoogle Mapsとは似て非なるOpenLayersを真面目に勉強することにする。
まず座標についてだが、そもそも座標系というものについてよくわかっていない（メルカトル図法とか正距方位図法とか）。大学の時に授業を受けたが、こういう部分は理屈の部分になるわけで、それは偉い先生方が考えればいい部分だと思っていた。位置は緯度経度がわかればそれで十分と思っていた。
企業に勤めた時、日本地図が国家座標系で位置をXYで表すとか、海上での船位測量に電波測位装置トライスポンダーを使うとか、時代が移り変わってGPSを使うとか、その段になってWGS84とか・・・。
企業をやめた今も、地図には関わらないけなかったが、基本的にGoogle Mapsオンリーだったのでやっぱり緯度経度で済んでいた。そしてOpenLayers。偉い先生方とのお約束があって使わなくてはいけない。そして「大学の時に真面目にやっときゃよかったな」とまたしても痛感する今日この頃である。
で、本題。OpenLayers。
当たり前だが、画面に地図を表示するということは、もともと球である地球を紙の上に展開するわけだから緯度経度じゃ都合悪いでしょ、ってことかな。OpenLayersではEPSG:900913という座標系を主に使うらしい。そもそもEPSG:900913自体がおまじないのようでとても嫌いなのだが、これはすなわちGoogle Mapsと同じ、ということのようだ（てことはこれがメルカトルかな）。
別にメルカトル図法で緯度経度でいいじゃん、と思うけどそれはダメらしい。緯度経度は球面での位置を表現するための手法だから平面用の手法に置き換えてから使ってくれということか。
じゃぁ、緯度経度っていったいなんだよ、となるがこれはEPSG:4326の位置表現手法、と理解してよさそう。EPSG:4326はGoogle Earthと同じのようだ。乱暴に言えば、球ならEPSG:4326、平面ならEPSG:900913、ということか。
だからOpenLayersで緯度経度を使うには、OpenLayers.LonLat()という如何にも、なメソッドがあるが、単にそれを使うだけではダメで毎回変換してやらないといけないということになる。
new OpenLayers.LonLat( 135, 35 ).transform( new OpenLayers.Projection(‘EPSG:4326′), new OpenLayers.Projection(‘EPSG:900913′) )
たかだかこれだけのことで・・・疲れる。