http://itpro.nikkeibp.co.jp/atcl/column/14/346926/040400918/

記事より、「新たな事業形態や開発スタイルに対応」「4月中に予定する新たな開発方法論は、一連の課題を克服したものになる」とあるので、terasolunaフレームワークの開発を活かす為の施策が打ち出されるものだと期待しています。

しかし「現行版のTERASOLUNAが抱える課題の解消を図る」と記事にあるのに、なぜ捨てるという表現を使ったのか・・・このブログのタイトルみたいな感じでいいのに。

＃　インパクトあるニュース見出しにしたかったのか、それとも表に出ていない何かを匂わせているのか。（例えば名称が変わるとか）

◎まずは継承関係確認：JavaDoc

http://terasoluna.osdn.jp/javadoc/server-web_2.0.0.2/jp/terasoluna/fw/exception/SystemException.html

java.lang.Object
  java.lang.Throwable
      java.lang.Exception
          java.lang.RuntimeException
              jp.terasoluna.fw.exception.SystemException

◎Terasoluna 5.7 例外ハンドリング

https://terasolunaorg.github.io/guideline/public_review/ArchitectureInDetail/ExceptionHandling.html

5.7.1.2. 例外のハンドリング方法

の、どのパターンに入っているかでハンドリングが変わるとのこと。

今回は(1)のtry-catchかな。・・・ん？

5.7.2.2.1. ユースケースの一部やり直し(途中からのやり直し)を促す場合

に誘導されてるんだけど、期待するハンドリングは

5.7.2.2.3. システム、またはアプリケーションが、正常な状態でない事を通知する場合

なんだけどな。。。ちゃんと見てみるか。

違うようだ。という検索結果が大半。

風水は統計学なのか？に対して、「風水　統計学」で検索したページを見てみると

そうだ。という検索結果が大半。

なんか違和感。

以下引用

「占い　統計学」

http://constellation.client.jp/uranaito_toukeigaku.html

【統計的方法】　（初等統計学　ポール・Ｇ・ホーエル　培風館）
統計的方法とは、最も広義に定義すれば、数量的データを処理する方法であると言える。

【統計】　（広辞典　　文学博士、宇野哲人編　集英社）
社会、自然の集団に関する現象を分析し、分類してまとめたもの「─学」

【統計学とは】　（はてなダイアリー）
数量的比較を基礎として、多くの事実を統計的に観察し、処理する方法を研究する学問。

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1329235618

皆さんの解答を読むに
「占い」などには何かしらの
「数字」「統計」はあるが
そこから「計算」などは無く、
「占い師」の「経験則」で判断するようですね。

それでは「数字」は、ただ「占い師」の
「看板」です。

http://www.senjutsu.jp/archives/2013/82

全てのデータに、全て同じ占法を使って、同じロジックで、全て機械的に鑑定を進めた結果として記録し続けなくてはなりません。

「○○さんだけ断易や人相も使って鑑定しました」ということは許されません。
データを集めている最中、その占い師さんは進歩しても、退歩してもいけないのです。果たして、実務上そんなことが可能でしょうか？

「風水　統計学」

http://r25.yahoo.co.jp/fushigi/wxr_detail/?id=20150317-00040898-r25

昔の人の経験則に基づく一種の統計ともいうべき側面がありますよ

北の方角は日光が入りにくく、冬には北風が当たります。つまり、夏は湿気がこもりがちで冬は冷える場所。ですので出入り口や、トイレ、風呂などの水まわりを配するとよくない

http://oshiete.goo.ne.jp/qa/194040.html

風水自体は前に回答しておられる方がおっしゃるように中国伝来の一種の統計的地政学だとは思います。

北東の方角は鬼門だとか水回りがどうしたとかいうのは、気候上湿気がたまりやすい場所には台所は作らないようにとか昔の生活の知恵が伝承となっていることがあるので、そういう観点で見て納得のいくものは取り入れるくらいでいいと思います。

占い＋伝承＋地理≒風水（但し科学的根拠に乏しい）というところじゃないですか？

