Docker で Golang の開発環境を整えてみた

この記事は Docker Advent Calendar 2018 の21日目の記事です。

前日は jin_yokoyama さんの Elastic Stackで簡単！Dockerコンテナ監視ダッシュボード作成 でした！

f:id:zoe302:20181220220023p:plain

こんにちは、みなさん Docker 活用してますか？

私はもっぱら開発環境として Docker を利用しています。

普段業務では PHP を触ることが多いのですが、プライベートの開発では Go の開発などもやっています。

そこで今回は私が普段 Go の開発環境として使っているものをご紹介したいと思います。

コード

解説より先に実物を見たい方はこちら

github.com

解説

この開発環境では下記のようなディレクトリ構成になっています。

$ tree ./
./
├── Makefile
├── README.md
├── docker-compose.yml
├── go
│    ├── Dockerfile
│    ├── Makefile
│    └── main.go
└── run
    └── Dockerfile

./Makefile

このファイルは docker-compose のラッパーとして存在しています。Go をビルドして実行したいときには make up と実行するとまるっと実行してくれます。

./docker-compose.yml

今回の構成では Go のビルド用のコンテナと実行用のコンテナを分けています (multi-stage-build)。これらのコンテナを管理するために利用しています。

./go/

Go のビルドをするためのディレクトリ及び、Go のソースコードを管理しているディレクトリです。

./go/Dockerfile

Go のビルド用の Dockerfile です。

./go/Makefile

Go のコマンドのラッパーです。Dockerfile からのインターフェースとなるように設計しています。もともと Makefile はコンパイルの自動化、依存解決に強いツールなので、Go のコンパイルととても相性が良いです。

./go/main.go

Go のコードです。今回は hello world するだけのコードを置いてます。

./run/

コンパイルした Go のバイナリファイルを設置して起動する用のディレクトリです。

./run/Dockerfile

ベースイメージは busybox を使って、multi-stage-build (COPY --from={image名}) を使ってビルドしたgoのバイナリファイルを取得して設置、実行しています。

利点

この設計にしておくことで run のコンテナイメージを共有することですぐに動く環境を共有することができ、かつベースイメージが busybox のためとても軽量で済みます。(今回の内容では3MBのイメージになりました！)

また、Go のコマンドを実行したい際には make run CMD='go fmt main' のようにすることで実行することができます。ファイルもマウントされているため、 go fmt で直ったものがホストマシンにも共有されます。

まとめ

Docker, Docker-Compose をうまく活用することで簡単に環境に左右されない開発環境を構築できるのはやっぱりとても楽ですね。

皆さんもこの機会にDockerで開発環境構築してみてはいかがでしょうか。

【随時更新】PHPカンファレンス2018参加した

2018/12/14 PHP カンファレンス2018に参加したので聴講したセッションを雑にまとめていきます。

phpcon.php.gr.jp

スライドまとめ

PHPの今とこれから

PHP5系のサポート終わるよ、アップグレードしようね。PHP7.0ももうサポート切れたよ。

ヒアドキュメントの改善のはなし、mbstringのはなし

  • PHP7.3の新機能
    • csrf対策デフォルト対応
    • is_countable()関数追加
    • 関数の末尾カンマ対応

php7.4開発していくよ プリロードして応答速度早くするよ、プロパティtyの型を設定できるようにするよ

[Track 4] 独立したコアレイヤパターンによる PHP アプリケーションの実装

[スライド後で張る]

Webサービスが解決したい課題のシステムとWebシステム自体はドメインが別だから分けた方がいいよね

レイア分けが薄いとファットコントローラ、もしくはファットモデルになりやすい

ユースケースをサービスレイアに分けると、肥大化したモデルのビジネスロジックをきりだせる！すごい！でも、完全には切り出せないことが多い、、

レイアードアーキテクチャを採用してみよう、レイアが細かく分ける手法が多いのでうまく分割しやすい、がドメインレイアの設計分析が大変、、、サービスによってはミスマッチになりうる

そこで、whatとhowをレイアとして分割して実装していく、コアレイアはフレームワークに依存しないようにDIP 等を使って設計していく。

こうすることで、フレームワークが変更なったとしても、問題ない。

なぜなら私たちは、「FW をうまく扱いたいのではなく、アプリケーションをうまく作ることなんだ」

[Track 2] 継続的なバージョンアップのためのテスト戦略 〜自動テストの導入とコンテナ化〜

