タグ

ブックマーク / higelog.brassworks.jp (5)

  • Rails 3.2 RC1 - ひげろぐ

    3.1のリリースから四ヶ月足らず。早くも3.2の足音が聞こえてきたようです。 Riding Rails: Rails 3.2 RC1: Faster dev mode & routing, explain queries, tagged logger, store Faster devとExplain queriesは開発を確実にテンポアップさせてくれそう。 Active Record Storeもいいかも。 Faster dev mode & routing Railsをdevelopment環境で動かしていると、アクセスするたびにクラスがリロードされる。 3.2では変更した箇所だけリロードされるようになる。 これはかなり快適になりそう。 またルーティングの解析も高速化されるとのこと。 これによって特にlink_to等を大量に含んだページでは高速化が期待できる。 Explain quer

  • TDDという言葉は呪われている - ひげろぐ

    引き続きTDDBCネタ。 Advent Calender全部俺とか昨日覚えた言葉を使いたいところだが、ネタもしくは自分の勤勉さが続くか心許ないので言わない方向で。 「テスト」という言葉の混乱 これは和田さんの講演の最初の方から。 テストという言葉の指すものがバラバラ 会社によって語彙がバラバラ 単体、ユニット、結合(といいつつ結合テストは割とどこでも指すものが一致している) テスト範囲による分類は曖昧で限界がある。話がまとまらない。 そこで再分類のための視点を探す。 「誰が、何のためにテストを行うのか」という視点 DeveloperTesting: 開発者が 開発促進のために CustomerTesting: 顧客(のロール)が 進捗管理のために 世に言う「受け入れテスト」 QATesting: 品質保証担当者(のロール)が 品質保証のために TDDはDeveloperTestingの領域

  • GuardでTitanium+CoffeeScriptの開発を快適に - ひげろぐ

    久々にTitaniumを触るにあたってCoffeeScriptのコンパイルをGuardにまかせることにしてみたメモ。 Guardはファイルの変更を監視して、変更があったタイミングで何らかの処理を実行できるツール。 これを利用するとCoffeeScriptを書いたそばから自動的にJavaScriptに変換するなんてことも簡単にできるわけで。 そしてそのものずばりのことを実現するGuard::CoffeeScriptなんてものがあったりします。 Guard::CoffeeScriptの導入 gem install guard-coffeescript これでGuard体も入る。あ、要Rubyです。 追記 ファイルシステム監視のために以下のGemも必要だった。 gem install rb-fsevent 上記はMacの場合でLinuxWindowsの場合は違うGemになるので詳しくはGua

  • CoffeeScript - ひげろぐ

    PythonRubyのような文法の小さな言語。 CoffeeScriptのソースをcoffeeコマンドでコンパイルするとJavaScriptのソースを生成できる。 ワケの分からない言い方をすると、JavaScriptを書かずにJavaScriptが書ける。 これはなかなか凄い。 言語の学習コストもそんなに高くないかんじ。 CoffeeScript 日語だと以下によく情報がまとまっている。Titaniumのコードも書けてしまう。 CoffeeScript – sappari wiki CoffeeScriptを使ってTitaniumでiPhoneアプリを作る – AUSGANG SOFT Node.jsといっしょに使ってみる Node.jsとの親和性も高くnpmでさくっと入る。 npm install coffee-script そしてNode.jsを動かすソースの頭で一言呪文を唱えれば

  • テストコードを書くコストに関する考察 - ひげろぐ

    昨年お世話になっていた職場の仕事仲間と先月ランチする機会があった。 自分の関わっていたプロジェクトはペアプロやTDDを実践していたのだが、残念なことに自分が抜けた後はテストコードを書かなくなってしまったという。 理由を聞くと「テストコードを書くより、動くプロダクトコードをどんどん書きたい」ということだった。 これは心情的にはよくわかる。 納期のプレッシャーが強く、TDDに慣れていない状況では特にそうだ。 要は「テストを書いてる暇なんかない」と判断してしまうわけだ。 TDDの最初の躓きのひとつとして、テストコードを書く手間が増えただけのように感じられるというものがあると思う。 実際に手間は増えている。 しかし適切なテストの書き方がよくわからないため、余分な手間をかけすぎているということもあるだろう。 例えばゲッターやセッターのテストを逐一書いてしまう。 これは実際に無駄なことであるから、この

  • 1