CIサービスだけでErgoDoxのファームウェアをビルドして公開する

はじめに

こんにちは、Go界のalva notoです。ErgoDoxを買ってから1ヶ月が経ちますが、毎日快適にデスクワークをしております。そして日々ErgoDoxを使いながら常に新しいキー配列を模索しています。ErgoDoxの良い点は単純にセパレート型で肩が開く点だけでなく、自より指（腱）に負担がかからない配列に自由に直せるという点もあります。ただ、自分でキー配列を変えたファームウェアをビルドするのはちょっと面倒。

これまでは単一キーのみのアサインだったのでMassdropのコンフィギュレーターを使っていましたが、さらなる最適化を求めてファームウェアを自前でビルドし始めました。しかしながら、毎度毎度VagrantやDockerで環境を立ち上げてビルドするのは面倒なので、CIでビルド出来るようにしましたので、その情報を共有します。

ビルドプロセスの設定

普通に手元で動くTeensy用ファームウェアのビルド環境があれば普通にdockerの環境で都度ビルドしたり、CIであればJenkinsなりdrone.ioなりでビルドを回せばいいのですが、自分はそのためにサーバを持ちたくなかったので、werckerでビルドしてビルド済みバイナリをbintrayにアップロードするようにしました。一連のプロセスを実施するwercker.ymlは次のファイルです。

• qmk_firmware/wercker.yml at master · ymotongpoo/qmk_firmware · GitHub

今回はこのレポジトリをforkした前提で話を進めます。

bintrayの設定

まずアップロード先のbintrayの設定をします。まずアカウントを作ると何をしていいのかさっぱりわからないトップ画面に連れて行かれますが "Owned Repository" の "view all" をクリックすると自分が所有するレポジトリの一覧が表示されるので "username/generic" にいきます。

genericレポジトリ内に ergodox.hex というパッケージを作成します。*1

それが終わったら画面右上のユーザ名をクリックすると出てくるメニューから "Your Profile" を選択し、表示された画面で自分のアイコンの隣にある "Edit" ボタンを押します。進んだ画面で "API Key" のメニューを選択して、そこに表示されているAPI Keyをどこかにメモっておいてください。

これで bintray 側の設定はおしまいです。

werckerの設定

次に wercker の設定をします。ログインした後に、新規Applicationを作成します。

するとレポジトリの選択画面が出てくるので、forkしておいた qmk_firmware のレポジトリを選択し、"2. Configure access" ではデフォルトを選択します。最後にビルドの様子を公開するかどうかは適当に設定しておいてください。無事にApplicationが作成されたところで、Applicationの設定をします。

werckerではbuildフェーズとpipelineフェーズで各々の設定が必要です。まずbuildの設定をします。 Applicationの右上にある "Settings" から設定画面にとんで、"Environment variables" のメニューで環境変数 "TARGET_KEYMAP" の設定をします。もしレポジトリ内に気に入ったキーマップがあったらそのディレクトリ名を、特になければ default にしてください。

次にdeployフェーズでbintrayにファイルを置く設定をします。 "Targets" のメニューで表示された "Add deploy target" を選択します。適当に Deploy target name に名前を付けて、Auto deployにチェックを入れ、対象のブランチ名を書きます。

すると "Deploy pipeline" という項目が表示されるので、そこで deploy に必要な環境変数などを設定します。次の表のように環境変数を設定してください。

環境変数名	値
BINTRAY_USERNAME	bintrayのユーザ名
BINTRAY_APIKEY	先ほどメモしたAPI Key （protectedにチェックを入れておくと良い）

キーマップの変更とデプロイ

下準備が整ったところで、キーマップの変更をしましょう。ErgoDox EZ用のディレクトリが qmk_firmware/keyboard/ergodox_ez にあり、このディレクトリ内の keymaps にいろいろなキーマップが事前定義してあります。良いキーマップを見つけた人はそのディレクトリ名を先ほどのwerckerの TARGET_KEYMAP に設定すれば良いです。しかし、私は自分なりのキーマップにしたいので書き換えます。基本的に default を書き換えるようにしています。この keymap.c がキーマップの設定を持っているソースコードです。

C言語で書かなければいけないような雰囲気を感じますが、面倒な関数定義やマクロ定義はすべて終わってるので、そのなかのキーアサイン用の配列を書き換えるだけです。キーの設定に関してはこのドキュメントとヘッダファイルを読むと良いでしょう。

