Slim3 1.0.0をリリースしました。 リリースノートはこちら http://sites.google.com/site/slim3appengine/release-notes ダウンロードはこちら http://code.google.com/p/slim3/downloads/list Slim3の主な特徴は次のとおりです。 Global Transactions Faster than JDO/JPA Fast spin-up HOT reloading Type safe query 詳しくはこちらをどうぞ http://slim3.org Seasar2譲りのHOT reloadingやS2JDBC譲りのType safe queryなどもありますが、最大の特徴は、Global Transactionsを実装していること。 http://d.hatena.ne.jp/hig

チャンスをつかまえることを「運命の女神の前髪をつかむ」なんていったりしますよね。それでは、運命の女神の前髪をつかむにはどうしたらいいのか。 私自身の経験とまわりを観察した結果から導き出されるのは、「数多くトライすること」だと思います。 チャンスをつかむ回数は次のように表現できるんじゃないかと考えています。 チャンスをつかむ回数 = チャンスをつかむ確率 * トライする回数チャンスをつかむ確率は、みんな同じように低い。だから、チャンスをつかむ回数を1以上にするために、何度もトライしなければならない。 才能は人それぞれ違うと思うけど、チャンスをつかむ確率は、みんな同じように低い。才能によって、チャンスをつかむ確率は変化しないんじゃないかな。才能があってもチャンスをつかめない人もいるし、その逆もある。そこから導き出されることは、「チャンスをつかむ確率は、みんな同じように低い」ということ。まぁ、あ

2008-12-12 いくつか誤解を生みそうな表現があるので、それをまずは指摘しましょう。 プログラムモデルとしては、すでにRDBMSからの脱却の準備は始まっています。ORマッピングがそれです。 これが、意図的かはわからないけど、ミスリードを生んでいます。「RDBMSの時代の終わりが見えてきた」というタイトルで、こういう書き方をすると、「ORマッピングによって、すでにRDBMSからの脱却の準備は始まっている」という風に読めるでしょう。これが、ミスリード。 JPAが大切だと思っているのは、永続パラダイムの転換に、コーディングを変えることなく対応できるからです。もちろんJPA+RDBMSのシステムをJPA+非RDBMSに切り替えれるという話ではなく、プログラマのコードの書き方の対応の話です。 これをもう少し、噛み砕くと、JPAのJPQL(SQLもどき)を使えば、SQLとしては統一されていない複

Javaのコネクションプーリングがどのような仕組みになっているのか、知らない人は結構多いんじゃないかと思います。 Slim3のコネクションプーリングの実装を見ると、この辺が理解できるようになります。トランザクションとコネクションプーリングがどのように連携しているかを把握することは重要です。 http://svn.slim3.org/browse/trunk/slim3/slim3-datasource/src/main/java/org/slim3/datasource/ 登場人物は、4人しかいないから簡単ですね。 最初に見て欲しいのは、ConnectionWrapper。DataSource.getConnection()したときに戻されるコネクションの実態です。このコネクションを論理的なコネクションと呼ぶようにします。 主な役割は、コネクションがクローズされたときに、コネクションをプー

日本IBMのリストラが始まった - yvsu pron. yasで、不況のときに安直にリストラすると、中長期の利益を失うリスクがあるというエントリを書きました。 安直なリストラのどこに問題があるのでしょうか。一番の問題は、「人」という会社で最も重要な資産を失ってしまうことです。 人の首を切ることは直ぐにできるけど、人を育てるには時間がかかります。中長期の利益を生み出すのは、やはり人です。人という大切な資産を失ってしまったら、利益を生み出す源泉がなくなってしまうのです。 下請けに頼りすぎれば、システム会社として持つべき技術や機能の低下は避けられない。それでも業界を覆う下請け依存症は年々悪化の一途をたどっている。 正社員をリストラして、その分は、下請けに頼るとしましょう。一時的にはコストが下がるかもしれないけど、かわりに技術という大事なものを失ってしまう。 別にこれは、リストラだけに限ったこと

