MVCで、M（DB側）とV（表示側）どちらを修正するか？

面白い議論があったので、メモメモ。

今、MVCモデルで、コントローラー部分はフレームワークになっていているものとする。
表示をJavascriptで行っているのだが、ある変数に

"null"という文字列が入ってくる。

この現象は、あるSQLを発行したとき、Selectで指定する１つの数値項目（valとしよう）がnullの
ときに、このようになり、SQLでselectする際nullだったら空文字を返すように書き換えると、
空文字になるようだ。

このとき、画面上にnullという文字列が表示されないようにしたい。
方法としては

（１）view側で、"null"という文字列が来たら空文字に変換する
（２）SQLでvalがNULLのときに空文字に置き換えるようにする

２通り考えられる（ハリウッドの法則があるので、ここでコントローラーはいじれないものとする）
どちらがよいか？

---

　別に（１）でも（２）でも、どちらでも良いのだが、問題なのは（２）と答えた人が、なぜ（１）の修正をするのかを考えず、ぼろくそにけなし、肝心な（２）で行うべきテストをしていないことがある点だ。

（２）は、nullを空文字に変えてしまう。もともとvalは数値項目なので、型が変わってしまう。
　そのため、nullのときは、例外処理、そうでないときは、四則演算処理のようなことを、
コントローラー内で行っていると、おかしなことが起こるリスクがある。

　それに対して（１）は、表示部分Vだけの処理なので、コントローラーCに影響を与えることが
まずない。つまり、（１）の修正は、修正が影響する範囲を最小化したいために行っている修正
である。

　したがって、（２）の修正を行った場合、コントローラーでnull判別している処理が無いか
どうか、回帰テストを行う必要がある。これを忘れると、null判別しているところで、バグが
入る危険性がある。

---

　影響範囲は結構重要なことなんだけど、不用意にモデルをいじることがあるので、注意したほうがいい。
　一方、ビューは、いじっても、影響が限定的なことが多い。

プログラミング、実務と大学と小学生では、考え方がちがう

プログラミングやソフトウェア工学等は、実務と大学では、
考え方が異なる。

---

■大学の場合－演繹

大学の場合は、プログラムなどを、論理的に考える。
アルゴリズムやデータを抽象化して考え、
論文を書くために実装したりもする。
つまり、演繹的、トップダウンな考え方だ。

だから、わからないところというのが基本的に無い。
演繹的に、論理的に考えるので・・・
たとえば、この考え方だと、以下のソースコード

Class.forName("org.gjt.mm.mysql.Driver");
Connection con = DriverManager.getConnection("jdbc:mysql:///test","root","password");
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM DEPT;");

は、完璧に説明できないといけない。呪文なんてのは、ゆるされないわけだ。

なぜ、Class.forNameがいるのか？
OracleやPostgreSQLなど、いろんなDBがあるのにどうして見分けが付くのか？
DBの違いがあるのにDriverManager.getConnectionという同じ方法で、どうしていいのか？

このへんが説明付かないと、このプログラムを使えない。
となると、JDBCが使えないので、データベースアクセスができない。
なので、これを説明するため、多態性の話や、ストラテジーパターンなどのデザインパターンの話が必要になってくる。

---

■実務－類推、帰納

しかし、実務的には、プログラムは、サンプルプログラムを元に作ることが多い。
上記のJDBCについても、説明が付かなくても、呪文としてしまうので、
何の問題もない。
思考法でいうと、サンプルを基にした類推ということになる。

したがって、サンプルが多いプログラム言語がいいことになる。
このへんの話については、

カネと時間考えるならPHPやっとけ。たぶｎ
http://blogs.itmedia.co.jp/fukuyuki/2013/03/php-57de.html

が名文だとおもう。このとおりである。

そして、類推によって、いろいろなサンプルから、経験を経て、知識
を得る。これが、帰納ということになる。

---

■小学生のプログラミング－経験

そうすると、小学生がプログラミングをする

TENTO
http://www.tento-net.com/

とかは、どう位置づけたらいいのか？ということになる。


大学におけるプログラミング、ソフトウェア工学は、
演繹的に考える。だとすると、論理的思考が必要となるが、
論理的思考は、ピアジェの思考発達段階説に基づけば、
１２歳以上の「形式的操作期」に行われるものであり、
小学生は、そのような考え方ができないのであるから、
小学生のプログラミング経験に意味は無いことになってしまう。


また、実務的に言えば、サンプルプログラムを基に作るので、
プログラミングを覚えることに、そんなに早期から力を入れなくていい。
むしろ、算数とか、国語とかをちゃんとやったほうがいい。


たぶん、これは、プログラムという物事に、真剣になって取り組む
という経験が大事なのであろう。

