読者です 読者をやめる 読者になる 読者になる

Masteries

技術的なことや仕事に関することを書いていきます.

マイグレーションツール「Anego」をCPANにdeveloper releaseしました.

追記: Anegoの入門記事(使い方)をQiitaに書きました: Perl製のデータベースマイグレーションツール「Anego」入門

metacpan.org

以前からちまちまと作っていた, RDBMSのマイグレーションツール「Anego」を, developer releaseしました. ドキュメントもテストも全然書けていない状況ですが, とりあえずslaslaのマイグレーションは既にAnegoに置き換えていていまして, 現状いい感じに動いているっぽいです.

ちなみにGitHubはこちら:

github.com

何故作ったか

元々, PerlでWebアプリケーションを作っている時のマイグレーションは, GitDDLとかGitDDL::Migratorとかを使っていたのですが, 自分が使う範疇ではちょっとオーバースペックかな, という部分が多くて, 最近は@sugyanさんが昔書かれていたブログ記事, 「SQL::Translator::DiffでDBスキーマに追従させる方法」を参考に, プロジェクトごとに"オレオレマイグレーションスクリプト"を用意したりしていました.

memo.sugyan.com

...が, いい加減, 毎回毎回マイグレーションスクリプトをいちから用意するのが面倒になってきたので, モジュールとして切り出そう! という感じになって出来上がったのが, Anegoです.

昔, @songmuさんが報告されていた, SQL::Translator::Diffで変なdiffが出る問題も, 手元の環境ではこうやったら動く... という感じのアレではありますが, うまく動くように対応したりしています.

まだまだ荒削りですが, 興味があれば是非使ってみてください. また, 機能追加の提案やバグレポート, Pull Requestもお待ちしております!

余談

...ちなみに, 名前は@karupaneruraさんが開発されたORM「Aniki」にインスパイアされて付けました. 「姉御のように頼りになるマイグレーションツール」になったらいいな, という思いがこもっています(?).

SocketIO::EmitterがCPANで公開されました!

以前, PerlからSocket.IOのイベントをEmitするという記事で, PerlからSocket.IOのイベントをemit(発火)するSocketIO::Emitterというモジュールがあるという話をしました.

github.com

こちら, 作者の@toritori0318さんに「CPANで公開できませんでしょうか?」とお願いしたところ, 快諾頂きまして, 今後はcpanmやCartonで普通に使えるようになります.

metacpan.org

本当にありがとうございます!

注意点

以下, SocketIO::Emitterを使うにあたって幾つか注意すべき点があるので, 記しておきます.

SocketIO::Emitterとsocket.io-emitter/socket.io-redisのバージョンについて

SocketIO::Emitterは, socket.io-emitterのPerl実装ですが, socket.io-emitterは途中で大きく実装が変わっています. そしてSocketIO::Emitter/socket.io-emitterを使うにあたっては, Node側でsocket.io-redisを利用する必要があるのですが, これのバージョンについても考慮しなければなりません.

具体的には,

  • socket.io-emitter 0.2.0以前 + socket.io-redis 0.1.4以前 ... SocketIO::Emitter 0.01
  • socket.io-emitter 0.3.0以降 + socket.io-redis 0.2.0以降 ... SocketIO::Emitter 0.03以降

という対応になっています.

socket.io-emitter 0.3.0/socket.io-redis 0.2.0は2015年12月上旬にリリースされているので, それ以降に開発がスタートしたプロダクトであればSocketIO::Emitterの最新版を使っておけば概ね問題はないでしょう. それ以前からSocket.IOを使って開発しているプロダクトの場合, socket.io-emitter/socket.io-redisの1.0.0が2015年12月中旬にリリースされているので, タイミングを見計らってこちらに切り替えることをおすすめします.

SocketIO::Emitter 0.02について

tl;dr: SocketIO::Emitter 0.02は, socket.io-emitter 0.3.0以降/socket.io-redis 0.2.0以降に対応したバージョンですが, 内部で利用しているData::MessagePackのバージョンの都合でうまく動きませんので使わないでください

SocketIO::Emitter 0.01は, socket.io-emitter 0.2.0以前/socket.io-redis 0.1.4以前に対応した実装になっていて, その後Pull Requestを出させて頂いて, socket.io-emitter 0.3.0以降/socket.io-redis 0.2.0以降に対応したSocketIO::Emitter 0.02になりました.

...ところで, SocketIO::Emitterはその内部でData::MessagePackを使っています. これは, SocketIO::Emitterやsocket.io-emitterがイベントをemitするにあたって, 次のような仕組みで動作しているからです.

  • emitするイベントの情報をMessagePackでシリアライズして, Redisに投げ込む
  • 投げ込まれたデータを, Redisが配信する
  • socket.io-redisがRedisから配信されたデータを受け取って, デシリアライズする
  • この情報を使って, イベントの処理を行う

