CentOS で古いカーネルを掃除する

開発環境(CentOS6系)で何も考えずにカーネルをアップデートし続けていたら、ずいぶんと古いバージョンのカーネルが溜まっていた。
何だか今日はお掃除したい気分だったので、いい掃除道具がないかとググッたら、欲しいものズバリの package-cleanup というツールがあった。

package-cleanup は yum-utils にあるとのことなので、インストール。

# yum install yum-utils

後は --oldkernels をつけて、package-cleanup をたたくだけ。

# package-cleanup --oldkernels
Loaded plugins: fastestmirror, presto
Repository pgdg92 is listed more than once in the configuration
Repository pgdg92-source is listed more than once in the configuration
Loading mirror speeds from cached hostfile
* base: ftp.iij.ad.jp
* epel: ftp.iij.ad.jp
* extras: ftp.iij.ad.jp
* updates: ftp.iij.ad.jp
--> Running transaction check
---> Package kernel.i686 0:2.6.32-279.el6 will be erased
---> Package kernel.i686 0:2.6.32-279.11.1.el6 will be erased
---> Package kernel.i686 0:2.6.32-279.14.1.el6 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

=====================================================================================Package Arch Version Repository Size
=====================================================================================Removing:
kernel i686 2.6.32-279.el6 @anaconda-CentOS-201207051201.i386/6.3 84 M
kernel i686 2.6.32-279.11.1.el6 @updates 84 M
kernel i686 2.6.32-279.14.1.el6 @updates 84 M

Transaction Summary
================================================================================================================================================================
Remove 3 Package(s)

Installed size: 252 M
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Erasing : kernel.i686 1/3
Erasing : kernel.i686 2/3
Erasing : kernel.i686 3/3
Verifying : kernel-2.6.32-279.11.1.el6.i686 1/3
Verifying : kernel-2.6.32-279.14.1.el6.i686 2/3
Verifying : kernel-2.6.32-279.el6.i686 3/3

Removed:
kernel.i686 0:2.6.32-279.el6 kernel.i686 0:2.6.32-279.11.1.el6 kernel.i686 0:2.6.32-279.14.1.el6

Complete!

うん、簡単♪
スッキリした。

ちなみに --count=KERNELCOUNT オプションを指定(デフォルトのKERNELCOUNT:2)すれば、残すカーネルの世代管理も出来るとのこと。

参考：
http://www.atmarkit.co.jp/flinux/rensai/linuxtips/801deloldkernel.html

Action! - デブサミ2013に行ってみた

2/14(木),15(金)の二日間に渡り、デブサミ2013に参加し、いろいろなセッションで興味深い話を聞かせてもらった。今年のテーマは

Action!

いいと思ったら、まずやってみる！というエンジニア魂の原点に回帰したようなストレートなメッセージに、最近ディベロッパーとして停滞気味の頭にまずガツンと響く。

セッションの構成は、「Enterprise」「Social/Game」「StartUp」という3つのサブテーマに沿った最新の話を聞けるというものだった。
現在の自分の立ち位置(技術)とは、ちょっと毛色の違うセッションが多かったため、知見を広げるかくらいの軽い気持ちで参加したのだが、自分を取り巻く環境や、意外と近いテクノロジーの話が沢山聞けて、久しぶりに興奮した。

まあ各セッションについての細かな内容については、ほかの有識者があれこれと細かく良記事を掲載するだろうからそちらに譲るとして、かならずセッションの最後の

It's your turn

という「セッションを聞いて何かを感じたら、次はあなたの番です」というメッセージを受けて、動悸が激しくなった。

（最近、自分がどうしたいかマジメに考える時間作っていないよね…）

ちょっとした反省ののち、まずは参加後のこの気持ちを忘れないために、事実上荒れるがままに放置していたこのブログに久々の投稿をしてみた次第。

で、考えた。

向こう1年の「Action!」プラン。

* アウトプット(溜めるだけじゃなく、情報もコードもたくさん出力する!)
* Webアプリ(動くモン作る!)
* ロボット(思いつき。だけど、楽しそうな世界じゃん)
* できるだけ英語

とにかく、考えている暇があったら、不完全でも手をとにかく動かして、出力するぞ。
#決意がどこまで続くかは知らんけど、まずは宣言してみる。失敗しても減るもんじゃないし。

リモート作業でのお作法

先日、開発しているシステムがバージョンアップしたので、導入してもらっているお客さんの環境にVPNなんかでリモート接続して、モジュール更新作業を行っている。

普段はcronで日次処理を行っているジョブも、一時的に止めてモジュールの差し替えを行うわけだが、サービス再開にあたり、その日だけは手動でその処理を実行する羽目になる。

lnux(bash)環境において、接続している端末からログアウトする際にジョブを停止しないように

$ nohup ./myjob &

のように、オマジナイ(nohup)をつけて実行するのだが、チョイチョイ忘れたりする。
#バックグランドで実行する「&」の方は忘れないんだけどなぁ…。

実行した後、ログアウトして

(やべっ)

みたいなことになるが、その前に慌てずにjobsコマンドで、そのプロセスのジョブ番号(以下例だと1番ね)を確認して

$ disown %1

と、オトナの対応をしてあげれば、ログインしているshellのジョブ管理から切り離されて働いてくれるので一安心。
#nohupだと、コンソールに吐かれる出力情報をnohup.outに格納するので、変なファイルが残っちゃうから、こちらのやり方の方がスマートな気がしないでもない。

脱・KYエンジニア

今日プレゼンをして大失敗。明日には忘れてそうだが、とりあえず今日は自分の欠点に自己嫌悪に陥る。

占いは基本的に都合のいいことしか信じないのだが、

(ひょっとしたら、当たっているかもしれん)
#B型、獅子座、寅年、動物占い→猿に共通する要素。

と感じる部分がある。それは各占いで、よく言えば「独創的」、ネガティブに言えば、「マイペース(自己中心的)」という指摘が含まれているところ。

