「みんなのGo言語」の執筆に参加しました
今回、「みんなの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」です。この本が少しでもみなさんの開発の助けになれば、嬉しく思います。
「サーバーレスの波はホンモノか?」あとがき
ご来場くださった方々、どうもありがとうございました。パネル内で話せなかったことやあとがきをまとめてみました。
ツールの補足
さきほどのパネルディスカッションで紹介したCloudWatch logsを見るツールは https://t.co/1ZmrgWfbYJ Kinesis Streamを雑にtailするツールは https://t.co/YAzsMZEQvj です #awssummit
— suzuken (@suzu_v) June 2, 2016
銀の弾丸はない
AWS Lambda、個人的には「簡単に立ち上がって隔離されたアプリケーション実行環境」としてつかってます。EC2でもECSでもできることがやれればいい。サービスつくる上で必要なものが動けばいいし、そのために試しやすい環境がすぐできるのはうれしい、というスタンスでつかってます。
— suzuken (@suzu_v) June 2, 2016
なので、これからLambdaで動いてるところを要件によってはEC2に移す、ということもするかもしれない。でもそれはよくて、初速をLambdaであげて実際に現場で動くものをつくれてリリースもできているのでよい。開発よりも運用の比重があがってきたときにどうなるか、あたりも大事。
— suzuken (@suzu_v) June 2, 2016
アプリケーションエンジニアとしてはすぐに本番のリソースと結び付けられて独立した実行環境が得られるのはメリットは大きい。ただし落ちづらいコード、スループットの出づらい実装になっていると使えないものに。そこはアプリケーションエンジニアとして責任をもつ必要がある。
— suzuken (@suzu_v) June 2, 2016
サーバーレス、という文脈で言うとLambdaみたいなものはとても便利に見えるだろうし、実際できることできないことははっきりしている。運用という観点から言うと、チームとしてインフラとアプリというもののスタンスを変えなければならないところもあるかもしれない。
— suzuken (@suzu_v) June 2, 2016
サービスをチームとしてサーブしている以上、そしてLambdaのようなものによって運用フェーズと開発フェーズが近くなる以上、そこで何を重要視するか?というのはチームによって違うと思う。たしかに検証はしやすいし、本番に近い状態でテストもできるのはメリットも大きい。
— suzuken (@suzu_v) June 2, 2016
とはいえ、じゃあ本当にこれはちゃんとサービスを動かし続けられるのか?というのをアプリケーションエンジニアがちゃんと動作モデルやエラーのケースまでケアしてコードを書く必要がある。普段からこれをやっているチームはすんなり運用までいけるかもしれないけど、そうじゃないと検証だけになるかも
— suzuken (@suzu_v) June 2, 2016
そういう文脈があるので、サーバーレス = デプロイが簡単ですぐ環境を得られる、ということだけではなくてチームとしてこういう領域を扱えるようにしていくというのをセットにしていかないとうまくいかないんじゃないかな、とも思う。だから使うだけで急に何かがよくなるわけではない。
— suzuken (@suzu_v) June 2, 2016
おわりに
パネルディスカッションの機会をつくっていただいたAWSのみなさま、モデレータの西谷さん、パネリストの木田さん、どうもありがとうございました。
追記 2016/06/15 12:50
セッションの動画が公開されました。
AWS Summit Tokyo Developer Conferenceのパネルディスカッションに登壇します
来週の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 を開催しました
昨日 Shibuya.go#2 を開催しました!参加していただいたみなさま、どうもありがとうございました。
そして発表者のみなさま、発表どうもありがとうございました。リンクを貼っておきます。
テクニカルトーク
#shibuyago https://t.co/xi72fZ0x2y
— 地獄谷麻婆豆腐おじさん (@ajiyoshi) 2016年3月22日
LT
滑舌悪くて申し訳ないです。資料はこちらに挙げてあります〜 https://t.co/M7VGbDPx4J #shibuyago
— 常にOffline (@snowcrush) 2016年3月22日
今回も多くの方に集まっていただいて、色々と技術的な話含めて楽しめてよかったです。
- 仕事でGoを使われている方は3,4割程度といったところでした。
- 圧倒的Slackユーザ率
- Soralisユーザはお二人・・
懇親会ではMakefile便利だとかhostファイルの話をしたりとか最初から🍺を飲むと眠くなるというデメリットもある、という話をしたりしました。また次回、5月頃に開催予定ですので、お気軽に参加していただけると幸いです。
Shibuya.go#2を開催します!
Shibuya.goの2回目を開催します!
前回 Shibuya.go#1を開催しました。 - すずけんメモ に引き続き、弊社オフィスにて開催します!前回も盛りだくさんで、懇親会もだいぶ色々な話ができて楽しかったので今回もまた色々なお話ができれば嬉しいです。
Shibuya.go#1を開催しました。
今週の火曜日に Shibuya.go#1 - connpassを開催しました。ご来場していただいた皆様、発表者の皆様、どうもありがとうございました。
渋谷近辺、都内近郊でGoを書いている人ともっと会いたいなぁと思い、今回開催するにいたりました。私は普段から仕事でも仕事以外でもGoを使っているのですが、どうもあまりGoを書いている知り合いがあまりいないのでせっかくだし開催してみようと思ったのでした。人が集まるかなぁと思いつつ募集してみたら嬉しいことに多数の参加申し込みをいただき、抽選となってしまいました。参加できなかった方々申し訳ありません・・。
発表資料をまとめておきます。発表者のみなさま、どうもありがとうございました。
資料です https://t.co/8A2uJxbuUS #shibuyago
— suzuken (@suzu_v) 2016, 2月 16
資料です https://t.co/XjnhXvEH2g #shibuyago
— aihara (@shunsukeaihara) 2016, 2月 16
本日の発表資料です #shibuyago / “horenso ~ 報・連・相” https://t.co/PQGEYD94Ru
— songmu (@songmu) 2016, 2月 16
本日の発表資料です!Revelサイコー!! #shibuyago Go+Web App - Shibuya.go#1 https://t.co/HuY7Ippqal
— kaneshin@かねしん (@kaneshinth) 2016, 2月 16
https://t.co/f96RavAaD8 わたくしの先ほどのスライドを上げました #shibuyago
— トーカナイザの守護霊 (@mackee_w) 2016, 2月 16
#shibuyago で発表した資料です / “revealgo - Shibuya.go#1” https://t.co/yvhcv4PhMr
— Yusuke Wada (@yusukebe) 2016, 2月 16
発表した資料です https://t.co/H4uz3Lg0eZ #shibuyago
— Gosuke Miyashita (@gosukenator) 2016, 2月 16
また発表後も飲みつつ、色々なお話をすることができました。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を利用した継続的な成果物の配置
こんにちは。 @suzu_v です。 Advent Calendar 2015 18日目 休載のお知らせ - VOYAGE GROUP techlog とのことだったので代打で書いてみます。*1
いま私が所属している fluct ではCIの一部にTravis CIを利用しています。用途としては、
- 継続的なテスト
- 継続的なビルド
というところを担当しています。今日は簡単に、
の紹介をします。
Travis Artifacts
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 さんです。
小ネタ
*1:決してTravis CIのビルドが詰まっているので息抜きに書いているわけではありません。 Travis CI Status - Start delays on legacy precise infrastructure for travis-ci.com (private) builds