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

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

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

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


なんか違和感。


以下引用


「占い 統計学」


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

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

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

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



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

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


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


TERASOLUNA では、いくつかの入力チェックの方法が用意されています。

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 を参照ください。


5.5.2.2. 単項目チェック

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

  • フォームクラスのフィールドに、Bean Validation用のアノテーションを付与する
  • Controllerに、検証するための@Validatedアノテーションを付与する
  • JSPに、検証エラーメッセージを表示するためのタグを追加する

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


    5.5.2.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が記載されていますね。

    annotationForm


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

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

    ----

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


    annotationController

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

    ----


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


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


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

    annotationJSPexample

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


    annotationJSPexample2


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

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

    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を準備します。

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

    ・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によって、相関項目チェックの実装するためには、独自バリデーションルールの追加を行う必要がある。

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

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

    ・新規ルールを実装


    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. 業務ロジックチェック

    (コピペです)

    業務ロジックチェックは、基本的にはドメイン層のServiceで実装 し、結果メッセージはResultMessagesオブジェクトに格納することを推奨している。

    一方で、「入力されたユーザー名が既に登録済みかどうか」など、対象の入力フィールドに対する業務ロジックエラーメッセージを、フィールドの横に表示したい場合もある。 このような場合は、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の入力チェックについてのまとめですた。

    環境構築第3弾です。


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


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


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

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


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


    jarget

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

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

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


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


    copypaste

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


    接続エラー


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

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


    tomcathome

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

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


    実行構成

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


    error

    でもまぁ、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]