株式会社クリアコード > ククログ

ククログ

2016年にやりたいことと2015年のまとめ

年のはじめなので、2016年にやりたいことと2015年のまとめを書きます。

2016年にやりたいこと

まず、今年やりたいことです。

設立当時からクリアコードが大事にしていることは次の2つです。

継続的にフリーソフトウェアの考えを実践すること
ソフトウェアを継続して改良してくいくためにクリアなコードを書くこと

これらを実現するために、2015年のはじめには次のことをやりたいとしていました。

世の中にフリーソフトウェアの開発に関わる人を増やす
世の中によいコードを書く人を増やす

前者の「世の中にフリーソフトウェアの開発に関わる人を増やす」に関しては、SEゼミでOSS Hack 4 Beginners・OSS Hack Weekendというワークショップを開催することで実践しました。これらはフリーソフトウェアの開発を体験するワークショップでした。

フリーソフトウェアの開発を通じて関わる人を増やすという取り組みはあまりうまくできませんでした。サポートはしていましたが、まわりの人たちを巻き込むという点ではあまり成果はありませんでした。ただ、まったくなかったわけではなく、数人くらいは関わる人が増えました。

「Groongaで学ぶ全文検索」という定期的にユーザーとイベントをはじめたのですが、この機会も活用すればより成果があがるかもしれません。

後者の「世の中によいコードを書く人を増やす」に関しては、schooで2回目のリーダブルコードのWeb授業を開催・「リーダブルコードワークショップ」の開催・WEB+DB PRESSの新人向け特集「1年目から身につけたい！チーム開発6つの心得」の執筆という形で実践しました。実践した内容はわかりやすいのですが、それらでどの程度効果があったかを測れなかったので、成果をどう評価するかに関しては難しいところです。リーダブルコードワークショップのように直接対象者と会う機会があるものに関してはフィードバックをもらえました。フィードバック結果からは成果があったと言えます。

ブログにクリアなコードを書く方法をまとめる活動は例年通り実践していました。ただ、今年は少なかったです。今年は次のことについてまとめましたが、これもどれだけの人の役に立ったかを測る方法がないため成果があったかを評価するのは難しいです。

2016年は2015年にやりたかった次のことを強化していきます。

世の中にフリーソフトウェアの開発に関わる人を増やす
世の中によいコードを書く人を増やす

前者に関してはOSS Gateの活動と日々のフリーソフトウェアの開発を通じて実現していきます。

後者に関してはリーダブルコードワークショップは引き続き実施し、ブログに知見を言語化するという点は2015年よりも強化していきます。

2015年のまとめ

それでは、2015年のことを月ごとにふりかえります。

1月

Heroku Meetup #13 新年会で「HerokuでGroonga」と題してHerokuでGroongaを使う方法を紹介しました。この方法でHerokuでGroongaを利用している方はいるでしょうか。

PbuilderとCowbuilderの性能比較はdebパッケージ作成時間を計測した結果をまとめました。debパッケージをどうやって作成するかを検討する際に参考にしてください。

CROSS 2015 全文検索エンジン群雄割拠〜あなたが使うべきはどれだ！〜でGroongaを紹介しました。Groonga以外はすべてJavaベースの全文検索エンジンでしたが、会場にはJavaベースの全文検索エンジンを使っているユーザーと同じくらいGroonga関連プロダクトを使っているユーザーもいました。

2月

Effective Rubyという本を紹介しました。著者の主張のうち気に入らないものがあるという観点から紹介しました。

mrubyのVMのデバッグ方法をまとめました。久しぶりにデバッグしようとしたら忘れていたからです。

クリアなコードの書き方として専用の機能を使う書き方を紹介しました。初級者向けの話です。

3月

Debianのバグ報告ツールであるreportbugを使用したバグ報告の具体的な手順をまとめました。

「実践リーダブルコード」というワークショップを開催しました。「読む人が読みやすいならリーダブル」という標語を思いついたのはこのときです。

