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

ククログ

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

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

2015年にやりたいこと

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

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

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

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

フリーソフトウェアの考えを実践している人・実践したい人の採用
コミットへのコメントサービスの改良

前者に関しては、実践している人を2人採用しました。

後者に関しては、学生向けのリーダブルコード勉強会やリーダブルコードのWeb授業という形でどのように改良していけばよいかを模索していました。まずはわかりやすい導入（よいコードはこう書くといいですよというノウハウ伝授のようなもの）があって、それからよいコードが当たり前という文化づくりに進んでいくという流れがよいのかもしれません。

2015年も大事にしていることは変わりません。大事にしていることを実現するために、2015年は次のことに力を入れます。

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

2014年はどちらかというとクリアコード自体を強化する方向でした。2015年は2014年に強化したクリアコードの知識やテクニックをより積極的に社外に共有します。共有することは自分たちの知識やテクニックを整理することにつながります。結果として、自分たちがフリーソフトウェアの考えを実践したり、クリアなコードを書くといった大事にしていることの継続的な実現につながります。

「フリーソフトウェアの開発に関わる人を増やす」は、GroongaやFirefox OSなどのフリーソフトウェアの開発を通じて実現するという案があります。周りの人たちを巻き込んだり、サポートしたりと、一緒に開発する機会を通じて実現する、ということです。

「よいコードを書く人を増やす」は、2014年の「コミットへのコメントサービスの改良」で得られた知見を活かして、より多くの人にノウハウを提供していきます。そのために、これまでとは違ったアプローチも検討しています。

2014年のまとめ

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

1月

メタプログラミングをして割に合うかの判断基準：処理を1箇所に局所化できるかは、開発している中で「ん？」と感じたことを、「なんとなくこれはよさそう・よくなさそう」ではなく、理由を考えて説明してみた話です。説明しようとすると考えがまとまる例でもあります。みなさんも試してみてください。

消費税率引上げへの対応　契約時の対応編はお金の話です。

監視統合ビューアHatoholのセットアップ方法は開発に関わっているHatoholという運用管理ツールをソースからビルドする方法について紹介しました。Hatoholは開発が活発で、このころの情報は一部古くなっています。HatoholのREADMEも合わせて参照してください。

2月

わかりやすい設定ファイルの項目名：否定形で修飾しないはよいAPIに関する話です。これもなんとなく「ん？」と感じたことを言語化したものです。

Rubyで自然なDSLを作るコツ：値を設定するときはグループ化して代入もよいAPIに関する話です。これは、普段コードを書いているときに無意識のうちに気を付けていることを言語化してみたものです。

Mozilla Firefox/Thunderbirdの法人利用者向けFAQを編纂中ですはお知らせです。Mozilla Firefox/Thunderbirdの法人利用に関する情報が必要な方はぜひ利用してください。

Groongaビジネスパートナーズ発足の経緯と発足後の変化もお知らせです。2014年はGroongaビジネスパートナーズ経由でのGroonga関連のお問い合わせが数件ありました。

3月

Debianでパッケージをリリースできるようにしたい - WNPPへのバグ登録はDebian関連記事の1つ目です。2014年はDebian関連情報をいくつかまとめました。

Groongaでの可変長データの管理方法はGroongaの内部実装の説明です。Groongaの内部に興味のある方は読んでみてください。図入りなので直感的にわかるはずです。

test-unitならRSpec 3のComposable Matchers相当のことをどう書くかはtest-unitの使い方の紹介です。RSpec 3がリリースされたことがこの記事を書くきっかけでした。

Firefox・Thunderbirdの組織内向けカスタマイズの方法の簡単な紹介と比較はMozilla Firefox/Thunderbirdをカスタマイズする方法をまとめたものです。Mozilla Firefox/Thunderbirdはカスタマイズして自分たちにあわせた使い方をできることが特徴の1つです。自分たちの使い方にあったもっと便利なWebブラウザー・メールクライアントが欲しいという方は参考にしてください。

4月

Debianでパッケージをリリースできるようにしたい - よりDebianらしくはDebian関連記事の2つ目です。Lintianというパッケージチェックツールを紹介しています。

GitHubのWikiが変更されたら差分付きで通知する方法は複数人でGitHubのWikiを使うときに便利なツールの紹介です。

