YAMAGUCHI::weblog

太めの女性の軍団が、本部をグルリと囲んでます。 現在恋人募集中! ポンコツミニチュア三等兵、中井です。

C言語でプログラミングする際の覚書(Notes on Programming in C)

はじめに

こんにちは、Go界のシャールト・コプリーです。気がついたら最後のエントリから3ヶ月も経ってました。

Goを始めると「なんでこういう書き方になってるんだろう」とか、「そもそもなんでこういう仕様になってるんだろう」とか思うことがちらほらあると思います。これは大いにGoの作者の一人であるRob Pike氏の思想に依るところがあるのが見受けられます。彼のプログラムに対する考え方が25年前に公開され「Pike Style」として知られていますが、いまもその考え方は大きくは変わっていないと思われます。せっかくなので翻訳しました。本文はC言語に関する文章ですがその本質は言語に依らないものだと思います。

(追記)25年前なのでコンパイラの動作に依存する部分(includeに関する記述)などは古い部分もありますが、プログラミングスタイルに関する部分は現代にも通じるところがあると思います。

(追記2)幾つか誤訳をご指摘いただけたので修正いたしました。コメントに感謝しています。

(追記3)僕の役はひどいのでこちらを読みましょう。

誤訳箇所の一覧です。

C言語でプログラミングする際の覚書

Rob Pike 1989年2月21日

Copyright (C) 2003, Lucent Technologies Inc. and others. All Rights Reserved.

まえがき

KernighanとPlaugerの “The Elements of Programming Style” (「プログラム書法」木村泉訳)は重要で間違いなく影響力のある書籍でした。しかし、ときに私はその簡潔なルールが本来意図した哲学の簡潔な表現としてではなく、良いスタイルにするためのクックブック的な手法として捉えられていると感じます。もし、かの書籍が変数名は意味があるように選ばれるべきだと主張するのであれば、変数名はその用途を説明したエッセイになっている方が良いということにならないでしょうか。 MaximumValueUntilOverflowmaxval よりも良い変数名でしょうか。私はそうは思いません。

従うべきは、厳しいルールを与えることではなく、プログラムを書く際の明確さの哲学を全体として助長するような短いエッセイです。みなさんにこれらすべてに同意してもらいたいわけではありません。なぜならこれは意見であり、意見は時間とともに変化するものだからです。しかし、私の意見は頭のなかにしばらくあったものをまとめたものであり、長らく文章として公開してきませんでした。またこれらは私の多くの経験を踏まえたものです。そのため、プログラムの細かな部分に関する計画方法の理解に役立てば幸いです。(これまでプログラム全体の計画に関しての良い文章は読んだことがありますが、それらはこの文章で触れる内容の一部となります)もしいまから紹介するものを特異だと感じたのであれば、それはそれで結構です。また同意できないとしても、それも結構です。しかし、なぜあなたがなぜ同意できないのかを考えるきっかけになったのであれば、より良いことでしょう。どのような状況においても、私がそういったからという理由で私が言ったやり方で書くべきではありません。あなたがそのプログラムで実現したいものを最も良く記述できると考える方法でプログラムしてください。そしてそれを一貫し容赦することなく行ってください。

あなたのコメントをお待ちしています。

表示の問題

プログラムは一種の出版です。プログラムはプログラマや他のプログラマ(おそらく数日後、数週間後、数年後のあなた自身)、そして最終的にはマシンに読まれることを前提としています。マシンはそのプログラムがどれほど美しいかは気にしません。コンパイルできれば、それで幸せなのです。しかし、人間は気にします。そして気にすべきです。ときに気にし過ぎます。たとえば、pretty printerは機械的にプログラムの重要でない部分も強調するような美しい出力をします。これは、英語の文章内にある前置詞 すべて太字 するの 同様 です 。しかしながら多くの人々がプログラムはAlgol-68 Reportのような見た目(システムによってはそのスタイルで編集することを強制します)であるべきと考えますが、明瞭なプログラムはそのような見た目で成されるものではなく、また悪いプログラムであれば明瞭にしても滑稽になるだけです。

もちろん表示に関する一貫した規約は見た目を明瞭にするためには重要です。インデントは最もよく知られ最も有用な例です。しかし、印字がプログラムの意図を曖昧なものにしてしまうのであれば、がやり過ぎだったということです。したがって、たとえあなたが昔ながらのタイプライターのような飾り気のない表示にこだわっているのだとしても、表示における愚かさを意識しましょう。余計な飾りをやめましょう。たとえばコメントは短く、バナーは無くしましょう。プログラム内で言うべきことを、綺麗に一貫して言いましょう。それから先に進みましょう。

変数名

そうですね、変数名です。変数名の長さは美徳ではありません。表現の簡潔さが大事なのです。滅多に使われないグローバル変数は長い名前にしてもいいでしょう。たとえば maxphysaddr といった具合です。ループ内のすべての行に出現する配列のインデックスは i 以上に凝った名前を付ける必要はないでしょう。たとえば indexelementnumber といった変数名はタイプ量(あるいはエディタ内で呼ばれる回数)が増え、計算の内容を不明瞭にします。変数名が巨大な場合、何が起きているかを把握するのが難しくなります。これは表示に関する問題の一部です。