自動テストを導入することで、段階的なリリースができるようになり、段階的なリリースができるようになった。

段階的なリリースができることで細かいバグに気づけるようになった。

テストの方法について、どういうテストはいやか、から考えていった。

Codeception いいぞ。

[Track 3] アーキテクチャ設計とUX設計は同じなのか!!?? 企業ブース回ってました

[Track 2] php-fpm をもっと理解しよう

php-fpmのステータスを見ながらプロセス制御の数を見てみた。staticやdynamicやondemandの違い。

大体知ってる内容だったけど、すごいまとまっててよかった

[Track 5] レビューで初心者インターンを一人前に育てた話

社員16でインターン40人でどうやって回していったかというような話

インターンの志望動機の100%が自己成長のためだった！

教えるなんておこがましい、成長をアドバイスできる立ち位置で居続けるのが大事。ネガティブなFBを恐れずに行動がポジティブになるようFBすること。

失敗したときに振り返り＋ネクストアクションを伝える。

応援されてることを知ってもらう。応援し合える関係を作り出す。

コミュニケーション回数を増やす、分報や、1on1など

分報チャンネルに検索ワードを貼り付けておく。すると先輩が細くしたり説明してくれたりする。

その場でペアプロで修正して教えてあげたり。

関係性の構築、明確に伝達、結果を共に確認。

インターンだけじゃなくてチーミングに共通する話だなぁ。

[Track 1] Webサービスを育てるための組織作りと文化作り

Webサービスは生き物のように変化していく、想定している変化想定していない変化がある。それに対応できるように、それを育てるチームの成長が求められる。

組織がチームの文化(カラー)を作り、チームがサービスを作る。

コンウェイの法則と同じでいいチームがいいサービスを作れる。

組織はマネージャーが変えられる。

文化はプレイヤーから変えられる。

「適切な問題が生まれれば自然と解決する人が生まれる」ので、正しく課題を分割することが大事。

成長するためには、できる限界の少し上をやっていくこと。

マネージャーの本質は課題提供すること、プレイヤーの本質は課題解決すること。

【貴族会アドベントカレンダー8日目】今年一年あったこと、習得した技術を振り返るなど

振り返り アドベントカレンダー

この記事は 貴族会 Advent Calendar 2018 - Adventar 8日目の記事です。

前日はシェーランさんの記事でした！

note.mu

アドベントカレンダーも8日目ということで、世の中は着々と年末へ向かって行ってます。

と言うことで、いい機会なので、自分の今年一年の振り返りをしようかなと思います。

大した内容は書いてないのでざーっとみていただければなと思います。

f:id:zoe302:20181208125507j:plain

1 ~ 3月

仕事

年明けすぐにサポーターズコラボで登壇させていただいたりしてました。

【サポーターズ勉強会】【PHP7 実践編】事例で学ぶ CakePHP と Laravel の徹底比較 - サポーターズCoLab

実はこの頃、もう一つ登壇してまして3社で合同でイベントやりたいという話になり、イベントの企画、開催、登壇をさせていただきました。

【増枠！】【PHP事例】プロダクトをレガシーにしないために闘う現場のリアル - connpass

他社さんとバージョンアップに対しての動き方など話せてとてもたのしかったです。

また、この頃から、2〜3人月程度の規模のプロジェクトを任せられるようになり、初のPM業務で色々勉強していました。

初めてのPM業だったため、要件の握りや、設計、スケジューリング、進捗のレポーティングなどがうまくできず苦労しました。

しかも、この時同程度の規模のプロジェクトを初めてなのに一人で3つ抱えていたのも失敗した原因だったなと思います。

自分のキャパを把握しておくことは大事ですね。

3月の末ごろから新しいプロダクトで、Laravelを使うぞ、という話が上がってたので、チームでLaravelを書いてみる会と言うのをやっていました。

他チームではすでにLaravelの経験があったのですが、私の所属しているチームでは経験者がいなかったのでモブプロ形式でLaravelを使った簡単なアプリケーションを作って練習と言うのを毎週2時間くらいとってやっていました。こういう新しいものを取り入れるために動ける環境はとてもいい環境ですね。

プライベート

昨年末から開発していた、仮想通貨を題材にしたサービスをローンチしたり機能追加の開発をしたりしていました。 仮想通貨でそれなりのインパクトのある大きなニュースがあったこともあり、想定よりは伸びなかったですが、やっとまともなサービスをローンチできたいい経験になりました。

