RSS FEED
今行ってる現場の勤務時間が変更になったらしい。
前にも言ったかもしれないが、ここで今までの勤務時間をおさらいしておこう(笑)。
まず、朝10時に出勤して昼12時までが午前。
午後は12:45?17:45,18:15?19:15という変則な勤務時間で計8時間。
問題なのは17:45?18:15の休憩時間。こんなのいらないっつ?の。
せめて、8時間働いた後で入れるのが普通じゃない？
「7時間労働(途中に昼飯タイム)＋30分休憩＋1時間労働」っていうこの方式は絶対におかしい。
というか、どう見ても「残業する人のためのスケジュール」だよね、これ。
残業しない人間にとって、この休憩時間は明らかに必要nothing（ルー大柴風）。
それが！なんと4月から休憩時間が「17:45?18:30」に延びるっていうからたまったもんじゃない。
これで定時は19:30になってしまった・・・
ほとんどの人がカップラーメンで夕食を済ましてるようなこの現場において、
45分もの休憩時間が求められてるとは考えにくい。
完全に会社の策略だぞ、これは。
こんなせこい会社、すぐにでも辞めたい??????
それにしても、ここの現場は作業ペースが遅い。
今の作業も始めてからかれこれ2週間近く経ってるのに
「来週末までには何とか出来るかな？」とか上の人に言われるし。
こんなの、ちゃんとやってればもうとっくに終わってるよ。
それとも、そんなに頼りにされてないのかな？俺は。
今週は月火と休んでいながらこれだもんね。
ホント、今週もう行かなくていいじゃんとかよく思うよ。
前に「暇でしょうがないんで（もう少し仕事増やして）」って言ったのに
何にも変わらないもんな?。
でも無駄だね。周りが遅いんだからそのペースに合わせないとどうしようもない。
というわけで、次の契約は5月末らしいので
今度こそはこれで終わりにしてもらうように営業の人にも強く言っといた。
あ?あ、それにしても前途多難だなぁ。
まさか技術職就いてこんな悩み抱えるとは思って無かったよ。
ではでは?。
・・・と終わらせ(以下略)。
帰りの電車の中で面白い事が起きた。
とりあえず赤羽まで行き、「後は高崎線乗って帰るだけだ?」と思ってたらアナウンスが。
「ただいま、人身事故により電車が遅れております」
まかこれかよ。ほんと高崎線はよく止まるor遅れる。
最近は運良くそういった事は無かったのに?、とか思ったけど
意外に早く電車が来たので助かった。そして無事出発。
大宮に着いたところで事件は起こった。今度は車内アナウンス。
「ただいま、急病人が出ましたのでしばらく止まります」
はぁ?(うんざり)。今日はなんてツイてないんだ。
１０分ほどしてからようやく発車。
やれやれ、と思ってたらまた車内アナウンス。
「先ほど急病人が出たとのことで探しましたが、見つからなかったので発車しました」
一体何があったのか？謎だ・・・
さぁ、３度目の正直で今度こそ本当に終わりです。
じゃ！
唐突にグチで始まって失礼（笑）。
昼の進捗での話。
今月からここ（＝僕等が今開発してる）のソフトを導入したらしい某会社(割と大手)が
余りの不具合の多さ＆スピードの遅さに導入の先送りを申し立てたらしい。
先送りの期限は1ヶ月。要するに「1ヶ月以内にまともなモン作れよコノヤロー」って事だ。
そんなこと現場の人間は前々から解ってたはず。
大体、その導入作業自体すら先週の土日に徹夜の大仕事だったらしいから。
そんなんで実際の運用がうまくいくはずも無い。
まっ、その対応をするのは僕じゃないから気にしないけどね。
な?んでこんな事が起こるのか。その原因を少し探ってみよう（←誰だお前は..）
こういう場合、大抵原因は一つに決まっている。
設計者（いわゆるSEと呼ばれる人達）と開発者（僕等みたいなプログラマ）の間で
意思の疎通が取れてないのだ。
設計がいくらしっかりしていても、それを形に出来るプログラマがいなければ意味が無い。
そして、プログラムの出来ない設計者が書いた設計というのは
大抵「ボロ」がどこかにある。
プログラムはそんなに万能ではないので
大きな事をしようと思ったらそれなりに細かい設計が必要になるというわけ。
本来ならその穴を埋めていくのも設計者の仕事なんだけど、
プログラムの難しい話をしても奴ら(SE)には通じないから
結局はプログラマが自分で（適当に）設計を考えて作っていくことになる。
というわけで、最終的に完成する物は「中途半端な」設計をされたプログラムになってしまうのだ。
そう、設計には段階が２つある。
まずは「基本設計」。これは作りたいものを簡単な文章にしたもの。
そして重要なのが「詳細設計」。これがプログラムレベルでの設計という位置付けになる。
詳細設計がちゃんとしてないから、ロクなものが出来上がらない。
設計をする人間がある程度プログラムのことを知ってればこんな事態は起きないと思うんだけどな?。
設計者は設計をしてハイお終い、プログラマはプログラムを作ってハイお終い、という環境じゃ先は見えてる。
今日の格言！（いきなり...）
「プログラムがうまく行かずにいらついてる奴は音を聞けば判断できる」
溜め息増えたりキーボードがんがん叩いたり。
迷惑極まりないぜ、まったく。子供じゃないんだから。
「僕は能力ありませ?ん」って公言してるようなもんだしね。
おっと、こんなこと書いてるうちにまた一人増えやがったぜ。困ったもんだ・・・
さて、今週もあと１日だ・・・って、いっつも週末にはこんなこと言ってる気がするぞ(笑)。
それはさておき、やっぱ就業時間延びたのは痛いよぉ。
今までより少し遅いだけなのに、今日の帰りの電車内はなぜか猛烈に酒臭くて参った。
金曜の夜遅いといつもあんな感じなんだけどね。今日はなんかあったんだろうか？
明日も張り切って会社行くぜっ！・・・ふぅ(笑)
この業界でよく使われる言葉があります。
「仕様です」
例をあげてみます。
ある会社が、シューティングゲームを作りました。
で、発売。そのゲームを遊んだAさんがゲームをしてるうちに、あることに気が付きました。
「この敵、倒せないじゃん！」
そう、ゲーム中に出てくる敵（仮にEとします）に弾が当たらないのです。
幸い、Eは放っておけば画面からいなくなるタイプなので
別に倒せなくてもそれほど困りません。
ここで、Aさんがゲーム会社に電話をしました。
「あのぉ、Eに弾が当たらないんですけど・・・」
電話に出た人はそれが正しい処理なのかどうかわからないので担当の人を呼ぶことにしました。
その後、担当者が代わって電話に出ました。そして一言。
「あぁ、そういう仕様なんです」
こんな風に使われます（笑）。
実は、本来その動作はバグ（誤動作）なのです。しかし、
開発者が「仕様です」と言っている以上、それが正しい動作とみなされてしまいました。
Aさんは納得のいかない様子で電話を切りました。
この前やった「100の質問」でも同じこと言ってる人がいました。
「バグの代わりに使っている言葉は？」の問いに「仕様です」の答え。
プログラマが見たら「なるほど」と思ってしまうかもしれません。
そうです。バグの定義を「本来と違う動きをすること」とするならば
その「本来の動き」を決めたのも紛れもなく開発者です。
明らかにおかしい（処理が止まってしまう等）ことが起きたのならば別ですが、
この程度のバグはバグと見なされない可能性があるのです。
では、なぜこのようなことが（しかも頻繁に）起きるのでしょうか？
答えは簡単、「直すのが面倒」だからです。
開発者は普通（それを仕事にしているのならば）、一つの商品を作っても
次に新しいものを作らないといけません。
そんなときに、以前作った（当人にとっては過去の産物でしかない）プログラムを
修正するような暇は無いのです。
もし幸いにして、今作っているものが以前作っていた商品のバージョンアップ版であった場合
そのバグは次の（＝現在作っている）バージョンで修正される可能性があります。
しかし、仮にそういう状況であっても「そのバグ修正に多大な労力が必要」な場合、
それは依然として「仕様です」の一言によって突っぱねられてしまうかもしれないのです。
さっ、長?い前置きは終わり（笑）。←長すぎるよ！
前置きということで、ちょっと口調を変えてみました。気づいた？
で、本題。
「そんなことじゃいつまで経っても良い商品は作れない」
ってこと。
「仕様です」と逃げることは、
「私達の能力ではそのような複雑な機能追加をすることは不可能です」って相手に公言してるようなもの。
その商品を使ってみて「こうだったらいいのになぁ」という
相手（顧客や消費者）の意見っていうのは、大抵が開発者サイドも同意できる要望のはず。
それすら直せないのは開発者の技術不足であり、怠慢に他ならない。
もちろん相手によってはとんでもない要求をする奴もいると思うけどね。
そういうのにこそ「仕様です」の一言で追い返してやればいい。
今の現場でも、そういう状況が少なからずある。
でも、中には「それやるにはプログラムを１から作り直さないと」ってやつもある。
それは向こうの要望がムチャだっていう説もあるけど
大半はその商品の「仕様」が悪いから起きる事なんだよね。
ロクな仕様も考えていないくせに
相手からの要望は「仕様です」と逃げる。
悲しいけどこれが現実だ・・・
さぁ、こんだけ長々と書いたのにまだ就業時間は終わらないぞ（笑）。
もうさすがに書くこともないので、今日はこれにて。
・・・と思ったが、もうちょっと書かせてくれ。
今日のサッカー、日本vsコスタリカ。
あれは酷かったね。
海外組がいないだけでこうも変わるもんかと思い知らされた。
ホームで1-1のドロー。
しかも、日本が取った１点はセンタリングの上げ損ないがそのままゴールに入っちゃったというやつ。
敵にはきっちり１点取られたし、PKのチャンスも１度与えている(外したけど)。
内容からすれば0-2と考えた方がいいね、これは。
やっぱり、中田と小野の中盤は日本にとって絶対必要だ。
今日スタメンのサントスはボールさばきも悪かったしクロスボールの精度も低かった。
あれじゃ厳しいね。
そんなわけで。今度こそ終わりです。では。
さ?て、今日は打ち合わせも終わったし後は適当に過ごすかぁ！・・・あ、違う？
結局完成は来週末でいいらしいのでのんびりやることにする。
こんな風に製作期間長いからまた週初めに行かなくなるんだよなぁ、きっと。
とりあえず、今の仕事が５月末で終わりってことが正式決定したらしいので一安心かな。
あいにく今日は雨だ。傘持ってっといて助かった・・・
遅い遅い遅いぃぃ???っ！！・・・っと、気にせずに。いつもの発作症状です（笑）。
ふぅ・・・もう、Accessなんか大嫌いだ??っ。
もしかしたら、遅い原因はAccessではなくアプリケーションの作り方かもしれないけどね。
とにかく、遅い原因すら特定できないような作りは勘弁だ。
よくこんなんで皆我慢して使ってるよなぁ。
まぁ、自分では作れないんだろうからしょうがないけど。
なぜこのアプリケーションがこんなに遅いか？
それは誰もがわかってる。「データベースにTCP/IP接続で頻繁にアクセスしてるから」だ。
データベースへのアクセスっていうのは通常のファイルと比べて
オーバーヘッドが大きい（＝遅い）のは周知の事実。
その代わりに「簡単」「高機能」という「使いやすさ」を追求したのがデータベースだからね。
それが、TCP/IP接続（つまり回線を通した接続）にするとさらに遅くなる。
もともと、TCP/IPというのはスピードを重視したプロトコル（説明略）ではない。
インターネットアクセスに代表されるように
「つながる事こそが全て」なのだ。速さなんかは二の次、というわけ。
アクセスの少ないアプリケーションならともかく、
頻繁にDB（データベース）アクセスが必要なこのアプリには高速化のロジックが必要だ。
そのためにあるのが「手続き型言語」、PL/SQLなんかが有名だね。
速くするにはどうすればいいか？
答えは意外にも簡単。ネットワークとのアクセス数を減らせば良いのだ。
例えばある処理をやるために、今まで100回のDBアクセスをしてたところをたった1回に減らせれば
明らかにそのアプリケーションは速くなる。
通常のDBアクセス（いわゆるSQL文）では、プログラムはデータベースに対して
「この値を取ってきて下さい」くらいの要求しかできない。
それがPL/SQLを使えば、
「これとこれの値を比較して、一番大きなものを取ってきて下さい。
あ、取ってきた値はもう必要ないのでデータベースから削除しちゃって下さい」
とかいった複雑な要求が１回で出来る。
つまり、今までプログラム中でやっていた処理をデータベース（厳密に言えばこれもプログラムなのだが）
にやらせちゃおう、というわけだ。
DBの中でプログラムを実行する仕組みが「手続き型言語」。
発想は誰もが思いつくほどシンプルだけど、これが相当役に立つのだ。
いいことづくめの手続き型言語だけど、一つだけ欠点がある。
それは「言語がしょぼい」ということ。
C++やJavaといった高級言語に比べて、手続き型言語の構文はあまりにも貧弱だ。
それはすなわち、「プログラムの見難さ」「デバッグのし難さ」という
最大とも言える弱点を持っている。
高速化のためには、ある程度の犠牲が必要になってくる。
ただし、それをしっかりと踏まえていればそれほどの障害でもない。
それ以上に、手続き型言語が与える利点というのは大きいのだ。
さぁ、長々と続いた話もこれくらいにして。
その手続き型言語、実は使うデータベースによってかなり違う。
僕が色々見た中で一番優れているのは、言わずと知れたOracleのPL/SQLだね。
これと比較すると、PostgreSQLのPL/pgSQLはかなり見劣りする。
ただ、PostgreSQLには新たな手続き型言語を追加する機能が付いている。
今後、同士達によってもっと優れたPL/pgSQLが誕生する可能性は大きい。
MySQLは・・・無いのかな？ドキュメントを見てもそれらしき記述が見当たらない。
この超遅いアプリケーションに手続き型言語が使われているのかどうかは知らないが
おそらく使ってないだろうね。
使ってたらもう少しマシな速度になってるはずだから。
あ、もともとAccessには手続き型言語が無いって可能性もあるか。
そういえばさぁ、ここの日記コーナー（2002/04/26現在）
上のカレンダーの月表示部分をクリックすると「月間日記一覧表示」になるの知ってた？
まとめ読みしたいときに使ってね。
もう１回クリックすれば一日ずつの表示に戻るよ。
にしても、Windowsマシン狙ったウイルスっていうのは頻繁に出るね。
そろそろ、企業もこんな穴だらけのOS諦めたらいいのに。
それか、社員にウイルス対策を徹底させるか、どっちかだね。
ウイルスバスター入れてるなんていうのはもはや当たり前。
もちろん、これ入れとけば安心だし、それはそれで間違いじゃない。
でも、もっと根本から「なぜウイルスに感染するのか？」っていうところが大切だよね。
おそらく大半の一般企業社員は、「とりあえず何か危険なもの」くらいの認知しかないはず。
現状だと「InternetExplorerとOutlook使ってなければ99%安全」なことくらいは知ってて欲しい。
が、だからってIE使わないわけにもいかないからねぇ。
PC知らない奴にPC使わせるからこういう被害が続出する。
企業として、社員に最低限の知識は身につけさせないとね。
もっとも、今の子供達は学校側である程度教え込まれるんだろうけど。
お?っと、気づいたら相当な量書いてるな、今日。
というわけで、このへんで終了。それじゃ?
なぜか今日は書くことがある。というわけで本日第２弾だ。
あんまり１日に何度もアップするのは好きじゃないんだけど
とりあえず書きたいときに書くのがモットーだからね。
珍しく仕事関係の本を買ってみる。
「Java言語で学ぶデザインパターン入門」by結城浩
いや、別に僕は回し者なんかではなく(笑)。
この人の書く本は本当に解りやすいのだ。書籍界では有名な人だよね？
で。
デザインパターンとは何ぞや？
簡単に言えば、Java言語でコーディングする際によく使われる技術をまとめたものだ。
普通、そういうものはライブラリで用意されてるんじゃないの？と思われがちだけど
これらはあくまで「パターン」であって
その実装方法は使う場所によって色々変えるのが良いとされているので
敢えてこういう形をとっているようだ。
もっとも、中にはデザインパターンをそのまんま使う(→そして失敗する)
「自称デザインパターン使い」みたいなのも多数存在するしいけど。
まぁ、(何も知らない)雇う側からしてみれば「ほ?、彼はデザインパターンが出来るのかぁ。ぜひ雇おう」
ってな気にさせられるのも無理ないとは思うが。
なぜデザインパターンなるものが出来上がったのか。
そして、それはどういう場面で利用するのが適しているのか。
こういった事を判断するのは、やはり最終的には自分で考えて結論を出していくしかない。
そう、プログラムに「これを使えば完璧な究極の方法」なんてものは存在しないのだ。
このデザインパターンの最重要テーマともなっているのが「資源の再利用」。
なんか急にエコロジーっぽい話に聞こえるかもしれないが、
ここでいう資源とはプログラムの集まり(ライブラリ)のこと。
「一度(手間暇掛けて)作ったものは出来るだけ長く利用しよう」
というわけだ。
この考えは何も最近になって始まったわけじゃない。
C++が登場した当初から、こういった発想は存在していた。
しかし、それはあくまで「理想論」だった。現実には、新しいプログラムを組むときには
少なからず以前の資源も手直しする必要があった。
それを、実際の現場で使えるレベルまで押し上げたのがJavaの概念。
中間コードという極めて機種依存性の低いもの(classファイル)を導入するにより
例えばある会社が作った資源を別の会社が(そのソースコードを必要とすること無く)
使うことが可能になった。
しかし、世の中そんなにうまくはいかない。
手直しせずに流用できるほどの信頼性の高いコードが果してどれだけ出回っているのか、甚だ疑問だ。
実際僕も、この先どこの誰が使うかも解らないコードに
それほどの拡張性を持たせるような無駄なことはしないと思う。
再利用可能なコードというのは、それなりの時間とテストが必要なのだ。
もちろん、半永久に自社で全てを開発できるような現場に移行できれば話も別だけど。
そうなれば、自分のやったことは必ず後々自分の為になるからね。
積極的にデザインパターンなんかも取り入れる事になるだろう。
・・・てな感じで。今日はこの辺で。
1ヶ月も遅れて報告たぁいい根性してるじゃねぇか。
まっ、こっちは既に知ってたから特に支障は無いんだけど。
いっつも暇そうにマージャンゲームやってるんだからメール出す暇くらいあるだろうにね?。
眠い・・昨日はそれなりに寝たはずなのに。
うっきゃ?！なぜここのプログラマーはこんなにもグチャグチャなプログラムを書くんだ?。
それなりにプログラム書ける人は何人かいるんだけど（内半数が派遣だが）
皆プログラムを「ただ書いてる」って感じ。
思いつくままプログラムにするんじゃなくて
ある程度のプログラム設計くらいはしてからコーディング始めてほしいよね。
読みにくい一つの原因。単一メソッドに費やすステップ数が多すぎる。
どっかで見た文章では
単一メソッドでは25行（＝ステップ）までにするのが良い、とかいってたけどそれはさすがに無理。
とりあえず現実的に考えて、せめて300行くらいには収めてほしい。
ここだと500超えてるのとか平気であるもんね。
まぁ、前の現場は3000超えてるような信じられんコーディングが蔓延ってたから
それよりはマシか・・・う?ん、低レベルな争いだ。
まただ・・・今まであった機能と似たような機能を作るらしいが
それのためのコードを全部「分けて」作るらしい。
とはいっても、大半はいままであったやつのコピー。
それをちょこちょこ修正して新機能を完成させることになる。
つまり、バグや仕様変更があった場合、両方のソースを変更する羽目に・・・
う?む、奴らにデザインパターンの本でも読ませてやろうか（笑）
これほど初歩的な「タブー」を繰り返すこの現場はどうかしてるぜ。
まぁ、今回の修正をするのが俺じゃなくて良かったよ。
あんな汚いソース、とてもとてもコピーして使う気にはなれないからねぇ。
さっきとんでもないことに気が付いた。
先月の勤務表を付けてて。実際の勤務時間が100時間を切ってる（笑）。
さすがにそのまま提出するわけにもいかにので少しだけイロ付けてなんとかごまかす。
今月はせめて120くらい行っとこうか・・・う?ん、低レベルな争いだぜ（笑）。
会社来て、メールチェックして、Web巡回して、日記書いて・・・
昼の3時にしてもう暇つぶしのネタが尽きたぞ（笑）。
もう帰っていいですかぁ？・・・「いいですよぉ！」
というわけで、神のお告げが聞こえたので帰ります。
。。。うむ、一人でこんなことやってても虚しいな（笑）。
なぜ俺がこんなに暇か。
スケジュール管理する人間がダメだからだ。
何かの仕事をするときは、大抵は誰かの下について作業するんだけど
その人間が忙しかったりすると見事な「放置プレー」をくらうことになる。
今なんかもうかれこれ1ヶ月以上は放ったらかしだぞ。
ひょっとして俺の契約期限が切れるまでこのまんまなんだろうか・・・
本格的にやることがないので、今日は６時で帰ることにする。
明日も行く必要ないな、これじゃ。
一足早くGW突入だっ！