慶應義塾幼稚舎に受かる理由、落ちる理由
幼稚舎合格者のほぼ1/3を輩出する塾「ジャック」とは？
http://media.yucasee.jp/posts/index/339/2

にあるように(以下太字は上記から引用）、

いかに夢中になって物事に取り組めるか、磨けば光るという可能性を感じさせてくれるかが大事

なんでしょうね。そして、そうなることによって(以下太字は下記から引用）、

慶應義塾幼稚舎に受かる理由、落ちる理由
合否に関係なく残るのは、「本物」を知った経験
http://media.yucasee.jp/posts/index/339/4


「本当に頑張るとはどういうことか」「自分を信じるとはどういうことか」を学んできた彼らは、同じレベルにある子供たちがわかります。そして、お互いの中に宿る「本物」を感じ取れるようになっているのです。それは、成功体験を積んだ人にしかわからないもの。

なんでしょうな。。。

---

つまり、プログラミングは、実務と大学と小学生では、考え方がちがう
のであって、これをいずれかのサイドに立って、他のモノを非難しても、
価値観が違うから、意味ないし、これが判らないと、混乱して、
プログラムが書けなくなってしまう・・・

”「うさみみ」のペアプログラミング”の答え合わせ！！ ばぷぱふ

この前書いた

「うさみみ」のペアプログラミング
とは、さっきの、スクラムブートキャンプで、私が挙げた、「作ろうとするWebシステム」の内容。
残念ながら（いや、当然　＾＾；）これはグループでは選ばれなかったんだけど、
こんなものを想像していました

---

■「うさみみ」のペアプログラミング

ペアプログラミングをすると、２人プログラマが必要なので、
人件費がかさむし、いやな人とペアになると、生産性が上がらない
かもしれない（いや、仲良しだと、もっと上がらないかもしれない）

なので

経営者にとって、ペアプログラミングでも、人件費があがらないように
プログラマにとっては、いつでも、お気に入りの人とペアプログラミングできるように

パソコン上に、うさみみの、ペアプログラマーを表示し、

なかんじ
（http://piapro.jp/t/dPNNより）

ドキュメントやプログラムを読み込み、（コミットしたり、セーブしたら、自動的に読み込んでもいい）
その内容を解析、問題点や警告を、
・ツンデレ調
・女王様調
・お嬢様調
　　：
　　：
などなど、お好みのパターンで読み上げ、表示、修正してくれるサービス

キャッチコピーは
うさみみと、いつも一緒

---

あと、もう一つ、考えた！

■「うさみみ」のペアプログラミング　PART2

上記にくわえ、
　女子大生も、実務経験を積もうとしても、つめない
　プログラマには出会いが無い
これらの問題も解消する！

上記、”「うさみみ」のペアプログラミング”は、システムが
ドキュメントやプログラムを読み込み、自動的に解析していたが、
これを、女子大生が解析する。

システムとしては

＜＜女子大生側＞＞
・うさみみをつけて、テレビカメラの前で待っている

＜＜利用プログラマ側＞＞
・気に入ったうさみみをチェックすると、そのうさみみさん
（女子大生）と、ペアプログラミングできる！

キャッチコピー
「うさみみ」付き出会い系ペアプログラミング

---

きっと、”「うさみみ」のペアプログラミング”って書いたら、
・おじさん２人が「うさみみ」をつけて
・真夜中に
・見つめあって、ペアプログラミング・・・

なんて、こい～のを想像していたと思うけど、
ありきたりな話でごめんなさい・・・

（なので、当然、選ばれませんでした。ありきたりすぎますね）

スクラム ブートキャンプにいってきた その４

スクラム　ブートキャンプ　for NII
について、いままでは、講義についてだったけど、
ワークショップもあった。

その内容をメモメモ

---

＜＜午前中＞＞
自己組織化ゲーム
　　座席移動：アジャイルを知っている順にならび、号令

本日の約束事（一日を通じて）
・誰かが手を上げたら従う

■ペーパープロトタイピング
　さまざまなＷｅｂ部品作る

---

＜＜午後＞＞


■ミッション：Ｗｅｂシステム作る

マンダラートＸしりとり

各自１つ：エレベーターピッチ→パッケージを作る
　　→その中でグループで１個を選ぶ

それについて
（１）スプリント計画ミーティング
　　第一部：プロダクトバックログ作成
　　第二部：スプリントバックログ作成
　　　　見積もり

（２）作業する
　　　　ペーパープロトタイプ作成

（３）デイリースクラム
　　　　作業報告

（４）（２）、（３）をもう一度繰り返す（＝２日分）

（５）スプリントレビュー
　　報告

（６）スプリントレトロスペクティブ
　　ＫＰＴ作成

（１）～（６）をもう一度繰り返し（＝２スプリント）