Data::MessagePackについては, つい先日新しいフォーマットに対応した0.50がリリースされていて, SocketIO::Emitterのリリースに向けて@toritori0318さんと相談している際, Data::MessagePackの0.50を利用するようにしましょう, というお話をしていて, 実際そのようになりました.

...が, 何故か手元の環境では, SocketIO::Emitterによるイベントのemitは成功するのですが, それをsocket.io-redisが処理する際, デシリアライズで失敗するという状況に. いろいろ調べていたところ, 次のような事情がわかってきました:

  • MessagePackについては, 古い仕様新しい仕様がある
  • Data::MessagePackの0.49以前は古い仕様, 0.50は新しい仕様に従って実装されている(っぽい)
  • socket.io-redisは, MessagePackのシリアライズ/デシリアライズにmsgpack-jsを使っている
    • npmにおいて, msgpack-jsは, MessagePackの古い仕様に従って実装されたものとして公開されている
    • npmにおいて, MessagePackの新しい仕様に従った実装はmsgpack-js-v5として公開されている

実際, 無理やりsocket.io-redisでmsgpack-jsではなくmsgpack-js-v5を使うようにしてみると, SocketIO::Emitter 0.02(Data::MessagePack 0.50を利用)でも問題なく動くことを確認できたので, MessagePackのシリアライザ/でシリアライザのバージョンというか, 仕様の違いが原因... のようでした.

今回は, @toritori0318さんに, SocketIO::Emitterが要求するData::MessagePackのバージョンを0.49以上に設定して頂いて, モジュールを使う側はcpanfileを,

requires 'Data::MessagePack', '== 0.49';
requires 'SocketIO::Emitter', '>= 0.03';

とする, という形で対応しました.

とはいえ, この場合, Data::MessagePack 0.50以降を使いたい, という場合対応できなくなってしまうので(自分たちの環境の場合, Data::MessagePackはSocketIO::Emitterのためにしか使わないので, これでも問題ないのですが...), socket.io-redisがmsgpack-js-v5を使うようになるか, 或いはData::MessagePackが"古い仕様"と"新しい仕様"の両方に対応するか... 辺りが必要なのかなあ, と思います.

まとめ

最近取り組んでいた, SocketIO::Emitterについてのまとめです. ちょっとこう, 雑多な感じがしたので, Qiitaではなくブログにまとめてみることになりました.

最後になりましたが, @toritori0318さんには, CPANへのリリース作業だけでなく, 0.02における原因調査など, いろいろお手伝いくださって本当に感謝しています. この場を借りて御礼申し上げます. ありがとうございました!

「共有会」, 「連絡会」の功罪, 或いはグループを横断した情報共有について

複数の事業(部署)を持つ会社, 或いは複数のチームを持つ部署において, 部署やチームといった"グループ"を横断した情報共有は, 非常に重要です.

特にエンジニア組織の場合, あるグループの課題を解決するソリューションを別のグループが持っていたり, 或いはあるグループの知見を別のグループが欲しがっていたりするものです. そのため, 会社が複数の組織を持つ利点, そして部署が複数のチームを持つ利点というのは, 適切な規模のグループで結果を出し, そこから得た成果物や知見をグループを横断して展開できるところにある, と思っています.

...とはいえ, この「グループを横断した情報共有」というのは, 言葉にすれば簡単ですし, みんな「そうあるべきだ!」と思うものだと思いますが, 実際にそれを実施していくのは簡単ではありません. 人間どうしても忙しくなると「目の前」, つまり「自分が所属しているグループ」のことで精一杯で, 他のグループのことを意識して動けなかったりするものです.

なので, 会社としては, 「グループを横断した情報共有が"当たり前"」という環境をつくり, それを部署や会社の文化にしていく必要があるのではないでしょうか. ここは賛否あると思いますが, 自分は「部署やチームの文化」の力は大きいと思っています. 「それ(今回の場合, "グループを横断した情報共有")っていいよね, 自分たちの強みだよね!」とみんなが認め, 明文化されて文化になると, 部署やチームにとってそういった行動をすることが当たり前になりますし, 新しく入ってきたメンバーもその姿を見て, 自然と真似ていくようになるのでは? と思っています.

ところで, 「グループを横断した情報共有」の一環として, 「共有会」や「連絡会」と呼ばれる集会を実施している会社やチームは多いのではないでしょうか. 開催間隔は会社やチームによってまちまちでしょうが, とにかく定期的に会社やチームの複数グループのメンバーを集めて, 最近の成果や近況報告などを行うといった取り組みです.

