FC2ブログ

年齢ってやつ

「丸め」でつついた重箱の隅シリーズの続き。

業務系の会員管理関係のシステムでは、「年齢計算」をする場面が出てくる。
例えば、生年月日を入力させて、登録申請時に年齢計算をし、18歳未満なら拒否する、とかそういうの。
この年齢計算ってぇのが実はちょっとした曲者で。

何が曲者かというと、誰もが一度は疑問に思ったことがあるであろう、学齢の絡み。
4月1日生まれの人は早生まれとして一学年上になるアレ。
4月1日生まれの人は、3月31日に一つ歳をとっちゃうんである。

もう10年も前にこの年齢計算でひとくさりゴネた事があるんだが、
18歳未満ならエラー
という要求仕様で、「年齢の更新日はいつか?」という質問をしたところ、さんざんバカにされたことがある。

誕生日になったら一つ歳を取るんだよ!当たり前だろっ!

と実際言われたんだが...
その時は、それでも頼み込んでクライアントに確認をとってもらい、結局、誕生日になった時点で更新するという事になった。

で、もしこれを読んでいて、「当たり前だろ」と思うようであるなら、是非、これを読んでもらいたい。
年齢計算ニ関スル法律(Wikipedia)

実際に世の中では「年齢は誕生日に更新する」としている業種は多いし、計算も簡単なので、それはそれで良いのだが、そうでもない業種や場面が存在することを認識して欲しい。

元々は、
  • 誕生日の前日の満了(前日の24:00)に更新
  • 誕生日の開始(誕生日の0:00)に更新
という、時間的には同一の時点を指しているものが、表現の違いにより、日を基準にしたところ、
  • 誕生日の前日に更新
  • 誕生日に更新
という二つの仕組みが世の中にできあがっている。

今年一気に売上を伸ばしたtotoも、管轄は文部科学省なので、もしかしたら19歳の誕生日の前日に購入できてしまうかもしれない。


こういうことを意識しておくのはプログラマの責任だと思っているので、(バカかお前は)の視線にも負けずにこれからも生きていく所存でございます。

