hubotとhipchatとjenkinsの連携で消耗している

hubot、去年しばらく触っていたので、とりあえずデプロイ用のスクリプトを実行させたり、gitlabからの通知を受け取ったりすることは出来るようになっていた。

今年に入ってまた色々といじっている。

IRCからhipchatへの乗り換え

今年に入って、社内のIRCが停止したので、hubotはhipchatに乗り換えることにした。 本当はslackが良いんだけど、お金の問題は地位の低いメンバーには解決できないし、chatworkは…もっと頑張って欲しい。

hipchatは、

  • アカウント無料
  • 連携も無制限

とのことで、気にせず色々繋げるのが良い。

移行の作業としては、アダプタを変えて、hipchatに合わせた環境変数を設定するだけ。XMPPでの接続も特に問題なかった。

jenkinsからhipchatへの通知

jenkins hipchat plugin ってのがあって設定も簡単にできたが、肝心のメッセージの日本語が文字化けしていた。

原因を追究するのも面倒くさいので、とりあえず、このままで行く。

hipchatのアプリ自体の通知がおかしい

アプリの設定でroomに発言があると通知をするようにしているのだけど、jenkinsやgitlabなどのシステム連携の通知がこない。 普通の人のメッセージは通知が来る。

バグっぽい気がする。

hubotのdaemon化

gistから拾ってきたinit scriptを使っていたが、stopが上手くいかない。centosのkillprocだと子供のプロセスまで殺せないらしい。

foreverというツールを使ってdaemon化する方法を良く見るので、試してみよう。

kandanってのがある

slackクローン？のOSSのアプリらしい。外部から繋げるためには社外で運用する必要があるし、その分の費用がかかってくる。

また社内で運用しないといけないツールが増えるのはしんどい。

なんか疲れた

昨日と今日で色々と触っていたがホント疲れた。

jenkinsのプラグインで頑張る方向性、プラグインに大きく依存するし、設定もリポジトリで管理できないし、あまり好きではない。

hipchatもなんか微妙だ。

lastpassを購入した

パスワード管理ツール、lastpassは有料というだけで敬遠していたけど、きちんと調べてみると$12/年だったので、即契約した。

オンラインにパスワードを預けるのどうなん？と思ったりもするが、まぁそこ信用しないとどうしようもない。

今のところ、iPhoneとMacで使っている。

便利なところ

Macだとブラウザの拡張機能から、登録済みのサイトのログインフォームなどで自動入力とかできる。この辺は当たり前の機能かな。

iPhoneのSafariから外部共有のところに、lastpassのアイコンが出てくるので、そこでアプリを切り替えてアカウントを選択すると、Safariに戻ってきて自動入力がされている。

微妙なところ

登録済みのサイトを利用するには問題ないが、 新規にサイトを登録するときの機能が微妙だ。

  • 対応URLがその時開いているURLになる
    新規アカウント発行するときのURLを何度も使い回すことないし、サイトのルートURLで良いんじゃないか。

  • パスワードの生成ができない
    せっかくパスワードジェネレーターがあるのに、それが登録時に利用できないのは残念。

正直なところ

なーんか違和感がある。 とりあえず今回の契約は1年限定にしているので、その間に他のツールを試したりしようと思ってる。

2015年の目標

今年の目標を書いておく。

去年は仕事忙しくて、社内での評価は悪くなかったが、出来なかったことも多かったので、そういうのがないようにしたい。

デプロイの自動化

テスト周りはそこそこ形になってきているけど、デプロイ周りはまだまだ心のこもった手作業がほとんど。

今年から始めるプロジェクトに関しては、デプロイも自動化する。 デプロイの準備や手順を見直せばはできるはず。

masterにマージしたらデプロイするってのをやりたい。

読書

子供の世話の都合とかで、まとまって作業する時間が取れなくなってきている。隙間時間でもできるようなこととして、本を読むことにした。

前々から通勤時に読むこともあったが、iPhone5sでは画面が小さくてよみづらかったので、NEXUS7を購入した。(そして2週間ほどして5sが壊れたので6に機種変した…)

積読も多いので、その辺りから消化しつつ、ウィッシュリストに入れていた書籍も手を伸ばそうと思う。

とりあえず週に1冊読むとして、年間50冊を目指している。

チームとかの共同作業

昨年は色々なトラブルもあり、チームでプロジェクトを進めていくやり方や、チームの在り方とかも考える機会が多かった。

その辺、今年は明確な目標として会社からも求められているが、自分の経験はまだまだ未熟なので、強化していく必要がある。

ドキュメント

品質改善もテーマとして与えられているのだけど、設計書類の見直しをしようと思っている。

