おもくそクエストⅣ 打ちひしがれし者たち

前回のつづき。前回、以下のような形でエントリを締めた次第であるが…

転職活動という名の冒険へと旅立った勇者おもくそ。
次の城ロマリアに辿り着くには、レベル10は必要だ。
だが、今の僕は…

この場合のロマリアは一体何を意味するのか。転職活動のゴール？いやいや、それなら普通に考えると「ゾーマをぶっ倒す」だろうが。全く、我ながら全く意味が分かりません。エントリのタイトルをあんな風にしてしまったので、ちょっと絡めてみたんだけど、何かに例えて綺麗に纏めるって難しいね。まあ、結局何が言いたかったのかというと
「現在の僕は低レベル」
ということです。まだアリアハン大陸すら脱出できない程に。

僕のスペック…その前に、やりたい仕事は？

希望の職種は今までと変わらず『システム開発』です。やっぱり好きだから。どんな会社で働きたいかは、前回述べた通り『やる気・向上心が高い会社』だ。ここは絶対に譲れない。

次に業種。前回ちらっと述べたが、できればSI業界ではなく、Web業界に行きたい。今までいろいろなIT系企業の仕事内容紹介の記事や、IT業界人のブログを読んだり、あるいは直接話を伺うなどして集めた情報によると、どうもWeb業界の仕事の方が面白くてやり甲斐ありそうだ。以下、それら情報を基に、それぞれの業界に対する僕の印象。

要素	SI業界	Web業界
市場の行方	縮小は確実。要因は以下。 ・SaaSやERPパッケージの普及 ・オフショア企業の台頭	拡大。ソーシャル系サービスの需要が増える。スマートフォン、iPad等のタブレットPCの普及が進めば、さらに拡大するか。
仕事内容	総じて、上流か下流かの2択（そうじゃない場合もあるだろうけど）。 今後、上流は要件聞いてそれに適したサービス選定や、経営戦略などの超上流にシフト？ 下流は…仕事あるのか？	企画発案からプログラミング、運用、改善など、一気通貫
開発プロセス	ウォーターフォールがメイン ※アジャイルも増えてきてはいるようだが…	アジャイル（でないと捌けない）
最新技術に対する 積極性（※１）	総じて低い？ リスクは少しでも抑えたがる。	SIerよりは高い？
ということで、 僕にとっての やり甲斐は…	無さ気。 上流会社だとプログラミング機会少ないし、下流だとそもそも生きられなさそう…	SIよりは確実にありそう。

まあ、SIerでも全工程担当＆最新技術に積極的な会社はあるだろうし、Web業界でも実装は外注＆最新技術に消極的な会社ってのは絶対いるだろうから、結局ピンキリだろうけどね。でも大体は上記のような傾向だと思う。
 
最期に、扱いたい技術。ぶっちゃけ『話のネタになる・技術を通じて人脈拡大できるような有名どころ』であれば何でもいい。大きな括りだと、RIA、クラウド、スマートフォンアプリ…など。小さな括りだと、Ruby on Rails、Flex、AIR、Silverlight…など。とにかく「何それ？」って言われるようなマイナーなものでなければ何でもOKです。「『何でもやります！』と言うのはダメ。ゼッタイ。」というのは心得ているが、実際どの技術にも興味があるのでしょうがない。まあでも１個決めろと言われれば、Androidアプリ開発かな。

ここで本題。僕のスペック

実務経験年数

4年6ヶ月

年齢

28　※早生まれなので、今年度29

リーダー経験

無し。それどころかSE経験も碌に無し（4ヶ月のみ）。

主な経験言語（事情により、全て手続き型実装）　※単位：ヶ月

Java 1.4：33.5

Java 5.0：6

C# 1.1：3

C# 2.0：2

VB 2008：4

主な経験FW　※単位：ヶ月

某商用Javaフレームワーク：37.5

.NET Framework 1.1：3

.NET Framework 2.0：2

.NET Framework 3.5 SP1：4

その他補足

実務におけるOOP、デザインパターン利用経験なし

必然的にUML作成・閲覧経験もなし

実務におけるTDD経験なし

Trac Lightningのディープな利用経験なし　※プラグイン作成とか

太字の部分に注目してください。どうですか？お客さん。市場価値ないでしょ？僕のキャリアの殆どは、某商用Javaフレームワークです。打ち込んできたJavaコードの殆どは、フレームワークに依存したもの。フレームワークが有名で普及しているモノであればいいんだけど、勉強会などで同業他社の方に尋ねても、まあ知ってる人はいなかった。一人だけ（マジで一人だけ）使った事あるという方が見つかったのだが、一言「使いにくい」。高評価をくだした人間には、結局会うことは無かった。話やブログのネタにもできないし（ブログに載せたら確実に正体ばれる）…「マイナー技術は嫌だ！」と嘆くのは、こういう訳です。

そして何よりも致命的なのは、オブジェクト指向プログラミング経験が皆無ということ。前に自分でも書いたが、オブジェクト指向してない内はJava初級だ。

これが、まだアリアハン大陸を脱出できないと嘆く所以である（※２）。

＊

さて、嘆いてばかりいても仕方がない。レベルが足りないならレベルを上げるしかない…ん？またまた声が聞こえる。
「今の時代、PCとネット環境あれば自宅で勉強できるだろ？今までやってこなかったのか？」と。
これ言われると、弁明の余地はありません…いや、断言する。勉強はたくさんしてきた。Googleリーダーの統計情報や、Googleウェブ履歴がそれを証明してくれる。ただ…「実際に手を動かしてコードを書く」ことを殆どしてこなかった。これはよくなかったかもしれない。別に面倒臭いとかいうわけじゃなく、単に効率的に時間を使いたかったからだ。前述の通り、いろいろな技術に興味があるので、RSSで熟読する記事も多岐にわたる。手も動かすとなると、とてもじゃないが時間が足りない。それに、手を動かしてきっちり身につけたところで、変化の早いIT業界、すぐに陳腐化してしまう可能性大だ。それならば、とりあえずは概要・文法・思想といった部分を広く浅く把握しておき、実務で使用するタイミングになったら深く学習する方が効率的でいいのではと思うのだが…どうなんでしょう。間違ってますかね？

＊

※１
この辺に関しては、SonicGardenの倉貫氏の以下エントリに非常に感銘を受けました。

• ディフェンシブな開発 ～ SIビジネスの致命的欠陥CommentsAdd Star
  ：kuranukiの日記

※２
自慢じゃないけど、こんな僕でも、驚く事に会社の中ではエース級だったんですけどね。何らかの技術系コミュニティで有名というわけでも無く、ブログの技術記事のレベルが高いわけでも無い、こんな僕が…。プログラマという職業、人によって100倍以上の生産性の開きがあるという話は有名だが、これはきっと会社単位でも当てはまるのだろう。

＊

おもくそクエストⅢ そして転職へ…

9月末をもって退職した。転職先が決まる前に辞めた。
というわけで現在、いわゆる無職である。

退職理由としては、「Web業界で働きたい」というのが一応メインではありますが、もう一つの理由として
「仕事に対してモチベーション低く、技術に対する興味や向上心が無い（必然的に技術スキルも低い）、こんな会社では成長できない！」
というものがある。他人の言葉を借りると「『熱い人』がいない。」

決定的な決め手となったのは『クラウドやAndroidが何かすら知らない上司』『SQLインジェクションを知らないベテラン技術者達』だ。あれで完全に踏ん切りがついた。他にはこんなのも。転職活動において「後ろ向きな退職理由はダメ。ゼッタイ。」というのが基本なので、前向きな理由に置換しますと
「仕事に対してモチベーション高く、技術に対する興味や向上心も高い、そのような会社で切磋琢磨して永遠に成長していきたい！」
といった所だ。
いや、正確には後者の前向きな気持ちが先にあったからこそ生じた「こんな会社でやってられるか！」である。

おや、声が聞こえる。
「周りのせいにするな！」「周りを変えようと頑張ったのか？」と。
はい、ごもっともです。不肖おもくそ、少しは頑張りました。ですが、人の心を動かすのは非常に難しいのです…（※１）。時間をかけて粘り強く頑張り続ければ、確かにいつかは変えられるかもしれない。その時の達成感は、きっと筆舌に尽くしがたいものがあるだろう。だが、変えられないかもしれない。そして、時間（人生）は有限だ。日々、少しでも楽しく生きていきたい。僅かな変化の可能性に賭けて数年の時間をその会社のために費やすのは、イヤだ。僕はその会社のために生きているのではない。

ところで、転職する時は「決まるまで辞めるな」というのがセオリーという意見はよく聞く。僕は別に『セオリー』だとは思わない。使い古された言葉だが、仕事というものは人生の大半を占めるものであり、それが人生に与える影響は甚大だ。その仕事を探す作業である転職活動というもの、片手間に行うべきではなく、じっくりしっかり取り組むべき。僕は常々そう思っている。

というわけで、転職活動という名の冒険へと旅立った勇者おもくそ。
次の城ロマリアに辿り着くには、レベル10は必要だ。
だが、今の僕は…
（つづく）

ところで

君は勇者に「うんこす」と名付けたことがあるかい？

＊

※１
参考エントリ

• 「無」から「有」への育成は？
  
• Trac横転

＊

ドラクエⅢ貼ろうと思ったけど、DSあたりで発売されてるモノと思いきや無いんですね。
では「次のステージッに～ゆきましょう♪」ってことで。

ちょっとは暑さがマシになった夜のJava系小ネタ

Log4j、ログのローテートに失敗。原因はlog()メソッド？

プログラマとして社会に踏み出して5年目となる今年、ようやくLog4jを使用するシステムに巡り会えた（※１）。つっても、我々にはLoggerやAppender設計・製造する権限はなく、元請けが昨年製造・全社標準として採択されたjarを使わされるだけの立場なのだが。

言われた通りに組み込んで使用していると、不具合発生。ログファイルは1日ごとにローテーションする設定なのだが、日付が変わってもローテーションされず。さらに、出力済みのログファイルの中身を確認したところ、ある時刻までのログが全く出力されていない（その時刻以降は問題無く全て出力されているが）。

で、調べてみたら、以下の記事発見。java-jaの方でしょうかね。

• Log4jのアペンダDailyRollingFileAppdenderはローリングがうまくいかないことがある

前述の通り日付ローテーションと言うことで、まさにこのAppender使っていた。原因はこいつか？別のAppenderに変更して試したところ…状況変わらず、暗礁空域へ…いや、待て。よくよく考えたら、標準ログ以外のログも出力する要件があり、いくつかのLoggerを自作していたのだが、自作の方はDailyだろうが何だろうが、ローテートに失敗したことは一度も無かった。ということで、不具合の原因はコンポーネント側にあると考えるのが順当だ。ということで、提供元に調査依頼を出した。

完全に我が社の責任範囲外の事象だが、そのコンポーネントのソースコードがjarと一緒に提供されていたので、ちょっと覗いてみた。…空のcatchブロックだらけじゃねぇか。例外殺しやがって、こりゃ発見遅れるわけだ、ったく…
正常にローテートされている自作Loggerと異なる部分を探してみる。すると、ログ出力するのに使用しているメソッドに違いが見られた。自作の方はinfo()とかdebug()とかログレベルの名称を冠したものを使用しているのだが、提供されたものはlog()メソッドを使用している。この違いが原因なのか？log()メソッドの部分をinfo()とかに替えて試してみたかったが、何かのクラスが足りなくてコンパイルできず、試行は断念…

Tomcat5.5にて、<jsp:useBean>タグでJasperException発生の原因

…Tomcatは5.0だったかもしれん…

過去最悪の仕事環境でのお話。JSP＋サーブレットというアーキテクチャのシステム（Struts等のフレームワークは未使用）で、本番環境でのサーブレットコンテナは商用のあまり聞いた事のないやつ。そのサーブレットコンテナは、無償開発版といったものが無いので、皆サーバー環境でデバッグしていたのだが、リンク先記事にある通りコードがグダグダ。ステップ実行とかできないのは厳しすぎるので、ローカルにTomcat環境作ることにした。Javaのバージョンは我が社の案件にしては珍しく5.0だったので、Tomcatは5.5をチョイス。

環境構築して実行してみると…当節見出しの通りの不具合が発生。しかし、全ての<jsp:useBean>の箇所で発生するのではなく、決まったBeanでのみ発生している模様。これらBeanの共通点を探してみると…引数なしコンストラクタが定義されていないことが判明。

次に、JSPから変換されたJavaコードを確認してみた。<jsp:useBean>の箇所は、以下のロジックに変換されていた。

1. 引数なしコンストラクタでBeanをインスタンス化
2. setter・getterにて値の遣り取り

つまり、1.で未定義のコンストラクタが使用されて例外が飛んだっぽい。

JavaBeansの必要要件である「publicで引数なしのコンストラクタを実装」を行っていなかったために起こった悲劇であった。
コードレビューってやっぱ必要だよね。

正規表現メモ

範囲指定子の「-」。これ、括弧内（[]）の先頭か末尾に定義した場合、リテラルとして扱われる…ということを先月知りました。はぁ～…（自分に溜息）

＊

※１
ちなみにJava5.0に巡り会うのには4年かかった。
「人月計算とExcelとスーツの世界」はホント石橋を叩きすぎだ（それとも我が社の案件が極端なのか？）。

暴風前夜のeclipse

「.metadata」は定期的にバックアップしとけ

