JAVAの1.4.1以前と以降でSJISのマッピングが違う文字

　一人勉強会シリーズの、「日経SYSTEM」前についてきた付録、『システム構築完全読本」から、お勉強になりそうな話。
　今日は、２章２部「SQLインジェクションはパラメータ・クエリーで防ごう」。

---

その話題自体は、
　ASP.NETの場合、SqlCommandをつかってSQL文（パラメータは＠をつけて）を指定し
　　　　　　　　　SqlParameterでパラメータの値を設定する

で、本に書いてないけど、
Java(JDBC)の場合はConnectionのprepareStatementでSQL文(パラメータは？)を指定
　　　　　　　　　　その返り値のPreparedStatementを使って値をセットする

っていうことをすると、エスケープしてくれるのでOKと
（エスケープが目的なので、たった１回の処理でもPreparedStatementを使う）
言う話がのってるんだけど、これは、もうこのブログにもさんざん書いた話なので
（サニタイジングについて）、いいとして、今日は別の話。

---

その後にのっている話で、「文字化けを防ぐには」がお勉強内容。

JAVAのJDKにおいて、Shift_JISとは

JDK1.1.8、JDK1.2　　　SJIS
JDK1.2～JDK1.4.1　MS932(Windows-31J)
JDK1.4.1以降　　　　　SJIS

をさすんだそーな（P49）。

で、SJISとMS932でUNICODEへのマッピングが違うものは、SJISコードで
0x5c（半角の￥）、0x7e(半角の~)
0x815c,815f,8160,8161,817c,8191,8192,81ca
だそーな。（P４７）

なので、

・これらの文字は、JDKのバージョンの違いによって、変換の問題が出る可能性がある。
・全部UNICODEにするというのが１つの解法
・ただしUNICODEにしても半角の￥とバックスラッシュは同じSJISコードなので問題がある

ってなことが載っていました。

---

今日のお勉強はここまで。

戻るボタンで戻ると「有効期限切れ」と出る対策とＨＴＴＰヘッダを見るプラグイン

　日経ＳＹＳＴＥＭの先月号についてきた、システム構築完全読本の２章Ｗｅｂアプリ開発の最新技法（ｐ３８－Ｐ７３）に書かれていることを、何回かに分けて取り上げてみたいと思います（１回でおわっちゃうかもしんないけど）

---

■重複処理を防ぐには
・JavaScriptでボタンがクリックされたら、ボタンを無効にするようにする
・隠しトークンとセッションをあわせる（トランザクション・トークン）

■ページを戻るボタンで戻ると「有効期限切れ」とでる
　→ＰＯＳＴで起こる。
・HTTPヘッダの「Cache-Control」を、クライアントにキャッシュできるような設定にする
　→no-cacheにしない
・特にＰＨＰは単純にsession_startを送ると、no-cacheになるので、session_cache_limiter("");を先に呼び出す。そーすると、ＯＫ

■ＨＴＴＰのヘッダを参照するプラグイン

ieHTTPHeaders
http://www.blunck.info/iehttpheaders.html

なぜシステム開発に失敗するのかを、認知心理学的に考えてみる（その２：一般的な失敗箇所）

　前回のブログ、なぜシステム開発に失敗するのかを、認知心理学的に考えてみる（その１）の続き。今回は、認知心理学的な問題解決ステップと、開発のステップを対比させて、そのうち、すでに開発で問題になっているところは、どこか、それはなぜ、問題になるのかを書きます。

---

■■　前回までのあらまし。

　認知心理学的には、問題解決は、良定義問題と不良定義問題に分かれる。
　システム開発は、不良定義問題の解決にあたる。
　この解決方法は、以下のステップで行われる。

●問題理解
　１.問題文の理解
　　　　（文→状況モデルを作成する）
　２.問題に関係するところだけを選び出し表象する
　　　　（状況モデル→問題スキーマ）
●実行
　３.その問題を解決する方法を見つけ出し、やり方を決める
　　　　（問題スキーマ→行為スキーマ）
　４.その行為スキーマをもとに実行する

