人様にお見せできないプログラムソース

ニフティクラウドで3万円分お試しができるというバナーを見ました。

以前にIIJさんのクラウドサービスであるGIOのお試しを使ってオルタナティブ・ブログの全ログを取得して簡単な分析をしたことがありましたので、もう1回やってみるかと思い立ちました。しかし障壁が2つあります。

1つはニフティクラウドが法人向けサービスであるということ。実際のところこの理由だけで十分に諦めがつきます。しかし敢えてもう一つ挙げたいと思います。それは。

「こんな結果でしたよー」という報告と共に、何となくソースも載せないといけないんじゃないかという感じのためです。（誰に言われるわけでもありませんが。）

IIJ GIOのCentOS上ではperlが最初から入っていたか、簡単に入れることができたか、ちょっと事情を忘れましたがとにかくperlでオルタナティブ・ブログの全ログを取りました。しかし私はperlを誰にも教わったことがないどころか、これまでに他人にソースを見せたことすらありません。もちろん仕事で書いたことはありません。そして「動けばいいや」の精神で典型的なコピペ継ぎ接ぎ製法を採用しました。

自分の中ではc言語やperlは特に書き手の差異が強調されやすい言語という認識です。逆にパッと見の文法面があまり気にならないのはjavaやVB系言語でしょうか。それほど多くのperlソースを見たことがあるわけではありませんが、それにしても自分のコードをまずく感じました。（設計の良し悪しはまた別の軸になると思います。）

更に正規表現という敵もいました。オルタナティブ・ブログのエントリ1本分のHTMLからタイトルや本文等の要素を取ってくるために当初はHTMLの各要素を扱うための何かのモジュール（失念）を使おうとしました。しかし数万エントリがあると100とかそういう単位でエラーが出るエントリがあり、実際に見てみるとタグがないなどValidでないようなものがありました。エラー箇所が様々なためエラー処理では吸収できず、そのためもっとルーズに扱えるよう正規表現を工夫しました。これによって取得したHTMLからブログの本文、タイトル、コメント、トラックバック等を分解できたのですが、それ用のパターンがまったく美しくありませんでした。難読だけれども無駄がないかというとそうでもなく、かといって冗長だけれども読みやすいかというとそうでもない、何度も試行錯誤して動いたところで「これ以上触るのやめとこう」という進め方をしたときの典型的な落とし穴です。

そんなこんなで、GIOでオルタナティブ・ブログを分析したソースは「時間のあるときに手を入れよう」と思いつつ、いつの間にかお試し期間が終了しました。ヘルプデスクは容赦なくいきなり削除することもなく「消してOKでしょうか？」というリマインドをして下さいましたが、仮にソースを救っても自分の魂が救われないような気がしてつい「消してもOKです」と言ってしまいました。

この感じ、何かに似ているなと思ったら中学・高校での英語の授業での発音練習に似ています。本当はしっかりと発音してダメなところを直したいんだけれども、人前で中途半端にしかできないと恥ずかしいので隠したい。それで敢えてベタベタのカタカナ読みをする、という感じです。そういえば英語も結局まともな発音ができないまま大人になってしまいました。

自分が書いたperlのコードも恥を覚悟で公開すれば色々とご意見をいただいて上達することができたのかもしれません。が、恥ずかしさの余りそれをしませんでした。

一方でYahoo!知恵袋などで「Excelのマクロが動きません」という質問をする人を探してみると「それ自動記録から起こしたでしょ？」という危なっかしいソースを堂々と公開していらっしゃる方がいます。対する回答者のほうは素晴らしい方もそうでない方もいらっしゃいます。しかしいずれの場合も技術者の掲示板と違って「書き方が冗長だ」とかいう人はあまりいませんでした。

自分のために作るプログラムはそれほど急に迫られたわけではありませんので、QAサイトや掲示板で質問をするために晒すこともありませんでした。これは中高の英語の授業と似ています。しかしネットで質問するほどの人は切羽詰まった所があって聞いていますので多少ソースが汚かろうが関係なく聞きます。これは留学や旅行に行けば多少のこだわりを捨てて英語を話さざるを得ないというところに似ています。

プログラムソースの指摘を仕事場や授業で受けられない人は主にインターネット上でソースの添削を受けることになろうかと思いますが、厳しい指摘があると嫌になってしまいますし、放置すると上達しませんし、なかなか難しいものだなと思います。