http://fusu.myumic.com/%E9%A2%A8%E6%B0%B4%E3%83%9E%E3%83%A1%E7%9F%A5%E8%AD%98/%E9%A2%A8%E6%B0%B4%E3%81%AF%E7%B5%B1%E8%A8%88%E5%AD%A6.html

風水とは、古代中国の思想です。

2000年以上の間、人間の行動や環境によって

起こる結果を蓄積した統計学なのです。

占の一種だと思ってください。

---

占いと風水が似てる、と思っていたが

占いの一種が風水だと。

統計「学」まではいかなくても、風水は天候と建物を入力としていて

しばらく中国内でとどまっていたのなら、ある程度経験則と根拠が結びつくんだろうなと。

ただ、どこかの方角に何色を置くと金運があがる、というのはサッパリです。

たまたまお金持ちの人の家の内装がそうだったか、何かしらのブームがあったかぐらいじゃないでしょうか。

10年以上前、バラエティのテレビ番組で「ちびまる子ちゃんの視聴率」と「原油価格の推移」が非常に似ていることから

「ちびまる子ちゃんはサダムフセインの申し子だ」のようなトンデモ結論が展開されていたのを思い出した。

つい最近でも水曜日のダウンタウンで「松本人志　ロシアのスパイ説」とこじつけされていましたが、あーいうの誰が見つけるんでしょうね。

5.5章の入力チェックを参考に、情報をざっくりまとめてみたいと思います。

---

5.5.1. Overview

長さや形式など、文脈によらず入力値だけを見て、それが妥当かどうかを判定できる検証

→「入力チェック」

システムの状態によって入力値が妥当かどうかが変わる検証

→「業務ロジックチェック」

と定義し、前者の入力チェックについて説明します（後者はドメイン層の実装をみてね）、とあります。

サーバサイドの入力チェックとクライアントサイドの入力チェックについて、以下のような言及をしています。

・サーバサイドの入力チェック：必須(JavaScripによる改ざん防止のため)

・クライアントサイドの入力チェック：ユーザビリティの向上

5.5.1.1. 入力チェックの分類

単項目チェックと相関項目チェックがあり、特徴を表でまとめています。

単項目は単一項目でのチェック、相関項目は複数項目に相関するチェックという感じです。

実現方法は以下の通りです。

・単項目チェックは「BeanValidation」を使用 (実装ライブラリとしてHibernate Validatorを使用)

・相関項目チェックは、「org.springframework.validation.Validatorインタフェースを実装したValidationクラス」または「BeanValidation」を使用

5.5.2.1. 依存ライブラリの追加

アプリケーションサーバにデプロイして動かす場合は依存ライブラリは追加しなくてよいとのこと。

スタンドアロン環境(JUnitなど)で動かす場合は、これらのライブラリを依存ライブラリとして追加する必要があるとのこと。

必要なものはTERASOLUNAの5.5.2.1を参照ください。

単項目チェックするには、３ヶ所に対して手を施す必要があるそうです。

アノテーションを付与する、という表現に関しては後述にて説明します。

フォームクラス、Controller、JSPについての例が記載されています。

----

フォームについては、下記Appendixを参考にアノテーションを付与してね、と言ってます。

5.5.4.1. Hibernate Validatorが用意する入力チェックルール
5.5.4.1.1. Bean Validationのチェックルール
5.5.4.1.2. Hibernate Validatorのチェックルール

これらのうち、ガイドラインの例では、@NotNull、@Size、@Email、@Min、@Maxを使ってます。

で、この@なんちゃらをアノテーションと呼んでいます。

アノテーションを付与するとは、宣言の前に@なんちゃらを記載することと捉えます。

ガイドラインの以下の例では、 private String name;　の前に、@NotNullと@Sizeが記載されていますね。

付与することにより、様々な入力チェックを実施してくれます。

Hibernate Validatorが準備しているアノテーションの種類と入力チェック内容が、上記Appendixに記載されています。

----

Contollerについては、入力チェック対象のフォームクラスに@Validatedを付けてね、と言ってます。

黄色の部分、UserFormの前に@Validatedがありますね。

----

JSPについては、<form:errors>タグで入力エラーがある場合にエラーメッセージを表示できますよ、と言ってます。

各入力フォームにタグを指定して・・・