• https://github.com/jackhumbert/qmk_firmware/blob/master/README.md
• https://github.com/jackhumbert/qmk_firmware/blob/master/tmk_core/doc/keycode.txt

MOD_T系（CTL_T、GUI_Tなど）は「押しっぱなしにしていると修飾キーに、それ以外はマクロに渡したキーコードになる」という設定なので、これを使いこなすと非常に強力なのではないかと思うんですが、自分はその設定はしていません。

変更を行ってGitHubにpushすればあとはwerckerが自動でビルドしてbintrayにデプロイしてくれるのでちょっと落ち着いて待っていましょう。無事にアップロードされるとbintrayのほうに「ブランチ名-コミット番号」というバージョンができています。 "Files" のメニューからダウンロードして、Teensy Loaderなどを使ってErgoDoxに焼いてください。

おわりに

ErgoDoxのノウハウが世の中に多く出てくればいいなと思います。ぜひみなさんもシェアしてください！あと、自分のTLを見ていてみErgoDoxを自分で組立たり既成品を買ったりしている人がちらほらと増えてきたので、ぜひ現状確認会のような集まりをしたいと思っています。

参照

関連レポジトリ

• GitHub - ymotongpoo/qmk_firmware: keyboard controller firmware for Atmel AVR USB family
  • フォークして自分用のキーマップや各種設定ファイルなどを追加したレポジトリ
• GitHub - qmk/qmk_firmware: Open-source keyboard firmware for Atmel AVR and Arm USB families
  • フォーク元。ErgoDox EZの人がドキュメントのメンテしてる。
• GitHub - benblazak/ergodox-firmware: firmware for the ergoDOX keyboard
  • ErgoDox本家からリンクされているファームウェア
• Docker Hub : ymotongpoo/ubuntu-trusty/
  • qmk_firmwareのビルド用に作ったDocker環境。Ubuntu 14.04にAVRのビルド関係のパッケージ突っ込んでる。

ErgoDox

• http://ergodox.org/
  • ErgoDox 本家
• ErgoDox EZ: An incredible mechanical keyboard | Indiegogo
  • ErgoDox EZの購入先。自分もここから買った。
• Infinity ErgoDox Ergonomic Keyboard Kit | Price & Reviews | Drop (formerly Massdrop)
  • 別の既成品。スケスケ筐体でLCDがあるのがかっこいい。

ErgoDoxを使うが起きる日本語の記事

• Community Blog - 握力王 vs 日本男児 ヘルシーすぎるプログラマ対談（Part2）
• http://blog.muuny-blue.info/a02ef8389f6d40f84b50504613117f88.html
  • Ergodox買おうの会 · GitHub
• 漢(オトコ)のコンピュータ道: キーボードを新しくした話（ErgoDox）
• http://kammers.aa0.netvolante.jp/20150928201048/
• キーボードをErgoDox EZに新調した | ぼこブログ-ドラクエ10を4垢攻略
• ErgoDox買ったったった（そしてハウツーConfigurator） - Make 鮫 noise
• code before design: 　ErgoDox入門しました
• ErgoDox というキーボードを買った — yosida95
• ErgoDox EZが届いた · I Will Survive
• 流行りにのってErgoDox EZを買ってしまった - タオルケット体操
  • 僕が考えた最強のErgoDoxのキーマップ - タオルケット体操 : 2時間後の記事
• オープンソースなキーボード Ergodox を組み立ててみた - cd01 の blog

*1:別にどんな名前でもいいんですが、上記のwercker.ymlを使い回すならこの名前にしてください。

ErgoDoxを購入して人生がバラ色になった

はじめに

こんにちは、Go界のスコット・ヘレンです。最近はPrefuse 73を毎日聴いています。今日は久々に熱いガジェットが2ヶ月ごしに届いたのでその話を書きます。

エルゴノミクスキーボード

「エルゴノミクス」と呼ばれるものがあります。日本語では「人間工学」などと呼ばれています。普段使っている道具が作られた時に、人間の操作しやすさや疲労のしにくさといったものが考慮されていないことがよくあります。たとえば、PCのキーボードなんかはそうで、もともとタイプライターというものが存在した前提があって、そのキーの並びをそのまま持ってきたのが現在のキーボードの標準のキー配列であるQWERTY配列です。これはPCのキーボードの配列としては理にかなっていないということで、Dvorak配列というキー配列が登場したわけです。

