最近の仕事

導入したMantisは上手く機能しているようだ。
バグ管理をExcelなどでやられた日にはたまったものではない。

それよりも問題は自分以外が素人程度のプロジェクト
運用能力しかないことだ。なにせ言葉が通じない。

そして、さらに悪いことに本人達がそれを自覚していないということだ。
今時、そんな運用をしているITシステムの開発現場は無い。
(有るだろうが、それはもう開発とは言わない)

僕の役割はシステムも構築からチーム運用にシフトしてきている。
もうこの編成で仕事をすることは二度とないだろう。

ガーソ

昼から4時間位休んで仕事を続けるつもりが気がついたら18:00回ってて、
携帯の着信リストがすごいことになるわ、SkypeのMessageがすごいことになるわで
げんなりする罠。

それでも今月の稼動が300時間行かないのは稼動制御がうまく行っているからか。
というか、これ以上働くと命令系統が破綻する予感…

昔は実装だけしていればいい環境だったから、400時間くらい軽く突破したもんですが、
コントローラーの役回りになると、そうそうそんな時間は行かなくなりますな。

まぁ、いったらいったで体を壊すことは目に見えているのだが。

徹夜で絶賛実装中

      r ⌒ヽ
      (´ ⌒`) ポッポー !
         .l l
       人
      (__)
 カタカタ (__)  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
     (・∀・#)<何この画面制御!?ぜんぜんできてないんだお!
   _| ̄ ̄||_)_\____________________
 /旦|――||// /|
 | ̄ ̄ ̄ ̄ ̄| ̄| . |
 |_____|三|/

今日はちょっとキレます。

文章は丁寧に書きなさい、と言う話。
仕事の仕様書作成ガイドラインにこんなのがありました。

「文末は”である”調。もしくは体言止めとする」

(‘A`)

である調は問題ない。それはいい、でも体言止めってどういうこと?
仕様の説明を名詞で止めるのか?

極端に言えば

 『これは、申請者が承認者に対して送信する申請書である。』

なら体言止め表現はこうかな?

 『これは、申請者から承認者に対して送信する申請書。』

この例だとまだ構文として単純だし、体言止め前の表現を出してしまっているので、
なんとなく意味が通ってしまうかもしれない。
ところが、こういう体言止め表現の文が突然出現したり、もう少し複雑な構造の
文章で使われると、何を言わんとするのかの意味の把握が難しくなります。
「である」か「ではない」か、どちらとも取れますし、
申請者が承認者へ送信する申請書だというのはわかるが、その後に何かあるのか?
と、勘ぐりたくなる文です。

もっと乱暴な人だとこう書くかも。体言止め+動詞の省略。
 『これは、申請者から承認者に対しての申請書。』
ここまでやると多分正確に意図を読み取るのはかなり難しいはずです。
でも、このレベルの文は気をつけていても結構書いてしまいます。自分も。
これくらいの表現で、プログラムの実行条件なんかを箇条書きにされた日には、
どうなるかわかりません。

ともかく、取扱説明書や論文などを書く際には体言止めは使わないのが普通ですが、
これは読み手の恣意的な解釈の混入を避けるためです。
同じことがソフトウェアの仕様書にも言えると思います。
ミスリードを誘発しかねない文章は、仕様書として書くべきではありません。

このガイドラインを書いた人は木下是雄を読んでない(笑)か、作家か、
どこかのどうでもいい技術系サイトのガイドラインを持ってきたか、
そんなところではないでしょうかね。少し考えればわかることでしょうに。

勤め人の頃、体言止めメールを仕事で書く上司と喧嘩しまくってた
記憶がよみがえってきたYO!
#当人は行間を読ませる訓練とか言ってましたが、それはレベルが違います(笑)

参考リンク: 体言止めは投げやりの証拠

kimura商店

個人事業主は基本的に社会保障が弱いです。
国民健康保険と国民年金ぐらいしか社会的保障が無いです。
追加で何らかの保障を載せない限り。

また、一人で動くことが多いので、何らかのトラブルが起きると
それをリカバリするのに個人で大変なコストを費やす必要があります。

この辺のしんどさは、僕や、ここを見ている僕の周りの物好きな
事業主経験者の人々ならお分かりいただけるところだと思います(笑)

そんなわけなのですが、僕も例に漏れずそのケースに当てはまり、
さらに自分の身を切り売りするほどの人の良さは持ち合わせていないので、
自分にとって負荷のかかる事は極力避けようとします。

