/var/log/azumakuniyuki

猫ポーカーって単語を思いついたので、現時点で確定しているルールを書いておこうかと思います。

とは言え世の中、人口の八割は猫好き(80％が猫好き・残り20％は未だ猫好きになっていない人々)なので、既に正式な「猫ポーカー」がルールと共に存在するのかも知れないのですが、ざっくり調べた限り、そういうのは見つかりませんでした。

後で先発の猫ポーカーのルールが発見されても良いように、いちおうここでは京都ローカルな猫ポーカーとして思いついたルールを記すことにします。

もはやライフワークみたいになっているわけですが、二月にバウンスメールを解析して構造化するライブラリ"Sisimai"(シシマイ)のRuby版(Gemも)をリリースしました。bounceHammerの後継者として開発したPerl版シシマイの妹分みたいな存在です。

Ruby版はいろんなPaaSでも動かしたいという要望と、僕がRubyにも慣れておきたいという願望のもと開発をしました。Ruby版を作ったのでPerl版は捨てるということはなく、現在も新機能や精度の向上に関する実装は、Perl版で実装してからRuby版に移植する形で開発をしています。

おっさんなのでMakefileが好きです。好きな理由としては`make`がキーボードで打ちやすい点、`make`というコマンド名がシンプルで美しい点が特に気に入っています。

とは言え、僕はC言語で何かを書く機会は殆ど無くなり、今やコンパイルの手順や依存関係の記述には使わなくなりました。しかし、C言語を書かないからといって`make`が無用の長物である事はなく、寧ろいつも実行する作業(コマンドとか)の自動化という点で役に立つ場面があります。

去年の明け頃からAnsibleを使い出して、去年の春ごろから仕事でも充分使えると判断して、今はサーバを構築するのは全てAnsibleでPlaybookを書いて構築→保守という流れが確立しています。とはいえ、他社と共同管理であるサーバも多く、構築完了から時間が経過した後に最初に書いたPlaybookを実行して、Playbookに反映されていない変更が巻き戻るという管理上の問題がありました。`ansible-playbook --check`での検査で何故かChangedになるタスクがあったり(これは僕の書き方が悪いのかも)して、テスト目的ではServerspecを使う事を検討し、実際に使ってみる事にしました。

結論としては、Serverspecは充分使えると判断してAnsible Playbookで実行した内容のテストをServerspecで記述して、構築完了後〜何か変更を加えるときに毎回`rake`を実行するという形が合理的であるとの解を得ました。

となると次は、ディレクトリ名からホスト名を得るServerspecにAnsibleのインベントリファイルを読込んで、対象とするホスト定義を共通化したいと思いました。最終的な目的は、Ansibleのインベントリファイルのみでホスト定義をしてServerspecもそれを読み、AnsibleのBest Practicesに従ったディレクトリ構造の中にServerspecのテストコード用ファイルを入れる事で、それを達成する為にRakefileを改造しました。

今年の夏ごろ、正確には8月16日にシシマイの最初のバージョンをリリースして丁度一年が経過しました。

今年は(も)YAPC::Asiaに行けなかったので残念極まりないところではありますが、今年でYAPC::Asiaが最終回という事もあり、また先週からタイムラインがYAPC::Asiaの話題で占められているのを毎日見て、ここはひとつ僕が最初に参加したYAPC::Asia Tokyo 2010の思い出を書いておこうかと、筆を取りました。

少し前に「InstargramでFollowerを増やすのってどうすれば良い？」って意図の質問を貰いましたというか聞かれました。

そもそもTwitterにしてもInstagramにしても余程の有名人でない限り、あるいは炎上しない限り、そうそうFollowerが増える事はないと思います。

とは言え、質問されたので思い当たる事を答えたのですが、後で考えてみてやはり次の3つが肝になってくるような気がします。なので、タイトルはFollowerを増やす方法って釣り気味にしましたが、正攻法であり爆発的に増えるわけではありません。

