阪神淡路大震災と呼ばれるようになる大地震、兵庫県南部地震。

幸いにも家族の中には人的被害は無かったのだが、意識がはっきりするにつれて恐怖を感じた覚えがある。

20インチ後半のブラウン管TVが両親の近くに落下し、その上に大きなタンスが倒れこむ。運良くテレビとタンスの間になり怪我も無かった両親の寝室や、兄弟同部屋にあった小さなタンスが倒れてガラスが散乱していたり、外壁の一部が床と離れて数センチの隙間があき、3階から地面を見える形になっていたり。

タンスとテレビを戻してつけたTVには横倒しになった高速道路の映像が流され、次々と死傷者の数が増えて行くのを目の当たりにした。

当時通っていた学校での被害者は一人と、神戸市灘区などの被害が大きかった地域に比べればマシという状況ではあったが、同じ学年の子が亡くなったというのも衝撃だった。特に仲が良いという訳でもなかったが、記憶に残っている。

その後、ライフラインの復旧の目処も立たず、震災後の対応で忙しい父親を残して母親の実家へと避難をしていた。

一時転校という形で避難先の小学校にお世話になりつつ数ヶ月の間の避難の後に西宮に戻ったが、ライフラインは復旧しつつもあちこちに爪痕が残る状態だった。

その後は大きな地震も無く、徐々にではあったが街並みが変わっていく様子を見ながら生活を送っていった。

そして去年あたりに完全復興の宣言が出されて一区切りがついた所である。

この経験があるからか、毎年1月17日頃には体調を崩してしまう。昨年までは「あぁ、そろそろ17日か」という意識もあるせいで体調を崩しているのかと考えていたが、今年に限っては東日本大震災の記憶が新しく失念していた。

しかし、例年のように体調を崩してしまった。記憶が薄くとも身体は覚えているということだろうか。

2007年。Twitterを知って始めたころ、ちょうど地震の研究を行う研究所に派遣で働いていた(事業仕分けで働いていた場所が本家に統合されて無くなってしまったのが少しばかり悲しい所)。

そこではまだ緊急地震速報が一般運用が本格的にされる前だったが、一台のモニタに日本地図が描かれており、そこに地震発生時に震源が表示されていた。それに感化されたと共にTwitterの速報性やAPIに可能性を見た私はearthquake_jpの開発を始めた。

これも元々被災者という事と、その際に情報がTV・ラジオのみしか情報源がない事に不安を感じていたからであって、この経験が無ければearthquake_jpを作っていなかったかもしれない。

そして東日本大震災をきっかけに自宅にシステムを置いておくことに不安を感じ、外部のサーバに配置するようにした。これは東海地震が発生し、被災した場合の事を考えての事ですね。

これから先もできる限り続けていきたいと思う、今日この頃でした。

MS UIゴシック

MS 明朝

メイリオ

MS～系フォントだと崩れる感じ。
とりあえず見れるようにするためにChrome Stylistで全サイトにユーザCSSを適応させてリセットすることによって対応できた。

* { font-family:sans-serif !important; } pre,code,kbd,samp,tt { font-family:monospace !important; } 

もちろん、ブラウザのフォント設定はMSゴシック系以外で。
これで暫定的にフォント描画崩れが無い状態で見ることができる。

Chromeがちゃんとしてくれれば一番良いんですけどね。

追記

Issueを確認しているとCJKフォントで発生しているようで、次回のDev channel更新では修正されているかもしれません。

Issue 98155 – chromium – Bad rendering of CJK characters

しかし、本日（2011/08/31）になっても公式RTで予測情報を流していたので思わずカッとなって書くことにした。

※自分は地震の専門家でもないし気象庁等の政府機関などと関係はありません。2007年から地震情報を流していただけの人です※

まずは大元のツイート。

英語に堪能ではないが、軽く意訳すると「日本の地震に注意。8月28日～31日の間、仙台、福島地方でマグニチュード5.5～6.5の地震が発生する可能性が高い」となる。
海外には震度という基準がないため、おそらくマグニチュード（気象庁マグニチュードではなく、モーメントマグニチュード）だとは思っている。

この情報の元はQukake Predictionという海外サイトで、地震の予測を行うサイトのようです。
しかしながら、NOTEとして「I am not associated with the USGS earthquake prediction site」と書かれています。これは「当地震予測サイトはUSGS(U.S. Geological Surve : 米地質調査所)とは一切の関係はない」と訳せるかと思う。

