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

SideCI TechBlog

SideCIを作っているアクトキャットのエンジニアによる技術ブログです。

PackerのAMI手動管理を卒業するプラグインを作ってみた

こんにちは、家から捕まえられるポケモンだけを捕まえて僕のポケモンGoは終了しました。@wata727です。

f:id:sideci-dev:20160817154928p:plain

弊社ではインフラ自動化の一環として、AMIの作成にPackerを利用しています。PackerはAMIを作るまでは自動化してくれるものの、作成されたAMIは残り続け、使わなくなった古いAMIは手動で削除しなくてはいけません。
この点に関して、公式*1では、

Packer only builds images. It does not attempt to manage them in any way. After they're built, it is up to you to launch or destroy them as you see fit. If you want to store and namespace images for easy reference, you can use Atlas by HashiCorp.

と述べており、Atlasを使ってくれという立場です。とはいえ、そこまで大げさな話でもないし、毎回手動で削除しないといけないのは面倒臭い、そうだ、Packerにはプラグインの仕組みがあるじゃないか、プラグインを作ろう、となったのが今回の経緯です。

Packerプラグインの仕組み

PackerはGo言語で作られており、本体は単独で実行可能なバイナリとして提供されています。 Packerのプラグインも同様にGo言語で作成し、単独のバイナリとして提供されます。内部的には、RPCを使ってPacker本体とやり取りをすることで、独自の処理を追加することができます。 詳しくは公式のドキュメントに書いてありますが、大まかに言うと以下のような処理をmainに書いて、自作プラグインの処理を登録します。

package main

import (
    "github.com/mitchellh/packer/packer/plugin"
    "github.com/yourname/packer-type-name
)

func main() {
    server, err := plugin.Server()
    if err != nil {
        panic(err)
    }

    server.RegisterPostProcessor(new(yourplugin.PostProcessor))
    server.Serve()
}

github.com/mitchellh/packer/packer/pluginがPackerのプラグインを作る上で必要なものをすべて持っているので、基本的にはこれをimportすれば動作させることができます。 後は追加したい処理をプラグインのインターフェイスを満たすようにゴリゴリ実装します。プラグインの種類はいろいろありますが、今回はAMIを作成したタイミングで、古いAMIを削除できれば良いので、最後に処理を挟むpost-processorプラグインを選択しました。

作ったもの

で、完成したものがこちらになります。

名前が異常に長いですが、packer-post-processorまでは命名規則なのと、他のpost-processor、amazon-importなどにあわせた結果、こんな名前になりました。もうちょっといい名前があったかもしれません...

インストール

ビルド済みのバイナリをダウンロードしてきて~/.packer.d/pluginsに配置するだけで動作します。 最初はpluginsディレクトリが無いこともあるので、その場合には作ってください。

$ wget https://github.com/wata727/packer-post-processor-amazon-ami-management/releases/download/v0.1.0/packer-post-processor-amazon-ami-management_linux_amd64.zip
$ unzip packer-post-processor-amazon-ami-management_linux_amd64.zip
$ mv dist/linux_amd64/packer-post-processor-amazon-ami-management ~/.packer.d/plugins

使い方

post-processorとしてamazon-ami-managementを以下のように指定します。

{
  "builders": [{
    "type": "amazon-ebs",
    "region": "us-east-1",
    "source_ami": "ami-6869aa05",
    "instance_type": "t2.micro",
    "ssh_username": "ec2-user",
    "ssh_pty": "true",
    "ami_name": "packer-example {{timestamp}}",
    "tags": {
        "Amazon_AMI_Management_Identifier": "packer-example"
    }
  }],
  "provisioners":[{
    "type": "shell",
    "inline": [
      "echo 'running...'"
    ]
  }],
  "post-processors":[{
    "type": "amazon-ami-management",
    "region": "us-east-1",
    "identifier": "packer-example",
    "keep_releases": "3"
  }]
}

AMIを作成するときにAmazon_AMI_Management_Identifierをキーに、任意の値のタグを設定しておけば、そのタグの値を指定することで世代管理の対象とすることができます。何世代まで維持するかどうかはkeep_releasesで指定できます。 これでいちいち古いAMIがたまった時点で定期的に削除する必要が無くなって、AWSの料金もきっちり節約できます、うれしいですね!

まとめ

普段、実務ではRubyを使うことが多いのですが、Goでコードを書いていて、特にAWSの通信まわりのモックを書くのに結構苦労しました... 現状はgomockを使ってSDKのモックを自動生成してそれを使っているのですが、もっと良い方法があればぜひ知りたいです。

Packerのプラグイン機構はまだ試験的なものとのことですが、短いコードでかなりいろいろな拡張ができるので、ぜひ便利プラグインを作って配布してください!

参考

突撃!どんな環境で開発していますか? SideCIメンバー編

こんにちは。 Atom大好き! @sumyapp です。SideCIのプロダクトオーナー的なことをしております。 この記事はこのテックブログの記念すべき10回目です。

しかしながら、最近まったく開発をしていない私で御座いますので、今回はインタビュー形式で社内の開発環境を取材していきたいと思います。
取材途中で全員分取材すると分量が大変そうなことに気づいたので、今回は4名分だけ。

セパレートキーボード始めました @sumyapp

インタビュー形式といいつつ、まずは私の環境から公開です!

f:id:sideci-dev:20160805150928j:plain

