2017年の振り返り

あけましておめでとうございます, 今年もよろしくおねがいします. というわけで毎年恒例, 昨年の振り返りエントリです. 今年もKPTを使ってやっていきます.

過去の振り返り達

papix.hatenablog.com

papix.hatenablog.com

papix.hatenablog.com

K

｢2017年にやってみてよかったこと, 2018年も継続して取り組みたいこと｣

年間通してメンタル的(?)に安定していた

2017年は2017年で, いろいろなイベントがありました. 嬉しいこと, 楽しいこともありましたし, ちょっとイラっとしたり, 悲しくなったり, 辛くなったりしたことも何度かありました. 2016年は, 精神衛生に悪い影響を与えるようなイベントが起きた時, それと上手く向き合えずに不安定になる... という出来事が多々ありましたが, 2017年は自分自身とちゃんと向き合って, 様々なイベント, 心境の変化などに立ち向かうことができて, 結果として, メンタル的な部分が不安定になって, 日常生活や各種業務に影響が出る, という場面はほとんどなかったと思っています.

まとめると, 2016年に, いろいろと苦しんだり, 迷ったりしました中で得た気付きを, うまく活かすことが出来た1年だったように思います. 心理面が安定していた一方で, 2017年は体力というか, 体調面でいろいろと限界が来て, いろいろ迷惑をかける部分が多かったような気がします. その辺りは2018年の課題と言えるでしょう.

はてなブログの開発に携わって, エンジニアとして自信を持つことができた

2017年, 自分にとって一番重要度の高かったイベントは, 間違いなく｢はてなへの入社｣と, ｢はてなブログチームへの加入｣だったと思います. 入社する前は, もう本当に不安しかなくて, はてなという会社は, 自分にとっては"神(のような腕を持ったエンジニア)が集う場所", みたいな印象があって, 果たしてその中で生きているけるのか? 試用期間で解雇されたらどうしよう, という気持ちが強かったです.

一方で, 入ってみて1年経った今の段階で振り返ってみると, 予想していた以上にチームの業務に食らいついていけた(?)と思っていて, そこは一定｢意外とやれるじゃん?｣という意味の自信になりました. 入社して半年くらいは, チームの足を引っ張る場面が多かったと反省していますが, ここ半年くらいは慣れなどもあって, 何とか戦力として計算できる程度には仕上がってきたのではないかと... 思いたいです. また, 既存のコードを読んだり, ペアプロやコードレビューを通して, これまで積み上げていた｢コードを設計して, 書く技術｣という部分を, より磨き上げることが出来たと思います.

そして何より良かったのは, これまでの様々な活動や, 前職を通じて得た経験やスキル, 或いは2017年に試みたチャレンジを, うまく仕事に活かせたことでした. 例えば, これまで続けてきたPerl入学式の活動や, 或いは前職での新人研修を通して, ｢技術的な内容を噛み砕いて説明するスキル｣が伸びていたようで, はてなに入社してから, 例えばプロデューサーやディレクターにプロダクトの仕様などをする時や, はてなブログMediaを担当している営業メンバーとやりとりをする時に活きていると思います. また, 思いつきで10月頃から初めた駄文を綴る活動(ぱぴったー)も, 結果として｢それなりの精度の文章｣をシュッと書き上げるスキルが伸びたように思っていて, それがGitHubのIssueのDescriptionや, 会議のアジェンダを準備するときに, うまく活かせているように思います.

エンジニアとしての狭義の技術(プロダクトを作る部分)はもちろん, 広義の技術(チームプレーやコミュニケーション)についても, 得るものが多くて, それが自信に繋がった2017年だったように思います.

P

｢2017年で良くなかったところ, 2018年に改善していきたいところ｣

｢手持ちの道具｣で戦いすぎた

前述したように, 2017年は自分自身が既に習得していた様々な技術(手持ちの道具)の精度を, しっかりと底上げできた1年でした. 一方で, 自分自身にとって未知の技術に挑戦して, スキルの伸びしろを埋めていく活動は, ほとんど出来ていなかったと思います.