すべての入力フィールドを未入力のまま送信すると、以下のようにエラーメッセージが表示されるよ、という例が記載されています。

また、cssを変更することによりエラーメッセージの出力方法を変えられる、とも言っています。

上記のように一覧で表示する場合「標準では出力順序を制御できないから、入力フィールドの横にエラーメッセージを出すことを推奨する」とあるけども

入力項目が多い場合とか他の画面との一体感の兼ね合いで、必ずしもそうではない、とは思ったりします。

5.5.2.2.2. ネストしたBeanの単項目チェック

基本的には

・Formのすべての項目にアノテーションを用意して

・JSPのすべての項目に<form:errors>タグを付ける

というのが上記の例です。

しかし、あるFormAから別のFormBを複数呼び出すときに

ネスト先のFormBの項目にアノテーションを付与すれば、FormA側のアノテーション宣言は不要になります、と言っています。

例えば、注文フォームに送り元住所と送り先住所があり、それぞれ同じ入力項目欄を準備する場合

住所フォームを用意し、送り元と送り先に同じ住所フォームを用いるのが一般的かと思いますが

その住所フォームにアノテーションを用意すれば、送り元と送り先それぞれの各項目に

アノテーションを付与したのと同じになります。

ただし、JSP側は全ての項目に設定が必要で、更に場合によっては

各FormBのすべてのパラメータが送信されなかった場合の<form:errors>タグを準備するなど

逆に手間がかかってしまう場合があるので、注意が必要です。

5.5.2.2.3. バリデーションのグループ化

・一つのフィールドに対して、グループごとに入力チェックルールを決められる「バリデーショングループ」を作れます。

・FormにグループごとのInterfaceを準備します。

・アノテーションリストを作り、そのリストの１つ１つにグループの条件を追加します。

・Controllerで、どの入力のときにどの条件を使うかを明示します。大きな変更になります。

・JSPはグループを判断できる入力項目があればよく、大きな変更は不要です。

5.5.2.3. 相関項目チェック

SplingValidatorとBeanValidatorのメリット、デメリットが記載していますが、メリットを抜き出すと以下になります。（もう片方に書いてあることがしづらいのがデメリット、という認識で）

・SplingValidator

特定のクラスに対する入力チェックの作成が容易

特定のフォームに依存した業務要件固有の入力チェック実装に向いている

・BeanValidator

Controllerでの利用が容易

特定のフォームに依存しない、開発プロジェクト共通の入力チェック実装に向いている。

5.5.2.3.1. Spring Validatorによる相関項目チェック実装

「パスワードリセット」処理を例に実装方法を説明しています。

Validatorクラスを作って、Controllerクラスで宣言します。

■Validatorクラス

・チェック対象以外のクラスは処理しないような実装とする。

・単項目チェックでひっかかったときにチェックしないようなら、そのような実装もする。

・チェックロジックを実装する。

・エラーが表示されるフィールド（場所）を実装する。

・エラーメッセージ（コードとデフォルト）を実装する。

■Controllerクラス

・Validatorをインジェクションする。

（インジェクションする・・・直訳すれば注入するとか注射するとかですが、要は「機能を有効にするための記載を加える」ぐらいの認識でよいかと）

・@InitBinderをアノテーションして、作成したValidatorを追加する。

5.5.2.3.2. Bean Validationによる相関項目チェック実装

（5.5.3. How to extend）

Bean Validationによって、相関項目チェックの実装するためには、独自バリデーションルールの追加を行う必要がある。

大きく、以下の２つの観点に分かれる

・既存ルールを組み合わせ

・新規ルールを実装

5.5.3.1. 既存ルールを組み合わせたBean Validationアノテーションの作成
・エラーメッセージの共通化をしたいときなどに有用

5.5.3.2. 新規ルールを実装したBean Validationアノテーションの作成
・javax.validation.ConstraintValidatorインタフェースを利用し、任意のルールを作ります。

5.5.3.2.1. 既存のルールの組み合わせでは表現できないルール
・ConstraintValidatorを継承したValidatorと、それを使用するアノテーションを作成します。

・アノテーション内に、表現したいルールを実装します。

5.5.3.2.2. 相関項目チェックルール