また、サービスローンチ後RDSの負荷が高く、閲覧していると死ぬことが多発したため、MySQL互換のあるAuroraに載せ替えるという経験もできました。

かなりスムーズにAuroraに以降もできたのでとても使いやすかったです。

4 ~ 6月

仕事

引き続きPMとして3プロジェクトみながら、新サービスのインフラ構築を担当していました。

業務では初めての一からのインフラ構築でした。またこの頃から社内でTerraFormを使おうという流れになっていたので、私も勉強してダイナミックインフラストラクチャーを構築できるようにしました。

構成としてはTerraForm+Ansibleという感じです。

また、4月になったので新卒社員も入ってきたので、そのメンターもやっていました。私のチームには新卒社員が二人入ってきたので、最初のころは二人みるのが大変でした。

この頃からプロジェクトに人が足りないことに気づき業務委託採用をするようになりました。面接の限られた時間で人を見極めるのって難しいですね。

サポーターズコラボでの登壇もまたやっていました。会社のサービスのバージョンアップについてまとめた内容を話しました。みなさんちゃんとバージョンアップ対応していますか？？

【サポーターズCoLab勉強会】PHP5.xから脱却する為の道のり - サポーターズCoLab

Laravel勉強会がひと段落したので、この頃からサービスワーカーの勉強会を週次でモブプロ形式でやっていました。新しいものをチームで学ぶのめっちゃ楽しいのでおすすめです。

この頃、社内の別チームでGoでバッチを書くので、知見がありそうだからPRをみてくれとオファーされました。別チームでもこのように技術的に知見がある人が入っていって課題解決したりアドバイスできるような環境、関係を築くことができていて、とてもよかったです。

プライベート

プライベートで言うとこの頃は仮想通貨サービスの開発がある程度ひと段落してきたのもあり、勉強会に通うことが多かったです。

Go勉強会や、k8sの勉強会などに積極的に参加していました。

7 ~ 9月

仕事

今までやっていたPM業がひと段落して、ちょうどその頃に別サービスがたち上がり、 バックエンドのリソースが足りないと言うことで急遽アサインされました。

LaravelでSPAでフロントはReactでというような構成でしたが、僕がジョインした段階ではちゃんとした定義書や要件が全然まとまっていなかったので、 その部分を整えるところから入って行きました。このプロジェクトに関しては、色々課題はあったものの、なんとか納期には間に合ったのでよかったです。学んだこととしては、ちゃんとリリーススコープを決めて要件を詰め切ることは大事なんだなと言うことをしみじみ実感しました。

長期インターンを募集していたところとてもスキルの高い子が入ってくれたので、採用しました。 若い子のスキルが高すぎておじさんはすぐ抜かれるんだろうなーってなことを思いながら、偉そうに教えてました。

エンジニアを集めて酒を飲みながらわいわい話すと言うイベントを企画していました。

結構いろんな人が集まってくださり、めっちゃ楽しかったです！

【増枠しました！】Hacker's GATE Beer Bash!!!! - connpass

プライベート

仮想通貨の自動取引ボットを作ってました。 友人が意外と簡単にボットでもうけられそうだぞ、という話をしてきたのがきっかけでした。 python でテクニカル指標を簡単に出せたので、それを利用しながら、独自のロジックを作り、検証して勝てそうなら回す、と言うような風にやっていました。

大学時代に一応少しpythonは触ったことはあったものの、ちゃんとしたコードを書いたのはこれが初めてでした。

データ処理がシンプルにかけるのがやっぱりpythonはいいですね。

結果としては、汎用的に勝てるロジックを組むのはやはり難しく、定期的に相場を分析してロジックを改変していかないといけないと言うことがわかり、 そこまで時間を確保できなくなり、一旦手を離しました。

10 ~ 12月

仕事

人生で初めて役職に就きました。管理職の大変さを学んでいます。

管理職についてから、本当にコードを書く時間が減りました。１日2〜3時間の時間の確保がやっとです。

日々チーム課題と戦ったり、事業部サイドとの連携、交渉で気づいたら１日が終わることがほぼです。

今までやってくれてた上長に本当に感謝ですね。

臨時で入っていたプロジェクトの方がひと段落したので、この頃からPMとして復活してまた最近大きめのプロジェクトを任されています。

