5/31(Tue)
/** ヒサビサたくすぃー */ ヒサビサの遅い帰りでタクシーだったんですが、 まあ、送別会がてら飲んでたってだけなんですけどね(^^; 駅から前は13分くらい歩けば着くところだったのですが、 引越してからは、45分くらい歩かなければならないところになり、 さすがに飲んでてダルかったので、タクシー乗りました。 1,500円もったいないなぁ。。。 /** 大沢在昌作品 */ 先週辺りに、新宿鮫の風化水脈っていうのを読んでる話を書いたのですが、 平塚市民になったあかつきに中央図書館ってところに行ってみたら、 同じのが２冊もありました。。。(T_T) うー。買わなくても、借りれば良かったんじゃん。と後悔。 他の新宿鮫シリーズはないものかと探してみるも、 無残にもないような感じでした。 なんか、検索すると出てくるんだけど、本棚にはないんだよなぁ。。 ちなみに平塚の図書館は、中央図書館のほかに、 北図書館、南図書館、西図書館、移動図書館(車で現れるんだと) ってのがあるらしくて、本好きには良い環境かもしれません。 そうそう。中古本屋もブックオフ２店舗＆いくつかありますし。 で、結局B.D.Tってのを借りて読んでみたんですが、 未来の東京(2050年くらい?)を舞台にした探偵もので、 これまたなかなか面白かったです。 結末はちょっと残念な感じでしたが。 こないだたまたま、直木賞を取ったという、 新宿鮫４「無間人形」ってのを中古本屋で見つけたので、 速攻でゲットしてきました。 昔読んだような気がしないでもないのですが、 それでも楽しみだったりします(^^;5/28(Sat)
/** PrepareStatementのパラメータマーカ */ いままでさんざん仕事でJDBC使ってきたんですが、 この間ふと、PreparedStatementに渡すSQLに、固定値としての?を含めるにはどうしたら良いか? ということを疑問に感じました。 そういえば、?はパラメータマーカというのが正式名称のようです。 「はてな」とか「ホスト変数」とか、結構いい加減な呼び方してたんですね(^^; 現在、JDBCのバージョンは3.0なのですが、 これの仕様書を探してみたところ、以下の場所にありました。 JDBCに関する仕様書の集まり PreparedStatementに関する辺りを引用すると以下の通りです。 > The PreparedStatement interface extends Statement, adding the ability to set > values for parameter markers contained within the statement. > PreparedStatement objects represent SQL statements that can be prepared, or > precompiled, for execution once and then executed mulitple times. Parameter > markers, represented by “?” in the SQL string, are used to specify input vaues to the > statement that may vary at runtime. というわけで、「SQL文字列として表現された?は、パラメータマーカとしての役割を果たさず、 単なる文字列として扱われるようになる」 とのことです。 試しに、こんなプログラムを書いてみました。 (動作検証コードなんで、かなり適当です(^^;)import java.sql.*; public class test { public static void main(String[] args) throws Exception { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Connection con = DriverManager.getConnection("jdbc:odbc:test"); PreparedStatement stmt = con.prepareStatement("select * from test where aaa = '?'"); ResultSet rs = stmt.executeQuery(); while(rs.next()) { System.out.println(rs.getString(1)); } rs.close(); stmt.close(); con.close(); } }このプログラムは僕の期待通り、 testテーブルよりaaa列が?という値の行を取り出しました。 つまり、SQL文中の?はパラメータマーカとして機能せず、 固定値?として機能することが分かりました。 ところで、SQL文字列が'〜'と表現されることに、 何の疑いも持たなかったのですが、 もしやデータベースによっては、違うのかも知れません。 SQL99を読めって話もあるのですが、ぐぐってみたところ、 2万円もするような高価な資料らしいので、 とても僕のおこづかいでは買えません。。。(T_T) まあ、そもそも全てのデータベース製品SQL99準拠してるっていう保証もないし。 そういや、どっかにOracleは空文字''とNULLの扱いが同じってんで、 SQL99準拠じゃないし、理不尽みたいなのが載ってましたしね(^^;5/25(Wed)
/** 相変わらず(Javaでの)データベース処理に進歩なし */ 今回のプロジェクトを振り返ってみれば、 (思えば、振り返る余裕ができるなんて、夢にも思わなかったですが(^^;) 相変わらずデータベース処理が貧弱だったのではなかったかと思います。 処理には大きく分けて、画面系／バッチ、常駐(間隔起動のバッチみたいなもの)系とあり、 画面系は某社Webフレームワークが用意されていたのですが、 バッチ、常駐系は何も用意されていませんでした。 そのため、バッチ、常駐系にはデータベース処理を行う部品を用意し、 業務処理には、その部品を通してデータベース処理を行うようにしたのですが、 いかんせん、部品化が中途半端だったため、部品を通さないデータベースへのアクセスが横行しました。 また、今回使用したデータベース技術が複雑だったため、 頻繁に、データベース処理全体に影響がある変更が入りました。 (信じられないとは思いますが、rollbackを2回発行しなければならないなんてのもありました。) 極端な話、コミット、ロールバック、コネクションクローズに至るまで、 部品化しても良いのではないかと思います。 上記のように、部品と業務でばらばらに処理が記述されていては、 データベース処理全体を把握するのは難しいですが、 一意性のある名前であれば、後でgrepするのにも役立つかも知れません。 一方、画面系は某社Webフレームワークを利用しており、 ここにはデータベース処理も含まれるのですが、 所詮JDBC APIのラッパ程度のものであり、機能的な進化はあまりないです。 ただ、かならず部品を通してのみデータベース処理を行うようになっていた という点では、データベース処理全体への影響に対するメンテナンスビリティが高く、 成功していたと考えられます。 というわけで、画面系／バッチ、常駐系ともに、 「JDBC APIに微妙にラッピングしただけのもの」 という結果に終わりました。 オープンソースをばりばり使いこなせる集団であれば、 HibernateなどのO/Rマッピングを使うところでしょうが、 そこそこ規模の大きいプロジェクトでは、 使いこなせるスキルを持った人も少ないでしょうし、 布教するのにも時間も体力も使うので、 標準に近い(というか教科書に近い?)形がベターなのかも知れません。 結論。 1. 初心者にも使える分かりやすさを備える 2. JDBC APIのラッパではなく、もう少し進んだインタフェースを提供する → 他のフレームワーク(例えばJSTL)との相性の良さなど 3. データベース処理を集約させる を兼ね備えたツールなりフレームワークが、僕は良いのではないかと考えます。5/22(Sun)
/** まったりまったり */ 自分でも、こんなにまったりしてて良いのか。 と思うほどまったりしています。 去年の六月から続いていた、毎日終電の過酷な(?)労働は、 大分落ち着いてきて、少しは早く帰れるようになってきた感じです。 まだまだ予断を許さないような状況は、微妙に続いていますが(^^; 今月より（坂の無い平らな土地）平塚に引越したのですが、 (そういえば、洋光台は坂ばっかりで、自転車の移動は大変でした。。。) 初めて一戸建てに住んだり(戸締りが大変です。。。)、 初めて自分の車を持ったり、通勤に片道２時間かかったり、 色々生活上の変化があって、なかなか楽しかったりします(^o^) ちなみに、婿養子にいかなかったという点以外は、マスオさん状態といえば分かりやすいと思います(^^; 家の近所には、国道１２９号線が通っていることもあり、 生活上便利なものがかなりそろっています。 その中でも、今後かなりお世話になりそうなものに、ブックオフがあります。 自転車で7〜8分くらいのところで、いい感じです。 ヒサビサに日本語練習帳(105円!)という、一昔前に流行った本を読んでみたり、 新宿鮫シリーズの最新(風化水脈)を読んでみようとしたりしてます。 要らなくなったら売ればいいし、うちの本棚として活躍するかも(^^; 後は、簿記２級の勉強をぼちぼち進めてたり、 英語の勉強もぼちぼち進めたいなあと思うこのごろ。 奥さんのおねえさんの旦那様がアメリカ人なので、 この家にいるには必須だったりするし。 まあ、なんだか忙しかった反動が来ているようなので、 しばらくはギアを落として、ゆっくり行くつもりです。 /** 仕事的なアレ */ 最近ようやくサービスイン(最近はリリースとかカットオーバーとは言わないらしい)して、 クソ忙しかった仕事も落ち着いてきました。 ＧＷもほとんど休めましたし。 なんだかんだ、使っている技術は非オープンソース的な最新で、 並べるとどこと仕事しているのがすぐバレてしまうのですが(^^; 排他制御にロックを使っているがために、やたらとデッドロックが起きてしまう、 アレゲなデータベースを使っていました。 また、Oracleとアレゲなデータベースを無理矢理(?)つないで、 データベース間で表結合ができてしまうという、 これまたアレゲな製品も使ってみました。 さらに、ワークフロー製品という、 これまたミドルウェアとしては全く完成度の低い、 まだウインドウズの方がマシなのではないかと思えるような、 相当アレゲな製品も使ってみました。 そんでもって、局所的には有名な、 ファイルでホストとかUNIXとかWINDOWS間で、 通信できてしまうあの製品も使ってみました。 これまた局所的には有名な、 運用管理ツールであるシステムを歩く製品も使ってみました。 これだけはまともな、Webアプリケーションサーバと、 その上に乗る、某社独自のフレームワーク(意外と使いやすい)と、 Eclipse拡張の開発環境(これまたかなり使いやすい)で、 そんな製品も使ってみました。 正直、業務はそんなに難しくない(設計に携わったわけではなく、テストしての印象ですが)が、 これだけ色んな製品がごっちゃごっちゃしていると、 下地となるインフラがものすごくもろくなるために、 そっちの収拾がものすごく大変でした。 ほんと、当たらし物好きも、ほどほどにして欲しいものです(T_T) よく、「新技術の導入は少なくした方が良い」 と言いますが、その真逆のことをやって失敗した良い例なのではないかと思います。 まあ、エラい人の一存とかで決まってるんでしょうから、 僕のような下っ端には、どうすることもできないのですが。。。