この辺りを振り返ってみると, 2017年の前半は, はてなに入社してとにかく必死で, そういった事を考える余裕がなかったような気がします. 2017年の後半は, 業務には慣れてきたものの, 様々な状況の変化があり, 業務の中に自分自身の技術スキルをぐっと伸ばす挑戦的な要素を入れる余裕がなかったのが正直なところです.

その分は業務外で... と行きたかった所ですが, 趣味活動*1と体力回復でほとんどの時間が費やされ, そういった自分自身の投資が出来なかった1年でした. 2018年は, 業務外はもちろん, 業務の中でも, そういった挑戦的な要素を, うまく織り込んで行きたいですね.

体調管理がうまくいかなかった

前述の, 業務外での挑戦をうまくこなしていく為にも, 2017年を通して課題に感じた｢体調管理｣の部分について, 2018年はしっかり気をつけていきたいです. 1年通して大きな病気になった場面はなかったですが, ライブに行った後に風邪を引いてしまったり, 寝不足や生活リズムの崩壊で, 業務に影響が出るという場面は結構多かったです.

8月に28歳になって, いよいよ30歳が目前となってきて, これまでのような無茶が徐々に効かなくなってきているような気がします. 2018年は, とにかく無茶な行いをしない, 夜更かしもしない, 早寝早起きを心がける, そういった所を意識してやっていきたいです.

Perl入学式の活動にほとんど携わることができなかった

転職があったり, YAPC::Fukuokaの運営に携わることになったりと, 2018年は1年通してPerl入学式の活動に, あまり携われない1年間となりました. それでも2017年を通してPerl入学式の活動は続いていて, 初の北海道開催が実現するなど, 多くの実りがありました. この辺りは, 本当に id:xtetsuji さんの功績だと思っています.

そういった状況を振り返ってみると, Perl入学式という活動に対して, 自分自身, 昔ほど大きな熱量を持って取り組めていない... というのが, 実際あるような気がしています. それでも, Perl入学式という活動に一切携わらないという選択肢は自分の中ではないですが, とはいえ｢コミュニティを主導する立場("校長"という立場)を譲る｣という選択肢について, そろそろ真剣に考えていく必要があるように思っています.

そのためにも, 2018年を通して, ｢基礎を改めて固める, 作り直す｣活動をやっていきたいですね. これまで, 6年に渡ってPerl入学式という活動をしてきて, 資料も毎年継ぎ足し継ぎ足しで手直しをしてきて, 現在の状況(Perlを取り巻く状況, Perl入学式を取り巻く状況)に追随出来ていないのが現実です. そういった状況を考慮しつつ, 更に｢Perl中学校｣構想も折り込み, 次の6年を見据えたカリキュラムを構築する... そこまで成し遂げて, 初めて引き継ぎについて考慮出来るようになってくると思っています.

T

｢2017年, 改めてチャレンジしていきたいところ｣

｢積み上げる｣活動を試みる, 継続する

昨年の終盤から始まった駄文を綴る活動だけでなく, 例えば読書とか, 貯蓄とか, 運動とか, そういった日々継続して, 積み上げていくような習慣を定着させたいですね. 読書とか, 読む時はガーっと読むけど, そうでない時は全く... という感じなので, 日々ちょっとずつ, コンスタントに読み進めることで積読を減らしていきたいです.

最近は, とりあえず ｢SQLアンチパターン｣と｢Redis入門｣をちまちまと読んでいます. 後者はRedis 2.6時代の本で, 今やRedis 4.0とかの時代ではありますが, これまで真剣にRedisを使った機会がなかったので, まずはどういう事が出来るかを掴むところから入っていければ... という気持ちです.

SQLアンチパターン

Redis入門 インメモリKVSによる高速データ管理

情報をどんどん発信していく, どんどん煮詰めていく

Webサービスの開発に従事するエンジニアとして, 情報の発信は必要不可欠なので, この辺りは引き続き2018年もやっていきたいですね. ブログ記事については, ネタが出て来る度にそれなりにアウトプットすることができましたが, 2017年はあまり勉強会などでの発表をしなかった(YAPC::Kansaiくらい...?)ので, (登壇することが目的にならない範囲で)登壇数を意識して活動していきたいですね.