for(i=0 to 100)
    array[i]=0

というコードと

for(elementnumber=0 to 100)
    array[elementnumber]=0;

というコードを見比べてみましょう。

現実の例では問題はもっと速く明らかになります。インデックスはただの注記なので、そのように扱いましょう。

ポインタもまた気が利いた注記が必要です。どの np が "node pointer" を意味しているかがすぐに分かる命名規則を一貫して使っていれば、 npnodepointer という名前と同じくらい読みやすいものになります。

プログラムの可読性に関していえば、命名において一貫性は重要です。ある変数に maxphysaddr と名づけたら、同様の変数に lowestaddress という名前をつけてはいけません。

最後に、私は最短の名前ではなく最も情報量がある名前を好み、ほかは文脈に任せる方法を好んでいます。たとえば、グローバル変数は典型的には使われる際にはほとんど文脈がないので、名前は比較的それだけで内容がわかるものである必要があります。したがって、グローバル変数名には maxpysaddrMaximumPhysicalAddress ではありません)という名前をつけ、ローカル変数には NodePointer ではなく np のような名前をつけます。これは好みによるところが大きいですが、その好みというのは明瞭さに関係するものです。

名前に大文字を入れるのも避けています。散文調の文章を見慣れた私には、大文字が文章の中に入ると不格好に感じられ快適に読めないのです。大文字は悪い印刷のように目障りなのです。

ポインタの使用

C言語はポインタでなんでも指せるという点で特異です。ポインタは賢い道具で、他の同様の道具のように、上手に使えば楽しく生産的になりえるものの、使い方を間違えると大きな損害を与えます。(この文章を書く数日前に木工彫刻刀で親指を怪我したばかりです。)ポインタは危険すぎる、あるいは汚すぎると考えられ、学術会では評判が良くありません。しかし私はポインタは強力な 注記 であると考えます。つまり、ポインタは明瞭な表現をする手助けをしてくれるという意味です。

次の状況を考えてみてください。あるオブジェクトに対するポインタがあるとき、それはまさにそのオブジェクトに対する名前であり、他のなにものでもありません。些細なことのように思えるかもしれませんが、次の2つの表現を見てください。

np
node[i]

最初のポインタはノードを指していて、2番目は(たとえば)同じノードを評価しています。しかし、2番目の形式は式です。単純ではありません。これを理解するためには node が何か、 i が何かを理解し、そして nodei がどのような関係にあるか(おそらく明記されていない)を周りのプログラムから理解しなければなりません。独立した式それだけでは inode の正しいインデックスかはわからないですし、ましてそれが私達がほしい要素のインデックスかはわかりません。もし ijk のすべてがノードの配列のインデックスだった場合、容易にうっかりと間違えてしまいます。特にサブルーチンに渡すときは間違いを起こしやすく、コンパイラでは避けようがありません。ポインタであれば1つのものを指しています。配列とインデックスは受け取ったサブルーチン側がお互い関係があるものとして信用しなければなりません。

オブジェクトに評価する式は、オブジェクトのアドレスよりも本質的により判断しづらく間違いを起こしやすいものです。ポインタを正しく使うことでコードを簡潔にできます。

parent->link[i].type

lp->type

を見比べてください。

もし次の要素の型が必要な場合は

parent->link[++i].type

よりも

(++lp)->type

のほうが見やすいでしょう。

i は値が進みますが、それ以外はなにも変化がありません。ポインタであれば進めるのは1つのものだけです。

ここでも表示の問題が出てきます。ポインタを使って構造を読み込むのは式を読むよりも理解が楽です。必要なインクの量は少なく、コンパイラやコンピュータが展開する労力も減ります。関連した問題として、ポインタの型が正しく使われているかに影響を与えているかというものがあります。これでコンパイル時に配列のインデックスが適切で無い旨のエラー検出が可能になります。また、そのオブジェクトが構造体の場合はタグとフィールドは型を思い出させてくれます。つまり

np->left

はそれぞれが何を挿すかを思い出させるのに十分です。これがもしインデックスが指定された配列であれば、配列名はきちんと選ばれた名前で、表現は長くなります。

node[i].left

再度になりますが、余計な文字は表現が大きくなるにつれて苛立たしくなります。

ルールとして、もし同様の表現を含むコード、たとえばデータ構造の要素を評価するような複雑なデータ構造があった場合、思慮深くポインタを使えばすっきりとできます。

if(goleft)
     p->left=p->right->left;
else
     p->right=p->left->right;

p の複合的な使い方をしているこのコードが何をしているかを考えてみましょう。時には一時変数(この場合は p )を使用したり、計算の本質を抜き出すマクロを使用する価値があります。

プロシージャ名

プロシージャ名はそれが何をするかを反映すべきです。つまり関数名はそれが何を 返すか を反映すべきです。関数は式の中で使われ、しばしば if の中で使われます。したがって適切に読む必要があります。

if(checksize(x))

