19102011 life
息子が傷のつきまくったDVDを入れたりトレイをガチャガチャと手荒にあつかった結果HDDレコーダーをぶっ壊した。
それにも関わらずDVDを見たいとのたまうので、息子の誕生日プレゼントと銘打って安いBDプレーヤーを購入。
19102011 life
息子が傷のつきまくったDVDを入れたりトレイをガチャガチャと手荒にあつかった結果HDDレコーダーをぶっ壊した。
それにも関わらずDVDを見たいとのたまうので、息子の誕生日プレゼントと銘打って安いBDプレーヤーを購入。
18102011 life
17102011 家庭菜園
スティックセニョールは半分枯れてた。補充すべきか放っとくべきか悩む。
にんにくは芽が出てきた。

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

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

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

16102011 Scala
本書は、Perlでいうところの「モダンPerl入門」またはPythonで言うところの「エキスパートPythonプログラミング」に対応する感じの中級を目指す人向けの本ですね。なお、Scalaだけでなく色々な言語をかじっていれば楽しく読めるので良いですね。
一通り読んでみて、5,6,7章が良かった。10章はあとでゆっくり(今継続やってもあれなので)。あと、標準ライブラリのソースも読んだほうがいいなと。
文法等の話はコップ本等で補足しながら読まないとよくわからないんじゃないかと。逆に言うと、コップ本の後に読んだ時にきちんと理解しているかどうかの確認としてよろしい。個人的にはコンパニオンオブジェクトとか、補助コンストラクタ、パッケージオブジェクトあたりの説明が役に立った。あと2.8-2.9の新機能紹介。
関数型プログラミングに関して。基本的な内容だったのでサラっと流して最後のほうだけ。
カリー化による部分適用はプレースホルダー構文による部分適用よりも柔軟性が低い
Haskellで引数の順番を入れ替えるflipっていう関数はあるけど、プレースホルダー構文のほうが楽ですね。
4-1とHaskellとの比較が大変参考になった。それから4-2のStructual SubtypingとNominal Subtypingの話はわかりやすかった。もう少しScalaを使ってみないときちんと理解してるかどうか不安な部分もあるけど。
とりあえず、sbtを入れてみた(0.11.0)けど、本のバージョン(0.7.5)のように起動時にディレクトリのスケルトンは作成しないようだ。?ってなったので調べたら0.7系と0.10系は結構変わってるらしい。まぁ、直接ドキュメント読みながら覚えていくからいいかなぁと思った。今、エディタはEmacs使って書いてるけど、そのうちEclipseに移行するのかなぁ、わからんなぁ。テストはなんかプロジェクトを作ったら使うけど今のとこは小さいサンプル動かしてるだけなのであまりそそられてない。
Play!が面白そうなので只今絶賛いじり中
Javaのデザパタ本をScalaで一回書いておくのがいいかなと思った。それからScalaのためのデザインパターン(Loan,Concept,Cake)は勉強になった。Cakeはいまいち飲み込めてないけど、あとで手を動かして考えてみる。
流し読んだ
Actorは軽く流してあったが継続は30ページ超えという。なぜか継続はワクワクしますな。ちゃんと読んでないのであとでゆっくり読む。
Scalaをある程度知っているのが前提だと思われるので。
Haskellも基本的なところは抑えつつRWHくらいまで読んでおいたほうが吉ですね。ちなみにプログラミングHaskellは名著なので練習問題も含めて一度は解いておくべきでしょう
Javaは知らんが、個人的にはパーフェクトJavaでも買おうかなと思っている(パーフェクトJavascriptがとても良かったので)。
デザパタ知らないヒトはいないと思いますが、読むならこれですね。
16102011 work
自分の職場ももっと継続的なインプルーブメントが必要だろうなぁと思っているが、なかなか難しいですね。まぁ、ああいうのは地道にやるしかないのかねぇとインテグレーション入門を読みなおした。
CIは単に技術の導入にとどまらず、組織やその組織の文化にも変化を及ぼす
第一部はCIの背景や、原則、プラクティスについて書いてあるので、ソフトウェア業界じゃなくても色々参考になります(といってもソフトウェア業界のCIを知らないとよく分からないかもしれないが)
というわけで、自分の置かれている業界(製薬業ですね)におけるCIとはどんなもんかねというあたりをメモっておく。
ちなみに第一部の各章はこんなタイトルです。
以下、用語に関しては特に説明しないが、創薬系におけるバージョン管理というものはどういうもんだろうかとかは考えたことがあるので参考に。
バージョン管理リポジトリの目的は、アクセスが制御されたリポジトリを用いることによって、ソースコードや、その他(ドキュメントなど)のソフトウェア資産に対する変更を管理することである。これによって、一ヶ所からすべてのソースコードが入手できる「唯一の入り口」が提供される
創薬プロジェクトにおける資産とは何だろうか(というよりどこまで管理すればいいのだろうか)?という問いに閑する答えはシンプルで、プロジェクトを進めるために必要な全てですね。特に実験データに関してはロボットデータまで管理する必要があって、IC50とか中途半端なデータから管理してると、ある日突然シボンヌしますね(データの正しさが担保できない)。
それから、実験プロトコールや、報告書もプロジェクトにおける重要な資産なのできちんと管理する必要があるだろう。プロトコールのような手順のほかにBDDっぽい何か、つまりプロジェクトにおけるビヘイビアのようなものも必要だろう。
ソフトウェア開発のようにレッドからグリーンを繰り返すサイクルとは異なり、いつか成功するかもしれない失敗を繰り返すから、基本的には常にレッドである。創薬プロジェクトは探索的なタスクが多く、イシューを細かく切ったとしても、それぞれが相互に強く依存しているために、常に手戻りが起きる危険が発生する。
そのため、インテグレーションとかビルドの考え方は大きく異なってくるが、どうしたらいいかに関しては自分の考えが固まっていない(だから文章におこしてるわけだが)。
よくありがちな創薬プロジェクトっていうのは
の順にそれぞれ閾値を決めて、多段フィルタリングのイメージでゴールに向かって進んでいく。上で書いたように基本的には成功(閾値を超える)するかもしれない失敗を繰り返しながら後半のアッセイ系に進む確率を挙げていくわけです。
基本的にアッセイを繰り返すことにより、そのアッセイ系での成功確率は上がっていくわけですが(あがらないのももちろんあるがそれはサイエンスとして理解できてないとか本質を捕まえてないと表現する)後ろのほうでイシューが出てきて合成方針が変わると、最初の方のアッセイ系の成功確率ががくんと下がることがよくある。
というわけで、フローとして流すのがいいのか、幾つかのアッセイを並行で流して多次元最適化を行うのがいいのかはコストの制約とか、プロジェクトの性質で決まってくるのだと思うが、プロジェクトスタート時にはどういう組み方をしたらいいのか不明だし、大体、デフォルトのプロジェクトフローをまわしやすいように組織が最適化されているので、なかなか難しいですね。
結局創薬におけるインテグレーションってのはプロジェクトのどの粒度でナニを達成するのかをもっと突き詰めて考える必要がある。バージョンの考え方と、前進しているってのはどういうことかっていう定義が必要なんだろうなぁ。
インスペクションは種々のアッセイ結果を解析していく上で得た理解、つまり薬剤候補としての化合物の性質の許容の範囲ということになる。こういう情報はコミット時(または合成に着手する前)にアラートとしてフィードバックされるべきものであろう。
推測するな計測せよっていうのは創薬プロジェクトにおいてもやはり至言で、ウェット(実験系)のヒトは実験結果を解析しないで雰囲気でいい加減な解釈をするヒトが多い。たんに散布図とるだけでも、いい加減な解釈してるとバレるんだけど、受け取る側のケミストも裏取りしないで素直に受け取るので、一緒に泥沼に突き進んでいく光景が散見されて微笑ましい(こういうのはうちだけの問題ではないだろう)。
ただし、これはヒトの問題で片付けないで、システムとしての問題として考えるべきことであろう。根拠としてのプロットを明示するような規約を用意するだけでもこういうアホなやりとりはだいぶ減るだろうし、自動的にプロッティングを用意するシステムにすればなお良い。そういう状況でも治らない場合は組織的な病気なので伝染る前に前に移ることを考えましょう。
テストは試験です、つまり人力です。ソフトウェア業界ではどんどん追加していくわけですが、創薬プロジェクトではプロジェクトが始まった段階で既にテストが存在しています(逆にテストがないとプロジェクトが始まらない)。テストは基本的にコストのかかるものであり、ある段階で新たなイシューが発生した場合に新たなテストを組み込むかどうかは大きな意思決定を伴うし、新たなコストが発生しますね。
1,4,5は創薬プロジェクトでも同様なことが起こり、有用であろう。2の手作業はちょっとわからないが、手順をきちんと決めることでアウトソーシングできるとかであれば、コスト削減と、コモディティ化という意味で意味があると思う。
3は創薬プロジェクトにはデプロイに相当する仕事がないからあまり関係ないかも。
個人的には4,5に関心があるなぁ。
この前の勉強会でJenkinsについて色々知った。JenkinsってJava向けだろうと思ってたら全然違って基本何でもいけるらしい(シェルから動かせるから)。あとgithubのプロジェクトもいけるらしいので早速pygamessっていう量子化学計算用のモジュールを使って試してみた。
最近GAMESSを仕事で使うことが多いんだけど、きちんとテストしてないと不安ですからね。
さくっと導入するならTraclightningがいいらしいんだけど、Jenkinsを単独で入れた。macだとパッケージをダウンロードして実行するだけでlocalhostの8080に常駐するので楽ちん
あとは、Gitのプラグインを追加でインストールしておく。
Pythonのテストといえばnoseですね。あと、Python版のPerl Testingみたいな本ないのかな?
Perl Testing: A Developer's Notebook (Developers Notebook)JenkinsとPythonの連携を参考にした。まずはnoseとunittest-xml-reportingをインストールしておく。
あとはJenkinsの設定のシェルの実行っていうところにnoseのテストを書いておく。
nosetests -v --with-xunit -w tests
これでnosetests.xmlっていうファイルにテスト結果が出力されるようになるので、JenkinsのオプションのJUnitテストの結果集計というところにチェックを入れて、nosetests.xmlを追加しておく。