eclipseを長く使っていると、ある日突然、起動できない、ビルドできない等のトラブルが時々発生する。原因の殆どは、ワークスペースフォルダ直下でeclipseを設定情報を管理している「.metadata」の破損。トラブった際は.metadata内のあのファイルをああしろこうしろと言った情報がWebに溢れているが、定期的に丸ごとバックアップしておいてズドンと上書くのが一番手っ取り早いです（当然、バックアップ取得以降の変更内容は失われますが）。

SVN管理化のJavaソースファイル名称変更後に発生した、同期化エラートラブルの記録

一般的なトラブルかどうか分からんが、一応記録しておく。

SVN管理化のJavaクラスの名称を、リファクタリング機能にて変更した。Javaの場合、クラス名＝ファイル名という決まりなので、必然的にファイル名も変更することになる。これにより、変更前のJavaファイルは「削除」、変更後は「新規」扱いとなり、それぞれコミットした。すると、それ以後、ファイル名変更をコミットしたメンバー（厳密にはworkspace？）以外の開発環境において、同期化エラーが発生するようになってしまった。

上記のトラブルは度々発生した。何が原因なのか結局わからなかったが、トラブル発生直前の操作内容を見聞すると、以下の共通点が浮かび上がってきた。

1. クラス名を変更した。
2. 変更するのにeclipseのリファクタリング機能を用いた。
3. 新規ファイル（クラス名変更後のJavaファイル）は、「バージョン管理に追加」せずに、いきなりコミットした。

これらを踏まえて、クラス名変更時の手順を以下のようにしたら、トラブルは発生しなくなった。

1. クラス名を変更する際は、リファクタリング機能は使わない。
   つまり、新名称のJavaファイルは新規作成、旧名称のは普通に削除。
2. 新名称Javaファイルは、まず「バージョン管理に追加」し、それからコミットする。

上記解決方法は別の人が調べて持ってきてくれたのだが、1・2どちらか片方だけではダメだったのだろうか。まあ「ダメだった」って言ってたからダメなのだろうが…一度自分で試そうとしたが、これ以上トラブル発生して作業が停滞するのもしんどかったので（てかプチ炎上中だったし）、実行に映さず。

ちなみに、そのリポジトリのルートディレクトリに対するアクセス権限が与えられていなかったのだが、関係あるのかな？

別リポジトリ管理化のリソースをコピペしてくる際の注意事項

ユーティリティ群など汎用的な部品は、別プロジェクトで作成したものをコピーしてくるという事はよくやると思うが（※１）、その際は「.svn」はコピーしないこと。どのリポジトリに接続するかという情報はこの中で管理しているので、「.svn」ごとコピーしてしまうと、同期化時に別のリポジトリに対する接続ダイアログが何度も表示されたり、「遮断」的なエラーが発生したりする。

ちなみに、TortoiseSVNのエクスポート機能を利用すれば簡単に削除できる。

※１
てかjar化しろって話か。

昨日よりはマシな夜のOracle

長さ0の文字列（''）はNULLとして扱われる

「フィールドの値がスペースのみのデータを抽出」という仕様を実現するのに「TRIM( [フィールド名] ) = ''」と組んだが、期待した結果とならず。TRIM( [フィールド名] )をSELECTして戻り値を見てみると、値がスペースのみの場合は何とNULLが返ってきている。あれっ！？空文字とNULLは別物の筈だが…何とも不可解であるが、ゴーイングマイウェイなOracleならあり得るかと、素直に抽出条件を「TRIM( [フィールド名] ) IS NULL」と修正した。

後で調べてみたら、やはりOracleの独自仕様らしい。DB界の泰斗であらせられるミックさんの記事で知った。

• SQLアタマアカデミー:第8回（の下部COLUMN）

上記記事によると、これに関してはOracleも反省しているのか知らんが、将来修正されるかもしれないとのこと。マジかよ。そうなったら上記みたいなSQLは修正しなきゃいけないじゃないか…

ANSI SQLの外部結合構文（OUTER JOIN）を使用時のバグが盛りだくさん

バージョン9i,10gにて、SQLの結合構文にANSI SQLのOUTER JOINを使用すると、エラーや結果不正が発生することがあるらしい。まあ、結構有名な話ですが。

ちなみに、具体的なバグの発生条件・内容や修正パッチは、サポート契約しないと入手できない（ケッ！）。
ネットに転がってないか散策していたら、以下のページを発見。何かのグループウェアのページのようだ。

• リンコム ネクスト/WF - 動作環境

上記ページの「Oracle9i,10gにおける不具合事項」の節に
「問題を修正した9.2.0.8,10.1.0.5,10.2.0.2のPSRが提供されています」
とあるが…本家発の情報じゃないので、何とも言えないな…

余程複雑なSQLでなければ、まあ大丈夫だというような意見をどこかで聞いたが…発生条件が不明である以上、あの忌まわしき(+)を使わざるを得ない。はぁ～…

複合主キーにまつわる幻？

ここで今から述べることは、夢幻の可能性大。

Oracleのバージョンは9i、複合主キーを使用したテーブルに、キーの一部がNULLのレコードを登録できてしまった…気がする。
例えば、複合主キーが3項目からなる場合、以下のようなレコードが登録できてしまった…気がする。

INSERT INTO table VALUES ('pk1', 'pk2', NULL, …)

しかも、複合主キーの一部がNULLのレコードは、幾つでも登録できてしまった…気がする。NULLはどの値とも等しくはならない（例え比較対象がNULLであっても）からだろう。

しかし、ネットで調べてみると、「複合主キーの一部にはNULLをセットできる」なんて誰も言ってない。自宅PCのMySqlで試したら、見事にはじかれたし。Oracleで試せって話だが、重たいし汚れるから自宅PCに入れたくない。

うーむ、俺、疲れてたのかな…

[Trac Lightning]秋とは名ばかりの夜の小ネタ集Ⅱ

VistaでTracLightningをサービスとしてインストールするには

TracLightningをサービスとしてインストールするには、スタートメニューの「サービスのインストール」を実行すればよい…のだが、Vistaだとエラーが発生した。


詳しく調べる気にもならんが、原因は十中八九、一般ユーザーには悪名高いUAC（ユーザーアカウント制御）によるものだろう（※１）。

よって、管理者として実行してみる。「サービスのインストール」で実行されるのは「[TracLightningルート]/bin」フォルダ直下の「install-service.bat」なので、これを右クリック→「管理者として実行」（※２）。続いてUACのダイアログが表示されるので迷わず「続行」…結果はうまくいった模様。

サービスのアンインストールも同様で、「uninstall-service.bat」を管理者として実行すればよい。
ちなみに、上記画像のコマンドからお分かりだと思うが、サービスの実体は「httpd.exe」つまりApacheです。

ビルトインアカウント「admin」を削除すると、プロジェクト追加時の手間が増える

…ここでのお話、ちょっと記憶が曖昧＆メモ取り忘れのため、間違っているかもしれません…

僕がTracLightningを使い始めるに当たって、以下の記事を参考にさせていただいた。

• Trac Lightningで始めるチケット式開発「電撃」入門

この記事のユーザー設定の節にて、
「管理者ユーザーを作成したら、admin／leader／guestアカウントは速やかに削除しましょう」
と述べられていたので、この通りに行った。

そしてある日、「create-project.bat」を実行して新規プロジェクトを作成。設定を行うため、作成した管理者ユーザーでログインを試みる。上記記事でも述べられているが「Trac Lightningのユーザーはプロジェクト共有」なので、問題無くログインできる筈…OK、問題無い。しかし、「管理」メニューが表示されない！。

どうも、自分で追加したユーザーの場合、新規プロジェクトではパーミッション設定が初期化されてしまう模様。ビルトインアカウントの場合はそのような事は無く、新規プロジェクトでも「admin」は名に違わず管理者権限を有しているのだが、上記の例では記事に従って削除してしまっていた。

以上より、管理者不在の状態に…嗚呼、設定ができない…
と、GUIどっぷり野郎の嘆きはここまでにして、この時は確かコマンドプロンプトでTRAC_ADMIN権限を付与して解決したような…

trac-admin [プロジェクトルートのパス] permission add [ユーザー名] TRAC_ADMIN

と言うわけで、adminアカウントを削除してしまうとこのような手間が発生してしまいましたと。
もちろん、セキュリティの観点では削除すべきであることは言うまでもありません。

添付ファイル最大サイズの設定

trac.iniで設定可能。確か再起動しなくても適用された。

[attachment]
max_size = 2000000

Wikiのファイル添付時Internal Error

に何度か遭遇したのだが、どうもファイル名（orフルパス？）にスペースや全角文字が混じっていると発生しうる模様。

＊

※１
ちなみに僕はマルウェアビビりなので、セキュリティを強化してくれるUACに対して嫌悪感は無い。

※２
管理者権限で実行する設定は、ファイルのプロパティの「互換性」タブ下部「特権レベル」セクションで設定できるのだが、バッチファイルの場合はグレーアウトしており設定できない。セキュリティ的な問題を考慮したVistaの仕様か？

[Trac Lightning]秋とは名ばかりの夜の小ネタ集Ⅰ

気がつけば夏は過ぎ去り、気がつけばTracLightningは2.5になっていた。
ファイル添付をドラッグ＆ドロップで行えるのはすげー便利だ。

複数ワードで検索時、ワードの区切りは半角スペースで

TracLightningの目玉機能の一つである全文検索機能。検索ワードをスペースで区切って複数入力した場合は、一般的なサーチエンジンと同様にAND検索となる…が、検索ワードの区切りのスペースが全角の場合、どうも区切り文字として認識されず、全角スペースという一つの文字として扱われる模様。

以前、ログファイルの出力レベルに関してヘルプを検索しようと「ログ△レベル」で検索した際、結果は以下の通り空振り。
※△＝全角スペース

「ログ レベル」と半角スペースで区切って検索すると、以下の通りヒット。

Googleとかと同じ感覚で検索してはいけないようだ。我々日本人にとっては地味に面倒臭いが仕方が無い。
尚、半角スペースを含むワードで検索したい（いわゆるフレーズ検索ね）場合は、一般的なサーチエンジンなどと同じように引用符（「'」「"」）で囲ってやればよろしい。

ログファイルの出力レベルは必ず設定しましょう

プロジェクトの動作ログは「{プロジェクトルート}/log/trac.log」に出力される訳だが、デフォルト設定のままだとデバッグメッセージも出力される。このまま運用すると、ログファイルサイズはすぐにGBの大台に達する。ログファイルのローテーション設定というのは無いようだし、ここは大人しくログレベルを適切に設定するようにしましょう。

設定方法はヘルプ（TracLogging）に書いてある。trac.iniの[logging]セクションでlog_levelオプションを記述。

[logging]
log_level = WARN

そう言えば、ソース弄ってログファイルローテーションを実現するとか言ってる奴がいたな…

Wikiの見出しに記号が含まれる場合、その見出しのURLに記号は含まれない