・ConstraintValidatorを継承したValidatorとアノテーション、フォームを作成する。

・相関項目チェック用のアノテーションはクラスレベルに付与できるようにします。

・フォームのクラスレベルに作成したアノテーションを付与する。

・Spring Validatorによる相関項目チェック実装で用いた InitBinderの宣言は不要

5.5.3.2.3. 業務ロジックチェック

（コピペです）

一方で、「入力されたユーザー名が既に登録済みかどうか」など、対象の入力フィールドに対する業務ロジックエラーメッセージを、フィールドの横に表示したい場合もある。 このような場合は、ValidatorクラスにServiceクラスをインジェクションして、業務ロジックチェックを実行し、その結果を、ConstraintValidator.isValidの結果に使用すればよい。

5.5.2.4. エラーメッセージの定義

Springのルール、BeanValidationのルールがあり、Springのほうが優先される。

Springの場所はここ。

5.5.2.4.1. ValidationMessages.propertiesに定義するメッセージ
javax.validation.constraints.Size.message=size is not in the range {min} through {max}.

のように、属性値の埋め込みが可能
javax.validation.constraints.Min.message=can not be less than {value}.

のように、不正となった入力値は、{value}で埋め込むことができる。

org.hibernate.validator.constraints.Email.message="{0}" is an invalid e-mail address.

のように、フィールド名は{0}で埋め込むことができる。

5.5.2.4.2. application-messages.propertiesに定義するメッセージ

ValidationMessages.を上書きたい場合に使用。

アノテーション名.フォーム属性名.プロパティ名=対象のメッセージ

====================

というわけで、（コピペもありますが）TERASOLUNAの入力チェックについてのまとめですた。

フライングラビットさんのページを参考に、進めます。

まずは「PostgreSQLにJavaプログラムからアクセスするための、JDBCドライバを入手」します。

参考ページにある「Java8の人はJDBC42を使え」というのは・・・あ、この文か。

「If you are using 1.8 then you should use the JDBC42 version」

というわけで、入手して、libの下に置きました。

そんでもって、controllerの内容を書き換えます。

（DBを取り扱えるのはrepositoryしかない、と思っていたのですが・・・できるんだ）

（List <String> が、List <string>と小文字のsだとエラーが出る、というのも理由が良く分かってない）

ちなみに、todoリストのプロジェクトは、STSでサンプルプログラムで作ったものをそのまま使ってます。

で、実行したら、ドライバ認識せずに接続エラー、と。なぜじゃ。

対処してみた1：tomcathomeの変更→変わらなかった。

参考URL:　http://blog.job-is.jp/archives/287

対処してみた2：ユーザーエントリーに追加→変化はあった。

参考URL：　http://www.yukun.info/blog/2010/03/java-no-suitable-driver-found.html

変化があったといっても、エラーが出るようになって余計悪化ようには見えます。

でもまぁ、connect部分のソースは通ってるし・・・

DBの値はコンソールに一応出てきてるし・・・

とりま接続できたということで、ギブアップです（汗

（最後の3文のトレースログ）

date:2015-11-15 12:17:12 thread:http-nio-8080-exec-2 X-Track:a3a32d5eb5b34d6faa194ffe2698b46a level:TRACE logger:o.t.gfw.web.logging.TraceLoggingInterceptor message:[END CONTROLLER ] TodoController.list(Model)-> view=todo/list, model={todoForm=todo.app.todo.TodoForm@12df1e2, todos=[豚生姜焼き, お, おろしポン酢], org.springframework.validation.BindingResult.todoForm=org.springframework.validation.BeanPropertyBindingResult: 0 errors}
date:2015-11-15 12:17:12 thread:http-nio-8080-exec-2 X-Track:a3a32d5eb5b34d6faa194ffe2698b46a level:TRACE logger:o.t.gfw.web.logging.TraceLoggingInterceptor message:[HANDLING TIME ] TodoController.list(Model)-> 111,482,029 ns
重大: サーブレット jsp のServlet.service()が例外を投げました [日 11 15 12:17:12 JST 2015]

といっても、公式サイト（http://tomcat.apache.org/ ）からダウンロードして

