1月第3週の振り返り - Napier

1月第3週（1/13-1/19）

並列プログラミング

自分で一から書いたコードがMPI_Barrierに到達しないで永久ループしているようで何が原因か見当もつかず困っている。レポート課題として提出できるよう試験終了後に集中的に取り組みたい。

メディアプログラミング

顔検出で用いられるHaar-like特徴量の白黒パターンのことがずっと分からないままだったが、ようやく理解の糸口をつかめた。様々なサイズで領域を指定して白黒パターン群を領域に適用し、白部分と黒部分の輝度差をとって、その領域における輝度差の特徴が「顔」「not 顔」のいずれに類似するかということを機械学習によって決定するものであるようだ。白黒パターンは「鼻の側面は陰になり、鼻梁と隣接する頬は明るい」「黒目は白目より暗い」といったことを踏まえてそれを検出できるよう設計されていると理解した。

ASP.NET Core MVC

MVCにおけるViewModelの意義を理解した。POSTリクエストには任意のフィールドを含めることができるので、Modelを直接Viewに渡してしまうとCreate/Updateの操作において変更を想定していないフィールドが名前さえ一致していれば書き換えられてしまう。アノテーションを使ってバインドするフォームデータを制約することもできるが、文字列による指定でありIDEを前提としないとフィールド名の変更に追従できないことが考えられる。また複数のModelをViewに渡したいときや、Viewのフォームでは姓名を別の欄に入力するが実際にDBに保存するのはフルネーム（仮定の話。実際そのような設計がよいかは分からない）であるときなど、Model側がViewに配慮して新しいフィールドを追加するべきではない。

そこでViewModelというViewへの便宜を図った存在に必要最小限のフィールドを設定し、Modelの一部を詰めて表示する。POSTリクエストはViewにバインドされたViewModelで受け取り、必要な分だけControllerの中でModelに移し替える。これによりフォーマッティングのModelからの分離と、Modelに対して行える変更の制限とを実現できる。

Dependency Injectionは名前が直感的な理解を妨げているように思われた。各クラスにおいて必要な（Dependency）別クラスのインスタンスを、利用側のクラスが内部で生成するのではなく、コンストラクタが呼び出される段階で引数として外部から与えられる（Inject）ようにする。クラスのオンデマンド外部供給とでも呼ぶべきだろう。

この時別クラスそのもの（具象クラス）ではなくそのクラスが持つメソッドを定義したインターフェースを引数の型に指定することで、実運用時に具象クラスを渡せるのはもちろんながら、インターフェースを実装してさえいればモックも許容されるので、開発段階で別クラスの実装完了を待ったり、それが自分の期待通りに動くことを確認したりせずとも、「もし別クラスが自分の期待する（または仕様書にある）通りの挙動を示しさえすればこのクラスは正しく動作できるか」を確認できる（＝単体テストが実行できる）という恩恵があるわけだ。