Engineer-Soul Archive

Heroku

Heroku はRubyで作成したWebアプリケーションをホスティングしてくれるサービスで、Ruby On Railsを無料で動作させることができます。

Heroku上に作成したGitのリポジトリに対してcommitを行うと、Heroku側で処理がフックされRailsがデプロイされるようになります。

2010年6月1日現在、Heroku上ではRuby1.8.6、Ruby1.8.7(beta)、Ruby1.9.1(beta)を使用することができます。また、Rails3で作成したWebアプリケーションを動作させることができるようになっています。

この記事では、Heroku上でRuby1.9.1(beta)を使用し、Rails3をデプロイするところまでの手順をメモしておきます。

※ Heroku 上で動くサンプルアプリ作りました。 Kaffetter（カフェッター） http://kaffetter.heroku.com/

Heroku でアプリを動かす手順

• Herokuでアカウントを作成する
• gemでheroku managment APIをインストールする
• ローカルにRails環境を構築する
• gitでHeroku上のリポジトリにコミットする

この記事を書くのに使った環境

• Mac OSX 10.6.3 Snow Leopard
• Git 1.7.0.3
• Ruby1.9.1
• Rails 3.0.0 beta3
• gem 1.3.6

技術メモ用のエントリ

技術者の宝石箱の続きエントリ

Struts2 は WebWorks2 をベースとした MVC フレームワークです。Struts1 と変わらずコマンドパターンのフレームワークになっています。

コマンドパターンの実装部分では、OPENSYMHONY の XWork が使われています。

Struts2の特徴

• WebWorks の後継となる WebWorks2 がベースの MVC フレームワーク
• コマンドパターンが使われている（XWork が使われている）
• アノテーションと XML ファイルによる設定
• ActionForm がない。代わりにアクションにフォームデータを格納する
• アクションは POJO で作成できる
• アクションがスレッドセーフ
• 設定ファイルに OGNL 式が書ける
• View に JSP、Freemaker、Velocity、XSLT が使える
• SpringFramework との連携が考慮されている
• Ajax をサポートしている
• プラグインによりフレームワークの拡張が行える

情報が正確ではない可能性が大いにあるので（ドキュメント読まずにソース見ながら書いているので・・・）、鵜呑みにしないでください。

随時更新予定です。

WebLogic9.2J でカスタムキーストアを使ってSSL通信を行うおぼえがきです。

使用した WebLogic は、下記のサイトからダウンロードしました。

日本BEAシステムズ株式会社 Evaluation Center

技術者として、気づいたこと、感じたこと、困ったことなどを書き連ねていこうと思います。この先気づいたことがあれば増やしていきたいとおもいます。

間違いなどあると思います。業務で利用する場合、そのまま鵜呑みにしないようにお願いします。できるだけ責任のある情報を載せたいと思います。訂正等ありましたら、ご連絡いただけると幸いです。

技術メモ もあります。

自分用の Eclipse 開発環境メモ。『Web+DB Press vol.35 の実演テスト駆動開発』 を読んで、自分用の開発環境テンプレートを作ろうとやっと決心したので ( ..)φメモメモ （といっても、ほとんど記事の内容そのままだけど）

ちなみに、TDD（Test Driven Development: テスト駆動開発） の利点は、「テスト可能なコードになる」、「コード利用者の視点を得る事ができる」、「インターフェースと実装を分けて考えることができる」。 2番目のコード利用者の視点を得ることができるというのに特に共感できる。自分の中で、インターフェースはユーザ（コードの利用者）が決めるものだ！というポリシーがあるので。t-wadaさんには、一度だけお会いしたことがある（名刺交換だけだけど）。

EJB3.0 を使ったプログラミング覚書です。EJB3.0は Hibernate、TopLink、SpringFramework の良いところを取り入れた、次期バージョンのの EJB です。

EJB3.0 は、EJB2.1 の問題点をいろいろと改善し、ほぼデフェクトスタンダードと言える Hibernate や SpringFramework などのフレームワークを参考にした機能を、標準化しています。