昨日、12月13日(土)は第一回なにわPerlに行ってきました。場所は今までのPerl入学式 in 大阪でお世話になっているJoe's Cloud Computingさん、大阪駅前第四ビルです。さすがに今まで何回も行っているので、大阪で迷わずに行ける数少ない場所の一つです。

なにわPerlは専門用語で言う「もくもく会」ってものなのですが、僕は「もくもく会」ってのには行った事がなくどんな感じやろかってのもありました。主催者はPerl入学式第一期生であり首席で卒業(私見)して現在はサポータをしてくださってる@tomcha_さんです。

Perl入学式 Advent Calendar 2014の12月12日(金)の記事です。昨日の記事は@toku_bassさんの「cpandocべんりってはなし」でした、perldocにcpandocと一次資料に簡単にアクセス出来るものがあるって便利ですね。

さて、僕は普段京都に住んでいて、Perl入学式 in 大阪のサポーターとして参加しています。とはいっても毎回参加出来てるわけではなく、学校の校庭にたまに現れる野良犬みたいな頻度でしか登場しないので、あんまり貢献出来てないなぁと思ってはいます。

12日目の記事は「プログラミング言語を学ぶということ」ってテーマで、本来なら校長が卒業式の壇上で長々と喋るような内容になるのかもしれませんが、(書き終わってから)なりました。

四ヶ月振りに書く記事です。

平成26年の冬ごろから開発をして、夏ごろに"Maikugi"って名前でリリースしようと思っていた次期 bounceHammer の中核となるモジュール部分ですが、方針を大幅に変更したりコードの大部分を書き換えたり、解析結果の形式を変更したりで、新たに"Sisimai(シシマイ)"という名前で世に出す事にしました、というか出しています。

モジュールとしての開発はある程度落ち着いた気がするので、纏めを目的とした覚書きと宣伝も予て一旦ブログに書いておくことにしました。

2014/11/11(火): 新しいエラーメール解析モジュールの記事「次期bounceHammerの中核モジュール"Sisimai"」を書きました。

本日、七月十七日は祇園祭山鉾巡行と神幸際です。今年から祭本来の姿に戻すという事で前祭(さきまつり)と後祭(あとまつり・七月二十四日巡行)に別れます。まわりが山鉾に囲まれているので、前祭の鉾立が始まる10日から後祭の巡行がある24日まで人が多くて外出するのも一苦労です。

さて、祇園祭の頃に完成予定のつもりで二月ごろからMaikugiという名前でエラーメールの解析モジュールをPerlで開発していまして、今日はそれについて少し書いてみます。

冬ぐらいからAnsibleを触りだして、春ぐらいにはいろいろとPlaybookを書いて実戦投入するようになり、夏ぐらいには新しく作るサーバは全部Ansibleで構成出来るようになるかなぁというところまで来ています。

PlaybookはBest Practicesに従ってなるべくRoleに切り出して書いて、ansible-playbookコマンドの引数となるファイルで、各Roleを実行する順序で並べて構成しています。

ただ、Roleに分けたファイルはBest Practicesに従ったディレクトリ構造に収まるので良いのですが、それよりも上をどういうディレクトリ構造で管理しようか、という点で冬から春にかけていろいろ試行錯誤をしていて、最近やっと自分の中で固まってきた気がするので、ブログにでも書いておこうかと思います。

2015/09/30(水)追記: この記事は古くなりました。もう少し改良したディレクトリ構造とServerspecとの共存について「AnsibleとServerspecでインベントリファイルを共通化した」を書いていますので、そちらをご覧ください。

今年度のPerl入学式 in 大阪 #1のお手伝いに行ってきました、土曜日に。前年度の最終回は急に入った出張で東京に滞在していたので行けなかったのですが、今回は新年度の第一回であり、環境構築という一年を通して最も嵌まりどころが多いであろう回なので、借りてきた猫の手程度の働きとは言え、サポータ層を分厚くしておいた方が良いというのもあり、大阪まで行ってきました。