このステップをシステム開発にあてはめると、こんなかんじ

●問題理解
　１.問題（＝要求）の理解
　　　　（ヒアリング）
　２.問題に関係するところだけを選び出し表象する
　　　　（ヒアリング→要求仕様作成）
●実行
　３.その問題を解決する方法を見つけ出し、やり方を決める
　　　　（要求仕様→設計）
　４.その行為スキーマをもとに実行する
　　　　（プログラミング、テスト）

で、こんかいは、そこから先の話。

---

■■　古典的に言われている問題
　ここでも大きく、「問題理解」と「実行」に分かれていますが、この問題解決と実行の間にギャップがあり、このギャップがＳＤＬＣの断層といわれます。このギャップにおける判断ミスが、プロジェクトの失敗を招くとされています。

　つまり、お客さんの要求は聞いた。

　でも、その要求を満たすシステムに落とし込む（認知心理学的に言うと、問題スキーマから、行為スキーマへ変換する）ところにおいて、この変換過程は、自動的に行うことではないので、システムの落とし込みに無理があったり、要件をすべて満たすものに変換できなかったりなどでで、問題が起きるということです。

---

■■　で、認知心理学的に考えると。。

　しかし、認知心理学的に考えると、変換過程は、

・状況モデルを作成するところ
　　ヒアリングでお客さんの話を理解する部分

・状況モデルから問題スキーマを生成するところ
　　そのヒアリングの中で、システム開発上、重要な要件はなにか、抽出する

・問題スキーマから行為スキーマを生成するところ
　　上記のＳＤＬＣの断層

・行為スキーマから実行のところ
　　設計内容をプログラミングへ正しく落とし込めるか？

の４つがあるわけです。なので、それぞれの箇所について、問題は起こりえます。
（一番大きな問題は、たしかにＳＤＬＣの断層でしょうが）

　では、どういう問題がおこるのか？についてですが、それを考えるには、そもそも、これらの変換を、人は、どのように行っているのか？ということから、考えないといけません。
　ということで、その話題については、「その３」で触れたいと思います。
　（もしやれば）

ということで、今回はここまで。

なぜシステム開発に失敗するのかを、認知心理学的に考えてみる（その１）。

　システム開発に失敗するということは、よくある話だが、それは、認知心理学的にどういう状態で、なぜ失敗するのかについて、考えてみたいと思う。

　まず、システム開発のような問題は、「不良定義問題」と認知心理学の世界では言われるようだ。

　これとは、逆の「良定義問題」とは、たとえば、

「○Ｘで、はじめにやったら、必ず負けない（引き分けるか勝つ）手について、調べなさい」

　のように、（以下、斜体は、後述の参考文献Ｐ７０をほぼ引用）

・初期状態
・ゴール
・オペレータ
・オペレータの適用制約
が問題中に明示されている（＝問題空間が明確）

のものをさす。

　これ以外のものは、「不良定義問題」となる。

　「良定義問題」は、しらみつぶしで答えられる場合もあるが、現実的ではない場合、ヒューリスティックな方略（必ずうまくいくとは限らないが、比較的うまくいく方法）を見つけ出し、答えたりする。

---

　しかし、現実のシステム開発の場合、「オペレーター」に相当する、なにをすれべ、回答までにたどり着くか、すわなち、適用要素技術がはじめから決まっていないし、その要素技術を決めてみないと、その制約も決まんない。なので、こういう問題は、「不良定義問題」となる。
　このような問題の解法は、以下のようになる（以下、斜体は、後述の参考文献Ｐ８０～を参考にした）