キー配列に関してはすでに慣れてしまったので、いまからDvorakに変更するということは（おそらく）しないと思います。しかし、慣れの問題では済ませられないものがあります。それがキーボードの形状そのものです。PCのキーボードは、典型的なものでは長方形の板状の筐体に50個超のキーが配置されています。人間がそこに手を伸ばしてホームポジションに手を置いてキーを打とうとすると、どうしても手が内転してしまいます。腱鞘炎待ったなしです。そこでエルゴノミクスキーボードでは、なるべく手首が内転しないように真ん中を盛り上がらせたり、キーの配置を少し変えてみたり、あるいはKinesis Contouredのように、キーの配置を2箇所に分けた上にキーをおわん型に配置するなどの工夫をしています。

これですべて解決しているように思えますが、残念ながら自分はまだ納得入っていませんでした。5年ほど前にマッサージ師から肩こりがヒドイのでエルゴノミクスキーボードに変えたほうが良いとのアドバイスをうけ、Kinesis Contoured を使うようになり、たしかに肩こりはなくなりました。しかしながら、まだ肩が内側に入ってしまい、リラックスまであと一歩という状況でした。理由は簡単で、キーボードの幅と肩幅を比べた時に、肩幅のほうが広いからです。普通は肩幅よりも圧倒的にキーボードのほうが狭くなります。そうなると、キー入力の際には必然的に両手が肩幅よりも内側に来るようになります。試しにその状態で胸を張ってみてください。無理だと思います。人間はそういう姿勢で胸を張れるように出来てません。

ErgoDoxとの出会い

もちろん上記の不満点から、セパレート型のキーボードを検討したこともありました。しかし、そうすると今度はキー配置が気に入らないのです。Kinesis Contouredの良い点は単にキー配置を2箇所に広げただけでなく、十分に動くにも関わらず、普通のキーボードではスペースキーとAlt/Option、Command/Winキー程度にしか使われていない親指を有効に使えるよう、多くのキーを親指周りに配置しているところにもあります。

Kinesis Contouredのキー配列でセパレート式になったものが無いだろうか。ここ1年はとくにそのようなことを思っていたわけですが、ここで友人が動き始めたわけです。日本一握力のある男、そう超オス、 @hiroki_niinuma がμTRONキーボードを改造して親指に機能を多めに割り当てて使い始めたとのこと。快適であることを日々報告されると、ますますセパレート型キーボードが欲しくなる。しかしμTRONはキー配列が好みでない。

そんな折、ふとしたことでErgoDoxと出会ったのです。そう、あの対談です。

• Community Blog - 握力王 vs 日本男児 ヘルシーすぎるプログラマ対談（Part1）
• Community Blog - 握力王 vs 日本男児 ヘルシーすぎるプログラマ対談（Part2）

実は、このときこの場に同席していたんです。

ここで @nippondanji さんがErgoDoxについて紹介してくださって、実機を見せてくださいました。キー配列はKinesisと同じで、メカニカルキーボードであることも同じ、そして重要なセパレート型。すぐにErgoDoxに移行することを決意しました。問題はErgoDoxはオープンソースなキーボードであり、自力で作ることを想定していること。基盤を焼いたり、筐体を作ったり、キーをすべてハンダ付けしたり、などなど全部やらなければいけない。しかし、 @nippondanji さんがブログに書いていたように、すでにErgoDoxエコシステムと呼べそうなものができつつあり、パーツ代と手間賃を払えば完成品を送ってくるサービスがあるとのこと。いろいろ探して、自分も一台注文。

そして1月末に注文してから2ヶ月弱、ようやく今日届きました。

こういう感じで傾きをつけることもできるので、とても楽です。

使い始めてみると、本当に姿勢に余裕ができて、胸が大きく広がるため、堅苦しさを感じることがありません。また呼吸も深くでき常にリラックスできます。自分はエンジニア以前に人間としてなるべく元気でいたいと思っているので、日々のパソコン作業で極力体に負担がかからにようにするというのもひとつの重要な要素だと考えています。なので、いまこうやってErgoDoxを使って文章を書いていると本当にいい買い物をしたと思います。

ErgoDoxの買い方、あるいは組み立て方は他のサイトに譲るとして、もっと多くの人が楽な姿勢で仕事ができるようになればいいなと思います。

とりあえず現状のキーマップを晒しておきますね。

Drop: Passions lead here (formerly Massdrop)