最近の業務内容と得意領域を教えて下さい

最近の業務内容は開発以外の全てですね。プロダクトのワイヤフレームを作ったり、ヒアリングにお伺いしたり。その他、オフィス(物件)を探したりとか、ほんとに何でもやっています。

得意領域は以前はネイティブアプリ(Obj-C, Android Java)とRailsといった感じだったのですが、今はプロダクトのためにやるべきことをやる、ということにフォーカスしていますね。

開発環境(物理)について教えて下さい

11inchのMacBook Air, 27inchの外付けディスプレイ、iPad mini Retina(Duet)を使ったトリプルディスプレイ構成です。キーボードはKinesis Freestyle2 for Macを使っています。

セパレートキーボードは先週買ったばっかりで、まだポテンシャルを十分引き出せていないなと思います。Ergodoxなども検討したのですが、USキーボード自体初めてで、一般的な配列のこれにしました。

f:id:sideci-dev:20160805151242j:plain

開発環境(ソフトウェア)について教えて下さい

立ち上がりの早いVimとAtomを使っています。1ファイルだけ修正する場合はVim、プロジェクト全体のソースを見る場合にはAtomといった使い分けです。

f:id:sideci-dev:20160805151010p:plain

1つだけ何かをお勧めするとしたら、何をおすすめしますか?

一番シンプルなところで、クリップボードの拡張アプリの「Clipy」はお勧めです! https://clipy-app.com/

最後に一言お願いします

キーボードを買い換えてから以前まで「当たり前」と感じていた肩こりが、セパレートではないキーボードを使うと肩こりが気になる、ぐらいになった気がします。 ぜひ皆様もこの夏、セパレートキーボードデビューしてみませんか?


エディタはRubyMine、好きなサービスはAWS @wata727

最近Sublime TextからRubyMineに鞍替えした @wata727 のデスクに訪問してみます。

f:id:sideci-dev:20160805151110j:plain

最近の業務内容と得意領域を教えて下さい

新機能の開発とインフラ関係を見ています。得意領域はAWSとかクラウド系とかですかね。 ※彼はAWSソリューションアーキテクトを有しているAWSのスペシャリストです。

開発環境(物理)について教えて下さい

MacBook Air 13inchと27inchのデュアルディスプレイと至って通常の開発環境です。拘りはないですね。拘りがないのが拘り

f:id:sideci-dev:20160805151257j:plain

開発環境(ソフトウェア)について教えて下さい

エディタはがっつり開発するときはRubyMineです。軽いものはSublimeだったりvimだったりします。

Terraformの設定ファイルなどインフラ周りのファイルを変更するときにはSublimeですね。軽く動くのでとても良いです。デバッグとかになるとRubyMineがやはり必要になるけれど、軽く弄りたいときはやっぱりSublimeです。

ターミナルはiTerm2, shellはzsh。たぶんそんなに面白いことはしていないと思います。わりと普通な感じです。

f:id:sideci-dev:20160805151310p:plain f:id:sideci-dev:20160805151343p:plain

1つだけ何かをお勧めするとしたら、何をおすすめしますか?

envchainが結構好きです。AWSのcredentialみたいなセキュリティ情報をexportでベタ書きせずに、Macのキーチェーンに入れて扱えるのがいいところですね。

envchain <namespace> を頭につけてコマンドを叩くと、設定した環境変数が引っ張ってこれるので、namespaceを分ければ、環境の切り替えもスムーズにできて重宝しています。

最後に一言お願いします

最後に一言ってすっごい難しいんですけど(私の適当過ぎるフリにちょっとおこ)


RubyMine大好き!でおなじみ @Vexus2

今度はJetBrains教の @Vexus2 先生のデスクに訪問してみます。

f:id:sideci-dev:20160805151143j:plain

最近の業務内容と得意領域を教えて下さい

開発全般。開発全部みたいな感じですかね。 得意領域は継続的インテグレーション周りの整備や開発フローの構築など、チーム寄りなエンジニアかなーと自称しています。

開発環境(物理)について教えて下さい

40インチUltraHD、MacBook Airのデュアルディスプレイです。 ターミナルを別画面にしたいのでトリプルディスプレイにしたいなと思っているんですが、今使っているディスプレイが解像度が大きい故に、表示が遅いので、トリプルは厳しいかなーと思っています。 モニタを画面分割しているし、バーチャルデスクトップを沢山使っていて、画面移動しまくるので、流石に少しカクカクしますね。

f:id:sideci-dev:20160805151519j:plain

開発環境(ソフトウェア)について教えて下さい

エディタはRubyMine、ターミナルはiTerm2 + tmux、shellはzshです。

f:id:sideci-dev:20160805151310p:plain

1つだけ何かをお勧めするとしたら、何をおすすめしますか?

RubyMine以外だとTotalSpaceですね。 TotalSpaceなしでみんなが生きていける理由が知りたいです。というぐらいにお勧めです。

最後に一言お願いします

RubyMine大好きって言わされている感があるのでノーコメントで


HHKB BTを操るSublimer @sweep3092

HHKBとgitを巧に使いこなすSublimer @sweep3092 さんの机にやってきました。
彼はmixi主催の「git challenge」の優勝者です。

Bluetooth接続のHHKBがシュッと決まってます。わりと一般的そうな構成ですが、果たしてその中身は。(ところでSublime text利用者をSublimerって勝手に呼んじゃったのですが呼び方正しいでしょうか…?)

