永田順伸のブログ

osCommerの商品画面で、オプションを選択すると価格計算がリアルタイムに再計算される機能を作成した。
まず、osCommerceのオプション機能を拡張して、商品詳細画面にJavaScriptで作成された処理を追加した。これらはPHPで自動生成される。

購入者が、商品のオプションを選択すると、合計が再計算され、同時に現在選択されているオプション名が瞬時に切り替わるようにした。
PHPやDB、JavaScriptの部分も同時に考えて作成しなければと難しく考えすぎて時間がかかった。
DOMの処理によってはブラウザごとに動作が違うことがあったため、さらに混乱したが、JavaScriptで使用するデータの構造を工夫することで、ブラウザ依存の処理も回避でき、後半は意外とすんなりと完成した。

オプションの選択方法をラジオボタンとプルダウンメニューにしたが、オプションの値の取得方法で時間がかかった。

取得した値を表示させる方法もはじめは戸惑った。
            obj.appendChild(textNode);

            obj.removeChild(obj.lastChild); // 末尾の子要素を削除
            obj.appendChild(textNode);

 こんな感じで表示を更新できた。
子要素があるかどうかは、
        if(!obj.firstChild){ // 子ノードがない場合に実行

などとするだけ。
価格の円マークは半角ではエラーがでるため、また後々面倒なことになりそうな気がしたので、全角の￥で代用した。

去年から作業している仕事を仕上げているところだ。
この作業が終わると何もなくなると思ったら、ちょっと不安を感じた。
少し営業もしておこうと作業の合間にやってみた。
私の営業方法は、普通の営業と違って歩き回ることはなく、Googleで検索して、メールを送信するだけ。
これはというサイトを探して、サイト内をくまなく閲覧して、修正ポイントを探る。
この方法で、去年までは数通メールを送付するとその日の内に連絡があったものだが今年は反応がまったくない。
不吉なことに、これまでに作業したことがあるお客様からも今年に入ってからほとんどメールが届かなくなった。
メールサーバが中継拒否されているのかもしれないが、
リーマンショックがかなり遅れてここまで来たというのが正しいのかもしれない。

もう少しで2008年も終わろうという頃、
長年お世話になっているお客様から電話があった。
osCommerceがここ何週間か非常に重くて1日に何度も画面が表示できないことがあるという。
topコマンドで確認してみるとMySQLが常に一番上に居座っている状態。
アクセス数などを確認してみたがそちらは問題ない状況だった。
MySQLにslowlogを設定して確認してみたところ、ある処理に12秒もかかっていた。
問題のテーブルを確認するとインデックスがない。
インデックスを追加すると、負荷は半分ほど低下した。さらに処理速度を確認しながら別のテーブルにもインデックスを追加した。その後に、テーブルを最適化したり、MySQLの設定をチューニングしたら、見違えるほど高速になった。レンタルサーバには使用していないアプリが動作していることがある。このサーバでもTomcatが動作していて、メモリを無駄に使っていたのでそちらを停止して、MySQLに余分に割り当てた。
ハードを上位機種にするとそれだけでも高速になるので、このチューニングは無駄だと考えられるお客様が多いが、チューニングは必要だと実感した。
今回、問題になったのは注文関係のテーブルだ。
長年、osCommerceで営業を続け、ある程度の売上がコンスタントにあるサイトだったため、注文関連テーブルに保存されたデータ量が膨大になりとうとう限界がきたということだと思う。
考えてみれば当たり前のことだが、予想外な原因で驚いた。
(also_purchased_products.phpで商品を表示して、ページキャッシュを使用していないとさらに遅くなります。　2009/01/26追加)

MySQLのパフォーマンスチューニングは面白いですね。
作業のご依頼があれば喜んでお引き受けします。
詳細を教えていただければお見積もりいたします。
(何件かお問い合わせをいただいています。ありがとうございます。　2009/01/26追加)

というわけで、
今年もよろしお願いします。

楽天APIを使って商品を検索する機能を作った。
データの取得はいろなサイトのサンプルを参考にすると意外に簡単に実現できる。
手間取ったのは検索数の取得だ。
simplexml_load_string関数で$xmlにデータを格納できたら、
$xml->Body->ItemSearch->Items->Item[0]->itemName
などのようにして商品名は確認できる。
検索数はcountというフィールド名にあることは出力パラメータからわかっているが、
$xml->Body->ItemSearch->Items->countとしても何もない。
リクエストＵＲＬを作成して、ブラウザで結果を表示させると名前空間が違うことがわかった。

$xml->Body->ItemSearch->count

として、結果をvar_dump関数で確認すると、

object(SimpleXMLElement)#7 (1) {
  [0]=>
  string(4) “6206″
}

と表示される。

print $xml->Body->ItemSearch->count;

では、6206だけが表示される。
念のため、

$count =  (string)($xml->Body->ItemSearch->count);

として検索数を取得できた。

// PHP5
$tmpData = file_get_contents(’ここに楽天APIの形式のURLを記述’);
$tmpData = str_replace(’header:Header’, ‘Header’, $tmpData);
$tmpData = str_replace(’itemSearch:ItemSearch’, ‘ItemSearch’, $tmpData);
$xml = simplexml_load_string($tmpData);

// 検索数を取得
$count =  (string)($xml->Body->ItemSearch->count);

WZ EDITOR が5から6へバージョンアップした。
正規ユーザなので優待販売のお知らせが届いた。しばらく待ってからにしようと思っていたが、期待や応援の意味も込めてすぐに購入した。

WZエディターはバージョン5を現在も使用しているが私には決して使いやすいものではなかった。機能は豊富だが一般のWindowsアプリケーションとは違ったメニュー構成でどこになにがあるのかわからなかった。

バージョン5のときの付属のファイラーには機能が少なく使いにくかったが、アウトライン機能を使いたくてがまんして使っていた。

今回のバージョンアップでは、タブ式の画面になり複数のファイルを扱うのが楽になった。Let’snoteの12.1インチの画面の中にたくさんのファイルが開くと収拾がつかなくなっていたが、タブ式になったことでコンパクトに収まり視認性が上がり、なかなかいい。Vistaのメイリオフォントがやわらかい感じがして、作業環境がさらに良くなった。

作業に関する文書はすべてテキストファイルに保存しているので検索やファイルのプロジェクト化が簡単なほど、作業の効率があがる。

作業の手順はすべて記録しているので、作業前に関連のキーワードで検索するだけでだいたいの作業準備が終わったりする。実際はそう簡単ではないけれどこの部分がおろそかだと効率が大幅にダウンしてしまうのだ。今回のバージョンでは、テキストを開くという機能が使い易くなっている。エディタの下側に窓が開いてそこでgrepと同じことが簡単にできる。

アウトライン部分の動作も良くなっている。アウトライン表示しているときの操作性が上がり、タブで開いているファイルを同じレベルでアウトライン表示できるので、あちこちに散らばったファイル内容を参照しやすくなった。