という記述は役に立ちません。なぜならchecksize関数がエラーの時にtrueを返すのか、エラーでない時にtrueを返すのかが推測できないからです。代わりに

if(validsize(x))

とすれば要点が明らかになり、将来同じ関数を使うときの間違いが起こりにくくなるでしょう。

コメント

慎重に、経験と判断をもって書く必要があります。私は、いくつかの理由から、コメントを極力書かないようにしています。まず、コードがきれいで、良い型名や変数名を使っている場合、コードそれ自身が内容を説明しているはずです。次に、コメントはコンパイラにはチェックされないので、コメントが正しいという保証はありません。特にコードが変更されたあとはそうです。誤解を招くコメントは非常に紛らわしいものです。最後に、表示の問題です。コメントはコードを散乱させてしまいます。

しかし私も時々コメントを書きます。ほとんどもっぱらその後に何が続くかを説明するために書きます。例えば、グローバル変数の使い方とその型の紹介(大きなプログラムではいつもコメントするものの一つ)、通常の使い方をしていないプロシージャや非常に重要なプロシージャの紹介、あるいは大きな計算をする際の区切りなどです。

悪いコメントの例としては次のようなものがあります。

i=i+1; /* Add one to i */

さらに悪いコメントの例は

/**********************************
*                                 *
*           Add one to i          *
*                                 *
**********************************/

i=i+1;

いまこの例を笑ってはいけません。実際にこのようなコードに出くわしたらはじめてそこで笑いましょう。

複雑さ

たいていのプログラムは複雑過ぎます。つまり、問題を効率的に解決するために必要な複雑さよりも複雑なのです。なぜでしょう。多くの場合、それは設計の悪さに起因しますが、ここではその話は大きすぎるテーマなので触れません。しかし、プログラムはしばしば細かなレベルでも複雑で、ここではその点についてお話します。

ルール1 プログラムのどこに時間がかかる場所があるかはわからない。ボトルネックは思わぬ場所で起きる。したがって、どこがボトルネックかわかるまでは、合理的な判断なしに余計な勘ぐりをしたり高速化のためのハックをするのはやめよう。

ルール2 計測しよう。計測するまでは高速化のためのチューニングはやめよう。さらに、高速化のためだとしても、プログラムの残りの部分を圧倒するような場合でない限り、チューニングはやめよう。

ルール3 n が小さい時にはしゃれたアルゴリズムは遅く、そして通常 n は小さい。しゃれたアルゴリズムではその影響が現れるコンスタントな値は大きい。 n が頻繁に大きくなるとわかるまでは、手が込んだアルゴリズムは使わないようにしよう。(たとえ n が大きくなるとしても、まずはルール2を考えよう)たとえば、日常的な問題では二分木は常にスプレー木よりも速い。

ルール4 しゃれたアルゴリズムは単純なアルゴリズムよりもバグを起こしやすい。そして実装がずっと難しい。単純なアルゴリズムと単純なデータ構造を使おう。

次に挙げるものはほぼすべての実用的な問題を解決するデータ構造の一覧です。

  • 配列
  • 連結リスト
  • ハッシュテーブル
  • 二分木

もちろん、これらのデータ構造を組み合わせたデータ構造にすることも配慮しなければいけません。たとえば、シンボルテーブルは文字型の配列の連結リストを含んだハッシュテーブルとして実装されているでしょう。

ルール5 データが支配する。正しいデータ構造を選び、物事をうまくまとめれば、それを使うアルゴリズムは自明である。アルゴリズムではなく、データ構造がプログラムの中心である。(詳しくは「人月の神話」を参照のこと)

ルール6 ルール6はない。

データでプログラミングする

アルゴリズム、つまりアルゴリズムの細かな部分は、しばしばデータという簡潔で、効率的で、表現豊かな形に記号化されます。それは、たとえば、多くのif文という形ではありません。その理由は、もし手元にある 複雑さ が独立した細かな部分の組み合わせによるものなのであれば、それは 記号化できるから です。古典的な例で言えば、表のパースです。これはプログラミング言語の文法を、定形のかなり単純なコード片によって説明可能な形式に記号化することです。特にこのような問題に取り組むときには有限状態機械が採用されていますが、ある抽象的な入力を「パース」して一連の独立した「振る舞い」に変換するようなあらゆるプログラムは、ほとんどが生産的な形としてデータ駆動のアルゴリズムになります。

おそらくこのような設計の最も魅力的な側面は、ときどき表が、古典的な例ではパーサジェネレータといった、他のプログラムに生成されることです。もっと現実的な例では、オペレーションシステムが、I/Oのリクエストとそれに対する適切なデバイスドライバの組み合わせを持ったひとまとまりの表によって動いているとした場合、システムはマシンに接続されたある特定のデバイスの説明を読み込み、対応する表を表示するようなプログラムによって「構成される」でしょう。