今日、三月七日はbounceHammerの4回目のお誕生日です、おめでとうございます。Version 2.0.0としてオープンソースでリリースしてから四年が経ちました、ケーキとかは特に用意していません。

去年の秋にリリースした2.7.11でほぼ完成というか、安定したものとなっているのですが、経年と共にいろいろと問題点や修正しにくい不具合、それに実装しにくい機能追加要望が出てきていまして、それらをまとめて解決すべく、現在Tonkachiという名前空間でVersion 3.0.0を開発しています、やはりPerlで書いています。

コミュニケーション手段としてのメール(SMTP)はほぼ死んでいるような気もしますが、通知手段としてのメール・IDとしてのメールアドレスはまだまだ死んではいないので、続編の開発をする事にしました。

Hainekoの纏まったドキュメントは思いつきで取ったドメインであるhaineko.orgに日本語と英語で書く予定ですが、すぐに出来るわけでもないので、現時点でのHainekoについて、いろいろちょいちょい書いていく過程の二回目、リレーサーバの定義について書きます。

今日書く内容は、Hainekoの要というか基礎となる部分であるリレーサーバをどう定義するかについて、二つのファイル: mailertableとsendermtを中心に紹介しようかと思います。

去年の夏ごろから作ってたHainekoを大晦日にCPANにアップロードしました。HainekoというのはHTTPサーバとして動いてJSONでPOSTされたメールを指定したSMTPサーバやメールクラウドにリレーするという代物なのですが、現時点でHainekoに関する最新情報は昨年渋谷であったShibuya Plack/PSGI Conference #1で発表した資料とgithubに置いているリポジトリのREADME-JA.mdです。

細かい説明まで含めるとREADMEに収めるには量が多い感じなので、ドキュメント類は思いつきで取得したhaineko.orgに纏めてそのうち置く予定ではありますが、開発開始〜今日に至るまでちょいちょい仕様が変わっているので、一旦全体的な概要を書いておこうかと思います。

11/30(土)にはてなさんで開催されたMonitoring Casual Talk in Kyotoに参加してきました。近所なので歩いて10分ちょいです。これまで参加してきた全ての勉強会で、「参加するからには何か喋る」事を信条としてきましたので、今回もLTの枠を一つ貰って喋ってきました。

仕事はインフラとかサーバ周りを扱う事が多いし、経験年数も長いので喋るネタはなんでもいけるやろと高をくくっていたのですが、実際に題材を選ぶ段階でお客さんのところのデータとか事例とか、さすがにそのまま出せない、かなりぼかしても特定可能なものは避けるといった感じで取捨選択していたら無難な、かなり過去の話からしか引っ張ってこれませんでした。

11/20(水)はたまたま東京へ出張する予定が合ったので、たまたまその日にLINEさんとこで開催されるShibuya Plack/PSGI Conference (shibuya.pl) #1に参加してLTでHainekoの話を少しだけ発表してきました。

YAPC::Asia Tokyoを除けば初めての東京で開催されるPerlの勉強会参加です。

Plackは以前から名詞として認識してはいたのですが、何であるか正しく理解していませんでしたし、また今年の夏から手を出した事もあり、良い機会なので勉強会があるなら参加するか、と決意した次第です。

去年は宗教上の理由(法事)で行けなかったYAPC::Asia Tokyo 2013に前夜祭から行ってきました。

応募したトークは残念ながらと言うか概要がアレで落選したのですが、前夜祭のLTソンと本編LTへの参加、Perl入学式のお手伝いに行ってきました。

いつも新幹線で通過するだけの神奈川県に初上陸、東京に近い大都市やから超高層ビルが林立しているイメージがあったのですが、そうでもなくて意外にのどかな感じでしたし、宿の近くに猫も居ましたし、今回も楽しい祭でした。

この前、仕事で移転作業をしたサーバを監視する為にmuninを入れたのですが、対象サーバで動いている pgpool の値を取得するプラグインが動かないので、いろいろ調べて最終的に雑なパッチを当てる事でちゃんと値が取れるようになりました。なのでその覚書きです。