また, 前述の駄文を綴る活動を初めたことで, ちょっとした思考が文章として記録されやすくなってきました. これが第1フェイズとすれば, 第2フェイズとして, そういった駄文を再び練り直して, 煮詰めて, より精査されたアウトプットに昇華(?)するような活動をしたい気持ちがあります. あと2年で30代になる訳で, そうなってくれば今まで以上に理路整然と会話をすることが求められる機会が増えてきそうで... そういった事態に備えて, 今のうちから練習として, まずは自分の考えをちゃんと文章で伝えられるようになりたいです.

そろそろ海外も視野に入れる

2017年は, JGC修行を兼ねて, 北は北海道から南は沖縄まで, 日本中を飛びに飛び回った1年でした. 旅行は自分にとって心休まる大事な趣味の1つですし, 旅を通して様々な体験, 知見が得られたと思っています. あとは旅先で, 素晴らしい風景を眺めながら様々な思案に耽るのも, なかなかに素晴らしかったです.

2018年は, 日本国内はもちろん, 国外を含めて, まだ行ったことのない場所に積極的に行ってみたいです. 2017年に日本最西端の与那国島に行くことができたので, 最北端の稚内や最南端の波照間島といった場所にも行ってみたいですし, 国外なら台湾やシンガポール, 高校の同級生がいるカンボジア, 或いはドイツやフィンランドなど, 行ってみたい場所はたくさんあります.

...そのためにも, とにもかくにも壊滅的な英語力をなんとかしなければ... と毎年思いつつ, 取っ掛かりを得ることが出来ずに今に至る, という感じです.

まとめ

振り返ってみて, 2017年は学びも多く, その分課題も多く... そういった1年だったように思います.

とはいえ1年を通して, 非常に楽しく, また充実感のある日々を過ごせました. これも, 様々な場面でお世話になった皆様のおかげです. まだまだ未熟者ではありますが, 2018年もご指導ご鞭撻の程, 宜しくお願いいたいます.

*1:JGC修行とアイドルマスターシンデレラガールズ

今, Smart::Args::TypeTinyが熱い!?

この記事は, ｢Perl Advent Calendar 2017｣の24日目の記事です.

qiita.com

昨日は, id:papix の｢VimにおけるPerl関連のスニペットを晒してみる 〜2017年版〜｣でした.

papix.hatenablog.com

Smart::Argsは便利

Perlで, 関数に渡ってきた引数のチェック(バリデーション)をするのであれば, Smart::Argsを使うのが一般的だと思います.

metacpan.org

Smart::Argsを使えば, 次のように関数に渡ってくる引数をチェックできます. ここでは, funcという関数に対して, fooというキーでInt(数値), barというキーでStr(文字列)が渡ってくることを指定しています.

use strict;
use warnings;
use utf8;

use Smart::Args qw/ args /;

func(foo => 1,     bar => 'bar');
func(foo => 'foo', bar => 'bar');

sub func {
    args
        my $foo => 'Int',
        my $bar => 'Str';
}

最初の呼び出しは, fooに1という数値, barに'bar'という文字列がそれぞれ渡っているので大丈夫ですが, 2回目の呼び出しは, fooに'foo'という文字列が渡っています. 2回目のfuncを呼び出すと, Perlは次のようなエラーを返します:

'foo': Validation failed for 'Int' with value foo at /path/to/lib/Smart/Args.pm line 179.
        Smart::Args::_validate_by_rule("foo", 1, "foo", "Int", SCALAR(0x7fccba8e8df8)) called at /path/to/lib/Smart/Args.pm line 63
        Smart::Args::args(undef, "Int", undef, "Str") called at smart_args.pl line 11
        main::func("foo", "foo", "bar", "bar") called at smart_args.pl line 8

Smart::Argsを使えば, ｢関数に渡ってきた引数のチェック｣と, ｢変数の宣言｣が同時に出来るので, とても便利です.

Smart::Args::TypeTiny

そんな中, 最近Smart::Args::TypeTinyというモジュールが公開されました. 作者は id:akiym さん.

metacpan.org