また、POJO の採用によるテストの効率化アップなど、 Ease of Development（EoD : 易しい開発）を追求しています。

Ejb3.0 は、次のような特徴を持っています。

• Java Persistence API（JPA : 永続化 API ）による永続化フレームワークの標準化
• アノテーションの採用
• デフォルト値の多用
• POJO のサポート、EJB インターフェースからの開放
• Dependency Injection（DI : 依存性の注入）の採用

Ejb3.0 の覚書をチョコチョコと書いていこうと思います。

『30日でできる！OS自作入門』 の覚書です。

本書を読んでいて気になったこと、整理したいことをメモしていこうと思います。ちゃんとした説明は、本書を読むほうが良いと思います。

プログラミングの基礎からはじめて、30日後にはウィンドウシステムを有する32bitマルチタスクOSをフルスクラッチで作り上げるという入門書。ビギナーでも無理なく作成できるようPCの仕組み・アセンブラ・Cの解説から始まり、試行錯誤を繰り返しながらアルゴリズムを学びつつ、たのしく自由な雰囲気でOSをゼロから構築していくという、他に類を見ない手法による、趣味と実用と学習を兼ね備えたOS作成の入門書です。

「Amazon 出版社コメント」

Portal Bridges は、Portlet 以外で作られた Web フレームワークと、JSR-168 に準拠した Portlet を橋渡しするライブラリです。The Apache Software Foundation によって提供されています。

今回の覚書では、Portal Bridges の中の Struts Bridges について書き留めておきます。

ちなみに、対応している Struts のバージョンは、1.2.4 と 1.2.7 だそうです。

Apache Pluto の覚書きです。Apache Pluto は、Java Portlet 仕様 のリファレンス実装です。この覚書きを書いている段階では、Java Portlet Specification (JSR-168) が Java Portlet 仕様として、まとめられています。

この覚書きで使っている環境は次の通りです。

• Eclipse 3.1.2
• Pluto 1.1 (alpha release 以前)
• Tomcat 5.5.9
• J2SE 5.0

参考にしたリソースは次の通りです。

• Java Portlet Specification Version1.0 (JSR-168)
• Developing Portlets with Apache Pluto

Pluto の中を追っていったときの覚書です。ソースコードを手元に読んでいただければ、より理解できるのではないかと思います。

間違い等に気づいた方は、ご連絡いただけると助かります。

Apache Pluto の覚書きです。Apache Pluto は、Java Portlet 仕様 のリファレンス実装です。この覚書きを書いている段階では、Java Portlet Specification (JSR-168) が Java Portlet 仕様として、まとめられています。今回は、Java Portlet Specification を読んだ覚書きを記録していこうと思います。その後で、Apache Pluto を触った覚書を記録していこうと思います。

この覚書きで使っている環境は次の通りです。

• Eclipse 3.1.2
• Java Portlet Specification Version 1.0
• Pluto 1.1 (alpha release 前のもの)
• Tomcat 5.5.9
• J2SE 5.0

参考にしたリソースは次の通りです。

• Java Portlet Specification Version1.0 (JSR-168)
• Developing Portlets with Apache Pluto
• ONJava.com - What Is a Portlet, Part 2

間違い等に気づいた方は、ご連絡いただけると助かります。（英語が苦手なもので --;）

Click は、J2EE Webアプリケーションのフレームワークです。ページ指向 + イベントドリブン なプログラミングスタイルでアプリケーションを開発します。Velocity を内部で使っていて、テンプレートモデルで、ページを作成します。

ここでは、Click の覚書きをしておきます。あくまで個人用なので、あてにしないようにお願いします。間違い等発見された方は、ご連絡いただけると助かります。

使用バージョン

• version Click 0.1.8

Clickはドキュメントがしっかりできているので、ドキュメントを読むのが一番です

Hibernate は O/R マッピングツールと呼ばれる、リレーショナルデータベースとオブジェクトモデルとの間を埋めるフレームワークです。