任意の場所に置くだけです。

（例によって、フライングラビットさんのページ（http://flyingbrown.blog.fc2.com/blog-entry-5.htm ）を参考ください）

bin配下のstartup.batをダブルクリックして、「Server startup in xxxx ms」の表示を確認し、、、

http://localhost:8080/ に猫(?)が出てきたら、tomcat単体の動作確認は終了です。

ここで、eclipse を起動させて、tomcatサーバの設定を行います。

----

なお、Eclipseの起動に関して、私のPCは64bitのはずなのですが、

http://mergedoc.osdn.jp/ より、「64bit用のJava（FullEdition）」をDLし実行しても、なぜかエラーとなってEclipseが起動せず

「32bit用のJava（FullEdision）」をDLし実行すると、普通にEclipseが起動するという謎の事象が発生していますが

そのまま突き進んでいることをご了承ください。

あ、あとMavenのインストールおよびブランクプロジェクトのインストールまでは終わっています。

----

サーバで実行を選びます。

Tomcat8を選びます。

HelloWorldが表示されました。

・・・駆け足もいいところですが、Tomcat設定を終わります。

フリーで postgres があるので、そちらを使用。

フライングラビットさんのページ（http://flyingbrown.blog.fc2.com/blog-entry-11.html）を参考にします。

----

まずは、日本PostgreSQLユーザ会からEnterpriseDB社のページへ飛んで、Version 9.4.5 のWinx86-64をDL。

VisualC++のプロパティが出て、少し経って消えたあと、setupの画面へ。

Nextを押したら、
Installation Directory、Data DirectoryとデフォルトのままNextを押し、

（C:\Program Files\PostgreSQL\9.4、C:\Program Files\PostgreSQL\9.4\data）
Password を postgres と入力してNext、
Port を 5432 とこちらもデフォルトのままNext、
最後 Advanced Option も Default locale のままNextを押し
Ready to Install で Next を押したらインストールが開始されます。

ここで、豚の生姜焼きでも食べながら、しばらく待ちます。

食べ終わるころには、インストール完了してました。

Windows8ってスタートメニュー無いのかな？

左下のWindowを押して、さらに↓をおして出てくる「アプリ」の中に

同等のものがありました。

インストール完了したので、動作確認です。

pgAdmin III を起動します。

サーバ起動、データベース作成、テーブル作成とフライングラビットさんのページ通りに進めます。

主キーを設定してっと・・・おっと間違えた。

todo_id を指定したつもりが todo になってた・・・

テーブルのtodoを右クリックで、プロパティを開きます。

制約タブを開くと、間違いを確認できます。

削除をクリック。

「選択した制約を削除したいと思うことは確かですか？」と問われます。

確かなので、はいを選びます。

その後、todo_id を追加します。

追加→OKを押して、主キーが変わったのを確認します。

最後に、データの確認です。

「選択オブジェクトでデータをビュー」のアイコンを選びます。

いくつかデータを追加します。

（２つ目は「おろしポン酢」と入れたつもりが、お、だけで確定してしまいました。

データ追加中は、ダブルクリックしても編集できなかったので、そのまま３つめを追加しました。）

ここで、リフレッシュのボタンを押すと todo_id が自動で採番されました。

（参考のページはビューを閉じて再度開きなおすことで自動採番してましたね。）

ここまでで、postgres環境構築編は終わりです。

terasolunaガイドライン

http://terasolunaorg.github.io/guideline/

今は5.0.1が最新版のようですね。

http://terasolunaorg.github.io/guideline/5.0.1.RELEASE/ja/

とりあえずTodoアプリケーションを動かしたいですね。

http://terasolunaorg.github.io/guideline/5.0.1.RELEASE/ja/TutorialTodo/index.html

ガイドラインには、STSっていうのを使って実装する、とあるけども訳あってEclipseを使って実現したいのですね。 なので、もっぺん環境構築からやり直してみようかなと。

（余談）

http://wkp.fresheye.com/wikipedia/TERASOLUNA

TERASOLUNA Server Framework for Javaの説明で「StrutsベースのためXML地獄という現象に陥ることがある。」ってあるけど、、どんな地獄？