blohgってのが面白そうだったのでコードを読みつつ手元のmacbookにインストールして触ってみた。
sudo easy_install-2.7 blohg mkdir myblohg cd myblohg/ blohg initrepo hg commit -Am 'initial commit' blohg runserver
エントリを追加する場合にはcontent/post/にあたらしくrstファイルを追加してaddしてコミットする。
で、コード読んでたら
from werkzeug.contrib.atom import AtomFeed, FeedEntry
ってあって、werkzeugにフィード生成用の仕組みが用意されていることを知った。自分のブログ(Flask製)ではfeedgeneratorを使っているのだけど、こっちでもいいかなと思った。
おまけ
fujinismもblohgベースに変えようかなぁ
17082011 chemoinformatics work
創薬系ももっときちんとログをとって定期的に振り返る、それを細かいサイクルでおこなったほうがいいんじゃなかろうかという意味合いも込めてSAR Newsに寄稿したのが去年のことだけど、もっと知識管理全体をどうするのがいいだろうかと、ここ数ヶ月考えていたので、お盆休みを利用して少しまとめてみる。(なぜ数カ月考えていたかというと、4月にITサポートの部署に異動になったという大人な事情ですねw)
今回移った部署が管理しているインフラ自体は僕らが昔作ったものだが（ITっていう名前がついててもシステム開発できたり、まともなプログラミングができるわけではない。）異動後何回か面談してみても、現在の上司に最近の手法であるアジャイルを創薬システムに応用してみようとか、PDCA(創薬だとDesign-Make-Test-Analysisかな)とかそういう話をしても理解出来なかったし、だからといっていまさら勉強する気もないだろうからなぁ。
とはいえ誰かがそろそろ前進させないとまずいと思うので、異動した記念にでも夏の終わりにでも(2,3個役職飛ばして)振るだけ振ってみる予定なんだけど、他のヒトの役にも立つかもしれないのでエントリとしてまとめておきます。
Data, Information and Knowledgeに従って考えていくと都合がいい。というのは割とスパッと切り分けがしやすいから。図ではwisdomが頂上に君臨しているのだけど、よく見るのはData,Information,Knowledgeの三層構造なので、そっちで考えていく。
まぁ、どこの会社もデータのインテグレーションはやるでしょう。とくに実験データのトレーサビリティをどうするかは問題になると思いますができるだけロボットデータにタイムスタンプを付与するくらいはやっといたほうがいいですね。あと実験者に電卓を叩かせないでIC50とかそういう値まで自動的に計算するようにしたほうがよいですね。（実験者は意外にタイポが多い）でもこういった話は今回はどうでもいいので略します。データのインテグレーションは適切に行われているという前提なので最下段のピラミッドはクリアーですな。
データがインテグレーションされたら、次にやるのは分析ですね。分析は別にRでもなんでもいいけど、情報管理という意味では分析のスナップショットが取れる奴がよいですね。 Spotfireとか使うと分析の共有化（情報の共有化）ができます。
Information can be considered as an aggregation of data (processed data) which makes decision making easier.
なぜ情報が必要かというと、それは意思決定がしたいからです。確かにInformationの層をきちんとすれば意思決定は効率的に行えるでしょう。
ところで、意思決定とはなんであろうか？なぜ我々は意思決定をしたいのだろうか？
意思決定をするために必要なものは情報とあと何であろうか？を考えてみます。
合成した化合物が活性あったよバンザーイ（さくせん:ガンガンいこうぜ）とか、頑張って難しい合成こなしてみたけど活性なかったよショボーン（さくせん：いのちをだいじに）
これは意思決定をしているわけではないですね。
ある仮説を立ててそれが正しかった正しくなかったか、正しい場合より角度の高い仮説はどうなのか、仮説が正しくなかった場合どこに問題があって、それを証明するにはどうしたら良いか、つぎはどういう方向で攻めるべきか
そういう継続的な改善作業をコントロールする仕組みが必要なんだと思います。でも、これはInformationの層では管理できないので、Knowledgeの層になにか、(とても大切な何か)が必要なんでしょう。
Knowledge is usually based on learning, thinking, and proper understanding of the problem area.
It can be considered as the integration of human perceptive processes that helps them to draw meaningful conclusions.
知識も簡単に検索できてすぐに理解できるような必要があるが、慣習的に報告書の打ち出しやPPTの資料が必須のとこも多いと思うんだけど、探索コストのかかるフォーマットはどうなのかなぁと思うが。誰の得になるんだろうか？wikiでイイじゃんとも思うが。自分は実験報告書をwikiで管理してて、職場のwordのフォーマットでいつでもexportできるようにしてるので、便利だし昔やった仕事もパパッと探せて快適ですね。
Rocheのやつは経験の共有化に重点をおいてるっぽいような気がする。であれば、構造のハンドリングできるようにしたwikiにタグつけたり、検索エンジンを強力にすればいいような気がする。文章自体構造化してあるんだから、みんな大好きPPTとかWORDでもPDFでも出力は気にならないでしょう。あとはバージョン管理システムのいいやつ入れておけば良いんじゃないかなぁ。でもやっぱ文化醸成の努力が素晴らしかったんだろう。
GSKのほうはHDD（仮説駆動型ドラッグデザイン）を推進するようなものだったと思う。合成案を相互レビューできるようにしてあったかな。合成のヒトは合成案を否定すると人格否定と捉えるヒトが結構いるから、こういう仕組みっていいよなぁと思った記憶がある。
こういったタイプの経験管理というのは、ノウハウを共有化して、プロジェクトを効率化するとともに、個人に張り付いた知識を引き剥がし、職場全体の財産にすることができるのでよいのだが、あまりインスパイアされないのでやっててあまり楽しくはない。
ソフィーの世界の作者が別の著作で良い事書いてたので、よく引用してます。知識ベースっていうのはまさに前者ですね。
An answer is always the stretch of road that's behind you. Only a question can point the way forward.
stackoverflowっていうプログラマのためのQAサイトが良くできていて、クローンが幾つか作られています(OSQA,shapado)
うちではshapado入れてみて半年くらいたつのだけど、ユーザーはまだまだ少ないが質問も70を超えてきて結構楽しい。良い質問にインスパイアされると、より楽しいアイデアが浮かんだりするし、複数のプロジェクトで同じような問題抱えてると、部署で何とかすべき課題なんじゃないの？なんてわかったりするし。
結局、知識管理をも内包したプロジェクトを前進するための全てをきちんと管理し、知識が属人的になりすぎないようにしつつ、柔軟にリソースをコントロールするための全体的な仕組みを考えていきたいが、そのためにはプロトタイプを幾つか作ってみて反応を見ながら進めないといけないなぁと。
読書情報は属人的なものであるが、どういう論文を読んだか、それでどうインスパイアされたか、(自分の持っている情報と照らし合わせて)どこを否定したかといったblogっぽいブックマークサービスがあると便利です。ポイントは目録じゃなくて、それを読んでどう考えたかを記す部分です。ちょっと前に新しいのをつくろうとしつつ開発が止まっているが、なかなかモチベーションを保つのが辛い。
自分でつくってみて、音楽は曲のつなぎかた自体に意味がある(DJing楽しい)から曲名リストは意味があるけど、論文目録眺めても大して面白くない。リファレンスをたどっていきつつサマライズするようなサービスは面白いかもしれないが。
どういうツナガリに意味を持たすかだなーと思う。
Express+ChemDoodleというjavascriptライブラリ同士の組み合わせなんかもコンセプト的にも技術的にも面白そうな気がするが。あとHTML5とタブレットで色々変わりそうな気もしている。
こういったアプローチはソフトウェア開発業界の方が断然進んでいるので、そういった本を幾つか。できるだけ概念を説明しているようなのを選んでみました。
継続的インテグレーション入門 開発プロセスを自動化する47の作法
入門Git
16082011 栃木
鬼怒グリーンパークに遊びに行った。
幼児向けのアスレチックもあって楽しい
夜は、曾祖母さんの89歳の誕生日祝いをした。一方バアさんは急性の肝機能障害で入院していたのであった。つまり、実家に帰ったのは見舞いがメインなわけだが。
あおい亭ってとこに行った。息子はエビフライが食べたいってずっと言ってたのでエビフライを注文。右は僕のロースのステーキ
曾祖母さんは生中を飲み干し、フィレステーキを完食していた。恐るべし食欲。
家に帰ってから花火をした。ちょっとした手持ち花火でも中々楽しかった。
その後、酒を飲みながらベランダでぼーっとしてみたが、田舎はやはり田舎であった。秋の夜長の虫の鳴く音はノスタルジックだなぁ。
15082011 life
3次から攻めつつというか、庄内という地にタレントがうまく揃ったというのがうまく言った秘訣か。
本書を読んで、種とりの大切さと地場野菜を育てる必要性をなんとなく感じたので、自分の家庭菜園も種とりを積極的にしようと思ったが、種の選抜のコツとかよくわからんな。今度隣のおじさんに聞こう。
地産地消っていうのはフードマイレージを下げるっていうよりも、その土地ならではの食文化を大切にするといったほうが個人的にはしっくりくるなぁ。
13082011 Scheme javascript
JGPによるとjavascriptはCの皮を被ったLispだからLISPの作法にも慣れておくと良いと思うのです。というよりこのシリーズは面白いので読むといいと思います。
two-in-a-rowっていうリストの中に同じ値が隣あっているかどうかを調べる関数を定義する。
まずは相互再帰
(define two-in-a-row? (lambda (lat) (cond ((null? lat) #f) (else (is-first-b? (car lat) (cdr lat)))))) (define is-first-b? (lambda (a lat) (cond ((null? lat) #f) (else (or (eq? (car lat) a) (two-in-a-row? lat))))))
これを直接再帰に書き直す。
(define two-in-a-row-b? (lambda (preceeding lat) (cond ((null? lat) #f) (else (or (eq? (car lat) preceeding) (two-in-a-row-b? (car lat) (cdr lat))))))) (define two-in-a-row-2? (lambda (lat) (cond ((null? lat) #f) (else (two-in-a-row-b? (car lat) (cdr lat))))))
8/20にJGPの読書会@静岡があります。
13082011 javascript
今月は20日開催
12082011 sake
道の駅与一の郷っていうところで蕎麦食べてきた。ここの蕎麦はなかなか美味いですね。そのあと、隣の物産館にあるジェラート屋でデザートタイム。オレンジチェリーっていう食用ほおずきがおいしかったですな。
12082011 javascript
これはすばらしい、やる気度上がった。
あと、org-modeでHTML5なスライド作れるのか。
他にもスライドが公開されてた。こっちは初心者向けチュートリアルっぽい感じ
shizudevつくる会#2でswarmationで協力プレイをしてみたい
ちゃんとした酒屋によれなかったので、スーパーで適当に買った。
惣誉のほうはアルコール度数が18度と高めなのでオンザロックが美味いという変わった日本酒だけど、これは好みかも。一方天鷹の生酒はちょっとレトロっぽい感じがしたけど、結局良く飲んでた。
ついでに買ってきた水ナスの漬物をつまみながらクイクイと飲んだ。
あと適当に。
Redmineによるタスクマネジメント実践技法
継続的インテグレーション入門 開発プロセスを自動化する47の作法
入門Git
アブダクション―仮説と発見の論理
庄内パラディーゾ―アル・ケッチァーノと美味なる男たち
Scheme修行
JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス