Zabbixでメールを送信出来るようになるまで

一昨年くらい前の静岡インフラ勉強会で紹介されてたzabbixが良さそうと思って書籍を購入したんだけど、購入後放置していた。

最近やっと使い始めたら、便利なんだけどメールの送信設定でハマった。

がtwitterのzabbix界隈の人達のおかげで設定できた。zabbixユーザー層厚い。というか厚いのはいいことだ。それから、職場のネットからはtwitterが遮断されているのでiPhoneでやり取りすんだけど、zabbix界隈の人達の助言がなかったらどんだけ時間をムダにしたんだろとか。

まぁ、それ以上にうちのIT部署は死活監視なんて使ってないんだけどねーw

zabbixのほうの設定

メールを送るのに

  • サーバーの設定:管理 ->メディアタイプでメールサーバーの設定をする
  • ユーザーのメールアドレス登録:管理 -> ユーザーでユーザーのメールアドレス設定
  • アクションの設定:設定->アクションでメール送信の設定

と3つの段階を踏む必要がある。ちなみに二番目の設定を忘れていた(わかりにくい)。ちなみに、ここまで設定してもメールが送信できなかったのではまった。

トラブルシュート

まずはエラーログってことで/var/log/zabbix/zabbix-server.logを覗いてみるもののなんも出力されてないのでイラッときた。エラーが出るのは想定内だけど、エラーログが出ないのは想定外なんで、ああいうのでイライラするのは環境に慣れているせいかもと思った。

ここから、twitterのzabbix界隈の人達の助言にお世話になりっぱなしで。

  • Administration -> auditをみる
  • eventの時間をクリックしていってログをあたる

とエラーが見つかるということを知った(今回の場合後者だった)。ログによると permission denied (13)っていうエラーでメールの送信ができていなかった。

あらかじめ、telnetでメール送れることを確認してあったので、permission deniedがでるのは謎だったのだけど、若干悩んだ挙句SELinuxが有効になっていることに気づきdisabledにして無事送信できるようになった。

管理->メディアタイプorユーザーの設定のところにテスト送信をするという機能がついていればこれほど悩まず解決したのにと思った一方で、悩んだおかげで多少詳しくなったからまぁいいかなぁと。

スクラムとは何か(アジャイル開発)

僕の場合アジャイル開発という大雑把な括りで理解しているので、具体的な開発手法名はなかなか覚えにくい、というよりそれすらちょっと抽象的な表現なので分かりにくいと言ったほうが適切か。

スクラムとは、会社を機能単位に分割した階層や組織ではなく、どこをとっても会社のビジョンに向かった判断・行動パターンを共有する自己相似の知識創造活動であり、それを実践する人びとである

本書を読みきれば、上の定義があーなるほどと理解できるようになる。あとは、自分のフィールドに翻訳する必要があるのだが、カルチャーを変革する系の手法なので、ボトムアップな取り組みだけではうまくいかないだろうし、上の理解が必須かなぁと思った。なのでマネジメント層に読んでもらいたいなぁと。

  • アジャイルは顧客満足を実現する手段であり可能性のひとつ
  • アジャイル開発では知識の外部への伝播が語られていない(これは欠点)
  • PDCAのPの前にはSECIのSを置くべき

スクラムを実践するには組織を変えていく情熱が必要である

これがなー、厳しい。リーンスタートアップみたいなやり方は時間がかかるしなぁ。

第三部の「アジャイルと開発とスクラムを考える」の野中郁次郎先生の考察が非常に深かった。アジャイルでは知識の外部への伝達が弱いのは技術者の流動性が高すぎるからだと考察している。流動性がそれほど高くない僕のいる業界なんかでは暗黙知の共有とか形式知化なんかは非常に重要なことなので、本書のオリジナルの論文(日本の製造業)と対比しながらの考察は理解が非常に深まった。

以下、製薬業界用メモ。

ユーザーストーリーのフォーマット

  • <ユーザーの役割>として
  • <機能>が欲しい
  • なぜなら<機能の価値や目的>だからだ

動態担当として、logPを下げてほしい、なぜなら膜透過性が改善するからだ

みたいな、なぜ今そういう化合物を作っているのか?というストーリーを張っておかないと、振り返った時に個々の化合物が合成された背景を掴めないし、そのやり方がうまくいきそうかどうなのかが外部から判断できない。

ケミストの「うまくいったから、結果としてうまくいったんだ」というようなくだらないトートロジーに付き合わされるのはかんべんしてほしい、というのはみんなの願いであろう(ケミストそれ自身の願いでもある気がするw)。

プロダクトバックログ

プロダクトバックログとは、実現するかもしれない未来の詰め合わせである。創薬的には合成してもいいかなぁと考えている案のリストと考えることができる。リードオプティマイゼーションにおいてはそういうアイデアリストをプロジェクトごとにまとめて管理して確度の高そうな案から作っていくというやり方がプロジェクト的に理想的かなと思っているんだが5年くらい前からトライしているんだけどうまくいっていない。色々理由はあると思うんだけど知財的なことを考えると誰が作ったかが重要視されるのでまぁしょうがないのかなぁと。

とか考えるとUK-QSARでみかけたAZのスライドはまさにバックログを実装していてすごいなぁと。

空洞化のウソはウソなのかホントウなのか

空洞化のウソ / mark-wada blogで触れられていて気になったので読んでみた。

筆者は新興アジア推しの現地化推し。

著者は空洞化を3つに分解する

  • 雇用の現象
  • 国内技術水準の停滞
  • 海外で稼いだ金が国内に還流しない

雇用の減少

筆者は現地化すれば企画立案部門とか新規開発部門のような付加価値の高い分野に雇用拡大(国内)できると論じているが、これは案にブルーカラーは仕事がなくなると言っているようなもんですね。逆に国内の教育も付加価値の高い人材をつくることに焦点をあわせないといけないが、実際はそうなっていないから、ホワイトカラーの人材も国内外問わずに取ってこないといけないでしょう。

まぁこうなるわな。

国内技術の水準の停滞

こっちのほうが重要だと思うんだけど、現場と離れたところに企画立案部門をつくると官僚化しておかしくなることが多いと思うが、開発力だって落ちていくでしょう。

第一三共とランバクシーの話が出てたけど、創薬知らなすぎなヒトの考えるストーリーだよな。コレに関してはお話にならない、イノベーションが求められている部分がそもそもずれているので。

お金の還流の問題

「日本入っている」戦略で現地化をうまくやってという話は正しいのだろうなと思う。結局人口分布に基づいた戦略は必要になるしなぁ。

お金の流れ的には空洞化していないってのが正しくて、雇用と技術に関してはどうなのかな?っていう印象。

というより、空洞化しているかどうか議論するということが些細な事なのかなと。

あわせて読みたい感じの対談

ビッグデータの衝撃というよりデータ分析の仕事が重要になるよっていう話

ビッグデータとは

  • Volume(データ量)
  • Velocity(データの生成頻度)
  • Variety(多様性、構造化できないという意味も含む)

のいずれか、またはそれらの組み合わせ。

構造化できない大量のデータがリアルタイムにどんどん生成されていくような状況だと、RDBに収めにくいし、処理するのにも新しい技術や手法が求められるということ。

ProductName ビッグデータの衝撃――巨大なデータが戦略を決める
城田 真琴
東洋経済新報社 / 1890円 ( 2012-06-29 )


本書では上に書いてあるビッグデータは狭いと考えていて、データ処理技術、ヒトを含めた組織まで含めてビッグデータとして捉えているが、そっちの話は分析力を駆使する企業のがずっと詳しいし、分析という観点から書いてある。

分析が先なのか、データが先なのかという話に関していえば、優秀なデータサイエンティストを有していればデータを与えれば意味のある分析結果がドンドン精製されてくるが、分析するヒトがいなければデータ生成はムダなコストにしかならないので、分析(者)ファーストだろうなと。

「Data is the new oil」とは良い例えだと思う。結局精製技術次第だし。あとは原油にあたるようなデータの入り口付近にいる業者も有利なんだろうな。

CROSS 2013でデータサイエンティストのセッションがあったみたいですね。

イノベーションを生みだすために必要なこと

リーン・スタートアップを読んだ。

リーン・スタートアップとは、スタートアップの成功確率を高める方策を集めたものである。

アイデアよりも実行すべきかどうか

「この製品を作れるか」と自問したのでは駄目。いまは、人間が思いつける製品ならまず間違いなく作れる時代だ。問うべきなのは「この製品は作るべきか」

検証できない仮説は意味ないですね。ただモチベーションを上げる手段としての仮説はアレだよなぁと。