f:id:sideci-dev:20160805151155j:plain

最近の業務内容と得意領域を教えて下さい

そうですね、基本的にはフロントエンドを触る方が多いです。 得意領域はユーザの行動を考える、フロント側からサービスを考えていく、というのが得意です。

情報セキュリティスペシャリストをこの間取得しました。本番サーバでのログ出力などについても、セキュアな情報が一切含まれないように情報のマスクなどは気をつけていますね。

開発環境(物理)について教えて下さい

MacBook Pro Retina 13inch、27inchのディスプレイ、HHKB、magic trackpadです。
これは自宅や研究室のデスクなどでも同じです。
全部揃えていて、全部HHKBで、全部magic trackpadです。

f:id:sideci-dev:20160805151535j:plain

開発環境(ソフトウェア)について教えて下さい

開発はRubyMineを使っていますね。

RubyMineだと単純なタイプミスなどもすぐ気づけますし、使われてない変数なども出てきます。バグが出たときなども見当を付けやすいですね。

Sublime Textの方がサクサク動くのでそこがSublimeの方が良い点ですね。

f:id:sideci-dev:20160805151310p:plain f:id:sideci-dev:20160805151343p:plain

1つだけ何かをお勧めするとしたら、何をおすすめしますか?

ハードウェアだとHHKBですね。
ソフトウェアだとソフト的なカスタマイズをしないでおくのがすきなので、あえてほとんどカスタマイズしないで使うというのが多いですね。

会社や研究室やサーバルームなど色々な場所で色々なコンピュータを触るので、あえてカスタマイズはしないですね。
(※SideCIはAWSを主に使っており、ここでいうサーバルームとは彼が所属する大学の研究室のサーバルームです)

最後に一言お願いします

@Vexus2 さんだとRubyMine最高とか言うんでしょうね。私は「最後に一言」に適切な言葉をひねり出せなかったです。「HHKB最高」とかそういう感じで。

f:id:sideci-dev:20160805151554j:plain


その他 / 全員共通

前傾チルト機能付きオフィスチェア

f:id:sideci-dev:20160805174516p:plain http://www.haworth.com/products/seating/desk-chairs/zody

ずっと座って仕事をするので椅子は大切!ということで、弊社では前傾チルト機能、4Dアーム、ランバーサポートなどフル機能を備えたヘイワース社のゾディチェアを会社全体で使っています。 (移転直後購入が間に合わず、慌てて買った『日本の「もてなしの心」を体現したチェア』と名高いイトーキ スピーナチェアも2脚だけあるのは秘密です。)

おわりに

社内の標準構成はMBAもしくはMBPと27インチディスプレイなのですが、40インチにトライしてみたり、エディタを変えてみたり、健康志向に目覚めてみたり。開発生産性のためとあらばまずはトライしてみているメンバーが多い印象です。
ぜひ皆様も気に入った物がこの中にあればぜひ試してみて下さい。

もし会社全体の環境や開発プロセスなどについても知りたいと思って頂けた方はコーポレートサイトをご覧頂ければ幸いです。
http://www.actcat.co.jp/jobs

独断と偏見で選んだ「開発効率向上」のための有料Macアプリ6選

こんにちは!RubyMine大好き!vexus2です。 自分は「開発効率の向上が大好き、効率化のためなら生産性が落ちても良い(健康のためなら死んでもいい的な)」をモットーにしているので、こと開発マシン内の最適化にはこだわることが多いです。

最近メインモニタを40インチにしたり開発環境周りを多少変えてみたので、私が使っている主に開発周りでのMacアプリをいくつか紹介してみます。

なお、エディタ系とかKarabinerとか、Alfredみたいな定番のいわゆる「おすすめアプリまとめ」の類はあえて省いています。

TotalSpaces2($11.99)

totalspaces.binaryage.com

f:id:sideci-dev:20160719122047p:plain

仮想デスクトップを構築するソフトウェアです。OSX Mavericks以降はMissionControlでも似たようなことが出来ますが、MissionControlだと横一列にデスクトップが並ぶのに対して、TotalSpaces2では縦横に構築できるのでデスクトップ間の移動が非常に高速です。

また、各アプリごとにどの仮想デスクトップに表示されるかを固定することができるので、例えば

  • 仮想デスクトップ1 -> 開発スペース(エディタ、ターミナル系)
  • 仮想デスクトップ2 -> ブラウザスペース(Chrome, Safari他)
  • 仮想デスクトップ3 -> マルチメディア系スペース(itunes他)
  • サブモニタ -> Slack

みたいにデスクトップごとに役割を固定化させることができるのでどこのデスクトップでなんのアプリを開いているのかというごちゃごちゃ感が少なくなることで脳内のスイッチングコストが少なく、アプリがいっぱい起動している状態でも低ストレスかつ高速にアプリ間を移動できます。

また、デスクトップ間移動時のトランジション(エフェクト)を無効にすることで移動が更に高速になって便利です。

デスクトップ間移動のショートカットはトラックパッドに割り当てられていますが、上下左右を縦横無尽に動きまわるためにキーボードにも割り当てておくことを個人的におすすめします。

BetterSnapTool(360円)

BetterSnapTool を Mac App Store で

f:id:sideci-dev:20160719145118p:plain

