結構使えるもの。

皆さんこんにちは。

プログラマーののぶさんです。

最近気温が緩み、日中も気温がプラスになる日が増えてきました。

暖房費もそれほどかからなくなるので助かります。

プログラマーのお仕事も順調です。

昨日は、以前納品したツールで変なエラーが出て、その解消に取り組んでいました。

というのは、エラーが出たらその番号を表示してプログラムを止める処理を入れてるのですが、あるエラーは無視するようにしてあるにもかかわらず、その番号が出てくるのです。

しかも、わたしの所では正常終了するのに、テストを担当してくださっている人のところでは３回に１度くらいの頻度でエラーになる。エラー箇所もまちまち。

これは変です。

一つ思い当たることがあって、ツールで読み込むはずのファイルが既に開いていたらまずいので、チェックする処理を入れてあるのだけれど、ここでわざとエラーを発生させるようにしてありました。

ネットで調べたら、そうしたらいいとあったので組み込んだのだけれど、正直言うとあまりやりたくない処理でした。

そしたら案の定動作が不安定になり、結局別のやり方で判断することにしたところ、エラーはぱったりと止みました。

結論としては、気の進まない処理はやっぱり入れない方がいいということなのでした。

話変わって、今日は生活ミニ知識。

わたしはサイフォン式でコーヒーを入れるので、燃料用のアルコールを持っているのですが、これが結構使えるのです。

コンロ周りの油汚れとか、シールを剥がした後のベタベタとか、意外とキレイに落ちます。

布やティッシュ、キッチンペーパーなどに含ませて拭くだけ。コンロ周りの油汚れなんかは、アルコールを浸した部分を少し押しつけてやると油も溶けてきて、汚れが落ちやすくなります。酷いところはアルコールをかけて、指でこすってやると溶けてくるので、あとは拭き取るだけ。水拭きしてから拭きすれば、ピッカピカです。

「なんとかペット」みたいな洗剤だと、いろいろ入っているので汚れは落ちるけど、変な薬液もあるから後の水拭きが大変。

アルコールならそれもなくてスッキリ。

揮発しやすいから、何度もかけないといけないこともあるけど、結果的にはそんなに使わなかったです。

ホームセンターに行けば、燃料用のアルコールは500ml500円もしないで売っているので、１本買っておけば、重宝しますよ。

生活ミニ知識でした！

設計が大事

こんばんは、のぶさんです。

連日連夜、街の中を除雪車と大型ダンプが出て、道路脇の雪を片付けてくれます。
いたる所で背丈より高かった雪の山がなくなり、すっきりとした街並みになってきます。
除雪作業に従事されてる方々に感謝です。

わたしはプログラマーなわけですから、コンピュータのプログラムをします。
いろんなプログラムがあるわけですが、わたしは主にExcelなどで動くツールを作っています。
Excelというのは表計算ソフトで、表計算をしなくても、表形式のデータを扱います。
表形式のデータというのは、縦軸と横軸で特定できる法則性を持ったデータ、つまりはデータベースです。
今の世の中、システムのほとんどはデータベースを使っていて、様々なシステムが様々なデータベースを使っています。個々のシステムには、それぞれ固有の形式があり、他のシステムからのデータを流用したい場合は、そのシステムに合わせた形式に直してあげなければ、適切に利用することは出来ません。

わたしは今まさにこの変換のツールを作っているのです。

データにはだいたい法則性があり、それを見つけてうまくプログラムに組み込んでいきます。
いくらコンピュータは処理が速いと言っても、だらだらとした作業のプログラムでは、宝の持ち腐れというもの。
効率よく処理できるようプログラムするのが、プログラマーの腕の見せ所。これがいわゆる、「アルゴリズム」というもの。
加えて、どんな処理をさせているのかが理解しやすいようなプログラムを組むというのも、センスの一つです。
プログラムを作るには、先ずはここを考えます。「設計」ですね。
ここが大筋で決まれば、あとはそれぞれの処理を記述していくだけなので、命令などをひたすら打ち込んでいくのです。これを「製造」と言います。

こうやってプログラムは出来るのですが、アルゴリズムを考えている時に仕様が変更になるならまだしも、製造に入ってしまってからでは、なかなか変更も出来ません。あらかた出来てからなんてのはもってのほか。
一番いいのは、設計に入る前に、どういうことをしたいのかを、決めておくことですね。
ここがブレブレだと、設計も製造もガタガタです。

設計が大事なのは、プログラムに限りませんね。

モヤモヤな仕事 その後

こんばんは、のぶさんです。

大寒も過ぎて、少しは寒さが緩んだ感も無いではないですが、やっぱりまだ北海道は寒いです。

先日のモヤモヤな仕事ですが、実は先週、とうとう爆発してしまいました、わたしが。

わたしは請負で今のプロジェクトに参加してるわけですが、一応「ツール開発」という業務をやっています。

ツール開発は大なり小なり、いろんなのがありますが、以前もお話ししたとおり、大雑把でもいいので、仕様書もしくはそれに準ずるものがあります。

要は、こんなことをしたいからこんな風に作ってくれ、ということがわかるものですね。

で、この現場はその仕様書の書き方がとても精度が悪い。

この仕様書を書いた人はコンピュータシステムをあまり知らないのでは？と思われる節があり、イヤ、それはそれで構わないので、何をしたいかが明確であればいいのです。

で、何をしたいかがわかりにくいので、担当者に問い合わせたのですが、まともな人なら頑張って調べて、答えてくれます。それはありがたい。

でも、今回の担当者はいくつかの質問には答えず、少し経ってから仕様書を再度見てみると！答えなかった部分が変更されているではありませんか！

これは由々しきこと！

仕事を依頼した側が、依頼の内容をしれっと変更する。これは大問題です。ツールの開発に限らず！

そんなわけで、クレームを入れたわけです。仕様書を変更したなら、ちゃんと連絡してほしい、と。

それにもかかわらず、今度は別件で似たような事象が発生！それが今日発覚したのです。これは組織的な体質なのか！

いやぁ、よくないですねぇ。。困ります。。

前回は、とりあえず担当者に直接申し入れをして、その後クレーム内容を公開したのだけれど、今回はストレートに公開の場でクレームを入れました。

こんな風に無断で仕様書を変えられたのでは、安心して開発が出来ない。仕様が固まったとわかるまで、開発は再開しないと言いました。

今回は別の担当者ですが、無断で変更したことについての謝罪すらない。

きっとまだ二十代の若い人なのだろうなぁと思いますが、以前はこんなことはなかった。エンジニアとして最低限のルールというものがありました。
今はそういう事を教えられる人もいないのでしょうね。