ワークショップの話を先に進めたいので皆さんで集まって飲みましょうってことで、初めて集まって飲んだ。

色々面白い話が聞けたのだけどそれはこっちに任せた。

前菜頼んだくらいで、あとは飲み続けたのでコスパ高かった。空芯菜の炒めものを見ながらもっと茎のあたりをガッツリ切ってもいいのかと勉強になった（あと葉っぱも減らして茎だけでいいやと）。うちはモロヘイヤも空芯菜も先っぽしか収穫しないので贅沢な使い方をしているなぁと思った。

ワークショップの内容

土日の二日間で組んでみました。

土曜日午後（使ってみようRedmine）

• インストールから使ってみるまでのハンズオン
• アジャイルとかスクラムといった背景思想を簡単に説明
• プロジェクトの合成での利用例
• HTSでの利用例
• ソフトウェア開発での利用例

日曜日午前（もくもくと軽いトークを混ぜたもの）

もくもくと好きな事をやってもいいし、普段聞けないことを聞いてもいいような軽い感じの質疑ができるようにします。

• Gitの使い方
• RDKitのすすめ
• Flaskでウェブサービスの作り方

何故二日の日程にしたかというと、ベアードビールは昼飲みでしょ!という当たり前の理由はおいておくとして、遠くから来る場合に交渉しやすくする意図もあります。

会場のすぐそばにある楽寿園は動物園とか遊戯があって子供だったら、半日ぐらいは余裕で遊べますし、散歩用の道が気持ちいいので大人がぶらぶらしても楽しいです。日曜日はソフトウェア開発よりなのでその日は参加せず、ひと駅先の沼津から沼津港に向かって深海水族館でもよって沼津港で美味しいものを食べても家族サービスとしていけてますし、修善寺とか熱海のほうをぶらついてもいいかと。尚、土曜日のみだったら東京から日帰りも余裕です（三島は意外に近い）。

つまり、プチ家族旅行を兼ねることでwin-winの関係が築きやすくなるわけですねｗ。早めに三島に入ってお昼に鰻をたべるというのももちろんアリだと思います。

もし興味があれば10月の前半の週末は空けておいて下さい。参加募集ページができたらまたご案内します。

ソフトウェアのワークショップに参加してきた、というより発表してきた。

発表は全て面白かったし、懇親会でも色々とフィードバックをいただけたので満足。

私のスライドから

• accelrysのMMPスライド
• ChEMBLからMMPの前処理するスクリプト
• d3.js
• Redmine
• VAMMPIRE

それからMMPのカットのやり方が気に入らないという質問を受けたのでメモっておく。この時もちょっと考えさせられたけど、あそこの会社のヒト結構おもろい。

• PPの切り方はナイーブすぎて気に入らない
• RECAP等のメディシナルケミストフレンドリーな切り方をしたい
• RDKitだったらもう少し柔軟に対応できるはず

プロジェクトで使うにはカットのやり方こだわったほうがいいかもしれない、あと置換ルールとして持っておきたいもそのほうがいいでしょうね。

というわけでRDKitのコード追いかけようと思ったら先行者がいたので、エントリ待ちで。

(2013.07.28追記) エントリきた

メディシナルケミストのredmineの使い方をちょっと聞いたんだけど面白くて勉強になりそうなので、今度話してもらおうかなと思っている。帰ったら日にちを調整しようっと。おおっぴらに公開しないでライフサイエンス系限定みたいなATNDないかな。

ここから駄文

（お前が言うなと自分で自分に突っ込みをいれつつも）志は高く持ったほうがいいよねとは思う。それから大きな挫折を味わないために小さな挫折をくり返すってのも大切かなと。結局は自分というスタートアップをマネジメントする感覚ですね。

それから、ヒトにフォーカスするとイライラするのでもっとカルチャーにフォーカスするように心がけています。以前の上司がPから移られた優秀なメディシナルケミストの方で、よく文化の醸成ということを口にされていたのでなんとなく背中を見て学んだ感じです。意識高い感じで書いておくとヒトとの出会いは大切ですねｗ

