WR blog

via Day by day(2005-05-31)

from Data Crunching: Everyday Help (Books)

Data Crunching covers areas of most interest to working programmers:

Using plain text files > Learning how to use Regular Expressions > Parsing XML using SAX, DOM, and XSLT > Encoding data in binary files > Handling relational databases using SQL >

ふむ。面白そう。

「プログラマの最大の武器は、プログラムを書けることである」とは、わいの親方の言葉であり、とても共感する言葉であるけれども、世間一般的な「SE」と呼ばれる立場の人間が日常の業務において「プログラムを書く」機会は少ない。残念ながら。 テキストエディタを相手にする時間よりも、打ち合わせをする時間、Word/Excelに向かう時間、ミドルウェア・OS等のマニュアルを読む時間のほうが圧倒的に多いのが現実。

ただ、「いざ！」というときはやってくる。 たいていの場合、緊急性が求められ、ミスが許されない状況下である場合が多い。

そう、素振り必要。

心の中で思っていても、考えても、「やる環境」を作るところまでやらないと意味がない。 この本がその助けになれば。

June 2nd, 2005 | Category: Book, Programming | Comments (2)

Practical WebObjects 読書会のみ参加。今月はChapter10. WebObjects In A J2EE World。

シンプルなアーキテクチャでServlet対応できてしまうところに、WebObjectsのスジのよさを感じるわけである。

ただ、あいかわらずマルチスレッド関係の処理に不安が残るわけである・・・。 WWDCに行かれる方は、Chales HillさんにEOEditingContextのLock問題について質問してきてください！(どうやらWWDC@SFにて、Pratical WebObjectsの著者がセミナーをやるらしい)

May 28th, 2005 | Category: Event, Java, WebObjects | Comments (1)

エラーの種類を簡単に。

ビジネスロジックエラー(代替フロー) システムエラー 入力エラー プログラミングエラー 内部状態不整合エラー (他にある?)

ビジネスロジックエラー

ユースケースにおける、いわゆる代替フロー。 残高1000円なのに、2000円引き出そうとしたときの処理フローに相当 機能定義・論理設計・基本設計段階で洗い出される必要がある。 機能の一部として、エラー発生時の処理が明確に洗い出されている必要がある。 アプリケーションは、エラー内容に応じた処理を実行するように実装されている必要がある。

システムエラー

動作環境などが正常に動いていない場合のエラー ATMシステムで、ATMとバックエンドシステムのネットワークが疎通していない場合や、バックエンドシステムにおいて、RDBMSが動作していない場合などに相当 基本設計・詳細設計段階で洗い出されている必要がある。 要件にも依存するが、致命的エラーであることをユーザーに通知できれば良い。エラーの種別毎に処理を行うなどは求められないケースが多い。 適切に不具合情報を入れ込んだロギングが重要。 2重化など、システムエラーが起こる原因自体を排除するor発生頻度を低める取り組みについては、ここでは触れない。

入力エラー

いわゆるvalidationエラー。入力したデータが、まずい場合 (機能定義・)論理設計・基本設計段階で洗い出される必要がある。 金額入力欄にアルファベットが入力された場合など (ビジネスロジックと同様?)

プログラミングエラー

API・クラスライブラリ・フレームワーク・ユーティリティクラスを適切に使用していないために生じるエラー。 基本的に、詳細設計・プログラミング作業中にしか発生しない。 結合テストにおいてこのエラーの発生する可能性を可能な限り低めるような努力がなされていなくてはならない。 DAOにConnectionをsetせずにfindXXX()メソッドを呼んだ場合など

内部状態エラー

主に2種類あると考える（もっとあるかも）

システムが保持するデータの不整合

マスタ不一致エラーとか 主に運用のミスによる

プログラムのロジックバグにより、満たされているべき前提条件が満たされなくなったため発生するエラー

たいていの場合DAOにConnectionがキチンと設定されるが、特定の処理を実行するとDAOにConnectionが設定されなくなり、nullPointerExceptionが発生する 設計・テスト段階で洗い出しに失敗したプログラミングエラーが顕在化したケースと考えることが出来る。

