10月 2010 のブログ記事

今日はWordCampNagoyaの開催日
　
9時から名古屋におけるサイト解析第一人者である運営堂森野代表のセッションがあるということで、普段10時起床の私にとっては、かなりの早朝の7時起床でいってきました。

Google Analyticsに関してのセッションでした。
私が生業としているECの世界においても解析は重要なのですが、Google Analyticsは使ったことがありません。
慣れなのでしょうが、とっつきにくくて…。
と、思っていたら、その解析業務を助ける、GreaseMonkeyの存在を話されていて、これがあれば使える！と思いました。行ってよかった。
WordPressに直接関係する内容ではないものの、WordPressをはじめCMS各種って、運営に焦点をあてたシステムにも関わらず、実は制作サイドの意識としてはサイト構築ツールまでで終わっていることが多いですよね。良くも悪くも。
解析の話を通して、運営面に少しでも目が向くのならと思いました。
　

---

その後、MightyWorksさんの「WordPressとは」というセッション。
Wordopressを紹介するセッション。
かなーりWordPress愛を感じるセッションでした。
　

---

　
次、WordCampを抜け、ゆるPerlに向かう。
初期メンバーに名を連ねながら、初めての参加。
　
おーい。色々緩すぎるぞ！いつもはこれでいいけど、たまには、目的意識をもった会をやったほうがいいぞー。
　

---

　
またWordCampに戻る。起きてたのにバスを乗り過ごすという、荒業を成し遂げてしまいました。
　
LTセッションでは、お友達のマイペースクリエーターKさんが話をするということで、まじまじと見る。完全初心者向けのWordPressテンプレートを公開したということで、それについて発表しました。おぉ。なんか、みんな良い反応！
　
横浜のWordCampのUstで見てめちゃ面白かった、め組のメガネさんのセッションもありました、こちらもWordPress愛を深く感じ、なおかつ面白いセッションでした。め組さん。普段お世話になってます。
　

---

大体こんな感じ。その後懇親会→二次会。
　
全体通じて思ったのは、WordPressって情報がいっぱいネット上には転がってるんだけど、やっぱりオープンソースゆえ隠れた情報も沢山ある。オープンソースの利用にあたっては、コミュニティに参加することが、情報を集める上で一番良い手段で、かつ、コミュニティに参加して恩返しをすることへの意識が必要なのではと思った。その辺がプロプライエタリとの大きな差かな。
　
私は、普段一般のWEB制作の世界とは違うところで、サイト制作を行っているので、必ずしも、WordPressが最上位のパブリッシングプラットフォームだとは思っていない。（これは立場の問題なので、この部分を突っ込まれるとちょっと困るので、聞き流してくださいね）
それでも、これだけ沢山のユーザーがいて、これだけ沢山のコミュニティ参加者がいるWordPress。常に選択肢の中には入ってくるとは思う。
　
まぁ、そんなこんなで、WordCampお疲れ様でした。
最後に謝っておきます。若干立場的に微妙な人が参加しててごめんなさい。（分かる人が分かれば良い謝罪）
　

---

　
あ、ゆるPもまとめなきゃ。
　
参加者の初心者の方に少しだけレクチャーさせてもらったんだけど（WEBでの利用に関して）、PHPに最初に手を出しては理解をせずに、飛び込んで行けてしまうHTTP関連の仕組みや仕様とかを、Perlにおいては、理解を持ちながら勉強をする必要があるなと実感。
諸先輩方がプログラミング初心者がPHPでプログラミングを学ぶことへの批判はこのあたりにあるんだろうなと。
　

---

そんなこんなで一日終わり。疲れたぞ。