あぁ、ひねくれものさ。(^^;
スポンサーサイト

丸め

なんちうか、素直な人が多いというのか。

そこは四捨五入でいいです

でいいです、って軽く言ってくれるもんで。四捨五入の意味がわかって言っているのかいないのか。

小学校で習う四捨五入っていうのは、プログラミング的には、Round-Half-Upってぇやつで、4はゼロに近い方へ切捨て、5はゼロから遠いほうへ切上げるやり方のことであって。

「1.4は1になるでしょ?1.5は2になるんですよ。(バカかお前は)」
みたいな顔してみないで欲しいんだけどなぁ(^^;
「んじゃー、-0.5は-1になっていいのね?小さくなるけど」
「あれ?、えと、あれ??」

ゆとりのせいにはできない年齢だぞ君。


閑話休題。
「丸め」というのはプログラミング的にはいろいろあって、
  • Round-Up (切り上げ:ゼロから遠い方へ)
  • Round-Down (切捨て:ゼロの方へ)
  • Ceil (切り上げ:大きい方へ)
  • Floor (切捨て:小さい方へ)

これらを組み合わせて、
  • Round-Half-Up (4はDown、5はUp)
  • Round-Half-Down (4はDown、5もDown、5超はUp)
  • Round-Half-Even (4はDown、5は近い偶数、5超はUp)

てぇのが存在する。
特に、Round-Half-Even(Banker's Rounding)は、JISでも推奨されている丸め手法で、累計時の誤差を抑える効果があって、(小数点付きの)金銭を扱う場合には良く使われる方法である。
上記以外にも、奇数丸めやランダムな丸めなんかがあるが、こちらはたぶん一生接することはないだろう。(^^;

市販の丸め関数が実装されたソフトウェア(Excelとか)には必ず、Round()の丸め方の説明があると思う。そして調べたわけじゃないが、Round()をRound-Half-Evenとして実装しているものの方が多いかもしれない。(たぶん想像以上に)

たかが丸め、されど丸め、なんだけどもなぁ...

(実数~小数下指定桁~の丸めだと、精度/有効桁の関係で処理が更にめんどくさくなるんだが、「四捨五入でいい」っていう感覚の人間にはわかんないんだろうな(__;)

逆順TreeMap

またまたJavaの備忘録。

順序付きのTreeMapに格納されたデータを逆順で取り出す。

C++では、reverse_iteratorが使えるのでmapの構造自体を意識することなく、昇順でも逆順でもiteratorを使い分ければ済む話なのだが、Javaではどうもそうはいかないようだ。


例えばC++

std::map<int, std::string> mp;
mp[4] = "def";
mp[2] = "abc";
std::map<int, std::string>::reverse_iterator it;
for (it = mp.rbegin(); it != mp.rend(); it++) {
    std::cout << (*it).first << ":" << (*it).second << std::endl;
}


4:def
2:abc

6.0からはTreeMap.descendingSet()が使えるようだが、5.0ではそれもかなわず。
どうも、Mapの作成時に逆順のComparatorを指定しなければならないようだ。


Map<Integer, String> mp
    = new TreeMap<Integer, String>(Collenctions.reverseOrder());
mp.put(4,"def");
mp.put(2,"abc");
for (Map.Entry e : mp.entrySet()) {
    System.out.println(e.getKey() + ":" + e.getValue());
}


4:def
2:abc

ひとつのMapで昇順、逆順を切り替えて取得するには、とぉぉぉっても不便そうだ。
逆に言えば、コンストラクタで指定するだけで、Iteratorを書き直す必要が無いということで便利な場面もあるか。ふーん。

Javaってみたり

Javaの仕事してたりする。

EnterPriseで言うところのAPあたりのちまちましたのを担当してるんだが、なにぶん素人に毛が生えた程度のJava-erで。JDK1.0でアプレットを書いた程度だものなぁ。

そいでまぁJavaだけにコレクションの類も十分揃ってはいるんだが、C++のSTLでいうところの、std::pairが見つからない。
例えば、
HashMap<Integer, String>
なんてので、順序(ソートではなく)を持たせたい場合-MapではなくListで行いたい場合-、C++では、
std::list<std::pair<int, std::string>>
と書くようなことをJavaでなんとかと思うんだが、このstd::pair相当がなんだったのか思い出せない。
parallel~とかなんとかだったかなぁ...
Listでは2値を持てないし、記述も煩雑になってしまうから、できれば2値をメンバに持ったClassを書きたいところなんだが、開発上のルールでファイルを増やせない。
そんでもって、型定義でなんとかtypedef風に、とも思うんだがそれもようわからん。そもそもJavaでマクロとかプリプロセッサとか無ぇだろうと...

うーむ、こうなってみると結構C++ってのも病的なもんだな...

#2007/06/20 追記
List<Object[]>とすることで期待する動作に。(詳細はコメント参照)
深いな、いや、浅いというか深読みし過ぎたというか...硬いな>頭 orz

OSC2007

OSC (Open Source Conference) 2007 が今年も開催される。
Open Source Conference 2007 Hokkaido

例年と同じように、MySQL等のDB、Xen等の仮想化技術、Apache関連、が主体(でもないか)だが、Microsoftの楠さん(別に知り合いでもなんでもないが著名な人)の話が聞けたり、北海道マイコン・ソリューション研究会による「昆虫型6足ロボット」が見れたりしそうだ。

去年は都合で行かれなかったので今年こそなんとか行きたいなぁ。

情報流出とか著作権とか

たまに契約書を見直したりしてみると、委託者を、受託者(プログラマ)をとして、
著作権の一切は甲に帰属する

なんて事が書かれていたりする。
これを文面通り受け取ると、プログラマは、
  • 甲の環境で
  • 甲の指示により
  • 甲の求めるコードを書く
という事になるわけなんだが、現実はどうかというと、
  • 客先でパイプ椅子でメモ帳で
  • 口頭の簡単な説明により
  • 乙の頭の中だけの技術で
  • 乙が仕様書を作り
  • 乙がスケジュールを作り
  • 乙がテスト仕様を作り
  • 乙がテストデータを作り
  • 乙がテストを行い
  • 乙が納品物を仕上げる
事が多い。それでも著作権は甲のものとなる。まぁこれはそういう契約なのだから、下請法や独占禁止法に引っかからない限りは受容しなければならない部分ではある。

しかし、これまでの経験上、不思議と著作者人格権に関して書かれた契約書は無く、甲としてはこれをどう考えているのかがわからない。何も考えていないのかもしれない。

著作者人格権は譲渡できる性質のものではないので、これこそ契約書に明記すべきであるのだが、誰も書かない。
著作者人格権はこれを行使しない

の一行でいいはずなんだが。

逆にこれを明記してくれていないことによって、プログラマ側は抵抗する武器を持っていることになる。
どの程度の力を持つかは適当な判例を探さないとわからないが、少なくとも昨今流行の情報流出に関しての末端プログラマへの不条理な責任転嫁に対しては、有効な脅しになるのではないか。

プログラマ側が守るべき守秘義務に関して契約書では、
業務に関わる一切の情報
と、もう何でもかんでものように書くのがもはや一般的となっているが、実際の裁判では「なんでもかんでも」は通用しないだろう。
甲および乙がその情報に対して機密/秘密という認識を持っていたか、また、そういう扱いをしていたかどうかも問題となる。

んで何を言いたいかっちうと、プログラマがもし万が一そういったなんらかの情報を外部に漏らしてしまったとされた場合、多くの現場の状況を見ると、十分反論の余地があると思うんである。

飲み会の連絡と同列に送られてくる、仕様書やソース。
排他もされず「ファイルサーバ」と呼ばれるただの共有フォルダ。
常にローカルへのコピーを要求される文書群。

内部ではそういった扱いをしてバラまいている情報を、漏らした、と言い張るのはかなり無理があるだろう。

Winnyでの流出では、後ろめたい部分があるせいか、その後のトラブルに関しての情報が少ないが、このような契約形態が続くのなら流出事故はどんどん増えるだろうし、黙っていないプログラマも出てくるだろう。
そしてこういった(技術屋的にはまったく)つまらない問題は結局、品質低下に繋がる。


こういったダメダメスパイラルから脱却するためにも、今一度、契約書の内容を見直す事が、甲乙両者に必要なんじゃまいか、と遠い目で年寄りプログラマは考えたりする。

(決してエロ動画を見る合間に考えてみたのではない。決して無い。)
プロフィール

f_yamaki

Author:f_yamaki

アクセスカウンタ
最近の記事
最近のコメント
最近のトラックバック
月別アーカイブ
カテゴリー
ブロとも申請フォーム

この人とブロともになる

ブログ内検索
RSSフィード
リンク