Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

「今月のケースファイル」あとがきにかえて

edited by DB Online   2015/01/14 00:00

 早いものでこの連載が始まってから1年ちょっと経ちました。今回が最終回です。晴々した気持ちでおります。ちょうど2年くらい前、編集の小泉さんからこの連載のお話をいただいたのですが、その時は正直言って「え、ムリ…」という気持ちでした。その頃は忙しかったし、安易に引き受けてうまく時間がつくれなかったなんてことになるとご迷惑がかかると思ったのです。

ネタ探しの日々

 この連載で辛かったのが、なんといっても「ネタ」を探すこと。NUMAの問題や最初に書いたメモリ不足の話など、いくつかのエピソードはあらかじめ書くことを決めていたのですが、途中ネタが切れてしまって大変でした。というのも、私が調査するような問題って、ユーザーさんが普段意識しないような部分の話、例えば、構造体の値がおかしいとか、オブジェクトのリファレンスカウンターがおかしいとか、終始プログラムコードの話になってしまうわけで、そんな話を書いてもなぁと。(結局、何回か書いたけど。)

 締め切り間近に小泉さんに「ネタがない、ネタが。」とメールすると、「いいから、とっとと原稿よこせ。」などと叱咤されるわけでもなく、いつもやさしく「がんばれー」と励ましてもらいました。泣き言を言ってスミマセン。

 平日は会社の仕事があるので、執筆はいつも休日に行っていました。土曜日にモソモソっとおきると、掃除や洗濯を済ませ、会社に行ってネタ探しand執筆、という感じです。でも、ネタを探しているハズが、気がついたら変なプログラムを書いていたり*1、全然関係のない調べ物をしていたりと、なんというか、やる気がないわけじゃないのですが完全に休日モードなのですよね。で、結局一文字も執筆できずに「とりあえず~、今夜はーこの辺で~、ヨシしとしよう~♪」と鼻歌まじりに帰宅するという日が何度かありました。(この歌を知らない人はごめんなさい。)

 *1 何の役にも立たないCDBのようなデバッガーをこの時作った。自分が主催する社内の勉強会で強引に披露してみたけど、だれもピンと来ず…

 昔から文章を書くことがあまり得意ではなく、小学生の時に道徳かなんかの授業で書かされる感想文は全く文章が思い浮かばないタイプ。「○○はいけないことだと思った。以上。」みたいな感じ。ただ、今回の連載に関しては、一度ネタが決まると過去の記憶を辿りながら文章を書くという作業は意外にも苦痛ではなくて、不思議と時間はかからなかったです。

 たぶん、それは普段から今の仕事に興味を持って携われているからだと思うのです。いや、正直に言うと、日々の業務で興味のある事ばかりに巡り合えているわけではないのですが、少しはまじめに仕事をやってきたから書くことがあったのかなぁと。

 実際のところ、日々の業務とは直接関係がないようなことに興味を抱くことが多くて、SQL Serverに関連する技術について調べていたのだけど芋づる式に関連する技術が気になり、気がついたら当初気になっていた事とは関係のない事を調べていた、なんてことがあります。

 ただ、Dragon Book*2 のような古い本を読んで眠れなくなったりすると、自分って変な奴だなぁと思います。「そこまで遡るか。」という感じ。でも、自分にとっては、新しい技術だけじゃなく過去の技術を勉強するのも結構楽しいことなのですよ。

 *2 正式名称 Principles of Compiler Design, by Alfred Aho and Jeffrey D. Ullman。SQL ServerとはLALR Parserの部分で少し関連があります。私が持っているのは1977年に出版された表紙がグリーンドランゴンのやつ。

タスクオブジェクトがリークした話

 この連載で個人的に気に入っているエピソードは、タスクオブジェクトがリークした話。記事のクォリティはともかく、事例として面白かったと思います。数ギガあるSQL Serverのコードから問題の箇所を見つけたときは「ココだーっ」という感じでひとり盛り上がっていました。結局、問題のコードを書いた人は、スマートポインターのオペレータ オーバーロードを誤って使用していたのですが、これがもうソースコードをパッと見ただけでは全然わからないのです。でも、アセンブラコードをみると明らか。デバッグに関する書籍を読んだことがある人はわかると思うのですが、大抵は「自分以外のところに問題があると考える前に、まずは自分を疑え。」といったことが書いてあります*3。しかし、この時ばかりは開発チームが「コンパイラーがおかしいのではないか。」と言いたくなる気持ちが理解できました。結局、セオリー通りコンパイラーは正しくて、プログラムコードが間違っていたわけですが。ま、そりゃそうだ。

 *3 え、読んだことない?John Robbins氏著のDebugging Applicationsには似たようなことが書いてあったと思います。これまた、古い本ですみません。デバッグ関連の書籍にはトラブルシューティングについて体系的にまとめられているものがあるので、そういった本は開発者じゃなくても読んでおくと役に立つと思います。

 唯一やり残したかなと思っているのが、決め台詞。この間、プライベートで飛行機に乗る機会があり、機内で「男はつらいよ」を見ていたのですが、寅さんの「それを言っちゃあおしまいよ。」というセリフを聞いたときに、ふと「何か冒頭や締めの決め台詞があってもよかったかな。」と思いました。でも、相当センスのいい決め台詞でないとさむくなってしまうような気もするので、やっぱりなくてよかったのかも。

 かなり取り留めもなくつらつらと書いてきましたが、あらためて振り返ってみると我ながらいろいろなケースをやってきたなとしみじみ思います。他にもOS側の問題やミドルウェアの問題でSQL Serverのトラブルになってしまった話など、いろいろとボツにしちゃった話があるのですが、それは、また別の機会にでも。

 今までご愛読いただきありがとうございました。



著者プロフィール

バックナンバー

連載:マイクロソフト古賀啓一郎の「今月のケースファイル」

もっと読む

All contents copyright © 2007-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5