ウィンドウのリサイズやドラッグ周りを拡張してくれるツールです。Windows7的な感じで画面端にウィンドウをドラッグした時に吸着しながら拡大とかも設定できます。(個人的にはドラッグでウィンドウを移動することはないので全く使ってません)

そこそこ大きめのモニタを使っていると画面内でアプリやエディタを2分割、3分割、4分割・・・としたくなると思います。

このツールでは今開いているアプリを画面の右半分で開くなど、右の1/3で開くなど縦に2分割、3分割がショートカット上でできるようになります。

また、デュアル/トリプルモニタを使っていると「今開いているアプリをサブモニタに移動したい」ケースって多々あると思うんですが、このツールなら「今開いているアプリを次のモニタに送って最大化」とかができるのでめちゃくちゃ快適です。

トラックパッドを使ってアプリをリサイズしたり移動していた頃が懐かしく思えるくらいに快適なので、画面を分割したりとかサブモニタ頻繁に使う方にはぜひオススメしたいツールです。

Jitouch2($7.99)

f:id:sideci-dev:20160720104611p:plain

jitouch 2 - Multi-Touch Extension for MacBook Multi-Touch Trackpad & Magic Mouse

トラックパッドでの操作を強力に拡張してくれるツールです。

類似にBetterTouchTool(BTT)がありますが、こちらも最近有料化しました。Jitouch2とBTTのどちらを使うかは割と好みの問題かなあと思いつつ、文字ジェスチャにアクションが割り当てられるのでJitouch2を使っています。

OSX El Capitanになってからたまにコマンドが認識されなくて、Jitouch2の再起動が必要だったりすることが増えたのでちょっとめんどくさいなあと思うことはたまにありますが、それでもやはり便利です。

Duet Display(2300円)

f:id:sideci-dev:20160719141849p:plain

www.duetdisplay.com

Macに接続してiPadをデュアルモニタにしてくれるツールです。LPには「生産性が最大48%向上します」と書いてあるのにスクリーンショットには「生産性が2倍になります」と謳っていたり、サイトの日本語が色々怪しかったりといったこともありますが、ツールとしてはとても便利です。

割とお高いお値段する割には動作が安定しないことが多いので、メインモニタがある状態からのトリプルモニタ用途というよりは、自席以外での開発でのサブモニタとしてブラウザとかSlackとかを表示しておく用途向けで個人的に重宝しています。今後、安定性が向上してくれることを切に祈ります。

MenubarClock(120円)

Menubar Clock | NagisaWorks

f:id:sideci-dev:20160719142820p:plain

最大3つまでのタイムゾーンでの時計を同時に表示できるツールです。弊社でも日本以外のリモートメンバーも増えたということもあり、「現地時間だと何時だっけ・・・」というのをサクッと把握できるのでべんりです。

Yoink(840円)

Yoink - ドラッグ & ドロップを快適なものに を Mac App Store で

D&Dなどでのファイル移動時にテンポラリ領域を作ってくれるツールです。昔はDragonDropというツールがあったんですがひっそりとApp Store上から消えてしまったので乗り換えました。

画像貼り付けたりとかするときに一時的にデスクトップに置いて別アプリにドラッグしたりすると思いますが、そういう時にこのYoinkのスペースに一時的に入れといて取り出す、みたいな使い方ができます。個人的には便利だなーと思って使ってますが、デスクトップが汚れるの気にならない派の人にはそこまでなくても困らないかもしれないです。

まとめ

Macアプリ系は意外と値上がりすることが多く、買おうと思ったら前見たときより値段が倍になっている、なんていうこともザラなので欲しいと思ったときに買ってしまうのが良いかなぁと最近思っています。

アクトキャットでは自分自身やエンジニアの生産性を高めたいという人を募集中です。ご興味ある方はぜひ以下からご応募ください!

www.wantedly.com

グロースハッカーがエンジニアと会話するときに心がけている7ヶ条

はじめまして。 SideCI運営元のアクトキャットにてグロースハック及びマーケティング周りを担当している@cage0703と申します。

f:id:sideci-dev:20160706113439p:plain

今回は「グロースハッカーがエンジニアと会話するときに心がけている7ヶ条」と題しまして、スタートアップという限られたリソースの中で開発に集中しなければならない組織において、非エンジニア職である私がどういったことを心がけながらエンジニアとの業務にあたっているかという点をまとめてみたいと思います。

通常エンジニアとグロースハックは別の組織になることが多いかと思いますが、目的達成のためには2者間における入念なコミュニケーションは必須です。

ただ弊社のようなスタートアップフェーズにある組織では、エンジニアのリソースもまだまだ少ないことから、MTGなどの共有・調整作業は最小限に抑える必要があります。

よってすべての業務において時間をかけずに最適な解を導くという考えで物事を進めていくことが必要となってきます。

グロースハッカーとエンジニアの関わり

さて、いきなりですが質問です。 皆さんが関わっているプロダクトにおいて、ユーザの数や質をGrowthさせる方法はいくつありますか?

おそらく1つしかないって方は少ないのではないでしょうか?

お金やリソースなど環境を含めて制限を考慮しなければ、少し時間をとって考えてみるだけでも非常に多くの施策が出てくると思います。

そしてその施策はプロダクトサイトの改修、広告、プロダクト自体の改修と内容も多岐にわたっているはずですので、ステークホルダーは非常に多くなります。

