REGZA SD-BD3

息子が傷のつきまくったDVDを入れたりトレイをガチャガチャと手荒にあつかった結果HDDレコーダーをぶっ壊した。

それにも関わらずDVDを見たいとのたまうので、息子の誕生日プレゼントと銘打って安いBDプレーヤーを購入。

本棚をガベコレした

うちの本が仮想メモリにスワップしまくった(床に無造作に置かれたともいう)ので、ガベコレすることにした。

1318918305

仕分け作業をしながらxooqに入れといたので欲しい本があったらお知らせ下さい。勉強会とかで会えれば譲ります。

そして、回収された貴重なスペースに積んであるヨ的な本をまとめて、読む気力を揺さぶってみることにした。

1318918307

ふつうのコンパイラなんて二年以上熟成させているので、そろそろバニラとかナッツを思わせるような香りがしてきてるはず。そろそろテイスティングしないとあかんね。

今日の畑(111012)

スティックセニョールは半分枯れてた。補充すべきか放っとくべきか悩む。

にんにくは芽が出てきた。

1318851795

ほうれん草も発芽してた。間引きしないといけないんだけど面倒臭いのでまた今度。

1318851796 1318851798

人参はやっぱ発芽率が悪いなぁ。

1318851800

浅葱は今年初収穫、あと3,4回はとれるかな。

1318851802

TANN-YA

YAPCのお昼

1318851501

東工大の近所の担々麺のお店にいった。

1318851499 1318851497

ちょい辛を頼んだけど辛口でよかったかも。肉に深みがあって旨かった。

Scala実践プログラミングを読んだ

本書は、Perlでいうところの「モダンPerl入門」またはPythonで言うところの「エキスパートPythonプログラミング」に対応する感じの中級を目指す人向けの本ですね。なお、Scalaだけでなく色々な言語をかじっていれば楽しく読めるので良いですね。

ProductName Scala実践プログラミング―オープンソース徹底活用
小笠原 啓
秀和システム / 2940円 ( 2011-06 )


一通り読んでみて、5,6,7章が良かった。10章はあとでゆっくり(今継続やってもあれなので)。あと、標準ライブラリのソースも読んだほうがいいなと。

1,2章

文法等の話はコップ本等で補足しながら読まないとよくわからないんじゃないかと。逆に言うと、コップ本の後に読んだ時にきちんと理解しているかどうかの確認としてよろしい。個人的にはコンパニオンオブジェクトとか、補助コンストラクタ、パッケージオブジェクトあたりの説明が役に立った。あと2.8-2.9の新機能紹介。

3章

関数型プログラミングに関して。基本的な内容だったのでサラっと流して最後のほうだけ。

カリー化による部分適用はプレースホルダー構文による部分適用よりも柔軟性が低い

Haskellで引数の順番を入れ替えるflipっていう関数はあるけど、プレースホルダー構文のほうが楽ですね。

4章 他言語との比較

4-1とHaskellとの比較が大変参考になった。それから4-2のStructual SubtypingとNominal Subtypingの話はわかりやすかった。もう少しScalaを使ってみないときちんと理解してるかどうか不安な部分もあるけど。

5章 開発環境

とりあえず、sbtを入れてみた(0.11.0)けど、本のバージョン(0.7.5)のように起動時にディレクトリのスケルトンは作成しないようだ。?ってなったので調べたら0.7系と0.10系は結構変わってるらしい。まぁ、直接ドキュメント読みながら覚えていくからいいかなぁと思った。今、エディタはEmacs使って書いてるけど、そのうちEclipseに移行するのかなぁ、わからんなぁ。テストはなんかプロジェクトを作ったら使うけど今のとこは小さいサンプル動かしてるだけなのであまりそそられてない。

6章 WAF

Play!が面白そうなので只今絶賛いじり中

7章 デザパタ

Javaのデザパタ本をScalaで一回書いておくのがいいかなと思った。それからScalaのためのデザインパターン(Loan,Concept,Cake)は勉強になった。Cakeはいまいち飲み込めてないけど、あとで手を動かして考えてみる。

8,9章

流し読んだ

10章Actorと継続

Actorは軽く流してあったが継続は30ページ超えという。なぜか継続はワクワクしますな。ちゃんと読んでないのであとでゆっくり読む。

多分読んであったほうがよいと思われる本

Scalaをある程度知っているのが前提だと思われるので。

ProductName Scalaスケーラブルプログラミング第2版
Martin Odersky
インプレスジャパン / 4830円 ( 2011-09-27 )


Haskellも基本的なところは抑えつつRWHくらいまで読んでおいたほうが吉ですね。ちなみにプログラミングHaskellは名著なので練習問題も含めて一度は解いておくべきでしょう