ユーザーストーリーは検証による学びが得られてはじめて完結だと考えること

創薬プロセスももうちょっとこういったことを意識しないと駄目だろうなぁと思うが。

リーンスタートアップにおける製品開発プロセスでは「行わなければならない実験をプル信号としてそれに反応する」と考えるべきだ

ピボットのタイプに種類があることを知った。

  • ズームイン型
  • ズームアウト型
  • 顧客セグメント型

高速文字列解析の世界が素晴らしかった

丸4日かけて8章(最終章)以外を読んだ。正月休みの後半の時間をこの本を読むのに費やしたのは正解だった。新年開始早々、知的な満足感が得られた。

本書を読めば、BWT、簡潔データ構造、ウェーブレット木、FM-Indexが理解できる。

LF-mappingのところ(p.28の補題3.4)を理解するのに時間がかかったが、これを理解できればFM-Indexのアルゴリズムが理解できる。ついでにWavelet Matrixも理解できた。ひとつひとつ丁寧に読み進めていけば理解できるようになっていたので良かった。

本や論文で書いてあるなら、まず読んで知っているのが必要条件(slide 24)と著者のスライドに書いてあるように、BWT、簡潔データ構造、ウェーブレット木、FM-Indexは知らないといけない知識になるんだろうなぁと。

pubmed調べたら、bioinformatics用途でしかみつからないのでchemoinformatics方面で応用できたらいいなぁと思った。

その他

  • LZEndはちゃんと理解していない
  • Boyer-Mooreは昔やった

簡潔データ構造

4章

簡潔データ構造は、操作が高速でありながら作業領域量が小さいという2つの性質を兼ね備えたデータ構造であり、データ圧縮と索引の技術が組み合わさったものである

完備辞書(FID)

  • access: B[i]を返す
  • rank:B[0,i)中のb∈{0,1}の数を返す
  • select:B中で伝統から見てi+1番目に出現したb∈{0,1}の位置を返す

p.48の式がo(n)ビットに抑えられていると書いてあるのだが手で計算して確かめていない(ので後で計算する)。 (13.01.05 libcdsのチュートリアル読んだら理解した)

簡潔木の説明がさらりとしすぎてあまり触れられていない気もするが、本書においてあまり重要でないってことでいいのかな(全体を読んでみないとわからない)。

それから読んでいて索引が貧弱だなと思った。RRRとかselectとか引けない。

2012年に読んだ本

今年読んだ本で良かったもの。

すごいHaskellたのしく学ぼう!

これはピカイチだった。RWHで停滞感が漂いまくっていた僕のHaskell理解力がかなり上がったのは間違いない。そういえば、最近Haskellしか書いてないなぁと2012年のエントリに付けられたタグを数えたらHaskell 90, Python 70, javascript 44だった。

ProductName すごいHaskellたのしく学ぼう!
Miran Lipovača
オーム社 / 2940円 ( 2012-05-23 )


あとはtwitterで色々教えてもらったりとか、三島Haskell無名関数の会が出来てモチベーションが上がったりとか色々タイミングが良かったということもあるが。来年も引き続きハスケりたい。

型というか、閉じている、自己同型といったイメージは数学ガールが良いかも

ProductName 数学ガール ガロア理論 (数学ガールシリーズ 5)
結城 浩
ソフトバンククリエイティブ / 1995円 ( 2012-06-01 )


チケット駆動開発

自分の仕事にアジャイルな要素を入れたいというのはここ数年ずっと考えていて、やっと来年すこし取り組めそうで嬉しい。

僕のチケット駆動に対する期待は、創薬研究への応用なので、チケット駆動開発の背景にある考え方がぎっしり詰まった本書は、色々な発見や再発見があったり、今の仕事のアナロジーを見つけたりとかなり満足度の高い本だった。

ProductName チケット駆動開発
小川 明彦
翔泳社 / 3444円 ( 2012-08-24 )


今年システムを少し運用してみて、意識の高低のバラツキを吸収する仕組みとしてゲーミフィケーション的なものも考えて行かないといけないし、受動的な情報伝達手段も考えて行かないといけないなぁと感じた。

(そもそも潜在的に)意識の高いマネジメント層は、能動的に情報アクセスしない研究者層(というより労働者層)が存在することを理解できないので、「そんなのホームに登録しておけばいいだけなんんじゃないか?」なんて言うんだけど、それすら能動的な情報アクセスなんだよなぁ。

