3年くらい放置していたけど、インフルエンザで一週間寝てたらついに読むものがなくなってしまったのでとうとう手を出してしまった。

結論、わけわからん。

海辺のカフカ (上) (新潮文庫)
村上 春樹
新潮社 / 767円 ( 2005-02-28 )

海辺のカフカ (下) (新潮文庫)
村上 春樹
新潮社 / 810円 ( 2005-02-28 )

この前の話をもうちょっとちゃんと書いてみる。

情報伝達とその重要度の軸としてはpush-pull,stock-flowというものがあって、pull,flow象限に対応する媒体に周知事項を流すとかpush,stock象限に対応する媒体にブロードキャスティングなお知らせ情報を送りつけるとかは良くない。

あともう一つ、data-knowledge,stock-flowという軸も考えられる。知識ベースを作りたいという欲求はどの組織にもあると思うんだけど、そういう場合基本的にpullな媒体を使うことになると思う。

はてブのブックマーク自体は単にデータだし、コメント昨日は単なる意見の集合体だから知識とは言えない気がする。 あとtwitterも似たような感じだけど、なんとなくフォロワーを選べば知識に近い情報が流れてくることが多いのでまぁ有意義かなと思う。

掲示板システムみたいなのは議論が発散しがちだし、まとまらないのであんまり好きじゃない。

お手軽に書き込める掲示板システムみたいなもので知識ベースを作りたいっていうニーズを良く聞くんだけど、結局うまく行ったものを見たことないのは、データしか流れなくて知識の蓄積というところまでいかないせいだと思う。あの仕組みで上手くやるためにはキュレーター（かモデレーター）が必要なんだろうなぁと。

でもそれってキュレーターの主観とかはいるし、togetterはそういう部分透けて見える時があるから、ああいうのは本質的に難しいんだろう（査読論文も一緒だと思うし）

というわけで、今のところsofの仕組みが良く出来ているなぁと思うわけだが、母数が大きくないとあの仕組みがうまく動かないのが悩ましいところ。イントラQAシステム入れて、1000人以下の規模でも上手く動いている例があったら知りたい

シカ肉は自分で調理してみると結構臭いなぁとイズシカを扱ってみて感じた。肉屋のおじさんは唐揚げにすると美味しいって言ってたけどその通りだと思った。

• 結構血なまぐさい
• 脂感が少ないからぱさつく

っていうのが大きい理由なのかなと。

で、シカ肉を上手く調理するための本があったので読んでみた。

いけるね!シカ肉 おいしいレシピ60
松井 賢一
農山漁村文化協会 / 2268円 ( 2015-06-05 )

シカ肉調理は前処理が大切らしい

• 60-70度の湯で湯がいて血が溶出したお湯を捨てる
• 加熱は弱火でじっくり
• 肉のカットの仕方

参考になった。

一方で、料理の写真は残念すぎたのとレシピは平凡すぎて普通の肉をシカ肉に替えただけのレシピがほとんどだった。特に写真はプロに頼めばいいのに…全く作る気にならんぞ、あれは。

追いインフルってやつを経験した（インフル自体も今まで経験した覚えはないが…）

結局土曜の夜からずっと寝ていた。当初は微熱が続いてだるいだけだったので月曜日に病院行ったら風邪だと診断されてグダグダしていたら、火曜の夜に強烈な喉の痛みと高熱が襲ってきて水曜日に再度通院したらインフルエンザAだった…

そのままイナビル注入したけど、高熱が治らなくて頭痛のせいで眠れず12時間後くらいに38度を切ってきた。朝はちょっと熱があったけど、起きたときには36度台になっていた。

イナビルすげーなと思った。

それから鎮痛剤はロキソニン、ロブ、カロナール

を試したけどロブよりロキソニンのほうが効き目が強い感じがした。カロナールはイナビル投与後に服用したけど全然熱が下がらなくて辛いままだった。

年末に虫垂炎が再発したし今年はなんか病気にかかりやすい気がするので体力づくりに励まないとあかんのかなと思っている。

一度年末に調整したのですが、タイミングが合わずにこの日にやることになりました。Shizdevのほうでも人工知能まわりをやっているので今回は共催となります。

• Shizuoka.py #6 and shizudev

python使いが静岡東部に多い+コミュニティFの利用料金が無料なのに綺麗という理由で最近のShizuoka.pyは富士でばかりやっていましたが、流石に他の地域で美味しいものを食べながらの懇親会をしなきゃなという理由で今回島田開催です。

尚、懇親会場は決まってないのでリクエストがあれば@fmkz___か@yajuまでよろしくお願いします。

島田のとなりの金谷には大井川鉄道があってSLが走っているので、鉄成分高めの方は満足するんじゃないかなぁと思います。僕は鉄成分がホメオパシー並に薄いのですが五和で撮ったとき(connpassの写真、今回は料理ではない)には「SLウォー！！！！」ってなりました。五和の中屋酒店に行った時にたまたま遭遇したんだけどねｗ

今の会社は完全にプル型メディアの文化でそれはそれですごくやりづらい。

というのは周知案件すらもわざわざ全社のお知らせページにアクセスしないといけないという文化だからだ。入社日の人事オリエンテーションの際にも「見逃さないように！」って念を押されたしｗ　周知案件を個人に任せるってどういうことやねんって疑問に思った。

で、前職は逆にプッシュ型メディア寄り過ぎだったなーと思った。なんでもかんでもメール。周知案件はメールで来るからいいけど、ゴミみたいな情報量もメールで送られてくる。結果、未読が貯まりすぎて重要なメールを見落とすことが多くなりがちな文化だった。マネージメント職は未読の数が多いほど仕事しているって感じだったｗ　1000件未読とか普通にいたなぁ。