ProductName プログラミングHaskell
Graham Hutton
オーム社 / 2940円 ( 2009-11-11 )


ProductName Real World Haskell―実戦で学ぶ関数型言語プログラミング
Bryan O'Sullivan
オライリージャパン / 3990円 ( 2009-10-26 )


Javaは知らんが、個人的にはパーフェクトJavaでも買おうかなと思っている(パーフェクトJavascriptがとても良かったので)。

ProductName パーフェクトJava (PERFECT SERIES) (PERFECT SERIES 2)
アリエル・ネットワーク株式会社
技術評論社 / 3780円 ( 2009-09-24 )


デザパタ知らないヒトはいないと思いますが、読むならこれですね。

ProductName 増補改訂版Java言語で学ぶデザインパターン入門
結城 浩
ソフトバンククリエイティブ / 3990円 ( 2004-06-19 )


継続的インテグレーションを創薬系のプロジェクトにあてはめてみる

自分の職場ももっと継続的なインプルーブメントが必要だろうなぁと思っているが、なかなか難しいですね。まぁ、ああいうのは地道にやるしかないのかねぇとインテグレーション入門を読みなおした。

CIは単に技術の導入にとどまらず、組織やその組織の文化にも変化を及ぼす

第一部はCIの背景や、原則、プラクティスについて書いてあるので、ソフトウェア業界じゃなくても色々参考になります(といってもソフトウェア業界のCIを知らないとよく分からないかもしれないが)

というわけで、自分の置かれている業界(製薬業ですね)におけるCIとはどんなもんかねというあたりをメモっておく。

ちなみに第一部の各章はこんなタイトルです。

  • 第1章 始めよう
  • 第2章 継続的インテグレーションの紹介
  • 第3章 CI によるリスクの軽減
  • 第4章 変更を起点としたビルドの実行

ProductName 継続的インテグレーション入門 開発プロセスを自動化する47の作法
ポール・M・デュバル
日経BP社 / 3360円 ( 2009-08-06 )


以下、用語に関しては特に説明しないが、創薬系におけるバージョン管理というものはどういうもんだろうかとかは考えたことがあるので参考に。

バージョン管理リポジトリ

バージョン管理リポジトリの目的は、アクセスが制御されたリポジトリを用いることによって、ソースコードや、その他(ドキュメントなど)のソフトウェア資産に対する変更を管理することである。これによって、一ヶ所からすべてのソースコードが入手できる「唯一の入り口」が提供される

創薬プロジェクトにおける資産とは何だろうか(というよりどこまで管理すればいいのだろうか)?という問いに閑する答えはシンプルで、プロジェクトを進めるために必要な全てですね。特に実験データに関してはロボットデータまで管理する必要があって、IC50とか中途半端なデータから管理してると、ある日突然シボンヌしますね(データの正しさが担保できない)。

それから、実験プロトコールや、報告書もプロジェクトにおける重要な資産なのできちんと管理する必要があるだろう。プロトコールのような手順のほかにBDDっぽい何か、つまりプロジェクトにおけるビヘイビアのようなものも必要だろう。

インテグレーション

ソフトウェア開発のようにレッドからグリーンを繰り返すサイクルとは異なり、いつか成功するかもしれない失敗を繰り返すから、基本的には常にレッドである。創薬プロジェクトは探索的なタスクが多く、イシューを細かく切ったとしても、それぞれが相互に強く依存しているために、常に手戻りが起きる危険が発生する。

そのため、インテグレーションとかビルドの考え方は大きく異なってくるが、どうしたらいいかに関しては自分の考えが固まっていない(だから文章におこしてるわけだが)。

よくありがちな創薬プロジェクトっていうのは

  1. in vitro薬理活性
  2. in vitro動態パラメータ
  3. in vivo 動態パラメータ
  4. in vivo 薬理パラメータ

の順にそれぞれ閾値を決めて、多段フィルタリングのイメージでゴールに向かって進んでいく。上で書いたように基本的には成功(閾値を超える)するかもしれない失敗を繰り返しながら後半のアッセイ系に進む確率を挙げていくわけです。

基本的にアッセイを繰り返すことにより、そのアッセイ系での成功確率は上がっていくわけですが(あがらないのももちろんあるがそれはサイエンスとして理解できてないとか本質を捕まえてないと表現する)後ろのほうでイシューが出てきて合成方針が変わると、最初の方のアッセイ系の成功確率ががくんと下がることがよくある。

