という事で、震災直後から約３ヶ月にわたり中継を行ってきたガイガーカウンターin柏ですが、事務所移転を機に、終了とさせていただき、新たな生かし方として期間限定無料レンタルをする事にしました。無料といっても「Amazonの被災地ほしい物リストに何かを送る」事を条件とします。金額は問いません。100円でも200円でもOKです。「一つのガイガーカウンターが、少しでも被災地の直接支援に繋がれば」と願う次第です。

詳しくは http://syun.jp/geiger_counter/rental/

なお、この３ヶ月間の中継エピソードです。

• 地震発生の夜、原発が危ないという噂からガイガーカウンターを注文。まだこの時は、RADEX1503も正常価格で2万円前後。
• 首都圏で放射線が検知された3/15の午前中に届きました
• この届いた時、オフィス内の放射線量は0.05μSv/hでまだ平和でした。
• 昼を過ぎたあたりで、聞きなれない「ピピッ！ピッ！」というキーボードのクリック音のような音が聞こえました。なんだろうと思っていると、気づけばガイガーカウンターの値が室内で0.8になっていました。窓の外に出して見ると1.5以上。
• 夕方ぐらいから落ち着き始め、翌日16日には0.1台へ。これはまずいと3/16からUstreamで中継を開始。
• 3/21の朝、雨と共に再びアラームがなり始めました。この時の雨雲が放射性プルームだったことを後から知りました。
• この日を境に室内で0.2前後。外は0.3～0.4前後。
• 雨が多い日をきっかけにすこしは下がるがそれほど変わらず
• 以下、中継中の噂
  • ある日、Ustreamの中継プログラムがスタックした際、ネット上で「政府の圧力でやめさせられた」との噂
  • 市役所に問い詰めた人が、当サイトを紹介されたという噂
  • 事務所移転は放射能から逃げるためという噂
  • etc