データ駆動プログラムが一般的でない理由の一つは、少なくとも初心者においては、Pascalによる圧政でしょう。Pascalは、その創始者のように、コードとデータの確固たる分離を信条としています。したがって(少なくとも本来の形では)初期化されたデータを作ることはできません。このことはチューリングフォン・ノイマンの理論の前にはたち消えてしまいます。この理論はストアドプログラム方式のコンピュータの基本原理を定義しています。コードとデータは同じものです。あるいは少なくとも同じになりえます。それ以外にどうやってコンパイラが動作するかを説明できるでしょうか。(関数型プログラミング言語でもI/Oにおいて同様の問題を抱えています。)

関数ポインタ

Pascalの圧政は、初心者が関数ポインタを使わない、という状況ももたらしています。(Pascalでは関数を値にもった変数を持つことができません。)複雑さを記号化するために関数ポインタを使うことにはいくつか面白い特性があります。

複雑さのいくつかは参照先のルーチンに渡されます。そのルーチンはいくつかの標準的な規約に従わなければいけません。そのルーチンは同じ呼び出し方をされたひとまとまりのルーチンの一つです。しかしそれ以上にそのルーチンは自分がすべきことしかしません。複雑さが 分散された のです。

この規約という考え方があり、そこでは似たような使われ方をする関数はすべて似たような振る舞いをしなければいけなません。これによって、ドキュメントが書きやすくなり、テストがしやすくなり、コードを成長しやすくし、さらにはプログラムをネットワーク越しに分散させて稼働させやすくなります。この規約はリモートプロシージャコールとして記号化されます。

私は、関数ポインタを明確な形でつかうことがオブジェクト指向プログラミングの心であると、主張します。あるデータに対してひとまとまりの操作を行いたい、かつ、それらの操作に対してひとまとまりのデータ型を返したい場合、そうプログラムする簡単な方法は各型に対して関数ポインタをまとめることです。これは、一言で言えば、クラスとメソッドを定義することです。もちろん、オブジェクト指向言語は優れた構文、派生型などといった、より多くのものを提供してくれます。しかし、概念的にはオブジェクト指向言語は先のものにほんの少しのおまけを提供してくれるだけです。

データ駆動プログラムと関数ポインタを組み合わせが、プログラムの驚くほど表現豊かな書き方へと導いてくれます。私の経験から、その書き方はしばしば嬉しい喜びももたらしてくれます。たとえ特別なオブジェクト指向言語がなくても、余計な手間をかけずに、オブジェクト指向の90%の恩恵を授かることができ、結果をより管理することができるようになります。より高度な次元の実装方法を推奨することはできません。私がこのようなやり方で書いてきたすべてのプログラムは、その後の多くの開発のあとも快適に動作しています。規律が少ない手法で開発されたものよりもずっと良く動作しています。以上です。この手法が強制する規律は、長い目で見て大きな利益をもたらします。

インクルードファイル

単純なルールです。インクルードファイルは決してインクルードファイルをインクルードすべきではありません。代わりに(コメントや暗黙的に)まずどのファイルがインクルードされるべきか宣言した場合、どのファイルをインクルードするかという問題はユーザ(プログラマ)側に押し付けられますが、ある意味では管理がしやすくなり、ビルド時に複数のインクルードを避けることができます。複数のインクルードはシステムプログラミングでの悩みの種です。一つのCのソースファイルをコンパイルするのに5回以上もインクルードされたファイルがあることは珍しくありません。Unix/usr/include/sys はこの点でひどいものです。

1つのファイルが2度呼ばれないように #ifdef を駆使する方法がありますが、普通は間違った結果となります。 #ifdef はインクルードされるファイルの中にあり、インクルードする側にはありません。その結果、しばしば何千行もの不要なコードが字句解析器に渡されることとなり、これは(良いコンパイラでは)最もコストが高いフェーズとなってしまいます。

単純なルールに従いましょう。

本文に出てきた書籍

プログラム書法 第2版

プログラム書法 第2版

人月の神話【新装版】

人月の神話【新装版】

「すごいErlangゆかいに学ぼう! 」という本が出版されました #すごいE本

はじめに

こんにちは、Erlang界のCBR400Rです。このたび、私の2冊めの翻訳書籍、印刷されたものとしては初となる書籍が「すごいErlangゆかいに学ぼう!」というタイトルでオーム社より出版されました。本日より書店ならびにAmazonはじめとするオンラインストアでご購入頂けます。

すごいErlangゆかいに学ぼう!

すごいErlangゆかいに学ぼう!

いま手元にある本の厚さや重さを実際に感じて、電子書籍では味わえなかった充実感、達成感を得ています。これの実現に至るまでに多くの方々にお世話になり、その方々のご協力なしには出版なんて到底ありえませんでした。本当に感謝しています。ありがとうございました。

「すごいErlangゆかいに学ぼう!」はどんな本なのか

これはFred Hebertの書いた"Learn You Some Erlang for great good!"の日本語訳書籍です。著者のFredはこの本の出版を評されて、2012年のErlang User of the Yearに選ばれています。Erlang公式コミュニティからも、推薦の一冊として紹介されている、という書籍です。

Learn You Some Erlang for Great Good!: A Beginner's Guide

Learn You Some Erlang for Great Good!: A Beginner's Guide