デジタルサイネージのようなものにも手を出してみたい。

ProductName 幸せな未来は「ゲーム」が創る
ジェイン・マクゴニガル
早川書房 / 2940円 ( 2011-10-07 )


JavascriptとTitanium Mobile

今年はクライアントサイドのMVCも熱かった。去年Javascriptを勉強してた時には、まさかiPhoneアプリの方に進んでいくとは思わなかったが。

ステートフルJavaScriptはjavascript MVCフレームワークの本でSpine.jsの解説に近い。そしてこの知識はTitanium MobileでJavascriptを使ったiPhoneアプリ開発で役立つ!

AlloyはTitaniumのためのMVCフレームワークでBackbone.jsを使ってつくられている。これを使うとjavascriptを利用してiPhoneアプリとかAndroidアプリが作れちゃうわけだ(下のエントリ参照)。

バージョンあげたら実機転送がうまくいかなくなって、最近は停滞気味ですが、来年はもうちょっと力を入れて取り組みたいと思っている(なんかアプリをリリースしたい)。

それから僕はCoffeeScriptが好きなので使っていますが、他にもNode.jsのテンプレートエンジン(Jade,eco,ejs)なんかも使えるので好みの開発スタイルを探求するためにCoffeeScriptやNode.jsの入門書もあわせて読んでおくとよいかも。

ProductName サーバサイドJavaScript Node.js入門
清水俊博
アスキー・メディアワークス / 3990円 ( 2012-10-26 )


過去に読んだ本

創薬プロジェクト版Git(Chemit)を思いついたので実装してみるかな

redmineはGitのようなVCSをセットにして使うのが当たり前なので、創薬系でもそのようなバージョン管理システムがあればいいなぁと思っている。

現状の化合物管理データベースは履歴管理をしないし、コミットログに対応するものも記録できないので、単なる構造データ管理としてしか機能しないが、化合物管理データベースのフロントにwikiかそれをモディファイしてコミットログとか履歴管理に対応する機能をもたせたものを用意すればやりたいことができそうだ。さらにAPIを用意してcliのラッパーとかpython,rubyバインディングを用意すればredmineと連携させやすいだろう。

logでログとかコミットツリーが出て

$ chemit log
commit C0000123
Author: ChemistA <XXXXX>
Date:   Sun Aug 19 10:05:53 2012 +0900

    improve solubility

commit C0000122
Author: ChemistB <YYYYY>
Date:   Sun Aug 19 10:04:58 2012 +0900

    reduce clogp  fixes #24

commit C0000121
Author: ChemistA <XXXXX>
Date:   Sat Feb 4 09:02:58 2012 +0900

代謝安定性を改善 fixes #23

それから

$ chemit diff C0000121 C000123

と打つと構造の差分とMCSが表示されようなものを作ってredmineと連携できれば素敵じゃないかなと思ったので、実証用のコードを書いてみようかな。

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


明日の資料の元ネタあたりをまとめてみた

創薬のためのメトリクスとかアジャイル開発手法の応用みたいな内容を話しますが、資料の中ではコンテクストや背景や動機なんかを端折ってるために、全体像がつかめないかもしれないので、参考になりそうなエントリをまとめておきます。

アジャイル開発とか継続的インテグレーション(CI)

アジャイルとはなんなのか?

モチベーションマネジメント、ゲーミフィケーション

成果主義を例に出すまでもなく、組織を活性化するためには賃金による報奨は必ずしもいいとは限らない。承認欲求に訴えるためにはどうしたらいいか?

加えて暗黙知を形式知になりやすくするようなカルチャーをつくるにはどうしたら良いか?といったこともシステム設計として考えていく必要がある。

リーンとかトヨタ生産方式とか

生産のアナロジーが使えそうな仕事または労働時間と生産性が比例するような仕事。参考書籍は沢山出ているので乱読すればよいでしょう。

リポジトリとしての化合物データベース

ELNは単に紙の実験ノートを電子化すればいいってもんじゃなくて、もっとリポジトリへのアクセス端末としての設計を考えなきゃいけないんじゃないの?とか思う。 認証だとかPart11対応だとかはバックエンドのデータベースの問題であってそんなのイノベーションとは関係無いだろ?と思っているのでELN界とは距離を置いてる。