夢とガラクタの集積場

どうやら、日本政府が福島原発事故のINESレベルを7に引き上げたそうで。

http://www.news24.jp/articles/2011/04/12/10180777.html

チェルノブイリレベルの事象になったということで、
一度チェルノブイリについてまとめて、マインドマップとしてまとめました。
・・・ハイ、嘘です。
状況と発表されている放射性物質の放出量から見てレベル７に達するかも、と見て
予めまとめておいたものです。

なんかいやな予感がしていたんですが、まさか現実となるとはなぁ。
ホントはこんなまとめ出さんで済むように終わってくれればよかったんだけど。。。。

尚、情報のベースは下記のドキュメンタリーより。

－チェルノブイリ原発事故・終わりなき人体汚染　→　1996年（事故10年後）NHKドキュメンタリー
－汚された大地で ～チェルノブイリ 20年後の真実～　→　2006年（事故20年後）NHKスペシャル

てか、チェルノブイリ事故発生時の幼い子供って私と同年代やん。
全く他人事とは思えない。。。。

てなわけで、「２．エネルギー戦略を見直す。」について書いていきます。
ようやくですが。

ちなみに電力の不足について書かれた記事はよりわかりやすいとこを見つけました。
＃以後、本ブログでも電力の現状を示す際には下記のブログの引用をさせていただきます。

東京電力の計画停電を考える
http://ameblo.jp/kazue-fujiwara/entry-10835236187.html

上記ブログ管理人のkazuさんはサマータイムで節電という１つの結論を出しています。
人／電力消費の『場所的な避難』ではなく、『時間的な避難』という形での対処とするものですね。

とはいえ、一応この一連の記事の目的は「２．エネルギー戦略を見直す。」について
今わかっていることを書いて、まとめておこうという目的のため、
エネルギー戦略に対する感想や考えみたいなものを書いていきます。

まず最初にそもそも発電の手段ってどんなのがあるか、を列挙します。
結果は下記の通り。

１．火力発電：燃料の持つ化学エネルギーを燃焼により熱に変換し、さらに運動エネルギーに変換する発電。
２．原子力発電：核反応により熱エネルギーを得る発電。運動エネルギーへの変換は、通常は蒸気タービンを用いる。
３．水力発電：水の位置エネルギーによる発電。
４．核融合発電：原子核の融合によってエネルギーを得る発電。
５．地熱発電：地熱による発電。
６．太陽熱発電：太陽光の熱エネルギーによる発電。
７．風力発電：風の運動エネルギーによる発電。
８．波力発電：波の運動エネルギーによる発電。
９．潮力発電：潮の干満の位置エネルギーによる発電。
１０．炉頂圧発電：高炉の高圧ガスでタービンを回す発電。
１１．冷熱発電：LNGの冷熱を利用し、中間熱媒体を液化、循環させて発電。
１２．海洋温度差発電：海面の温水と深海の冷水の温度差を利用する発電。
１３．人力発電：人間を動力源とする発電。燃料や電池の補給が難しい局面で重宝される。
１４．燃料電池発電：燃料の化学エネルギーを直接電力に変換する発電。部分出力でも発電効率が良い。
１５．太陽光発電：太陽光エネルギーを太陽電池で直接電力に変換する発電。自然エネルギーなので燃料の購入の必要がない。
１６．宇宙太陽光発電：宇宙空間で太陽光発電を行い、それによって得た電力を地上に送る。
１７．MHD発電：ファラデーの法則に基づきプラズマなどを用いて発電する。
１８．熱電発電：温泉水と河川水などの温度差を利用して熱電変換素子により発電する。
１９．振動発電：圧電素子と振動板を組み合わせることにより、音や振動のエネルギーを電気エネルギーに変換する発電。

・・・・なんか、思ったより一杯あるんですね。
まずは分類分けしよう。ただ時間も時間のため、分類分け等は次回以降に。

てなわけでその３。

全く解決策ではなく、『真夏の停電をいかに乗り切るか』についてまずまとめちゃいます。
備忘録としても。

まず、真夏の停電において障害となるのは下記の３つです。
１．照明が無い暗闇
２．猛暑による体力の消耗
３．猛暑による食べ物の急激な痛み

１．照明が無い暗闇

夜は真夏であろうと暗いです。
長期にわたって夜間の停電が続くことを考えると、下記の２条件を満たした照明器具が必要でしょう。
Ａ．LEDを使用している
→　LEDの長寿命は大きいです。使い続けるため、電灯みたいに途中で切れては困る。
Ｂ．充電式か、今持っている充電池で使用することが出来る
→　重要。
おそらく、夏季にも照明器具向けの乾電池は不足するはず。
不足している状況下で数日でワンセットの乾電池を消耗することは出来ない。
なので、Eneloop等の繰り返し使用できる充電池と、
そのサイズの充電池で使用可能な照明器具を入手する必要があります。

Ａ、Ｂを満たす照明だと、充電池が入手しやすい単３電池、単４電池で稼働する
LEDランタンが理想かな？
ただ、今は入手できないので、４月か５月を待ちますか。。。