国産のキーボードメーカーへのお願い

日本には品質の高いキーボードを作っているメーカーが多いので、ぜひエルゴノミクスキーボードにも力を入れて欲しい。特にErgoDoxはオープンソースライセンスで基盤や基本的な筐体の設計図をすべて公開しているので、それこそPFUや東プレが誇る静電容量無接点方式のErgoDoxキーボードが出たらまず買います！

エンジニアが長いキャリアを積めるようになれば、キーボードメーカーの皆様におかれましても市場が拡大されると思いますので、ぜひご検討ください。

あわせて読みたい

• 漢(オトコ)のコンピュータ道: あの超オスもセパレート式キーボードを使ってるらしい（ErgoDoxじゃないけど）
• 漢(オトコ)のコンピュータ道: キーボードを新しくした話（ErgoDox）
• 長時間作業するための快適そうなキーボードまとめ - kuenishi's blog

AMP対応 2016.02版

はじめに

こんにちは、Go界のエルゴノミクスキーボードです。今日Googleがモバイル検索で Accelerated Mobile Pages に対応したというアナウンスがありました。

• Google Japan Blog: モバイルウェブをもっと速く

また中の人が仕組みや導入手順を書いてくれたようです。やさしい！！

• Google モバイル検索が Accelerated Mobile Pages に対応しました - Google Developers Japan

しかしながら、私も今回のGoogleのAMP対応に関して、なぜかいろいろと知見が溜まったような気もするので、忘れないうちにこの場に書いておこうと思います。これはあくまでも私個人の意見であって、ここのコメントになにか書かれても一切お答えしないことを先に書いておきます。なお2016.02版としているのは、これからもいろいろと追加されたり変更されたりする可能性があるので、とりあえず現時点のものだという意思表示です。

まずAMPで何が出来るのか

よく聞かれることですが、まず大前提としてAMPは「一切」技術的に新しいことはありません。それどころか、現在ブラウザ上でウェブアプリケーションが実現できることが100だとすると、10くらい、あるいはもっと少ないことしかできません。しかしながら、出来ることを絞っているからこそ高速に表示ができるという、ごくごく当たり前のものです。当たり前でしょう、ということがQiitaの記事で書いてあったのでここにリンクしておきます。

• AMP(Accelerated Mobile Pages)ってなんで速いの。 - Qiita

しかしできないことが少ないながらも、収益化や分析や最低限のエンターテイメント性のためにはカスタムタグを作って、極力出来ること残しているという形です。

なにを目的としているのか

プロジェクトの公式サイトにも書いてありますが、私の理解では「静的なページをユーザが求める速度で素早く表示する」というところが主目的だと考えています。ですので、多くのユーザーインタラクションが必要なページはAMP化を考えるよりもProgressive Web Applicationのような形で実現するほうが筋が良いように思います。

「静的なページ」が何を指すのかといえば、ニュース記事、ブログポスト、店舗ページ、商品ページなど、内容の変化が無いあるいは少ないページを想定しています。いくつかは実際にサンプルにも載っています。

どうすればAMP対応になるのか

先のGoogle Developers Japan Blogのポストに手順が紹介されていますが、どこからか得た知見を元にもう少し詳細に書いておこうと思います。特にこれはGoogleのクローラーがインデックスするための内容です。

1. URL構造の決定

そもそもAMP化するという場合、既存のモバイル向けページを置き換えるというイメージを持たれる方がいますが、そうではなく、そのページは残したままAMP HTMLの仕様に従ったページを追加で作成するという形になります。*1 そして、元のページ（canonicalページ）とAMPページをお互いに <link> タグで指し合う必要があります。例示すると

• canonicalページ

<!doctype html>
<html lang="ja">
<head>
  <meta charset="utf-8">
  <title>Lorem Ipsum</title>
  <link rel="amphtml" href="https://example.ampproject.org/amp/article-metadata.html" />
  ...
</head>
<body>
  ...
</body>
</html>

• AMPページ

<!doctype html>
<html AMP lang="ja">
<head>
  <meta charset="utf-8">
  <title>Lorem Ipsum</title>
  <link rel="canonical" href="https://example.ampproject.org/article-metadata.html" />
  ...
</head>
<body>
  ...
</body>
</html>

そのため、CMS等で自動生成する場合には元ページに対してAMPページをどのようにするか決めておく必要があります。たとえば

