最近の調査と検討で、方向性が見えてきたと思う。だが攻略したわけではない、学ぶべきことは山ほどある。 頑張ろう･･

MicrosoftのMSDNにpatterns&practicesというソフトウェアアーキテクチャのリファレンスがあるが、その関連サイトでRIA(リッチインターネットアプリケーション)の設計構造について解説されていた。 [Google先生の翻訳] Google 翻訳 [原文はこちら] CodePlex A…

JAXBは、XMLデータとオブジェクトの相互変換を実現するAPIで、JavaSE6から標準で使えます。API規格自体は結構古くからあったと思いますが、XMLスキーマがどうだとかの説明が鬱陶しくて、何気に敬遠していた感がありました。JAXB2.0よりアノテーションによる…

これではユーザが離れてしまうのではないだろうか？

遅ればせながらDomain Driven Designが熱い、まだまだ理解が全然足りないがOOの現時点での集大成的なものを感じている。 マーチン･ファウラーのDDDについての考察 EvansClassification InfoQのDDDについての実践的な構築方法 ドメイン駆動設計・開発の実践 …

何をするにも、誰かの影響を受けることが大切だと思っている。芸術や音楽でも誰かのマネをすると上達が早い。優れた物を、とことん観察･研究して本質を得てからオリジナリティを出しても決して遅くない。ソフトウェア開発も誰かのマネをしようと思う、正確に…

オブジェクト指向のさまざまな書籍の中で「バリューオブジェクト」というのが紹介されています。Effective Javaに不変クラスとして詳しく解説されています。これまで私はオブジェクトが可変か不変かを、あまり考慮していませんでした。まだまだ学ぶべきこと…

Eric EvansのDomain Driven Design(ドメイン駆動設計)というソフトウェアパターンの書籍は海外では超有名らしいですが日本語翻訳版はありません。しかし、その要約本の日本語版のPDFがダウンロード出来ます。 Domain Driven Design（ドメイン駆動設計） Quic…

SpringとHibernateのソースコードを読んでました、Java2SEのソースコードも真剣に見てなかったので遅ればせながら読んで行きたいと思います。java.util.Listの作者が「Effective Java」のJosh Blochだった、Javaも人が作っているんだと改めて感じた。

マーチン･ファウラーのPofEAAを読んでました、いろいろと考えさせられることが多かったです。先人の知恵から学ぶ姿勢が大切だと思いました。私はこのブログをいろいろな目的で使用しています、文章を断定形式で書くのは自分の考えを整理する為です。そして毎…

準備していたパーツが連結しだした感じがする。階層モデルと関係モデル、どちらも必要な抽象概念だと思う。 そうだ、抽象的な関係モデルという考え方はイケルのではないだろうか？

OOのUMLとRDBのER図、どちらもシステムの抽象概念をモデリングすることが出来ると思う。ここに来て、UMLでシステムの概要を検討しながらクラス仕様に落としていく行為と、データ構造をシンプルに表したER図を徐々に具体化してデータベーススキーマに落として…

やはりデータモデリングは重要だと思う、RDBやSQLはそんなに苦手ではなく、むしろ好きな分野だが、まだ知識と実践が足りていない。OOAと並行してDOAに取り組む必要がある。

オブジェクト指向プログラミングのお作法が載っている、沢山のコードを書いてしまう前に読んでおくべきだったと後悔している。インタフェースを型として優先して使用すべきとの明快な解説は、心の靄が晴れた気持ちになった。プログラミング全般のあらゆる場…

作業が溜まってきている、もう少しスピードを上げないと･･ だが焦る必要はない確実に進んでいる、コンセンサスを少しずつ得る作戦で行こう。割り込みが発生しない貴重な時間を有効に活用しなければいけない。

Linuxサーバ上に公開されている画像ファイルがあったとします、そのファイルを絶対にcpで上書きしてはいけません！鉄則です、mvで書き換えましょう。

うーん、なんとかならんのか。

システムのログ出力は非常に重要だと思う。エラーは仕方ないが何か痕跡を残してくれるとありがたい･･

RDBでは"多対多" のリレーションシップを使用しますが、その2つのテーブルの主キーを外部キーとして格納するテーブルを接合テーブルと呼ぶそうです。ある案件の画面設計だけ見せられてRDBのテーブル構造を設計しましたが、上記みたいな接合テーブルが何で必…

そして自分の行動を省みることが必要だと思う、また未来の自分の姿を想像することも非常に大切だ。 今日は何を成し遂げ、そして明日は何を成すべきか？ 常に自問する必要がある。

関心ごとへのアンテナを常に張っておくのは非常に重要だと思った、そしてリサーチを怠ってはいけない。1つの技術体系、言語にこだわっても得られることは知れている、異文化コミュニケーションが大切なんだ。 一見無関係な物事のつながりや類似性を探し、そ…

明日も頑張ろう

なぜ必要かを問いただしてみることが重要だ、なぜなら何が問題かを明確にしないと意味が無いからだ。 時には立ち止まって周りを見渡そう、今までと違った感覚がしないかい？ なんでこんな事に気付かなかったんだろう？ そんな繰り返しが大切だと思う。

MVCに対して違和感がある、概念が統一されていない。なんでこんなことになっているんだろう？

無理にMVCアーキテクチャに当てはめる必要はないかもしれない。欲しいのはプレゼンテーションレイヤとドメインレイヤの分離なんだ。

MVCアーキテクチャをObserverパターンの実装から考えた場合、Modelオブジェクトがクライアントから起動されるべきだと思う。 MVCを処理(Model)･出力(View)･入力(Controller)のレイヤ分割として捉える クラス図 ModelはView･Controllerに依存しない、Subject…

答えは1つではない。

MVCがObserverパターンで実装されることに疑問を感じた、GoFのObserverパターンはSubjectのメソッドから起動されるはずだ。 MVCアーキテクチャをObserverパターンで実装する場合、ModelがSubject役だ、ClientからはModelのメソッドから起動されるべきではな…

MVCアーキテクチャ(パッシブモデル版) クラス図 シーケンス図 Controller event：イベントを起動します View display：何らかの出力処理を実行します Model service：ロジックを実行します getState：データを返します 思ったこと UI処理に限定した話ではな…

MVCのプリミティブなクラス図 ビューとコントローラの両方がモデルに依存しています モデルはビューとコントローラのどちらにも依存していません 入出力と処理を分割している図と捉えます プレゼンテーションロジックをビジネスロジックから区別する為の基本…