Emacs上で動くメールクライアントであるMewでHTMLで整形されたコミットメールを読む方法をまとめました。クリアなコードを書くにあたり、コミットを読むということは大事なことです。それを支援する方法の1つです。なお、クリアコードでMewでメールを読み書きしている人は1人しかいません。

新しくクリアコードに入社した横山さんがクリアコードに入社した理由をまとめました。それはフリーソフトウェアに関連することを仕事にするためです。

Software Design 4月号にDebianパッケージを追加する流れを寄稿しました。

クリアなコードの書き方としてマッチしすぎる正規表現に気をつけるとよいということを紹介しました。初心者向けの話です。

Gitでコミットメールを配信する方法をまとめました。クリアコードで使っている方法です。

起動時にパスワード認証が完了するまでUIを非表示にする、というThunderbirdの法人向けカスタマイズ事例を紹介しました。

4月

schooで2回目のリーダブルコードのWeb授業を開催しました。質疑応答でいい回答をしたものがあったので別途まとめました。「新人プログラマーにどうやってリーダブルコードについて伝えるか」についての回答です。回答は「自分がリーダブルコードを書くことによりリーダブルコードを伝える。本を読んでおけとも言わないし、そもそも『リーダブルコード』という用語も使わない。」でした。余談ですが、schooで授業していましたよね？と声をかけられることが数回ありました。

WEB+DB PRESS Vol.86の新人向け特集「1年目から身につけたい！チーム開発6つの心得」を執筆しました。

Markdownで書いたテキストをPDFに変換して納品用ドキュメントを作成する方法をまとめました。

AppVeyorというWindows用CIサービスの使い方をまとめました。

5月

公式のWindows版PostgreSQLパッケージ用の拡張機能のビルドシステムの作り方をまとめました。PostgreSQLのソースコードなしでビルドする方法です。

pg_shardとPGroongaを使ったレプリケーション対応の高速日本語全文検索可能なPostgreSQLクラスターの作り方をまとめました。

PostgreSQLアンカンファレンス＠東京（2015/5/30）でPostgreSQLで日本語全文検索する方法を紹介しました。LIKEとpg_bigmとPGroongaについて紹介しました。

6月

Red Hat系のディストリビューション用のinitrdカスタマイズツールであるDracutを紹介しました。

複数のレイアウトのキーボードを接続しながらインプットメソッドフレームワークであるFcitxを使うときに便利なツールを紹介しました。

2014年に引き続き、SEゼミの一部として学生向けにリーダブルコード勉強会を開催しました。メンターが非常に充実した勉強会となり、参加した学生・メンターの満足度も高かったです。

ConoHa上にDroongaクラスターを設置する手順をまとめました。

複数人のGitHub上のアクティビティをタイムラインで表示するためのツールfluent-plugin-github-activitiesとSharetaryを紹介しました。続編もあります。

Firefox 29で削除されたセキュリティポリシー機能と、その代替手段を紹介しました。

OverlayFSの一種であるunionfs-fuseを使う方法を紹介しました。

Groongaがキャッシュしている内容を確認する方法を紹介しました。

7月

WerckerというCIサービスのDockerバックエンドを使う方法を紹介しました。続編もあります。

SEゼミの一部としてOSS Hack 4 BeginnersというOSSの開発に参加したことがない学生向けのイベントを開催しました。このイベントもメンターが非常に充実していました。このイベントが後で登場する「OSS Gate」につながります。

AngularJSのユニットテストでつまづいた点をまとめました。

CutterというテスティングフレームワークでマルチメディアフレームワークGStreamerをどのように使っているかを紹介しました。

SEゼミのイベントがすべて終わったのでSEゼミのコンテンツ作成と進行をしてわかったことをまとめました。

マルチメディアフレームワークGStreamer 0.10から1.0へ移行する方法を紹介しました。

8月

