22102011 HTML5
衝突をHTML5で。
HTML5 Canvas: Native Interactivity and Animation for the Web本書は10章がPhoneGapの使い方なんだけど、まだそこまで到達してない(今5章)。
600ページ超えでサンプルも豊富な割に3000円を切る値段と安いのでコストパフォーマンスは高いと思う。 英語も難しくないし。
21102011 Scala
いろいろあってS-99への気力が削がれているので、Scalaの標準ライブラリを読み始めてみた。
Booleanオブジェクトにはbox,unboxメソッドがあった。
scala> Boolean box true res20: java.lang.Boolean = true scala> Boolean unbox (Boolean box true) res21: Boolean = true
Play! Scalaでなにかを作ってみたい。
20102011 coffeescript
for loopを二回かけたい場合。
つまりjavascriptではこんな感じのよくある2重ループ。
for (var i =0; i<a.length; i++) { for (var j = i+1; j <a.length; j++) { # なんか } }
こういうループを回したい場合はpythonでいうところのenumerateとかは必要なくて二番目の返り値にインデックスが返るっぽい（返り値の数をチェックしてんのかな？よくわからないが）
for el1, i in a for el2 in a[i+1..] #なんか
となるので、非常にわかりやすい。
20102011 Scala
こんなのをREPLで動かすと普通に動くんだけど
def sieve(s: Stream[Int]): Stream[Int] = Stream.cons(s.head, sieve(s.tail filter (_ % s.head != 0))) val ps = sieve(Stream.from(2)) println(ps.tail.head)
スクリプトで動かそうとすると、型が違うよって怒られます。
$ scala e.scala /Users/kzfm/scala/e.scala:4: error: type mismatch; found : scala.collection.immutable.Stream[scala.Int] required: Stream[<empty>.Int] val ps = sieve(Stream.from(2)) ^ /Users/kzfm/scala/e.scala:2: error: value % is not a member of Int Stream.cons(s.head, sieve(s.tail filter (_ % s.head != 0))) ^ two errors found
これはいったい何なんでしょう？
ubuntuの2.9.1.finalではエラーが出なかったが、mac osxの2.9.1.final (Java 1.5.0_30)だと出た。JDK 1.6.0_26+Scala 2.9.1だと動くという情報を頂いたので、javaのバージョンを上げてみたが、結果は変わらなかった。
よくかんがえてみればREPLで動かせば動くので、javaの問題ではない気はする。
それから以前、よくわからなかったIntじゃなくてScala.Intにしないといけない理由も同じあたりに問題があるような気がしてきた。
残るのはMacのバージョン(10.5)に問題があるのか、環境変数なんかおかしいかくらいしか考えられないが、同じような問題を抱えてるヒトをググってみても全然出てこないのが、自分固有の問題臭を漂わせているわけでなんかボケたことをやっている気がしないでもない。
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に関心があるなぁ。
Scalaスケーラブルプログラミング第2版
TOSHIBA REGZAブルーレイ ブルーレイディスクプレーヤー SD-BD3
Scala実践プログラミング―オープンソース徹底活用
プログラミングHaskell
Real World Haskell―実戦で学ぶ関数型言語プログラミング
パーフェクトJava (PERFECT SERIES) (PERFECT SERIES 2)
増補改訂版Java言語で学ぶデザインパターン入門
継続的インテグレーション入門 開発プロセスを自動化する47の作法