2007年02月19日

PPMのワナ(Perl 5.8)

久々にperlを新しくしてPPMを使おうとしたところ、407(Proxy Authentication Required)が返ってくる。
会社の環境はユーザ認証が必要だけど、今まで環境変数HTTP_proxy_userとHTTP_proxy_passでどうにかなってたのに。
調べてみたところ、5.8以降のPPMは環境変数の指定方法が変わっている。
activestate.comによると、環境変数HTTP_proxyに全部指定しろということらしい。


5.6まで:
HTTP_proxy=http://hostname:port
HTTP_proxy_user=username
HTTP_proxy_pass=password

5.8以降:
HTTP_proxy=http://username:password@hostname:port
意味のない仕様変更のおかげですっかり時間をとられてしまった。やれやれ。

人気blogランキング



posted by まる at 22:48| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2006年12月02日

定数のチェックはちゃんとやりましょう

一ヶ月更新の予定だったのに、10月、11月は書けずに過ぎてしまった。
申し訳ないので、今月は3本をノルマにしときます。

最初は軽く定数のチェックをサボったおかげでヒドイ目にあった話。

ずっと快調に動いていたプログラムが3月に入って、突如動作を停止。
顧客「3月に入って動かなくなるって、まさか月処理を間違えてないですよね」
自分「そんなことはないですよ。これはプログラムの〜というバグだと思いますよ。」

その場を切り抜けてから、モジュールを調べてみたら、
3月を判定すべきところに「may」と書いてありましたとさ。

アルゴリズムは問題なくても、定数まで含めてちゃんとテストしなかったおかげで、顧客先でのしょうもないバグ。
テストは定数値のチェックまでやりましょう。

人気blogランキング

posted by まる at 09:49| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2006年09月19日

高レベルと低レベル

高レベル、低レベルとコンピュータ屋さんが言った場合、一般の人が使う意味と違います。

一般的な意味でも使用しますが、コンピュータ屋さんの高レベル、低レベルは、ハードウエアに対する抽象化の階層(レベル)を意味する場合が多い。BIOSなどのハードウエアべったりのものが底辺。ハードを意識して書くアセンブラ。アセンブラを抽象化したC。C以上にハードの依存性を低くしたJava、Perlなどがその上でしょうか。

言語論争の途中なんかで高レベル、低レベルと言ってるとどっちの意味でも通用する面白い文章が出てきたりします。

「Cなんてレジスタをポインタに置き換えてるだけの低レベル言語じゃないか。Javaはポインタやメモリ管理も隠蔽した高レベル言語だ」

文脈によってどっちとも取れる文ですね。
どちらの意味かは読者の良心におまかせします。

人気blogランキング

posted by まる at 00:42| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2006年07月15日

安田生命と皇紀

中国は4000年、朝鮮は半万年だとしたら、日本の歴史はどのくらいなんだろうという会話になりました。
エライ人に尋ねたところ、「日本は皇紀なんじゃない」とお言葉をいただきました。

wikipediaの皇紀
ふむふむ。皇紀は西暦に600年足せばいいのか。だから今年は2666年っと…

