ククログ
reportbugを使ってバグ報告をしてみよう
Software Design 2015年3月号の「Debian Hot Topics」でreportbugを使ってバグ報告をする方法についての記事がありました。 reportbugを使ったことがなかったので、最近踏んだバグについてreportbugを使ってバグ報告をしたときのことを紹介します。
遭遇したバグについて
DCMTKというDICOMのToolkitをインストールしたときに、Apacheの設定をa2enconfで有効にできないことに気づきました。
% sudo a2enconf dcmtk ERROR: Conf dcmtk does not exist!
丁度reportbugの記事を読んだのでreportbugを使ってバグ報告することにしました。
reportbugでバグ報告するには
reportbugでバグ報告するには以下の手順を踏みます。
- reportbugの初期設定をする
- reportbugを起動する
- 対象となるパッケージを選択する
- 新しいバージョンを確認する
- 既知のバグを確認する
- 変更したファイルを添付する
- バグに適切なタイトルをつける
- バグの重要度を決める
- バグの詳細を記述する
- バグを送信する
それぞれ、順に説明します。
reportbugの初期設定をする
まずは、初期設定が必要です。 reportbugコマンドを実行すると対話形式で設定ができます。
% reportbug Please choose the default operating mode for reportbug. 1 novice Offer simple prompts, bypassing technical questions. 2 standard Offer more extensive prompts, including asking about things that a moderately sophisticated user would be expected to know about Debian. 3 advanced Like standard, but assumes you know a bit more about Debian, including "incoming". 4 expert Bypass most handholding measures and preliminary triage routines. This mode should not be used by people unfamiliar with Debian's policies and operating procedures. Select mode: [novice] Please choose the default interface for reportbug. 1 text A text-oriented console user interface 2 gtk2 A graphical (GTK+) user interface. Select interface: 2 Will reportbug often have direct Internet access? (You should answer yes to this question unless you know what you are doing and plan to check whether duplicate reports have been filed via some other channel.) [Y|n|q|?]? Y What real name should be used for sending bug reports? [HAYASHI Kentaro]> Which of your email addresses should be used when sending bug reports? (Note that this address will be visible in the bug tracking system, so you may want to use a webmail address or another address with good spam filtering capabilities.) [hayashi@clear-code.com]> Do you have a "mail transport agent" (MTA) like Exim, Postfix or SSMTP configured on this computer to send mail to the Internet? [y|N|q|?]? Please enter the name of your SMTP host. Usually it's called something like "mail.example.org" or "smtp.example.org". If you need to use a different port than default, use the <host>:<port> alternative format. Just press ENTER if you don't have one or don't know, and so a Debian SMTP host will be used. > (SMTPサーバーを指定) If you need to use a user name to send email via "mail.clear-code.com" on your computer, please enter that user name. Just press ENTER if you don't need a user name. > (メールアカウントを指定) Do you want to encrypt the SMTP connection with TLS (only available if the SMTP host supports it)? [y|N|q|?]? y Please enter the name of your proxy server. It should only use this parameter if you are behind a firewall. The PROXY argument should be formatted as a valid HTTP URL, including (if necessary) a port number; for example, http://192.168.1.1:3128/. Just press ENTER if you don't have one or don't know. > Default preferences file written. To reconfigure, re-run reportbug with the "--configure" option.
上記のように設定をおこなったときの設定ファイルの保存先は~/.reportbugrcです。パスワードは設定されないので、適宜smtppasswdのエントリを編集します。
reportbugを起動する
初期設定ができたら、reportbugを起動します。初期設定でGTK2のインターフェースを選択したので、GUIで起動できます。
対象となるパッケージを選択する
次にバグ報告の対象となるパッケージを選択します。
新しいバージョンを確認する
新しいバージョンを自動的に確認します。もし更新されたパッケージがあるならそちらで再現するか確認するとよいでしょう。
既知のバグを確認する
バグ報告する前に既知のバグに該当するものがないか確認します。
変更したファイルを添付する
もし変更した設定ファイルがあると自動的に検出してくれます。設定ファイルは問題の切り分けに有効です。添付しておきましょう。
バグに適切なタイトルをつける
バグの内容をわかりやすく説明したタイトルをつけます。 dcmtkの設定ファイルをa2enconfが認識できないので「/etc/dcmtk/apache.conf is not recognized by a2enconf」にしました。
バグの重要度を決める
バグがどの程度深刻なものかを指定します。 設定ファイルが認識されないので、「important」にしました。
バグの詳細を記述する
次にバグの詳細を記述します。 あらかじめ雛形が表示されるので、適宜編集します。
求められているのは、以下の4つです。
- 状況の説明
- 何をしたら効果があったのか or 効果がなかったのか
- 作業の結果どうなったか
- 期待している結果
雛形にそって詳細を記述しました。
バグを送信する
バグの記述を終えたらあとは送信するだけです。
このまま送信してもいいですし、一旦ファイルへと保存しておいて、あとで報告することもできます。
他に追記することもなかったので、そのまま送信しました。
これで、dcmtk-www: /etc/dcmtk/apache.conf is not recognized by a2enconfとしてバグ報告が登録されました。
まとめ
フリーソフトウェアを使っているときに、バグを踏んでしまった経験はありませんか？そのとき、開発元にバグ報告をしていますか？あるいは回避策をとってそのままにしていたりしませんか？ 踏んだバグをそのままにしてしまうと、他の人も同じバグを踏むことになります。パッチを作成するところまでは無理でも、適切なバグ報告があると開発者の修正の助けになります。
今回は、バグ報告のための専用ツールであるreportbugを実際に使ってバグ報告をしたときのことを紹介しました。 Software Design 2015年3月号の記事では、CUIで報告する例でしたが、初期設定によってはGUIでバグ報告することもできます。機会があったら使ってみてください。
「リーダブルコード」に関する有料ワークショップ「実践リーダブルコード」を開催
2015年3月6日にアジャイルアカデミーの1講座として実践リーダブルコードという「リーダブルコード」に関する有料ワークショップを開催しました。
クリアコードでは去年からリーダブルコードに関する講師をいくつかやっていますが、それぞれ目的が違います。具体的には次のようになっています。
- schoo：初心者向け。「こんなコードがリーダブルコードですよ」と紹介することが目的。本の内容がベース。
- SEゼミ：学生向け。「参加者自身」がリーダブルコードを書けるようになることが目的。本の本文の内容は使わない。解説の一部を体験。
- アジャイルアカデミー：現場向け。「参加者のチーム」がリーダブルコードが当たり前となることを支援することが目的。本の本文の内容は使わない。解説の一部の体験と現場に導入するときの障害を乗り越える方法のアドバイス。
- 実践リーダブルコード（2015年3月6日開催）
今のところ、アジャイルアカデミーが一番高度な内容で「チーム」を対象にしています。
内容
リーダブルコードの解説では自然にリーダブルコードを書けるようになるための3つのステップを紹介しています。
- 実際にやる
- 当たり前にする
- コードで伝える
アジャイルアカデミーでのワークショップは「実際にやる」と「当たり前にする」の入り口あたりまでをカバーします。「コードで伝える」はさらにその次のステップとして紹介するにとどめています。
このワークショップでは、参加者にとって今までの考え方とはかなり違う考え方を伝えます。例えば次のような考え方です。
- リーダブルの基準はチームごとに違う。基準はコーディング規約などの形で押し付けたり押し付けられたりするものではなくチームごとに育てていくものである。
- リーダブルコードを書くためには「書き方を覚える」のではなく「コードを読もう」。ただし、コードレビューのように「間違いを見逃さないため」ではなく、「リーダブルなコードを探すため」に読もう。
参加者は「現状はリーダブルコードではない」という課題を持っていました。その課題を解決するために、「コーディング規約を作って守らせる」や「コードレビューで問題を指摘する」という方法を実施したり検討したりしているとのことです。
それらの方法と今回のワークショップで伝えた考え方はかなり違います。
コーディング規約のアプローチは作ることも大変ですし、守ってもらうことも大変だそうです。守られないことも多いそうです。
コードレビューのアプローチもコーディング規約と同じ方向の考え方かもしれません。コーディング規約は「規約を作った人たちが考えるよい書き方に書き方を制限する」という考え方ですが、コードレビューのアプローチも「レビューアーが考えるよい書き方」に制限することで品質をあげる、という考え方なのかもしれません*1。
今回のワークショップで伝えた考え方は、制限するのではなく「チームでのよい」は「チームで作る」という方向です。「悪いところを指摘してチームの悪いを減らす」のではなく、「チームのよいを共有してチームのよいを育てる」。制限する方向でやってきた人は「そんなのがうまくいくはずはない」と感じるかもしれませんが、参加者は「そんな考え方があったのか」と言いながらも考え方の違いを理解しようとしてくれました。ありがたいことです。
なお、今回のワークショップで伝えた考え方は、フリーソフトウェアの開発の世界では特別なことではなく、当たり前のことです。しかし、現場では特別なことのようです。
課題
今回のワークショップの課題は、会社に戻ってからワークショップで学んだことをどう展開すればよいかの支援が弱かったことです。自分はやりたいと思うが上司を説得するのは難しそう、というケースをうまく支援しきれませんでした。
上司の説得に関しては参加者のみなさんの方が経験が多そうなので、参加者と講師を含めてうまいやり方や考え方を共有する時間を作るとよいかもしれません。
次回試してみたいことです。
まとめ
アジャイルアカデミーの1講座として実践リーダブルコードという「リーダブルコード」に関する有料ワークショップを開催したので、その内容と課題を紹介しました。ワークショップの内容はGitHubで公開しています。ワークショップ内で使ったスライドも公開しています。興味のある人はシナリオからリンクを張っているので辿ってください。
最後にワークショップの資料を作りながら思いついた標語を紹介します。
「読む人」が 読みやすいなら リーダブル
チームで開発していて、たとえ一般的にはリーダブルコードだったとしても、チームの他のメンバーが読みやすくなかったらそれは「チームにとっては」リーダブルではありません。もしかしたらそのリーダブルコードは「自己満足なリーダブルコード」なのかもしれません。「誰のためのリーダブルコードなのか」考えてみてください。
*1 こういう書き方をするとコードレビューはいらないの？と感じるかもしれませんが、「間違いを見逃さない」というフェーズが必要ならやるとよいです。コードレビューをするなら「リーダブルなコードを探すために読む」ことはしなくてよい（あるいはその逆）、というものではなく、目的が違う独立したことなので必要なら両方やればよいです。両方やる場合は相互によい影響がでることもあります。例えば、コードレビューで指摘しなければいけないことが少なくなるということがあります。
この記事の続き
Mewで色付きでコミットメールを表示する方法
普通のフリーソフトウェアの開発のように、クリアコードでの開発では他の人のコミットを読むことは当たり前です。コミットを読むコストを下げるため、コミットメールを利用しています。
コミットメールを使うとコミットされたら随時メールで通知がくるので、push型の読み方になります。自分でそれぞれのリポジトリーをgit log・svn logするpull型の読み方に比べて、自分でそれぞれのリポジトリーのコミットを取得する手間がない分、コミットを読むコストが下がります。
クリアコードではGitのコミットメールはclear-code/git-utilsに置いているスクリプトで送信しています。このスクリプトはtext/plainとtext/htmlのmultipart/alternativeなコミットメールを送信することができ、text/htmlの方はdiffに色を付けるというような整形をしています。
EmacsでMewを使ってコミットメールを読むときでもtext/htmlのコミットメールを色付きで表示する方法を紹介します。
MewでのHTMLメール表示の設定
Mewはバッファー内でHTMLメールを表示する仕組みを用意しています。mew-prog-text/html変数に関数を指定する仕組みがそれです。
MewでHTMLメールを表示するときはEmacs-w3mを使うことが多いのですが、残念ながらEmacs-w3mは色に対応していないのでコミットメールを色付きで見るために使うことはできません。
Emacs 24.1からSimple HTML Rendererというモジュール（shr.el）が付属しています。このSimple HTML Rendererは元々はGnusに含まれていたモジュールで、Emacs 24.4で追加されたEmacs Web Wowser（Emacsで動くEmacs Lispで実装されたWebブラウザー）のレンダリングでも使われているモジュールです。
このSimple HTML Rendererは色にも対応しているので、MewとSimple HTML Rendererを連携させることで色付きでコミットメールを読むことができます。実際にSimple HTML Rendererで表示すると次のようになります。
Simple HTML Rendererを使う最小限の設定は次の通りです。この設定は~/.mew.elに記述します。
1 2 |
(when (fboundp 'shr-render-region)
(setq mew-prog-text/html 'shr-render-region))
|
Simple HTML Rendererは内部でlibxml2を使っていて、Emacsがlibxml2サポート付きでビルドされていないと実行時エラーになります。もし、実行時エラーを避けたいのであれば、次のようにlibxml-parse-html-regionが束縛されているかもチェックするとよいですが、多くの場合はlibxml2サポート付きでビルドされているでしょうからそこまでチェックする必要はないでしょう。
1 2 3 |
(when (and (fboundp 'shr-render-region) (fboundp 'libxml-parse-html-region)) (setq mew-prog-text/html 'shr-render-region)) |
この設定をすると、明示的に「.」を押せばHTMLをレンダリングしてくれるようになります。
次のようにmew-use-text/htmlをtにすると、自動でHTMLをレンダリングしてくれるようになります。
1 2 3 |
(when (fboundp 'shr-render-region)
(setq mew-prog-text/html 'shr-render-region)
(setq mew-use-text/html t))
|
さらに、multipart/alternativeにtext/htmlがあった場合はtext/plainよりも優先して表示するようにしたい場合は次のようにmew-mime-multipart-alternative-listも設定します。これで、コミットメールのHTMLを自動で表示してくれるようになります。
1 2 3 4 5 |
(when (fboundp 'shr-render-region) (setq mew-prog-text/html 'shr-render-region) (setq mew-use-text/html t) (setq mew-mime-multipart-alternative-list '("Text/Html" "Text/Plain" ".*"))) |
表示するだけならこれで十分ですが、HTMLメール内のリンクを簡単に辿りやすくするともっと便利になります。たとえば、リポジトリーブラウザー上のコミットのページや特定の行に行くと周辺のコードを見れて便利です。
Mewでは、Messageモード内で「TAB」を押すと次のリンクに移動できます。これはmew-urlテキストプロパティーを探すことで実現しています。Simple HTML RendererはHTMLをレンダリングするとリンクにshr-urlテキストプロパティーを設定します。Simple HTML Rendererでレンダリングした後、shr-urlテキストプロパティーが設定されているテキストにmew-urlテキストプロパティーも設定することで、Mewの「次のリンクに移動」機能を使うことができます。それを実現すると次のようになります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
(defun mew-render-html-shr (begin end)
(save-excursion
(save-restriction
(narrow-to-region begin end)
(shr-render-region (point-min) (point-max))
(goto-char (point-min))
(let ((url-begin-pos (next-single-property-change (point) 'shr-url))
(url-end-pos))
(while url-begin-pos
(goto-char url-begin-pos)
(setq url-end-pos
(or (next-single-property-change (point) 'shr-url)
(point-max)))
(put-text-property (point) url-end-pos
'mew-url (get-text-property (point) 'shr-url))
(setq url-begin-pos
(next-single-property-change url-end-pos 'shr-url)))))))
(when (fboundp 'shr-render-region)
(setq mew-prog-text/html 'mew-render-html-shr)
(setq mew-use-text/html t)
(setq mew-mime-multipart-alternative-list
'("Text/Html" "Text/Plain" ".*")))
|
これでEmacsで色付きのコミットメールを読みやすくなります。
まとめ
Emacs上でMewを使って色付きのコミットメールを読む方法を紹介しました。Mewでメールを読んでいる人は参考にしてください。
クリアコードに入社した理由: フリーソフトウェアを仕事にしたい
はじめまして、今年の2月にクリアコードに入社した横山です。この記事では、私がクリアコードに入社した理由のひとつである「フリーソフトウェアを仕事にしたい」ということについて、フリーソフトウェアやクリアコードに興味を持ったきっかけと、入社までの経緯をお伝えします。
フリーソフトウェアに興味を持ったきっかけ
私は社会人になってから本格的にプログラミングを始めました。研修や仕事でプログラミングに触れるにつれて楽しさを感じ、研修で触れたRubyがよさそうだったので、趣味でもプログラムを書いたりしていました。
その頃、何度か社内外の勉強会で発表する機会があり、既存のプレゼンテーションツールに不満を感じていました。そこで、新しいツールを探していたところ、Rubyで作られているRabbitというソフトウェアがあることを知り、次のような点が気に入って使い始めました。
- テキストエディタで書けるのでバージョン管理しやすい
- うさぎとかめのタイマーで経過時間とスライドの進捗がひと目でわかる
- フリーソフトウェアなので不満があったら自分で直せる
しばらく使っていると、SlideShareにアップロードする機能がうまく動かないことに気づきました。Rabbitがフリーソフトウェアでなかったらそこで終わっていたのでしょうが、ソースコードが公開されていてすぐに読むことができたため、プログラマーとして成長したいと思っていたこともあり、自分で直してみる気になりました。
そこで送ったpull requestがこれです。おそらく、私が初めて送ったpull requestだと思います。数時間後には取り込んでもらえて、その日のうちに早くも修正が反映された新バージョンがリリースされました。すぐに好意的な反応をしてもらえたのが印象に残っています。
自分で使っているソフトウェアの問題を自分で直すことができるというところがとても気に入って、その後もRabbitを中心にいろいろなフリーソフトウェアに関わり始めました*1。
クリアコードに興味を持ったきっかけ
初めてpull requestを出してフリーソフトウェアに関わり出した頃の私は、Javaを使った金融系システムの開発や保守を仕事にしていました。公開できるシステムではなかったので、フリーソフトウェアに関われるのは夜間や週末になります。初めのうちはそれで満足していたのですが、だんだんもっと深くフリーソフトウェアに関わりたいと思うようになりました。
そんなとき、RubyのカンファレンスであるRubyKaigiの過去の資料や動画を見ていて、フリーソフトウェアを仕事にしているクリアコードという会社があることを知りました。本当にフリーソフトウェアを仕事にできるのか、にわかには信じられませんでしたが、会社のWebサイトやブログにビジネスについての情報が公開されていて、本当なんだと思いました。
入社までの経緯
そのうちクリアコードの選考プロセスであるパッチ採用に応募してみようと思っていたところ、偶然にもRabbitの作者の須藤さんがクリアコードの代表取締役で、クリアコードに興味はないかと声をかけてもらったのが入社の直接のきっかけになりました*2。
そして、今年の1月に今まで住んでいた札幌から東京に引っ越し*3 、2月から入社となりました。
まとめ
私がフリーソフトウェアやクリアコードに興味を持ったきっかけと、入社までの経緯をお伝えしました。フリーソフトウェアやクリアコードに興味がある方に参考にしてもらえるとうれしいです。
Software Design 4月号の紹介
クリアコードの林です。
3/18(水曜)に技術評論社から「Software Design」4月号が発売されました。 そのなかでDebian開発者であるやまねひできさんが連載中の「Debian Hot Topics」に、全文検索エンジンGroongaをDebian公式に入れるまでのあれこれを「Debian公式入りへの道」と題して書きました。
内容について
記事の内容は、過去にククログで公開した以下の記事のダイジェストです。
- Debianでパッケージをリリースできるようにしたい - WNPPへのバグ登録
- Debianでパッケージをリリースできるようにしたい - よりDebianらしく
- Debianでパッケージをリリースできるようにしたい - mentors.debian.netの使いかた
- Debianでパッケージをリリースできるようにしたい - そしてDebianへ
GroongaをDebian公式のパッケージにするにあたり、そのきっかけや、どんな作業をしたのか、苦労した点などをGroongaを題材にして書いています。
まとめ
Debian公式に入れたいパッケージがあるんだけど、どうしたらいいかわからない人はぜひ読んでみてください。 紙面の都合で、詳細を割愛したところもあります。上記で紹介したククログの記事も合わせて参照してみてください。
クリアなコードの作り方: 正規表現はマッチしすぎに気をつける
正規表現は短い表現でたくさんのパターンを記述できるため適切に使えばとても便利な機能です。しかし、雑に正規表現を使ってしまうと思わぬバグになったり、わかりにくいプログラムになってしまいます。「動く」正規表現は書けるけど、「適切な」正規表現はまだ書けない、という初級者向けの話です。
例: 拡張子を変更する
正規表現を使って実現することが多い処理として「拡張子を変更する」という処理があります。次のような処理です。
1 |
pdf_file_name = ps_file_name.sub(/.ps$/i, ".pdf") |
この処理では「XXX.ps」や「XXX.PS」といったファイル名を「XXX.pdf」というファイル名に変更します。
これで問題がないと思いますよね？でも、問題があるんです。問題があるのは例えば次のケースです。
1 2 3 |
eps_file_name = "XXX.eps" pdf_file_name = eps_file_name.sub(/.ps$/i, ".pdf") p pdf_file_name # => "XXX..pdf" |
この場合は拡張子が「.eps」なので何もしないで欲しいところですが「..pdf」になっています。
これは正規表現が「マッチしすぎている」からです。ちなみに、マッチしすぎる正規表現は初心者の人がやりがちな雑な正規表現の使い方です。丁寧に正規表現を使えるようになると、「この人はしっかりしているな…！」と一目置かれることでしょう。
マッチしすぎる正規表現
まず、どこがマッチしすぎていたかを確認しましょう。
1 |
/.ps$/i
|
この正規表現の最初にある「.」が注目するポイントです。「.」は任意の1文字にマッチするので「.」そのものにもマッチしますが、「e」など他の文字にもマッチします。
初級者の人は「マッチするパターンだけを確認して大丈夫」と判断する傾向があるようです*1。初級者からステップアップするために、「マッチしすぎていないか」も確認するようにしましょう。
マッチしすぎる正規表現の問題
では、「マッチしすぎる」となにが問題なのでしょうか。1つは、正常なデータを壊れたデータにしてしまうことです。もう1つは、コードを読むときに理解しにくくなることです。
マッチしすぎる正規表現はエラー処理を省略することよりも深刻な問題になることがあります。エラー処理を書いてない場合は（例外機能がある言語の場合は）エラーでプログラムが止まりますが、マッチしすぎる正規表現の場合は正常なデータを壊れたデータにし*2、そのまま処理が継続します。問題が発生したときに止めていれば被害が最小限にとどまったり、原因を見つけやすくなりますが、問題が発生したまま処理を継続すると被害が拡大したり、原因究明を難しくしたりしてしまいます。
コードを読んだときに理解しにくくなることもマッチしすぎる正規表現の問題です。「あれ、この処理だとこの正規表現はマッチしすぎる気がするんだけど。。。なにか特別な意図があるんだろうか。。。」と勘ぐってしまい、理解に手間取ってしまいます。
マッチしすぎる正規表現を防ぐポイント
マッチしすぎる正規表現を防ぐ方法はいくつかあります。たとえば次の方法です。
- 他の人にも確認してもらう。
- メタ文字を意識的に注意する。
チームのみんながそれぞれのコードを読む文化になっていると「他の人にも確認してもらう」は実現しやすいでしょう。そうでない場合は、まわりの人にお願いすることになります。
メタ文字は特別な意味のある文字で「.」もメタ文字の1つです。これらを意識的に注意することでマッチしすぎないかを見つけやすくなります。中級者以上の人はこれをやっているはずです。
なお、fluent/fluentd-ui@a28b710のケース（↓）のように式展開後の値にメタ文字が含まれるケースもあるので注意してください。これは中級者でも気づきにくいケースです。
1 2 3 |
FILE_EXTENSION = ".conf".freeze # ... @note = note || Note.new(file_path.sub(/#{FILE_EXTENSION}$/, Note::FILE_EXTENSION)) |
ちなみに、今回の例ではファイル名の終端を表すために「$」を使っていましたが、Rubyの場合は「\z」の方が適切です。違いは「$」は行末、「\z」は文字列の最後を示すという点です。しかし、通常はファイル名に改行は入らないので、「拡張子を変更する」という機能であれば「妥当なファイル名を渡すのは呼び出し側の責任」と設計することで「$」でも問題なくすることもできます。
まとめ
初級者がついやってしまいがちなマッチしすぎる正規表現とその問題、およびその対策について説明しました。中級者を目指している人は意識してみてください。
Git でコミットメールを配信する方法
クリアコードが開発に関わっているプロジェクトではdiff付きのコミットメールを流すようにしています。
コミットメールを流すための方法を紹介します*1。
使用しているのは以下の2つのGemです。
- git-commit-mailer
- コミットメールを生成して送信するコマンド
- github-web-hooks-receiver
- GitHub*2のWeb hookのエンドポイントとして機能するウェブアプリ
環境はDebian GNU/Linux wheezyを想定しています。Rubyのバージョンは1.9.3以降であれば問題ありません。
専用のユーザを用意します。
$ sudo useradd app
アプリケーションをデプロイするディレクトリを用意します。
$ sudo mkdir -p /srv/www/webapps/web-hooks-receiver $ sudo chwon -R app:app /srv/www/webapps
/srv/www/webapps/web-hooks-receiver/Gemfileを用意します。
1 2 3 4 |
source "https://rubygems.org" gem "git-commit-mailer" gem "github-web-hooks-receiver" |
ここではApache+Passengerでセットアップします*3。
以下のコマンドを実行し、必要なGemをインストールします。
$ cd /srv/www/webapps/web-hooks-receiver $ sudo -u app -H bundle install --binstubs --path vendor/bundle --without=development,test
ここで--binstubsオプションを付けているのは、カレントディレクトリのbin以下にgit-commit-mailerコマンドをインストールするためです。
Rackアプリケーションとして動作させるための設定ファイルconfig.ruを用意します。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
require "yaml" require "pathname" require "github-web-hooks-receiver" use Rack::CommonLogger use Rack::Runtime use Rack::ContentLength base_dir = Pathname(__FILE__).realpath.dirname config_file = base_dir + "config.yaml" options = YAML.load_file(config_file.to_s) map "/post-receiver/" do run GitHubWebHooksReceiver::App.new(options) end |
もし、GitHubWebHooksReceiver::Appの実行中に発生したエラーをメールで通知したい場合は、exception_notificationやrackngaを使うと良いでしょう。
Passenger の設定は以下のようにします*4。
/etc/apache2/sites-available/github-web-hooks-receiver:
<VirtualHost *:80>
ServerName web-hooks-receiver.example.com
DocumentRoot /srv/www/webapps/web-hooks-receiver/public
<Directory /srv/www/webapps/web-hooks-receiver/public>
AllowOverride all
Options -MultiViews
</Directory>
ErrorLog ${APACHE_LOG_DIR}/web-hooks-receiver_error.log
CustomLog ${APACHE_LOG_DIR}/web-hooks-receiver_access.log combined
AllowEncodedSlashes On
AcceptPathInfo On
</VirtualHost>
/etc/apache2/mods-available/passenger.conf:
PassengerRoot /path/to/passenger PassengerRuby /path/to/ruby
/etc/apache2/mods-available/passenger.load:
LoadModule passenger_module /path/to/mod_passenger.so
GitHubWebHooksReceiver用の設定ファイルconfig.yamlを用意します*5。
base_dir: /srv/www/webapps/web-hooks-receiver
mirrors_directory: mirrors
git_commit_mailer: bin/git-commit-mailer
to:
- commit+default@example.com
error_to: commit+error@example.com
exception_notifier:
subject_label: "[git-commit-mailer]"
sender: null+git-commit-mailer@example.com
add_html: false
domains:
github.com:
owners:
clear-code:
to: commit@example.com
from: null+github@example.com
repositories:
cutter:
to:
- cutter-commit@lists.sourceforge.net
cutter-macports:
to:
- cutter-commit@lists.sourceforge.net
pikzie:
to:
- pikzie-commit@lists.sourceforge.net
rabbit-shocker:
to: commit@ml.rabbit-shocker.org
from: null@rabbit-shocker.org
gitlab.example.com:
to: commit+internal@example.com
from: null+gitlab@example.com
- base_dir
- 基準となるディレクトリを絶対パスで指定します。
- mirrors_directory
-
Gitリポジトリをミラーするディレクトリをbase_dir からの相対パス、または、絶対パスで指定します。
省略すると
#{base_dir}/mirrorsを使用します。 - git_commit_mailer
- git-commit-mailer コマンドへのパスを指定します。 ruby コマンドの引数として実行するので、任意の Ruby スクリプトでも構いません。
- error_to
- エラーが発生したときの宛先を指定します。
- to
- コミットメールの宛先を配列で指定します。
- sender
- 送信者のメールアドレスを指定します。 Sender ヘッダーの値や from が指定されなかった場合のエンベロープFromの値として使用します。
- from
- 省略すると Author の name と email から「Commiter Name <commiter@example.com>」のようなメールアドレスを生成して使用します。指定可能なのはメールアドレスの部分のみです。
- add_html
- true を指定すると、HTMLメールで色付きのdiffを生成します。
- send_per_to
- true を指定するとtoごとに別のSMTPセッションでコミットメールを送信します。
- sleep_per_mail
- コミットメールを一通送信するごとに指定された秒数だけsleepします。
コミットメールの宛先を指定する方法
以下の4つの単位で指定することができます。マッチした条件のうち最も小さい範囲にコミットメールを送信します。
- 全体
- ドメイン単位
- オーナー単位
- リポジトリ単位
上の例で言うと、以下のように配信します。
- github.com の clear-code organization にある cutter, cutter-macports リポジトリは cutter-commit@lists.sourceforge.net にコミットメールを配信する。その際 From ヘッダーの値には Author の name と email を使用する。
- github.com の clear-code organization にある pikzie リポジトリは pikzie-commit@lists.sourceforge.net にコミットメールを配信する。その際 From ヘッダーの値には Author の name と email を使用する。
- github.com の clear-code organization にある cutter, cutter-macports, pikzie 以外のリポジトリは commit@example.com にコミットメールを配信する。その際 From ヘッダーの値には Author の name と null+github@example.com を使用する。
- github.com の rabbit-shocker organization の全てのリポジトリは commit@ml.rabbit-shocker.org へコミットメールを配信する。その際 From ヘッダーの値は Author の name と null@rabbit-shocker.org を使用する。
- gitlab.example.com の全てのリポジトリは commit+internal@example.com へコミットメールを配信する。その際 From ヘッダーの値には Author の name と null+gitlab@example.com を使用する。
- 上記全ての条件にマッチしないリポジトリは commit+default@example.com へコミットメールを配信する。その際 From ヘッダーの値には Author の name と email を使用する。
プライベートリポジトリのコミットメールを流す場合
GitHubやGH:Eの場合は、検証していないのでわかりません。検証した人はこっそり教えてください。
GitLab の場合は、全てのリポジトリにReporter権限のユーザーを追加して、そのユーザーにパスフレーズなしの公開鍵を登録します。その上で以下のコマンドを一度実行して $HOME/.ssh/known_hosts に情報を登録しておきます。
$ ssh -T git@gitlab.example.com
この作業を忘れると、コミットメール配信用のリポジトリをミラーできません。
予告
GitLab でリポジトリを追加するたびに手動でWeb hookを追加するのは面倒です。 そこで、自動でWeb hookを登録できるWeb hook*6としてgitlab-system-hooks-receiverを作りました。
またGitHubで自分の管理下にないリポジトリのdiff付きのコミットメールを読みたくなることがあると思います。GitHubのフィードだとdiffが付いていないため、diffの確認に一手間かかってしまいます。github-event-watcherを使うと自分の管理下にないリポジトリでもdiff付きのコミットメールを配信することができます。
次回はそれらの使い方を紹介します。
まとめ
GitHubやGitLabにあるリポジトリのコミットを色付きのdiffを含むコミットメールで通知する方法を紹介しました。
Thunderbirdの法人向けカスタマイズ事例紹介：起動時にパスワード認証が完了するまでUIを非表示にする
発端
クリアコードでは、FirefoxおよびThunderbirdの利用にあたってお困りのお客様について、問題を解決するお手伝いをしています。
その中で、起動時にメールのバスワードを入力し、サーバー認証が完了するまでUIを非表示にしたい、という要望がありました。
カスタマイズの方針
「起動時にメールのバスワードを入力し、サーバー認証が完了するまでUIを非表示にしたい」
この要望には以下の二つの実現したいカスタマイズが含まれている事が分かります。
- 起動時のメールアカウントのパスワード入力
- メールアカウントのサーバー認証が完了するまでUIを非表示にする
要望の1つ目は「メールアカウントのパスワードを保持させない」と読み替えるとクリアコードで開発したアドオン donotsavepassword により実現できます。
要望の2つ目を実現するアドオンについては、要望を伺った時点ではクリアコードの開発したアドオンの中で要件を満たせるものが無かったため、新規に開発する必要がありました。
Thunderbirdのアカウントの種類
アドオンの紹介に入る前に少しThunderbirdのメールアカウントについて見てみましょう。 ThunderbirdではIMAP、POP3の他、メールアカウントを一つでも作成した場合に自動的に作成されるローカルフォルダアカウントがあります。 このアカウントがIMAP、POP3のどのアカウントでもない為、認証を求める対象から外す必要があります。 認証対象となるのはIMAPとPOP3アカウントです。
今回作成したアドオンはIMAPとPOP3のメールアカウントの両方でのメールアカウントのサーバー認証前のUI非表示化に対応しています。
作成したアドオン
force-auth-at-startupという名前のThunderbird用のアドオンです。 GitHubのクリアコードのリポジトリの tb-force-auth-at-startup にてMPL 2.0のライセンスで公開しています。
このアドオンは法人利用を想定しています。
利用方法
このアドオンはMCD（設定集中管理用ファイル）を使用していません。インストールするだけで起動時にメールアカウントのサーバー認証が未完了だった場合にUI非表示とメールアカウントの認証を要求します。
想定される利用方法
このアドオン単体ではメールアカウントのパスワードが保存されている状態では起動時にすぐにUIが表示されてしまいます。 カスタマイズ事例にある通り、クリアコードの開発したアドオンの中でパスワードを保存させない donotsavepassword と組み合わせて使用するとカスタマイズの効果を最大限発揮できるのではないでしょうか。
まとめ
Thunderbirdの法人向けカスタマイズ事例を紹介しました。
クリアコードでは開発するアドオン一つにつき一つの機能を原則として開発しています。そのため、実現したいカスタマイズを実現するにあたり、複数のアドオンを組み合わせてカスタマイズをする事があります。また、時には既存のアドオンと新規開発のアドオンを組み合わせてカスタマイズをする事もあります。
FirefoxやThunderbirdの導入やカスタマイズでお困りで、自力での解決が難しいという場合には、有償サポート窓口までぜひ一度ご相談下さい。
2015年4月3日（金）にschooで2回目のリーダブルコードのWeb授業を開催予定
昨年、2014年12月9日にschooでリーダブルコードのWeb授業を開催しました。そのときは単発の企画で続編の予定はなかったのですが、今週の金曜日（2015年4月3日）の21:00から続編として名著『リーダブルコード』を解説者と一緒に読み解こう ~7章 制御フローを読みやすくする~の授業をすることになりました。
内容
前回は「3章 誤解されない名前」をベースにした授業でしたが、今回は「7章 制御フローを読みやすくする」をベースにした授業です。前回受講した人はわかると思いますが、本の内容をベースにした「初級者向け」の内容です。一部、ステップアップしたい人向けの内容も含まれていますが、基本的に本の内容をベースにしています。
本の内容を十分理解したという方は受講しなくても大丈夫です。
本は読んだけどピンときていない、リーダブルコードに詳しい人に質問したい、他の人のリーダブルコードに対する意見を聞いてみたい、という方は受講してみてください。
授業で使う資料は次の通りです。受講するかどうかの参考にしてください。
リーダブルコードを書くためにはコードを読むこと
資料でも触れていますが、リーダブルコードを書くために大事なことは「コードを読むこと」です。受講しない人も、「リーダブルコードを書きたいならコードを読むこと」ということは覚えておいてください。コードを読むことで読む人の視点がわかりますし、リーダブルなコードの書き方を知ることもできます。必ず役に立ちます。
この話をすると「コードを読めばよいと言うけどどんなコードを読めばよいのだろう」となる人が結構います。そんな人は「自分が使っているオープンソースソフトウェアのコード」を読んでください。
どうして自分が使っているオープンソースソフトウェアがよいのかというと、使い方やどう動くかがわかっているからです。動きがわかっていると、動きを対応させてコードを読むことができるので理解しやすくなります。読む人の経験を養えるだけでなく、実はこんな使い方もできたのか、こんな機能もあったのかと新しい発見もあるかもしれません。自分が使っているソフトウェアのソースだと楽しくコードを読めるはずです。
ぜひ、「自分が使っているソフトウェアのコードを読んでみよう」という観点でコードを選んで読んでみてください。
まとめ
それでは、本は読んだけどピンときていない、リーダブルコードに詳しい人に質問したい、他の人のリーダブルコードに対する意見を聞いてみたい、という方は授業でお会いしましょう。そうでない方もコードを読むことを当たり前にして、よりリーダブルなコードを書けるようになってください。
- ククログの記事はCC BY-SA 4.0とGFDLのデュアルライセンスで自由に利用できます。
- クリアコードはプログラミングが楽しいソフトウェア開発者を1名募集しています。
- クリアコードは「クリアコードをいい感じにする人」を1名募集しています。
- クリアコードはフリーソフトウェア開発で培った技術力を提供しています。特にMozilla製品（Mozilla FirefoxとMozilla Thunderbird）とRubyとGroonga（全文検索）に関連した開発を得意としています。