名前からわかる通り, 型にType::Tinyを使った*1Smart::Argsライクなバリデーターなのですが, Smart::Argsとの｢IMCOMPATIBLE CHANGES｣が, かなり痒い所に手が届くようになっていて, 個人的に注目しています.

期待していないパラメータが渡されるとエラーになる

例えば, 次のコードのように, func関数はfooというキーでIntが渡ってくることを期待しているとします.

use strict;
use warnings;
use utf8;

use Smart::Args qw/ args /;

func(foo => 1, bar => 'bar');

sub func {
    args
        my $foo => 'Int';
}

ここで, Smart::Argsの場合, funcにfooに加えてbarというキーで値を渡した場合, 次のようにエラーではなく警告が発生します.

unknown arguments: bar at smart_args.pl line 10.
        main::func("foo", 1, "bar", "bar") called at smart_args.pl line 7

一方, Smart::Args::TypeTinyであれば, 出力される文言は同じですが, 警告ではなくエラーになります.

use strict;
use warnings;
use utf8;

use Smart::Args::TypeTiny qw/ args /;

func(foo => 1, bar => 'bar');

sub func {
    args
        my $foo => 'Int';
}

optionalはundefが渡ってくることも許容する

Smart::Argsでは, 次のようにして, 引数をoptional(任意で渡すことが出来る)にすることが出来ます.

use strict;
use warnings;
use utf8;

use Smart::Args qw/ args /;

func(); # (1)
func(foo => 1); # (2)
func(foo => undef); # (3)

sub func {
    args
        my $foo => { isa => 'Int', optional => 1 };
}

このとき, funcを呼び出す時にfooをキーとして値を渡されなければ, funcにおける$fooはundefになります(コード中の, (1)のパターン). もちろん, (2)のように, fooをキーとして値を渡せばfuncにおける$fooは渡された値(この場合は1)になりますし, ここでIntではない値を渡せばエラーになります. 問題は, (3)のようにoptionalな引数にundefを渡した場合で, この時Smart::Argsではエラーが発生します.

'foo': Validation failed for 'Int' with value undef at /path/to/lib/Smart/Args.pm line 179.
        Smart::Args::_validate_by_rule(undef, 1, "foo", HASH(0x7fe8cf89f510), SCALAR(0x7fe8cf80e7f8)) called at /path/to/lib/Smart/Args.pm line 63
        Smart::Args::args(undef, HASH(0x7fe8cf89f510)) called at smart_args.pl line 12
        main::func("foo", undef) called at smart_args.pl line 9

一方, Smart::Args::TypeTinyであれば, (3)のようにoptionalな引数にundefを渡してもエラーにならず, funcにおける$fooの値はundefとして処理を続けることができます.

追記

ちなみに、Smart::ArgsでSmart::Args::TypeTinyと同様のoptionalの処理にするには{type => 'Int', optional => 1}ではなく{type => 'Maybe[Int]' optional => 1}とするといいです（出来ないわけではないよ）

— かるぱ (@karupanerura) 2017年12月24日

defaultにサブルーチンリファレンスを渡すことで, 必要な時だけ評価することができる

Smart::ArgsもSmart::Args::TypeTinyも, 次のようにdefaultを指定することで, その値が渡ってこなかった時のデフォルト値を指定することができます. そしてこのとき, 何かしらのサブルーチンを呼び出してデフォルト値を埋めることが出来ます.

use strict;
use warnings;
use utf8;

use Smart::Args qw/ args /;

func(); # (1)
func(foo => 1); # (2)

sub func {
    args
        my $foo => { isa => 'Int', default => create_value() };

    print "$foo\n";
}

sub create_value {
    print "called!\n";
    return 123;
}

上のコードでは, funcを呼び出す時にfooというキーで値を渡さなかった場合, create_valueという関数を実行して, その結果をデフォルトの値にする... という挙動になります. このコードを実行すると, Smart::ArgsもSmart::Args::TypeTinyも, 次のような結果になります.

called!
123
called!
1