ピクシブさんと永和システムマネジメントさん向けにリーダブルコードワークショップを開催しました。「チームメンバーのリーダブルコードを見つけて共有」することを体験するワークショップです。SEゼミでの学生向けのリーダブルコード勉強会の内容を社会人向けにアレンジしたものです。

RedPenという校正ツールの拡張方法を紹介しました。

進捗共有に必要な情報として目的、期日、現状、今後があるということをまとめました。

9月

Firefoxの独自ビルド方法を紹介しました。続編もあります。

Visual Studioなしでmingw-w64だけでWindowsのイベントログに出力する機能を実現する方法を紹介しました。

クリアコードとフリーソフトウェアとビジネスについてまとめました。

PostgreSQLで日本語全文検索を実現する拡張機能であるPGroongaがどのようにJSON検索を実装しているかを説明しました。

ブログにまとめられていませんが、12月は他にも、OSS Gateの立ち上げ・ジャストシステムさん向けにリーダブルコードワークショップを実施をしていました。早いところまとめておきたいところです。

まとめ

2016年にやりたいことは2015年にやりたかったことをもっとがんばるということであると宣言しました。

2015年の活動もまとめました。

2015年は発表はGroonga関係のことが多かったです。外向けの活動は発表だけでなくワークショップの実施、雑誌への寄稿などこれまでとは違った形での活動をしてきました。

ブログの内容は自分たちの知見を言語化したものよりも、ツール紹介・機能紹介の方が多かったです。2016年は知見の言語化を強化していきたいです。

この記事の続き

2017-01-05: 2017年にやりたいことと2016年のまとめ

2016-01-06

OSS Gateワークショップ2016-01-30開催のおしらせ

2015年10月に「OSS Gate」という取り組みを開始しました。

OSS Gateとは「OSS開発に参加する人を増やす取り組み」です。OSS開発に参加する人を増やすためにOSS Gateでは次の知見をベースにしています。

OSS開発に未参加の人は参加方法がわからないだけであり、参加方法がわかればOSS開発に参加できる

この知見を活かしたワークショップを2016年1月30日（土）に開催します。それがOSS Gateワークショップ2016-01-30です。

以下、ワークショップについて説明するので、次の項目に該当する方はぜひお申し込みください。また、まわりに該当する方がいる人はぜひこのワークショップを教えてあげてください。

OSSの開発に参加したいけどまだ参加したことがない
OSSの開発に参加したことはあるけどまだ自信がない
すでにOSSの開発に参加していて↑のような人たちをサポートしたい

ワークショップの内容

このワークショップは「OSSの開発に参加する」を実際に体験するワークショップです。実際に体験することで「OSSの開発に参加する方法」がわかり、その後はワークショップ形式でのサポートがなくてもOSSの開発に参加できるようになる、という流れを目指しています。

そのために、次のような流れで実際にOSSの開発に参加します。

開発対象のOSSを1つ決める
↑をREADMEなどのドキュメントを参照しながら実際に動かしてみる
多くの場合、↑の作業の中でうまくいかないところ・わかりにくいところがあるので、それを開発対象のOSSにフィードバックする

短くまとめると「ユーザーとして使って気になったところをフィードバック」です。

OSSの開発に参加していない人でもユーザーとしては使っています。それに「気になったところをフィードバック」というアクションを加えているだけです。

いつもならうまく動かなかったときに「Twitterにつぶやく」としているところを、「それOSSの開発に参加するチャンスだよ！こうやればいいんだよ！」と一緒にやってみる、ということです。

さらに、開発対象のOSSには参加者をサポートする人（メンター）が開発に参加しているOSSを選びます。開発に参加している人がその場にいるので「こんなフィードバックで大丈夫かな。。。」と心配な人でも安心です。「大丈夫だよ！」と後押ししてくれます。

どうですか？今までOSSの開発に参加したことがなくてもこのワークショップでOSSの開発に参加できそうな気がしてきませんか？

