ニュートリノの光速超えについて

色々今巷で話題になっているので、ちょっとぼやいておこうかなぁと。

スラド　での記事をみたのですが、時計の進みのずれが光速を超えたニュートリノの観測
になった可能性があるそうですね。

そこまで、重力の差異で影響はでるとは思っていませんでした。
でも、なんでスイスーイタリア間をニュートリノを飛ばして、そんな厳密なテスト
を行おうと思ったのだろうか？
経度が変わることにより重力に差異が出ることはわかっているはずなのに。。。
K2Kだって、ちゃんと経度があまり変わらない方向に打ち込んでいるはず。

時間の進みに補正をかけるということは誤差が出てその誤差が実際の測定の誤差になる誤差の伝搬が発生してしまうのではないかな。

業界から離れた人間がごたごたいってもしょうがないので、じっくり検証結果を待つとしよう。

playコマンドの動作について

playの勉強会をUstで参加？したため、ちょっと色々コードリーディングして、
動作を把握していこうかなぁと思います。

まずは、playコマンドを叩いて起動する部分について。

> ./play run myApplication
と実行したときの動作。

1. playコマンド
1. play_command、application_path、remain_argsを取得
2. framework/pym/play/application.py
1. application_pathからconf/application.conf、conf/routesの存在チェック。application.confのパース
3. framework/pym/play/cmdloader.py
1. commands配下にあるコマンドスクリプト一覧を取得する。
2. コマンドスクリプトのCOMMANDからplay_commandと一致するスクリプトファイルを取得する。
3. 一致した場合はスクリプトファイルのexecuteを実行する。
4. runの場合：base.pyの中のrunを実行し、java_cmdでplay.jarを起動する引数を作成して、Popenで子プロセスを立ち上げる。

独自コマンド追加

commandsディレクトリの中にXXXX.py(適当なファイル名)を追加して、COMMANDSに独自コマンド名のリストを定義して、executeメソッドで起動をする。

※play run 実行時のjava起動コマンドライン引数

java
-javaagent:/Users/kazuhiro/work/play/play-1.2.3/framework/play-1.2.3.jar
-Dfile.encoding=utf-8
-Xdebug
-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n
-Dplay.debug=yes
-classpath [設定するパス]

-Dapplication.path=/Users/kazuhiro/work/play/play-1.2.3/myApplication
-Dplay.id=
play.server.Server

Playframework勉強会#2まとめ（スライド）

Playframework勉強会#2のスライド一覧みたいなのがなかったので、作ってみました。
逐次アップされたら更新していきます。

時間	発表者	タイトル
15:05~35	@ikeike443	「Play! の紹介」
15:35~16:05	@garbagetown さん	「playdocjaのこれまでとこれから」
16:10~16:40	@genki_ さん	「Play!で作る業務アプリケーション構成例」
16:40~17:10	@hagikuratakeshi さん	「Play! + GAEで作ったアプリをPlay! + Heroku で動かすとどうなるか」

発表者	タイトル
@daiksy さん	「大阪勉強会の続きのはなし」
@kara_d さん	「Play FrameworkでWebSocketを使ってSVGのビジュアルチャットを作ってGDD open call html5に応募してみたけど落ちました」（仮）
@mitsuhiro さん	「HerokuのPlay! 対応について」（仮）
@Masahito さん	「5分で説明するPlay-Scala」
@tan_go238 さん	「NettyはPlay!でどう使われてるのか的な話」（仮）
@ikeike443さん	「Jenkins+Play!で気軽にCI」

「プロセッサを支える技術」読了

「プロセッサを支える技術」をついちょっと前から読み始めてました。
理由は複数個あるのだが、やはり関数プログラミングの集いの場で村主さんの発表で
ハード屋さんの努力があってのことなので、それをうまく使わなければならない。（そんな風な感じ）というのを聞いて全く以てその通りと思った。

あとは、一応組み込みの会社に入っているのだからハードのことも知らないとね。ってことで。（入社して全く組み込みをやったことないが。。。。）

さて、内容はプロセッサ関連について400ページほどあるので、ある程度詳しく書かれてています。
情報処理系の試験にでてきそうな話ですね。

• RICS , CISCキャッシュ、スーパースカラ、Out of Order、メモリ、割り込み
• x86アーキテクチャについてCore7iなどの命令セットやキャッシュについての動作
•  仮想化のCPUの動作について
• マルチプロセッサについて（キャッシュコヒーレンス、スヌープ等）
• メモリについて（これは情報処理系のテストに似た内容）
• GPGPUについて（CUDA,OpenCLなど）

といろいろ盛りだくさんの内容になっていました。

ハードウェアに興味がある方は読んでみてよいと思いますよ。

JUnit 4.10 リリースされました。

５日前ほどにJUnit 4.10 がリリースされたので簡単にリリースノートをまとめてみました。
一応Theoriesが拡張してGenericType対応になっていくような雰囲気。

RuleChain

• RuleChainはTestRulesの順番の指定可能

TemporaryFolder

• TemporaryFolder#newFolder(String... folderName)が再帰でフォルダ作成可能
• TemporaryFolder#newFile()はランダムなファイル名を作成
• TemporaryFolder#newFolder()はランダムなフォルダ名を作成

Theories

• Theories runnerはGeneric Typeを持つTheoryパラメータを予測しない。
• Theoriesがjunit-contribへ移動するまで、この修正は行われない。
• 4.9.1はrunner classに必要な機構をいくつか追加した。Theories runnerを使う場合、メソッドをdeprecatedにした。(producesType())
• JUnitがリリースされたCommon Public Licenseはソースリポジトリ内に含まれている。

Bug fixes

• ビルドインルールの実装
• TemporaryFolderはruleが失敗の場合、現在の作業ディレクトリにファイルを作成すべきではない。
• TestWatcherとTestWatchmanはAssumptionViolatedExceptionsに対してfailedをコールすべきではない。
• Javadocのバグ
• Assersionドキュメンテーション
• ClassRule
• Parameterized
• その他
• RunAfterに不要なコード
• Parameterizedテストクラスは@Categoryアノテーションを持つことができるはずです。
• エラーカウントはjunit.tests.framework.TestListenerTestで初期化されるべき。
• AssertionFailedErrorコンストラクタはnullメッセージでsuperをコールすべきではない。
• no-static内部テストクラスの明確なエラーメッセージ

Minor changes

• Description,Result,Failureがシリアル可能
• FailOnTimeoutは再利用可能で、Ruleを再利用できる。
• 理由を指定することができるErrorCollector.checkThatのオーバーロード