確かに私はある事柄で頭が一杯になってしまうとそこから離れられなくなって他のものが見えなくなってしまう傾向がある。さらに人と対話する時も、相手が聞きたがっている話しを聞かずに(本人はそのつもりはないのだが)、自分の関心があるところの話をしてしまい話題をずらしてしまうことが多々ある。
要はKY(空気読めない)人なのである。

まあこれが、他愛も無い日常生活の1シーンなら付き合わされる相手さえ我慢できれば問題は発生しないのだが、これが仕事となると振り回される方はたまったものではない。
#…と思われる。私の立場が振り回す側でしかもその場では振り回す自覚がないので反省した時点での推測。

私の参画するプロジェクトの方々は賢く辛抱強い人が多いので、私が脱線するとうまいこと軌道修正をして下さるが、毎回おバカな私に

「これは…ですか？(はい/いいえで答えなさい)」

のような聞き方をするのは、物凄く疲れることだと思われる。
#さらにこの質問に対してはい/いいえ以外の回答をするのも私…。相当手強い(←自分で言うな)。

さすがに、ここ最近

(もう少し何とかならんもんかねぇ)

と自分自身に幻滅してしまう。この欠点は、結構昔から認識していることなので、そこにハマると毎度の事ながらへこむ。
#後から客観視できるようになるまで、自分がその状況に陥っていることに気付けないのが情けない。もはや病気…。

今更ながら、今年の大きな目標として、せめて仕事の時くらいは人の話(なにを意図して聞いてきているのか)を理解できるようになろうということ(脱・KYエンジニア)を掲げることにした。
#なかなか治らないんだろうけど…。そこを脱却せずして技術的なスキルアップは望めまい…。

さっそく明日から色々と対策を講じてみようっと(←ホントに出来るの？)。

ポストモーテム

先日、プロジェクトチームのポストモーテムが行われた。
#ポストモーテム(postmortem)って反省会とか振り返り会のことさしていることは知っていたけど、和英辞典で調べると検視とか死体解剖の意味があって妙に納得してしまった(どうでもいい話)。

今回のプロジェクトの期間は約5ヶ月。あっという間だった気もするし、この間色々な出来事があったので、内容の密度からするとまだ5ヶ月しか経っていないのという意外な気もした。

毎回このチームは趣向を凝らして振り返りをするが、今回も結構楽しかった。午後の時間に会議室を占拠して、お菓子(リーダの粋な振る舞い)をつまみつつ、お茶を飲みながら和やかな雰囲気で行われた。

今回の目玉は「タイムライン」による振り返り。

いきなり1メートル強四方の紙が5枚壁に

ズドーン

と張られてまずビックリ。
その紙には1枚ごとに9月、10月...と日付＆各フェーズの範囲を示す線が引かれ、そして中央に一本の長い線が横に貫かれたもの。それ以外はほぼ白紙の紙。

そしてメンバには3色の付箋が配られた。それぞれチーム内(個人含む)、チーム外、技術に分けたトピック(この5ヶ月間の出来事、感情、なんでも)を自由に書きましょうとの説明された。
みんな夢中で付箋に色々なことを書き込む。「あーだ」「こーだ」とぶつぶつ話しながら作業する様は、なんだか小学生の時のグループ学習みたい。
#大きく違うのは構成するメンバ。大半が30過ぎのいい年のオッサンなので小学生のような微笑ましさは無い(知らない人が見たら不気味？)。

そして約1時間後、5メートルの巨大な白紙は付箋で埋め尽くされた。プロジェクトで起きた様々なイベント、新しい技術の完成、ドツボにハマった障害から、風邪引いて辛かった、旅行に行ってリフレッシュなどの個人イベントまでびっしり。5ヶ月間の年表
(月表？)が完成したのだった。
#圧巻!!

出来上がったタイムラインの内容を皆で改めて点検。

忘れていたことも思い出されて、改めて5ヶ月なんだかいろいろとあったなぁと振り返ることが出来た。

この作業はこれで半ば目的は達成。
無理に全体でこの中から何か法則を見つけ出そうと躍起になったり、反省しようとする必要はないと思った。この過程であれこれ交わした会話の中に何か気付かされることが各人あったに違いないから。

しかし年表は面白い。
もともと私は史学科出身と言うこともあり、この手の解析はワクワクする。大学でも文献を読んで、出来事や自分の考察などを真っ白な年表に書き込んでいって何かを導き出そうとする作業に没頭したことを思い出してちょっと懐かしい。
#あとは白地図にいろいろ書き込むのも面白かったなぁ。

この手のアプローチはアナログにやるのが良いと個人的に思う。PCで年表とかをデータ化すると入りきらなくなった情報がスクロールしなければみえなくなってしまうことが多々あるから。
1枚で俯瞰するところに大きな意味があると信じているし。アナログだと情報がビジーな箇所は整理したくなる心理が働き、整理することによって新しいアイディアが生まれてくることも多いので、環境には優しくないけど、こういうところはケチらず行きたいものだ。

で、結局プロジェクトの振り返りはどうだったかというと、

(あれ？まとまってない？？)

でも、それでいいのだ。

設計内検証

現在参画しているプロジェクトでは、いくつかの製品の開発が同時平行している。作業も大詰めでリリース間近という時期で、いくつもの検証プロセスが走っている。
年末から年始にかけて私がやっている作業も動作検証が中心である。ユニークなのは設計者視点での動作検証をやっていること。
#私のチームでは設計内テストと呼んでいる。

製品の一般動作検証については、検証チームやＱＡ部門といった別のプロセスで実施される。これらは画面遷移や操作の組み合わせから試験項目を洗い出し、直交表を使って効率よくテストパターンを実施したり、ユーザ視点での品質評価が行われたりする。

それに対して設計内テストは開発自身が

「これ危なそう」

とか

「やって欲しくないなあ」

という最悪ケースをひたすら組み合わせて、テスト項目を洗い出すというマゾヒスティックなテストのことを指す。利用場面は無視され、

「普通こんな操作しねーよ」

