ついに東京の水道水にもヨウ素131が混入するようになったそうなので怖くなってリスクをざっくりと計算してみた。
水道水の放射能測定結果について / 第17報 / 平成23年3月23日 / 東京都水道局
金町浄水場: 2011/3/22 9時 I-131 210 Bq/kg
緊急時における食品の放射能測定マニュアル / 平成14年3月 / 厚生労働省医薬局食品保健部監視安全課
I-131(ヨウ化メチル以外の化合物) を幼児が経口摂取した場合の実効線量係数 0.000075 mSv/Bq
ベクレルをシーベルトに換算すると
210Bq/kg * 0.000075mSv/Bq = 0.01575mSv/kg
シーベルト - Wikipedia
これ以上はヤバイかなという値を 100mSv とすると
100mSv / 0.01575mSv/kg = 6,349.2kg (およそ 6t)
一日1L(1kg)水道水を飲んだりすると
6349.2kg / 365日 = 17.39年 で 100mSv に到達
まあ、とりあえずはドキドキしながら暮らすとして、
今後数ヶ月にわたって改善されないと引っ越したくなりますね。
免責条項
- 浄水場から蛇口までの話はわかりません。
- ヨウ素の半減期8日についても考慮してません。
- セシウム134やセシウム137についてはどうなんでしょう。
- 当然ですが、計算間違いの可能性、または仮定の間違いなどあるかと思うので、気になる人は検算してください。
Wednesday, March 23, 2011
Monday, March 7, 2011
use transactional_fixtures with capybara akephalos driver
You may turn on transactional fixtures with Capybara akephalos driver (it may work with selenium driver too) having the monkey-patch below in spec_helper.rb or somewhere else.
akephalos driver を使っている場合でも以下のコードを spec_helper.rb にでも書いておくと transactional_fixtures を有効にできそうです。 (たぶん selenium などでも同様)
ActiveRecord::ConnectionAdapters::ConnectionPool.class_eval do
def current_connection_id
# Thread.current.object_id
Thread.main.object_id
end
end
かなり無茶苦茶な変更なので ActiveRecord を非同期に使うコードがあるとアウトなので要注意。
以下は簡単な説明です。
Capybara はデフォルトではサーバーも仮想ブラウザもテストを実行している ruby のプロセス内で同期的に処理するので ActiveRecord の connection をテストとサーバーで共有でき、 transactional_fixtures が使えます。
しかし、 Selenium driver の場合ブラウザは本物、 Akephalos は HtmlUnit という Java の仮想ブラウザを別プロセスで実行しています。
そのため、テストのサーバーも実際の http リクエストを処理する必要があるので、 Capybara は thin や webrick を別スレッドで実行することにより対処しています。
一方、 ActiveRecord の ConnectionPool は connection のレースコンデションを避けるためにスレッド毎に異なる connection を返すため、 fixtures ロードを含むテストとサーバーは同一トランザクションにはなりません。
そこで、無理矢理に異なるスレッドでも ConnectionPool が同じ connection を返すように変更。真面目にこの問題に対応するためには、別スレッドでサーバーを起動せずにリクエストをブロックして rack-test で処理すればできそうな気も。
Monday, February 28, 2011
smart pointers for Core Foundation style references
iOS や mac のアプリケーションを書くときに Objective-C を使うときでも、 Core Graphics などの C の API を使うときは CGImageRef などのリファレンスの開放とか面倒です。特に関数の途中で return したり、C++ のライブラリを使用するときの例外処理を考えるとウンザリです。メモリリークのリスクも高まるし。
Objective-C のオブジェクトなら最初に autorelease しておけばいいんですけどね(iOS でなければガベージコレクションも使えるし)。
そんなときは C++ のテンプレートで smart pointer 的なリファレンスのラッパーを書けば、ことあるごとに XXXXRelease(ref) しなくて済みます。
これで、こんなふうに書けるようになります。
Objective-C のコードで C++ のコード使う場合(Objective-C++)は、拡張子を .mm に変えるを忘れずに。
void doSomething(void) {
CGImageRef image = CGImageCreate(......);
// do something...
if (some condition...)
CGImageRelease(image);
return;
}
try {
CPlusPlusClass::aFunction()
} catch (...) {
CGImageRelease(image);
return;
}
// use image...
CGImageRelease(image);
}
Objective-C のオブジェクトなら最初に autorelease しておけばいいんですけどね(iOS でなければガベージコレクションも使えるし)。
そんなときは C++ のテンプレートで smart pointer 的なリファレンスのラッパーを書けば、ことあるごとに XXXXRelease(ref) しなくて済みます。
これで、こんなふうに書けるようになります。
#include "AutoRef.h"
void AutoRefRelease(CGImageRef ref) { CGImageRelease(ref); }
void doSomething(void) {
AutoRef image = CGImageCreate(......);
// do something...
if (some condition...)
return;
}
try {
CPlusPlusClass::aFunction()
} catch (...) {
return;
}
// use image...
}
Objective-C のコードで C++ のコード使う場合(Objective-C++)は、拡張子を .mm に変えるを忘れずに。
Monday, February 14, 2011
a Lifehack for the redirection problem of lifehacker.com
If you can't understand Japanese, please go to English part of this post.
2011-02-24: mac の場合 「プロキシ構成ファイル」として gist の "view raw" リンク の URLを指定すればOKなことに気がついた
2011-02-24: gizmodo もダメだったので追加
2011-02-24: pacファイルを gist に
最近、僕の自宅から lifehacker.com にアクセスすると lifehacker.jp にリダイレクトされるようになってしまっていました。
調べてみると、みんなが見たい USサイトは us.lifehacker.com で、グローバルな lifehacker.com へのアクセスは親切なことになんらかの情報(アクセス元のIPアドレス?)をもとに各国の lifehacker にリダイレクトしているようです。
で、何が問題かと言うと、最悪なことに
USサイトのフィードの記事、たとえば、
"Disable or Restrict Plug-Ins in Chrome to Prevent Malware Installs [Security]" のリンク先、
http://feeds.gawker.com/~r/lifehacker/full/~3/zLgSu5CwbAM/
のリダイレクト先は
http://lifehacker.com/#!5757551/disable-or-restrict-plug+ins-in-chrome-to-prevent-malware-installs
なので、lifehacker.jp にリダイレクトされてしまって、該当の記事が読めないという具合。
本題の、この問題を回避するライフハックは、以下の javascript コードを lifehacker.pac みたいな名前で保存して、プロキシ構成 (.pac) ファイルとして設定することによりリダイレクトを回避します (Mac OS X の場合です。 Windows とかはよくわかりませんが、たぶん同じような設定がどっかにあります。)
最後に、こんなすばらしいライフハックを思いつくきっかけを与えてくれた lifehacker のリダイレクト仕様に感謝します。というか、早く直してください。お願いです。
LifeHacker の運営母体? Gawker Media Tech のサポートサイトでも、Stop redirecting to Japanese site!! 同じような問題が放置されてしまっているようですね。
以下、日本人以外のひと用。
If you are annoyed with the lifehacker redirect problem like this, Stop redirecting to Japanese site!!, this may be a help.
SET FOLLOWING SNIPPET AS A PAC FILE:
Or just use URL to "view raw" link above as "Proxy configuration File" URL.
If you don't have any clue about "pac file", try Proxy auto-config - Wikipedia, or if you use mac, see Apple's support page about pac file.
That's it.
2011-02-24: mac の場合 「プロキシ構成ファイル」として gist の "view raw" リンク の URLを指定すればOKなことに気がついた
2011-02-24: gizmodo もダメだったので追加
2011-02-24: pacファイルを gist に
最近、僕の自宅から lifehacker.com にアクセスすると lifehacker.jp にリダイレクトされるようになってしまっていました。
調べてみると、みんなが見たい USサイトは us.lifehacker.com で、グローバルな lifehacker.com へのアクセスは親切なことになんらかの情報(アクセス元のIPアドレス?)をもとに各国の lifehacker にリダイレクトしているようです。
で、何が問題かと言うと、最悪なことに
USサイトのフィードの記事、たとえば、
"Disable or Restrict Plug-Ins in Chrome to Prevent Malware Installs [Security]" のリンク先、
http://feeds.gawker.com/~r/lifehacker/full/~3/zLgSu5CwbAM/
のリダイレクト先は
http://lifehacker.com/#!5757551/disable-or-restrict-plug+ins-in-chrome-to-prevent-malware-installs
なので、lifehacker.jp にリダイレクトされてしまって、該当の記事が読めないという具合。
本題の、この問題を回避するライフハックは、以下の javascript コードを lifehacker.pac みたいな名前で保存して、プロキシ構成 (.pac) ファイルとして設定することによりリダイレクトを回避します (Mac OS X の場合です。 Windows とかはよくわかりませんが、たぶん同じような設定がどっかにあります。)
最後に、こんなすばらしいライフハックを思いつくきっかけを与えてくれた lifehacker のリダイレクト仕様に感謝します。というか、早く直してください。お願いです。
LifeHacker の運営母体? Gawker Media Tech のサポートサイトでも、Stop redirecting to Japanese site!! 同じような問題が放置されてしまっているようですね。
以下、日本人以外のひと用。
If you are annoyed with the lifehacker redirect problem like this, Stop redirecting to Japanese site!!, this may be a help.
SET FOLLOWING SNIPPET AS A PAC FILE:
Or just use URL to "view raw" link above as "Proxy configuration File" URL.
If you don't have any clue about "pac file", try Proxy auto-config - Wikipedia, or if you use mac, see Apple's support page about pac file.
That's it.
Sunday, December 19, 2010
my first impression of using capybara + akephalos
thoughtbot and the Holy Grail - GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS
を見て、 capybara + akephalos を試してみた。
結論から言うと、 jquery-ujs ajax リクエストのテストができたんですけど、補足事項がいくつかあります。
1. javascript_driver でなく default_driver を変更する必要があった
2. selenium でテストするときのように、サーバープロセスを起動してアクセスするので transactional_fixtures = false にしてテスト毎に DBの cleanup が必要
具体的には
あと DB の cleanup は database_cleanupが便利でした。以下の例は transactional_fixtures を無効にして、全ての example が実行される前に一度 cleanup して、あとは example が終わると cleanup します。(truncate なので DatabaseCleaner.start はたぶん何もしないんですけど、 transaction strategy に変えたときには意味があるのでお約束です)
元記事のコメントには「selenium より遅い」という意見があります。たしかに最初の akephalos サーバーの起動には時間かかるので、rspec コマンドで単体の example もしくは example group を実行しているときにはオーバーヘッドが大きいですね。しかし、 rake spec などで全部実行するときには akephalos サーバーの起動は一度で済むので、リクエスト自体は意外とサクサクと動いて僕の selenium のツライ経験からすると全然いいですね。
その他の注意事項としては、
1. 現状の akephalos (0.2.4) では capybara 0.4.0 に対応できてないので 0.3.9 を使うのですが、
2. webrat -> capybara 移行に際して、 capybara は rails の integration test のしくみを使ってないので、
を見て、 capybara + akephalos を試してみた。
結論から言うと、 jquery-ujs ajax リクエストのテストができたんですけど、補足事項がいくつかあります。
1. javascript_driver でなく default_driver を変更する必要があった
2. selenium でテストするときのように、サーバープロセスを起動してアクセスするので transactional_fixtures = false にしてテスト毎に DBの cleanup が必要
具体的には
# spec/spec_helper.rb
require 'akephalos'
#Capybara.javascript_driver = :akephalos
Capybara.default_driver = :akephalos
あと DB の cleanup は database_cleanupが便利でした。以下の例は transactional_fixtures を無効にして、全ての example が実行される前に一度 cleanup して、あとは example が終わると cleanup します。(truncate なので DatabaseCleaner.start はたぶん何もしないんですけど、 transaction strategy に変えたときには意味があるのでお約束です)
# spec/spec_helper.rb
RSpec.configure do |config|
config.use_transactional_fixtures = false
config.before(:suite) do
#DatabaseCleaner.strategy = :transaction
DatabaseCleaner.strategy = :truncation
DatabaseCleaner.clean_with(:truncation)
end
config.before(:each) do
DatabaseCleaner.start
end
config.after(:each) do
DatabaseCleaner.clean
end
end
元記事のコメントには「selenium より遅い」という意見があります。たしかに最初の akephalos サーバーの起動には時間かかるので、rspec コマンドで単体の example もしくは example group を実行しているときにはオーバーヘッドが大きいですね。しかし、 rake spec などで全部実行するときには akephalos サーバーの起動は一度で済むので、リクエスト自体は意外とサクサクと動いて僕の selenium のツライ経験からすると全然いいですね。
その他の注意事項としては、
1. 現状の akephalos (0.2.4) では capybara 0.4.0 に対応できてないので 0.3.9 を使うのですが、
within "#item_1"はダメで、
within :css, "#item_1"のように書く必要あり
2. webrat -> capybara 移行に際して、 capybara は rails の integration test のしくみを使ってないので、
get "/"や
response.should contain("hoge") が使えないので各、 visit "/",
page.should have_content("hoge") などに書き換えが必要
Thursday, September 23, 2010
Yet Another Offline Google Maps for iOS
Android Mapというプロジェクトの紹介記事から知ったのですが、 Mobile Atlas Creator という Google Maps などのソースからオフラインで利用できる地図データを作成するツールがあります。
作成した地図を iPod Touch から利用できると便利なので探してみると、 Galileo Offline Maps というのがありました。この app 本体は無料で CloudMade と OpenStreetMap のデータが利用できます。これらの Crowdsourcing マップは日本だとデータが少なくて役に立たないからなのか、否定的なレビューばかりで残念なのですが、 230円のアドインを購入すると Mobile Atlas Creator などで作成したデータをインポートできるようになります。(表示が 230 $ で焦りますが、まあ、アメリカンクオリティなのはよくあることですね。)
オンライン地図のインポートの方法の詳細は Galileo Offline Maps のGuide - How to Import Offline Maps を参照してください。
ちなみに、Google Maps のデータの利用に関してはグレーな感じがするのですが、 MapFolder のように app 本体がダウンロードするわけではないので抹殺されないことを願います。
作成した地図を iPod Touch から利用できると便利なので探してみると、 Galileo Offline Maps というのがありました。この app 本体は無料で CloudMade と OpenStreetMap のデータが利用できます。これらの Crowdsourcing マップは日本だとデータが少なくて役に立たないからなのか、否定的なレビューばかりで残念なのですが、 230円のアドインを購入すると Mobile Atlas Creator などで作成したデータをインポートできるようになります。(表示が 230 $ で焦りますが、まあ、アメリカンクオリティなのはよくあることですね。)
オンライン地図のインポートの方法の詳細は Galileo Offline Maps のGuide - How to Import Offline Maps を参照してください。
ちなみに、Google Maps のデータの利用に関してはグレーな感じがするのですが、 MapFolder のように app 本体がダウンロードするわけではないので抹殺されないことを願います。
Sunday, August 15, 2010
a way to specify a ruby with rvm for new windows of a screen session
$ rvm use --default ruby-1.9.2
の状態で
$ rvm use system
で利用する ruby を切り替えても screen の window の環境は新規のシェルセッションになるので ruby-1.9.2 に戻ってしまう。
screen が新規 window を作成するときに利用する shell のスタートアップスクリプトが実行され初期化されてしまうので当たり前といえば当たり前。
そこで、シェルスクリプトの source rvm の直後に以下のおまじないを書いて、
if [[ -n "$rvm_use" ]] ; then
rvm use $rvm_use
fi
環境変数 rvm_use を与えて screen を起動すると、
rvm_use=system screen
screen の新規 window が作成されるたびに rvm use system が実行されるようになります。
もっといい方法があるかと思うので、知ってる人は教えてください。
RVM inside Screen に描いてあることは、 screen の新規 window で script/rvm が読み込まれるようにするだけだったので残念。
Subscribe to:
Posts (Atom)