Wikiの見出しには以下のようにURLが割り当てられる。あるWikiページにて、別のWikiページの特定見出しへのリンクの記法は
[wiki:Wiki名#見出し リンクテキスト]
という具合。

ところで、見出しに記号が含まれる場合は、URLは以下のように記号を除いたものとなる。記号は半角だろうが全角だろうが除去される。リンク貼る際は要注意。

灼熱アイランドのExcel

CollectionオブジェをMap的に使用する際の注意事項

VBAのCollectionオブジェクトは、Key-Value形式で値を格納でき、Map的な使い方が可能。
ところが、キーの有無を確かめるAPIが無い（JavaでいうところのMap#containsKeyみたいな）。
その上、存在しないキーを指定すると、落ちる。
以下の例では「mapModoki.Item("キー２")」で落ちている。

ちなみに利用可能メソッドはたった4つ（仕様は名称から大体分かるよね）。

VBAの内部文字コードはUnicodeで、エンコーディングはUCS-2

※Office2000以降。参考：EXCELのVBAでLenB関数について

あまり聞いた事がない符号化方式だが、これって何と全角も半角も2バイト。

'以下はすべて「10」と表示される
MsgBox LenB("12345")
MsgBox LenB("abcde")
MsgBox LenB("１２３４５")
MsgBox LenB("ＡＢＣＤＥ")
MsgBox LenB("あいうえお")

Shift-jisで扱いたい場合は、StrConv関数使って変換すべし。

LenB(StrConv("文字列", vbFromUnicode))

Javaでいうところのcontinue文は無し

次ループに処理スキップするcontinue的な構文は何と用意されておらず、ラベルとGoto文使用するしかないとのこと。使えね～
参考：VBAのループ構文にnext(Perl)やらcontinue(C)やらの機能がない件

セル内改行の検索方法

「Alt + Enter」で入力できるセル内改行。これを検索したい場合は、「Ctrl + J」を使うんだってさ。
以下、セル内改行を「\n」に置換した例。ご覧の通り、「Ctrl + J」の値は検索ボックス上には見えない。


ちなみにOpenOfficeのセル内改行は「Ctrl + Enter」。OpenOfficeの場合の検索方法は不明。

ワークシート一覧表示隠しコマンド

シート移動矢印部分を右クリックすると、シート一覧が表示されることを最近知った。
これでシートが数十あるような場合の移動が楽になる（てかブック分けろ）。

え？みんな知ってたって？

真夏の夜のWindows

リモートデスクトップ接続：接続先のPCをシャットダウンする方法

リモートデスクトップで接続した場合、スタートメニューに「ログオフ」「切断」はあるが「シャットダウン」が無い。
まあコマンドプロンプトでshutdownコマンド実行すれば済む話なのだが、GUIどっぷり世代としては、マウスクリックでシャットダウンする方法も知っておきたい所だ。
調べたらすぐに見つかったので、ここに記す。

by GUI：「ロック」やら「タスクマネージャ…」ボタン等が並んだあのダイアログから

PCフリーズ時の御用達である「Ctrl + Alt + Delete」。この操作で出現するダイアログ（※１）には「シャットダウン」ボタンがある。接続先PCも同じWindowsなので、このダイアログを利用してやればいい。

では早速「Ctrl + Alt + Delete」ポチッとな…ダメだ。接続元PCに対してダイアログが表示されてしまう。

正解は「Ctrl + Alt + End」でした。

by CUI：shutdownコマンドの使い方も

オプション無しで実行した場合はヘルプが表示されるだけ。
シャットダウンを実行する場合は「/s」オプションが必要。

C:\>shutdown /s

「いもうとデスクトップ」と空耳ったあの日は快晴だった

はい、既出ですね：検索結果

コマンドプロンプト：カレントドライブの移動

「cd」だけだと移動できないということを時々ど忘れする。
ここに記すことを以て焼きつけるんだ、俺。

方法１：cdなんていらない

ドライブ名だけでOK。

C:\>D:

方法２：やっぱりcdが恋しい

「/d」オプションを使用。

C:\>cd /d D:

＊

※１
WindowsXPで「ようこそ画面を使用する」設定の場合、ダイアログは表示されずタスクマネージャが起動する。しかし、この場合タスクマネージャに「シャットダウン」メニューが追加されており、そこからシャットダウン可能。
試したことないですけど、もし接続先PCが「ようこそ画面を使用する」設定だった場合、同じ挙動なんですかね？

オラ、焼け野原しんのすけだゾ！ その５（完） Trac横転

炎上プロジェクト記録、完結編。

Trac、稟議通らず

当プロジェクトの作業場所は客先。よって、ハードウェアは客先のものを利用することになるので、Tracのようなサーバソフトウェアのインストールには申請が必要（※１）。セキュリティに五月蠅い企業なので、こういった申請のフローは複雑・面倒で時間がかかり、散々待たされた挙げ句NGということが屡々。しかし、Tracに関しては、別会社主導のプロジェクトで利用実績があったので、すんなり通るだろうと皆高を括っていた。それでも申請してすぐOK出るかというと流石に厳しいので、それまでは僕のPCにインストールして利用することとなった。

結果…何とNG。情報共有ならグループウェアNがあるし、タスクリストはExcelでいいじゃないですかとのこと。Excelで情報共有する事の愚かしさなんて過去に語り尽くされたし、グループウェアNは全文検索ができない（※２）。今時、Webで情報検索する時、カテゴリ辿りますか？キーワード検索でしょ？キーワード検索の方が遙かに楽でしょ？
上記の事を（勿論大人の対応で）伝えて頑張ってみたが、玉砕。某社はOKだったのに…会社力の違いか？それとも俺の力不足か？
一応、現状の環境（僕のPC上で稼働）を利用する許可は頂けたのだが…何だかなぁ…（※３）

Trac ＜ Excel

今年の1月の私。

・仕事が楽しくなってきた。『Trac Lightning』を利用して開発プロセスのChange（死語）に取り組んでいるからだ。
・懸念していた「面倒くせ～」といった反発もなく、むしろ積極的に利用してくれており…
・非常に充実している

この頃はまだ平和だったからなぁ…

プロジェクト序盤は、上記の通りそれなりに利用されていた。しかし火を噴いた中盤以降、
「Excelの方が記入楽。チケット登録するのって面倒臭い。」
「口頭の方が速い」
「チケットだと集計がしづらい。Excelならマクロが使える。」
等の難癖をつけだし（上も下も）、殆ど利用されなくなった。
人間の本質は、やはり追い込まれてから現れる。

「チケット登録の手間とExcel記入のそれの間に大きな差があるとは思えない。」
「Tracには集計に利用できるクエリ機能というものが備わっている。SQLを使えるので、マクロ組むよりは絶対簡単。どうしてもExcelで欲しいという場合でも、Excel形式でダウンロードできるので、チケット登録しておいて損はない。」
「今回、Tracによる管理に取り組んでいる第一の目的は、ノウハウ蓄積。やり方戻したら、今まで通り何にも残りませんよ！」
そしてここでもExcelで情報共有することの愚かしさと共に、上記事項を伝えて頑張ったが、再び玉砕。中盤以降は、質問は殆ど『口頭』、Excel管理すらされていない状況。バグ一覧表とかは流石にExcel作っていたが（それこそTracの役割なのに…）。てか、あんだけ「Excelじゃないと集計できない」とか言ってた癖に、出来上がったExcelファイル見た限り、集計なんてしてる気配が全くない。あの啖呵は一体何だったのだ？

口頭至上主義

その２・その３でお伝えした、DBアクセスロジックの仕様分裂問題。この問題の対応がどうしても納得いかず、はらわた煮えくりかえっていたので、プロジェクト完了後に改めて直訴した。こちらの最大の主張は、
「『意見があれば言ってください』と伝えており、さらに使えない旨を伝えて向こうは『了解した』と言ったにもかかわらず、勝手なことをしていた」
という点。ちなみにこの遣り取りのメールは、本文冒頭に「マネージャー陣も含めて全員必ず読んでください」という一文を赤太字で含めていた（レビュー時のリアクションを考えると、ここまでしても読んでなかったようだが）。
するとマネージャーは
「口頭で遣り取りしなかったからだ。」
…わからん。世の中、そういうものなのか？その時も、こうして文書書いている今も、これに対して何て返事していいかわからない。
「読字障害をお持ちなんですか？」という言葉が危うく喉から出かけた。
てか、フロアが結構離れてるっつーの。一々口頭でなんて、非効率すぎる。

まあ、殆どのメンバーはその『口頭』方式を実践してましたが…
うちの会社、分散開発は絶対無理だなと実感した次第。それとノウハウの蓄積・見える化も。
「どんなにすぐれたツール・システムを導入した所で、使う人間に使う意志が無ければ…」という、ありがちな台詞がこの身を貫く。

※１
ちなみに、PCの場合は「Vector・窓の杜で公開されている『フリーウェア』は自由にインストールしてよいが、それ以外はNG」という、厳しいんだか厳しくないんだかよく分からんというもの。とにかく、どんなに有名・信頼のおけるツールであろうと、上記サイトで公開されてなければNG。秀丸もATOKもNG。ギークがキレる職場。

※２
或いは備わっていたのかもしれないが、少なくともその顧客は利用していなかった。

※３
僕のPCのパフォーマンス悪化を懸念していたが、後述する通りTracは殆ど利用されなかったので、それ程支障は無かった。嬉しいような悲しいような…

＊

ガキの頃よく唄ってた初代オープニング、唄うは亀田誠治の嫁。

オラ、焼け野原しんのすけだゾ！ その４ プログラミング力≒片付け力

気がつけば本日は終戦記念日。そんな日にこんなタイトルのエントリ、不謹慎か？

＊

さて、これまで3回に分けて行ってきた、炎上プロジェクトの1人ふりかえり（その１ その２ その３）。致命的レベルの問題のふりかえりは粗方完了した。私の仕事力・文章力不足もあり、Tryの内容・表現がショボかったり、そもそもエントリ自体が愚痴っぽくなっているかもしれないが、それは追々改善していこうと思う。

当エントリからは、プロジェクトに対するその他の考察・感想・愚痴などを記す。

プログラミング力≒片付け力

プログラマに対して、私はある偏見を抱いている。それは
「デスクトップやブックマークが汚い者は、総じてソースコードも汚い」
というものだ。
プログラミングは、結局は『整理整頓』作業の連続だ。固定値の定数化、何度も使用するロジックの関数化・クラス化、関数化・クラス化する際はどのように分割するのがベストか、無駄・冗長な記述を如何に抑えるかetc…。よって、僕が思うに、プログラミングで一番必要なのは、『整理整頓力』とか『片付け力』とでも言う力だと思う（※１）。
そしてこの力の有無を如実に露わにしてくれるのが、デスクトップやブックマークだ。『片付け力』の無い者は、フォルダやタグで系統立てて整理することを碌に行わず、混沌と化している（フォルダの命名も分かりにくかったり…）。

『片付け力』という力。この力は、向上させるといういう意識を持って取り組まなければ、向上するものでは無い。人生経験、仕事のキャリアを積んでいけば自動的に向上するというものではないのだ。皆も今までたくさん見てきたことであろう、部屋を『片付けられない大人たち』を。
プログラミングも同じで、整理整頓された綺麗なコード書いてやるぞ！という意識が無い者は、いくらプログラミング経験を積んだところで、生み出すコードは汚いままだ（※２）。

以上より、『Problem6：技術力はキャリアの長さに比例するという認識』には、大いに異を唱えたい。

上記偏見、僕の少ないキャリアで見てきた限りでは大体当たっていると思うが、皆さんの周りではどうだろうか？

＊

※１
この理屈だと、「ソースコードが汚い人間は、デスク周りや部屋も汚い」という事になる。確かにその通りの者は多い。そうでは無い者、つまりソースコードの割にデスク周りなどは綺麗な者は、得てして『八方美人』が多いというのが僕のもう一つの偏見だ。現在のプロジェクトにもそういう輩がいる。目に付く範囲ではきちんとする、普段は遅刻してる癖に、マネージャーがいる日だけは遅刻しないという…それも1人だけではない…鼻折りたい。

※２
経験を積むことで、既存のライブラリだけでどれだけの事ができるかという知識が蓄積され、所謂『車輪の再発明』をやってしまう可能性は減少し、「無駄・冗長な記述を抑える」に繋がる事は確かにある。
が、根本的に『片付け力』が備わっていなければ、焼け石に水だろう。

＊

オラ、焼け野原しんのすけだゾ！ その３ 技術力∝キャリア？（後）

前回のあらすじ。

DBアクセスロジックに関して、どのように実装するかの方針を開発者全員で打合せを行い合意形成。その後に意見は何も出なかったのでフィックスし、製造フェーズが開始された。
製造フェーズが開始されて数日後、メンバーの1人から「DBアクセスの仕組みを作った」との連絡が。内容を確認した所、致命的な問題も含まれており、そもそもフィックス済みの方針と異なるので、採用できない旨を伝える。その後、了承した旨の返事を受け取る。これで一件落着かと思われたが…

メールの遣り取りがあった次の週、コードレビューが実施された。内容は、コーディング・命名規約等が遵守されているかどうかをチェックするというもので、「ここはこう実装した方がいいんじゃない？」というようなリファクタ目的ではない。
※ちなみにコードレビューは結局この1回限りだけだった。何だかなぁー…

今回のシステムは、大きく分けて画面系とバッチ系に分かれていた。プログラマは全6名で、その内2名がバッチ系担当、その他4名が画面系担当だ。全てのソースコードをレビューする時間的余裕は無かったので、画面系・バッチ系それぞれから代表して1つの機能を抜粋し、それに対してレビューを実施した。画面系の代表は私が製造した機能だ。まず私のコードのレビューを行い、つづいてバッチ代表の番となった。途中まで淡々と進んでいたが、DBアクセスロジック部分で問題発覚。バッチ側のコードが、開発者間で合意形成した決定事項を遵守していない。 先週のメールで遣り取りした「採用できない」仕組みのままだ。
同席していたリーダー（以下、L）が

L「何で分裂しているの？統一してください。」

とごもっともな一言。いや、ごもっともじゃないな、ここは違反している側に対して「規約を遵守してください」じゃないのか？
「統一せよ」ではなくて「違反している側は遵守せよ」が正当である旨と、そもそもこの仕組みは「採用できない」旨を伝えたところ、その仕組みを作った人物（以下、X）曰く

X「致命的な問題は修正したので問題無い。」

との事。どうやら、SQL文実行クラスを、Java標準のものから、フレームワーク標準のDBアクセスクラスに変更した、これで要件満たせるとの事。いや、もうそう言う問題じゃ無いんですけど。約束事を守っていないんですよ。
すると、

L「何でちゃんと話し合っておかないの！とにかく統一してください。」

私「こちらはその話し合った末の結論に従っています。それに、結論出た後も度々『意見があれば言ってください』って伝えてましたが、このような仕組みを作っている事に関して、何も連絡ありませんでした。致命的な問題の修正に関してもそうです。」

約束事は度々破るわ、技術的にも使えるものでは無いわ…折衷案があるような問題でも無いし、こちらとしては全く譲歩する気は無い。その旨伝えた所、

X「こっちの修正は無理。もう大分作り込んであるから。」

…わからん。何ですか、この威風堂々っぷりは。
しかし、もっとわからないのは、リーダー陣はどうもXの方を支持しているらしいという現実だ。
その心は、前回エントリで挙げた
Problem6：技術力はキャリアの長さに比例するという認識。つまり、キャリアが短い者の言うことよりは、長い者の方が正しいという価値観。によるものだ。
5年目の若造よりも、10年以上の付き合いがあって仕事も速く（※１）て信頼できるベテランの方が正しいと考えてる感がひしひしと伝わってくる。「Xさんが言うなら間違いない！」という台詞を何度聞いたことか。実は、「致命的な問題は修正した」と言っておきながら、相変わらずPreparedStatement使ってなかったので（※２）、この点に関して突っ込んだのだが、ここでも終始「Xさんが言ってるんだから…」という感じだった（※３）。

結局、約束事を守っていたのは画面チームの3人で、画面の1人とバッチチームは例の「採用できない」仕組みを利用していた。再度話し合って決定しろという事になったが、そこでの遣り取り・雰囲気を考えると、「話し合え」なんて只のポーズであることは明らかだ。結論なんて、既に決まっている…結局、約束事を守っていた3人が、血を吐く羽目となった。

＊

後で聞いた話だが、バッチチームが独自の仕組みを作ったのは、マネージャーの命令だったとのこと。バッチ系プログラムは、将来的にフレームワークを変更した場合も利用できるように、フレームワークに依存しない作りにしたかったそうだ。
…いやいや、それなら、画面系と統一させる必要なんてないじゃないか…ったく、リーダーは偉そうに「ちゃんと話し合え！」と言っていたが、そっちだってマネージャーと意思疎通できてないじゃないか。
それに、「フレームワークに依存しない作り」なんてものは、顧客は望んでいなかった。一応、プログラマ・リーダーという立場のため、クラス構成の説明等を顧客に説明しなければならない機会があったのだが、
「何でこんなややこしい作りにしてるんですか？」
「フレームワークに依存しない作り？でも結局フレームワークのライブラリ使ってますよね？」
「ハッキリ言って非常にわかりづらくて、保守しづらいです。」
と、散々だった。はい、全く仰る通りです…
マネージャーはその旨伝えてあると言っていたが、この時の遣り取りを鑑みるに、全然伝わってないことは明確だ。YAGNIの原則について勉強してください。

＊

さて、今回のProblemをおさらい。

• Problem5：開発者間で決定するように指示した事項に関して、その決定事項の内容確認、及びそれらが遵守されているかどうかを確認しなかった。
• Problem6：技術力はキャリアの長さに比例するという認識。つまり、キャリアが短い者の言うことよりは、長い者の方が正しいという価値観。

これらを解決するためにTryしなければならないことは？

• Try5：
  …わからん。確認してもらったところで、Problem6が存在する限り、覆る可能性は常に存在する。
• Try6：
  価値観を変えさせるのは非常に困難。よって、「技術力がある」と思われるようになるしかない…のか？

＊

※１
確かに仕事は速い。だが質はどうかというと…↓

※２
PreparedStatement使わない理由を尋ねると、「SQLがキャッシュされると、大量のSQL実行した場合、サーバーのメモリ食い尽くして落ちる」とのお答えが。いやいや、キャッシュしない（使い回さない）方がメモリ食い尽くすと思うが？それ以前に、メモリ食い尽くす程の量のSQLをPreparedStatement使わないで実行してたら、パフォーマンスの面を絶対クリアできない。
ちなみに、SQLインジェクション脆弱性に関しては、「エスケープ処理は（パラメータ）渡す側の仕事」だそうだ。絶対間違っている。PreparedStatement使う方が、遙かに簡単・安全・確実だ。

※３
この遣り取りで、開発チームの誰もがSQLインジェクションを知らないらしいという事実が判明。

＊

懐かし。『ESCAPE』よりは『アネモネ』の方が好きだったなー

オラ、焼け野原しんのすけだゾ！ その２ 技術力∝キャリア？（前）

「燃えるゴミのほうに燃えないゴミ入れたらダメですよ。
でも燃えないゴミのほうに燃えるゴミ入れるのは別にエエやん」
～ by 松本人志 at 松紳とか放送室とか

松ちゃん、それは屁理屈だ。

さて、前回に引き続き、ふりかえりを行う…って、1ヶ月近く経ってるじゃねぇか。この間一体何してたのかというと、ロシア状態ですわ、また…

• Problem5：開発者間で決定するように指示した事項に関して、その決定事項の内容確認、及びそれらが遵守されているかどうかを確認しなかった。
• Problem6：技術力はキャリアの長さに比例するという認識。つまり、キャリアが短い者の言うことよりは、長い者の方が正しいという価値観。

詳細設計フェーズも終盤に差し掛かった頃、DBアクセスロジックの実装の規約・方針を決めておくように上から指示された。

Java言語（というよりオブジェクト指向言語）でDBアクセスといえば、DAO・DTOと呼ばれるクラス群（＋ORマッパー）で行うのが一般的だ。開発を何年も行っていれば、どこの会社も大抵はプチフレームワークとでも言うような仕組み・パターンを構築しているものだろうが…うちの会社はさにあらず、全社標準の規約というようなものは存在しない。コーディングは疎か、仕様書のフォーマットなども、プロジェクトによってまちまちだ。外部から参画している1人のメンバーは「（全社標準規約的なもの）無いの！？駆け出しの会社じゃあるまいし、普通作るよね…」と呆れ顔だ。
※規約が無い事もさることながら、その現実に対して何ら疑問を持ったり改善しようとしてこなかった古参社員にはもっと…

閑話休題。さて、話し合い、今回のプロジェクトではどうするか…ぶっちゃけ、特に話し合うことなどは無かった。どういう事かというと、

1. 当プロジェクトで利用するフレームワークのライブラリに、DBアクセスクラスは用意されている。
   ※SELECT・FROMといったSQLの要素をプロパティとしてセットし、それを元にSQL文を生成し、SELECT文であれば検索結果をHashMap的なオブジェクト（の配列）で返すといったクラス。
2. このフレームワークのシステムでは、1.のクラスを用いるのが一般的というか当然。
   同じフレームワークで構築した他のシステムにおいても、勿論上記クラスを使用している。
3. 1.のクラス使用すると、ログ出力・主キーにセットするシーケンスの採番等、『おまけ』処理も自動で行ってくれる。
4. 3.のおまけ処理に関して、顧客から要望が挙がっている。つまり、顧客も1.のクラスを使用するものだとの認識でいる。つまり、「1.のクラスを利用する」ことは、暗黙的ではあるが顧客の要件である。
5. 作ったシステムを保守するのは顧客自身。顧客（情シス部門）はSIerと異なり、保守的なスタンスであり、あまり新しい事にチャレンジしたり覚えたりしたがらない。
   よって、2.で述べた他の既存システムとあまり外れた方法をとるべきではない。むしろ揃えるべき。

と、言うわけで、選択の余地など無い。DAOやらDTOやらクラス設計どうするというような大規模な取り決めなど不要。こちらで出来ることと言えば、上記DBアクセスクラスをラッピングすることくらい。
結局、上記5項目を全員に伝えた上で、どういう単位でラッピングするかという事だけで終了。話し合いは意見が衝突するようなこともなく、「意見は？」の問いに誰も挙手せず。話し合い終了後も意見は出ることもなかったので、フィックスし、数日後に製造フェーズは開始となった。

製造フェーズが始まって数日、あるベテランプログラマから連絡が入った。
「DBアクセスを行う仕組みを作った、概要・使い方を説明したいので、時間取れないか？」と。
…はて、フィックス済みだが。ユーティリティー的なものを作りましたってことなのか？でもそれにしては「時間取れないか？」って大袈裟だよな。
この時点で進捗に遅れが発生していたこともあり、あまり時間をかけたくなかったので、とりあえずソースコードを見せてもらった。

…結果、絶句。 本当に仕組みを0から作ってやがる。
SELECT・FROMといったSQLの要素を引数で渡し、それを元にJava標準のStatementやResultSetを使用してDBアクセス、SELECT文であれば検索結果をHashMap（の配列）で返すといった仕組みだ。
前述の1.のDBアクセスクラスと、内容どんがぶりである。激しく無意味だ。そして、無意味なだけでなく、致命的な問題点も含んでいる。

• 致命的な問題
  • 顧客の要件を満たせない（ログ出力等）
  • PreparedStatement使用していないので、SQLインジェクション脆弱性が存在！
• 致命的では無いが…
  • インターフェイスをテーブル単位で作成する必要があるなど、クラス数が増大する。 今までのやり方と異なる事もあり、顧客からクレームが来る可能性大。
    ※フレームワーク標準のDBアクセスクラスは、DB情報は設定ファイルから取得するので、このような余計なクラスは不要。
  • SQLの要素を渡す手段が引数だと、その組合せの数だけ引数違いのメソッドを用意しなければならない。
    ※SELECT、FROM以外は必須じゃないからね。必要無い場合はNULLで渡すなんてイケてないし。
  • そもそも、この仕組みで行えることは、フレームワーク標準のDBアクセスクラスで全て実現可能。しかも、より簡単かつスマートに。

PreparedStatement使ってないのは本当にビックリした。『いろはのい』だぞ？何年やってんだ…
上述の通り、採用できないのは明らか。加えて、そもそも既にこれに関してはフィックス済みで、その決定内容で製造フェーズが開始されてしまっている。このような案があるなら、何故事前に連絡をくれなかったのか？
そのような事も添えて、この仕組みは採用できない旨をメール送信。ここでも「意見があれば言ってください。」の一文と共に。結果、「了解した」との素っ気ない返事。ちょっとイラっとしたが、取り敢えず一件落着…と思っていた…

そのような遣り取りがあった次の週、我が社では珍しく（というか恐らく初の）コードレビューが実施された。 そこで明らかされたのは、開発者間打合せ、上記のようなメールの遣り取りを経たにもかかわらず、決定事項が守られていないという現実…しかも、6人中3人も。

思ってた以上に長くなったので、エントリ分ける。つづく。

＊

ちなみにCoccoで一番好きな曲は『寓話。』です。

オラ、焼け野原しんのすけだゾ！ その１ 基本設計＝画面「のみ」設計？

「『燃えない』ゴミの収集日、何でよりにもよって火曜日やねん！」
～ by 千原ジュニア at 人志松本のゆるせない話

あー疲れた。かねてから述べていたプチ炎上プロジェクトがようやく鎮火した（まだ燻ってはいるが）。これでやっと開発フェーズは完了となった。

さて、プロジェクトが一段落ついたら、KPT方式などでふりかえりを行い、仕事をカイゼンしていくといった活動を普通は行うものなのだが…うちの会社はさにあらず。正確に言うと、その文化は全く無いわけではないのだが、弱い。実際、今回のプロジェクトでは実施されていない。プロジェクトが炎上したにもかかわらず、である。プロジェクトが大成功したわけでもないのに、である（てか、成功したとしても必要だ）。

今回のプロジェクトの炎上原因は、見積もりが甘かったとか要件肥大化したなど、よくありがちな要因によるところもあるのだが、最大の原因は、そもそも仕事の進め方・考え方が根本的に間違っていたことである気がしてならない。いや、「気がする」ではなく「間違っている」と断言できる自信はある。
しかし前述の通りふりかえりは行われず。そして（あまり言いたくないけど）周りは殆ど職業プログラマばかりで、議論をして進言して現状を変えていこうという気概のある者がいない…

というわけで、自ブログにて1人でひっそりとふりかえりを行うことにした。
問題の雲散霧消を防ぐためにも、そして自分の考えが本当に正しいかどうかを記録に残しておくためにも。そのうち@IT会議室とかに投稿して、集合知の意見を聞いてみようと思う。

• Problem1：基本設計＝画面「のみ」設計であるという認識
• Problem2：メンバーの成長のために仕事を任せるのは良いが、その仕事に必要な準備・情報が全然足りていない。
  
• Problem3：そんな状態なので、当然いろいろと意見を述べた所、マネージャーは「（悪い意味での）思ってた通りの反応だ！」「もう知らん！」ってな具合になったらしい。
• Problem4：では一体何がいけなかったのか、どう進めていくべきだったのかなどの、フォロー・フィードバックが結局無い。
  ※3の件は、マネージャと同じフロアで仕事していた人から、プロジェクト完了『1ヶ月後』に聞いた。

私が参画したのは詳細設計フェーズから。詳細設計を行うにあたり渡された資料は、画面イメージHTML『のみ』。入出力項目定義や業務フローの資料は一切無い。ER図は一応あったものの、テーブル・フィールド・リレーションどれをとっても明らかに不足しており、明らかに未完成だ。
料理を作るのに、完成図だけ見せて「これ作って」と言われても、何を望んでいるかが分からなければ、お口に合うものなど作れるわけがない。お客さんはどんな料理を欲しているのか、どんな材料を使うのか、そういう情報が必要だ。

基本設計書の有無・DB設計の状況をマネージャーに確認したところ、彼はこう言い切った。
「基本設計工程では、画面『のみ』を設計する。業務フローなどは詳細設計フェーズで行うことだ。」
「テーブル設計も詳細設計と並行して行う」
いやいや、その認識、絶対間違ってると思うんですけど！？
…まあ、よかろう。認識間違いはとりあえず置いておくとして、要は我々に『一般的な意味』での『基本設計』をさせようということですね？ それならそれで問題が多々あります。マネージャー・リーダー陣は「この進め方で問題あるなら伝えてください」と言っているので、以下のような事を伝えた。

• 今回実現する要件を纏めた資料が見つからない。今ある要件定義書は、元々の肥大化しすぎた状態のまま。これでは、我々は結局どういったものを作ればよいかが分からない。
  ※今回のプロジェクトは、元々大手ベンダーが要件定義を行なっていたが、肥大化しすぎて見積金額が膨大となりお客さんが怒ってしまったので、（単価の安い）私の会社が引き継ぎ、要件は取捨選択することとなった。
• 機能毎（詳細設計の単位）で各人がDB設計を行うやり方だと、DB定義に矛盾や重複などが発生する可能性大。
  また、重要度が低い機能は、他の機能の製造・テスト完了後に詳細設計を行う予定となっている。これでは低重要度機能の詳細設計時、その機能の都合でDB定義が変更される可能性があり、もし発生した場合、当然影響範囲の機能の手戻り修正が発生する。これは凄く非効率。
  せめて『DB設計』というサブフェーズを設け、そこで一斉に行うべき。
• そもそも工数が足りていない。『基本設計』も行わせるのなら、それ用の工数も盛り込んでおいてもらわないと困る。

で、マネージャー陣からの回答。

• 「元々の要件定義書から自分で考えること。不明点は質問してくれれば対応する。」
• 「DB定義に関しては、矛盾が生じないように、ちゃんと開発者間で話し合うこと」

…うーん、やっぱり何か違うと思うが。 時間が潤沢にあるなら、もちろん勉強になるので全然こんなやり方でも良いのだが。 てか、やっぱり工数に関しては何にも無しか。

そういうわけで、進め方に関していろいろと意見を述べてたら、前述のProblem3発生ですよ。プロジェクト中は全く知る由も無かったけど。

また要件に関しては、「要件に関しての不明点は質問しろ」と言っているので、（もちろん、ちゃんと考える事を行った上で）遠慮無く質問投げていると、いつしか
「詳細設計レビューでまとめて回答する」
との流れに。いやいや、詳細設計行うのに必要な情報を尋ねているのに、回答が詳細設計完了後に行う工程て… 結果、詳細設計レビューは、（マネージャー陣に対する）要件の確認から始まったため、殆どの機能で1人日を超える工数を消費。そしてそれだけ時間をかけてレビューを行っても、要件漏れ多発。これまたマネージャー陣の『頭の中』にしか無かったもの大半。特にエラーチェック。どういう場合にエラーにするかなんて、要件定義書も概要設計書も無く、お客さんと遣り取りする権限も無いのに、分かるかっ！！
またDB設計も案の定、フェーズ後半で詳細設計着手した機能の都合でそれまでのDB定義が変更され、テスト完了済みの機能で手戻り発生…

＊

このマネージャー、今までもずっとこんなやり方をしてきたのだろうか。だとすれば、よく今までやってこれたなと、逆の意味で感心した次第である。 僕の認識では、以下の設計は基本設計工程で行うものだと思っている。

• 業務フロー作成
• 画面設計（入出力項目定義、画面遷移）
• DB設計

分かり切ってはいるものの一応ネット等で改めて調べてみたところ、僕の認識は間違ってはないと思う。V字モデルでは、総合テストは基本設計と対応するとされているし。これに準じた場合、うちの会社の定義の基本設計だと、総合テストのテストケースは画面レイアウトの確認だけとなってしまう。そんなバカな話があるか。

＊

さて、では上記Problemを解決するためにTryしなければならないことは一体何なのか。

• Try1：システム開発に関して勉強し直してください。もうホントに根本的に間違ってるから。
• Try2：必要な情報を準備してくださいとしか言いようがありません。
  錬金術師をもってしても、『無』から『有』を作り出すことはできません。
  
• Try3：
  Try4：
  何故『見限る』ということになるのか、およそ管理職らしからぬ行動は全く理解できません。我々に不備があったのならば、それを指摘・叱責するなどしてフィードバックしてくださいよ。
  これでは、我々も会社も成長できませんよ。
  

＊

↓大人が観ても面白いと、松本・高須がラジオで絶賛してた作品

僕歪黄金号～世界を動かすもの Vol.2

気がつけば黄金週間も終わり。
仕事プチ炎上によりほったらかしとなっていた、年度末辺りの小話その２。

＊

3D映画『アバター』を見た人の75％は“満足”

アバター、観てないのですが。ていうか、ここ数年そもそも映画は全くといっていいほど観ていない（松本人志作品以外は）。最後に観たのは確か『ダンサー・イン・ザ・ダーク』だ。あれはホント良かった、うん。これって何年の作品だ？2000年！？マジで！？

観たい映画は一応それなりに存在する。最近気にしているのは是枝裕和やら想田和弘やら塚本晋也やら、2次元だと押井守とか『クレヨンしんちゃん』の大人帝国・戦国とか（こうしてみると洋画はあんまり興味ないのか？俺）。気になった作品は忘れないようブックマークしているのだが…時間が足りない。松本人志の番組DVDの消化すら追っついていないし。あ、上記リンク先エントリ見て思い出したが、こたついらずの季節となったことだし、キーボードの練習も再開しなくては。さらに今年はキャリアチェンジも考えているので、それの勉強もしなきゃならない。これでは益々映画鑑賞どころではない。

映画鑑賞の習慣が無いことが影響してか、AV機器に対するこだわりは薄い。IPアドレス枯渇とランデブーなアナログTVのXデーがいつの間にか来年に迫っているが、我が家では未だに「ブゥ～ン」と唸るメタボブラウン管式だ。別に、笑ってはいけないシリーズをデジタル高画質で観る必要ないし、すべらない話をドルビーデジタル5.1chで聴いたってしょうがない。最低限のAVが確保できればそれで十分なのだ。

ところで、冒頭の記事では「3D映画で見たい映画のジャンルは何ですか？」という世論調査の回答も載っている。以下、引用。

最も多かったのは「SF・ファンタジー」（68.0％）だった。このほか「アクション」（57.8％）、「アドベンチャー」（43.3％）、「ホラー」（21.7％）と映画の迫力、リアル感などが求められる映画のジャンルが上位を占めた。

上記世論調査は『映画のジャンル』と絞ったため上記のような結果となったが、映像作品全般に対象を広げた場合、1位は断トツで『エロ』だろう。人類の歴史を創ってきた原動力であるその力は計り知れない。あのATOK、Googleですらこの通りだ。

ちなみに私、「AV機器に対するこだわり薄い」と前述したが、思春期の頃は全く異なり、画質へのこだわりは半端なかった。ビデオデッキ・テープは高級な物を使用（19ミクロンヘッド、S-VHS等。つってもティーンエジャーの財力では限界があるが）、テープの劣化を防ぐために真空BOXや除湿器購入（財力的限界により実現には至らず）、エロ番組のアンテナ受信感度向上を図ってのブースター搭載（これも財力…）etcetc
あのパワーは一体何だったんだ。

え、何？エロDVD60本超所持しているくらい好きなくせに、画質へのこだわり無いんですかだって？お答えします。DVD、画質良すぎ！安物プレーヤーで観ても、ちょっとした肌の荒れ・シミや毛穴の黒ずみとかも識別できてしまうなんて、優秀すぎ。時にはそれで萎えてしまう事があるので、むしろ少し画質落としてほしいくらいだ（賛同者は多いと思う）。今となっては、VHSの頃の画質がちょうどよかったとの感慨をいだいている。最近はエロBlu-rayも出始めているが、DVD以上の高画質、果たして必要なのだろうか？

そういうわけで、エロ映像の3D化は是非実現して欲しいのだが、肌荒れなどを緻密に表現するレベルの画質は、私としては不要です。

※60本超所持は確かに多いかもしれないが、私はレンタルや違法ダウンロードを一切利用しないので、鑑賞本数ではむしろ少ない方だと自負しているが、実際どうなんでしょう。

＊

その昔、ホームシアターの巨大スクリーンでエロビデオを鑑賞した際に放たれたとされる、島田紳助の名言

「みんな巨乳や」

僕歪黄金号～坊主麻薬説

気がつけば5月。
仕事プチ炎上によりほったらかしとなっていた、年度末辺りの小話その１。

＊

“不衛生”と指摘され……安くて早い「1000円散髪店」がピンチ

10分1000円カットで知られる散髪店が、ピンチに立たされている。業界団体からの「不衛生だ」という指摘を受け、店内の洗髪台設置を義務づける条例改正を行う自治体が続出。
…
「苦情を口実に専門店の新規出店を妨害しようとしているとしか思えません」
「値上げとなれば、お客さまは大迷惑でしょう。誰のための条例改正なのか分かりませんね」

20代男性の4人に1人が髪の悩みを抱いている昨今、皆様どのようなヘアライフをお過ごしでしょうか？私はと言いますと、快適ノンストレスヘアライフを謳歌しております。といいますのは、数年前に『坊主』と言われるテラインコグニタに勇気をもって踏み出したところ、そこはユートピアであることが判明し、以来それ以前までおりましたディストピアに戻ってこられないのです。ていうか、テラインコグニタとディストピアという言葉を使いたかっただけです。

まあ、坊主にした理由は、額のベジータ化によりどう頑張っても格好良く決まらないからという、結局僕も前述の4人に1人な訳ですが。
※松本人志が『プレイ坊主』で語った『坊主にした真意』を聞いて憧憬・触発を受けたというのもあるが。

しっかし坊主は本当に楽だ。日常のストレスが確実に一つ減るからね（しかも結構でかいストレスが）。風呂上がりの手入れも寝癖直しも日中のメンテナンスも不要。一度踏み出したらもう戻れない、ホント麻薬みたいなものです。『楽』という漢字が『薬』と似ているのにも納得だ。

唯一の欠点は、リンスが中々減らないことくらいか。てか全く使わないので、厳密には『中々』ではなく『全然』ですが（ちなみに坊主でもシャンプーは必須ですよ。脂落とさなきゃいけないんで）。ということで、余ったリンスをどうするかで数年悩んでいる（厳密には気にも掛けずにほったらかし）。使いかけのリンスを人に贈るわけにもいかないし。そうだ、ならば残っている毛に対して利用すればよいではないか！…否、陰毛サラサラにしたってしょうがない。松本人志が言ってたではないか、「年取ると陰毛がサラサラになる。陰毛がサラサラになると竿に巻き付いて鬱陶しい！」と。
他には、ドライヤー、こだわり抜いて選んだマイナスイオンヘアブラシとか…どうすっぺ。

はい？冒頭で引用した1000円床屋存続の危機に対しての意見だって？
はいはい述べますよ。一言で言うと
「自分で刈ってるから関係ねー」
ご無礼しました。本当は「既得権益者っていやーねー」です。まあ薄いことに変わりはありませんが。髪だけに。
こういう時事ネタ切りは、三流プログラマの意見なんかよりも、アルファブロガーのちきりん氏の意見を参照してください。

• 事件は会議室で起きている
• “何が”問題なのか

＜後記＞
てか、余ったリンスの活用法なんてググれって話か。調べてみたら拭き掃除に使えるそうです。

• リンスの再利用?について

＊

↓松本人志が坊主にした真意を語っている

僕なりに波紋は起こしているつもりなので、今はご容赦…

～孫正義 LIVE 2011～

世の中が悪いとか、政治家が悪いとか、景気が悪いとか、そんな言い訳を言うとったんじゃ、そんな愚痴を言うとったんじゃ、しゃあないぜよ。

愚痴を言ったら、自分の器を小さくする。

愚痴なんか言うとっても、なんも世の中ようならん。

愚痴を言う暇があったら、自分ひとりの命でもいいから、命を投げ捨てる覚悟があれば、波紋は起きはじめるということです。

3月の終わり、上司と年度末の面談を行った。2009年度の目標管理の実施結果の確認や、会社に対する質問・意見などを伝える場である。新年号その２でお伝えしたが、今年から我が社はクラウド（Google App Engine）及びAndroidに力を入れるとのことなのだが、仕事が無くて自社で待機状態となっている同期に聞いたところ、それらの勉強や研究を（会社レベルで）全く行っている様子が無いとのことなので、実施計画・本気で取り組む気があるのか？等を尋ねた。すると、上司曰く
「そもそも『クラウド』とか『Android』って何なの？」
…ご存じありませんでした。
他には、2009年度目標に「簿記資格を取得」を掲げていたことと絡めて『IFRS』を口にしたところ、上司曰く
「それってLinuxの資格試験だっけ？」
…それはLPICです。
こんな感じだったので、RIAの話もしたかったのだが、これ以上ストレス溜めたくないので引っ込めた…

どの用語もトレンドで、浅い内容ならITニュースを斜め読みしてれば猿でも知ることができると思うし、しかもこの先IT業界で食っていくには避けては通れないものなのだけど、この現実、マジか！？これからの厳しい時代に我々PGを率いていくPL・Mgrという立場の人間が、業界の動向を全く分かっていないというこの現実は。そしてさらに絶望的なのは、私と同じ現役バリバリのPGやSEという立場の人間に関しても同様であるということ。少なくとも、私の知る範囲では。

証券マンであれば株式などの動向をチェックするだろうし、
モデルであれば規則正しい食生活・寝起きを心掛けるだろうし、
スポーツ選手であれば肉体維持のためのトレーニング・栄養管理を行う。
それと同様に、IT業界に身を置くのであれば、技術動向のチェックは最低限の義務だろう。しかも、ただでさえ技術の移り変わりは早く、他の業種よりもたくさんの勉強が必要と言われるくらいなのだから…

何で勉強しないのだろうか。1秒でも多く、プライベートの時間を確保したいからなのだろうか。
であれば、なおさら勉強するべきだと僕は思う。
『一番効率的に人生を送りたいのなら、程々に勉強することだ』というのが持論だ。
全く勉強しない場合、見かけ上は勉強する場合と比べて自由時間をより多く確保できるように見えるが、実際は違ってくると思う。例えば毎日1時間勉強すれば、単純計算ではプライベートの時間が1時間減ってしまうが、勉強の効果で仕事の効率は確実に向上し、きっといつか必ず1時間以上早く仕事が仕上がるようになり、時間の元は取れると思う。当然スキル・成果物の品質も上がるし、それに伴い評価も上がることだろう。
かといって勉強やりすぎるのは精神衛生上よろしくない（勉強が好きで堪らないのであれば話は別だが）。

と言うわけで、程々に勉強するのがベストだと私は思う。
所帯持ちの場合、勉強する暇があったら家族サービスに費やしたいのだろうが、勉強していつ会社が潰れてもすぐ仕事見つけられるくらいの力をつけておき、家族を安心させておくこと、それが一番の家族サービスでは？

まあ、現実はスキルをつけて早く仕事を終えたところで、他人の尻拭いさせられるのが常ですが…これが評価（具体的には給与）に反映されていればそれでもいいのだが、少なくともうちの会社には『生産性』や『ソースコードの品質』という評価指標は無いようだ（あるかもしれないが、実感できない）。

＊

はぁー…また愚痴ってしまった。冒頭の孫社長の言葉は仰る通りで、自分でもイケてないのは重々承知の上だ。ただ、私は何も改善しようとせずに全てを周りのせいにしている訳ではない。私なりに波紋を起こしてきた上で、IT技術者としての義務を放棄して『志』も見受けられないような者に対して愚痴っているのです。
そういうこともあり、内に溜めておくのは精神衛生上宜しくないということもあるので、今は勘弁してください…
ソフトバンクの純有利子負債と同様に、2014年度まではゼロにしますので…

＊

↓波紋といったらこれだけど、スタンド登場でお役御免

痔 1st Anniversary

あー忙しい。もう3月も終わりか。
今年こそはスキルアップし、勉強会に参加して人脈拡大、そして転職して収入アップ、最終的にはカレーの肉を鶏胸肉からビーフへ…という野望を打ち立てていたが、既に頓挫気味だ。殆ど何もできていない。仕事がプチ炎上気味で帰りが遅いので、基本的に平日は自由時間が殆どあらず、帰宅後は風呂入って寝るだけ。ノー残業デイや休日は気晴らし・未読RSS消化で精一杯、とても勉強する気にならん。春の情報処理技術者試験（データベーススペシャリスト）の勉強も全く着手できていない。くそ。

それでも一応技術を扱う仕事をしているので、普通に働いていれば確実にスキルは上がるものの、扱っている技術が如何せんマイナー、汎用的に使えるスキルの上がりペースは豚足だ。

そんなこんなでとにかく忙しく、1秒でも多く自由時間を確保したいこともあり、先月から平日の食事は3食全て常駐先の社食で摂取している。切り替えてから約2ヶ月が経とうとしているが、何なんでしょう、この体の快調ぶりは。何なんでしょう、このお肌のハリと潤いは。どうやら、私の作る料理とは栄養バランスがダンチでいいようだ。全く、忙しいほど健康体とは、何という皮肉か。

そういう訳で、自炊は休日にしか行っていないのだが、この2ヶ月はニンニクを多用している。『ニンニク注射』でより有名になった『疲労軽減』効果を期待して（しかも安いし。3玉100円）。
で、効果は出ているのかというと正直わからないが、とにかく体が臭い。摂取したその日は当然のこと、次の日の大体昼過ぎまで、汗や皮脂といった分泌物は漏れなくニンニク臭い。ニンニクを剥き剥きするため一番触れあうことになる指先に至っては、次の週の水曜日くらいまで匂いが完全に取れん。
何度、自分にファブリーズを振りまこうと思ったことか。

ところで、『ニンニクを食べ過ぎると鼻血が出る』という話をよく聞く。
今のところ鼻からは出ていないが、メンズにもかかわらず股から出ている。いわゆるアーナルー（『オードリー』と同じ抑揚で！）から大量発生している。先週は過去最大規模のものが発生、便器の筋がまるでベーコンのようであった。

＊

気付けば先週、いつの間にか誕生日を迎えていた。
ちなみに昨年の誕生日は…同じだ。病院でおっさんに指を突っ込まれてたではないか。
1周年の出血大サービスってか？大きなお世話だ！

＜余談＞
白いパンツ履くと便通UP、ピンクだと性欲UPするとかいう話も聞いたことあるが（松本人志あたりの冗談話だったかもしれんが）、同じような理屈で
『赤いパンツ履くと痔DOWN』
というのはないのだろうか？「あれ？俺、もう出てるじゃん！」という具合で血が引っ込むみたいな。
…失敬な！パンツに付着してたことなど今まで無いわ！

Money, Money, Money～郵政 イズ ザ グレート

前回、グレーゾーン金利絡みの話をさせていただいたが、それにまつわる話を少々（厳密には無理矢理まつわらせたのであるが）。

＊

2009年末、郵便局に定額小為替を購入しに行った。
何でかというのは↓のプレゼント応募に必要だったので。


必要になるのは300円券なのだが、発券手数料が何と100円！
手数料は全券一律らしいが、300円券の場合だと利率は実に33%！せこい商売しやがって。
グレーゾーン金利なんて可愛いもんじゃねぇか。

ところで今月、前述のプレゼントが届いた。正直、好きなのは松本人志の『作品』であり、グッズとかの類にはそれ程思い入れはないのであるが、前回・前々回と異なり事前にプレゼント内容が明かされていなかったので、まあそれなりに楽しみにしていた。で、その内容はと言うと…

クリアファイルと

オリジナルのスポーツ新聞

…しょ、しょぼいぞ！

ガキの使いDVDは売れている筈だから（実際『300万枚突破記念！』とか謳ってるし）、景気は悪くはない筈だが…プログラマには想像もつかないコストの法則でも渦巻いているのだろうか？

余談１

上記のスポーツ新聞に記載されていた、ココリコ遠藤のバカエピソードが面白かったので抜粋。

英語教師「『I live in Tokyo』を過去形にしなさい」
遠藤　　「『I live in Edo』」

余談２

てか、写真の画質が凄え。去年の夏とはダンチだ。
今年頭にケータイの機種変更を行ったのだが、3年以上前に購入した1円ケータイとはかくも違うか、世界のiidaよ。

Money, Money, Money～灰色地帯

「払いすぎた利息を取りもどそう」「着手金不要で完全成功報酬」――。

弁護士業界にとって、過払い金請求は「ビジネスチャンス」だ。
公正取引委員会の後押しで、弁護士や司法書士の手数料報酬や広告規制が近年、相次いで自由化されたことも追い風となり、法律事務所の間で競争が激化している。

いつの頃からか、郵便ポストに「借金問題解決します」「払いすぎたお金を取り戻しましょう！」といった冊子が投函される事が増えた。現在も週一くらいのペースで投函される。
所謂グレーゾーン金利撤廃によるムーブメントであるが、こういったチラシを見る度にこう思う。
「金利に関して理解・合意した上で借りたのだから、払うのは当たり前なんじゃないの？返還求めるのは筋違いなんじゃないの？」と。
契約書に記載されていた利息以上に払わされたというなら妥当な行動だけど。
…って、まあ皆言ってる事ですが。

強引な取り立てだとかが辛いというのは分かるが、もし強引でなかったとしたら「あそこの業者、返さなくても大して何もしてこないぞ」と舐めて開き直る輩が出てくるのは目に見えているので、ある程度強く出ざるを得ないのはしょうがない。

27歳にして手取りはぶっちゃけ17万という状況の中、勝間和代もびっくりの効率的やりくりで何とか生き延びている僕としては、昨今の過払い金返還請求ブームは何か間違っている・歪んでいる気がするのです。
※その癖家賃9.1万の部屋に住み続けている俺も十分歪んでいるぞ！てかホントよくやりくりできてるな…

ところで本日もまた新たな冊子が投函されていたのだが、今回の事例はひどかった。

• デート資金が足りなくてア○ムで10万円を借りたのがきっかけで気がつくと100万円まで膨み…
• バブル当時に消費者金融やキャッシングを利用して豪遊したことが災いし…

会社を回すための資金とかいうならいざ知らず（前述の通りそれでも駄目だと思うけど）、完全なる『遊ぶ金』じゃねぇか。腹立ってしょうがない。

そんな腹立つチラシだったが、ちょっとほろっとくる言葉が書いてあったので、引用させていただきます。ソースは2ちゃんとのこと。

10年後にはきっと、せめて10年でいいから
戻ってやり直したいと思っているのだろう。
今やり直せよ。未来を。
10年後か、20年後か、50年後から戻ってきたんだよ今。

総量規制を始めとする、改正貸金業法による規制強化。これにより借金重ねて自己破産や犯罪に走る輩が減り、真面目に働こうとする人間が増えるのだろうかと思いきや、ヤミ金が増えるとか言われてるし…どうなる、日本。

僕歪週末号～ホワイトデーらしく『死』まつわるエトセトラ

呪いの音楽、夜聴いたらトイレに行けなかった包茎時代

あー忙しい。仕事がプチ炎上気味だ。プロジェクトメンバーの何人かは昨日も出勤したらしい（僕は何とか回避できたが）。昨年から何度も嘆いていた通りとなってしまった。くそ、分かっていながらこうなるとは…

そんな状況で迎えた3月、プロジェクトメンバー曰く「忙しくてドラクエする暇が無い」。
え！？また出たの！？


ゲームは高校卒業してから殆どしなくなったので動向には疎いのだが、ドラクエはここんとこしょっちゅう発売のニュースを聞いている気がするんですけど。

ドラクエか。ドラクエでプレイしたのはファミコン版のⅢのみ。
ある日電源を入れると、おどろおどろしい音楽と共に黒地の画面に映し出される「おきのどくですが…」の文字。そう、『呪いの音楽』である。そう、データが死んだのだ。こればかりは神父でも生き返らせる事はできない。
それまでの努力が水泡と帰す事を何度も経験して嫌気がさし、それ以来は他人のプレイを観てるだけのドラクエ人生である。

ところで、男の子なら誰しも一度は勇者をこう名付けたであろう。
『うんこす』と。

※ちなみに戦士は『おといれ』だったけな。

『オーラの泉』って観たこと無いけど

3月に入って間もない頃、夢に美輪明宏が出現した。夢の中の僕は、どうやらカウンセリングを受けているらしい。そして僕は美輪に向かってこう言った。
「そう言えば、昨日夢に江原さんが出てきたんですよ！」

他に何を話したのかは覚えていない。
兎に角、夢の中の僕は夢の中で江原啓之に会ったらしい。
この夢の意味する所は一体何なんだ？年度初めなら「今年度は何かが起こるのか！？」と言うような期待を抱く事ができるかもしれないが、年度末中の末だぞ。

ちなみにその夢を見た週、そうそう遭遇する事はない出来事多々発生。

1. 行きつけのスーパーで買い物したら、合計金額がちょうど1000円。
2. すき家で牛丼食ってお代払ったら、小銭がちょうどすっからかんに。
3. 久しぶりの半休でウキウキ気分で帰宅した時に限って、自宅マンションのエレベータ点検日（我が部屋は4F）

しょうもないとは言え、これらの事象の意味する所は一体何なのだ？

Trac野郎、散る

自宅PCのTracが死んだ。動的ページにアクセスすると500エラーが発生してしまう。プラグインいろいろ入れたり消したりしてた時、消してはいけないものも消してしまったのだろうか？情けなさ過ぎる…

取り敢えずインストーラを再ダウンロードして上書きインストールしてみたが、変わらず。
結局再インストールした。

ところで、2月はいろいろとTracに関するエントリばかり書いてきたが、情けない話ぶっちゃけネタ切れ。。。

取り敢えず現在模索中なのは以下。

• ログファイルのローテーション方法。1ヶ月の運用で、数GBに膨れあがっていた。
• チケットの内容変更・コメント追記時、そのチケットが属するカスタムクエリ・レポートのRSSを飛ばしたい
• カスタムクエリ・レポートのExcelダウンロードする項目の取捨選択・並びのカスタマイズ

こいつらは多分ソースコード弄らないといけないよな。実現できたら追々書いていきます。

松本人志はどこへ行く？

松本人志第2回監督作品『しんぼる』のDVDが先月発売された。



プロフィールに書いてある通り、私は松本人志が大好きだ。プチ信者と言っていいくらいに。という訳で、一応購入。
『一応』と修飾しているのはどいういう事かというと、以前に書いた通り、兎に角全然面白くなかったからだ。おまけに釣られて前売り券2枚購入していたものの、結局1回しか行かず。

それでも『一応』購入したのは、2回目以降は面白いと感じるかもしれないとの淡い期待があったからだ。1回目はそうでもなかったけど、2回目観たら面白い、そういうのって皆さんもよくありますよね？
ちなみに今この段落の文章をタイプしていて気付いたのだが、だったらもう1枚の前売り券使って観に行けばよかったではないか、俺！

そう言う訳で、2月半ばの4連休に第2回鑑賞を行った。鑑賞したその日に立ち上げたが長らく下書き状態であったこのエントリ、やっと本日魂を吹き込む事ができた。

結論から言うと…やっぱり全然面白くなかった。ベッタベタな笑いしか含まれていない。本人が「全っ然おもんない！！」と言ってたMr. ビーンと何ら変わらない（あんまりちゃんと観たこと無いけど）。台詞が殆ど無いからずっと早送りでした。

只、僕が分からないのは世間の評価。『ごっつ』に惹かれてやってきた世代が「面白くない」と感じるのは分かるのだが、「グ～」とか「そんなの関係…（テキスト化するのもサブい）」とかを楽しめるこの世の中であれば、割と高評価となりそうな気がしたのだが（『大日本人』も然り）。実際、映画館で観た時は、周り結構笑ってたし。
※でも、唯一捻っていたと言える『マジック番組でババア消えてません』シーンは、まさに「シーン」としてたな…そしてちょっと経ってから「えっ！？」という声がちらほら。

「ドーン！」等に代表される松本の奇声が面白く感じられるのは、飽くまでディープ＆シュールな笑いの合間に見せた場合であって、ベタベタなネタの合間に連発されてもサブいだけである。所謂『一周回った笑い』というやつなのだから。

終盤の浮遊シーンは割と好きなのだが、『笑い』というカテゴリのシーンじゃないし…

＊

「人志松本の○○な話」ゴールデン進出！

「ファミリー層に“面白いこと”をお届けできるよう、頑張ります」

「ファミリー層に」とか言ってるので、プチ信者にとっては「つまらない話」になることは必至だろう。
ここまで人を変えてしまう『家庭を持つ』という事象、やはりその重みは相当なものなのだろうか。

＊

ちなみに今月、サバンナ八木の出世作『ゆるせない話』のDVDが発売。
深夜のこの頃はテロップも落ち着いてて良かったなー…

[Trac Lightning]RSS配信に関するエトセトラ

特定条件のチケットの登録通知を受信したい

カスタムクエリを作成し、そのクエリのRSSフィードを購読すればよい。

カスタムクエリの作成方法は以下の通り。

1. TracLinks
2. TicketQuery
3. 『[/query]』リンクから飛ぶ

1,2による作成方法はヘルプの『TracQuery』を参照。表示されたチケット一覧のリンクを選択すると、カスタムクエリ作成画面に飛び、画面下部にRSSフィードのリンクがある。

クエリを修正した場合は、画面真ん中辺りの『更新』ボタンを押下することをお忘れなく。

尚、カスタムクエリのRSSの場合、チケットの属性変更・返信時は配信されない。
それらの通知を受け取る方法は後述する。

チケットの属性（ステータス、進捗率etc）変更や追記・返信の通知を受信したい

チケット個別のRSSを購読する。チケット一覧から変更を追跡したいチケットを選択して詳細画面を開くと、カスタムクエリと同じく画面下部にRSSフィードのリンクがあるので、それを購読する。

この方法だと、チケットの数が増えてくるとRSSフィード一覧が大変な事になってしまうが…私はこれ以外の方法を見つけることができなかった。
他に簡単な方法をご存じの方がいらっしゃいましたら、ご教示ください。
まあ、Tracはオープンソースなので、時間ができたらソース弄りに挑戦してみるか。

フォーラムの変更通知を受信したい

タイムラインで『フォーラム changes』だけにチェックを入れた状態で『更新』を押下し、更新された画面下部のRSSフィードを購読する。

但し、通知されるのはフォーラム・トピックの新規作成や返信時のみで、本文修正や削除時は通知されない。
これもソース弄らないと無理かも。

[Trac Lightning]プラグインインストール手順＋TracWikiToPdfPlugin情報

Trac Lightningのヘルプ（TracPlugins）にも書かれてはいるが、お世辞にも分かり易い文章とは言い難く、また初心者にとっては余分？な情報も含まれている感じなので、最低限の情報をここに記録する。

ここではTracWikiToPdfPluginのインストールを例とする。

※このプラグインはその名の通りTracのWikiをPDF出力（HTML出力も可能）してくれるものである…が、我が日本語をはじめとする各種アジア言語（他にはアラブ言語）は対応していない模様…一応試してみたが、PDFは「破損してます」的なダイアログが表示され、HTMLは真っ白だった。
このプラグインの中核を担っているHTMLDOCというライブラリが、西欧言語以外のUTF-8文字に対応していないとのこと。
参考：miau's blog?：TracWiki をドキュメントに変換するプラグイン調査

０．ez_setup.pyのインストール（一度だけ）

ヘルプのリンクから『ez_setup.py』ダウンロードし、コマンドプロンプトでダウンロードフォルダに移動後、以下コマンドを実行。

python ez_setup.py

これで『easy_install.exe』が{Tracホーム}\python\Scriptsに配置される。

ちなみにpythonはTrac Lightningと同時にインストールされ、パスも通った状態となっている筈。

１．プラグインのインストール

プラグインアーカイブを適当な場所に解凍し、コマンドプロンプトで『easy_install.exe』インストールフォルダに移動し、以下コマンドを実行。

easy_install.exe {解凍ファイル内の『setup.py』格納ディレクトリのパス}

TracWikiToPdfPluginの場合、『setup.py』格納ディレクトリは「0.10」or「0.11」です。

２．trac.iniにプラグインの設定を追加

設定内容はWebなりプラグイン一式に含まれているドキュメントなりを参考に。
TracWikiToPdfPluginの場合は、docsフォルダに『trac.ini.example』というのが置いてある。

※trac.iniは以下フォルダに存在する。

{Tracホーム}\projects\trac\{プロジェクト名}\conf

３．Tracを再起動

４．プラグインを有効化

管理者アカウントでログインし、『プラグイン管理』メニューにてプラグインのコンポーネントを有効にし、『変更を適用』押下。
※２．の設定で既に有効になってるかも。


TracWikiToPdfPluginの場合は以上。まあ、前述の通り日本語対応してないのだが。
てか、試しにASCII文字だけのページを出力してみたけど、それも上手くいかんかった。分からん。

＊

プラグインファイルがeggで提供されている場合、ひょっとしたら管理コンソールからだとインストール瞬殺かもしれない。まだ試してないので結果がどうなるかは不明ですが、その内試します。



＊

アンインストール手順もヘルプに書いてある。インストール時程やることは多くなく、ヘルプの記述で十分分かるので、割愛。

[Trac Lightning]Excelの表をWikiの表として貼り付ける方法

TracのWikiにはExcelの表を貼り付けることができる。というより、Excelのセルはテーブルとして貼り付けられる。
よって、Wiki文法やWikiエディタで表を作るのが苦手な人は、Excelで作って貼り付けるようにすると効率的。

＜注意事項＞
自宅のPCにはExcel入れてないの忘れてた…
よって、当エントリはOpenOffice Calc 3.0における例となっております。ご了承ください。
尚、Excelと同じ結果となることは確認済みです。

１．まずは表作成

ちなみに「合計」右のセルは計算式（SUM関数）です。

２．Wikiの編集モードを「wysiwyg」にする

３．表をコピー

４．Wikiに貼り付け

計算式入力セルは計算結果の値がちゃんと貼り付けられる。
すげぇ！表のイメージそのまま！

…かと思いきや、編集モードを一度「textarea」にしてから再び「wysiwyg」に戻すと…

残念！流石にそこまで面倒は見てくれないか。

ところで、セルの結合をしている場合はどうなるの？

まずは行方向結合。


上端セル以外は亡き者とされている。


続いて列方向結合。


今度は左端セル以外が亡き者に。


最後に行列方向。


左上端以外は死亡。尚、セルの詰めは垂直方向が優先される模様。

セル結合した表を描くには

htmlプロセッサを使用してHTMLで表を描く

htmlプロセッサを使用すれば、Wiki内でHTMLを利用することが可能。
詳細はTracLightningヘルプの『WikiHtml』を参照してください。

{{{
#!html
<table>
…
</table>
}}}

rstプロセッサを使用してreStructuredTextで表を描く

rstプロセッサを使用すれば、Wiki内でreStructuredTextを利用することが可能。
reStructuredTextでの表の描き方は以下サイトを参照してください。

• はやわかり reStructuredText：表

rstプロセッサに関してはTracLightningヘルプの『WikiRestructuredText』を参照してください。
以下、サンプル。

{{{
#!rst
+---------+---------+---------+
| 見出し1 | 見出し2 | 見出し3 |
+=========+=========+=========+
| １－１  | １－２  | １－３  |
+---------+---------+---------+
| ２－１  | ２－２～３        |
+---------+---------+---------+
| ３－１  | ３－２  | ３－３  |
+---------+ ～      | ～      |
| ４－１  | ４－２  | ４－３  |
+---------+---------+---------+
}}}

[Trac Lightning]静的HTMLの配置場所～さらば、J2SE 1.4日本語ドキュメント

以下フォルダに配置すれば、「http://{インストールURL}/{ファイル名}」でアクセスできる。

{Tracルート}\CollabNetSVN\httpd\htdocs

ちなみに上記フォルダには「Trac Lightningについて」ページが「index.html」として置いてあります。

＊

現在の仕事では、上記フォルダにダウンロードしたJDK 1.4の日本語ドキュメントを置いています。
1.4の日本語ドキュメントは、Web上にはもういないんですよね…アーカイブページに置いてあるのは英語だし…

てか、いい加減1.5以上に携わりてぇよ！
新規開発案件なのに、今時Javaは1.4でブラウザはIE6って…

[Trac Lightning]稼働ポートを変更する際に修正する設定ファイル（過不足あるかも）

Trac LightningはApache上で稼働するのだが、稼働ポートはデフォルトで80番である。
稼働ポートを変更したい場合は、以下設定ファイルに記述されているポート番号を変更（或いはURLにポート番号を明記）する。
注：確認したバージョンは2.4.2です

ファイル名	場所	備考
hudson.scm.SubversionSCM.xml	{Tracルート} \install\hudson\.hudson\	その名の通りHudsonの何か
hudson.scm.SubversionSCM.xml	{Tracルート} \projects\hudson\.hudson\	その名の通りHudsonの何か
httpd.conf	{Tracルート} \CollabNetSVN\httpd\conf\
httpd.conf	{Tracルート}\CollabNetSVN\httpd\conf\original\
httpd-vhosts.conf	{Tracルート}\CollabNetSVN\httpd\conf\extra\	3箇所。 バーチャルホストの設定。
httpd-vhosts.conf	{Tracルート}\CollabNetSVN\httpd\conf\original\extra\	3箇所。 バーチャルホストの設定。
nginx_nginx.conf	{Tracルート} \python-lib\Pygments\tests\examplefiles\	名前からしてサンプルの何か？ 「proxy_pass」のURLにポート番号追記が必要か。

上記以外にも以下ファイルが見つかりましたが、ローカルホストを指していないっぽいので不要と判断。

ファイル名	場所	備考
settings.xml	{Tracルート}\maven\conf\	その名の通りMavenの何か。 デフォルトではコメントアウトされている。 プロキシのポート番号？
rss20.xml	{Tracルート}python-lib\feedparser\docs\examples\	名前からしてサンプルの何か？ クラウドサービスのポート番号？

ちなみに、上記ファイルを導き出した方法は、単純に以下拡張子のファイルを「80」でgrepしただけです。

• .xml
• .conf

なので、修正不要なものが含まれていたり、修正必要なものが漏れているかもしれません。
てか、Apache関連以外のファイルはそもそも何を意味するのかも分かりません。
追々勉強していきますので、今日の所はこれで勘弁してください。
URLが「localhost」「127.0.0.1」となっている部分はまず修正必須だと思いますが。

ご存知の方がおられましたらご教示いただけると幸いです。

ちなみにRedmineの本も2冊しか無い模様。

＊

今回初めてTableタグが必要になった訳だが、そういえばBloggerのエディタには表作成機能がありませんでしたね。と言うわけで、Bloggerの第一人者であるクリボウさんの記事を参考にさせて頂きました。

• Blogger で表を書く方法

＊

＜後記＞
BloggerのWYSIWYGエディタでテーブル編集時、IE8だと上記クリボウさんの記事でも紹介されている丸・三角・四角のやつが表示されないではないか。


Firefoxだと表示されるのを確認。
ちなみに、TracのWikiのWYSIWYGエディタもこれと全く同じ現象が発生します。

[Trac Lightning]移行（バックアップのリストア）手順

リストア対象のTracLightningのインストールパス（デフォルトではC:\TracLight\bin）が、バックアップ取ったTracLightningと同じの場合、バックアップしたフォルダを配置するだけでよい。バックアップ格納フォルダとリストア先は以下の通り。

• プロジェクト：backup\trac→{Tracルート}\projects\trac
• Subversionリポジトリ：backup\svn→{Tracルート}\projects\svn

上記に当てはまらない場合、つまりバックアップ取得元とリストア対象のインストールパスが異なる場合は、さらに以下の作業を行う必要がある。

１．各種設定ファイルに記述されているインストールパスの変更

最低でも以下ファイルは変更する必要有り。

• {Tracルート}\CollabNetSVN\httpd\conf\httpd.conf
• {Tracルート}\projects\trac\{プロジェクトルート}\conf\trac.ini

MavenやSSL認証等を利用している場合、これ以外も変更する必要があるかも知れない（まだ全然TracLightningしゃぶれてないので詳しくは分からん）

２．trac-admin.batの実行

コマンドプロンプトで以下コマンドを実行（Tracスタートメニューの「コマンドプロンプト」から起動するのはお約束）

C:\TracLight\bin>trac-admin.bat [プロジェクトルートのパス] resync

以上でリストア完了。
ちなみに、プロジェクト名を変更する場合も、フォルダの名称（もちろん各種設定ファイルのフォルダ名も）を変更してからリストアと同じ手順を踏めばよい。

＊

ところで先月に2.3.2→2.4.0の移行を行った。
インストールフォルダが違っていたのでresyncまでを行ったのだが、「External users」が全部「Users」に格下げされており、また登録し直し…何かミスったか？それとも元々こういうものなのか？

＜補足＞
TracやSVNを利用するには「External users」への登録が必要。「Users」では利用できない。
ちなみに、「External users」から削除したユーザーは「Users」に移る。「無効アカウント」との認識でよいのだろうか。

＊

右の本は初版がまだ残っているようなのでお間違いの無いよう。

[Trac Lightning]プロジェクト作成手順

プロジェクト作成

「Trac Lightningについて」ページにも書いてあるが、コマンドプロンプトでTracのインストールフォルダ（デフォルトではC:\TracLight）配下binフォルダ内の「create-project.bat」を実行すればよい。
Tracのスタートメニューフォルダ内の「コマンドプロンプト」から起動すると、カレントディレクトリが上記binフォルダに設定された状態で起動するので、一々cdコマンド打ち込む必要がなくて省エネ。

C:\TracLight\bin>create-project.bat [プロジェクト名]

ちなみにTraMプラグインっての使うと

ブラウザの管理コンソールから新規プロジェクトの作成ができる。
Trac Lightning 2.4.xの場合、上記プラグインはインストール済み。（参考：TraM）。



ところで、TraMで新規プロジェクト作成を試した所、以下の問題？が発生した。

ページヘッダーのロゴ画像が無い

ご覧の通り。

adminの権限が減ってる

管理コンソールを開いてみると一目瞭然である。


TraMの解説ページには「プロジェクトを作成したユーザが、作成されたプロジェクトのTRAC_ADMINに設定されます。」とあるし、実際パーミッション確認すると「TRAC_ADMIN」はちゃんと付与されているのだが…はて、何かミスったか？

というわけで、ロゴ画像やパーミッション設定の手間を少しでも減らしたいなら、コマンドプロンプトで作成しましょう。

＊

Tracの本って2冊しかないらしい…

僕歪新年号 2010～ワーク その２ UIだけでもリッチで行きたい

新年号その2。本業のプログラミングに関する目標を掲げる。

いい加減にRIAスキルを身に付けないと

今後はバックエンドのクラウド化が加速していくだろうから、フロントエンドで差別化を図らないといけないと思う。そうなると、RIAの利用は必須。只のHTML＋Javascirptでは、確実に段ボールハウス行きであろう。

しかしうちの会社、その１でも述べた通りRIAを扱った経験が全く無い。親会社の基幹システムはColdFusion 8を使っており、何ヶ月か前から再構築の話が持ち上がっていたので、そのシステム担当している同僚にFlex紹介して「Flex採用された暁には俺呼んで！」と言っておいたが、結局ERPパッケージ使う事に決定したらしい。個人的にも会社的にも残念…

ちなみに、今年年頭の挨拶で聞いた会社方針では、クラウド（Google App Engine）及びAndroidに力を入れていくとの事。ITニュースをコピペしたような内容で、具体的にどうするか、例えばクラウドなら提供する側なのか利用する側なのか、と言った事が全く見えず、行く末に不安を感じた。話が長くなるから簡単にしたのであって、具体策はこれから追々伝えていくという事であって欲しいと願うばかり。

ところで、昨年にはWindows Server 2008によるActive Directoryを導入する等、基本的にマイクロソフト文化なのに、クラウドはAzureじゃないのかよ。ちなみにGAEを選択した理由は「Javaが使える」との事らしいが。全く、相変わらず目標に一貫性がない。Azureなら、既存の.NETアプリはそのまま流用できるよな、確か。やっぱり費用の問題だな。Azureだと、Visual Studioとかのライセンス費用が発生するのがキツいのだろう、きっと。
いや、思い返してみると、マイクロソフト文化と言っても、そう言えば殆どVB6以前だった…

ちなみにここ数年力を入れていた事業は、長らくそして現在私が担当しているマイナーな商用Javaフレームワークであった。力を入れると言っておきながら、使えるレベルに達している技術者は私を含めて3人。10人作るという目標を達成せぬまま、計画終了。結局、元々信念や志があって始めたのではなく、最重要顧客がそれを使うと言い出してそれに迎合しただけだったので、こんなものだろう。

それ以前に、先ず『分割』スキルだろ

うちの会社、『分割』スキルが弱い。『MVC分割』とか『クラス分割』とか『メソッド分割』とか。一例を挙げると、JSPにロジック埋め込みまくったり、基本1画面1クラス（VB6の感覚）で作るので数千～数万行にメタボ化し、他は以前も愚痴ったように数千行のメソッド、数百行のifブロックetc…
以前、ある勉強会に参加した際、Flex開発で有名な某ベンダの方と懇親会でお話ししたのだが、「会社が中々RIA開発に移行しない」と嘆いた所「Java扱っているなら、Flexへの移行は別に難しくないですよ」とお話ししてくれた。いや、うちの会社の場合は、非常に難しいのですよ…前述の通り、JSPにロジック書いちゃったりしてるもんだから、フロントだけFlexに交換と言うことすら厳しい。そして、うちの会社の感覚では、JavaとAction Script 3.0は完全なる別言語扱いなのです。

もう一つ、適切に分割されていないと言うことは、バックエンドだけクラウドに交換する事も難しい事を意味する。私が携わっているフレームワークは、MVCなんて概念が無い（ロジックもORマッピング情報もView部品に埋め込まれているetc）。
うーむ、出航前から座礁してないか？

＊

プロジェクトの進め方を（少しだけ）変える事は何とかできたが、まだまだ課題は満載だ。
個人的なことであれば、少しでも前進しているので慌てないでコツコツ行こうぜという姿勢でもいいが、ビジネスではそうは言ってられない。果たして生き延びることができるのだろうか？

僕歪新年号 2010～ワーク その１ Trac野郎に俺はなる

もう1月も末日だというに新年号などと、相変わらずのマイペース及びKY（死語）っぷりを絶賛発揮中ですが、今年もこんな感じで人の目気にせず慌てずに生きていこうと思っています。今年もワールドカップ期間中はダウンタウン・松本人志のDVDを観ていることだろう。僕にとってワールドカップは「テレビ番組のダイヤを乱し、善良な市民を非国民へと変化させる黒ミサ」でしかないのだ。

さて、景気が底を打つと言われている2010年。今年の目標でも立てておこう。まずは仕事編。

トラックに乗ってから赤い地雷を踏みに行く

社会人4年目終盤の現在、やっと仕事が楽しくなってきた。というのは、以前のエントリで述べた通り、今回のプロジェクトから『Trac Lightning』を利用し始め、開発プロセスのChange（死語）に取り組んでいるからだ。懸念していた「面倒くせ～」といった反発もなく、むしろ積極的に利用してくれており、良い意味で拍子抜け。当初は、タスク管理・QA管理は従来通りExcelのままの予定であったが、使っている内に「1箇所で管理・参照できる方がいい」という事になり、結局それらもTrac上にご在住。
久しぶりの一次請け＆新規案件で、客先との窓口の一部等、仕事もいろいろと任せて貰えており、世間の景気とは裏腹に非常に充実している（いや、うちの会社も景気は悪いですよ。例に漏れずボーナス大幅カットだったし…）。
ちなみに現在の私の役割は、『Trac管理者』及び『PL』です。前にも言いましたが、『PL』つっても『Programmer Leader』ですけど。

2008年末にRedmine紹介した時は「機能が多すぎる」と却下（どこが多すぎるというのだ？）
2009年春のプロジェクトでは、Subversion利用するならと『Trac Lightning』を導入したが、サブちゃん以外は一切利用されず。
2009年夏、セキュリティが物凄く厳しい客先での膨大な量の入場手続き・各種申請作業の手順が一切文書化されていなかったので、トーンダウンしてWikiだけでもと導入提案したが、「Excelでいいじゃん」と却下…
※ちなみにその現場、議事録すら書く文化が無く、恐らくお客さん側の責任であろう問題も全て押しつけられ、現在炎上中…

上記以外にも、カテゴリは違うが『Adobe AIR』がまだ『Apollo』だった頃に紹介した事もあったけか。ちなみに2010年現在、うちの会社はAIRどころかFlexもSilverlightもAjaxも全く扱った事がありません…
こんな感じの超保守的な会社なので、今回の動きには大変感慨深いものがある。よくここまで辿り着いたなと（何様）。まあ、さすがにこの不景気に危機感を感じてケツに火が付いただけかもしれんが。
否、俺の意見・説得がようやっと通じたと思おうじゃないか。たまには自分を褒めようではないか。

…とは言うものの、世間的には「今更w」「遅ッ！」なんでしょうけど。
しかも、もう何年も前からTracに手を出しているような先駆者の方々に言わせると、「これから使うならRedmineの方がいい」。
これは僕も同感。まあ、Redmineもそんなに深い所まで使ったこと無いので、何となくの感想ですけど…

• プログラマの思索：RedmineとTracの機能比較part2

それでもTracを選択したのは『Trac Lightning』の簡便さには勝てなかったからなのですが、Trac導入が決定して利用ルール等を纏めて纏め終わろうかという2009年12月、まさかのRedmine簡単パックの登場。

• RedmineLE

これ以前もいくつかあったみたいだけど、どうも運用していく自信が無かったので流していたのだが、これは非常に良さ気。
「こっちの方がいいです！」と伝えたが、突然すぎるのでこれは流石に却下。まあ、今回のTrac処女喪失でまずは『見える化』開発に慣れて、「Tracでは難しいがRedmineでは簡単」というような機能要望が発生したらすぐ移行できるように準備をしておこう。

と言うわけで今年の目標その1、TracとRedmineを使いこなすってとこかな。

本業のプログラミングに関しては…長くなったのでエントリ分ける。

「明けましておめでとうございます」を「あっす」って言うのはどうだろうか？

あっす、オラおもくそ。うん、センスゼロ。

前回エントリで述べた通り、今年の年末年始はただの6連休でした。予告通り、年越しは風呂場で迎えました。どの部分を洗ってたかまでは流石に把握できてませんが。風呂から上がったら初詣に行くこともなく引き続き『海辺のカフカ』を読み、2時頃就寝。

元日もいつもの休日の如く洗濯物を干し、引き続き『海辺のカフカ』を読んで読書スピードの調子が悪いことに落ち込み、録り溜めしていた松本人志の番組を鑑賞する…
午後、「お前は一人でも生きていけるよ」と高校の頃言われる程マイペースな僕でも、流石にこれでは味気なさすぎて悲しくなったので、ちょっと年末年始に肖る事を決意。昼食は香川県の陰謀『年明けうどん』にしてみました。

麻婆うどんです

まあぶっちゃけた話、いつもの休日もこれ食ってるので、結局いつもの休日の一コマじゃねぇかと嘆くことになりましたが。
あ、そう言えば、大晦日は除夜の鐘に肖って腹筋を108回やってたっけな。5セットに分けて1日かけて。

2日は実家暮らしの会社の同僚とマルイのバーゲンに出かけた。携帯弄りながら歩いてる子持ち女のベビーカーが俺の足にガツンガツン当たる事に少しイラッとしたり、購入を決めたジーパンの裾丈がデフォルトぴったんこで調整不要であることで店員さんが「基本裾は長めに作られているので、ぴったしってことは足長いってことですよ～」と言われてデヘヘヘとなったり。帰りはブックオフに寄って、タイトルでずっと気になっていた『最終兵器彼女』を立ち読み。3巻まで読んでみて、ふむ、悪くないな。次週のスケジュールに残り巻消化を追加。
ちなみに『足長デヘヘヘ』の件がこの年末年始のピークでした。

3日は全くいつもの休日。初詣のお誘いがあったが断った。初詣は4日に行くことにしているので。何でかは次の段落参照。

4日。前段落の予告通り、初詣に出かける。4日している理由は、僕のラッキーナンバーが4だからというのと、「今年こそはいよいよ（14）飛躍するぞ！」という意志を込めて。…まあこの程度ですよ、人間なんて。
毎年願い事する時は事前に何も考えず、咄嗟に思いついた事を願うことにしているのだが、今年の願いは…
「同期のT君が不治の病でありませんように！」
ちょっと自分でもビックリした。
僕の同期には不治の病の疑いがある人間がいます（以前のエントリで出てきた『ホワイティ』）。命に別状は無いけど、失明するとの事。それもキツい…
てか、同期の仲良し4人組の中で、不治の病が2人いるんですけど（ホワイティは前述の通りまだ確定ではないですが）。不治の病って、こんなに蔓延してるものなのか？
ちなみに残り1人はそういった疾患とかは抱えていないが、仕事は某ブラック会社の担当で、結構肉体的精神的にヤバイらしい（ちなみに、うちの会社はブラックではないです。けど…）。

そいつらと一緒にいると、俺自身は特に神頼みしたくなるような切羽詰まった事は無く、幸せな方なんだなと本当に思う。当ブログで散々愚痴っている仕事の事も、別に俺が頑張れば何とかできるレベルのものだろうし、最悪転職すればいいし。マンションの隣人が深夜うるさいので度々注意してるが、完全に俺の事舐めてやがるようで、一旦大人しくなってもやがては再発する事も、まあ…イラつくけど生き死に係るような問題じゃないし、ムカつくけど耳栓すれば回避できるレベルだし、最悪引っ越せばいいし（そろそろ引っ越そうかと思っているし）。

そういった深層心理から出た願いだったのかな。ただ、
「自分の願いを棚上げして友人の無事を願っているこんな私ってどうですか？神様！」
と、結局見返りを期待している邪心が少なからず存在していたのを否定できないのが悲しい。
まだそこまで解脱できない弱い人間です。