今度こそ失敗しないように、色々動くつもりです。

ここでもイベントを企画してました。テーマは「新卒入社『約』3～5年目のホンネ」という内容でやりました！

この時も多くの方に参加してもらい、とてもエモい話も聞けてよかったです。

Hacker's GATE LT & 交流会 #2 - connpass

プライベート

最近もくもく会をはじめました。

一人だとだらだらしてしまって作業進まないことありませんか？僕は全然進まないですw

そんな方はもくもく会に参加してみてはいかがでしょうか、もくもく会では何をしてもいいのですが、参加時にこれをやる、

というものを発表して最後に進捗を報告して終わります。進捗自体は各自の自由ですが、私は発表しなきゃという気持ちで身が引き締まりいつもより成果を出せていますw

また、わからないこととか、他愛もない雑談をしながら作業するのもとても楽しいので、ぜひ参加してみてください〜

Hacker's GATE もくもく会 #5 - connpass

振り返り

良かったこと

意外といろんな技術に触れることができた。

いろんな役割を経験することができた。

登壇系も今までより、回数、質が上がってきた気がする。

プライベート開発でサービスローンチできてよかった。

もっとこうしていきたいこと

プライベート開発したサービスで収入をえたい、そのためにはもっとサービス案を出して、もっと開発してマネタイズを考えなければ、、

いろんな役割を経験することはできたが、色々中途半端になってしまっているため、器用貧乏感が否めない。もっと技術とマネジメント能力を磨いていく。

イベントの企画はだいぶやれるようになってきたが、まだまだ巻き込み力が足りないので、もっと影響力をだせるように、興味を引けるようなイベントを考えられるようになる。

来年はもっといっぱいいろんなことができるように頑張ります！

ので応援お願いします！

【look-pixela】草をはやせるAPIのPixelaをシェア出来るサービスを作った

作ったもの

f:id:zoe302:20181115205545p:plain

そもそも pixela とは - 草をはやせるAPI

エンジニアなら誰しも知っているgithubの草をgithubにコミット以外でも生やせるように作られたのがPixelaというサービスです。

pixe.la

このサービスではすべての操作をAPI経由で行え、エンジニアライクに作られています。 もちろん自分の活動内容はこのサービス上から閲覧できます。

例) https://pixe.la/v1/users/zoe302/graphs/test-graph https://pixe.la/v1/users/zoe302/graphs/test-graph

pixela のグラフをシェアしたい

このサービスとても素晴らしいと思ったのですが、私は自身の活動量をツイッターなどでシェアしたいなと思いました。 めっちゃ活動しているのが周りの人に見られて褒められればモチベーションも上がるし、逆に草が全然生えてなければ危機感をもって行動するかなという考えです。

ただツイッターなどでグラフのURLをシェアしてもただURLリンクになってしまい、活動量がパッと見で判断できませんでした。

そこでOGPタグなどをつけて画像を呼び出すだけの簡単なサービスを作ってみました。

look-pixela を作りました

そこでできたのが look-pixela です。(あまり名前に捻りがなくてすみません。。)

使い方は簡単で元の pixela のドメインから後ろをそのままコピーして、張り付けるだけ

https://pixe.la/v1/users/zoe302/graphs/test-graph ↓ https://look-pixela.zoe.tools/v1/users/zoe302/graphs/test-graph

はてなブログでシェアするとこんな感じ look-pixela.zoe.tools

ツイッターだとこんな感じ

(TOPページはまだ作ってないので、あまり見ないでください><)

中身はpixelaさんのサービスを使わせていただいてます。本当に素晴らしいサービスを作ってくれてありがとうございます。

おまけ

ちなみに、このサービスは 株式会社Willgate でやっている 『Hacker's GATE もくもく会』 での成果になります。みんなでもくもくやると作業進捗も出たり、アイデアも出たりとお勧めです！

willgate.connpass.com

ぜひ、一緒に参加してくれる方募集しています～～～～！

ansibleのオプションが長くて覚えられないので工夫した話

技術 作ったもの CLIツール Ansible Makefile

結構前にansibleの実行時のオプションが長すぎて覚えられず、工夫したものをどこにも資料を残してなかったので、まとめてみました。

あくまで僕が取った一つの手段であり、ベストプラクティスだとは思ってないですが、少しでも誰かの役に立てばと思い残しておきます。