2014/6/22（日）に学生向けリーダブルコード勉強会を開催予定はお知らせです。よい勉強会になりました。

Jekyllで複数言語のコンテンツを継続してメンテナンスする方法はGitHub Pagesでも使える方法です。

LXCのテンプレートをカスタマイズする方法は業務でLXCを使っているときに得た知見をまとめたものです。

5月

Thunderbirdの要約ファイルやアドレス帳ファイルの内容を読む方法は多くの人には必要のないけどもしかしたら必要になる人がいるかも？という情報です。

HerokuでRroongaを使う方法はHerokuでRubyを使って全文検索する方法の紹介です。2015年1月13日（来週）開催のHeroku Meetup #13 新年会の懇親会で少し紹介する予定です*1。

6月

Heroku用Groongaのビルド方法はもしかしたら必要な人がいるかも？くらいのHeroku情報です。

Launchpadを利用してパッケージを公開するにははUbuntu用パッケージの公開方法の紹介です。

Groongaの管理画面の改良案はインターンシップの題材案です。Groongaの管理画面はインターンシップとは関係なく開発を始めました。参考：Groongaの細かいことを知らなくても使えるWebブラウザー上で動く管理ツール

SEゼミ - リーダブルコード勉強会（1回目）を開催は学生向けのリーダブルコード勉強会のレポートです。この勉強会は応募者多数のため、2回開催することになりました。これはその1回目のレポートです。かなりチャレンジングな内容にしましたが、うまくいきました。メンターのみなさんのサポートのおかげです。

7月

Debianでパッケージをリリースできるようにしたい - mentors.debian.netの使いかたはDebian関連記事の3つ目です。パッケージのレビューに関する情報です。

SEゼミ - リーダブルコード勉強会（2回目）を開催は2回目の学生向けのリーダブルコード勉強会のレポートです。1回目でのフィードバックを反映して内容を改良しました。

Groongaユーザ向けの、はじめてのDroongaはGroongaベースの分散全文検索エンジンであるDroongaの紹介です。

GStreamerのエレメントをつないでパイプラインを組み立てるにははGStreamer関連のツールの使い方の紹介です。久しぶりのGStreamer情報です。

LXCコンテナに名前でアクセスする方法はLXC情報です。lxc-consoleがC-aをとってしまう問題は他の解決方法もあった気がします。

8月

LXCコンテナにホスト側のユーザをバインドする方法はLXCをひと手間かけて便利に使うための情報です。

RubyKaigi 2014にスピーカー・スポンサーとして参加予定はお知らせです。

新装版リファクタリングは本の紹介です。

PassengerでRroongaを使ったWebアプリケーションを動かすときにチューニングのコツはるりまサーチをチューニングしたときの知見をまとめたものです。

FedoraプロジェクトのGroongaパッケージを一緒にメンテナンスしてみませんか？はお誘いです。今でもまだ誘っているので興味のある方はぜひお声がけください。

9月

手動でインベントリーファイルを作らずにVagrantとAnsibleを一緒に使う方法はHatoholを開発しているときに得られた知見をまとめたものです。

SSHポートフォワード（トンネリング）を使って、遠隔地からLAN内のコンピュータにログインするはSSHの使い方例です。

AC_ARG_WITHでオプションを省略するとき、しないときはAutotools関連情報です。普段の開発で得た知見をまとめたものです。

RubyKaigi 2014：Three Ruby usages - High-level interface, Glue and Embed #rubykaigiはRubyKaigi 2014で発表した内容の紹介です。

Cutterで画像を使ったテストを書くにははCutterの画像向けアサーションの紹介です。

10月

検索エンジン自作入門は本の紹介です。

いろいろ考えると日本語の全文検索もMySQLがいいね！ #osc2014tkはOSC2014 Tokyo/FallでのMySQLの日本語全文検索に関する発表内容をまとめています。

Debianでパッケージをリリースできるようにしたい - そしてDebianへはDebian関連記事の4つ目です。ついにGroongaのパッケージがDebianの公式リポジトリーに入りました。

11月

Rubyのテスティングフレームワークの歴史（2014年版）はRuby 2.2リリースを前に各種テスティングフレームワークについて整理しました。