リレーショナルデータベースとオブジェクトモデルとのミスマッチには、下記のようなものがあります。

• オブジェクトの粒度に関する問題
• サブタイプ（継承）に関する問題
• オブジェクトの同一性（識別子）に関する問題
• オブジェクト同士の関連に関する問題
• オブジェクトの検索に関する問題

Hibernateは、このようなミスマッチを解決する方法を提供します。

リレーショナルシステムにおけるテーブル形式のデータ表現は、オブジェクト指向のJavaアプリケーションで使用されているオブジェクトのネットワークとは根本的に異なっている。この違いが、いわゆるオブジェクト/リレーショナルパラダイムのミスマッチだ。

『Hibernate イン アクション』はじめに より

JSFでカスタムコンポーネントを作るときの覚書きです。参考にした『JavaServer Faces完全ガイド』は、ツリーコンポーネントをカスタムコンポーネントとして作る手順が載っていました。

ここでは、カスタムコンポーネントを作るときに必要となるパーツと、注意点などをまとめておこうと思います。カスタムコンポーネントは大きく、入力用のコンポーネントと出力用のコンポーネントの2つに分けれます。入力用のコンポーネントはリクエスト間で値の保存・読み込みやデコードレンダリングなどを行わなければなりません。出力用のコンポーネントの場合は、値を保持し、エンコードレンダリングを行うことで機能を表現します。

ここでは、出力用のコンポーネントの話をしています。説明が断片的なので、上記の本を読んだほうが手っ取り早いかも・・・ ^^;

Unix,Linuxで使えるコマンドラインの覚書です。使えそうなコマンドがあれば、随時更新していこうと思います。もし、間違いなどありましたら、連絡いただけると助かります。

申し訳ないですが、コマンドを実行した結果は保証しません。ご自分の責任でお願いします。 <_(_ _)_>

概念モデリングでは、「関連」と「多重度」がモデルを読むときに大切な要素となります。

関連は、あるエンティティとエンティティを結ぶ線のことです。しかし、今回は、もう一歩進んだ関連の使い方である、「関連の属性のクラス」と「関連のクラス」の違いを整理したいと思います。

もう一つの目的として、「多重度」の見方も整理したいと思います。「種類(品目)と物(特定品目)」の多重度の違いを理解できればと思います。

Hibernate は O/R マッピングツールと呼ばれる、リレーショナルデータベースとオブジェクトモデルとの間を埋めるフレームワークです。

O/Rマッピングを行うとトランザクション制御をあまり考えなくてもいいような気になってしまう感があります。でも、トランザクション制御って非常に大切な要素です。しかも、O/Rマッピングを行っていようと、トランザクションのことを何も考えていなければ、データの不整合が起きる可能性もあればデッドロックが起きる可能性もあります。

JDBCを直接扱う場合は、まだトランザクションを気にしながらコーディングする方なのでいいのですが、O/Rマッピングを使う場合に忘れがちなトランザクションのことを、ちょっとでも頭にとどめておくためにメモ程度に記録しておきます。(間違いを見つけたらコメントください)
+ Hibernate Reference 3.0

設計やプログラミングを行う上で、覚えておいたほうがいいことなどをメモしておこうと思います。意見などありましたら、コメント等でご連絡ください。随時、更新予定です。

適用、引用による効能は自己責任でお願いします。

大学で、SELinuxの講習会をうけたので、そのメモです。かなり基礎的な部分の説明で、アクセス制御の部分を集中的に教えてもらいました。

セキュアOSと呼ばれるOSの中でも、フリーで手に入るSELinuxは今後かなり注目されそうです。今日は、アクセス制御の仕組みとロールの付与の仕方について勉強しましたが、そのほかにもいろんな機能がある様子。詳しくは、『SELinux徹底ガイド』を読むのが良いらしいです。(宣伝宣伝っと 笑)

セキュアOSとは何ぞやって事とSELinuxのアクセス制御(Type Enforcement)の方法、セキュリティ属性、Role-Based Access Control あたりをメモっておきます。かなり適当なメモなので、読むだけだと分からないかも・・・。『SELinux徹底ガイド』買おっかな。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。
GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