というわけで、フローとして流すのがいいのか、幾つかのアッセイを並行で流して多次元最適化を行うのがいいのかはコストの制約とか、プロジェクトの性質で決まってくるのだと思うが、プロジェクトスタート時にはどういう組み方をしたらいいのか不明だし、大体、デフォルトのプロジェクトフローをまわしやすいように組織が最適化されているので、なかなか難しいですね。

結局創薬におけるインテグレーションってのはプロジェクトのどの粒度でナニを達成するのかをもっと突き詰めて考える必要がある。バージョンの考え方と、前進しているってのはどういうことかっていう定義が必要なんだろうなぁ。

インスペクション

インスペクションは種々のアッセイ結果を解析していく上で得た理解、つまり薬剤候補としての化合物の性質の許容の範囲ということになる。こういう情報はコミット時(または合成に着手する前)にアラートとしてフィードバックされるべきものであろう。

推測するな計測せよっていうのは創薬プロジェクトにおいてもやはり至言で、ウェット(実験系)のヒトは実験結果を解析しないで雰囲気でいい加減な解釈をするヒトが多い。たんに散布図とるだけでも、いい加減な解釈してるとバレるんだけど、受け取る側のケミストも裏取りしないで素直に受け取るので、一緒に泥沼に突き進んでいく光景が散見されて微笑ましい(こういうのはうちだけの問題ではないだろう)。

ただし、これはヒトの問題で片付けないで、システムとしての問題として考えるべきことであろう。根拠としてのプロットを明示するような規約を用意するだけでもこういうアホなやりとりはだいぶ減るだろうし、自動的にプロッティングを用意するシステムにすればなお良い。そういう状況でも治らない場合は組織的な病気なので伝染る前に前に移ることを考えましょう。

テスト

テストは試験です、つまり人力です。ソフトウェア業界ではどんどん追加していくわけですが、創薬プロジェクトではプロジェクトが始まった段階で既にテストが存在しています(逆にテストがないとプロジェクトが始まらない)。テストは基本的にコストのかかるものであり、ある段階で新たなイシューが発生した場合に新たなテストを組み込むかどうかは大きな意思決定を伴うし、新たなコストが発生しますね。

CIの価値

  1. リスクを軽減
  2. 繰り返しが多い手作業を削減する
  3. いつでも、どの環境にもデプロイできるソフトウェアを生成する
  4. プロジェクトの可視性を改善する
  5. ソフトウェア製品に対する開発チームの自信を深める

1,4,5は創薬プロジェクトでも同様なことが起こり、有用であろう。2の手作業はちょっとわからないが、手順をきちんと決めることでアウトソーシングできるとかであれば、コスト削減と、コモディティ化という意味で意味があると思う。

3は創薬プロジェクトにはデプロイに相当する仕事がないからあまり関係ないかも。

個人的には4,5に関心があるなぁ。

Jenkins+GitHubでPythonプロジェクトの継続的インテグレーション

この前の勉強会でJenkinsについて色々知った。JenkinsってJava向けだろうと思ってたら全然違って基本何でもいけるらしい(シェルから動かせるから)。あとgithubのプロジェクトもいけるらしいので早速pygamessっていう量子化学計算用のモジュールを使って試してみた。

最近GAMESSを仕事で使うことが多いんだけど、きちんとテストしてないと不安ですからね。

Jenkins

さくっと導入するならTraclightningがいいらしいんだけど、Jenkinsを単独で入れた。macだとパッケージをダウンロードして実行するだけでlocalhostの8080に常駐するので楽ちん

あとは、Gitのプラグインを追加でインストールしておく。

Python

Pythonのテストといえばnoseですね。あと、Python版のPerl Testingみたいな本ないのかな?

ProductName Perl Testing: A Developer's Notebook (Developers Notebook)
Ian Langworth
Oreilly & Associates Inc / 2160円 ( 2005-08 )


JenkinsとPythonの連携を参考にした。まずはnoseとunittest-xml-reportingをインストールしておく。

あとはJenkinsの設定のシェルの実行っていうところにnoseのテストを書いておく。

nosetests -v --with-xunit -w tests

これでnosetests.xmlっていうファイルにテスト結果が出力されるようになるので、JenkinsのオプションのJUnitテストの結果集計というところにチェックを入れて、nosetests.xmlを追加しておく。

python Jenkins

4つテストを走らせて、1つFailしている。

これは環境変数とかの問題で、gamessの実行ファイルがきちんと呼び出せてないせいで、テストがこけているんだけど、Jenkinsのほうにエラーの内容が吐かれてないのでどこでこけているのかつかめていない。

そもそもrungms使うのが間違っているのかなぁ。あとでよく考える。

YAPC ASIA 2011に行ってきた