というようなテスト項目も続出。基本的には複数スレッドが起動している(多いほど面白い)場面で、それぞれのコンテキストが変化する瞬間や重なる瞬間を突くような視点のものが多い。自分がお金を出して買った製品に対してはしたくない行為がけっこうある。
#携帯電話とかで、データ登録中にボタン連打したりとかリセットボタン押してみるとかしたくないでしょ？

そういう非日常的な性質を持ったテストは結構盛り上がる。
特に強烈なバグ(ハングとか)を出した者は殊勲賞もの、出された実装者は

「やったー♪」

と大喜び。
#以前参画していたプロジェクトでは考えもしなかった(ちょっと変態チックな)雰囲気だが、最近ではその感覚が分かるようになってきたから結構自分も染まってきたのかもしれない。

結構面白いのがバグを出した名探偵の推理と、実装者による原因の答え合わせ。ぴたりと一致した時でも、バグの真犯人が見つかった時でも、盛り上がるのだ。

バグを出されれば出されるほど喜ぶ開発者に近づければ、自分もレベルアップできそうだ。
#まだまだ言い訳が多い自分の今年の目標のひとつは「バグを楽しむ」かな？

キャッシュの罠

プロジェクトのリリースも間近でしかも年の瀬と言うこともあって、

ちょっと一息

…ついたような気になっていたのだが、その気分を吹き飛ばす大きなバグが発見され、何の因果か修正担当に。
#自分が書いたコードではなかったので、おバカな私は仕組みを理解するのにちょっとかかった…。

原因は処理性能を上げるために頻繁に参照される情報を上位層でキャッシュしていたこと。キャッシュすること自体はよいのだが、特定の処理実行後に情報本体とキャッシュの内容の整合が取れていない状況が存在し、その条件下で特定の操作を行うとキャッシュから不整合情報を取得してアプリの動作をおかしくしてしまうのが問題になった。
修正自体は情報本体とキャッシュの情報が異なるケースが発生する場合にキャッシュを破棄する仕組みを入れるだけで済んだ。

実はこの系の問題は過去にも嫌と言う程経験している。

本来なら正規の手続きで、本体情報にアクセスしてキャッシュのような情報のコピーを作らなければ間違いは発生しない(情報は分散せず一箇所で管理論？)のだが、要求の処理性能を満たすために速度チューニングをする場合に、この手法で解決することはよくある。
問題が発生するケースはキャッシュを実装した後のアップグレードなどで機能追加などがなされた際(正規の情報アクセスに関する処理手続きに変更が入った場合)に、キャッシュ処理部の検討をし忘れることが多いことである。さらにテストにおいても情報本体の変更はデータの中身を覗いて確認するであろうが、メモリ上で一時的にキャッシュされている情報については看過されやすい。

「情報に早くアクセスする速度性能」と「正確な情報を取得するサービス」は（システムによって程度は異なるが）基本的に相反する性質のもので、重点の置き方によってどちらかを犠牲にしなければならないことが多い。

例えばGoogleの検索システムは最新のWeb情報とは非同期である。基本的にある時点でのWeb情報を収集してその結果をキャッシュしていて、そのキャッシュにアクセスすることで驚異的な検索性能を提供している。そのため本体情報の変更が頻繁なWikiやブログ、掲示板なんかはGoogleで検索した結果を元にそのリンクページを見てみると、全く違う内容だったということはよくある。このシステムの場合は、圧倒的なアクセス速度重視システムといえる。
#逆に本体情報同期していないと困るのは、チケットの予約システム。

そういえばちょっと前にドキュメントの整理について考え悩んでいたのが、似たようなことだった。設計資料や仕様書など読み手に応じていろいろなものを作成するが、どうしても情報が一部かぶってしまうことがあって、設計の変更にあわせてドキュメントを更新する際に、すべての情報が正しく更新するにはどうしたらいいかというものである。この問題の根幹は同一情報を複数のファイルで管理している(二重三重に情報を持つ)ことにある。

コードを本体情報と考えたら、その仕様書はキャッシュみたいなもんか。二重管理しないとなると「コードを読め！」ということになるが、作業効率を考えると人間が読みやすい設計資料におこすのは正しいし…。でもキャッシュの作りすぎはメンテナンスコスト増加…。
#うーん。やっぱり難しいぞ。

こん(con)な名前は付けちゃダメ

現在、参画している組み込み機器用のソフトウェアの開発プロジェクトは佳境に入っていて、検証プロセスががんがん走っている。そんな最中に発生した問題。

「PCと機器を接続してファイル転送をしていると、ある一定の容量で転送エラーが発生する」というもの。使用済みの容量は半分にも満たない。

ぬ？以前にも似たようなことが…。

しかし原因は前回と異なった。
…が、またしても犯人はFAT32(ファイルシステム)。今度はファイルのエントリ数ではなく、ファイル名がいけなかった。
「con.〜」と言うファイルを作成しようとしてエラーが発生し、以降の処理が中断してしまったことによる。
#これだけで、DOS時代からのベテランエンジニアならピンとくる(…はず？)

なんとconはDOSの予約語で使えないんだそうだ(Microsoftさまのページをどうぞ)。

「 " / \ [ ] : ; | = ,」の文字がファイル名に使えないのは、Excelなんかでうっかり使って怒られるので知っていたが、「 CON, AUX, COM1, COM2, COM3, COM4, LPT1, LPT2, LPT3, PRN, NUL」と言う文字が予約語だっていうのは、若くてピチピチの私には分かろうはずが無い。
#↑単に無知なだけ。

またこれらの予約語の後にピリオド(.)が続くファイル名は一切作れないのだ。
#con.txtは作れない。

手元のWindowsXP(NTFS)の環境で試したら、メッセージが間抜けで笑えた。
Excelで「prn」と言う名前で保存しようとしたら

『ファイル名'prn.xls'はデバイス名として予約されています。』
#一般peopleに優しくない表現。

「con.con」にすると

『ファイル'con.con.xls'は既に存在します。既存のファイルと置き換えますか？(はい/いいえ)』
#もちろんそんなものは無い。

で、「はい」押すと

「'〜con.con.xls'にアクセスできません。〜」
#いったいどういうことじゃ？意味不明。

という感じの投げやりなダイアログが表示されて、作成は出来ない。

