Masteries

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

｢みんなのGo言語｣を読みました

9月9日に発売された｢みんなのGo言語｣を, いろいろなご縁がありまして, 筆者の1人である@lestrratさまよりご恵贈頂きました.

みんなのGo言語【現場で使える実践テクニック】

みんなのGo言語【現場で使える実践テクニック】

...私事ではありますが, 8月から9月にかけて仕事が盛り上がっており, ちまちまと時間を作って読み続けていたのですが, ようやく読了しましたので感想などを綴りたいと思います.

結論から述べると, ｢LL言語からGoへ入門する人は絶対に持っておくべき!｣という感想を持ちました. 少なくとも自分のようにLL言語(自分の場合, Perl)からGo言語に入門するようなエンジニアであれば, 絶対に手元に持っておくべき良書だと思います.

最初の障壁｢環境構築｣にしっかり文面を割いている

@songmuさんが執筆された第1章の｢Goによるチーム開発のはじめ方とコードを書く上での心得｣は非常に価値がある内容だと思います. というのも, Perl入学式という初心者向けのプログラミング勉強会を主催している身としては, ｢プログラミングの最初の障壁は, プログラミングをするための環境を作るところである｣と常々感じていて, この章の内容はその辺りの｢Go言語を書き始めるにあたって必要な初期の環境設定｣について, 懇切丁寧に書かれていてとても良かったです.

正直, このへんの環境構築は, 正直適当にやっていてもなんとかなるっちゃなんとかなりますが, ちゃんとやっておけば非常に楽になりますし, 何よりGo言語はフォーマッターやLintツールがオフィシャルに提供されていて, これに｢乗っかる｣ことで効率よくコードを書けるので, こういう形で｢1つの章｣としてまとめて書かれているのは, Go言語をチームで導入していく際の知見共有などを考えても非常に有り難いことだと思います. ｢みんなのGo言語｣を手渡して, ｢第1章を読んで, こんな感じで設定してみて!｣って言えますし.

CLIから入っていける

｢みんなのGo言語｣では, @deeeetさんが担当された第4章を中心に, ｢Go言語でCLIツールを作っていく｣というテーマ(?)で, Go言語の様々なテクニック, ノウハウが紹介されています. この辺りは, ｢Go言語でWebアプリケーションを作りたい!｣と思っている人にとっては多少の不満ポイント(?)かもしれませんが, 本書では逆にCLIツールに特化することで, ｢現場で使える実践テクニック｣の紹介に集中出来ていると思いました(なので, 個人的な意見ではありますが, 次は｢Go言語で"Webアプリケーションを作る時に"使える実践テクニック｣とか出てくると非常に嬉しいですね!).

更に言えば, ｢Go言語でWebアプリケーションを作りたい!｣と思っている人こそ, 本書を手に取るべきだと思っていて, なぜなら｢いきなりWebアプリケーションを書くのは難しい｣と思っているからです. Webアプリケーションは, 作ったものをブラウザで実際に動かすことができるので, 達成感というか, ｢勉強してやりきったぜ!｣という気持ちになりやすいのですが, そこに至るまではプログラミング言語そのもの(ここではGo言語)だけでなく, データベースといったミドルウェアや, WAFやORM, テンプレートエンジンといったライブラリの知識も必要になってくるので, 最初の一歩としてはやはり障壁が高いように思っています.

なので, 始めてGo言語に挑戦する人はもちろんのこと, 他言語を足がかりにGo言語にチャレンジする人も, いきなりWebアプリケーションに向かっていかずに, CLIツールから入っていくのが良さそう, と思っています. この辺り, @yusukebeさんのブログに書かれているGolangを初めて本番投入したぜ!という記事で,

と言っても、いきなり画像処理や文字列の改行計算を含んだ「ひとつの」アプリケーションを書き始めるのはニュービーにとって漠然としすぎてて、ムリゲです。なので、スタンプサーバの実装要件をピックアップし、それごとに小さなGoコードの塊=コードスニペットをたくさん書いていきました。

と書かれていて, まずは｢小さなGoコードの塊｣... 恐らくは小さなCLIツールを書いていって, それをまとめてボケてというWebサービス(アプリケーション)にGo言語を導入していったのと, 同じ... なのかなあ, と思っています.

特に, PerlとかRubyとかを使って, 何かしらの｢便利スクリプト｣を書いて使っている人は, 本書で紹介されているテクニックを参考にしながら, それらをGo言語に移植していくところから入っていくと良さそうですね!

まとめ: 理論の｢Tour of Go｣, 実践の｢みんなのGo言語｣

｢Tour of Go｣がGo言語の理論, つまり｢こう書けば, こう動く｣という所を教えてくれるとすると, ｢みんなのGo言語｣はGo言語を実際に使う場面で役立つ, ｢こういう感じでやっていけばいいよ!｣というテクニックやノウハウを教えてくれる本です.

｢Go言語でプログラミング言語に初チャレンジします!｣という人はともかく(個人的には, そういった方はまずはRubyとかLL言語から入っていった方がいいのでは? という気もしますが...), 自分のように何かしらのプログラミング言語を既に学んでいて, そこからGo言語へ入ってくという場面であれば, ｢Tour of Go｣の次に, 或いは｢Tour of Go｣と並行して, 本書を読んでいくのは非常に有意義だと思います.

...というわけで, ｢みんなのGo言語｣, 非常に良い本でした!

マイグレーションツール｢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