２．猛暑による体力の消耗
真夏に冷房を使用せずに凌ぐとひたすら体力を消耗します。
なので、少しでも消耗を抑えるためには。。。
何がいいんだろ。
扇風機と、保冷剤を多めに用意しておくくらい、しかないのかな。
後は、水分を頻繁に摂取できるよう確保しておくくらいでしょうか。


３．猛暑による食べ物の急激な痛み
停電の間冷蔵庫も止まります。
ただ、今と違うのは猛暑であるため、３時間であっても冷蔵庫の停止が響きます。
であれば。。。こちらも大きめの保冷剤を用意するか、
ジップロックに水をためて凍らせたものを保冷剤代わりに使用するといった対処が必要となります。



まとめ

夏までに下記のグッズを買い込んでおこう。
今は混乱期だから、物流も一通り回復した４月下旬あたりに。
１．LEDランタン（単３電池、単４電池で使用可能なもの）
２．EneloopかEvolta充電型の充電可能な電池
３．扇風機
４．保冷剤
５．ジップロック

てなわけで続きです。

電力不足が深刻になっていて、
それが急場の発電所の建設だけではどうやら解決しないだろう。
ただ、原子力発電の今後は絶望的だろう、というのが前回までの内容。

今回の地震は間違いなく戦後最大のインパクトを日本に与えた災害でしょう。
被害の大きさだけでなく、日本の社会への影響も。

多分、今のままでは東日本のエネルギー不足は解消しません。
ということは、おそらく取るべき策は下記の２つのうちいずれかではないかなぁ、
と考えています。
１．東電地域にある都市／設備／人口を日本各地に分散させる。
２．エネルギー戦略を見直す。

１．東電地域にある都市／設備／人口を日本各地に分散させる。

電力を使用する存在自体を地方に移動させてしまおう、という解決方法。
ただ、これについては個々の組織が自発的にやるとは思えないため、
多分ごく一部しか実現しないはず。
＃取引先が関東にあるままだと移動できませんしね。

２．エネルギー戦略を見直す。
根本解決につながる可能性ですが、５年１０年単位の時間がかかります。

１は多分実現しない、２は５年１０年かかる。。。
あれ？てことは５年間くらいの夏は今行われている計画停電をはるかに
上回る規模の計画停電が実施され続ける、ということですよね。

本当は２について書きたかったんですが、
まずは真夏の停電を乗り切るために必要なものを列挙しておく必要がありそうです。
ではまずそれをその３に。

てなわけで、思ったことのまとめ開始。

まず前提として、東京電力の発表によると、現状で東電区域において電力が不足しています。

Ａ．３月中旬の総発電能力：3350万KW
Ｂ．３月中旬の総必要電力：4700万KW（節電＋計画停電でＡにあわせている）

Ａについては４月前半までに
検査中だったり、フル稼働していない火力発電所をフル稼働状態に
持っていくことで4000万KWまで供給能力を持っていく予定のようです。

４月になれば暖房はほぼ使用されなくなる関係上、4000万KWあれば
必要な量はほぼ確保できる模様。
なので、４末時点では下記のように重要と供給はつりあいます。

Ｃ．４月末時点の総発電能力：4000万KW
Ｄ．４月末時点の総必要電力：4000万KW

ですが、このページや、このページを見ていると、
夏季に必要となる電力量は6000万KW～6400万KW程にもなる模様。
＃暖房と違って、冷房は電力で行う他ないから、という話なのでしょうか。

東電側も数か月で動作開始可能なガスタービン発電所（出力30万KW級）をいくつか
建設する予定のようですが、それでも4800万KW程までしか行かないようです。

ということは、下記のように最大1600万KWのギャップが出る。
夏の猛暑の中、計画停電突入、ということになってしまうわけです。

E．夏季の総発電能力：4800万KW
F．夏季の総必要電力：6000～6400万KW

かつ、今回の福島原発の事故によって、
今後原子力発電所を新設／修理することは極めて困難な状況になっていると思います。
世論／国際情勢的に。

もしかすると今停止している原発を再開することすら無理かもしれない。

てことは、おそらく上記の1600万KWを
今までとは違う手段を持って埋める必要がありそうです。

そのために何が出来るか、を考えた結果を書いていこうと思います。

東北関東大震災により被害を受けられた皆さんに心よりお見舞い申しあげます。

東北関東大震災では私自身も直接被災地区ではないにしろ、
停電やモノ不足による影響をかなり受けました。

幸い、動くのが早かった＆そもそも１人暮らしであまりモノを必要としない関係上、
生活必需品については困ることはありませんでした。
ただ、おかずのバリエーションは減ってたかな。そのくらいでした。

なんですが、電力不足によって街から明かりが消え、
物流が麻痺している都市を見ていると物思う所がありました。
とまぁ、ただそれはまた違う話題になるので、次の投稿で。

後、いまいち今までのデザインは見にくかったので変更しました。
すっきりして見やすくなったかと思います。

Androidだったり、クラウドだったり、分散システムだったりするののメモ