昨今のリッチなPC環境でなんでこんな縛りが！
#天下のMicrosoftさまのすることにしては、お粗末な気がする(笑)

興味が出てきて色々調べてたら、Windows95/98系で一旦はこのお粗末な仕様から脱却しようと頑張ったんだけど、いろいろとセキュリティホールが見つかって、

「conて言う名前が使えなくって何が悪い！」

と、結局居直ったのが現状ということらしい。

「こんなかっこ悪い仕様でも、天下は取れるんだぁ。一応は頑張ったんだよね。おーよしよし」

と私のようなB級エンジニアに言わせたくなる位のみっともなさ。
#このヘンテコ仕様の尻拭いさせられそうなので、せめてこれ位は言わせてヨ。

気になるAndroid

Appleと同じくらい気になるGoogle。
iPhoneと同じくしてGPhoneを極秘開発しているらしいという噂がまことしやかに流れていたが、詳細はちょっと違ったらしい。
Googleは「Android（アンドロイド）」という」と、携帯端末のためのオープンな総合プラットフォームを作ってのだった。

「ついにOS作ってきたかぁ〜」

ある程度予想はしていたが、発表されると

「やっぱ、Googlはすげえな」

と感心してしまう。携帯端末では近年Linuxも人気だが、今後どのように変わっていくのだろうか。自分の働き方にも影響を与えるかもしれないので、要注目である。

Androidを知ったのと同時に「Open Handset Alliance」という業界団体が作られていることも知った。名だたる企業が名を連ねていて、KDDI、NTTドコモなど日本の携帯企業も参加しているので、近いうちにAndroidを搭載した携帯電話が日本で販売されるようになるんだろう。

などぐだぐだ書きながら、ホームページみていたら、

... Android is built on the open Linux Kernel.

と書いてあった。linuxとは競合しないのか。Unix系元気だなぁ。どちらかというとMicrosoftの戦略と競合するんだろう。
よくよく読むと、AndroidはOSを含めたミドルウェア、アプリケーションを含めた携帯端末向けソフトウェアパッケージみたい。

どうでもいいが、Androidの紹介動画でチームマスコットは犬であることが分かった。
#ペンギンよりヒューマンフレンドリー？

SDKのダウンロードは11月12日。もうすぐだ。

コード読み会

ここ数日、インフラ周りのお仕事以外に開発の作業を頂いて、コードを書いているので、ちょっと楽しい♪
最近の仕事が自分にとって抽象的で未消化な部分が多かったので、ストレス発散になったようだ。
#自分自身でアイディアがまとまっていない時は何をしてもうまくいかないことが多いので、気分転換が必要だったのかもしれない。

今日は開発チームで企画された「コード読み会」に出席。
この会はコードレビューやコーディング規約のチェックが主旨ではなく、日頃コードを書いていて

「こんな時他の人はどう書くのかなぁ？」

のような、どちらかというとコーディングスタイル、書き癖、個人の得意技のような技術を共有することを目的としたものであった。
今回は実際のコードを見ながら、こんな時皆さんどう書きます？的なＱ＆Ａ方式で会は進行した。
ソースの書き出し部であるヘッダのIncludeの書き方から色々なポリシーが飛び出し、個性が出ることが発覚。数行毎にネタが提供され大盛況だった。
コーディングルールやフレームワーク上でコードを書いているにもかかわらず、結構「俺色が出るのね」という発見の連続と、「こんな場合はこうやって書くといいのか」という小ネタが満載の楽しい時間であった。
#Ｑ＆Ａ方式はイディオム単位でディスカッションできるのが最大のメリット。特にこういう会に慣れていない私のような人には、場のトピックがハッキリするので分かりやすい。お経のように1行ずつひたすら読むのは上級者向きかも。

コードから個人の性格、考え方(ひいては生き方まで？)まで透けて見えるコード読み会はチョッピリ怖いけど、その分ぐっと書いた人の気持ちが分かるようになる。
相手が何を考えているかを理解するのはチームで仕事をする上でとても重要なことなのは言うまでもないことだが、「言うは易し、行なうは難し」である。その実践の一つの解として、「コード読み会」はお勧めしたい。
#何より面白い♪

開発文書管理の憂鬱

ドキュメント隊長に任命？されて早一ヶ月近くが過ぎようとしている。

プロジェクトの今回のマイルストーンの中のミッションの一つに開発ドキュメントの品質向上が掲げられていて、そのお題目を同実現するかの旗振りをする役目をおおせつかっているのだが、どうもうまくいかない。

例えばプロジェクトの品質管理が流行のISO 9001(？)に準拠して運用されているのであれば、そのプロジェクトの定める品質マニュアルで規定される文書をプロジェクト必須文書として管理し、それ以外は参考文書としてある程度自由に任せるなど管理方針が立つものだが、そういうポリシーがプロジェクト内で採用されていないので、どうしたもんだか悩んでしまう。
#以前いたプロジェクトではISO 9001のせいで、見かけだけの本質的には意味のない文書を大量生産するという不毛な作業を経験しただけに、縛りだけあるのもどうかとは思うのだが…。

チーム内の意見を聞いてみたところ、関心は品質云々というよりは、自分が開発で必要とする技術トピック(情報)をいかに効率よく集められるかという点に集まっているようであった。それこそ情報収集の観点のみで言えば、Googleに代表されるようなキーワード検索によるフィルターを通じて、必要な文書を見つければいいと思うのだが、文書の品質を管理していく上ではある程度の構成管理を行う必要があって、その兼ね合いが難しい。

基本的に開発者はコードを書くのは好きだが、文書となると途端にモチベーションが下がる人たちが多い。文書を書くことは基本的にやったことを焼きなおす作業(しかも不得意な言語を使って翻訳し直す作業)の色彩が濃く、いまいち創造的ではないからかもしれない。
#ロジカルな人ほど作業の重複を嫌がる傾向にある。

