あるプロジェクトのヘルプに入った。リリースはまだ先ではあるが、工程的に遅れているからだ。現在は結合テストに入ろうとする段階である。

ヘルプで入ってテストをたんとしたのだが、その中でいくらか「あらあら」と思うネタがあるので少しアップしていこうと思う。

 

担当はバッチ処理。まず、テスト仕様書がまともにできていなかったので(応援に来た新人に作らせて、レビューなし状態だった・・)設計書を見てテストケースを起こしなおしていた。

その時に、「ん?これは何をしたいのかな?」と疑問を感じる仕様があった。実装はどうなっているのだろう?とどういう実装をしたかを確認させていただいた。

40才も過ぎているだろうエンジニアに確認したところ「仕様にある通りに実装した」とのこと。え?私が時代遅れなのかな?と思ってへこみつつ、設計書から読み取れる「このケースのときはどういう結果が期待値か」を丁寧に聞いていった。すると、結局設計者に尋ねるのが面倒でとりあえず書いてあるらしきことをそのまま実装した、ということだった。

 

設計者に確認したら非を認めてもう少しわかりやすく設計書を書き換えてくれた。

 

しかし、そういう確認は実装者が確認することではなかったのか?上流工程の担当によって差異はあるものの、仕様書がものすごくわかりやすくて設計ミスがない、なんてことは通常ない。

仕様ってそういうものなのだ。間違いもあれば不十分なこともある。あいまいな部分が実装時に明らかになることも結構ある。

 

その仕様をそのまま実装する、という感覚が、日本のソフトウェアの品質を下げているのではないか、という気がしてならない。

 

 

 

AD

併せてご利用

テーマ:

とある始発駅でのこと。

「次の電車も続いております。併せてご利用ください。」

というアナウンスがあった。

 

おかしくない?

 

併せて、というのは「一緒に」とかいうニュアンスのはず。

今の電車と、次の電車、一緒にご利用・・・・・・

 

無理やがな。

 

 

今の仕事先で主にBtoCのwebシステム構築/運用を行うのと、内部のドキュメントがgoogle docs を利用しているため、基本ブラウザベースでの作業が多い。

 

お客さん先へ行って話をする場合でもブラウザを開いて見て頂きながら、というのはよくある。そのとき、ブラウザのブックマークやスピードダイヤル、履歴などに他社の情報が出ているのは心証的な問題のみならず、場合によっては「あそこの会社はあそこの仕事をしているんだ」とバレることになる。中には対外的には秘密裏に行う必要のあるものもあるので、これはよろしくない。

 

やりたかったことは「案件別に独立したブラウジング環境を作る」ことだ。

具体的には、案件A、案件Bがあったとして

・案件A、案件Bはそれぞれ別のショートカット等があり、それぞれブックマークやスピードダイヤル、履歴、前回開いていたタブも含め、独立していること。

・案件A、案件Bが干渉せず利用できること。片方の更新がもう片方の更新に影響を与えないこと。

・案件Aのブラウザのみ起動中のとき、案件Aのブラウザを起動しようとしても多重起動しないが、案件Bのブラウザを起動しようとすると通常起動すること。

・googleアカウント等、案件が違えば同一サイトでも別のIDが利用できること。

 

一番の候補はChromeだった。以下のサイトに起動オプションがある。

http://chrome.half-moon.org/43.html

この中の --user-data-dir="<ユーザーデータフォルダの場所>" という起動オプションで設定すればかなり近いことができた。多重起動がダメだったように思う。が、Operaに慣れていた私にはどうしてもスタート画面がなじめない。

Operaで同様のことができないものか?と調べたが、シェアの小さいブラウザの宿命だろう、情報は皆無と言って良かったが、Operaにも起動オプションがあることだけは分かった。どのオプションかは忘れたが、そのオプションがChromeと同じだったのだ。

そういえばOperaのエンジンはChromeと同じであったよな、を思いだし、Chromeのオプションが使えるのでは?と上記の --user-data-dir="<ユーザーデータフォルダの場所>" を試してみたところ、すんなりと認識した。

