Block Rockin’ Codes

back with another one of those block rockin' codes

Web+DB Press vol.82 で Go の特集を書かせて頂きました #wdpress

update

intro

タイトルのとおり、 Web+DB Press の vol.82 に

「はじめての Go」

というタイトルで特集記事を書かせていただきました。

WEB+DB PRESS Vol.82

WEB+DB PRESS Vol.82

Web+DB に Go が載るのは、これが初めてだそうです！

Tour of Go の次

この特集は、 Google の Go 言語について、初心者を対象に書きました。

Go には Tour of Go というチュートリアルが用意されており、 数か国語に翻訳されているため、初心者はまずここから始めるというパターンが多いと思います。

しかし、このチュートリアルはかなり初歩的な部分で終わっており、「この次に何をしよう」となると、 もう自分でドキュメントを読みながら、コードを書いて覚える。という感じになり、若干飛躍が大きいところがありました。

いくつかある書籍も、ちょっと古い内容になりつつあります。

そこで、 Tour Of Go ではあまり扱われていない、標準パッケージの使い方、もう一歩踏み込んだ interface の使い方、並行処理の考え方などを盛り込んで、

「Tour of Go の次」

を意識して書きました。

もちろん本誌で初めて Go を知り、　Tour of Go をやっていない方でも Go を始められるように、言語の紹介や環境構築についても書いていますので、安心して読んでいただけるように書かせていただきました。

今回、特集を通して使用する Go のバージョンは執筆時点で最新の 1.3 です。

章立て

章立ては以下のようになっています(30 ページくらい)。

第1章：Go言語の特徴と環境構築 第2章：基本文法 第3章：型システム 第4章：標準パッケージ 第5章:並行プログラミング

内容

1ç« 

Goが生まれた背景や、全体的な特徴について触れてから、Go の環境構築方法を解説しています。 初心者がハマりやすい、環境変数 GOPATH に始まる一連のプロジェクト構成や、ビルドの方法、 Github へのパッケージ公開までできるようになります。

最近主流の GOPATH 固定スタイルや、クロスコンパイルの準備方法など、ちょっと探しづらい情報についても載せています。

2ç« 

ひたすら基本文法を解説しています。 Go の文法仕様は割とコンパクトな方だとは思いますが、書き始めたらページが膨らみすぎたため、やむなく削ったところはたくさんあります。

扱い切れなかったことは多くありますが、それでも基本的にここに載っていることを知っていれば、公式のドキュメントを読み進めたり、公開されているコードを眺める上での第一歩とはなると思います。

3ç« 

この章のテーマは型で、名古屋方面の方々などに殴られそうな表題になっていますが、内容はいたってシンプルに、 Go の type キーワード周辺の扱いについてです。

struct や interface の定義や使い方から、型の埋め込み(embed)、 type assertion や type switch といった内容をまとめています。 メインは文法であり、型についての専門的な内容ではないので、ご容赦ください。

4ç« 

Tour of Go に足りてないことの一つが標準パッケージの扱いだったと思っています。 Go は標準パッケージが非常に充実しているので、そのなかから良く使うであろう encoding/json, io, net/http, html/template などを取り上げて扱いを解説し、 最後はそれらを組み合わせて簡単なHTTPサーバを作成します。

実は裏テーマとして、 io.Reader/io.Writer の扱いを重視しています。 特にサーバのようなものを書く場合、これらの組み合わせ方法を知っておくと非常に役に立ちますし、 ドキュメントを読んで、それらがどう組み合わせられるかがわかるようになると思います。

5ç« 

並行処理も Go の特徴的な部分なので、 goroutine, channel, for-select, などを使って並行処理をする方法と、その考え方の基本的な部分を順を追って解説しています。

sync.WaitGroup による同期や、 time.After() によるイベント、バッファ付き channel の扱いなども扱っており、応用することで自分が必要とする並行処理を組むための基礎になると思います。 しかし、この章はサンプルコードがどうしても大きくなりがちなので、削ったものも多くありました。 ここより先は go concurrency でググれば腐るほどスライドが出てくるので、それらを読むと良いかと思います。

ペア執筆

ペアプロで作業をする方が良い場合が多いように、執筆も1つのキーボードを奪い合って行うスタイルでやると、誤字脱字に対する精度も上がるし、迷う部分をすぐに共有して議論できるし、集中もできるし、なにより数時間 PC に向かってても進捗がゼロという状態を回避できていいのでは、と前々から思っていました。

そこで、 @ さんから執筆の話を頂いたときに「俺とペア執筆してくれるならやります！」と説得を試みたところ、ちょっと強引ではありましたが、 3, 4 回ペア執筆をする機会を得られることになりました。

スタイルとしては、俺が先にラフ気味な WIP 原稿を書いておき、それを二人で校正しながら、構成や言い回し、記法、誤字脱字を見ていく感じです。 編集者である @ さんと一緒に執筆すれば、 @ さんが別途校正して gitlab で issue を立てて「これはこうではありませんか？」みたいなやりとりをするコストもだいぶ減るだろうし、俺が書いて分かりにくいところも、すぐに「これではよく分からない」と指摘してくれるので、はかどるのでは無かろうかという狙いです。

あと単純にやってみたかったので、 @ さん直々に俺の家に来てもらい、1台の Mac を前にペア執筆を試してみました。

結果として、 @ さんとペアで校正をするメリットはあったと思います。 1つの章の校正がおおむね三時間くらいで終わり、これは校正と修正が別になった時のトータルコストと、俺が修正するふりして思わず Twitter やらハテブを開いてしまうリスクを限りなくゼロにできるので良かったと思います。

しかし、校正までの Go の解説原稿を書く部分については、やっぱり俺が先に用意しないといけないのですが、そこの用意があまり進まず、結果的に俺ができてない現行を書いてるのを、俺の隣で稲尾さんが監視するという感じになってしまい、最終的には「やっぱりあまり効果出てないね」ということで普通のスタイルに収まっていってしまいました。

俺がもうすこし原稿部分の作業を前もってやれれば、かなり効率よく校正進められたんじゃないかなと思います。原稿部分をまた別の人とペア執筆するというのも面白かったかも。 ともあれ、もう少しうまくやれたらという反省とともに、悪くはないなと思いました。

あと、毎回終わった後 @ さんとご飯を食べにいって、色々な話をしたのが楽しかったです。 そこでのやり取りは、先日公開した #mozaicfm の REST の回 にも濃く影響していたりしますw

謝辞

Web+DB はこれで三回目ですが、なんどやっても執筆はなかなか難しいですね。。

そんな中でも、俺のわがままにつきあって仕事終わりに俺の家までペアプロしに来てくれた @ さんには本当に感謝しています。楽しかったです！

筆が止まってた頃に、原宿某社で行われた黙々会で、その場ハンズオンをやらせてもらったおかげで、それがそのまま 4, 5 章の原型になりました。 @ さん、 @ さん、 @ さんありがとうございました。

そして、 暇そうにしてるところを俺につかまって 大事な休日を空けて、つきっきりでレビューしてくれた @ には感謝してます。あれも濃い議論もできたし、楽しかった。

書き物業はお腹いっぱいなので、しばらくはコード書く方に専念したいです。