このような性質の文書を拡充し品質を上げていこうとするには相当なエネルギーが必要となる。好きな作業は黙っていてもやるとおもうが、嫌な作業に対してモチベーションを上げるには「ご褒美」が必要。しかし手持ち無しといった状態にある。
もともと整理整頓が苦手な性質であるのに、このような宿題が手元に残っているとそれだけで、憂鬱な気分になる。

どうしたものかな…。

ドキュメント隊長

最近私は開発環境のインフラ整備っぽい作業をしているのだが、
本日正式に「ドキュメント隊長」に任命された(笑)。
#このプロジェクトに参画したときの肩書きがテクニカルライターだったが、ついに隊長に。ちなみに隊員はいない。ノリとしては劇団一人？

もちろんプロジェクトチーム内で付けられた冗談の肩書きであるが、「〜リーダ」とかより「〜隊長」という響きの方がステキ度が高いのでモチベーションが上がる(？)。

開発が継続すればするほど溜まっていく文書(情報)が陳腐化しないように整理・管理したり、開発規模がどんどん大きくなるにつれて不足しがちなドキュメントを補填したり、メンテナンスを促す仕組みを作るのが「ドキュメント隊長」のミッションである。

今まで経験してきたプロジェクトを振り返っても、「開発モジュールの内容と開発ドキュメントの内容がきちんと同期を取って常にメンテナンスされた状態にある」ことはなかなか無かったことである。だからと言って、それらのプロジェクトに於いてドキュメントが軽視されていたわけではないのだが(むしろドキュメントは重要だという声はどこででも聞くのだが)、タイトな開発スケジュールの中でついついドキュメント作成はコーディングより後回しにされたり、初期に作った開発ドキュメントがメンテナンスされずに終盤、モジュールの実装と乖離してしまったりといった事態になっていることが多い。

継続型のプロジェクトの場合、問題となるのが中途半端なドキュメント。ドキュメントを作った後、メンテナンスされていないものである。障害対応や機能追加、仕様変更、リファクタリング等の様々な要因で変更がモジュールに加えられたにもかかわらず、ドキュメントは以前のままという状況は最悪である。この時点で別の作業員に引継ぎを行うケースを想像してみるとよい。作業員は開発情報が残されているということで、ドキュメントに目を通すであろう。その情報を前提にモジュールを利用したところ、思わぬバグが発生したが、原因がわからない。結局ソースコードを確認したところ、ドキュメントに書かれた情報が古くて誤った使い方をしたことが分かったのだった…みたいなことを引き起こしてしまうからである。

まずは「モジュールとドキュメントが常に同期が取れた状態に保つにはどうすればいいのか」という仕組みを現在の開発プロセスにあった形で実現するのが最初の仕事になりそうである。
#今までの仕事と全然違うが、これはこれで新鮮で楽しい。

じぇみ人の集い

私が所属しているプロジェクトでは、毎週月曜日に「ランチ勉強会」というのが開催される。
この会は「お昼休み(昼食時間帯の休み時間)を使って、弁当でもつつきながら様々な技術トピックを気楽に話しましょ♪」というもの。
#この手の自主勉強会系はよく話題には上がるものの、実際に運用されているのに遭遇したのはここが初めて。素晴らしいことだ！

この会の運用の特徴は、禁酒の会とか禁煙の会みたいに当事者達が会の進行を勤めること。お医者様と患者、講師と生徒みたいな関係ではない点が面白い。また参加資格問わず(プロパーでなくてもOK)という点もよい。

私はこの会のことを勝手に「じぇみ人の集い(非公式)」と呼んでいて、参加するのが週明けのちょっとした楽しみのひとつとなっている。

ちなみに「じぇみ人」とは、基本的には「理想の開発」と「現実の現場」のギャップに日々悩み格闘している分裂症気味のエンジニアのことを言う。
#あくまでも私の勝手な定義。

なので「じぇみ人の集い」は、じぇみ人同士で自分の知っているちょっとした開発改善の知恵や知識を共有したり、現場の問題について話し合うことで、様々な障害を乗り越えて、解決する糸口を見つけましょうという会合のことを指す。
#くどいようだが、私見。

今日はそんな「じぇみ人の集い(もういいって！)」の語り部(発表者)になってしまったので、あまりこういうのは得意ではないのだが、頂いたお題(テーマ)を元に喋った。
今までの人達が格式高い内容だったので、おバカな私が話をするのは少々重荷ではあったが、個人的にはもう少し砕けた感じが欲しかったので、ハードルを下げる役は果たせたのではないかと前向きに評価。
#威張るな！

じぇみ人の自覚症状が少しでもあるエンジニアは、早めの処方が必要かも。周りにいるじぇみ人(もしくは元じぇみ人)との話し合うことで、症状は軽くなりますよ。

楽しいペアプロ

参画しているプロジェクトの製品のリリース判定も終わり、次の製品に向けての成果物をまとめる作業が、現在私に与えられているミッション。
ドキュメントをまとめたり既存の機能実装の見直し(&改良)など、地味な作業ではあるがこれはこれで面白い。

ちなみに、私の所属するチームは

「スクラムっぽい開発サイクルを回して攻めつつ、XPのプラクティスをガシガシ実践していきまっせ。ホイホイ」

みたいなちょっと体育会系のアジャイラー(?)達で構成されている。スゴイ人たち揃いなので、おバカな私がこのチームのアキレス腱といって間違いない！(←威張るな)
#構成メンバー全員が男で、お色気0%な点が唯一の不満であるが…。

今日は開発フェーズにおいて機能実装優先で混沌としたまま放置された私の醜いソースのリファクタリングを行った。一人では心もとないので、頼もしい助っ人(というかメイン)の力を借りてのペアプログラミング。

このチームでは「実装が複雑」とか「担当が複数にまたがる」とか「この時期のバグ修正は危険」とか今回みたいに時間にゆとりがある場合なんかによくペアプログラミングをする習慣がある。
個人的にはとてもいい習慣だと思う。
#自分の椅子をもっていって「お邪魔しまーす」みたいな感じで雰囲気もいい。

