すずけんメモ

技術メモです

「みんなのGo言語」の執筆に参加しました

golang

今回、「みんなのGo言語」の執筆に参加しました！

みんなのGo言語【現場で使える実践テクニック】 : 松木雅幸, mattn, 藤原俊一郎, 中島大一, 牧 大輔, 鈴木健太 : 本 : Amazon

私がGoでプログラムを書き始めたのは2015年の明けごろからです。mattnさんのブログ を読みながら、面白い言語があるのだなーと思って書き始めました。 A Tour of Go を触ってみて、ちょっと冗長そうだけど案外いい感じかもな？と思いつつ少しずつGoで実装するようになっていました。そこから標準ライブラリ読み漁り、小さなツールを書きつつ、気がついたらプロダクションでも使うようになっていました。今では毎日Goで何かを書いています。

これまでにつかった言語のなかで、いまのところGoがなぜかしっくりしてきています。一言でいうと「あーこういうのでいいんだよこういうので」感です。思えば、以下の機能がこの感覚の中心になっているように思います。

  • 言語仕様が小さい
  • gofmtがある
  • コードレビューがしやすい
  • 高速なビルド

Goでコードを書いていると、GoっぽくないGoのコードはよくないコードにみえてきます。これが言語設計のちからなのだな、というのを書いていて感じます。

「みんなのGo言語」はsongmu さん、mattn さん、fujiwara さん、deeeet さん、lestrrat さん、そして私の6人で書きました。個人的には執筆中も学びがあり、そして楽しく、書かせていただきました。みなさんありがとうございました！

私はテストの章を担当しました。 testing パッケージの解説から、実際の現場でどのように testing をつかってテストを書いているかという話を書きました。初めてGoの testing パッケージをみたときには、「こんなシンプルなAPIでいいのかな？」と思ったのですが、使っていくうちにGoらしいテストライブラリであることがわかりました。Goの魅力の1つは標準ライブラリのシンプルなAPI設計です。テストライブラリとしての Less is exponentially more を感じていただけると幸いです。

「みんなのGo言語」、通称「みんGo」です。この本が少しでもみなさんの開発の助けになれば、嬉しく思います。

「サーバーレスの波はホンモノか？」あとがき

awssummit aws

suzuken.hatenablog.jp

ご来場くださった方々、どうもありがとうございました。パネル内で話せなかったことやあとがきをまとめてみました。

ツールの補足

銀の弾丸はない

おわりに

パネルディスカッションの機会をつくっていただいたAWSのみなさま、モデレータの西谷さん、パネリストの木田さん、どうもありがとうございました。

追記 2016/06/15 12:50

セッションの動画が公開されました。

www.youtube.com

AWS Summit Tokyo Developer Conferenceのパネルディスカッションに登壇します

aws

来週のAWS Summit TokyoのDevconにて、以下のパネルディスカッションに登壇予定です。6/2の16:20 - 17:00の回です。

AWS Summit Tokyo 2016 Developers Conference（DevCon）

【パネルディスカッション】サーバーレスの波はホンモノか？ 最前線の開発者に聞くコードでサービスの全てを提供する方法

スケーラブルなアプリケーションやマイクロサービスを構築する上で、インフラの管理から「解放」されるサーバーレスアーキテチャーが注目されています。このサーバーレスアーキテクチャーが、どのくらいのインパクトを持つものなのか、実際にアプリケーションやサービス開発の最前線で活躍されている方をお招きし、その実態や期待値をお伺いするとともに、今後の進展についても議論します。

モデレータはAWSの西谷さん、パネリストはリクルートジョブズの木田さんと私です。サーバーレスのセッションで、今後のアーキテクチャを考える上でどのようにサーバーレスアーキテクチャを扱っていくか、というところ話す予定です。今実際にAWS LambdaやKinesis Streamを組み合わせたシステムを運用していてどうなのか、という話を交えつつ議論する予定です。私の事例としては以前AWSさんのオフィスにて発表したものがベースになります。どういった点がLambdaないしサーバーレスに向いており、どのような点から開発フェーズから運用、そしてアーキテクチャを考えていけばいいのかといったあたりの参考になるようなセッションにしたいと考えています。

