coding as drawing

Fibonacci Algorithm Benchmark

2012-08-23T16:30:00.000+09:00

Subject

Node.js is cancer (リンク先は素に削除さている、uu59さんによる和訳記事はこっち) でも言われてた「node.js でフィボナッチは遅い」。

この例はあくまでフィボナッチ関数がどうの、という話をする為ではないし、そもそもRyanが言うように

Node.jsはスケーラブルなネットワークプログラムを簡単に書くための手段であって、レイトレーシングや、ウェブブラウザや、動画エンコーディングシステムをNode.jsで作ってはいけない。

のであって、Suckな例として出すには藪蛇なものだったのだけれど。

それはそれとして、じゃあ実際フィボナッチ関数の実装アルゴリズムは複数あるけれど、実際どれくらいの差が出るのかベンチマークとってみました。

How

Hardware/OS

MacBook 2009 (2.26GHz Intel Core 2 Duo)
Mac OS X - 10.7.4(Lion)
Node.js v0.8.0

fib(n) in 60fps

60fps(およそ16ミリ秒) 以内で処理が終わる限界を調査して、速い実装ほど、引数 n の値が大きくなることを確認する。

なぜ、同じ引数 (例えば n = 1000) を渡して実行時間を比較する方法でないかというと、それぞれの実装のパフォーマンスの差があまりにも大きいのと、再帰処理による実装では引数が大きいとコールスタックの上限を超えてしまい、参考にならないから。

Algorithm

Recursive normal O(n^2): 普通に Fib(n) = n <= 2 ? 1 : Fib(n - 2) + Fib(n - 1) の実装
Recursive with accumulation O(n): 蓄積変数を2つ用意したイテレータを内部で用意し、そちらを再帰
Recursive sequential square O(log n): 逐次平方による再帰
Procedure with accumulation O(n): 蓄積変数を非再帰で while ループ
Procedure sequential square O(log n): 逐次平方の非再帰

なお、最速アルゴリズムである 黄金比のn乗を√5で割った近似値で計算する方法 は O(1) で、「制限時間内で回せる限界を図る」ベンチマークを取ると終了しなくなるのがわかっていたので除外した。

最速アルゴリズム : φ ^ n / √5 (O(log n))

黄金比のn乗を√5で割ると、フィボナッチ数列のn番目の値と近似します

var PHY = (1 + Math.sqrt(5)) / 2;

var SQRT_5 = Math.sqrt(5);

var fib = function(n) {
  return Math.round(Math.pow(PHY, n) / SQRT_5);
};

定数時間で処理が終わります。

Result

$ node fib-benchmark.js
::: Fibonacci Implements Benchmark :::
by 60 fps, each implements reach ...
recursives normal ::: fib( 30 )
recursives accumu ::: fib( 7617 )
recursives square ::: fib( 997146 )
procedures accumu ::: fib( 13740 )
procedures square ::: fib( 5265634 )

大体予想どおりだった。注目すべきは同じ O(n) や O(log n) であるはずの実装が、再帰か非再帰かでかなりのパフォーマンスの差が出ていること。関数呼び出しがかなりのオーバーヘッドになってるのが確認できる。

理屈的には同じパフォーマンスであるはずの逐次平方処理でも、再帰版と非再帰版でほぼ5倍の差が出ている。

Implements

var fibonacci_implements = {
  recursives: {
    normal: function fib(n) {
      return n <= 2 ? 1 : fib(n - 2) + fib(n - 1);
    },
    accumu: function fib(n) {
      var iterator = function(a, b, c) {
        return c <= 0 ? b : iterator(b, a + b, c - 1);
      };
      return iterator(1, 0, n);
    },
    square: function fib(n) {
      var iterator = function(p, q, a, b, c) {
        return c <= 0 ? b :
          c % 2 === 0 ?
            iterator(p * p + q * q, q * (q + 2 * p), a, b, c / 2) :
            iterator(p, q, (a + b) * q + a * p, a * q + b * p, c - 1);
      };
      return iterator(0, 1, 1, 0, n);
    }
  },
  procedures: {
    accumu: function fib(n) {
      var a, b, c, tmp;
      a = 0;
      b = 1;
      c = n;
      while (c > 0) {
        tmp = b;
        b = a + b;
        a = tmp;
        c = c - 1;
      }
      return b;
    },
    square: function fib(n) {
      var p, q, a, b, c, tmp_1, tmp_2;
      a = q = 1;
      p = b = 0;
      c = n;
      while (c > 0) {
        if (c % 2 === 0) {
          tmp_1 = p * p + q * q;
          tmp_2 = q * (q + 2 * p);
          p = tmp_1;
          q = tmp_2;
          c = c / 2;
        } else {
          tmp_1 = (a + b) * q + a * p;
          tmp_2 = a * q + b * p;
          a = tmp_1;
          b = tmp_2;
          c = c - 1;
        }
      }
      return b;
    }
  }
};

Benchmark Script

var fibonacci_implements = require('fib.js');

var FPS_60 = Math.floor(1000 / 60);

var get_time = function() {
  return new Date().getTime();
};

var benchmark_fibonacci = function(fib_func) {
  var start_at, end_at, limit, should_step, n, i, l, score, sum;
  limit = FPS_60;
  i = 0;
  l = 100;
  score = 0;
  while (i < l) {
    should_step = true;
    n = 0;
    while (should_step) {
      n++;
      start_at = get_time();
      try {
        fib_func(n);
        end_at = get_time();
        should_step = end_at - start_at < limit;
      } catch (e) { // maybe "Stack Over Flow"
        should_step = false;
      }
    }
    score += n;
    i++;
  }
  return Math.floor(score / l);
};

(function main() {
  var type_name, sub_type_name, type, fib, time;

  console.log('::: Fibonacci Implements Benchmark :::');
  console.log('by 60 fps, each implements reach ...');

  for (type_name in fibonacci_implements) {
    if (fibonacci_implements.hasOwnProperty(type_name)) {
      type = fibonacci_implements[type_name];

      for (sub_type_name in type) {
        if (type.hasOwnProperty(sub_type_name)) {
          fib = type[sub_type_name];
          arg = benchmark(fib);
          console.log(type_name, sub_type_name, ':::', 'fib(', arg, ')');
        }
      }
    }
  }
})();

結論

確かにJavaScriptって関数呼び出しがコストになったりするので、速い実装にこだわると如何にして関数呼び出しを避けられるかっていう所に頭使うのだけど、それ以前に最速アルゴリズムが定数時間で終わるように、基本的なことまずできてからやるべきではあると思います。

それと、そもそも「O(n^2) かかるような処理でも良いじゃないか、たかが JavaScript なのだし」（過剰に委ねずにすむ方法を考える方が大事では？そんなに頑張りたいんだったらネイティブでやれ）って考え方もある。

ニコニコ超デザイン-Metro考察編-を公開しました

2012-05-04T20:56:00.000+09:00

ニコニコ超デザイン-Metro考察編-

View more presentations from Mizushima Kazuhiro

ニコニコ超デザイン-Metro死闘編-の続きです，

元々は社内勉強会の資料として作成しました
死闘編は経緯だったりネタ的な要素に走りすぎたのでデザインに関するナレッジはここにまとめてあります
より実践的かつ具体的なノウハウ等は正規リリース後あたりで公開したいと思っています

ニコニコ超会議で発表したスライドを公開しました

2012-05-02T04:39:00.000+09:00

ニコニコ超デザイン-Metro死闘編-

View more presentations from Mizushima Kazuhiro

この発表内容について

経緯として，超会議2日目の超エンジニアミーティングでは，午前にプロ生勉強会の中で，koizuka さんによる "ニコニコ超開発" の発表があり，僕がデザインで参加したニコニコ動画の MetroStyleApp の開発状況や裏話的なものはもう話されていたのですが，LT枠が余ったというのと，午前中講演に行けなかった人用に，「天丼芸」として用意し，発表したのがこの内容です

本来なら，もっと有用な「Metro Style App のデザインの勘所ってどこよ?」とか「プログラマーとのスムーズなやり取りが出来るデザインワークフローってどうやるの?」とか，そういった内容をプレゼンすべきだったのですが…

どう考えても 5分でまとめ切れないというのと，自身がまだそれをキチンとしたカタチで整理できていないところもあり，「逼迫した状況で出来るだけ，やるだけやるしかなかった」感が伝わりさえすればいいやと思い，来場者の方には最後に笑って締めていただこうとこのようなカタチになりました

おわりに-ニコニコ超会議に参加された皆様へ御礼

2012/04/28-29 に幕張メッセでニコニコ超会議が行われ，来場してきてくださったユーザーの皆様，企画に登壇者として参加してくれた皆様に再度お礼を申しあげます．

BDD on Haskell その5 : テスト用ユーティリティ関数など

2012-03-09T15:19:00.000+09:00

前回までのエントリーはこちら

今回はテストコードを手早く書く為のユーティリティを紹介

例1 TemplateHaskell を使う

test-framework-th というライブラリを利用すると，関数の先頭に case_ prop_ というプレフィックスがあるものを自動的にテストユニットに組み入れてくれる