自分以外の人にコードレビューをしてもらうのはちょっと緊張する(最初は赤点を見られるような恥ずかしさであったが…)が、ホワイトボードにフローチャートやシーケンスを書きながら議論してコードをブラッシュアップしたり、巨大すぎるコードをクラス図書きながら細分化したり、共通コードを親クラスに昇格させたりとワイワイやっているととても楽しい。
結構考えていたつもりが意外と自分の中で整理されていないことが分かった時や、自分の実装方法よりもっと洗練された手法を教えてもらうと1日得した気分になる。

今日もいろいろな「気付き」があってとても有意義だった。

またリファクタリングした後、自分の書いたテストコードでエラーが発生すると、怒られているにもかかわらずなんだか嬉しくなるのは自分だけだろうか？

コードを綺麗にすると部屋を片付けた時に似た達成感が味わえるが、ペアプログラミングだとその充実感を共有できるのでもうちょっと嬉しいかも。お勧めですよ。

メイ探偵ごっこ

現在参画しているプロジェクトもいよいよ大詰め。
基本的に機能は凍結され既にRCレベル。本番製品目前の状態である。

さすがにこの時期ともなると

「ゴリゴリとソースコード修正しまっせ！」

というような状況ではないのだが、それでも大きなバグが見つかると、

「えらいこっちゃ、えらいこっちゃ、よい、よい、よい、よい♪」

と、お祭り騒ぎで対応を迫られることになる。

昨日アプリが異常終了するという大きな障害報告があって、ちょっとした騒ぎになっていたのだが、今朝出勤したらそのエラーが混入したバージョン管理システム上のリビジョンまで判明していた。そのリビジョン以前には発生していなかったので、そのリビジョンの修正によってエンバグしたものだった。
#しかもバグ追跡システム(ばぐじらみたいの)に報告されたある障害の対応をしたことによってエンバグしたことが分かった。

直接の原因は、システム開発をしているとよく遭遇するメモリリークで、リソースの解放忘れから発生したもの。バッチアプリだとそれほど大きな問題にはならないが、デーモンのような常駐アプリにとって恐ろしい問題だ。
#なにせじわじわとリソースを食いつぶし、突然プロセスが死んじゃったりするわけだからおっかない。

今日はその調査のお手伝いをした。該当ソースの担当者が不在だったため、急遽調査チームが編成され対応することになったからだ。
#ソースまで絞り込まれていれば、リーク箇所を見つけるのは時間の問題であったが。

他の人のソースを直す場合(レガシーシステムの保守を担当する場合などよくあるが)、障害に対しての対応方針が、人それぞれで面白い。

よくあるのは、

『実際に発生する障害に対して原因を特定して、その障害が発生しないようにすること』

である。今回、一緒にチームを組んでバグ修正にあたった方の発想は素晴らしくて、単にリークする箇所を修正してオシマイでは無く、

『この修正によって、本来修正しようとしていた開発者の意図を損ねないか』

という視点で調査されていたことであった。
#今回の件は結果から言うと、前者の対応のみでも特に開発者の意図を曲げるようなことにはならなかったのだが。

前者は医学で言えば、対症療法的なアプローチ、後者は原因療法的なアプローチと言える。つまり前者は目の前で発生している現象のみに着目して、それが発生しないようにちゃっちゃか修正してしまうやりかた。後者は本質的な原因そのものを突き止め、障害が発生しないように制御するやりかた。

前者の方がコストは低く即効性もあるのだが、表層的な事象を押さえたことによって、別の障害を引き起こす副作用の危険性もある。
後者の方は全体を把握(アーキテクチャを理解する)コストが高くつくのだが、根幹治療を施すため完治すると将来のメンテコストを下げることになる。
#後者の方が本質的な治療方法ではあるのだが、結局はコストが決定的要因になることが多い。

面白そうだったので(重要！)、私も後者のアプローチで考察開始。

けっこう楽しい作業だ。

物事の本質的原因を追究するのは、名探偵が犯人を追い詰める作業に似ていてる。その問題のコードが記述された経緯も、犯人になったつもりで推理してその意図を探っていくのだからちょっとドキドキする。ソースコードを通じて他人の思考を覗き見ているわけで、言うならば他人の日記を見ちゃっているような感じなのである。
#今回は犯人が分かった後で、犯人の心理に迫るみたいな感じであったが…。

私なりに推理して

「犯人はこのときこう考えた！」

みたいなカッチョいいシチュエーションを勝手にイメージして名探偵気分を満喫。

午後には担当された方が出社されて、その推理の答え合わせをして障害は無事解決した。
ただし迷探偵やぎぞうの推理は見事外れていたのだった(笑)
#推理ではなく妄想だったみたい。修行せねば…。

RadRailsへの道のり

先日Ruby on Railsにハマっていると書いた。

本当に

「アッ！」

と言う間に簡単なWebアプリは動き始めるので
#ちなみに私の「あっ！」は二十分位(笑)

「いやぁ〜だ、奥さん、本当に凄いんですのよ。おほほ」

と思わずおばさん口調になってしまうほど、感動した。

…のであるが、自宅の非力なWindows(XP)マシンに構築するのには

「あ〜〜〜〜〜〜〜〜〜〜〜ぁ(ため息)」

のように、別の意味でハマったで環境構築をメモっておこう。
#実は私だけ？

まずはRubyのインストール。オフィシャルホームページよりWindows版(ruby 1.8.6)をダウンロードして、インストーラをキックするだけ。
全く問題なし。

次にRubyGemsのインストール。GemはRubyのパッケージ管理君。rpmとかyumのようにコマンド一発でパッケージ追加ができる便利なやつである。これもダウンロードサイトからrubygems-0.9.4.zipを落として解凍後のフォルダ内のsetup.rbをクリックするだけでOK。

これでgemが使えると思ったら大間違い。

DOSプロンプトでRailsを入れるべく

> gem install rails -y

と入力すると、

ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError)
Bad file descriptor - connect(2)(Errno::EBADF)

と怒られて進まない。ググッて調べるとプロキシ設定云々というアドバイスがあるものの、自宅では使っていない。自宅の環境を色々疑って数時間格闘するものの解決せず。
結局、依存関係のある個別のパッケージをRubyForgeでダウンロードして、gemでインストール。
#メンドクサイ…。StandAloneマシンか全く！