fooというキーを指定せずにfuncを呼び出した場合, つまり(1)の場合はもちろんのこと, fooというキー指定した(2)の場合でも, create_valueの呼び出しが発生してしまっています. 万が一, create_valueが多少時間のかかる処理であった場合, create_valueの呼び出しが不要であっても毎回呼び出されてしまうので, パフォーマンスの面でも気になって来るかもしれません.

一方, Smart::Args::TypeTinyでは, defaultに対してサブルーチンリファレンスを渡すことで, ｢必要な時だけ｣デフォルト値を生成することが可能です.

use strict;
use warnings;
use utf8;

use Smart::Args::TypeTiny qw/ args /;

func();
func(foo => 1);

sub func {
    args
        my $foo => { isa => 'Int', default => sub { create_value() } };

    print "$foo\n";
}

sub create_value {
    print "called!\n";
    return 123;
}

このコードを実行すると,

called!
123
1

このような出力になります. create_valueが, 1度しか呼び出されていないことがわかります.

まとめ

最近個人的に注目している, Smart::Args::TypeTinyの紹介をしました. Smart::Argsを使っていない人はもちろんのこと, 既に使っている方も, Smart::Args::TypeTinyに置き換えていく価値は結構ありそうでは? と思っています.

*1:Smart::Argsは型にMouseを使っている

VimにおけるPerl関連のスニペットを晒してみる 〜2017年版〜

この記事は, ｢Perl Advent Calendar 2017｣の23日目の記事です.

qiita.com

昨日は, @magnolia_k_さんの｢ビルドツールの裏側にいるMakefileを覗いてみる ｣でした.

qiita.com

VimにおけるPerl関連のスニペットを晒してみる

あと30分で12月24日ですが, まだ23日の記事が開いてそうだったので, 折角なので小ネタで埋めようと思います. 大きめのネタにしなかったのは, 24日のPerl Advent Calendarも担当しているからです.

...さて, 去年このような記事を書きました:

papix.hatenablog.com

日頃, Perlを書く時は(というか何かしらコードを書く時は)Vimでコーディングをしていますが, その時に使っているスニペットを紹介した記事です. この記事では, あれから1年以上が経過した, 今現在のVimにおけるPerl関連のスニペットをご紹介します.

snippet u
    use strict;
    use warnings;
    use utf8;

    ${0}

snippet env
    #!/usr/bin/env perl
    use strict;
    use warnings;
    use utf8;

    ${0}

snippet pkg
    package `expand('%:p:s?.*lib/??:r:gs?/?::?')`;
    use strict;
    use warnings;
    use utf8;

    ${0}

    1;

snippet dw
    use DDP { deparse => 1, use_prototypes => 0 };
    DDP::p ${0}

snippet slurp
    open my $fh, '<', ${0} or die "failed to open file: $!";
    my $content = do { local $/; <$fh> };

...だいぶシンプルになりました. 数ヶ月前にvimrcの大掃除をしたので, その時に余り使わないスニペットは消してしまった, というのもあります.

• スクリプトを書く時はuないしはenvでuse strictやuse warningsなどを一括で挿入
• ライブラリを書く時は, pkgでuse strict, use warningsなどに加えて, packageも一括で挿入
• Printデバッグをする時は, dwでData::Printer(DDP)を挿入
• Path::Tinyなどを使わずにファイルを読み込みたいときは, slurpでファイルを一気に読み込んで, 変数に代入するコードを挿入

...という感じに使っています.

SirVer/ultisnips

pkgのスニペットについては, SirVer/ultisnipsを使っています.

github.com

このプラグインを使って, 上記のようなスニペットにしておけば, 例えばlib/Foo/Barというディレクトリで, 新たにBaz.pmを作り, そこでpkgのスニペットを展開すると, このようになります.

package Foo::Bar::Baz;
use strict;
use warnings;
use utf8;



1;

現在のパスから, packageの部分をいい感じに補完してくれて, 非常に便利です(ちなみにこの設定は id:masawada さんのvimrcから拝借したものです, ありがとうございます).

まとめ

Vimを使っている時によく使っているPerl関連のスニペットと, そこで利用しているSirVer/ultisnipsを紹介しました. 他にも｢これがあると捗るよ!｣といった, 便利なスニペットがあれば, 是非ブログなどで紹介してもらえると嬉しいです!