Word、Excelでのドキュメントではなく、CIに組み込めるようなものができないかと考えている。

autodocのようなテスト(つまりはコード)からドキュメントを生成するという方向性。

やらなくて良いことは、やらない

ほんとこれ。

時間は有限だし、自分の成果とスキルの向上を最大化できるように、余計なことにはクビを突っ込まないようにしたい。

今年の振り返り

今年の振り返りをやっとく。

やったこと

git、gitlabの導入

プロジェクトのソースコード管理にgitを導入できた。リポジトリの管理にはgitlabを使っている。

とりあえずバージョン管理のツールがSVNからgitに変わって、レビューのタスクが可視化された点が大きいと思う。

まだまだ活用できてないので、来年は活用の幅を広げていく。

osakapyの会場提供

会社の会議室を気軽に使えるので、会場提供をさせてもらった。

ちょっとした準備をするだけで特に負担もなく、自分の移動のことを考えなくて良いので、メリットが大きい。

社内開発環境の管理

プロジェクトの社内テスト環境としてVMware使っているのだけど、その管理を一部やることになった。

せっかくなので、API経由でサーバ構築できるようにしたら、kickstartやansibleとかやる必要が出てきて、その辺に明るくなったのが良かった。

ついでに、メンバーの開発環境構築にも手を出すことにして、packer使えるようになった。 (会社のアドベントカレンダーにも書いた。)

できなかったこと

docker

boot2dockerを数回触る程度だった。

あるプロジェクトで採用を検討してたんだけど、アプリの構成の都合もあって見送ったあたりで熱が冷めた感じ。

ブログ

仕事忙しい→しんどいので休みたい→アウトプットしない、という感じになっていた。

gemの公開

capistranoでデプロイするときに、cronの更新もしたいんだけど、wheneverとかやってられないので、そういうタスクを過去に作った。

キチンと整理してgemにしようと思っていたんだけど、バージョン3対応ができないままほったらかしにしている状況。

来年は…

大きなテーマとしては自動化かな。細かいところは年末年始で考えてみる。

ネットでブログやスライドを見ていると、意識高い感じになるんだけど、足元はガタガタでまだまだ道のり長いなぁと言うのが正直な気持ち。

あと、35歳になるし定年説意識しないかといえば嘘になるので、若い人も増えるだろうから、老害化しないようにしたい。

ペアプロをやった

少し前にペアプロをやったので振り返っておく。

準備

準備という程でもないけど、ペアプロのやり方をインターネットで簡単に調べた。 色々とやり方や定義があるっぽいけど、厳密にやることが目的ではないので、

2人で1つのパソコン使ってプログラムする

という当たり前のことだけ決めといた。

良かったこと

コードがかなり丁寧になる。

理由は色々あるだろうけど、

  • ひとりだとやってしまいがちな、蛇足的な調査とかしなくなって、ペアプロのタスクに集中してコードが書ける
  • 考えたことを説明や相談したりしながら書いていくので、変なバグが埋め込まれにくい

とか影響してそう。

ちなみに「見られてるから丁寧に書かないといけない」みたいな脅迫観念のようなものはなかった。 もともとコードレビューが前提にあって、見られるのが当然という状態だからかもしれない。

仕事してる感が高い

コードを書く作業に対する充足感のようなものが高い。 「あーオレ、今日良いコード書けたな〜」みたいな感じになる。

1人で作業しててこういう感覚になったことないので、ペアプロの効果だと思う。

相手への理解が深まる

普段どんなふうにして作業をしているのか、例えばエディタの使い方とか、コードの書き方とか、コマンドの使い方とか、そういうのってその人のポリシーが出ると思う。 そういうのを、見せる・見せられることになるので、相互理解の助けになる。

逆に、そういったポリシーがなければ、「こいつホントなんも考えてないんだな」というのがわかって恐ろしくもある。

微妙だったこと

何でも良いことばかりでもない。

生産性良いのかどうなのか

  • 2人でコード書いてるわけだから、コードを書く生産性は全然高くない
  • でも丁寧になってるし簡単なバグは少ないはずだし、デバッグの時間は減りそう

というジレンマみたいなもんがある。

スキル差をカバーできない

スキルの差がありすぎて、今回はほとんど自分が考えたことをコードに書いてもらう感じになった。

先に書いたようなメリットはあったが、 仕事のコード書くんだったら、双方のレベルが同程度でないと意味がないっぽい。

教育目的なら良いかもしれないけど。

まとめ

本当に丁寧に作らないといけない箇所、例えば課金系とかはペアプロやってみるというのは、効果があると思う。

色々と意見があるみたいだけど、自分で経験して実感できたので良かった。