●問題理解
　１.問題文の理解（文→状況モデルを作成する）
　２.問題に関係するところだけを選び出し表象する（状況モデル→問題スキーマ）
●実行
　３.その問題を解決する方法を見つけ出し、やり方を決める
　　　　（問題スキーマ→行為スキーマ）
　４.その行為スキーマをもとに実行する


　実際に、システム開発の場合、１は、ヒアリング、２は要件定義、３は、設計（とくにアーキ）、４はプログラミングに相当するわけだが、ここで、論外の問題が１つ起こる。

---

　つまり、３の見込みがないときに、「とにかく、できるかどうか、わかんないけど、とりあえずわかるところからやっていきましょう」っていうやつ。
　わかるところからやっても、わからないところは、やっぱわかんない。。。となることが多いので、こういう状態ではいれば、当然できない。

　そもそも、問題が一部しか見えてないときと、全体が見えたときには、解法が違うことも考えられる。画面数がわかんないとき、片っ端から作っていく方法がとられるが、それが相当数あった場合は、画面作成ツールを作ったほうが良いなど（逆に画面数が少ないなら、ツールを作らないほうがいい場合もある）

　しかし、ここでは、さすがにそういう状態は、排除して、もっと本質的に、この４段階のうち、どこがどうまちがって、システムができなくなるのかについて、考えたい。


　ということで、「その２」につづく。

参考文献
　放送大学大学院　認知過程研究　テキスト

JUNITの本に「書かないコードに単体テストは不要」と書いてあるけど、テストしないと。。

　ＪＵｎｉｔによるテストファースト開発入門のＰ１６に「書かないコードに単体テストは不要」とかかれていて、ＤＬＬやJavaのAPIは単体テスト不要（結合、総合は必要）とかかれています。

　現実は、ＤＬＬやＪａｖａＡＰＩでも、やばそうなものや、他社が書いたプログラムを利用する場合は、一般にＪＵＮＩＴで行うような、ユニットテストをプログラム前に行うと思います。　なぜ、行うかは、今日、これから書く理由のためです。

　ただ、ユニットテストを、単体テストと呼ぶか、結合テストと呼ぶかという問題があります。ユニットテストは、結合テストであるという場合（こういう主張がある。単体とは、ソースをみながら行うソース内部をテストすることであるという主張）、単体テストは不用（というより、できない）ということになります。

---

　で、なぜ、ユニットテストを行わないといけないかという話（＾＾）

　というまえに、どうやって、この手のものを、ユニットテストするかについて、書きますね。

　まあ、この手のユニットテストの仕方はきまっているわけで、
（１）呼び出し部分とラッパーを作って
　→ラッパーは、ダミーの値をいれ、この時点では他社の関数等を呼び出さない
（２）その状態で動くことを確認（テスト）してから、
（３）ラッパー部分の内部を、使いたいプログラムを使ってコーディング、
（４）そして、（２）のときの確認したデータ、方法で、確認する
という作業をします。

　一般の仕事においては、開発は、
・アーキテクト（アーキ）と
・共通部分開発
・個別の業務部分開発
にわかれ、業務チームの人は、ラッパーの関数・メソッドを使うため（開発は、（３）が間に合わないときは、（１）で作ったラッパーのなかにダミーモジュールをいれたものを、スタブとして使ってもらうという形をとる）、自分でテストすることは、ないかもしれません。

　共通やアーキ（とくに共通）がこういうテストをします。
　共通の私は、そんなんで、よくやるわけで、今日も、そういうお仕事だったわけですが。。。。

---

　あるプログラムの、ソースとオブジェクト（だけ）をもらって、お仕事です。

　（１）、（２）の作業を終え、（３）。

　まあ、今日は、（市販されているソフトらしいので）ソース内部を確認しなくても大丈夫だろうと、ソースを読まないで、そのままインターフェースをあわせて呼び出したら。。。

　はんぐあーっぷ！！

　なんでなんで（＞＿＜！）

　とおもって、ソースを見てびっくり。。。