ansibleって？

サーバの構成を管理するためのツールです。これを使うことでアプリケーションを実行するための設定などをコードで管理し、設定を自動化することができます。

設定をコードで管理、自動化出来ることのメリットとしては、サーバの設定項目に対してレビューを挟むことがしやすくなり誤った設定などを防いだり、急遽サーバを増やす（スケールアウト）対応が必要になったときなどにすぐ対応することができる、などがあげられます。

ansibleのコマンド長い問題

今回の記事ではansibleのための細かい書き方などについては記載しません。（他のサイトや公式で十分いっぱい記事がありますので、そちらを見てください。）

ansibleを書いていると実行コマンドが下記のようにオプションがいっぱいついて長くなることはないだろうか？

ansible-playbook --vault-password-file $(VAULT_PASS) -i ec2.py -l tag_Environment_${ENV} --private-key=$(KEY) site.yml -u ${user} --check

上記は私が使ってる環境のプロビジョニング用のコマンドですが、もう長すぎて覚えられません。 一応解説しておくと、

  • --vault-password-file $(VAULT_PASS) はファイルを暗号化して管理しているときに複合化してプロビジョニングを実行するための鍵となるファイルを指定するオプション
  • -i ec2.py はダイナミックインベントリという仕組みを使うためのオプションで、プロビジョニング対象が動的に変化する際に使用する
  • -l tag_Environment_${ENV} はプロビジョニングを実行するホストのフィルタリングオプション
  • --private-key=$(KEY) はプロビジョニングの際に使用するssh用の鍵のオプション
  • -u ${user} はプロビジョニングの際に使用するssh用のユーザのオプション
  • --check はdry-runのためのオプションで、これをつけて実行すると実際にはプロビジョニングせずに実行したときの結果をテストすることができます

もちろん一つ一つの意味は理解しているので、思い出しながら書けば実行できないこともないですが、そう頻繁に実行するものでもなかったりするので、久しぶりに「さープロビジョニングするぞ」っていうときに「あれ、コマンドなんだっけ？」となることが多いです。

もちろん忘れても大丈夫なようにコマンドをどこかにメモしておいたり、READMEに書いておいてもいいと思うのですが、それを毎回見たりコピペして実行するのもなんだかイケてないですよね。

対策候補

上記の解決策として、下記を考えました。 1. Alias 1. シェルスクリプト 1. Makefile

Alias

一番最初に思いついたのがAliasでした。長ったらしいコマンドに対してAliasを張るというのはよくやりますよね。 ですが下記の理由から、Aliasでやることを断念しました。

  1. 1台のansible発射サーバから複数サービスのansibleを実行する際にオプションがそれぞれ違うためaliasでは対応しきれない
  2. ダイナミックインベントリを使うためのec2.pyにコマンドが依存しているが、この依存解決ができない

1台のansible発射サーバから複数サービスのansibleを実行する際にオプションがそれぞれ違うためaliasでは対応しきれない

私の触ってる環境的な問題でもあるかもしれませんが、複数のサービスを触っててそれぞれに対してansibleがある状態で、かつその実行を一台のansible実行用環境からプロビジョニングをかけているため、 aliasに登録すると他のサービスのプロビジョニングのコマンドとバッティングしてしまいます。もちろんこれをalias張る名前にサービス名などをつけて対応してもいいのですが、煩雑になりそうだったのでやめました。

ダイナミックインベントリを使うためのec2.pyにコマンドが依存しているが、この依存解決ができない

これについても私の環境によるものでもあるのですが、ダイナミックインベントリを使用しており、その解決にawsのec2.pyを使用しています。これについては公式でも書かれているので詳細はこちらを確認してください。

Working With Dynamic Inventory — Ansible Documentation

問題としては、このプロビジョニングコマンドを実行する際にあらかじめec2.pyを取得しておくことが必要なのですが、環境のセットアップはせっかくコードで管理できるようになったのに、環境セットアップするための手順がコードで管理できていないのでは、意味がないじゃないか。というのが私の意見です。なのでこのec2.pyに対しても何らかの形で取得しておくことが必要だということをコードで表現したいなと思い、aliasは却下になりました。

シェルスクリプト