Groonga 4.0.7の実験的機能であるカラム値の圧縮とRroongaからそれを使うにははカラム値の圧縮機能の使い方を説明しています。

Ubuntuでdebパッケージのお手軽クリーンルーム（chroot）ビルド環境を構築するにははDebian関連記事の5つ目です。パッケージのビルドを便利にするツールであるcowbuilderの紹介です。

12月

UbuntuでdebパッケージのテストをするにははDebian関連記事の6つ目です。debパッケージのテストツールであるpiupartsの紹介です。

milterプロトコルはPostfix Advent Calendar 2014向けに書いた記事です。残念ながら未完ですが、日本語で書かれたmilterプロトコルの説明は現時点ではこれが唯一です。

schooでリーダブルコードのWeb授業を開催はリーダブルコードに関するWeb授業の開催レポートです。とても多くの人が受講しました。

Sphinx 1.3で使えるgettextとバージョン管理の相性の悪さを改善する仕組みはgettextとバージョン管理システムの相性の悪さを解消する案のSphinxバージョンです。

Clangの静的解析を使ってコードの潜在的な問題点を探すにははscan-buildの紹介です。

Firefox OSのサポートサービス開始のお知らせはクリアコードはFirefox OSに力をいれていくぞ！という決意表明です。

まとめ

2015年にやりたいことと、2014年のことをまとめました。

2014年はコードの書き方に関する話は前半が多く、後半はあまりなかったですね。2015年はコードの書き方に関する情報も提供していく予定です。

今年もよろしくおねがいします。

*1 懇親会中でだれも聞いていないはずなので、Heroku Inc.の新入社員の人だけに説明するつもりで話す予定です。

この記事の続き

2016-01-06: 2016年にやりたいことと2015年のまとめ

2015-01-07

Rubyのしくみ

2014年11月にオーム社から「Rubyのしくみ -Ruby Under a Microscope-」というRubyの処理系を解説する本が出版されました。

Rubyのしくみ -Ruby Under a Microscope-
Pat Shaughnessy/島田浩二/角谷信太郎
オーム社
￥ 3,456

須藤がこの本を紹介します。

内容

この本はRubyの処理系（主にCRuby、GCまわりはJRubyとRubyinusも）がどうやってRubyスクリプトを実行しているかを解説しています。図をたくさん用いて解説していることが特徴で、直感的に理解しやすくなっています。るびまのYARV Maniacsシリーズでピンとこなかった人はこの本で再チャレンジしてみるとよいでしょう。

Rubyスクリプトが動くためのベースのルールも一緒に紹介しています。自分が知らなかったRubyの動きがわかるかもしれません。私は定数探索にレキシカルスコープを使っているとは知りませんでした。

例えば、A::Xが定義されている状態で次のコードを実行するとエラーになります。

module A::B
  class C
    p X
  end
end

しかし、次のコードではA::Xを参照できます。

module A
  module B
    class C
      p X
    end
  end
end

この挙動は知っていて、module A::Bのような書き方が好きじゃない理由だったのですが、この挙動がレキシカルスコープに由来していたことは知りませんでした。

読むとどうなるか

まぁ、内容の紹介はどうでもいいんですよ。Rubyがどう動いているかに興味がある人は、この本を勝手に見つけて勝手に読むはずなんです。

そんなことよりも、この本を読むことによりRuby処理系の実装について考えるまとまった時間ができることが大事なんですよ。付録でささださんが「読みながら実装の非効率な部分などを見つけてしまい」と書いているように、Rubyの処理系は完成されたものではなく、今でも徐々に改良されているものです。なので、「今はこういうしくみで動いているんだ」だけでなく、「だったらこう変わったらもっとよくなるかも？」と考える、もっと言えば、その考えを実装してみて実験してみる、という風になると素晴らしいじゃないですか。そのきっかけになるのがこの本のよいところです。

私はこんなアイディアが浮かびました。（メモなのでなにを言っているかわからないかもしれません。）