｢雑に文章を書く｣活動と, そこから得たもの

この記事は, ｢はてなエンジニア Advent Calendar｣の18日目の記事となります.

qiita.com

昨日の記事は, id:masayoshi さんの｢はてなサマーインターン2017の講義とメンターをした話｣でした.

masayoshi.hatenablog.jp

今日は, 最近やっている｢雑に文章を書く｣活動と, それが業務の中に微妙に活きつつある, という話をしようと思います.

雑に文章を書く

はてなにおける業務として, ｢はてなブログ｣の開発に携わっているので, そのドッグフーディングは極めて重要です. 言うまでもなく, 仕事や技術について語ることを主目的としたこのブログもはてなブログを使っていますし, 日常や趣味について語るブログもはてなブログを使っています: 絶対笑顔でまだまだいっぱい夢見るブログ そして2ヶ月ほど前から, これら2つのブログに加えて, ｢パピッター｣という, とにかく雑に, 思ったことを, 勢いだけで綴るブログをやっています. ...もちろんはてなブログで.

papix.hatenadiary.jp

最初は, 割と勢いでスタートした｢雑に文章を書く｣活動ですが, 継続していると, 予想していた以上にメリットがあることがわかってきました.

｢雑に文章を書く｣活動から得られたこと

｢思考の書き損じ｣が減る

昔から, ｢気付いた事, 学んだ事, 考えた事, そういった思考の成果は文章にまとめて残したい. そうしないと, 折角頭を使って思考を巡らせたのに, それを全部忘れてしまう｣という気持ちを持っています. それを果たすべく, 2つのブログを書いていましたが, 何となく｢このブログは, 思考したことを, しっかりまとめてからアウトプットする場所｣といった気持ちになってしまって(この辺りの, ｢ブログの使い方｣的な部分は人それぞれあるとだと思います), 結果として書き損じる, というパターンが多かったです.

｢このブログは, 雑に文章を書いても良い場所だ!｣と定めることで, 思考したことを5〜6割くらいまとめた段階のものを, どんどんと書き残せるようになりました. もちろん, これまでよりもクオリティ(?)は低いかもしれませんが, 一度雑に書き残しておくことで, それを後で振り返ったり, まとめなおしたりすることが出来るようになりました.

｢文章を書く｣作業が苦ではなくなる

エンジニアとして, コードを書き, プロダクトを改善, 成長させていくのは重要な仕事です. しかしながら, それをチームで取り組んでいくのであれば, ある程度の｢文章｣を書く必要がある場面が多々あります.

例えば, IssueやPull RequestのDescriptionだったり, 日報/週報といった定期的なレポートだったり, 会議のアジェンダだったり... 丁寧に書きすぎると時間がかかりすぎますし, かといって雑に書きすぎると, IssueやPull Requestであれば, ｢これはどうですか?｣, ｢これって何ですか?｣といった, コメントによるコミュニケーションが何度も何度も繰り返されてしまったりしますし, 会議であれば, 議論の前提やテーマがズレてしまったりして, 気がついたら混沌となっていた... といった事があるかもしれません.

｢雑に文章を書く｣活動を初めてから, 定期的に｢5〜6割くらいの完成度｣の文章を書くようになって, 結果として, IssueやPull RequestのDescriptionや, 会議のアジェンダを用意するとき, 50%〜60%くらいの完成度のものを, すぐに書き出せるようになった気がします. これまでは, 書き始めるまでにいろいろ考えすぎたり, なんとなく書き始める事が出来ずに, 結果として延々と時間だけが経過していた... というパターンが多かったです.

｢50%〜60%｣という完成度も, 良い塩梅なのかもしれないと思っていて, 文章を書く時, 完成度を上げようとすれば上げようとする程, 時間が必要になってきます. 程よい準備時間を費やしつつ, ある程度前提や自分の意見などをまとめられる完成度がこの辺りなのではないか? ...と, 勝手に思っています.

---

思いつきで初めた, ｢雑に文章を書く｣活動と, そこから得られたものについて紹介しました. ｢雑な文章｣, よければはてなブログで是非綴ってみてください.

