「電子申請サポートシステム for Wordアドイン」って結構ずさん？

　陸上無選協会は、無線機の免許の為の申請書を「電子申請サポートシステム for Wordアドイン」というのを使ってシステム化しやすいようにしてくれています。
利用者としてはとてもありがたいと思っています。

ページと項目毎のフィールドに名前を付けてあるのでシステムで管理しているデータをテキストファイルに出力することで簡単に連携できます。
システムで出力したテキストファイルを提供されているテンプレートのWord文書に読み込ませるとそのフィールドに値を設定してくれます。

ですが、ですがですよ。
フォーマットによっては恐らく作りが良くないんでしょうけど、テキストファイルに項目名が存在しないと全然関係の内フィールドの値を設定してくれます。

例えば、「無線設備の設置場所4」というキー項目がないと勝手に「かがみ申請者名前フリガナ」という違う項目の値を設定してくれます。

「無線設備の設置場所4」というキー項目を準備すれば問題無いんですけどね。

でも作る側としては出力するテキストデータを共通化して楽チンしようしているので項目は無視してほしいわけですよ。

もうちょっと使い勝手よくに作って欲しいです。

または、フォーマットのメンテナンスの仕事受けますけどね。

「取り急ぎ」ということば禁止令

メールの「取り急ぎ」という言葉を廃止してほしい。

その「取り急ぎ」の後のフォローとかいつ正式にとかのことが書いてあればまだいいんだけど大抵は書いてない。

何かの作業をお願いした時に目についたとこだけ作業して「とりあえず返しておけ」程度。
全部やってから返してほしいのよ。か、いつ正式なのを出すかの明記を。

この言葉を書いて終わるのは大抵「ちょっとめんどくさいから後回しにします。でも、言われなかったらやらないけどね。ははっ。」という言葉が見え隠れしてるんですよ。

こういう人と何かをつくりあげようとするとこんなのばっかりでやり直しが繰り返される。

通常の自分の仕事もやり直しばっかりしてるんだろうなと想像される。

で、叱られてもその場では反省したようなふりをするし。

ダメなんだよ、話になりません。

チャットで質問する時のこころ構え

　いつも思ってるんですけどなんでどね。

一緒にプロジェクトをやっている人から質問がチャットで来るのはいいんですが、聞きたいことをまとめてから来れば？ってすごく思う。

　特にキーボードを叩くのが遅い人はそれをやっておこないと、会話のリズムがめちゃくちゃになってしまいます。
　こっちは、打ち終わるまでずーっと待ってるんですよね。
ほんの数十秒だったとしてもじーっとまっとないとならないですしね。

そこから派生した話は仕方ないですが…。

PHPUnitでテストしてるけど

　ある会社の若手とPHP使ったシステムのUnitテスト(PHPUnit)を書いてて一応これで行けるんではないか？という状態になってたけど最近、テストコードのコミットを見たら

「ユニットテストを正常に行えないため、fixturesの利用を廃止」

なんてコメントのコミットを発見してしまうましたよ。

？？はっ？

ユニットテストを正常に行えないため？ってPHPUnitがバグってるってことなの？

いやいや、あなたの使い方が誤ってるだけですよそれは。

自分がやった時はちゃんと動いてましたけどね。
でも、Fixureの動きがわからない時は、データベース壊したり大変だったけど、何をどこにセットすればどう動くかは理解できましたけど。


めんどくさいけど、明日検証して、こらっ！って言わないとだなこれは。

VCSでファイルコミットの時に気をつけてね

　プログラム開発している時は、今時は、Gitだったり、Subversionだったりを使ってソースのバージョン管理をするのは当たり前です。

　ですが、こんな人は「コミットしないでください」と言いたくなってしまいます。

1. 特に内容は変更してないけど、使っているエディタの影響でインデントが全体的にちょとずれちゃったけどそのまま大量にコミット
2. コンフリクトとになったけど、そのマーク付きのままコミット
3. コンフリクトになったけど、適切に修正しないでコミット
4. 変更の塊ごとではなく、ファイルを個別にコミット
   Gitだったら、コミットを纏めることができるからまだ救いようはある。
   コミットをまとめてからPushしてくれれば良いので

みなさんは、ちゃんと意識してコミットしてますか？

VCSは、バックアップようのもとと思っていませんか？

使ったことない人、理屈がわかってない人にはちゃんとなぜ使うのかをちゃんと説明して挙げてください。

システム開発は、どこを目指しながらすすめるか

　一般論としては多分正しくないですが、こうシステム開発というか、プロジェクトを進めないと次回も同じ目にあったり、何も得ることができないと思っています。

まず！

　システム開発で「システムを完成させて稼働させること」を目標にすると、動けばOKのシステムになってしまって、

• メンテナンス性が悪いとか
• 遅いとか
• 動いてるソースと直しているソースが違うとか
• 残業が殺人的になるとか
• 自分さえ良ければほかはどうでもよいという人が出てきたりとか
• 新しい技術を習得して次の時に楽をするとかができない

となってしまいます。

プロジェクトを完成させるとなんで最低限やらないととダメなことなのでそんなところを目標にしても
なんの意味もないです。

人が逃げようが、死のうが、精神的にやられようがそんなことは関係なく、プロジェクトは完成させなければならないのです。

なので、なので、次回楽になるような仕組みを実験しながらプロジェクトを進めると案外楽しかったりします。

だって、その部分は初めてなので上手く行かなくて当たり前なんですよ。でも、上手く行けば次回からいろいろと楽になったりするんですから。
上手く行かなくても、何がまずかったのかを検証すれば次回にはきっと上手く行くんですよ。そして、楽になる。

スキルアップになるとも言います。

だからいつも言うんです。

今やっていることは、次のプロジェクトの為の練習なんだよ。
※練習は本番の為にやるので手抜きは無いという前提ですよ。


さぁ、プロジェクトリーダーやメンバーは、次のプロジェクトの為に頑張って練習しましょう！


お客さんに怒られそう…。

Oracleでエラーが出たから教えてほしいといわれ

　もうちょっと(いや、もっと！)、調べることを覚えたらどう？

 VB.NETのアプリケーションでストアドプロシージャを呼び出したらあるエラーが出ているようです。
なんかすごく奥が深い話でヒントがほしいのかと思ったら、返却されているエラーコードは何を意味するものかすら調べないで答えだけほしかったようです。

　「まずは、エラーコードが何を意味するのから調べてください」と言ったら、Google検索でOracleのエラーコード検索しました。
　まぁ、エラーコードの意味を知るためには、これが一番手っ取り早い探し方だと思うので良いと思います。

　で、検索結果をさーっとみて、適当なリンクをクリックして中をチラ見してました。
「なんかよくわからない」と発しましたよ。

「はぁ…、まずは、エラーコードが何を意味するかを調べてから、解決方法を探ればいいんじゃないですか？」と答えたあげましたよ。

何なんだろ？自分が何を探しているのかわからない状態で答えだけを求めようとする姿勢にちょっと腹がたちました(自分の中で)。

　エラーコード見たら、「更新できないビューを更新しようとしている」というものででしたので、ストアドプロシージャを見てみたらどうですか？とこれで終わりです。
　ストアドプロシージャを見てみたら、サマっているビューを更新していたそうです(Oracleの環境を作るのをミスっていただけ)


　もう、超ベテランなんだから答えだけ聞きたがるんじゃなくてもうちょっと、何が問題かを考える力を付けてほしいものですよっ。
　超若手だったらどういう手順で調べていくのかはちゃんと教えますけどね。


まずは、エラーコードの意味を把握してから調べましょうね。