生年月日から年齢を計算する簡単な計算式

最近知ったんですが、生年月日から年齢を計算する簡単な計算式というのがあるそうです。

(今日の日付-誕生日)/10000の小数点以下切捨て。

PHPで書くとこんな感じです。

echo (int)((20070608 - 19850101)/10000);

アルゴリズムって芸術ですね。

※補足1(2007/8/21)
「公の世界では年齢の判断って業務ごとに異なり、誕生日の前日に年齢取得させる業務が多い」とのことを聞きました。くわしくはこちらをご覧ください。alittlethingさん、ご指摘ありがとうございました。

※補足2(2007/8/21)
このエントリーで大きくわけて2つの批判をいただいていると理解しております。1つ目は「ソースコードとしてひどい」というものです。これについては簡単に試せるようにサンプルとして載せただけなので、PHPの実装として適切であるかどうかは読者のご判断におまかせします（最適な実装について具体例を挙げて説明してくださった皆さんありがとうございました）。 ただ、一応「動く」という意味では批判されるほどのことなのかなあと思いました。

2つ目は「これアルゴリズムといえないのでは？」というものです。まぁそうかもしれませんが、こんな些細なことで大騒ぎされるのもどうかと思います。この記事にその旨一言コメントいただければ済む話しな気がします。

^Mを取り除く方法

テキストをviで見ると行末に「^M」と表示されることがあります。これはWindowsとUNIX・Linuxなどの間でファイルのやりとりをしているときに良く起こります。これは双方の改行コードの扱いに由来する問題です。

ちなみに改行コードはWindows(SJIS)のときはCRLF、UNIX・Linux(EUC)のときLR、MAC(JIS)のときCRです。

さて、本題ですが、^Mは余分なCRが原因ですので、それを取り除けば問題は解決します。ここでは4つの方法を記します。

【1.viで除去する方法】
vi の文字列置換を使用して CR を取り除くためのコマンドは

:%s/^M//g

となります。まず「:」を押下しコマンドモードに入り、%s以下を入力しますが、ここで注意は^Mの入力です。これは文字通り「^M」と入力するのではなく「Ctrl+V」「Ctrl+M」と入力します。すなわち「:」「%」「s」「/」「Ctrl+V」「Ctrl+M」「/」「/」「g」[Enter]と入力します。

【2.コマンドラインから除去する方法】
tr -d '\r' < input_filename > output_filename

【3.PHPで除去する方法】
$line=str_replace("\r\n","\n",$line);

【4.Perlで除去する方法】
s/\x0D\x0A|\x0D|\x0A/\n/g;

ライブラリを使いこなしましょう

最近の開発環境は昔と比べてとても豊かになりました。よく使う機能の多くがライブラリ化され、よくあるパターンの実装であれば短期で簡単に行えるようになり時代の進歩を感じます。ところが世の中にはせっかくそのような資産を活用しようとせず、全て1からプログラミングしたがる人もまだまだ多いようです。そこで今回はライブラリを使いこなすことを強く推奨してみたいと思います。

【ライブラリの便利な点】
・しばらくプログラミングから遠ざかっていて最近またプログラミングを始めて驚いたんですが、実装しようと思っていた機能のほとんどがライブラリ化されていて、極端な話し、関数を1つ呼び出すだけで実装が完了してしまうなんてことも不思議ではないくらいです。(メリット1:実装量を減らせる)

・また実装量が減ったことにより開発工数が激減します。(メリット2:開発工数を短縮できる)

・当然実装量が減るとバグ発生量も激減します。(メリット3:バグ発生量が減る)

【ライブラリを使わない人の心理】
そのようなメリットがあるにも関わらず世の中にはライブラリを使いたがらない人もまだまだ多いようです。その人たちの心理はおおよそ次のようなものだと思います。

1. 他人が書いたコードは怖くて使えない。(職人的思考)

2. 正直なところ、テクノロジーの進化についていけない。(時代に取り残されている)

【考察】
正直なところ僕自身も最近時代に取り残されている感じを持っています。例えばperlなんですが、僕がperlを始めた頃はCPANなんて便利なものは多分なかったです。なので未だに「何か開発するときは最初にCPANを探す」という習慣がついてません。が、今後も開発を続けるのであればちょっと遠回りでもライブラリの利用を押さえる習慣をつけていくと実装力は間違いなく向上すると思います。（が、反面職人的なプログラミングテクニックは失われていくんだろうなあ）

海外ソリューションのローカライズで微妙なbug

現在海外ソリューションをローカライズして日本仕様にするプロジェクトのプロマネをしてますが（最近ではシステム管理から離れてばりばりSIやってます）が、現時法人では正常に動くのに日本では動かないというバグがあり、何故かな～と調べてみると、とても微妙なことが問題でした。

