前回3.4系でスマートフォンでの新規登録が出来ない件で無理矢理対応を行ったが、今回は3.6系での処置を行った。
スマートフォンの対応については3.8系で進められている様ですが、諸事情で3.6系を使わざるを得なかったので、力業で・・・。前回と同様にこの記事を参考にする場合は、筆者は一切の責任を負いませんので、自己責任でお願いいたします。ここではver3.6.3について行っています。

基本的には前回の記事と同様ですが、いくつかさらに変更しなくてはならない点があります。
opAuthRegisterFormMailAddress.class.php
に新しい関数として”validateMemberConfig”があります。これによりモバイルであるかPCであるかをチェックしているようですが、「メールアドレスはモバイルだがブラウザはPC扱い」と言う不整合を正しいとみないといけないので、この関数の判断部分をコメントアウトにしました。
———-
public function validateMemberConfig($validator, $values, $arguments = array())
{
// if (sfConfig::get(‘app_is_mobile’, false))
　　（略）
// }
//
return $values;
}
———-
次に、下記でもチェックがありましたので、これもチェック部分を外します。
plugins/opAuthMailAddressPlugin/apps/pc_frontend/modules/opAuthMailAddress/templates/_registerBox.php
———-
<?php //if (!$pcAddressPre): ?>
<?php
//$options = array(
// ‘title’ => __(‘Errors’),
//);
//op_include_box(‘registerError’, __(‘Can access this registration URL with mobile only.’), $options);
?>
<?php //else: ?>
<?php op_include_parts(‘ButtonBox’, ‘opAuthMailAddressPluginRegisterBox’, array(
‘title’ => __(‘Registration with your e-mail address’),
‘body’ => __(‘You can go to the registration page by clicking the button below.’),
‘button’ => __(‘Go to the registration page’),
‘url’ => url_for($sf_user->getRegisterInputAction()),
‘method’ => ‘get’,
)) ?>
<?php //endif; ?>
———-
取り急ぎこれで動くようですが、はたしてこれで良いのだろうか・・・(-_-;

2012/05/21修正
<>が生きていたので、phpソース部分が一部抜けていました。

このところ辛いものにはまっておりまして、今日はそのネタです。
本日御徒町で唐辛子を仕入れてきました。

以前このメーカーの「激辛唐辛子」というものを食していたのですが、この「超激辛唐辛子」はもっとききます。
カレー1人前に小さじ１くらい入れると○○壱番屋の10倍より辛くなる気がします。少量で効くので風味のバランスを壊さずに料理を辛くする事が出来ます。子供は辛いものがダメなので家では辛いものが・・・という方でも自分の一皿だけ激辛に出来ます。みそラーメンも結構いけました。粉末なので目立たないのが良いと思います。
ちなみに、このお店で「ハバネロ唐辛子」という商品を見かけたので、そのうち試してみたいと思います。

ご無沙汰です。
知り合いより「最近実験室更新していないね・・・」といわれたのですが、最近実験ネタが・・・というわけで実験ネタ以外も書くようにしたいと思います。

昨年の夏休みに子供の自由研究のアドバイスで考えたのですが、ボツになったネタです。
太陽系の星の大きさの図を見たことがあるかと思いますが、実際太陽系はどんな感じなのでしょうか？
手元に理科年表が出てこなかったので、ネットで各星の直径と太陽からの距離を調べました。この値を用いて、太陽の大きさを直径１ｍとして他の星がどのようになるかを考えてみます。
太陽が1mなら地球はおおよそ100ｍ先の9.2mmになります。パチンコ玉より小さいです。実際の球体を用意して・・と思ったのですが、惑星の大きさが小さいので写真に撮ってもわからない事が判明いたしました。
そこでサイクリングロード上に各惑星の位置を示した地図を作成してみました。
冥王星に至っては4km先の2mmの球体なんて絶対見えませんよね。

より大きな地図で 太陽系大きさと距離 を表示
大きな地図で見ないと全体出てこない様です。
計算間違えてたらごめんなさい。
ちなみに冥王星は準惑星ですが、のせちゃいました。

本投稿は不確かな測定に基づく記録ですので、結果は正確なものではありません。本情報により発生した損害や障害については一切の責任を負いかねますので、ご承知おき下さい。時期的に微妙でしたので投稿をやめようかとも考えましたが、マスコミ報道がすでに過去の事の様に感じるので、投稿する事にしました。データの再検証も行いました。

すみません最近更新をさぼっていました。

さて、東日本大震災から１年経ちました。以前わんこそばを食べに行った面子で再び出かけようとの話になったが、仕事の都合でなかなかタイミングが合わない。最近遠出していないこともあったので、ふとガイガーカウンターを持って前回通った道と同じルートで今回は一人で行ってきた。
お彼岸の最終日と言うこともあるので、交通渋滞の元になっても仕方がないので、深夜の出発とした。帰る頃に日が昇ってくるようなタイムスケジュールだったため、今回は写真は撮れませんでした。

前回と同じ装置を助手席に置き測定を行いながら走ってきた。
今回は須賀川ICから郡山経由で向かい、伊達市の方までまわる事とした。
途中あちこちで舗装工事が行われていた。除染を考慮しての事なのだろうか、それとも地震で傷んだ道路の補修なのだろうか。
行程中の計測結果を示す。
自作のガイガーカウンターなので校正は取っていないので、カウント値の相対値をみていただきたい。また、車で移動しながらの測定なので、計測結果とGPSデータに差が生じているので、正確では無いので注意が必要です。

より大きな地図で 東北120320 を表示

特に以前通った時に放射線の高かったあたりはどのようになっているのであろうか・・・。
山間の道は路肩に雪が残っている感じで、所々アイスバーンがある感じである。一部路肩が崩れている箇所もあり慎重に運転した。
下記に昨年11月に通った時のデータと今回のデータを重ねたグラフを示す。先に述べたようにGPSデータとカウント値に若干のズレが発生している可能性があるので、その点を考慮して見ていただきたい。また、異なるデータを重ねるため、二つのデータのGPSの値からある基準点からの積算移動距離を求めて、これを横軸にする事にした。積算移動距離は山中を移動しているため正確には出せないため、直線部分で補正を行った。またカウント値は各々の移動平均値を用いる事にした。
結果を下記に示す。

本結果から、いくつかの場所でカウント値が下がっている感じが見られた。移動しながらの測定なので、正確にはわからないが、状況が改善していることを祈りたい。
また、役場の線量計は前回は2.51uSv/hであったが、今回見た数値は0.77uSv/hであった。この役場周辺の放射線が低くなっているのは、大変な努力をされてこの付近の除染を行っているからだと思う。道のりは大変だと思うが、被災地の復興を切に祈ると同時に、非常に困難な事があることも感じられた。

また今回PINダイオードの計測器も持って行ったが、振動等のノイズと諸々の対策でいろいろ試した結果何を見ているかわからない状態になってしまった。仕方がないので、時間を見て再度作り直して見る事にする。また、秋月でシンチレータが販売されているので、そちらについても検討したいと思う。
（実はいろいろ実験はしていたのですが、今ひとつ結果が出なくて・・・）

注意）
　本データは個人が自作の計測器を使って測定した結果であり、正確なものではありません。ただ、一つの実測データとして何かのご参考になればと思い記載しています。

補足）
　半減期2年のものが60%、半減期30年のものが40%あった場合、単純な計算で
　　昨年3月 100%
　　昨年11月 86%
　　今年3月 82%
と計算出来ます。と言うことで11月から今回の差は、この比率を仮定してかつ、ものの移動が無いと計算すると半減期による変化は約6%程度となります。

昨日一時的に公開した祭は２データの重ね方が悪く、役場以外では値に差が見られませんでしたが、改めてデータを整理したところ何となくそれらしい結果になりました。いずれ公式のデータを見る事が出来れば本当の事がわかると期待しています。

またしてもログが止まっていた。よくよく見るとcronのログの関係で大量の小さいファイルが出来ていたため、新しいファイルを作ることが出来なくなっていたようだ。ゴミファイルを消す処理を追加して再稼働させました。・・・これで大丈夫かな・・・

OpenPNEを使ったサイトでスマートフォンで登録出来ないとの事で対応しました。
いろいろ手をかけてあるので単純にバージョンをあげれなかったので、改造に踏み切りました。
尚、ここで述べた方法を行った結果生じた不具合・損害については一切責任を負いませんので、自己責任でお願いいたします。

初期登録では「メールアドレス」を登録し招待メールを送るのですが、この際メールのドメインで携帯であるかPCであるかを判断するので、スマートフォンの場合でもメールアドレスは携帯扱いになってしまいます。ところが・・・いざ登録する場面ではUserAgentで識別されてしまうため初期登録がエラーとなってしまいます。
スマートフォン用の画面を製作していないので、PC用を使ってもらっている関係でUserAgentにスマートフォン用のブラウザを追加する事は出来ません。またいろいろなブラウザを使用しているためいたちごっこになりそうです。

そこで、PCの初期登録URLで携帯のメールアドレスを処理出来る様に改造する事にしました。
突貫であったのでもう少し良い方法があるかもしれませんが取り急ぎ動いているようです。
尚、OpenPNEは3.4系です。
ご参考まで

初期でtokenを処理するために下記を改造する。
“plugins/opAuthMailAddressPlugin/apps/pc_frontend/modules/opAuthMailAddress/actions/actions.class.php”
=======================================================
　　　略
　public function executeRegister($request)
　{
　　$this->getUser()->setCurrentAuthMode(‘MailAddress’);
　　$token = $request->getParameter(‘token’);
　　$memberConfig = Doctrine::getTable(‘MemberConfig’)->retrieveByNameAndValue(‘pc_address_token’, $token);
##追加#######################
if ($memberConfig != ‘pc_address_token’){
　　$memberConfig = Doctrine::getTable(‘MemberConfig’)->retrieveByNameAndValue(‘mobile_address_token’, $token);
}
#########################
　　$this->forward404Unless($memberConfig, ‘This URL is invalid.’);

初期登録画面でmobile_address_preを処理出来るように下記を変更する。
“./plugins/opAuthMailAddressPlugin/lib/form/opAuthRegisterFormMailAddress.class.php”
=======================================================
　　public function doSave()
　　　　略
　　if (sfConfig::get(‘app_is_mobile’, false))
　　{
　　　$memberConfig = Doctrine::getTable(‘MemberConfig’)->retrieveByNameAndMemberId(‘mobile_address_pre’,$this->getMember()->getId());
　　　$memberConfig->setName(‘mobile_address’);
　　}
　　else
　　{
　　　$memberConfig = Doctrine::getTable(‘MemberConfig’)->retrieveByNameAndMemberId(‘pc_address_pre’,$this->getMember()->getId());
##コメントアウトして、追加########
　　　#$memberConfig->setName(‘pc_address’);
　　　if (“$memberConfig” == “pc_address_pre”){
　　　　$memberConfig->setName(‘pc_address’);
　　　}else{
　　　　$memberConfig = Doctrine::getTable(‘MemberConfig’)->retrieveByNameAndMemberId(‘mobile_address_pre’,$this->getMember()->getId());
　　　　$memberConfig->setName(‘mobile_address’);
　　　}
##########
　　　}
　　　$memberConfig->save();
　　　return $memberConfig;
　　}
=======================================================

ふと見たらガイガーカウンターの積算データが出ていない・・・・どうやらログサーバーが止まっていたようで、再起動しました。
多分メモリあたりがおかしい感じです。作り直すかな・・・。

以前秋葉原でアルコールテスターを購入していたものが出てきたので、以前からやってみたかった実験を行ってみた。
実験とは、「飲んだお酒の量と呼気中のアルコール濃度の変化」である。
行きつけのお店で店主の許可をもらって早速開始した。
ちなみにこの実験はかなりいい加減なのでちゃんとしたものではないのですが、まあご愛敬って事で・・・。

１．使用機器
　使用機器は秋葉原で購入した下記機器である。製品に書いてあるが、「正確なものではありません」とちゃんと書いてあります。

被験者
　性別：男
　年齢：４０代
　体重：0.1ｔ弱
アルコール
　Chamisul（チャミスル）22度
　高清水（日本酒）

２．実験方法
　ショットグラスの容量を予め計測しておき、このグラスで飲んだお酒の量と、飲み終わった後の呼気中のアルコール濃度を測定します。計測前には水で口の中を洗浄してから測定する事としました。尚、店主と周りのお客の許可を取って（・・というより皆さんも楽しんでました）実施しています。
水割りやお茶割りの場合は上記ショットグラスで計測してから作るようにしました。

３．結果
　時刻とともなって呼気中のアルコール濃度がどのように変わってきたかと言うと下記の様になりました。

次に摂取アルコール量をザックリ計算してグラフにしてみます。ロックで飲んだり、割ったり、途中で日本酒に切り替えたりしたのでかなりいいかげんですが、20%と見なして飲んだお酒の量(割もの除く)に0.2をかけてCCで表現しました。

なんか同じようなグラフになってしまいました。
試しに時間と飲んだ量をグラフにすると下記の様になりました。

律儀に飲んでいたようです。37cc/hくらいですね・・・。

予想していたのは、もう少し飲んだ量に対して右上がりのデータを期待したのですが、実際はコップ1杯(チャミスル100ml位)飲んだあたりで0.2mg/L弱になり、後はしばらく飲んでもあまり変わらない感じです。ちなみに「あ、酔ってきたかも・・」と自覚したのはグラフ中の0.3mg/Lを示したあたりです。後半の0.25mg/Lあたりを示したあたりからは結構楽しい状態でした。（感想は飲んでる環境の影響が大きいですが・・・）
ちなみにグラフの真ん中あたりで日本酒に切り替えてます。
しばらくの間値が一定となったのは、おそらく腸からのアルコール吸収とアルコールの分解のバランスが取れていたのでは無いかと思いますが、次回はここらあたりの推測が出来るデータの取り方を考えてみたいと思います。

ちなみに「成人男性の適量の目安が、１日平均純アルコールで約20g程度」と見たことがありますが、上記実験ではその10倍位ですね・・・（＾＾；。

補足
下記に呼気中のアルコール濃度と状態の記述がありました。
全く別の製品の資料ですが参考になるかな・・・
www.figaro.co.jp/data/pdf/20100628214833_98.pdf

しばらく空いてしまいました。少々まとめてアップする様にします。
先日まで東京方面では異常乾燥がつづき、ようやく月曜日に雨と雪になりました。この時間帯でガイガーカウンターの記録に変化がありましたので、一応記載しておきます。
下記は連続記録データの、１月２４日午前８時のグラフです。前日の１４時頃に雨が降り、１８時頃から２４時頃にかけて雪が降りました、図中にこれについても記載しています。カウンターの値が高くなっているのが、降雨(雪)にあわせて高くなっている感じです。
乾燥で空気中に浮遊している埃などが雨で落ちてきたのでしょうね。２Ｆで測っているのですが、雪の方がやや高い感じがするのは、落ちてくる速度と何らかの関係があるんでしょうかね・・・単なる気のせい・・・？

最近部屋のガイガーカウンターがうるさい気がしていたので、記録を残してみる事にした。
とりあえず手元にあった１ボードのPCがあったので、linuxサーバーにし、手製のガイガーカウンターを接続する事にした。幸いFT232R-USBシリアル変換モジュールがそのまま認識してくれたので、この装置でデータを取った後本ブログを動かしているサーバーに送る事にした。
写真は本装置の外観である。

cronで１分ごとにガイガーカウンターよりデータを取り、そのままサーバーに送る仕様でプログラムを作成して実行した。
ときおり通信に失敗するものの、大体送れているのでとりあえずこれで良しとする。
次にサーバー側でグラフを書こうかと思ったが・・・・！GD関係が使えない！・・サーバーサイドでグラフを作成する事が出来ないではないか・・・・。
集信装置側でグラフを作成する等を考えたが、とりあえずテキストで表示する事にした。
自作ガイガーカウンターの測定結果の1時間毎の平均値
一応左側にリンクを表示しておきます。

さて、このカウンターで年間1mSvはどの様になるか考察しておく。
このあたりの自然放射線は、
　地質からの放射線　　　　　　　　0.036uSv/h
　宇宙線による放射線量（海抜 0m） 0.33mSv/y
　　参考：http://www.geosociety.jp/hazard/content0058.html#map
となる。これより合計で　　　　　　0.074uSv/h
自然外からの放射線が1mSv/yとすると、1時間あたの値にして自然放射線と合計して0.188uSv/hとなる。
これを先の換算係数0.0094として計算すると、約20cpmとなる。
核種が異なるので、単純に換算する事は間違いであるが、参考値として考える事にする。
このあたりは特に放射線が高いとされている場所ではない。執筆時には平均値が14cpm程度であるが、20cpm程度の値がでる事もあるので、他と比べて問題視するレベルでは無いように思うが、生活圏として結構微妙な感じである。
今後の推移を見ていきたいと思います。

2012/1/3
グラフを追加しました。5分間隔で更新しています。フォントの関係でちょっと見づらいですがご愛敬って事で・・・。

赤が1分ごとのデータで、緑が1時間の平均値です。横軸は時間で、23時間のデータを表示しています。