ゴミになったStringオブジェクトはfreeしてからフリーリストに戻して再利用するんじゃなくて、truncateして別のStringオブジェクトとして再利用したら効率がよくならないか
- 本にはStringオブジェクトはアロケートしたメモリーと文字列の長さは別管理していると書いている（知っていた）
- 本には遅延スイープだと書いている（知っていた）
- → Stringオブジェクトを完全にfreeしないで、文字列の長さだけ0に切り詰めて、アロケートしたメモリーを再利用すればアロケート回数が減るので速くなるのではないか。
- →→ この方法が効果があるならArrayとかHashでも使えるかも。
スコープを抜けたときにゴミオブジェクトを検出できないか
- 本にはスコープが増えるたびに環境を作ってどうこう書いていた（そうだろうなぁとは思っていたけどあまり考えていなかった）
- 本にはライトバリアのしくみがすでに導入されていると書いていた（知っていた）
- → スコープを抜けるときに環境が破棄されるだろうからそこに残っているオブジェクトが参照されているかだけを低コストで確認できないかしら。できるなら、GCの頻度を減らせそう。Pythonだとスコープを抜ける毎にオブジェクトが回収されているけど、Pythonはリファレンスカウンター方式だからできるのかしら。

思いついたことをささっと実装して実験できるようになりたいものです。

まとめ

Rubyのしくみという本を紹介しました。

まえがきで、まつもとさんが「本書の読者のうちの誰か、もしかするとあなたがRubyの開発に関わるようになるかもしれませんし、そうなれば我々は大歓迎します」と書いています。興味が湧いてきたら、この本を読んで「あなた」になってみてはいかがでしょうか。

2015-01-08

Heroku Meetup #13 新年会：HerokuでGroonga #herokujp

Heroku Meetup #13 新年会*1の懇親会のLTで3分くらいでHerokuでGroongaを使えるということを紹介しました。

HerokuでGroonga

補足

いろいろ詳細を省略しているので簡単に補足します。

Disposable DatabaseができるのはGroongaの更新が速いというのは理由の1つですが、dynoの上で扱えるデータ量に制限があるので、せいぜい数10MBから100MBくらいのデータしか扱わないから*2という理由もあります。
Groongaの更新が速いのはインデックス構築時に静的インデックス構築モードでインデックスを構築できるからです。

他の詳細は次のリンク先を参考にしてください。（スライド中にあるリンクです。）

Groongaのビルドパックの指定方法：groonga/heroku-buildpack-groonga
Ruby（Rails）用のビルドパックの指定方法：groonga/heroku-buildpack-rroonga
RailsからGroongaを使うサンプル
- デモ（Heroku上で動いています。）
- ソース
- 解説
Webブラウザー上でGroongaを試せるサンプル
- デモ（Heroku上で動いています。）
- ソース

その他

懇親会で何人かの人がこのブログのことを知っていると言ってくれました。長いこと*3やっていると知ってもらえるもんなんですね。

まとめ

Heroku Meetup #13 新年会で使った資料をちょっとした補足付きで紹介しました。Herokuで日本語全文検索したいときは参考にしてください。

*1 新入社員の人に会うために行ったのに会えませんでした。。。

*2 それより大きいデータを扱う場合はサーバーとして使った方がよいです。

*3 6年くらい前から書いています。

この記事の続き

2016-01-06: 2016年にやりたいことと2015年のまとめ

2015-01-14

Pbuilder と Cowbuilder の性能比較

Ubuntuでdebパッケージのお手軽クリーンルーム（chroot）ビルド環境を構築するにはで Pbuilder よりも Cowbuilder の方が速いと書いてありますが、本当に Cowbuilder の方が速いのかどうか検証しました。

検証環境は以下の通りです。

OS:: Debian sid amd64
CPU:: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz (8 core)
Memory:: 8GB

検証に使うシナリオは以下の通りです。

Debian Wheezy amd64 向けの milter-manager-2.0.5 をビルドします
ネットワークの影響を排除するために一度ビルドして aptcache を用意します
pbuilder --updateかcowbuilder --updateでOSを更新する
pdebuildでパッケージをビルドする

検証に使ったコードはmilter managerのリポジトリにあります。ここでは(3)+(4)をスクリプト化して*1実行し、時間を計測しました。

いくつかのパターンで計測した結果は次の通りです。

ビルド方法	時間(秒)
Pbuilder	241.40
Cowbuilder	215.12
Pbuilder + tmpfs	99.98
Cowbuilder + tmpfs	N/A