• パスを追加する
  • https://example.com/foo.html -> https://example.com/amp/foo.thml
• ファイル名に文字を追加する
  • https://example.com/foo.html -> https://example.com/foo.amp.html
• URLパラメータを追加する
  • https://example.com/foo/ -> https://example.com/foo/?amp

AMPページをGoogleのクローラーが見られるようにする

キャッシュ出来るようにするためにはGoogleのクローラーが見に行けないと意味ないのでrobots.txtやメタタグにnofollowなどがないようにします。 たとえばこういうタグがあったらアウトです。

<meta name="robots" content="nofollow,noarchive">

AMPページを作成する

AMP HTMLの必須事項にしたがってAMPページを作成します。特にAMP HTMLの仕様とGoogleインデックスの仕様で異なる部分はschema.orgの仕様にしたがったメタデータの付与が必須である点です。

• amphtml/amp-html-format.md at master · ampproject/amphtml · GitHub

またAMPが発表された直後のブログポストではboilerplateのタグが次のような形になっていましたが、これは古いので（一応validになりますが）変えたほうがいいでしょう。*2

<style>body {opacity: 0}</style><noscript><style>body {opacity: 1}</style></noscript>

いまのコードはこちらです。

<style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>

validatorを使って検証する

現在、開発者が使えるvalidatorは次の2種類があります。

1. URLにフラグメント #development=1 をつけてGoogle Chromeなどのデベロッパーコンソールで確認できるもの
2. node.jsで書かれたコマンドラインで動かせるもの

基本的には1でテストするのがお手軽ですし、開発中はこれが楽だと思います。ただCIなどに組み込む場合は2を使うのが良いと思います。当たり前ですが2のほうが実装としては新しいので、1で見つからないエラーが2で見つかることもよくあります。

メタデータが正しいか確認する

AMP HTMLの検証が通ると結構安心してデプロイしてしまうのですが、メタデータが正しくないとGoogleのクローラーはキャッシュしてくれないので、Structured Data Testing Tool で検証します。また schema.org よりも制限があるところでよく引っかかるのは次の2点です。

1. logoのImageObjectのurlがPNG、JPEG、GIFになっていない
2. imageの横幅が696px未満

特に1はエラーになるので注意です。詳細はこちらのページにあります。

Search ConsoleのAMPレポートツールで状況を確認する

• Google Search Console

実際にインデックスされたAMPページはここに表示されます。手元でAMPのvalidatorやStructured Data Testing Toolで何もエラーが出ていないのに、ここでエラーが出ている場合でよくあるのが、テスト段階でクローラーが見に行ける場所にAMPページを置いていて、一度invalidな状態でインデックスされてしまった場合です。その場合はSearch Consoleから再クロールのリクエストをしましょう。

• URL の再クロールを Google にリクエストする - Search Console ヘルプ

よくある質問やはまりどころ

canonicalページはPC版とモバイル版どちらを指定したらいいでしょうか

すでにPC版とモバイル版それぞれにおいてページを作成している場合に、AMPページで指定するcanonicalページはどちらを指すべきか、ということですが、結論から言えばPC版とモバイル版だけを見た場合に、その2つでcanonicalになっている方を指すようにしてください。（たいていはPC版がcanonicalになっていると思います）

整理するとPC版がcanonicalで、各々次のようなURLになっている場合

• PC版: https://example.com/foo.html
• モバイル版: https://m.example.com/foo.thml
• AMPページ: https://m.example.com/amp/foo.html

このような関係になります

• PC版
  • canonical: https://example.com/foo.html
  • amphtml: https://m.example.com/amp/foo.html
• モバイル版
  • canonical: https://example.com/foo.html
  • amphtml: https://m.example.com/amp/foo.html
• AMPページ
  • canonical: https://example.com/foo.html

amp-adはどのアドネットワークに対応していますか

まずはここを見ることをおすすめします。type属性で対応しているアドネットワークであれば非常に簡単に設置できます。

また使用しているアドネットワークが対応していなかった場合には、ぜひそのアドネットワークの方にampprojectのレポジトリにpull requestしていただけるようリクエストされることをおすすめします。アドネットワークの方であれば、ぜひ率先してpull requestされることをおすすめします。以下公式ドキュメントより引用。

• amphtml/README.md at master · ampproject/amphtml · GitHub

We welcome pull requests by all ad networks for inclusion into AMP.

amp-xxxxというタグはどう使ったらいいでしょうか