皇紀と安田生命保険
安田生命保険(今の明治安田生命保険)は1970年代に個人情報管理のシステムを構築することになった。その際システムの担当者は、20数年後に生じるであろう2000年問題を予測していた。そこで、年号の下2桁をグレゴリオ暦や元号ではなく神武暦(グレゴリオ暦−40年)を使用した。そのことにより、安田生命保険は2000年問題を40年先送りした。
誰がうまいことを言えと(ry

実際に2000年問題に対応した身としては、うらやましい。の一言に尽きます。

昭和、平成などの元号で表示する場合は変換するから、西暦だろうと皇紀だろうと内部で使用する分には関係ないし。
もうひとつ嬉しいのが、いわゆる2038年問題まで回避できること。
ここまで考えた安田生命の担当者には頭が下がります。

人気blogランキング

posted by まる at 22:29| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2006年06月09日

MS06-13によるActiveXのワナ

小雨がしとしと降り続く中、いそいそとテストしていたところ、顧客から怒りの電話がきました。
おそるおそる事情を聞くと、ウチの提供してるサービスを使うとIEがフリーズして作業できないとのこと。
以前は問題なく使えていたのに、ある日を境にフリーズするようになったそうで。

そのサービスではHTML中にActiveXで画像を表示させていますが、以前はなんともなかったのに、電話を受けた時点では画像が一瞬消えるとのこと。こちらでも確認したところ、画像が少ないうちは「画像が消えるなー」という印象ですが、画像が増えると再描画に処理時間を喰われるようで、IEがフリーズします。
ウチはそのサービスに手を加えていないし、ある日を境に動かなくなっているので、IEのパッチが怪しい。調査した結果MS06-13が原因と判明。
MS06-13の説明とか、KB912812の説明によると、ActiveXの扱いを「無条件に使用可能」から「手動で有効にした後でのみ使用可能」に変更した影響のようです。KB917425を適用すれば回避できるので、顧客にはこれで回避してもらいました。

回避策があるといっても、全ての顧客にKB917425を当ててもらうのも面倒。そこで、Microsoft様のご指導に従い修正します。

もとのソース

// test.htm
<object classid="clsid:FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF" id="test"
  codebase="http://foo.com/activex/test.cab#version=1,0,0,0">
    <param name="Target" value="...">
    <param name="ImageURL" value="http://foo.com/test.bmp">
</object>

修正後のソース
// test.htm
<div id="DivId">
    <script src="createElementExplicit.js"></script>
</div>

// createElementExplicit.js
var myObject = document.createElement('object');
DivId.appendChild(myObject);
myObject.classid= "clsid:FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF";
myObject.id="test";
myObject.codebase="http://foo.com/activex/test.cab#version=1,0,0,0";
myObject.Target="...";
myObject.ImageURL = "http://foo.com/test.bmp";

これで、画像が消えることなく動作するようになりました。やれやれ。

人気blogランキング

posted by まる at 21:49| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2006年04月04日

期末のたたかいかた

期末の忙しさにかまけて、更新が停止してから一ヶ月が経過してしまいました。 更新をいったん止めてしまうと、再開が大変ですね。

今回は、期末のやりすごしかたです。
納期直前に終わらない〜 と頭を抱えている場合。
どうするか。

1.にげる
2.たたかう
3.そのた

あなたならどれをとりますか。

1.の「にげる」は訴えかけるものがある選択肢です。後を考えなくてよいのなら、0コンマ1秒の迷いもなく選びます。 ただし、「○○はにげだした。。。しかし、まわりこまれてしまった」となるとシャレになりません。「つうこんのいちげき」を喰らって一発昇天かもしれません。

2.の「たたかう」は、死ぬ前に勝てるかが問題です。レベル1で『りゅうおう』と戦おうとしていたら勝ち目などありません。「はげしいほのお」を吐かれて昇天です。そう考えると、「たたかう」は勝てる場合にのみ通用する選択肢ともいえます。まあ、そもそも勝つ見込みのない戦い(=納期に間に合う見込みのない仕事)を受ける時点で、何かおかしいという気はしますが。世の中にはオトナの事情という分かりたくもない事情があるわけで。

紹介したいのは、「そのた」です。
具体的には、いちぶ「たたかい」、いちぶ「にげる」戦法です。
こういってはなんですが、期末になってくると、できないものはできません。誠意を見せようと、徹夜しようと、休日出勤しようと、人を増やそうと、一ヶ月でWindowsをつくれと言われたってつくれやしません。

そこで、できないという前提の上で、どのように進めるかを顧客と相談します。 頑張れば期間内にできるのであれば、「たたかう」を選択すればよいのです。

顧客と相談する際には、工数に基づいた取捨選択リストを持っていき、期末までに何を達成し、何を残すかを顧客に選ばせましょう。顧客に選ばせてしまえば、我々の責任が少しは減り、次の期に作業を持ち越せます。
会社は来期にただ働きすることになってしまいますが、作業員は一息つけます。

一番いいのは、期間内にちゃんと納品できることなんですけどね。

人気blogランキング

posted by まる at 00:43| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2006年02月28日

SEに要求される力

SEとして大成するには、どういう能力が必要か考えてみました。
まあ、筆者が数時間考えただけなので、他にもいろいろあると思いますが、ご容赦を。

■全般
・文章作成技術
・報告、連絡、相談の徹底
・相手の立場になって考えれるか
・ひとりでかかえこまないか
・2徹、3徹を乗り切る体力
・英語の読み書きができるか

■対顧客折衝
・客、同業他社に対して仕様を押し通す折衝能力
・価格折衝に勝つ折衝能力
・大嘘を平気でつけるか
・客の雰囲気に合わせて出す技を変えられるか

■部下、PGへの指導
・部下への指導ができるか
・面倒見がいいか
・部下の悩みを察知できるか

■システム設計能力
・顧客から要件をヒアリングできるか
・与えられた具体的な要件から抽象的な仕様に変換できるか

■システム開発能力
・プログラミング能力
・プログラミング言語の習得能力
・仕様策定能力

■テスト能力
・大量データを流した場合にどうなるかの予想がつくか
・きわどいパターンを思いつけるか

■障害対応
・障害発生時になぜ?と考えて原因を追究する力

■姿勢・精神力
・客にいじめられても耐えられる精神力
・新しいモノに興味があるか
・新しい技術を使うべきところと、枯れた技術を使うべきところの見極めができるか
・SE関連業務の勉強が苦にならないか


ほかに、こういった能力が必要というのがあれば、教えてください。

人気blogランキング

posted by まる at 00:37| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2006年02月20日

富豪的プログラミングの弊害

最近の富豪的プログラミングに影響されてると、アルゴリズムを考えるのがおっくうになります。
ついつい、簡単に実装できるアルゴリズムを採用してしまいます。
しかし、実装する前に少しだけ考えてください。そのアルゴリズムで本当に問題ないのか。

大半の処理は性能に影響を与えません。しかし、一部の処理は確実に性能に影響を与えます。
その一部の処理だけは、手を抜かずに考えましょう。

実際に筆者がやらかした例を挙げてみます。

メタデータを管理するクラスを作り、メタデータ自身をファイルで保管していました。 データ量が膨大になるのは自明でしたので、データ自体の保存、読み込み処理は、当然、性能を意識して作成。 テストは何事もなく過ぎ、リリースしてしばらくのこと。

遅くて使えないと、顧客からクレームがきました。 顧客環境を調査したところ、メタデータの検索で時間がかかっている模様。 メタデータはたかだか100件程度だろうとタカをくくって、メタデータの探索は逐次探索としていました。 が、実際の運用環境では10000件を超えており、一件のメタデータの探索に、平均10ミリ秒消費していました。 ということは、全件の処理は10ミリ秒×10000件=100秒となります。 一回の処理に100秒かかるようでは、遅いといわれてもしょうがありません。 メタデータだから、そんなに件数がないとサボった罰です。逐次探索からハッシュ探索に切り替えたところ、1秒かからずに処理が完了し、問題は解決しました。

おかげで、顧客からイヤミを言われ、肩身の狭い思いをしましたとさ。

気に入った方はこちらもクリック。人気blogランキング

posted by まる at 23:42| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2006年02月07日

障害対応手順

前回の予告どおり,障害対応の手順を説明します。

  1. 障害の発覚
    第一報は,顧客か,監視ツールのエラーとしてあがってきます。
    そこで,何が発生しているのか,どのシステムに影響があるのか,現象を明確にし,他人に伝えれるようにまとめます。

  2. ユーザへの通知
    ユーザに障害の発生を通知します。 障害があってもシステムには影響がなかったり,ダウン時間が短くユーザにバレないと考えたり,ユーザにバレても誤魔化せると踏んだ場合は,ユーザに通知しないこともありますが。

  3. 障害情報の取得
    システムの挙動がおかしいときに,再起動するとそれなりの確率で直ります。しかし,勝手に再起動すると,障害が再現しないことがあり,原因不明で片付けられてしまいます。
    二度と発生しない障害ならいいのですが,この手の障害に限って保守部隊のいないスキを狙ったかのように発生します。
    そこで,保守部隊に確認して,再起動しても問題ないか,再起動する前に取得しておく情報がないか,先に確認しておきます。
    ま,自分のシステムのバグなら,自分で原因追求するだけなので関係ない話ですが。

  4. 原因の調査
    保守部隊に原因の調査を依頼します。自分が解析を依頼された場合は障害解析手順を参考に,どうにかしてください。

  5. 暫定対策の実施
    原因の調査で,不具合箇所の見当はつきます。
    次にOSやプロセスの再起動,縮退運転,待機系への切り替えなど,障害をとりあえず回避する対策を実施します。 ハードウエア障害で代替機がない場合や,システムの基本機能がバグっていた場合は,使用禁止にするしかありません。

  6. 本体策の実施
    調査を依頼した結果として,暫定対策以外にモジュールや,ハードウエアの入れ替えが必要であれば,改めて実施します。

  7. 障害報告書の作成
    ひととおり終わったら,ユーザに障害報告書を持って謝りにいきます。本体策までに時間のかかる場合は,本体策の前にいくこともあります。障害報告書には障害の概要,対応経緯,不良原因,対策などを書きます。
posted by まる at 00:28| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2006年01月30日

Fedora Core3でのWikiの使用

本来は障害対応の手順を解説する予定でしたが予定を変更ます。
Fedora Core3でのWikiの設定にてこずったので,備忘録として書いておきます。

Wikiを使ってみようとインストールしたのですが,うまく動きません。
別件で使用しているレンタルサーバには簡単にインストールできました。どうもWikiのインストールが下手だからというわけでもないようです。
どうもファイルの書き込みでエラーになるようです。しかも,/tmpへは書き込みできるのに,htmlの下には書き込めないようです。

なぜ,こんな現象が発生するのか。
調べたところ,SELinuxが原因と判明しました。

SELinuxでは,ファイルの読み書きに制限を与えます。そのため,CGIやPHPからファイルの書き込みを行うとエラーとなります。
エラーにさせない方法は二つ。

  • SELinuxを使わない
  • SELinuxでhtmlを書き込み可能とする
今回は一般公開しているサーバでもなかったし,調べるのも面倒だったので,SELinuxを使わない方法で対処しました。

まず,SELinuxを使用しているか調べます。

[root@localhost ~]# getenforce
Enforcing

Enforcingと表示されたらSELinuxが有効となっています。 これは,setenforceコマンドで無効にできます(setenforce Permissive)。
しかし,setenforceコマンドではOSを起動するたびに設定する必要があります。
そこで,/etc/sysconfig/selinux を編集し,起動時にPermissiveモードに設定してもらいます。
具体的には SELINUX=enforcing の行をコメントにし,SELINUX=permissive を追加します。

[root@localhost ~]# vi /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
#SELINUX=enforcing
SELINUX=permissive
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

これで問題なくhtmlの下に書き込めるようになり,Wikiも動作するようになりました。
もうひとつの方法は別の機会に紹介します。
posted by まる at 00:46| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2006年01月24日

障害解析手順

最近プロジェクトに配属された新人と話していたら,障害が発生した場合の対処方法を知らないと言われました。
このサイトを見て勉強しろ!と言おうと思い,過去の記事を調べたんですが,まだ書いてなかったんですね。
とっくに書いたつもりになってました。

そこで,今回は障害解析手順を説明します。

  1. 現象の確認
    顧客は「よく分からないけど、動かない」といってくるので,現象を明確にします。
    ・「動かない」と主張しているのは、どのような状況なのか。
     エラーメッセージを出力しているのか,アプリケーションが無応答となっているのか,OSがフリーズしているのか
    ・障害が発生する直前にした操作は何か。
     障害の発生した直前の操作に、障害解析のヒントが隠されています。どのような操作をしたかは教えてもらいましょう。
この時点で既知の不具合や,仕様の場合は分かるかもしれません。
  1. 資料採取
    OSがフリーズしていおらず,画面に何か出力されているのであれば,Alt+PrintScreenで画面のスクリーンショットを取ってもらいます。
    同時に使用しているOSのログ(Linuxだったら/var/log/以下のファイル,Windowsだったらイベントビューアの内容)も念のため送付してもらいます。
    イベントビューアは[名前を付けて保存]でファイルの種類をテキストまたはCSVにして出力してもらいます。イベントログ形式は,そのPCでしか出力されないメッセージがあるのでNGです。
    システムがログを出力していれば,ログを送付してもらいます。自分の作成したシステムでは,ログだけで障害が解析できるようにしておくべきです。
できれば,このフェーズまでで障害原因をつきとめたいところです。
そうもいかない場合は次に進みます。
  1. 開発環境での再現実験
    顧客から聞いた情報と資料をもとに再現実験を行います。開発環境で再現するようであれば,開発環境で原因の追究を行います。

  2. 実運用環境での再現実験
    障害が開発環境では再現できないけど,顧客環境で再現できるのであれば,実運用環境で再現実験をするしかありません。この場合,なるべく少ない回数で原因を追究できるようにしましょう。状況がゆるすのであれば,罠かけ用モジュールを設置するのも一つの手段です。
それでも駄目なら最後の手段です。
  1. あきらめる
    実運用環境でも再現しないのであれば,次回の障害発生に期待するしかありません。今回の解析で原因を絞り込めなかった理由を追求し,ログの出力を追加する等の対策を行い,次の障害発生を待ちます。

5はただの逃げなので,1,2ででどうにかしたいところです。マルチスレッドやメモリ破壊の問題は再現しづらく,原因も絞込みにくいので,原因不明のままになることも多いのですが…。力不足を感じます。

posted by まる at 00:36| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2006年01月10日

美しいコード

プログラマはコードの美しさを語りますが,プログラマ以外の人種からは何が美しいのかさっぱりです。 ときどき人からも聞かれるので,コードの美しさについて分析してみましょう。
  1. 読みやすいコード

  2. これはフツーの人でも理解できます。ソースコードを見れば一目瞭然。
    コーディング規約に従って書いてあるようなコードです。コーディング規約ではクラス・変数の命名規則,中括弧の取り扱い,インデントの間隔(タブ/空白4文字等),コメントのつけ方,Javadoc用コメントの有無,現場によっては関数当たりのステップ数や,空行の入れ方まで規定してあるようなものもあります。
    コーディング規約で統一していると,プログラマごとのコードのクセがなくなり,ソース全体が読みやすくなります。が,自分の好きなスタイルでしか書かないプログラマがいると簡単に崩壊します。ソースコードのレビューなどで,ソースをチェックしておくべきでしょう。

  3. 変更しやすいコード

  4. プログラムはしょっちゅう仕様が変わります。そこで,あらかじめ変更が見込まれる部分は,変更しやすいようにしてあるコードです。定数は変数としておき,データ間の関係を疎にし,データとアルゴリズムの間の従属性を減らします。
    仕様変更がかかってプログラムを修正する際に,あまりに簡単に変更ができるため,「美しい…」と言葉がでます。
    変更しやすいコードを書くプログラマというのは,えてして変更に弱いというのも面白いところです。

  5. 論理的に簡潔なコード

  6. ここまでくると,プログラマ以外には理解しづらいでしょう。プログラムではさまざまな条件分岐や繰り返しがあります。たとえば,xの値が0.3と0.5の場合はAの処理をして,xの値が1.5と2.0の場合はBの処理をする処理を書く場合を考えます。
    提示された条件を満たすだけであれば,0.3と0.5の場合を書いて,1.5と2.0の場合を書けば問題ありません。 if( x == 0.3 || x == 0.5 ){
      A();
    } else if( x == 1.5 || x == 2.0 ){
      B();
    }
    そこを一歩ひねって抽象化します。この場合は,xが1より大きいか小さいかにより分けてみます。 if( x < 1 ){
      A();
    } else {
      B();
    }
    こんな簡単な例だと当たり前のように思えます。しかし,複雑な条件を簡潔にまとめたコードを目の当たりにすると,思わず「美しい…」という言葉が漏れてしまいます。自分が書いたコードだったら,自分をほめたい気分になります。
posted by まる at 00:02| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2005年12月27日

IT業界の愉快な面々

さて,IT業界にはいろいろな登場人物がいます。簡単に登場人物を眺めてみましょう。
営業仕事を取ってくる人。あることないこと言って顧客から仕事をもらってきます。営業の言った,妄想,ではなく青写真を実装する立場としては気が重くなります。営業から「こんなのできる?」と聞かれたら,簡単にできることでも「難しいですね」と返しておきましょう。
コンサルタントシステムのあるべき姿を示す人。机上の空論を言って現場を混乱させます。なまじシステムを理解しているだけに,営業以上の無理難題を押し付けてくる人でもあります。できるコンサルタントならいいんですけどね。できるコンサルタントなら。
システムエンジニア(SE)顧客とやりとりしながらシステムを構築する人。定義のあいまいな職種です。営業とSEしか区分がなく,システムに関する作業はすべてSEという会社もあります。基本はシステム全体の概要とサブシステムごとの入出力を定義するのが仕事です。今日も営業からは無理難題を吹っかけられ,プログラマからは反発される悲しい中間管理職です。
プログラマコーダと同一視される場合もありますが,個人的にはサブシステムの仕様を検討する人と考えています。SEが提示したサブシステムの入出力からプログラムの仕様を考えるのがプログラマ。プログラマの作った仕様を実装するのがコーダ。
コーダプログラマが考えた仕様をコーディングする人。仕様書さえ完璧なら単純作業です。インドだろうと中国だろうと仕事を出せます。ま,日本で完璧な仕様書というのはそうそうお目にかかれませんが。
テスタプログラマが実装したソースをテストする人。プログラマがよく兼務しています。品質保証がしっかりしている会社では,専門のテスタを雇っていたりします。そのような会社では,今日もプログラマとテスタの仁義なき戦いが見られます。
オペレータシステムを運用する人。手順書どおりに作業すればよい場合が多いので,単価の安い仕事でもあります。問題が発生すると真っ先に影響を受ける人でもあり,IT業界のカースト制度が垣間見れます。
プロジェクトマネージャプロジェクトの責任を取る人。よく年長のSEが兼務しています。進まない進捗を管理し,問題点を上位の管理職に報告します。責任の割には給料が安い場合が多く,SE以上に中間管理職の悲哀を感じます。技術が好きなSEに管理職をやれというのが無理な話。必要性の割にSEから敬遠される職種です。
アーキテクトプロジェクトマネージャに代わるキャリアパスとして人気なのがコレ。技術面でのエキスパート。システム全体の設計を行ったり,DB・ネットワークのスペシャリストとして活躍します。技術が好きなSEが目指しますが,少数しかいらないので狭き門です。ホントはSEだけど,単価を上げるためにアーキテクトを名乗ってる人はたくさんいますけどね。
posted by まる at 00:45| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2005年12月20日

それほど間違っていないプログラマ用語辞典

「それほど間違っていないプログラマ用語辞典」
著者:MW 価格:¥1680

プログラマの現場で耳にする単語や,誰かがやっている行動をまとめた本。
読みながら「あるある」と頷いたり,ニヤリとさせてくれます。

20時から会議をするのを不思議に思わない心理。「疲れたよ,パトラッシュ」と呟きながら机に突っ伏すよく分からない生態。システムの引継ぎでは,大量のドキュメントより本人の携帯番号と住所を押さえる行動。喫煙室で重要事項が決定される組織。本書ではこのような内容がプログラマへの愛と共に描かれています。

ちょっと疲れたときに軽く読みたいなあと思うプログラマのアナタや,プログラマの生態ってどんなものだろうと考える人にお勧めです。
プログラマに憧れる学生さんは,本書を一読して進路を考え直したほうがよいかもしれません。

posted by まる at 07:43| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2005年12月13日

質問のしかた

SEの仕事というのは,顧客の曖昧な要求を,言われたとおりにしか解釈できないコンピュータに,プログラムの形式で渡してやることです。
最新のハードウエアや流行のソフトウエア,プログラミング技法などIT関係のスキルも重要ですが,顧客から仕事を受けたり,曖昧な要求を外部仕様,詳細仕様,プログラムと詳細にしたり,ソフトハウスと折衝したりするには,コミュニケーションスキルが重要です。 SE向けの雑誌を見るとコミュニケーションスキルが重要というのは声高に叫ばれているのに,現場ではお粗末な質問に手を焼きます。
口頭の質問はその場で聞き返せばどうにかなりますが,メールではすぐに聞き返せないので対処に困ります。
そこで,困った質問の事例を挙げてみます。
  • 日本語として破綻している
学校の授業で作文をしないせいでしょうか。日本語として破綻している人がいます。主語と述語で対象が違う場合なんかは,頑張れば理解できますが,「てにおは」の違いで意味が異なる場合はお手上げです。
日本語になってない時点で読む気力も50%ダウン(当社比)です。
といいつつ,自分もときどき間違えます。自戒せねば。
  • 必要な前提条件,知識を省略している
ありがちです。
自分は理解できるからいいでしょうが,他人はあなたではありません。あなたの思考までは理解できません。

×「負の値を入力した場合のエラー処理が漏れてる件ですが...」
○「金額入力画面で,負の金額を入力した場合のエラー処理が漏れてる件ですが...」
  • 用語の認識が一致していない
これもありがちです。
たとえば,Aさんは単体テストをデバッガを用いたテストだと考えており,Bさんは単体テストをプログラムを実行させるテストだと考えていたとします。
この二人が単体テストの会話をしてもかみ合わないでしょう。
同じ業界でも会社が違うと用語の定義が異なるので,一般的でない用語は最初に定義を確認するべきでしょう。
posted by まる at 00:32| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2005年11月29日

Java Web Startアプリケーションのデバッグ

Java Web Start経由で起動するアプリケーションはデバッグが困難です。
javaを起動してデバッグできればよいのですが,javaws(Java Web Start)を起動しないとデバッグできない場合もあります。
javawsはjavaを起動するアプリケーションなので,javawsに設定をしてもJava Web Startを用いたアプリケーションはデバッグできません。
そこでリモートデバッグを使用します。WindowsでEclipseを用いた場合は次のようにします。
  1. 環境変数JAVAWS_VM_ARGSの設定
    環境変数JAVAWS_VM_ARGSで,javaws経由でjavaを起動する場合のオプションを指定できます。

  2. set JAVAWS_VM_ARGS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=8200,server=y,suspend=n

  3. アプリケーションを起動
    デバッグ対象のアプリケーションを起動します。

  4. javaws http://localhost/test/test.jnlp

  5. Eclipseの起動,デバッグ
    Eclipseを起動し,デバッグのダイアログを開きます。
    「リモート Java アプリケーション」を選択し,「新規」を押します。
    「プロジェクト」にプロジェクトを指定し,接続プロパティーの「ホスト」に「localhost」,「ポート」に「8200」を指定します。
    その後,[デバッグ]を押すとデバッグできるようになります。
  6. remote.JPG

    おまけ。
    環境変数JAVAWS_TRACE_NATIVEに1を設定すると,java起動時のオプションを画面に表示します。
    オプションに何が指定されてるか知りたい場合にどうぞ。

posted by まる at 07:26| Comment(1) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2005年11月22日

保守の恐怖

他社が開発した案件の保守や、前任者から保守の仕事を受け継ぐことがあります。
まず最初に、「どうやって保守しよう・・・」と胃が痛くなります。
保守案件ではいろいろ痛い目にあっています。
顧客による検収も完了してから引き継いだ某案件。
システムの勉強がてらに仕様書とソースを比較してると、仕様書にある記述がソースにでてきません。 このシステムって開発終わったんじゃなかったっけ?と思いながら前担当に確認をとってみます。

「あのー。仕様書に記載してるDBとの連携機能がないんですけど…」
「えーっと。ホントだ。作ってないや。」

青ざめる筆者。前担当はお構いなしに話を続けます。

「ま、俺も別の開発で忙しいからどうにかしといてよ。」

機能がそっくりないのに,どうしろと。
なぜ機能が作りこまれてなかった経緯を調べたところ、該当機能は半年に一回しか使わない処理なので、顧客も前担当者もすっかり忘れていた模様。
話が違うと上司にかけあっても、前担当者は火消しとして別のプロジェクトに投入されたので、自分らでどうにかしろとのお達しが。 しょうがないので、顧客にバレないうちに休日出勤を繰り返してプログラムを作成し、別のシステム改修の機会にこっそりとプログラムを追加しておきました。
顧客にバレなかったから助かりましたが、バレたらどうなってたんでしょう。

posted by まる at 00:21| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2005年10月29日

ソースとバグ管理票の紐づけ

皆さんは自分の開発したソースをちゃんと管理していますか。
筆者はソースの管理が不十分だったため,顧客に怒られたことがあります。

とある本番稼動中のシステムでプロセスが異常終了しました。
原因はメモリの初期化忘れ。メモリの初期化を忘れたため,変数に想定外の値が入っており,不正なアドレスを参照してプロセスが異常終了していました。 その場でプログラムを修正し,顧客への修正版の提供と,障害報告書の提出で,この件はクローズとなりました。

そう,問題が発生したのはこの後でした。

しばらくしてからシステム更新の提案を行い,顧客に予算を取ってもらいました。更新内容を提示し,顧客から了承をとってプログラムを修正。自社内でのテストまでは完璧でした。
本番稼動中のシステムに差し替え,実際に稼動させてからが問題でした。

以前とまったく同じ場所でプロセスが異常終了したのです。

問題が発生したと連絡を受けた時点で顧客はカンカンに怒ってました。

「あの不良は直ってたんじゃないのか。どうしてまた発生するんだ。」

急いで調査したところ,案の定,更新したシステムではメモリの初期化忘れの処理が修正されず残っていました。
よくよく考えると顧客環境でしか問題のプログラムを修正しておらず,自社に持ち帰るのを忘れていたのです。自社でバグ管理票は起票していたのに,対応するソースが入っていないという間抜けなミスをしていたのです。

気がついたときはあとの祭り。顧客からは以前のシステムで発生した障害への対策がすべて組み込まれてることを確認しろと言われ,社内では反省会でボロボロにされました。

posted by まる at 09:55| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2005年10月18日

入力値はすぐに妥当性を検証せよ

ユーザが入力した値は信用してはいけません。
ユーザというものは,プログラマの予想の斜め45°上を行くものです。油断してはいけません。
入力値の妥当性チェックは必須。それも入力が行われた直後にするべきです。
ユーザの仕込んだ恐ろしいトラップがプログラムを異常終了や不正演算に追い込むのです。

例えば身長と体重を入力すると,BMI(肥満度を示す指標)が出力される簡単なプログラムを考えます。
BMIは体重(Kg)/(身長(m)×身長(m))で求められます。
身長を0,体重を60として入力するとどうなるでしょう。

計算式に値をあてはめると次のようになります。
BMI=60/(0×0)=60/0=???
結果として,計算結果が不正となるか,例外を送出するか,異常終了するかのいずれが発生します。
身長に0を入力するほうが間違いです。しかし,入力が間違いであることを通知しなければなりません。 入力値のチェックをせず無邪気に計算するようでは,プログラマとしての腕が疑われます。

ユーザの入力値を検証するタイミングはいつがいいか。 身長として入力された値のチェックは,ユーザが入力した直後と,BMIの計算直前の二つのタイミングがあると考えられます。
どちらでチェックするのがいいか。それはユーザが値を入力した直後です。
ユーザの入力が間違っていることがすぐに分かるからです。

例えば,身長が入力されてからBMIの計算を行うまでに5分かかる処理がある場合を考えてみましょう。
身長が入力された直後に値をチェックするのであれば,ユーザはすぐに自分の入力が誤っていたことが分かります。
ところが,BMIの計算の前にチェックするのであれば,5分待ってから初めてユーザは自分の入力が誤っていたことが分かるのです。たまったものじゃありません。

今回の例では出てきませんが,処理の直前に値のチェックをしようとすると,他の処理により値が書き換えられる場合があります。ユーザの入力値が原因で不正な処理となるのか,プログラムのバグで不正な処理となるのかが判断できなくなり,障害なのか,ユーザの入力が間違えていたかの判断が難しくなります。

入力値の妥当性チェックは必須。それも入力が行われた直後にすべきことを肝に銘じてください。

posted by まる at 01:14| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2005年09月19日

Red Hat Linux(Fedora Core)でのシングルユーザーモード起動方法

Red Hat Linuxでのシングルユーザーモードでの起動方法です。
画面はRed Hat Linuxですが,Fedora Coreでも同じ手順で大丈夫でしょう。
  1. 電源を投入すると次の画面になります。
    OSを起動される前に'e'を押して編集モードに切り替えます。
  2. 起動画面


  3. 起動方法を選択する画面となるので"kernel /vmlinuz..."という項目を選択し,'e'を押します。
  4. 選択画面


  5. 起動コマンドを編集できるようになります。末尾に single と入力します。



  6. 起動方法を選択する画面に戻ります。先ほどの"kernel /vmlinuz..."の末尾に single が追加されていることを確認します。
    問題がなければ'b'を押して起動します。
  7. 編集後の選択画面


  8. OSがシングルユーザーモードで起動されます。
    コマンドプロンプトが表示されればシングルユーザーモードでの起動は完了です。
  9. シングルユーザーモードでの起動画面


posted by まる at 23:00| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

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