ボタンとINSERT文

PHPとMySQLを使った、Webの開発、ちょっと前まで何ら問題なく動いていたのに、ページのデザインをいろいろ凝ったものに変えたり、プログラムにいろいろ機能追加したりしているうちに、問題が出てきた。

画面上の[追加]ボタンをクリックするとテーブルに１レコードをINSERTするという仕組みなのだが、１回のクリックでなぜか２レコードが追加されてしまう。

プログラムが以前よりややこしくなってきたので、もしかしたらループ処理の中にINSERT文を入れてしまったのではないかと、処理の途中にトレース用の適当なprint文を書いて実行回数を調べてみる。でも確かに１回しか処理されていないようだ。

MySQL単体で同一のSQL文を発行しても正常にINSERTされるし、MySQL専門の書籍でINSERT関係の命令を見てもこれといったものは書いていない。データベース側の問題ではないようだ。そもそもそんな複雑なSQLではないので、そこで間違いがあれば見つけられるレベルの内容だ。

PHPのプログラムを念入りに調べても問題なく、MySQLの問題でもないとすると、見えないところで[追加]ボタンの１クリックで、Webサーバーに対して２回のリクエストが発行されている可能性がある。


その点に目星を付けてネットで調べてみた。
すると、やはりそのような現象が起こることが分かった。原因は、PHPというよりもHTMLの作りに問題があった。

一番初めは、単純に[追加]という標題を表示するボタンで、「<INPUT type="submit"・・・・」というのを使っていたのだが、ちょっと凝った見栄えにしようとして、「<INPUT type="image"・・・・」に変えていた。これは文字ではなく画像をボタンとして表示するためのもの。それがすべての原因だったようだ。

調べたところによると、「<INPUT type="image"・・・・」を使ってフォームをPOSTすると、２回リクエストがWebサーバーに飛んで行ってしまうそうだ。そしてそれはHTMLの仕様に問題があるわけではなく、どうやらIEのバグらしい（他のブラウザでの確認はしていないが...）。情報源では数年前のバグとなっていたが、それは最近のIEでも解決されていないようだ。

結局、「<INPUT type="image"・・・・」はやめて、「<BUTTON・・・・><IMG src="・・・"></BUTTON>」という表記を使って、見た目はイメージボタンのようになるように変更した。この変更だけで問題は完全解決。
ただ、マウスをイメージの上に持っていったとき、よくリンクのときに表示される指差しのポインタに変わらないのがちょっとした玉にキズという感じだが、機能優先ということでそれくらいは我慢だ。


それにしても、そういった特定の状態でも起こる問題については、なかなか本には書いてない。もしかしたら手持ちのHTMLやPHP関連の本でも全部探せばどこかに載っていたかもしれないが、それを探し出すのはあまりにも無謀だ。
そういった意味では、トラブル解決にインターネットはやはり欠かせないものだとつくづく思った次第.....。

PHPの条件判断

PHPのプログラムに不穏な感じの動きが見つかった。

変数aが真か偽か判断して条件分岐する際、次のように書くことができる。