• あとは、同じビルの八百屋さんのPCの画面に常時表示されていた事があとから判ったり、知り合いが弊社でやっていることに気づかず見ていたり、昔の友人から突然連絡があったり、TV局から取材のTELがあったり、といろんなことがありました。(^^
• 最終的にはUstreamは3ヶ月で68万pvでした

メインの仕事が忙しすぎてなかなか進まないのですが、ようやくあらゆる環境から柏市に設置した私設ガイガーカウンターの値を閲覧できるようにしました。

http://syun.jp/geiger_counter/

Ustreamの画面を１分に１回キャプチャして、OpenCVでカウンター部分を切り出しています。
もしかすると、切り出しが失敗することがあるかもしれません。(^^;
予め御了承願います。

なお、Androidアプリはwosagを使って作ってみました。

「遅すぎたんだ・・・腐ってやがる」って感じになってしまいましたが、いまさらながら公開をさせて頂きます。(^^;

ターゲットは、コンテンツホルダー向けのサービスになりますが、ブラウザでぽちぽちするだけで、スマートフォンアプリを自動生成できるサービスです。
ぶっちゃけ、Android端末だけでアプリが作れます。

というとすごそうですが、作れるのはRSSリーダーかWebサイトを開くだけのアプリです。(^^;
去年しらべた時は、Google App Inventorではこのパターンが作れず、隙間としてはありだと思っていたのですが、
先日出たFlash Builder 4.5では作れそうです。（未テスト）

また、思想としては、一度の操作で全てのスマートフォンのアプリが作れる予定だったのですが、iPhoneが微妙にヘマったままの公開となっています。すいません。。。

突っ込み処やバグが満載の状況ですが、取り急ぎオープンとさせていただきます。

サイト： http://wosag.com/

■データセンターの状況

データセンターは特に被害はありませんでした。また、計画停電の影響ですが、発電機も完備しておりますので、さしあたっては影響は御座いません。

■弊社の被害状況

オフィスはかなりの物が壊れましたが、スタッフ一同、無事でした。柏オフィスについても、発電機の導入やリモートメンテナンス環境の充実をはかることにより、停電が起こっても業務に影響をきたさない環境を構築する事が出来ました。

■震災に対する弊社の取り組み

社内で保有していたマスク等の物資を現地に送りました。

また、柏オフィス内の、放射線量のUstreamを行っております。安物の装置＆室内窓際なので、どこまで正確かは不明ですが、近隣住民の方々のお役にたてればと思っております。

■fsckが途中で10分間停止

客先でlinuxサーバを再起動したところ、180日を経過していた(tune2fsでoffにしていなかった）ので起動時にfsckが走りました。このfsckが29.8%のところでピタっと止まってしまいました。
左脇の「／」がくるくる回るアニメーションも停止したままです。サーバのdisk　i/oのランプはつきっぱなしでした。10分まっても状況が変わらず予定作業時間をオーバーしてしまったので、リセット＆fastbootでfsckスキップでサービス再開せざるおえませんでした。ただ、/var/log/messageにもEXT3　Error等は待ったく出ません。
後日、スタンバイサーバへの切替を行い、落ち着いてfsckをかけたところ、やはり同じ29.8%でピタッと止まったのですが、待つこと15分。正常に動き出しました。ちなみにbadblocksでも何も出ませんでした。

教訓：「fsckのアニメーションが10分ぐらい止まってもdisk i/oがあるうちは信じて待つべし」

■日曜日にサーバが過負荷になる

毎週、日曜日、処理が微妙に遅延するという連絡がありました。調査すると確かにロードアベレージが高い。よくよく見ると99-raidなるプロセスがcron.weeklyで起動されていました。
これは、software RAIDのチェックプログラムで、昔は無く、CentOS5の途中からmdadmのパッケージ内で供給されるようになったようです。
このサーバは、2TBのハードディスクをSoftware RAID1していたため、チェックプログラムが半日近く走っていました。ただ、実際には0.1TBぐらいしか使っていないのが現状でした。

教訓：「ハードディスクが大容量になったとは言え、使いもしない容量のパーティションは切らないほうが良い。」

■apacheのリバースプロキシのリクエストが切れる

apacheのリバースプロキシを運用しているサーバで、「時々真っ白の画面になる」との連絡。apacheのログにはエラー無し。tcpdumpをすると、apacheまでパケットは来ているのに、裏の実サーバには届かない。結局原因は、リバースプロキシの設定を外部のシステムから制御できる仕組みがありこの仕組みで/etc/init.d/httpd reloadを使っていた。よくよく調査すると、apachectlのreloadは、セッションは保持されるが、/etc/init.d/httpd のreloadはセッションは保持されないrestartと同じである事が判明しました。

教訓：「/etc/init.d/httpd reload は使ってはいけない」

■SSDなのに異常に遅い

近年、SSDの恩恵に預かることが非常に多くなったのですが、あるときSSDに換装すると逆に遅くなる現象に出くわしました。ベンチマークを取ると数MB/sぐらいしか出ない始末。認識もなぜか /dev/hda1。対策としては、grub.conf のkernelパラメータにhda=noprobe hda=noneで、/dev/sda1として認識されるようになり、ベンチマークも100MB/sを超えるようになりました。

■vistaとwindows7だけインターネットに出れない

あるお客さんの環境で、ある日突然、vistaとwindows7だけがインターネットに出れない現象が発生しました。そのフロアには、Mac,XP,Vista,Windows7と4種類のOSがあったのですが、MacとXPだけは全く問題がありせんでした。wiresharkを使ってパケットを解析すると、ルータまでpingのICMPのパケットは来るのですが、ルータがなぜか応答パケットを返せない始末。結局は、BuffaloのDWR-PGがクレードル経由でネットワーク上に接続されていたのが原因でした。DWR-PGはクレードルでLANに接続するとルータとして機能するようになり、この時のIPが既存のルータとぶつかっていたようです。通常同じネットワーク内であれば、pingを打つとIPがぶつかっている場合は、duplicateとワーニングが出るはずなのですが、この時は、HUBのせいかこのワーニングが出なかったため、気づくことが出来ませんでした。

教訓：「pingの応答パケット来ているのにackがない場合はルーティングだけでなく同一IPの機器がネットワーク上にいないが調べるべし」

IT系の仕事にむいているかどうかは、トラブル解決を楽しめる性格（≒マゾ?）かどうかだと思っています。自分は比較的むいているほうだと思うのですが、さすがにこれだけ続くと・・・くたびれました。(^^ゞ

• 机上論や流行でシステムを複雑にしない
• メーカー固有仕様のハードは使わない
• 出来る限り枯れた技術を使う

という設計ポリシーがあります。
そのため、ほとんどの場合、RAIDについては、メーカー固有のハードウエアを使わず、Linux の Software RAIDで済ませるようにしています。
SSD+Linux Software RAIDという構成がどこまで有効なのか？以下、ベンチマーク結果です。

■システム構成

• CPU Intel(R) Core(TM) i7 920  2.67GHz
• SSD　Intel  SLC 64G ( X25-E Extreme SATA SSD SSDSA2SH064G1 )

■ベンチマーク方法

• シーケンシャルライト   dd if=/dev/zero of=test oflag=direct bs=100M count=10
• シーケンシャルリード   dd if=test of=/dev/null iflag=direct bs=100M count=10

■測定結果

• RAID無し （SSD 64G ×1 = 64G)
  • シーケンシャルライト  125MB/s
  • シーケンシャルリード  187MB/s

• Software RAID1　（SSD 64G ×2 = 64G)
  • シーケンシャルライト  121MB/s
  • シーケンシャルリード 170MB/s

• Software RAID0　（SSD 64G ×2 = 128G)
  • シーケンシャルライト  68.6MB/s
  • シーケンシャルリード 400MB/s

リードがほとんどのシステムには有効ですが、書込みの多いシステムについては、Software RAID0は逆に遅くなるようです。

あと、当然、Software RAIDなので、マルチスレッドでCPUに負荷をかけるプログラムが稼動する場合は、影響を受ける事になります。

新聞業界という複雑な体質の中、フル実装にこぎ着けられた裏方が非常に気になるところです。
また、電子版オンリーの金額設定が4000円という金額から、電子版オンリーでも購読者の地域の販売店にバックされるロジックがあるのでしょうか？
一般紙ではなく、セグメント化されたコンテンツホルダーならではなのですが、是非ビジネスモデルとして成功して欲しいと思う次第です。

気になるのは、iPadやiPhone Safariでの閲覧がどの程度の操作感になるかですね。

あとは、購読者の地域のチラシも一緒に読めるビジネスモデルは、広告集める販売店側も購読者もWelcomeな気がするのですがどうなんでしょうか？

少なくとも、ここからの１０年間。
私たちは、従来の紙の時代から変わりゆく歴史的転換点の目撃者になるのは間違いないなさそうです。

先日、iPhoneアプリからアダルトっぽいものはすべて削除されたそうです。
嘘かほんとかはわかりませんが、iPadに教科書をすべて入れて、子どもたちに配布するのが視野にあるからだという噂も。個人的には、ちょっと暴走気味な気もしますが、１０年後、子どもたちの重いランドセルが軽く小さくなる日が来るのかもしれません。

• 自分のアカウントが設定されて出荷。開封して、wifiの設定や3Gの契約は全く不要で、いきなり日本でもネットワークにどこでもつながるのはビックリ! パスワードもなにもなく、いきなり本が買えるのにもビックリ（危ない。。。）
• 田舎でも3Gマークが点灯せずにネットワーク出来ている時が多い。いったい何処と接続しているのか？
• ページ送りが遅い。ページ送り時の電子ペーパー固有の画面のフラッシュする感じが、なかなか慣れない
• Amazonの売上がキンドル:紙=10:6って本当？
• 電子書籍でおしまいにする将来を確実に感じる事が出来るが、世間で騒いでいる程、急速にはいかない気がする。
• 加速要素は、やっぱり学生による「マンガ」「アダルト」「ファイル交換」。
• 同じレベルの値段なら、サクサク＆カラーのiPadに明らかに軍配。重さやバッテリーの持ちはあまり問題ではない。
• キンドル for iPadのリリースはAmazonにとっては必須。