お時間ありましたら是非お越しください。また6/2、6/3とも夕方から会場にはいる予定ですので、細かい技術的な質問等などあれば捕まえてください。あと飲みに行きましょう。

Shibuya.go#2 を開催しました

shibuyago golang

昨日 Shibuya.go#2 を開催しました！参加していただいたみなさま、どうもありがとうございました。

shibuyago.connpass.com

そして発表者のみなさま、発表どうもありがとうございました。リンクを貼っておきます。

テクニカルトーク

bokko.hatenablog.com

sfujiwara.hatenablog.com

LT

konboi.hatenablog.com

今回も多くの方に集まっていただいて、色々と技術的な話含めて楽しめてよかったです。

  • 仕事でGoを使われている方は3,4割程度といったところでした。
  • 圧倒的Slackユーザ率
  • Soralisユーザはお二人・・

懇親会ではMakefile便利だとかhostファイルの話をしたりとか最初から🍺を飲むと眠くなるというデメリットもある、という話をしたりしました。また次回、5月頃に開催予定ですので、お気軽に参加していただけると幸いです。

Shibuya.go#2を開催します！

golang shibuyago

Shibuya.goの2回目を開催します！

Shibuya.go#2 - connpass

前回 Shibuya.go#1を開催しました。 - すずけんメモ に引き続き、弊社オフィスにて開催します！前回も盛りだくさんで、懇親会もだいぶ色々な話ができて楽しかったので今回もまた色々なお話ができれば嬉しいです。

Shibuya.go#1を開催しました。

shibuyago golang

今週の火曜日に Shibuya.go#1 - connpassを開催しました。ご来場していただいた皆様、発表者の皆様、どうもありがとうございました。

渋谷近辺、都内近郊でGoを書いている人ともっと会いたいなぁと思い、今回開催するにいたりました。私は普段から仕事でも仕事以外でもGoを使っているのですが、どうもあまりGoを書いている知り合いがあまりいないのでせっかくだし開催してみようと思ったのでした。人が集まるかなぁと思いつつ募集してみたら嬉しいことに多数の参加申し込みをいただき、抽選となってしまいました。参加できなかった方々申し訳ありません・・。

発表資料をまとめておきます。発表者のみなさま、どうもありがとうございました。

また発表後も飲みつつ、色々なお話をすることができました。Goの集まりでしたがPerl感があったとの噂です。また来月も開催予定ですので、是非また参加していただけると幸いです！

その翌日（おとといですね）は Go 1.6 Release Party - connpass に行ってきました。主催者のみなさん、会場を用意してくださったはてなさん、どうもありがとうございました。こちらも楽しい会で、残念ながらGo 1.6はパーティー前にはリリースされなかったのですが、Gopherのみなさんとお話できて楽しかったです。 Go 1.6 is released - The Go Blog にもあるとおり、Go 1.6はリリースされました。私もさっそく今日一部のサーバにGo 1.6でビルドしたものをデプロイしました。

Travis CIを利用した継続的な成果物の配置

travisci golang

こんにちは。 @suzu_v です。 Advent Calendar 2015 18日目 休載のお知らせ - VOYAGE GROUP techlog とのことだったので代打で書いてみます。*1

いま私が所属している fluct ではCIの一部にTravis CIを利用しています。用途としては、

  • 継続的なテスト
  • 継続的なビルド

というところを担当しています。今日は簡単に、

の紹介をします。

Travis Artifacts

f:id:suzu_v:20151218150020p:plain

travis-ci/artifacts はTravis CIのアドオンとして利用されているもので、ビルド済みのartifactsを扱うことができます。私たちは一部のバッチやAPIサーバの実装について、Travis CIを利用したビルド及びs3への転送を行っています。

プロジェクト構成は概ね以下のようになっています。この場合Goのアプリです。

github.com/your-username/your-reponame
    .travis.yml
    Gomfile
    Gomfile.lock
    Makefile
    ci.mk
    cmd/myapp.go
    kuke.go
    kuke_test.go