で、そういうのが嫌なスマートな世代はイントラRSSリーダーとかを上手く活用していて、今の会社に移った際に一番最初に入れようとしたのがFastladderなんだけど、今の会社がRSSフレンドリーじゃないので入れてもちょっと使いづらい（イントラRSSとか完備されていないから）

という感じなので最近ちょっとイントラtwitterクローンとボット群を作っていて、 あー、これってゆるいRSSリーダーだったんだと認識した自分が新鮮だった。

プッシュとプルってのは対立するもんじゃなくて、ツールを上手く噛ませば効率的な情報共有手段になるのかーと感じたのであった。

会社の同じグループの人達と幸村ホルモンに行ってきた。

ここは、ある程度焼いた状態で出てくるので、焼いたり寄せたりという焼肉にありがちな間接業務（マネージメント職）から解放される。

ホルモンミックスはコブクロ、センマイ、ハツ、トントロなどの盛り合わせがいい感じにのってやってくる。右側はハツとカルビとミノだったかな。

上カルビ。これで終わりと思いきやまさかの４回転目ｗ　多分カルビとミノ

３時間半くらい食べ続けたの笑えるｗ

初めてグループ飲みに参加したけど、飲むより食べる派だということが判明したのでちょっと自分のペースを保たないといけないなぁと。僕は食べるより飲む派です。

電車通勤楽しい

tychoのライブで品川に泊って、次の日に築地かなぁと思ったが、ほぼ直通で京成立石に行けることが判明したので、うちだでしょう。

煮込みとタン生

梅割りとアブラタレヨクヤキ（呪文）

ガツ塩とおしんこう

ナンコツたれとシロタレヨクヤキ

満足

不思議な漬物が色々紹介されていてなかなかおもしろかった。尚、農家向けなので量がとんでもない（納豆一キロとか）

別冊うかたま 農家が教える 至福の漬物 2013年 04月号 [雑誌]

農山漁村文化協会 / ?円 ( 2013-03-29 )

納豆のベッコウ漬け

納豆(10)、米麹(5)、スルメ(2)、昆布、塩、水を混ぜて漬ける。10日くらいから食べられる

菊芋の味噌漬け

菊芋を味噌で漬ける。菊芋って買ったことないわ

ピーマンのぱりぱり漬け

ピーマン、キュウリ、唐辛子、醤油、味醂、ごまを混ぜる

うどの三杯酢漬け

ウドを三杯酢に漬ける

結論は出ていないけど、面白いかなと思うのでメモっておく。まともなコードを書ける人が何人もいるところに移ったのでアウトプット（プロダクト）に対するフィードバックも早く且つ適切なので自分の生産性も非常にいい感じだし、考えるための材料もどんどん溜まって楽しい(イマココ)。

今のところ足りないのはせっかく電車通勤に変えたのに健全な往復をしているところ。もっと寄り道して飲んだり、飲みながらハックしないといけないと思っているｗ。

さて、創薬プロジェクトの進捗の把握のためのシステムを考えた場合、 とりあえず先行しているソフトウェア業界のベストプラクティスを製薬業界に応用するのが自然かと思う。

• 継続的インテグレーションを創薬系のプロジェクトにあてはめてみる
• Quantifying, Visualizing, and Monitoring Lead Optimization.

普通に考えると構造最適化プロジェクトってのは典型的なTDDだと思う。スクリーニングフローがまずあって、それをパスするようにケミストは構造最適化を行い、全てのアッセイをパスするものが前臨床に進んでいく。だからパスしないアッセイをリスクと捉えてリスクゼロの化合物の取得を目指すのがプロジェクトの意味だ。

プロジェクトを外側から評価する立場としては全く持って正しいし、そういう方向で見える化するべきだと思っていたが、実際にある程度実装してみたら異なる意見が出てきてなるほどなーと感じた。

きっかけは、テストしてない構造がfailになっているのがおかしいのでは？というケミストからのメールだった。TDDやアッセイをリスク払拭と考える立場だと、passしない限り全てfailと考えるのは正しい。彼らの言い分は明らかにパスするようなアッセイ系なのでスキップしているので、failにされるとプロジェクトの進捗が実際よりも悪く見えて気持ち悪いという話であった。もう一点はゼロに近づくほどいいという指標は如何なものか？という意見。

まぁ、確かにと思ったので、ここら辺に関してよく考えてみた。

スクリーニングフロー

ソフトウェア開発では通すべきテストをきちんと書いて、それをパスするコードが正しいのだろうけど、スクリーニングフロー自体にはそこまでの強さはない。地図に対するコンパスのようなものか？つまりスクリーニングフローはケミストが進むべき方向を指し示すものといったニュアンスが強く、柔軟に対応すべきものと考えるべきなのであろう。だからアッセイしてない化合物がfailになることに対して気持ち悪さを感じるのかな。

リスクをゼロにするという考え方

ケミストは「よりよい化合物を作ってそれを次のステージ（前臨床）に送り出す」という感覚が強いように思う。そうだと、リスクゼロの化合物が前臨床入りするという価値基準では合わないような気がする。スコアが高いほどよい構造だという指標を導入したほうが納得性が増すのではなかろうか？でもそういう指標ってぱっとは思いつかない。

以上、メモだけど今後考えていくべきことの一つかなとは思う。上手い答えが出せればいいなぁ。