USGSはドメイン名を見てもusgs.govとなっており、(.govはアメリカの政府機関や関連組織用のドメインに使用できる）信頼のおけるサイトです。
個人的にはUSGSと関係が無い時点で情報源としては信頼度が乏しいものとして判断している。

問題の@eq_tokyoの投稿になると下記のようになっていた。

なぜか震度に変わっている。この時点でまったく信頼するつもりはないが、知らない人だと反応してしまうかもしれない。
これが個人のアカウントであれば、「また予測してるわ」ぐらいでスルーしていますが、緊急地震速報を流している個人制作のbotアカウントで言っていたので問題と感じましたね。@earthquake_jpも個人制作の地震botアカウントですので。

さて、この予測は間違いなのでしょうか？と聞かれると「可能性が低い」と明確ではない答えをせざるを得ません。
というのも地震予知に関しては難しいところで、明確に「揺れる」「揺れない」を出すのは現在の技術では言えないのです。

東海地震については例外的に気象庁が情報を提供する準備がありますが（東海地震関連情報）、Q&Aでも「必ず予知できるとは言えない」という返答を行っています。(東海地震は必ず予知できるのでしょうか？ : 気象庁)
地殻の動きと過去の前例などを踏まえてある程度、大まかな予測はできても、基本的には発表するほどの精度ではないのかと思っています。

3/11以降、しばらくの間は気象庁も大きな余震の可能性を情報を提供していましたが、確率が～%という表現でなされており、必ず発生すると言ったことはありません。
今回の情報も気象庁の発言から出たものであればわざわざ反応はしませんでしたが、研究機関等じゃない所の発言をソースとして予測ツイートしてるのは放っておけなかった。

上記のような理由で個人的にはTwitter上に流れている地震予測は明言していない限りデマとまでは言わないが信頼性が低いと考えています。
今回の@earthquake_jpの発言で”デマ”という文字を入れなかったのはあくまで発言が「予測」「可能性が高くなっています」となっている為であり、完全にウソというわけではないからですね。

そのような情報でいちいち反応して騒ぐよりも、普段から地震の対策をしておいた方がよいかと思いますよ。

・・・自分は東海地震がどうのこうの言われる地域ですがこの前やっと避難用品を購入した体たらくですが。

そこで対応ブラウザの場合はリソースファイルをgz圧縮して転送するように設定する方法を備考録として書いておきます。

参考サイト

• 亜細亜ノ蛾 – Weblog – prototype.jsをgzip圧縮して利用するテスト（Safari 対応版）
• Schuzak’s Blog – Webサイトの.htaccessをいじってGZIP圧縮を使う
• C/pHeR Memo – Java とか。Eclipse とか。 – [Web]サイト高速化のための JavaScript と CSS 圧縮スクリプト

前提

転送数を減らす為にCSSとかJavaScriptとかで1ファイルにまとめられるものはまとめておく。

それに加えて圧縮をかける事により転送するデータ量を減らします。

また、gz圧縮できるアーカイバが必要。

ファイルの圧縮

まずは対象のファイルをgz圧縮します。

gz圧縮は1ファイルしか圧縮できない形式なので、まず、CSSやJavaScriptファイルを1つにまとめておきます。

別にまとめなくともこの手法は有効ですが、転送数が多いままになってしまうことと、読み込み方法によってはシリアルで読み込んでしまうのでまとめておく方が早いです。

まとめたファイルをgz圧縮します。自分の場合、windowsではExplzh、mac/linuxの場合はgzip -c [ファイル名] > [ファイル名].gzを使用しています。

.htaccessの作成

gzファイルが存在する場合はgzファイルを読み込むように設定をします。

最近は使えるサーバが多くなっていますが、mod_rewriteがサーバに入っていないと使えません。

<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{HTTP:Accept-Encoding} gzip
    RewriteCond %{REQUEST_FILENAME} !.gz$
    RewriteCond %{REQUEST_FILENAME}.gz -s
    RewriteRule .+ %{REQUEST_URI}.gz

    <FilesMatch ".html.gz$">
        ForceType text/html
        AddEncoding x-gzip .gz
    </FilesMatch>

    <FilesMatch ".txt.gz$">
        ForceType text/plain
        AddEncoding x-gzip .gz
    </FilesMatch>

    <FilesMatch ".js.gz$">
        ForceType application/x-javascript
        AddEncoding x-gzip .gz
    </FilesMatch>

    <FilesMatch ".css.gz$">
        ForceType text/css
        AddEncoding x-gzip .gz
    </FilesMatch>
</IfModule>

まず、mod_rewriteでgzファイルが存在する場合にはアクセスされたファイル名.gzを読み込むように切り替えています。

そして、FileMatchでファイル毎にMIME-TYPEとgzエンコードを指定しています。

これによってgz圧縮ファイルに対応しているブラウザの場合はgzファイルを読み込めるようになります。

更に高速化

これだけでファイルのサイズが下がりますが、キャッシュで持たせるようにしておきます。

これも.htaccessに記述する事によって利用可能です。

ExpiresActive on
ExpiresDefault "access plus 1 month"
FileETag None

実行したらGrowlに開始通知。

Phingでlintとユニットテストを走らせるように書いておく。
さっきのバッチファイルはphingを実行するようにしてる。

監視対象のファイルを更新して保存すると裏でphingコマンドを実行して、テストとlintを実行している。
そのログがGrowlに出力されている図。

ある程度まとまれば公開するつもりだけど、仕事が忙しくてリリース物作るほどの余裕がない罠。

とりあえず今の時点ではヘッダ部分のみ完了

新ドメインではメールアドレスの管理とサイトの管理に使っていきます。なのでその内「Avenie Puffer Trackback Center」も移動させます。
移動させるとしたら「http://avenie.transrain.net/」になるかと思います。
ほら、たまに落ちてる事あるじゃない？

今までのariela.jpは自宅サーバに置いていたので、様々な要因でアクセスしづらい事があったり、メールサーバが色々制限かけられたりした事によって引越を決意しました。

実際には急がなくてもよかったのですが、リアルでも引越の予定がありますのでさっさと移行しておけば、リアルでの引越があってもそのまま使い続けられる事もあって、新しいドメインで再スタートをかける事にしました。

まぁ、のそのそと書いていく次第です。