yasuabe blog

Haskell で平面ルービックキューブ

2012-01-07T20:40:00.001+09:00

急に、ルービックキューブをプログラムで解いてみたい衝動にかられたが、手元にブツが無い。近所のコンビニにも無かったので、作ってみることにした。

以下のような方針

極力シンプルに。本物に近い操作感とか立体性とか別にいらないので、二次元の図形で表現する。
中央の小正方形は動かさない事にする。
操作はテキストボックスへの入力とする。色を表す文字一文字により、その色が中央となる面の回転を表し、小文字なら時計回り、大文字ならその逆とする。
現在、テキストボックスに入力されている文字列全体が反映された結果を描画する。
図形は中央に描画する。
Haskell でやってみる

結果から示すと、以下が実際の様子。まず初期表示

初期表示

赤い面を時計回りに2回、青い面を時計回りに1回、赤い面を反時計まわりに1回、青い面を反時計まわりに1回、それぞれ90度回転させた結果。

コードは以下のような感じになる。

module Main where

import Graphics.UI.Gtk
import Graphics.UI.Gtk.Glade
import Graphics.UI.Gtk.Gdk.GC
import Graphics.UI.Gtk.Gdk.Drawable
import Graphics.UI.Gtk.Gdk.Events as Evt
import Data.IORef

--図形
data SquareColor = G|R|W|Y|O|B
color G = Color 0x0000 0xE000 0x0000
color R = Color 0xE000 0x0000 0x0000
color W = Color 0xFFFF 0xFFFF 0xFFFF
color Y = Color 0xFFFF 0xFFFF 0x0000
color O = Color 0xF000 0x5000 0x0000
color B = Color 0x0000 0x0000 0xD000

initialState = map (replicate 9) [G,R,W,Y,O,B]

v60    = (18, -10)
v120   = (18,  10)
v180   = (0,   21)
angles = [[(-108,-30), v120,v180],
          [(-108,-30), v60, v120],
          [(-54,   0), v60, v180],
          [(0,   -30), v60, v180],
          [(0,    33), v60, v120],
          [(54,  -60), v120,v180]]
allParas = concatMap createParas angles 
createParas v = map toPara $
    map (\n -> dupV v n) [0..2] >>= (\x -> map (\n ->dupH x n) [0..2])
toPara = (\[(ox,oy), (x1,y1), (x2,y2)] ->
  [(ox,oy), (ox+x1-1, oy+y1-1),
  (ox+x1+x2-2, oy+y1+y2-2),(ox+x2-1, oy+y2-1)])
dupH = (\[(ox,oy), v1@(x1,y1), v2] n -> [(ox+x1*n, oy+y1*n), v1, v2])
dupV = (\[(ox,oy), v1, v2@(x2,y2)] n -> [(ox+x2*n, oy+y2*n), v1, v2])

centering _ [] = []
centering size (angle: angles) =
  (map (centeringPoint size) angle): (centering size angles)

centeringPoint (w, h) (x, y) = (x + (div w 2), y + (div h 2))

--ウィンドウ操作
main = do
    initGUI
    surfaceIORef <- newIORef initialState
    Just xml     <- xmlNew "rcube.glade"

    window       <- xmlGetWidget xml castToWindow "window1"
    onDestroy window mainQuit

    drawingArea  <- xmlGetWidget xml castToDrawingArea "drawingarea1"
    onExposeRect drawingArea (const $ do
        dw       <- widgetGetDrawWindow drawingArea
        gc       <- gcNew dw
        surface  <- readIORef surfaceIORef
        size     <- widgetGetSize drawingArea
        drawCube dw gc size surface)

    entry        <- xmlGetWidget xml castToEntry "entry1"
    onEditableChanged entry $ do 
        n <- get entry entryText
        writeIORef surfaceIORef $ rotateAll initialState n
        widgetQueueDraw drawingArea

    widgetShowAll window
    mainGUI
  where
    rotateAll p [] = p
    rotateAll p (x:xs) = rotateAll (rotate p x) xs
 
    drawCube d g size x = do
      drawParas d g (foldl (++) [] x) $ centering size allParas
    drawParas d g _ [] = return ()
    drawParas d g (x:xs) (p: ps) = do
      gcSetValues g $ newGCValues { foreground = color x }
      drawPolygon d g True p
      drawParas d g xs ps

-- 回転操作
g2r [g,r,w,y,o,b] = [r6 o,r3 g,r3 w,r3 r,y,   r9 b]
r2g [o,g,w,r,y,b] = [r9 g,r9 r,r9 w,y,   r6 o,r3 b]
w2r [g,r,w,y,o,b] = [r9 g,w,   r3 o,r3 y,r3 b,r6 r] 
r2w [g,w,o,y,b,r] = [r3 g,r6 r,w,   r9 y,r9 o,r9 b] 
y2r [g,r,w,y,o,b] = [r9 w,y,   o,   r3 b,r3 g,r9 r]
r2y [w,y,o,b,g,r] = [r9 g,r3 r,r3 w,y,   o,   r9 b]
o2r [g,r,w,y,o,b] = [r6 b,r6 o,r6 y,r6 w,r6 r,r6 g]
r2o [b,o,y,w,r,g] = [r6 g,r6 r,r6 w,r6 y,r6 o,r6 b]
b2r [g,r,w,y,o,b] = [r9 y,b,   r9 o,r3 g,r3 w,r]
r2b [y,b,o,g,w,r] = [r9 g,r,   r9 w,r3 y,r3 o,b]
rotate [(g1:g2:g3:gs), [r1,r2,r3,r4,r5,r6,r7,r8,r9],
        (w1:w2:w3:ws), (y1:y2:y3:ys),
        o,              (b1:b2:b3:bs)] 'r' =
       [(w1:w2:w3:gs), [r7,r4,r1,r8,r5,r2,r9,r6,r3],
        (y1:y2:y3:ws), (b1:b2:b3:ys),
        o,              (g1:g2:g3:bs)]
rotate [(g1:g2:g3:gs), [r1,r2,r3,r4,r5,r6,r7,r8,r9],
        (w1:w2:w3:ws), (y1:y2:y3:ys),
        o,             (b1:b2:b3:bs)] 'R' =
       [(b1:b2:b3:gs), [r3,r6,r9,r2,r5,r8,r1,r4,r7],
        (g1:g2:g3:ws), (w1:w2:w3:ys),
        o,             (y1:y2:y3:bs)]
rotate p 'g' =r2g (rotate (g2r p) 'r')
rotate p 'G' =r2g (rotate (g2r p) 'R')
rotate p 'w' =r2w (rotate (w2r p) 'r')
rotate p 'W' =r2w (rotate (w2r p) 'R')
rotate p 'y' =r2y (rotate (y2r p) 'r')
rotate p 'Y' =r2y (rotate (y2r p) 'R')
rotate p 'o' =r2o (rotate (o2r p) 'r')
rotate p 'O' =r2o (rotate (o2r p) 'R')
rotate p 'b' =r2b (rotate (b2r p) 'r')
rotate p 'B' =r2b (rotate (b2r p) 'R')
rotate p _ = p
r3 [s1,s2,s3,s4,s5,s6,s7,s8,s9] = [s7,s4,s1,s8,s5,s2,s9,s6,s3]
r6 x = r3 $ r3 x
r9 x = r6 $ r3 x

画面定義は、GtkWindow に GtkVBox を置いて、その上側に GtkDrawingArea、下側に GtkEntryを置いたものを、Glade 3.8.1 で適当に作っておく。

====

一応、ルービックキューブにはなったが、遊ぶにはシャッフルする機能を追加する必要がある。あと、そもそもの目的だった、解く方のコードも書こうと思うのだけど、なんかここまでの作業で変にコーディング欲が充足されてしまって、当初のモチベーションが既に半減してしまった。なんだかなあ。

s/UT/UnitTest/

2012-01-05T00:27:00.000+09:00

このブログで今まで UnitTest について書いた投稿には、「UT」というラベルを付けていたが、これを今日、「UnitTest」に付け替えた。

最初は何の気なしに「UT」としてしまっていたけど、最近は、なんだか見れば見るほどウォーターフォール文化における単体テストを表す略号に見えてきて、本来語りたい事とのズレが大きく感じられるようになってきた。

ちなみに本文では、だいたい UnitTest とパスカルケースで書いてきたつもり。これは、ウォータフォールの単体テストと区別するためであると同時に、本家 wiki の仕様に合わせてリスペクトを表明しているからでもあったりする。

ところで、ウォーターフォール色が強い組織・現場では、未だに「実装フェーズ」の直後に「単体テストフェーズ」を設けて、そこで初めて JUnitコードを書き始めるような残念な開発が、特に反省されることもなく日々実践されている。

そういう現場でも、理論的には後付けテストはダメなんだと言う事が、何かの拍子に認知され始めて、一応名目上は「実装・UTフェーズ」みたいに、前後関係をボヤかした感じになったりするのだけど、いかんせんプログラマの意識が「テストの事なんか後で考える」のままだから、実質的には何も変わらないし進歩もない。

泳ぎの真似を陸上でどれだけやったところで泳げるようになんかならないように、後付けテストなんか何年やってもテスト・ファーストで書けるようには全然ならない。

だからそろそろ、現場の開発チームで指導的な立場にある人は、「できればなるべく差し支えない範囲でTDD推奨」みたいな感じではなく、そろそろ「TDD必須」って宣言すべきだと思う。

本当に、一度できるようになったら、というか、できるようになってみないと「テストを先に書く」方がその逆よりも、工数、品質、仕事の面白さなど、どれをとっても格段に優れているという認識は成立しないのだろうと、つくづく思う。

とはいっても、「やってみればテストファーストの方が速い事が分かるよ」なんてやんわりと言って聞かせたところで、どうせ一向に浸透しないのはもう分かった。つう事は、山本五十六も「やってみせ、いって聞かせて、させてみて、褒めてやらねば人は動かじ」なんて言っているとおり、まずは横に座って実演するところから始めなければならない事になるらしい（やっぱ結局XPに戻ってくる事になるのか…）。

高跳びでも、背中を下に向けた方がその逆より高く跳べるという事に、フォスベリーが記録を出すまでは、だれも気づかなかった。だから、まず「やってみせ」から始めないとダメなのだろう。やってみせる事なしに「言って聞かせて」も結局効果がないし、「させてみせ」も、結局ちょっと目を離したスキにうやむやになってしまう。

・・・つう事を考えているのだけど、本当に残念で仕方が無いが、今の現場では直接コードを書いて実演できるような立ち位置ではなかったりする。次の現場こそは、まずは絶対に、自分で「やってみせ」るところから始められる、実装メインのロールでプロジェクトに参画したい。

Haskell でソケット通信をやってみる

2012-01-01T07:09:00.001+09:00

Haskell でソケットを使ったクライアント-サーバ通信をやってみる。

Haskell を使ったネットワーク・プログラミングの入り口が分かればいいので、クライアントから受け取った文字列をひっくり返して返すだけの、簡単なお題とする。

まず、サーバはこんな感じ。

import Network
import System.IO 

main :: IO ()
main = withSocketsDo $ do 
    hSetBuffering stdout NoBuffering
    server `catch` (const $ putStrLn "Exception caught.")
    putStrLn "Connection closed."

server :: IO ()
server = do
    sock <- listenOn (PortNumber 8001)
    repeats (receive sock)
    sClose sock

repeats :: Monad m => m Bool -> m () 
repeats x =
    x >>= (\x' -> if x' then (return ()) else repeats x)

receive :: Socket -> IO Bool
receive sock = do
    (h,host,port) <- accept sock
    hSetBuffering h LineBuffering
    msg <- hGetLine h           
    putStrLn msg 
    hPutStrLn h $ reverse msg 
    return $ null msg

クライアントはこんな感じ。

import Network
import System.IO 

sendMessage msg = withSocketsDo $ do 
        hSetBuffering stdout NoBuffering 
        h <- connectTo "127.0.0.1" (PortNumber 8001)
        hSetBuffering h LineBuffering
        hPutStrLn h msg
        hGetLine h >>= putStrLn
        hClose h

実行は GHCi でやってみる。
以下、サーバ側

ghci> :load server.hs
[1 of 1] Compiling Main             ( server.hs, interpreted )
Ok, modules loaded: Main.
ghci> main
Loading package bytestring-0.9.1.10 ... linking ... done.
 ・・・略・・・
Loading package network-2.3.0.7 ... linking ... done.
hello
1234

Connection closed.
ghci>

以下、クライアント側

ghci> :load client.hs
[1 of 1] Compiling Main             ( client.hs, interpreted )
Ok, modules loaded: Main.
ghci> sendMessage "hello"
Loading package bytestring-0.9.1.10 ... linking ... done.
 ・・・略・・・
Loading package network-2.3.0.7 ... linking ... done.
olleh
ghci> sendMessage "1234"
4321
ghci> sendMessage ""
ghci>

思ったより難しくない。次は、マルチスレッド化かなあ。

