統計

統計学、というのは高校数学の中でもかなり実用的な部類に入ると思う。
しかし、私の高校では最後の方に軽く流され、あまり重視されなかった。おそらく他の高校でもそうだろうし、私が高校生だった昔だけの話ではなく今もそうな のではないだろうか。
理由は受験にあまり関係ないから、か。

統計(今の学習課程の区分では数学C？)では、製造ラインの歩留りの問題も出たと思う。
サンプリング検査とか無作為調査法などと呼ばれている方法を使った検査の信頼性についてはそこで学んだはずである。

あの数字は私にとっては衝撃的で、統計量の威力は偉大だと思った。
のだが、あまり重要視していない人が多いのは、学校でちゃんと学ぶ機会が無かったからなのだろうか。


高卒の人は、大学教育を受けていない、という以外に高校教育を十分理解できていない、ということに最近気付いた。
(上記は単純に学力が問題で大学に進学出来なかった人に対して。)
大学入試って高校時代の学力の試験だし、言われてみれば当然なのだが。

Java叩き【年寄りが若年層を虐めているという構図】

プログラマ板でJava叩 き【年寄りが若年層を虐めているという構図】というスレッドを見つけた。
なんとなく興味が出たので覗いてみると、自分の意見だった。

私がここに書いたのが9/19、おそらく深夜だろう。
それに対し2chにスレッドが立ったのが9/20の14:30ごろ。
@niftyのココログは昔書いていたMemorizeより人の目 に触れやすいということだろうか。

スレッドを一通り読んでみた。
最初の頃はプログラム板、プログラマ板にありがちな言語比較、死滅系の内容だが、240番辺りか らテストの在り方、のような話になってきている。

テストについては、数が多ければ多いほど良い、と考えているわけではない。一般的にもそのような考え方はされていないだろう。
ちょうどすぐ前にも書いたが、境界を認識し、その境界で区切られた領域(及び境界上の領域)ごとにテストが実施されなければ意味が無い。同じ領域で似たよ うなテストを何回行っても効果は薄い。
JUnitでテストを作成し(テストコードに誤りはないとする)、カバレッジ100%ですべてのテストに成功するにもかかわらず意図しない動作をさせるプ ログラムは容易に作成可能だ。

しかしテスト数に意味が無いかというとそうではない。
領域の数に満たないテスト数であれば、テストされない条件があるのは自明である。
ただし、全ての領域をテストしなければならない、というプロジェクトは少ないと思う(体面上はともかくとして)し、実際の業務システムに対し実施すること は現実的に不可能だ。

適切なテスト数を決定するのは難しい。
システムの規模に応じてテスト数を増減させると言われても、じゃあシステムの規模ってどうやって測る？
その規模の大きさ1に対してテスト数はいくつに設定する？

ソース行数何行に対してテスト何個、という決め方は、上の疑問に対して答えを明確にしている、という点では評価するところはあるのかな、とスレッド後半を 読んで思った。
経験的にその割り合いが決定されているのであれば、信頼性もある程度は保っているのだろう。
(自分自身がその方法を推奨するかと言われれば、それはまた別の話。)

スレッドにも参加してみようと思う。
時間に空きが出来れば。

境界条件

テストを行っていて思ったのだが、「境界」というものの重要性を認識していない人が多いように感じた。
境界条件テストというものは、テストケースを作成する上ではメジャーなもののはずであるのだが、実践するとなるとそういう基本的と言われている類いのもの でもやはり難しいのだろうか。


久しぶりにVisualStudio6でCのコードを書いた。
コンパイルするまで誤りが分からないのがこんなに苦痛に感じるのは、EclipseでJava開発を行っていたせいだ。
Eclipseを使い始めたときは、いちいちうるさいなぁ、そこはこれから書くところなんだよ！とか思っていたのだが、これが慣れと言うものか。
ちなみに私はリターンキーと同じくらいの頻度でCtrl+Sキーを押す癖があるが、昔からMacOSなりWindowsなりを使用している人共通の性質で あると信じている。


衝動買いをする機会も殆ど無かったので、久しぶりの休みには積極的に欲望を前面に押し出してみた。
結果として、スノーボードの用具一式が家に揃ったが、置く場所を確保するために部屋掃除が必要であり、その時間がいつ取れるかが未決である。


資格について書こうと思ったことがあるのだが、考えをまとめている時間が無いため次までの課題としておく。
そのまま忘れる可能性も高いが。
そういえば、久しぶりに情報処理技術者試験センターのサイトに行ったのだが、昔 と比べて大層スマートになっていたのに驚いた。

一般的に言われるところのデスマーチ

少なくともこのblogを利用し始めたときには関わっていた案件が、やっと終わりを迎えようとしている。
開発言語にはJavaを利用していた。
この案件以前はC(とほぼベターCとしてのC++)しか経験が無かった。

Javaのコンパイラ(javac)の時点では本番用のものであっても、デバッグ->on、最適化->offにしておくのが一般的(少なくと もCの場合と比べた場合)らしい。が、本当なのだろうか。

そういえばこのプロジェクトでは、C実行モジュールでも最適化は行っていないものが多い。
確かに、以前少し測定してみた限りにおいては、実行速度に大差は無いように見えた。
しかし、かなりパフォーマンスが要求されるはずの箇所でもそのような実行ファイルがあるようなので、いずれ調査は必要ではないかと考えている。
数値計算系のプログラミングを大学でやっていた経験からすると、最適化の有無が速度に関係しないというのが信じられないのだが…

JavaはNullPointerExceptionのような実行時エラーでも、比較的容易に原因が突き止められるのが有難いと思ったのだが、debug をoffにした場合、最適化をonにした場合はどうなのだろう、また実行速度と障害原因特定容易性とのトレードオフはどの程度なのだろう。


次案件はC++で決まりのようだ。そういう縁もあってC++の設計と進化を読んで いる。
どこかのサイトで「ストラウストラップの弁明集」といった風な説明がされてあったが、この本を一言で言うのであれば最適な表現だと思う。


GUIを持ったクライアントアプリケーション(おそらくOSはWindows)の案件も別件で入りそうである。
パフォーマンスが要求される場合、現状ではどういった開発環境が選択肢としてありえるのだろうか。
まだやはりVC6なのだろうか。JavaはGC大丈夫なのだろうか(-serverオプションでもつけるか？)。.NETはGCのパフォーマンスの話をあ まり聞かない、そもそもクライアントサイドの本格的なプロジェクトの話自体あまり聞かない。アンマネージドC++は商用パッケージのサポートが薄い。
ここはひとつリッチクライアントというやつでFlashやらCurlやらでやろうか、という意思は初めから無い。
ふとMicrosoft のサイトを見ると、VC6のメインストリームサポートというものはすでに終了している。とするとこの選択肢も消えるわけか。
(案件におけるリスクとしては、言語・開発環境よりむしろ担当者のスキルや思想が問題になる可能性が高いと思うのだが、まだ新人だし、あまりそういうこと まで考えなくても良いように進めばいいな、と敢えて言語問題に逃避。)