< 2010/02 | 新 | 2010/04 > | ||||
2010/03 | ||||||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
01 | 02 | 03 | 04 | 05 | 06 | |
07 | 08 | 09 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 |
趣味だからこそ到達できる領域がある。
ここ三日ほど、僕が作った全てのサイトの PHP プログラムロジックをいじり倒していた。それも客観的に見れば実に単調な作業だった。
まず三日前、PHP の高速化についてちょこっとネットを探してみたら、for ループロジックにおいて「配列変数の値を出力する for ロジックにおいて count() 関数を条件に入れると遅くなる。( for($I = 0; $I < counr($array); $I++) )」という記事を見かけた。理由はループが一回終わるたびに count() 関数が利用されて配列数を逐一確認しに行くため。そして、実はこの駄目だと言われる書き方、もろに僕の PHP で採用している書き方だった。実は前からダメかもしれないとは思っていたのであるが、直す気にならず放置に放置を重ねていたのである。
今回、高速化に当たって「それは遅い」と言われたならば迷うことはない。すべての for ループロジックの条件を書き直すことにした。
for($I = 0; $I < count($array); $I++) → $I_CNT = count($array); for($I = 0; $I < $I_CNT ; $I++)
書き直しが終わったのが二日前の夜である。そして、これでいいだろうとさらに別のページを見てみると。
「配列変数の値の出力をループで行うなら foreach ループを使うこと」
しくじった!
これは本当にしくじった。新しい事実に一つぶつかっただけで行動に出てしまったため、さらにその後ろに控えている新しい事実まで見つけられなかった僕の失態である。さらに早い方法がある、と言われて直さないわけには行かないので一日半かけて修正したところをもう一回全て修正することになった。
foreach ループは配列専用のループ関数である。配列を渡せば配列に格納されている値の個数分、最初から最後まで一回ずつループしてくれるもので僕のプログラムにはぶっちゃけ使われてないほうがおかしい関数である。しかしながら僕のプログラムには今の今まで一度も使われたことがなかった。存在そのものは PHP を勉強したときに知っていたのであるが、実際にプログラムを組むときには完全に忘れてしまっていた。
理由としては、この配列に特化した foreach 関数は一般的なプログラムには存在しない関数だからで、全くなじみがなかったのである。PERL や PHP のようなインタープリタ言語で実装されている関数らしい。
foreach 関数の特徴として、基本的には必ず「配列の最初から最後まで」らしいので、配列の途中からループを開始したりする場合には for ループを使わざるを得ないのであるが、最初から最後までループしたい場所はいくらでもある。というか、八割がた最初から最後までループする必要がある。よりて、再び八割がたを書き直したわけである。一日半かけて。
一般プログラムとの互換性は失われてしまうが、互換性にかまけてプログラムの特徴を殺すのは得策とは言えない。それぞれの特徴を使い分けて扱うのが腕の見せ所だろう。
と、いうわけで、実に単調ながらも自分の好きなようにプログラムをいじり倒せる贅沢な一日を過ごしたわけである。
この三日間の僕の行動は僕自身の技術力養成には実に有意義なものであったが、傍からみると「ちゃんと動いているものをなんでバグが起きる危険を背負ってまで書き直さなきゃならんのか」という心境に陥る、実質的に実りのない行動である。おそらく、もしもこのプログラム作成が仕事であったならば、工数圧縮のために絶対にやってはいけない行動である。上司がいたならば顔を真っ赤にして怒鳴り散らされるレベルだ。「三日も同じところで足踏みしやがって、この給料泥棒が!」と言われることだろう。
実質的に、プログラムを書き換えまいが書き換えようが、出力されるウェブページは全く同じものである。僕が感じたところ、書き換え前と書き換え後でそれほど表示速度が上がったとは思えない。高速化についてちゃんと効果があると立証されているものに置き換えたわけだが、今のところは秒コンマ以下での差でしかないのだろう。しかも、この書き換え作業においてプログラムバグを引き起こした場面があり、しかもその修正に二時間も費やしたとなっては仕事場で上司及び同僚に首を締め上げられてもおかしくない。なんでああいう単純なミスほど、見つけるのに苦労するんだろうね……見た目正しいものだから、本気でバグの発生理由がわからずストレス蓄積速度の倍率が酷いことになる。
※※※ 単純なミス ※※※※※※※※※※※※※※※
今回のミスは $w_entry_data という配列変数を使わなければならないところに別の配列変数 $new_entry_data を使ってしまっていたこと。よく似た名前の変数だから起きた悲劇。
※※※※※※※※※※※※※※※※※※※※※※※※※
このように実質的に何の利益もない行動を誰の咎めもなく平然と行えるのは、一重にこのプログラム作成が個人の趣味だからである。個人の趣味だからこそ、どんなにつまらないことであってもどこまでもこだわることが出来る。こだわりが全ての世界。すばらしき趣味世界である。ファーブルが有名になったのは昆虫を観察することが趣味だったからである。ライト兄弟が飛行機を発明したのは空飛ぶものを作るのが趣味だったからである。アインシュタインが偉大な発見をしたのは考えることが趣味だったからである。大抵の偉大なる功績は、その道の暇人、つまりは趣味の人が手に入れている。逆に言えば、趣味を持っている人でないと何らかの偉大な功績は手にできない、と言えるかもしれない。他人に言われたままに行動して偉大な発見をした人は実に稀だと思う。
念のために書いておくが、趣味を持つ人のすべてが偉大な発見をするわけではない。どこまでこだわるかに個人差があるし、到達したところで世間からは全く評価されないものも存在する。ギネスに載ってるのにあまり評価されないものが多いのはそういう事情である。ルービックキューブを適当にまわした状態から一秒できれいに揃えられたとしても、エンターテイメント系テレビに出演できても世間からはさして評価されない。世界一カップヌードルを食べていてそれにまつわる本を出そうとも、僕は興味ない。
参考:『日本一インスタントラーメンを食べる女』が書籍化決定! ラーメン好きのバイブルに - livedoor ニュース
記事は日本一だったな……まあいいや。
ただひたすら自分のためだけに趣味に走れるのは実に贅沢なことだ。余裕がなければ趣味に走ることは出来ない。お金がないオタクは何も買えず、いずれオタクから脱落する。僕もウェブページ作成が趣味と言ってもパソコンとネット環境がなければただの無能だ。余裕を持つまでが大変である。余裕を持てれば贅沢が出来る。余裕がないはずなのに贅沢をしている奴は馬鹿か外道である。多分。借金まみれの買い物好きとか。買い物依存症も趣味に入ると思うんだけどなぁ。自滅まで突っ走る趣味。
仕事でやってたら到達できないだろう領域と言うのは確実に存在する。もっと抽象的に言えば、自分から突き進まなくては到達できない領域は確実に存在する。それは他人にとやかく言われるものではなく、他人に言われてやっているようでは駄目なものであり、つまりは他人の分際で口を出しても詮無き事なのである。ほぼ、自分と同化している様な人の意見ならば届くかもしれないけども。
趣味とは才能である、と言い換えることも出来るかもしれない。才能にうだうだ言っても仕方ない。そういうものだから。
ここ最近、気温の上下が驚くほど激しい。桜が咲いたかと思えば雪が降る。体調には気をつけなくてはならないところだが、うちの親父が三九度の熱を出して寝込んでしまった。しかも腹に来たようでトイレにこもる時間も長かった。実に大変である。
本当、気をつけないとね。