スピーカー、スタッフの皆様お疲れ様でした。今年は一日目しか参加できなくて懇親会も出られずに帰ってしまったけど大変充実した一日をおくることができました。

聴いたセッション

個人的にはフェライト会議室のパスワード保護からperl meets beatsまでの一連のセッションが面白かった。

Rubyist のための Perl ウェブアプリケーション開発入門

@kyannyさんの Rubyist のための Perl ウェブアプリケーション開発入門を聞きながら、dotcloudサインアップした。Node.jsで書いたwikiがあるので動かしてみようかと思った。あとperlで書くならMojolicious::Lite使おうかなぁと。今メインで使っているFlaskもSinatraクローンみたいなもんだし、最近使い始めたExpressもそうだしね。

Perl Mongerなりきりカードゲームの考案と実践

パルモン

use strict!出社!出社!出社!出社!

最高でした。

perl meets beats

楽しみにしてたトーク。@techno_nekoさんによる、wave作成の話。思ったよりガチだった。最近、node.js系のイベントとかみてると、こういう音作る系がちょこちょこ出てくるので、興味があったんですよね。

コードがGitHubにあがっているので後で読んでみる

ドラムンベースよいですねと、帰りの新幹線でdrum'n'bass arena眺めてたら、Dom & RolandのLPが出てたので即買い、今聴いてる。

その他

Cartonは便利そう。あれで職場のレガシーな環境をどうにか出来ればいいなぁと。他人事なんだけど、バージョン管理きちんとしないでメンテナがどんどん変わるあのインフラヤバイんちゃうかなぁと思っているので、ああいう管理ツールの助けがあればと。あと、ああいうのは構成管理ツールという認識でいいのだろうか?最近インフラの話を聞くことが多くて境目がどこなのかよく分からなくなっている(そもそも境目なんてないのか?)。

SmartPhone development guide with Node/CoffeeScript and HTML5 technologies, for Perl programmersを聴いてて、確かにCoffeeScript+Expressで簡単なのは割りとサクサク開発できるなぁと。特にperl(pythonも同じことだろう)である必要性を感じないという結論だったのかなぁと。

PhoneGapはHTML5 Canvasの後ろの方に載ってたので、読み進めていけばいずれぶつかる。TituniumはShizudevの誰かに聞いてみよう(っていうか誰かハンズオンやってくれないかなぁ)。

ProductName HTML5 Canvas: Native Interactivity and Animation for the Web
Steve Fulton
Oreilly & Associates Inc / 2922円 ( 2011-05-13 )


と、色々刺激になったYAPC::Asiaだった。

PythonでSelenium2.0のWebDriverを動かす

seleniumも覚えようかなぁとmacbook(10.5)で触ってみた。

selenium2.8とselenium 2.8.1のpythonモジュールではfirefoxが立ち上がらずに死ぬので、firefoxで動かすことに固執せずにとっとと諦めてchromeでやってみた。

Chromeで動かす場合にはchromedriverというものをダウンロードしてきて、適切な場所に配置(Macだと/Applications/Google Chrome.app/Contents/MacOS/)する必要があります。

from selenium import webdriver
from selenium.common.exceptions import NoSuchElementException
from selenium.webdriver.common.keys import Keys
import time

browser = webdriver.Chrome()
browser.get("http://www.yahoo.com")
assert "Yahoo!" in browser.title
elem = browser.find_element_by_name("p")
elem.send_keys("seleniumhq" + Keys.RETURN)
time.sleep(0.2)
try:
    browser.find_element_by_xpath("//a[contains(@href,'http://seleniumhq.org')]")
except NoSuchElementException:
    assert 0, "can't find seleniumhq"
browser.close()

というわけで触りだけ。

FitNesse+Selenium+Jenkinsによるテストケース継続的インテグレーションなんて素敵な匂いがしますな。

pythonで動かせるんだったらnosetestと一緒にごにょごにょすればそのままJenkinsと連携できそうな気もするが。

追記 11.10.14

でもって、selenium-server-standalone-2.8.0.jar

:::sh java -jar selenium-server-standalone-2.8.0.jar

ってな感じで起動しておいて、以下のスクリプトを動かす

って書いてたけど、Chrome使う場合は別に動かす必要なかった。

震災後に倒産しない法

支払いの優先順位

ProductName 震災後に倒産しない法
吉田猫次郎
サンマーク出版 / 1365円 ( 2011-05-20 )


  1. 自分の給料、生活費
  2. 社員の給料、生活費
  3. 税金
  4. その他の必要経費
  5. 借入金

借入金が後回しなのは勉強になった。よくよく考えてみれば金融機関もリスクを取るんだから当然か。