1.にげる2.たたかう3.そのたあなたならどれをとりますか。1.の「にげる」は訴えかけるものがある選択肢です。後を考えなくてよいのなら、0コンマ1秒の迷いもなく選びます。まわりこまれてしまった」となるとシャレになりません。「つうこんのいちげき」を喰らって一発昇天かもしれません。2.の「たたかう」は、死ぬ前に勝てるかが問題です。レベル1で『りゅうおう』と戦おうとしていたら勝ち目などありません。「はげしいほのお」を吐かれて昇天です。考えると、「たたかう」は勝てる場合にのみ通用する選択肢ともいえます。そもそも勝つ見込みのない戦い(=納期に間に合う見込みのない仕事)を受ける時点で、何かおかしいという気はしますが。世の中にはオトナの事情という分かりたくもない事情があるわけで。紹介したいのは、「そのた」です。具体的には、いちぶ「たたかい」、いちぶ「にげる」戦法です。いってはなんですが、期末になってくると、できないものはできません。誠意を見せようと、徹夜しようと、休日出勤しようと、人を増やそうと、一ヶ月でWindowsをつくれと言われたってつくれやしません。そこで、できないという前提の上で、どのように進めるかを顧客と相談します。頑張れば期間内にできるのであれば、「たたかう」を選択すればよいのです。顧客と相談する際には、工数に基づいた取捨選択リストを持っていき、期末までに何を達成し、何を残すかを顧客に選ばせましょう。顧客に選ばせてしまえば、我々の責任が少しは減り、次の期に作業を持ち越せます。会社は来期にただ働きすることになってしまいますが、作業員は一息つけます。いいのは、期間内にちゃんと納品できることなんですけどね。|2006年02月28日SEに要求される力SEとして大成するには、どういう能力が必要か考えてみました。・新しいモノに興味があるか・新しい技術を使うべきところと、枯れた技術を使うべきところの見極めができるか・SE関連業務の勉強が苦にならないかほかに、こういった能力が必要というのがあれば、教えてください。最近の富豪的プログラミングに影響されてると、アルゴリズムを考えるのがおっくうになります。簡単に実装できるアルゴリズムを採用してしまいます。実装する前に少しだけ考えてください。そのアルゴリズムで本当に問題ないのか。大半の処理は性能に影響を与えません。一部の処理は確実に性能に影響を与えます。その一部の処理だけは、手を抜かずに考えましょう。実際に筆者がやらかした例を挙げてみます。メタデータを管理するクラスを作り、メタデータ自身をファイルで保管していました。データ量が膨大になるのは自明でしたので、データ自体の保存、読み込み処理は、当然、性能を意識して作成。テストは何事もなく過ぎ、リリースしてしばらくのこと。遅くて使えないと、顧客からクレームがきました。顧客環境を調査したところ、メタデータの検索で時間がかかっている模様。メタデータはたかだか100件程度だろうとタカをくくって、メタデータの探索は逐次探索としていました。実際の運用環境では10000件を超えており、一件のメタデータの探索に、平均10ミリ秒消費していました。いうことは、全件の処理は10ミリ秒×10000件=100秒となります。一回の処理に100秒かかるようでは、遅いといわれてもしょうがありません。メタデータだから、そんなに件数がないとサボった罰です。逐次探索からハッシュ探索に切り替えたところ、1秒かからずに処理が完了し、問題は解決しました。おかげで、顧客からイヤミを言われ、肩身の狭い思いをしましたとさ。気に入った方はこちらもクリック。予告どおり,障害対応の手順を説明します。第一報は,顧客か,監視ツールのエラーとしてあがってきます。そこで,何が発生しているのか,どのシステムに影響があるのか,現象を明確にし,他人に伝えれるようにまとめます。ユーザへの通知ユーザに障害の発生を通知します。障害があってもシステムには影響がなかったり,ダウン時間が短くユーザにバレないと考えたり,ユーザにバレても誤魔化せると踏んだ場合は,ユーザに通知しないこともありますが。障害情報の取得システムの挙動がおかしいときに,再起動するとそれなりの確率で直ります。勝手に再起動すると,障害が再現しないことがあり,原因不明で片付けられてしまいます。二度と発生しない障害ならいいのですが,この手の障害に限って保守部隊のいないスキを狙ったかのように発生します。そこで,保守部隊に確認して,再起動しても問題ないか,再起動する前に取得しておく情報がないか,先に確認しておきます。ま,自分のシステムのバグなら,自分で原因追求するだけなので関係ない話ですが。保守部隊に原因の調査を依頼します。自分が解析を依頼された場合は障害解析手順を参考に,どうにかしてください。原因の調査で,不具合箇所の見当はつきます。次にOSやプロセスの再起動,縮退運転,待機系への切り替えなど,障害をとりあえず回避する対策を実施します。ハードウエア障害で代替機がない場合や,システムの基本機能がバグっていた場合は,使用禁止にするしかありません。調査を依頼した結果として,暫定対策以外にモジュールや,ハードウエアの入れ替えが必要であれば,改めて実施します。障害報告書の作成ひととおり終わったら,ユーザに障害報告書を持って謝りにいきます。本体策までに時間のかかる場合は,本体策の前にいくこともあります。障害報告書には障害の概要,対応経緯,不良原因,対策などを書きます。本来は障害対応の手順を解説する予定でしたが予定を変更ます。Core3でのWikiの設定にてこずったので,備忘録として書いておきます。Wikiを使ってみようとインストールしたのですが,うまく動きません。別件で使用しているレンタルサーバには簡単にインストールできました。Wikiのインストールが下手だからというわけでもないようです。ファイルの書き込みでエラーになるようです。,/tmpへは書き込みできるのに,htmlの下には書き込めないようです。こんな現象が発生するのか。調べたところ,SELinuxが原因と判明しました。SELinuxでは,ファイルの読み書きに制限を与えます。そのため,CGIやPHPからファイルの書き込みを行うとエラーとなります。エラーにさせない方法は二つ。SELinuxを使わないSELinuxでhtmlを書き込み可能とする今回は一般公開しているサーバでもなかったし,調べるのも面倒だったので,SELinuxを使わない方法で対処しました。SELinuxを使用しているか調べます。getenforceEnforcingEnforcingと表示されたらSELinuxが有効となっています。Permissive)。setenforceコマンドではOSを起動するたびに設定する必要があります。編集し,起動時にPermissiveモードに設定してもらいます。protection.SELINUXTYPE=targetedこれで問題なくhtmlの下に書き込めるようになり,Wikiも動作するようになりました。ひとつの方法は別の機会に紹介します。プロジェクトに配属された新人と話していたら,障害が発生した場合の対処方法を知らないと言われました。このサイトを見て勉強しろ!と言おうと思い,過去の記事を調べたんですが,まだ書いてなかったんですね。とっくに書いたつもりになってました。そこで,今回は障害解析手順を説明します。顧客は「よく分からないけど、動かない」といってくるので,現象を明確にします。・「動かない」と主張しているのは、どのような状況なのか。エラーメッセージを出力しているのか,アプリケーションが無応答となっているのか,OSがフリーズしているのか・障害が発生する直前にした操作は何か。障害の発生した直前の操作に、障害解析のヒントが隠されています。どのような操作をしたかは教えてもらいましょう。この時点で既知の不具合や,仕様の場合は分かるかもしれません。資料採取OSがフリーズしていおらず,画面に何か出力されているのであれば,Alt+PrintScreenで画面のスクリーンショットを取ってもらいます。同時に使用しているOSのログ(Linuxだったら/var/log/以下のファイル,Windowsだったらイベントビューアの内容)も念のため送付してもらいます。イベントビューアは[名前を付けて保存]でファイルの種類をテキストまたはCSVにして出力してもらいます。イベントログ形式は,そのPCでしか出力されないメッセージがあるのでNGです。システムがログを出力していれば,ログを送付してもらいます。自分の作成したシステムでは,ログだけで障害が解析できるようにしておくべきです。できれば,このフェーズまでで障害原因をつきとめたいところです。いかない場合は次に進みます。顧客から聞いた情報と資料をもとに再現実験を行います。開発環境で再現するようであれば,開発環境で原因の追究を行います。障害が開発環境では再現できないけど,顧客環境で再現できるのであれば,実運用環境で再現実験をするしかありません。この場合,なるべく少ない回数で原因を追究できるようにしましょう。状況がゆるすのであれば,罠かけ用モジュールを設置するのも一つの手段です。それでも駄目なら最後の手段です。あきらめる実運用環境でも再現しないのであれば,次回の障害発生に期待するしかありません。今回の解析で原因を絞り込めなかった理由を追求し,ログの出力を追加する等の対策を行い,次の障害発生を待ちます。5はただの逃げなので,1,2ででどうにかしたいところです。マルチスレッドやメモリ破壊の問題は再現しづらく,原因も絞込みにくいので,原因不明のままになることも多いのですが...。美しいコードプログラマはコードの美しさを語りますが,プログラマ以外の人種からは何が美しいのかさっぱりです。ときどき人からも聞かれるので,コードの美しさについて分析してみましょう。読みやすいコードこれはフツーの人でも理解できます。ソースコードを見れば一目瞭然。コーディング規約に従って書いてあるようなコードです。コーディング規約ではクラス・変数の命名規則,中括弧の取り扱い,インデントの間隔(タブ/空白4文字等),コメントのつけ方,Javadoc用コメントの有無,現場によっては関数当たりのステップ数や,空行の入れ方まで規定してあるようなものもあります。コーディング規約で統一していると,プログラマごとのコードのクセがなくなり,ソース全体が読みやすくなります。自分の好きなスタイルでしか書かないプログラマがいると簡単に崩壊します。ソースコードのレビューなどで,ソースをチェックしておくべきでしょう。変更しやすいコードプログラムはしょっちゅう仕様が変わります。そこで,あらかじめ変更が見込まれる部分は,変更しやすいようにしてあるコードです。定数は変数としておき,データ間の関係を疎にし,データとアルゴリズムの間の従属性を減らします。仕様変更がかかってプログラムを修正する際に,あまりに簡単に変更ができるため,「美しい...」と言葉がでます。変更しやすいコードを書くプログラマというのは,えてして変更に弱いというのも面白いところです。論理的に簡潔なコードここまでくると,プログラマ以外には理解しづらいでしょう。プログラムではさまざまな条件分岐や繰り返しがあります。xの値が0.3と0.5の場合はAの処理をして,xの値が1.5と2.0の場合はBの処理をする処理を書く場合を考えます。提示された条件を満たすだけであれば,0.3と0.5の場合を書いて,1.5と2.0の場合を書けば問題ありません。){B();}そこを一歩ひねって抽象化します。この場合は,xが1より大きいか小さいかにより分けてみます。{B();}こんな簡単な例だと当たり前のように思えます。複雑な条件を簡潔にまとめたコードを目の当たりにすると,思わず「美しい...」という言葉が漏れてしまいます。自分が書いたコードだったら,自分をほめたい気分になります。|2005年12月27日IT業界の愉快な面々さて,IT業界にはいろいろな登場人物がいます。簡単に登場人物を眺めてみましょう。あることないこと言って顧客から仕事をもらってきます。営業の言った,妄想,ではなく青写真を実装する立場としては気が重くなります。営業から「こんなのできる?」と聞かれたら,簡単にできることでも「難しいですね」と返しておきましょう。システムのあるべき姿を示す人。机上の空論を言って現場を混乱させます。システムを理解しているだけに,営業以上の無理難題を押し付けてくる人でもあります。できるコンサルタントならいいんですけどね。できるコンサルタントなら。顧客とやりとりしながらシステムを構築する人。定義のあいまいな職種です。営業とSEしか区分がなく,システムに関する作業はすべてSEという会社もあります。基本はシステム全体の概要とサブシステムごとの入出力を定義するのが仕事です。今日も営業からは無理難題を吹っかけられ,プログラマからは反発される悲しい中間管理職です。コーダと同一視される場合もありますが,個人的にはサブシステムの仕様を検討する人と考えています。SEが提示したサブシステムの入出力からプログラムの仕様を考えるのがプログラマ。プログラマの作った仕様を実装するのがコーダ。プログラマが考えた仕様をコーディングする人。仕様書さえ完璧なら単純作業です。インドだろうと中国だろうと仕事を出せます。ま,日本で完璧な仕様書というのはそうそうお目にかかれませんが。プログラマが実装したソースをテストする人。プログラマがよく兼務しています。品質保証がしっかりしている会社では,専門のテスタを雇っていたりします。そのような会社では,今日もプログラマとテスタの仁義なき戦いが見られます。システムを運用する人。手順書どおりに作業すればよい場合が多いので,単価の安い仕事でもあります。問題が発生すると真っ先に影響を受ける人でもあり,IT業界のカースト制度が垣間見れます。プロジェクトの責任を取る人。年長のSEが兼務しています。進まない進捗を管理し,問題点を上位の管理職に報告します。責任の割には給料が安い場合が多く,SE以上に中間管理職の悲哀を感じます。技術が好きなSEに管理職をやれというのが無理な話。必要性の割にSEから敬遠される職種です。プロジェクトマネージャに代わるキャリアパスとして人気なのがコレ。技術面でのエキスパート。システム全体の設計を行ったり,DB・ネットワークのスペシャリストとして活躍します。技術が好きなSEが目指しますが,少数しかいらないので狭き門です。ホントはSEだけど,単価を上げるためにアーキテクトを名乗ってる人はたくさんいますけどね。価格:¥1680プログラマの現場で耳にする単語や,誰かがやっている行動をまとめた本。読みながら「あるある」と頷いたり,ニヤリとさせてくれます。20時から会議をするのを不思議に思わない心理。「疲れたよ,パトラッシュ」と呟きながら机に突っ伏すよく分からない生態。システムの引継ぎでは,大量のドキュメントより本人の携帯番号と住所を押さえる行動。喫煙室で重要事項が決定される組織。本書ではこのような内容がプログラマへの愛と共に描かれています。疲れたときに軽く読みたいなあと思うプログラマのアナタや,プログラマの生態ってどんなものだろうと考える人にお勧めです。プログラマに憧れる学生さんは,本書を一読して進路を考え直したほうがよいかもしれません。質問のしかたSEの仕事というのは,顧客の曖昧な要求を,言われたとおりにしか解釈できないコンピュータに,プログラムの形式で渡してやることです。最新のハードウエアや流行のソフトウエア,プログラミング技法などIT関係のスキルも重要ですが,顧客から仕事を受けたり,曖昧な要求を外部仕様,詳細仕様,プログラムと詳細にしたり,ソフトハウスと折衝したりするには,コミュニケーションスキルが重要です。SE向けの雑誌を見るとコミュニケーションスキルが重要というのは声高に叫ばれているのに,現場ではお粗末な質問に手を焼きます。口頭の質問はその場で聞き返せばどうにかなりますが,メールではすぐに聞き返せないので対処に困ります。そこで,困った質問の事例を挙げてみます。日本語として破綻している学校の授業で作文をしないせいでしょうか。日本語として破綻している人がいます。主語と述語で対象が違う場合なんかは,頑張れば理解できますが,「てにおは」の違いで意味が異なる場合はお手上げです。日本語になってない時点で読む気力も50%ダウン(当社比)です。いいつつ,自分もときどき間違えます。必要な前提条件,知識を省略しているありがちです。自分は理解できるからいいでしょうが,他人はあなたではありません。あなたの思考までは理解できません。用語の認識が一致していないこれもありがちです。Aさんは単体テストをデバッガを用いたテストだと考えており,Bさんは単体テストをプログラムを実行させるテストだと考えていたとします。この二人が単体テストの会話をしてもかみ合わないでしょう。同じ業界でも会社が違うと用語の定義が異なるので,一般的でない用語は最初に定義を確認するべきでしょう。Start経由で起動するアプリケーションはデバッグが困難です。Start)を起動しないとデバッグできない場合もあります。Startを用いたアプリケーションはデバッグできません。そこでリモートデバッグを使用します。WindowsでEclipseを用いた場合は次のようにします。環境変数JAVAWS_VM_ARGSで,javaws経由でjavaを起動する場合のオプションを指定できます。-Xrunjdwp:transport=dt_socket,address=8200,server=y,suspend=nアプリケーションを起動デバッグ対象のアプリケーションを起動します。http://localhost/test/test.jnlpEclipseの起動,デバッグEclipseを起動し,デバッグのダイアログを開きます。アプリケーション」を選択し,「新規」を押します。「プロジェクト」にプロジェクトを指定し,接続プロパティーの「ホスト」に「localhost」,「ポート」に「8200」を指定します。その後,[デバッグ]を押すとデバッグできるようになります。環境変数JAVAWS_TRACE_NATIVEに1を設定すると,java起動時のオプションを画面に表示します。オプションに何が指定されてるか知りたい場合にどうぞ。他社が開発した案件の保守や、前任者から保守の仕事を受け継ぐことがあります。最初に、「どうやって保守しよう・・・」と胃が痛くなります。保守案件ではいろいろ痛い目にあっています。顧客による検収も完了してから引き継いだ某案件。システムの勉強がてらに仕様書とソースを比較してると、仕様書にある記述がソースにでてきません。このシステムって開発終わったんじゃなかったっけ?と思いながら前担当に確認をとってみます。