とりあえず以下のページを見てイメージを掴んでから公式のドキュメントを見るのがおすすめです

• AMP by Example
• DFP AMP Testing
• Social Playground - AMP Partners Playground

公式のドキュメントはGitHubレポジトリのMarkdownファイルを見るのが最新なのでおすすめです。

• amphtml/builtins at master · ampproject/amphtml · GitHub
• amphtml/extensions at master · ampproject/amphtml · GitHub

アナリティクスを使いたいですがどうしたら良いですか

まずGoogle AnalyticsとAdobe Analyticsは両方共対応しています。他にも多くのアナリティクスツールに対応しています。type属性を確認してください。詳しくは次のドキュメントを参照。

• amphtml/amp-analytics.md at master · ampproject/amphtml · GitHub

最も気になるところとして取得できるイベントとデータだと思いますが、現状日々増えているので常に次のドキュメントを確認することをおすすめします。

• イベント: amphtml/amp-analytics.md at master · ampproject/amphtml · GitHub
• 変数: amphtml/analytics-vars.md at master · ampproject/amphtml · GitHub

<amp-analytics> 要素を <head> 要素内に書きたい人もいますが、 <body> 要素内に入れてあげてください。またAMPプロジェクトが発表された直後の記事などに <amp-pixel> を使った例がありますが、こちらもあまりおすすめしません。

styleについて

AMPの制限で一番きついところの一つにstyleを <head> 要素内の <style amp-custom> 要素内で一発で決めないといけない、というのがあります。CMSなどの開発をされている中で、 <article> 要素の入稿である程度自由にタグを挿入できる機能がある場合は、まずあらゆるstyleを全部 <head> 要素内に押しやらないといけないですし、要素内の属性もかなり削ってやらないとinvalidになります。

AMP対応のブラウザはなんですか

まず、そもそも「Accelerated Mobile Pages」なので、デスクトップブラウザは（動かないわけではありませんが）無視してください。また最初に書いたとおり、AMP HTMLというのは、HTML5の仕様に制限をつけただけのものです。なのでHTML5を解釈するモダンなモバイルブラウザであれば基本的になんでも動きます。ただそれ由来で細かいところで差異が出てくることも承知しておいてください。（例: <amp-video> タグ）

おわりに

どこからか得られた知見でした。

*1:もちろん、AMP HTMLのページに置き換えることも可能です。その場合はそのページ自体をcanonicalページとします。

*2:ここにも古いって書いてあります

恵贈御礼 「Go言語にWebアプリケーション開発」読了

はじめに

こんにちは、Go界のパルメザンチーズです。オライリー・ジャパンより次の本をいただきました。ありがとうございます。

Go言語によるWebアプリケーション開発

感想

Go言語そのものをまったく書いたことがない人がいきなり本書を読むのはいささか厳しいと思いますので、あらかじめ A Tour of Go などを終え、FizzBuzz程度でもいいので簡単なコマンドラインアプリを手元で書いてみてから読み始めるのが良いと思いました。

この本で一番読み応えがあったのは、監訳者の鵜飼さんによる日本語訳版オリジナルの書き下ろしである「付録B：Goらしいコードの書き方」でした。本書を読むにあたって、まず最初に読むべき章だと言っても過言ではありません。本文に出てきたソースコードをより洗練するためにどのような点に注意すればよいかが書かれている貴重な日本語資料です。また本文のいたるところで補足するべき箇所にきめ細かな監訳注があるのも、日本語訳版の素晴らしいところです。この監訳注によって本書の品質が大幅に向上していることは間違いありません。

内容そのものは、構造化された解説書というよりも、実践的なチュートリアル本というのが適切でしょう。Goの文法はわかったけれどどこから手をつけていいかわからないという方は、まずは自分が取り組んでみたいと思っているテーマに近い章を開き、本文にしたがって少しずつコードを書きながらGoでプログラムを書くことに慣れるというのがおすすめです。サードパーティーライブラリの紹介なども多かったので、他言語の経験があるけれどもGoは初めて、という方にも肩慣らし的に試すのには手っ取り早い本だと思います。

1-3章がWebSocketを使った簡単なチャットシステムのフロントエンドとバックエンド、4章で簡単なコマンドラインツール、5-6章では並列処理を使ったデータ解析サービスとそのREST API化、7章ではファイルバックアップシステムと、テーマは多岐にわかっていますので、つまみ食いでも始めやすいです。