.travis.yml には以下のように設定しています。

sudo: false

language: go

go:
  - 1.5.2

before_script:
  - export PATH=$HOME/gopath/bin:$PATH

install: make -f ci.mk deps

script:
  - make -f ci.mk test
  - make -f ci.mk build

addons:
  artifacts:
    paths:
      - $(git ls-files -o --exclude-standard | tr "\n" ":")
    debug: true
    bucket: your-bucket
    target-paths: artifacts/$TRAVIS_REPO_SLUG/$TRAVIS_BRANCH
  s3_region: "ap-northeast-1"

このようにすると s3://your-bucket/artifacts/your_user_name/your_repo_name/branch_name 以下にビルド物が展開されます。例えば github.com/suzuken/gs のmasterブランチのビルドに対しては s3://your-bucket/artifacts/suzuken/gs/master 以下に成果物(artifacts)が配置されます。Pull Requestを出した場合にも同様で、トピックブランチごとのartifactがs3に配置されます。テストをするサーバ側ではこのartifactを aws s3 cp などで取得し、利用することができます。ちなみにブランチ以外にもcommit hashやtagごとに出す、ということもできます。詳しくは travis-ci/artifacts をみてください。

git ls-files -o --exclude-standard | tr "\n" ":" というのはざっくりいうと「git管理下では無いファイル」をリストする、ということをしています。こうすることでビルドされたものだけs3へのアップロード対象にすることができます。

ci.mk というのはCI用のMakefileです。Makefile は開発用に、 ci.mk はCIで使うように、と分けています。実際にそれぞれやっていることはあまり変わりませんが、こうすることでプロジェクトごとのCI用のマクロを揃えておくということがやりやすくなります。例えばJavaのプロジェクトでもこの仕組をつかおうとしたときにでも、 make -f ci.mk install test build すれば成果物ができる、という取り決めにしておけばよいのです。

実際に ci.mk の中身は以下のようになっています。（プロジェクトによって若干異なりますが、Goのプロジェクトだと概ね以下のようになります。）

.PHONY: install build test deps

BRANCH := master
GOOS := linux
GOARCH := amd64

deps:
  go get github.com/mattn/gom
  gom install

test:
  gom test -v ./...

build: myapp.$(GOOS).$(GOARCH).gz
   -rm myapp.$(GOOS).$(GOARCH)

myapp.$(GOOS).$(GOARCH):
  GOOS=$(GOOS) GOARCH=$(GOARCH) gom build -ldflags "-X=main.version=$(shell git rev-parse HEAD)" cmd/myapp.go
  mv myapp $@

myapp.$(GOOS).$(GOARCH).gz: myapp.$(GOOS).$(GOARCH)
  gzip -f $<

clean:
   -rm -rf myapp.$(GOOS).$(GOARCH)
   -rm -rf myapp.$(GOOS).$(GOARCH).gz

依存の管理には mattn/gom を利用しています。Go版のBundlerのようなものです。s3への転送は myapp.linux.arm64.gz だけを配置する、ということにしたいので適当に整理しています。

Travis CIからS3への転送についてはcredentialが必要になります。これはTravis CIのプロジェクト設定で、環境変数から読み込ませることができます。 Uploading Artifacts on Travis CI - Travis CI に書いてあるとおり、リポジトリの設定から以下を設定します。

ARTIFACTS_KEY=(AWS access key id)
ARTIFACTS_SECRET=(AWS secret access key)
ARTIFACTS_BUCKET=(S3 bucket name)

Bucketについては .travis.yml に設定してもよいでしょう。Travis CI側ではtestが通らないとbuildが実行されないようにしているので、これでビルドが通ったもののみs3に配置される、ということになります。

以上、簡単ですが代打でした。明日は @qooh0 さんです。

小ネタ

f:id:suzu_v:20151218151850p:plain

*1:決してTravis CIのビルドが詰まっているので息抜きに書いているわけではありません。 Travis CI Status - Start delays on legacy precise infrastructure for travis-ci.com (private) builds