それを「エー(・д・)ヤダ」とか「(‘A`)マンドクセ」とか言う僕にも問題が
有る気がしますがそれについてはまた別の機会で。

ともかく、これは楽して設けようという発想とは別次元の話です。
独り身で仕事をする上でのリスクヘッジをしているだけです。
逆に、これをやらないと我々の様な人種はたちまち暮らしが立ち行かなくなるのです。
一度倒れたら首括る覚悟が要ります。
だって自営だった実家で子供の頃からそう教えられてきたんだもん。

どうもこれが向こう側の人々には理解しづらいことのようです。
その辺の多くは組織の論理でリスクが分散してしまうので、
気が付きにくいと言えばそうなのでしょうけども。

まぁ、そろそろ何らかの判断をしなきゃいけない時期ではあるのですが。
とはいえ、大体腹は決まっていて、このまま行ける所まで行ってみようという感じではあります。

つまるところ、僕は通勤電車に乗りたくないのです。
結局それかよ。でもマジで嫌。

このBlogはSkypeを応援しているかもしれません

本仕事の方で、コアタイムを指定しようとする意思があるようで。
そんな工程一覧のアウトラインがメールで回ってきたのでちょっと考えてみるテスト。

しかし、そんなに同じ時間・場所でやらなきゃ心配なんですかね。
僕の役回りは、ソフト部品というかエンジンの供給者であって、
プロジェクトの推進要員ではないはずなんですけど…

そもそも彼らとはマインドが違いすぎるのかもしれないが、
面と向かわないとメトリクスが取れないというのも、今時変な話なわけで。
僕は支払給与ではなく事業所得の人なので自分に負荷のかかる
仕事の仕方の要請はは敬遠せざるを得ないのです。

しかしながら、もう一方の仕事では、それでうまくやれている。
別の仕事もそれでうまく回る。この違いは何処から来るのでしょうかね。

要は、必要十分なコミュニケーション手段と成果物を入れるリポジトリと
遠隔から使えるセキュアな通信路があればいいのです。

結論:Skypeは(・∀・)イイ!!

Pluggable VCは遠くになりにけり

久しぶりにクラスパスで嵌る。
side-by-sideやGACが懐かしい今日この頃です(つД`)
動いたからいいけど。

例のフレームワークは、View-Model間の更新伝播の仕掛けも
バッチリでいい感じではあるのだが、バインド情報を延々とXMLで
書くのはやっぱりJavaだなぁ、と。
まぁ、SwingのTableModelを弄る不条理さとお別れできるだけでもいいのかも知れない。
TMFの中途半端さ加減もアレだったし。
#.NETで編集画面作るときは呼んでくれると喜んで書きますの是非で呼んでください:-)

しかしながら、MicorsoftのDataBindingを見せられると車輪の再開発のような気もしなくも無い。
あれは恐ろしく良くできている。

PC上の分散環境なんて十年以上前の話ですョ?

タイトルとは関係無い話。
ここ3日ばかりちょっとJava仕事。

僕にとってはJ2EEも.NETのEnterpriseServicesもWindows DNAも
同じようなものなので、環境さえつかめばたいしたことは無いのでどうでもいいです。

今回のはもう一段上の開発フレームワークもあったりして、そっちを把握するほうが忙しいですが。
というか実装行為として発生する作業は掴んだので、ワーカレベルなら動ける。
しかし、僕の仕事の対象はどっちかというとマーケティングでの説明のための
フレームワークの仕掛けの把握と、アサイン可能なワーカの手配なので、
僕自身がワーカとして動くのはなるべく回避したい。マジで。
Eclipse立ち上げるとコード書き出す。ちょっと感動。

我ながら、だんだん手配師くさくなってきているなぁとは思うが、
今の僕の役回りはそういう感じなのです。

というわけで、来週あたり理不尽なプロジェクトに投入されて死にそうになっている
某人を拾い上げに行ってきます。
.NETじゃないけど、いいよね。そっちはそっちで謎プロジェクトでやりますし。

連休

前半で某山梨筋とか、静岡あたりを廻る予定だったのだが、
仕事で作っている部品のベンチマーク測定をしなければならない関係で、
ここ三日、自宅で作業しております。

今日の午後あたりの動き次第で、明日から実家に帰れるかどうかが決まる予定。

早く犬をモフりたい。

追記:明日帰れそう