先週の自分の発表の時、Hさんに複数のMMPを同時にふるようなやり方はうまくいくのか聞かれて、難しいのではないかと直感的に答えたのだけど、お昼寝しながらあの答えで正しかったのかなぁと考えていた。

というより、ゴロゴロしながら考えていたら寝てしまったのだけど。

MMPでコアの構造を考えなくて良いとした場合には再帰的にフラグメントの置換が可能になってしまうので、ちょっとこまる。メチル基3つつけたら3倍の効果がでるかと言われればそれは難しいんじゃないのと。

クラシカルなQSARやれるような場合はそれぞれのフラグメントの効果は独立だからうまくいくんだろうなと思う。

つまりフラグメント-フラグメント相互作用とかフラグメント-コア相互作用なんかを考慮しなくていい場合にはうまくいく感じがする。

FBDDやる場合にはフラグメント-コア相互作用として歪のエネルギーを考慮していますね。

pychembldb使えば楽勝だというということの証明をしようと思ったが、意外に面倒くさかった。

• ヒトのアッセイ系
• 信頼レベルマックス(Direct single protein target assigned)
• アッセイのタイプはBinding

という条件でデータを引っ張ってくる。その後構造数<2のファイル（MMPにならない）を削除して、メタデータ(アッセイID, Uniprotのアクセッション番号、一般名称、データ元のジャーナル)を吐き出したあと、活性データをTSVに出力するようにしている。

最初はsdfのほうに活性情報も付けておけば楽勝じゃないかと思ったが、スキーマ見てたら測定タイプが正規化されてないうえに、AssayじゃなくてActivityのほうについてることに嫌な予感がしたので調べた。

やはり、pIC50とIC50が混在してたり、InhibitionとIC50が混在していた。

これはペアに出来ないので僕の場合はpandasでゴニョるのでこうしましたが、PPのスキルが高まっていてこっちでやれるのであればsdfに活性入れておいたほうが取り回しやすいかも。

コードはexamples/recreation.pyにあります。ファイル名があれなのは今朝コードを買いている時にスーパーカーを聴きまくっていたからというわけなので察してください。

IC50とKiのトレンドをChEMBLのデータセットから探るという論文を読んでいたら、データ抽出のフィルターにconfidence level == 9を入れていたので、これは何かなぁと。

>>> from pychembldb import *
>>> for c in chembldb.query(ConfidenceScore).all():
...   print c.description
... 
Default value - Target unknown or has yet to be assigned
Target assigned is non-molecular
Target assigned is subcellular fraction
Target assigned is molecular non-protein target
Multiple homologous protein targets may be assigned
Multiple direct protein targets may be assigned
Homologous protein complex subunits assigned
Direct protein complex subunits assigned
Homologous single protein target assigned
Direct single protein target assigned

これはキュレーターが付与してるのかな？ そうだとしたらかなりありがたい分類だ。

Direct single protein にアサインされているアッセイ数を調べてみる

>>> from pychembldb import *
>>> c9 = chembldb.query(ConfidenceScore).filter_by(description="Direct single protein target assigned").one()
>>> len(chembldb.query(Assay).filter_by(confidencescore=c9).all())
76773

こんな感じで

from pychembldb import *
for a in chembldb.query(Assay).filter(AssayType.assay_desc == "Binding").distinct():
   a.description

去年辺りから色々思うところがあって、ここのところまとめていくつか社外発表したし、原稿も書いたしでそろそろアレかなぁと思っていて腑抜けみたいなみたいなノリで過ごしてたのだけど、先週、他業種の方々と色々と話をする機会があって、結局のところ自分は無理ゲーを言い訳にしてなすべきことをなしてないだけじゃないか！と自省したので、創薬にredmine的なものを持ち込むところまでは頑張るか頑張るまいかと悩み始めたのであった。

-> ハードモード(残機1)でもう一回
-> 次のステージへ
-> 違うワールドに進む

というあたりで悶々していた一週間だった。そんなわけでちょっと創薬系のエントリ連投というアクセス数を確実に減少させる悪手を繰り返していた。