要件にも依存するが、致命的エラーであることをユーザーに通知できれば良い。エラーの種別毎に処理を行うなどは求められないケースが多い。 適切に不具合情報を入れ込んだロギングが重要。 (システムエラーと同様?)

フェーズとエラー種別とエラーハンドリング

フェーズとエラー種別により、適切なエラーハンドリング戦略は異なる。 プログラミングフェーズで好ましいエラーハンドリングと、保守・運用フェーズで好ましいエラーハンドリングは異なる。そもそも出るエラーの特性がまったく異なるのだから、乱暴な比較ではあるのだけれども。

すくなくとも、エラーハンドリングの目的が、「機能仕様を満たす」ことか、それとも、次のアクションを起こしやすくするための単なる「情報提供」か、で、求められる戦略が異なる点は留意したほうが良い。

ツッコミは愛をこめて。

artonさんの日記のやりとりに刺激されて、妄想含みで書いてみた。乱文失礼。

May 22nd, 2005 | Category: Programming | Leave a comment

from S2.2.9 リリース - koichikのひとりごと

例えば XA に対応した Oracle (Oracle が提供する XADataSource を使用する) と対応していない HSQLDB (S2 が提供する XADataSource で XA をエミュレートする) を同一のトランザクション中で更新する場合，最初に HSQLDB からコネクションを取得することで，二つの DB がどちらもコミットされるかどちらもロールバックされるかという原子性 (ACID の A) が実現できます．

なるほどーそういうことか。理解できました！ ありがとうございます！ koichikさん。

昨日の質問

昨日のJ2EE勉強会(仮)で、以下の質問をさせていただいた。（若干、わかりやすく整理しています。昨日はもっと要領を得ない質問な感じ（苦笑）でした。）

S2JTAの枠組みの中で、XA非対応のリソースマネージャを扱う場合、XAをエミューレートするラッパ経由で扱うことになるようだが、その場合、

XA非対応のリソースマネージャ1つがJTA配下のトランザクションに参加している場合、1フェーズコミットプロトコルを使用する > XA対応のリソースマネージャ1つの場合、通常の1フェーズコミットプロトコルを使用する > XA対応のリソースマネージャ2つ以上の場合、2フェーズコミットプロトコルを使用する >

という理解でよいか？

なるほど、S2JTAの実装はLast Resource Commit Optimizationの機構を持っているため、 1番目、2番目の内容は正しいようだ。ただ、koichikさんの日記にかかれてあるように、

Last Resource Commit Optimization は，このように複数のリソースがある場合に，最後のリソースに対しては prepare ではなく，通常の 1 [...]

May 15th, 2005 | Tags: Transaction, XA | Category: Java, RDBMS, Seasar | Leave a comment

J2EE勉強会(仮) - ひがやすを blog

参加してきた。

内容は、

Seasar2のJTA実装、コネクションプール実装をソースコード中心に追っかける JSFの特徴・アーキテクチャをPPTで説明する

でした。説明はすべてひがさん。お疲れ様でした＆ありがとうございました。

May 15th, 2005 | Category: Event, Java, Seasar, Web, WebObjects | Leave a comment

仕事を終えてから、明日のズラ会に備えてファミレスでJava Transaction Processingを読んでいた。 いつもと同じように、X31と書見台：ほんたった、ポストイットがお供。 そして、本の内容や目次、不明な用語などをExcelにまとめつつ、読み進めた。

この本の対象はトランザクションという分野であるため内容が多少概念的だし、英語で書かれているから、読むのにちょっと時間がかかる。今日は無理に読み進めることはせず、JDBCとXAResouceの関係、JTAの代表的なインタフェースであるUserTransaction, TransactionManager, Transactionの関係と、UserTransactionとTransactionManagerの相違点に触れている箇所を抜粋して読んだ。 これらの位置づけを大体理解したので、明日のズラ会で不明な点、理解があいまいな点がクリアになることを期待しようかなと。

さて、本題。

自分は、よくファミレスで本を読むのだけど、そのときは、