タイトルに「Erlang」と入っているので、当然プログラミング言語Erlangに関する本です。ただその内容の量、質が尋常じゃないんです、ほんとに。内容をいくつかの章ごとに大きく分けると、おおよそ次のような構成になっています。

  • 1-9章: Erlangの基礎と関数プログラミングの初歩について
  • 10-13章: 並行プログラミングについて
  • 14-17章: OTPの基礎
  • 18-25章: OTPアプリケーションについて
  • 26-29章: 分散アプリケーションについて
  • 30章と残り: 型と新仕様について

Erlangの本なので1-9章でErlangの文法の習得をするのは当たり前なのですが、それ以降の章はErlangを習得しようとする方のみならず、並行プログラミングや分散アプリケーションを実現する上で一体どのような機構を用意しなければいけないのかを理解したい他言語の方にも十分有用な内容となっています。OTPという「フレームワーク」がいかに先に述べたようなアプリケーションを容易にかつ堅牢に実現しているかを理解する上で、本書の構成が非常に優れていると私個人は思っています。その理由はこの本がOTPありきで進まないからです。まずかならず手持ちの機能だけで頑張ってアプリケーションを実装してみて、いよいよ実装が複雑になりお手上げとなったところでOTPを紹介し、その有用性を実感できる形になっています。一つ一つ確実にその有用性を理解することで、Erlangに限らず他の言語でも同様のアプリケーションを実装する際には似たような機構が必要になることを直感的に理解できるのではないでしょうか。このような内容を自分で手を動かしながら理解できる日本語書籍は、自分で言うのもなんですが、他に知りません。

また理解が進めば進むほど、OTPの強力さを思い知らされることになります。普通の言語では標準ライブラリ等はあくまで言語に付随するもので、とりだてて別称することはありません。しかしErlangではわざわざErlang/OTPと標準ライブラリであるOTPを併記します。個人的にはこの辺りにOTPの重要性が垣間見えると思っています。つまりOTPというフレームワークがあるからこそ、Erlangが存在しうる、という意志の表れではないでしょうか。

「新しい言語を学ぶ」というだけではなく「新しい仕組みを知る」という点でもおすすめです。ぜひご一読下さい。また本書は原著版にもない、最新のR17.0から導入されたマップについてのまるまる1章追加されています。R17.0対応している日本語のErlang書籍は本書だけです!

翻訳の思い出

この翻訳書籍を出版するきっかけは3年半前までさかのぼります。*1 訳者序文にもありますが、まだ僕が転職する前に、レビュアーの @voluntas から原著のウェブ版(当時はまだウェブ版しかなかった)を紹介されたのがきっかけでした。そして、Erlangという、よくわからないけどなにやら並行・分散プログラミングが非常に得意でネットワークサーバの作成にすこぶる向いている面白い言語がある、と前々から聞いていたので、勉強がてら翻訳を開始しました。

始めのほうは順調に翻訳を行っていたものの、後半になるにつれどんどん1章ごとの分量が増え、さらに内容も複雑化して、非常に苦労していたことを覚えています。その後、途中で別のことをしていたり、仕事が忙しくなったりして翻訳が滞り、ウェブ版の原著が30章まで完成しいよいよ印刷版が出るという噂が出始めた頃には、まだ22章までしか翻訳が終わっていませんでした。その後しばらくして転職をし、そろそろ翻訳を再開しようかと思っていた頃に、オーム社の鹿野さんと高尾さんに今回の翻訳書籍の出版のお話を頂きました。

とりあえずウェブ版原著の翻訳を終えることが肝心ということで、なんとかウェブ版原著の翻訳を終えました。その後、原著の書籍版が出版され、オーム社さんにウェブ版と書籍版の突き合わせ原稿を作成してらっているうちに、またバタバタしだしてしまい、翻訳が滞ってしまい、結局今年の頭から書籍版の翻訳を再開。とまあ、書籍版自体の翻訳を開始するまでがすでにウェブ版の翻訳から3年経っているという状況だったのですが、書籍版の翻訳が始まってからは、多くのレビュアーの方に的確なレビューをいただき、短い期間で非常に多くの改善を行うことが出来ました。現在公開されているウェブ版の日本語訳と比較すると、恥ずかしくてウェブ版を取り下げたいレベルです。

自分の中で4年間弱常に頭の片隅にあったモヤモヤが、こうやって無事に出版にこぎつけた今日ようやく消えた気がします。あー、長かった。

オーム社での翻訳体制の話

ウェブ版の翻訳は個人のBitbucketのhgレポジトリ、後半になってGitHubのprivateレポジトリ、そして書籍版の翻訳は最初はsvn+tracを使い、2013年11月からはオーム社GitHubのプライベートレポジトリに移行しました。このように何度かレポジトリの引越しをして出版まで来たわけですが、最後のGitHubでの運用が一番個人的に楽でした。運用方法は特に明文化されていたわけでなく、レビュアーに自由にチケットを切っていただきながら、ラベルやマイルストーンを適宜追加していったわけですが、いま振り返ると次のような方法で翻訳するのが楽だったなと思いました。

編集原稿

