2007年06月16日

SE からコンサルタントに転職しました

 タイトルの通りです。
 開店休業状態が続くこの Blog ですが、タイトルだけ改めて継続していこうと思います。
 今後ともよろしくお願いします。
posted by 市井賢児 at 2007年06月16日 01:56
| Comment(0) | TrackBack(0) | プログラミング


2005年11月25日

プログラム=アルゴリズム+データ構造+インターフェース?

Rogue Engineer's Diary / やさぐれ日記より「「アルゴリズム+データ構造=プログラム」? 本当に?」。

面白いネタなので、メモ代わりリンク。

オブジェクト指向がパラダイム変換を伴っていたのは間違いないけど、それを端的に表すシンボルになるかも知れません。
デザインパターンのように、もやもやとした理解や共有知識に名前が与えられることで、我々が明確に知覚できるようになる効果も大きいです。

一方で、「アルゴリズム+データ構造=プログラム」という言葉が、現状に沿わなくなっているにも関わらず、1つの定理であるかのように今もプログラマの間で伝えられていることも注目に値します。

面白い。
posted by 市井賢児 at 2005年11月25日 00:47
| Comment(0) | TrackBack(0) | プログラミング


2005年07月11日

SE のためのカレンダー学

…てな学問は冗談にしても、雑誌連載くらいあっていい気がします。
私が知らないだけでもしかしたらあるのかも知れません。

意外とカレンダーや時計関連のバグや不具合って多くないですか?
社会問題にまでなった 2000 年問題はあまりにも有名ですが、
週またぎや月またぎのタイミングで発症する週次処理の不具合や、
時差やサマータイムへの配慮が不十分なために出るバグ、
連携先のマシンの時刻設定に依存した処理、
処理日付と対象データ日付がくい違うと途端に挙動が一定しなくなる夜間バッチ郡などです。

最近の環境なら閏年の扱いなどは API や標準クラスなどが隠蔽してくれるのであまり気にする必要はないですが、日付をどう解釈し利用するかは設計によりマチマチです。
また、起算日とは何かとか、民法における年齢の計算方法などはある種の業務知識として体系化してまとめられてもいいと思います。
上記のようなキナ臭いポイントの他、日付にまつわる要件やテスト項目の注意点や、製品の仕様でここは確認しておこう、なんてのもまとめられたら役立ちそうです。

浮動少数演算の誤差のように、ほぼすべてのエンジニアが一度は直面する問題のように思えるのですが、どうでしょうか。
posted by 市井賢児 at 2005年07月11日 18:22
| Comment(0) | TrackBack(0) | プログラミング


2005年04月08日

Round() 関数は四捨五入関数ではない

 知っている人は当たり前なネタですが、知らないと素通りしてそのままにしてしまいそうなネタです。

 多くの言語に Round() 関数が用意されていますが、これは四捨五入する関数ではなく、「丸め」る関数です。
 名前のまんま。

 実は私、最近まで「丸め」とは「四捨五入のコンピュータ系方言」くらいに思っていたのですが、実は違いました。もっと広い言葉です。
 まず、「丸め」とはある精度以下の数値情報を捨てる処理のことで、「四捨五入」を含みます。他に少なくとも切り上げ、切捨て、そして今回話題にする「偶数丸め」があります。(もっとあるかも知れません)

 「偶数丸め」は IEEE 754 で定められており、JIS や ISO にも同じ規定があります。
 多くの Round() 関数の挙動もこの IEEE 754 に則った「偶数丸め」です。

 「偶数丸め」は四捨五入とほぼ同一ですが、次の1点が違います。
 「丸め単位の丁度まんなかで、どっちつかずの場合は、偶数側を採用する」
 したがって、1.25 を 0.01 の位で丸めると 1.2 になり、1.35 は 1.4 になります。

 俗に、Bankers Rounding(銀行の丸め)と呼ばれている計算方法だそうで、処理による誤差が「四捨五入」と比べて小さくなります。
 中央にあって本来どちらに属すかは半々であるものを「常に五入」すれば、半々でなく「常に大きく」なってしまいます。
 ですから「偶数丸め」は「四捨五入」よりも処理による誤差が小さくなります。

 先ほど「丸め単位」という言葉を使ったのは、2 を単位とする「丸め」や 0.5 を単位とする「丸め」もありえるためです。
 「丸め」は「四捨五入」よりも広い概念を示す言葉なんですね(四捨五入だと常に1×(10のn乗)を単位とします)。


 私、学生の頃に一部の言語でこういう挙動を見て「バグか?まぁ所詮○○だしな」と某社への偏見にまみれた思い込みをしていました。

  Round() がこういう挙動をする言語で四捨五入を実現する方法も常套手段があって、
 1)四捨五入したい位が1の位になるよう、(10のn乗)をかける。
 2)四捨五入したい値が正の数だったら 0.5 を足す。負の数だったら 0.5 を引く。
 3)小数点以下を切り捨てる(Int関数やFloor関数など)
 4)1)で使った数字の逆数をかける。(桁数を元に戻す)
 という処理です。(キャストや変数の型による精度も要注意)

 VB.NET だと