プログラミングファースト開発と最初に聞いて、ソフト開発の手順としては当たり前過ぎて、最初は何が新しいのかさっぱり分からなかったんだけど、肝は如何に受託開発でそれを貫徹するかの交渉術や契約形態にありそうだということに合点がいった。人月に代わる値付けの方法、機能や品質に応じた対価を得る手法として、パッケージ販売やSaaSといった共通化と利用者拡大の他に、相対取引での値付けにも新たな道は広がるのだろうか。 実は世の大半の名だたるソフトウェアに厳密な仕様書などないし、受託開発でも設計書と呼ばれているものがコードと同期している可能性はかなり低い。これはソフトにとって役に立つこと、問題を起こさないことが、仕様書通りに動くことよりずっと重視されてきた結果であって、みんな心のどこかで気掛かりではあるけれども、マクロ的には合理的なトレードオフの結果であって必ずしも悪い話ではない。 恐らくプログラミング・ファ

今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる

Railsが成功し、EJB3が失敗したわけは、イノベーションへの解にでてくる「独自仕様の製品アーキテクチャ」と「モジュール方式のオープンな業界標準」の考え方で、うまく説明できるように思えます。 ただし、この手の話は、理論にあうように現実を説明しているところがあるので、あくまでも、1つの可能性として聞いてください。 ここでの重要な考え方は、「顧客のニーズ」と「製品の性能」の力関係です。 「顧客のニーズ」が「製品の性能」を超えている場合は、顧客は、製品の性能向上に価値を認め、お金を払います。このときに企業として、成功しやすいソリューションは、「最適化された独自アーキテクチャ」で望むことです。性能を向上させるためには、独自アーキテクチャのほうが、いろいろ工夫ができるためです。 「製品の性能」が「顧客のニーズ」を超えている場合は、顧客は、製品の性能向上に価値をあまり認めません。既に、製品の性能に満

最近の大田さん@mixiのところで、Rubyについて考察する機会があったのと、よういちろうの考えと同じことを思っていたので、たまには本音で書いてみる。 Railsで、最も良いところは、テストの雛形も自動的に作ってくれて、テストの敷居を下げてくれてるところだと思う。なのに、それについて触れる人があまりにも少ないような気がする。一応、私は、1年半以上、はてなのキーワード検索で毎日Railsについては調べているので、はてなでRailsについて書いている人の記事はたいてい見ています。 理由は、いくつか考えられますが、私の読みだと、テストが当たり前の人にとっては、当たり前すぎてわざわざ書く意味がないし、そうではない多くの人にとっては、ほとんどテストは書いていないんじゃないかな。 実は、テストを書くのは結構工数かかるんですよ。スクリプト言語は、コンパイラがミスを教えてくれることはないので、Javaと比

現在のS2AOPでは、pointcutを指定しない場合、そのクラスが実装しているインターフェースのメソッドがすべて対象になります。 インターフェースありきの開発なら、便利な仕様だと思うのですが、今後の主流になると思われる暗黙的インタフェースを使うとなると、いちいちpointcutを指定しなければいけないのが不便です。単に不便なだけではなく、pointcutを指定する場合は、メソッド名が一定のパターンで記述していなければならず、AOPのためにメソッド名に制約が入るのもおかしな感じです。 暗黙的なインターフェースの詳細はこちら。 Seasar 2.4.18から、暗黙的インターフェースに対応するために、pointcutを指定しない場合、実装しているインターフェースのメソッドがないなら、Object.classに属さないpublicでfinalではないすべてのメソッドを対象にするようにしました。

何をもって10倍と言うのか、、、と思ったんだけど、 何に比べて生産性が10倍かというとJava標準のJPA(Java Persistence API)に対してです。 相手が悪い。 JPAと比べてどうするのって思う。 S2Daoと比較することで、S2DaoのユーザをS2JDBCに移行させることにどれほど意味があるのかは疑問です。それで、Seasar2のユーザが増えるわけではないから。 これまで、Seasar2のユーザではなかった人たちが、S2JDBCの生産性の高さに引かれて新規ユーザになってくれるのが望ましいシナリオではないでしょうか。 JPAはJavaの標準だし、比較対照としては妥当だと思います。標準だけど、生産性は高くない。一見簡単そうだけど、はまりどころが多くて結局生産性は悪くなる。だから、生産性を比較しやすいって「ずるい」計算もあります。 jdbcManager.callBySql(