ちょっと野暮用で（という言い方も変だが）、
さくらインターネット（スタンダード）にSeezooCMSをインストールする必要があった。
　
公式のインストール方法を元に設置まで進んで、
いざインストール設定をと思うと進めない。
？？？
と思い、/index.phpに直接アクセスしたら、
インストーラーを見ることができたので、
なーんだと思ってインストール完了。
　
さぁ、じゃあ使おうじゃないかと思うと、
ここでさっきの問題が何を意味しているかわかった。
mod_rewriteの動作が変！！！orz
　
最初はmod_rewriteの動作がなのかなと、
.htaccess周りをずっと見ていたのだけれど、
どうもなんか違う。.htaccessの書き方は正常だ。。。
　
というようなことをTwitter嘆いていたら、
@longkey1さんが
・ルーティングあたりに問題がある。
・mod_rewrite後PHPにPATH_INFOが渡されないのが問題かも。
とアドバイスを受ける。
　
！！！
　
初めてCGIモードでPHPを触ったのですが、
CGIモードの場合、PATH_INFO周りの扱いが非常に面倒になるのですね…。
知りませんでした。。。
　
でも共有ホスティングではCGIモードがメインの日本では、
知らなかったでは済まされない事態…@longkey1さんありがとうございます。。。
　

---

　
私が行った対処方です。
　
まず、seezoo CMSデフォルトのサンプルでは、.htaccessは、

RewriteEngine On

RewriteCond $1 !^(index\.php|sitemap.xml|sitemap_ssl.xml|css|js|captcha|uploads|templates|blocks|phpMyAdmin|.+\.gif$|.+\.jpg$|.+\.png$|.+\.js$|.+\.css$|.+\.json$|.+\.ico$|.+\.swf$|.+\.flv$)
RewriteRule ^(.*)$ index.php/$1 [L]

　
こんな感じですが、これを
　

RewriteEngine On
RewriteBase /
RewriteCond $1 !^(index\.php|sitemap.xml|sitemap_ssl.xml|css|js|captcha|uploads|templates|blocks|phpMyAdmin|.+\.gif$|.+\.jpg$|.+\.png$|.+\.js$|.+\.css$|.+\.json$|.+\.ico$|.+\.swf$|.+\.flv$)
RewriteRule ^(.*)$ index.php?__REQ__=$1 [L]

　
こんな風にします。@_tk84さんの情報によると、さくらの場合は、基本的にRewriteBaseの設定は行った方が良いようです。ありがとう！_tk84さん。
　
次に、/index.phpの冒頭に、次のPHPスクリプトを埋めます。
　

if( isset( $_GET['__REQ__'] ) ){
    $_SERVER['PATH_INFO'] = $_GET['__REQ__'];
}

　
ここまでの流れを説明すると、
URLのパス情報を「__REQ__」というリクエストで送信して、
それを受け取ったindex.phpが、
$_GET['__REQ__']を$_SERVER['PATH_INFO'] に代入して、
ルーティングを成功させようという魂胆。
　
　
これでいけるか。と思ったら、まだ変。。。
改めてCodeIgniterのルーティングについて調べる。
すると、CodeIgniterでは、何を基準にルーティングするのかを決める設定があって、
デフォルト状態ではそれが「auto」になっているという話。
それを明確に「PATH_INFO」を基準にせよとすれば、
うまく行くっぽい！
　
/system/application/config/config.php
の次の箇所

$config['uri_protocol']	= "AUTO";

を

$config['uri_protocol']	= "PATH_INFO";

　
と書き換えた。
　
　
これで成功！めでたしめでたし。
あとはつくるだけ。
　

---

　
@longkey1さん、@_tk84さん、ありがとうございます！

なでしこには、変数を破棄する命令がありません。（ないんだよね？）
　
普通になでしこ単体でプログラムを組む分には、
なでしこは定型処理ツールに近く、何度も変数を使うということがないので、
ほとんど問題にはならないのですが、
Filemakerプラグインで使う場合は、
メモリ上に常駐させて使いまわすケースが個人的に多く、
配列やハッシュを使いまわす場合など、結構困ります。
　
ということで、どうしたらいいんだろうと思って、いろいろ考えた結果、
　

ARRAYとは文字列。
ARRAY = 「」。
ARRAYとは配列。

　
このように、一旦文字列型などにしてしまうことで、
配列を再初期化できます。（というより、多分内部的には再生成している）
　
これ使わないと、FileMakerのLoopと組み合わせる時とか、苦しい・・・。