WYDKYDK が読めたよ！ﾜｰｲヾ(´ρ`)ﾉ゛ﾜｰｲ

2011-12-22T00:12:00.000+09:00

Alistair Cockburn の本に出てくる変な綴りの言葉。意味は分かるけどなんて発音するのか、ずっと分からなかったけど、何の気に無しにググってたら見付けた。

なんかソフトウェア開発とは全然関係ない、オレゴン州の自治会か何かの議事録らしき文書だけど、WYDKYDK ("wid-kee-dik")とある。カタカナにするとウィドキーディクみたいな感じだろうか。

綴りが珍しいのは略語だからで、もとはこんな文。

What you don't know you don't know

簡単な英語だけど、構文が分からない人が意外と多い。順を追って見てみると、

You don't know it.
あなたはそれを知らない

↓

What you don't know.
あなたが知らないもの

↓

You don't know you don't know it.
あなたはそれを知らないという事を知らない

↓

What you don't know you don't know.
あなたが知らないという事を知らないもの

といった感じで、入れ子になってたりして、プログラマには親和性が高い気がするんだが。

ところで、現場ではこの WYDKYDK への認識が足りない人が、例えば WBS を作ったり作らせたりすると、困った事になる。

「これだけ詳細化したんだから、見積りは正確なはずだ」なんて思考様式なんだけど、そもそも認識されていない事を詳細化しようもないし、予測に組み込みようもない。

正解は、何らかの形で現実に実行してみて「知らない事」を「知らなかった事」に変えていく事なんだけど、下手な人はこの当たり前の事ができず、日程にバッファを組み込むといった程度の、稚拙な手に走ってしまう。まあ現場ごとの文化とか、プロジェクトごとの事情とかもあるけどね。

小事の思案と割れ窓理論

2011-12-21T00:20:00.000+09:00

葉隠と言えば、「武士道といふは死ぬ事と見付けたり…別に仔細なし。胸すわって進むなり。」で有名だけど、正直、自分みたいな「すくたれもの」には難しい。

だけど実は葉隠には、そんなムリなやつばかりじゃなくて、普通に実践的なアドバイスも結構ある。

『大事の思案は軽くすべし。／小事の思案は重くすべし。』

これについて自分は、やっぱり開発者で飯を食っているせいか、前半をリスク管理の問題、後半を品質管理の問題と捉えてしまう。

前半の『大事の思案』がなぜ軽いかについては、非常にクリティカルな事態に関しては、いざというときに判断に迷って対応が遅れたりしないように、普段から方針を定めておいて、即断即決できるように備えておくべきだという解釈になる。

後半の『小事の思案』がなぜ重いかについては、三島由紀夫が葉隠入門の中で、アリの穴から堤防が崩れるように、瑣末なことを軽んじる事によって生活の体系や重大な思想までもが台無しになると解説している。

で、もちろん前半も後半もどちらも大事なんだけど、どちらかというと自分なんかには後半の方が、より切実にピンと来る。（管理の比重が大きい人は前者かもしれない。）

例えば、コーディング規約なんかみたいなものでも、「ぎりぎり読めりゃいいじゃん」みたいに適当にしないで、きっちり律儀に守ってかないといけない。と自分は思う。

そこを疎かにするから、規約違反の放置->->内部品質の低下->->外部品質の低下->->製品品質の低下ってな感じで、結局、また地獄になってくんじゃないかと。

で、この小さい事こそ大事ってのを、別角度から現代風に理論化したのが、割れ窓理論だと思う。

一般には、ジュリアーニ市長の時代にニューヨーク市が治安を回復したときにベースになった理論として有名なアレだけど、Wikipedia によるとこうなる

「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」

ささいに見える Duplicate code の放置が、コピペだらけの巨大な糞コードの山に繋がっていくという、まあ、ありがちなあれと同じじゃないだろうか。

で、この割れ窓理論をベースにした政策が「ゼロトレランス」だけど、開発現場に当てはめてみると、さしずめ Refactoring Mercilessly といったところか。

なんて事を考えていると、例えば、「途中return は是か非か」みたいな、一見不毛でアホらしい事についてムキになって議論するのも、けっこう大事というか、度を越さない範囲ならむしろ健全だとも思えてくる。もちろん自分もわりとムキになる方だ。

Spring 3.1 の Cache Abstraction

2011-12-20T01:45:00.001+09:00

Spring 3.1 が GA になった。最後に Spring を触ったのはこれを書いたときだから、もう2年近く前になるけど、こんときは 3.0 が出た頃だった。あんまり進んでなかったのかも。

いろいろググってみると、キャッシュがどうかしたとか書いてあるので、寝る前にちょっと試してみる。

package spring.trial1.ex1;

import java.util.HashMap;
import java.util.Map;

import org.springframework.cache.annotation.Cacheable;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

class Bar {
   Map<Integer, String> map = new HashMap<>();
   {
      map.put(1, "one");
      map.put(2, "two");
   }
   @Cacheable("bar")
   public String findString(int key) {
      System.out.printf("findString(%d) called%n", key);
      return map.get(key);
   }
}

public class Foo {
   public static void main(String[] args) {
   ApplicationContext ctx = new ClassPathXmlApplicationContext(
         "applicationContext.xml");
   Bar bean = ctx.getBean(Bar.class);

   System.out.println(bean.findString(1));
   System.out.println(bean.findString(2));
   System.out.println(bean.findString(3));
   System.out.println(bean.findString(1));
   System.out.println(bean.findString(2));
   System.out.println(bean.findString(3));
   }
}

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:cache="http://www.springframework.org/schema/cache"
  xmlns:p="http://www.springframework.org/schema/p"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
                http://www.springframework.org/schema/cache http://www.springframework.org/schema/cache/spring-cache.xsd">
  <cache:annotation-driven />

  <bean id="cacheManager" class="org.springframework.cache.support.SimpleCacheManager">
    <property name="caches">
      <set>
        <bean
          class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean"
          p:name="bar" />
      </set>
    </property>
  </bean>
  <bean id="bar" class="spring.trial1.ex1.Bar"/>
</beans>

pom.xml の dependency に spring-context 3.1.0.RELEASE と、cglib 2.2.2 を指定して、ビルド→実行したら、以下のような結果が得られる。（既に Maven Central に入ってるらしく、特に repository を指定したり、ローカルリポジトリに入れたりとかしなくても、普通に 3.1 がダウンロードされる。）


findString(1) called
one
findString(2) called
two
findString(3) called
null
one
two
null

findString の中身が呼ばれるのは最初だけで、2回め以降はキャッシュが使われているらしいのが分かる。

■ 雑感

JavaConfig/JSR-330 で xml を書かずに済むようになったと思ってたけど、この <cache:annotation-driven> に関しては、やり方が分からない。

仕方なく、昔ながらのapplicationContext.xml を書いてしまった。もしかすると、ちゃんとしたやり方があるのかもしれないけど、部分的にアノテーションで部分的にXMLみたいにマジでなるとしたら、結構イヤかも。

gtk2hs で落書きしてみる

2011-12-18T16:13:00.000+09:00

前回の書き込みで、gtk2hs の準備ができたので、もう一歩進めてみる。

10年以上前、Visual C++を使ってた頃、MFC のチュートリアルで Scribble というのがあった。これを、Haskell で試してみた。

ただし、MDI とかドキュメントの保存とかは割愛して、とりあえず描画の API とマウスイベントのハンドリングだけを気にすることにした。

仕組みは簡単で、マウスボタンが押下されたときから放されるまでのマウスポインタの軌跡を記録し、ウィンドウ描画時に各点を線でつないでいくというもの。コードは以下のようになる。

import qualified Graphics.UI.Gtk as G
import Graphics.UI.Gtk.Gdk.GC
import Graphics.UI.Gtk.Gdk.Events
import Data.IORef
import Graphics.UI.Gtk.Gdk.Drawable

main = do
    G.initGUI
    w <- G.windowNew
    G.onDestroy w G.mainQuit

    da <- G.drawingAreaNew

    isDrawingIORef <- newIORef False
    figuresIORef   <- newIORef [[]]

    G.onExposeRect da (const $ do dw <- G.widgetGetDrawWindow da
                                  gc <- gcNew dw
                                  f <- readIORef figuresIORef
                                  drawFigure dw gc f)

    G.onMotionNotify da True $ \Motion {eventX = x, eventY = y}-> do
      isDrawing <- readIORef isDrawingIORef
      case isDrawing of
        True  -> do  modifyIORef figuresIORef (\f->addPoint f x y)
                     G.widgetQueueDraw da
        _     -> return ()
      return True
  
    G.onButtonPress da $ \Button {eventX = x, eventY = y}-> do
      writeIORef isDrawingIORef True
      modifyIORef figuresIORef (\f->[point x y]: f)  
      return True

    G.onButtonRelease da $ \Button {eventX = x, eventY = y}-> do
      writeIORef isDrawingIORef False
      modifyIORef figuresIORef (\f->addPoint f x y)
      return True
  
    G.containerAdd w da
    G.widgetShowAll w
    G.mainGUI

  where
    point x y = (round x, round y)
    addPoint figures x y = (point x y: head figures): tail figures
    drawFigure _ _ [] = return ()
    drawFigure d g (f:fs) = do {
      G.drawLines d g f; drawFigure d g fs }

Haskell 自体にまだ慣れていないので、いかにも未熟な感じだけど、イベント処理と描画の作法がなんとなく分かってきた。ネット上で API を調べる事にも、だんだん慣れてきた。

ただ、IORef というのが、なんだかしっくり来ない。結局、状態を持ってしまってる事になり、どうも気持ち悪い。初心者なりに勝手に純粋関数型言語に期待していたのは、もっと、引数と戻り値だけでつながっていく感じなんだけど、まだまだ勉強が足りないのかもしれない。

結果としては、マウスボタンの判別をしていないので、右でも左でも書けてしまうけど、一応思ったとおりに動作するものができた。スプーの絵もこんな風に書く事ができる（頭頂部の突起がやや足りない事を除けば、我ながらよく描けたと思う）。

gtk2hs と Glade の相性

2011-12-18T00:19:00.000+09:00

gtk2hs を Glade と組み合わせて使うときのメモ。

Haskell の GUI プログラミングを試したくて、テキストボックスに文字列を入れて Enter を押したらラベルに表示されるような簡単なプログラム echo を、gtk2hs を使って書く実験をしてみた。

で、まず Glade というツールで GUI を定義する XMLを生成して、これを適当に書いた Haskell プログラムに読ませたら、こんなエラーが出た

$ ./echo 

(echo:4887): libglade-WARNING **: Expected <glade-interface>.  Got <interface>.

(echo:4887): libglade-WARNING **: did not finish in PARSER_FINISH state
echo: user error (Pattern match failure in do expression at echo.hs:8:5-12)

なんか Glade が生成した GUI定義XML の形式に問題があるっぽい。

調べてみると、Glade の出力形式には libglade と GtkBuilder の二通りの方法があり、gtk2hs が対応しているのは前者という事らしいのだが、ファイルを保存するときに libglade を選んでも、事態は全然変わらない。

さらに調べてみると Glade の3.8系と 3.10系で大きな違いがあって、出力XML に関してだと 3.10系では libglade 形式が無くなってるらしい。自分は、特に意識しないまま 3.10 を使っていた模様。

この2つのバージョン間で、保存時のダイアログに以下のような違いがある。

3.10系

3.8系

XML出力の違いは以下のような感じ

3.10系

<?xml version="1.0" encoding="UTF-8"?>
<interface>
  <requires lib="gtk+" version="2.24"/>
  <object class="GtkWindow" id="window1">
    <property name="can_focus">False</property>
    <child>
    …

3.8系

<?xml version="1.0" encoding="UTF-8"?>
<glade-interface>
  <widget class="GtkWindow" id="window1">
    <property name="can_focus">False</property>
    <child>
    …

というわけで、Glade の 3.8 系を使えば、gtk2hs がちゃんと処理できる形式の XML になる。

ただし、うちの環境で使ってる Fedora16 なんかでは、「ソフトウェアの追加／削除」から普通に Glade をインストールすると 3.10系が入って来てしまう。従って、この場合 3.8系を別途インストールする必要がある。

これは、ここから glade3-3.8.1.tar.xz を落としてきて、tar Jxf glade3-3.8.1.tar.xz -> ./configure -> make -> make install のようにすれば、/usr/local/bin/glade-3 が使えるようになる。

ちなみに、以下が実験で使った Haskellコード

module Main where

import Graphics.UI.Gtk
import Graphics.UI.Gtk.Glade
import Graphics.UI.Gtk.Gdk.Events as Evt

main = do
    initGUI
    Just xml    <- xmlNew "echo.glade"
    window      <- xmlGetWidget xml castToWindow "window1"
    onDestroy window mainQuit
    label       <- xmlGetWidget xml castToLabel "label1"
    entry       <- xmlGetWidget xml castToEntry "entry1"
    onKeyPress window $ \(Evt.Key _ eventSent _ _ _ _ _ _ name _) -> do
      keyPressHandler label entry name
      return eventSent
    widgetShowAll window
    mainGUI

keyPressHandler :: Label -> Entry -> String -> IO ()
keyPressHandler label entry "Return" = do
  name <- get entry entryText
  set label [labelText := name]
keyPressHandler _ _ _ = return ()

たかだかこれだけのコードを書くのに、かなり骨を折るが、いちおう動作する。

現場でよくある Agile 認識の齟齬

2011-12-14T00:10:00.001+09:00

現場で、開発プロセスをどうしましょうかなんて話をしていると、対話の流れを止めて指摘するほどではないけど、認識の違いが引っかかって嫌なときがある。今日は、そんな事象のメモ。

★ Agile プロセスはユルいものだという認識

	ユルい	キビしい
なんか違う	Agile全般	ウォーターフォール
たぶんこう	Adaptive Software Development、Crystal Clear	XP、Scrum、ウォーターフォール

Agile が総じてユルいのではなく、実はユルいのもキビしいのもある。この見方は、確かものすご〜く前に読んだ Cockburn の本に載ってたものだけど、仮に読んでなかったとしても同じ認識になってた気がする。

ちなみに、同じ High-Discipline プロセスの中でも、XP とウォーターフォールでは、前者が高効率・高難度で後者が低効率・低難度って事になると思う。寛容な方のグループの Crystal Clear なんかは、ユルい分、XP のような究極的な生産性は得られないけど、その分、負担が少ないって事になると思う。

★ 反復型といえば軽量プロセスだという認識

	軽量	重量
なんか違う	反復型プロセス全般	ウォーターフォール
たぶんこう	Agile系	UP系（AgileUPは除く）、ウォーターフォール

反復型のプロセスはどれもみな軽量だという思い込みもよくあるけど、たいてい「軽量プロセスはドキュメントを作らない」ってドクサも併発してるから、とりあえず反復型にしてみませんかなんて提案しても、習慣による心理的抵抗が大きい。

ウォーターフォール色の強い組織でも、ドキュメント体系を差し当たり尊重したまま、やや長めの期間の反復型プロセスに切り替えた上で、反復型が浸透してきた頃合いを見て、段々と期間を短くしたり文書や儀式を減らして、段階的に軽量にしていくというやり方もある。

Alloy 本

2011-12-13T02:44:00.000+09:00

土曜に Amazon のお急ぎ便で注文したら、日曜の夜に届いた。
日曜は暇がなかったので、今日、帰宅してから早速 Alloy Analyzer をダウンロードして、テキストに取りかかる。（単なる jar なので java -jar ですぐ動く。）

下図の左側ペインのようにコードを書き込んで、[Execute]>[Show Metamodel]を実行すると、、、

、、、このようなダイアグラムが得られる。

このダイアグラムは、四角形の配置を変えたり、色やフォントを変えたりして、ある程度見せ方を好きなように変えられるようだけど、どうもダイアグラムはそれほど本質的なものではないっぽい。

まあ、1時間ほどいじっただけだし何も理解できてないけど、上の上の図で左側のペインに書いてある Alloy コードがやっぱり主役っぽい。
これに述語（pred）やファクト（fact）をちょっと書き足しては、それに対してアサーション（assert）をちょっと付け加えて、そしたら実行して右側のペインで確認して、って流れになる模様。そうだとしたら、どこか TDD に似ていてとっつきやすい。

とは言っても、関心の重点は実装ではなくむしろ仕様であって高い抽象レベルで仕様をモデリングする事が目的の技術らしい。
ちなみに、抽象度をレベル分けするときに、伝統的に分析レベル、設計レベル、実装レベルなんて言ったりするけど、Alloy と同じ雰囲気で、なおかつレベルの違う他言語を持ってくると、分析レベル：Alloy、設計レベル：LePUS3、実装レベル：Coq てな感じに当てはまるんじゃないかと思う。

まあ、いきなりいろんな事をやり始めなくても、とりあえず Alloy だけでも、例えば金融システムのビジネスルールとかに適用して、仕様バグを取り除くような事は、結構すぐにでも始められそうな予感。

Haskell+HDBC+MySQL で Hello World

2011-12-11T08:07:00.001+09:00

Haskell で MySQL を使ってみるウォーミングアップ。

こんな環境

Fedora16
GHC 7.0.4
MySQL 5.5.18

====

まずテーブルを準備する。適当に mysql で MySQL に接続して以下のようにする。

mysql> create database hdbc_test;
mysql> connect hdbc_test;
mysql> create table greeting (id int not null auto_increment, text varchar(50), primary key(id));
mysql> insert into greeting(text) values ('Hello, world!');
mysql> select * from greeting;
+-----+---------------+
| id  | text          |
+-----+---------------+
|   1 | Hello, world! |
+-----+---------------+
1 row in set (0.00 sec)

テーブルの準備ができたら、次は使用するモジュールだけど、このサイトによると、Haskell から DB を使うには、HDBC、HSQL、HaskellDBと言った選択肢があるらしい。とりあえず HDBC でいってみる。

$cabal install HDBC
$cabal install HDBC-mysql

※ cabal 自体は、Fedora のアプリケーションの追加／削除でインストールした。
※ ghc-pkg という低レベルのコマンドもある。
※ MySQL以外に HDBC でサポートされてるやつを調べるにはここ

できたら、MySQL に接続してみる。
まず ghci を立ち上げて、モジュールを取り込んでからDB接続を取得する。

ghci>  :m +Database.HDBC Database.HDBC.MySQL
ghci> conn <- connectMySQL MySQLConnectInfo{mysqlHost="localhost", mysqlDatabase="hdbc_test", mysqlUser="root",mysqlPassword="XXXX", mysqlPort=3306, mysqlUnixSocket="/var/lib/mysql/mysql.sock"}
ghci>

mysqlUnixSocket に設定するファイル名は、/etc/my.conf に書いてあるのでそれを指定すればいい。成功したら、上のようにエラーメッセージなしで次のプロンプトに移る。

ちなみに、省略時値が既に設定されている defaultMySQLConnectInfo を使えば、この場合だと mysqlHost, mysqlUser, mysqlPort を省略して以下のようにできる。

ghci> conn <- connectMySQL defaultMySQLConnectInfo{mysqlDatabase="hdbc_test", mysqlPassword="XXXXX", mysqlUnixSocket="/var/lib/mysql/mysql.sock"}

※ソースを読みたかったら、ここで見られる

接続が得られたら、いよいよ HelloWorld。

ghci> quickQuery' conn "SELECT * from greeting" []
[[SqlInt32 1,SqlByteString "Hello, world!"]]

うん。できたっぽい。

ちなみにエラー無しで取得できたと思った Connection を、いざ使おうとしたら "No instance for (IConnection Connection)"なんて言われる事がある。自分もそうなったけど HDBC 関連のパッケージを更新したら解消した（参考URL）

====

ついでに、もうちょい他の事もやってみる。

■ prepared statement

ghci> stmt <- prepare conn "INSERT INTO greeting(text) VALUES (?)"
ghci> executeMany stmt [[toSql "Good-bye, world..."], [toSql "Hello, another world2!"]]
ghci> quickQuery' conn "select * from greeting"[]
[[SqlInt32 1,SqlByteString "Hello, world!"],[SqlInt32 2,SqlByteString "Good-bye, world..."],[SqlInt32 3,SqlByteString "Hello, another world!"]]
ghci> commit conn

JDBC やってるのと同じだね。

■ メタ情報

ghci> describeTable conn "greeting"
[("id",SqlColDesc {colType = SqlIntegerT, colSize = Nothing, colOctetLength = Nothing, colDecDigits = Nothing, colNullable = Just False}),("text",SqlColDesc {colType = SqlVarCharT, colSize = Nothing, colOctetLength = Nothing, colDecDigits = Nothing, colNullable = Just True})]

うーん…colType は良いけど、colSize がNothing になってるのはどういう訳だろう。ここは varchar (50) を反映していてほしかった。標準SQL の INFORMATION_SCHEMA で、普通にメタ情報を得ることも、もちろんできる。

■ 日本語

ghci> run conn "UPDATE greeting SET text='こんにちは' WHERE id=1" []
ghci> quickQuery' conn "select * from greeting where id=1"[]
[[SqlInt32 1,SqlByteString "S\147kao"]]

ははは、文字化けした。mysql で見ても化けてる。面倒そうだから後で考えよっと。

気になるところが幾つかあったけど、最初の試行としてはこんなものだろう。

====

最後に豆知識メモ。

ghci のプロンプトを変えるには、":set prompt "ghci> "と入力すればいい。これを永続化するには、~/.ghc/ghci.conf に同じ事を書く。ただし、どういうわけか、ファイルのパーミッションで、グループに w が付いていると無視される。無視されないようにするには、"chmod g-w .ghc .ghc/ghci.conf "として、書き込み権限を取り除いておけばいい。

あと、いろいろググってると、HaskellDB と HSQL と HDBC とで、似て非なる事柄が一緒くたに引っかかってくるので、酒を飲みながら作業してたりすると、 HDBC.MySQL のソースのつもりで HaskellDB.HDBC.MySQL のソースを読んで小一時間頭をかきむしって苦しむ事になったりする。

Prolog で楽典クイズ

2011-12-09T00:44:00.001+09:00

我々が日ごろ聞いてるふつうの音楽は、１オクターブの中に高さの異なる音が１２個あって、それぞれの音は「音名」という名前を持っている。

実は、ほとんどの音はそれぞれ三つの音名を持っている。例えば、ミ♯、ファ、ソ♭♭の組み合わせや、レｘ、ミ、ファ♭の組み合わせは同じ音高であったりする。

ところが、ある音だけは二つの音名しか持っていない。この音が何かわかるだろうか。

ダブルシャープとかダブルフラットを使ってるから、小学校で習うかどうかは分からないけど、たぶん義務教育の範囲には入ってる気がするくらいの基礎的な楽典知識だけで構成された問いだけど、面白いことに、意外と音楽をやってる人でも即座には答えられなかったりする。

ピアノの鍵盤を思い浮かべて単なる図形として捉えたら簡単なんだけど、今日は、これを「寝る前ちょこっとプログラミング」のお題にしてみようと、帰りの電車で思いついた。Prolog でやってみる。

====

note(0, 'C').
note(2, 'D').
note(4, 'E').
note(5, 'F').
note(7, 'G').
note(9, 'A').
note(11, 'B').

notes([0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11]).

alteration('ｘ', -2).
alteration('♯',  -1).
alteration('♮',   0).
alteration('♭',   1).
alteration('♭♭',  2).

noteWithThreeNames(Names)   :- findNoteNamesByCount(Names, 3).
noteWithOnlyTwoNames(Names) :- findNoteNamesByCount(Names, 2).

findNoteNamesByCount(Names, Count) :-
   notes(Notes), member(Note, Notes),
   collectNoteNames(Note, Names),
   length(Names, Count).

collectNoteNames(Note, Names) :-
  findall(Name, findName(Note, Name), Names).

findName(Note, Names) :- 
  alteration(Alteration, Diff), 
  getNote(Note + Diff, NaturalTone),
  concat_atom([NaturalTone, Alteration], Names).

getNote(N, X) :- N2 is N mod 12, note(N2, X).

素朴な実装だけど、以下のように正しい結果が得られる。


?- noteWithThreeNames(Names).
Names = ['B♯', 'C♮', 'D♭♭'] ;
Names = ['Bｘ', 'C♯', 'D♭'] ;
Names = ['Cｘ', 'D♮', 'E♭♭'] ;
Names = ['D♯', 'E♭', 'F♭♭'] ;
Names = ['Dｘ', 'E♮', 'F♭'] ;
Names = ['E♯', 'F♮', 'G♭♭'] ;
Names = ['Eｘ', 'F♯', 'G♭'] ;
Names = ['Fｘ', 'G♮', 'A♭♭'] ;
Names = ['Gｘ', 'A♮', 'B♭♭'] ;
Names = ['A♯', 'B♭', 'C♭♭'] ;
Names = ['Aｘ', 'B♮', 'C♭'].

?- noteWithOnlyTwoNames(Names).
Names = ['G♯', 'A♭'] ;
false.

====

音楽の話題でいえば、厳格対位法という、こんなのとは比較にならないくらいパズルっぽいやつがある。これは与えられた音の配列（定旋律）に対して、たくさんの「禁則」をくぐり抜けてごく限られた音の配列（対旋律）を見つけ出していくという、古典音楽作曲の伝統的なトレーニングなんだけど、視点を変えるとパズルの「川渡り問題」に似てなくもない。

たぶん、とっくにどこかのプログラマが挑戦してるだろうけど、もうちょいヒマができたら自分でもやってみたい気がする。

Jaskell このやろう！

2011-12-06T01:25:00.001+09:00

名前だけはずいぶん前から知ってたけど、あまり興味が無くて放置していた Jaskell。

『プロダクティブ・プログラマ』で紹介されて高評価だったから、さぞかし有望株なのだろうと思いきや…

誰も使ってる気配がない…

まあダウンロードはできるから、ちょっと試してみようとしたけど、そもそも動いてくれない。

Exception in thread "main" java.lang.NoSuchMethodError: jfun.parsec.Parsers.plus(Ljfun/parsec/Parser;Ljfun/parsec/Parser;)Ljfun/parsec/Parser;
 at jfun.jaskell.JaskellParser.(JaskellParser.java:299)
 at jfun.jaskell.JaskellParser.instance(JaskellParser.java:1377)
 at jfun.jaskell.JaskellParser.parseExprOrLib(JaskellParser.java:1436)
 at jfun.jaskell.Jaskell.parseExprOrLib(Jaskell.java:2356)
 at jfun.jaskell.Jaskell.parseExprOrLib(Jaskell.java:2376)
 at jfun.jaskell.Jaskell.eval(Jaskell.java:2469)
 at jfun.jaskell.Jaskell.evalInputStream(Jaskell.java:2657)
 at jfun.jaskell.Jaskell.evalResource(Jaskell.java:2555)
 at jfun.jaskell.Jaskell.evalResource(Jaskell.java:2531)
 at jfun.jaskell.Jaskell.importPrelude(Jaskell.java:1990)
 at jfun.jaskell.shell.Shell.getShellRuntime(Shell.java:42)
 at jfun.jaskell.shell.Shell.main(Shell.java:35)

ちなみにこの例外は、java コマンドから Jaskell Shell を起動しようとしたときにも、Jaskell インスタンスを生成してそいつにスクリプトを読ませようとしたときにも、どっちでも発生する。

第一、起動の仕方らしきものにたどり着くまでだいぶかかった。プロダクティブ・プログラマで紹介されている URL、「http://jaskell.codehaus.org/」は、Jaskell でググっても一番上にくるやつだけど、動かし方がどこにも全然書いてない。

jaskell-1.0.jar を実行したら何か起こるだろうと思ったけど、うんともすんとも言わない。MANIFEST.MFにも、やっぱなんも書いてなかった。

しょうがないから、JavaDoc を読んでたら Jaskell クラスというのがあって、こいつが文字列やファイルを評価する eval () メソッドを持ってるから、インスタンス作って eval() したら、上の例外。

半泣きでググってたら、Jaskell Shell というのを見つけるが、トップページからリンクされてる訳でもなく、どこが本物のプロジェクトページだか、訳が分からない。で、動かしてみたら、また上の例外。

まあ、何個かある jar の組み合わせを変えてみるとか、再コンパイルしてみるとかで、解決しない事もないんだろうけど、もういい。心折れた。降りるわ。

それにしても Neal Ford さんは、なんでこんなの紹介したんだ…。
普通に、Haskell 勉強して行こうやって結論しか出てこない。

Groovy+HttpClient で Redmine の wiki 更新

2011-12-04T23:19:00.001+09:00

Redmine の wiki を、HTTP のクライアントプログラムで更新する方法を考えてみた。言語は何でもいいが、ここでは Groovy を使ってみた。

====

例えば、以下のようなコードで、

class Test {
   def static content = """\
h1. 大見出し

なんとかこんとか
${ new Date().toString() }
"""
      public static void main(args) {
      new RedmineWikiRewriter()
         .login("user001", "password")
         .startEdit("project001", "Http_post_test")
         .saveEdit(content)
   }
}

下の画像のように、wiki ページが更新されるようなクラス RedmineWikiRewriter を考えてみる。

login() では、与えられたユーザ名とパスワードでログインして、Redmine から返されるクッキーを保持する。
startEdit()は、指定のプロジェクトの指定の wiki ページを開く。これはページのバージョンを得るために必要
saveEdit()は、wiki コンテンツをマルチパートの HTTP POST で送信する

コードは以下のようなものになる

class RedmineWikiRewriter {
   def static UTF8 = Charset.forName("UTF-8")

   def HTTPBuilder http = new HTTPBuilder('http://localhost:3000/')

   def redmineSession
   def authenticityToken
   def contentVersion 
   
   def project
   def wikiEntry
   
   public RedmineWikiRewriter login(String username, String password) {
      http.get(path : '/login', query : [q:'Groovy'] ) { resp, reader -> 
         authenticityToken = reader.BODY.DIV.DIV
            .findAll { it.id="login-form" }.depthFirst()
            .grep { "authenticity_token"== it.@name.toString() }[0]
            .@value.toString()
      }
      http.request(POST) {
         uri.path = '/login'
         send URLENC, [
            username:username, password:password, 
            authenticity_token:authenticityToken]

         response.success = { resp ->
            redmineSession = resp.getAllHeaders()
               .find {"Set-Cookie"==it.name.toString()}
               .value.split(";")
               .find {it.toString().startsWith("_redmine_session")}
            }
      } 
      this
   }
   RedmineWikiRewriter startEdit(String project, String wikiEntry) {
      this.project = project
      this.wikiEntry = wikiEntry 

      http.request(GET) { resp ->
         uri.path = "/projects/"+project+"/wiki/" + wikiEntry + "/edit"
         headers.'Cookie' = redmineSession
         response.success = { res, reader ->
            contentVersion = reader
               .depthFirst()
               .grep{"content_version"==it.@id.toString() }[0]
               .@value.toString()
         }
      }
      this
   }
   void saveEdit(String content) {
      DefaultHttpClient httpclient = new DefaultHttpClient();
      def uri = "http://localhost:3000/projects/"+ project +"/wiki/" + wikiEntry

      HttpPost httppost = new HttpPost(uri)
      httppost.addHeader('Cookie', redmineSession)
      
      MultipartEntity mpe = new MultipartEntity(
         HttpMultipartMode.BROWSER_COMPATIBLE, 
         "----WebKitFormBoundaryfmexSJQ5daIXdA04", 
         UTF8);
      addPart(mpe, "commit",          "Save");
      addPart(mpe, "project_id",       project);
      addPart(mpe, "action",          "update");
      addPart(mpe, "_method",          "put");
      addPart(mpe, "authenticity_token", authenticityToken)
      addPart(mpe, "id",             wikiEntry)
      addPart(mpe, "content[text]",    content)
      addPart(mpe, "content[version]", contentVersion)
      addPart(mpe, "controller",       "wiki")
      
      httppost.setEntity(mpe);

      httpclient.execute(httppost);
   }
   static void addPart(MultipartEntity entity, String name, String value) {
      entity.addPart(name, new StringBody(value, UTF8));
   } 
}

■ 振り返り

saveEdit() でも HttpBuilder を使いたかったが、なぜか思うように動かない。仕方なく、DefaultHttpClient を使用
wiki エントリの新規作成でも動くかどうかは未確認
たかだかこれくらいのコードでも、やってみると予想外に難しい。Redmine の Rubyコードを読んだり、HTTP の Header を調べたりいろいろ手間がかかった。あと multipart の POST も意外と難しい
仕組みはだいたい分かったので、他の言語でも試してみたい。もともとやりたかったのは、Excel 上の VBA からデータを整形して wiki に載せるというのを自動化すると言う事だった。

Fantom でサンタクロース問題

2011-12-03T03:43:00.001+09:00

前回のせんだみつおゲームで Fantom の Actor の使い方が何となく分かったので、サンタクロース問題でもやってみようと思う。クリスマスも近いしな。まあ、本物のプログラマには、そんなの関係ないけどな。

====

SantaClausProblem.main()は、サンタ、トナカイ、小人を生成して起動する

using concurrent

class SantaClausProblem {
  Void main() {
    ActorPool pool := ActorPool()

    Santa santa  := Santa(pool)
    Deer[] deers := (1..9).map |Int n->Deer| { Deer(pool, n, santa) }
    Elf[] elves  := (1..10).map |Int n->Elf| { Elf(pool, n, santa) }

    deers.each |Deer deer| { deer.send("vacation") }
    elves.each |Elf elf| { elf.send("home") }

    while (!pool.isStopped) { Actor.sleep(1sec) }
  }
}

Player は登場人物共通のコード。ActorUnderSanta はトナカイと小人の共通コード。

Actor
 └ Player
     ├ Santa
     └ ActorUnderSanta
         ├ Deer
         └ Elf

const class Player: Actor {
  new make(ActorPool pool) : super(pool) {}

  Void sleepRandom(Range r) { Actor.sleep(1sec* Int.random(r)) }
}
const class ActorUnderSanta: Player {
  const Int number
  const Santa santa

  new make(ActorPool pool, Int number, Santa santa) : super(pool) {
    this.number = number
    this.santa = santa }

  Str name() { this.typeof().name + number  }
}

トナカイと小人はこんな感じ

const class Deer: ActorUnderSanta {
  new make(ActorPool pool, Int number, Santa santa)
    : super(pool, number, santa) {}

  override Obj? receive(Obj? msg) {
    if ("vacation" == msg) { sleepRandom(1..10); santa.send(this) }
    return msg
  }
}

const class Elf: ActorUnderSanta {
  new make(ActorPool pool, Int number, Santa santa)
    : super(pool, number, santa) {}

  override Obj? receive(Obj? msg) {
    if ("home" == msg) { sleepRandom(2..15); santa.send(this) }
    return msg
  }
}

サンタはこんな感じ

const class Santa: Player {
  new make(ActorPool pool) : super(pool) {}

  override Obj? receive(Obj? msg) {
    echo (((ActorUnderSanta)msg).name + " が来た")
    
    if (msg is Deer) addDeer((Deer)msg)
    else if (msg is Elf) addElf((Elf)msg)
    
    return msg
  }
  Void addDeer(Deer deer) {
    Deer[] deers := get("deers", (Deer[])[,])
    deers.add(deer)
    wakeUpIfConditionIsMet
  }
  Void addElf(Elf elf) {
    Elf[] elves := get("elves", (Elf[])[,])
    elves.add(elf)
    wakeUpIfConditionIsMet
  }
  Void wakeUpIfConditionIsMet() {
    if (9 == getDeers().size) deliverToys
    else if (3 <= getElves().size) meetInStudy
  }
  Void deliverToys() {
    echo("おもちゃを配る")
    sleepRandom(1..2)
    getDeers().each|Deer deer| { deer.send("vacation") }
    Actor.locals["deers"] = (Deer[])[,]
  }
  Void meetInStudy() {
    echo("小人と打ち合わせ")
    sleepRandom(1..2)
    Elf[] elves := getElves()
    elves.eachRange(0..2, |Elf elf| { elf.send("home") })
    Actor.locals["elves"] = elves.removeRange(0..2)
  }
  Deer[] getDeers() { (Deer[])Actor.locals["deers"] }

  Elf[] getElves() { (Elf[])Actor.locals["elves"] }

  Obj get(Str key, Obj defaultValue) {
    Obj? result := Actor.locals[key]
    if (null == result) {
      result = defaultValue
      Actor.locals[key] = result
    }
    return result
  }
}

こんな結果が得られる

$ fan santaClausProblem.fan
Deer6 が来た
Deer1 が来た
Elf2 が来た
Elf9 が来た
Deer9 が来た
Deer2 が来た
Deer8 が来た
Deer3 が来た
Elf3 が来た
小人と打ち合わせ
Elf5 が来た
Elf8 が来た
Deer4 が来た
Deer7 が来た
Elf1 が来た
小人と打ち合わせ
Deer5 が来た
おもちゃを配る
Elf2 が来た
Elf7 が来た
Elf9 が来た
小人と打ち合わせ
Deer9 が来た
Deer5 が来た
Elf4 が来た
Elf6 が来た
Elf3 が来た
小人と打ち合わせ

Fantom でせんだみつおゲーム

2011-11-29T00:20:00.001+09:00

Youtube 観てたら、古いテレビの録画で、せんだみつおゲームをやっていた。やっぱりプログラマだから書いてみたくなる。言語はこないだ見つけた、Fantom にしてみる。

こんな感じ

Actor を５つ生成して、5名の参加者に見立てる
メインのスレッドでは、無限ループしながら Actor にタイミングを出しつづける
Actor は、"SENDA", "MITSUO", "NAHANAHA"を出力しながら、ランダムに次の番のアクターを指名する

using concurrent

class SendaMitsuoGame {
  Void main() { play }

  Void play() {
    pool := ActorPool()
    Actor[] actors := (1..5).map { Player(pool, it) }

    actors[0].send("next1")
    actors.each { it.send(actors.toImmutable) }

    messages := ["senda", "mitsuo", "nahanaha"]
    while (true) {
      message := getHeadAndRotate(messages)
      actors.each { it.send(message) }

      Actor.sleep(1sec)
    }
  }
  Str getHeadAndRotate(Str[] m) { m.add(m.removeAt(0)).last }
}

const class Player : Actor {
  const Int number

  new make(ActorPool p, Int number) : super(p) {
    this.number = number }

  override Obj? receive(Obj? msg) {
    if (msg is List) { Actor.locals["all"] = msg }
    else if (msg == "senda") doSenda
    else if (msg == "mitsuo") doMitsuo
    else if (msg == "nahanaha") doNahanaha
    else if (0==((Str)msg).index("next")) {
        setMyTurn(((Str)msg)["next".size..-1].toInt)
    }
    return null
  }

  Bool isNext(Int n) {
    diff := (n - number).abs()
    return 1 == diff || 4 == diff
  }

  Bool isMyTurn() { Actor.locals["myTurn"] }

  Void setMyTurn(Int f) {
    Actor.locals["myTurn"] = (number == f)
    Actor.locals["nextOnesTurn"] = isNext(f) }

  Void doSenda()  { callAndAssign("SENDA") }

  Void doMitsuo() { callAndAssign("MITSUO") }

  Void doNahanaha() {
    if (Actor.locals["nextOnesTurn"])
        echo("" + number + ": NAHANAHA");
  }

  Void callAndAssign(Str call) {
    if (!isMyTurn()) return

    next := nextOne()
    echo("" + number + ": " + call + " -> " + next);

    ((Actor[])Actor.locals["all"]).each { it.send("next" + next) }
  }

  Int nextOne() {
    next := Int.random(1..4)
    if (next < number) return next
    return (++next < 6) ? next: 1
  }
}

出力はこんな感じになる。ミスる事も無く、延々とせんだみつおゲームを繰り返す。適当な確率でミスさせる事も、もちろんできるけど、割愛。


$ fan senda.fan 
1: SENDA -> 2
2: MITSUO -> 5
1: NAHANAHA
4: NAHANAHA
5: SENDA -> 1
1: MITSUO -> 3
4: NAHANAHA
2: NAHANAHA
3: SENDA -> 5
5: MITSUO -> 4
5: NAHANAHA
3: NAHANAHA
4: SENDA -> 3
3: MITSUO -> 1
5: NAHANAHA
2: NAHANAHA
1: SENDA -> 4
4: MITSUO -> 5
1: NAHANAHA
4: NAHANAHA

しかし夜遅くまで、俺、何書いてんだ・・・

Groovy + POI

2011-11-25T02:56:00.001+09:00

Groovy では、クロージャを使って若干の下準備（下例では TableBuilder）をしておくと、以下のようなコードが書ける。


static void main(args) {
   new TableBuilder().with {
     sheet(   "test"
         )(   style(header)
         )(   "No"   )(   "名前"      )( nextRow
         )(   style(normal)
         )(   1      )(   "琵琶湖"    )( nextRow
         )(   2      )(   "多来加湖"  )( nextRow
         )(   3      )(   "富内湖"    )( endTable   )
   }.write(new FileOutputStream("sample.xls"));
}

TableBuilder の中では、Apache POI を使っていて、実行すると下のような Excel ファイルが sample.xls に書き出される。

カッコの開き方が気に入らないが、しょうがないらしい。下の A、B は等価だけど、C は別ものに解釈される。上例を C のようなカッコのに直すと、動作しない。

A	B	C
("A1")("B1")( "A2")("B2")	("A1")("B1" )("A2")("B2")	("A1")("B1") ("A2")("B2")

TableBuilder は下のコードのようになる。

class TableBuilder {
   def book
   TableBuilder() { book = new HSSFWorkbook() }
   def nextRow = { cell, style ->
      cursor.curry(cell.offset(1, -cell.columnIndex), style)
   }
   def endTable = { cell, style -> book }
   def cursor = { cell, style, arg ->
      if (arg instanceof Closure) { arg(cell, style) }
      else { 
         cell.setCellValue(arg)
         if (null != style) cell.cellStyle = style 
         cursor.curry(cell.next(), style) 
      }
   }
   def start(sheet){ cursor.curry(sheet.cellAt(0, 0), null) }
   def sheet(name) { start(book.createSheet(name)) }
   def style(styleClosure) {
      { cell, style-> cursor.curry(cell, styleClosure(book))}}
}

また、POI の API が Groovy コードの中で馴染むように、Mixin でメソッドを追加した。

class CellMix {
   def next() { offset(0, 1) }
   def offset(r, c) {
      sheet.cellAt(rowIndex + r, columnIndex + c) }
}
class RowMix {
   def cellAt(c) { getCell(c) ?: createCell(c) }
}
class SheetMix {
   def rowAt(r) { getRow(r) ?: createRow(r) }
   def cellAt(r, c) { rowAt(r).cellAt(c); }
}
class CellStyleMix {
   def borderMethodName = { s-> "setBorder" + s.capitalize() }
   def setBorder = { arg, edge -> 
      owner."${borderMethodName(edge)}"(arg."$edge" ?:BORDER_NONE); 
      setBorder.curry(arg) }
   def setBorder(Map arg) {
   setBorder.curry(arg)("top")("left")("bottom")("right") }
}

カッコを連鎖させるやり方にしたのは、単にクロージャとカリー化を試したかっただけで、実は、普通のクラスと leftShift() のオーバライドだけで、下のような C++風の書き方もできて、こっちの方がむしろスッキリしたコードになる。

sheet("test") << 
   "A1" << "B1" << endRow <<
   "A2" << "B2" << endTable

Fantom

2011-11-23T18:50:00.001+09:00

Info Q を読んでたら、Scala は先行き暗いねって記事があった。その内容自体は、まあ一理あるねくらいだけど、その問題提起をしている人が、気に入ってる言語として Scala と対比してる Fantom というのがあって、ちょっと調べてみた。

ここでサンプルコードを読んでみると、特にキャッチーな感じはしないけど、その分、実用性を念頭に置いてる気がする。知的な遊びのためよりむしろ割と泥臭い現場でも使えるように考えられてる印象。C# が分かる Javaプログラマで、面倒くさがりな人向けって感じか。言語仕様とか文法のパラダイムよりも、バイトコードやモジュールの扱いみたいなアーキテクチャ寄りの面に長所があるのかもしれない。

Linux にインストールするには、

オフィシャルサイトのトップページからダウンロードして、
適当なところに展開して、fantom-1.0.XX フォルダの中に入る
adm/unixsetup を実行して bin/下のファイル群に実行権限を付ける
bin/fan -versionを実行して、動作確認
必要に応じて PATH にbin/を追加する

以下のようにして、FWT という GUI 上の HelloWorld ができる。

ファイル FwtHello.fan に以下のコードを書く

using fwt
class FwtHello : Test
{
  Void main()
  {
    Window { Label { text = "Hello world" }, }.open
  }
}

$ fan FwtHello.fan で以下のようなちっこいウィンドウが表示される。

====

全然、Fantom とは関係ない話だけど、Fantom についていろいろググってて、Fantom で迷路の最短経路をとくパズルをやってる人がいたので、その先をたどると面白い記事を見つけた。

問題は「人材獲得作戦・４　試験問題ほか」に載ってて、この問題をどのように使ったかという顛末（「人材獲得作戦・３」）まで書かれていてとても面白い。

ただ、「問題の性質からいって、キューやリストが必要なのは明らかなのに、言語にCを使う人が相当多い。」ってところだけ残念。以下のようにすればオブジェクト指向も関数型も論理型も関係なく簡単に解ける。

S の上下左右に隣接する空のマスに1 を書き込む
1 に隣接する上下左右の空のマスに2 を書き込む
・・・
N に隣接する上下左右の空のマスにN+1を書き込む
Gに着いたら、隣接するマスを N からカウントダウンする形で戻れば完成

コードは簡単だから省略。C 言語はもちろん、多分 COBOL でも書ける。

Squeak の右クリメニュー

2011-11-23T05:35:00.001+09:00

Fedora のソフトウェアの追加／削除から Squeak をインストールするとバージョン 3.10 の Mysqueak ってのが入ってくるけど、かなり古いものらしい。 [→参照]

で、squeak.org のここから Squeak All-in-One をダウンロードすると、バージョン 4.2 が入っている。これを適当なところで展開して、squeak.sh を実行すれば、環境が立ち上がる。

ちなみに今使っている Linux 環境では、特に設定しなくても、右クリで 'do it'を含むコンテキストメニューがポップアップされたけど、古いやつはマウスの設定を変える必要があった。

何もない背景のとこで左クリック
World のメニューが出てくるので[open...]を選択
サブメニュー[Preference Browser]を選択
"mouse"でフィルタすると [swapMouseButtons] ってのが出てくるので、enabled にチェックを入れる

Windows 版だと、今のバージョンでもそんな設定が必要になる事もあるらしい。［→参照］

LePUS3

2011-11-21T20:52:00.001+09:00

昨日のブログを書くために、Wikipedia の Strategy パターンのエントリを開いてみたら、見慣れないものがあった。

なんかかっけえ。フリーメイソンとかみたいだ。三角のとことか。

LePUS3 というダイアグラムらしい。五十音的には、レプスさんくらいの感じだろうか。

Wikipedia によると

UML と同様のオブジェクト指向モデリング言語である。
formal specification language(形式仕様記述言語) の一つである。
First-order predicate logic(一階述語論理)のサブセットである
Codechart とも呼ばれる
いいところ
- スケーラビリティ ：少しの記号を用いた小さな Codecharts で、大規模なプログラムをモデリングできる
- 自動検証 ：設計と実装を同期させて、自動的に適合性を検証できる
- 可視化 ：リバースでソースコードから Codecharts を生成しやすい
- パターンの実装 ：プログラムがデザインパターンを実装しているかどうか、自動的に判断できる
- 設計抽象化 ：実装の詳細に取りかかる前に抽象的なプログラムを表現できる
- 総称：特定の実装ではなく、設計のモチーフとしてデザインパターンを表現できる
- 厳密性：設計者は Codecharts によるモデルを厳密に検証できる

いつのまにか、Wikipedia のプログラム関連のエントリの、至る所で LePUS3 が使われている。全然、気がつかなかった

オフィシャルサイトはここ

この本で紹介されている。

自分は注文したけど、しかし高い。
7300円もか。そんなにもか・・・

OSGi で GoF の Strategy

2011-11-20T19:16:00.001+09:00

久しぶりに OSGi でもいじってみるかと思い立つ。

Wikipedia に載ってる Strategy パターンのサンプル・コードでも OSGi で動かしてみよっかなと。今回は、Equinox でやってみる。

OSGi 環境を作る

適当な場所に osgi-test フォルダを作る
osgi-test フォルダ下に plugins フォルダを作る
Eclipse の plugins下から以下のファイルを osgi-test/plugins フォルダ下にコピーする。
- org.eclipse.osgi_*.jar
- org.eclipse.equinox.ds_*.jar
- org.eclipse.equinox.util_*.jar
- org.eclipse.osgi.services_*.jar

うちの環境だとこんな感じになる

$ cd /tmp/osgi-test
$ tree
.
└── plugins
    ├── org.eclipse.equinox.ds_1.3.1.R37x_v20110701.jar
    ├── org.eclipse.equinox.util_1.0.300.v20110502.jar
    ├── org.eclipse.osgi.services_3.3.0.v20110513.jar
    └── org.eclipse.osgi_3.7.1.R37x_v20110808-1106.jar

起動して、他のプラグインも追加しておく

$ java -jar plugins/org.eclipse.osgi_3.7.1.R37x_v20110808-1106.jar -console

osgi> ss
Framework is launched.
id State       Bundle
0 ACTIVE      org.eclipse.osgi_3.7.1.R37x_v20110808-1106

osgi> install file:///tmp/osgi-test/plugins/org.eclipse.osgi.services_3.3.0.v20110513.jar
Bundle id is 1
osgi> install file:///tmp/osgi-test/plugins/org.eclipse.equinox.util_1.0.300.v20110502.jar
Bundle id is 2
osgi> install file:///tmp/osgi-test/plugins/org.eclipse.equinox.ds_1.3.1.R37x_v20110701.jar
Bundle id is 3

osgi> start 1
osgi> start 2
osgi> start 3
osgi> ss
Framework is launched.
id State       Bundle
0 ACTIVE      org.eclipse.osgi_3.7.1.R37x_v20110808-1106
1 ACTIVE      org.eclipse.osgi.services_3.3.0.v20110513
2 ACTIVE      org.eclipse.equinox.util_1.0.300.v20110502
3 ACTIVE      org.eclipse.equinox.ds_1.3.1.R37x_v20110701

環境が出来たので、以降ではプラグインを作って動かしてみる。先に書いたとおり、Wikipedia にある Strategy のサンプルコードをネタにして、Strategy、ConcreteStrategyAdd、ConcreteStrategyMultiply、Context を連動させてみる。

Strategy の作成〜インストール

まずは、Strategy プラグインプロジェクトの作成

[New]->[Plugin-Project]
Project Name には "ex1.osgi.strategy.strategy"を指定、Activetor 無し、tempate 不使用で[Finish]
MANIFEST.MF の [Runtime]タブを開いて、[Exported Packages]に"ex1.osgi.strategy.strategy" を追加する。

以下の Wikipedia から持ってきた、以下のコードを追加する

package ex1.osgi.strategy.strategy;
public interface Strategy {
   int execute(int a, int b);
}

できたら以下のように Export しておく。

プロジェクトのコンテキストメニューから、[Export]->[Deployable plug-ins and fragments] を選択
[Destination] / [Directory]に、osgi-test フォルダを指定する
[Options] で、"Package plug-ins as individual JAR archives"のみチェックされている事を確認して[Finish]

エクスポートしたら、OSGi に install しておく

osgi> install file:///tmp/osgi-test/plugins/ex1.osgi.strategy.strategy_1.0.0.201111202011.jar
Bundle id is 4
osgi> refresh
osgi> ss
Framework is launched.
id State       Bundle
0 ACTIVE      org.eclipse.osgi_3.7.1.R37x_v20110808-1106
1 ACTIVE      org.eclipse.osgi.services_3.3.0.v20110513
2 ACTIVE      org.eclipse.equinox.util_1.0.300.v20110502
3 ACTIVE      org.eclipse.equinox.ds_1.3.1.R37x_v20110701
4 RESOLVED    ex1.osgi.strategy.strategy_1.0.0.201111202011

ss や refresh といったコマンドの意味は、OSGi コンソールから help と打てば、説明が出てくる。

ConcreteStrategyAdd の作成〜インストール

[New]->[Plugin-Project]
Project Name には "ex1.osgi.strategy.add"を指定、Activetor 無し、tempate 不使用で[Finish]
MANIFEST.MF の [Dependencies]タブを開いて、[Required Plugins]に"ex1.osgi.strategy.strategy" を追加する。

以下のようにコード追加する。

package ex1.osgi.strategy.add;
import ex1.osgi.strategy.strategy.Strategy;

public class ConcreteStrategyAdd implements Strategy {
    public int execute(int a, int b) {
        System.out.println("Called ConcreteStrategyAdd's execute()");
        return a + b;  // Do an addition with a and b
    }
}

プロジェクト直下に OSGI-INF フォルダを追加する
OSGI-INF フォルダのコンテキストメニューから、[New]->[Component Definition]を選択
"Component Definition Information" / Class に ex1.osgi.strategy.add.ConcreteStrategyAdd を指定して[Finish]
component.xml の Service タブで、[Provided Services]に ex1.osgi.strategy.strategy.Strategy を追加する

これも Export して、OSGi にインストールしておく。

Context の作成〜インストール

次は ConcreteStrategyMultiply をやる前に、Context に行ってみる

[New]->[Plugin-Project]
Project Name には "ex1.osgi.strategy.context"を指定、Activetor 無し、tempate 不使用で[Finish]
MANIFEST.MF の [Dependencies]タブを開いて、[Imported Packages]に"ex1.osgi.strategy.strategy" を追加する。

以下のコードを追加する。Wikipedia のサンプルコードでは、Context#executeStrategy() を実行するのは StrategyExample#main() だけど、面倒だから strategy が関連付けられたときに Context 自身が executeStrategy() のテストコードを実行するようにした。

package ex1.osgi.strategy.context;
import ex1.osgi.strategy.strategy.Strategy;

public class Context {
   private Strategy strategy;
 
   public synchronized void setStrategy(final Strategy strategy) {
      this.strategy = strategy;
      testExecuteStrategy();
   }
   public synchronized void unsetStrategy(final Strategy strategy) {
      if (strategy == this.strategy) this.strategy = null;
   }
   public int executeStrategy(int a, int b) {
      return strategy.execute(a, b);
   }
   public void testExecuteStrategy() {
      final long l = System.currentTimeMillis();
      final int a = (int) (l % 10);
      final int b = (int) (l / 10 % 10);
      final int result = executeStrategy(a, b);
      System.out.printf("execute(%d, %d) = %d", a, b, result);
   }
}

プロジェクト直下に OSGI-INF フォルダを追加する
OSGI-INF フォルダのコンテキストメニューから、[New]->[Component Definition]を選択
"Component Definition Information"/Class にex1.osgi.strategy.context.Context を指定して[Finish]
component.xml の [Service]タブで、[Referenced Services] に Strategy を追加する
追加した Strategy を選択して[Edit]、"Bind"にsetStrategy、"Unbind"にunsetStrategy を指定する

できたら、これもエクスポートして、OSGiにインストールしておく。

動作確認

とりあえず、ここまでで動かしてみる。

osgi> start 4
osgi> start 5
osgi> start 6
Called ConcreteStrategyAdd's execute()
execute(3, 1) = 4
osgi>

期待通りに動作する。（実は、start 4 は無くても良いし、start 5 と start 6 の順番は逆でも良い。）

ConcreteStrategyMultiply の追加と動作確認

最後に、ConcreteStrategyMultiply を付け加えて、ConcreteStrategyMultiply と差し替えてみる。

[New]->[Plugin-Project]
Project Name には "ex1.osgi.strategy.multiply"を指定、Activetor 無し、tempate 不使用で[Finish]
MANIFEST.MF の [Dependencies]タブを開いて、[Required Plugins]に"ex1.osgi.strategy.strategy" を追加する。

下のようにコード追加

package ex1.osgi.strategy.multiply;
import ex1.osgi.strategy.strategy.Strategy;

public class ConcreteStrategyMultiply implements Strategy {
    public int execute(int a, int b) {
        System.out.println("Called ConcreteStrategyMultiply's execute()");
        return a * b;   // Do a multiplication with a and b
    }
}

プロジェクト直下に OSGI-INF フォルダを追加する
OSGI-INF フォルダのコンテキストメニューから、[New]->[Component Definition]を選択
"Component Definition Information"/Class に net.yasuabe.osgi.ex1.strategy.multiply.ConcreteStrategyMultiplyを指定して[Finish]
component.xml の Service タブで、[Provided Services]に ex1.osgi.strategy.strategy.Strategy を追加する

これもエクスポートして、OSGiにインストールしておく。

エクスポートしたら、Context から実行される Strategy を、Add から Multiply に変えてみる。

osgi> ss
Framework is launched.

id State       Bundle
0 ACTIVE      org.eclipse.osgi_3.7.1.R37x_v20110808-1106
1 ACTIVE      org.eclipse.osgi.services_3.3.0.v20110513
2 ACTIVE      org.eclipse.equinox.util_1.0.300.v20110502
3 ACTIVE      org.eclipse.equinox.ds_1.3.1.R37x_v20110701
4 ACTIVE      ex1.osgi.strategy.strategy_1.0.0.201111202011
5 ACTIVE      ex1.osgi.strategy.add_1.0.0.201111202028
6 ACTIVE      ex1.osgi.strategy.context_1.0.0.201111202042
7 RESOLVED    ex1.osgi.strategy.multiply_1.0.0.201111202123

osgi> stop 5
osgi> start 7
Called ConcreteStrategyMultiply's execute()
execute(3, 1) = 3
osgi> ss
Framework is launched.
id State       Bundle
0 ACTIVE      org.eclipse.osgi_3.7.1.R37x_v20110808-1106
1 ACTIVE      org.eclipse.osgi.services_3.3.0.v20110513
2 ACTIVE      org.eclipse.equinox.util_1.0.300.v20110502
3 ACTIVE      org.eclipse.equinox.ds_1.3.1.R37x_v20110701
4 ACTIVE      ex1.osgi.strategy.strategy_1.0.0.201111202011
5 RESOLVED    ex1.osgi.strategy.add_1.0.0.201111202028
6 ACTIVE      ex1.osgi.strategy.context_1.0.0.201111202042
7 ACTIVE      ex1.osgi.strategy.multiply_1.0.0.201111202123
osgi> stop 7
osgi> start 5
Called ConcreteStrategyAdd's execute()
execute(4, 3) = 7
osgi>

Context を起動したまま、Strategy を差し替えられるのが確認できる。

雑感

今まで、何回か、いわゆるパッケージ開発案件に関わってきたけど、納品先個別の要件の扱い方について、何パターンかの手法がある。

一番泥臭いのだと、トランクのソースコードに個別要件対応のコードを入れてしまって、条件文で切り分けるというベタベタのローテク手法がある。「バカじゃね？」って思う人も多いかもしれないけど、実際の現場では結構多い。

それよりは、少しはマシな手法だと、納品先別にブランチを切って個別要件はそこに入れていくという事になる。まあ、これも知的な方法とは言いにくいけど、割と普通に行われている。

もっと良い方法としては、パッケージ共通部分と個別にカスタマイズ可能な部分について最初に見通しを立てた上で、カスタマイズ可能な部分がプラガブルになるようにアーキテクチャを設計する手法がある。

この手法をとると、機能の差し替えや追加、また管理面においてもリスクが少なくて、柔軟なソフトウェアになるんだけど、この場合にもさらに、プラグインの方式を自分で作るか、既存の仕様や製品を使うかで道が分かれる。

必ずしも自作にこだわる必要がないとしたら、OSGi がかなりの有力候補なのではないかと思う。（個人的には、はっきり言って、かなり高い割合で自作の道を取るのは不正解だと思うけど。）

Eclipse + Groovy + NekoHTML

2011-11-19T18:33:00.001+09:00

Redmine や Trac の wiki などを使ってプロジェクト内で情報共有している HTMLベースのコンテンツを、プログラムで取り扱うやり方を考えていて、Groovy でも使ってみようかと思い立つ。

で、やっぱり Eclipse で使いたいのでプラグインを入れる。Indigo なら update site はここで、Required とマークされている Groovy Eclipse ってのがあるから、これを選択してインストール。

インストールできたら、お試しプロジェクトを作る。パッケージエクスプローラ上の右クリから New -> Other と進むと、Groovy Project がリストに出てくるから、選択して適当に操作すると、Groovy Project が生成される。

適当に Hello World を書いて、main() メソッド上の右クリから[Run As]を選択すると、サブメニュー、[1 Groovy Console], [2 Groovy Script], [3 Java Application]が表示される。どれを選んでも、同じコードが同じように実行される。

これで、Eclipse で Groovy が使える書けるようになった。

Groovy 自体、たいして使ったことがないので、練習がてら「wikipedia の適当なページから「他の言語」にリストアップされている言語を、標準出力に書き出す」という簡単なお題をやってみる事にする。

Groovy で HTTP GET や HTML/XML を扱う方法をググりながら、以下のようなコードを書いてみた。

class Ex2 {
   static void main(args){
      new XmlSlurper(
            new org.cyberneko.html.parsers.SAXParser())
         .parse("http://ja.wikipedia.org/wiki/秋刀魚")
         .depthFirst()
         .grep{it.name() == 'DIV' && it.@id == 'p-lang'}[0]
         .DIV.UL.LI.each { println it.text() }
   }
}

Eclipse から実行すると、秋刀魚を解説している10個の言語の名前が書き出される。あまり便利ではなかったが、デバッガも一応使える。

XmlSlurper のコンストラクタに渡しているものは、NekoHtml の SAXParser というやつで、HTML にタグを補完して well-formed な XML として扱えるようにしてくれる。

使えるようにするには、ここから zip か tgz をダウンロードして、中の nekohtml.jar と xercesImpl.jar （または xercesMinimal.jar ）を、~/.groovy/lib 下に置けばいい。

論理パズルで Prolog のウォーミングアップ

2011-11-13T16:47:00.001+09:00

テストケース（開発者が作る、いわゆる DeveloperTest のテストケースじゃなくて、開発はやらないテスト部隊が使うテストケース）を作るための小道具として Prolog を使うと便利かもと思って、自宅の環境に SWI-Prolog を用意してみた。

Fedora の「ソフトウェアの追加／削除」でリストアップされてたので、選択して適用するだけでインストールできた。

本当は、与えられた条件にしたがって、縦に要因、横にテストケースを並べた直交表もどきの表を生成するような仕組みを作りたいんだけど、その前にウォーミングアップしてみる。

手元にある論理パズル集の中から簡単なものを選んで、Prolog で解いてみる事にする。

お題は以下のようなもの。

とあるミスコンで、好美、恵美、明美、麻美、宏美が予選通過した
なかよし4人組が以下のように優勝者を予想した
- まゆみ：好美と恵美ではないだろう
- 大貴：恵美か明美だろう
- 崇臣：好美か麻美だろう
- やす美：好美と麻美ではないだろう
予想が的中した人数は２名だった。

優勝したのはだれか？

あまり Prolog に詳しいわけではないけど、素朴に書くと以下のようになるのではないだろうか。


% 出場者
contestant(akemi). 
contestant(asami). 
contestant(hiromi). 
contestant(emi). 
contestant(yoshimi).

% 誰が誰の優勝を予想しているか
expect(mayumi, akemi). expect(mayumi, asami). expect(mayumi, hiromi).
expect(daiki, akemi). expect(daiki, emi).
expect(takaomi, yoshimi). expect(takaomi, asami).
expect(yasumi, emi). expect(yasumi, akemi). expect(yasumi, asami).

% 結局、優勝者は２名の予想者に予想された出場者だった
winner(Contestant):- expectors(Contestant, 2).

% 優勝者と予想者数の関係
expectors(Contestant, Count):-
  contestant(Contestant),  
  countExpectators(Contestant, [mayumi, daiki, takaomi, yasumi], Count).

% 優勝者を予想した人を数える
countExpectators(_, [], 0 ).
countExpectators(Contestant, [Expector|OtherExpectors], Count) :-
  expect(Expector, Contestant), 
  countExpectators(Contestant, OtherExpectors, Count2),
  Count is Count2 + 1.
countExpectators(Contestant, [Expector|OtherExpectors], Count) :-
  not(expect(Expector, Contestant)),
  countExpectators(Contestant, OtherExpectors, Count).

これを SWI-Prolog に読ませて、以下のようにすると答えが出る。


?- winner(Winner).
Winner = emi .

ちなみに明美の優勝を予想した人数は、上で定義した述語 expectors 使って、以下のように求められる。


?- expectors(akemi, Count).
Count = 3 .

逆に、同じ expectors を使って、3名が優勝を予想した出場者を求めることもできる。これがPrologの面白いところでもある。


?- expectors(W, 3).
W = akemi ;
W = asami ;
false.

====

ソフトウェアのテストケースを作ろうとすると、あるテスト対象の振る舞いに影響を与える条件群について、すべての条件を掛け合わせると現実的でないテストケース数になったりする

なので、少ないテストケース数でなるべく各条件を網羅できるように工夫する事になるんだけど、その辺りの作業がちょっとしたパズルみたいになってくる事がある。

で、せっかくプログラミングを生業としているのだから、プログラムでなんとかしようかって発想になるんだけど、手続き型言語を使うと、やりたい事とコード上の表現がいまいち直截性に欠けていたりする。

あまり流行ってはいなけど、こういう時は Prolog が割と使えそうな気がしないでもない。

Fedora のアップグレードで平常心の訓練

2011-11-10T22:55:00.001+09:00

Fedora 16 が昨日か一昨日リリースされたので、Fedora15 からアップグレードしてみた。

まず、Fedora のサイトに書いてあるアップグレード手順どおりにやってみる。


rpm --import https://fedoraproject.org/static/A82BA4B7.txt
yum update yum
yum clean all
yum --releasever=16 --disableplugin=presto distro-sync

うん。やっぱり、うまくいかない。
--skip-broken が使えないからとか何とかメッセージが出て、途中で止まる。

まあ、初めはいつもこんなもんだ。俺は、ぜんぜん動じない。で、ちょっと調べて以下のようにして再挑戦。


yum --releasever=16 --disableplugin=presto distro-sync --skip-broken

今度は、「Transaction Check Error で、gnome-icon-theme-symbolic と gnome-power-manager が keyboard-brightness-symbolic.svg のアレやら何やら（意訳）」とか言ってくる。こやつめ、ハハハ！

よく分からないけど、試しに以下のようにしてみた（gnome-icon-theme-symbolicとか言うやつは、この際、忘れる）。


yum --releasever=16 --disableplugin=presto distro-sync --skip-broken --exclude=gnome-icon-theme-symbolic

うん、なんだか上手く行ってるっぽい。エラーも無く yum が終了。再起動してログインしたら、Fedora 16 のデスクトップ画像が見えた。端末から cat /etc/fedora-release とやってみたら、 Fedora release 16 (Verne)と出た。

うん、これは出来ておるね。出来たっぽいね。

まあ、いちいち書いてはいないけど本当はもっと試行錯誤して、正直つらかった。よく覚えてないけど、気がつくと頬が濡れてたから、俺ちょっと泣いてたのかもしれん。まあでも、どうやら一応、Fedora 16 にアップグレードできた。

で、まずは「ソフトウェアの追加／削除」で Eclipse を Indigo に変える。実はこれが、そもそもの目的だった。うまくインストールから起動まで確認できて一段落。ほっとする。

更に、他のいろんなもの全部をアップグレードしたくて、「ソフトウェアの更新」を起動すると、700個近く検出された。かまわず[Install Updates]押下。

・・・って、ま〜たかよ。また、gnome-icon-theme-symbolic と gnome-power-manager が干渉してるとか言ってきた。

今度は、 yum remove gnome-power-manager で、電力管理の何かを削除してみる。多分使ってないし、要るなら後でなんとかすればいいし。
で、再度、[Install Updates]。

すると今度は、「libnih が GLIBC とナントカカントカ」だの言ってきやがって、ギギギ、てめえコノヤ……まあ、短気は損気とも言うからな。

rpm -q --whatrequires libnih で見てみると、別にどこからも依存されてる形跡がないので、yum remove してしまう。

再び、[Install Updates]を再試行すると、今度はどんどん進む。これは今渡こそ、上手く行ってるっぽい。

小一時間で 700 近い更新が適用。清々しい気分。再起動しろというので、にこやかにOKボタン押下。

で、しばらく待ってると、いつものようにユーザ選択のポップアップが表示された。ユーザ名を選んでからパスワードを入力。

…そしたら、困った顔のマシンの画像で「ああ、何かがおかしいです、ログインし直してください」とか、メッセージを出してくる。
はあ？何だ、その言い草？しかし、何度やってもログインできず、同じ戯言を繰り返してくる・・・

何度やっても、何度やっても、何度やっても、何度やっても、何度やっても、何度やっても、何度やっても、

おぎゃーーーーーーー！！！

…ひとしきり地団太を踏んで暴れると、嗚咽も収まり、だんだん冷静さが戻ってきた。いつまでもクヨクヨしない。泣いたってログインできないよって、ばあちゃん言ってたし、俺は大人だしな。

で、なんとなく SELinux のせいだろうと思ったので、無効になるようにしたいのだけど、ログインできない状態でどうすれば良いか分からない。幸い予備のマシンがあったからググったら、シングルユーザモードというのがあって、Windows の safe mode みたいな事ができるらしい。

なんか、起動中に良い感じのタイミングで「E」キーを押すと、カーネルの選択画面になるので、そこで single を追加指定すれば root でログインできる（詳しいやり方は、シングルユーザモードで検索するとなんぼでも出てくる）。

で、CUI ログインしたら、 vim /etc/sysconfig/selinuxで SELinux の設定ファイルを開いて、「SELINUX=enforcing」から「SELINUX=disabled」に書き換える。

で、もっかい再起動。
今度こそ、ちゃんとログインできた。
ほっとしたが、えらく手間がかかったなあ・・・。

まあ、こういったアップグレード関連のアレコレとかって、Linux そのものが好きでベータ版から使ってる人には、大半が常識的で造作ない事なんだろうけど、自分はすごい苦手。こういった作業はたまにしかしないし、してもさっぱり記憶が定着しないし、本当、弱点だわ。

# Fedora 自体は気に入っているが

FEST+JavaScript で半自動 Swing テスト

2011-11-05T18:16:00.001+09:00

あ〜、暇だから、Swing フォームを JavaScript で動かすやり方でも考えてみっかな。

====

例えば、打鍵＋目視に基づいた手動画面テストが既に実施されていたり、チェックリストとかテスト仕様書が出来ている場合に、作業負荷を減らすために、後から部分的に自動化を導入して、半自動テストにしたい場合がある。

ところでfest という、Swing アプリを Javaコードから機能テストするための API セットがあり、JavaコードからUIイベントを発生させて画面上のコンポーネントを操作するAPIが一揃い入っている（AWT の Robot をベースにしたものらしい）。

また、JavaScript コードを Javaプログラムから動かす仕組みは、Java 1.6 から備わっていて、特に何か特別なライブラリを必要とせずに、簡単に使えるようになっている。

これらを利用すれば、テスト対象フォームの外で JavaScript を実行して、フォーム上の要素を制御することができるはず。

■ 実験台

実験台として、以下のフォームを考えてみる。

こんな仕様

テキストボックスの名前は "field1"
チェックボックスの名前は "check1"
ボタンの名前は "button1" で、押下すると "check1"がチェックされている場合は field1 を大文字化した文字列、チェックされていない場合は field1 そのままの文字列を、標準出力に書き出す。

実験台だから単純なフォームにしたけど、実際の現場での開発対象フォームは入力項目が何十個もあって、実行ボタンを押すまでに必要な打鍵動作が多く、１回なら問題ないけど、同じようなテストケースや回帰テストをしたりすると心身ともに疲れたりする。やはり、そういうのは、何とかして省力化したい。

■ 方針

まず、テスト対象フォームを開くと同時に、以下のような別ウィンドウを開く。

で、ここで JavaScript を入力して Excecute ボタンを押下すると、手動の打鍵と同等の JavaScript が実行されるようにしたい。

■ 実装

JavaScript 入力用のウィンドウ ScriptInputWindow は、最初にテスト対象ウィンドウの FrameFixture を受け取る。

public static void main(String[] args) {
   JFrame frame = showWindow(new TestTargetWindow("Test Target"), 0);
   FrameFixture window = new FrameFixture(frame);
   showWindow(new ScriptInputWindow(window), 3000);
}
public static JFrame showWindow(JFrame frame, int xpos) {
   frame.setSize(250, 150);
   frame.setLocation(xpos, 0);
   frame.setVisible(true);
 
   return frame;
}

見ての通りテスト対象ウィンドウは TestTargetWindow だけど、ScriptInputWindow と TestTargetWindow は同じテストハーネスのプロセスから実行する事になる。もしかすると、開発対象システムに固有な何か特別な親ウィンドウとか、ランチャーとかを介さないと、テスト対象ウィンドウ単体ではフォームを開けないと心配する人もいるかもしれないが、大抵の場合は instrumentation ベースのモックツールを使えば何とかなるし、そんなに難しくもない。

ScriptInputWindow はまず最初に、テスト対象フォーム上のコントロールを、JavaScript 用の ScriptEngine に登録する。ScriptEngine も ScriptInputWindow が保持しておく。

public ScriptInputWindow(FrameFixture window) {
   super("JavaScript input window");

   initializeControlls();  

   this.jsEngine = new ScriptEngineManager().getEngineByName("JavaScript");
   registerComponents(window, window.component(), 0);
}

@SuppressWarnings("restriction")
private void registerComponents(
      FrameFixture window, Container container, int indent) {

   for (Component component: container.getComponents()) {
      String name = component.getName();
      if (null != name) {
         ComponentFixture comp = selectComponent(window, name);
         if (null != comp) this.jsEngine.put(name, comp);
      }
      if (component instanceof JComponent)
            listComponents(window, (Container)component, indent + 1);
   }
}

selectComponent() は ContainerFixture から name に一致する ComponentFixture を選んでくるメソッドだけど、面倒なので省略。

ボタンを押すと書き込んだJavaScriptコードを実行する部分は以下のようなもの。

executeButton.addActionListener(new ActionListener() {
   public void actionPerformed(ActionEvent arg0) {
      ExecutorService e = Executors.newSingleThreadExecutor();
      e.execute(new Runnable() {
         public void run() {
            try {
               String text = ScriptInputWindow.this.textArea.getText();
               ScriptInputWindow.this.jsEngine.eval(text);
            } catch (Exception e) {
               e.printStackTrace();
             }
          }
      });
   }
});

■ 試行

以下のコードを書き込んで実行すると、テキストボックスの内容が "123abcABC" に変わり、チェックボックスがチェックされ、ボタンが押され、標準出力に”123ABCABC”が出力される。

field1.setText("123abcABC");
check1.check();
button1.click();

■ 応用

フォーム上のコントロールの操作以前に、まずコントロールの名前を知ってなきゃならないんだけど、必要な時に階層状に表示してテスターに見せる機能もあった方が良いかもしれない。これは registerComponents でやってる事をそのままどっかに書き出すだけだから簡単。
自動打鍵の結果として得られた画面上の更新項目を、比較しやすい形式でどこか（TextArea とかクリップボードでもファイルでも）に書き出す仕組みもあると便利かもしれない。グリッドとかツリーとかあると、ちょっと手間がかかるかも。
自動打鍵後に、用意しておいた期待値と自動的に比較する仕組みがあると、かなり全自動に近づいてくる。
手動打鍵の記録なんかまでやるとなると、それは難しい。商用製品でも買った方がマシかもしれない（下記の参考記事をみるとFESTでも対応作業中みたいな書きっぷりだけど、どうなったのか不明）。

■ 参考サイト

仲間外れはどれか？

2011-11-03T16:17:00.002+09:00

下の図は、仲間外れを見つける問題例だけど、小学校受験のためのものだから幼稚園児向けということになる。

仲間外れといっても、一応、少なくとも野菜ではあるのだから、問題の趣旨を一旦置いておけば、あながち間違った括りとは言えなくもない。

でも、じゃあ、「カボチャ」の代わりに、「八百屋さん」だったり「プログラマ（好きな食べ物：肉、嫌いな食べ物：野菜）」とかだったとしても、同じカテゴリって言い張る奴っているのだろうか。まあ、こんなアホな質問はした事はないけど、身の回りには多分いないと思う。つうか、いたら嫌だ。

ところが、それに相当するようなソースコードなら、プロの開発現場でもしょっちゅう見かける。今日はそんな事を書いてみる。

====

こんなコードがあったとする。

このコードには、ダメなところがいくつかあるけど、特にまずい問題点を、ちゃんと技術者っぽい言葉で説明できるだろうか。

/** 色を指定できるカーペット。 */
public class Carpet {
   private final int color;
   public Carpet(int color) {
      this.color = color;
   } 
   //…
}

/** システムで使える色の集合  */
public class Colors {
   private static final Map COLORS = new HashMap();
   static {
      COLORS.put("赤", 0xFF0000);
      COLORS.put("緑", 0x00FF00);
      COLORS.put("青", 0x0000FF);
   };
   private Colors() {} 
   public static int colorNameToRgbValue(String colorName) {
      return COLORS.get(colorName); 
   }
   public static List createCarpets(String[] colorNames) {
      List result = new ArrayList();
      for (String colorName: colorNames) {
         result.add(new Carpet(COLORS.get(colorName)));
      }
      return result;
   }
}

Colors は本当は enum を使うべきだけど、サンプルの都合上普通のクラスにした。また、そもそもユーティリティクラスがまずいってのは、取り敢えずこの際、放っておく事にする。

Colors という色のセットを表すクラスに、色に関係ない事はないけど明らかに異質でレベルの違う Carpet という概念を扱うメソッド、createCarpets() が定義されている。

こういうとき、ちょっと堅苦しい言い方だけど、「凝集性が低い」という（もちろん低いほどダメ）。

もっと言うと、暗合的凝集度と論理的凝集度の間くらいになると思われ、レベルとしてはサイテーに近い。（技術者っぽくない言葉でいうと、暗合的凝集度は「なんで同じクラスに入れてんのかイミフ」なやつで、論理的凝集度は「言い訳できない事ないけど必然性に乏しい」やつ。）

この凝集性と表裏一体の概念として、結合度というのもある。

上のコードは結合度が高い（こっちは高いほどダメ）のだけど、実質的にグローバル関数といえるメソッド群がクラス変数という実質グローバルな情報を介して結びついている点で「共通結合」であり、６段階あるうちの悪い方から2番目で、やはりかなり酷いコードと言える。

さらに、凝集性や結合度はオブジェクト指向隆盛以前の、構造化手法全盛期からある設計評価基準だけど、オブジェクト指向に関連の強い言葉「責務」を用いて表現すれば、「createCarpets によって、Colors が一つ以上の異なる責務を負っている事が問題」と言う事もできる（責務：言うまでもなく CRC の R(Responsibility)）。

つうわけで、上のコードは単純過ぎる例ではあるものの、技術的には「低凝集・高結合度で、複数の責務を負った下手糞なコード」だと言える。まあ、そういうコードや設計を放置しておくと、その先どうなるかについて、技術者じゃない人になら説明する必要があるけど、技術者同士なら説明不要だと思う（思いたい）。

ただし、実はクソヘタプログラマだけがこんなコードを書いているのではなくて、そこそこの技術者／チームでも、開発期間の中で生じるいろんな行きがかり上、たまたまこんな感じになってしまって、そのまま直す機会を逸してしまってる場合もある。

まあ、でも。そんな時のためのリファクタリング技術なわけで、ちゃんとテストコードを実行するという前提（当たり前だけど、無ければ必ず書き足す）さえ守れば、なんぼでも体質改善すれば良い。

だけど、そもそもダメだって事が認識できないとなると、いろんな意味でかなりやばい。説明するこっちも、クラスの責務から説明すればいいのか、結合度・凝集度から説明すればいいのか、それとも小学校受験の仲間外れ問題まで遡って説明しなければならないのかと考えてしまって、なんかもうキッツイわ…

Eclipse と JMockit でテストファースト

2011-11-01T01:19:00.002+09:00

以前のブログで、他の２つのクラスとのコラボレーションを含む簡単なクラスのテストをJMockitを使って書いたけど、その時は、敢えてレガシーコードに後付けテストを追加するような感じで書いてみた。

やろうとしている事は以下のようなものだった。

作ろうとしているのは Foo というクラスで、文字列を返すメソッド hoge() を持っている
Foo#hoge() が返す文字列は、Baz#hoge() から取得したものである
ただし、Baz のインスタンスは、Bar のインスタンスを経由しないと使えない

これを以下に、テストファーストで実装してみる。ただし今日は、Eclipse を極力活用するという趣向でやってみる。

====

まず①のクラス Foo とメソッド hoge()だけど、以下の様に、まず最初にテストクラスを書く。

public class FooTest {
   @Test public void hoge() {
      Assert.assertEquals("dummy", new Foo().hoge());
   }
}

まだクラス Foo が無いから当然コンパイルエラーの赤波が表示されるので、以下のように仮実装する。

 public class Foo {
   public String hoge() {
      return null;
   }
}

ただし、これをそのままタイプしてはいけない。Eclipse を使うという前提なのだから Ctrl+1を2回（クラスに一回、メソッドに一回）使うだけでタイプせずに済むので、これを活用する。
とりあえず、ここまでで JUnit を実行して、テストが失敗するのを見てから、hoge() の戻り値を"dummy"に変えて、テスト成功に変わるのを確認しておく

で次に、② の Baz#hoge() への委譲。これもテスト・コードから書く。

public class FooTest {
   @Test public void hoge() {
      new NonStrictExpectations() {
         Baz baz;
         {
            baz.hoge(); result = "dummy"; times = 1;
         }
      };
      Assert.assertEquals("dummy", new Foo().hoge());
   }
}

ここでももちろん、Baz も Baz#hoge() も未だ無いわけだから赤波が表示されるけど、さっきと同様に Ctrl+1 を 2回使って Baz の空実装を Eclipseに生成させる。ただし今度は Baz#hoge() の中身を以下の様に書き換える。

public class Baz {
   public String hoge() {
      //FIXME [your user name] Nov 1, 2011
      throw new AssertionError();
   }
}

自分の環境では、この FIXMEコメントから AssertionError送出の2行は、Java エディターのテンプレートに登録してあるので、fixme とタイプして Ctrl+1を押せば、その日の日付とログインしているユーザ名で2行挿入される。

で、赤波が消えたら、また JUnit を実行して Baz#hoge() が呼ばれていないというアサーション例外が上がるのを確認し、Foo#hoge() を以下の様に書き換える。

public String hoge() {
   return new Baz().hoge();
}

書いたらまた JUnitを実行して、今度は緑になるのを確認。

最後に、③ の Bar インスタンスを経由して Baz インスタンスを得るところ。これもやっぱりテストコードから。

public class FooTest {
   @Test public void hoge() {
      new NonStrictExpectations() {
         Baz baz;
         Bar bar;
         {
            bar.baz(); result = baz; times = 1;
            baz.hoge(); result = "dummy"; times = 1;
         }
      };
      Assert.assertEquals("dummy", new Foo().hoge());
   }
}

またここでも Baz#hoge() と同様に、Ctrl+1 をクラスとメソッドにそれぞれ適用して空実装を生成し、FIXME付きのアサーション例外送出コードを書いておく。

赤波が消えたらJUnit実行。Bar#baz() が呼ばれてないってアサーション例外が上がったら、おもむろに Fooを以下のように書き換える。

public class Foo {
   private final Bar bar = new Bar();
   public String hoge() {
      return this.bar .baz().hoge();
   }
}

但し、これも Ctrl+1 （→ Create field 〜）を活用し、無駄なタイピングをせずに編集する。できたら、Junit を実行し緑になることを確認。

というわけで、完了。

====

ちなみに、この間からかじり始めた Coq のチュートリアルの第2回で、結論から１個ずつ論理を遡って証明を完成させていく手順が紹介されていたけど、テストファーストと似ているところがあると思った。

暇だから MongoDB でも入れてみるか

2011-10-29T20:59:00.000+09:00

せっかくの休日、Eclipse の Xtext を試してみたかったのに、Indigo はコアダンプ吐いて即死するし、Helios はプロジェクトの作成に失敗するわで、15分くらいで心が折れた。

で、代わりの暇つぶしとして、最近 NoSQL について下調べしていて見かけた MongoDB とか言う奴でもいじってみようかなと思いつく。この辺りを参考（飽くまでも参考）にして、Fedora15 の 32bit 環境でやってみた。

実は、Fedora で管理しているMongoDB が「ソフトウェアの追加と削除」で最初からリストアップされてるんだけど、これをインストールしても、なんかちゃんと起動しなかった。

====

まずはインストールだけど、配布元の 10gen を Fedora （というか yum）に認識させるために、ファイル /etc/yum.repos.d/10gen.repo を作って以下の記述を追加する。

[10gen]
name=10gen Repository
baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/i686
gpgcheck=0

そうすると、「ソフトウェアの追加と削除」にリストアップされるから、以下を選択して[適用]

mongo-10gen-server-2.0.1-mongodb_1
mongo-10gen-2.0.1-mongodb_1

インストールされたら、起動してみたい所だけど、その前に、なんかデータを保存するフォルダを作っとく必要があるらしい。

$ sudo mkdir -p /data/db/
$ sudo chown `id -u` /data/db

準備ができたので、Fedora の[サービス]ツールで mongod を開始する。

端末で、mongo を起動して動作確認。

$ mongo
> one = {name: "one", value: 1}
> two = {name: "two", value: 2}
> three = {name: "three", value: 3}
> db.things.save(one)
> db.things.save(two)
> db.things.save(three)
> db.things.find()
{ "_id" : ObjectId("4eabd63586daea21618266ca"), "name" : "one", "value" : 1 }
{ "_id" : ObjectId("4eabd63786daea21618266cb"), "name" : "two", "value" : 2 }
{ "_id" : ObjectId("4eabd63a86daea21618266cc"), "name" : "three", "value" : 3 }
> db.things.find({name:"one"}, {_id:0})
{ "name" : "one", "value" : 1 }
> db.things.find({value:2}, {name:1})
{ "_id" : ObjectId("4eabd63786daea21618266cb"), "name" : "two" }
> db.things.find({value:3}, {name:1,_id:0})
{ "name" : "three" }

ちゃんと動いてるらしい。

次は、java コードから動かしてみたい（チュートリアル）。

JavaScript + XSLT の小技

2011-10-27T00:19:00.000+09:00

ここ数年、一部界隈でアンチXMLみたいな動きがあったりするが、現実には XML はいろんな場面で使われている。中には数万行のものがあったりするけど、さすがにそのサイズになると、直接、内容を読もうとすると、結構不便だったりする。

というわけで、最近重宝しているブラウザと Javascript と XSLT を使った小技を書いてみる。

こんな感じの XML があるとする。

<?xml version="1.0"?>
<numerals>
  <numeral><arabic>1</arabic><jp>壱</jp><en>one</en></numeral>
  <numeral><arabic>2</arabic><jp>弐</jp><en>two</en></numeral>
  <numeral><arabic>3</arabic><jp>参</jp><en>thee</en></numeral>
</numerals>

これを XSLT で HTML に変換して、ブラウザ上で左下のようなリストを表示し、それぞれのリスト要素に設定されているハイパーリンクをクリックすると、右下の様に詳細が表示されるといった事をしたい。

⇨

数字	2
日本語	弐
英語	two

以下、その方法。

====

リストを表示する XSLT は以下のようなものになる。ポイントは<a>要素を生成しているところで、javascript 関数 showDetail()に arabic 要素を渡すようなリンクが作られる。

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ul>
      <xsl:for-each select="numerals/numeral">
        <li>
          <xsl:element name="a">
            <xsl:attribute name="href">
              javascript:showDetail(<xsl:value-of select="arabic"/>)
            </xsl:attribute>
            <xsl:value-of select="jp"/>
         </xsl:element>
        </li>
      </xsl:for-each>
    </ul>
  </xsl:template>
</xsl:stylesheet>

で、次に詳細を表示するためのXSLTは以下で、ポイントはパラメータ arabic をグローバルで宣言しているところ。

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:param name="arabic"/>
  <xsl:template match="/numerals/numeral">
    <xsl:for-each select=".[arabic=$arabic]">
      <table>
       <tr>
         <td>数字</td>
         <td><xsl:value-of select="arabic"/></td>
       </tr>
       <tr>
         <td>日本語</td>
         <td><xsl:value-of select="jp"/></td>
       </tr>
       <tr>
         <td>英語</td>
         <td><xsl:value-of select="en"/></td>
       </tr>
      </table>
    </xsl:for-each>
  </xsl:template>
</xsl:stylesheet>

いよいよ、Javascript とそれを含むHTMLだけど、ソースは以下のようなものになる。

<html>
 <head>
  <script type="text/javascript" src="sarissa.js"></script>
  <script type="text/javascript">
   function loadXmlFile(fileName) {
     var result = Sarissa.getDomDocument();
     result.async = false;
     result.load(fileName);
     return result;
   }
   function replaceResultArea(xmlDom) {
     var serializer = new XMLSerializer(); 
     var output = serializer.serializeToString(xmlDom.documentElement);
 
     document.getElementById("resultArea").innerHTML = output;
   }
   function showList() {
     var xml = loadXmlFile("test.xml");
     var xslt = loadXmlFile("ul.xsl");

     var processor = new XSLTProcessor();
     processor.importStylesheet(xslt);
     var xmlDom = processor.transformToDocument(xml);

     replaceResultArea(xmlDom);
   }
   function showDetail(arabic) {
     var xml = loadXmlFile("test.xml");
     var xslt = loadXmlFile("detail.xsl");

     var processor = new XSLTProcessor();
     processor.importStylesheet(xslt);
     processor.setParameter("", "arabic", arabic);
     var xmlDom = processor.transformToDocument(xml);

     replaceResultArea(xmlDom);
   }
  </script>
 </head>
 <body onload="showList()"/>
   <div id="resultArea"/>   
 </body>
</html>

冒頭で参照している sarrisa.js はXMLを扱うための JavaScript ライブラリで http://dev.abiss.gr/sarissa/ からダウンロードできる。ただし Chrome がどうもサポートされてないっぽい。本当にそうなら残念（まあ、それほど困らないけど）。

以上、「(1)パラメータを与えつつ、(2)動的に XSLT を適用して、(3)ブラウザ上で表示を切り替える」方法。サンプルなんで、簡単なものだけどなんぼでも応用がきく。（例えば、静的ソース解析ツールが吐いたXML形式のレポートを分析したり、XMIで出力したUMLのドキュメントを解析してメトリクスを試算したりとか。）

ちなみに、個人的には XML それ自体に対する忌避感みたいなのは、全くといって良いほど無い。他の大抵の技術要素と同じく、上手く使えば役に立つし、下手に使えば役に立たないという単純な問題。

簡単な後付けテストで基本を再確認

2011-10-24T22:57:00.000+09:00

こんなクラスがあるとする。

public class Foo {
   private final Bar bar = new Bar();
   public String hoge() {
      return this.bar.baz().hoge();
   }
}

見ての通り、Foo はメソッド hoge()の中で、関連オブジェクト bar から取得した baz に、hoge() 処理を移譲している（日本語にすると、なんのこっちゃだが…）。

Bar と Baz は以下のような感じで後回しにしてある。

public class Bar {
   public Baz baz() {  throw new AssertionError();  }
}
public class Baz {
   public String hoge() {  throw new AssertionError(); }
}

ここで、Foo#hoge() をテストするにはどうするか。つまり以下の/* ??? */ のところに何を入れたらテストできるか。

public class FooTest {
   @Test public void hoge() {
      /* ??? */
      Assert.assertEquals("hello", new Foo().hoge());
   }
}

とりあえず２個だけ例を書いてみると（ちょっとずつニュアンスの違うものを何通りも書けるが）、以下のようになる。

@Test public void hoge1() {
   new Expectations() {
      @Mocked("baz") Bar bar;
      @Mocked("hoge") Baz baz; {
         bar.baz(); result = baz;
         baz.hoge(); result = "hello";
      }
   };
   Assert.assertEquals("hello", new Foo().hoge());
}
@Test public void hoge2() {
   new NonStrictExpectations() {
      Bar bar;
      Baz baz; {
         bar.baz(); result = baz; times=1;
         baz.hoge(); result = "hello"; times=1;
      }
   };
   Assert.assertEquals("hello", new Foo().hoge());
}

JMockit を使い始めたばかりだと、結構、とまどうんじゃないかと思う。デバッガで追ってみると、例えば "result = baz" のところで、初期化していないはずの baz に何故かインスタンスが設定されているし、代入されたと思った result が null のままだったりして、普通の Java ソースの感覚で読んでいると訳が分からなかったりする。

とは言ってもまあ、すぐ慣れるし、そうなると逆に、JMockit 無しのテストを考える事が、時折難しく感じられてくる。

ただ、JMockit を使うと後付けテストもかなり簡単になるにはなるけど、やっぱりテストファーストが基本というのは押さえておいた方が良い。この例はもともと簡単だから、それほど大変なテストコードにはならないけど、もっと複雑なものになると、後付けとテストファーストではテストコーディングの生産性が大きく違ってくる。

====

テストファースト版は、こっちに書いた。

Fedora 15 + JavaDB

2011-10-23T01:53:00.002+09:00

自宅マシンで javaDB を使って試したいことがあったんだけど、OpenJDK には JavaDB が入っていないらしい。「ソフトウェアの追加と削除」にもリストアップされない。という訳でRPMからインストールしてみた。

まず、ここからダウンロード

で、Oracle サイトのここを見てインストール

$ chmod +x javadb-10_5_3_0-linux-rpm.bin 
$ ./javadb-10_5_3_0-linux-rpm.bin 
# su
# cd javadb-10.5.3.0/
# rpm -ivh sun-javadb-*.rpm

ij コマンドで起動して、試してみる

ij> connect 'jdbc:derby:testdb1;create=true'; 
ij> create table t1 (col1 int primary key, col2 varchar(10));
ij> insert into t1 (col1, col2) values (100, '俺'));
ij> select * from t1;
COL1       |COL2      
----------------------
100        |俺

まあ問題なさそう。
※実はエラーメッセージとか help とかが文字化けしてたけど、javaコードから使うのがメインだから放置。

Coq をインストールしてみた

2011-10-18T22:47:00.001+09:00

今日、現場の昼休みに、最近噂の Coq のチュートリアルを見つけたので、早速インストールしてみる。

Fedora 15 でアプリケーションの追加と削除を開くと、Coq 8.3がリストアップされてきたので、チェックを入れて適用。

さらに、端末を開いて coqide と打ち込んでみると、ひとしきり追加のインストールが実行されたあと、CoqIDE が開いた。とりあえず、チュートリアル一回目の練習問題を解いてみるが、初回なんで難しくない。

結構面白い。明日もやろっと。

リファクタリング再読 4章テストの構築

2011-10-17T23:40:00.000+09:00

このブログで、何度も引用してきたけど、10年以上前に読んだリファクタリングが、今読んでも面白い。

面白いと言っても、当たり前の事が普通に書いてあるだけなんだけど、忘れた頃に読み返すと、自分が現場でいつも言っている事と大部分一致していて、若い頃に受けた影響ってやっぱりずっと残るんだと実感する。（さすがに、このレベルの名著ですら、やはり10年も経つとある程度の陳腐化は避けられず、全てに同意はできるわけではないけど…）

今日は『4章テストの構築』から、何点か引用して考えてみたい。

====

テストを完全に自動化して、その結果もテストにチェックさせること。(P.90)

xUnit Patterns の言葉で言うと、Manual Interventionは止めようねって事で、まあ、JUnitの基本中の基本。とはいっても、@Test メソッドの中で普通のアサーションで書ける比較を、標準出力に書き出して目視確認してたおバカさんを、こないだ発見した。こんなレベルの人が「JUnit 使用歴○○年です！」なんつってプロジェクトに入り込んできちゃったりするから、この業界っておそろしい。

テストを頻繁に実行せよ。コンパイル時にはテストを局所化して、一日に最低一度は全てのテストを実行せよ。(P.94)

今は普通に CIサーバでコミット時にテスト走らせたり、incremental test とかも普及してるから、一日一度はさすがに10年前って感じがするが、なるべく頻繁に実行すべしってのが、この文の趣意。まあ、なんぼ言っても、他人のテストコードをコケさせておきながら、コンパイルが通ってるってだけでテストもせず、平気でコミットする間抜けが減るどころか永遠に増え続けてるから、気が滅入るが…。

バグレポートを受け取ったら、まずそのバグを明らかにするための単体テストを書け。(P.97)

これは今も昔も良いプラクティスで、余り反論する人を見たことがないけど、数年前までは、いざバグを再現させるテストコードを書こうにも、そもそもテスタビリティが低すぎて、異常に難易度が高い場面もあった。今は、instrumentation を活用したテストフレームワークが普及しているから、そうでもないけど。（テストツールのテスト能力が高まっただけで、ソースコードのテスタビリティは大して進歩していないのが悲しいが）

ここでお話しするのは「単体テスト」です。これはプログラマの生産性を向上するために行うものです。これで品質管理部門が満足するとしても、それは副作用に過ぎません(p.96)

リファクタリング〜xUnit の文脈の中で、「機能テスト」と対置されて語られる「単体テスト（UnitTest）」って、ウォーターフォール・モデルの単体テストを単に自動化しただけのものとはかなり違うんだけど、この勘違いは今でもかなり根強い。自分が、現場で説明する時には、「外部品質じゃなくて内部品質をあげるためのツールだから」とか言う事がある。分からない人はどう言い換えてもやはり分かってくれないけど、わかる人はなるほどそうかと納得してくれたりする。

不完全なテストでも、書いて実行する方が、実行できない完全なテストよりもましだ。

テストを書けば自分が楽になるって認識が成立しないとプログラマはテストを書きたがらないわけで、つまり下手なプログラマって、テストコードによって自分で自分の作業を楽にする事ができないプログラマなんだけど、その手の輩に無理やりテストを書かせようとするから無理なカバレッジ基準が制定されて、後付けでパスを通そうとするから、却って生産性が下がる。そんなのどうせ、まともなアサーションが書かれるわけないのにさ。

本当は、自覚して UnitTest を使えてるプログラマが、どこにどの程度テストコードを書くか自分で判断すればいい事なんだけど、最低辺も含めて、いろんな人が集まるプロジェクトでは、うーんやっぱ難しいのかな…

大事な事は、一番怪しいと思う部分をテストすることです。それが最も効率の良いテスト方法です。(p.97)

失敗の恐れのある境界条件を考えて、そこを集中的にテストせよ。(p.99)

失敗すると予想される時に、例外が上がることをテストし忘れないこと。(p.100)

境界条件や例外条件なんかをテストするにしても、テスト駆動／テストファーストでやるのが、結局は一番楽で確実なんだけど、現場のレベルによってはいくら言い聞かせても浸透しない。後付けでテスト書いたって、カバレッジだけに必死になって、どこが「怪しい」かなんて完全に眼中の外になってしまう事が分かりきってるんだけどね。

テストで全てのバグが見つからないからといって、テストを書くのを止めてはならない。ほとんどのバグはテストで補足される。

そもそも開発者が要件を誤解していたり、忘れていたりしたら、そういった認識エラーは本体コードと同様にテストコードにも織り込まれてしまうから、開発者テストだけで捕捉するのは論理的に不可能。そういった限界がある事を認識した上で、機能テストも絡めた全体的なテスト計画を立てるのが常道。

====

あと、引用ではないけどテスト関連で付け加えると、『リファクタリング』に載ってるリファクタリング・パターンのほとんどに「コンパイルしてテストする」と言う手順が組み込まれている事も、改めて確認できる。

この10数年で、リファクタリングという言葉が普及したおかげもあってか、動いてるコードに手を入れる心理的ハードルが昔より低くなったけど、「動いているコードはいじるな」っていう昔からの不文律を乗り越えて良いのは、テストコードという前提あってこそという、基本中の基本が蔑ろにされ始めてるのを感じる。テストもせずにコードをいじって、CIサーバから常時テスト失敗メールが飛んできてるのに何とも思わない連中が、どんどん増えてきている気がする。

出来ている現場の出来てる人達はびっくりするかもしれないけど、まだまだこんな感じの現場が多いんだよな…いかん、また眠れなくなってくる…

自動テストのレベル分け

2011-10-10T09:42:00.002+09:00

最近は、「xUnit で UnitTest を書いてカバレッジとってます」なんて、どいつもこいつも謳ってるけど、お前らマジかと。それで出来てるつもりなのかと…?

というわけで、秋の朝がさわやかなので、自動テストの出来てる度合いの段階区分を考えてみたい。

　Level 3: 出来てる：常時テスト成功、高カバレッジ

ちゃんとできてるプロジェクトの出来る子ちゃん達からしたら、取り立てて言及することもない当たり前の状態だと思う。

"Clean Check-In" が普通に守られているから、当然、テストも常時全件成功する。まあ基本中の基本。

で、TDD/TestFirst で開発してるから、開発の最初期から高カバレッジ（計測対象範囲内でのカバレッジ基準充足）で始まり、進捗に伴いソースコード量が増えていく中でも、高カバレッジを維持したまま推移する。

Level 2:怪しい：ほぼ常時テスト成功、低カバレッジ

"常時"かつ"全件"、テストが成功してはいるけど、カバレッジが低いプロジェクト。まあ、後付けでテストを書こうとすると、えてしてそんな感じになる。

原因としては、単にスキルがないから仕方なく後付けになったり、確信的にテストをサボっていたり、いろいろあるにせよ、結果的に以下のような感じになる。

①：テスト・コーディングに凄い余計な時間が掛かる。テスト・ファーストでやってさえいれば自然に得られたはずの保守性・メンテ性が備わってない低テスタビリティ・コードに無理やりテストコードを書いてく事になるから、まともな生産性は無理。

② ：テスティング・ポイントがウヤムヤになる。本体コードを書いていた時点では脳内にあったはずのコーディング意図がとっくに揮発した状態で、テストコードを後付けする破目になる。何をテストしてるのか本人が分かってない状態。

③ ：テストコードがザルになる。①で指摘した生産性の低いテストコードを、②で指摘した曖昧状態のプログラマが書いてくわけだから、「何かをテストする」事ではなくカバレッジを通す事が自己目的化してしまい、結果、Assertion も Expectation も不十分で、単に実行経路に含まれただけの空虚なテストコードになってしまう。

まあ、後付けテストの全てがそんな糞テストコードばかりとは限らないけど、テストコードは本体コードより先に書いとくに越したことはない。それが普通なのだと認識するだけで、悪い事がいろいろ避けられて良い事がいろいろ増えてくる。

Level 1:下手糞：常時テスト失敗、低カバレッジ

低カバレッジでも、取り敢えずテストが存在して差し当たり成功していれば、まだ見どころはある。また、たまたま間違えてテストを壊す事もあると思うが、そんなのすぐ直せば良い事で別に問題じゃない。

だけど、テストが通らないコードをコミットするのが常態化していたり、CIサーバでテストが失敗してるのに放置されていたりしたら、それはかなりの低スキル・チームの疑いがある。

実は、そうしたプロジェクトでは、Level 3 の状態を志してはいたもののスキル不足で健闘虚しくって感じじゃなくて、 Level 1 の状態で普通・正常だと思ってる開発者が大勢を占めていたりする。酷いのになると「今までに経験したプロジェクトではそれが普通だったし、テストが壊れても気にしない方がリファクタしやすい。」なんて事を真顔で主張したりする（リファクタするためにこそテストコードが必要だという最低限の常識を弁えていれば、そうした発言は出ないんだけど…）。

そうやって考えてくと、そもそも技術者の○○使用経験とか○○歴とかって何なのだろうという問題に突き当たるが、これは別の機会に考えてみたい。あと、Level 1 で生じている問題には、余りにも劣化した形で普及し実践されている『リファクタリング』もあるのだけど、これも別の機会に考える。

朝から、気が滅入ってきた。山でも歩いてこよっと。

Eclipse から XSLT 2.0 を使うやり方

2011-10-09T23:49:00.000+09:00

今更だけど、Eclipse の XSL Developer Tool で XSLT2.0 を使うやり方が分かったのでメモっとく。

まず、Saxon home edition の新しいやつ (saxonhe9-3-0-8j.zip)をダウンロード。
ダウンロードしたZIPを適当なとこに展開して、中の saxon9he.jar を出しておく。
Eclipse のメニューを [Window]>[Preference]>[XML]>[XSL]>[Java Processors] ってたどる。
Add を押して開いたダイアログボックスで、だいたい以下の様な感じで入力。追加したやつのチェックボックスを選択しておく。

これで使えるようになる。試しに、昔のポストで書いた XSLT で平均と分散を計算するやつを、XSLT2.0 を使ってやってみる。

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output indent="yes" />
  <xsl:template match="/list">
    <xsl:variable name="result">
      <xsl:call-template name="stat">
        <xsl:with-param name="items" select="item" />
        <xsl:with-param name="subtotal" select="0" />
        <xsl:with-param name="count" select="0" />
      </xsl:call-template>
    </xsl:variable>
    <average>
      <xsl:value-of select="$result/avg" />
    </average>
    <varianece>
      <xsl:value-of select="$result/sumOfD2 div $result/count" />
    </varianece>
  </xsl:template>
  <xsl:template name="stat">
    <xsl:param name="items"/>
    <xsl:param name="subtotal"/>
    <xsl:param name="count"/>
    <xsl:choose>
      <xsl:when test="$items">
        <xsl:variable name="t">
          <xsl:call-template name="stat">
            <xsl:with-param name="items" select="$items[position() > 1]" />
            <xsl:with-param name="subtotal" select="$subtotal + $items[1]" />
            <xsl:with-param name="count" select="$count + 1" />
          </xsl:call-template>
        </xsl:variable>
        <sumOfD2><xsl:value-of select="($items[1]-$t/avg)*($items[1]-$t/avg)+$t/sumOfD2"/></sumOfD2>
        <count><xsl:value-of select="$t/count"/></count>
        <avg><xsl:value-of select="$t/avg"/></avg>
      </xsl:when>
      <xsl:otherwise>
        <sumOfD2>0</sumOfD2>
        <count><xsl:value-of select="$count"/></count>
        <avg><xsl:value-of select="$subtotal div $count"/></avg>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>
</xsl:stylesheet>

前回と同じ入力XMLから同じ結果が得られることが確認できた。

前にやった時は、結果ツリーフラグメントの制約から template の結果を文字列にして返さざるを得なくて煩わしかったけど、XSLT 2.0 の temporary tree では普通の XML データとして扱えるので、やってる事をより直截に表現したコードになった。

リファクタリング本の Cyclomatic complexity

2011-09-29T01:03:00.000+09:00

『リファクタリング』を読んだ人なら、以下のコードに見覚えがあるかもしれない。第一章「最初の例」でのリファクタリング実演のために用意された架空の「長すぎるメソッド（Long method）」で、このメソッドを含む一群のコードを改善する過程で、リファクタ術が披露される。

まあ、実演のためのサンプルだから、本気でバカ長いメソッドを掲載するわけにはいかないだろうけど、それでも全然簡潔ではないし見た目も悪い。

自分なら普通、こういうのを製品コードに残したりはしないけど、それは単に自分にとって綺麗とか汚いといった審美的な感覚だけではなくて、他の開発者のミスリーディングを引き起こしたり生産性を下げたりといった、つまり他人様に迷惑をかける真似はすべきでないという、割と真面目というか普通な社会人的常識からでもあったりする。

  public String statement() {
      double totalAmount = 0;
      int frequentRenterPoints = 0;
      Enumeration rentals = _rentals .elements();
      String result = "Rental Record for " + getName() + "\n";
      while (rentals.hasMoreElements()) {
         double thisAmount = 0;
         Rental each = (Rental) rentals.nextElement();
         
         switch (each.getMovie().getPriceCode()) {
         case Movie.REGULAR:
            thisAmount += 2;
            if (each.getDaysRented() > 2)
               thisAmount += (each.getDaysRented() - 2) * 1.5;
            break;
         case Movie.NEW_RELEASE:
            thisAmount += each.getDaysRented() * 3;
            break;
         case Movie.CHILDRENS:
            thisAmount += 1.5;
            if (each.getDaysRented() > 3)
               thisAmount += (each.getDaysRented()  - 3) * 1.5;
            break;
         }
         frequentRenterPoints ++;
         if ((each.getMovie().getPriceCode() == Movie.NEW_RELEASE) &&
               each.getDaysRented() > 1) frequentRenterPoints ++;
         
         result += "\t" + each.getMovie().getTitle() + "\t" +
         String.valueOf(thisAmount) + "\n";
         totalAmount += thisAmount;
      }
      result += "Amount owed is " + String.valueOf(totalAmount) + "\n";
      result += "You earned " + String.valueOf(frequentRenterPoints) +
      " frequent renter points";
      
      return result;
   }

ところで、このコードの扱いにくさを「計測」するとどうなるか。よく使われている尺度としては、Cyclomatic Complexity があるが、どんなもんだろう。

ちなみに、CheckStyle の解説では、

1-4: considered good
5-7: ok
8-10: consider re-factoring
11+: re-factor now!

とある。

で、実際に測ってみると出てきた複雑度は 9 だった。"consider re-factoring"という事になるから、本の中での実演のネタとしては、正に丁度良かったという事になる。

さらに本に従って最後の段階までリファクタを施したコードの CyclomaticComplexity を測ってみると、結局 2 にまで低減していた。さすがにこれくらいまでやると、変な引け目も後ろめたさもなくソース・コードを共有できる。

で、せっかくある程度客観的にコードの良し悪しがでるのだから、自分だけじゃなくチームにも、簡潔で扱いやすいコードを書く方向で前向きに頑張ってほしいと思うのだけど、いろんな人が集まる現実のプロジェクトではそうも言ってられない場合も多い。

特に、すでにある程度コードが書き貯まったプロジェクトで、途中で CyclomaticComplexity チェックを適用したりなんかすると、「11+」どころか、妥協して15以上とかで設定しても警告が大量発生して、結局「今回は諦めようぜ」って感じになる。

人生って厳しいよね。

依存 jar を変更したらどうなるか

2011-09-18T00:12:00.000+09:00

あるアプリケーションがビルド時に参照していたライブラリの jar を変更して、そのアプリケーション再コンパイルせずに実行したらどうなるか。

====
以下のようなライブラリ・コードを書き、コンパイルして foo.jar に丸めておく。

package p1;

public class Foo {
  public String bar() {
    return "hello";
  }
}

で、このライブラリを使う以下のようなクライアントコードを書いて、-cp に foo.jar を指定してコンパイルする。

package p2;

import p1.Foo;

public class Client {
  public static void main(String[] args) {
    System.out.println(new Foo().bar());
  }
}

コンパイルされたクラスを java コマンドで -cp に foo.jar を指定して実行すると、標準出力に hello と出力される。

さて、ここでクラス Foo を変更して、つまり foo.jar の中身を変えて、再コンパイルせずに再度 Client#main() を実行したらどうなるか。

(1) メソッドの中身を変えてみる

  public String bar() {
    return "good-bye";
  }

問題無し。標準出力に good-bye と表示される。

(2) メソッドの名前を変えてみる

  public String Bar() {
    return "hello";
  }

メソッド p1.Foo.bar()Ljava/lang/String が見当たらないって事で、NoSuchMethodError が送出される。リフレクションのコーディングでよく catch したりするNoSuchMethodExceptionではなく、NoSuchMethodError が投げられてきた。

(3) メソッドの引数を変えてみる

  public String Bar(String s) {
    return "hello";
  }

これは (2) と同じ

(4) メソッドの戻り値を変えてみる

  public Object Bar() {
    return "hello";
  }

これも (2) と同じ。戻り値も識別される。

(5) throws を追加してみる

  public String bar() throws IOException {
    throw new IOException("test");
  }

これは意外にも普通に実行されて、IOExceptionが送出されてスタックトレースされる。意外というのは、これを再コンパイルしようとすると、コンパイルエラーが出るからで、Client#main() に throws を追加するか、bar() を try-catch で囲むかしないと、コンパイルが通らない。でも、コンパイルは通らなくても実行時のメソッド呼び出しは成功する。

(6) メソッドの可視性を変えてみる

  private String bar() {
    return "hello";
  }

これは IllegalAccessError が送出される。つまり、一応 p1.Foo.bar()Ljava/lang/String の存在は識別された上で、アクセスに失敗して例外が発生した模様。

(7) クラスの可視性を変えてみる

class Foo {
…

(6) と同様だが、クラス p1.Foo の存在を識別したあとに、アクセスするところで失敗している。

(8) 定数を変えてみる

メソッドは以上のような感じで、フィールドもだいたい想像がつく。で、ここでちょっと定数を試してみる事にする。

まずライブラリコードを以下のように変える。

package p1;

public class Foo {
  public static final int C = 100;
}

次に、クライアントコードを以下の様に変える

package p2;

import p1.Foo;

public class Client {
  public static void main(String[] args) {
    System.out.println(Foo.C);
  }
}

両方コンパイルして実行すると、標準出力に100が実行される。

ここでライブラリコードを以下の様に修正し、jar を作り直す。

  public static final int C = 200;

で、クライアントコードを再実行すると、標準出力に 200 が出力されると思いきや、実際には変更前と同じ100が出力される。
javap で見てみると、バイトコードに定数 100 が埋め込まれているのがわかる。なるほど定数はこういう扱いらしい。

public static void main(java.lang.String[]);
  Code:
   0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
   3: bipush 100
   5: invokevirtual #3; //Method java/io/PrintStream.println:(I)V
   8: return

(9) null値を試してみる

ライブラリ・コードを以下のように変更して、両方とも再コンパイルして実行してみる。

package p1;

public class Foo {
  public static final String C = null;
}

標準出力には、null が出力される。

ここでライブラリ・コードを、public static final String C = "a"; に変更して、クライアントを実行してみる。

(8) の結果から、null が出力される結果を類推してしまうが、実際には "a" が出力される。理由は、Java 言語仕様として null 定数として扱われないためコンパイル時には byte コードに直接書き込まれず、実行時に初めて Foo.Cの値を読むことになるかららしい。javap は以下のようになる。

public static void main(java.lang.String[]);
  Code:
   0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
   3: getstatic #3; //Field p1/Foo.C:Ljava/lang/String;
   6: invokevirtual #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   9: return

Advanced Level テストマネージャ試験受けてみた

2011-08-27T23:06:00.002+09:00

今日、JSTQB という団体がやってる、ソフトウェア・テスト技術者試験の Advanced Level 試験（Foundation Levelの上級試験）を受けてきた。

全65問のうち、きっと問題のミスだろうと思われる不可解なところを除けば、全問できたような気がする。まあ9割5分とか9割でも普通は合格だと思う。

というかあまり難しくなかった。去年、実施したらしいトライアル版試験の統計をみると合格率10%というから、さぞかし難関だろうと思ってたけど、試験時間を半分過ぎた辺りから余裕な感じで退出する人も多かったりして、今回は合格率50%を越えるような気がしないでもない。

ところで、試験勉強はISTQB（JSTQBの親の国際団体）が出している試験のシラバス（学習事項）をひたすら読むだけだけど、これがよくできていて勉強が苦にならない。

以前のポストで、Foundation Level のシラバスを紹介したけど、さすがにそれよりはテスター向けの専門性が高い。それでも自分のようなテスト専門じゃない開発者にとっても、読み応えがある。

実プロジェクトのテスト技術者の教科書としてもそのまま使えそうな内容で、暗記事項の羅列などはほとんど無いかわりに、なんというか現場感覚があるので、過去に携わったプロジェクトや今現在進行中のプロジェクトについて、いろいろ考えさせられる。

ちなみに Advanced Level 資格にはテストマネージャ、テストアナリスト、テストテクニカルアナリストという種別があり（今回のはテストマネージャだった）、３つそろったら、なんか格上の称号が与えられるらしい。まあ、欲しくないと言えば嘘になる。

JMockit: 基底クラスのコンストラクタのすりかえ

2011-08-15T00:18:00.002+09:00

基底クラスのコンストラクタ呼び出しだけをモックですりかえるにはどうすれば良いか。

以下のように実験してみた。AssertionError を投げているところを、設定ファイルの読み込みとかマスタデータへの依存とか、面倒なセットアップが必要だったり時間がかかったりする処理に読み替えると、ニーズが分かると思う。

====
例題 (1)

クラス BaseClass を継承したクラス CuT があるとする。こんな感じ。

public class CuT extends BaseClass {

   public CuT() {

      super();

   }

}

ところが、BaseClass の実装はこんな感じだったとする。

public class BaseClass {

   protected BaseClass() {

      throw new AssertionError();

   }

}

以下のテストコードを実行すると、当然、AssertionEror が発生してテストが落ちるが、落とさずにインスタンスを作るにはどうすれば良いか？

@Test public void testCuTConstructor() {

   //ここに何を書けば落ちないか

   new CuT();

}

答え (1)

以下の様にして、基底クラスのコンストラクタをすり替えられる。

@Test public void $init() {

   new MockUp<BaseClass>() {

      @Mock void $init() { /*とりあえず何もしない*/}

   };

   new CuT();

}

例題(2)

例題(1) にちょっと書き足してみる。

public class BaseClass {

   protected final int bar;

   protected BaseClass(int bar) {

      this.bar = bar;

      throw new AssertionError();

   }

}

public class CuT extends BaseClass {

   public CuT(int bar) {

      super(bar);

   }

   public int foo() {

      return this.bar * 100;

   }

}

@Test public void $init2() {

   new MockUp<BaseClass>() {

      //ここに何も書かないと、下のアサーションが失敗する

   };

   Assert.assertEquals(200, new CuT(2).foo());

}

このままだと基底クラスの bar が 2 で初期化されず、foo() が 0 * 100 = 0を返してしまうので、アサーションが失敗する。MockUp の匿名インナー型定義に、何を書き足せばテストが通るか？

答え (2)

コンストラクタ実行中のタイミングで、モック対象インスタンスの bar フィールドに適当な値を設定すれば良いわけだが、そのインスタンスをどう取得するかというのが問題。"it"フィールドという仕組みを利用すれば良いらしい。

@Test public void $init2() {

   new MockUp<BaseClass>() {

      BaseClass it;

      @Mock void $init(int bar) { 

         Deencapsulation.setField(it, bar);

      }

   };

   Assert.assertEquals(200, new CuT(2).foo());

}

この例では、bar は private フィールドなのでDeencapsulation ユーティリティクラスを使っている。ちなみに bar は final だけど、問題なく設定できている。

JMockit を使って簡単に「後回し」するやり方

2011-08-14T19:21:00.017+09:00

二つのクラスがあって、片方がもう片方に依存しているとする。つまり、参照関係や使用関係がある。

両方とも開発対象の場合、常に「依存される」側からしか作ろうとしない／作れない開発者がいるけど、逆の方向、つまり「依存される」側を一旦後回しにして「依存する」側から作った方が見通しが良い場合が多い。

方法はいくつもあるが、今日は JMockit を使って実演してみる。

====
◆ 仕様
依存する側のクラス

クラス CuT：Collaborator を使うクラス。こいつから作る。
　関連オブジェクト：
　　col1: Collaboratorのインスタンス
　　col2: Collaboratorのインスタンス
　コンストラクタ：受け取った2つの整数によりcol1 と col2 を初期化する
　メソッド：
　　int foo(int number):
　　　col1 と col2 の bar() に number を渡し、結果の合計を返す

依存される側のクラス

Collaborator：CuT に使われるクラス。後回しにする。
　コンストラクタ：受け取った整数を保持する
　メソッド：
　　int bar(int number)
　　　コンストラクタで受け取った整数と引数 number を用いて、何か計算をして返す。

◆ コーディング
両クラスのガラだけ書いてみる。CuT から作ってく趣旨なので、テストクラス CuTTest も書き始める。

public class CuT {}

public class Collaborator {}

public class CuTTest {}

まず、コンストラクタのテストを CuTTest に追加する。CuT のコンストラクタで受け取った引数が、二つの Collaborator のコンストラクタに受け渡されれば良いので、次のようなテストメソッドを書く。

@Test public void $init(final Collaborator mock) {

 new Expectations() {

    {

     new Collaborator(2);

     new Collaborator(3);

    }

 };

 new CuT(2, 3);

}

とりあえず、存在しないコンストラクタを呼んでいるのでコンパイルエラーになるから、これを解消する。

まず、Collaborator のコンストラクタだが、こいつは以下の様なコードで後回しにする。

public Collaborator(int i) {

 throw new AssertionError();

}

次に、CuT のコンストラクタだが、まずモックがちゃんと効いているか確かめるために、以下のように空の実装を書いて、一度テストを実行してみる。

public CuT(int number1, int number2) {}

テスト実行すると、「コンストラクタが引数 2 で呼ばれていない」といった感じのエラーメッセージが出力されるので、今度は以下のような感じで、ちゃんと書く。

public class CuT {

 final Collaborator col1;

 final Collaborator col2;

 public CuT(int number1, int number2) {

    this.col1 = new Collaborator(number1);

    this.col2 = new Collaborator(number2);

 }

}

再度テスト実行すると、テスト成功。

続いて同様に、まずテストから foo() を書く。

テスティングポイントは、「foo() で受け取った引数を、col1, col2 の bar()に渡している事」と「col1, col2 の bar()の戻り値の合計を、foo() の戻り値とする」なので、以下のようなテストコードになる。

@Test public void foo(

    @Mocked(capture=1) final Collaborator col1,

    @Mocked(capture=1) final Collaborator col2) {

 new Expectations() {{

    col1.bar(7); result = 10;

    col2.bar(7); result = 100;

 }};

 Assert.assertEquals(110, new CuT(2, 3).foo(7));

}

Collaborator#bar() の実装が無いので、コンストラクタ同様に AssertionError 送出のみの後回しコードを追加して、コンパイルエラーを解消する。

public int bar(int i) {

 throw new AssertionError();

}

CuT#foo() は、とりあえずダミーの固定値を返すようにして、テストを実行してみる。

public int foo(int i) {

 return -1;

}

実行すると「bar が引数7 で呼ばれていない」といったエラーメッセージが出力される。期待通りなので、おもむろに foo() の実装を本物コードに修正する。

public int foo(int i) {

 return this.col1.bar(i) + this.col2.bar(i);

}

これで、テストがちゃんと通るようになる。

一段落ついたら、クラス CuT の事は忘れて、Collaborator 実装に集中して取りかかればいい。

◆ 補足
ちなみに、JMockit に不慣れで capture の意味が分からなければ、このサンプルの col1 と col2 の capture を変えてテスト実行すれば、capture がどういう働きを持つのか分かると思う（場合によっては Expectations を NonSrictExpectations に替える必要がある）。

例えば、col1 のcapture を2に変えると、foo()の戻り値は20になる。col2 をそのまま変えずに col1 の capture を 0 にすると、foo()の戻り値は100になり、col2 の capture を2にすると、foo()の戻り値は200になる。

テストメソッド CuTTest#foo() のパラメータの col1, col2 が、CuT のフィールドのcol1, col2 のどれに対応するかが、capture で制御されているのが分かると思う。

さらに、もう一つ追記。上の CuTTest#foo()は以下のように書き換えられる。

@Test public void foo_explicitVerification(

    @Mocked(capture=1) final Collaborator col1,

    @Mocked(capture=1) final Collaborator col2) {

 new NonStrictExpectations() {{

    col1.bar(anyInt); result = 10;

    col2.bar(anyInt); result = 100;

 }};

 Assert.assertEquals(110, new CuT(2, 3).foo(7));

 new Verifications() {{

    col1.bar(7);

    col2.bar(7);

 }};

}

若干、冗長になるが、テストの都合で指定したい動作と、検証したい動作を分けて書いている。実際の業務ロジックなんかで複雑な相互作用がある場合など、Expectations に全部書いてしまうと何がテスティングポイントだったのか分かりにくくなる事がある（特に後付けでテストを書かざるを得ない状況などで）。そんなとき Verifications のブロックに本当に検証すべきだった事を書いておくと、テスティングポイントを見失わずにすむ。

ちなみに、Verifications には、FullVerifications, FullVerificationsInOrder, VerificationsInOrderといった派生クラスがあるから、適当に使い分けるべし。

JMockit と Swing と無名クラス

2011-07-11T00:03:00.002+09:00

JMockit を使った Swing の UnitTest を考えてみる。今日はとりあえず、最初の一歩。
参考資料はこれ → Behavior-based testing with JMockit

====
まずこんなコードから始めてみる。Swing に限らず、GUI フレークワークの入門書の最初に出てくるような、何もないウィンドウを単に開いてみるだけのもの。

public class Exercise1 {
  public static void main(String[] args) {
     JFrame frame = new JFrame();
     frame.setSize(500, 300);
     frame.setVisible(true);
  }
}

要するに 500×300のウィンドウがビジブルになれば良い訳で、以下のようなテストコードになる。

public class Exercise1Test {
  @Test public void main() {
     new Expectations() {
        @NonStrict JFrame frame; {
        frame.setSize(500, 300);times=1;
        frame.setVisible(true);times=1;
     }};
     Exercise1.main(new String[]{});
  }
}

ここで、ウィンドウのクローズイベントに対応するアプリケーション終了処理が無い事に気づき、例えば、以下のように追加したとする。

public static void main(String[] args) {
  JFrame frame = new JFrame();
  frame.addWindowListener(new WindowAdapter() {
     @Override public void windowClosing(WindowEvent e) {
        System.exit(0);
     }
  });
  frame.setSize(500, 300);
  frame.setVisible(true);
}

この無名クラスを含むコードをどうやってテストするか。

以下のような方針をとってみた。

System クラスをパーシャルモックして、exit(0) 呼び出しを expect する（変な日本語だが…）。
無名インナークラスについては、次のようにする。
- addWindowListener に渡された、WindowListener を保持しておく。
- main() 実行の後で、保持しておいた WindowListener のwindowClosing()を明示的に呼び出す。

コードはこんな感じ。

public class Exercise1Test2 {
  @Mocked({"exit"}) System system;
 
  static class WindowListenerCapturer implements Delegate {
     WindowListener captured;
     void addWindowListener(WindowListener l) {
        captured = l;
     };
  }
 
  @Test
  public void main() {
     final WindowListenerCapturer delegate = new WindowListenerCapturer();
     new Expectations() {
        @NonStrict JFrame frame; {
        frame.addWindowListener((WindowListener)any); result = delegate;
        frame.setSize(500, 300);times=1;
        frame.setVisible(true);times=1;
     }};
     new Expectations() {{
        System.exit(0);
     }};
     Exercise1.main(new String[]{});
     delegate.captured.windowClosing(null);
  }
}

ここでは、実際の実行パスの流れと同じになるように、main() からの Expectation と、windowClosing() からの Expectation を分けて書いてみた。

WindowListenerCapturer を使わないで、result = new Delegate() { ... }として、「...」のところで、windowClosing() を呼ぶやり方も試してみたが、何故か Eclipse プラグインがテスト終了を認識しない。

まあ上で示したコードでも、キャプチャのためのコードが若干増えることになるとはいえ、実行時の流れを表していると言う点では、却って分かりやすいような気もする。

Effective Java から例外関連項目

2011-07-07T00:44:00.002+09:00

以下、『Effective Java (2nd Edition)』から、9章「例外」に関係する項目。

緑：推奨黄：注意赤：禁止

Item 57: Use exceptions only for exceptional conditions
ループとかに使うなという基本中の基本。パフォーマンスにも悪影響あり。

Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors
まあ一応、教科書的な原則としてはこんな感じだろう。ただチェック例外の是非については、結構物議を醸す。そもそも、こんなの必要なのかと。Spring なんかも RuntimeException 派だし、C＃や C++ でチェック例外が無いからといって困った事も全然ない。

Item 59: Avoid unnecessary use of checked exceptions
むやみにチェック例外を使うなと。例えば、「とりあえず呼んでみて例外が上がったらハンドリングする」なんてやり方より、「呼ぶ前にまずチェックする」やり方の方が、よりインテンショナルなコードになる場合がある。そんなメソッドのシグネーチャに例外を含めたって、誰の得にもならず負担が増えるだけ。

しかしここでも、いっそチェック例外なんて止めりゃいいじゃんなんて思いが、やはり沸いてきたりする…

Item 60: Favor the use of standard exceptions
例外に限らず全ての Java 標準APIに言えるけど、よく調べ、よく理解して、使い倒していくと、いろんな意味で効率的。低リスクで高い生産性が得られる。

Item 61: Throw exceptions appropriate to the abstraction
よくAPI なんかについて、低レベルとか高レベルとか言うけど、例外についてもレベルに合わせて使い分けよう、必要なら変換もしようという話。

Item 62: Document all exceptions thrown by each method
メソッドのドキュメントで、例外の説明をちゃんとしとけと。特に、RuntimeException だけで押し通す方針を選択した場合、チェック例外の面倒くささから解放される分、このドキュメント化だけはちゃんとしないと単なる手抜きになる。

Item 63: Include failure-capture information in detail messages
せっかく例外投げるんだから、ちゃんと原因究明の手がかりも含めようという、まっとうな話。まあ、面倒くさいし省かれがちだけど、これが正論。

Item 64: Strive for failure atomicity
例外送出による実行中断のおかげで、システムの状態が中途半端になったりしないように、例外発生時には呼び出し前の状態を復元しようという項目。

こういうのを考えると、注意喚起力が強いチェック例外って、やっぱアリかなあなんて思えてくる。少なくともドキュメントには、やはり可能性のある例外を列挙しておきたい。まあキャッチしたとしても、状態の復元はいつも簡単には行かないだろうけど。

Item 65: Don't ignore exceptions
これについては、前に書いた。驚くべき事に、例外を基底クラスでキャッチしてモミ消した挙句、鼻高々という面白い人種が、業界の底辺には多数棲息しているが、これらのおバカさん達についてもレポートした。

JMockit

2011-07-04T01:28:00.007+09:00

数日前のポストで、この２・３年に普及してきた、Java の Mocking / Isolation フレームワークに触れた。今日は、そのうちの一つ JMockit を使って、以下のお題について解を考えてみる。

クラス TestTarget があり、Collaborator オブジェクトへの関連と、メソッド methodA() を持っている。

public class TestTarget {
   private final Collaborator collaborator = new Collaborator();
   public String methodA(String pattern) {
      int hour = Calendar.getInstance().get(Calendar.HOUR_OF_DAY);
      return String.format(pattern, collaborator.methodB(hour));
   }
}

methodA() では、Collaborator オブジェクトのメソッド methodB() を呼んでいるが、methodB() の振る舞いについて分かっている事は、24時間制の「時」を表す整数を与えると、その時刻を表す単語（"morning"や"夕方"など）を返すと言う事だけである。

さて、ここで methodA() における、Collaborator オブジェクトとの協調を含む、TestTarget の振る舞いをテストするコードはどのようなものになるか。

見ての通り、methodA() の振る舞いは、

Calendar から現在時刻の「時」の部分を取得し
これを Collaborator.methodB に渡して戻り値を受け取り
更にこれを書式化して返すというものになる。

テスティングポイントは以下のようになる。

Calendar から、正しく「時」を取得している事
collaborator に渡された「時」が、上記1で取得したものである事
collaborator から返された文字列を正しく用いて、メソッドの戻り値を作っている事

また、以下のような事に留意する必要がある。

Collaborator.methodB() の現時点の挙動には依存しない事。
時間の区切りがどうなっているか、言語が何であるかなどは、今後変わる可能性があるが、TestTarget クラスの責任範囲外である。
Collaborator.methodB() の実コードを呼ばない事。
Collaborator は外部サービスが起動している事に依存していて、実行時間も無視できない。また TestTarget のテストで Collaborator コードまで呼ばれてしまうと、コード・カバレッジが実際を正しく反映しなくなると言う問題もある。
このテストをどの時間帯に実行しても結果が変わらない事。
つまり、Calendar が返す時刻に依存してはいけない。

この UnitTest を、従来の dynamic proxy ベースのツール（jmock など）を使ったり、ましてや状態ベースの普通の JUnitテストで書こうとすると、難しいテストコーディングになったと思う。

JMockit を使うと以下のような感じになる。

public class TestTargetTest {
   @NonStrict Collaborator collaborator;
   @Mocked({"getInstance", "get(int)"}) Calendar mockCalendar;
   @Test public void methodA() {
      final int HOUR = 7; 
      new Expectations() {{
         collaborator.methodB(HOUR); result = "morning";
         Calendar.getInstance(); result = mockCalendar;
         mockCalendar.get(Calendar.HOUR_OF_DAY); result = HOUR;
      }};
      String actual = new TestTarget().methodA("good %s!");
      Assert.assertEquals("good morning", actual);
   }
}

コードの意味は以下のようなもの

Calendar.getInstance() がモックの Calendar を返すように、getInstance() コードを差し替えた
Calendar のモックは、今、何時なのか尋ねられる事を期待し、またその際、固定値7 を返すよう記述した。
Collaborator のモックが、固定値7 で methodB()が呼ばれることを期待し、その際、固定値"morning"を返すよう記述した
上記設定で、TestTarget.methodA()に"good %s!"が与えられ、"good morning"が得られる事を検証するよう記述した。

一度グリーンにしてから、いろいろコードを変えてみて期待通りにレッドになることを観察してみた。

せいぜい jmock の延長くらいかと思っていたら、使用感はかなり異なっていて、若干戸惑う。ただし、状態変化ベースだけではなく、相互作用ベースの UnitTest まで理解していれば、それほど高いハードルではない。DynamicProxy 系のテストを書いていていろいろ悩んだり困った経験のある人ほど、理解が早いと思う。

技術者と英語：「読める」だけで嬉しい三つの事

2011-06-30T02:04:00.006+09:00

TOEIC 800点前後というと、レベルBに当たる。

TOEIC が提示している相関表の説明によると、「どんな状況でも適切なコミュニケーションができる素地を備えている」、「日常会話は完全理解」、「業務上も支障なし」とされている。

なんて言っても、実は「話す」「書く」が未経験でも「聴く」「読む」がソコソコできれば、割と取れる点数だったりする。自分もだいぶ前に 800を越えたが、恥ずかしながら全然喋った事なんかない。

つうか話す相手も機会も今のところ一切無いし、従って興味も沸かず努力のしようもないんだけど、ソフトウェア開発技術者としては、「読める」だけで結構役に立つ事がある。

以下の３つ。

◆ 英語でググれる
言うまでもなくインターネットは日本語情報より英語情報の方が圧倒的に多いし、技術情報は特に英語圏発のものが時間的にも先行している事が多い。

英語が読めると、Google の search settings で、English を設定しておいても別に問題ないから、情報量の少ない日本語サイトを避けて効率的に検索できる。

技術系BBSでのディスカッションやトラブルシューティングでも、海外の方が盛んで検索にもヒットしやすい。

◆ 技術系の洋書が読める
最近は、少しだけ改善したようだけど、一昔前の邦訳書は、かなり読みにくいものが多かった。APIリファレンス的なものはまだマシな方だけど、ちょっとユーモアを交えた語り口になったり、思想的に難解な話になったりすると、途端に日本語がおかしくなる。

邦訳書の日本語に対する文句は至る所で聞くけど、最初から原書にしておけば、無駄なイライラをせずにすむ。つうか、無駄な変換レイヤーが無いという点で情報処理の視点からもある意味合理的なわけで、技術者ならなおさら原書を選択すべき。

◆ ソースコードが英語に見えてくる
意外と意識されていない事が多いが、ほとんどの高級プログラミング言語は英語ベースだったりする。

まず単語の面で、言語のキーワードにおいても、各種 API の識別子においても、そのほとんどは英語の語彙、つまり何百年も前からアングロサクソンが日常のコミュニケーションの中で使ってきた言葉で構成されている。

また文法の面でも、意識的にか無意識的にか知らないけど、メソッド呼び出しの文が、「subject.verb(object)」みたいな感じで、だいたい英語の語順に従うようになっていたりする。

なので、上手に書いたプログラムは自然言語としての英語に近くなり、下手なコメントやダイアグラムなんかよりも、書き手の意図を読者に、より効率的、より直截に伝える高い表現力を持つ事ができる。

英語が「読める」ようになるだけでも、人間同士が意思疎通するコトバという観点から見たプログラムの良し悪しがより分かるようになり、ソースの読み書き両面に良い効用が出てくる。

====

ちなみに、逆に英語が全然読めない人の場合、英文としての表現力さえ備えるに至った良質なコードを前にしても、解読を要する意味不明な記号の羅列か、もしかすると ASCII アート的な図形にしか見えていないのでは、と疑わしくなる場面がよくある。

こういう人達って、「ソースを読む」ではなく「ソースを解析する」という言い回しを好む。「ソースが言葉である」なんて事は脳内ですら成立したためしがないから、「読める」コードなんか自分でも書ける訳もなく、必然的に無駄なコメントだらけの残念なコードを書いてしまうことになる。

java の static メソッドの mocking

2011-06-27T23:36:00.002+09:00

しばらく .net 案件とかやってた間に、いつの間にか Java でもstatic メソッドに mocking が適用できるようになっていたらしい。

ググってみると、今のところ PowerMock と JMockit が、どうやら使えそうな感じ。

前に Java をやっていた頃、mocking には jMock（いわゆる「流れるようなインターフェイス」が何とも素敵な奴だったのだが）を使っていたが、この jMock の制約のせいで java では static メソッドは迂回もすり替えもできないと諦めていた(final 外しはあったが)。

考えてみれば、.net の Mole も TypeMock も instrumentation を使っていたわけだけど、Java だって 5.0 からは instrumentation があったんだから、とっくにできていて不思議はなかった。

しかし、どっちを使えば良いか悩む。

つうか、昔と同じく jMock を使うという選択肢も捨てきれないから、3択になる。いや、PowerMock は EasyMock か Mockito と組み合わせるからもっと選択肢が増える（jMock との組み合わせもできないことないらしいが、ちょっと不安）。

カバレッジツールとの相性とか、微妙な使い勝手の優劣とかもあるだろうし、急いで決めねばならない状況ではあるんだけど、拙速な決断は危ない。

うーん、もっと早く気づいていればなあ…

Fedora 15/Jenkins/Maven3/Subversion/Helios

2011-06-24T04:29:00.003+09:00

空きマシンに入れていた Fedora 12を Fedora 15 Lovelock に入れ替えて、自宅環境の筆頭開発マシンに昇格させ、ついでにその他開発ツールもセッティングした。その作業の超ザックリメモ。

====

Helios:Fedora の「ソフトウェアの追加と削除」から GUIでインストール。Fedora 12の時は Galileo だったが、Fedora 15 では Helios (Eclipse 3.6)になっていた。

Maven 3:apache のダウンロードサイトからバイナリを落としてきて適当に展開。README.txtを見ながら適当に設定、"mvn --version" で 3.0.3 が入ったことを確認。

Subversion:これも「ソフトウェアの追加と削除」でインストール。バージョン 1.6.16 が入ってきた。"svnadmin create" で適当にリポジトリを作っておく。差し当たり file://でアクセスするだけなので、これ以上の設定は保留。

m2eclipse:Helios の「新規ソフトウェアのインストール...」で、更新サイトに[このURL]を指定してインストール。

Subclipse:Helios の「新規ソフトウェアのインストール...」で、更新サイトに[このURL]を指定して、Subclipse, Client Adapter, JavaHLを選択してインストール。

Jenkins: [ここ]を見てインストール。"sudo /etc/init.d/jenkins start"で起動し、ブラウザで localhost:8080 を開いて確認。で、とりあえず stop しておく。

テスト用プロジェクト作成:

Helios に戻る。
maven-archetype-quickstart を指定して新規 Maven Projectを作成。
pom.xml で JUnit のバージョンを4.8.2に変更して、依存性を更新。

App.java を書き換える

public class App {
    public String getMessage() {
        return "Hello World!";
    }
}

AppTestを書き換える

public class AppTest {
   @Test
      public void testGetMessage() {
      String message = new App().getMessage();
      Assert.assertEquals("Good-Bye World!", message);
   }
}

Maven package を実行して、テストでビルドが失敗するのを確認。
上で作ったリポジトリを指定して"プロジェクトの共用"を実行し、適当にファイルを選んでバージョン管理に追加して、敢えてテスト失敗版をコミット。

Jenkins に Jobを追加:

"java -jar /usr/lib/jenkins/jenkins.war"で起動する。(init.d/jenkins startだと、file:// で SVNリポジトリにアクセスできなかったので、とりあえず war を直接起動。)
ブラウザから開いて、[Manage Jenkins]/[Configure System] から、右のように Maven の設定 → Install Automatically をアンチェックして、上でインストールした Maven のパスをMAVEN_HOMEに指定。
Jenkins の[New Job] で [Build a maven2/3 project] を選択。"Source Code Management" で Subversion を選択し、上で作ったリポジトリを指定。

Build 確認:

[Build Now] を実行し、テストでビルドが失敗している事を確認。
Helios に戻ってテスト・メソッドの"Good-Bye"をHelloに変えて、SVNコミット。
再び[Build Now] でビルド。今度はテストを含むビルドが成功している事を確認。

====

TODO

svn+ssh でのリポジトリアクセス
サービス化
Trac の導入とSVNとの連携
SVNコミットをトリガーとする自動ビルド
FishEye導入
Emma 導入

アジャイルの資格

2011-06-21T15:49:00.004+09:00

アジャイル関連の資格について調べてみた。

アジャイルと認定資格って、なんとなく相容れないイメージで、開発者の間でも物議を醸しているらしいが、最近は結構、動きが活発になってきている。

まあ他の資格と同じで、保有しているからといって実務能力があるって事にはならないだろうが、少なくとも会話が成立するレベルの語彙を持っている事の表明くらいにはなると思う。もちろん実践で成功している人なら、我流に偏らないお墨付きの正統な知識も持っているという事になり、鬼に金棒で言う事が無い。

====
◆ Scrum Alliance: 認定スクラムマスタ等
すでに日本でも取得者が増え始めている、Scrum Alliance の認定資格。

トレーニングコースに参加する必要があり、日本開催時の受講体験記をネットでも散見する。ただ、これが結構高い。ざっと検索したところ、同時通訳付きで20万、通訳なしで15万といったところか。会社の金ではなく個人で受けるとすると、ちょっとした決断が必要になる。

なんか昔のイメージだと、お金を払って2日間の講習に座ってるだけで取れるって感じだったけど、調べてみると、今は一応、インターネット経由の試験で知識を証明する必要があるらしい。

ちなみに Master 以外には、ProductOwner, Developer, Professional, Trainer, Coach といったものがある。

◆ Scrum.org: Professional Scrum Master 等
URLはここ

Professional Scrum Master I (Fundamental) :
トレーニング・コースも提供されているが必須ではなく、自信があればいきなりネット試験を受験してもよく、そこで 85%とれば合格らしい。

Professional Scrum Master II (Intermediate):
これもネット試験だが、小論文もあるらしい。費用もやや高額。

Professional Scrum Developer:
これはコース受講と試験の両方が要るらしいが、ただトレーニング・コースの方は欧米中心の開催。アジアでは今のところインドだけっぽい。

Professional Scrum Product Owner:
これもコース受講とネット試験。

◆ PMI: PMI-Agile Certified Practitioner

先月、Pilot Programが始まったばかりの PMIのアジャイル認定試験。

以前、PMP の勉強をしていたとき、使っていた問題集でも参考書でも、道路の延伸工事プロジェクトだとか、小売業の店舗拡大プロジェクトだとか、予想外にソフトウェア開発と離れた設問ばかりで、PMBOKってそう言うものだったのかと、ちょっと驚いた。

でも、同じ PMI の資格でも、PMI-Agile のFAQを見ると、馴染みのあるアジャイル開発の用語ばかりで、ソフトウェア開発者としてちょっとテンションが上がってくる。

◆ ICAgile:
ユースケースで有名なコーバーンとかが創立した、ICAgile なる組織でも、認定試験を提供する計画らしい。

組織自体が発足したてで、試験などはまだまだ形になっていないようだけど、この記事を読む限り、結構おもしろそうではある。

Java のスレッドプール

2011-06-21T02:58:00.004+09:00

『More Effective C#』の item 11 に、"Use the Thread Pool Instead of Creating Threads"というのがある。new でスレッドを生成するのではなく、.Net で提供されるプールを使えと。

で、昨日『Effective Java (2nd edition)』を調べていると、item 68 で、ThreadPoolExecutor が紹介されていたので、ちょっと試してみた。

====

以下のような状況を想定する。

クライアントが Socket をつなぐと、サーバは ServerSocket で accept()して、1から10までの整数乱数を 1000個返す。
クライアントはその整数を一つずつ読み取り、幾ばくかの処理時間を要する何らかの処理を行う。ここでは、読み込んだ整数をミリ秒の時間間隔と捉えて、その分だけ sleep() させるようなコードを書く事にした。

クライアントは以下のようなコード。

public class Receiver {

   private static final short LISTEN_PORT = 3434;
   private static final int CORE＿SIZE = 1;
   private static final int MAX_SIZE = 100;
   private static final int KEEP_ALIVE = 10;

   private static final ExecutorService pool = 
      new ThreadPoolExecutor(
         CORE＿SIZE, MAX_SIZE, KEEP_ALIVE, TimeUnit.SECONDS, 
         new LinkedBlockingQueue());

   public static void main(String[] args) throws IOException {
      Socket socket = new Socket("localhost", LISTEN_PORT);
      DataInputStream in = new DataInputStream(socket.getInputStream());

      long start = System.nanoTime();
      for (int i = 0; i < 1000; ++i) test(in.readInt());
      System.out.println((System.nanoTime() - start) / 1000000000.0);

      in.close();
      socket.close();
  
      pool.shutdown();
   }

   private static void executeTimeConsumingProcess(int interval) {
      try {
         TimeUnit.MILLISECONDS.sleep(interval);
      } catch (Exception e) {}
   }

   private static void test(int interval) throws IOException {
       //ここを書き換えて比較する
   }
}

で、この test() メソッドの中身を変えて、①逐次実行（並列なし）、②スレッドを生成する方式、③スレッドプールを使う方式で比較してみる。（サーバー側は、DataOutputStream で整数を返すようなコードになるが、ほぼ自明なので省略。）

① まず、並列処理をしない逐次実行のパターン

private static void test(int interval) throws IOException {
   executeTimeConsumingProcess(interval);
}

実行時間は、約 5.6秒と出た。平均 5ms の処理が1000回なので、だいたい想定どおりの結果。

② 次に、スレッドを生成するパターン。

private static void test(final int interval) throws IOException {
   new Thread(new Runnable() {
      @Override public void run() {
         executeTimeConsumingProcess(interval);  
      }
   }).start();
}

これは約 0.14秒と出た。当然ながら、逐次実行よりは大幅に速い。

③ 最後に、スレッドプールを使うパターン。

private static void test(final int interval) throws IOException {
   pool.execute(new Runnable() {
      @Override public void run() {
         executeTimeConsumingProcess(interval);
      }
   });
}

結果は約 0.028秒で、スレッド生成の5倍のスピードが得られた。やっぱり、それなりにパフォーマンスは良いらしい。

====

プールの初期サイズ、最大サイズなどを調整すると、若干値が変わってくる。実務で使うときは、実行環境に応じて調整できるような仕組みを作っておくと良いかもしれない。

ThreadPoolExecutor よりさらに手軽に使えるスレッドプールが、Executors の newCashedThreadPool() や newFixedThreadPool() などのメソッドで得られるが、一応試してみたところ、ThreadPoolExecutor を直に使うより、若干遅かった（倍くらいの所要時間）。もちろん、簡易な分、調整は利かない。

Effective Java からperformance 関連項目

2011-06-20T10:36:00.004+09:00

以下、『Effective Java (2nd Edition)』から、パフォーマンスに関係する項目。

赤：パフォーマンスに特に関係する項目
橙：パフォーマンスに割と関係する項目
黄：パフォーマンスに一部だけ関係する項目

Item 1: Consider static factory methods instead of constructors
オブジェクトの生成が抑えられるという static factory methods の利点について、instance-controlled class というキーワードで記述されている。Flyweight パターン（GoF）的に活用するとパフォーマンス向上に効果あり。

Item 5: Avoid creating unnecessary objects
「immutable なオブジェクトは常に再利用しよう」とか、「boxing / unboxing による暗黙のオブジェクト生成に気をつけよう」などといった注意喚起。

Item 6: Eliminate obsolete object references
メモリリーク対策として紹介されているが、オブジェクトへの参照を常に null out することは、無駄に内部品質（すなわちコーディングの生産性）を損なうバッド・プラクティスとされている。null 代入するなら、メモリリークを起こし易い場所に見当を付けて集中的に行うべき。

Item 7: Avoid finalizers
デストラクタ感覚で使うのは止めましょうという話だが、往々にして期待通りに動かないし、そもそも必要性からして疑わしい。さらに深刻なパフォーマンス劣化さえもたらしうるとの記述がある。

Item 9: Always override hashCode() when you override equals
極端な例だが、hashCode()で定数を返したりなんかすると、リニアなアクセス時間になって、本来のHashXXX のパフォーマンスが得られないって話。

Item 15: Minimize mutability
クラスを定義する際には、できるだけ immutable にして行こうという、今ではかなり普及したプラクティス。パフォーマンスとの関連でいえば、無駄なオブジェクト生成を抑えられるという利点と、値が変わる度に新規インスタンスが必要になるという欠点の、両面があるので注意。

Item 48: Avoid float and double if exact answers are required
業務アプリのプログラマには常識的な話。ただ、あるデータ項目について、どの程度正確な値が求められているか、必ずしも自明ではない。BigDecimal で精度をとるかプリミティブ型でパフォーマンスをとるか、やはり要件によりけり。

Item 49: Prefer primitive types to boxed primitives
Integer や Long などを無自覚に使うと、暗黙の boxing / unboxing で深刻にパフォーマンスが落ちうると言う話。

Item 50: Avoid strings where other types are more appropriate
特にパフォーマンスへの言及は無いが、普通に考えればわかるとおり、本来それ専用の型定義で表現されるべきデータ構造を、下手に文字列なんかで扱ったりすると、内部品質にもパフォーマンスにも悪影響がある。

Item 51: Beware the performance of string concatenation
まあ常識。StringBuilder を使いましょうと。

Item 53: Prefer interfaces to reflection
普通のメソッド呼び出しより reflection の方が遅いという普通の話。

Item 54: Use native methods judiciously
昔と違って JVM が大幅に速くなった今では、JNI経由の native メソッド使用は、期待するほど効果がないという話。

Item 55: Optimize judiciously
「未熟な最適化は諸悪の根源」という Knuth の言葉など、今よりもメモリが小さくCPUが遅くてパフォーマンスが難問だった時代から受け継がれる先人の警句を引用して、やみくもなコード最適化／パフォーマンス・チューニングについて警告している。このブログでも書いてきた（これとかこれ）。

Item 57: Use exceptions only for exceptional conditions
Exception をループ境界の判定などの制御フローに使ったりするのは、本来の使い方から逸脱しているだけでなく、パフォーマンスにも悪影響がある。まあ、そこまでバカな事する人なんか見たことないけど。

Item 66: Synchronize access to shared mutable data
「アトミックなデータならば、パフォーマンス向上のための同期コード省略が可能」という迷信を批判。

Item 67: Avoid excessive synchronization
同期コードによる待ちが増えると、並行性の機会が奪われたりしてパフォーマンスが上がらないという普通の話。synchronize ブロックから alien method を呼ばないとか、synchronize ブロックを小さく留めるとかヒントが書かれているけど、まあ普通はそれほど簡単にいかないので、工夫のしどころではある。

Item 68: Prefer executors and tasks to threads
スレッドプールが標準APIで提供されているので活用すべし。

Item 69: Prefer concurrency utilities to wait and notify
高パフォーマンスな concurrent collection の紹介など、java.util.concurrent パッケージ活用のすすめ。

Item 71: Use lazy initialization judiciously
パフォーマンスに良かれと思って lazy initialization を書いても、大抵は逆効果だから止めておけと。どうしても必要なら、static field には lazy initialization class イディオム、instance field には double-check イディオムを使うこと。

Item 75: Consider using a custom serialized form
デフォルトのシリアライズ形式は、ロジカルなデータ形式に着目したカスタムのシリアライズより、パフォーマンスが悪い事が多い。

CodeComplete からパレートの法則など

2011-06-19T01:34:00.003+09:00

『リファクタリング』第2章の「リファクタリングとパフォーマンス」を読んでいたら、Steve McConnell の『Code Complete （下巻）』への参照があった。

以下、「25章コードチューニング戦略」から抜粋。

パレートの法則：
成果の80%は作業の20%から得られる

Barry Boehm：
20%のルーチンがプログラムの実行時間の80%を消費

Donald Knuth：
プログラムの4%未満がプログラムの実行時間の50%を占める

Jon Bentley：
あるプログラムで、0.5%の行が実行時間の80%を占めていた

Steve McConell：
あるプログラムで、1%未満のコードが実行時間の90%を占めていた

まあ、数字は異なるが言ってる意味は一緒で、要するにパフォーマンスに影響を及ぼしている部分はプログラム中のかなりちっちゃい部分だって事。まあ、アプリケーションのパフォーマンス改善の経験者には、割と常識かと。

「25章コードチューニング戦略」では、この他に「コードを書くそばから最適化すべきだ」という稚拙な戦略についても、バッサリ斬っている。これは以前の自分のポストでも同じような事を書いた。

また、チューニングを段階的に繰り返して効果を累積させる戦術を、さかんに奨励している。ただし当然ながら、それをやるには、それ相応の内部品質＝コード保守性が維持されていなければならない。例えば、パフォーマンスと引換えに内部品質が落ちるような箇所に関して、これを局所化するようなリファクタリングを併用しつつ、コードチューニングを積み重ねるというやり方が必要になると思われる。

あと、コード・チューニングはパフォーマンス改善策の一部であって、実は、アーキテクチャやデータ構造によるパフォーマンスへの影響に比べたら意外と大したことない場合が多いとも言っている。当たり前のことだけど結構大事だと思う。

保守性とイマドキの開発

2011-06-18T03:03:00.007+09:00

「ソースを綺麗にしてコードの保守性を高めよう」なんて事は誰もが言うし、「規約を作って静的チェックツールにかけよう」とか、「UnitTest を書いてリファクタリングも奨励しよう」なんて感じで話が進む事もあるけど、いざとなるとグズりだす怪しからんヤツらが実に多い。

スケジュールがきついからとか、コスト面の制約で人が足りないからとか言うのが、お約束のエクスキューズなんだけど、うーん、だからこそなんだがなあ・・・

で、ちょっとコードの保守性について、特に、それが大事なのは何故なのかという点を中心に考えてみる。

＝＝＝＝
実はまず、「保守性」ってネーミングが、そもそも良くなかったりする。語の使用の歴史的経緯から見ても、どうしても納品後の保守フェーズに係る品質要素という印象が拭えない。最も適切と思われる内部品質は意外と知られていないし、可読性だと読むだけみたいだし、「綺麗なソース」とか「健康なソース」では情緒的過ぎて説得力に欠ける。

ここで「保守性」を、開発者の素朴な観点から言い換えると、「保守作業の生産性」って事になる。ISO 9126の分類は、論点が違うのでここでは割愛

この生産性が低ければ、当該の保守作業にもその分だけ時間とお金が掛かったりするわけだけど、じゃあ、その保守作業とは何だっただろうか。

再び開発者観点で素朴に考えると、「既存ソースを読んで意図と構造を理解し、追加・書き換え・削除等の編集を施す」、さらに短くは「ソースを読んで編集する」という、それだけの事だとわかる。

で、これを踏まえて言い直すと、「保守作業の生産性」とは「ソースを読んで編集する作業の生産性」という事になる。…が、はて？こんなのは今時、保守フェーズに限定された作業なんかでは全然ない。

極論すれば、6ヶ月の開発期間における最初の10分くらいから、「ソースを読んで編集する作業」は早くも発生し始めるし、反復型の開発なら第二イテレーション以降は大部分がその意味で「保守作業」になる。

「動いてるコードはイジらない」的な昔の開発風景ならともかく、既存コードを編集しながら成長させる現代の開発では、「保守性」はプロジェクト全期間に渡る重大ファクターであり、開発初期から「実装生産性」そのものに漸近していく。

なわけだから、正しくは「スケジュールがキツいし人も足りない」-> 「ならば生産性を上げよう」-> 「つまりソースを改善して保守性を上げよう」と考えなければならない。これの逆をやってるから、各反復で負のスパイラルを誘発し、ドツボにハマっていく。

=＝＝＝
というのが、コード保守性に関する不見識への、差し当たりの抗議。

「そもそも保守性の高いコードとは何か」と、「保守性向上作業（リファクタ等）の工数はどうしてくれるんだ」という2つの事項についても説明が必要だが、別の機会にする。

まあ現場では、こうして理詰めで説明しても、心理的・組織的圧力で生産性を考慮しないままなし崩しに開発が進んでいってしまう事は往々にしてあるんだよなあ。

コード最適化の個人的三原則

2011-06-17T16:27:00.004+09:00

最近、アプリケーションのパフォーマンス・チューニングやコード最適化ついて、自分の考えを開陳する機会が何度かあった。

足し合わせて要約すると、以下のような感じになる。

◆コードを直す前後に計る
コード最適化に当たっては、修正を加えるに先立って、まず現時点の速度やその他のパフォーマンス指標を計測し、プロファイラ等を用いてボトルネックを突き止める。しかる後に、該当コードをピンポイントで修正し、それから再度パフォーマンスを計り直し、修正前と比べて効果を確認する（効果が無ければ元に戻す）。

…というのが、まあ、常識的な流れだが、実際の現場では意外とちゃんとできていない。

場当たり的な思いつきのパフォーマンス改善策を、システム全体のソースコードにバラまいて内部品質を下げてしまい、パフォーマンスチューニング改善作業そのものを停滞させてしまう場面がかなりよくある（これはまた、別の機会に詳述したい）。

カンに頼ったやみくもな対処は止めて、とにかく実測で把握する事がまずは必須。

◆数値目標を立てる
まあパフォーマンス向上というか、ほとんど何にでも一般的に当てはまる仕事の基本とも言える事だから、まあ、あまり説明がいらない気がする。

ところが、実際の現場では「とにかく速く」なんてお題目の下で作業が行われる事が結構多い。

こういうのは、要するに精神論・根性論みたいなものだから、そういったスローガンのもとでの作業は、無駄にプレッシャーが増加するだけで結局はあまりうまく行かない。

効果の薄い小手先の対応をせいぜいガンバッテみたりはするけど、具体的な目標を立てておけば決断できたはずの本来的な抜本対策が、なんとなく見過ごされたり、あるいは見てみぬふりをされたりする。（目標の立て方にもいろいろあるが、詳しく立ち入るのは別の機会にする。）

具体的な測定可能な目標を立てることが肝要。

◆最初から継続的に計る
これも「何事も早めに確認して早めに対応するのがよろしい」という、パフォーマンス話に限らず人の営みのほとんど全域に当てはまりそうなプラクティス。

まあ、リスク管理の基本中の基本でもあるはずなんだけど、なぜかシステム開発に限ってはなおざりにされている。かなり多くのプロジェクトで、パフォーマンスに関するテストや最適化を開発期間の一番最後にもってきて、関係者一同、毎度頭を抱えることになる。

開発初期から、継続的に計測する仕組みを作って監視するのが大切。

====
という３点について、自分としては、かなり当たり前の言わずもがなの事だと感じているが、いろんな反応があった。単なる同意だったり、なるほどと感心されたり、わかってはいるけどウチじゃ難しいんだよなって感じの苦笑いだったり。

まあ、各現場でそれぞれ文化や事情があるからなあ。

Scrum + XP

2011-06-13T03:37:00.003+09:00

国内外のいくつかのIT技術系サイトから、RSS 経由で配信される記事をいつも読んでいるけど、この数年、Agile系記事の中での XP 関連の話題がめっきり少ない。

と言っても XP が陳腐化したのではなくて、XP のプラクティス群が、その根底にあった価値観と一緒に既に広く普及し、実績を上げ、評価を確立し、換骨奪胎した形でこの業界に取り込まれて、いまさら extreme (究極)なんてキーワードで語られる必要が無くなったって事なのだと思う。

もちろん、XP の導入に挫折した残念な技術者たちが、プロジェクトの失敗の原因を自分たちの力不足ではなく、XP それ自体に帰結させて、「やっぱ、XP なんかダメだね」なんて言ってるような、底辺な現場も少なくないだろうけど。

で、少なくなった XP の話題の代わりに、スクラム関連の記事が多くなってきていて、たまに Lean と Kanban の話題が上がってくる以外は、ほとんどスクラムの話ばかりになっている。

また、ちょうど一年くらい前に、マイクロソフトのプリセールス技術者から、Team Foundation Server の導入事例について話を伺う機会があったが、そこでも開発プロセスは Scrum を採用していると聞いた。

そんな昨今だけど、XP でアジャイルに入ってきた人が、スクラム導入のために XP のプラクティスを捨てたり、XP的の価値観を矯正したりする必要はほとんどない模様。

XP はプラクティスに着目していて、一方、スクラムは組織と管理に着目していて、両者の対象範囲は意外と重ならなかったりする。重なっている部分も無くはないが、同じ事を言っているだけだったりする。

どうやら、スクラムという枠組み＝フレームワークの中で、XP のプラクティスを実践していくというのが、正しい方向なのだと思う。というか今にして思うと、それぞれを単体で導入・実施するより、スクラム＋XP の組み合わせの方が、大抵の開発現場ではむしろ摩擦が少なかったような気がする。

このギャラ、損か得か？

2011-06-12T03:40:00.002+09:00

開発案件のギャラを比べるとき、単純にどっちが得でどっちが損か比較するのは意外と難しかったりする。

難しい理由は、案件の内容だとか契約条件だとかいろいろあるが、今日は、契約条件に含まれる清算方式の違いを解消して比較する方法を考えてみる。

例１）
見込み稼働時間数が月240h の半炎上プロジェクトで、140h〜180h上下割60万の条件がついたとする。これと等価な単金固定プロジェクトのギャラはいくらか？

答え：
60万 + 60万 ÷ 180h ×（240h−180h） = 80万

言い換えると、これまで 140h〜180h上下割60万で仕事を受けてきた技術者が、見込み月240h の単金固定案件を受けるとすると、80万もらわないと割に合わないということになる。

例２）
単金固定72万の案件の引き合いがあって、プロジェクト内容を聴いたらとっくにデスマ化していて稼働300hに達している。これを140h〜200h上下割に換算するといくらになるか。

答え：
x + x ÷ 200h ×（300h−200h） = 72万
これを解いて、x = 48万。

このご時世、72万なら悪くないと思うかもしれないが、稼働時間によっては、上下割換算で40万台のしょっぱい案件になり得るとわかる。（ちなみに、この例を上限180hで換算すると43万2千円）

比較用に標準的な条件を設定して、複数案件を比較するという手もある。例えば「162h の時給換算」とか。（行政機関の年間営業日243日を採用し、これを12ヶ月で割ると、一月あたりの勤務日数は20.25日となり、これに8時間を書けると162時間となる。）

例３)
他の条件（通勤、やりがい等）が同じとすると、得なのはどれか。
① 60万単金固定 (想定220h)
② 57万(140-200) (想定220h)
③ 55万(140-180) (想定220h)
④ 54万(140-180) (想定200h)

答え：
① 60万 ÷ 220h × 162h =44.1818万

② 57万 × (1 + 20h／200h）=62.7万
　 62.7万 ÷ 220h × 162h =46.17万

③ 55万 × (1 + 40h／180h）=67.2222万
　 67.2222万 ÷ 220h × 162h =49.5万

④ 54万 × (1 + 20h／180h）=60万
　 60万 ÷ 200h × 162h =48.6万

得な順に、③→④→②→①　となる。

①、②、③は清算方式の違いによって、見掛け上の単金と受け取り額の順序が逆転し、従って損得も逆転する。
①と④では、受け取り額が同じだけど、稼働時間の違いにより、損得が逆転する。

====
こんな感じで、案件を比較できる。

（理想的には、8時間働いた後に追加で働く1時間と、12時間働いた後に追加で働く1時間では、同じ1時間でも価値が違うので、これを考慮する変換方式にする必要があるが、かなり複雑になる。）

換算方式を工夫すれば、他の要素も取り込んで標準化して比較できる。特に、通勤にかかる時間は、実は交通費以上に結構大きく影響する。往復30分と3時間では、実質的に失う時間が大きく違うので、比較するには一工夫必要になる。

なぜ UnitTestが生産性を上げるか

2011-06-11T06:54:00.008+09:00

前回、UnitTest の必要性について書き始めて、どうやらコーディングの生産性向上らしいってとこまで来た。今回はその続き。

＝＝＝＝
UnitTest はコーディングの生産性を高める。

・・・というのは少し大雑把で、より正確には、高い生産性を得るために最も重要な条件の成立に、UnitTest が不可欠であると言う事になる。

で、その条件とはすなわち「内部品質が高い」と言う事である。

この内部品質を高める事により、「ソースを読む」、「書き足す」、「書き直す」、「間違いを探す」と言った、コーディングの大部分を構成する作業に要する時間を大幅に削減できる。内部品質が高まるほど、コーディングの所要時間が下がり、生産性が上がってくる。

では、なぜ UnitTest が内部品質の向上に寄与するのか？

これは、UnitTest が内部品質向上作業の生産性を高めるからなのだけど、この「内部品質向上作業」とは、ザックリ言うとリファクタリングの事である。

このリファクタリングを徹底的に（Mercilessly）に行う事により、高度な生産性を実現できるような、高いㇾベルの内部品質に初めて到達できる。ここで UnitTest は、リファクタリング作業それ自体の生産性を高めるために（同時にリスクを下げるために）利用される。

これ以上の説明は不要な気がしないでもないが、なぜ UnitTest によってリファクタリング作業の効率性が高まるかというと、コード修正による「意図せざる事象」をもっとも効率よく検出できるからと言える。
前にも書いたが、UnitTest とは「doing the right things（正しい動作をしている事）」ではなく、「"doing things right"（正しく動作している事）」を検証するものである。ここで「正しく」とは、「意図した通り」という意味なわけで、つまり UnitTestとは「意図せざる事象」を発見する仕組みという事になる。

リファクタリングという作業は、極論すれば仕様なんて知らなくても良いとうホワイトボックスの中身だけに着目した作業と言える。また、プログラムの成長に伴い、随時（常時）、実施していくものなので、必然的に反復作業となる。

従って、外観の振る舞いを変えずにソースコード修正を繰り返すリファクタリングという作業に当たっては、自動化ホワイトボックステストである UnitTest が最適なプラクティスということになる。FunctionalTest でも結果的に「意図しない動作」を検出できないでもないが、直接性において UnitTest に比べて劣る。

ちなみに、そもそも JUnit を用いた UnitTest が広く一般に認知されたのは、ファウラーのリファクタ本で紹介されたのが契機だったりするので、歴史的にも UnitTest はリファクタリングと密接に関連付けられたプラクティスだと言える。（JUnit を使う事が UnitTest であるとは必ずしも言えないが）。

以上、コーディング生産性向上と UnitTest の関係についてだいたい説明したが、振り返ってまとめると、以下のようになる。

UnitTest を充分書く
↓
リファクタリングの生産性が高まる
↓
内部品質が向上する
↓
短い時間で正しいコーディングが簡単にできるようになってくる

これは、以下のように逆に書くこともできる

UnitTest を書かない
↓
リファクタリングできない
↓
内部品質が低下する
↓
頭をかきむしりながら長時間かけてるのにバギーなコード

====
実際の現場では、逆に書いた版のプロジェクトが、未だに多いんだよなあ。

UnitTest をしないからリファクタできないパターンと、リファクタリングをしない（或いはそもそも知らない）から、UnitTestの必要性が分からないってパターンの両方考えられるが、どっちにしても低レベルすぎる。

といったわけで、内部品質の劣悪なソースコードと UnitTest の不履行との間には高い相関があるわけだけど、内部品質だけじゃなく外部品質、つまりバグやらパフォーマンス劣化やらにも巡り巡って因果関係が及んでいたりする。
そのうちこれも書こうと思う。

なぜ UnitTest が必要か

2011-06-11T06:54:00.003+09:00

以前、2種類の品質、製品品質とコード品質について対比した。
また FunctionalTest と UnitTest についても違いを比べた。

前回は、製品品質の保証のためには、FunctionalTest が必要であることを説明したが、それらを踏まえて、今回は UnitTest の必要性とは何かを、考えてみる。

=＝＝＝
UnitTest を書く理由、得られる効用について考えると、テストって語が含まれてるぐらいだから、品質向上のためじゃなかろうかと最初は思う。

でも違う。仕様通りに動くかどうかといった製品品質（外部品質）の検証なら、前回書いたように、UnitTest ではなく FunctionalTest の出番になる。また製品品質ではなくソースコード品質（内部品質）の検証だとしても、静的チェックツールがふさわしい。どちらの意味の品質についても、UnitTest の出番ではない。

品質じゃないとしたら、何だろう。UnitTest といえば、自動化テストなわけだから、つまり生産性向上？

うん、生産性の向上である事は間違ってなさそうだけど、でも何の生産性か。ソフトウェア開発にはいろんな作業が含まれるが・・・

ならば、直訳で「単体テスト」だから、単体テストの生産性の向上？

うーん、いわゆる「単体テスト」、つまり旧来のウォーターフォール・モデルで言うような、「一個のモジュールが、後工程の結合テストを実施するに足る品質を満たしているかどうか検証する作業」という意味なら、やっぱり違ってるだろう。

「単体→結合」の観点で見た場合に、そこで単体に要求されている品質は、単体レベルの機能要求がブラックボックス的にで満たされていればそれで良い訳で、これを検証するのは FunctionalTest という事になる。繰り返しになるが、UnitTest は品質（機能・非機能要求の充足）、つまり"doing the right things"は検証しない。

単体テストじゃないし、設計でもなさそうだし、そんじゃ、コーディングの生産性か・・・

まあ、結局そういうことになる。

がしかし、そもそもテストを書くという追加作業をしてるのに、生産性が上がるのはなぜだろう。それにコーディングといってもいろいろあるし、どの局面の何のコーディングだろう。

====
長くなったので、次に続く。

FunctionalTest の必要性

2011-06-08T03:19:00.007+09:00

以前、 UnitTest と FunctionalTest との違いについて、「コードが正しく書かれている事」のテストと、「コードが正しく動いている事」のテストとして対比した。

今日は、前者の FunctionalTest について例を上げて説明し、その必要性について考えてみる。

例えば、こんな問いがあるとする。

数字を受け取って平方根を返すプログラムを書いた。
ところが、平方根ではなくて二乗が返されるというバグが出た。
さて、どんなテストを書いておけば、これを防げたか。

最近 xUnit や TDD を始めたばかりの人なら、「xUnit で UnitTest を書いてカバレッジを 100%にしておけばよかったんじゃない？」なんて考えるかも知れない。

だけど、xUnit の実践経験がそこそこある人なら、それじゃ十分ではないとすぐ分かると思う。

これが単なるコーディングミス、つまり「正しく仕様を理解した上でのコードの書き間違い」によってのみ起因するバグならば、例えば 4 から 2が得られる事を確かめるアサーションがテストコード中にあるはずなので、誤りはすぐに検出される。この場合は、上の答えでもあながち間違いではない。

ところが、同じバグは単なるコーディングミスによるのではなく、「誤った仕様理解の下での意図通りのコーディング」によっても生じてくる。

例えば何かの拍子で、プログラマが平方根と二乗を勘違いして取り違えていた場合、本体コードに二乗の計算が書かれるのみならず、テストコードにも 4 から16を返すアサーションが書かれてしまうので、バグは検出されない。

平方根と二乗の勘違いなんて何だか馬鹿馬鹿しい例だが、実際のシステム開発のドメイン（問題領域）は、普通はもっと複雑だから、こうした認識ズレがバグの原因に占める割合は非常に多い。（また、上のような概念Aと概念Bの取り違えの他にも、仕様の見落としや失念、変更の連絡ミスなど、様々な事が認識ズレの原因になる。）

一般に、「要求されている仕様」と「実装者の認識」のズレから生じたバグは、テストコードにも同じ誤認を織り込んで書かれてしまっているため、本体のコーディングと連動して生産された UnitTest によっては検出できない。

この種のバクを防ぐためには、仕様を理解し責任を持っている人が作業に介在しなければならない。

仕様担当者がプログラマが書いたテスト仕様書をレビューしたり、仕様担当者自身がテスト仕様書を作ったりといった形で、「わかってる人」の意識をくぐり抜ける必要がある。上の例では、「平方根を返す」という要件を定義した人が、テスト仕様書に「4 ならば 2」という「条件 ---> 結果」のペアが含まれている事を確認していなければならない。

つまり最初の問いの答案としては、仕様が分かっている人にレビューされた仕様ベースのテスト、つまり FunctionalTest が必要ということになる。

（ちなみに、テスト仕様書の作成はコーディング前でも良いし、またテスト実施に自動化ツールを使ってもいい。ただし、ソースコードベースの DeveloperTestとは視点が全然違うことに注意する必要がある。例えば、網羅率はコードカバレッジではなく、仕様から起こしたテスト項目の実施率となる。）

=＝＝＝
といったような事は実はかなり基本的な事項なんだけど、かなり多くの底辺現場では理解されていない。で、「コードカバレッジが100%に近づいているのにバグが減らない。って事は、xUnitや TDD は役に立たないって事になるんじゃね？」なんて、アホな論理がまかり通るようになる。やれやれ…

Hadoop

2011-05-31T02:43:00.003+09:00

今日、初対面の技術者との会話の中で、ハドゥープという単語が出てきた。最初よく聞き取れず、「はぁ？ハヌですか？ハドブ？」なんて聞き返してしまった。恥ずかしい。

帰宅して、ヤマ勘で Hadoop とタイプしてググってみると、ちゃんとスペルが合ってたらしく、それっぽいのがたくさん引っかかってくる。その中に、Apache Hadoop とかいうのがある。うん、なんか知らないけどこれだろ、これ。

つうか、どこの馬の骨とも知れないマイナー製品かと思ったら、れっきとした ASF の Top Level Project らしい。YouTubeでも、たくさん動画がある。
※ちなみに、「ハデュープ（敢えて五十音にマッピングすると）」って感じで発音してる欧米人も多い。
簡単に言うと、分散コンピューティング環境上で稼働する大量データ処理フレームワークで、分散ファイルシステム、分散DB、MapReduce の Java 実装なんかが含まれているらしい。Google の既存製品やプログラミングモデルに影響を受けているとの事。

下の動画が、紹介レベルとしては能くまとまってる感じ。（ただし音声は滅茶苦茶に酷いが）

しかし、こんな有名で面白そうなのを知らなかったのか、俺…。

まあ 2年以上、仕事としては Java から離れていたわけだけど、
うーん、やっぱブランクかなあ…

ユビキタス言語のベースの言語

2011-05-29T02:58:00.005+09:00

ドメイン駆動開発（DDD）を謳っている開発案件が、なんだか最近出始めてきたらしい。今日は、このDDDの中での最重要プラクティスのうちの一つである「ユビキタス言語」について思案してみる。

ちょうど一年くらい前、日本のソフトウェア開発現場でも、せめてユースケースだけでも英語化されるといいなあ、という思いを書いた。そこで、「ほとんどの日本の現場では、日本語による要件定義と英語ベースの実装作業との間のどこかに日本語⇔英語のギャップが横たわっていて、これがオブジェクト指向開発の効果的な流れを阻害しているが、要件定義側、特にユースケースの段階で英語化してしまえば、この不経済がかなり解消できると思われる」という事を述べた。

個人的には英語→日本語のギャップが、実はかなり昔から、オブジェクト指向分析やドメイン・モデリングの普及や実施において大きな阻害要因になっていたのではないかと常々思っていたが、意外と取り沙汰される事がない。必然的に問題として認識しようもない英語圏ならばともかく、日本の開発現場では、一応気にはなっている技術者もきっと少なくないはずなんだけど。

さて DDD においては、業務の世界と開発の世界の狭間に、ユビキタス言語---つまりドメイン専門家とのコミュニケーションにおいても、プログラミング言語を用いたコーディングにおいても、常に一貫して使用する事を求められる共通言語---が策定される事になっていて、これが肝だったりする。

で自分が思うに、このユビキタス言語についても、ユースケースと同じ理屈で英語ベースにしてしまってはどうかと。

この英語ベースのユビキタス言語の語彙を用いて、クライアントや業務SEと対話し、ドメインモデルの各要素に名前を与え、プログラム中のクラスやメソッドに識別子を与えるようにすれば、無駄なギャップが解消され、少なくとも英語圏ではほぼ自動的に実現されるレベルの一貫性・直接性に、ちょっとは近づけるのではないかと思う。※1

もちろん、言語の差異の吸収という非英語圏特有の負担を押し付けられてしまっているわけだから、Eric Evans らが考えるオリジナルのユビキタス言語からはちょっと変質してしまうかもしれない。英語の使用により、業務屋にとってもプログラマにとっても、多かれ少なかれユビキタス言語の「難易度」は高まるとは思う。

それでもやっぱり、開発工程全体のどこかで必ず生じるこのギャップを、結局はどこかで吸収せざるを得ないならば、開発序盤、あるいは「上流工程」で英語化してしまうのが一番経済的って気がする。

もちろん顧客によっても、事情は大きく変わるに違いない。社内公用語を英語にするような動きのある顧客では、さして抵抗も強くないはず（楽天だけじゃなく、最近は結構増えてきている）。逆に、余りにも一般教養レベルが低いような層の顧客だと、ワンクッションとしての業務SEを置いて、英和変換させるなどの策を講じないと難しいかもしれない。

あと、単なるユースケースの英語化と違って、ユビキタス言語の場合は文書だけじゃなく会話でも使うだろうから、カタカナ英語を日本語の助詞や助動詞でくっつけたような変な会議風景が現出するかもしれない（完全英語化すれば別だけど）。

まあ、日本語と英語のどちらをユビキタス言語のベースに採用するにせよ、「どっちを選んだときに、どんな作業や問題が発生するか（DDD関連の洋書には普通書かれていない）」について、予めよくよく考えておく事が、DDD導入にあたっては大きなポイントになってくるんじゃないだろうか。

====
※1 あまりにも無学なPGばかりが集まる底辺プロジェクトだと、JavaやC＃等の高水準OOPLが英語ベースであることすら認識されていない事が多い。彼らにとってはプログラミング・コードなんて、記号の羅列としか認識されていないから、そもそもドメインの語彙とか分析とか殆ど関係ない。従ってもちろん DDD も大して意味が無い。

FedoraCore12 + JBoss6.0 + Helios

2011-05-28T01:02:00.002+09:00

久しぶりにJava案件をやることになりそうなので、自宅環境を準備。だいぶ前に FedoraCore12 を入れたマシンがあったので、これを使うことにする。

FedoraCoreメニューの「ソフトウェアの追加と削除」に Eclipseがあったのでインストールしてみたが、これは一世代前の Galileo だったので、アンインストールして Helios を入れ直すことにした。と言っても、Eclipse 本家サイトから java EE開発用のバイナリを落として、単に /usr/local/eclipse/下に展開しただけで、特に難しい作業は無し。

で、一応Webアプリという事で、アプリケーションサーバが必要になるが、とりあえず JBoss の6.0 を入れることにした。JBossサイトのインストールの説明に従ってしばし簡単な作業をしてから、run.sh で起動して正しくインストールされ起動する事を、ログとブラウザで確認。

次に Eclipse との連携を準備。Eclipse の Servers ビューで新規追加しようとしたら、Server Adapter が JBoss5.0 までしかなくて一瞬戸惑ったが、JBoss5.0 のアダプタでも問題なくJBoss６.0を動かせるという話があったので、とりあえず信用してJBoss5.0でサーバを追加。ところが、起動してみるとrun.sh からの起動では出ていなかった例外がスタックトレースされている。

20:56:53,101 ERROR [AbstractKernelController] Error installing to Instantiated: name=PostEjbJarMetadataDeployer state=Described: java.lang.NoSuchMethodError: javax.annotation.Resource.lookup()Ljava/lang/String;
    at org.jboss.metadata.annotation.creator.AbstractResourceProcessor.createResourceEnvRef(AbstractResourceProcessor.java:394) [:2.0.0.Alpha24]
    at org.jboss.metadata.annotation.creator.AbstractResourceProcessor.process(AbstractResourceProcessor.java:237) [:2.0.0.Alpha24]
…略

ググってみると、同じ現象についてとあるサイトで議論されていた。これを参考にプラグインのjar（JBoss 6.0 対応の Server adapterらしい）をダウンロードして（ここから）eclipse/plugin下に展開。さっき作った JBossサーバを一旦削除してからEclipseを再起動し、再び Server ビューから新規作成を始めると、今度はJBoss6.0が選択肢に含まれている。これを指定して再作成。

おもむろにスタートボタンを押すと今度はエラー無しに起動する。念のため、適当に Dynamic Web Application を作成し、適当なtest.jsp を追加してデプロイ。ちゃんと表示される事を確認。

とりあえず、準備できた。

Test Double の「Double」とは

2011-02-01T21:11:00.004+09:00

プログラマにとって「double」と言えば、まず第一に倍精度浮動小数点数のことだろうけど、Test Double の「double」はどうか。

昨今の開発で、まともにテスト駆動が成立するレベルのテストコード、つまり TestSmell が一定以下に抑制された DeveloperTest を書いていくためには、かなり多くの場面で Test Double パターンが必要になる。今日びのプログラマにとっては、Stub、Mock、Fake、Spy 等を含む Test Double と言われる一群のテストパターンを自在に使いこなす事は、必須技術の一つと言えるんじゃないかと思う。

個人的な話になるが、実は自分は、この Double の意味を知らないまま、長い間「Test Double」という言葉を使っていた。深く考える訳でもなく、何となく「Test」を動詞、「Double」を副詞と認識して「二重にテストする」なんて意味かなと思っていたが、TestDouble が意味する手法と一致しなくて、ずっと気持ち悪かった。

ある時、何気なくネットの辞書を引いてみたら、ちゃんと答えがあった。

Weblio の英和辞書ではこんな感じ

【名詞】3.b【映画】
代役，替え玉 〔for〕.

英英辞書の OALD ではこんな感じ

NOUN PERSON/THING [countable] 
 an actor who replaces another actor in a film/movie 
 to do dangerous or other special things

まず、Double を副詞と考えていたのが、そもそも間違いで、本当は映画用語の名詞。Double が副詞でないということは「Test」は動詞ではありえず、したがって「Test Double」で名詞+名詞の複合名詞、つまり「テストの替え玉」という意味になる。

やっぱ辞書はこまめに引かないといかんな。

※OALD は非英語ネイティブ向けの英英辞書としては、かなり良い感じ。ネット版だけじゃなく、リアルの辞書もよくできてる。

底辺プロジェクトの DoNotCatchGeneralExceptionTypes

2011-02-01T04:18:00.003+09:00

前回普通で当たり前な例外処理コーディングについて書いたとき、同様のやり方が FxCop の開発者のブログ記事でも推奨されている事に触れた。実は、その記事の本来の趣旨は、例外を基底クラスの Exception型で catch しようとする無知な輩を啓蒙するというものだった。

今回は、その事について考えてみる。ちょっとクドクドとネチっこく考えてみる。

＊以下、いちいち「例外を基底クラスの Exception型で catch する」と書くのは面倒なので「基底キャッチ」と呼ぶ。

=＝＝＝
その記事で、件の開発者は以下のように告白している。

There are actually far too many catch (Exception) blocks in FxCop itself and it has caused us a great deal of grief. We’re working on removing them and I’m confident it will help us to deliver better software!

「実は、FxCop のソース自体に基底キャッチが濫用されていて酷い目にあったが、それを取り除いていくことで結局良いソフトウェアになった」と言う話。で、その教訓を踏まえて、基底キャッチがいかにダメな事なのか、基底キャッチ容認派への反論も交えて詳説している。

当の FxCop 開発者がそんな真似をしていたなんて意外だが、記事自体がもう4年半も前のものである事を考えると、相当に古い昔話なんだろうし、まあそんなものかと。でも、この記事やその他の同内容の言説のおかげで、基底キャッチが是か非かなんて問題を今さら蒸し返すような人は、少なくとも英語圏には少ないんじゃないかと思う。

====
ところが、未だに日本の底辺プロジェクトでは、基底キャッチで例外をもみ消して、「臭い物に蓋」よろしく無かった事にしてしまう手法が、当たり前のように日夜実践されている。しかも「教科書通りに行かないプロの現場で禁じ手を使いこなしてる俺って、やっぱプロだぜ！」てな感じで、一部の底辺プログラマが得意気な感じだったりもする。

そんなドン底の世界では、こんな事がもっともらしく力説される。

「うちのアプリは何があっても落とさないポリシーだから、どんな例外だろうとスルーは容認できない。防止も予測もできず、従って対処法の分からない未知の例外もあるだろうが、そう言うのはもみ消してでも続行させるしか手はない。それがうちの流儀なんだから仕方がない。」

で、全ての例外を漏らさないために、基底キャッチが導入されるというわけだが、まずそもそも、そんな想定外で正体不明な例外をもみ消したあと、アプリがまともに動くってどうして保証するんだろう？ DBに不正データを作ったり、誰かの給料を間違って計算したり、外部のサービスに不正なリクエストを送ったりしないと言えるのかと。そんなの技術以前に、論理的に矛盾してるし、言える訳がない。

そもそも顧客は何て言ってるんだろう。「Null参照でアプリが落ちると嫌だから、取引先の公開サービスに不正リクエストを送っても良いから、動作続行させてください」なんて、言った人がいるんだろうか。でなければ、実行を続ける事で不測の重大事態が起きないと限らない事を伏せたまま、うちのアプリは落ちませんとだけ、顧客に説明している事になるわけで、それこそ大問題のはず。

====
エンドユーザの使用中には自分のアプリは落ちてほしくない。落ちるのは嫌だ。落ちるべきでない。それに敢えて異議を唱える訳ではない。が、だからと言ってアプリの誤動作の方がマシと言う事にもならない。だとしたら、いかに未知の例外によりアプリが停止する状況を極少化していくか、それしかないはず。

もうほとんど結論が出ているが、その前にもう少しだけ底辺プログラマの声に耳を傾けてみると、たいていこんな事を言っている。「発生し得る全ての例外の型をキャッチしていたら、いくつ catch ブロックがあっても足りない。現実的でない。」

この主張の駄目な点を指摘すると、以下の2つになる。

第一に、キャッチすべき例外が何か分かっていない。前回書いたフツーの例外処理の作法を分かっていれば、「全ての例外を…」なんて発想にはならない。発生の条件が既知であり、対象法がわかっている例外だけがキャッチする意味がある訳で、それ以外はキャッチせずにスルーしろと言っている。

第二は、第一のダメな点の原因でもあるのだが、やはりこれも「アプリを停止させるくらいなら、もみ消してしまいたい」という強迫観念に憑かれているという点。「アプリは停止できない」 → 「どんな例外もスルーできない」 → 「例外は須くキャッチすべき」という思考パターンだが、これが間違っているのは上で説明した。

予見できて対処できるものをキャッチするという、これこそ正に現実的としか言えない話しか、最初から誰もしていない。

====
これだけ言っても、まだ次のような言い分で食い下がる人もいる。

「そんな風に例外をスルーしてばかりいたら、その度にアプリが停止して、顧客がいちいち再起動する状況が頻発するから大問題になる。」

そんなの、例外とか catch の作法以前に、単に納品できる品質に至っていないという馬鹿な話でしかないんだが、実はこの辺りに問題の本質がある。

つまり、スルーした場合のアプリ停止にしても、もみ消した場合の不正動作にしても、それらは結果として出てきた現象なのでって、まず先んじて発生した未知の例外状況が、そもそもの原因としてある。

で、この「想定漏れ」や「考慮漏れ」、「テストから漏れたコーディングミス」などを含む原因側に働きかける事こそが、抜本対応と言えるわけだが、正にここにおいて、「例外スルー」と「例外もみ消し」は決定的に正反対の効果を見せてくる。

潔く例外をスルーする事は、結果としてアプリを落とす事になっても、結局は未知の例外状況の発生を減らしていく事になる。理由は、開発中に発見しやすく、従って現行犯的に処置できるため、もっとも効率がいいから。

一方、例外をもみ消す事とは、潜在バグを温存し溜め込んでいく行為に他ならない。健全な開発作業に当然含まれるはずの、意図しなかったのコードや想定から漏れていた条件を発見し、意図通りに直したり想定内に置き直していく営みが台無しになる。せっかく開発中に潰せたかもしれない未知の挙動を握りつぶして、客先まで不安定要因を持ち込んでしまっているわけだから、救いようがない。

かなりの極論になるが、突き詰めると、こういう選択になる。

数年に一回、未知の例外により停止するものの、その他は誤動作もない安定したアプリと、停止だけはしないが、年中不安定な動作を続けながら、しばしば深刻な誤動作をしでかし、しかもその障害解析が極めて困難なアプリとで、どちらが良いか？

使う側にとっても、作る側にとっても、どちらにとっても答えは決まってると思うんだが。

====
まあ、普通のプログラマは、分かり切った事なのに、ずいぶんくどいなあと思うかもしれない。自分だって「例外のもみ消しは、結局は品質落とすよね。」の一言で済む話だと、正直思ってた。そうした普通の感覚が成立しないどん底プロジェクトにいつ巻き込まれるか分からないから不景気って恐ろしい。

※ 私見だが、最初から checked と unchecked が峻別される Java の業界では比較的少なく、どちらかというと.NET 業界に多く見られる気がする。

C＃での例外処理コードの基本

2011-01-30T15:20:00.002+09:00

C＃コーディングで例外をどう扱うか。

普通はこうなる。

<A.防止可能か？>
  ├─(yes)─→ [B.防止するコードを書く]
 (no)
  └→<C.予見可能か？>
       ├─(yes)─→ [D. catch して処理するコードを書く]
      (no)
        ↓
     [E. スルー]

A. 防止可能か？
例えば、「パラメータで null を渡されたら ArgumentNullException を投げる」ってドキュメントに書いてあったり、ソースコード上自明もの（バグも含む）だったり、例外発生の条件が分かっていて、そうならないようなコードを書ける場合は、防止可能と言う事になる。

B.防止するコード
A を満たす場合に、例外を発生させないようにコーディングする。

C.予見可能か？
防止できず、つまり実行するまで分からないが、状況によっては発生する事が分かっている例外状況を、「予見可能である」とする。例えば、ファイルを開くときの FileNotFoundException など。

D. catch して処理するコード
C で可能性が認められた例外については、catch してハンドリングするコードを書く。

E. スルー
防止も予見もできないものについては、復旧処理のしようも無いので、無理にアプリを動かし続けて誤動作による事態悪化を招くより、スルーしてアプリが停止するに任せる。書いてもせいぜい、AppDomain の UnhandleException イベントくらい。

この手順は、以下の URL で FxCop の開発者が詳説していたりもする。
http://blogs.msdn.com/b/codeanalysis/archive/2006/06/14/631923.aspx

まあ、普通のプログラマにとっては、いつも実践している通りの、言われるまでもない当たり前のコーディングじゃないだろうか。今更感満載で、「他にやり様あったっけ？ないでしょ？」てな感じになっちゃうと思う。

で、これを踏まえた上で、例えば、メソッドの API リファレンスに例外が沢山書いてあったらどうしようとか、catch 節もちゃんとテストしましょうだとか、finally を活用しましょうとか、いろいろな細かい事が生じてくる。

====
というのが、普通に計算機科学を勉強して、普通にプログラミングを習得して、普通にC＃を書いてる人の自然なコーディングプラクティスだと思うのだけど、底辺プロジェクトでは、この基本フローの段階で物言いがつく事がある。

曰く
「うちのアプリは何があっても落とさないポリシーだから、E のスルーは容認できない。未知の例外はもみ消して無かった事にするのが我々の流儀である。」と。

・・・いや、それ、マジで言ってんのかと。

次は、これについて考えてみる。

パターンカタログの私的ランキング（TOP 20）

2011-01-29T17:06:00.003+09:00

1位から10位までは前回書いた、独断と偏見によるパターンのランキングを、20位まで続けてみる。

1位 GOFのパターン (100.0)
2位 PoEAA (89.6)
3位 Effective Java (86.4)
4位 CodeSmell (85.3)
5位 xUnitパターン (82.8)
6位アンチパターン (81.3)
7位 POSA (79.1)
8位 Effective C# (77.9)
9位アナパタ (69.5)
10位 Enterprise Integration Patterns (67.7)

11位 Implementation Patterns
ベックの smalltalk イディオムの古典 SBPP をベースに、言語を Java に代えて内容を調整したもの。個人的にはもっと普及しても良いと思うのだが。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
4	2	3	3	4	67.4

12位 Portland Pattern Repository / Wiki Wiki Web
元祖 wikiwikiサイト。カタログとしてはイマイチ使いにくいが、有名人たちの過去の議論が読めたりして、意外とおもしろい。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
2	4	1	5	4	64.9

13位『パターン言語』
PLoP のパターンの選集、『プログラムデザインのためのパターン言語』に掲載のパターン。ここでも挙げている他のパターン集に含まれているものが多い。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
2	2	5	4	2	64.1

14位 Patterns for Effective Usecases
同名の書籍より。ユースケース・ライティングの記念碑的傑作『Writing Effective Use Cases』に書いてある内容の焼き直しがほとんどだが、パターン仕立てになっているのが良い。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
4	2	4	1	2	63.5

15位 SOA Patterns
ネットで見られる良質な SOA のパターン集だが、不勉強にも、最近まで気づかなかった。これはいい感じ。 → [URL]

実用度	有名度	使い勝手	教養度	面白さ	ポイント
3	3	4	2	3	63.4

16位 Core J2EE Patterns
Java EE x が J2EE だった昔のエンタープライズ・アプリのパターン集。今、読み返しても、意外と古くさい感じはしない。→[URL]

実用度	有名度	使い勝手	教養度	面白さ	ポイント
2	4	4	3	2	63.4

17位 Patterns for Test-Driven Development
ベックの傑作『Test-Driven Development』の PART３。TDD のためのパターン集が収められている。

これに限らずベックのパターン集は、パターンやプラクティスや単なる基本用語が、境界がよくわからないまま並列に解説されていて、カタログとしてはどうかと思うが、不思議と違和感無く読めて面白い。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
4	3	2	2	3	63.1

18位コプリエンのイディオム本
イディオム・カタログの発祥とも言われている『C++プログラミングの筋と定石』より。かなり古い本だが、これにもアンチ・イディオムが載っていて、当時の書評でもこれが重要って事で指摘されていた。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
2	4	2	4	3	61.7

19位 Workflow Patterns
workflowpatterns.comで紹介されている、ワークフローのパターン。通常、パターンというと問題に対する解の事を指すが、これはどちらかというと解というより問題の方の定形って感じ。このうちの基本的なパターンは BPM の試験でも問われる。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
2	3	4	2	4	61.6

20位 Data Model Patterns
アナパタでも参照されている分析レベルのモデリングの古典、『Data Model Patterns: Conventions of Thought』より。アナパタ同様、これも図法がとっつきにくいが、自分でUMLなどを使って分かり易い図に起こすと理解が進む。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
3	2	3	3	3	59.3

★ ついてでに20位圏外

『Smalltalk Best Practice Patterns』 (58.2)
言わずと知れた smalltalk イディオムの古典的名著。いろんな記事とか本とかから引用されていて教養的価値が高いけど、差し当たり仕事では smalltalk を使わない事もあり圏外。

Enterprise Solution Patterns (57.8)
ちょっと古いが、良く体系化されている。なのに何故かイライラする。理由は不明→[URL]

Effective C++ (55.7)
『Effective C++: 55 Specific Ways to Improve Your Programs and Designs』
Effective ナントカの C++版。最近、C++の案件やってないなあ・・・

Ajax パターン (53.7)
『Ajax Design Patterns』
文字通りAjax のパターン。Ajax そのものの勉強にもなる。

J２EEアンチパターン (46.8)
『J2EEアンチパターン』
この手のパターンは陳腐化しやすい。

EJB Design Patterns (45.1)
『EJB Design Patterns: Advanced Patterns, Processes, and Idioms』
これも Java の EoD 運動以前のものだから、さすがに古い。

EJBアンチパターン (44.6)
『EJBアンチパターン』
これも EJB Design Patterns と同様古い。

AOPパターン（43.3）
『Aspectj in Action』に掲載されている AOPパターンと AspectJイディオム。そこそこ面白いが、まだ数も少なく未成熟。

以上、「物」と「事」でいうと、「物」的なパターンを特に選び、「事」性が強いリファクタリングやプラクティスは入れないことにした。

今回のは洒落で作った私的な順位だけど、工夫すればもっと客観的な点数付けができると思う。そうしたらスキル評価の尺度として、開発要員のアサインや調達の際に、ちょっと使えるかも。

つうか底辺プロジェクトでは、GoF すら覚束ない人が多数派なので、切なくなってくるが・・・

パターンカタログの私的ランキング（TOP１０）

2011-01-29T03:31:00.006+09:00

パターン・カタログ＝GoFのデザパタだと思ってる人をたまに見かけるが、実は結構、他にもたくさんある。

以下、勝手に作ったパターンカタログのランキング。飽くまでも私的で主観的な尺度でポイントを付けた。

1位 GOFのデザパタ
言わずと知れたデザインパターンのバイブル、『オブジェクト指向における再利用のためのデザインパターン』掲載されている、２３のパターン。まずはこれが基本かと。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
5	5	5	5	5	100.0

2位 PoEAA
『エンタープライズアプリケーションアーキテクチャパターン』に掲載されている、いわゆる PoEAA （Patterns Patterns of Enterprise Application Architecture）。2000年代初頭までのオブジェクト指向システム開発の流れを総括した上で、現在に至るその後の展望を示したパターンの金字塔。さすがに、もうそろそろ、若干の陳腐化が見られなくもないが。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
4	5	4	5	5	89.6

3位 Effective Java
『Effective Java (2nd Edition)』掲載の Javaコーディングイディオム。Java プログラマは必携・必読かと。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
5	5	3	3	5	86.4

4位 CodeSmell
ファウラーの『リファクタリング本』に載っているアンチパターン。リファクタリング手法そのものより、むしろこっちの方が重要だと思う。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
5	4	3	4	5	85.3

4位 xUnitパターン
『xUnit Test Patterns』で紹介されている UnitTesting のパターン。XUnitPatterns.comでも閲覧可能。これもアンチパターンの部分が重要。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
5	4	3	4	4	82.8

6位アンチパターン
『AntiPatterns』掲載の、定番のアンチパターン集。ちょっと古いが、コーディングや設計に止まらず、プロジェクト管理などにも渡る広めのスコープをカバー。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
3	4	5	5	4	81.3

6位 POSA
ブッシュマンの『POSA本』(Pattern Oriented Software Architecture)に載ってる、アーキテクチャパターンの古典。1巻しか和訳されていないので余り知られていないが、２巻も３巻もある。いや、確か５巻くらいまであったかもしれない。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
3	4	5	5	3	79.1

8位 Effective C#
『Effective C#』と『More Effective C#』に掲載の C#のイディオム。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
5	4	3	2	4	77.9

9位アナパタ
ファウラーによる分析レベルのパターン集の古典『アナリシスパターン』。モデルの図法が若干とっつきにくい。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
2	4	2	5	5	69.5

10位 Enterprise Integration Patterns
『Enterprise Integration Patterns』掲載のパターン。意外と知られていないが、ここで導入された図法、グレゴールグラムも含めて、EI 界隈では金字塔と言われるパターン集。SOA、ESBをやる人はほぼ必須知識に近いかと。

実用度	有名度	使い勝手	教養度	面白さ	ポイント
3	3	4	3	4	67.7

→TOP20へ

====
★ 補足
上記のとおり、五つの評価軸について5段階評価して、ポイントに集計してランクをつけてみた。

・実用度は、仕事で役に立つかという観点。個人的な職歴によるバイアスがかかっている。したがって、仕事では使わない smalltalk や最近現場では使っていないC++に関連するものは、点が低かったりする。

・有名度は、各種の記事や著作から引用されてているのを目にしたり、同僚との会話の中に出てくる事が多いもの。これももちろん私的な環境に依存する。

・使い勝手は、主にカタログとしての質。書式・体裁や、粒度、識別し易さなど。またダイアグラムやサンプルコード、パターン間のナビゲーションなども。

・教養度は、他のパターンが前提的な知識として要求していたり、このパターンを知っていると他のパターンを理解し易いというもの。

・面白さは、文字通り面白いという事。知的好奇心を刺激されたり、可能性が開けていく感覚があったり、思わぬ気付きがあって興奮したりとか、そういうやつ。

評価軸自体にも、実用度に５点、有名度に３点、使い勝手に３点、教養度に２点、面白さに１点と言うように重みを付けた。

点の集計は、一応技術者らしくフィボナッチスケールを応用してみた。１～５の点数をフィボナッチをもとにした数列｛21, 27, 34, 44, 55｝に変換して総合点を集計し、オール５だったときに100になるように調整した。

ソフトウェア品質の対概念

2011-01-27T00:28:00.005+09:00

プロがで自分の職能分野の事柄を wikipedia で調べる事となると、何となく気恥ずかしさを感じないでもないが、たまに良い事が書いてあってちょっと嬉しい時がある。

「ソフトウェア品質（Software_quality）」で調べると、ちゃんと「ソフトウェア製品品質（Software_product_quality）」と「ソースコード品質(Source_code_quality)」に分けて書いてあった。

ソフトウェアに関しては、一般的な意味での品質ーーーつまり「日本の精密機械の品質は・・・」なんて言うときの「品質」とは別の、もう一つの品質があるという事が、実はわりと普通の考え方なのだという証言が一つ得られた事になり、少しほっとした。更に少し調べると、ISO/IEC 9126-1:2001でも「内部品質」という形で定義されているらしい。不勉強だった。

とは言っても、この二つの品質が互いに異なる別物だという考え方は、まだソフトウェア開発業界で常識となるには至っていないように見える。

開発中の製品の品質について会議なんかで議論すると、こっちが後者の意味で話しているのに、しかも、どういう意味での「品質」か、ちゃんと前置きしてから語っているはずなのに、いつの間にか前者の話に流れて行ったりする。終いには「”品質”の話をしてるんだから、コードとか関係なくね？」みたいに返してくるから、こっちも「だ～か～ら～」みたいになってくる。

大雑把に言うと、製品品質は売上に関わり、ソースコード品質は費用に関わる。つまり、製品品質は使う側の生産性を左右し、ソースコード品質は作る側の生産性を左右する。あるいは、製品品質の問題は消費者側で顕在化し、ソースコード品質の問題は生産者側で顕在化するとも言える。

ある意味正反対の概念が、「品質向上」などと言ったスローガンの下で一緒くたに扱われるから、品質管理会議が何だか噛み合わない。いっそ別の言葉でもあれば良いんだけど、日本語でも英語でも適切な言葉が見当たらない。

「今話している「品質」はソースコード品質の意味での「品質」なわけで、つまり（略）」みたいな面倒くさい断りを入れずに済む状況は、当分なくなりそうにない。

リファクタリングの因果ループ

2011-01-26T00:14:00.002+09:00

リファクタリングの効果をシステム・シンキングで考えてみる

まず、もっとも近視眼的に原因 → 結果を考えるとこうなる。

＋記号は、原因側の増加・強化が、結果側にプラスの効果をもたらす事を意味する。反対に、原因側の減少・弱化は、結果側にマイナスの効果を与える。－記号ならば、原因側の増加・強化が、結果側にとってのマイナスとなる。

つまり、上図ではリファクタリングの実施が開発工数の増加をもたらす事を表している。逆に言うと、重複やらスパゲティコードやらの放置も、直接的には工数を減少させるとも言っている。

これに、「ソースの体質」（ソースコードの読み易さ、書き易さ、使い易さ）と開発作業における「余裕」を付け加えて、因果関係のループを作ると以下の用になる。

要するに、短期的には工数増加をもたらすリファクタリングが、ループを繰り返すに連れて効力を増して、次第に工数を減少させていく様子を表しているが、これを説明してみたい。

解説のため、二つのループに分けると下図のようになる。

上のループは－が一個（奇数個）なので、バランス・フィードバック・ループになる。

つまり「リファクタする」→「工数増える」→「余裕が減る」→「リファクタさぼる」→「工数減る」→「余裕がでる」→「またリファクタする」→「・・・」という感じで、一周ずつ反転しながら繰り返して、適当な均衡点に落ち着いて行こうとする。

下のループは－が二個（偶数個）なので、拡張フィードバック・ループになる。

この場合、「リファクタする」→「ソースが改善される」→「だんだん工数が減ってくる」→「余裕が出る」→「もっとリファクタする」→「もっとソースが改善される」→「さらに工数が減ってくる」→「・・・」という自己強化的な繰り返しになる。

ただしソースの体質改善が開発工数に影響を与える際、遅延（上図のコンデンサー記号）を生ずるのが一般的なので、ループの勢いは最初は弱い場合が多い。

とは言っても、ループの効果は一方向的に増強されるのみなので、「リファクタ実施 → 工数増加」と言う短期的な効果を、いずれ結局は追い越す事になる。

というのが、システム・シンキングで理屈をつけたリファクタの効果。

※実は、ループによる効果の増加を待てないような使い捨て度の高いシステムでは、リファクタしたところで却って費用対効果が良くない事も、同時に示唆していたりする。

ちなみに、リファクタしない場合の悪循環は、「リファクタさぼる」→「体質悪化」→「じわじわと工数増大」→「余裕が減る」→「リファクタしようにもできない」→「もっと体質悪化」→「さらに工数増大」→ ・・・、と言った感じ。

GUI コードのUnitTest の例

2011-01-25T01:01:00.002+09:00

こんな感じのしょうもないフォームがあるとする。DataGridView があり、A列と B列は数値を入力できる列で、C列は A - B の計算結果を表示する。さて、このフォームには、C列の値が負のとき赤で表示するという振る舞いがあるが、果たしてこれをテスト駆動で書けるだろうか？TDD に慣れた人なら、普通にテストファーストで書くだろうけど、ハナからできないと決め付けてる人も意外と多い。そんな人が考えるテストはこんな感じ。

アプリケーションを起動する。
A列、B列に値を入力する。
C列の前景色が変わったことを確認する。

まあ普通の手動の動作確認と同じだけど、これを自動化テストコードとしては書けないから UnitTest は無理と言う。実際にはそういったテストコードも書けないことはないが、TDD の UnitTest ではそんなのは書く必要ないし、第一、テストの観点も目的も手法も違ってるから、むしろ書いてはいけない。前に書いた HumbleView の作法でやると、例えばこんな風になる。

[TestFixture]
public class Form2PresenterTest
{
    public Form2Presenter presenter;
    public Mock<IForm2> mock;

    [SetUp]
    public void SetUp()
    {
        this.mock = new Mock<IForm2>();
        var view = mock.Object;
        this.presenter = new Form2Presenter(view);
    }
    [Test]
    public void SelectStyle_Plus()
    {
        TestSelectStyle(10, 5, CellStyle.NonNegative);
    }
    [Test]
    public void SelectStyle_Zero()
    {
        TestSelectStyle(10, 10, CellStyle.NonNegative);
    }
    [Test]
    public void SelectStyle_Minus()
    {
        TestSelectStyle(10, 20, CellStyle.Negative);
    }
    public void TestSelectStyle(int a, int b, CellStyle style)
    {
        //arrange
        var rowData = this.presenter.RowDataAt(0);
        rowData.A = a;
        rowData.B = b;
        //act
        this.presenter.Update(0);
        //assert
        mock.Verify(v => v.SetGridStyle(2, 0, style));
    }
}

見ての通り、Update()メソッドで行のインデクス（簡単のため0固定とした）を受け取った Presenter が、更新された A 列とB列の値に基づいてスタイルを選んで、セルの位置とともにビューに返すという流れになる。これを満たす IForm2 と Presenter のコードはこんな感じ

public interface IForm2
{
    //･･･略･･･
    void GridDataSource(List list);
    void SetGridStyle(int col, int row, CellStyle styleId);
}

public class Form2Presenter
{
    //･･･略･･･
    public void Update(int rowIndex)
    {
        var rowData = this.list[rowIndex];
        var cellStyle = rowData.C < 0 ? 
                CellStyle.Negative : CellStyle.NonNegative;

        this.view.SetGridStyle(2, rowIndex, cellStyle);
    }
}

やり方はいくつかあるが、ここでは色を System.Drawing.Color で直接指定する代わりに、列挙値 CellStyle を定めて使っている。この CellStyle 定数と実際にセルに設定する DataGridViewCellStyle オブジェクトのマッピングを保持しておくクラスも別途必要だが、自明なので省略。この辺りまで書くとテストも通る。後は、View と Presenter を関連付けるだけ。

public partial class Form2 : Form, IForm2
{
    //…略…
    private void dataGridView2_CellEndEdit(
        object sender, DataGridViewCellEventArgs e)
    {
        this.presenter.Update(e.RowIndex);
    }
    public void SetGridStyle(int col, int row, CellStyle styleId)
    {
        this.dataGridView2[col, row].Style = CellStyleMap.StyleOf(styleId);
    }
}

前回と同様、View オブジェクト（Form2）は受身で丸投げなクラスで、余りテストの必要性が高くないほんの少量のコードを残して、その他の振る舞いのコードを Presenter に移した。こんな風に、一見いかにも GUI の最表層みたいな振る舞いでも、フォーム＝View を薄く薄くしていく事で、妥当な網羅性を備えた UnitTest が書けるようになる。

CIのプラクティス

2011-01-23T23:50:00.002+09:00

以下、『継続的インテグレーション入門』にのってるプラクティスのメモ

「始めよう」からのプラクティス

変更を起点としてビルドを実行する

「CIの紹介」からのプラクティス

頻繁にコードをコミットする
ビルドできないコードをコミットしない
ビルド失敗を速やかに修復する
開発者テストを自動化する
全てのテストとインスペクションを合格させる
プライベートビルドを実行する
ビルドが失敗したコードを取得しない

「変更を起点としたビルドの実行」からのプラクティス

ビルドを自動化する
コマンド１つでビルドを実行する
ビルドスクリプトをIDEから分離する
ソフトウェア資産を集中化する
一貫したディレクトリ構造を作成する
失敗しやすいビルドプロセスから始める
複数環境へのデプロイに対応する
インテグレーションビルドマシンを使用する
CIサーバを使う
手動インテグレーションビルドを実行する
短時間でビルドを実行する
段階的にビルドを実行する

継続的DBインテグレーションのプラクティス

DBインテグレーションを自動化する
ローカル環境でサンドボックスを使う
バージョン管理リポジトリを使ってDB資産を共有する
開発者にDBを変更する権限を与える
DBAを開発チームの一員にする

継続的テストのプラクティス

単体テストを自動化する
結合テストを自動化する
システムテストを自動化する
機能テストを自動化する
開発者テストを分類する
実行時間が短いテストを先に実行する
不具合に対してテストを書く
結合テストを再実行可能にする
一つのテストケースに一つのアサーションを書く

継続的インスペクションのプラクティス

コードの複雑度を下げる
継続的にデザインレビューを実施する
コード監査による組織標準の維持
コードの複製を減らす
コード網羅率を評価する

継続的デプロイのプラクティス

動作するソフトウェアを常にリリースできるようにする
リポジトリの資産にラベル付けをする
クリーンな環境を構築する
個々のビルドにラベルを付ける
全てのテストを実行する
ビルドフィードバックレポートを作成する
リリースのロールバックを可能にする

継続的フィードバックのプラクティス

継続的フィードバック手段を利用する

GUI コードのUnitTest の基本形

2011-01-23T01:38:00.005+09:00

こんなフォームがあるとする。

ツールボックスからコントロールを持ってきて置いただけの状態だが、これを

右のボタンを押すとメッセージボックスが開いて、OK すると文字列"OK"、Cancel すると文字列"Cancel"が、左のテキストボックスに表示される

ようにしたい。

さて、この作業を TDD でやるとどうなるか。

GUI アプリは UnitTest できないものと考えがちな人は、やはりここでもメッセージボックスに伴うユーザ・インタラクションを理由に UnitTest を諦める。

実は、こういった場合の対処法は割と昔から研究されて、パターンとして広く知られているものも既にいくつかある。

基本的な方針は、最小限のコードを残して、振る舞いに関する責務をテスタビリティの高い別のオブジェクトに移動してしまうというもの。

そうやって、極薄にしたフォーム・コード（UnitTest はオプション）と、振る舞いを含む実質的な UI ロジック（カバレッジ100%）に分けることで UI 層全体としてのコード・カバレッジを満足のいくものにする。

いろいろな変種パターンがあるが、さしあたり以下のように単純に実装してみる。

Form1 = view
- あくまでも受動的に動くフォーム・クラス。
- Presenter の指示により MessageBox を表示するものの、何も考えずに結果を Presenter に返すだけ。
- イベントは Presenter に丸投げする。ただし無駄なパラメータは渡したりしない。また、フォーム上のコントロールのプロパティへのアクセッサを、必要最小限な分だけもつ。
Form1Presenter = presenter
- 次のような UI の振る舞いを担う。
  - View にメッセージボックスを表示させて、結果を受け取る。
  - 受け取った結果に応じた文字列を View に表示させる。

また、Presenter から Form1 へのアクセスは、以下のようなインターフェイスを通じて行う。

public interface IForm1
{
   string ResultText { get; set; }
   bool AskOkOrCancel();
}

※Presenter も interface を実装するような形にもできるが、オプション。

まずは先にテストコードから

[TestFixture]
public class Form1PresenterTest
{
   private Form1Presenter presenter;
   private Mock<IForm1> mock;

   [SetUp]
   public void SetUp()
   {
       this.mock = new Mock<IForm1>();
       this.presenter = new Form1Presenter(mock.Object);
   }
   [Test]
   public void HandleButtonClick_OK()
   {
       TestHandleButtonClick(true, "OK");
   }
   [Test]
   public void HandleButtonClick_Cancel()
   {
       TestHandleButtonClick(false, "Cancel");
   }
   public void TestHandleButtonClick(bool isOk, string resultText)
   {
       //arrange
       mock.Setup(v => v.AskOkOrCancel()).Returns(isOk);
       //act
       presenter.HandleButtonClick();
       //assert
       mock.VerifySet(v => v.ResultText = resultText);
   }
}

※モックはMoqを使った

ビューに聞いてこさせたユーザの意図（isOk）に応じて、期待通りの文字列（resultText）が選択され、ビューに設定されることを検証している。
見ての通り MessegeBox もコントロール･オブジェクトも関係ないコードになっている。
実際には、いっぺんにテスト・コードを書いてしまわないで、ちょこっとテストを書いては本体コードを書くというような形になる。

で、その本体コードは以下

public class Form1Presenter
{
   private readonly IForm1 view;
   public Form1Presenter(IForm1 view)
   {
       this.view = view;
   }
   public void HandleButtonClick()
   {
       this.view.ResultText =
           this.view.AskOkOrCancel() ? "OK": "Cancel";
   }
}

ここまで書けば取りあえずテストが通る。あと残ったのは、放置していた Form1 を含む Presenter との連携コード。

こんな感じでフォームを実装する。

public partial class Form1 : Form, IForm1
{
   private Form1Presenter presenter;

   public Form1()
   {
       InitializeComponent();
   }
   public bool AskOkOrCancel()
   {
       return DialogResult.OK == MessageBox.Show(
           "OK or Cancel", "", MessageBoxButtons.OKCancel);
   }
   public string ResultText
   {
       get { return this.textBox1.Text; }
       set { this.textBox1.Text = value; }
   }
   internal void Attach(Form1Presenter presenter)
   {
       this.presenter = presenter;
   }
   private void button1_Click(object sender, EventArgs e)
   {
       this.presenter.HandleButtonClick();
   }
}

この他、フォームを表示するところ（Program.csあたり）で、view を Presenter と関連付けるコードが必要だが割愛。

こんな風に、実フォームでは MessageBox.Show() 等のユーザ・インタラクションと、コントロールへの必要最小限のアクセッサのみを書く。

なんだか、もとのお題が小さすぎるから、コードを切り出したにもかかわらずフォームのコードが増えてしまっているが、実際の業務要件を満たすようなフォームだと、イベント・ハンドラに全部書くようなスタイルよりスッキリしたコードに、ちゃんとなる。

こうしたフォーム・コードは、コード量も多くならないし更新の度合いも少ないし、テストの必要性はそれほど高くない。UnitTest を省略していい部分だと思うが、どうしても DeveloperTest を書きたければ TypeMock か Moleを使えばいい。後付でも問題ないし、テスト・コードも極簡単なものですむ。

さらにフォームのコードを少なくするやり方もあるが、次の機会に。

GUI アプリのフォームの UnitTest

2011-01-20T00:31:00.003+09:00

UI 層のオブジェクトの UnitTest は簡単じゃない。
それは否定しない。

ただ、確かに一定の難易度があるにはあるけど、それを何とかする工夫が、かなり昔から研究され、いくつかはパターンとして提唱されて既にかなり広く知れ渡っている。

それにも関わらず、巷の底辺プロジェクトでは、未だに「GUI 層に関しては専用の UI テスト・ツールでも使わない限り、UnitTest は不可能」なんて迷信が未だに根強い。（UI テスト・ツールを使ったテストを、UnitTest の代替物と考えている時点で駄目なんだが･･･）

まあ、４・５年前までは雑誌とかでもそんな感じで言われてたし、未だにその頃の記事が技術系のサイトで閲覧できてたりするから、悪習が減らないのはそういった陳腐化した情報のせいもあるかもしれない。

困った事には、そうした底辺プロジェクトでは何でもかんでも UI 要素のイベント・ハンドラ・コードに書いてフォームを巨大化させるのが常だから、全ソースの半分以上がフォームのコードだったりする。

その上更に、大半の仕様変更がフォームにも影響を与えるものだったりするから、更新回数でいうとフォームのソースが 9割くらいにも達する。そういった、本来は最も UnitTest コードを書くべき部分でサボっておいて、大して変更頻度も高くない部分のカバレッジについて上がったの下がったの言ってるのを現場で見ていると、何とも切なくなってくる。

取り合えず、まず基本はフォームのコードを分割する事。

ユーザ･インタラクションや Windows のメッセージループが必要になる層（以下、View と呼ぶ）と、そうでない層に分ける。View をどこまで薄くするかという技法上の選択肢はあるが、とにかく薄くする。で、残りの部分について、View のインターフェイスに対しておもむろにモック･ツールを適用して、あとは普通に xUnit を使う。

ここまででも UnitTest としては、そこそこの網羅率になる。更にカバレッジを完璧に仕上げたかったら isolation ツール（.net なら TypeMock や Moleなど）を使えば、View についても UnitTest が書けるが、これはオプションと考えて良いと思う。

後で、実際のコード例を挙げてみる。

JSTQB認定テスト技術者資格試験のシラバス

2011-01-18T20:45:00.002+09:00

去年の夏の終わり頃、JSTQB という団体が認定するテスト技術者資格の試験を受けた。

Foundation Levelという事で、上級者向けの Advanced Level (まだ始まっていない)とはおそらく違ってそれほどハードルは高くなく、プロならほとんどが受かる難易度だと思う。勉強の材料は、JSTQB のサイトで配布されているシラバスを使った。これをよく読めば大体受かるはず。

実は、このシラバスがすごく良く出来ていて、受験者だけが読むのでは少しもったいない気がした。

短い分量に、用語、基礎知識、各種テクニックから教訓まで、非常に上手くまとめられている。

テスターはもちろんの事、開発者から PM、仕様担当者まで、広めの範囲の関係者一同で読み合わせて、認識を共有したりすると良いと思った。

コピペ・プログラミングの善悪の境界

2011-01-17T22:13:00.006+09:00

コピペ・プログラムは悪い事だと言われる。

コピペ・プログラマは駄目人間だとも言われる。

一方で、実際の現場ではコピペ・プログラミングは現実によく行われている。

リーダが「追加が決まった例の機能は、コピペで済むからラッキーだね」なんて言って、PM と一緒に嬉しがったりする。

当のプログラマも、「任務遂行のためならコピペも辞さない俺って、なんて冷徹なプロだろう」てな感じで、どこか得意げだったりする。

どう言う事か？コピペは良いのか悪いのか。

より正しく言うと、悪いのはコピペ自体ではなく、コピペにより生ずる重複コードの放置だと言える。古来より、共通コードはサブルーチン化すべしと言われてきたし、近年においても Merciless な Refactoring が強く推奨されている。

要は、結果的に重複が解消されて、保守性が下がる事もリスクが増える事もなくなれば、コピペそのものは別にどうって事ない。

もちろん現場の緊急事態においては、コピペ解消に要する数分～数十分を惜しんで保守性を犠牲にしリスクを高め、従って後になって無駄にコストばかり膨れ上がるという高利の負債を受け入れてもなお、一時も早くコミット／リリースせざるを得ない状況もある。

しかしだからと言って、TODO コメントで重複コードである旨を表示して、後続のプログラマの注意を喚起するくらいの事ができないわけはない。

それすらやらないという事こそ、もう言い逃れのできない不作為、無知、鈍感と言わざるを得ない。プログラムの仕事が分かってないという事になるのではないか。

★まとめ

コピペしない ← OK
作業の流れで一旦コピペしても、重複は残さない ← OK
やむを得ず重複を残したが、他人が怪我しないように手は打った ← ギリOK
コピペでコードを重複させましたが、何か？ ← 悪

★豆知識

かなり古い本だが『AntiPatterns』でも、"Cut-And-Paste Programming"として、Clipboard Coding、Software Propagationといった別名と共に紹介されている。
『Refactoring』では、Code Smellのうちの"Code Duplication"として紹介されている。
以下、元祖 wikiwiki から
- OnceAndOnlyOnce：「書くべきコードは一度だけ、ただ一度きりのみ書きましょう」と言う、おそらく最も有名な重複防止の標語。
- Refactoring Mercilessly：昔から XP で言われているプラクティス。特にコードの重複の解消を念頭においていると考えても良い。
- Duplicated Code：言わずと知れたコードの重複。CodeSmell(駄目なコードの兆候)の最たるものとされている
- Copy And Paste Programming：ずばり今回のテーマ。冒頭で一応、プログラミング手法の一つとして中立的に紹介された後、なぜこれが駄目なのかと延々と批判が続く

アジャイル・ワナビーの観察 1

2011-01-16T23:59:00.006+09:00

Agile Manifesto は over を挟んで左辺と右辺を対置し、右辺より左辺に高い価値を置くという形式になっている。

◆Individuals and interactions over processes and tools
◆ Working software over comprehensive documentation
◆ Customer collaboration over contract negotiation
◆ Responding to change over following a plan

ただし原文を読むと分かるとおり、右辺の価値を認めた上で更に左辺の方がより重要だと言っているわけで、右辺を害悪や無価値なものと断じているわけではない。だから共にプラスの価値とした上での比較論、バランスの問題とも捉えられる。

従って、右辺の重みを減らすなら、少なくともその効用が減少した分以上は、左辺に由来する効用によって補償されていなければならず、でなければプロジェクトに負の影響が生じてしまう。

さてアジャイル開発者とは、投下したコストから得られる効用の比率が、右辺より左辺の方が高いと考える人であり、その具体的な手法を提示しているのが各アジャイル･プロセスといえるだろう。

但し、その手法＝プラクティスは旧式の開発作法に比べ簡単だとは一概に言えず、それなりの知識と理解はもちろんの事、練習や工夫、或いは集中力が求められたりする（開発者としてはやり甲斐があるが）。

ところが、よくあるワナビな現場やプロジェクトでは、左辺の効力を増加させるための努力によってではなく、単に右辺を等閑視する事によってアジャイル開発になる（＝生産性・品質が向上し変化に迅速に対応できる）なんて短絡的に勘違いしている人が未だに多い。

以下、個別に見てみる。差し当たり、左辺に関するプラクティスの巧拙については割愛し、右辺がなおざりにされる状況だけを記述する。

プロセスが閑却されるケース
今時、ルールでガチガチに固めた単に監査のためだけにしかならないような重量プロセスもどうかと思うが、軽量プロセスって言葉もあるとおり、アジャイルだからといってプロセス不要って事にはなるわけがない。

にも関わらず、なんちゃってアジャイルな現場では、この肝心のプロセスすら無視される。むしろ完全にその場しのぎの行き当たりばったりの仕事が「臨機応変」とさえ捉えられてしまう。

で、たまに組織の上層部の思いつきで、「暫定」標準プロセスが適用されたりするが、長引くデスマの中で有耶無耶にされ、反省も（従って改善も）されないから、永遠に「下手の考え休むに似たり」の悪しきオリジナリティから卒業できない。

反復型なのか非反復型なのかも判別できない、グダグダでノッペリした開発作業が、終わりの見えないまま続いたりする。

（tools に関しては「ツールを減らせばアジャイルに近づく」的な勘違いは、特に見られない。但し、いわゆるアジャイル系･ツールの誤用・過信は非常に多い。これは、ここでのテーマと違うので割愛。）

文書が閑却されるケース
文書の方が有効なコミュニケーション場面ですら、口頭＝喋りで全てを伝えたがる悪癖に染まった現場も多い。伝える側は、無駄な文書化の手間が省けたと最初は思うが、何度も別の相手に同じ事を伝えている事に気づいて、初めて愚策だったと悟る（鈍感な人は、それすらいつまでも気づかないが）。

また、後のリファクタ・軌道修正が困難な箇所の設計すら個人の脳内で完結し、"Working software" が出来上がって来るまで他人のチェックが入らないため、後で一同頭をかきむしる事になるのもこのケース。（そもそもワナビな現場では、ユニットテストが後回しで、CIもロクに実現されていないから、そもそもアジャイルの意味での"Working software"と言えるのか疑問でもある。）

顧客交渉が閑却されるケース
最低限の契約交渉すらないというのは、つまりプロジェクト初期においては単なる安請け合い、末期には単に怒った顧客の言いなりに過ぎないケースがほとんどで、「協働」の本来の姿とはかけ離れている。

初期の交渉がテキトーだから、気が付いたときには既に顧客はイライラあるいは激怒し始めており、理性的にスコープを定める事ができなくなっていたりする。結局はプロジェクト外の上層部の長が出向いて、改めて不利な立場で交渉せざるを得ない羽目に陥る。

計画が閑却されるケース
ここまで記述してきたような、プロセスもなくスコープも定まっていないプロジェクトだと、従うべきプランなんて存在しようもなく、その場その時のアドホックな状況に反射的に反応しているだけとなる。

一応、後の変更を前提とした暫定プランが策定されたりもするが、ノウハウの蓄積の無い未熟な現場では合理的判断の根拠も無く、単なる思考停止の所産だったりする。

･･･というのが wannabe agile な現場でよく見かける愚行の一端。

====
http://agilemanifesto.org/を見ると 2001 とあるから、そろそろ10年になるらしい。

既にアジャイル・プロセスを導入して成功している現場に定住している人から見ると、上述のような現場が未だにあることに驚くかもしれないが、一般的には意外と多い普通の状況だったりする。自分もリーマンショック以降、初めて知る事になったわけだが・・・。

yasuabe blog

Haskell で平面ルービックキューブ

s/UT/UnitTest/

Haskell でソケット通信をやってみる

WYDKYDK が読めたよ！ ﾜｰｲヾ(´ρ`)ﾉ゛ﾜｰｲ