　正常系しか、テストしてないのかなあ。。。
　異常系で、エラーになると。。。（＾＾；）。。。

　おいおい、エラーのとき、この順番でフリーしたら、フリーした後で、その領域、見ちゃってるじゃん！そのうえ、フリーしてない領域もあるしい。。

　あーーーーそこで、すぐに抜けたら、メモリフリーしてないだろ。。

　つーか、ここで、フリーすんじゃねーよ。

　おまえ、ヌルかどうかきいて、フリーしてるけど、その領域、初期化してねーだろ（＾＾；）

　とかいうわけで、これ、つかえないじゃん！

　ということで、かきなおしです。。。

---

　で、書き直したら。。まあ、ハングアップした理由が異常系にいったから
ということからもわかるように、エラーになるわけなんだけど、そのエラーの
理由が。。。

　エラーコードを見たら

　「このクラスは、サポートされていません」。

　はじめから、言えよ（＾＾）

---

　たぶん、環境設定がおかしいんだと思います。

　こういうケースはすごーく良くあって、最近、マネージャーが、システムを良くわかんない人がやることが多いので、環境設定のドキュメントを持ってこないとか、ドキュメントが抜けてるとか言うのがあって、それを、事前に確認しておかないと、開発のコーディングが終わってから後だと、完全に手遅れ（実は、ターゲットの環境では動かせない！というケース）ということが、ありますね。

　で、最近は、ユニットテストの正常系だけ通して持ってこられたりするので、そーすると、環境が違って、異常系に入ると、上記のように。。。っていうことも、ないわけじゃない。

　ということで、最近は、ＤＬＬやほかの会社が作ったモジュールでも、共通部隊は、単体テスト（ユニットテストですけど）を行って、環境の確認、および異常系がちゃんとできているかなんかの確認をしますね。
　で、確認するときに、上記のように、ラッパーを作って、ラッパーの中を、ダミー入れて、テストドライバが通ることを確認してからやるため、時間がないと、ダミーを入れたラッパーを使って結合してもらったりします。

　そのため、共通以外の人たちから見ると、他人のモジュールはテストしなくて言いように見えるかもしれないけど、一応、テストは、してまーす！

　その状況をみると、「なんで、共通の人しか、テストしないようにするか」というのがわかります。ハングアップしてしまうと、リセットして、再度立ち上げないと、なにもできなくなるんです。（＞＿＜！）

　もう、リセットばっかで進まない、進まない。。。

　で、通った！と思ったら、「そのクラスは、サポートされていない」

　うーん、今日１日、何やってたんだろう　（＾＾；）

　

勉強会って、ブログ上でやるっていう手もあるかも。。

　会社員だったころ、勉強会っていうのがありました。

　まあ、みんなあつまって、ある本をきめて、本の内容を説明する。。。
　つーのを、部分部分にわけておこなうわけですな。。。

　ウィリアムのいたずらの会社では、「関数プログラミング」とか、雑誌に出ていた、ＲＤＢの作り方（Ｂ＋木、データ格納、ＳＱＬ解析とか、そういうのを実装する方法が、たしかインターフェースという雑誌にでてて、それをやった）とか、やってました。

---

　でも、いまって、世の中、どっかの会社に常駐してる人が多いわけで、そうすると、みんな集まって勉強会なんて、できませんよね。。

　で、おもったんだけど、勉強会のブログを作って、みんな、そのブログに入れるようにしておいて（＝つまり、ユーザー名とパスワードを勉強会の参加者に教えておいて）、担当の人が、発表する内容を、記事として書いて、そのブログにアップしておけばいいんだよねえ。

---

　なんで、こんな話をするのか、コンピューターに関係ないのに。。。

　というのは、ほかでもない。このブログで、一人勉強会をやろうと思ったから。

　せっかく「JUnitによる、テストファースト開発入門」（ISBN 4-7973-2572-0）が目の前にあるので、この本を読んで、勉強会で発表するような内容・・とまでは、まじめに書かないけど、そんな内容を、
ブログに書いていこうと思います。

