Yokohama.pm #12 に行ってきた

先日、面白法人カヤックさんのオフィスで開催されたYokohama.pmに行ってきた。

Gazelleについて (kazeburoさん)

Starletの軽量高速版であるGazelleについて。

  • Starletと互換性あり。
  • reverse proxyの後ろ側に置く前提。
  • HTTP/1.0オンリー。
  • prefork型。

速さの秘密は。

  • keepaliveもサポートしないのでコードは超シンプル。
  • picohttpparser - H2Oでも使われているパーサ (kazuhoさん作)
  • accept4(2) - acceptしつつソケットオプションをセットする。
  • writev(2) - 複数のバッファから一度にソケットへ書き込む。

高速化にはシステムコールを減らすのとメモリコピーを減らすのが肝心なのだとか。

Mackerelについて (myfinderさん)

はてなのMonitoring as a Service "Mackerel"の活用事例。

Mackerelの特徴。

  • サーバに割り当てたroleごとにメトリクスをグラフに出してくれる。
  • roleを消さない限り、ホストをごちょごちょやってもグラフは継続。
  • CloudWatchは公式サポート。ほぼ勝手にやってくれる。
  • WebのUIからホストにroleを割り当てられる。
  • fluentd-plugin-mackerelとかある。

CLIツールからMackerelにデータ投げるために、WebService::Mackerelを書いたという話。

GoからPerlを使う話 (acidlemonさん)

PerlインタプリタC言語のプログラムに埋め込んで実行できる。詳しくはman perlembed。

また、Goはcgoという仕組みでC言語のプログラムを埋め込める。

ということで、Perlコードをcgo経由でGoから実行できる。

ただし、goroutineを使ってPerlコードを並行実行すると豪快に死ぬ。インタプリタの状態をぶっ壊してしまうらしい。

Perlコードの並行実行をするには、スレッドを有効にしてperlをビルドしないといけない。うーん、スレッドかあ。。

XSでSQLパーサ書いた話 (karupaneruraさん)

SQLダンプしてアーカイブしたユーザの行動履歴データを分析する必要が出てきたが、量が多いのでSQL::Tokenizerでは性能が足りない。そこでXSを使って自前で書いた。

XSモジュールを書くためのドキュメントやツールはそれなりにあるので、そんなに難しくない。

XS化して30倍くらいの性能が出たとのこと。

LT: YAPCについて (uzullaさん)

YAPC::Asia 2015の準備は既に始まっているんだという話。

アンケートはスゴい参考になるので是非書いて下さい! とのこと。

LT: Perlで作った社内基盤ソフトについて (papixさん)

GaiaXで使っているPerl製社内ツールの紹介

  • 公開鍵管理システム。公開鍵ファイルを中央管理し、各サーバが自動で公開鍵を取ってくる。削除にも対応。
  • サーバ監視。
  • 障害対応特化型チャット。障害ごとにチャットルーム作って、それがログに残るというのが特徴。あと、メンバーに一斉に電話をかけたりできる。

LT: Perlと本気で向き合いたくない人と向き合う僕ら (debug-ito)

地域pm初参加ではあったが、枠も空いていたしせっかくなのでLTをさせていただいた。

発表スライドはこちら。

内容としては、以前Qiitaに書いたこの記事の裏話、といったもの。LTとはいえ、他の方々に比べ内容的にもプレゼン的にもレベルの低いトークをしてしまったと思う。次に何か話す時があればもう少し聴衆の方々の興味を考えて練ってこよう。

ところで今回のスライドを作るにあたって超久々にLibreOffice Impressを使ったのだが、長らくPowerPointのリボンUIと機能を使ってきたせいで随分と使い方を忘れてしまっていて驚いた。慣れのせいもあるだろうが、やはり図形描画関連機能はPowerPointの方が優れているように思う。

LT: 横浜に住んで、横浜から離れて (yusukebeさん)

横浜といえばkazeburoさんという話。

LT: 正規表現lexerの話 (moznionさん)

正規表現の字句解析器を書いた(書いている?)という話。

字句解析器は構文解析器の前段なので、最低限の意味情報を返すべきである。しかし本当に最低限の情報しか持たないのでは意味がない。例えば返してくるトークンが全て「文字」クラスのトークンだったら、構文解析器にとって何の役にも立たない。

つまり、字句解析器には構文解析器が何を求めているかを推し量る思いやりが要求される。ただし、これを突き詰めると字句解析器と構文解析器が密結合してしまうのでそのへんのバランスが重要になる。

また、字句解析器は構文のvalidityを判定してはいけない、トークンにはできるだけメタ情報(トークンの位置とか)を含めるとよい、などが設計上のポイントになるらしい。