移動単位 = (10 ^ 桁数)
If 数値 > 0 Then
数値 = Math.Floor((数値 * 移動単位) + 0.5) / 移動単位
Else
数値 = Math.Ceiling((数値 * 移動単位) - 0.5) / 移動単位
End If
ですね。

  Round() の挙動が、あれはあれで正しいというのはちょっと恥ずかしい驚きでした。

 会計システムを扱っていた事がありましたが、自分が開発に関わった範囲では丸め、四捨五入は偶々なかったからよかったですが。
 消費税も含めて、日本円の金額か数量っていう自然数だけを扱っていましたから。
 でもこれで私が為替レートなど丸めが絡む仕様書を書いたら、曖昧さを混入させてしまうところですね。危ない危ない。
posted by 市井賢児 at 2005年04月08日 02:18
| Comment(2) | TrackBack(5) | プログラミング


2005年03月02日

メインフレームについて話してみる

私はメインフレーマ系の SI 会社でパッケージ導入を経験し、外資コンサル系 SI に転職した身です。
そんな立場からなら一つの視点を提示できるかも、と「プログラマの思索」より「システム開発のボトルネックはメインフレームに有り」のトラックバックです。

前の会社では、自社製メインフレームからのリプレースもやりました。
メインフレームの頃からお付き合い頂いていたお客様で、ハード的な老朽化やビジネス上の要求の変化から、 Windows ベースのシステムに切り替える、なんて案件もありました。

実際にお客様のビジネスを支える、という視点に立つと、既に充分な稼動実績のある、エンジニアが使う言葉で言えば「枯れた」システムに手を入れるのは大きなリスクが伴います。

確かに「開発」という作業から見ればメインフレームやオフコンはオープン系の技術との親和性が低く、連携が絡むと足を引っ張られる、邪魔くさい存在ですが、ビジネスプロセスをどう設計するかという視点からすれば、大きな意義のある存在です。

だって今、ゲンバで実際に役立っているんですから。
システムはそれがすべてでしょう?

さらに会計や人事給与なんかは商法、証券取引法、税法などの法律や各種社会福祉制度などで業務自体がガチガチに固められているので、既にあるメインフレーム上の仕組みを置き換える理由がなかなか出てきません。
例え連携で開発コストが増えたとしても、会計の仕組み自体を作り変えるよりはずっと安上がりですし、安心です。

それに業務アプリを作るソフトウェアエンジニアは見逃しがちですが、メインフレームで使われている技術ってスゴいですよ。
トラブルがあっても基本的に一社がすべて取り仕切るので、OSのバグやミドルウェアの不具合まで含めてサポートされるというメリットもあります。「それは Sun に、これは Oracle に」なんてことは絶対ありません。
どこのメーカーもある種の威信をかけてサポートしますからね。


メインフレーム自体は技術者の減少と共に徐々に減っていくだろうとは思いますが、なかなか無くならないでしょう。

私としてはメインフレームの問題は、むしろ保守体制が生むベンダーとの関係にあると思います。
どうしてもメーカーに頼りきってしまう。
確かにサポートは厚いけれど、それに見合う金額は支払わなければならないし、徐々にベンダーをコントロールする能力を失ってしまい、お客様が自分のシステムに対して主体性を持てなくなってしまう。