Thinkpad X31をたたきながら、 本を書見台：ほんたったに載せて、 ポストイットを手元に置いて

という感じでやっている。結構大掛かりな感じであって、ちょっと目立つ。でも便利なので、気にしないことにしている。

当然、今日もこんな感じでやっていた。

今日は遠くから熱い視線を感じる・・・。と思ったら、遠くの席の外人さんにチェックされているようだ。 そんなに物珍しいかね？ ま、気にせずに本を読んでいたのだけど、2時になったので帰宅することにした。 レジに向かう途中、その外人さんが近寄ってきて、たどたどしい日本語で・・・

May 14th, 2005 | Category: Java, RDBMS | Comments (2)

さて、土曜日までにどこまで読めるかなー

May 12th, 2005 | Category: Book, Java | Leave a comment

構造化分析・プログラミング - ひがやすを blog

先に取り上げた、いがぴょんさんのエントリに対する ひがさんのコメントと、実装スタンス。

OCPを守るために、くーすでどうしているかというとロジック(メソッド)は常にインターフェース経由で呼び出すようにします。あるロジックが別のロジックを呼び出す必要があった場合、DIコンテナによってロジックオブジェクトをDIしてもらい、それを利用するのです。

文章だけだと、やっぱりわからない部分が残る。しょうがない。

ただ、外から見ていると、なんとなく、立ち位置や価値観が違うところもあれば、単に表現上の問題でミスマッチがおきているところもあるように感じられる。 もちろん、これは単なる勘だけど。

感謝したい。

あらためて思うのだけど、こういうやり取りを直接読めること、そのものに感謝したい。

少し前は、第一線で活躍する一流デベロッパの意見を聞くことは非常にむずかしかった。 イマイチ信用してよいのかどうかわからない専業ライターさんと、何をたくらんでいるのかわからないエバンジェリストもしくは社長さんぐらいからしか、情報を得ることができなかった。

われわれは幸せな時代にすんでいる。 第一線で活躍する一流デベロッパのソースを読み、開発に対する考えを聞くことができるのだから。

May 12th, 2005 | Category: Modeling, Programming | Leave a comment

職場で設計に関する議論があり、自分がJavaのメモリモデルを理解していないことを痛感させられた。 というわけで、

Javaの理論と実戦: Javaメモリ・モデルを修正する　第1回 dW : Java technology : Javaの理論と実戦: Javaメモリ・モデルを修正する　第2回 Java言語規定 スレッド及びロック

などを読んで学習。メインメモリとローカルメモリの同期をとることが肝要と理解した。

Java言語仕様は、メモリモデルと呼ばれる、いわゆるRAM、キャッシュ、レジスタなどなどから構成される実際のマシンのメモリを適切に抽象化したモデルを用い、そのモデルがどのような要件を満たさねばらないか？を規定している。あくまでもモデルに対する要件のみを規定しているため、実際のマシンアーキテクチャから、比較的独立性を確保することができる。という仕組みになっているようだ。誰が考えたか知らないが、うまい仕組みだ。モデルの適切な定義・モデルの適切な利用と感じられる。

さて、この作業を通じて改めて思うのは、Whatを正しく知るためにはHowを知らなくてはならないということである。ある概念を、自然言語や類似の概念でいくら説明されても、詳細は理解できない。「それがどうやって実現されるか」を知らなくては、概念をキチンと理解できないのだ。

この例でいうと、プログラミング言語がどのような機能性を果たしているかを説明するためには、プロミング言語の処理がどのように実行されるかを知らなくてはならないということになる。

ただ、このWhatとHowの関係で注意していただきたいのは、Howを説明するときに使用する下位の概念の抽象度・詳細度である。 Howはある下位の概念を用いて記述されなければならず、かつ、問題を説明するのに適切なレベルで詳細な概念を用いて説明しなくてはならない。Howを説明する際に用いた概念が詳細すぎては、Howが複雑になりすぎて、Whatを理解することが難しいことは容易に理解できるだろう。

What -> How -> What -> …

無限ループ・・・。

オチはない。

May 10th, 2005 | Category: Java, Think | Leave a comment