Androidをデバッグし、メモリダンプからデータを復旧する
http://monoist.atmarkit.co.jp/fembedded/articles/filesys/10/filesys_10a.html

Androidを組み込みボードにインストールして、
Linuxのメモリ管理を見よう、という企画。
自分で何かハードを組むことは無いでしょうけど、こういうのは面白いなぁ。


Java ベースのNo SQL ミドル Apache Cassandra
http://gihyo.jp/dev/serial/01/cassandra/0001

分散ＤＢ／ＦＳがフルにJavaで構築されているのって珍しいなぁ。


Hadoop MapReduceプログラムを解剖する
http://codezine.jp/article/detail/5582

今更といえば今更ですが、Hadoopも。
このへんの概念一度きちんと学んでおく必要がありそう。


Thrift
http://blog.broomie.net/index.cgi?id=38

これも今更といえば今更ですが。

後は、Thrift、ProtocolBuffer、MessagePackって、性能に関しては下記ページみたいに
調査結果があるんだけど、開発コストとしてはどんなものなのかな？
パッと見た感じ、通信スケルトンまで自動生成してくれるThriftがいいように見えるんだけど。。。
http://d.hatena.ne.jp/shot6/20091112/1258002372

分散バージョン管理システム「Mercurial」
http://journal.mycom.co.jp/column/ide/093/index.html

GitでなくてMercurialかぁ。
Google Codeでも使われているし、情報はおっておくべきかな。


Htmlコーディング支援「Zen Coding」
http://journal.mycom.co.jp/column/ide/098/index.html

モック書く時には使えるのかなぁ。

気になったので残しておこう。

これまでERP/CRMとかのソフトウェアって、
商用なソフトウェアばかりかと思っていたんですが、
下記みたいにOSSのソフトウェアも存在するらしいです。これ結構意外。

Adempiere

Compiere

もしかすると、こういったOSSをベースに
後、AdempiereについてはリポジトリでJavaで書かれていることを確認。
これは普通に改造していろんなものに使えるんじゃないかな？

CompiereはCVSリポジトリは見つかったんだけど、
ソースはまだ見えない。。。とりあえず何の言語で書かれているか
どうか、くらいは確認しておこうっと。

追記：
CompiereはJavaベースのようなのですが、
なんか既にリポジトリはほぼ稼働していない状態？
ファイルが見つかりませんでした。
ただ、ソースコード一覧はダウンロードできて、きちんとJavaでした。

通信用のライブラリとして最も気になっているのが、MessagePack。

Google のProtocolBuffersと比べても4倍も高速という辺りが非常に興味深い。

シリアライズの負荷も小さく、サイズも小さいという理想的なライブラリに見えます。
ハード性能、ネットワーク帯域がどんどん大きくなるから
そういったものは必要ないじゃないか、という気もしますが、全然違う。

アプリケーションが通信を行う量の方が其れ以上の速度で増えていますし、
パブリッククラウド上に乗せる場合は計算量、ネットワーク流量が
まんま使用料として跳ね返ってくるわけですし。

なので、今でもこういうのは重要。
てなわけで、調べてみよう、っと。

そろそろ今年も終わり、ということで、来年に調べると面白そうな技術要素を
列挙していく方針で。

今回はSonar。（InfoQ）


何かというと、ソースコード品質管理ツール。

リポジトリに登録されたソースコードに対して解析を行い、
結果をレポート形式で出力するツールです。
ソースコードの量やら、コメント率やら、ソースコードの複雑度やら。

これだけだと他にもあるんですけど、面白そうなのは「アーキテクチャルール」。

＝＝＝
開発者は、異なったパッケージにあるクラス間での参照を認めないパターンベースのルールを
定義することができる。
パターンの例には、*.dao.* クラスから*.web.*へのアクセスを禁止したり、
どのクラスからも java.util.Vector, java.util.Hashtable や java.util.Enumeration へのアクセスを
禁止するものが含まれている。
ソースコードがアーキテクチャ制約のセットに忠実に守れば、
プロジェクトは、アーキテクチャ モデルを遵守することになる。
このルールを使うには、Javaのバイトコード 分析が必要である
＝＝＝

参照をルールとして定義して警告が出せるのは面白い。
これを利用すれば、下記みたいな解析が出来そう。

1. DaoやJDBCドライバ系の参照を禁止することで、WebシステムでAction層からデータベースをレイヤーを無視してアクセスすることを検出
2. 同一パッケージとプロジェクトのcommonパッケージにのみ参照を許すことで、後で他プロジェクトに機能を移行しやすくする
3. スレッドやconcurrent系のパッケージに対する参照を禁止することで、開発者が独自方式でスレッドを起動することを検出

後は、Mavenのレポートも取り込める、となるとおそらく
CheckStyle、FindBugsといった
他の静的解析のツールの結果も統合して表示できるんだろうなぁ。

加えて、カスタムダッシュボードを作れる辺りも面白い。
この辺りは使うだけでなくて、OSSなので実際にソースコードを見てみるかなぁ。。。