名古屋サイト改善研究会「だがや」Vol.1に行ってきました。
前回の会合が、Vol.01だと思ってたんですが、
今回がVol.01でした(^-^;
　

---

　
今日は、ワークショップ形式で、メンバーの方のECサイトを解析なり改善なりしてみようということでした。自分はグループのリーダーとなり発表を行ったのですが、あまりまとまってなくて、考えながら話をしたら、あまりにもひどい言葉を発していて、大反省です。大変申し訳ないです。
　
というわけで、グループの発表ないようは、他のメンバーの皆さんに任せるとして、私が個人的に思ったところをこの日記にまとめ直したいと思います。
　

---

　
まず、パッと見で問題だと思ったのが、
来客数の少なさ、コンバージョン率の低さでした。
　
これまでの私の経験で言えば、
大体の平均値が、一日来客600人程度で、コンバージョンが0.6%程度が、
損益ラインかなと考えています。
　
今回拝見したお店は、それぞれそこには及んでいませんでした。
単価が高く、法人からの受注が多くなるであろう商品が並んだお店でしたので、
実際は現在の売上でも、お店としては維持できているのかなとは思いましたが、
逆に言えば、通常のラインまで持っていけば、
相当な売上を上げることが可能になるのかなと思いました。
　

---

　
じゃぁ、何が問題なのか。
　
検索エンジンで検索されたキーワードの1位がいわゆる「ビッグキーワード」でした。
分かりやすい単語で、かつ広汎なキーワードですね。
　
個人的には、ECの場合そういったキーワードでの最適化は好ましくないと思っています。
もう少し範囲の狭いキーワードに最適化するべきです。
　
ECの場合は観てもらうだけでは意味がないので、
集客はするに越したことはないですが、
来るユーザーの質のが問題です。
　
幸い、来客数2位のキーワードが、
そのものずばりの商品の種類を指すキーワードで、
なおかつ顧客単価も上がるキーワードでした。
　
ここにサイトを最適化しないでどうするんだということですね。
　

---

　
サイトを見ると、せっかく2位のキーワードが購入につながりやすいキーワードにもかかわらず、それに対応するランディングページやアイキャッチがない。また、カテゴリページがあるにも関わらず、そこには説明らしいものもない。「紙のカタログ」っぽいサイトになっているのが非常に勿体無く思います。
　
まずは、ここから手をつけるべきでしょう。
　

---

　
次に思ったのが、他のグループの方が、トップページの目立つところに案内のある大口受注の案内を活かして、もっとわかりやすくしようという発表をされていました。
　
私は個人的には、それには半分賛成半分反対です。
大口注文がとれますよ。ご相談下さい。という内容は。
トップページの目立つところにある必要はないです。
むしろサイドやヘッダにバナーとして用意して、
各ページ共通で分かりやすくすべきでしょう。
　
そしてトップページのスクロールしなくてもわかる範囲には、
やはり、おすすめ商品などへのリンクバナーをバチっと出すべきです。
　
検索数3位以下のキーワードもばらつきがあるようなので、
この部分で動的LPOの導入を考えてもいいと思います。
　

---

　
次に、価格的には、かなり安く売っているので、
そこでも訴求が出来るはずなのですが、
そういった謳い文句もありません。
xx%OFF!とか大きく謳えば、購買見込みではなかったユーザーも、
購買ユーザーへ変わるかなと思います。
　
また、そういった格安とかいう複合キーワードでの来客数増大を狙うべきでしょう。
今のところの、来客キーワードは本当に「単語」のみで来客していました。
どのお店も、1位〜4位くらいまでは単語である傾向は強いのですが、
それ以降が、複合キーワードであった場合、購入率が高いのかなと感じています。
　

---

　
で、一番問題だと思ったが、前述の通り「紙のカタログ」っぽいサイトになっているんですが、これはカテゴリ一覧のページだけではなく、商品ページもそのような状態でした。
　
私の職務上でも、クライアントに口を酸っぱくしていっているのですが、
載せれば売れる時代は終わっています。
そして、ECサイトが自動販売機の時代も終わっています。
とにかくコンテンツ作りが重要。
これだけ自信をもって売っています。これは本当におすすめです。
というのを、カタログに乗っているデータではなく、
売っている人の言葉やその人の目線での写真で伝えなくては、
間違いなく売れません。
なんだったら、デザイン性は一番最後に考えてもいい話かもしれません。
　
文字や情報が増えれば、それだけSEO効果もあり、
なおかつ、ユーザーにとっては好印象となりうるものです。
（ただし、●天のお店のようなコンテンツづくりは、
　ユーザーもうんざりですし、
　サイト制作側としても、恥ずかしいです。）
　
　
ここはぜひ充実させて欲しいものです。
　
　

---

　
私がよくTwitterで言っているのですが、
検索があって、カートがあって、会員情報が取得できて、商品ページには本当に「説明っぽい説明」があって、というサイトは、まさに仕組みに自分のお店づくりを当てはめるだけの、コンビニ経営や、自動販売機と何ら変わりありません。
　
ECもお店です。
通常のお店であれば、アイキャッチとなるPOPを作ったり、店員としてしっかり説明をするのは、当然です。しかし、意外にこういう事ができているお店って少ないです。
　
また、会員情報を当たり前のように集めていたりとかポイント制導入しているサイトを見るのですが、これすら、私には甚だ疑問です。
　
前述の通り、ECサイトだってお店です。現実のお店を考えると、お客様がリピーターになるのは、個人情報を集めているからではないです。ポイントカードを作っているお店のお客さんがリピーターというわけではないです。
お店の雰囲気や売っているもののアソートでリピーターになる人が多いです。
店員さんの「ありがとうございました」の笑顔ひとつでリピーターになることだってあります。
　
要するに、プログラマの私が言うのも変なのですが、仕組みじゃないんです。
どんなお店づくりをして、どんなことをつたえるかが重要なんです。
そして、それを実現するために、必要であれば、会員情報を集める機能やポイントが付いてくるんです。（現実的には不要なお店が大半だと思います）
　
今日拝見したお店は、こういった点で、非常に立ち遅れているという印象を受けました。
　

---

　
社長の話を伺うと、商品のことはわかっていらっしゃるようですので、
もっと社長自らチューニングに関わるだけでも、
かなりの改善が見られると思います。
　

---

　
以下、本名出しているこのブログで言っていいものかわかりませんが、
届いて欲しいので書いてしまいます。
　
私が仕事で担当しているクライアントは、
「お店として」売ろうという気概が全く感じられません。
人がいないからとか、PCが苦手でよくわからないからと言い訳されるんですが、
でも、1つの商品に対して、何かが伝わる紹介文を書いたり、写真を撮ったりということは、PCの世界には関係のないことですから出来るはずなんです。
それでも、やらない。結果担当する僕のモチベーションはガチ下がり。そして売上減。
もう、負のスパイラルです。
　
生意気なことを言いますが、上記のクライアントと違い、今日の勉強会で改善提案したサイトは、お店として売ろうという気概と伸びシロがあると思うから、ここまで書けるんです。
話半分で良いので、聞き耳立ててもらえると嬉しいです。

サイトで、ヘッダ部分やフッタ部分やサイドメニューなど、
サイト全体で共通の表示をおこないたい時に、
昔からよく使うのがSSIの

<!--#include virtual="ドキュメントルートからのパス"-->

　
や
　　

<!--#include file="同ディレクトリ内のファイル、または、下位ディレクトリのファイルのパス"-->

　
でインクルードする方法。
　
　
古い方法ですが、非常に有用。
　
でー。Smartyで同じような機能を実現するのが、{include file=’xxx.html’}の記述。
こちらも有用。
　
SmartyのテンプレートをDremweaverで編集するとき、
やはりインクルードの状態をプレビューしたくて、
編集のときは、SSIの表記を埋め込んで編集。
アップするときは、{include}に置き換え。
というまぁ、とてつもなくめんどくさいことをずっとやってました。
　
よく考えたら、
SSIの記述をSmartyの{include}に置き換える処理を、
Smartyのプリフィルターとして用意しておけばいいじゃん！
ってことに気づきました。
　
ってわけで作成。

function smarty_prefilter_ssi2include($source, &$smarty){
    //<!--#include virtual="ドキュメントルートからのパス">
    $source = preg_replace( 
        '/\<\!\-\-\#include virtual\=\"\/([0-9a-zA-Z\.\/\_\-]*)\"\-\-\>/i',
        $smarty->left_delimiter . 'include file=\'' . $_SERVER['DOCUMENT_ROOT'] . '/' . "$1" . '\'' . $smarty->right_delimiter,
        $source
    );

    //<!--#include file="相対パス" -->
    $source = preg_replace(
        '/\<\!\-\-\#include file\=\"([0-9a-zA-Z\.\/\_\-]*)\"\-\-\>/i',
        $smarty->left_delimiter . 'include file=\'' . "$1" . '\'' . $smarty->right_delimiter,
        $source
    );
    return $source;
}

　
これを「prefilter.ssi2include.php」の名前でプラグインフォルダに保存し（PHPタグを忘れずに）
smartyのインスタンス作成時に読み込むプリフィルターとして「ssi2include」を指定してやれば、OKです。
　
　
なお、インクルードするファイルのパスには半角英数「-」「_」「.」「/」が利用されることを想定しています。
それ以外の文字が入る場合は修正して利用してください。
　
あと、正規表現は実に適当です(^-^;

昨日のファイルメーカーランタイムの記事のWindowVista版についておはなし。
　
何がしたいかは、昨日の記事を御覧ください。
　
基本的には対策はWindows7と同じでOKですが、
WindowsVistaは御存知の通り、到底出来のいいOSとは言えないOSで、
セキュリティ面に関しては、行き過ぎなところと、
逆に全然行き届いてないところがあります。
なんというか、非常に雑な印象を持ちます。
そりゃ、マイクロソフトにとっても黒歴史になりうるものだと思います。
（↑言いたい放題）
　
それはさておき、では、Filemakerのランタイムをインストーラーとして用意したとき、
WindowsVistaで起こりうる問題についてお話します。
　
前述の通り、基本的にはWindows7と同じでいいです。
　
が、ひとつ問題が。これは環境差があるようで、発生するマシンとそうでないものがありました。問題になった場合の対応策として考えてください。
　
ランタイムを起動したとき、データが更新するタイミングで、
ランタイムアプリケーションがフリーズする現象に見舞われることがあります。
　
これに3ヶ月近く悩まされていたのですが、
ようやく対応策がわかりました。
　
WindowsXP SP2以降、Windowsには、DEPという機構が設けられています。
（決して某県刈谷市にあるプロレス団体のことではないwww）
　
これがどうも悪さをしていたようです。
詳しい説明をすると、アホみたいに話が難しくなるので、
割愛しますが、DEPをWindowsの設定により、
明示的にランタイムアプリケーションに対して除外設定を行うことで、
このフリーズ現象が回避できました。
　
しかし、WindowsXP SP2以降で導入されている機能にも関わらず、
なぜWindowsVistaでのみそのような現象が起きているのかワケが分かりません…。
　
そして、どういうわけか、DEPの設定での回避は
サービスパックの最新版を適用していないと、
うまく回避が出来ませんでした…これもまた謎です。
　
しかも、サービスパック適用→DEPの設定の順で行わないと、回避できません。
Windowsアプリの専門家ではないので、
頭がオーバーフローしてしまい、
その日は非常によく眠れました（何のこっちゃ。）
　
というわけで、WindowsVistaでFilemakerランタイムを使うにあたって、
このへんは気をつけていきたいものです。

　
現在Filemakerのランタイムアプリケーションと、
なでしこプラグインのランタイム版を使ったアプリケーションを開発中だ。
そのアプリケーションをインストーラーとして固めて配布するときの注意Win7版覚書です。
　
ランタイムアプリケーションは、
Filemaker本体なしで、FMのDBアプリケーションが利用できる有用な機能だ。
（DB構造が変更できないなど制限はある）
ノンプログラマでも、スタンドアロンアプリケーションが作れる。
　
　
ランタイムアプリを作成すると、
フォルダの中に非常に多くのファイルが詰め込まれた状態で、
アプリケーションがアウトプットされる。
普通に使うには、
そのフォルダをデスクトップやマイドキュメントあたりに格納して使えば
特に問題はおきません。
　
しかし、それらをインストーラーとして固めて配布する場合に注意すべき点が多々あります。

---

　　
1)インストール先
ファイルメーカーはデータベースソフトウェアで、
ランタイム版も同様にデータベースソフトウェアです。
データベースならば、当然、アプリケーション自体または付属のファイルに
利用する都度ファイル保存や書き換えが行われます。

通常アプリケーションの格納場所は
C:¥program files¥
だと思うのですが、
このディレクトリの下にあるファイルは、
通常ユーザーではファイルの保存や変更はアプリケーションから行うことができません。
つまり、Filemakerのランタイムアプリでは、
レコードの追加やフィールドの変更など、
データベースとして重要な機能を使えず、
ReadOnlyなデータベースアプリケーションになってしまうというわけです。
　
これでは話になりません。
　
ということで、Filemakerランタイムアプリの場合は、
ドキュメントフォルダや、ユーザーデータフォルダなどにインストールするように、
インストーラーを設計した方が吉です。
私の実験では、C:¥直下でも大丈夫だったようですが、
世間的にはあまり推奨されていないようです。
　

---

　
2)ファイルのコピー
多分、通常のランタイムアプリをインストーラーにする場合は、
1の対応だけで問題ないはずですが、
　

　
今回は、エクセルのテンプレートファイルを用意しておき、
エクセル表示時に表示用のファイルをコピーで新たに作成して、
表示用ファイルへ表示する内容を流し込む。
という動きを自動的に行うよう、
なでしこプラグインによって制御しているのですが、
このコピーという動作は、
たとえ、ユーザーデータフォルダや、ユーザードキュメントフォルダであっても、
UACの制限をうけ、アプリケーションから実行することができませんでした。
　
管理者権限でアプリケーションを実行している場合のみ、
コピーの制御ができるようです。
　
Vistaのときは、いつでも管理者権限でアプリを起動する手段があったようですが、
Win7はどうなんだろう…どっちにしても回り道なのであまり考えたくありません。
　
コピーがだめなら、エクセルを制御しているわけだから、
一度テンプレートのエクセルファイルを開いてしまって、
自動で別名保存するようにすればいいじゃないかと思って、
これも行ってみましたが、拒否されるようです。
（なぜかOpenOffice.orgを制御する場合はそれでいけた）
　
どうしようか…と思って試行錯誤したところ、
なでしこでテンプレートファイルの内容をバイナリとして、
なでしこの変数に保存し、
なでしこでファイルを作成して、そこへ変数に保存されたバイナリを流しこんで保存。
という回りくどい手段を使えば、擬似的にコピーを
UACの影響なしに行えることがわかりました。
　
多分ですが、Win32APIのCopyFile関数がUACの監視下にあるのだと思います。
開いて内容取得→ファイル作る→取得した内容保存
ですと、CopyFileを使うことはないのでUACの影響を受けなかったのではと思います。
　
これはおそらく他の言語とかでも役に立つはず。
　

---

Win7でFilemaker+なでしこのランタイムアプリをインストーラーで配布する場合は、
とりあえず、以上で今のところ問題点は見つかっていません。
　
Win7は比較的セキュリティは高いのに、仕組みはシンプルなので、
要点を押さえれば、アプリ開発はすんなりいきます。　
問題はVistaです。こっちはハマりまくったので、
また次回レポします。