小事の思案と割れ窓理論

Spring 3.1 の Cache Abstraction

gtk2hs で落書きしてみる

gtk2hs と Glade の相性

現場でよくある Agile 認識の齟齬

Alloy 本

Haskell+HDBC+MySQL で Hello World

Prolog で楽典クイズ

Jaskell このやろう！

Groovy+HttpClient で Redmine の wiki 更新

Fantom でサンタクロース問題

Fantom でせんだみつおゲーム

Groovy + POI

Fantom

Squeak の右クリメニュー

LePUS3

OSGi で GoF の Strategy

Eclipse + Groovy + NekoHTML

論理パズル で Prolog のウォーミングアップ

Fedora のアップグレードで平常心の訓練

FEST+JavaScript で半自動 Swing テスト

仲間外れはどれか？

Eclipse と JMockit でテストファースト

暇だから MongoDB でも入れてみるか

JavaScript + XSLT の小技

簡単な後付けテストで基本を再確認

Fedora 15 + JavaDB

Coq をインストールしてみた

リファクタリング再読 4章 テストの構築

自動テストのレベル分け

Eclipse から XSLT 2.0 を使うやり方

リファクタリング本の Cyclomatic complexity

依存 jar を変更したらどうなるか

Advanced Level テストマネージャ試験受けてみた