　カテゴリを一人勉強会にしておきます。

　気が向いたときに行います。勉強会というのは、そういうものだ（気が向いたらやるもの）

Ｐ．Ｓ　今日の、ユニットテストの話も、「一人勉強会」のカテゴリに変えておきます。

ユニットテストのテスト種類と方法について考える

　突然ですが（実は、あることが書きたい前置きでこれを書いているわけなのですが）、単体テストとして行われる、ユニットテストの方法について、考えてみたいと思います。

　ということで「JUnitによる、テストファースト開発入門」（ISBN 4-7973-2572-0）で、ユニットテスト方法のところをみてみる。

　なぜ、この本を選んだか？というと、目の前にあったからというだけで、深い意味はない。
　もっといい本があるかもしれないし、ないかもしれない。
　独断と偏見で（というか、運と、惰性と成り行きで）選んだ。

---

上記の本の、９１ページの図「テストの種類とエラーの種類」の図では、以下の４つが、テストの種類としてあがっている。
・制約値テスト
・限界値テスト
・例外処理テスト
・存在テスト
　このうち、たぶん、例外処理テストは、なにかの間違いじゃないかな？実際、この図の説明文にあたる、Ｐ９６では、「妥当性テスト」になっているし、ここに挙げる例としては、妥当性テストがただしいとおもう。

　ということで、以下に、それら４つのテストと、その内容を説明する
・制約値テスト－システムの制約から来るもの
　　　　　　　　桁あふれのとき、どうなるか（エラーとして受け付けないか）とかなど

・限界値テスト－いわゆる、境界値テスト。仕様の制約からくるもの

・妥当性テスト－引数の組み合わせを考えたとき、その値は妥当か？などのテスト
　　　　　　　　決定表などを使い、各ケースについて求める。

・存在テスト－そもそも、引数が存在しなかったら(NULLで渡したら）どうなるかのテスト

---

　で、これらのテストのそれぞれに対して、結果がどうなるかによって、正常系、異常系に分かれる。
　正常系とは、正常に値が帰ってくるもの。
　異常系というのは、そうではないもので、「エラー」と「例外」に分かれる
　　　エラーは、エラー値が帰ってくる
　　　例外は、例外処理され、例外が帰ってくるもの

　エラーと例外の区別について、個人的な見解を述べると、一般論でいえば、エラーは、想定の範囲内であり、本システムで、警告など、対処すべきもの。
　例外は、想定の範囲外のことが起きた場合と、想定の範囲内だが、本システムでエラーとして対処するには、不適切なもの（熱暴走が起こった等）に対処する。
　ただし、想定の範囲内で、警告などで対処すべきケースでも、例外処理に落とし込む場合もあり（ＤＢのデッドロック等）このエラーと例外の区別はあいまいになる。

---

　そうすると、ユニットテストは、こんなかんじに分類できる（ここをうめるように、テスト項目を検討していく）

	正常系	異常系（エラー）	異常系（例外）
制約値テスト
限界値テスト
妥当性テスト
存在テスト

これを、各項目ごとに、行うことになる。

---

　とすると、ウィリアムのいたずらが、前に示した単体テストのテストケースの作り方と、異なる。
　なぜ異なるかということと、実は、この表をテキトーに書き換えると、ウィリアムのいたずらの示した表になる（具体的には、３次元、いや、４次元を２次元に圧縮して、あるものを付け加える。別に、次元を乗り越えるというＳＦな話ではない。ただ、「具体的には」といっておきながら、ひとつも具体的ではない）。

　今日は、その前置きとして書いたのでは。。実は、「ない」。
　もし、気が向いたら、その展開過程を書くかもしれないけど。

　じゃあ、何のために、この話題を書いたのかについては、気が向いたときに、覚えていたら、説明するかもしんない。