4つテストを走らせて、1つFailしている。
これは環境変数とかの問題で、gamessの実行ファイルがきちんと呼び出せてないせいで、テストがこけているんだけど、Jenkinsのほうにエラーの内容が吐かれてないのでどこでこけているのかつかめていない。
そもそもrungms使うのが間違っているのかなぁ。あとでよく考える。
15102011 Perl yapcasia yapcasia2011
スピーカー、スタッフの皆様お疲れ様でした。今年は一日目しか参加できなくて懇親会も出られずに帰ってしまったけど大変充実した一日をおくることができました。
聴いたセッション
個人的にはフェライト会議室のパスワード保護からperl meets beatsまでの一連のセッションが面白かった。
@kyannyさんの Rubyist のための Perl ウェブアプリケーション開発入門を聞きながら、dotcloudサインアップした。Node.jsで書いたwikiがあるので動かしてみようかと思った。あとperlで書くならMojolicious::Lite使おうかなぁと。今メインで使っているFlaskもSinatraクローンみたいなもんだし、最近使い始めたExpressもそうだしね。
パルモン
use strict!出社!出社!出社!出社!
最高でした。
楽しみにしてたトーク。@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の誰かに聞いてみよう(っていうか誰かハンズオンやってくれないかなぁ)。
HTML5 Canvas: Native Interactivity and Animation for the Webと、色々刺激になったYAPC::Asiaだった。
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と連携できそうな気もするが。
でもって、selenium-server-standalone-2.8.0.jarを
:::sh java -jar selenium-server-standalone-2.8.0.jar
ってな感じで起動しておいて、以下のスクリプトを動かす
って書いてたけど、Chrome使う場合は別に動かす必要なかった。
12102011 life
支払いの優先順位
借入金が後回しなのは勉強になった。よくよく考えてみれば金融機関もリスクを取るんだから当然か。