年のはじめなので、2016年にやりたいことと2015年のまとめを書きます。
まず、今年やりたいことです。
設立当時からクリアコードが大事にしていることは次の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年のことを月ごとにふりかえります。
Heroku Meetup #13 新年会で「HerokuでGroonga」と題してHerokuでGroongaを使う方法を紹介しました。この方法でHerokuでGroongaを利用している方はいるでしょうか。
PbuilderとCowbuilderの性能比較はdebパッケージ作成時間を計測した結果をまとめました。debパッケージをどうやって作成するかを検討する際に参考にしてください。
CROSS 2015 全文検索エンジン群雄割拠〜あなたが使うべきはどれだ!〜でGroongaを紹介しました。Groonga以外はすべてJavaベースの全文検索エンジンでしたが、会場にはJavaベースの全文検索エンジンを使っているユーザーと同じくらいGroonga関連プロダクトを使っているユーザーもいました。
Effective Rubyという本を紹介しました。著者の主張のうち気に入らないものがあるという観点から紹介しました。
mrubyのVMのデバッグ方法をまとめました。久しぶりにデバッグしようとしたら忘れていたからです。
クリアなコードの書き方として専用の機能を使う書き方を紹介しました。初級者向けの話です。
Debianのバグ報告ツールであるreportbugを使用したバグ報告の具体的な手順をまとめました。
「実践リーダブルコード」というワークショップを開催しました。「読む人が読みやすいならリーダブル」という標語を思いついたのはこのときです。
Emacs上で動くメールクライアントであるMewでHTMLで整形されたコミットメールを読む方法をまとめました。クリアなコードを書くにあたり、コミットを読むということは大事なことです。それを支援する方法の1つです。なお、クリアコードでMewでメールを読み書きしている人は1人しかいません。
新しくクリアコードに入社した横山さんがクリアコードに入社した理由をまとめました。それはフリーソフトウェアに関連することを仕事にするためです。
Software Design 4月号にDebianパッケージを追加する流れを寄稿しました。
クリアなコードの書き方としてマッチしすぎる正規表現に気をつけるとよいということを紹介しました。初心者向けの話です。
Gitでコミットメールを配信する方法をまとめました。クリアコードで使っている方法です。
起動時にパスワード認証が完了するまでUIを非表示にする、というThunderbirdの法人向けカスタマイズ事例を紹介しました。
schooで2回目のリーダブルコードのWeb授業を開催しました。質疑応答でいい回答をしたものがあったので別途まとめました。「新人プログラマーにどうやってリーダブルコードについて伝えるか」についての回答です。回答は「自分がリーダブルコードを書くことによりリーダブルコードを伝える。本を読んでおけとも言わないし、そもそも『リーダブルコード』という用語も使わない。」でした。余談ですが、schooで授業していましたよね?と声をかけられることが数回ありました。
WEB+DB PRESS Vol.86の新人向け特集「1年目から身につけたい! チーム開発6つの心得」を執筆しました。
Markdownで書いたテキストをPDFに変換して納品用ドキュメントを作成する方法をまとめました。
AppVeyorというWindows用CIサービスの使い方をまとめました。
公式のWindows版PostgreSQLパッケージ用の拡張機能のビルドシステムの作り方をまとめました。PostgreSQLのソースコードなしでビルドする方法です。
pg_shardとPGroongaを使ったレプリケーション対応の高速日本語全文検索可能なPostgreSQLクラスターの作り方をまとめました。
PostgreSQLアンカンファレンス@東京(2015/5/30)でPostgreSQLで日本語全文検索する方法を紹介しました。LIKE
とpg_bigmとPGroongaについて紹介しました。
Red Hat系のディストリビューション用のinitrdカスタマイズツールであるDracutを紹介しました。
複数のレイアウトのキーボードを接続しながらインプットメソッドフレームワークであるFcitxを使うときに便利なツールを紹介しました。
2014年に引き続き、SEゼミの一部として学生向けにリーダブルコード勉強会を開催しました。メンターが非常に充実した勉強会となり、参加した学生・メンターの満足度も高かったです。
ConoHa上にDroongaクラスターを設置する手順をまとめました。
複数人のGitHub上のアクティビティをタイムラインで表示するためのツールfluent-plugin-github-activitiesとSharetaryを紹介しました。続編もあります。
Firefox 29で削除されたセキュリティポリシー機能と、その代替手段を紹介しました。
OverlayFSの一種であるunionfs-fuseを使う方法を紹介しました。
Groongaがキャッシュしている内容を確認する方法を紹介しました。
WerckerというCIサービスのDockerバックエンドを使う方法を紹介しました。続編もあります。
SEゼミの一部としてOSS Hack 4 BeginnersというOSSの開発に参加したことがない学生向けのイベントを開催しました。このイベントもメンターが非常に充実していました。このイベントが後で登場する「OSS Gate」につながります。
AngularJSのユニットテストでつまづいた点をまとめました。
CutterというテスティングフレームワークでマルチメディアフレームワークGStreamerをどのように使っているかを紹介しました。
SEゼミのイベントがすべて終わったのでSEゼミのコンテンツ作成と進行をしてわかったことをまとめました。
マルチメディアフレームワークGStreamer 0.10から1.0へ移行する方法を紹介しました。
ピクシブさんと永和システムマネジメントさん向けにリーダブルコードワークショップを開催しました。「チームメンバーのリーダブルコードを見つけて共有」することを体験するワークショップです。SEゼミでの学生向けのリーダブルコード勉強会の内容を社会人向けにアレンジしたものです。
進捗共有に必要な情報として目的、期日、現状、今後があるということをまとめました。
Firefoxの独自ビルド方法を紹介しました。続編もあります。
Visual Studioなしでmingw-w64だけでWindowsのイベントログに出力する機能を実現する方法を紹介しました。
クリアコードとフリーソフトウェアとビジネスについてまとめました。
PostgreSQLで日本語全文検索を実現する拡張機能であるPGroongaがどのようにJSON検索を実装しているかを説明しました。
Firefox 38以降で急にSSL/TLSのエラーが出るようになった、という問題の原因と対策を紹介しました。
Fluentdの新機能であるメモリ上の設定をダンプする方法を紹介しました。
ImageMagickを使って動作確認用画像を生成する方法を紹介しました。
認められて伸びる・やる気がでるタイプなら依頼者・ユーザーに認めてもらうという方法があるということを紹介しました。
Fluentdの新機能であるプラグインの設定項目を確認する方法を紹介しました。
コミットメール配信サービスcommit-email.infoを紹介しました。
OSS開発に参加する人を増やす取り組み「OSS Gate」を開始することにしました。
Firefox用アドオンの署名義務化に伴う、一部アドオンのMozilla Add-ons掲載取りやめについて説明しました。
Firefoxのメモリ消費の状況を定期的に監視する方法を紹介しました。
Ruby on RailsでPostgreSQLとPGroongaを使って日本語全文検索を実現する方法を紹介しました。
同様に、Ruby on RailsでMySQLとMroongaを使って日本語全文検索を実現する方法も紹介しました。
Fedoraプロジェクトで共同でパッケージをメンテナンスする方法を紹介しました。
PostgreSQLカンファレンス2015でPGroongaの実装を紹介しました。
軽快で使いやすいオープンソースのメールソフトであるSylpheedのプラグインを作る方法を紹介しました。
Groonga Meatup 2015でGroonga族の最新情報を紹介しました。
FluentdからApache Flume NGへレコードを送る方法を紹介しました。逆にApache Flume NGからFluentdへレコードを送る方法も紹介しました。
FirefoxのJavaScript処理系であるSpiderMonkey固有の__noSuchMethod__
機能をES6 Proxyで実現する方法を紹介しました。
Groongaプラグインを開発する方法をまとめました。
RubyKaigi 2015でRubyのテスティングフレームワークフレームワークの歴史を紹介しました。また、RubyKaigi 2015をシルバースポンサーとして応援しました。
Firefoxを意図的にクラッシュさせる方法を紹介しました。
Thunderbirdのエラーコンソールの出力結果を効率よく収集する方法を紹介しました。
Firefox用アドオンのデジタル署名の自動化方法を紹介しました。
クリアコードが公開しているFirefox用アドオンCert ImporterとFirefox ESR版の署名要求についてまとめました。
Firefox・Thunderbirdをクリーンな環境で起動する方法を紹介しました。検証時に便利です。
Sytemdのサービスの依存関係を調べるために使えるsystemd-analyze
とsystemctl
を紹介しました。
ブログにまとめられていませんが、12月は他にも、OSS Gateの立ち上げ・ジャストシステムさん向けにリーダブルコードワークショップを実施をしていました。早いところまとめておきたいところです。
2016年にやりたいことは2015年にやりたかったことをもっとがんばるということであると宣言しました。
2015年の活動もまとめました。
2015年は発表はGroonga関係のことが多かったです。外向けの活動は発表だけでなくワークショップの実施、雑誌への寄稿などこれまでとは違った形での活動をしてきました。
ブログの内容は自分たちの知見を言語化したものよりも、ツール紹介・機能紹介の方が多かったです。2016年は知見の言語化を強化していきたいです。
2015年10月に「OSS Gate」という取り組みを開始しました。
OSS Gateとは「OSS開発に参加する人を増やす取り組み」です。OSS開発に参加する人を増やすためにOSS Gateでは次の知見をベースにしています。
この知見を活かしたワークショップを2016年1月30日(土)に開催します。それがOSS Gateワークショップ2016-01-30です。
以下、ワークショップについて説明するので、次の項目に該当する方はぜひお申し込みください。また、まわりに該当する方がいる人はぜひこのワークショップを教えてあげてください。
このワークショップは「OSSの開発に参加する」を実際に体験するワークショップです。実際に体験することで「OSSの開発に参加する方法」がわかり、その後はワークショップ形式でのサポートがなくてもOSSの開発に参加できるようになる、という流れを目指しています。
そのために、次のような流れで実際に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回目のワークショップ開催について告知しました。参加者・メンターともに募集しています。以下のイベントページから応募してください。
まわりに興味のありそうな人を知っている人はぜひ教えてあげてください。
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の機能拡張に興味がある人は参考にしてみてください。
クリアコードでは社員全員が働きやすい環境をつくることによって、全ての社員がその能力を十分に発揮できるようにすることを目的として、10月からワークライフバランスの推進に取り組んでいます。今回はその取り組みを紹介します。
なお、この記事は取り組みの様子の社外への紹介だけでなく、クリアコード社員に向けての周知も兼ねています。
クリアコードは創業から今年で10年となり、社員のライフステージも変化してきています。設立当初は一人暮らしの社員がほとんどでしたが、結婚して共働きをしている社員や、子育て中の社員が増えてきました。
そのような変化にともない、家事や子育てと仕事を両立したい、あるいは自己啓発の時間を確保したいといった声が聞かれるようになりました。以前からフレックスタイム制の導入、残業時間削減、有給休暇の100%取得などを行ってきましたが、家族と過ごす時間を増やす、自己啓発の機会を作るためには別の施策の必要性が増してきました。 そこで現在、東京都の中小企業ワークライフバランス推進助成金という制度を活用して、ワークライフバランスの推進に取り組んでいます。
ワークライフバランス推進の最初の取り組みとして、社員がワークライフバランスについてどのように考えているのか、その実態を調査することにしました。新宿区のワーク・ライフ・バランスに関する企業および従業員の意識・実態調査報告書にある「ワーク・ライフ・バランスに関する従業員の意識・実態調査アンケート」調査票を使って社内アンケートを実施した結果からは、次の課題が見えてきました。
アンケートでは会社の制度として様々なワークライフバランス支援策の有無と利用の意思についての質問がありましたが、支援策の有無については回答がバラバラであったことから、就業規則等が正しく認識されていないことがわかりました。
なお、アンケートで取り上げた各制度のクリアコードにおける有無は以下のとおりです。
就業規則は社員であればRedmine上で誰でも見られるようになっています。 クリアコードの社員の皆さんは、ぜひこの機会に就業規則に目を通してみてください。 また就業規則の疑問点や、改善のアイデアがあれば、是非聞かせて下さい。
今回はクリアコードにおけるワークライフバランス推進の取り組みについて紹介しました。就業規則から自社のワークライフバランスへの取組状況が見えてくると思います。読者の皆さんも、久しぶりに就業規則を読んでみてはいかがでしょうか。今回扱えなかった課題への対応はまたの機会に紹介します。
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の実例から学ぶ。問題に即したデザインと普遍の考え方」を紹介しました。ライブラリーを作っている人は読んでみてはいかがでしょうか?ライブラリーを作っていない人は読み物として読んでも案外おもしろいかもしれません。話題が多岐にわたっているので「へぇ、こんな世界があるんだぁ」という気持ちになれます。