鹿野さんが用意して下さったのですが、拡張HTMLのようなマークアップ原稿でした。基本HTMLなのですが、原稿には日本語と英語原文の両方があり、日本語の部分のみ編集。たとえばつぎのような感じです。

<p lang="en">Learn You Some Erlang for great good!</p>
<p lang="ja">すごいErlangゆかいに学ぼう!</p>

このlang="ja"の部分だけど編集する形。GitHubへpushするとCIが回され、そこでLaTeX化の後にPDFになり、毎日夜中に最終版のPDFが共有のWebDAVサーバに置かれる形でした。

この原稿がよかったのは、CSSがきちんと用意されていたので、ローカルでもブラウザで簡単に読めたこと、そしてHTML、PDFという異なる形式でレビューできたので間違いを拾いやすかったことです。逆になれないと大変だったのは、HTMLを直接さわる感じなので、最初はタグがチラチラ目障りに感じたこと、そして < などの特殊記号のエスケープがたまに必要だったことぐらいです。自分の好きなエディタで気軽に編集できたのは助かりました。

ブランチ戦略

基本masterブランチ1本で、Pull Requestがある場合にのみブランチを切ってもらいます。ソースコードほど厳密にfeatureがあるわけでもないので、ブランチ名はレビュアー名とか、適当に分かる名前をつけてもらいました。mergeに関しては翻訳者である自分と編集者の鹿野さんが行うのみ。自然言語のmergeは時折うまくいかないことがあり、mergeツールに騙されたことが何度かありましたが、ほぼ問題なく運用できていました。

レビューのissueの切り方

それぞれにまちまちで、それぞれにわかりやすい点はあったのですが、個人的に一番対応しやすかったのは次のようなissue。

  • タイトル: <章番号> <該当箇所 or issue概要>
  • 本文: <GitHub上の該当箇所への行リンク> <issue内容>

GitHubでは行へのリンクが可能なので、ブラウザ上で読むときにリンクが該当箇所のリンクがあるのは非常に便利。さらに、行リンク内に行番号があるので、実際に手元で編集を行う上でも行リンクは便利でした。編集後に行番号がずれることはありましたが、基本的に10行もずれないのでこの方法でうまく行きました。

編集コメントの扱い

最初は僕と編集の方だけでやりとしていたので特にissueとか上げず タグでやりとしをしていました。が、レビューの段になって、編集コメントで質問されている内容が後々まで放置されてしまい、最後で慌てて回収するという事がありました。組版や作業報告以外は編集コメントではなく、issueに上げたほうが皆の目が入るし幸せかなと思いました。(もしくは両方に記載する)

おわりに

訳者序文でも書いていますが、本書の出版はレビュアーの方々のご協力なしには到底ありえませんでした。私がErlangを業務で書いているわけではない中で、実際にErlangで、しかも先端で仕事をされている方々からの実務経験に基づいた細かなアドバイスや、他の関数型言語のエキスパートとしての側面からの指摘、さらには他言語の経験がありつつErlang初学者としての視点からのフィードバッグなど、果ては私の拙い日本語の修正など、多くのレビューを頂きました。この場を借りてレビュアーの皆様に改めて感謝いたします。

書籍版レビュアーのみなさま(五十音順)

  • @ajiyoshi さん
  • 幾田雅仁さん (@cooldaemon)
  • 上西康太さん (@kuenishi)
  • 篠原俊一さん (@itawasa)
  • 渋川よしきさん (@shibu)
  • 島崎清山さん (@seizans)
  • 中居良介さん (@voluntas)
  • 廣江 深さん (@hiroe_orz17)
  • 山本和彦さん (@kazu_yamamoto)
  • 力武健次さん (@jj1bdx)
  • 若山史郎さん (@r_rudi)

Special Thanks

  • 古瀬 淳さん (@camloeba) :型について

オーム社

  • 鹿野桂一郎さん (@golden_lucky)
  • 高尾智絵さん

皆様からのレビュー(随時追加)

*1:原著者のFredに翻訳の許可をもらうメールを送ったのが2010年12月22日でした。

Go Conference 2014 springを開催しました #gocon

はじめに

こんにちは、Go界のユアン・マクレガーです。5月最終日にリクルートライフスタイルさんの会場をお借りしてGo Conference 2014 springを開催してきました。

前回は「新幹線を使って参加してくれた人もいました」と書いていましたが、今回は僕が呼んだBrad Fitzpatrik以外に、国内でも飛行機を使って福岡から来て発表してくれた @monochromegane や、なんとシドニーからDave Cheneyが参加してくれたりと、本当に規模の大きいイベントになってきたなと実感しています。

発表者スライド(発表順)

「あとで」となっているものは公開され次第追加します。

togetter

参加できなかった方もこちらにまとめがありますので、眺めつつ資料を見ていただければと思います。

まとめてくださった岩田さん(@qt_luigi)ありがとうございました!

運営・スタッフの皆様ありがとうございました!

今回のGoConは開催を決めてから当日までがほとんど日にちがなく、かつ自分がかなり立て込んでいたこともあって、正直自分の中では開催が危ぶまれていたのですが、蓋を開けてみれば、会場提供をしてくださったリクルートライフスタイルの荒川さんを始めとする皆様のご協力や、スタッフ参加で申し込んでくださった皆様のお陰で、非常にスムーズな運営が出来ました。