16番目のパターンは実行可能なアクション(コマンド)をオブジェクトとして扱い、コマンドの詳細をカプセル化するCommandパターンです。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。
GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

15番目のパターンはデータ構造と振る舞いを分離して、振る舞いを実行するクラスの変更や拡張を可能にするVisitorパターンのメモです。

Javaの新バージョン「J2SE5.0 Tiger」の新機能のメモ。詳しい使い方などは、参考文献や他のサイトをご覧ください。

J2SE5.0 Tiger では、言語構文が大幅に追加されています。Generics や オートボクシング、Enum(列挙型)、可変長引数、アノテーション、拡張for ステートメント、Static インポートなど、目を見張る機能がたくさん付け加わっています。

J2SE5.0 Tiger は、EoD (Easy Of Development) を行うための道具です。今後はさらに普及してきて、J2SE1.4 に確実に置き換わると思います。今のうちに概要や変わったところをチェックしておくのがいいと思います。

Hibernate は O/R マッピングツールと呼ばれる、リレーショナルデータベースとオブジェクトモデルとの間を埋めるフレームワークです。

関連するテーブルのオブジェクトを管理する方法が、十数種類あります。Index of Relationships のサイトに、Hibernate でサポートされる関係の一覧が載っています。非常に分かりやすかったのですが、さらに理解を深めるために、車輪の再発明をしてみようと思います。

