MacJournal5の使用許諾契約。。さすがにこれはないだろ。。

いろんなメモ書きを管理できるツールが欲しいなぁ、と思い、いろいろと評判の良いMacJournal5の体験版を落としてみました。で、早速使ってみようと思ったところ。。

いつもは無頓着に「同意する」を選んでいるけど。。さすがにこれは平然と「同意する」ボタンを押せないよね。。何考えてんだ。。

なんだこのエロゲ - 「白いネコは何をくれた?」を読了

一身上の都合でマーケティング理論を勉強することになりました。大学では経営工学をやっていたので一般的なマーケティング理論は大体名前だけなら知っているのですが、その戦略的な組み立てとなると「うーむ」という感じです。

そんな訳で本格的にいろんな本を読みあさる前に、一冊軽く小説仕立てのものを読みたいなぁ、と思い手に取ったのがこの本です。

白いネコは何をくれた?

白いネコは何をくれた?

著者の佐藤義典氏の提唱する戦略BASiCS理論によって、ダメな主人公がモリモリかわって最終的には超大手競合会社を打ち負かし恋人(?)までゲットする、まるで「こんな私も戦略BASiCSで(ry」みたいな物語です。読んでて何だこのエロゲ、と30回ぐらい思いました。

戦略BASiCS理論自体はとっても使いやすい理論です。この本でも理論自体は40ページ弱でコンパクトにまとめられており、ストーリーと反復しながら読み返すことで更に理解を深められる構成になっています。

戦略BASiCS理論
B: Battlefield => どこで誰と戦っているか?
A: Asset => 独自資源
S: Strength => 強み/差別化(独自資源をどのように展開して戦うか?)
(i: integration => 他5つを連動させる)
C: Customer => 顧客を絞る(強みが生きる顧客を選ぶ)
S: Selling message => どのように実行するか?

Selling messageはちょっと間違ってるかも知れませんが、大体上記のような形です。そのまま就活の自己分析にも使えそうな感じです。

どこにでもありそうな考え方ですが、この本で一番伝えたがっているのは「一貫性」です。カッコで括ったオマケのようなintegrationの部分です。一つ一つを正確に答えとしてはじき出しても、それぞれが連動していないと、全く使えないフレームワークになってしまいます。この連動がいかに大事かということは、この本でストーリーとして繰り返し何度も何度も出てくる部分です。一貫性で恋人もゲットです。

BASiCSの組み立て方も物語調で読むとすんなり理解できます。ビジネスを戦略的に考えたいけど、よく本に載ってるフレームワークとか使い方がよくわからないよー、みたいな、そういう悩みを持っている方にオススメ。

PL/SQL with RSpecでビヘイビア駆動開発(?)シリーズまとめ

2週間弱に渡っていろいろ書いていたのでまとめてみます。何かのご参考になれば幸いということで。

Hello, Worldだけじゃ癪なので、とりあえずGroovyでOracleに接続してみた

Groovyで何が目玉かって、その一つにGroovy SQLがあると思うのです。(チュートリ*1にもあるし)

そういう訳で寝る前にOracleに接続してから寝ようと思います。寝る前にOracleとか少しどんだけって感じがしますね。

import groovy.sql.Sql
import java.sql.SQLException

try{
    sql = Sql.newInstance(
        "jdbc:oracle:thin:@192.168.11.100:1521:xe"
        ,"apxe", "apxe"
        ,"oracle.jdbc.driver.OracleDriver")
    sql.eachRow("select * from Messages", { println it.message_code + " " + it.message } )
} catch( SQLException sqle ){
    sqle.printStackTrace()
} finally {
    sql?.close()
}

プロジェクトの参照ライブラリにOracle JDBC Driverを加えておくのを忘れずに。

まずは以下のようにライブラリにJDBC Driverを追加して。。

プロジェクトに設定、と。

そしてF6実行すると以下のように出力されます。

run:
MES000001 私の名前は &NAME です。
MES000000 正常終了しました。
構築成功 (合計時間: 2 秒)

意外とハマらずにスイスイ行けちゃうのがステキですね。

Groovy with NetBeans@MacでHelloしてみる

どうせGroovyするならIDEから!というわけで、現在無料で使える総合環境の中で一番Groovyが使いやすそうなNetBeansでHelloしてみます。Eclipseは滅びればいい。

インストールしたNetBeansは最新版の6.5です。それではHelloするための旅に出てみましょう。

1. まずはプロジェクトを作成

Groovyを選択したところでGrailsのプロジェクトしか作れないので、Javaのプロジェクトを選択しますよ。

2. プロジェクト名を決める

てきとうにHelloGroovyで良いのではないでしょうか

3. プロジェクトの中にGroovyスクリプトファイルを追加する

新しくできあがったプロジェクトなのでまだソースファイルが一つもありません。というわけでGroovyファイルを追加します。

するとこんな感じに追加されます。


4. Hello Worldと書かせろよ

既に勝手に何か書かれてるのが癪ですが、ついカッとなってそのままビルドします。「クラスがないよ?」と聞かれますが、「まぁ適当に作っておいてよ」とすると以下のように実行結果が返ってきます。


これから

NetBeans使うのははじめてなので、NetBeansの使い方を覚えつつGroovyしていこうと思います。

P.S. http://www.jggug.org/ なんとなく会員になってみました。

ビヘイビア駆動とかよく分からないけど、とりあえずRSpec書きながらプロシージャを作ってみる #3 まとめ

正直なところ、今までノープランで書いてきたスペックファイルはあまりにあんまりなので、前回の最後に記述した通り、ここらで一回整理してみようと思います。

describeに記述したシチュエーションの振る舞いをitで確かめるのだとすれば、describeの分割単位はパラメータの入力パターン毎であり、itはそのときの振る舞いを一つ一つ定義するのが自然です。例えば「Dogクラスのインスタンスをnewしたとき」というdescribeを描いたならば、itはそのインスタンスの状態を一つ一つ確かめるものであるべきです。

このような前提でスペックファイルを書き直してみると、そこそこスッキリします。

describe "MES000000を指定し、トークンに何も入力しないとき" do
  it "「正常終了しました。」というメッセージを返す" do
  end
  it "ov_retcodeは0(正常終了)である" do
  end
end

describe "MES_ERROR_TESTを指定し、トークンに何も入力しないとき" do
  it "「GET_MESSAGE ERROR:存在しないエラーコードが指定されました。」というメッセージを返す" do
  end
  it "ov_retcodeは1(異常終了)である" do
  end
end

describe "MES000001を指定し、トークン1に「もっこす」と入力したとき" do
  it "「私の名前は もっこす です。」というメッセージを返す" do
  end
  it "ov_retcodeは0(正常終了)である" do
  end
end

上記のスペックを実行した結果は以下のようになります。

MES000000を指定し、トークンに何も入力しないとき
- 「正常終了しました。」というメッセージを返す
- ov_retcodeは0(正常終了)である

MES_ERROR_TESTを指定し、トークンに何も入力しないとき
- 「GET_MESSAGE ERROR:存在しないエラーコードが指定されました。」というメッセージを返す
- ov_retcodeは1(異常終了)である

MES000001を指定し、トークン1に「もっこす」と入力したとき
- 「私の名前は もっこす です。」というメッセージを返す
- ov_retcodeは0(正常終了)である

ちなみに、今までの実行結果は以下の通りです。

トークンを指定せずにメッセージを取得するとき
- (1) SELECT message FROM Messages WHERE message_code = 'MES000000'で「正常終了しました。」というメッセージを取得できる
- (2) 「MES000000」を指定すると「正常終了しました。」というメッセージを取得
- (3) 存在しないmessage_codeを指定するとエラーメッセージとエラーコードが返る

トークンを1つ指定してメッセージを取得するとき
- (1)「MES000001」でトークン1に「もっこす」と指定すると「私の名前は もっこす です。」と返る

Finished in 1.247753 seconds

4 examples, 0 failures

今まで書いてきたスペックがどうにもスッキリしないのは、itにまとめていろんなことを書いていたからなのでした。itで確かめる内容は1つに限定すれば綺麗にまとまります。(theyではないしねえ。。)

実際に実装してみると以下のようになります。

#
# get_message_ref1_spec.rb
# describeに引数のパターンを記述し、その振る舞いを
# itに書いていくやり方
#
require 'rubygems'
require 'spec'
require 'oci8'
#
# テスト対象のPL/SQLプロシージャ
# (こんな感じのプロシージャ作る)
# PROCEDURE get_message( iv_message_code IN Messages.message_code%TYPE,
#                        iv_token1 IN Messages.token1%TYPE,
#                iv_token2 IN Messages.token2%TYPE,
#                iv_token3 IN Messages.token3%TYPE,
#                iv_token4 IN Messages.token4%TYPE,
#                iv_token5 IN Messages.token5%TYPE,
#                ov_message OUT VARCHAR2
#                        ov_retcode OUT VARCHAR2);
#
target_plsql = <<-PLSQL
BEGIN
  get_message(:iv_message_code,
              :iv_token1,
              :iv_token2,
              :iv_token3,
              :iv_token4,
              :iv_token5,
              :ov_message,
              :ov_retcode);
END;
PLSQL
#
describe "GET_MESSAGEプロシージャで" do
  before(:all) do
    # Oracle databaseへ接続
    @conn = OCI8.new('apxe','apxe','xe')
  end
  after(:all) do
    # databaseへの接続を切断
    @conn.logoff
  end
  
  describe "MES000000を指定し、トークンに何も入力しないとき" do
    before(:all) do
      @cursor = @conn.parse(target_plsql)
      @cursor.bind_param(':iv_message_code', 'MES000000')
      @cursor.bind_param(':iv_token1', '')
      @cursor.bind_param(':iv_token2', '')
      @cursor.bind_param(':iv_token3', '')
      @cursor.bind_param(':iv_token4', '')
      @cursor.bind_param(':iv_token5', '')
      @cursor.bind_param(':ov_message', nil, String, 2000)
      @cursor.bind_param(':ov_retcode', nil, String, 10)
      @cursor.exec
    end
    it "「正常終了しました。」というメッセージを返す" do
      @cursor[':ov_message'].should == "正常終了しました。"
    end
    it "ov_retcodeは0(正常終了)である" do
      @cursor[':ov_retcode'].should == "0"
    end
  end
  
  describe "MES_ERROR_TESTを指定し、トークンに何も入力しないとき" do
    before(:all) do
      @cursor = @conn.parse(target_plsql)
      @cursor.bind_param(':iv_message_code', 'MES_ERROR_TEST')
      @cursor.bind_param(':iv_token1', '')
      @cursor.bind_param(':iv_token2', '')
      @cursor.bind_param(':iv_token3', '')
      @cursor.bind_param(':iv_token4', '')
      @cursor.bind_param(':iv_token5', '')
      @cursor.bind_param(':ov_message', nil, String, 2000)
      @cursor.bind_param(':ov_retcode', nil, String, 10)
      @cursor.exec
    end
    it "「GET_MESSAGE ERROR:存在しないエラーコードが指定されました。」というメッセージを返す" do
      @cursor[':ov_message'].should == "GET_MESSAGE ERROR:存在しないエラーコードが指定されました。"
    end
    it "ov_retcodeは1(異常終了)である" do
      @cursor[':ov_retcode'].should == "1"
    end
  end
  
  describe "MES000001を指定し、トークン1に「もっこす」と入力したとき" do
    before(:all) do
      @cursor = @conn.parse(target_plsql)
      @cursor.bind_param(':iv_message_code', 'MES000001')
      @cursor.bind_param(':iv_token1', 'もっこす')
      @cursor.bind_param(':iv_token2', '')
      @cursor.bind_param(':iv_token3', '')
      @cursor.bind_param(':iv_token4', '')
      @cursor.bind_param(':iv_token5', '')
      @cursor.bind_param(':ov_message', nil, String, 2000)
      @cursor.bind_param(':ov_retcode', nil, String, 10)
      @cursor.exec
    end
    it "「私の名前は もっこす です。」というメッセージを返す" do
      @cursor[':ov_message'].should == "私の名前は もっこす です。"
    end
    it "ov_retcodeは0(正常終了)である" do
      @cursor[':ov_retcode'].should == "0"
    end
  end

end

実行結果は以下の通り。

pasta:get_message mahm$ spec -c -fs get_message_ref1_spec.rb 

GET_MESSAGEプロシージャで MES000000を指定し、トークンに何も入力しないとき
- 「正常終了しました。」というメッセージを返す
- ov_retcodeは0(正常終了)である

GET_MESSAGEプロシージャで MES_ERROR_TESTを指定し、トークンに何も入力しないとき
- 「GET_MESSAGE ERROR:存在しないエラーコードが指定されました。」というメッセージを返す
- ov_retcodeは1(異常終了)である

GET_MESSAGEプロシージャで MES000001を指定し、トークン1に「もっこす」と入力したとき
- 「私の名前は もっこす です。」というメッセージを返す
- ov_retcodeは0(正常終了)である

Finished in 0.213314 seconds

6 examples, 0 failures

逐次的にスペックを増やしていくよりも、最初に日本語のレベルでスペックをある程度書いてから開発するのが吉ですね。スペックを実行したときに、実際の仕様書のように日本語(もしくは英語)が繋がっていると良い感じです。

仕様をコードで書いていくようなイメージなんですね。。って、だからビヘイビア駆動なのか。

Groovy + DbUnit + easybの組み合わせもアリだなぁ

今回RSpecでやってみましたが、上記の組み合わせも個人的にはアツいです。DB系のテストだとDbUnitが既に受け入れられているので、現場で使う分にも良いかも。(groovy + easybが難関すぎるが)

参考 : 2007-12-27

rubyならrailsのfixturesですが、これって単独で使うにはどうすれば良いのだろう。。railsがあんまりよく分かっていないのでアレですが、この辺は後々の宿題ですかね。。

まとめ

  • ビヘイビア駆動は仕様をコードで書くイメージ。仕様に対する実装は逐次的にやっても良いけれども、仕様を逐次的に追加するのはあまりよろしくない。(#1, #2が悪い例)
  • #1, #2は少し悪い例だったが、PL/SQLプロシージャのビヘイビア駆動開発は十分可能(だと思う)。
  • RSpecはdescribeに記述する単位とitに記述する単位を明確にするのが大事。