例えばjavascriptでこんなコードがあったとします。

if ( date1 <= "05-12-31" ){
  alert("昨年は設定できません。");
  return false;
}

これがどうしても動かないんです。date2に何が入っているかを調べたら、日本語OSの場合は日付が"06/01/11"、韓国語OSの場合は日付が"06-01-11"となっていました。国によってスラッシュかハイフンか違うんですね～。

個人的にこれからは日本のIT企業はもっと海外に出て積極的に外貨を稼がねばならないと思っているのですが、こういう微妙なところからつまづいている限り、国際進出はなかなか時間がかかりそうです。な～んて。

【C#】 ウィンドウの形を自由にデザインする

今更ですが最近VC#.NETのプログラミングを半分趣味で始めました。昔チャレンジしたVC++6.0と比べると本当にプログラミングが簡単になりました。VC++6.0ではやりたいことを実現するまでに覚えなければならない難解な要素が非常に多かったものですが、VC#.NETでは難解で意味不明な部分の多くがなくなりかなりわかりやすくなりました。一時プログラミング引退を宣言しましたが、これならまたやってみてもいいかも、と思うようになりました。

と、前置きが長くなりましたが、今回はいろいろプログラミングの実験をしているときにいくら検索エンジンをまわしても出てこなかったウィンドウの形を自由にデザインする方法を覚え書き的に記してみたいと思います。ここでは型紙となる画像を用意するとウィンドウがその形になってしまいます。非常に簡単でいいですね！

Keyword: C# ウィンドウ デザイン Form リージョン ビットマップ

private void Form1_Load(object sender, System.EventArgs e)
   // Windowの形を設定するregion定義
   Bitmap bitmap1 = new Bitmap("C:/background.gif") ; // 型紙の画像をロード。BMP/GIF/PNG/TIFFに対応。JPGは駄目らしい。
   bitmap1.MakeTransparent(Color.Blue) ; // 型紙の透明色を設定
   this.Size = bitmap1.Size ;
   this.BackgroundImage = bitmap1 ;
   this.FormBorderStyle = FormBorderStyle.None ; // Formの枠を消す
}

外見のきれいさと内面のきれいさ

サービス開発において、開発者は得てして内部構造やソースコードの綺麗さにこだわり肝心な外見（ユーザから見てシステムがどう見えるか）にはあまり関心を持たないケースが多いと思います。しかし実際はサービスは外見のきれいさがとにかく重要なんだよ、ということを今回は述べてみたいと思います。

【開発者が内面をきれいにしたがる心理】
優秀な開発者は総じて設計やソースコードに対して潔癖な傾向があるように思います。その理由はソースコードの高い可読性、機能の拡張性、メンテナンスの容易性のためであることが推測されます。たしかに優秀な開発者の作成したプログラムというのはプログラミングをかじったことのある人が見ればその素晴らしさが一目瞭然で芸術作品を鑑賞するかのごとく感嘆する場合も多いです。

【会社からは何が求められているか】
ところがそういった芸術的こだわりは仕事の現場ではあまり評価されないという現実があります。何故か。それは会社から求められているものが顧客からお金がもらえる成果だからです。乱暴な言い方をすればユーザが満足さえすれば内面はどうであっても構わないということです。言うまでもないことですが、納得しましたか？　はい、納得いかない人も多いですね。「設計やソースコードが汚いとあとで何か問題が起きたときどうするんだ」とか、「結局そういう場合は我々が直さざるを得ないハメになるんだから最初の段階で内面を綺麗にしておくのは評価されてしかるべきだ」と普通は思うわけです。

こういう場合はこう考えたらよいと思います。それはずばり収益的にどう貢献するのか数値で算出するとどうなのか。やろうとしていることが会社にとって明らかに利益になるのであれば数値で示しましょう、と。煙に巻いているように見えますか？　でも会社というものはそういうものです。上層部を説得できない理屈は独り善がりの考えでしかないと割り切るのがよいと思います。もし「上層部は無能だから」という考えをする方がいたとしたらそれはとても愚かです。物事を人のせいにするということは逃げでしかありません。もちろん「それはずばり収益的にどう貢献するのか数値で算出するとどうか」をきちんと算出して誰の目から見てもそのほうが合理的という場面でも上層部の対応がない場合は別ですけどね。

【まとめ】
自分のミッションはあくまでも成果物の外見をきれいに整え、顧客の要求を満たすということであると割り切ることです。もし内面についても評価の対象にされたければ上層部にその有用性をきちんとデータを用いて立証しながら示すべきです。それをやらずに上層部の無能さを嘆いても何も進展しません。もし自分が優秀で上層部が無能であるという確信があるのであればいっそのこと独立して自分の思い通りにやるのがよいと思います。