if (a) {

if (!a){

それぞれ「aが真だったら」、「aが偽だったら」という意味。これはVBAでも同じような表記ができる（Not a のように）。

ほとんどの場合、いや、これまではすべてにおいてこれでうまく動いていた。

しかし、たまたま、確実に偽であるにも関わらず、真の場合の処理が実行されてしまう、正確に言うと「実行されてしまうこともある」という非常に不安定な処理フローが発生することが分かった。

そこはちょうど、真だったらデータベースにINSERTするという処理だったため、SQLの書き方が悪いのではないかとか、データベースエンジン側に何か問題があるのだろうかといろいろ考えてしまった。
プログラム側が悪いのかそれともデータベースが悪いのか？、原因を広げ過ぎたため、さまざまな検証を行う。さまざまにプログラムを部分変更して試してみる。


たった１ヶ所だけのために何時間か浪費した末、意外なプログラム修正を行うことで解決できた。

それはあまりにも簡単な変更。
if文の条件式「(a)」を「(a == true)」と書き替えただけ。
「(a)」でも文法的には間違っていないハズだし、今までそれでトラブったことはない。
それに、問題のあった行のすぐ上辺りでも同様の書き方で問題なく処理されているのだ。
どうしてそこだけダメなのかまったく分からない。

とはいえ、それ以上原因究明する必要もないし、その気もない。
とりあえず「結果オーライ」ということで、それで走らせることにする。


100%の完璧な解決策でなくても、とりあえず回避するための代替案を持っていればなんとかなるものだと思うし、そんなもんでいいんじゃないかと気楽に考えているが、そこに行き着く時間はけっして無視できない。
代替えの方法を次々と思い浮かべる力はやはり重要だし、それもノウハウや経験のうちだろうか？。

あまりに古いテクニック

ときどき、ハードディスク上のフォルダやファイル名などをテキストでリスト化してファイルに保存したいときがある。
その手のツールはフリーでもいろいろあるようだが、常に使うといったものがなく、結局のところどうするかというと「DOSのコマンド」を使う。具体的には「Dir」コマンド。

コマンドプロンプトから「Dir」と打ち込んでEnterキーを押すと、カレントフォルダのファイルやフォルダの一覧が画面上に表示される。さらに、「Dir > dir.txt」のように打ち込めば、本来画面に出力されるデータを「dir.txt」というテキストファイルに出力することができる（リダイレクトという方法）。
また、作成日時なども出力されて邪魔な時には、テキストエディタで後で編集してもよいのだが、「/b」オプションを付けてDirコマンドを実行すれば”ファイル名のみ”あるいは”フォルダ名”のみリスト化することもできる。他のオプションを利用すれば再帰的にサブフォルダも検索することもできる。


コマンドプロンプト自体、自分もめったに使うものでもないし、中には一度も使ったことのない人も多いかもしれない。
ただ、パソコンを使い始めた頃の手法が頭に染み込んでいるせいか、そういった場面では真っ先にそのような方法が頭に浮かぶ。たいてい一度ぽっきりの利用なので、フリーのソフトを探すのも面倒なので、ついつい使ってしまう。

でも考えてみると、この方法は実に古い、というより古くからあるテクニックだ。なぜなら、もう20年以上も前、WindowsのようなGUI環境がなかったころ、パソコンの入門書などを買うと真っ先に覚えさせられるのがこのコマンドだからだ。今で言ったら、マイコンピュータやエクスプローラの画面の使い方を説明するのと同じような感覚でまずはこのコマンドを誰もが最初に覚えたものだ。また、それを知らないとハードディスク（いや正確にはフロッピーディスクと言った方がよいかもしれない）の中を確認することさえできない。

そんな古い方法を未だに使うのもどうかとは思うが、それでも役に立つのは間違いないわけで、いざというとき、DOSのいろいろなコマンドを知っていてよかったなあとも思うことも多い。古かろうが新しかろうが、役に立てば何でもよい！。

Webでの文字コード

昔は、半角は１バイト/全角は２バイトというのが常識で、文字数を数えたり、データベースのフィールドに保存できる長さを計算したりするのが面倒だったが、最近は”バイト”という言葉自体聞かなくなったような気がする。

Accessの場合、今は文字コードがUnicodeで半角/全角問わず処理できるようになっており、テーブル設計上も気にすることはないし、VBAのプログラムで文字列の切り出しを行ったりする際もめったに気に掛ける必要はない。Mid$関数はちょくちょく使っても、MidB$関数はそうそう使う機会はない。


一方、Web関係の開発ではそういった文字コードは常に悩みの種だ。

Windows標準のShift-JISもあれば、EUCもある。ASP.NETはUTFだし、メールはISO-2022だし.....。

よ〜く文字コードを配慮しないと文字化けとの戦いが終わらない。しかしうまく対処すれば一切文字化けに会うこともない。
ファイルの保存形式とか、データベースの保存形式とか、フィールドごとの保存形式とか、HTML上のMETAタグの指定方法とか、あるいは文字コード変換の関数の利用とか、配慮すべきことは多いが、それらをうまく整理しながら考えなければならない。常に文字コードは頭のどこかに入れておく必要がある。

半角文字でも全角文字でも一切悩まなくてもいいような、画期的なキャラクタ体系でも登場してほしいものだ。

開発言語の切り替え

PHP関連のソフト開発、PHP関連の執筆と、なぜかここのところPHPだらけになっている。

基本的にはどんな言語でプログラムを書こうとあまり変わらない。大まかな書き方の基準は全然違ったりするが、要領さえつかめば、関数を呼び出したり、ループ処理や分岐処理など、けっこう似ているものだ。

横通しで見てみると、似たような目的に使う関数は結構そのネーミングも似ている。よって、瞬時に頭を切り替えるとは行かないまでも、往々にして複数の言語を行き来するのはそれほどは苦ではない。

ただ、やはり違うのは、一方にはあって一方にはない関数類。たとえばVBAならオリジナルのFunctionプロシージャを作らなければならないような処理が、PHPなら標準関数で処理できたりする。PHPならライブラリの関数を使えばよいところ、VBAではWindows APIを使わないといけなかったりする。そういったものはやはり普段からガンガン使う関数ではないので、ついつい忘れがちになる。

そのようなときは、最低限、いわゆる関数などのリファレンス本をざっとでもいいから一度目を通すと非常に参考になる。よくよく見てみると使ったことのある関数なのだが、頭の中ではすっかり忘れていたものも発見したりする。

ただ、やはり根本的に違うこともある。VBAでは普通にイベントドリブンのプログラムを書いていけばよいが、PHPあるいはASP.NETなどはWebアプリケーション特有の仕組みがあるので、ポストバックなどの動作を配慮しなければいけない。また、Webアプリの場合はHTMLとかCSSとかJavaScriptなどの知識も総動員しなければいけないので、おのずと範囲が広くなってしまう。経験的にある程度は対応可能だが、そういった周辺の知識もはじめに一度は復習しておいた方がよいようだ。


ところで、新規開発とはいっても、けっこう以前使ったオリジナルの関数とか全体的な仕組みなどを再利用する場面は多いものだ。そんなとき、ASP.NETとPHPではそうでもないのだが、VBAとPHPでは大きな開きがある。
というのは、Access VBAの場合ならVBAのコードはMDBファイルもしくはACCDBファイルの中に包含されているので、簡単にディスク上を検索してピックアップするということができない。データベースファイルをいちいち開いてから、VBEで検索を掛けるような探し方が必要となる。
それに対してPHPは簡単だ。エクスプローラなどからも検索できるし、テキストエディタのGREP検索の機能も利用できる。PHPファイルが単独で存在しかつテキストファイルとして保存されているからだ。
よくそういったプログラム部品の再利用では”クラスの利用”とかいう言葉が出てくるが、過去に自分の使った一連のプログラムをそっくり利用するのも開発効率面で大切なことなので、そういった意味ではPHPの方が楽といえば楽かもしれない。


そういえば、最近はすっかりDelphiやVB.NETはご無沙汰だ。趣味でいじるほどの時間的余裕もないし、また特段の興味もない。その上、DelphiやVB.NETを指定しての受託開発は皆無なので、ほぼ忘れつつある。
VB.NETはまだVBAと通じるところもあるしASP.NETとも通じるところもあるのだが、Delphiはまったく別次元なので、今すぐやれと言われても相当復習しないといけないだろう。

ちなみに、Dephi for PHP というがあって、非常に興味があるところだが、PHPでありながらかなり違う感じの開発スタイルなので、実務で使うかどうか分からないのにトライしてみようという気にはちょっとならない。
EclipseでのPHP開発も取っつきにくいし、結局は”古いやり方”と揶揄されようと、テキストエディタで書くのが一番快適に感じている。

InputMan試用感

昨日、GrapeCityから「InputMan for ASP.NET」という入力コンポーネント発売のお知らせメールが来た。
VB時代から「InputMan」は馴染みのあるコンポーネントであり自分も使ったことがあるし、「InputMan for ASP.NET」があることも概要としては知っていたが、今回は昼休みを使ってちょっとだけデモ用の画面をいじってみた。

気づいた点としては、

• 漢字（全角）入力指定のテキストボックスに半角１文字入力すると、ポストすることなく赤いエラーメッセージ文が表示される、警告アイコンが表示される、警告ポップアップヒントが表示される
  
• ひらがな入力欄で英数字を入力すると、自動的に英数字が除去される
  
• カーソル移動で自動的に入力内容のヒントが表示される
  
• Accessでいうところの定型入力の設定が可能
  
• 日付入力用コンボボックスをドロップダウンさせるとカレンダが表示される
  
• コンボボックスの代わりにスピンボタンで選択項目を切り替えられる
  
• 入力必須項目を未入力でポストするとその旨のメッセージが表示されるが、入力すると自動的にそのメッセージが消える
  
• Enterキーや矢印キーなどでもフォーカス移動できる
  

ほんの数分いじってみただけで、機能説明文などをよく読んだわけではないのだが、おそらく他にも非常に多くの機能が使えることは間違いない！。

一般のアプリケーションと同様の入力操作性がWebでも実現できる、またこのコンポーネントを使わない場合はASP.NETの独自プログラムもしくはJavaScriptなどを多用しなければいけないようなことがプロパティ設定一発でできるということで、魅力的な製品であることは間違いないと思う。

個人的には現在そのようなものを使って開発するような案件はないが、機会があればぜひ一度は使ってみたいコンポーネントだ。

受託開発における保証期間

受託開発において、契約時に保証期間を求められることがある。
もちろん、出来たらほったらかしではなく、あとまで面倒を見て欲しいということだと思うが、それを盾にされ、とんでもない手離れの悪い事態になってしまうこともある。

納入時はまったくテストしてくれず、いきなり本番運用を始めてしまい、数週間あるいは数カ月に渡って、チョロチョロと「あれがない」、「あれが違う」、「あの機能も必要」となり、しまいには要求仕様になかったものまで「あれがあると便利なので付けてくれ」ということさえある。しかも「保証期間中だろ」と言うからまたたちが悪い。

まぁよほど時間がかかるものでなければ対応するが、「納入時に一通りチェックしてくれれば”お互いに”もっと楽だったのに！」と思うことも少なくない。

正直、保証期間を要求する人ほど、真剣にテストしようという意識が希薄だし、適当に運用を始めてしまうし、実運用で困ったら直させればいいやという感じ。本当は、それはお互いにとって損なんだけど......。

ということで、期間を決めて、「その間に不具合や変更要望がなければあとは知らない」と言っておいた方が真剣にチェックくれるようだ。

とは言っても、現実的には、たとえ一年経とうが不具合が見つかればきちんと対応しているつもり......。

「InputMan」試用

GrapeCityの「InputMan」、Web環境での動作をデモページで試用してみた。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
■豊富な書式設定
日付、数値、テキストなどの入力目的ごとに最適化した数多くの書式スタイルを設定でき、エンドユーザーに正確な入力を促します。

■強力な入力チェック機能
コントロールに搭載されたエラーハンドリング機能により、指定した書式以外の文字や、範囲外の日付や数値が入力されると、エラーチェックのコーディングなしで不正入力を検出できます。

■日本仕様の機能
和暦による日付の表示と入力、漢数字の表示、バイト単位での入力文字数を認識、またIMEモードを制御するなど、日本仕様の多彩な機能をサポートしています。

■ショートカットキー
コントロールの内容のクリア、フォーカス移動やコントロール内のフィールド移動、日付や数値の値増減、ドロップダウンオブジェクトの表示など、さまざまな動作を任意のキーに割り付けることができ、エンドユーザーの操作性を補助します。

■クライアントスクリプトの充実
標準でサポートされているクライアント側イベントの他、独自のスクリプトも搭載しています。サーバーへのポストバックなしで、プロパティ設定やイベント処理を行うことができます。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

InputManの付き合いは、長くはないが古い。もう10年以上前になるが、VBの５か６の頃、Windowsアプリケーションの開発に用いたことがある。もちろん当時はWebコントロールではなく、通常のWindowsフォームでの使用。
VBのテキストボックスの機能は何かとシンプルで貧弱なので、書式設定も入力チェックも、入力制限もコーディングを要し面倒だったが、このInputManのおかげでそれらがプロパティ設定のみで実現でき、かなり生産性が上がったように思う。

ただ、当時は、開発時のデザイン系の作業がどうもスムースに動かず、ちょっと厄介な思いをした記憶がある。完成してからの動作については問題ないのだが、デザイン時にコントロールを少しずらすと再調整が面倒だったり、何かちょっとした設定変更でまたはじめからやり直しということが多かったような記憶がある（定かではないが）。

また当時の記憶では、Accessのテキストボックスコントロールが持っていないような、たとえば入力範囲の制限（はじめから範囲外の値をキーインできないようにする）などもプロパティだけで設定できるといった便利なところも確かにいくつかあった（AccessでもVBAで可能だが）。
しかし全般的には、やはりAccessの方が軽い動作でサクサクとデザイン作業を進められるなという印象が強かったように思う。そのときは環境等の制約でVBでの開発ではあったが、やはりインタフェース類についてはAccessがよいと再認識させられたのもその頃だったと思う。それに、VBの場合はやはりInputManのようなものを買って用意しておかないと能率面ではかなり不利になると思うが、Accessならコントロールを買わなくてもそれなりの機能が使えた、というのも自分としては”Access＞VB”と感じる一要素でもある。

ただ、それから10年以上経っている。InputManも相当進化しているはずだ。また、Web開発でも使えるというのも大きなメリット。通常のHTMLだけのテキストボックスと比較すれば、その機能たるや雲泥の差、利用価値はWinアプリに比べてかなり高いのだろうと思う。

Silverlight

『本格的なリッチアプリケーションの開発を可能にするSilverlight2の提供が開始されました』
『動画や音声、アニメーションなどのメディアコンテンツ配信の機能を強化』
『Web上でこれまでにないインタラクティビティを実現するDeep Zoomを実装』
『サーバーサイドと高度に連携したアプリケーションの構築を可能にするさまざまな新機能』
『アプリケーションの開発にはVisual BasicやC#などの.NET言語の活用が可能』

Webアプリの開発に.NETの知識が使えるのは大変ありがたいことだし、”リッチ”なのはよく分かるのだが、Silverlightで作られたページを見てみるとやたらと重い印象があった。リッチだから重いのかどうか分からない、たまたまネットが遅かったのか分からない。ただ「これはすごいことができる！」という印象はなかった。まだまだ知識不足だからだろうか？。

今のところ、使う側というより、作る側として”いろいろできる”というメリットの情報の方が多いので、もうちょっといろいろ見てみようと思う。

Report Builder使えそう？

Microsoftから、SQL Server2008と連携できるレポート作成ツール「Report Builder 2.0 日本語版」が提供されるそうだ。無償提供のツール。

SQL Serverについては、どのバージョンからかは覚えていないが、”レポーティングツール”がこれまでも提供されていた。フォームツールというのはないようだし、データベース＋レポートのみのシステム構成というのもあまり個人的には開発を請け負うこともないので、使ってみたことはない。定型業務のシステム開発向けというより、エンドユーザーが非定型でレポート作成するような用途が多いだろうか？。それでもそれらは確か”デベロッパー向け”ということで提供されていたように思う。

しかし、Report Builderは若干それらとは毛色が違うようだ。”一般ユーザー向け”と謳っているし、何よりもレポート作成のインタフェースが特長的だ（ただし実際に使ってみたわけではなく、プレスリリースなどで見ただけ）。Office2007ではお馴染みのリボンを使ったインタフェースになっている。そしてSQL文を知らなくてもクエリを作れるウィザードも付いているということ。
そう、見た目や機能はAccess2007のレポート作成と酷似している印象が強い。さらに、多次元の表、グラフやゲージを使ったレポートも作れるそうで、聞くだけではAccess2007のレポートの上を行っているかも？。

ただ、この手のツールはやはり使ってみないと分からない部分も多々ある。
SQL ServerとAccessは兄弟のような印象がある一方、各種ツールとか使ってみると、”同じMicrosoft製？”と思ってしまうところも少なくない。同じAccessでも、MDBとADPの作り方の違いを見てみればよく分かる。なので、”リボンを使っている”、”Accessに見た目が似ている”、”DBを使ってレポートを作れる”というだけでは、Accessを使い慣れた人がスムースにそちらのツールを使えるかどうかは何とも言えない。
VB系のレポーティングツールでは「宣伝文句に乗せられて買ってはみたものの使いづらくてしょうがいない」、「Accessの方がはるかに使いやすい」という経験もある。無償提供ということなので、やはりまずは試用してみるのが一番だと思う。

XDev2008参加

昨日、「X-over Development Conference 2008」、通称「XDev2008」の一日目のセッション３つを聴講してきた。
「サーバサイド開発最新事情 2008」、「ADO.NET Entity Framework 概念モデルによる次世代データアクセス テクノロジ」、「ビジュアル操作でWebフォトギャラリーを作成！Delphi for PHP開発術」の３つ。

中味はもちろんこの時期にあった最新情報ではあるが、やはり40分程度の話しではなかなか表面的なことしか触れられず、技術紹介的な内容にとどまるを得ないという感じ。雑誌記事のちょっと詳細版という感じだったことは否めない。あえて東京まで出向くほどのことはなかったような.....。

「サーバサイド開発最新事情 2008」については、いつもWeb開発の著書で勉強させてもらっている山田祥寛氏の講演。中身はもちろん最新の状況を再確認することができ参考にはなったのだが、その最新技術個々がどのような特徴がありどのようにプログラミングに応用するのかということまでは触れられない、というより時間的に突っ込みようがないという感じだったので、時間不足がネックだったように思う。

「ADO.NET・・・・」については、完全にうたた寝モードになってしまった。後半は記憶なし.....。

「Delphi for PHP」については、すでにネットでデモンストレーションの動画を見ているので、それを実演で再確認できたといった程度か？。確かに、テキストエディタでガリガリとコードを書くよりはWIGSYG環境はすばらしいという印象。ただ、開発時のHTMLなどとの絡み、WIGSYGでのデザイン以外のコーディングなどを考えると、ちょっとASP.NETの方がよいかなという印象もあった。
ASP.NETはじっくり使い込んでいるし、Delphi for PHPは全然使っていないので、それを自分が比較するのは申し訳ないことだが、今回はのデモだけでは”ASP.NETよりDelphi for PHPだ！”と決定的に思うには至らない。
「VB.NET経験者がASP.NETを始める」、「PHP経験者がDelphi for PHPを始める」あるいは「Delphi経験者がDelphi for PHPを始める」という３つを比較した場合、やはり「VB.NET経験者がASP.NETを始める」のが一番分かりやすいような気がする。ただしあくまでも40分の説明での印象なので、そこは注意。
もし２つのどちかを開発環境として採用するかを検討する際には、表面的なメリットの説明を読むだけでなく、やはり両方をじっくり使い込んでから判断した方がよいように感じた。

今年のAccess開発の仕事

先週、あるAccess開発の仕事、とりあえず完了。お客様サイドの検証待ち状態に入る。

今回の場合はかなり小規模なカスタマイズという範疇の作業。そういった場合、”どこをどう変更してどう動作すればOK”という作業のポイントが非常に明確なので、作る側もテストする側もかなり楽。終わったあとの気分もかなりすっきりするという感じ。

ただ、業務分析とかデータベースの設計など、基本的なところから入る開発はもう半年程度していない。
考えてみると、今年は執筆が本当にメインだった。ところどころ合間にAccessの開発が入る感じで、受託開発の比率は極端に少ない年だ。ただ考え様によっては、極端にオーバーロードになる程でもないし、かといって何週間も暇になることもないし、ある意味それなりにちょうどよい充実した仕事の負荷だったようにも思う。

CMSのオープンソース、いろいろあるけど.....

最近は何かと話題の多いオープンソース。CMS（コンテンツマネジメントシステム）系では、MovableType、GeekLog、WordPress辺りが人気のよう。

CMSということなので、一般的な投稿とか、テンプレートの差し替えでできるようなカスタマイズに関しては、おそらく（あくまでも推測）それほどは大きな違いはないのではないだろうか？。もちろん管理者用のページが操作しやすかったり、ドキュメントなどの情報が豊富あるいは分かりやすかったり、動作スピードが違ったりと、違いは当然ないわけではないが....（特に書籍の量では完全にMovableTypeが圧勝という感じ）。

ただ、本格的にカスタマイズするとなると、その違いはかなり出てくるようだ。開発言語的なこと、ソースの分かりやすさ、システム構造の分かりやすさ、プラグインやテンプレートの数など、その要因は多々ある。

自分の場合、もしやるとなると、やはり言語的なところが重要なポイントかもしれない。PHPで作られているものがやはり良いなあと思う。難しい専用タグを覚えるよりは、PHPソースをいじってしまった方が速い場合もあるかもしれないし、コードからシステム構造を理解しやすいといったこともあると思う。また、別の次元では、ソースを見ることによってPHP自体の勉強にもなるかもしれない。

その点でいうと、JavaとかPerlで作られたものは、たとえソース公開であっても手が出せないと思う。出せたとしても、ほんの片隅をツツクくらい？。それでも話題性の高いMovableTypeが一番興味はあるのだが....。

ブログのデータをPHPで１行表示

T'sWareサイト（http://www.tsware.jp/）のトップページにあるSOHOの散歩道の”一行表示”。従来はCGIの日記ソフトのデータの１件目を直接読み込んで表示していた。もちろんCGIのプログラムを組んで。

一方、ブログに移行したあと。当初は両方を持ちながらダブルで毎日更新という考えがあったが、よく考えみたらブログ側の機能として最近の投稿内容をRSSで提供してくれるようになっている。なので、PHPを使ってそのRSS（内部的にはXML）を読み込んでそこの１件目のデータだけを出力するようなプログラムを作ってみた。とりあえず動いているようだが、しばらく様子見。

まあ言ってみればブログをひとつ立ち上げただけだが、あの手この手でいろいろなことができるものだと思う。

オープンソース増えましたね？

オープンソース、世の中にはどんどん増えている。昔に比べて関連書籍も多い。「これからは自分で作る時代ではない、オープンソースをカスタマイズして使う時代」なんて声も聞こえてきそうだが、カスタマイズもピンからキリ。簡単なものはそれこそ管理者用のページで済ませられるが、高度なものならHTMLはもちろんのこと、PHPなどの言語の知識も必要となる。さらに英語で書かれたコメントを頼りにあるいはコメントがないものも多いので、ソースを解析する力が必要となる。これって意外と楽ではない。そういったことを考慮すると、オープンソースとかプラグインとか追加モジュールといったもので自分の希望のものが完全に実現できるならよいが、そうでないなら必ずしもすべて自分で作るというのはマイナス点ばかりではなく、やはり選択肢として大いに考えるべきと思う。

ところで、Web系のオープンソースを選定する際の条件のひとつとして、海外製かどうかはちょっと検討すべき点なようだ。海外で多く使われているということは、それだけ多くのユーザーがいるということ。当然その内容を熟知しているハッカーも多くなる。よって海外製のオープンソースを設置すると、英文のスパム的投稿がガンガン来たりする。これは自分もXOOPSで経験済み。その際の対応策もまたカスタマイズ作業によって必要になる。

ちなみにXOOPSの場合、module（？）というディレクトリにモジュールが置かれるので、PHPのソースを書き換えてmoduleという名前ではない場所で動作させる、さらにプログラムのファイル名もデフォルトのまま使わず意図的に別名にする、といった小細工が必要なようだ。

コンピュータ用語の発音

「Access」をどう発音するか？、アクセス→、ア↓クセス、どちら？。「Excel」をどう発音するか？、「フォーム」をどう発音するか？、「オブジェクト」をどう発音するか？、決してテレビでよく耳にする言葉ではないので、けっこうみんな好き勝手発音しているのではないかと思う。こういった発音、Microsoftのセミナーにいったり、ネットで入手可能なデモのビデオなどを見ると、自分がふだんしている発音と違っていてドキッとすることがある。でもいろいろ見るうちにみんなが必ずしも同じでないことにも気が付く。

また、VBAのオブジェクト名やプロパティ名、あるいは関数名などは、なおさら公式な発音を耳にする機会は少ない。これは発音やイントネーション以前に、読み方自体がいい加減になっていることも少なくないのでは？。自分の場合すぐに思いつくのは「False」の読み方。おそらく正しくは「フォルス」だとは思うが、「ファルセ」といったり「フォルゼ」といったり、とにかく適当！。最後にはどれが本来の読み方だったかも忘れてしまうことがある。まあ、コードを書いているだけならどれでも関係ないのだが、人と話すときは注意しないと恥をかく。

Eclipseを使ったPHP開発

Eclipseを使ったPHP開発、プロジェクトの管理、ソースの編集に関してはなかなかよい感じ。でも「これはいい！これからはこの環境だ！」と思えるほど強い印象は受けない。ほんの数時間の試用で良し悪しを判断してはいけないが、何かに付けてすんなりと動いてくれないというのが印象。自分にあった環境を構築するためにはさまざまな設定を行っていかなければいけないのだとは思うし、それができるかどうかも技術のうちだとは思う。でもデフォルトの設定ではすれがスムースにはいかない。その点に関しては、やはりPHP専用でかつ有償ということもあり、Zend Studioの方がぜんぜん簡単にとりあえずの導入ができるという印象。内部的なデバッガもこちらの方が強力ではないか？（そういえば最近、Zend Studioも最新バージョンではEclipseのプラグイン化したようだ、セットアップの簡便性、実際の開発機能・デバッグ機能はどんなものだろうか、気になるところ）。

とはいえ、Zend Studioも試用版を使ったことしかなく、本格的に開発に使うに至っていない。結局のところ、慣れ親しんだ秀丸エディタに行き着いてしまう。あとはプロジェクトエクスプローラのような機能があれば秀丸は文句なしなのだが......もしかしたらアドインであるのか？。

Eclipseを使ったPHP開発

PHPの開発、自分はもっぱら原始的な方法、テキストエディタ中心だが、最近はいろいろ開発環境が出てきている。DelphiでもPHP用のエディションがあり、ASP.NETと同じような感覚で、コントロールを使ってWebページの外観的デザインができる。もちろん開発言語はPHP。

一方、Javaの開発環境で有名なEclipseでも、PHP用のプラグインをいろいろ用いることによって、PHPの開発環境が整う。デバッガも使えるし、無料ということなので、ちょっと試してみることにした。

Eclipse本体をまずインストールしてプラグインをいろいろ追加していく方法もあるが、PHPの開発や日本語環境に必要なものがすべてオールインワンパッケージ化されたものがネットで入手できるので、それを使ってみた。

パッケージ化されているので、面倒な設定は必要なく、簡単にセットアップできた。しかし微妙にバージョンが新しくなっているせいか、手元にある教科書通りには動作しない。PHPのコードを書いて実行させても、ブラウザは真っ白だし、そもそも内部ブラウザが起動しない。Apacheのhttpdconfまでいじってやっと実行できたものの、デバッガは動作しない。たぶん設定もしくは操作、何か自分が悪いのだとは思うが.....。

XAMPPの試用状況

XAMPPの試用状況。XAMPPのさらにすばらしいところは、PHP5とPHP4の両方がいっしょにセットアップできるという点。ただ、単に画面でボタンをクリックすれば変わるというものではない。http://www.apachefriends.org/jp/xampp-windows.html の説明によると、「両バージョンの切り替えには"php-switch.bat" ($path-to-xampp\xampp\php-switch.bat) を使用してください。」とある。

これを実行してみる。でもphp.exeが見つかりませんといったようなメッセージが出てしまう。

そこでこの.batの中味を見てみると、「if exist php\php.exe GOTO Normal」という命令があることが分かる。”php\php.exeファイルが存在していたらNormalというラベルにジャンプしなさい”という命令だ。ということは、カレントディレクトリからみて”php\php.exe”なので、このバッチファイルが保存されているフォルダにまず移動しなければならない。他のフォルダがカレントになっている状態からフルパス指定でこのファイルを呼び出してもダメということ。

その点を踏まえて、コマンドプロンプトでまず「CD」を実行してからこのバッチファイルを実行。今度はうまくいった。うまく動作すると、”バージョンを４に変更したいなら「４」と入力しないさい”といったようなメッセージが出るので、その通りに入力してEnter。何かファイルのコピーらしき処理が行われて、うまく切り替え完了。phpinfo()で確認すると確かに変わっていることが確認できた。

XAMPPの試用状況

XAMPP、ちょっといくつか問題発生。「XAMPP コントロールパネルアプリケーション」を開くと、本来はそこからApacheやMySQLのサービスの開始/停止をコントロールできるはずなのだが、エラーとなってしまい特に反応なし。調べたところ、まだ完全にVistaに対応していないのが原因らしい。多少面倒ではあるが、それらのサービスの再起動や停止にはWindowsのサービスのコンソールを使う。そちらを使えば確実にサービスを操作できる。

一方、これはXAMPPとは直接関係ないことだが、従来うまくレンタルサーバー上では動いていた.htmさえサーバーエラーとなって動かないところがあることが分かった。「Server error! サーバ内部で障害が発生し、 リクエストに応えることができませんでした。 サーバが過負荷であるか、 CGI スクリプトにエラーがあります。 Error 500」というエラーが発生する。

サーバー上にあるファイルのいくつかを一時的に除外してシンプルなファイル構成で調査していったところ、.htaccessファイルの存在がエラーを発生されていることが判明。Apacheのエラーログには「C:/xampp/htdocs/******/.htaccess: Invalid command 'RewriteEngine', perhaps misspelled or defined by a module not included in the server configuration」と出力されている。どうやら要するにRewriteEngineを処理するモジュールがApacheに組み込まれていないことが原因のようだ。

そこで、httpd.confを編集。「#LoadModule rewrite_module modules/mod_rewrite.so」とある部分の「#」、つまりコメントを外してこれを保存。Apacheを再起動すると今度はうまくいった。なんだかんだいっても、やはりhttpd.confとかphp.iniをいじることは必要なようだ。