タグ

ブックマーク / www.clear-code.com (10)

  • Rubyのテスティングフレームワークの歴史(2014年版) - 2014-11-06 - ククログ

    2014年12月にRuby 2.2がリリースされる予定です1。 Ruby 2.2にはRuby 1.9.1のときに外されたtest-unitというテスティングフレームワークが再びバンドルされる予定です。Rubyのテスティングフレームワーク周りに詳しくない人にはよくわからない状況でしょう。そこで、Rubyのテスティングフレームワークの歴史を説明することで状況を整理します。 名称の整理 この説明の中ではたくさんのテスティングフレームワークが登場します。似たようなものもあるため、最初にテスティングフレームワークの名称を整理します。この説明の中で登場する名称は次の通りです。 RubyUnit Lapidary rubyunit Test::Unit test/unit test-unit miniunit minitest RSpec 違いがわかりますか?ざっくり説明すると次の通りです。 RubyU

    Rubyのテスティングフレームワークの歴史(2014年版) - 2014-11-06 - ククログ
  • Rubyで自然なDSLを作るコツ:値を設定するときはグループ化して代入 - ククログ(2014-02-13)

    最近、fluent-plugin-droongaという分散データストリームエンジンを書いています。その中で、RubyでDSLを実現するときに工夫していることに気づきました。それは、値を設定するときは代入する字面にするということです。代入する字面にするために、グループ化用のオブジェクトを作っていました。 これだけだとどういうことかわからないので、具体例を示しながら説明します。 RubyとDSL Rubyを使っているとRubyで実現されたDSLに触れることが多くあります。RubyのMake実装であるRakeの設定ファイルもそうですし、ライブラリー管理ツールのBundlerの設定ファイルもそうです。 Rakeの場合:

    Rubyで自然なDSLを作るコツ:値を設定するときはグループ化して代入 - ククログ(2014-02-13)
  • おすすめzsh設定 - 2011-09-05 - ククログ

    他の人がzshを使っているのを見ていると、「もっと便利に使えるのに」と、もやっとしたり、「え、その便利な機能ってなに?」と、発見があったりします。だれかに「この設定をすると便利ですよ」と話しやすくするために、今のzshのおすすめ設定をここに記しておきます。 もし、Emacsも使っている場合はおすすめEmacs設定もどうぞ。 ディレクトリ構成 長年漬け込んできたzshの設定がそこそこの量になっているので、以下のようなディレクトリ構成にして分類しています。主に、zsh標準機能の設定と追加パッケージの設定を分けるためにこうしています。 ~ ├── .zshrc # シェルを起動する毎に読み込まれる。 │ # ~/.zsh.d/zshrcを読み込んで │ # 標準機能の追加設定を行う。 ├── .zshenv # ログイン時に一度だけ読み込まれる。 │ # ~/.zsh.d/zshenvを読み込ん

    おすすめzsh設定 - 2011-09-05 - ククログ
    libero18
    libero18 2013/03/11
  • るびま0040号の「Rubyコードの感想戦」とDevLOVE Conference 2012の「リーダブルコードを読んだ後」のお知らせ - 2012-11-26 - ククログ

    株式会社クリアコード > ククログ > るびま0040号の「Rubyコードの感想戦」とDevLOVE Conference 2012の「リーダブルコードを読んだ後」のお知らせ るびま0040号の記事とDevLOVE Conference 2012でのセッションの紹介です。 るびまの記事「Rubyコードの感想戦」の紹介 昨日(2012-11-25)、るびま0040号がリリースされました。今回、久しぶりに記事を寄稿しました1。Ruby コードの感想戦 【第 1 回】 WikiRというタイトルの記事です。あの咳さんのコードにコメントをして、気に入らないところがあったら理由をつけながら直していく(自分好みに変えていく)という内容です。記事中で作ったコードや実際のコミット、記事の原稿などはすべてGitHubにあるので、コードをコピー&ペーストしたりせずに動かしてみたいという人はGitHubにあるリポ

    るびま0040号の「Rubyコードの感想戦」とDevLOVE Conference 2012の「リーダブルコードを読んだ後」のお知らせ - 2012-11-26 - ククログ
  • Rubyの拡張ライブラリにYARD用のドキュメントを書く方法 - 2012-10-02 - ククログ

    はじめに YARDというRuby用のドキュメンテーションツールがあります。この記事ではCで書かれたRubyのライブラリにYARD用のドキュメントを書く方法を紹介します。 YARDはソースコード中にドキュメントを埋め込むタイプのドキュメンテーションツールです。ドキュメントはコメントとして書きます。ドキュメントに@タグ名という記法でメタデータを書けることが特徴1です。YARDに添付されているyardocというコマンドを使うことで、ソースコード中に書いたドキュメントからHTMLのリファレンスマニュアルを作成することができます。 Ruby2はライブラリをRubyでもCでも書けます3。Cでライブラリを書くと、処理を高速化したり、既存のC/C++で書かれたライブラリをRubyから使えるようにできます。例えば、rroonga4はC/C++で書かれた全文検索エンジンライブラリgroongaをRubyから使

    Rubyの拡張ライブラリにYARD用のドキュメントを書く方法 - 2012-10-02 - ククログ
  • 思い出せるチケットの書き方: 「動機」、「ゴール」、「実現案」 - 2012-07-12 - ククログ

    ソフトウェア開発を支援するために、やりたいことや問題を管理するシステムがあります。例えば、Bugzilla1やRedmine2、GitHubなどがそのような機能を持っています。システムごとにやりたいことや問題の呼び方が違います。例えば、Bugzillaでは「バグ」、Redmineでは「チケット」、GitHubでは「Issue」と呼んでいます。ここではRedmineと同じ「チケット」と呼び方を使うことにします。 今回紹介するのは、後からチケットを見たときに、チケットを書いた時に知っていた情報を思い出せるようなチケットの書き方です。 このような書き方は、プロトタイプのような「作って終わり」とか「短期間の開発」というようなソフトウェアでは必要がないでしょう。また、後述の通り、「チケット駆動開発」にも使えないでしょう。継続的に開発を続けていくソフトウェアの開発のように、やりたいことや問題はあるけど

    思い出せるチケットの書き方: 「動機」、「ゴール」、「実現案」 - 2012-07-12 - ククログ
  • リーダブルコードの解説 - 2012-06-11 - ククログ

    注: 記事中の「解説」の部分のライセンスは「Creative Commons 表示 - 非営利 - 継承」です。「解説」は「クリアコード」(「ClearCode Inc.」)によって変更されています。変更前の原著作者は「オライリー・ジャパン」です。「Creative Commons 表示 - 非営利 - 継承」なので再配布や変更や翻訳などはライセンスに従って自由に行えますが、営利目的で利用することはできません。 https://amazon.co.jp/dp/B0064CZ1XEの翻訳である「リーダブルコード」が今月(2012年6月23日)発売されます。すでに予約できるようです。 https://amazon.co.jp/dp/4873115655 書の内容は原書の紹介記事を参照してください。 日語版の訳者は角さんです。これまでの訳書と同様にとても読みやすく訳されています。翻訳なので読

    リーダブルコードの解説 - 2012-06-11 - ククログ
  • テストをすっきり書く方法 - 2012-04-25 - ククログ

    はじめに ソフトウェアを作るときには同時にテストも作ります。 テストを動かすことで、ソフトウェアが設計の通り動作しているかを確認できます。もし設計の通りに動作しない場合はテストが失敗し、ソフトウェアに期待する動作と現在の間違った動作が明確になります。 テストをすっきりと書くことができると、テストを読みやすくなり、また、きれいなソースコードのままで新しくテストを追加することができます。 今回は、そのすっきりとテストを書くための方法について説明します。 テストを追加していくと発生する問題 例えば、1つのテストケースの中にいろいろな機能のテストがある場合を考えます。 ここで、ある機能の実装を修正したので、この機能に関するテストを追加しようとしました。 テスト名に「テストのコンテキスト」と「テスト対象」を含めてどのような内容のテストかを示します。 このとき、ある機能に対して様々な動作をテストするこ

    テストをすっきり書く方法 - 2012-04-25 - ククログ
  • コミットメッセージの書き方 - 2012-02-21 - ククログ

    はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常

    コミットメッセージの書き方 - 2012-02-21 - ククログ
  • クリアなコードの作り方: 縦長・横長なメソッドを短くする - 2012-02-07 - ククログ

    最近読んだRubyのコードではYARDのコードがキレイでした。 さて、長いメソッドは不吉なにおいがするからメソッドを分割するなどして短くしましょうとはよく言われることですが、ここでいう「長い」とは「縦に長い」ことを指していることがほとんどです。長いのが問題なのは縦に長いときだけではなく横に長いときもです。 縦に長いメソッド まず、どうして縦に長いメソッドが問題かについてです。縦に長いメソッドには「処理を把握しづらい」という問題がある可能性が高いです。 どうして処理を把握しづらいか 処理を把握しづらい原因はいくつかあります。例えば、抽象度が低いのが原因です。 メソッドが縦に長くなっているときは、多くの処理が行われていることがほとんどです。これらの処理はメソッドになっていないため名前がついていません。処理に名前がついていない場合は実装を読まないとなにをしているかがわかりません。 せっかくなので

    クリアなコードの作り方: 縦長・横長なメソッドを短くする - 2012-02-07 - ククログ
    libero18
    libero18 2012/02/09
    "メソッドの長さは視覚的にわかるので、パッと見てキレイなコードかそうでないかをざっくりと判断しやすくて便利です。あなたのコードはパッと見てキレイですか?"
  • 1