何気なく
またblog再開するかなぁ〜
EzJDBCいらなくね＞＜
本日は、相変わらずどうでもよい情報を紹介したいと思います。
JavaコードでタイプセーフなSQLを記述できるオープンソースのフレームワークを見つけましたのでご紹介いたします。
そのフレームワークの名前は「jOOQ」といいます。
だらだら説明するよりも、実際のコードをみてみましょう（百一：百文は一見にしかず）
下記のSQLを例にJOOQのコードを見てみます。
【SQL例】
SELECT FIRST_NAME, LAST_NAME, COUNT(*)
FROM AUTHOR
JOIN BOOK ON AUTHOR.ID = BOOK.AUTHOR_ID
WHERE LANGUAGE = 'DE'
AND PUBLISHED > '2008-01-01'
GROUP BY FIRST_NAME, LAST_NAME
HAVING COUNT(*) > 5
ORDER BY LAST_NAME ASC NULLS FIRST
LIMIT 2
OFFSET 1
FOR UPDATE
OF FIRST_NAME, LAST_NAME
上記のＳＱＬを「jOOQ」を利用して書くと以下のようになります。
【jOOQでの書き方】
create.select(FIRST_NAME, LAST_NAME, create.count())
.from(AUTHOR)
.join(BOOK).on(Author.ID.equal(Book.AUTHOR_ID))
.where(LANGUAGE.equal("DE"))
.and(PUBLISHED.greaterThan(parseDate('2008-01-01')))
.groupBy(FIRST_NAME, LAST_NAME)
.having(create.count().greaterThan(5))
.orderBy(LAST_NAME.asc().nullsFirst())
.limit(2)
.offset(1)
.forUpdate()
.of(FIRST_NAME, LAST_NAME)
説明はいりませんね。SQLそのままです。
SQLそのままなら、Javaで書く必要性なくね！と思われた方もいるでしょうが、Javaで記述するとタイプセーフかつネームセーフになるのです。
例えば、属性が文字列のカラムを抽出条件とした場合、誤って比較値に数値を受け渡した場合は、Eclipe上で即エラーが発生します。
SQLの場合だと実行しないと、この種のエラーは判別できません。
また、selectする項目名をtypoした場合も即座にエラーになるため、記述ミスをすることがなくなります。
さらに！
Eclipseを利用すると保管機能がりようできますので、カラム名を全てマニュアルで入力する必要がなくなりますので、流れるようにコードを記述することが可能になります。
保管機能ではJavaDocが表示されますので、Eclipse上でカラムの日本語名（論理名）や桁数属性などを確認しながらSQLを記述することができるのです。
と、ここからが本題！
上記「jOOQ」のコードを初めて見たとき、EzJDBCが勝手にオープンソースにされている。と思うほどEzJDBCにそっくりなので驚きました。
以下にEzJDBCで記述した例を記載します。
【EzJDBCでの書き方】
select(AUTHOR.firstName, AUTHOR.lastName, AUTHOR.count())
.from(AUTHOR)
.join(BOOK).on(AUTHOR.id.eq(Book.id))
.where(BOOK.language.eq("DE"))
.and(BOOK.published.gt("2008-01-01"))
.groupBy(AUTHOR.firstName, AT.lastName)
.having(AUTHOR.count().gt(5))
.orderBy(AUTHOR.lastName.asc().nullsFirst())
.limit(2)
.offset(1)
.forUpdateOf(AUTHOR.firstName, AUTHOR.lastName)
どうですか？かなり近いですね。って、ことはEzJDBCいらなくね~＞＜ というオチに入り込むと。。。
生産性向上の鍵
稼働率と生産性はイコールではないが、無関係でもない！
生産性があがるとモチベーションがあがりゾーンに突入する。
ゾーンに入ると、同じ作業を行っていても集中力が違うためスピードは上がり、ミスも少なくなる。
すると時間に余裕ができるようになり、次のステップに進みやすくなる。この一瞬は稼働率は下がるが、スキルアップするために、行える仕事が多くなる。
それにより上位者が行っていた仕事を変わりに行えるようになり、待ちが発生しなくなる。
かなり強引だが、以下の公式が成り立つ。
生産性向上→モチベーションＵＰ→学習意欲向上→スキルアップ
最終的に「稼働率up」へとつながる。
風が吹けば桶屋が儲かる的な話だが、あながち眉唾でもない。
では、生産性を上げるには、どうしたら良いのだろうか？
まず、生産性の定義を決めておく！
生産性は「開発生産性」と「保守（生産）性」の両方を含むものとする。
立場にもよるが、開発と保守の両方をお粉なっている人も少なくないはず。
モチベーションを上げるには、開発生産性だけではなく保守性も向上しないことには、まったく意味が無い。
よって、ここでは生産性は「開発」と「保守」の両面を含むものとして定義する。
以下に生産性を向上されるための鍵となる「稼働率」を向上させるためのルール（規約）を上がる。
・ルーチンワークの排除
ルーチンワークは単純なものが多くモチベーションを下げる。 ルーチンワークはマニュアルで行わずに、プログラムで行う。 それを実現する環境（ソフト、ハード、人）を用意する。 ＊人がマニュアルでやっている事には、何らかのルール(判断基準) がある事が多い、そういう作業はプログラムの方が得意。
・既存機能のコピー＆ペーストを廃止
テンプレートを利用する分には可とする。 ＊理由は、既存の機能には固有のロジックが含まれている場合が 多いため、開発中半・後半に障害が発生する場合が多い。
・プログラム開発は小さい機能から作成し、常に稼動確認出来る状態で開発する。
ＢＬは一気に完成系のものを作成しようとすると、バグが混在しや すい、且つバグの発見にコストがかかる。 但し、ＢＬを含まない画面遷移は、一気に作成したほうが効率が 良いため可とする。
・設計の段階でデータストアへのアクセステスト(SQL等)は、先に行っておく（DBが存在する場合）
設計の段階で開発言語が顔をだすのは、良くない事かもしれない が、実装の段階で問題を発覚するぐらいであれば許容範囲
・同じ機能は2度作らない（同じことは2度行わない）。
時間が経過してから、同じものが必要になった場合は、その時に 共通化を行うべき。別システムであったり、本番導入の関係上 共通化できない場合は、2つめ以降を共通かし、その後は同じ機能 を開発しない。 開発時間、テスト時間の削減と、ノウハウの蓄積につながる。 プログラムもドキュメントも。。。 つまり、DRY(Don’t Repeat Yourself)に生きろ！
・実装前に想定される共通機能、テンプレート作成しレクチャーする。
画面のビューに関してはシステムのテーマがあるため装飾や フォントおよび配置などを機能毎(エントリー画面や一覧照会画面) にテンプレートを用意しておく。 画面の機能（ボタンやリンク押下時の動き）についても、スクリプト等を埋め込んだ「タグ」をテンプレートを用意しておく。
・担当者割り当てをユースケースレベルから機能単位に変更する。
1ユースケース(サブシステムの機能)単位で、人を割り当てるので はなく 開発する機能(プログラム)のレベルで担当者の割り当てを 行う。単純なマスター系であっても、その1部の機能が複雑であれ ば、その箇所はレベルのあった別担当者に任せる。 スキルアップを目指すためにレベルにあっていない開発を行うこと は、担当者もプロジェクトも不幸になる。 レベルにあったプログラムが完璧になったら次のステップに行く。
・ソースレビューを行う。
初めはこまめに行い。少しづつ大きな（単一機能）レベルで行う ようにする。 大勢でおこなうのではなく、1対1で行うようにする。行う場所は レビューを受ける人の端末で行うようにする。
EzJDBCのSQL自動生成機能に対する大口を反省して…
以前「大半のSQLはEzJDBCのSQL自動生成機能で作成可能」と大口をたたいた高橋です...m(＿＿)m
その責任を取るべく、現在EzJDBCの機能強化を行っています。
EzJDBCは、JDBCの煩雑な作業を完全に隠蔽し、利用者が開発に専念できるORマッパーです。
大半のSQLは、SQL自動生成機能で作成可能となるため、SQLを直接記述する必要がなく、流れを止めずに開発を行なうことが可能になります
「大半のSQL」となると目標が漠然としてしまうので、私の愛読書「SQLポケットリファレンス(改訂第3版)」の内容をすべてSQL自動生成機能で作成出来ることを目標にしました。
絶対条件として、以下の3点は守ることにしました。
1.利用方法が複雑にならない。
2.メソッドの追加は最低限で済ます。
3.SQLを知っていれば直感的に利用できる。
現時点で全体の30%が完了し良い感じになってます。
もちろんストアドもEzJDBCから呼び出すこともできますし作成することもできます。
＊現時点では機能が限定されていますが…＞＜
来年早々には完成させまーす...(￣０￣)/
EzJDBCのコード補完機能／今更ですがvol.2
今回ご紹介するのは、EzJDBCのコード訪韓機能についてです。
今までも何度かEzJDBCはコード補完を利用するとほとんどタイプ（記述）することなくコードがかけますよ。と発信してきましたが、今回はもう少し具体的な説明をしたいと思います。
EzJDBCはJava1.6に対応してから、「new EzJDBC().select().from(CS)...」という記述方法をやめ、static import機能を利用して、「selects().from(CS)...」という記述方法にかわりました。
より、記述方法が単純になったわけです。照会したい場合は「selects()」、登録したい場合は「inserts()」、更新したい場合は「updates()」、削除し対場合は「deletes()」とだけ記述すればよいわけです（CREATEやDROP系は特殊なので、ここでは説明しません）。
しかし、その後に何を記述すればよいかは開発者が考えてタイプ(記述)しなければいけません。
EzJDBCでは、その点をEclipseの入力補完機能をフルに利用して、開発者をサポートするように出来ています。
では、以下の例を見てもらいましょう。
以下の画面では、照会系SQLを発行するためのコードをタイプ（記述）している途中です。
staticメソッドである「selects()」を呼び出した後に、Eclipseの補完機能を利用(Ctrl+Spaceを押下)して、次に呼び出せるメソッドを一覧で表示しています。
上記画面のサブウインドウの上側では、次に呼び出せるメソッドの一覧が表示されます。
サブウインドウの下側は、上サブウインドウで選択したメソッドの説明(JavaDoc)が表示されています。
上記例では、selects()メソッドの次に呼び出せるメソッドは3つだけが表示されており、2つめの(_from(Table))メソッドの説明が表示されています。
単純なSQLですので、誰にでもわかると思いますが、SELECT句の後に呼び出せるSQLはFROM句のみであるため、3メソッドだけが表示されているのです。
注意：3メソッドの説明
1._(Column... columns)メソッドは、selectメソッドで指定した列情報以外に取得する列を追加するメソッドです。
通常のSQLには存在しませんが、機能的に便利なのでついています。
2._from(Table table)メソッドは、通常のfrom句の意味になります。引数にはテーブル情報を設定します。
3._from(Option subquery, String alias)メソッドは、from句にサブクエリーを設定するメソッドです。
では、次にfrom句の後に設定できるメソッドの一覧を見てみましょう。
2画面に分けて表示しますが、以下のような感じです。
その1
その2
一番初めに表示されている「_bind」メソッドは、ここでは説明を割愛しますが、from句の後に利用できるSQLに対応するメソッドのみ
が表示されているのがわかるかと思います。下ウインドウの説明には、SQLの説明と利用例が表示されていますので、悩まずに利用する
事が可能になります。
とはいっても、SQLを熟知している方は、こんな説明は読まずに「Ctrl+Space」押下、「↑↓」で選択し、「Enter」押下すれば、一切タイプすることなくSQLを組んで行くことが可能になります。
SQL初心者にとっては、単純なSQLならともかく普段利用しない関数を利用したい場合に、どこに記述すべきか迷うこともあるかと思いますが、EzJDBCでは、その関数が利用できる箇所にならないとメソッドが表示されませんので、自然にSQLの構文を理解する事が出来るようになります。メソッドの説明＆例題を見ることによりSQL内で解決できる内容が増えてくるようになります。
SQL初心者にとっては、学習したけど忘れている関数を思い出せることや、素のSQLで良くあるタイプミスによるSQLエラーがなくなることが、一番の利点かもしれません。
EzJDBCのコード補完機能は、単にメソッド一覧を表示し入力を楽にするだけではなく、SQLのルールに基づいて記述する事を可能にする機能なのです...(￣０￣)b