懇親会に関しても、@Jxckさんが色々と手配してくれたこともあり、会場と同じ建物の素晴らしい眺めのカフェで行うことが出来ました。

チュートリアルに関しても当日に無茶ぶりをしてくれたにも関わらず、快く引き受けてくれて、多くの参加者が楽しかったと言ってくれるようなチュートリアルをしてくれた@tenntennさん、本当に助かりました。

次回以降

何も決まっていませんが、もうちょっとコミュニティベースの開催にできたらいいなと思っています。また国内外の他のGoコミュニティとももっと交流を深められるような会にできればいいなとも思っています。

ymsr送別会で山城さんと酒飲んできた

はじめに

技術的でもなんでもない、俺がymsr送別会に行ってきたという話。区切りを付けるために書く。

俺と山城さんが初めて会った日

前からTwitterではフォローしてたし、もしかするとどこかの勉強会で会ってるはずなんだけど、ちゃんと面と向かって話したのはjava-ja温泉だったと思う。1日目の夕食の時間に、芳泉閣の例のご飯部屋で自己紹介タイムになった時に、幹事だった山城さんが「では自己紹介で、名前、id、何をやりたいか、そして童貞かどうかを話してください」と高らかに合図をして、のっけからやばいと思った記憶がある。

それから

リアルに会ったのは、他のjava-ja勢から比べたらほんとに少ないし、飲み会なんかでは自分も酒飲んでバグってたから、正直何話したか細かい内容は結構覚えてない。ただ、ついさっきまでゲスい話をしていた10秒後に真面目にエンジニアの生き方みたいな話をしたりしていたのは覚えていて、そのギャップを楽しみつつ、何話しても気さくに話せる彼の人柄はいつも気持ちいいなと思って、毎回楽しかったことは覚えている。

知らせを受けた日

「はー、今年もjava-ja忘年会だなー」となんとなく考えていたら昼間にチャットで「亡くなったらしい」と連絡を受けて、「ちょっとマジで何言ってるかわかんないんすけど」って状態でその日は上の空だった。 その日の直前にこんなこと言ってるし、知らせは多分現実なんだろうと思いつつも、これは悪いフリで、java-ja忘年会当日にはなにかネタをやらかしてくれるんだろうと思っていたりもした。

昨日の送別会で俺の中でも山城は死んだ

@ryushi がLTで「今日俺の中で山城は死んだ」と言った。それ以外でも皆口々に「死んだ」と言った。わざわざ口に出すまでもないことなはずなのに、皆確認するように言った。「亡くなった」と言わなかったのは、そう表現することで少しでも遠くに行ってしまったという言い方をしたくなかったのだろう。俺はそうだ。

いつでもインターネットで "yamashiro" で検索すれば彼がそこにいるし、いつまでも彼の思い出を振り返ることが出来る。

山城は死んだが、yamashiroはこれからもそこにいる。

山城さん、楽しい飲み会をありがとう

飲み会が大好きだった山城さんらしい送別会だった。幹事をしてくれたのは、 @ryushi や @yoshiori をはじめとする本当に親しい人達だったが、これだけの人が集まったのはやはり @yamashiro だからだろう。

「楽しい」と言ったら送別会らしくないかもしれないし、もしかしたら失礼だと思う人がいるかもしれないがが、あの雰囲気はまさしく @yamashiro が周りの人達と築いてきたもので、だからこそ感謝して伝えたい。

山城さん、最後に楽しい飲み会の幹事をしてくれてありがとう。

また今度

最後に山城さんと会って挨拶した時に山城さんが「最近Goに興味があるんで、また今度飲みながら話しましょう」と言っていた。もうそれ何年後になるかわからないじゃないですか。そっちに行くまでにGoでなんか作っててくださいよ。

会場は、名幹事にお任せします。それではまた来世。

YAMAGUCHI::weblogの2013年を振り返る

はじめに

こんにちは、Go界のティム・バートンです。今年もついにあと1日となりましたが、みなさんいかがお過ごしでしょうか。ところで私事ですが本日誕生日を迎えました。

関連エントリ

今年で1年の振り返りエントリも7年目になるようです。年を取るわけですね。

昨年立てた目標

まずは去年の年末に立てた2013年の目標を振り返ってみます。

  • 仕事頑張る(YouTube APIとか)
  • Go言語の普及
  • 地を足につけた技術力の向上

仕事頑張る

まずこの仕事については、大きな変化がありました。2011年4月にGoogleに入社以来、YouTubeのTechnical Account Managerという職種に就いていました。簡単に言えば、YouTubeの大手パートナー向けの技術営業という形ですが、その幅は非常に広く、データ解析、戦略立案補助から始まり、Business Developmentチームとの連携、ライブ配信サポート、技術系の質問に対する回答など、範囲は営業から技術までカバーする、社内でも最も刺激的な職種の1つです。この職種では面白い経験も出来、例えばライブ配信サポートでオールナイトのクラブイベントに行ったり、はたまたロケットの打ち上げで種子島に行ったりということがありました。