hatenablog.com

EdgeRouter Xでmackerel-agentを動かす

この記事は, ｢Mackerel Advent Calendar 2017｣の17日目の記事です.

qiita.com

EdgeRouter Xでmackrel-agentを動かす

EdgeRouter Xは, ネットワーク機器ベンチャーUbiquiti Networksというところが開発しているルータ製品の1つです. 安価な割にいろいろ遊ぶことができて, 秋あたりからいろいろと設定して遊んでいます. ちなみに最近はAmazonでも買えるようになったみたいです.

Ubiquiti Networks Edgerouter ER-X（日本国内）

EdgeRouter Xの上にはMIPSが乗っており, すなわちMIPS向けにビルドすればEdgeRouter Xでもmackerel-agentが動く...! という情報を, 同僚の id:astj さんから伺ったので, 実際にやってみたというのがこの記事の内容です.

astj.hatenablog.com

この記事で紹介した方法を使えば, (Go言語が対応している)任意のアーキテクチャでmackerel-agentを動かすことができそうです.

mackerel-agentをビルドする

mackerel-agentをビルドするには, リポジトリをcloneした後,

$ make build

すればOKです. 今回の場合, EdgeRouter XのためにMIPS(正確にはリトルエンディアンのMIPS)でビルドしたいので,

$ GOOS=linux GOARCH=mipsle make build 

このようにしましょう. すると, buildディレクトリ下にmackerel-agentが生成されますので, scpなどを利用して, EdgeRouter Xに持っていきます.

後は, EdgeRouter X側で,

$ sudo su -
# mv /path/to/mackerel-agent /usr/bin/mackerel-agent

のようにして, /usr/bin/mackerel-agentに配置しましょう.

設定ファイルの設置

mackerel-agentの設定ファイル, mackerel-agent.confも設置しなければなりません.

# mkdir /etc/mackerel-agent/

のように, ディレクトリを用意して,

# vi /etc/mackerel-agent/mackerel-agent.conf

で, APIキーなどを書き込みましょう.

自動起動の設定

これで, /usr/bin/mackerel-agentで, mackerel-agentが起動するようになりました. 次は, EdgeRouter Xを再起動した際, 自動的にmackerel-agentが起動するようにしてみましょう.

いろいろと方法はありますが, 今回は起動時に/etc/rc.localが実行されることを利用して, ここでmackerel-agentを起動する方法を取ります.

# vi /etc/rc.local

でファイルを開き,

/usr/local/bin/mackerel-agent supervise  >> /var/log/mackerel-agent.log 2>&1 &

のように, mackerel-agentがバックグラウンドで実行されるように設定します.

これで, 何らかの事情でEdgeRouter Xがシャットダウンしても, mackrel-agentが自動的に起動するようになりました.

Mackerelから見たEdgeRouter X

こういう感じで, 普通に各種パラメータが取得できます. 途中一部データが途切れているのは, EdgeRouter Xを再起動したときにmackerel-agentが再起動することを確認したときの様子です.

EdgeRouter Xでプラグインも動かす

Goで実装されたプラグインであれば, ここまで紹介してきた方法を使い, GOOS=linuxかつGOARCH=mipsleとしてビルドすれば, EdgeRouter Xで動かすことができます.

papix.hatenablog.com

実は, 先日こちらの記事で紹介したMackerelのnasne用プラグインも, Goで実装されていたので, ビルドしてEdgeRouter Xの上で動かしたりしています...!

EdgeRouter Xであれば, 意外とPerlも5.14.2が使えるようになっているので, コアモジュール縛りをすればPerlでプラグインを書いて... ということもできそうです.

まとめ

EdgeRouter Xでmackerel-agentを動かす方法を紹介しました. mackerel-agentはGo言語で実装されているので, こういった時に適切なアーキテクチャでビルドすれば, シュッと動かすことができて便利ですね!

Mackerelは, 無料プランでも5ホストまで監視することが出来るので, EdgeRouter Xを使っている方は是非Mackerelを使った監視にもチャレンジしてみて下さい.