次に思いついたのがシェルスクリプトです。まぁ、いくつかの手順があってそれを自動化したいとなると、カスタマイズ性の高いシェルスクリプトが候補に上がるのは当然かと思います。 シェルスクリプトであればサービスごとのansibleのレポジトリにスクリプトを含めて実行するようにすれば、aliasのようにバッティングしてしまう問題も防げます。

結論から言うと、私はシェルスクリプトを選びませんでした。もちろんシェルスクリプトでできないわけではありませんし、十分にありな選択肢ではあると思います。 ただ、自分がシェルスクリプトを書くほどのものではなく、かつシェルスクリプト書くのがめんどくさいと思ってしまったために却下しました。

Makefile

Makefileです。普段あまり触ってない人からすると「え、Makefile？」となるかもしれません。ですが、自分はMakefileを結構気に入っています。Makefileのいい点としては、依存解決ができ、簡単なコマンドのラップが書きやすい。これに尽きるかと思います。今回の目的でいうと、ansibleの長いオプションをラップし、サービスごとに微妙に違うオプションもサービスごとにMakefileを書くことで解決し、ec2.pyの依存解決も簡単に表現することができます。

具体的にどうしたか

最終的に下記のようなMakefileをサービスのansibleレポジトリに含めるようにしました。

init: ec2.py ec2.ini
.PHONY: init

ec2.py:
    wget https://raw.github.com/ansible/ansible/devel/contrib/inventory/ec2.py
    chmod +x ec2.py

ec2.ini:
    @echo 'please set up your credential ec2.ini'
    exit -1

VAULT_PASS=./default/path
ENV=default-env
KEY=default-key
USER=default-user
dry-run: init
    ansible-playbook --vault-password-file $(VAULT_PASS) -i ec2.py -l tag_Environment_${ENV} --private-key=$(KEY) site.yml -u ${USER} --check
.PHONY: dry-run

run: init
    ansible-playbook --vault-password-file $(VAULT_PASS) -i ec2.py -l tag_Environment_${ENV} --private-key=$(KEY) site.yml -u ${USER}
.PHONY: run

MODE=encrypt/decrypt
TARGET=your_target_file
vault:
    ansible-vault $(MODE) --vault-password-file $(VAULT_PASS) $(TARGET)
.PHONY: vault

encrypt:
    @$(MAKE) vault MODE=encrypt
.PHONY: encrypt

decrypt:
    @$(MAKE) vault MODE=decrypt
.PHONY: decrypt

このMakefileがあるディレクトリ上で make dry-run のように実行すると初回実行時は init のターゲットも実行されるのでec2.pyは自動でDLされ、ec2.iniにクレデンシャル情報を記入しろ、という旨のメッセージを出して終了します。また、ec2.iniがターゲットになっているのでこのファイルが生成されるまでこのエラーは解消されないので、作成されていないのにansibleが実行されることはありません。

また、おまけでファイルの暗号化のコマンドも僕は覚えられないので、make のターゲットにしてみました。こういう感じでコマンドのラップとしても使え、忘れたとしても make の補完リストから、何ができるかを判断できるので、便利ですね。

新しい人がプロジェクトに入ってきたとしてもよく使うコマンドがmakeにまとまっているとコマンドの説明を細かくしなくても理解してもらえるのでとても助かってます。