レガシーマイグレーションなんて言葉も流行りですが、単純にオープン系に置き換えるだけでは「マイグレーション」は不完全で、ベンダー依存の体質からの脱却が伴わなければ、またベンダーからいいように甘い蜜を吸われてしまうんじゃないでしょうか。
posted by 市井賢児 at 2005年03月02日 02:04
| Comment(0) | TrackBack(0) | プログラミング


2005年02月28日

プログラマの三大美徳

プログラマの三大美徳。それは無精、短気、傲慢。
Perl の生みの親である Larry Wallによる、Perl 解説本「プログラミング Perl」の「はじめに」で現れる有名なこの言葉。
同著の用語集に解説があります。

無精:
エネルギーの総支出を減らすために、多大な努力をするように、あなたをかりたてる性質。こうして労力を省くために書いたプログラムは他人も使うようになり、そのプログラムに関する質問にいちいち答えずに済ますためにドキュメントを書くようになる。それゆえ、プログラマにとって最も重要な素質である。またそれゆえ、この本が存在するのである。

短気:
コンピュータがサボっているときに感じる怒り。あなたの指令に反応するだけでなく、実際に指令を予測する−あるいは、少なくともそのようなふりをする−プログラムを書く原動力になる。それゆえに、プログラマにとって2番目に重要な素質である。

傲慢:
ゼウスの怒りにふれるほど、プライドが高いこと。また、他人にケチを付けられないようなプログラムを書く(そして維持する)ための原動力になるもの。それゆえ、プログラマにとって3番目に重要な素質である。


こういうイタズラゴコロ、大好きです。
この Larry Wall というおっさん、「プログラミング Perl」では、言語解説書なのになぜか親しめてしまう文体で Perl を紹介し、講演では複雑なものから本質をすくいとってシンプルに表現してしまう。
憧れと尊敬を隠せない、愛すべきおっさんです。

三大美徳はhttp://www.lanl.gov/Document/で原文が参照できます。参考までに。
posted by 市井賢児 at 2005年02月28日 23:33
| Comment(5) | TrackBack(1) | プログラミング


2005年02月20日

グローバル変数:説明方法を変えてみようか

プログラマなら誰もが聞いたことのある「グローバル変数は使うな」という言葉。
「読みにくくなるから」との説明が多いけれど、「変化への対応が難しくなるから」というのはどうでしょうか。

結局は同じことを言っているけれども、プログラマやコーダーの視点での問題点よりも、プロジェクトやシステムの視点での問題点、悪影響を挙げた方が新人が「育つ」気がします。
顧客のビジネスモデル自体が変化への対応力を問われており、それを具現化したシステム、ひいてはプログラムにも変化への対応が求められます。それにアジャイル宣言の背後にある原則の2点目にも「変化の対応により顧客の競争優位に寄与する」との文言があり、若手プログラマ的にアツいトピックにつながりますし。

新たなバズワードの提案かも知れませんが、「読みやすさ」とか「保守性」よりも「変化への対応」の方が響く感じがするんですよね。

悪態のプログラマ」より「グローバル変数が嫌われる理由」のトラックバックでした。
posted by 市井賢児 at 2005年02月20日 23:38
| Comment(4) | TrackBack(1) | プログラミング


2005年02月13日

コンピュータが理解できるコードなら誰でも書ける。優れたプログラマは人間が理解できるコードを書く。

Martin Fowler, Refactoring, 1999 より。
オリジナルは 'Any fool can write code that a computer can understand. Good programmers write code that humans can understand.' 日本語訳はピアソンエデュケーションから「リファクタリング プログラミングの体質改善テクニック」というタイトルで出版されています。


良いプログラムの指針として覚えておきたい格言ですね〜。

よく「コメントの多いコードが人間にとって理解しやすいコードだ」という人もいるけれど、本当の意味での理解しやすさは、コード自身が「自分は何をするか」を雄弁に語っているものだと思います。
そういったコードは大抵、設計が素直でネーミングがうまいんですよね。この Refactoring の中でも、ネーミングは訓練すべきスキルだとされています。関数内のある処理に名前をつけたいがために、そこを別関数に切り出すことまでしています。

そう、ネーミングって意識して伸ばしていくべきスキルなんですよね。やってないけど。(^^;
英語は苦手だしな…
posted by 市井賢児 at 2005年02月13日 00:16
| Comment(2) | TrackBack(0) | プログラミング


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。