なお、自分はこのOSSの開発に参加したい！という人はそのOSSを開発対象のOSSにしたり、時間が余った人はフィードバックするだけではなく改善案をパッチにしよう、既存のバグ報告が自分の環境でも再現するか確認してフィードバックしよう、など参加者にあわせてこの内容をカスタマイズする予定です。そのため、OSSの開発に参加したことはあるけどまだ自信はない、という方もお待ちしています。

メンター募集

このワークショップではOSSの開発に参加したい人をサポートする人「メンター」も募集しています。OSSの開発に参加する人を増やしたい人はぜひ協力してください。

ワークショップの内容は前述の通り簡単なものです。「やってみようよ！難しくないから！」を体験するためだからです。そのため、メンターはすごいスキルや経験がある必要はありません。OSSの開発に参加した経験があれば大丈夫です。

ワークショップでのメンターの役割は「一緒にやってくれる人」です。「こういうときはこうするのが正解だ」というような完璧な答えを参加者に教えることは求めていません。OSSはさまざまなので完璧な答えなんてありませんし。

そうではなく、参加者がはじめてのフィードバックをしていて不安なときに一緒に作業してください。そのとき、「自分はこう考えてこうやっているよ」とか「自分がフィードバックをもらうときはこうだとうれしいんだよね」とか伝えながら一緒に作業してください。経験者の考えや受け取る側の考えは不安を軽減することに役立つはずです。

なお、メンターは自分がまだ開発に参加していないOSSでもサポートできるのかと不安になる必要はありません。このワークショップは、まだどのOSSの開発にも参加していない人に「難しくないよ！やってみようよ！」ということを体験してもらうワークショップです。メンターの人だって大丈夫です。「難しくないよ！やってみようよ！」

開催の背景

このワークショップを開催する背景についても少し触れておきます。

2015年10月に「OSS Gate」という取り組みを開始したあと、賛同してくれた人たちで、この取り組みで成果をだすにはどうしたらよいかということを話し合いました。それが2015年12月15日に開催したOSS Gate を立ち上げようというイベントです。このときの内容はGitHubのoss-gate/meetupリポジトリーの2015-12-15/ディレクトリー以下に記録してあります。

この話し合いには、OSS GateをはじめるきっかけとなったOSS Hack 4 Beginners・OSS Hack Weekendというイベントに参加していない人も多数いました。イベントに参加していない人たちにはOSS Gateがベースとしている「OSS開発に未参加の人は参加方法がわからないだけであり、参加方法がわかればOSS開発に参加できる」という知見がまだ実感としてピンときていないようでした。そのため、一度、OSS Hack 4 Beginners・OSS Hack Weekend相当のイベントを体験することにしました。知見がピンときていれば、話し合いで考えたアイディアをよりうまく実現したり、新しいもっとよいアイディアを思いつくなど今後のOSS Gateの活動にプラスに作用しそうだからです。

これが今回のワークショップを実施することにした背景です。

参加者にとっては「OSSの開発に参加するきっかけ」となるためのワークショップですが、OSS Gateを推進する人たちにとっては「これからOSS Gateをうまく進めるためのフィードバックを得る機会」としてのワークショップでもあります。

OSS Gateに賛同してくれる方で都合のあう方はぜひご参加ください。そして、このワークショップで得たフィードバックを今後の活動に活かしていきましょう。

まとめ

「OSS開発に参加する人を増やす取り組み」であるOSS Gateの1回目のワークショップ開催について告知しました。参加者・メンターともに募集しています。以下のイベントページから応募してください。

OSS Gateワークショップ2016-01-30

まわりに興味のありそうな人を知っている人はぜひ教えてあげてください。

この記事の続き

2016-02-05: OSS Gateワークショップ2016-01-30を開催 #oss_gate

2016-01-07

Groongaプラグイン自作入門 - コマンド詳細編

はじめに

Groongaのプラグイン自作入門では、プラグインの雛形を作成できるgrnplumというgemを使って実際に「hi」と出力するだけのgreetコマンドを作成しました。今回は、このgreetコマンドを拡張しながら、コマンドについてもう少しだけ詳しくみていきます。具体的には次の2つのことについてどうやったらいいのか、というのを説明します。