actionmailer-1.3.3.gem
actionpack-1.13.3.gem
actionwebservice-1.2.3.gem
activerecord-1.15.3.gem
activesupport-1.4.2.gem
rails-1.2.3.gem

無事にRailsの環境は整ったが、データベースが必要なのでMySQLをダウンロードすることに。インストールは簡単なのだが、ダウンロードするのに基本情報とメールを登録しないといけないのが、手間である。
#こういう小さいことが重なるとモチベーション下がるのよね。

ネットで調べていると、無料でRails開発用のIDEがあるとのことなので、せっかくなので使ってみることに。
RadRailsというIDEでEclipseベースに作られたもの。Eclipse大好きっ子(？)の私にピッタリ。



RadRailsのホームページに行き、まずはAptana IDEをダウンロード。
起動すると、起動ロゴこそ違うものの見た目Eclipseそのもの(当たり前だが…)。起動画面にRadRailsプラグインダウンロードのボタンが表示されているので、

(ポチっとな)

と押すとあっけなくインストール完了。

これで動くとぬか喜びをしたが、実は環境設定がチョビっと必要。

「ウィンドウ(W)」→「設定(P)」を選択して、起動した設定ダイアログ上の「Rails」→「Configuration」を選び「Rails Path」と「Rake Path」を入力して、今度こそ設定完了。

以上、環境設定。
#誰もハマらんよって声が…。

Railsのレポートはまた後日(引っ張るよ〜)。

線路の上での遊びすぎに注意！

担当の仕事がひと段落して(プロジェクト的にはヒートアップなんだが)、ここ最近は早めの帰宅で一息ついている。ムスコが起きている時間帯なのでちょっと嬉しい。

玄関の鍵をカチャっと回すと、リビングの方から「あっ、オトウサンだ！」と弾んだ声がして、ダダダッと玄関まで走ってくる足音が聞こえる。そして扉を開けると、

「オト、オト、オト〜サンが帰ってきたよ！オカーサン」

と、まるで半年間蒸発していた父親が帰ってきたかのような大騒ぎで面白い。
#この時の声がデカイのでご近所に対してちょっと恥ずかしいが…

そして、ぺこりとお辞儀をしながら

「お帰りナサイ。お仕事お疲れ様デス。どうぞどうぞ、いらっしゃいませ、明けましておめでとうゴザイマス…%&$#？」

と続く。
#もはや何が何だか分からない歓待だが、見てるとカワイイ(親バカでスミマセン)。

このようにムスコと過ごすのだけでも楽しいのだが、実はここ最近ハマっているのが

「Ruby！」

正確にはRuby on Railsの方なのだが、触っていてとても楽しい。

きっかけは、先日遊びに行った知人がハマっているのがRuby。しかもRuby会議に(2日間家族をほっぽって)参加して仕入れたネタを披露してくれて、興味が急上昇！
#Ruby会議参加者がもらえるRubyトートバック(Tシャツじゃないのがいい)を見せてもらって、「何か、えぇですねぇ」という気にさせられたのもある。

基本的に乗せられやすい上に、今月の日経ソフトウェアが「丸ごと特集 Ruby大作戦」とタイムリー。購入して読む。
#前回の「Web＋DB」でも特集してたし、飛びつけ！という神託か？

気分も盛り上がり、特に前々から興味のあったRuby on Railsについて「触ってみましょ、そうしましょ」と行け行けGoGoというわけで、書店で入門書を求めたのが1週間前。

購入したのは「実践 Ruby on Rails Webプログラミング入門」という書籍。
Javaプログラマ向けRuby入門と、StrutsとRailsを比較しながら解説してあったので、私にとってありがたかったからである。
#以前、仕事でStrutsフレームワークを使ってJavaでwebアプリを開発したことがあったので、うってつけだったのである。

そんなこんなで、Ruby開発環境を自宅のノートPC(WinXP)上に構築して、毎日コソコソといじって遊ぶのが実に楽しい♪
#AptanaIDE(Eclipseベースの統合開発環境)にRadRailsというプラグインを追加して遊んでいるのだが、これだけで結構なネタになるのでまた次回。

ついつい遊び過ぎて、気が付くと深夜なのが難。仕事に影響しないように気を付けないとねぇ。

伝説のアプリ

6月も終盤に差し掛かった。何だか梅雨入りした途端、「夏到来!」みたいに天気がやたらとよくて季節感があまり無い。
#雨が少ないので「よもやこの夏給水制限とかならんだろうなぁ」とちょっと心配していたりする。

6月に入った時、「新人研修」ネタを書いて微妙に反響があったのでもう一つ披露。

私が新人の時にいた会社は人数が少なかったせいもあって、上からペーペーの社員まで良くも悪くもお知り合いであった。
#よく言えばアットホームな感じ、悪く言えば運命共同体…。
そんな雰囲気なので、当然ながら研修中に先輩社員からいろいろと悪戯された。

中でも忘れられないのが、「うゃ〜ん.exe」事件。
#なんだ「うゃ〜ん.exe」って？気になるでしょ。ちゃんと話しますよ。

前回のネタに書いた通り、私は「エンジニアのいろは」の下地０％の状態で入社した。
#ある意味、潔い！
そんな訳で研修中は、常にPCとの格闘＆頭の中「??」だらけの状態で突き進んでいた。そんなある日、1通のメールが先輩社員より届く。細かい内容は忘れたが、「研修中に困ったことがあったら、これを使うといいかも？」みたいないかにも誘っている感たっぷりの胡散臭い文章に「うゃ〜ん.exe」という不審なファイルが添付されていた。

(いかにも怪しい)
…でも物凄く興味があったので、用心深く同期に「うゃ〜ん.exe」について尋ねてみたところ

「とにかく凄いよ」

とにやにやしながらの返答。ただし内容は教えてくれない。

確かVBの研修中だったが、先輩社員の説明を聞いているととてつもなく眠くなってきたので、暇つぶしにこっそり例のヤツを起動してみることにした。