こういった「共有会」や「連絡会」という取り組みは, 短期的に見れば「グループを横断した情報共有」という成果に非常に貢献します. とはいえ, その「短期的な成果」だけで満足していいのでしょうか?

今回, この記事で伝えたいのは, 「共有会」や「連絡会」は, 「その先」を見据えて設計しなければ, 意味がないとまでは言いませんが, 効果は半減してしまうのでは? ということです. そして, ここでの「その先」というのは, 先ほど挙げた「グループを横断した情報共有が"当たり前"」の状況を作ることです.

もし, 「グループを横断した情報共有が"当たり前"」の状況を作るという未来を見据えず, 単に「グループを横断した情報共有ができる場所を作ろう!」という観点だけで, 「共有会」や「連絡会」という取り組みを実施すると, 大抵の場合, 「やったことは共有会で報告しておけばいいよね」とか, 「あー, ちょっとこういう問題あったけど, 明日連絡会だし, そこで連絡すればいいや」みたいになっていくのではないか? と思っています.

そうならないように, 会社の首脳陣(社長やCTO等)や, チームのリーダーは, 習慣とか, 文化とか, そういったレイヤーで「グループを横断した情報共有」について考え, 「共有会」や「連絡会」という実際の施策は, その習慣や文化の定着を推進する為の場所として設計しなければならないのではないでしょうか.

...まあ, この辺りも「言うは易し行うは難し」であり, 「具体的にどうすればいいんだよ!」と問われると「わからん...」という感じです. 自分は会社の首脳陣でも, チームのリーダーでもありませんが, この辺り文章化して, 頭の片隅においておけば, いつか良い考えが浮かぶんじゃないかなー, という気持ちでこの文章を書いた次第です.

この辺り, 各社いろいろな考えや取り組みがあると思いますので, Twitterやはてブのコメントで教えて頂けると幸いです. よろしくお願いします.

「Software Design 8月号」に記事を書かせて頂きました!

...というわけで, 「Software Design 8月号」のGitHub特集に記事を書かせて頂きました.

ソフトウェアデザイン 2016年 08 月号 [雑誌]

ソフトウェアデザイン 2016年 08 月号 [雑誌]

今回自分が担当させて頂いたのは, この特集の4章の部分です. 3章までは具体的なGitやGitHubの使い方が主ですが, 4章では「実際に, 企業でGitHubをどのように活用しているか」について, 私が所属しているGaiaxの事例をもとに書かせて頂きました. GaiaxにおけるGitHubの導入の経緯や, その際に行った様々な施策, GitHubの利用ルールや権限周りの設定についてだけでなく, ReactioチームにおいてGitHubをどのように活用しているか, などを書いています.

GitHubだけではありませんが, 新しいSaaSやツールを企業やチームに導入するにあたっては, 単に「アカウントを用意しました!」だけでは不十分だと思っています. 新しいSaaSやツールの導入を推進するメンバーが, 「こう使うと便利ですよ!」とか「こうやるといいですよ!」という感じで, 率先して「そのツールがある状態」というのを周りに見せて, 啓蒙して, 巻き込んで, その結果として「そのツールがある」状態を会社やチームに定着させて, 最終的には「会社やチームの文化」にしていく必要があると思っています.

今回の内容は, あくまでGaiaxにおける事例ではありますが, 「自分達のチーム/会社でGitHubを入れる時, どうやって進めていこう?」という悩みに対する, 1つのアドバイスになればいいな, と思っています.


ちなみに, この特集, @neko_gata_sさんも担当されていて, そのお知らせブログがめちゃくちゃいい内容だったので, こちらも是非お読み下さい.

だから、もし今この文章を読んでくれてるあなたが、プログラミングが好きで、なおかつアウトプットすることに興味があったりコミュニティに興味があるんだけど、それでもなんか一歩が踏み出せない、なんて状態で悶々としてるなら(そうじゃないならごめんなさい)、心配せずにその一歩を踏み出してみたらいいと思います。

nekogata.hatenablog.com

「Perl Hackers Hub」に寄稿した記事が技評のウェブサイトにも載り始めたみたいです

gihyo.jp

gihyo.jp

gihyo.jp

以前, WEB+DB PRESSの「Perl Hackers Hub」に寄稿した, 「PerlでInfrastructure as Code─IaaSやSaaSをコードで自動化」の記事が, 技評のウェブサイトで公開が始まったようです.

今年に入ってから, Software Designの「ChatOps特集」, WEB+DB PRESSの「Perl Hackers Hub」と, 雑誌に記事を書く機会をたくさん頂いていて, 非常に有意義で嬉しい限りです. 本当にありがとうございます.

そして実は最近またまた2本ほど, 記事を書くお話を頂いておりまして, 非常にてんやわんやしたりしております... こちらについても, また公表していいタイミングが来たらお知らせさせていただきます!