グロースハッカーはプロダクトを深く理解し、現在の課題分析や、そこからの改善案を考えられるプロでなくてはなりません。

ただ、プロダクト(ソースコードなどの内部的な作り、仕組み)への理解においては、おそらくエンジニアを上回ることは難しいでしょう。

つまり、いくらクリティカルな課題を見つけ改善案をイメージできたとしても、最終的な実装の際にエンジニアの協力がないと、様々なパターンの中で最適な解を導くことができないのです。

以下、そんな中で私が注意していること7ヶ条を記しました。

エンジニアと会話するときに心がけている7ヶ条

1. 定性、定量の両面から考察する

  • やること例
    • 相談したい課題の要因について、定性的な推測だけでなく裏付けとなりうる定量的なデータの収集を心がける
  • 効果
    • 話す内容の裏付けが確立される
  • メリット
    • 自信を持って会話することができるようになる
    • 相手に伝わりやすいので、相談時間の短縮につながる
    • 根拠の部分がしっかりとするので、納得されやすい

2. KGIとKPIを明確にする

  • やること例
    • KGI(最終目的とする指標)とKPI(KGI達成のために見るべき指標)が何なのかをあらかじめ設定してから、分析などの作業を行う
  • 効果
    • 最終的な目的とそのために考慮するべき指標が明確になる
  • メリット
    • 話や施策がぶれにくくなる(ぶれたとしても気づきやすい)
    • 最終的な目的が指標として明確になっているので、相談された側も助言しやすい

3. 5W1Hを明確に伝える

  • やること例
    • 相談内容を5W1Hを考慮したかたちで共有する
  • 効果
    • 誰がいつ何をどうすればいいかなど、漏れなく明確に定義できる
    • 内容を容易に把握することができる
  • メリット
    • 定義が明確になることで、タスクを正確に管理、遂行することができる

4. 常にコスト(工数)をイメージする

  • やること例
    • 自分がやろうとしていること、依頼しようとしていることのコストを考える
  • 効果
    • 物事に対して費用対効果を考える癖がつく
    • 依頼するタスクの規模感(難易度)が把握できる
  • メリット
    • 無駄なタスクが発生しづらくなる
    • 依頼前に実現可能かどうかの一時判断と優先順位付けができる(事前にスケジューリングしやすい)

5. 事前にアジェンダを共有する

  • やること例
    • 相談やMTGの前にアジェンダを展開して確認を促す
  • 効果
    • 事前に議論の概要を抑えてもらうことができる
    • 資料も事前に共有しておけば、内容をより深くまで理解してもらえる可能性が高まる
  • メリット
    • すぐに本題に入ることができる
    • より本質的な質問が発生する可能性が高くなる

6. クリティカルシンキングで考える

  • やること例
    • 事象をロジカルに組み立てるだけでなく「なぜ」などの問いかけをしながら思考する
  • 効果
    • 思考をより多角的かつ深いところまで落とし込むことができる
  • メリット
    • 個人の範囲で深くまで考えることができるので、他者からの質問に対してスムーズに回答することができる(時間短縮)
    • 詳細まで考えることができるので、潜在的な課題に気づく確率が上昇する
    • 相談の場で発生するであろう質問に対する回答を、事前に網羅することができる

7. メンバーと業務以外での共通時間を持つ

  • やること例
    • お昼ご飯に一緒に行く
    • 雑談してみる
  • 効果
    • 仕事うんぬんの前に、人としての距離が縮まる
  • メリット
    • 相談事をするハードルが下がる
    • 接しやすくなるので心理状態が良化する

最後に

これらの7箇条はエンジニアとグロースハッカー間だけではなく、上司や多職種の人とのコミュニケーションの際にも役に立ちます。

多少当てはまりの悪い内容もあるかもしれませんが、観点としては様々な業務に通じるものかと思いますので、それぞれ解釈して頂けると幸いです。

現在アクトキャットでは一緒に働いて頂けるメンバーを募集しています。 Webエンジニアの方、インフラエンジニアの方、Webデザイナー、マーケターの方を積極採用中です! 社員1桁台のスタートアップに興味がある方はぜひWantedlyからご応募ください!

https://www.wantedly.com/companies/actcat/projects

「エンジニア向けサービスを支える技術」を開催しました。SideCI Study 1th

sideci_study

こんにちは。 @sumyapp です。
6月29日にSideCIチーム主催でテックイベント(勉強会)を開催しました!その様子をご紹介します:) 株式会社はてなさんのMackerelチームと共同で開催させて頂きました。

テーマは「エンジニア向けサービスを支える技術」です。
エンジニア向けサービスを提供している会社様3社に登壇して頂きました。(+弊社)

sideci.connpass.com

ダイジェスト

  • 19:30~19:40 イベント内容や登壇者様、会場のご紹介
  • 19:40~20:50 発表 + QA
    • SideCIのインフラ構築を自動化した話
    • エンジニア向けSaaSを開発・運用するということ ~ Mackerelの場合
    • Mobingi: Have FUN! with Spot Instance
    • DeployGateの作り方
  • 20:50~21:00 懇親会の準備 & 宣伝タイム & 事後アンケート
  • 21:00~22:00 懇親会わいわい(BEER & PIZZA etc…)

会場はMackerelを運営しているはてなさん。
木目の壁に銀色のロゴはカッコイイ! f:id:sideci-dev:20160704172124j:plain