上記の業務を行う傍ら、この職種に就いてから、YouTube APIの連携などを行うサイト制作者あるいはデバイスメーカーの支援も行っていたのですが、その経験やこれまでのOSSコミュニティでの活動を評価してもらい、今年の10月からDeveloper Relationsチームに異動しました。これまではまず「売上」を念頭に仕事をしていて、部署も技術職と言えど営業ラインの部署だったわけですが、今度は完全に技術系の部署に移動し、いかにしてYouTube APIが世の中の開発者の助けになるかを考え、そのサポートをする職種となりました。

これまでは20%でAPIの普及を行っていたわけですが、今後は積極的に広めていきたいと思います!このエントリを見たみなさんもぜひ年始のお休みにYouTube APIで遊んでみてください!

ところで、僕が抜けてしまったYouTube Technical Account Managerですが、絶賛新メンバー募集中です。もし興味がある方がいたらお気軽に僕までご連絡ください。

Go言語の普及

Go言語の普及に関しては、今年は @Jxck_、@tenntenn、@nuki_pon を始め、多くのGoコミュニティの方々と一緒にGo Conferenceやその他イベントを開催出来、またその内容も徐々に濃くなっていったことを実感出来ました。Go普及の一助になれたのではないかと思っています。

来年も引き続き日本でのGo普及に努めますが、それだけでなく、Goコミュニティが非常に活発な近隣諸国のコミュニティとの橋渡しが出来ればなと思っています。来年はGoの初めてのグローバルカンファレンスであるGopherConもありますので、目が離せません。ʕ ◔ϖ◔ʔ Go~

地を足につけた技術力の向上

これは評価が難しいところではあるんですが、部署異動をしてから社内での位置づけも完全に技術者となったので、早速色々と叩きこまれています。社内で必要になる技術というのがなかなかおもしろくて、この3ヶ月は楽しく過ごせました。またiOS開発を初めてやってみたわけですが、Objective-Cのキモさに最初は戸惑いつつも、初めてのことを学ぶ楽しさを久々に味わうことができました。来年も今の延長で多くのことに手を出さずに集中していきたいですね。

ymotongpooの2013年

引越し

8月に引っ越しました。上京してきてからこれまでに4回の引越をしているわけですが、その中で東京都北区に10年も住んでいたことに気づき、職場も転職してから通勤しづらくなったことから、思い切って渋谷区に引っ越しました。

これまで住んできた北区は東京23区内にありながら、のんびりとしたところで、田舎出身の自分には性があっていました。最初の2年は王子駅周辺で、後の8年は駒込駅周辺で過ごしたわけですが、川沿いの公園や、六義園、ちょっと南に行けば谷根千があるし、上野公園も近く、決して華やかではない場所でしたが、うるさくない良い土地でした。一方で、勤務先は都心にあり、特に転職後は六本木に勤務となったので、どうしても駒込からだと乗り継ぎが悪く、地図上の距離の割には不便な通勤を強いられる場所でした。

転職して2年半経ったので、頃合いだと思って引越しをしましたが、引っ越してみると、通勤時間を始め、生活に大きな変化があり、気持ちにも少なからず影響がありました。よく「人間が変わる方法には、時間配分を変える、住む場所を変える、付き合う人を変えるの3つしかない」と言いますが、住む場所が変わったことによって、自分の生活の優先度にも影響が出始め、仕事をする上では良い影響が起きたように思います。

プロジェクター+スピーカー

引越してから最も生活に影響を与えたのは、プロジェクターとスピーカーです。新しい場所に引越して、部屋に多少の空間が出来たので、前々から欲しかったプロジェクターを導入したわけですが、これで観る映画は本当に良いものですね。これまでは24インチのPCモニターで観ていたわけですが、100インチ強のサイズで観られる環境を作ると映像の見え方が変わってきました。来年は映画100本鑑賞を目標に、沢山の名画を観ようと思います。

来年に向けて

  • YouTube(のAPI)の人として認知してもらえるようになる
  • Go言語の更なる普及
  • 翻訳本出すぞ
  • カメラの機能をひと通り使いこなす

2014年は今の部署に異動してから、いよいよ本格的に稼働する年となります。仕事においては、APACでのYouTube APIを用いた多くの開発を活性化する一端を担えるよう頑張ります。まずは皆さんにYouTube APIの人として認識してもらうところから。

そしてGo言語の普及に関しては、これまでどおりオンライン・コミュニティでの情報交換や発信、そしてイベントを通じてのGoユーザの交流を高められればと思っています。

2年前から出す出すと言っていた翻訳本も、いい加減区切りを付けたいので今年こそ出します!

またプライベートでは、最近木工やカメラを始めたこともあり、趣味の時間を大切にしたいと思っています。会社ではチーム内で僕一人だけがUS外のオフィスにいることもあり、時差の都合でオンオフが切り替えづらい状況になったわけですが、そういう中でこの3ヶ月はだらだらと仕事をしてしまった様に感じています。来年は集中をきっぱり切り替えられるような1年間にしようと思います。