Cowbuilder はハードリンクを使うので原理的に tmpfs を使うことができません。*2

追加の設定

追加の設定が必要な環境について説明します。

Pbuilder + tmpfs

Pbuilder と tmpfs を一緒に使うためには追加の設定が必要です。

tmpfs を用意します。

$ sudo mount -t tmpfs -o size=2g tmpfs /var/cache/pbuilder/build

pbuilder のデフォルトのビルドディレクトリを tmpfs にします。

pbuilderrc に以下の内容を追加します。

APTCACHEHARDLINK=no

これで aptcache のコピーにハードリンクを使わなくなります。 APTCACHEHARDLINK以外の設定はほぼ全てコマンドラインオプションで指定することができます。それ以外のオプションをどのように使用しているかはビルドスクリプトを参照してください。

まとめ

Cowbuilder は Pbuilder よりも速いことがわかりましたが、それよりも Pbuilder + tmpfs の方が速いということがわかりました。 Cowbuilder は Pbuilder でボトルネックとなっていた Disk I/O の量を減らす方法として COW を使っています。一方、Pbuilder + tmpfs では tmpfs を使うことによって Disk I/O そのものをなくして高速化しています。*3

pdebuildを使ったdebパッケージのビルドでは、最小環境にビルドに必要なパッケージを全てインストールしてからパッケージのビルドを開始するので、大量のパッケージをインストールします。そのため COW を使って変更のあった部分のみディスクに書き込んだとしてもベースイメージからの変更量が多くなるため大量の Disk I/O が発生し、Cowbuilder でも思った程速くなりませんでした。 Pbuilder + tmpfs では大量のパッケージインストールを tmpfs 上で行うため Disk I/O が発生しないので、高速化できました。

*1 milter managerのパッケージビルドスクリプトを改造

*2 ハードリンクはデバイスをまたいで使うことができないという制限があります。

*3 pbuilder --updateによるtarの展開と再圧縮もtmpfs上で作業するとで速くなっています。

この記事の続き

2015-01-15

無料でチケットを譲ります：CROSS 2015 全文検索エンジン群雄割拠〜あなたが使うべきはどれだ！〜

2015年1月29日にCROSS 2015というイベントが開催されます。その中に全文検索エンジン群雄割拠〜あなたが使うべきはどれだ！〜という「参加者が最適な全文検索を選択することをサポートする」ことを目的としたセッションがあります。

このセッションにGroonga担当スピーカーとして須藤が参加します。全文検索エンジン選びに興味のある方はぜひお越しください。

なお、スピーカー特典として無料参加チケットを2枚もらっています。興味のある方にこの無料チケットを譲ります。興味のある方はinfo@clear-code.comに無料チケットが欲しい旨を書いて連絡してください。チケットのURLをお送りします。

2015-01-22

CROSS 2015 全文検索エンジン群雄割拠〜あなたが使うべきはどれだ！〜：Groongaの紹介 #cross2015

CROSS 2015の全文検索エンジン群雄割拠〜あなたが使うべきはどれだ！〜というセッションで他の全文検索との違いという観点でGroongaの紹介をしました。

Groongaの特徴

内容

全文検索エンジンの性能面での特徴では次のようなこともあるのですが、今回は「既存のシステムと連携できる」という観点で紹介しました。

更新をしているときも検索性能が落ちない（参照ロックフリーな実装のため）

連携できるという観点をもっとアピールできるように、この日のためにPostgreSQLと連携できるPGroongaという拡張機能を開発して肉の日リリースしました。まだ最初のリリースで最小限の機能しかなかったりしますが、興味のある方はぜひ試してみてください。

まとめ

CROSS 2015の「全文検索エンジン群雄割拠〜あなたが使うべきはどれだ！〜」でGroongaを紹介するときに使った資料を紹介しました。ElasticsearchやSolrのユーザーと同じくらい（少し少ないくらい）Groonga関連プロダクトのユーザーがいました。（いるように見えました。）インターネット上の情報はElasticsearchやSolrの方が圧倒的に多いのですが、実際に使っている人は同じくらいいたことがわかったので参加できてよかったです。

全文検索エンジンを検討するときはGroonga関連プロダクトも検討対象に入れてみてください。