{-# LANGUAGE TemplateHaskell #-}

import Test.Framework.TH ( defaultMainGenerator )
import Test.Framework ( defaultMain, Test )
import Test.Framework.Providers.HUnit ( testCase )
import Test.Framework.Providers.QuickCheck2 ( testProperty )
import Test.HUnit ( (@=?) )

main :: IO ()
main = $(defaultMainGenerator)

case_10_div_2 = 5 @=? (10 `div` 2)

prop_add_commutative x y = x + y == y + x
    where types = (x :: Int, y :: Int)

テスト実行

$ runhaskell test.hs
Main:
  add commutative: [OK, passed 100 tests]
  10 div 2: [OK]

        Properties  Test Cases  Total
Passed  1           1           2
Failed  0           0           0
Total   1           1           2

プレフィックスに続く関数名をテストのラベルとして表示してくれる．これは便利だし，手早くテストコードを書く際はこれで良いと思う

例2 自作のユーティリティ関数

ただ，TH を使ったこれらだと，たくさんテストケースを記述したりするのが億劫でもある．よくコンパクトに設計したライブラリであれば，テストしたい対象は2つのパターンに収まる

ライブラリで宣言した代数データ型に，いくつかの関数を適用するテスト
ライブラリで宣言した関数に，いくつかの引数を与えて検証するテスト

そこで，自分は以下のユーティリティ関数を自作して使ってる

module Util.Test (
  subject, should,
  (<-?), (<=?), (+:), (-:), (*:), (%:), (/:)
 ) where

import Test.Framework ( testGroup, Test, TestName )
import Test.Framework.Providers.HUnit ( testCase )
import Test.Framework.Providers.QuickCheck2 ( testProperty )
import Test.HUnit ( (@=?), Assertion )
import Test.QuickCheck ( Testable )

infixr 5 +:, -:, *:, %:, /:
infixr 6 <-?, <=?

subject :: TestName       -- test label
           -> a           -- subject function
           -> [a -> Test] -- tests about subject
           -> Test
subject label target = testGroup label . map ($ target)

should :: TestName                 -- test label
          -> t                     -- expected value
          -> (t -> b -> Assertion) -- test assertion operator
          -> (a -> b)              -- function return actual value
          -> a                     -- subject
          -> Test
should label expected op fn = testCase label . op expected . fn

(<-?) :: (Show a, Show b, Eq b) =>
          b           -- expected value
          -> a        -- argument for subject function
          -> (a -> b) -- subject function
          -> Test
expected <-? arg = testCase detail . ( expected @=? ) . ($ arg) where
  detail = unwords
           [ "λ", show arg, "\t->", show expected ++ "\t" ]

(<=?) :: (Show b, Eq b) =>
         b           -- expected value
         -> (a -> b) -- function return actual value
         -> a        -- argument for subject function
         -> Assertion
expected <=? fn = (expected @=?) . fn

(-:) :: TestName -> Assertion -> Test
n -: t  = testCase n t

(+:) :: TestName -> (a -> Assertion) -> a -> Test
n +: f  = testCase n . f

(*:) :: Testable a => TestName -> a -> Test
n *: p  = testProperty n p

(%:) :: Testable b => TestName -> (a -> b) -> a -> Test
n %: f  = testProperty n . f

(/:) :: TestName -> [Test] -> Test
l /: ts = testGroup l ts

リファクタリング -- 見やすいテストコード

これがどう便利かというと，今まで書いていた quotF, remF などのテストコードがこのように記述できる

import Util.Test

testSuite :: [Test]
testSuite =
  [ "example" /:
    [ subject "\\(x, y) -> x `quotRem'` y" (uncurry quotRem')
      [ Left DivideByZero <-? (   1,   0)
      , Right ( 12,  2)   <-? ( 122,  10)
      , Right (-12,  3)   <-? ( 123, -10)
      , Right (-13,  7)   <-? (-123,  10)
      , Right ( 13,  7)   <-? (-123, -10)
      , Right (  4,  0)   <-? (  10,   2.5)
      , Right (  1,  1.5) <-? ( 4.5,   3)
      , Right ( -1, 29.9) <-? (-0.1,  30)
      ]
    , subject "\\(x, y) -> x `quot'` y" (uncurry quot')
      [ Left DivideByZero <-? ( 1, 0)
      , Right          12 <-? ( 123, 10)
      ]
    , subject "\\(x, y) -> x `rem'` y" (uncurry rem')
      [ Right 3    <.? (123, 10)
      , Right 0.1  <.? (4.7, 2.3)
      ]
    ]
  , "specification" /:
    [ "(q, r) = (quot' x y, rem' x y)" /:
      [ "x - y * q + r (0 <= r < |y|)" *: prop_quotRem'
      , "(q, r) = quotRem' x y"        *: prop_synonym
      ]
    ]
  ]

prop_quotRem' :: Double -> Double -> Bool
prop_quotRem' x y =
  case (x `quot'` y, x `rem'` y) of
    (Left _, Left _)   -> y == 0
    (Right q, Right r) ->
      if r == 0
      then (x .= (fromIntegral q * y)) tolerance
      else 
       (x .= (fromIntegral q * y + r)) tolerance
       && 0 < r && r < abs y
    _ -> False -- any mistake definition

prop_synonym :: Double -> Double -> Bool
prop_synonym x y =
  case (x `quot'` y, x `rem'` y, x `quotRem'` y) of
    (Left  _, Left  _, Left   _)       -> y == 0
    (Right q, Right r, Right (q', r')) -> (q, r) == (q', r')「
    _ -> False -- any mistake definition

-- adhock utility
(<.?) :: (Show b, Show e, Ord e) =>
          Either e Double -> b -> (b -> Either e Double) -> Test
expected <.? arg = should label expected eq' ($ arg) where
  label = intercalate " " keys
  keys =
    [ "λ", show arg
    , "\t->", show expected
    , "(±", show tolerance, ")"
    ]
  eq' (Right x) (Right y) =
    unless ( abs (x - y) < tolerance ) $
    assertFailure $ msg x y tolerance
  msg x y t = intercalate "\n"
  [ "\n expected\t : "   ++ show x
  , " but got\t : "      ++ show y
  , " out of trancate: " ++ show t
  ]

tolerance :: Double
tolerance = 1e-10

testSuite の宣言とか，RSpec にも負けない可読性だと思うのだけど，どうだろう．このユーティリティを使うユーザーのテストコードは，subjectにテストの対象となる関数あるいはデータ型を第二引数に渡し，第三引数に「(期待値)<-? (引数)」のリストを列挙する仕組みになる．

テスト実行後の出力

example:
  \(x, y) -> x `quotRem'` y:
    λ (1.0,0.0)       -> Left divide by zero   : [OK]
    λ (122.0,10.0)    -> Right (12,2.0)        : [OK]
    λ (123.0,-10.0)   -> Right (-12,3.0)       : [OK]
    λ (-123.0,10.0)   -> Right (-13,7.0)       : [OK]
    λ (-123.0,-10.0)  -> Right (13,7.0)        : [OK]
    λ (10.0,2.5)      -> Right (4,0.0)         : [OK]
    λ (4.5,3.0)       -> Right (1,1.5)         : [OK]
    λ (-0.1,30.0)     -> Right (-1,29.9)       : [OK]
  \(x, y) -> x `quot'` y:
    λ (1,0)     -> Left divide by zero: [OK]
    λ (123,10)  -> Right 12: [OK]
  \(x, y) -> x `rem'` y:
    λ (123.0,10.0)    -> Right 3.0 (± 1.0e-10 ): [OK]
    λ (4.7,2.3)       -> Right 0.1 (± 1.0e-10 ): [OK]
specification:
  (q, r) = (quot' x y, rem' x y):
    x - y * q + r (0 <= r < |y|): [OK, passed 100 tests]
  (q, r) = quotRem' x y: [OK, passed 100 tests]

        Properties  Test Cases   Total
Passed  2           12           14
Failed  0           0            0
Total   2           12           14

テストケースのラベルが「引数 -> 期待値」というパターンになり，subject に渡した関数が具体的に何をテストしたかが一目瞭然になる．

TDD/BDD で一番煩わしいのって，テストケースを書き足していく時なので，こうやって関数に対する引数と戻りの期待値を列挙するだけで済むようなユーティリティを書いていくとラクになるし，テスト結果も，開発者以外の目で見ても，何が出来ているかチェックしやすくなる．

TemplateHaskell を利用しなくても，このような DSL Like なユーティリティを自作できるので，色々試してみると良い．ある程度まとまったら，更にそれらをより簡潔に記述できるように TemplateHaskell を利用するのも良い．

自分も今後，これをもっと整理して Hackage で公開しようかと思う

BDD on Haskell チュートリアルその4 : リファクタリングとパフォーマンスチューニング

2012-01-31T20:27:00.000+09:00

前回までのエントリーはこちら

今回のテーマ「テスト済みのモジュールのパフォーマンス改善」

前回までで一通りの TDD / BDD によるアプローチで，Scheme RSR6 の div-and-mod に相当する関数群のモジュールは実装できた．
ゼロ除算時におけるエラーも，Either モナドで包む事で，より正確な型による関数の表現もでき，テストもほぼ完璧．

これでもう一切の問題も無いのでは… と思いきやまだ一つ懸念すべきことが残されている．

パフォーマンスとスケールである．

現時点のパフォーマンス

今の時点での quotRemF, quotF, remF のコードは以下のようになっている

quotRemF :: (Num a, Num b, Ord b) => b -> b -> Either ArithException (a, b)
quotRemF _ 0 = divZeroError
quotRemF x y = Right $ iter x y 0 where
 iter r k q
  | r == 0 = (q, 0)
  | 0 < r && r < abs k = (q, r)
  | otherwise = iter (r `step` k) k (next q)
 step a b
  | x * y >= 0 = a - b
  | otherwise  = a + b
 next n
  | x * y >= 0 = n + 1
  | otherwise  = n - 1

quotF :: (Num a, Num b, Ord b) => b -> b -> Either ArithException a
quotF x y = fmap fst $ quotRemF x y

remF :: (Num b, Ord b) => b -> b -> Either ArithException b
remF x y = fmap snd $ quotRemF x y

divZeroError :: Either ArithException a
divZeroError = Left DivideByZero

BDD on Haskell チュートリアルその1 : HUnit で TDD をで，あくまでも「テストが通ること」を主眼において実装されていたのだけど，この実装では「巨大な数と，ごく小さい数から商と余剰を計算する」場合とてもコストがかかる．この関数のオーダーは O(n) になっているからだ

$ ghci Util.Numeric
Util.Numeric> 1e20 `remF` 0.3
# いつまでたっても計算が終わらない

もう一つは，浮動小数点をそのまま再帰で加算させ続けているので，たとえば 10000 という数に対して，0.3 の余剰を求めようとすると，33333回誤差が広がる事になる．これではモジュールとしての完成度は低い

テストを担保にリファクタリングする

HUnit, QuickCheck でのテストは成功している状態なので，それを担保にしてリファクタリングをする．
まず，今現在の関数の関係を見ると

quotRemF :: 独立
quotF :: quotRemF に依存
remF  :: quotRemF に依存

という実装になっている．そして，テストの方で

quotRemF x y が 返す (q, r) は， q = quotF x y と同じ

ことを保証している．

これを利用して，浮動小数点小数の誤差が出ない関数 quotF をリファクタリングして，テストが通り次第 quotRemF の実装に置き換えれば良さそうである

`Data.Fixed.div'` を参考にする

-- Data.Fixed

-- | generalisation of 'div' to any instance of Real
div' :: (Real a,Integral b) => a -> a -> b
div' n d = floor ((toRational n) / (toRational d))

標準ライブラリの Data.Fixed にある div' (浮動小数点小数含む実数同士の商) はこのように実装されていた．floor は小数を小さい方向に丸めるので，たとえば -0.1 は -1 に丸められる (0.1 は 0 に丸める)．この性質を利用すると，必ず「余りの絶対値が0により近い方」で出せる．
これを参考にして，「検算して，余剰がマイナスだったら調整して結果を出す」ようにしてみれば，必ず定数時間内に計算が終わるように出来るのではないだろうか．あ，あと今気づいたけど quotF の戻りの型が正しくない．商は整数である事をちゃんと型で示しておこう

-- 修正
quotF :: (Real a, Integral b) =>
         a -> a -> Either ArithException b
quotF _ 0 = divZeroError
quotF x y = Right . adjust . floor $ rate x y
  where
  rate n m = toRational n / toRational m
  adjust n = if prove n < 0 then n + 1 else n
  prove  n = x - fromIntegral n * y

こうやって書き換えた後に，テストで検証してみる

$ ghci UnitTest.Util.NumericTest
*UnitTest.Util.NumericTest> :m + Test.QuickCheck
*UnitTest.Util.NumericTest Test.QuickCheck> quickCheck prop_quotF
++ OK, passed 100 tests
*UnitTest.Util.NumericTest Test.QuickCheck> quotF 1e+50 0.3
Right 333333333333333371101710855030252968956534903824135

リファクタリングに成功しているようだ．数が巨大すぎるので，もう誤差そのものはどうしようもないけど，計算は定数時間 O(1) で出る

テストで外堀を埋めつつリファクタリング

リファクタリングに成功してる quotF を足がかりに，残りの quotRemF, remF をリファクタリングする．
再度 quotF, remF の関係をおさらいすると

prop_quotF_and_remF x y = case (quotF x y, remF x y) of
  (Left _, Left _)   -> y == 0
  (Right q, Right r) ->
      if r == 0 then
         x .== fromIntegral q * y
      else
         x .== fromIntegral q * y + r
  _ -> False -- そもそも実装が失敗している
  where
  n .== m = abs (n - m) <= 1e-5
  -- 誤差が 0.00001 以下 で「近似している」とみなす

このテストが通る事を維持しながら，remF をリファクタリングする

remF x y = fmap prove $ quotF x y
  where
  prove n = x - fromIntegral n * y

リファクタリング後のコードを見てみると，where 節で定義した検算の為の関数 prove n = x - fromIntegral n * y の宣言が quotF にも remF にもある，これは共有化できそうだ．

quotRemF _ 0 = divZeroError
quotRemF x y = Right . pair . adjust . floor $ rate x y
  where
  rate n m = toRational n / toRational m
  adjust n = if prove n < 0 then n + 1 else n
  prove  n = x - y * fromIntegral n
  pair   n = (n, prove n)

quotRemF の宣言は「x と y の比率を計算し，より小さい整数へ丸め，検算した結果で商を調整し，再度検算した余りと対にして返す」と読める
quotRemF が効率のよい実装になったので，quotF, remF はそこから参照するようにする

quotF x y = fmap fst $ quotRemF x y
remF  x y = fmap snd $ quotRemF x y

これは元の実装と同じですね

まとめ

実装の仕様を変更する際は

テストから変更する
テストに失敗したのを確認する
再度テストが通るように実装を修正する

リファクタリングの際は

実装を修正する
テストに失敗せず，実装を修正してもテストが通る事を確認する
もしテストが失敗しても，テストに手を加えず，実装を見直す

実装の仕様を変更する時は，テストから変更し，リファクタリングはテストを固定させ「最終的な挙動は変わってない」ことを保持できるようにする．

次回はテストをより効率よく，手早くやるためのユーティリティ関数の自作を紹介

BDD on Haskell チュートリアルその3-3 : 仕様変更はテストから

2012-01-10T09:23:00.000+09:00

前回までのエントリーはこちら

今回のテーマ - 「テスト済みのモジュールの仕様変更」

前回書いたように，IO が絡まないはずの関数群に Exception を throw させるよりは Either <Error> <Success> というパターンで型をつけてあげた方が設計としては親切だ．
というわけで今回は，「テスト済みのモジュールに仕様変更を加える」実例として， quotF remF の返す型を変更し，もっと良いモジュールへ書き換え，テストもより完璧なものにする取り組みをやってみる

`throw Exception` する関数に対するテスト

前回「例外はテストしずらい」と書いた．一応テストする術はある

使うモジュールたち

テストモジュールに以下をインポートする ( test-framework, HUnit, QuickCheck2 がインストールされている前提 )

import Test.Framework.Providers.HUnit ( testCase )
import Test.Framework.Providers.QuickCheck ( testProperty )
import Test.HUnit ( @=? )
import Test.QuickCheck ( Property, (==>) )
import Control.Exception

例外テスト - Hunit

HUnit では assertTrue などを使って，スローされた例外が，求めている型と等しいかチェックするように書く

testCase "throw Exception" testDivZero
-- ...
testDivZero = IO (Left DivideByZero) @=? divZero where
 divZero = try (evaluate (1 `div` 0) :: ArithException )

例外テスト - QuickCheck

QuickCheck では，例外がスローされる条件と，スローされたものが期待する例外型と同じ事をコードで示せば良い

testProperty "if denom is 0, throw Exception" prop_divZero

prop_divZero :: Int -> Int -> Property
prop_divZero x y =
  y == 0 ==>
  IO (Left DivideByZero) == (try (evaluate (x `div` y) :: ArithException))

IO が不要なのに throw を検証する事の不快な理由

まぁ，こんな風に例外を投げる関数も，その投げる例外についても検証できるから「これでも別に良いのでは」と思うかもしれない．けれど，"純粋"という言葉が好きなはずの Haskeller 諸氏はこれで甘んじてはいけないだろう．理由は以下である

「何をテストしたいんだか」純粋でなくなる

上記の例で見るように，例外を捕捉する為に目的の関数を evaluate で IO モナドに持ち上げてテストすると，結果として見た場合「これは本来 IO によらない」モジュールである事がわかりづらくなる．

そして， try で例外をとらえて assertEqual で，期待している値と比較するわけだけど，元々検証したい関数は "div" であって，evaluate や try が「完璧」である事に依存しているし，何を本当に検証したいか簡潔明確でない

モジュールの目的の曖昧化

そして，仮に例外を投げうる関数をこのようにテストしきった後のテストコードは，そのコードを直接さわった開発者以外から見た時に，モジュールの目的が曖昧に見える．「ん? IO に関係あるの?」「これって整数以外にも何か別の型返すの?」というように．

もちろん，IO に関係する，HTTP Request, Response などに使うユーティリティのモジュールであれば，try, catch はあって良いだろう (というか，それが本来の正しい使い方)

けれど，IO に関係なく動作するはずの純粋な関数を束ねるモジュールであれば,出来るだけ「呼ぶことが無かったはずの外部のモジュール，モナド」を組み込んでテストしたのでは，モジュール自体の設計にミスがあるようなものだ．
(だって，そのモジュールだけじゃマトモに使えないって言ってるようなものだしね)

テストから修正

TDD / BDD の基本にのっとり，テストの方から仕様を変更しよう
今までのコードは BDD on Haskell チュートリアルその2 : QuickCheck でランダムテストを参照

UnitTest/Util/NumericTest.hs

-- ...
  testCase "y = 0" -: ((Left DivideByZero) @=? (1 `quotF` 0)
, testCase "0 < y < x" -: ((Right 3) @=? (4.5 `quotF` 1.5))
-- ...

こんな風に「ゼロ除算をしていたら (Left DivideZero), していなければ (Right <期待する計算結果の値>)」という風にテストコードを書き換えていく．
QuickCheck の為のテストコードも以下のように変更する

-- ...
prop_quotRemF :: Double -> Double -> Bool
prop_quotRemF x y = case x `quotRemF` y of
  Left e -> y == 0 && e == DivideByZero
  Right (q, r) ->
      (x .= q * y + r) 1e-5
    && 0 <= r
    && r < abs y
-- ...

こちらは，

x と y を quotRemF の引数に渡し，結果が
Left e であれば ->
  y は必ず 0 で，e は DivideByZero
Right (q, r) であれば ->...

という風に読めるはず．

さきほどの evaluate, try で例外をやりこめてテストするよりも綺麗だしわかりやすくなる．

再度検証して，実装を修正

そしてテストを実行しようとすると，確実にコンパイルエラーで実行さえ出来なくなっているはず．

TDD / BDD に馴染みの無い人だったら，ここでかなりの抵抗感があるだろうけど，こうやって「テストから手を加える」→ 「テストを何かしら失敗する」→ 「テストを成功させるよう実装を修正する」は大事なファクターなので徹底しよう．

間違いの存在を見つけようとするよりも，間違いを正そうとする方がかかる労苦は圧倒的に少なく，そして確実に実りがある

Util/Numeric.hs

import Control.Exception ( ArithException(..) )
import Control.Monad.Instances

quotRemF :: (Num a, Num b, Ord b) => b -> b -> Either ArithException (a, b)
quotRemF _ 0 = divZeroError
quotRemF x y = Right $ iter x y 0 where
 -- ...

quotF :: (Num a, Num b, Ord b) => b -> b -> Either ArithException a
quotF x y = fmap fst $ quotRemF x y

remF :: (Num b, Ord b) => b -> b -> Either ArithException b
remF x y = fmap snd $ quotRemF x y

-- private functions
divZeroError :: Either ArithException a
divZeroError = Left DivideByZero

前回までのコードに対して，変更するのはこれだけ．やった事は

quotRemF, quotF, remF の返す値を Either ArithException <a> に変更
divZeroError の実装を throw DivideByZero から Left DivideByZero に変更
quotRemF の成功した場合の結果に Right コンストラクタを加えただけ
quotF, remF は fmap を加えただけ
fmap の性質を利用して quotF, remF の条件分岐は省略できた

fmap f $ Left x  = Left x
fmap f $ Right x = Right $ f x

Control.Monad.Instances モジュールをロードした後は Either 型は Functor のインスタンスになるので， fmap を適用すると上記のような処理になる．Left Error ならそのまま何もせず，Right x であれば内部の x に f を適用して， Right に包み直す

コンパイルエラーで何も出来なくなって焦ったかもしれないけど，修正はごくわずかで済んだ

テストしてみよう

$ runhaskell UnitTest/Util/NumericTest.hs
quot and rem for Fractional:
  example:
    y == 0: [OK]
    x = qy: [OK]
    x = qy + r: [OK]
    x < 0, 0 < y: [OK]
    x < 0, y < 0: [OK]
    0 < x, y < 0: [OK]
    0 < x, 2 < y < 3: [OK]
    x < 0, 2 < y < 3: [OK]
    2 < y < 3, 4 < x < 5: [OK]
  specification:
    x = qy + r (0 <= r < |y|): [OK, passed 100 tests] #|a|
    quotF = fst (q, r): [OK, passed 100 tests]
    remF  = snd (q, r): [OK, passed 100 tests]

         Properties  Test Cases  Total
 Passed  3           9           12
 Failed  0           0           0
 Total   3           9           12

ちゃんとテストに成功している事がわかる

まとめ

モジュールの仕様を変更する時はテストを直す
テストに通るようモジュールを修正する
IO を併わないモジュールは Either <Error> <Success> 型パターンで

これが今回のまとめ．次回はリファクタリングとパフォーマンスチューニング

おまけ

よく考えてみたらこの連載用にソースを GitHub に上げて，コミットのチェンジログを貼るのが一番良いような気がした…

再現するの時間かかるけどそっちの方が見やすいわな…

BDD on Haskell チュートリアルその3-2 : throw Exception を使わず基本は Either を使おう

2012-01-06T12:44:00.000+09:00

前回の続き．前回までのエントリーはこちら

「どちらか」を表現する `Either` 型

Control.Exception の try catch finally はそもそも IO モナドで利用される事を想定している．つまり外部からの入力や Haskell の実行結果を出力する境界で発生する予期しない事態に対応する為のものだ．

なので，IO に本当は依存してないはずの論理計算や算術演算で Haskell の try throw をもっぱら使うのは妙な話．ではどうすれば良いか．

例えば x / 0 は数学的に無意味，または未定義とされている．あともっと具体的な例だと，色彩計画における HSL, HSV 色空間の無彩色(彩度が0%，黒から灰，白の色彩の無い色) での色相の角度 (Hue) なども実際は未定義の値．
このような「何かを求めるが，場合によっては別のモノを結果として出さないといけないかも」という計算を型で表現するには Either 型を使う．

data Either a b = Left a | Right b             -- Defined in Data.Either
instance (Eq a, Eq b) => Eq (Either a b)       -- Defined in Data.Either
instance (Ord a, Ord b) => Ord (Either a b)    -- Defined in Data.Either
instance (Read a, Read b) => Read (Either a b) -- Defined in Data.Either
instance (Show a, Show b) => Show (Either a b) -- Defined in Data.Either

Either は「この関数は任意型 a か任意型 b を返す」という事を表現できる．慣例として，よく Left コンストラクタにエラーや未定義を示す型を， Right コンストラクタに正常動作した場合の結果を返すように利用する．

throw Exception のパターンを使って，特定の条件で例外を投げるようにするよりも，最初から返り値を Either 型で宣言した方が，ライブラリの利用者にとって「あ，この関数は場合によってエラーになりうるんだな」という事が明確になる．

前回で取り上げたControl.Exception の try は，汎用的にその関数の評価結果をエラーか正常動作の結果かを Either モナドで包む関数となっている．

`throw` しないで `Either` で異常値，未定義値を包む

前回哀しい事実をつきつけてくれたData.Fixed の div' mod' のあの憎い感じを Either で解決してみよう

-- Sample.Fixed.hs

module Sample.Fixed where

import qualified Data.Fixed as F
import Control.Exception
import Prelude hiding ( div, mod, divMod )
import qualified GHC.Real as R

divZero :: Either ArithException a
divZero = Left DivideByZero

div' :: (Real a, Integral b) => a -> a -> Either ArithException b
div' _ 0 = divZero
div' x y = Right $ F.div' x y

mod' :: Real a => a -> a -> Either ArithException a
mod' _ 0 = divZero
mod' x y = Right $ F.mod' x y

divMod' :: (Real a, Integral b) => a -> a -> Either ArithException (b, a)
divMod' = pairEither div' mod' divZero

div :: Integral a => a -> a -> Either ArithException a
div _ 0 = divZero
div x y = Right $ R.div x y

mod :: Integral a => a -> a -> Either ArithException a
mod _ 0 = divZero
mod x y = Right $ R.mod x y

divMod :: Integral a => a -> a -> Either ArithException (a, a)
divMod = pairEither div mod divZero

pairEither f g e x y = case (f x y, g x y) of
  (Right n, Right m) -> Right (n, m)
  _ -> e

これで，div div' はそれぞれ，ゼロ除算に至った場合 ArithException を持つ Either 型の関数になった．

Either と Maybe

Either 型と Maybe は似てる．違いは

Either: 「B か A か」
Maybe: 「何も無いか A」

二つとも「期待しているのが無ければ引数のデフォルトを使って，任意型a の値を返す」関数が用意されている． either と maybe だ

-- Data.Either
either :: (b -> c) -> (a -> c) -> Either b a -> c

either (const 0) id $ Left "error" -- 0
either (const 0) id $ Right 10     -- 10

-- やってることはこれと同じ
myEither f g (Left x)  = f x
myEither f g (Right x) = g x


-- Data.Maybe
maybe :: b -> (a -> b) -> Maybe a -> b

-- Data.List
find :: (a -> Bool) -> [a] -> Maybe a

maybe (-1) id $ find (< 2) [3..100] -- -1
maybe (-1) id $ find (< 4) [3..100] --  3

-- やってることはこれと同じ
myMaybe y f Nothing  = y
myMaybe y f (Just x) = f x

「試しにやってみて，失敗したらデフォルト値でいいや」っていう場合ならこの関数で Either や Maybe で包んだ元の型が取れる

Control.Monad.Instances モジュールをインポートすれば，Either も Maybe も Monad , Functor のインスタンスとして利用できる. つまり Either も Maybe もモナドの一つだし，ファンクタでもある

find (< 2) [3..100] >>= return . (\x -> x + x) -- Nothing
find (< 4) [3..100] >>= return . (\x -> x + x) -- Just 6

fmap (\x -> x + x) $ find (< 2) [3..100] -- Nothing
fmap (\x -> x + x) $ find (< 4) [3..100] -- Just 6

Left "error" >>= return . (\x -> x + x) -- Left "error"
Right 3 >>= return . (\x -> x + x)      -- Right 6

fmap (\x -> x + x) $ Left "error"  -- Left "error"
fmap (\x -> x + x) $ Right 3       -- Right 6

「試しにやってみて，失敗しても今はスルーして処理続行させよう」という場合ならこの関数で，型の情報そのままに正常系動作の継続処理を記述できる

例外とか例外処理とか要らなかったのでは

このように IO の境界の内側での処理を Maybe や Either で「失敗もする関数の型」として扱う事で他の言語のような「どこで例外起きてるの…」と苦悩することなく「絶対うまくいく」処理と「うまくいかないかも」という処理を型で表現できる．

そして，「うまくいかないかも」という処理を型で表現した時に「うまくいかなかったら代替使う」「うまくいった場合にこれをさせる」という高階関数がすでに標準ライブラリで用意されてるので，これらを使って設計する事でハナから「例外とか無くて良いのでは」と思えるほど余計なエラーでストレスなくプログラミングが出来る．

次回は Either を使って，今まで書いた quot' rem' のテストと実装を改良する

BDD on Haskell チュートリアルその3-1 : catch できない哀しみ

2012-01-06T12:30:00.000+09:00

前回までのエントリーはこちら

前回までで，ほぼ TDD BDD の基本は書いたのだけど，今回は例外について．

Haskell の例外処理

Haskell も普通の言語よろしく，例外処理は throw try catch 使える．けれど IO が絡んでくる場合でないとあまり有用ではない印象．

throw try catch

Haskell の try catch throw finally は Control.Exception モジュールで定義されている．それぞれの型はこのようになっている

try :: Exception e => IO a -> IO (Either e a)

-- Prelude で宣言されてる catch
catch :: IO a -> (IOError -> IO a) -> IO a

-- Control.Exception で宣言されてる catch
catch :: Exception e => IO a -> (e -> IO a)

throw :: Exception e => e -> a

finally :: IO a -> IO b -> IO a

evaluate :: a -> IO a

こんな風に使う

-- Sample/TryCatchArith.hs
module Sample.TryCatchArith where

import Control.Exception
import Prelude hiding ( catch ) -- Prelude の catch は不可視にしておく

-- ゼロ除算例外を投げる場合
divZeroError = throw DivideByZero

-- スローされた例外を catch したい場合
catchArith :: Num a => a -> a -> IO a
catchArith proc alt = catch (evaluate proc) handler
  where
    handler e = print (e :: ArithException) >> return alt

-- Haskell 的 try
tryArith :: Num a => a -> IO (Either ArithException a)
tryArith proc = try (evaluate proc)

try catch はそれぞれ IO モナドを引数に取って，規定の例外型 Exception が投げられた時に何かしらのハンドリングをする．

catch はユーザー側でその時の処理を関数で渡して，IO モナドの中身の型と同じ型の代替値を返せば良く， try は Either モナドに包んで，例外だったら Left へ，正常に動作した結果であれば Right に値を格納する． Either については後述．

試してみる

$ ghci Sample.TryCatchArith
*Sample.TryCatchArith> catchArith ( 1 `div` 0 ) 0
divide by zero
0
*Sample.TryCatchArith> catchArith ( 6 `div` 3 ) 0
2
*Sample.TryCatchArith> tryArith $ 1 `div` 0
Left divide by zero
*Sample.TryCatchArith> tryArith $ 6 `div` 3
Right 3
*Sample.TryCatchArith> divZeroError
*** Exception: divide by zero
*Sample.TryCatchArith> :t divZeroError
divZeroError :: a

Haskell の try catch throw はいずれも単なる関数で，他の言語のようなシンタックスキーワードではない．経緯として Control.Exception は後発のモジュールだったりする．

`Data.Fixed div' mod'` に見る `try catch` の問題点

Haskell base ライブラリには浮動小数点小数の型向けの余剰を計算するモジュールがある． Data.Fixed モジュールの div', mod', divMod' がそれにあたる．この関数の挙動は Scheme RSR6 の div0-and-mod0 と同じ．つまり，余剰の絶対値が0により近い方で計算をする．

$ ghci
Prelude> :m + Data.Fixed
Prelude Data.Fixed> :t div'
div' :: (Real a, Integral b) => a -> a -> b
Prelude Data.Fixed> :t mod'
mod' :: Real a => a -> a -> a
Prelude Data.Fixed> :t divMod'
divMod' :: (Real a, Integral b) => a -> a -> (b, a)
Prelude Data.Fixed> divMod' 4.7 2.3
(2,0.10000000000000053)
Prelude Data.Fixed> divMod' (-4.7) 2.3
(-3,2.1999999999999993)
Prelude Data.Fixed> divMod' 4.7 (-2.3)
(-3,-2.1999999999999993)
Prelude Data.Fixed> divMod' 1 0
(*** Exception: Ratio.%: zero denominator

divMod' でのゼロ除算で投げられる例外は単純にメッセージを投げられているので型が無い

$ ghci
Prelude> :m + Data.Fixed
Prelude Data.Fixed> let x = 1 `div'` 0
Prelude Data.Fixed> :t x
x :: Integer
Prelude Data.Fixed> x
*** Exception: Ratio.%: zero denominator

ソース見てみる

最新の GHC のソースでどうなってるか見てみると

-- | generalisation of 'div' to any instance of Real
div' :: (Real a,Integral b) => a -> a -> b
div' n d = floor ((toRational n) / (toRational d))

-- | generalisation of 'divMod' to any instance of Real
divMod' :: (Real a,Integral b) => a -> a -> (b,a)
divMod' n d = (f,n - (fromIntegral f) * d) where
    f = div' n d

-- | generalisation of 'mod' to any instance of Real
mod' :: (Real a) => a -> a -> a
mod' n d = n - (fromInteger f) * d where
    f = div' n d

div' は引数を toRational で Ratio 型に変換してから除算している. で， Ratio 型の実装で， (/) の右辺に 0 が渡された場合に

error "Ratio.%: zero denominator"

でエラーメッセージのみの例外がスローされている，という仕組み．この為標準の ArithException で例外をキャッチできない (!!)

$ ghci Sample.TryCatchArith
*Sample.TryCatchArith> tryArith $ 1 `div` 0 -- 例外キャッチできる
Left divide by zero
*Sample.TryCatchArith> :m + Data.Fixed
*Sample.TryCatchArith Data.Fixed> tryArith $ 1 `div'` 0 -- 例外キャッチできない
*** Exception: Ratio.%: zero denominator

そういうの，ほんとやめてほしい．

例外処理はテストしずらい

上記の例で見てわかる通り， throw や error でもって例外を投げるのは書く方こそ簡単ではあるけれど，利用側にとっては

ソース読まない限り例外が来るかどうかわからない
遅延評価で，その値が必要な時が来るまで例外発生しない

という問題がある．たとえば開発中にどこかで Exception でひっかかって，調査してみようとして REPL で適当に関数を叩いたりしても，

型情報に例外が明記されないので例外の型がわからない
どんな例外型が来るか，プログラマが頭で推定して対処しないといけない
例外が投げられている関数がコールスタックの深部にあると探すのが大変

などが考えられる．あと単純にテストコードも try 使ったりして面倒この上ない

というわけで，次回は「テストしやすくする為の」throw Exceptionの代替として Either型を使ってモナディックに解決するという事をやる．

おお，単純なライブラリ開発を初心者向けに書いてみるって趣旨でちゃんとモナド出てきたぞ

BDD on Haskell チュートリアルその2 : QuickCheck でランダムテスト

2012-01-01T08:00:00.000+09:00

新年のご挨拶

あけましておめでとうございます．

2012年は Schemer, Haskeller にとって飛躍の年でありますよう心から願う所存であります．

デザインについてはあと最終勧告まで2年を切った HTML 5 がそびえたつクソにならない事を切に祈り，ユーザビリティ，アクセシビリティ，ユースケース，UX をガン無視した「CSS3だけで出来たなんちゃらかんちゃら」「美麗なビジュアルエフェクトを実現する jQuery プラグイン」で衆目を集めてなんちゃってクリエイティブ気分を味わってる人たちが滅亡してくれる事を期待しています

前回までのエントリー

今回は QuickCheck を使ってランダムテストを取り入れた BDD について

前回までのおさらい

前回までのエントリーで，プロジェクトはこのようになった．テスト結果を受けて型情報を追加していたり，テストコードを読みやすくする為のユーティリティ演算子を追加している．

ソースツリー

app/
 |- src/
 |   |- Util/
 |   |   `- Numeric.hs
 |   `- UnitTest/
 |       `- Util/
 |           `- NumericTest.hs
 |- app.cabal
 |- Setup.hs
 |- LICENCE
 `- README/

app/src/Util/Numeric.hs

module Util.Numeric where

quotRemF :: (Num a, Num b, Ord b) => b -> b -> (a, b)
quotRemF x y = iter x y 0 where
 iter r k q
  | r == 0 = (q, 0)
  | 0 < r && r < abs k = (q, r)
  | otherwise = iter (r `step` k) k (next q)
 step a b
  | x * y >= 0 = a - b
  | otherwise  = a + b
 next n
  | x * y >= 0 = n + 1
  | otherwise  = n - 1

quotF :: (Num a, Num b, Ord b) => b -> b -> a
quotF x y = fst $ quotRemF x y

remF :: (Num b, Ord b) => b -> b -> b
remF x y = snd $ quotRemF x y

app/src/UnitTest/NumericTest.hs

module UnitTest.Util.Numeric where

import Test.Framework ( defaultMain, testGroup )
import Test.Framework.Providers.HUnit ( testCase )
import Test.HUnit ( (@=?) )

import Util.Numeric

main = defaultMain testSuite

testSuite = [
    "quot and rem for Fractional" /: [
      "example" /: [
          "x = qy"           -: (( 12, 0)  @=? (  120  `quotRemF` 10))
        , "x = qy + r"       -: (( 12, 7)  @=? (  127  `quotRemF` 10))
        , "x < 0, 0 < y"     -: ((-13, 7)  @=? ((-123) `quotRemF` 10))
        , "x < 0, y < 0"     -: (( 13, 7)  @=? ((-123) `quotRemF` (-10)))
        , "0 < x, y < 0"     -: ((-12, 3)  @=? (  123  `quotRemF` (-10)))
        , "0 < x, 2 < y < 3" -: (( 1, 0.5) @=? (    3  `quotRemF` 2.5))
        , "x < 0, 2 < y < 3" -: ((-1, 0.5) @=? (  (-2) `quotRemF` 2.5))
      ]
    ]
  ]

(-:) = testCase
(/:) = testGroup

単体テスト実行

コンソールで

$ cd ~/app/src/
~/app/src/
$ runhaskell ./UnitTest/Util/NumericTest.hs
quot and rem for Fractional:
  example:
    x = qy: [OK]
    x = qy + r: [OK]
    x < 0, 0 < y: [OK]
    x < 0, y < 0: [OK]
    0 < x, y < 0: [OK]
    0 < x, 2 < y < 3: [OK]
    x < 0, 2 < y < 3: [OK]

         Properties  Test Cases  Total
 Passed  0           7           7
 Failed  0           0           0
 Total   0           7           7

「ユニットテストで自分で考えてたユースケースは全部テストしたよ!」

今回の主なテーマは↑のような，開発者が TDD でありがちな油断，ケアレスミスに対して，ランダムテストは有効かつ，プロダクトコードをより堅牢にするよ，という話．

勘のいい，というかマトモに開発をやってた人だったら，Haskell に馴染みが無くても，現状の実装には抜けがあるのに気づく．

例えば...

商を計算する関数なのに，ゼロ除算の事を考えてない
浮動小数点小数を扱っているのに，誤差について考えてない
INT_MAX と INT_MIN とかが引数に入った場合大丈夫なの?

などなど．まだまだ「これで十分テストはしてあるよ」とは言いづらい実装である．けれど，ここで2つ問題．

「どこまでやったら大丈夫だって言えるの?」
「開発者が具体的なテスト例を思いつくのを待つの?」

どこまでやったら大丈夫だって言えるの?

上記の問題が実はあるけれど，カバレッジをとってみると quotRemF に関しては実はもうカバレッジが 100% になっている．

カバレッジレポート 100% はあくまで記述したソースコードの中の条件分岐やループを評価したか否かであって，異常系と正常系を網羅したという事ではない．

だから開発者はテストを充実させていくわけだけど，ある意味で「キリが無い」といえばキリが無い

開発者が具体的なテスト例を思いつくのを待つの?

だから開発手法としてペアプログラミングだったり，コードリーディングをプラクティスとして取り込んで，多様な視点を持ってコードを精査する事で上記の問題を克服してきたのだけど，それもそれで限界があって．

例えば，誰も思いつかなかったらやはり問題は「実際にプロダクトを動かした後で顕在化」するだろうし，その対策として「経験や知識を積め」というのは科学的手法では無くて，割とスピリチュアルな結論である．

ちゃんとコードの問題はコードで解決したいし，そう出来た方がモダンなエンジニアリングだと言える

ランダムテストを導入しよう

前回の冒頭で，今実装したい quotRemF は Scheme の RSR6 の div-and-mod だと書いた．そして，その返り値の特性は以下の通り

y != 0 の時
(div-and-mod x y) => n m
x = y * n + m
0 <= m < |y|

つまり，どんな引数を取ろうが上記の「性質」が担保できれば要求仕様を満足させた事になる．そして y == 0 の時に上記の性質が成立しない事も見てわかる．( n にどんな数を代入しても x = m となるので，n は無限に選択がある. また， x < 0 であったら， m の性質と矛盾する )

入力値は適当にコンピュータにまかせて，ランダムで引数をブチこんで，それでも常に上記の性質が成立しているのを確認できればよさそうである．ランダムだから運良くテストが失敗する例に当たるかどうかはわからない．けれど，100回，1000回試行したら，それに遭遇する確率は高くなるし，10000回試行してもテストが成功していたら，「ほぼほぼ大丈夫だ」という事が言えるのでは．

Haskell には QuickCheck という，こうした要求を叶えるランダムテストライブラリが用意されている．

QuickCheck を使う

テストに次のように testProperty 関数を使ってランダムテスト用のテストを追加しよう

-- import モジュールを追加 ...
import Test.Framework.Providers.QuickCheck2 ( testProperty )
import Test.QuickCheck ( (==>), Property )
-- ...

  -- 略 ...
  "quot and rem for Fractional" /: [
      "example" /: [
        -- 略 ...
      ]
    , "specification" /: [
        testProperty "x = qy + r (0 <= r < |y|)" prop_quotRemF
      ]
    ]
  -- ...

  prop_quotRemF :: Double -> Double -> Property
  prop_quotRemF x y =
    y /= 0 ==>
    let (q, r) = x `quotRemF` y
    in x == q * y + r && 0 <= r && r < abs y

prop_quotRemF は「Double 型の引数を二つ取って，y が 0 でない時なら，quotRemF の返り値と x と y で以下のような関係が成立する」と読める．

テスト実行

QuickCheck をよくわからない，ランダムテストってそもそも知らない人の為に，GHCi でどんな事をしてくれるのか見てみよう．

$ ghci UnitTest/Util/NumericTest.hs
# ...
*UnitTest.Util.Numeric> :m + Test.QuickCheck
*UnitTest.Util.Numeric Test.QuickCheck> :t verboseCheck
verboseCheck :: Testable prop => prop -> IO ()
*UnitTest.Util.Numeric Test.QuickCheck> verboseCheck prop_quotRemF
Skipped (precondition false):
0.0
0.0
Skipped (precondition false):
0.0
0.0
Passed:
-0.5785404360888579
1.4050607149068028
Passed:
7.0219393237978736
2.5971907610723477
Passed:
1.7946454896303736
-6.527731796226503
Passed:
-10.994215492628914
32.166637725883405
Failed:
5.877469666395628
-1.519039404965895
*** Failed! Passed:
5.0
-1.519039404965895
Failed:
5.877469666395628
1.519039404965895
Passed:
5.877469666395628
1.0
Falsifiable (after 5 tests and 1 shrink):
5.877469666395628
1.519039404965895
*UnitTest.Util.Sample Test.QuickCheck> # テストは失敗したらしい

verboseCheck は QuickCheck の基本テストの quickCheck 関数の視覚化版で，実際にどんな入力値を与えているかを見る事ができる．

QuickCheck はどうやら，「テストプロパティの型情報から，その型の値をランダムに生成して突っ込みまくって，結果が False だったらテストを失敗したとみなして中断，失敗が無かったらデフォルトの件数 (n = 100) までテストを繰り返す」みたいだ．

テスト失敗時は QuickCheck の IO なのか，処理を並列化させている故かわからないけど，ヘンな位置でメッセージの差し込みが入るので，崩れるのだけど，これはライブラリの開発者にがんばって修正してもらいたい…

ランダムテストの失敗を，ユニットテストに引き上げる

さて，今の時点でテストはコケることがわかったわけだ

$ runhaskell UnitTest/Util/NumericTest.hs
quot and rem for Fractional:
  example:
    x = qy: [OK]
    x = qy + r: [OK]
    x < 0, 0 < y: [OK]
    x < 0, y < 0: [OK]
    0 < x, y < 0: [OK]
    0 < x, 2 < y < 3: [OK]
    x < 0, 2 < y < 3: [OK]
  specification:
4.7
2.3
    x = qy + r (0 <= r < |y|): [Failed]
Falsifiable with seed 3539781479325104925, after 5 tests. Reason: Falsifiable

         Properties  Test Cases  Total
 Passed  0           8           8
 Failed  1           0           1
 Total   1           8           9

コケた入力例は x = 4.7, y = 2.3 らしい，これをコピペして，testCase に追加して検証してみよう．

"2 < y < 3, 4 < x < 5" -: ((2, 0.1) @=? (4.7 `quotRemF` 2.3))

追加してテストを実行すると，その原因が推測できる

2 < y < 3, 4 < x < 5: [Failed]
Failed: expected: (2,0.1)
 but got: (2,0.10000000000000053)

はい，見事に浮動小数点小数の演算による誤差問題でした．

Nearly 型クラスを利用してテストに近似かどうかをチェックできるように

Haskell の浮動小数点小数の同値比較についてで実装した Nearly型クラスを利用して HUnit のアサーション，QuickCheck のテストプロパティに組み込んでテストしてみよう．

-- UnitTest/Util/NumericTest.hs
-- ...
import Test.HUnit ( (@=?), assert ) -- assert のインポートを追加
-- ...

-- tv - tolerance value
tv :: Double
tv = 1e-5

-- tp - tolerance pair
tp :: (Double, Double)
tp = (1e-5, 1e-5)

testSuite = [
    "quot and rem for Fractional" /: [
        "example" /: [
         -- ...
         -- @=? の代わりに @.=? を使う
       , "2 < y < 3, 4 < x < 5"-: (((2, 0.1) @.=? ( 4.7  `quotRemF` 2.3)) tp)
       ]
       -- ...
     ]
  ]

-- prop_quotRemF を変更
prop_quotRemF :: Double -> Double -> Property
prop_quotRemF x y =
  y /= 0 ==>
  let (q, r) = x `quotRemF` y
  in
     (x .= (q * y + r)) 1e-5 -- 誤差 0.00001 以内で近似しているかどうか
  && 0 <= r && r < abs y

テストを実行してみる

$ runhaskell UnitTest/Util/NumericTest.hs
quot and rem for Fractional:
  example:
    x = qy: [OK]
    x = qy + r: [OK]
    x < 0, 0 < y: [OK]
    x < 0, y < 0: [OK]
    0 < x, y < 0: [OK]
    0 < x, 2 < y < 3: [OK]
    x < 0, 2 < y < 3: [OK]
    2 < y < 3, 4 < x < 5: [OK]
  specification:
    x = qy + r (0 <= r < |y|): [OK, passed 100 tests]

         Properties  Test Cases  Total
 Passed  1           8           9
 Failed  0           0           0
 Total   1           8           9

テストが全件通ったみたいだ. 見た目9件のテストなんだけど，実際には108件テストケースを噛ませた事になる. (QuickCheck のランダムテスト分)

ちなみに，書いてないけど Nearly 型クラスについてもちゃんとテストを書かないとダメだよね．

テスト済みの関数を基準にテストプロパティを書く

quotRemF の関数の性質がテストで保証されたので，同じ条件で quotF, remF もそれぞれの性質が担保できる事をテストプロパティで示そう．

-- UnitTest/Util/NumericTest.hs
testSuite = [
  "quot and rem for Fractional" /: [
-- ...
    , "specification" /: [
        "x = qy + r (0 <= r < |y|)" *: prop_quotRemF
      , "quotF = fst (q, r)"        *: prop_quotF
      , "remF  = snd (q, r)"        *: prop_remF
      ]
    ]
  ]
-- ...

-- testProperty 用のユーティリティ演算子
(*:) = testProperty

-- 追加のテストプロパティ
prop_quotF :: Double -> Double -> Property
prop_quotF x y =
  y /= 0 ==>
  let (q, r) = x `quotRemF` y
  in q == x `quotF` y

prop_remF :: Double -> Double -> Property
prop_remF x y =
  y /= 0 ==>
  let (q, r) = x `quotRemF` y
  in r == x `remF` y

要は「quotF は quotRemF の結果の，最初の要素と値が同じ， remF は quotRemF の最後の要素と値が同じ」というだけの事をテストしている．

こちらは別にユニットテストで沢山の具体的なテストをしなくても良く，quotRemF の性能が保証されていれば，あとはテストプロパティが常に正しくテストに成功する事が確認できれば良い．

ポイントは，このテストのおかげで， quotF remF は quotRemF に依存する実装じゃなくても良くなるという事．リファクタリング等で，quotF を quotRemF と独立した実装にしたいと考えた時に，このテストが生きていれば性能が担保できる．

テストを実行

$ runhaskell UnitTest/Util/NumericTest.hs
quot and rem for Fractional:
  example:
    x = qy: [OK]
    x = qy + r: [OK]
    x < 0, 0 < y: [OK]
    x < 0, y < 0: [OK]
    0 < x, y < 0: [OK]
    0 < x, 2 < y < 3: [OK]
    x < 0, 2 < y < 3: [OK]
    2 < y < 3, 4 < x < 5: [OK]
  specification:
    x = qy + r (0 <= r < |y|): [OK, passed 100 tests]
    quotF = fst (q, r): [OK, passed 100 tests]
    remF  = snd (q, r): [OK, passed 100 tests]

         Properties  Test Cases  Total
 Passed  3           8           11
 Failed  0           0           0
 Total   3           8           11

それぞれランダムテストで100遍やっても成功できているのが確認できた．
合計で 308 回テストした事になる

[わき道] 例外どうすんの

残った問題はゼロ除算だけになったんだけど，これについては 1エントリーちゃんと立てられるくらい話が出来るので，今回は「 QuickCheck でのテストプロパティを書いている時点で気づいて実装した」という事でお茶を濁す．

一旦， Util/Numeric.hs をこのように実装しなおす

module Util.Numeric (
  quotRemF,
  quotF,
  remF
  ) where

import Control.Exception ( throw, ArithException(..) )

quotRemF :: (Num a, Num b, Ord b) => b -> b -> (a, b)
quotRemF _ 0 = divZeroError
quotRemF x y = iter x y 0 where
 iter r k q
  | r == 0 = (q, 0)
  | 0 < r && r < abs k = (q, r)
  | otherwise = iter (r `step` k) k (next q)
 step a b
  | x * y >= 0 = a - b
  | otherwise  = a + b
 next n
  | x * y >= 0 = n + 1
  | otherwise  = n - 1

quotF :: (Num a, Num b, Ord b) => b -> b -> a
quotF _ 0 = divZeroError
quotF x y = fst $ quotRemF x y

remF :: (Num b, Ord b) => b -> b -> b
remF _ 0 = divZeroError
remF x y = snd $ quotRemF x y

-- private functions
divZeroError = throw DivideByZero

これで， quotRemF, quotF, remF の2番目の引数に0を渡した際には DivideByZero Exception がスローされるようになる．

ただし，確かにこれでこのモジュールの関数は無限ループに陥って計算が止まらない等の異常は回避できているのだけど，ゼロ除算したら例外が投げられるという情報はライブラリのソースを見た人間にしかわからないし，テストでの確認もしずらい．

次の回で TDD/BDD とは話題が違うのだけど， Haskell の例外について，より Haskeller っぽいアプローチでこれを解決しよう．

ユニットテスト TDD => ランダムテスト BDD

ここまでが Haskell での TDD/BDD の基本ステップになる．

HUnit で，ユースケースを，テストケースとして書く
テストに失敗してから，テストが通るように実装を進める
HUnit のテストケースを増やす
追加したテストに失敗したら実装を見直す
思いつく限りのテストケースを書いては (1-4) の繰り返し
QuickCheck のテストプロパティを書く
テストプロパティで失敗した入力をメモしてテストケースに追加して検証する
実装を見直す
満足できるまで (6-8) の繰り返し
リファクタリング

このワークフローは (1-5) までがいわゆる TDD で，(6-9) が BDD または QA テスト的な性格を持つ．

結果的に出来上がるテストコードは，こんなに有用なリソースになる

HUnit のテストケースで，入力と戻りの実例が列挙され，実装コードを見るより何をしてくれるかがわかりやすい
QuickCheck でのテストプロパティは対象の関数の特性が一目瞭然となる
テストコードがそのままライブラリのドキュメントとして役に立つ
実行できる検証ツールとしても使える

Haskeller の Hackage 公開ライブラリって驚くほどテスト書かないか，書いてはいるけど非公開にしているのが不思議でしょうがないのだけど，HDoc 書くよりよっぽどこのアプローチでテストコードしっかり充実させた方がライブラリ利用者にとってわかりやすいのではないかと思っている．

ということでみなさんちゃんとテストを書きましょう

次回は例外処理についてとリファクタリング

おまけ

QuickCheck みたいなのってどうせ Haskell () だけなんでしょw

Wikipedia でちょっと検索するだけで出てくるんだからちゃんと調べましょう

Lang	Library
C	qc
C++	QuickCheck++
ObjC	objcheck
CommonLisp	cl-quickcheck
Java	QuickCheck for Java
Ruby	RushCheck
Python	paycheck
Perl	Test::LectroTest
Scala	ScalaCheck
JavaScript	qc.js
node.js	quickcheck

というか，ランダムテストの有用性と意義について RushCheck の作者の ikemgami さんが5年以上も前にこういうエントリーを上げている．5年と半年経過した今だと，メジャーどころだと PHP 以外はみんなそれなりにランダムテストライブラリ公開されてる．もちろん，XUnit系に対してバージョンはとても若いのが多いけれど

プログラマがテストも書くならば lightweight なランダムテストを試すといいと思う

QuickCheck () , Haskell () とか失笑してないでちゃんと自分の第一言語の動向チェックしておくべきだし，ぜひランダムテストを導入しましょう

今回までに書いた事は何も Haskell 独特のモノではなくて，あらゆる言語で言える事だし，XUnit系のライブラリと QuickCheck 系のライブラリを共存できるラッパーフレームワークを書けば同じ事が出来るはず

そのうち XUnit と対比して XCheck なんてランダムテストのデザインパターンが提唱されそうね

n参考リンク

Haskell の浮動小数点小数の同値比較について

2011-12-31T13:00:00.000+09:00

`4.7 - 2.3 * 2 == 0.1` は `False`

↑の式は，算数的には True が返ってほしいもの．でも，プログラムの実行結果は False が返ってきてしまう．原因は浮動小数点小数の演算の誤差によるもの．

小数を扱うライブラリを開発するにあたり，この手の小数の誤差問題はよく出てくるけれど，これに対処する為に3つアプローチがある．

ライブラリ側で丸めてしまう
ライブラリの利用側で丸める
テストでのみ，「だいたい合ってる」というテストにする

(1) のアプローチはオススメしない．ライブラリで丸める，という事は，その丸め誤差をライブラリの利用者が知ってないといけないし，またライブラリの利用者はその丸め誤差を自分でコントロールできない．

また，この類は小数だけでなく，巨大な整数でもケースが考えられる．「だいたい百より下の桁の数は別にどうだっていい…」っていう時とかね．

だから (2),(3) のアプローチを取る．

テストの際に，誤差を与えて，そのテスト結果が誤差の範囲内で等しい，「nearly equal」という比較演算が出来る型クラスを定義しよう．汎用的な型クラスを定義すれば，リスト [a] やタプル (a, b) などの複合型にも対応できる．

Nearly 型クラス

isNearly を実装すれば，同じ型同士で近似しているかどうかが判定できる Nearly 型クラスを作る．新たに Data, Data/Eq ディレクトリを作り，そこに Nearly.hs を書こう

  -- Data/Eq/Nearly.hs
  module Data.Eq.Nearly where

  class (Eq a, Ord a) => Nearly a where
    isNearly     :: a -> a -> a -> Bool
    (.=)         :: a -> a -> (a -> Bool)

    -- default Implementation
    x .= y = isNearly x y

  instance Nearly Int where
    isNearly = isNearlyNum

  instance Nearly Integer where
    isNearly = isNearlyNum

  instance Nearly Float where
    isNearly = isNearlyNum

  instance Nearly Double where
    isNearly = isNearlyNum

  isNearlyNum :: (Num a, Ord a) => a -> a -> a -> Bool
  isNearlyNum x y t = abs (x - y) <= abs t

  instance Nearly a => Nearly [a] where
    isNearly xs ys ts = and $ zipWith3 isNearly xs ys ts

  instance (Nearly a, Nearly b) => Nearly (a, b) where
    isNearly (p, q) (r, s) (t1, t2) =
      isNearly p r t1 && isNearly q s t2

これで，この型クラスを定義しているモジュールをインポートすれば，Int, Integer, Float, Double と，そのそれぞれの型のタプルとリストは近似している事を示す事ができる．

使い方は

  -- isNearly x y t -- t = x と y の誤差の許容上限
  isNearly 0.1 (4.7 - 4.6) 1e-5 -- True
  -- x .= y --「誤差の許容上限 t を引数に取って近似かどうかを返す関数」を返す
  (0.1 .= (4.7 - 4.6)) 1e-5     -- True

  -- 誤差±0 も出来る
  (1 .= 0.5 + 0.5) 0 -- True

  -- タプルも比較できる
  import Data.Fixed ( divMod' )
  (((2, 0.1) .= (4.7 `divMod'` 2.3)) (0, 1e-5)

テストに利用する場合

  import Test.HUnit ( assert )

  x @.= y = assert . ( x .= y )

  ((1.01 @.= 1) 1e-1) -- Assertion (Test case will pass)

Data.Ratio

Haskell の base ライブラリである Data.Ratio には，任意の誤差を丸めて小数を有理数に変換する approxRational 関数が用意されている

$ ghci
 Prelude> :m + Data.Ratio
 Prelude Data.Ratio> :t approxRational
 approxRational :: RealFrac a => a -> a -> Rational
 Prelude Data.Ratio> approxRational (1/3) 1e-1
 1 % 3
 Prelude Data.Ratio> approxRational 0.3334 1e-5
 1450 % 4349

1番目の引数に分数に変換したい小数を，二番目の引数に閾値となる許容値を渡す

approximate-equaly

Hackage に approximate-equaly というのも公開されている．ドキュメントはこちら

$ ghci
  Prelude> :m + Data.Eq.Approximate
  Prelude Data.Eq.Approximate> 1 == (1+10^^(-6) :: ApproximateDouble)
  True

こちらは 0.00001 の誤差を許容した型で数値型を包み，Eq で同値性判定を出来るようにしたモノ．テスト毎に誤差の範囲を指定しなくてもかまわない場合でなら，こちらも便利かと思う

参考リンク

BDD on Haskell チュートリアルその1 : HUnit で TDD を

2011-12-29T16:00:00.000+09:00

すこし日が空いてしまったけど，BDD on Haskell チュートリアルの続き．
前回までのエントリーはこちら

今回は HUnit を使って，基本的な TDD (BDD でなく) の進め方について．

例商と，小数の余剰を返す関数を定義してみる

今回のチュートリアルで適当に「ある程度需要があって，あるとそれなりに便利なもの」として，Scheme の RSR6 で採択された div mod をやってみる．

Haskell の mod について

Haskell の標準実装である mod rem は整数型しか受付けず，また返りも整数型なので，たとえば，Javascript や Ruby のように小数の余剰を返すことは無い．

$ ghci
Prelude> :t mod -- modulo
mod :: Integral a => a -> a -> a
Prelude> :t rem -- remainder
rem :: Integral a => a -> a -> a

これは 「整数である事を示す Integral 型クラスのインスタンスの引数を2つ受けて，その引数と同じ型の返り値を返す」という事を示している．つまり二つとも整数でないとダメだということ.

よって mod 3 2.5 のような計算は出来ない．( 2.5 は Fractinal, つまり分数化できる数の型クラスのリテラルと解釈される )

Ruby では余剰計算の結果は小数も受けつけている

$ irb
ruby-1.9.2-p180 :001 > 3 % 2.5
  => 0.5

div-and-mod

Scheme の RSR6 では商と余剰計算の為の関数をいくつか追加していて, div-and-mod と div0-and-mod0 である．前者は余剰が常に非負数であるのに対し，後者は余剰の絶対値が0により近いものを返す

x = y * n + m
div-and-mod の考え方
0 <= m < |y|
(div-and-mod 127 10) => 12 7

div0-and-mod0 の考え方
-|y|/2 <= m < |y|/2
(div0-and-mod0 127 10) => 13 -3

これに倣う形で，TDD でこれらを実装してみよう
Haskell には quot rem が商と余剰を計算する関数として用意されているので，「Fractional な型も受けつける quotRemF quotF remF」と仮に名前をつけておく

quotRemF :: (Num t1, Num t, Ord t) => t1 -> t1 -> (t, t1)

quotRemF は数値型ふたつの値を取って (商, 余り) のタプルを返す関数．これがあれば

quotF x y = fst $ quotRemF x y
remF x y  = snd $ quotRemF x y

で，それぞれ小数同士でも商や余剰を取れるようになる

まずテストコードから書く

まずテストコードを書こう. 汎用的に使える関数なので，Util.Numeric モジュールとして纏めると予定しておき，以下のように構成しておく．

ファイル構成

Numeric.hs と NumericTest.hs は touch コマンドでとりあえずファイルを置くだけにしておく

app/
 |- src/
 |   |- Util/
 |   |   `- Numeric.hs
 |   `- UnitTest/
 |       `- Util/
 |           `- NumericTest.hs
 |- app.cabal
 |- Setup.hs
 |- LICENCE
 `- README

app/src/UnitTest/Util/NumericTest.hs を書く

module UnitTest.Util.Numeric where

import Test.Framework ( defautMain, testGroup )
import Test.Framework.Providers.HUnit ( testCase )
import Test.HUnit ( (@=?) )

import Util.Numeric

main = defaultMain tests

tests = [
  testGroup "quot and rem for Fractional" [
      testCase "(q, r) of 127 10" ((12, 7) @=? (127 `quotRemF` 10))
    ]
  ]

テストを失敗したところから実装を始める

当然，テストコードだけを書いてもテスト対象のモジュールが無かったり，テスト対象の API がそもそも宣言されてないとコンパイルエラーで実行さえできない．だけど，TDD で大事なステップはこういう当たり前のような事を確認しながらやる事が重要で．

とにかくテストを通せるように app/src/Util/Numeric.hs を編集する

module Util.Numeric (
  quotRemF
  ) where

quotRemF x y = (12, 7)

もうこれでテストは通る．実行してみよう

$ pwd
app/
$ cd ./src
app/src
$ runhaskell UnitTest/Util/NumericTest.hs
quot and rem for Fractional:
(q, r) of 127 10: [OK]

       Test Cases  Total
Passed  1           1
Failed  0           0
Total   1           1

無事テストは実行されてることがわかる

テストで失敗しながら実装を確実にしていく

ただ，これは確かにテストを通しているものの，全然要求と違う事はわかっている．どうすれば良いか．答えは単純で．テストケースを増やせばよい

testGroup "quot and rem for Fractional" [
    testCase "(q, r) of 120 10" ((12, 0) @=? (120 `quotRemF` 10))
  , testCase "(q, r) of 127 10" ((12, 7) @=? (127 `quotRemF` 10))
]

こうやってテストケースを増やしてテストを実行する事で，テストが失敗し，「今の実装は要求を満たせてなかった」という事が確実に判明する．

実装を修正しよう

とにかく，テストが通る事だけを考える

quotRemF x y = iter x y 0 where
  iter x y n
   | x == 0 = (n, 0)
   | 0 < x && x < (abs y) = (n, x)
   | otherwise = iter (x - y) y (n + 1)

これで，前のような「取り敢えずテストが通るように値を返すのではなく，引数を計算して返すよう実装した」ことになる．

更にテストを増やそう

testGroup "quot and rem for Fractional" [
    testCase "(q, r) of 120 10" ((12, 0) @=? (120 `quotRemF` 10))
  , testCase "(q, r) of 127 10" ((12, 7) @=? (127 `quotRemF` 10))
  , testCase "(q, r) of -123 10" ((-13, 7) @=? ((-123) `quotRemF` 10))
]

すると今度はテストが終了せず，無限ループにハマってしまっているケースに遭遇している．あわてず Ctrl + D 等でテストを中断し，実装コードを修正

quotRemF x y = iter x y 0 where
  iter x y n
   | x == 0 = (n, 0)
   | 0 < x && x < (abs y) = (n, x)
   | otherwise = iter (x `step` y) y (next n)
  step x y
   | x * y >= 0 = x - y
   | otherwise  = x + y
  next n
   | x * y >= 0 = n + 1
   | otherwise  = n - 1

やや不恰好ではあっても，リファクタリングはテストが通ってから

テストケースを増やして要求仕様を見えるようにしていく

さて，この実装でかなり求めている事が出来るようになっているようなので，テストをどんどん増やして，「自分のやりたい事」が客観的に見えるように進めていく

-- ... 前略
  testCase "x = qy"     (( 12, 0) @=? (  120  `quotRemF`   10))
, testCase "x = qy + r" (( 12, 7) @=? (  127  `quotRemF`   10))
, testCase "x < 0 < y"  ((-13, 7) @=? ((-123) `quotRemF`   10))
, testCase "x < y < 0"  (( 13, 7) @=? ((-123) `quotRemF` (-10)))
, testCase "0 < y < x"  ((-12, 3) @=? (  123  `quotRemF` (-10)))
, testCase "y :: Fractional" ((1, 0.5) @=? (3 `quotRemF` 2.5))
-- ... 後略

testCase の1番目の引数はテストケースの概要を示すラベルであり，テストを実行した時にどのテストが成功または失敗かを示す目印になるので，上のように書いてあると後で見てもわかりやすくなる．

このようにして，自分が意図するテストケース，そのモジュールの関数のユースケースを書きつらねるようにテストを書き，失敗を見つけた際に実装を見直すのを繰り返していこう．

次回，「ユースケースで想定していないパターンはどうする?」

実は，一見これ完璧のように見えるけれど，実は現状の実装ではまだまだ抜けがあり，たとえば演算の基本であるゼロ除算に対して対策していなかったり，また (x < y) な条件下のテストをしていない．

これが次に出てくる QuickCheck を使う意味に通じる．
HUnit による具体的な入力値を，実装している自分たちがちゃんと全部類推できればそれに越したことは無いけれど，今のような数値ですら沢山のパターンを列挙する事になるし，数値でない，たとえば文字列入力などを考えたら入力例はそれでこそ膨大になる．

というわけで，今回はここまでにして，次回， QuickCheck を導入して 「関数の特性」 を記述して手当たり次第データを自動的につっこむテストの仕方について解説していく．

おまけ

いちいち testCase とか書くのダルイ

正直コードも見にくいわな．ということでユーティリティ関数作れば良いのでは

(-:) = testCase

正直これだけでだいぶテストコードの見通しよくなる

  "x = qy"     -: (( 12, 0) @=? (  120  `quotRemF` 10))
, "x = qy + r" -: (( 12, 7) @=? (  127  `quotRemF` 10))
, "x < 0 < y"  -: ((-13, 7) @=? ((-123) `quotRemF` 10))
, "x < y < 0"  -: (( 13, 7) @=? ((-123) `quotRemF` (-10)))
, "0 < y < x"  -: ((-12, 3) @=? (  123  `quotRemF` (-10)))
, "y :: Fractional" -: ((1, 0.5) @=? (3 `quotRemF` 2.5))

こういうのもアリ

should label expect assert =
  testCase label . assert expect

shouldEq label expect =
  should label expect (@=?)

-- テストケースをこう書ける
shouldEq "x = qy" (12, 0) (120 `quotRemF` 10)

後々のエントリーで test-framework 用のユーティリティ関数も紹介する

BDD on Haskell チュートリアルその0

2011-12-13T11:00:00.000+09:00

前回の記事で Haskell で BDD する基本的な構成は出来たので，これから実際に簡単なチュートリアルを書いてみる．あと HPC を Cabal に設定させてビルドテストからテストカバレッジレポートも生成させる要領もわかったので，そっちの準備等も書く

その前に

前回の記事の追記

公開したら，まさに「もっとスマートな方法ありますよ」という反応が．インターネットってすばらしい

GHC 7.0.2 以降，Cabal 10.2 だと Test-Suite 指定が出来る

自分の環境が GHC7.0.2 なのに cabal-install が 0.8.2 というあべこべな状態だったので，前回のような方法でしかビルド構成できなかったのだけど，元々，GHC 7.0.x 同梱の cabal-install 0.10.x 以降は exitcode-stdio でちゃんとテスト構成を指定する事ができる，とのこと．っていうか Cabal User Guide に書いてあったね．

というわけで MacOSX Lion に GHC7.2.2 インストール

$ curl -O http://www.haskell.org/ghc/dist/7.2.2/ghc-7.2.2-x86_64-apple-darwin.tar.bz2
$ tar -xjvf ghc-7.2.2-x86_64-apple-darwin.tar.bz2
$ cd ghc-7.2.2
$ ./configure --with-gcc-42
$ make install

もし古い GHC や Cabal などが入ってたら，前もってアンインストールしておいた方が無難

インストールできたか確認

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.2.2
$ cabal --version
cabal-install version 0.10.2
using version 1.12.0 of the Cabal library

よし．ただ，この時点で以前の cabal でインストールされていたものは使えなくなるので，改めて必要なライブラリをインストールしなおす手間は要る

app.cabal の書き直し

最新の Cabal が入ったので，それに合わせて cabal ファイルを書き直す

最後の GHC-Options: -fhpc -hpcdir dist/hpc/${cabal_name}-${cabal_ver} を今回更に追加してある．これは HPC でテストのカバレッジ結果を出力する為の GHC オプション

何もしてないんじゃないかってくらいさっぱりした Setup.hs

カスタマイズした UserHook を入れなくても良くなったので，極端にシンプルになった．

通常は cabal init でこれとまったく同じファイルが出来るので，最初から構成する場合は何も気にしなくともよい

前回からの大きな変更箇所は以上．テストランナー，ディレクトリ構成等は変更なし

テストカバレッジレポートから「必要な情報だけ抜く」スクリプト

これで基礎は改めて整った．以降は以下のフローが繰り返される

# テスト，またはテスト対象の実装をする ->
$ cabal clean # いちいちする必要もなし，大きくディレクトリ構成が変化した時, 外部ライブラリを新たに必要とした時など
$ cabal configure --enable-test # --enable-test をつけるとテストスイート込みでビルド
$ cabal build # 文字通りビルド
$ cabal test
$ ./test-report.sh

app/dist/test/unit-test/以下に，設定したテストのレポートファイル(unit-test.tix)が生成されるのだけど，このレポートにはテスト用のモジュールまでカバレッジに含まれているので，今回 test-report.sh ファイルを用意した．これはテスト用モジュールを find してカバレッジレポートから除外して，レポートの html ファイルと xml ファイルを再生成するモノ

test-report.sh

実行すると，dist/test/unit-test/ ディレクトリに，テスト用モジュールをカバレッジレポートから除外した結果を改めてファイルに書き出して，その中の hpc_index.html をブラウザで開く．同時に result.xml ファイルを書き出すので， Jenkins とかでビルド管理してテストの結果を監視するような利用方法も想定してる

思いの他長くなってしまったので，今回はここまで. 次回に続く

[再掲] ディレクトリ構成例

app
|- LICENSE
|- README
|- app.cabal
|- Setup.hs
|- test-report.sh
`- src
   |- Main.hs
   |- Test.hs 
   |- Hoge
   |  `- Foo.hs
   |- Huga
   |  `- Bar.hs
   `- UnitTest
      |- Hoge.hs
      |- Huga.hs
      |- Hoge
      |  `- FooTest.hs
      `- Huga
         `- BarTest.hs

cabal configure すると dist ディレクトリが生成されるのだけど，これは .gitignore なり .hgignore なり .darcs/boring なりで，バージョン管理から外しておく

参考

Installing GHC 7.2 on Mac OS X: ちょっと古いけど MacOSX Lion に GHC7.2.1 をインストールする手順
Cabal Users Guide: よく見りゃちゃんと書いてあったわ…
Cabal パッケージの作成: 今回の記事はこちらの構成を参考にした

BDD on Haskell の為のディレクトリ構成を考える

2011-12-12T08:00:00.000+09:00

ひさしぶりの Haskell ネタ

2011/12/13 追記

下の例で app.cabal の設定や Setup.hs の記述などの情報が古かったので，こちらも一読してください → BDD on Haskell チュートリアルその0

経緯

Haskell でそれなりのプログラムを書いてみようとしたので，HUnit や QuickCheck を使って BDD でやろうとしたのだけど，How to write a Haskell program 以上の事を誰も書いてないし，HUnit や QuickCheck の実例を書いた日本語圏のブログ記事も，その単体モジュールのテストのみ書いていて，肝心の全体テストを通しで実行するなどのネタが書かれていない．

じゃあ実際に公開してるリポジトリでも見てみるかと思い，patchtag を見ても今度は公開してる人の殆どがテスト書くとかしてなかった．Haskeller って文化としてテスト書かないの?

これでは単体テストは確かに出来ても全体テストを一発で実行するような事が出来ないし，また，Haskell.org 内で挙げられているケースでも複数のモジュールがあるような場合が記述されておらず(たとえばルートディレクトリにそのままモジュール.hs を置くようなカタチ)，どうやって構成してやれば良いのかわからなかった．

自分なりに工夫してみて，とりあえず単体テストとビルドテストが出来るようになったので，それをメモする

これよりももっと遥かに簡単で，かつスマートな方法があるのならトラバください．真剣に知りたい

必要なモノとか，使ったモノ

GHC: 言わずもがな Glasgow Haskell Compiler. 無いと始まらない

test-framework: HUnit, QuickCheck を両方使えるようにするフレームワーク．GitHub で公開されている． cabal install test-framework で入る
HUnit: xUnit系の皮をかぶった xSpec系の Haskell テストライブラリ
QuickCheck: 「テストケースとそのアサーションをハードコーディングするなんてバカのすることよねー」と言わんばかりの自動テストライブラリ

ディレクトリ構成

以下のような構成にする

app
|- LICENSE
|- README
|- app.cabal
|- Setup.hs
`- src
   |- Main.hs
   |- Test.hs 
   |- Hoge
   |  `- Foo.hs
   |- Huga
   |  `- Bar.hs
   `- UnitTest
      |- Hoge.hs
      |- Huga.hs
      |- Hoge
      |  `- FooTest.hs
      `- Huga
         `- BarTest.hs

しばらく Java の開発手法のトレンドとか追ってなくて，自分が知ってたころは src と test が並列していたが，最近は src の中に test ディレクトリがある方がトレンドだと聞いている (maven とかがそうなのかな?)．このように構成する事で，UnitTest モジュール内の *Test.hs は単体で，本来 Main から参照されるはずの Hoge, Huga モジュールを import しつつ，スタンドアロンで実行する事ができる．また，ビルドした際に Hoge, Huga モジュールの中に *.o *.hi が入って汚される事が無くなる．(*Test な .o .hi は UnitTest/Hoge などのディレクトリに集約される)

.cabal でのパッケージ情報・ビルド情報記述

cabal init 使って基本情報を埋めてしまって，その後で直接 app.cabal を編集し，cabal test の時にビルドテストを走らせるように書く

-- ...
Name:        app    -- アプリケーションでもライブラリでも良いけど，その名前
Builld-type: Custum -- Build-type を Simple から Custum に変更
-- ...
Executable:  app
  hs-source-dirs:   src
  Main-is:          Main.hs -- こちらが本来のメインモジュール
  Build-depends:    base, -- メインで必要な cabal ライブラリを列挙．ここにはユニットテスト用のライブラリは記載しない
-- .cabal の末尾に以下のように Executable を追加する
Executable:  test
  hs-source-dirs:   src
  Main-is:          Test.hs -- テストランナーの Main
  Build-depends:    test-framework, test-framework-hunit,
                    test-framework-quickcheck2, HUnit, QuickCheck

Main-is に Test.hs を指定しているのがキモ．これに全体テストが走るように書く．Executable に test と指定しているので，これで cabal build すると app/dist/build/以下にテストランナー用の testディレクトリが作られ，その中に実行ファイルの test がコンパイルされる

Setup.hs

import Distribution.Simple
import Distribution.Simple.UserHooks
import Distribution.Simple.LocalBuildInfo
import Distribution.PackageDescription
import System.Cmd
import System.FilePath

main = defaultMainWithHooks hooks
 where hooks = simpleUserHooks { runTests = runTests' }

runTests' :: Args -> Bool -> PackageDescription -> LocalBuildInfo -> IO ()
runTests' _ _ _ lbi = system testprog >> return ()
 where testprog = buildDir lbi  "test"  "test"

Setup.hs は cabal configure コマンドで， cabal build 時にどうビルドするかを設定する．この simpleUserHooks のコンストラクタにテストランナーの挙動を書く

Test.hs

import System.Environment ( getArgs )
import Test.Framework

import qualified UnitTest.Hoge as Hoge ( testSuite )
import qualified UnitTest.Huga as Huga ( testSuite )

main :: IO ()
main = runTests

runTests :: IO ()
runTests =
 do 
  args <- filter (/= "--tests") `fmap` getArgs
  ( defaultMainWithArgs testSuite args )

test :: [Test]
testSuite = foldl (++) [] [
   Hoge.testSuite
 , Huga.testSuite
 ]

テストランナーのやっている事はいたって簡単で，各モジュールレベルのテストをまとめあげて，test-framework の defaultMainWithArgs にテストケースを渡しているだけ．

あえて testSuite の宣言を foldl で束ねているかというと，こうする事で最後の引数のリストに，追加すべきテストモジュールが増えてもコードの変更をそこまでしなくても良いから

各モジュールのテスト

UnitTest/Hoge.hs

module UnitTest.Hoge where

import Test.Framework
import qualified UnitTest.Hoge.Foo as Foo ( testSuite )

main :: IO ()
main = defaultMain testSuite

testSuite :: [Test]
testSuite = foldl (++) [] [
    Foo.testSuite
  ]

こちらも，モジュールの各単体テストをまとめあげて，test-framework の defaultMainWithArgs にテストケースを渡しているだけ．この時点で，「ライブラリ全体のテスト」「モジュール単位のテスト」「モジュールの更に細分化された単体テスト」がそれぞれ実行できる環境が整う．ビルドせずに runghc UnitTest/Hoge.hs を実行する事で，モジュール単位でのテストを通すことができる．import qualified で各サブモジュールを import するので UnitTest.Hoge.Foo.testSuite と，ここで宣言されている testSuite とで名前空間が衝突するような事は無くなる

UnitTest/Hoge/Foo.hs

module UnitTest.Hoge.Foo where
import Test.Framework
import Test.Framework.HUnit
import Test.Framework.QuickCheck
import Test.HUnit
import Test.QuickCheck

import Hoge.Foo -- テスト対象のモジュール

main :: IO ()
main = defaultMain testSuite

testSuite :: [Test]
testSuite = [
    testGroup "..." [ 
      -- テスト対象のトップレベル宣言関数の testCase, testProperty を列挙
    ]
   , testGroup "..." [
      -- ...
    ]
  ]

こちらがサブモジュールの単体テスト．というか各テストの本体にあたる．ビルドせずに runghc UnitTest/Hoge.hs を実行する事で，テストを通すことができる．

たぶん初心者的にはこちらの方を重点的に解説した方が良いのだけど，そこも含めると長いので別途エントリーをあげる

テスト実行

すべて app/ ディレクトリ以下で実行されているものだとして

単体テスト

$ pushd src && runghc UnitTest/Hoge/Foo.hs && popd

モジュールレベルテスト

$ pushd src && runghc UnitTest/Hoge.hs && popd

全体テスト

$ cabal configure
$ cabal build
$ cabal test

はい，これで Haskell で BDD する手筈が整った．具体的な BDD のステップについては次のエントリーで．

参考

How to write a Haskell program: なんか日本語のブログとかでこれより詳細な Haskell 入門とか見たことが無い気がする…
Cabal Users Guide: そういえば Cabal の解説も見たことがない
some ideas for practical QuickCheck: 今回の記事はこちらの構成を参考にした

GUI ボタンのデザイン・ストラテジーについて

2011-10-02T03:50:00.000+09:00

GUI デザインをする上で考えていること

Stocker.jp さんのところで [連載]Webデザイン入門（3:光とボタン）というWebデザイン初学者向けの連載が行われているのだけど，それに触発されて「自分だったら (こうする/こうしてる)」というのを実例を持って書いてみる．

ここでいう UIデザインは GUI のスタイリングであって，実際にはデザインと呼ぶには領域が挟すぎるのだけど，おそらく多くの人が認識している"デザイン"と呼ぶものに合わせる．実際には DBモデル, API設計, URI設計, CallbackFunction まで実装して，はじめてデザインと呼べるものだと思う

サマリー

機能について把握すること
機能の記号化(ピクトグラム) ・そのシルエットのデザイン
「押せそうな」アフォーダンス・「明暗」と「光沢」「質感」を切り離して考える
「押せそうな」アフォーダンス・「明暗」のデッサン
表現の変更に強いレイヤー構成
ベクターデータ形式で UI のイメージを作る時は「実際に利用されるサイズ」を考える
スタイルとトレンド
まとめ・デザインする目的を

機能について把握すること

Ajax 等を使って API を再度リクエストする Reload ボタンだという想定．最近は Async な非同期処理で，ユーザーがわざわざ更新の操作をする機会は減ったものの，まだまだ「マッシュアップサービスなので，API のリクエスト先はストリーミングAPIを実装していない外部ドメイン，よって頻繁にリクエストを投げにくい」など，そんなケースが存在する．また，分単位で解析結果が更新されるようなサービス (Blogger のアクセスログや Amazon アフィリエイトなど) にも，そうした需要がある．

今回の作例はそうした背景のある機能を GUI ボタンとしてデザインする

機能の記号化(ピクトグラム) そのシルエットのデザイン

まずは機能の記号化したものを，ユーザーに記憶してもらうように，ピクトグラムのシルエットで考える．

ここで間違ってたり効果が薄かったら上からグラデーションやらメタリック/グラスな質感とかにこだわっても結局何のボタンなのかわからない

ここで，仮にピクトグラムではなく，「Reload」「再読み込み」など，ボタンのラベルをテキストにしなければならない，あるいは想定しているユーザーにとって，その方が理解しやすいと判断できる場合は，そのタイポグラフィをまず全力でやる

手短に書いてはいるけれど，このフローが一番大事で，それが分かっていればダラダラと長いこのエントリーを最後まで見なくてもよい

「押せそうな」アフォーダンス・「明暗」と「光沢」「質感」を切り離して考える

で，次に「UI 以外の文書や画像，動画コンテンツとは一線を画す」ための差別化として，「押せそうな」アフォーダンスを提供するために，立体的な陰影を付けたりするのがポピュラーな方法なのだけど，件の記事の作例ではいきなりメタリック/グロスな質感を与えてしまっている．

作例のグラデーションは上図のような感じだった．(注：実際にはちゃんと滑らかな曲面に仕上げていたのだけど，後述の為にやや誇張している) しかし，この表現では横から見たら，右のような断面図に見えてしまう

(「でっぱり」の再現であればこれで良いとは思う)

質感表現は，その全体的なスタイリングとマッチするかどうかや，機能のプライオリティ (ユーザーにどれくらい優先的に使ってもらいたいか)，に影響を大きく左右されるし，明暗，陰影とはレイヤを別にしないとリテイクを受けた時がツラくなる．実務で安易にやってしまった場合一番リテイクが来るのもココだ．

もっと言えば「質感表現はそもそもそのデザインに必要不可欠なのか?」って問いに明確な回答が無い．先に述べたように次に地の「UI 以外の文書や画像，動画コンテンツとは一線を画す」ための差別化として，「押せそうな」アフォーダンスを提供するための目的に対してはオマケのようなモノでしかない

「押せそうな」アフォーダンス・「明暗」のデッサン

質感を追求する前に，立体形状をグラフィックで再現する事の方をまずトレーニングした方が良い．本当にカマボコ状の出っ張りのあるボタンであれば，上の図のようなライティングになる．

デッサンには環境光をいくらか無視して光源が基本一点，そこから地面や他の物体が反射光を照り返してる，という想定をわざとする事で，描く対象の立体感をより強く描画する，という基本がある．

質感，ボタンのベースカラーはとりあえず保留して「形状に光と影があった場合はこのようになるはず」というデッサンをまずやる

表現の変更に強いレイヤー構成

試しに(ほどよく磨かれたギラギラとまではいかない程度の)メタリックな質感をつけてやってみたのが上

ピクトグラム : Symbol (通常透過)
オマケ的な質感表現 : gloss (スクリーン透過)
ボタンの光源によって光る部分 : HighLight (スクリーン透過)
陰影: Shadow (乗算透過)
ボタンのベースカラー : Base

こうすれば基本ベースカラーをWebサイトのカラーマネジメントや，機能的に色を意味づけしたいなどの要望に手早く応答できる．

基本はベクターデータ形式 (.ai .svg) で原本を管理しておき，デプロイ時に png フォーマットに出力するのが楽な管理方法．サイズ変更にもPhotoshopで直に作成するよりは比較的強い．

色空間モデルは最終的にラスターデータ形式の画像ファイルに出力してしまうのだから，デザイナー的に色を操作しやすい HSL/HSV でやった方が良い

ベクターデータ形式で UI のイメージを作る時は「実際に利用されるサイズ」を考える

ここまでは「実際に利用されるサイズ」の事を度外視していたわけだけど，そもそもWebでもPC用アプリケーションでもスマートフォンアプリでも，限られた画面の中で，「他のジャマにならず，かつユーザーが欲する時にすぐ目につくような」スケールを考えてデザインはしないといけない

作例の一つ一つのボタンの高さは 18px ．これが今考えられるスマートフォン等で指で押しやすい最小と思われるサイズであることから．文字とのジャンプ率的にもこれくらいが妥当

ベクターデータ形式はスケーラブルなのが強みなのだけど，現在 .svg ファイルは img src="... で受けつけられないフォーマットなのでラスターデータ形式にする．jpeg では圧縮アルゴリズムの関係でエッジの部分やボーダーラインに色のノイズが入り，汚ない変換になりがちなので，透過GIF, 透過PNG を選ぶ．

また，その圧縮時にピクセルの色がアンチエイリアス等でにじんでしまうので，基本的には「UI のベースに貼りつけたい原寸のサイズ」でデザイン作業をやる．

特にボーダーラインピクトグラムのディテールを元を大きなスケールで作って満足してしまうと，「実際に貼りつけるサイズ」に縮小した時に残念な事になる．ディテールが潰れて見えない，ボーダー，ハイライトにアンチエイリアスがかかって想像した物より薄い色になる，等々

また，原寸のサイズでデザインをやると，Webデザインの場合 CSS スプライトを作成するのが簡単になる．

作例の 100% はこのような png に出力される．ボーダーラインやハイライトもキレイに変換できている．

スタイルとトレンド

近年までは MacOS の Aqua に始まり Window Vista, iOS, Android のUIは図の真ん中のような立体感を強調するグロスの効いて，角丸の大きくとったスタイルが好まれ，どこもかしこも Web デザインにこのような UI スタイルが流行っていたのだけど，最近は Twitter bootstrap Facebook Google+ など，Window 8 (Windows Phone) で Metro UI と称されるシンプルなスタイルの方向性 (一番上) がトレンドになってきている．

これを書く殴り書きの段階で，DanKogai さんから「Metroは一番下じゃない?」ってツッコミが来たんだけど，純粋なMetroは角丸なし，枠線なし，特徴的な背景色に，白(あるいは黒) の前景色のシンボルのパターン．「Metroっぽい(?)」くらいが表現として妥当かと思われる

UI というか，ヴィジュアルデザインの基礎は図と地の明度差による認識であり，シルエット，シンボルカラーの二つが最も影響度高いので，なんというか基本に立ち返った感がする．

まとめ・デザインする目的を

タイトルを「デザイン・ストラテジーについて」とした理由は，ここで書いた一連はグラフィックツールの操作など，実際の作業手順より一層抽象的に記述されているからで．おそらく初学者からしたら，それよりは具体的に「次にグラデーションツールでどうするか」などの細かい"手順"が書かれていた方がてっとり早いかと思われる

それらを省いて，あくまで手順に向かう際の「指針」だけなのは，それらを書きはじめると，本筋が埋没してしまうし，本件で言いたいトコロではない

重要なのは，仮に些細なボタンを作成する時であっても，

「それは誰の為に」

「それは何の為に」

「それはどれくらい重要で」

「それはどのくらいの頻度で」

を考えながら具体的な作業をする事が大事で，その目的がしっかりしていれば「どんなスタイリングにするか」「あるべき大きさ」「あるべき位置」は自ずと絞られてくるからだ．

逆にそれらが念頭に置かれてなく，グラフィックツールを使いこなして，(えーと…) 例えばはてなブックマークでよく「デザイン」タグでのホットエントリーに上がってくる「クールでフリー利用可能なGUIボタンの Photoshop データ 10選」みたいなのに目移りして，そのような "流行りの" スタイリングをしても，誰の為のデザインもしてない．何の為のデザインもしてない．

それらを踏まえた上で，実際に実務でデザイン(正確に言うとスタイリング)する際に，後々の作業のしやすさ，本質的なデザインの追求のしやすさを意識しやすくする事について書いた．

そういえば肩書き一応デザイナも兼ねてるエンジニアなのだけど，始めてデザインについてエントリー書いたな…

参考にすると良い書籍

フォントサイズを軽く調べるGaucheスクリプト

2011-09-08T11:51:00.001+09:00

デザイナー向けスクリプトシリーズ

経緯

きっかけは友人のこんな発言から．

Twitter / @orange21: Qで作業しながらPt分かるようになりたいんだけどさー

Q っていうのは活字の級数で，要するに感覚的に文字のサイズは級数で考えたいんだが，その文字サイズが実際ポイントにしてどれくらいかを確認しながら作業したい，という事．自分の場合 pt よりも pt, mm, px でそれぞれ，そういう風にチマチマとチェックしながらデザイン作業やってたりしてたなーと思い返す．

今日び，その手のフォントサイズ変換表とか，JavaScript 変換表作ってみましたーってやつ，ググればいっぱい出てくるんだけど，わざわざブラウザの大きな画面を必要とするものじゃないし，モニタのすみっこに小さくコンソール開いておいて，ちょいちょい打って確認できるくらいがちょうどいいんだよなー，ということで，ちゃっちゃと簡単なスクリプトを書いてみた．あまり Lisp 的な高度な事はやってないので結構冗長である

使い方

$ gosh font-size-conv.scm -dpi 300 -p 144

とかにすると，DPI=300 の状態での 144pt のフォントサイズが級数Q，mm, px ではどれくらいになるのかを標準出力で変換表を出してくれる．illustrator とか InDesign で印刷物やってる時とかは dpi 直接入力できると便利だと思う

デフォルトのDPIはWindows標準の96にしてあるので，Web系であれば，

$ gosh font-size-conv.scm -x 100

などで見れば標準的なモニタ解像度での 100px になるフォントサイズを調べられる．

ツッコミ所は「なんで Perl Ruby Python みたいに標準でOSに入ってる言語じゃなくて Gauche なん」っていうところでしょうか (だって Lisp/Scheme が好きなんだもん)

はい，「Gaucheって何? いんすとーるどうすればいいのん」って人はググってコンソールアプリケーションの世界にようこそ

font-size-conv.scm

参考図書

Type Safe(?) MetaClass for Gauche MOP

2011-09-07T03:18:00.000+09:00

仕事はもっぱら PHP HTML CSS JavaScript なのですが，ここ最近は一年に一度の Scheme 熱に浮かれております．特に思い付いたアイデアをスケッチする感覚でEmacs立ち上げてアルゴリズムの実装とかやるのに，とても Gauche は気持ちが良い．みんな Schemer になりましょう．

CLOS をもう少し使いこなしてより自分好みにしたい

Gauche の CLOS 風オブジェクトシステムってとても良い感じなのだけど，クラス設計時に Perl の Moose のようにある程度メンバ変数の型を固定しておきたいなぁと思う事がしばしばあり，試しにこんな風なメタクラスを作ったら，完全に型安全というわけではないけれど，そこそこ自分が求めているレベルの安心が担保できた．というのを書きとめておく.

要求

スロット定義時に <hoge> またはそのサブクラスのインスタンスのみにしたい
スロットに許容限界値を設けたい．
許容限界値を超えた場合の動作を，フィルタリングによって丸めこんでしまえるように
許容限界値を超えた場合の動作を，エラーとして投げるようにする場合も欲しい

考えてみたメタクラス仕様

:is-a <hoge> で <hoge> またはそのサブクラスのインスタンスのみ set! できる
:filter (<closure> な関数) で set! 時に値をフィルタリング
:validate (<closure> な関数) で set! 時に許容範囲外の値を検出してエラー投げる

運用上，2 と 3 は :filter :validate のどちらかを持たせるだけで本当は良いのだけど，ソースを後で見た時に「:validate だからこれは異常系でエラー出るのな」「:filter だからこれは異常系丸めこむのか」と分かり易くする為にあえて分けている．ただし，実装上，両方あった場合も :filter が2つ合成関数になった状態でスロットに set! したい値に適用されたようなものになる．

サンプルコード(実装編)

詰めが甘そうではあるけど，こんな風に実装してみた．実際にやってる事は slot-set-using-accessor! の処理の前に :is-aが指定してあれば，そのサブクラスかを is-a? でチェックして，:validate :filter を記述してあれば，その合成関数をかけておくようにする

(define-class <type-safe-meta> (<class>) (()))

(define-method compute-get-n-set ((class <type-safe-meta>) slot)
  (let* ([has? (cut slot-definition-option slot <> #f)]
	 [acc (compute-slot-accessor class slot (next-method))]
	 [type-error
	  (^ (value type)
	     (error
	      #`"Type Error : require type ,|type| but ,(class-of value)"
	      value))]
	 [validate-type
	  (^v (if-let1 t (has? :is-a)
		(if (is-a? v t) v (type-error v t))
		v))]
	 [validate-value
	  (^v (if-let1 validate (has? :validate) (validate v) v))]
	 [filter-value
	  (^v (if-let1 f (has? :filter) (f v) v))])
    (if (or (has? :is-a) (has? :validate) (has? :filter))
	(let1 filter/validate (.$ filter-value validate-value validate-type)
	  (list (^ (o) (slot-ref-using-accessor o acc))
		(^ (o v) (slot-set-using-accessor! o acc (filter/validate v)))
		(^ (o) (slot-bound-using-accessor? o acc))
		#t))
	(next-method))))

サンプルコード(応用編)

今，趣味でCSSマクロ言語みたいなのを自前で開発したくて，その前に，それの為の RGB HSL HSV なんかの色空間を扱うライブラリを書いていて (VoQn/Gauche-Color - GitHub)，それぞれのモデルを記述する時に，こんな風に書いて簡略化，というか，「スロットの中身があらかじめどんなもんか見当つく」クラスを設計できる．これなら公開モジュールとして export しても，想定してない使われ方はしなさそう

(define (loop-mod$ max) 
  (^x ((^v (if (= v (floor v)) (x->integer v) v))
       (cond [(<= max x) (fmod x max)]
	     [(> 0 x) (fmod (+ x max) max)]
	     [else x]))))

(define (inner$ min max) (cut clamp min <> max))

;;; HSL Color Model
(define-class <hsl> (<color>)
  ([hue :init-value 0 :init-keyword :hue :is-a <real> :filter (loop-mod$ 360)]
   [saturation :init-value 0 :init-keyword :saturation  :is-a <real> :filter (inner$ 0 1)]
   [luminance :init-value 0 :init-keyword :luminance :is-a <real> :filter (inner$ 0 1)]))

更にdefine-classもマクロ使って init-value :init-keyword :accessor とかを補完したりできるので，もっとクラス定義を自分が特記したい部分だけの記述にできる．

(define-class* <hsl> (<color>)
  ([hue :is-a <real> :filter (loop-mod$ 360)]
   [saturation :is-a <real> :filter (inner$ 0 1)]
   [luminance :is-a <real> :filter (inner$ 0 1)]))

自分のリポジトリの中だと，これだけで良い．MOP 駆使したら Ruby のメタプログタミングよろしくけっこうな事が出来る気がする．もう少し研究したい

wtf!? JavaScript Empty Array Programming

2011-05-30T00:55:00.001+09:00

昨日，やきとんオフに参加したところ，mizchi や ymrl に「頭おかしい…」と言われたので，ちゃんと解説します．

0. サンプルコード

これをコピーして,ブラウザのアドレスバーに javascript: と先頭につけてペーストして実行してみましょう．

_=-~-~-~[];__=[][(![]+[])[_-_]+([][[]]+[])[_+_-_/_]+(![]+[])[_-_/_]+(!![]+[])[_-_]+(!![]+[])[_]+(!![]+[])[_/_]]+[];___=__[_]+__[_+_]+__[_-_/_]+(![]+[])[_]+(!![]+[])[_-_]+(!![]+[])[_/_]+(!![]+[])[_-_/_]+__[_]+(!![]+[])[_-_]+__[_+_]+(!![]+[])[_/_];___[___][___]((![]+[])[_/_]+(![]+[])[(_+_)/_]+(!![]+[])[_]+(!![]+[])[_/_]+(!![]+[])[_-_]+"(\""+'\\'+(([][[]]+[])[_-_])+(_)+(_-_)+(_+_/_)+(_+_)/_+"\");")();

このような実行結果になります．当然ですよね

なんでこのコードが動くのか，の前にいくつかの wtfjs な挙動の解説が必要で，まぁ wtfjs を見ている人だったら「ああなんだ，いつしかやってみたJsF*ckじゃんか」で終わる話でもあります

1. 'constructor' で無名関数が作れる

'constructor'['constructor']['constructor']('alert("Hello, World!");')();

JavaScript のオブジェクトは，自身のプロパティを['<property>']で呼び出せるのはご存知かと思います.つまり "Stringインスタンスのコンストラクタのコンストラクタを呼べばそりゃ Function クラスのコンストラクタに到達するよね" という話

// 当然 String オブジェクト
var c = 'constructor';

// String.constructor(), つまり Function オブジェクト
var c2 = 'constructor'['constructor'];

// Function.constructor(), なのでここに文字列渡すと Function オブジェクトが作れる
var c3 = 'constructor'['constructor']['constructor']; 

// 結果として，Hello, World がアラートできる
c[c][c]('alert("Hello, World!");')();

2. [] にまつわる挙動

JavaScript の空配列リテラルに関する挙動には変なものが多いんだけど，おかげでだいぶ F*ck な事ができる

[] === [] // #=> false
[] == [] // #=> false
![] // #=> false
[] == true // #=> false

// もうこの時点で泣きそうだが

[,] // #=> []
[].length // #=> 0
[,].length // #=> 1

+[] // #=> 0
[]+[] // #=> ""
!+[] // #=> true
!+![] // #=> true
+!+![] // #=> 1

[][[]] // #=> undefined

![]+[]    // #=> "false"
!![]+[]   // #=> "true"
[][[]]+[] // #=> "undefined"

この時点で頭がイッてる人なら"ああ，じゃあ空配列リテラルから true, false, undefined, [0-9], a, d, e, f, i, l, n, r, s, t, u のアルファベットが取れるのか"と気づくでしょう

Q.\uXXXX の書式で任意の文字コードいくらでも作り放題じゃね?

A.やりましたね

3. 結果としてなんでも出来てしまった空配列リテラル

さて，この時点でUnicodeが空配列だけでもう普通に作れる事がわかったので，ソースコード自体をほぼ空配列だけで書ける．が，もう一つ，先の 'constroctor' の例を考えてみよう．これも空配列で作れたらいいけど，c と o が無い．これをどうするか．

Array.filter を呼べばいいのでは

[][(![]+[])[0]+    // f ('f'alse)
   ([][[]]+[])[5]+ // i (undef'i'ned)
   (![]+[])[2]+    // l (fa'l'se)
   (!![]+[])[0]+   // t ('t'rue)
   (!![]+[])[3]+   // e (tru'e')
   (!![]+[])[1]    // r (t'r'ue)
] // []['filter'] => Array.filter()
+[]; // "function filter { [native code] }" の 文字列が返ってくる

これで 'function' の文字列から c と o が文字としてとれてしまうので，以下のコードで'constructor' が作れてしまう

_=-~-~-~[]; // #=> 3
__=[][(![]+[])[_-_]+([][[]]+[])[_+_-_/_]+(![]+[])[_-_/_]+(!![]+[])[_-_]+(!![]+[])[_]+(!![]+[])[_/_]]+[]; // #=> "function filter { [native code] }"
___=__[_]+__[_+_]+__[_-_/_]+(![]+[])[_]+(!![]+[])[_-_]+(!![]+[])[_/_]+(!![]+[])[_-_/_]+__[_]+(!![]+[])[_-_]+__[_+_]+(!![]+[])[_/_]; // #=> "constructor"

-~-~-~[] の部分はビット反転と正負反転を繰り返して0から3を作っている

~[]         // -1
-~[]        // 1
-~-~[]      // 2
_=-~-~-~[]; // #=> 3
_-_         // 3 - 3         #=> 0
_/_         // 3 / 3         #=> 1
_-_/_       // 3 - 3 / 3     #=> 2
_+_/_       // 3 + 3 / 3     #=> 4
_+_-_/_     // 3 + 3 - 3 / 3 #=> 5
_+_         // 3 + 3         #=> 6
_+_+_/_     // 3 + 3 + 3 / 3 #=> 7
_*_-_/_     // 3 * 3 - 3 / 3 #=> 8
_*_         // 3 * 3         #=> 9

これで，'constructor'['constructor']['constructor'] は作れるし，中で呼ぶソースコードの任意の文字は

_=-~-~-~[];
// \u3042 , 'あ' の Unicode
''+'\\'+(!![]+[])[_-_/_]+(_)+(_-_)+(_+_/_)+(_-_/_)

のようにする. これで JavaScript が書けるわけだけど，ものすごい時間の無駄ですね!

参考リンク

Vows でクライアントサイドの CoffeeScript / JavaScript のテストをする時の Tips

2011-05-17T07:28:00.002+09:00

0. node.js の Vows フレームワークがとてもかわいい

JavaScript のTDD, BDDフレームワークはたくさんあるけど，テスト結果の見た目の良さと記述の楽さで Vows というフレームワークを使っている．RSpec からの影響を受けていて，Rack アプリケーションのテストと同じような感覚で書ける，というのが良い．

たとえばこんな感じでテストコードを CoffeeScript で書く

で --spec オプションをつけて実行するとこういう風に表示してくれる．

assertion でテストが通らないと黄色く，内部エラーの場合は赤にラベルが表示される．しっかり全部通すと

このように表示される．見た目が良いし，ラベリングを丁寧にやるとテストの内容がわかりやすい．

元々 node.js のテスト用なので，require exports など， pure JavaScript には無いグローバル変数が必要だけど，ちょっとした工夫でクライアントサイドの JavaScript / CoffeeScript もテストできるようになるよ．という話

1. JavaScript/CoffeeScriptのファイルの最後に`export`すれば良し

テストしたいオブジェクト群やメソッド群はこうやるだけで ok. アプリケーションのルートディレクトリ($APP_ROOT)に対して，テストする対象のスクリプトは $APP_ROOT/public/(js|coffee)/ 以下にあるとする

1-1-a. JavaScript の場合 ($APP_ROOT/public/js/hoge.js)

// テストしたいオブジェクト
var Hoge = function(id, name){
    this.id = id;
    this.name = name;
    return this;
};
//...

if (typeof exports != 'undefined' && exports !== null) {
   exports.Hoge = Hoge;
}

1-1-b. CoffeeScript の場合 ($APP_ROOT/public/coffee/hoge.coffee)

# テストしたいオブジェクト
class Hoge =
    constructor: (@id, @name) -> @
    #...

exports?.Hoge = Hoge

で，テストコードには以下のように記述する. アプリケーションのルートディレクトリ($APP_ROOT)に対して，テストコードの場所が $APP_ROOT/spec/(js|coffee)/ 以下にあるとする

1-2-a. JavaScript の場合 ($APP_ROOT/spec/js/hoge_spec.js)

// テストしたいコードを相対パスで指定して require する
var vows, assert, Hoge;
vows = require('vows');
assert = require('assert');
Hoge = require('../../public/js/hoge').Hoge;

vows.describe('Hoge').addBatch({
    'a instance':{
        topic: new Hoge(1, 'hoge'),
        'has id': function(hoge){ assert.equal(hoge.id, 1);},
        'has name': function(hoge){ assert.equal(hoge.name, 'hoge');}
    },
    // テストを上記と同じように書いていく
}).export(module);

1-2-b. CoffeeScript の場合 ($APP_ROOT/spec/coffee/hoge_spec.coffee)

# テストしたいコードを相対パスで指定して require する
vows = require 'vows'
assert = require 'assert'
Hoge = require('../../public/coffee/hoge').Hoge

vows.describe('Hoge').addBatch
    'a instance':
        topic: new Hoge(1, 'hoge')
        'has id': (hoge) -> assert.equal hoge.id, 1
        'has name': (hoge) -> assert.equal hoge.name, 'hoge'
    # テストを上記と同じように書いていく
.export module

「なんで Vows なの?」 ってそもそもの疑問については，「最初っから CoffeeScriptでテスト対象もテストコードもそのまんま書いて実行できるから」．他のフレームワークに Jasmine もあるけど，あれよりも簡単にコマンドで

$ vows *_spec.* -w

と実行しておけば watch モードとして実行され，テストコードの更新の度にテストを回し直してくれるので，ガンガンテストコードが書ける．Jasmine みたくいちいちブラウザで実行結果を開いたりしなくても良い． RSpec の .autotest の中にこのコマンドを回させてしまうのもアリ．ただ，watch モードではテスト対象そのものの更新はチェックされないので，TDD でガンガンやってるって感はしない．特にテスト対象側の undefined エラーで落ちたりする場合なんかだと途中で止まったりする(この場合，Ctrl+C で落とさないとダメ)．

普段は

テストコードを先に書く
テストのあるディレクトリで$ vows *_test.* --spec でテスト走らせてみる
コケたり，エラーで落ちた箇所を修正する
もっかいテスト走らせる

を繰り返してる．

2. クライアントサイドで，先に読みこまれているはずの JavaScript / CoffeeScript があった場合

ここまでは普通に独立した各スクリプトの場合のテストだけど，他の JavaScript ライブラリをHTML側で先読みされていて，そのグローバルオジェクトがそのスクリプトで利用されている場合．

たとえば jQuery や Underscore.js なんかのライブラリのメソッドを利用していた場合など．

この場合，Vows からはライブラリからのグローバルオブジェクト，メソッドはわからないので，実行中にコケたりする．なので，テストの方のスクリプトに require を書いておかないといけない．以下，スクリプトファイルと同じディレクトリにそれらライブラリがあると仮定した場合のコード．

2-1. JavaScript の場合 (hoge.js)

// 使ってるライブラリを require する
if (typeof require == 'function') {
    if (typeof $ == 'undefined' || $ === null) {
       $ = require('./jquery').$;
    }
    if (typeof _ == 'undefined' || _ === null) {
        _ = require('./underscore')._;
    }
}

2-2. CoffeeScript の場合 (hoge.coffee)

# 使ってるライブラリを require する
if require?
    $ ?= require('./jquery').$
    _ ?= require('./underscore')._

たったこれだけ．この場合， pure JavaScript であろうと，ブラウザ実行時には require, exports 共に undefined なのでそのままスルーされる，という仕組み

3. まとめ

すごく単純な話で，ブラウザ側の実行時にひっかかって困らないように require, exports を

if (typeof ... != 'undefined' && ... !== null){ ... }

で囲って，その中でテストの為に渡す処理を書けば良し．ちなみに，デプロイ時に GCC で圧縮・最適化をかける際，このあたりの記述はスルーされて圧縮後には消えるはず．

CSS3 Transition のための CoffeeScript / JavaScript

2011-04-22T13:43:00.000+09:00

CSS3 Transition がほぼモダンブラウザで使えるようになってきた

昨年 CSS3 の仕様にアニメーションプロパティが加わって，一時的な熱狂があったわけだけど，それから一年してどのブラウザにも一応の CSS Animation / Transition が出来るようになってきた．しかし，W3C の仕様のとおり transition: <property> <duration> <timing-function> <deley> を指定して動くわけでなく，-moz- なり -webkit- なりのプレフィックスがまだ必要な現状だったりする．ん? ああ，IE お前は座ってろ

CSS プロパティを結局 jQuery で差し込む方向で

最近，やっと自分のサイトを開発しようと思って，Sinatra + mongoDB で，View を Haml Sass CoffeeScript + jQuery で作っている最中なのだけど，アニメーション効果をつけるにあたって，どうも Sass の mixin では可変長引数に対応していないため，思うような効果を出せなかった．また，.fade-in .fade-out とかそんなクラスをマークアップするのは HTML のモデル的に醜いとか思った．ということで jQuery#css メソッドを使ってアニメーションを制御する方向にした

ダルいポイント2つ

クロスブラウザ対応の為にたくさんプロパティを生成しないといけない
これを一行一行書くのはダルい．しかも次の項のようにずらずらと設定を書く必要がある
トランジションを複数のプロパティに一度にかけないと変な動きする

トランジションを効かせるCSSプロパティが一つであれば，クラスを作って sass の mixin 呼ぶだけで事足りる．GitHub にある madr 氏の css3-sass-mixins とかを @import すれば幸せになる．

んが，こういう風に二つ以上のプロパティを同時に作用させたいって時がある
```
.fade-in {
    visibility: visible;
    opacity: 1;
    transition: visibility 1s linear, opacity 1s linear;
    -o-transition: visibility 1s linear, opacity 1s linear;
    -webkit-transition: visibility 1s linear, opacity 1s linear;
    -moz-transition: visibility 1s linear, opacity 1s linear;
}
```
先のmixinにはこうした複数のプロパティ適用に対して有効でなく，まぁ transition-property: には all って特殊キーワードが使えるんだけど，それを指定してしまうと，継承してる，トランジションが効くすべてのプロパティまでアニメ〜ションしてしまう．あとそのせいで確実に重くなる．試しに all と指定してブラウザの文字を大きくしたり小さくしてみるといい．気持ち悪いから．というわけで「複数のプロパティを一度にトランジションかけたいが，必要なモンだけにしたい」というのをなんとかする．

jQuery#css に渡すオブジェクトを作るメソッド.coffee

雑ではあるけど，こんな風に書いた．CoffeeScript で

使い方は以下のようにやる．あ，以下のコードも Js より短く書けるから CoffeeScript で

style =
  visibility:'visible'
  opacity:1
  max-height: 100%
// .fade-in に トランジションを効かせたい
$(.hoge).css animateCSS style, '1s', 'ease-in-out', 0.5

jQuery#css に渡すオブジェクトを作るメソッド.js

CoffeeScript 使わねーよって人は JavaScript でコンパイルした方も記載しておくので，こちらを参考にして直して使えば良い

CoffeeScript の方がやりたい事を手短に書ける分だけ気持ちが良い．ただこのまんま HTML タグで呼び出すとデバッグできないんだよね．それが課題だな

dotfile (~/.file) の類を Dropbox で一元管理

2011-04-19T01:10:00.001+09:00

あらまし - 複数のマシンの環境を統一しておきたい

Dropbox で dotfile をまとめて持っておいて，複数のマシンでも同じ環境で作業できるようにしてる人ってもう既にたくさんいるし，新規性のあることではまったくないのだけど，ようやく自分もそこらへんの整備が終わったんで，記録として残しておく．

ドットつけないで，共有するファイルやディレクトリを Dropbox へ

Dropbox に共有するファイル群を入れる dotfiles ディレクトリを作る．

たとえば SKK だったら .skk-jisyo を my-jisyo とかにして，~/Dropbox/dotfiles/skk/my-jisyo としてつっこむ．どうせ後でドットファイルとしてシンボリックリンクしてしまうので気にせずどんどんやる．例として自分の場合を GitHub に晒しておく．ここには別途必要なプラグインとか，プライベートな設定ファイルとかは gitignore で弾いてるからそのままだと使えないのでご了承を

個別の環境用の設定の余地を残しておく

vim しかり zsh しかり，個別で環境変数や設定が別に必要な場合があるので，それ用に個別環境をロードする仕組みを各々のドットファイルに記述しておく．また，個別環境の下の履歴やバックアップまで共有するとおかしな事になるし，Dropbox も後々圧迫される．ので，履歴やバックアップを個々で持つように設定しておく．

たとえば zshrc の場合

# ... 先頭あたり
export ZSH=$HOME/.zsh # バラけないようにこんな風にまとめてしまう
source $ZSH/env_common.sh # 共通の環境変数を env_common.sh に書く

# ... 補完とか
autoload -U compinit
compinit -d $ZSH/compdump 

# ... どこでも良いけど，HISTSIZE を指定する前とかで
HISTFILE=$ZSH/history

# ... ファイルの末尾あたりに
source $ZSH/env.sh # 個別の環境変数をこっちに書く

としておくなど．当然，この場合 ~/.zsh を mkdir する必要がある．後のリンクを張る項で説明．なお，上記の例だと ~/.zsh/env_common.sh も Dropbox で共有する．

個別の環境へシンボリックリンクを張る

一回リンク用のシェルスクリプト書いておくと楽になる．ただ，間違って元の環境を破壊しかねないので，実行する前に以前の環境とかをちゃんと確認してからするように．

新しいマシンで何も手つかずの環境とかに以下のスクリプトを走らせる．例として vim

ln コマンドは，リンク元を絶対パスで記述しないと駄目なので $PWD を使ってる．当たり前だけど，カレントディレクトリでこのパスが変わるので，この場合だと ~/Dropbox/dotfiles/ に cd とか pushd してから走らせる．他の例は先にリンクした GitHub にそれぞれの場合のスクリプトがあるのでそれを見てみればよろしいかと．

After...

シンボリックリンクがちゃんと正しく張り終わったら，以下のような状態になる

どのマシンでも Vim などのエディタが同じ環境，プラグイン利用で使える!
SKK の変換履歴や登録が共有されてるので使えば使うほど便利になる!
コマンド履歴やバックアップは別々なんだけど，コマンドラインの利便性はどこでも一緒!
Dropbox でそれらが同期しているので，自分から手動で更新する必要が無い!

とても便利で幸せになれました

補足その1 - Dropbox が使えない環境では

VPS とか，Dropbox インストールできない環境下ではどうするかというと，自分の場合は ~/Dropbox/dotfiles 自体を git で管理しているので，そこから clone できる．ただ，gitignore してるプラグインの類はそれで入らないので，zip してから sftp で送ってしまえば，リンク張るのもスクリプトでそこまで面倒ではないかと．しかし課題として残るかも (Github をリモートにしないのであれば全部プラグインも git add してしまえという選択もアリ)

補足その2 - アプリケーションは当然入れてないと使えない

当然 Vim が入ってないとか，SKK が入ってないとか，そこらへんまで当然世話できないので，環境が手に入ったら，諸々必要なアプリケーションは入れておく手間はある．Vimperator の為に Firefox 入れるとか．

PHPUnit / Phing を MacOSX で実行できるようにして，NetBeans で開発するための設定メモ

2011-04-15T10:24:00.000+09:00

あらすじ

前回のエントリでMacOS マシンにも最新の PHP と PHPUnit, Phing が入り，開発途中になって pear や pecl のライブラリをインストールできるようになったのだけど，このままだとまだ NetBeans でホイホイ開発できるようにはなってない．このエントリで残りの環境構築をやる

/etc/php.ini をコピー

前回のビルドで，PHP は再インストールしたわけだけど，実は MacOS にはデフォルトの /etc/php.ini ファイルが無かったりする．(これは今回びっくりした) なので，pecl のライブラリなんかを呼び出せないままになっているのが確認できる．というわけで前回の PHP をビルドしたフォルダから php.ini-production なんかをコピーして編集する．(php.ini-development でも良いけど，別に PHP そのものをハック対象にしてない場合はこれで十分だろう)

前回で php のソースを ~/tmp に展開しているので，その前提で作業ログを載せる


$ pushd ~/tmp/php-5.3.6
$ find . -name 'php.ini*' -print
./php.ini-development
./php.ini-production
$ sudo cp php.ini-production /etc/php.ini
$ pushd /etc
$ sudo vim /etc/php.ini

/etc/php.ini を編集

拡張の指定はextension_dirとextensionで指定できるけど，Xdebug などは Zend_extension なので絶対パスで記述しないといけない事に注意．また，pecl のデフォルトインストール先は /usr/lib/php/extensions/ じゃなかったりするのでそれもあわせて．

;;; /etc/php.ini
;;; だいたい 805 行目くらい
; Directory in which the loadable extensions (modules) reside.                                                                         
; http://php.net/extension-dir
; extension_dir = "./"
; On windows:
; extension_dir = "ext"
;;; 拡張のインストール先を追記
extension_dir = "/usr/lib/php/extensions/no-debug-non-zts-20090626/" 
;;; Zend_extension をそれぞれ絶対パスで追記
zend_extension = "/usr/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so" 
 
;;; XDebug 用の追記
xdebug.remote_enable = On

当然 TimeZone の指定とか，他にも色々この時点でしてもいいけど，本題からそれるので省略．ひとまずこれで拡張の件は済んだ．この時点で，IDE 使わない開発が普通にできる．Phing も入れてあるので，プロジェクトのルートディレクトリに build.xml を書いて定期的に phing すれば良い

NetBeans 側の設定

前回でそれぞれのバイナリやライブラリはこんな感じにインストールされているはず．まぁそのまんまなので簡単

php

/usr/bin/php

phpunit(コマンドの方)

/usr/bin/phpunit

PHPUnit(ライブラリ)

/usr/lib/php/PHPUnit

これを NetBeans で利用できるように設定する．

NetBeans の [環境設定] の PHP の項目

一般:PHP 5 インタプリタを次に指定 → [/usr/bin/php]
一般:大域インクルードパスをフォルダ追加 → [usr/lib/php/PHPUnit]
単体テスト:PHPUnit スクリプトを次に指定 → [/usr/bin/phpunit]

大域インクルードパスに /usr/lib/phpを指定しても動くけど，他の余分なライブラリまで見る分だけ重くなるので，それはプロジェクト単位で追加した方がいい

これでちゃんとひととおり NetBeans で PHP プロジェクトを TDD で開発できるようになった．あとはリモートのリポジトリを Jenkins なんかで監視すると良い

PHPUnit / Phing を MacOSX で実行できるようにする為の PHP ビルド・インストールメモ

2011-04-09T01:42:00.001+09:00

あらすじ

PHP で開発するにあたって，「やっぱり複数人で開発するし，NetBeans とか IDE 使いたいよねー」的な話になったので，NetBeans を入れて，これまでリモートのサーバー上で Phing 使ってテストしてたのだけど，それをローカルマシンでやるにあたって，PHPUnit をインストールすることになった．バンドルされてる PHP も古いバージョンだし．

しかし，SnowLeopard に標準でインストールされている PHP には --with-pear 付きでビルドされておらず，しかも，バンドルで付けられていたビルドオプションをコピペして，追加して ./configure しても，--with-jpeg-dir とかでコケるという愉快なトラブルでえらく時間かかった．

というわけで，ビルドちゃんと出来るようになるまでの手順ログを書いておく

入れたい/使いたいモノ

こちらがわの環境

MacBook 6,1 (2009/10モデル)
MacOSX 10.6.7 SnowLeopard
XCode 3.2.5 (XCode Tools インストール済み)
Homebrew 0.8

ぶっちゃけ MacPorts だったら何も問題なかった．でも Homebrew の方が使っててステキなんですよ．アホみたいに /opt/local/ にファイルが入ったりしないし，アップデートも早く終わるし

ビルドオプション

バンドル時のオプション


./configure \
--prefix=/usr \
--mandir=/usr/share/man \
--infodir=/usr/share/info \
--disable-dependency-tracking \
--sysconfdir=/private/etc \
--with-apxs2=/usr/sbin/apxs \
--enable-cli \
--with-config-file-path=/etc \
--with-libxml-dir=/usr \
--with-openssl=/usr \
--with-kerberos=/usr \
--with-zlib=/usr \
--enable-bcmath \
--with-bz2=/usr \
--enable-calendar \
--with-curl=/usr \
--enable-exif \
--enable-ftp \
--with-gd \
--with-jpeg-dir=/usr/local \
--with-png-dir=/usr/local \
--enable-gd-native-ttf \
--with-ldap=/usr \
--with-ldap-sasl=/usr \
--enable-mbstring \
--enable-mbregex \
--with-mysql=mysqlnd \
--with-mysqli=mysqlnd \
--with-pdo-mysql=mysqlnd \
--with-mysql-sock=/var/mysql/mysql.sock \
--with-iodbc=/usr \
--enable-shmop \
--with-snmp=/usr \
--enable-soap \
--enable-sockets \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--enable-wddx \
--with-xmlrpc \
--with-iconv-dir=/usr \
--with-xsl=/usr \
--enable-zend-multibyte \
--enable-zip \
--with-pcre-regex=/usr

追加したオプション

-with-pear --with-libedit

↑のオプション以外はバンドル時に指定されていたはずのモノ．しかし，追加したオプションじゃなくてバンドルについてたオプションのみがコケていた．アホか

必要なモノ

別に全部公式サイトからバイナリ持ってきてやってもいいけど，たぶん面倒くさいよ．
libpng 以外は $ brew install FORMULA で余裕でした．これについては後述．

PCRE

Perl5 の正規表現を C でも出来るっていうライブラリ

libxml2

まさかこれが入ってなかったとは思わなかった

libjpeg/libpng

たぶん今回の詰まったキモ

もしかすると，あらかじめ自分が別の用事で既にライブラリをインストールしてたおかげでスルーされたものもあるかもしれない．でも大抵 Homebrew あれば大丈夫．MacPorts ならそもそも迷わず sudo port install php5 してもいい．

手順

PHP-5.3.6.tar.gz を DL して展開
~/tmpとかでよし

$ pushd ~/tmp
$ wget http://jp2.php.net/get/php-5.3.6.tar.gz/from/this/mirror \
> -O php-5.3.6.tar.gz
$ tar -xf php-5.3.6.tar.gz
$ pushd php-5.3.6

$ ./configure して必要なライブラリを確認しておく
$ brew install pcre
$ brew install libxml2
libjpeg と libpng を，このインストーラでインストールする
前述のオプションつけて $ ./configure
$ make && make test
$ sudo make install

ビルドは時間かかるので何か作業やってる時じゃなくて寝る前とか，よっぽどヒマな時にやった方がいい．とりあえず，これで購入時から書いてた PHP と動作互換をとりつつ出来るかと．(わかんない)

最後に． PHPUnit, Phing のインストール

あとはもうどのディレクトリでもいいから流れ作業で sudo してけばいいだけ

$ sudo pear channel-discover pear.symfony-project.com
$ sudo pear channel-discover components.ez.no
$ sudo pear channel-discover pear.phpunit.de
$ sudo pear channel-discover pear.phing.info
$ sudo pecl install xdebug
$ sudo pear install -a phpunit/PHPUnit
$ sudo pear install -a phing/phing

補足「なんで libjpeg/libpng は Homebrew 使わなかったの?」

2011年3月半ばあたりでこんな議論になって，今は libpng は Formula に一応残ってるものの，素直にコマンドで $ brew install libpng してもError出てインストールできないようになってる．警告どおり Formula/libpng.rb に

 def install
  ENV.x11
  # ENV.libxml2 # あるいはこっちの ENV を指定
  ...
  system "./configure", ...
  ...
 end

としてもダメ．その内，ちゃんと Formula そのものから除外されるっぽい．libjpeg は普通に Homebrew で入る．

今、隠蔽しているHaskellライブラリーだけ表示するワンライナー

2010-09-28T14:50:00.001+09:00

Haskellの外部ライブラリ、パッケージ管理ツール、Cabal と ghc-pkg

最近Haskellをまた書きはじめたのだけど、HUnit や HaXml などの外部ライブラリを利用する際に、Cabal というパッケージ管理ツールを利用してCPanとかRubyGemsのような感覚でライブラリーをインストールする事ができるのですね。

で、その際に「自分が何のライブラリをインストールしているか」には、以下の二つの方法で確認する事ができます。

Cabal コマンド内のサブコマンド list --installed

$ cabal list --installed

こちらは正しく言うと現在の haskage.haskell.org を参照して、利用しているライブラリのバージョンと公開されている最新版を表示します。普通だったら、これを見て Latest version available と Latest version installed を比較してバージョンを上げるのを検討するのに使います。

GHC のパッケージマネージャーから

$ cabal list --installed

こちらの場合は、現状ローカルでインストール済みの、コンパイルの事情利用不可にしてあるものを含めた全ての(GHC依存の?)ライブラリを列記します。cabal list --installed コマンドとはそういう意味で毛色が違います。

現状でもその事で躓いたりするのですが、Cabal から欲しいライブラリをインストールしようとした時に、依存している外部の、既にインストール済のライブラリとバージョンの違いにより失敗してしまう、という事がよくあります。(入れようとした hoge ライブラリが bar-1.0.0 に依存しているけど、既に後方互換が約束されていない bar-2.1.0 等がローカルに入ってしまっていた場合など)

こういった状況の時に、まず依存と互換性問題が起きているライブラリを ghc-pkg hide "ライブラリーの名前"とコマンド実行させて、コンパイラから参照できないようにして目的のライブラリーをインストールして上記の問題を解決させています。

本題: 読みづらいのをなんとかしたい

ということで、依存性問題を解決する為に、「今ローカルにどんなライブラリがあって、どれを隠蔽しておいたんだっけ」というのを確認する事が多々あるのですが、この ghc-pkg list の出力結果が読みにくい。

まぁこんな感じの表示になります。(ライブラリー)でくくられたものが隠蔽されているライブラリーになります。同名でバージョン違いのものは隣に併記してくれたり、矩形にテキスト整形されてはいるもの。まぁ英数字とダッシュと丸括弧でゴチャゴチャして見えますね。

たいていのケースは、「依存ライブラリのバージョン違いを隠蔽したい/隠蔽してたライブラリって何があったっけ?」なので、grep "hoge"なんかを使って検索しますが、このまんまだと一行に余計なものもついてきます。

スクリプト

そこでこうしました

結果このような出力結果に

うむ、見やすい!!! もし、ライブラリーが重複してないか調べたいなら、上のコードを改変して、

$ ghc-pkg list | sed 's/,/,   /g' | tr ',' '\n' | grep "$ライブラリーの名前"

とすると良いでしょう。

それにしても hide と cabal install --reinstall 繰り返しってったら、なんかライブラリの再インストールさえ満足にできなくなってきたような気が…

追記(2010/09/28 17：00)

これ書いた直後に「そういえばGHCのバージョンが古いっていう線もなくね?」と思って確認したら自分のGHCのversionが 6.10.4 で、最新版の 6.12.3 を入れなおしたら上のワンライナーがほぼ不要になってしまった…。まあいいか…

CSS3だけでWebサイトのUIをMacPro的なメタル調にしてみた

2010-05-27T01:30:00.029+09:00

百聞は一見にしかず。デモ

このエントリーはIEだと面白くないですよ!

文字サイズを大きくしたり小さくしたり、キャレットで文字列を選択してみたりして、これが画像でないか確めてみましょう。一切画像ファイルは使ってないよ!

<2010/05/28 13:00追記> Chromeだとwindow.onloadイベント処理が動作してないようなのでハンドラをonmouseoverに変更。マウスポインタを重ねるとloading...部分が動作するはず

I ♥ Internet

趣旨

見せてもらおうか、W3Cの新しいCSSの性能とやらを

先に結論

無理にすべてCSS3だけで表現を完結させようとすればするほど一昔前のブラウザ別ハックみたいな事しなきゃいけなくなりますよ。

ちなみにBloggerにデモ用に直にHTML記述してみたんだけど、やっぱりレンダリングが変になる。Blog内で無理にデモをやってみようとするとやっぱりどこかおかしくなる。あと要素へ与えるidやclass名を記事毎に気をつけて命名しないと意図しない所へCSSが適用されてしまったり…

一応、見掛けはこういう風になるはずなんです。完全なものがレンダリングされるのはChrome, 次にFirefox, そして Safari, Operaの順ですね

ソースコード

gist: 414498 - GitHub

ローカルに保存してFirefox, Safari, Chromeなどでひらいて確認してみてください

(予告)メイキング

メイキング、解説編は後日アップするという事で

あ、ちなみにこれエントリ込みでかなりの頻度で細かいところ修正してます。ご了承ください

Canvas要素の為の HSV/HLS色空間モデルjavascript

2010-05-14T01:11:00.012+09:00

趣旨「RGBで色指定すんのアホくさい…」

というわけでマンセル色相環とかそのへんの色計画に馴染みのある人が使いやすい色空間モデルを導入したい。

先に結論

たぶんuupaaさんが開発してるuupaa.jsのスピンオフ利用した方が良いですよ

Canvasで利用できるRGBカラーシンタックス

var red = 'rgb(255, 0, 0); // 赤100%
var alphaRed ='rgba(255, 0, 0, 0.5); // 赤100%なんだけど不透明度は50%

どんな場でこれが利用できるかというと、こう使う

var canvas = document.getElementById('canvas');
var ctx = canvas.getContext('2d');
ctx.beginPath();
ctx.strokeStyle = 'rgb(200, 255, 0)'; // ←ココ
ctx.fillStyle = 'rgba(0, 255, 0, 0.5)'; // ← ココ
ctx.stokreRect(0, 0, canvas.width, canvas.hight);
ctx.fillRect(0, 0, canvas.width, canvas.height);
ctx.closePath();

#FF0033 みたいな表記よりもわかりやすいんじゃないですかねー、という事はあるし、透過色もサポートされてはいる。これはありがたい…。

だけど、これだと「色相のグラデーションをやりたい」とか「明るさのグラデーションをやりたい」はムリ。っていうか正規でHSVとかサポートされてないの? って調べてたんだけど、すぐに見つからなかったので、もう自前でモデルつくって見る事にした。結果的に凄い基本的な色空間の変換アルゴリズムを知る良い勉強になったので仮にムダでも良かった事にする。

ソースコードは例のごとくGistに
ColorSpaceModel.js

使い方

var hlsa = new HLSA(0, 0.5, 1, 1); // ← HLSA色空間における 赤の純色
var hsva = new HSVA(0, 1, 1, 0.9);   // ← HSVA色空間における 赤の純色(不透明度90%)

var color1 = convertHSLAtoRGBA(hlsa).toString() // 'rgb(255, 0, 0)'
var color2 = convertHSVAtoRGBA(hsva).toString() // 'rgba(255, 0, 0, 0.9)'

convert{$Model1}to{$Model2}({$InstanceOfModel1}) っていう書式で命名している関数があるので、それにモデル化したオブジェクトを渡し、toString() 関数を呼ぶと(RGBAモデルなら)canvasで使える文字列が返る、という仕様にしました。

でもこれは非常にJava脳っぽいところがあるので、多分これJavaScriptユーザーにとっては不自然なんだろうな、という処もあり、今後改良したいところ。

なんというか convert〜の戻りが直に文字列返ってくるのがちょっと気に入らなかったというか、Objectとして返す方が一旦あるモデルに変換してから、メンバを少し弄って、更に別のモデルに変換する、みたいな便利さがあるんじゃないかとか思ったり。実際どうなんだろ

デモ

Color:

coding as drawing

Fibonacci Algorithm Benchmark

Subject

How

Hardware/OS

fib(n) in 60fps

Algorithm

最速アルゴリズム : φ ^ n / √5 (O(log n))

Result

Implements

Benchmark Script

結論

ニコニコ超デザイン-Metro考察編-を公開しました

ニコニコ超会議で発表したスライドを公開しました

この発表内容について

おわりに-ニコニコ超会議に参加された皆様へ御礼

BDD on Haskell その5 : テスト用ユーティリティ関数など

例1 TemplateHaskell を使う

テスト実行

例2 自作のユーティリティ関数

リファクタリング -- 見やすいテストコード

テスト実行後の出力

BDD on Haskell チュートリアル その4 : リファクタリングとパフォーマンスチューニング

今回のテーマ 「テスト済みのモジュールのパフォーマンス改善」

現時点のパフォーマンス

テストを担保にリファクタリングする

Data.Fixed.div' を参考にする

テストで外堀を埋めつつリファクタリング

まとめ

BDD on Haskell チュートリアル その3-3 : 仕様変更はテストから

今回のテーマ - 「テスト済みのモジュールの仕様変更」

throw Exception する関数に対するテスト

使うモジュールたち

例外 テスト - Hunit

例外テスト - QuickCheck

IO が不要なのに throw を検証する事の不快な理由

「何をテストしたいんだか」純粋でなくなる

モジュールの目的の曖昧化

テストから修正

UnitTest/Util/NumericTest.hs

再度検証して，実装を修正

Util/Numeric.hs

テストしてみよう

まとめ

おまけ

BDD on Haskell チュートリアル その3-2 : throw Exception を使わず基本は Either を使おう

「どちらか」を表現する Either 型

throw しないで Either で異常値，未定義値を包む

Either と Maybe

例外 とか 例外処理とか要らなかったのでは

BDD on Haskell チュートリアル その3-1 : catch できない哀しみ

Haskell の例外処理

throw try catch

こんな風に使う

試してみる

Data.Fixed div' mod' に見る try catch の問題点

ソース見てみる

例外処理はテストしずらい

BDD on Haskell チュートリアル その2 : QuickCheck でランダムテスト

新年のご挨拶

前回までのエントリー

前回までのおさらい

ソースツリー

app/src/Util/Numeric.hs

app/src/UnitTest/NumericTest.hs

単体テスト実行

「ユニットテストで自分で考えてたユースケースは全部テストしたよ!」

どこまでやったら大丈夫だって言えるの?

開発者が具体的なテスト例を思いつくのを待つの?

ランダムテストを導入しよう

QuickCheck を使う

テスト実行

ランダムテストの失敗を，ユニットテストに引き上げる

Nearly 型クラスを利用してテストに近似かどうかをチェックできるように

テストを実行してみる

テスト済みの関数を基準にテストプロパティを書く

テストを実行

[わき道] 例外どうすんの

ユニットテスト TDD => ランダムテスト BDD

おまけ

BDD on Haskell チュートリアルその4 : リファクタリングとパフォーマンスチューニング

今回のテーマ「テスト済みのモジュールのパフォーマンス改善」

`Data.Fixed.div'` を参考にする

BDD on Haskell チュートリアルその3-3 : 仕様変更はテストから

`throw Exception` する関数に対するテスト

例外テスト - Hunit

BDD on Haskell チュートリアルその3-2 : throw Exception を使わず基本は Either を使おう

「どちらか」を表現する `Either` 型

`throw` しないで `Either` で異常値，未定義値を包む

例外とか例外処理とか要らなかったのでは

BDD on Haskell チュートリアルその3-1 : catch できない哀しみ

`Data.Fixed div' mod'` に見る `try catch` の問題点

BDD on Haskell チュートリアルその2 : QuickCheck でランダムテスト

`4.7 - 2.3 * 2 == 0.1` は `False`

BDD on Haskell チュートリアルその1 : HUnit で TDD を

例商と，小数の余剰を返す関数を定義してみる

まずテストコードから書く

BDD on Haskell チュートリアルその0

ベクターデータ形式で UI のイメージを作る時は「実際に利用されるサイズ」を考える