はじめに クリアコードが関わるプロジェクトの多くでは、ビルドシステムとしてAutotoolsを使用しています。そのため、新しくプロジェクトに参加した開発者にもAutotoolsに関わる修正を担当してもらうことがあります。しかし、個々の開発者のバックグラウンドは様々であり、必ずしもすべての開発者がAutotoolsに関する知識を持っているわけではありません。その上、プログラミング言語などの基礎的な知識とは異なり、学校の授業や企業の研修などでAutotoolsについて学ぶことができる機会は稀であり、まとまった解説書も少ないなどといった事情があるため、その使い方を伝授するのには毎度手間を要しているというのが実状です。 そこで、これから数回に分けてAutotoolsの使い方を解説していくことを予定しています。 Autotoolsとは Autotoolsとは、autoconf、automake、li
インターン募集を開始したのが半年前の2月で、6月に開催されたRubyKaigi 2013までは1件も応募がありませんでした。RubyKaigi 2013に参加したところ1件応募があり、6月後半から7月にかけて実施しました。ここ最近まとめているインターンシップで学んだことはこの時期に実施したインターンシップで学んだことです。 その後、さらに2件の応募がありました。クリアコードのインターンシップは学生に限定せず働いている人でも働いていない人でも対象としていますが、3件ともすべて学生の方です。学生の方からの応募は夏休みの時期の方が多いようです1。 2件の応募のうち、1件は「インターンシップ実施企業と学生が話をできる場を提供するイベント」がきっかけでした。もう1件はリーダブルコードの解説を読んでクリアコードを知ったことがきっかけだということでした。解説を書いてよかったです2。 なお、この2件の応募
はじめに 今回は、Fedoraプロジェクトで新規パッケージをリリースする方法を、Cutterをリリースしたときの経験をもとに紹介します。 Cutterプロジェクトでは、従来はFedora向けに独自にリポジトリを用意してRPMを提供していました。しかし、この方法では、ユーザーがCutterをインストールするときにリポジトリを追加登録する手間がかかり、不便でした。 そこで、FedoraでCutterを利用したいユーザーがもっと簡単に導入できるように、FedoraプロジェクトからRPMを提供するようにしました1。 新規パッケージリリースまでの流れ 新規パッケージの公開までの流れについては、Join the package collection maintainersに詳細がまとめられています。 このドキュメントは日本語訳もあります。 ところどころ内容が最新版に追従していませんが、参考としては十分
プログラムの種類によっては、そのまま実行できるものと、実行できるようにするために「ビルド」が必要なものとがあります。Cなどのコンパイルが必要な言語で書かれたプログラムは当然ビルドが必要ですし、コンパイルが不要な言語であっても、インストーラパッケージを作るというビルド作業が必要な場合はあります。 ビルド作業の自動化のためのツールとしてmakeなどがありますが、そこまで本格的な事をやる必要がない場合は、シェルスクリプトで「ビルドスクリプト」を作るのが手軽でおすすめです。この記事では、そのような場合に役立つシェルスクリプトのテクニックを4つご紹介します。 エラーの気付きやすさとデバッグのしやすさを高める メッセージに色を付ける シェル関数をライブラリにする 一時的に作業ディレクトリの中に入る エラーの気付きやすさとデバッグのしやすさを高める はじめに紹介するテクニックは問題が発生した時に気づきや
はじめに YARDというRuby用のドキュメンテーションツールがあります。この記事ではCで書かれたRubyのライブラリにYARD用のドキュメントを書く方法を紹介します。 YARDはソースコード中にドキュメントを埋め込むタイプのドキュメンテーションツールです。ドキュメントはコメントとして書きます。ドキュメントに@タグ名という記法でメタデータを書けることが特徴1です。YARDに添付されているyardocというコマンドを使うことで、ソースコード中に書いたドキュメントからHTMLのリファレンスマニュアルを作成することができます。 Ruby2はライブラリをRubyでもCでも書けます3。Cでライブラリを書くと、処理を高速化したり、既存のC/C++で書かれたライブラリをRubyから使えるようにできます。例えば、rroonga4はC/C++で書かれた全文検索エンジンライブラリgroongaをRubyから使
ソフトウェア開発を支援するために、やりたいことや問題を管理するシステムがあります。例えば、Bugzilla1やRedmine2、GitHubなどがそのような機能を持っています。システムごとにやりたいことや問題の呼び方が違います。例えば、Bugzillaでは「バグ」、Redmineでは「チケット」、GitHubでは「Issue」と呼んでいます。ここではRedmineと同じ「チケット」と呼び方を使うことにします。 今回紹介するのは、後からチケットを見たときに、チケットを書いた時に知っていた情報を思い出せるようなチケットの書き方です。 このような書き方は、プロトタイプのような「作って終わり」とか「短期間の開発」というようなソフトウェアでは必要がないでしょう。また、後述の通り、「チケット駆動開発」にも使えないでしょう。継続的に開発を続けていくソフトウェアの開発のように、やりたいことや問題はあるけど
注意: 長いです。 一言まとめ: withinとtest-unit-capybaraを使ってHTMLのテストを書くと問題を見つけやすくなる。あわせて読みたい: デバッグしやすいassert_equalの書き方 HTMLに対するテストに限らず、開発を進めていく中でテストが失敗する状況になることは日常的にあることです。HTMLの場合は、入力フォームのラベルを変更したり、項目を追加したら既存のテストが失敗するようになるでしょう。そのとき、どのようにテストを書いていれば原因を素早く見つけられるのかを説明します。ポイントは「注目しているノードを明示すること」です。 HTMLテストのライブラリ さて、Rubyで処理結果のHTMLをテストするときにはどんなライブラリを使っていますか？The Ruby ToolboxにあるBrowser testingカテゴリを見てみると、Capybaraが最も使われてい
クリアコードではMozilla製品やRuby関連の開発だけではなく、広くフリーソフトウェアのサポートもしています。もちろん、サポート対象のソフトウェアの多くは私達が開発したものではありません。しかし、それらのソフトウェアに問題があった場合は調査し、必要であれば修正しています。 このようなサポートが提供できるのは、もともと、私達がフリーソフトウェアを利用したり開発したりしているときに日常的に問題の調査・修正をしていたからです。ソフトウェアを利用していると、問題に遭遇することはよくあることです。そのソフトウェアがフリーソフトウェアの場合は、開発者に問題を報告し、可能ならパッチを添えます。このとき、そのソフトウェアの内容を完全に把握していることはほとんどありません。しかし、それでも修正することができます。 それはどうしてでしょうか？今まではどのようにやっているのかを自分達でもうまく説明できなかっ
オフィス文書形式が要求されるようなドキュメントではなくて、自分が開発したライブラリのドキュメント（リファレンスマニュアルやチュートリアルなどライブラリのユーザーが読むためのドキュメント）の話です。以下の「ドキュメント」もそのような意味で使っています。 使いやすいライブラリを開発したかったらプログラムだけではなくドキュメントも書くべきです。 なぜドキュメントを書くか ドキュメントを書く習慣があるかどうかは開発者によってあったりなかったりです。使っているプログラミング言語に相関がある気もしますし、リリースするかどうかに相関がある気もします。理由はいろいろあるでしょうが、ドキュメントを書く習慣のない開発者の方が多いでしょう。 書かない理由はこんな感じでしょうか。 面倒。 自分しか使わないからいらない。 どのように書けばよいかわからない。（どのツールを使えばよいかわからない。） 一方、書く理由はこ
他の人がzshを使っているのを見ていると、「もっと便利に使えるのに」と、もやっとしたり、「え、その便利な機能ってなに？」と、発見があったりします。だれかに「この設定をすると便利ですよ」と話しやすくするために、今のzshのおすすめ設定をここに記しておきます。 もし、Emacsも使っている場合はおすすめEmacs設定もどうぞ。 ディレクトリ構成 長年漬け込んできたzshの設定がそこそこの量になっているので、以下のようなディレクトリ構成にして分類しています。主に、zsh標準機能の設定と追加パッケージの設定を分けるためにこうしています。 ~ ├── .zshrc # シェルを起動する毎に読み込まれる。 │ # ~/.zsh.d/zshrcを読み込んで │ # 標準機能の追加設定を行う。 ├── .zshenv # ログイン時に一度だけ読み込まれる。 │ # ~/.zsh.d/zshenvを読み込ん
リファレンスマニュアルの記述方法を検討し、埋め込み方式のドキュメントツールを採用したとします。Rubyで埋め込み方式のドキュメントツールを使うとしたらRDocかYARDになります1。 RDocからYARDへの移行方法につなげたいのでYARDを使う方向で話を進めたいわけですが、その前にRDocとYARDの背景や機能の違いを確認しておきましょう。 RDocの背景 RDocはRuby 1.8.1からRuby本体に標準添付されています。Ruby1.8.1は2003年のクリスマスにリリースされているので、もう7年くらい前になります。Ruby本体や標準添付されているライブラリもRDoc用にドキュメントが書かれていますし、Rubyで標準的なドキュメントツールといえばRDocという存在です。 RDocは2004年くらいまではRuby本体のリポジトリ上で活発に開発されていましたが、それから数年は開発が停滞し
Rubyではライブラリのリファレンスマニュアル作成のドキュメントツールとしてRDocが標準となっています。これは、古くからあるという理由とRuby本体に標準添付されているという理由からです。しかし、RDocはそれほど活発に開発されていないため、最近のドキュメントツールとして機能不足と言わざるをえません1。どのような機能が足りないのかについては別の機会にします。 数年前からYARD（Yey! A Ruby Documentation Tool）というドキュメントツールが開発されています。YARDはRDocとの互換性を残したまま機能を拡張しているため、RDocからの移行も容易です。実は、YARDは第2回フクオカRuby大賞（SSLの証明書の期限が切れているので警告がでます）に「Improving Documentation in the Ruby Community」というタイトルで応募してい
デバッグしやすいassert_equalの書き方とデバッグしにくいassert_equalの書き方があるのは知っていますか？1 デバッグしやすいassert_equalの書き方を2パターン紹介します。 まとめたassert_equal まず、1つ目のよくみるデバッグしにくいassert_equalの書き方です。 def test_parse assert_equal(29, parse_integer("29")) # (1) assert_equal(29, parse_integer("+29")) # (2) assert_equal(-29, parse_integer("-29")) # (3) end これがデバッグしにくいのは、(1)が失敗したら(2)、(3)が実行されないからです。すべてのassert_equalが実行されて、どのassert_equalが失敗したかを確認す
昔から「Rubyはドキュメントが弱い」と言われてきました。「PythonやPHPはあんなにドキュメントが揃っているのに、それに比べてRubyは。。。」というわけです。でも、待ってください。ドキュメントは記述が充実しているだけで十分ですか？簡単に目的のドキュメントにたどりつけますか？ GoogleやBingなどの検索エンジンや、Amazonを筆頭とするECサイトは「探しものを見つけやすくする」ことにどんどん磨きをかけています。なぜ、ドキュメントの検索機能はそれほど進歩しないのでしょうか？ ドキュメントの検索機能が、検索エンジンやECサイトでも使われているような最新の検索パターンを取り入れ、もっとリッチになればプログラミングがもっと楽しくなるはずです。それをRubyのドキュメントで実現しようとしているのがるりまサーチです。 最近、るりまサーチがよりパワーアップしたので、どう変わったかを紹介しま
先日、milter managerのスケーラビリティ向上計画を紹介しましたが、そこに書いた内容を実装したmilter manager 1.6.4をリリースしました。（メーリングリストでのアナウンス） スケーラビリティ向上のための主な追加機能は以下の3点です。 マルチプロセス対応 libev対応 writeの非同期化 このうち、「マルチプロセス対応」と「libev対応」は「実験的」な扱いということで、デフォルトでは無効になっています。「writeの非同期化」は有効になっています。このため、Postfixや子milterのreadが遅い場面では劇的にスループットが向上するでしょう1。 また、スケーラビリティ向上に加えてRuby対応を強化しています。代表的な変更はRuby 1.9.2に対応したことです。Rubyでmilterを書くのがより便利になりますね。 まとめ milter manager
milter managerの開発を始めたのが2008年の9月なので、2年と少し前になります。この当時はPostfixでmilterを使うというのはそれほど一般的ではありませんでした。しかし、最近ではPostfixでmilterを使うというのが選択肢の1つになっています。これは、Postfixのmilter対応が強化されたことと、Web上にPostfixでmilterを利用した事例が増えてきたことが大きな要因でしょう。 このような状況になると、より規模の大きなメールシステムでもmilter managerを利用することを想定しないといけません1。そのため、milter managerがよりスケールするように内部の構造を改良する予定です。これらの改良は近いうちにmilter manager 1.6.3としてリリースする予定です。1.6.Xシリーズの間は「実験的」な扱いで機能を提供し、1.8.
全文検索エンジンgroongaを囲む夕べ #1 : ATNDの定員が50人から120人に増えましたね。たぶん、何人かはキャンセルするはずなので、今のうちに登録しておくとおそらく参加できるでしょう。興味のある方はお早めに登録してください。 さて、以前、サーバ上でPDFやオフィス文書からテキストを抜き出す方法を紹介しました。これらを使うことにより様々なフォーマットの文書からテキストを抽出し、groongaなどの全文検索エンジンを利用して高速に目的の文書を見つけることができます。例えば、ファイルサーバやデスクトップ上にある文書を検索する用途にも有用です。 しかし、文書のフォーマット毎に抽出方法を変えなければいけないため、実際にテキストを抽出する部分（インデクサーの機能の一部）を作る場合に不便です。文書のフォーマットに依らず、同じ方法でテキストを抽出できると便利ですよね。 ということで、文書のフォ
groongaなどを使って全文検索システムを作るときは、PDFやオフィス文書などからテキスト情報を抜きだして検索用インデックスを作る必要があります。Windowsでテキストを抽出するソフトウェアとしてはxdoc2txtなどがありますが、ここでは、Linuxサーバ上でテキストを抽出する方法を紹介します。 PDF Linux上でPDFを閲覧する場合は、昔はXpdfでしたが、最近はEvinceやOkularの方がよく使われているようです。どちらもPDFの処理にはXpdfからforkしたPopplerというライブラリを使っています。 popplerにはPDFからテキストを抽出するpdftotextというコマンドが付属しているため、それを利用してPDFからテキストを抽出できます。 % pdftotext hello.pdf hello.txt これでhello.pdfのテキスト情報がhello.tx
とあるRails 3を使っているたいやき用のCMSでDeviseを使ってOpenID認証をするようにしたので、そのやり方を紹介します。RubyはRuby 1.9.2 RC2も出ていますが、今回はRuby 1.9.1を使います。 Deviseとは DeviseはRackベースの認証システムです。バックエンドにWardenを利用しているため、Basic認証やOpenID、OAuthなど認証方法を切り替えることができます。 ただ、以下の説明を読んでみてもらってもわかる通り、動き出すまでにそこそこの作業が必要になります。機能は豊富なので、動き出したらカスタマイズしてアプリケーションの要求に合わせていくことができるでしょう。日本語での情報もあまりありませんが、探せばいくつかはあるので、試してみてはいかがでしょうか。 とはいえ、今回はDeviseのデフォルトの認証方法ではなく、OpenIDでのみ認証す
みなさんはPassengerの管理下にあるRails/Rackプロセスをどのように監視しているでしょうか。 Muninを使った方法もあり、Dan Manges's Blog - Rails Application Visualization（gist: 20319 - munin plugin for passenger- GitHub）で公開されていたりします。このプラグインはpassenger-statusの結果をグラフ化しています。passenger-statusの結果はこんな感じになります。 ----------- General information ----------- max = 6 count = 3 active = 0 inactive = 3 Waiting on global queue: 0 ----------- Domains ----------- /h
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く