パラメータを受けとるには
結果を返すには

パラメータを受けとるには

コマンドでは、通常何らかのパラメータを受け取ってその挙動をカスタマイズできるようにします。

これを実現するには、GRN_PLUGIN_REGISTERで、greetコマンドが受けつけるパラメータを宣言します。例えば、fooとbarとbazという3つのパラメータを受けとることができるようにするには、次のようにgrn_plugin_expr_var_initを呼びだして変数varsを初期化し、grn_plugin_command_createの引数として渡します。

grn_rc
GRN_PLUGIN_REGISTER(grn_ctx *ctx)
{
  grn_expr_var vars[3];

  grn_plugin_expr_var_init(ctx, &vars[0], "foo", -1);
  grn_plugin_expr_var_init(ctx, &vars[1], "bar", -1);
  grn_plugin_expr_var_init(ctx, &vars[2], "baz", -1);
  grn_plugin_command_create(ctx, "greet", -1, command_greet, 3, vars);
  ...

コマンドを実装するcommand_greetでは、grn_plugin_proc_get_varを使って値を受けとります。

static grn_obj *
command_greet(grn_ctx *ctx, int nargs, grn_obj **args, grn_user_data *user_data)
{
  grn_obj *var;
  var = grn_plugin_proc_get_var(ctx, user_data, "foo", -1);
  if (GRN_TEXT_LEN(var) > 0) {
    /* fooが指定されているとき */
  }
}

例えば、http://localhost:10041/d/greet?foo=1というURL経由でGroonga HTTPサーバーへとアクセスしたとき、GRN_TEXT_VALUEを使って変数varの値を取りだすと1が得られます。

結果を返すには

コマンドの目的とする処理が終わったら、何らかの整形した結果を返すことでしょう。

Groongaでは、出力形式にあるように

[HEADER, BODY]

HEADER部分と、BODY部分からなる配列で構成されています。前回の記事では、BODY部分が"hi"だったわけです。

これをもう少し複雑な構造をもった形で出力するにはどうすればいいのでしょうか。

BODY部分では、selectコマンドのようにN件のデータを配列[...]で表現するものと、statusコマンドのように、ハッシュ{...}で表現するものとがあります。それぞれどのようにしたらいいか説明します。

結果を配列で返すには

配列で結果を返すには、次のようにgrn_output_array_openとgrn_ctx_output_array_closeをペアで使います。

grn_ctx_output_array_open(ctx, "name", 2);
grn_ctx_output_int32(ctx, 1);
grn_ctx_output_int32(ctx, 2);
grn_ctx_output_array_close(ctx);

grn_ctx_output_array_openの第3引数は何個の要素をもつかというのを指定します。上記の例では、int32型の値「1」と「2」を出力しているので、BODY部分の結果は[1,2]となります。

結果をハッシュで返すには

ハッシュで結果を返すには、次のようにgrn_output_map_openとgrn_output_map_closeをペアで使います。

grn_ctx_output_map_open(ctx, "name", 2);
grn_ctx_output_cstr(ctx, "key1");
grn_ctx_output_int32(ctx, 1);
grn_ctx_output_cstr(ctx, "key2");
grn_ctx_output_int32(ctx, 2);
grn_ctx_output_map_close(ctx);

grn_output_map_openの第3引数も何個の要素をもつかというのを指定します。上記の例では、「key1」の値が「1」、「key2」の値が「2」であるハッシュを出力しているので、BODY部分の結果は{"key1":1, "key2":2}となります。

まとめ

今回は、Groongaプラグイン自作入門として、コマンドの実装をもう少し詳しく紹介してみました。 Groongaの機能拡張に興味がある人は参考にしてみてください。

2016-01-15

ワークライフバランス推進の取り組み

クリアコードでは社員全員が働きやすい環境をつくることによって、全ての社員がその能力を十分に発揮できるようにすることを目的として、10月からワークライフバランスの推進に取り組んでいます。今回はその取り組みを紹介します。

なお、この記事は取り組みの様子の社外への紹介だけでなく、クリアコード社員に向けての周知も兼ねています。

ワークライフバランスに取り組むきっかけ

クリアコードは創業から今年で10年となり、社員のライフステージも変化してきています。設立当初は一人暮らしの社員がほとんどでしたが、結婚して共働きをしている社員や、子育て中の社員が増えてきました。

そのような変化にともない、家事や子育てと仕事を両立したい、あるいは自己啓発の時間を確保したいといった声が聞かれるようになりました。以前からフレックスタイム制の導入、残業時間削減、有給休暇の100%取得などを行ってきましたが、家族と過ごす時間を増やす、自己啓発の機会を作るためには別の施策の必要性が増してきました。そこで現在、東京都の中小企業ワークライフバランス推進助成金という制度を活用して、ワークライフバランスの推進に取り組んでいます。

ワークライフバランス実態調査

ワークライフバランス推進の最初の取り組みとして、社員がワークライフバランスについてどのように考えているのか、その実態を調査することにしました。新宿区のワーク・ライフ・バランスに関する企業および従業員の意識・実態調査報告書にある「ワーク・ライフ・バランスに関する従業員の意識・実態調査アンケート」調査票を使って社内アンケートを実施した結果からは、次の課題が見えてきました。

就業規則があまり理解されていない
柔軟な働き方を推進するための法制度について認知されていない
仕事とプラベートの調和を図りたいが、実際は仕事を優先している（ただしワークライフバランスはまあまあ取れているという人がほとんど）
時間短縮勤務と在宅勤務を望む人が多い

就業規則があまり理解されていない

アンケートでは会社の制度として様々なワークライフバランス支援策の有無と利用の意思についての質問がありましたが、支援策の有無については回答がバラバラであったことから、就業規則等が正しく認識されていないことがわかりました。

なお、アンケートで取り上げた各制度のクリアコードにおける有無は以下のとおりです。

Q 法定を超える育児休業、介護休業制度: A ありません。法定通りの育児介護休業規程となっています。利用実績はありません。
Q 短時間勤務制度: A あります。育児介護のため1日6時間勤務にする制度があります。利用実績はありません。
Q フレックス勤務制度: A あります。2008年に導入し、すべての社員が利用しています。
Q 始業・終業時刻の繰り上げ・繰り下げ: A ありません。フレックス勤務制度を活用することで同等の効果が期待できます。
Q 残業の免除: A あります。育児期間中の残業を免除する制度があります。ただし、最近は全社員がほぼ残業0となっており、申請する必要がありません。
Q 残業時間の削減: A あります。就業規則で定めたものではありませんが、毎月残業時間が0になるように全社で取り組んでいます。残業をした社員には、フレックス勤務制度を活用して、早帰りを推奨しています。
Q 転勤への配慮: A ありません。ただし、就業規則ではそのような規定はありませんが、これまでに会社都合で転居を伴なう転勤を命じたことはありません。（この設問は、全国に事業所があるような会社内での転勤を想定したものです。）
Q 勤務地限定・選択制度: A ありません。ただし、就業規則ではそのような規定はありませんが、勤務地は基本クリアコード本社であり、勤務地を限定する必要はありません。（この設問は、全国に事業所があるような会社内での転勤を想定したものです。）
Q 再雇用制度: A ありません。ただし、一度クリアコードを辞めた人を再び迎え入れるためだけの特別な制度は設けていないということで、辞めた人を迎え入れないというわけではありません。
Q メンタルヘルスの相談窓口の設置: A ありません。ただし、メンタルヘルスの不調についての相談に応えることはできませんが、治療のために通院しやすいよう勤務時間の変更や休暇を取得しやくすることはできます。

就業規則は社員であればRedmine上で誰でも見られるようになっています。クリアコードの社員の皆さんは、ぜひこの機会に就業規則に目を通してみてください。また就業規則の疑問点や、改善のアイデアがあれば、是非聞かせて下さい。

まとめ

今回はクリアコードにおけるワークライフバランス推進の取り組みについて紹介しました。就業規則から自社のワークライフバランスへの取組状況が見えてくると思います。読者の皆さんも、久しぶりに就業規則を読んでみてはいかがでしょうか。今回扱えなかった課題への対応はまたの機会に紹介します。

この記事の続き

2017-01-05: 2017年にやりたいことと2016年のまとめ

2016-01-20

APIデザインケーススタディ

2015年12月に技術評論社から「APIデザインケーススタディ――Rubyの実例から学ぶ。問題に即したデザインと普遍の考え方」というライブラリー作成者（=APIを設計する人）向けの本が出版されました。

APIデザインケーススタディ ~Rubyの実例から学ぶ。問題に即したデザインと普遍の考え方 (WEB+DB PRESS plus)
田中哲
技術評論社
￥ 3,002

内容

本書は「事例紹介」→「その事例から得られる、APIを作るときの方針」という流れを繰り返します。

「APIを作るときの方針」では「既存の知識とあわせると使いやすいAPIになる」や「変な使い方をできないようにすると使いやすいAPIになる」、「ユースケースに合わせると使いやすいAPIになる」といったことを挙げます。「事例紹介」の後なので、「方針はわかったけど具体的にどうすればいいの！？」となりにくいです。

全編を通して「事例紹介」→「方針紹介」という一貫した流れをとっていることが理解しやすさを助けています。この理解しやすさを助ける一貫性は、著者の「使いやすいAPIにするにはどうしたらよいか」という知見からきているのかもしれません。

話が逸れてアレですが、リファレンスマニュアルや仕様書など（たぶん論文も）の正しく伝えることが重要な技術文書は、小説や感想文などの読み物の文書と違い、「同じことは同じように書く」ことが効果的です。

たとえば、「関数AはBを受け取りCを返します」と説明するなら、他の関数も「関数xはyを受け取りzを返します」と書くということです。「yを渡されたらzを戻すのが関数xです」というように書き方を変えないということです。同じように書いていれば同じことだということがすぐにわかるからです。（読み物の文書は何度も同じように書くと飽きることがあるので同じようなことを違う言い回しで書いたりします。）

本書は一貫した流れになっているので、読み進めるうちにパターンがわかって理解しやすくなっていくでしょう。

本書の多くは著者が実際にやったことを事例として紹介しています。読むと、「たしかにこの事例だとこういうAPIがよさそうだなぁ」という気持ちになるでしょう。たまに「ここまでやるのか！」という気持ちになることもあるでしょう。自分もそこまでやるかはケースバイケースでしょうが、ここまでやられると「そのAPIがよさそう」という気持ちになるというのは知っておくと役に立つでしょう。役に立つのは、自分がだれかにAPIを提案したりだれかが使うAPIを作ったりするときです。

なお、「さまざまなタイムゾーン」というコラムを読むと「うん！わかった！わかったから！」という気持ちになれます。

最後に、本書の日本語の文ですが、もしかしたら、読む人によっては助詞の使い方で読むときにつまる人がいるかもしれません。たとえば、「このときに読み出したデータは捨てることはできません。」（19ページ。「1.02 feof関数とIO#eof?メソッド」）が気になるならつまるかもしれません。（気になる人は「このときに読み出したデータを捨てることはできません。」か「このときに読み出したデータは捨てられません。」ならどうでしょうか。）

まとめ

ライブラリー作成者（=APIを設計する人）向けの本、「APIデザインケーススタディ――Rubyの実例から学ぶ。問題に即したデザインと普遍の考え方」を紹介しました。ライブラリーを作っている人は読んでみてはいかがでしょうか？ライブラリーを作っていない人は読み物として読んでも案外おもしろいかもしれません。話題が多岐にわたっているので「へぇ、こんな世界があるんだぁ」という気持ちになれます。