Goはシステムプログラミング言語としてよく知られていますが、実際にどういう形で実現できるのか、本書で実感いただけるのではないかと思います。

読書メモ

ページ数は書籍版のものです。

p.21 監訳注2

デフォルトのパッケージ名は package キーワードで指定されたものであり、ディレクトリ名ではないが、通常は揃えるという話。違ってくる場合としてよくあるのはパッケージをバージョンニングするとき。たとえば、Google Drive APIのクライアントライブラリはv1, v2, v3と３つのバージョンがある。これをimportするときは次のようになる。

import github.com/google/google-api-go-client/tree/master/drive/v3

p.81 監訳注1

パッケージ名に common や lib 、 util を使わないようにしようという話はgoblogに詳しく解説されている。

• Package names - The Go Blog

p.158 ノート

GorillzはGorillaのtypoだと思う。muxerも自分で書いてみるような問題もあれば良いのにと思った。

p.221 監訳注2

const では指定しないかぎり型がないという話はgoblogに詳しく解説されている。

• Constants - The Go Blog

「高熱隧道」読了

はじめに

こんにちは。Go界の日本電力です。年末に買った本を年末年始で読めなかったので、昨晩一気に読み終えました。

高熱隧道 (新潮文庫)

仙人谷ダムと黒部ダム

• 仙人谷ダム - Wikipedia
• 黒部ダム - Wikipedia

プロジェクトXで取り上げられてたのは、黒部ダム（通称「黒四ダム」、黒部第四発電所のためのダム）で、この高熱隧道の舞台になっている場所よりもさらに奥地に建設されています。黒部ダムの建設に関する逸話は小説をはじめ、映画、ドラマやドキュメンタリーの形で取り上げられているため、名前を知っている人も多いし、自分もプロジェクトXではじめてその壮絶な工事を知ったときには圧倒されたことを覚えています。工事での殉職者が171人にも及んだというのは、高校生の自分には衝撃的な内容でした。黒部ダムの難工事に関する物語としては「黒部の太陽」が有名でしょう。

黒部の太陽

しかし、その20年以上も前、まだ戦時中に同じ黒部川水系で、黒部ダムに負けずとも劣らない難工事が行われていたことをこの小説で初めて知りました。その内容が本当に壮絶で、真の意味でデスマーチと呼びたくなるものでした。

本当のデスマーチ

どういう意味でデスマーチだったのか、ある程度ネタバレにはなりますが書いてしまうと

• そもそも工区にたどり着くまでの道が切り立った岩場を繰り抜いた程度のもので道幅がわずか60cm程度。資材の運搬を行うボッカが工事着工前にあっという間に5名転落死する。
• 工区そのものが温泉湧出地帯のまっただ中を通過することが工事着工前の地質学者による調査では明らかになっていなかった。
• 掘削する岩肌が開始30m地点ですでに摂氏65度を超え、掘り進めるにしたがってどんどん加熱、最高地点では摂氏166度に。
• 掘削中の隧道内はサウナ状態であり人夫が切端で作業を行える時間がたった20分に。それですら、失神する人夫も数多くいた。
• 人夫を冷やすために渓谷から汲み上げた水を人夫にかけるが、その水が隧道内にたまり人夫の膝まで、ひどい時には腹までたまるほどに。しかも岩肌に暖められて水温が摂氏45度まであがることも。
• 岩肌がダイナマイトの発火温度を超えるほどになってしまい、設置と同時に爆発。担当していた人夫が死亡。

まだまだこれは序の口で、最終的にこの工事による殉職者が300人に迫るほどになるわけですが、それに至る過程が緻密な描写で淡々と語られていくのがこの小説の恐ろしいところです。多数の犠牲者を出しながらも工事が中止とならなかった背景には、工事の発注元の日本電力の社運をかけた工事だったことと、当時電力が国家的に求められていたこと、しかも天皇からも恩赦がでるほどであったため辞めるに辞められなかったという状況があるようでした。

吉村昭氏の綿密な調査により、工事中の隧道の様子が細かな部分まで伝わってくる、素晴らしい「記録小説」でした。小説に登場する人物や企業はフィクションではあるものの、実際にそれに対応する人物や企業がいるようです。実際に小説中の各事件での殉職者数は現実の事件と一致しています。

「デスマーチ」という言葉を職業柄よく聞きますが、真の意味で「デスマーチ」の物語でした。