それも、上記に挙げた条件をすべて満たしていた。

 

あと、実現したいところとしては「ブラウザの左上のアイコンをカスタマイズできれば」見間違いがなくなるので有り難いかな、というところだろう。

 

注意点としては、同期オプションは極力OFFにする、ということくらいか。そうでないと同期され独立性が保たれなくなるからだ。

 

なお、OperaではChromeの拡張機能を実行できる拡張機能があり、移行する障壁はかなり低いのではないかと思う。

クラウドとVBA

テーマ:
数年前のVBAといえば、クラウドではありえなかった。
数年前からOfficeがクラウドされたりしてても、あくまでもExcelの共有であったり。もっと言うとExcelVBAもxlsxではなくxlsmでないと保存できない、とかになり、かつ、ダウンロードしたら許可しないと実行できないとか、いろいろある。
 
確かに色んなことができるがゆえに守らないといけないと思う。しかし、どこまで何をするか、を決めてさえいれば、そこまで大変ではないのではないかなとも思う。
そのあたりをやり始めているのがGoogleなのかな、とも思う。
 
VBAはとても強力な言語ではあるが、敢えて強力ではない(私の偏見)のgoogle docsで今後はもしかすると強いのかな?とも思う。
強力すぎるとセキュリティホールになりかねないからだ。
 
このあたりは追いかけていきたいと思う。
 

少子化が言われて久しい。大家族に優しい税制ではないこともあり、仕方ないと思う。

ということは、必然的に労働人口は減る運命にある。

これから10年後、20年後は、確実に労働人口は減る。その際の労働人口不足にどう対応すればいいだろうか?

 

策はいくつかあるあろう。

・就業できる年齢を引き上げる

・海外から労働者を受け入れる

・女性が結婚/出産しても働きやすくする

 

こういう策はよくある。しかしこれらは「就業人口を減らさない」策だ。これも一手だろう。

しかし「就業人口が減ったとしても大丈夫」な策も必要ではないか。

 

今の段階で派手ではなくとも、社内の事務効率が5%でも10%でもよくなるなら、それはそれでよく、将来的により効率的にしていくようにすれば10年で半分とかの事務量になることも十分考えられる。

 

それを可能にするのがVBAではないか?と思っている。プログラム言語というよりはツールとして使える上、習得するための間口は広いからだ。

今年から来年からは、そのあたりに力を入れられればと考えている。

 

 

今の契約先ではチャットツールを使っている。

傾向として

 チャットで饒舌なエンジニアほど仕事しない

と思う。

 

チャットツールではいろんなチャンネルがある。息抜き的なものがあっても全然かまわないのだが、いろんなところで饒舌な人ほど「忙しい」と言う。

 

なら、チャットを減らせばいいのではないかと指摘すると、「チャットはそれほどしていない」と主張する。

 

チャットを否定はしない。むしろ便利なシチュエーションも多々ある。しかし、ほぼ個人同士のチャットなのに、すぐ横に居るのに、チャットの必要があるのか?等々、使い方を間違っている人ほど「チャットはそれほどしていない」という傾向にあるようだ。

 

ここまでくれば病的なのかもしれない。

一緒に仕事をしている人に、プログラミングは物凄く優秀な人がいる。簡単なものなら話しているそばからコーディングし、仕上げてしまう。それも、かなり早い。

 

しかし、設計経験がない。どう教えようか。

 

悩んでいるところ、とりあえず設計書を作ってもらった。

あー!なるほど。

 

どういうことかというと、バッチ設計書、DB設計書、画面仕様書、を作ってもらったのだが、「整合性がきちんととれていない」のだ。

これは、各論には強いが、総論とか全体の整合性という点が弱い、ということだ。

 

そこで、全体でデータがどう流れるのか、まず確認して、ならそれぞれが何をすればいいのか、を学んでもらうことにした。

そのあとに書いたものを見ると、これまでとは比べ物にならないくらいの状態であった。

 

全体が見えて、それぞれバランスよく理解ができていて、初めてまっとうな設計ができるのだなと、改めて感じた。

 

 

子供は4月2日に産め

テーマ:

子供は4月2日に産むのがよいと思う。運勢が、星座が、とかではない。単純にお得だから。

 

お酒は二十歳になってから。選挙権は18歳から。というのが法律である。これは満年齢よるもので、同じ学年の人より先取りができる。

が、これは小さな理由。ただ、学年ではなく満年齢を採用しているものがある、というのはひとつ重要。

 

さて、大きい方の理由。地域によっては乳幼児や小中学生の医療費が無料である。これは満年齢ではなく学年を採用している。

例えば小学六年生まで、とすれば 4/2生まれだと12歳と364~365日(うるう年の場合)の間適用されるが、4/1生まれだと12歳の誕生日の前日までの適用となる。実にほぼ1年、差が出る。

 

 

自治体等の助成関係は学年を採用していることが多いので、今の制度なら4月2日に子供を産むと、親としては一番お得なのではないか。

 

 

 

先日の問題 の問1の回答

 

------------------------------------

問2 印刷のタイミング

1. 印刷対象のブックを選択したらシート毎に順次印刷を行う。印刷処理が終わったらすぐに、次のブックを選択する。

2. 印刷対象のブックを選択したらそのブックのシートをすべて選択し一度に印刷を行う。印刷処理が終わったらすぐに、次のブックを選択する。

3. 印刷対象のブックを選択したらシート毎に順次印刷を行う。印刷後に待ち時間を設ける。待ち時間は15秒程度とする。

------------------------------------

 

これも過去の失敗談に基づく。

2001年とか2002年くらいだったろう。データベースの定義書をDBMSから情報を取得して作成する、というもの。

DBMSは大型汎用機上にあるDB2で、定義情報をODBC経由でExcelで取得してローカルのDB(他にインストールできるものがなかったのでAccessを使用)へとため込む処理と、取得したデータをExcelの定義書として作成し管理する処理と、特定のテーブル定義だけを出力しても、全体で通し番号として付与しているページ番号を正しく印刷する処理を作成した。

 

最後のものには当然、一気に印刷する機能も付けていた。

一通りテストを終え、一気に印刷するテストを実施した際、すぐにスプールがパンクした。これ、スプールせず印刷データをプリンタに直接送ったとしても、プリンタ側のバッファを食いつぶすことになる。

 

つまり、大量の印刷をする場合には、一気にデータを送り込むのではなく、中断させながら送る必要があり、正解は 3.となる。

1.も2.も、スプールを食いつぶすことには変わりない。

 

 

先日の問題 の問1の回答

------------------------------------

問1 ブックの開き方/閉じ方

1. 印刷対象のブックを印刷前にすべて開く。印刷がすべて終了したときにすべて閉じる。

2. 印刷対象のブックを印刷直前に開き、印刷後に閉じる。これをブック数回繰り返す。

3. 印刷対象のブックを印刷直前に開き、印刷後は開いたままにする。印刷がすべて終了したときにすべて閉じる。

------------------------------------

 

考慮すべきことは何だろう?

一般ユーザーであれば、「確実に印刷されること」が重要だろう。その次に「速いこと」かと。

 

1997年か1998年のことだ。COBOLのプログラムのコンパイルリストを印刷するのではなくデータとして大型汎用機からダウンロードし、2000年問題で影響しそうなところをピックアップするための処理をVBAで作成した。

定義とその利用箇所をVBAで関連付けし、年月日に関するところを抜き出し、その中でも桁数の足りないところを色付けして影響調査をプリントアウトする処理だった。本数は800本くらいだったか。

 

その時、最初に行ったやり方が 上記の3. であった。しかし、夜10時ごろ、実行してすぐ帰ったのだが、翌朝10時で終わっていなかったのだ。

検証したところ、10ブック目を開いたあたりから急激に速度が落ちていたのだ。

そこで、上記2.の措置を取ったところ、問題は解消された。

 

つまり、正解は 2.となる。

1.はおそらく、全部OPENするまでに相当な時間を要するか、途中でエラーになるだろう。

 

PCのリソースは有限であること。不必要なメモリは解放してやること、が大量の処理が行われる場合には必要である。