こちらのサイトでも、体験記 と言うことで、おんなじことしていました。参考にします。さらに、「Hibernate 入門記 - koichik」 はすごい ・・・ (^^;

Hibernate は O/R マッピングツールと呼ばれる、リレーショナルデータベースとオブジェクトモデルとの間を埋めるフレームワークです。

関連するテーブルのオブジェクトを管理する方法が、十数種類あります。Index of Relationships< のサイトに、Hibernate でサポートされる関係の一覧が載っています。

ドキュメントも豊富にそろっていて、リファレンスマニュアル (日本語翻訳済み) が非常に参考になります。マニュアルの中から、気になった部分や使えそうな部分だけを抜き出しておきます。

Hibernate は O/R マッピングツールと呼ばれる、リレーショナルデータベースとオブジェクトモデルとの間を埋めるフレームワークです。

Hibernate は独自のオブジェクトクエリ言語 HQL を使って、非常にハイパフォーマンスな検索を可能にしています。それだけでなく、高度なキャッシュ機構など、実行時のパフォーマンスを向上させる機能が盛りだくさんです。

ドキュメントも豊富にそろっていて、リファレンスマニュアル (日本語翻訳済み) が非常に参考になります。マニュアルの中から、気になった部分や使えそうな部分だけを抜き出しておきます。

Dependency Injection (DI) は、「依存性の注入」という言葉で最近話題になっています。「EJB は重過ぎて使えない」とか「軽量コンテナは疎結合だからすばらしい」といった声をよく聞くようになりました。

Dependency Injection (DI) はサービスコンポーネント間の関係を疎に保ったままアプリケーションを構築するというものです。「設定を利用から分離する」という原則が、DIの本質です。

いろんな書籍が出始めてきた中で、依存性注入の何がステキなのか、疎結合だと幸せだよねといったことは非常に良く分かるようになりました。それでも、自分の中で何かしらの引っ掛かりがあります。それをつらつら書き連ねてしまおうかと思っています。

アメリカではほとんどデフェクトスタンダードとなっている「Spring Framework」の覚書きです。Spring は簡単に言うと、IoC (制御の反転)、またの名を DI (依存性注入) という仕組みを取り入れた軽量コンテナです。

AOP(アスペクト指向プログラミング) はクラスの直接的な責務ではない、各モジュールから共通で使われる処理を、独立して切り出す手法です。「クラスの直接的な責務でない」とは、例えば「ログ」や「トランザクション」、「認証」などです。多くのクラスに重複コードが生まれてしまうような処理は、アスペクト(横断的関心事) として別のモジュールにしてしまうという手法をとることが出来ます。Spring AOP は、このアスペクトを扱うものです。
参考：『AspectJによるアスペクト指向プログラミング入門』 ソフトバンクパブリッシング
　
Springの詳細については、ほかにもっとよいサイト(Spring-Java/J2EEアプリケーションフレームワークリファレンスドキュメントやSpringフレームワークの紹介)があるので、そちらを参考にしてください。ここでは、Springを使っていて、ハマった点や気になった点などをメモしていこうと思います。随時更新していくつもりです。間違っている可能性が高いので、気になる点があればコメントをお願いします。

アメリカではほとんどデフェクトスタンダードとなっている「Spring Framework」の覚書きです。Spring は簡単に言うと、IoC (制御の反転)、またの名を DI (依存性注入) という仕組みを取り入れた軽量コンテナです。

Springは MVCフレームワークを提供しています。Springのフレームワークは、すべてインターフェースベースになっているので、単一継承の JAVA にとっては非常にありがたいものです。Spring MVC の View には、JSP の他、Velocity、XSLT、JSFなどといったさまざまな技術が使えます。

Validation 機能は、Web システムにとって非常に重要なものとなっています。Springでは、 Validation は Web パッケージと切り離されているので、単体テストも簡単に出来るようになっています。

Springの詳細については、ほかにもっとよいサイト(Spring-Java/J2EEアプリケーションフレームワークリファレンスドキュメントやSpringフレームワークの紹介)があるので、そちらを参考にしてください。ここでは、Springを使っていて、ハマった点や気になった点などをメモしていこうと思います。随時更新していくつもりです。間違っている可能性が高いので、気になる点があればコメントをお願いします。

アメリカではほとんどデフェクトスタンダードとなっている「Spring Framework」の覚書きです。Spring は簡単に言うと、IoC (制御の反転)、またの名を DI (依存性注入) という仕組みを取り入れた軽量コンテナです。

Springはとても抽象化した方法で、トランザクション管理を行います。抽象化というのは実装に依存していないという意味です。アプリケーションサーバが持つトランザクション機能や、 JDBCのようなリソースを使った DataSource に関しても、共通の方法でトランザクション管理を提供しています。

Springの詳細については、ほかにもっとよいサイト(Spring-Java/J2EEアプリケーションフレームワークリファレンスドキュメントやSpringフレームワークの紹介)があるので、そちらを参考にしてください。ここでは、Springを使っていて、ハマった点や気になった点などをメモしていこうと思います。随時更新していくつもりです。間違っている可能性が高いので、気になる点があればコメントをお願いします。

アメリカではほとんどデフェクトスタンダードとなっている「Spring Framework」の覚書きです。Spring は簡単に言うと、IoC (制御の反転)、またの名を DI (依存性注入) という仕組みを取り入れた軽量コンテナです。

Springは JDBCを抽象化した層を持っています。JDBCを使ったプログラミングで、共通化できる部分や、煩雑な部分をすっきりとした統一的な方法でアクセスできる手段を提供してくれます。

Springの詳細については、ほかにもっとよいサイト(Spring-Java/J2EEアプリケーションフレームワークリファレンスドキュメントやSpringフレームワークの紹介)があるので、そちらを参考にしてください。ここでは、Springを使っていて、ハマった点や気になった点などをメモしていこうと思います。随時更新していくつもりです。間違っている可能性が高いので、気になる点があればコメントをお願いします。

アメリカではほとんどデフェクトスタンダードとなっている「Spring Framework」の覚書きです。Spring は簡単に言うと、IoC (制御の反転)、またの名を DI (依存性注入) という仕組みを取り入れた軽量コンテナです。

Springが他のIoCコンテナと差別化を計っている点として、「ビジネスオブジェクトを管理する方法にフォーカスを当てている」という点があります。また、「レイヤー化されたアーキテクチャであるため、局所的にSpringアーキテクチャを利用できる」、「テストドリブンプロジェクトに理想的なフレームワークになるように設計されている」という利点があります。

Springの詳細については、ほかにもっとよいサイト(Spring-Java/J2EEアプリケーションフレームワークリファレンスドキュメントやSpringフレームワークの紹介)があるので、そちらを参考にしてください。ここでは、Springを使っていて、ハマった点や気になった点などをメモしていこうと思います。随時更新していくつもりです。間違っている可能性が高いので、気になる点があればコメントをお願いします。

『REFACTORING TO PATTERNS』から、場合別リファクタリングカタログのメモです。本書は『リファクタリング―プログラムの体質改善テクニック』の続編になっています。

例のごとく、自分で読み直したときにどんな場合にどのリファクタリングが使えるかのメモにしようと思ってます。2005年中くらいには、本書の和訳が出版される予定です。

現在、洋書読破中。記事もそのつど更新していくつもりです。(最終更新日：2004/10/29)

本家サイトはこちらになります。カタログ一覧あります。

Refactoring To Patterns

最近、ドメインモデリングと業務アプリケーション開発がちぐはぐだなーと感じます。たぶん色々な開発者が感じていると思いますが、業務アプリケーションというのは、得てして「データの出し入れが基本」となるシステムになります。ビジネスロジックがふんだんに盛り込まれた業務システムというのはあまりありません。

「データの出し入れ」が基本ということは、データの格納庫が必要になってくるわけで、それがデータベースになります。最近ではオブジェクト指向データベースも使われ始めましたが、まだまだリレーショナルデータベースの方がよく使われています。

オブジェクト指向で開発していると、ほとんど必ず問題となるのが、リレーショナルデータベースとオブジェクト指向のインピーダンスミスマッチです。データベースは「データ」を扱い、オブジェクト指向は「振る舞い」を扱います。つまり、「振る舞い」をいかにして「データ」に落とすかというのが、問題となるわけです。

最近では、「DAO(Data Access Object」パターンや「O/Rマッピング」というものを使い、オブジェクト指向とリレーショナルデータベースの差を埋める努力がされています。DAOとO/Rマッピングをまとめつつ、業務アプリケーション開発で思ったことを書いていこうと思います。かなり主観的な意見になります。

ドメインモデリング

簡単に言うと、システム要件から問題領域(医療システムであれば医学、とか)の用語を抜きだすこと。さらには、抜き出した用語の必要性や重要性、独立性などを考慮してオブジェクト間の関連をモデル化すること。

ビジネスロジック

ワークフローやUMLのアクティビティー図で分岐処理を行うこと。

「JUnitでユニットテストをするときに、クラス間の関係が問題でテストできない。」なんて事ありませんか？ TDD(テスト駆動開発)で行っている場合は、クラスの関係をそのつど考えながら進めていくので、こういった問題はあまり起きません。しかし、TDDはまだまだ敷居が高いと思う開発者が多いように思います。

テスト駆動開発考察

djUnit を使うと、Virtual Mock Objectsという手法を用いて、クラス間の関連を裏技的に変えることが出来るようになります。つまり、クラスがどんなに複雑に絡み合っていても、それらをすべて無視してテストが出来るようになるのです。さらには、『JCoverage』というツールを使ったカバレッジテストの結果をエディタ上で見ることが出来るようになります。

djUnitは JUnti の機能と Aspect の機能を併せ持ったユニットテストツールとなっています。

Antはビルドツールです。OSや環境に依存しないビルドツールということで幅広く使われています。

個人的にAntを使う理由というのは、ビルド以外のいろんな設定が簡単に出来ることです。例えば、環境ごとに異なった設定ファイルを作りたいときに、ベースとなるファイルを一つ用意するだけで、Filterという機能を使って設定ファイルの内容を変化させることが出来ます。

他にも、JUnitを使ったときに、Reportを自動で生成する機能や、Webアプリケーション用のwarファイルを作りそのままデプロイしたりと、色々なことが連続的に出来るのが気に入っています。作業と作業の間に人の手を入れずに実行できるので、作業忘れが発生しないというのが特徴です。　

JSFは今後期待されるWebアプリケーションフレームワークの一つです。標準規格ということで、普及してくるのではないかと思います。

JSFはユーザインターフェース周りの処理を簡単に実装できるということを目標に開発されたフレームワークで、WebでGUIアプリケーションを作っているような感覚でコーディングが出来ます。

アクションやイベントといった概念を扱っていて、非常に直感的に流れが分かるようなフレームワークになっています。ということで、今回はJSFフレームワークの流れについての覚書きです。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。
GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

14番目のパターンは観察対象の状態が変化を通知しそれに沿って処理を行うというObserverパターンのメモです。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。
GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

13番目は唯一性を保証するSingletonパターンとは別の方法であるMonostateパターンのメモです。

「7つの習慣」を読み始めました。人生で成功するための原則が書かれているということです。まだ、最初の方しか読んでませんが例のごとく、気になったことや学んだことをメモしておこうかなと思います。

本書の読み方として、読んだことを人に話し、議論するのがいいということでした。そういったことを念頭において読むことで、よりよい理解を示せるらしいです。ということで、早速実践のためにぶろぐの記事を使います。　

まだ最初の方だけしか読んでないのでこれから読み進めていくうちに色々な考えができるようになるかと思います。(というより、なりたい！)

業務でアプリケーションプログラミングを行っている人で、データベースを使わない案件はまれでしょう。ほとんどがデータベースに顧客データを格納したり、マスターデータを引っ張ってきたりするはずです。

そんなデータベースとのやり取りで、SQL文を書いたが、それがほんとうに合っているのか?、単体テスト時にテストデータを毎回手動でデータベースに入れては、プログラムで引っ張ってきた値と等しいかをチェックするのはばかばかしい、データを更新してはみたが、ほんとうに更新されているのかを確認しないといけない、なんて作業はとてもめんどくさくて憂鬱な作業ですよね。

そんな時に威力を発揮するのが、DBUnitという、データベースに関係する単体テストを自動で行ってくれるツールです。
もちろん、どんなテストケースがあるのかは自分で書かなければいけませんが、意図しているデータや、更新されたはずのデータはすべて外部のXMLファイルに書くため、プログラマとテスト実施者が別々に作業することも可能です。

「アジャイルソフトウェア開発の奥義」を読み始めました。最近では、ソフトウェアエンジニアに馴染みが深くなってきた「アジャイル」という言葉ですが目からウロコです。僕は本を読むとすぐに影響されてしまう性質で、哲学書とか開発手法に関する本とかを読むとすぐにやってみたくなってしまう人です。それでも最近は、色々な視点から考えることもできるようになってきたと思いますが・・・。

まだこの本は全部読みきっていないので、書評はまた後で書きます。今は本書を読んで心に残ったことをメモっておきます。( ..)φメモメモ

とりあえず、テストファーストに関してのメモです。テストファーストという言葉をきくとワクワクしてくるのは僕だけじゃないはず・・・。テスト、最高です！

リファクタリングとは「ソフトウェアの外部的振る舞いを保ったままで、内部の構造を改善していく作業」をいいます。と、こんな説明は世の中腐るほど出ています。僕のおすすめの「リファクタリング プログラミングの体質改善テクニック」という本もあります。

ここでは、プロジェクト中のちょっとしたときに、リファクタリングを行えるような覚書きをまとめておこうかと思います。すべてのリファクタリングに先立って自動テストを行うことがリファクタリングの最低条件である。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。
GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

12番目は処理手順やアルゴリズムをスムーズに交換できるようにするStrategyパターンのメモです。

Code Readingを読んで、ループ性能(妥当性)に関しての議論を考えるときに、有効な手段があると書いてあった。「バリアント(variant)」と「インバリアント(invariant)」という概念を使う方法だ。「バリアント(variant)」とは、変わりやすいとか変更されるといった意味を持っている。

逆に「インバリアント(invariant)」は、変わらないとか不変なとかという意味を持っているらしい。

この「バリアント(variant)」と「インバリアント(invariant)」を使って、ループ構造が正しいかを証明する方法が、Code Readingの2章に載っていたので、忘れないうちに復習しておきたいと思います。

それにしても、Code Readingは面白いですね。技術者のツボをついた本だと思います。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。
GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

11個目はインスタンスを新しく作るときに、既存のインスタンスのコピーを作成するPrototypeパターンのメモです。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。
GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

10回目になりました。インスタンスの生成手順や生成内容が複雑な場合に、インスタンス生成作業を軽減するBuilderパターンのメモです。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。
GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

9回目は、抽象概念を用いて、関連オブジェクトの集合を作成するAbstract Factoryパターンのメモです。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。
GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

ついに、1/3を消化しました。
8回目は、機能の拡張と、実装の拡張を別々に管理するBridgeパターンのメモです。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。
GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

7回目、統一された方法で、集合オブジェクトに順番にアクセスするIteratorパターンのメモです。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。
GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

6回目は、機能拡張を統一的な方法で、自由に行うことができるDecoratorパターンです。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。
GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

5回目は、再帰的な概念を表すことに使えるCompositeパターンです。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

今回は、処理の順番を規制するためにつかう、Template Methodパターンです。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。
GoFの23のパターンが有名です。
デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

今回は、インスタンスを一つしか作らせたくない、Singletonパターンです。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。GoFの23のパターンが有名です。

デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

今回は、インスタンスを生成する責務を切り出した、Factory Methodパターンです。

デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。GoFの23のパターンが有名です。

デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

最初は、仕様の違いを吸収する目的で使われる、Adapterパターンです。

JNDIは、オブジェクトに名前をつけて管理するネーミングサービスの共通インターフェースを提供します。JAVAアプリケーションはこのJNDIを使って統一された手法でネーミングサービスにアクセスすることができます。

JNDI(Java Naming and Directory Interface)とは、Javaでネーミングサービスを扱うためのAPIを定めたものです。JNDIが定められた目的はアプリケーションがさまざまなネーミング/ディレクトリサービスを統一的に利用することができるようにすることです。

ネーミングサービスとは、名前とオブジェクトを関連付けて管理するサービスのことです。例えば 管理人 => 「ハマショウというオブジェクト」 というように、管理人という名前をハマショウというオブジェクトに結び付け、管理人 = ハマショウという関連を作ることと説明できます。

15分でWebServiceについて、知ったかぶりできる知識をまとめておきます。

Web Serviceとは

Webサービスとは最近流行の技術の一つです。実は、Webサービスの定義は結構曖昧で、その人や、その時々によってまちまちです。そこで今回はWebサービスを以下のように定義します。

Webサービスとは

「コンピュータが利用可能な、ネットワーク上のソフトウェアコンポーネント」。「コンピュータが利用可能」、「ネットワーク上」、「ソフトウェアコンポーネント」という3つのキーワードがWebサービスの特徴

Sangam(サンガム)とは、リモートでペアプログラミング(通称ペアプロ)をEclipse上で行うためのものだ。
Eclipseのプラグインとして提供されており、リモートでファイルロックと同期を取りながらペアプロを行うことができる。

ペアプロとは、2人1組でプログラミングする方法で、片方がドライバ(プログラミングする方)ともう一方がオブザーバ(見ているほう)という役割を行いながら進めていきます。詳しくはこちらを参考に。

さて、Sangamの話に戻ります。このプラグインでペアプロを行う場合はインターネット越しでも使えるので、会社と自宅とでペアプロを行いたい場合もぜんぜん使えます。

設定項目も非常にわかりやすく、ローカルエリア内で使用する分には、パフォーマンスも気にならない。ネットワークが遅い環境で、サイズの大きなファイルをペアプロするとどうなるかはわからないです。

まずは、Sangamをダウンロードして、Eclipseにインストールしましょう。

自分用のエントリーです。

それはBooks で使っているスタイルの意味を定義しておくページです。