(本当は、公式でansibleの実行オプションをファイルで記述できれば一番いいんだろうけど、、

【zcrypt】Go製のツールを作る際に便利だったツールの紹介

技術 Golang CLIツール 作ったもの

zcrypt というgo製のCLIツールを作った。

github.com

何ができるの？

CLIで手軽にファイルの暗号化、複合化ができる。

作った背景

apiなどを使用する際の鍵などのような機密情報をバックアップ目的でgithubに乗せておきたいけど、さすがに平文で置いておくのは怖いので適当に暗号化して保存したかった。

暗号化、複合化するだけならopensslなどのコマンドを使えばよいがせっかくなのでツールを作ってみたかった。（コマンドのオプションを覚えるのも面倒だった。）

使ってる技術

使い方などはREADME見てもらえばだいたいわかると思うので、ここでは記述しない。

代わりにこのツールを作るに当たって利用させていただいた便利なツールについて書きたいと思う。

並列クロスコンパイルツール(gox)

golangはクロスコンパイル可能な言語である。コンパイル時にどの実行環境で動かすかを設定することでその環境用の実行ファイルを生成することができる。

しかし、golang単体でこれをやろうとした場合、いろんな環境で動くようにいろんなパターンの実行環境用のビルドファイルを作ろうとすると何回もビルドする必要があるし、オプションも実行環境に合わせて変更する必要があり、一つ一つコンパイルするので時間もかかりとても面倒である。

そこでこのgoxと言うツールを使うと、コマンド一つで複数の実行環境用のコンパイルを一度に実行してくれ、オプションも自動でいい感じにしてくれる。

github.com

リリースタグとファイルアップロード(ghr)

リリースタグを切るのとリリースタグにファイルをアップロードしてくれるツールがこちらである。しかも並列でアップロードできるので早い！

go製ツールのデプロイと言うと多くがリリースタグを切ってそこにバイナリファイルをおくことが多い。このツールではこの部分を自動化してくれるものだ。とても便利ですね。

github.com

デプロイのフロー

上記で紹介したツールをCircleCIからうまく使いデプロイを行ってる流れは次の通りだ。

  1. masterにマージ
  2. CircleCI上でイベントを検知
  3. CircleCIでビルドできるか確認
  4. CircleCIで正常に暗号化複合化できているか確認
    • ここはあえてgoでのtestではなく、ツールをCLI上から実行して動作確認するようにしている。コードはこちら。
    • これはgoでテストしてもそれはライブラリのテストになってしまうと思ったためである。あくまでここでテストしたいのはCLIツールとして使用した時に正しく使えるかである。
  5. CircleCIで並列クロスコンパイル
  6. CircleCIからリリースタグ作成、バイナリファイルのアップロード

リリースタグ作成時に工夫したこと

自動でリリースタグを採番してリリースして欲しかったため、少し工夫した。

具体的には下記の部分である。

https://github.com/IkezoeMakoto/zcrypt/blob/master/get_tag.sh#L4

お手製のワンライナーであるが、やってることとしては簡単で

  1. git tag でタグ一覧取得
  2. sort で新しい順に並び替え
  3. tail -1 で1件のみ取得(この時点で最新のタグを取得できる)
  4. awk -F "." "{cnt=\$3+1}{printf \"%s.%s.%d\", \$1, \$2, cnt}" 少し難しいが、 . 区切りにして3つ目に+1をしてくっつけ直している

これでタグを自動でつけるようにしている。 もちろんセマンティックバージョニングに乗っ取るなら、機能性の追加や後方互換のない変更の場合には手動でタグを切る必要があるだろう。

まとめ

Go製のツール作るためのライブラリや環境が多く整っていて、簡単なものをサクッと作りやすいので何か困ったことがあればサクッとツールを作って解決してみてはいかがだろうか。

技術書典5 行ってきました

技術書典とは?

techbookfest.org

技術者の同人イベントですね。今回で5回目らしいです。私は今回が初参加でしたが欲しいものや興味あるものもあったので友人と一緒に行ってきました。

戦利品(買えたもの)

運よく早めに会場につき入ることができたので、欲しいものは一通り購入することができました。(ミュウツーは近くの公園でたまたま捕まえましたw) また、公式サイトには参加サークルのチェックリストもあり、効率的に回ることもできました。本当に助かります、ありがとうございます。

後払い決済のアプリについて

参加サークルのうち対応していたサークルのみですが、技術書典公式でQRコードでの後払い決済アプリを用意してくれていました。

これを使うと、事前にアプリをDLし登録(電話番号の登録が必要)を済ませておくと、イベント当日にサークルごとのQRを読み取ることで購入したい本を後払い決済できると言う仕組みのようです。ここまで用意してくれるなんて本当にすごいですね。。

技術書典

技術書典

  • Tatsu-zine Publishing Inc.
  • ビジネス
  • 無料

感想

結構事前にチェックしていたもの以外にも当日実際に本を手に取って読んで、「あ、これいいな」と購入したものも多くありました。実際に手にとって読んでみることの良さを久しぶりに実感できました。

また、こう言うところで本を出すことについての機会や、敷居が低くなったりといいイベントですね。やはりアウトプットは大事ですからね。

それとは反対にやはり、会場に対して参加者が多いので当日の混み具合はすごいものでした。ひどいところだと満員電車並みの混雑具合で冗談ではなく進めないレベルでした。ここに関しては上記の電子決済などで少しでも緩和されるといいなと思います。

全体的にはとてもいいイベントだと思うので、今後も開催に期待ですね。ありがとうございました。