JMockit: 基底クラスのコンストラクタのすりかえ

JMockit を使って簡単に「後回し」するやり方

JMockit と Swing と無名クラス

Effective Java から例外関連項目

JMockit

技術者と英語：「読める」だけで嬉しい三つの事

java の static メソッドの mocking

Fedora 15/Jenkins/Maven3/Subversion/Helios

アジャイルの資格

Java のスレッドプール

Effective Java からperformance 関連項目

CodeComplete からパレートの法則など

保守性とイマドキの開発

コード最適化の個人的三原則

Scrum + XP

このギャラ、損か得か？

なぜ UnitTestが生産性を上げるか

なぜ UnitTest が必要か

FunctionalTest の必要性

Hadoop

ユビキタス言語のベースの言語

FedoraCore12 + JBoss6.0 + Helios

Test Double の「Double」とは

底辺プロジェクトの DoNotCatchGeneralExceptionTypes

C＃での例外処理コードの基本

パターンカタログの私的ランキング（TOP 20）

パターンカタログの私的ランキング（TOP１０）

ソフトウェア品質の対概念

リファクタリングの因果ループ

GUI コードのUnitTest の例

CIのプラクティス

GUI コードのUnitTest の基本形

GUI アプリのフォームの UnitTest

JSTQB認定テスト技術者資格試験のシラバス

コピペ・プログラミングの善悪の境界

アジャイル・ワナビーの観察 1

WYDKYDK が読めたよ！ﾜｰｲヾ(´ρ`)ﾉ゛ﾜｰｲ

論理パズルで Prolog のウォーミングアップ

リファクタリング再読 4章テストの構築