すると突然画面が真っ青になり、

「システムが不安定になりました。修復しますか？　[OK] [中止]」
のようなダイアログが表示。※ここ

(うそぉ〜〜〜〜〜〜〜！)
予想外の結果に物凄い衝撃を受けた。
#補足すると、入社当時の研修端末はWindows98でスペックもCPUがPentium120MHz、メモリ64MB、HD2GBと今からすると玩具みたいな感じ。とにかくWindows98はブルー画面が出てシステムが不安定になった。

(えらいこっちゃ、えらいこっちゃ)
と額には汗が流れ出したが、とにかく指示に従うかと[OK]ボタンを押すと、

「すべてのファイルを削除します」(※ここ２)

と言うメッセージと共に、ハードディスクはカリカリと音を立て画面には次々と「〜を削除しました」みたいなメッセージと進捗状況を伝えるプログレスバーが表示される。削除される〜の中にはsystem領域にある神聖なるdllのファイル名も垣間見えた。

(ぬぉぉぉぉ)
完全にパニック。おそらく脳内には得体の知れない分泌物が充満し、心拍数も普段の倍だったはず。
プログレスバーの下部に[中止]ボタンを発見し、とにかくそれを連打。
すると上部の「※ここ」に戻った。

(恐ろしい。中止しよう)
と[中止]ボタンを押したところ、何故だか「※ここ２」の処理が始まる。そう何をしても結局のところ「ファイルの削除」が実行されるのである。

何度か悪あがきをしたが徒労に終わり、茫然自失の状態でプログレスバーを見つめながら、遠くで先輩の声を聞いていた。

…十数分後。

「うっそぴょ〜ん」

というメッセージ付きのとある先輩社員(あだ名がexe名だった)のデジカメ写真が表示され、何事も無かったかのように(実際に何事もなかった)見慣れたVBの画面に戻った。

(…やられた)
そう。先輩謹製のジョークアプリだったのである。

話を聞くと、VBの開発においてファイルシステムをなめるコードを書いたのでせっかくだから何かに使えないかと考えて誕生したのがこのアプリ。苦労したのは、いかにWin98のシステム異常を伝えるブルー画面とダイアログを似せて作るかということ。またご丁寧にもファイルの削除表示にあわせて、ダミーの0バイトのファイルを作成しては削除するという念の入れよう。
単なるアプリなので、Alt＋F4とかで簡単に終了させられるのだがパニックになっている時は全く思いもよらなかった…。

その時決意したのである。

「ちゃんと勉強してスキルを磨き、後輩を引っ掛けるための立派なアプリを作っちゃる」

書かない技術

暫く仕事の方が忙しかったのであるが、私自身の疲弊度(肉体的にも精神的にも)が高まってきたので、今週は(割と自主的に)早く仕事を切り上げて帰宅することにさせてもらった。
#おいおい、大丈夫か？

ここ最近、本を読むためのまとまった時間がとれていなかったので、溜まってしまった雑誌やら新聞やらなにやらに目を通すために活用することにした。

今日は天寿の雪室氷点熟成させた純米酒を片手に、最新の「ウェブDBプレス　Vol38」を読むことに。
#なんだか久しぶりで贅沢な気分。適度な仕事に、適度な夜の時間。これが日常化すると最高にHappyであるが、そのためにはまだまだ修練が足りないようだ…。

今回の特集で気になったのは、「無駄なコードを書かない技術」。常日頃からいいコードを書けるよう心がけているつもりだが、それでもバグは0にはならない。
#オブジェクト指向の開発思想を学び、テストコードをサボらず書くなど、イロイロと実践しているのだが…理想はまだまだ遠い(-_-;)
そういう意味でこの特集の発想はちょっと面白い。バグを最小限に抑えるには、ズバリ

「できるだけ(無駄な)コードを書かない」

という視点を持っているから。
#究極はコードを書かなくても、やりたいことが実現できるシステムを構築することなんだろう。

特集自体はコードジェネレータなどを駆使して、反復するロジックをテンプレート化し、できるだけ同じ処理のコードを減らしたりするなどの実践テクニックが紹介されており、今すぐどうこうというわけではないが面白かった。

今回はそれ以外にも「はじめてのRuby & Rails」といった興味のあるトピックの特集やここ最近の仕事であった「DBチューニング」など充実していてお買い得な号であった。
#明日は溜まってしまった日経コンピューターを読むか。

今更ながら…でも祝！

先日受験した情報処理試験の合格発表が今日だった。

受験したのは今更ながらソフトウェア開発技術者試験。以前サラリーマン時代に受験したことがあるが、業務が忙しく撃沈。その後個人事業主になってからは色々とありまして…まあ要はサボっていたのだ。

現在参画しているプロジェクトはとてもアカデミックな雰囲気なので

「無知なままではイカーン！」

と心機一転。
#色々と刺激を受けて、なんとなくモチベーションアップ！

「1ヶ月前からはしっかり勉強するぞ」と気合十分で受験申し込みまではよかった。
だが2月頃から急に仕事が忙しくなり(誰か見てた？)、休日は育児で完全に燃え尽きる。
結局何もしないまま(割と諦めはいいほうなので)、受験。
当日面倒になってサボろうかと思ったが、カミさんが弁当を作ってくれたので、ウォークマンと新聞と弁当を持って会場へ。
#音楽聴きながら新聞広げて弁当を「旨ぁ〜」と食べているおっさんははっきり言って浮いていたと思う。

そんな訳で結果をあまり期待していなかったが、万が一ということもあるので、合格発表を確認したところ

「あれれ？、番号あるぞ」

と嬉しい誤算。
#最近では得点もwebで確認できるようになっていたので見てみると、まあいつもながらギリギリ滑り込み(笑)。

実に基本情報技術者をとってから●年ぶりの情報処理であった。
#昨年「江戸歴史文化検定」以来の試験だが、受験者の年齢層は全然違う(暴)

会社で強制されなくなると、不思議と勉強するのが楽しいから我ながらアマノジャクだなあと思う。
#気持ちが仕事じゃなくて趣味に近くなったのかなぁ。