19時開場後、続々と人が集まってきました。
ちなみにここはSHIBAFUというセミナールームで、床は名前の通り芝生で覆われています。

f:id:sideci-dev:20160704172158j:plain

余談ですが、普段はテントがあったり昼食を食べるスペースがあります。(設営前の風景です)

f:id:sideci-dev:20160704172212j:plain

早速始まりました!本記事では、会場説明等は省略して、いきなり発表セッション。
(※カメラマンと司会が兼任のため写真がなく...(T-T)

まずは私たちSideCIチームの若手(若手というか本記事記載時点で22歳とガチで若い)の @wata727 が発表させて頂きました。

f:id:sideci-dev:20160704172228j:plain

QAセッションでもゴールデンイメージやPush/Pull型のデプロイなどについて質問が上がりました。


続いて株式会社はてな、Mackerelチームの @songmu さんこと松木さんの発表。

f:id:sideci-dev:20160704172241j:plain

sideci-mackerel_p01.png エンジニア向けSaaSを開発・運用するということ ~ Mackerelの場合 http://songmu.github.io/slides/sideci-mackerel/#0

皆さん真剣に聞いておられます。その後QAセッション。

f:id:sideci-dev:20160704172254j:plain 深い話が盛りだくさんで、もっと聞きたかった!との声もたくさん頂きました。


続いてMobingiチームの望月さんとWaylandさんが発表。
日本語で簡単に製品の紹介->簡単な英語でのデモ+Mobingi EnterpriseでのSpot Instanceを利用したオートスケールの話。

f:id:sideci-dev:20160704172311j:plain QAではスポットインスタンスの場合のAWSでの入札額によって、インスタンスが確保出来なかった、ダウンした場合などにについての質問とお話がありました。


最後にDeployGateチームのへんてこさんがテンションアゲアゲで発表してくれました。

f:id:sideci-dev:20160704172329j:plain

大盛り上がり!

f:id:sideci-dev:20160704172402j:plain

この後、懇親会の準備を後ろで進めながら、恐縮ながら各社の宣伝タイム + アンケート等させて頂きました。

そして懇親会!
「懇親会からが本番ですよね!」と乾杯の音頭をsongmuさんから頂きスタート。

写真はここでおしまいです、ごめんなさい!
参加者30名強に対して60人分のピザ+ビールという状態で、 カメラを忘れてピザを食べるのに夢中。 もしピザの写真をお持ちの方いましたら @sumyapp まで頂けると嬉しいです!

皆様ご参加頂きありがとうございました!

LT

ダイジェストでもリンク記載させて頂きましたが、改めて皆様のスライドやブログ等へのリンクをご紹介させて頂きます。

SideCIのインフラ構築を自動化した話

スライド資料です。 https://speakerdeck.com/wata727/sidecifalseinhuragou-zhu-wozi-dong-hua-sitahua

エンジニア向けSaaSを開発・運用するということ ~ Mackerelの場合

スライド資料です。 http://songmu.github.io/slides/sideci-mackerel/#0

Mobingi: Have FUN! with Spot Instance

Mobingi Enterpriseの実際の画面でデモをしながらの話。 スライドではなく実際のサービスサイトのリンクを掲載させて頂きます。

https://mobingi.co.jp/saas-public-aws

発表にあったスポットインスタンスを使う機能はまだパブリックにはなっていないらしく、Facebook Pageの投稿から内容をご紹介させて頂きます。(2016年6月30日現在)

ワンクリックでスポットインスタンス/リザーブドインスタンス/オンデマンドの自動切り替えを行う新機能により、最大30%もの利用料金の削減に成功!Mobingiの技術を駆使したコンテナオーケストレーションにより、ゼロダウンタイムを実現しました。 https://www.facebook.com/mobingitokyo/posts/1813308045572272

DeployGateの作り方

参加ブログも書いて頂きました!(ありがとうございます!) http://henteko07.hatenablog.com/entry/2016/06/30/100000

スライド資料も上記ブログに記載があります。

Twitterでの様子

QA含め色々な方にツイート頂きました! スライドにのっていない部分や雰囲気はこちらから

togetter: http://togetter.com/li/995623

おわりに

たくさんの方にご興味持って頂き誠にありがとうございました!今後も #sideci_study というハッシュタグを使いながら、SideCIについて勉強するわけではなく、SideCIチームが聞きたいと思っている話などを中心にイベントを開いていこうと思います。

今回、100名を超える方に申し込みを頂いておりましたが、初回開催のため人数少なめで開催させて頂きました。次回以降よりブラッシュアップしていきますので、ぜひご参加下さい!

SideCIの製品やメンバーについてはこちらをご参考下さい。(メンバーも募集しております!) https://sideci.com/ja http://www.actcat.co.jp/jobs

RuboCop 0.41 / 0.41.1 がリリースされました。

こんにちは、RuboCop大好き@pockeです!

f:id:sideci-dev:20160628100359p:plain

先日(日本時間2016年6月26日)、RuboCop 0.41及びバグ修正リリースの0.41.1がリリースされました。
0.41 では13個のCopの新規追加の他、機能追加、バグ修正などが行われております。
また、0.41.1では新規追加されたCopがRailsプロジェクトにおいてクラッシュしてしまう問題が修正されています(該当のPR)。
そのため特にRailsプロジェクトでRuboCopを使用しているのであれば、バージョン0.41.1を使用することをおすすめします。

また今回のリリースでは、先ほど紹介したバグ修正を含むいくつかのコミットに私も関わっています。 ですので今回のリリースの概要を紹介させていただきたいと思います。

では、CHANGELOGを読んでいきましょう。

Release RuboCop 0.41 · bbatsov/rubocop

New Features

新規Cop

今回のリリースでは、13個の新規Copが追加されました。

  • Style/SpaceInsidePercentLiteralDelimiters
  • Style/SpaceInsideArrayPercentLiteral
  • Style/NumericLiteralPrefix
  • Style/ImplicitRuntimeError
  • Style/EachForSimpleLoop
  • Lint/ShadowedException
  • Lint/PercentSymbolArray
  • Lint/PercentStringArray
  • Lint/InheritException
  • Performance/PushSplat
  • Rails/RequestReferer
  • Rails/OutputSafety
  • Rails/Exit

以下で一つ一つ見ていきましょう。

Style/SpaceInsidePercentLiteralDelimiters

Rubyのパーセント記法において、パーセントの内側にスペースが書かれてしまっていることを指摘します。

# Good
%i(foo bar baz)

# Bad
%i( foo bar baz )

Style/SpaceInsideArrayPercentLiteral

上のStyle/SpaceInsidePercentLiteralDelimitersと似ていますが、Rubyのパーセント記法において、余分なパーセントが入っている場合を指摘します。

# Good
%i(foo bar baz)

# Bad
%w(foo  bar  baz)

Style/NumericLiteralPrefix

数値リテラルのプレフィックスを統一するよう指摘します。

See. リテラル (Ruby 2.3.0) #数値リテラル

Style/ImplicitRuntimeError

暗黙的なRuntimeErrorを指摘します。

# Bad
# 文字列を直接投げると、RuntimeErrorが暗黙的に適用されてしまう
raise 'error'

# Good
raise ArgumentError, 'error'

Style/EachForSimpleLoop

.eachをよりシンプルに出来る場合を指摘します。

# Bad
(0..10).each { }

# Good
# 上の例はtimesで置き換えられる
10.times { }

Lint/ShadowedException

rescue節において、一般的な例外クラスがより限定的な例外クラスより前に置かれていることを指摘します

# Bad
begin
  something
rescue Exception # ExceptionはStandardErrorの親クラスなので、StandardErrorの例外もここで拾ってしまう
  handle_exception
rescue StandardError
  handle_standard_error
end

# Good
begin
  something
rescue StandardError
  handle_standard_error
rescue Exception
  handle_exception
end

Lint/PercentSymbolArray

RubyのSymbolのパーセント記法において、必要のない文字が入っていることを指摘します

# Bad
# : と , はパーセント記法では必要がない
%i(:foo, :bar)

# Good
%i(foo bar)

Lint/PercentStringArray

Lint/PercentSymbolArrayと同様、RubyのStringのパーセント記法において、必要のない文字が入っていることを指摘します

# Bad
# ' , " はパーセント記法では必要ない
%w('foo', "bar")

# Good
%w(foo bar)

Lint/InheritException

Exceptionを直接継承した例外クラスを指摘します。
Rubyでは通常、Exceptionを直接継承した例外クラスは定義せず、StandardErrorなどから継承します。
See Rubyで独自例外を定義するときはStandardErrorを継承する - Hack Your Design!

# Bad
class SomeError < Exception; end

# Good
class SomeError < StandardError; end

Performance/PushSplat

配列を連結する際に、パフォーマンスが悪い方法で書かれていることを指摘します。

# Bad
[1, 2, 3].push(*a)

# Good
[1, 2, 3].concat(a)

Rails/RequestReferer

Railsにおいて、request.referrerrequest.refererのどちらかを使用するよう統一します。

本来、参照元という意味の英単語は「referrer」であるが、HTTPリファラの場合は意図的に「referer」と綴る場合がある。これは、HTTPが策定された時にヘッダ名を間違ったスペルで書いてしまい、それが今でも使われている、という歴史的経緯のためである。

HTTPリファラ - Wikipedia

Rails/OutputSafety

RailsのView / Helper等で、.html_safeを使っているものを指摘します。

Rails/Exit

Railsアプリケーション内で、exitメソッドを使用していることを指摘します。
通常はexitの代わりに、raise, break, returnなどを使用すべきでしょう。

注目する新機能

新規Copの他に、以下の2点の新規機能に特に注目しています。

.ruby-versionを見るようになった

RuboCopはデフォルトではRuby 2.0を想定したパーサで解析を実行します。
この挙動は従来、下記のように.rubocop.ymlを設定することで変更可能でした。

# Ruby 2.3 のパーサを使用する場合
AllCops:
  TargetRubyVersion: 2.3

RuboCop 0.41からは、.rubocop.ymlの設定より優先して、.ruby-versionの内容から使用すべきパーサのバージョンを推定するようになりました。

テスト用のヘルパー関数がGemに含まれた

これは主にRuboCopプラグインを開発している人を対象とした変更です。

従来、RuboCopのテストヘルパー関数はspec/下に置かれていました。
Gemとして配布する際にはspec/下は含まれていなかったため、RuboCopプラグイン開発者はgit submoduleなどを駆使して別途RuboCopのソースコードをプロジェクトに含める必要がありました。

今回の変更でテストヘルパー関数はlib/下に移され、Gemにも含まれるようになりました。
その為、プラグイン開発者もRuboCopをGemとしてインストールするだけでテストヘルパー関数をプラグインから利用することが可能となりました。

その他機能追加

CHANGELOGからのコピペになりますが、以下にその他の新規機能をまとめます。

  • Add IndentationWidth configuration parameter for Style/AlignParameters cop.
  • New compact style for Style/SpaceInsideLiteralHashBraces.
  • Add Fastlane's Fastfile to the default Includes.
  • Make Style/ModuleFunction configurable with module_function and extend_self styles.
  • Allow arbitrary comments after cop names in CommentConfig lines (e.g. rubocop:enable).
  • Add configuration style indented_relative_to_receiver for Style/MultilineMethodCallIndentation.
  • Add autocorrect for Rails/Validation cop.
  • Add autocorrect for Style/EachForSimpleLoop cop.

その他

数多くのバグ修正と、いくつかの修正が行われたようです。

まとめ

RuboCopのCHANGELOGをまとめてみましたが、いかがでしたでしょうか?
これを機に今書いているRubyのスタイルを見直してみるのも良いかも知れません。

また、SideCIでは最新のRuboCop 0.41.1がお使いいただけます! 是非一度お試しください。

スタートアップでも管理画面を作ろう!フルスクラッチの管理画面がもたらす効果

こんにちは!アクトキャットでエンジニアをやっています、 sweep3092 と申します! ユーザ視点に立ったものづくりが得意で、SideCIでも主にクライアント寄りの開発を担当しています。

先日、SideCIの社内向け管理画面のリニューアルを担当いたしました。本記事ではその際に私が心がけたポイントをいくつかご紹介いたします。

ActiveAdminを使わない理由

リニューアル前は管理画面にActiveAdminを使用していたのですが、リニューアルに当たってフルスクラッチで開発をすることにしました。

SideCIでは多くのお客様の多種なプロジェクトに対して解析を行っているという特性上、 たとえば不具合のご指摘をいただいた際には都度詳細なエラー内容の調査が必要になります。 迅速な返答や対応のためには、適切な検索条件を設定できることや、エラー情報を生データではなく調査に最適な表示をすることが望ましくなります。 ActiveAdminやre:dashなどを使用すると驚くほどさくっとCRUDを備えた管理画面を作ることができる一方で、 これらを生のデータではなく最適化された表示を用意したり、 社内の要望に沿った検索条件を用意したり、 データベース以外の操作が必要なオペレーションに対応しようとしたり、 などの要望への対応はかえって実装や管理が大変になってしまっていました。

心がけたポイント

1. 想定されるユーザを明らかにすること

前述の通り現在弊社は社員のほとんどがエンジニアで、開発しているサービスもエンジニア向けのものになります。 そのためついついエンジニア視点でエンジニア向けの開発をしてしまいがちなので、今回は特に ターゲットユーザを明確にする ことを心がけました。

今回のリニューアルでは、markdownで記述するSideCIのドキュメント管理画面にプレビュー機能を設けました。 この機能によってドキュメント画面内で公開された場合のプレビューを確認できるようになり、入稿・公開時の意図しない表記崩れなどを防ぎやすくなりました。

f:id:sideci-dev:20160622105052p:plain

また、弊社にはクーポン発行機能がありますが、これらのユースケースはある程度限られています。 発行にあたってはいくつかの入力項目がありますが、プリセットを「クーポンの目的」として用意してやることで、 入力ミスや意図に沿わないクーポンを発行するなどのヒューマンエラーを回避できるようになりました。

f:id:sideci-dev:20160622105132p:plain

2. ユーザのユースケースを明確にする

ユーザのオペレーションの中でも、

  • ミスが発生しそうなこと
  • ミスしたときのリスクが高いもの

を意識し、確認できるような仕組みを心がけました。 あえて工数を割いて管理画面を作るのは、こうしたミスが起こりにくくすることも大きな理由だと考えています。

例えばユーザの契約プランを初期化するような超イレギュラーなオペレーションに対しては、 GitHubのリポジトリ削除画面を参考に3段階の操作が必要なものにし、極力ミスが起こりにくくなるような導線にしました。

f:id:sideci-dev:20160622105157g:plain

3. 時間をかけすぎないこと

フルスクラッチするといっても開発リソースは限られており、本来その限られたリソースは社内向けの管理画面では無くプロダクトそのものに使われるべきです。 最小限のリソースで最大限の効果を発揮するものを作る という点を意識することがより一層求められます。 要望に対して思い込みで機能を無駄に作り込んでしまったり、親切心で誰も使わない機能を作ったりしてしまうことは避けなければなりません。

おわりに

管理画面は必ずしもサービス立ち上げ初期に必須なものではなく、また直接的なサービス向上に繋がらないことも多いですが、 むしろ限られた開発リソースを開発に注ぐために開発以外を効率化する、という観点からは有意義なものになると思います。 また社内向け管理画面の開発は要望やフィードバックがすぐに得られるので、ユーザが本当は何を求めているのかを考える勉強にもなります。

今回の内容は「よく考えられた管理画面」という書き方でご紹介させていただきました。 しかしながら、これは弊社の現時点でベターであると選択したものであり、正答というわけではありません。 皆様のフェーズや課題に合わせてご検討いただき、本記事がみなさまの快適な管理画面ライフのお力になれれば幸いです。