自分の技術力がそれなりにあがったのと、ライブラリとか充実してきてて、チーム組まなくても独りでそこまでは到達しそうかなぁという感触がつかめたというのが1つ、いきなりredmine的なものを持ち込もうとしても上手くいくチャンスがゼロなので、仕事をやり慣れている今の職場で見ておいてもいいかなというのがもう一つ。それからAstraZenecaが似たようなことをやっていてDjangoで構築しているらしいので、PythonistaとしてFlaskでやり遂げなければならないという謎の使命感に燃えたという事情もあってredmineの導入と動き出すところくらいまではコミットしようかなと。

「一見した創薬知識の総量が多い少ないなんて気休めにもならねぇ」「活性の解釈なんてたゆたってて当たり前、それが創薬プロジェクト」「だが、、、それでも」「100％成功させる気でやる」「それがフルスタック創薬インフォマティストの気概ってもんさ」

イマココ

注）今月かまってくれた皆様には非常に感謝しております。

かなり前に創薬プロジェクト版Git(Chemit)というCLIなアプリを思いついたのだけど、化合物データベースへのSQLAlchemyラッパー用意したり、色々ツールを揃えたおかげで簡単に実装できるようになってたので、近いうちに作っとこうかなぁーと

で、chemit diffはMCSとか買いてたけど、これはMMPの間違いだった。

Redmineによるタスクマネジメント実践技法
小川 明彦
翔泳社 / 3444円 ( 2010-10-13 )

アッセイ結果から生データへのトラッキングというかトレーサビリティには気をつかうのに、合成化合物から合成案(何を目的とした合成なのか)までのトレーサビリティには注意を払わないのは如何なものかと。

というわけで、今は「この化合物は一体何を意図して作られたんだ？！」というような疑問がフツフツと湧くようなシステムを作っている。

VAMMPIREという

1. PDBの複合体構造からリガンドを引っ張ってきて
2. ChEMBLからMMPをサーチして
3. ドッキングモデルを構築してWebGLで表示する

っていうDatabaseの論文をみつけたのだけど、コンテキストが入りまくりなのはどうなのかなぁ？タンパク質-リガンド相互作用を骨格の多様性で積分したら普通ゼロになるよね？実用性に疑問符がと思ったが、

ふと、あーFMOの題材としてはいいんじゃないのかなぁと閃いた。置換基変換のペアとKi差や活性差の値が出ているからFMOのエネルギー比較して色々遊べるかな。

仮設駆動デザインを強く主導しているっぽいAZの論文読んでて、そういえばDjango製であるところのDesign Trackerの論文って見たことないなぁと思って探してたら、すでに購読しているBlogの著者が開発者だった。しかもOpenEyeにジョインしているのか。

というわけでこの本超読みたい。

Open Source Software in Life Science Research: Practical Solutions in the Pharmaceutical Industry and Beyond (Woodhead Publishing Series in Biomedicine)

Woodhead Publishing / ?円 ( 2012-12-28 )

The book is divided into four parts. Part one looks at laboratory data management and chemical informatics, covering software such as Bioclipse, OpenTox, ImageJ and KNIME. In part two, the focus turns to genomics and bioinformatics tools, with chapters examining GenomicsTools and EBI Atlas software, as well as the practicalities of setting up an ‘omics’ platform and managing large volumes of data. Chapters in part three examine information and knowledge management, covering a range of topics including software for web-based collaboration, open source search and visualisation technologies for scientific business applications, and specific software such as DesignTracker and Utopia Documents. Part four looks at semantic technologies such as Semantic MediaWiki, TripleMap and Chem2Bio2RDF, before part five examines clinical analytics, and validation and regulatory compliance of free/open source software. Finally, the book concludes by looking at future perspectives and the economics and free/open source software in industry. - See more at: http://www.woodheadpublishing.com/en/book.aspx?bookID=2830#sthash.n8wZvfrs.dpufOpen source software in life science research

特にDjangoを採用した経緯がちょっと知りたかったりする。日本の製薬企業の研究所の規模程度だったらFlaskで十分な気もする(maxでも3000userくらい捌けばいいんでしょ？)が。

でもやっぱDjangoはあつかえるようにしておいたほうがいいのかなぁー、悩む。

次々回のShizuoka.pyで誰か入門Djangoとかやってくれないかなぁ。