まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

WordPress の最新バージョン 3.9(Smith) がリリースされました:
WordPress 3.9 "Smith"

ちなみにコードネームの "Smith" はジャズオルガン奏者の "Jimmy Smith" にちなんで付けられたそうです。この分野はあまり詳しくないので(苦笑)触れずに説明を続けます。 (^^;

注目の新機能のうち、特に気になるのが「画像編集」機能です。アップロードした画像コンテンツの拡大・縮小・切り抜き・回転・ドラッグ&ドロップといった簡易編集については標準機能だけでできるようになった、というものです。

これ、結構大きな意味があると思っています。WordPress はこれまでもコミュニティ提供の各種プラグインを使った拡張によって、CMS(コンテンツ管理システム)の(カスタマイズ前の)標準プラットフォームの主流になっていました。そこに今度は画像編集機能までが付属することになります。

これまでも WordPress をベースにカスタマイズする方法でウェブサイトを開発すれば、コンテンツ編集のリッチテキスト化やPC/モバイル両対応のレスポンシブ化といった機能については標準機能だけで実現できていましたが、今回の新機能によって、コンテンツにアップロードした画像の編集も(WordPress 3.9 以上をベースにしているだけで)可能になる、ということになるのです。

ウェブアプリケーションを開発する視点から考えると、この「画像編集」とはスクラッチで作るには結構面倒なものです。それを「WordPress をカスタマイズするだけで実現できる」ことになれば、開発者としての負担は大きく軽減します。システムを Java で作るべきか、PHP で作るべきか、、、という議論も吹きとんで「WordPress(とPHP)で作るのが一番楽」という判断になってもおかしくないし、現にプライベートでは Java メインの自分でも、運用中のウェブサイトの次回リニューアル時は WordPress ベースにしようかな、実現に都合悪いことってあったかな?? と考えなおしてしまいかねないインパクトです。

WordPress 3.8 から 3.9 へは一見するとあまり見た目の変更が伴ったバージョンアップではないので気づきにくいのですが、内部的にはかなり大きな衝撃を伴う新機能が含まれていましたね。



ケースバイケースではあるのですが、まだ自分の中で明確な答が出ていない問題です。

ウェブサイトを作る時に、そのサイト内のページや情報を検索するための「サイト内検索」、これを用意するべきかどうか、用意するとしたらどうやって用意するか、という問題です。
2014050301
↑こういうやつね


普通は「え?そりゃ無いよりあった方がいいでしょ?」と思いますよね。ではサイト内検索機能を用意する前提でもう少し細かく考えてみます。


サイト内検索を自前で用意する場合、開発コスト/運用コストによって選択肢はいくつかあります。まず手っ取り早いのは「DB内を全文検索する」ような検索実装です。端的に言えば SQL で select * from XXX where title like '%キーワード%' or category like '%キーワード%' or body like '%キーワード%' みたいなのを実行する、というやり方です。これだとウェブ/DBサーバーの負荷はその分上がりますが、サーバー構成の変化をあまり意識する必要がなく、懐にやさしい実装と言えます。

ただし、このやり方はいわゆる「ゆらぎ」や「同義語」に対応した検索ができないので、指定したキーワードにピッタリマッチした場合だけヒットします(近いキーワードではヒットしません)。そのため利用者視点では期待するような検索結果にならず、必ずしもユーザビリティはよくありません。また RDB の SQL を使うこの方法は複雑な条件での検索に対応できる一方で、検索速度については(KVS 型などと比較して)遅くなってしまいます。速度低下を避けるためにディスク高速化やメモリキャッシュを使うなどハードウェアで対処することもできますが、これはサーバーコストにまともに跳ね返ってしまうので、経済的というメリットが薄くなってしまいます。またクラウドサーバーでの運用を考えている場合、そもそもクラウドベンダーがハードウェア高速化を提供しているかどうかも事前に調べておく必要があります。そこまでして実現しても、利用者が検索にグーグル並の使い勝手を期待しているような場合、ちょっと残念な検索機能という印象を持たれてしまうかもしれません。


検索専用に別サーバーを用意してもいい、という費用感であれば、検索サーバーを立ち上げて検索機能に関しては検索サーバーに一任する、という方法も考えられます。このケースでは検索サーバーをオープンソース製品などを使って自前で用意してもいいし、商用の検索サービスを提供している業者と契約する方法も考えられます。検索サーバーの細かな機能や得意・不得意機能は千差万別ですが、対象レコード数や検索クエリー頻度、検索速度で検索サーバーの規模を概算して、それに見合ったサーバーを用意することになります。検索専用サーバーであればほとんどの場合で「ゆらぎ」や「同義語」にも対応できますが、その辞書メンテナンスを含めた管理を自分達で行うのか、そこも業者に任せるのか、どこまで任せるのか、そしてそれはいくらかかるのか、というコスト感と合わせて判断することになります。

この方法の問題点として、検索サービス専用業者との契約はその他のサーバー運用費と比較して結構高コストになる、という印象を持っています。また検索エンジンは途中から「やっぱりいらない」とは(アプリ設計から見直すことになるため)しにくいのです。したがって、一度導入すると定常的に(安くない)運用コストがかかる要素と言えます。


そして、個人的にはここが一番気になるのですが、「そもそもサイト利用者はサイト内検索をどれだけ必要としているのか?」という問題があります。上記のようにユーザビリティの高いサイト内検索を(コストもかけた上で)用意したとして、ユーザーのサイト内検索にはどれだけの需要があるのでしょうか?

これは提供するサービスの内容にもよるとは思います。例えば有名人のブログやニュースサイトなど読み物コンテンツ中心だったり、利用者が特定の何かの情報を探しに来ているのであれば、利用者はトップページから参照して、過去の情報も含めてサイト内を検索する、という行動も珍しくないと思っています。そのようなケースに該当する場合、サイト内検索は必要と考えるべきでしょう。 

でも現実問題として、多くのケースで利用者はトップページから情報を探すわけではなく、グーグルなどの検索エンジンから見つけたコンテンツに直接(トップページを経由せずに)訪問してきます。そうして訪問してきた利用者を同じサイト内の他コンテンツにも誘導したい気持ちは分かるのですが、そこでどれだけの利用者がサイト内を検索するのでしょうか? 例えば人気コンテンツや関連コンテンツ、リコメンドといったリンクを用意しておいて、そこから誘導させる手段は(自分の行動を顧みても)ある程度の効果があると思うのですが、グーグル検索結果からふと訪れたサイトで、わざわざ再度サイト内検索をしてまで別の情報を探すか?と言われると、ほとんどしていないように思うのです。


ここで改めて冒頭の疑問にたち戻ります。サイト内検索機能は比較的高いコストを要して用意することになるのですが、本当にサイト内検索はコストに見合うだけ使われるのでしょうか?それともコストをかけて用意するだけの必要性はないと考えるべきでしょうか? これが自分の中で答の出ていない問題なのでした。

そしてもう1つ。ユーザーはサイト内を検索することはなくても、グーグルなどのウェブ検索をすることは一般的と言えます。であれば SEM/SEO 対策を効果的に行ってユーザーの検索結果に自分達のコンテンツをある程度うまく表示させることができていれば、グーグルをサイト検索代わりにすることができるようになります。検索時に「検索キーワードに続けてサービス名も入れてもらう」とかであれば比較的すぐに検索結果を上位に持ってくることもできると思うし、グーグル検索であればかなり複雑なゆらぎにも対応した検索を提供してくれるし、その実装については悩む必要もありません。

極端な言い方かもしれませんが、検索エンジンにコストをかけるのであれば、その分を SEO 対策やマーケティングに費やしてもいいのでは? と考えてしまうのでした。


ただ例外もあります。キーワード以外で、例えば位置情報や画像やらユーザー名やらで検索するような場合はグーグル検索に任せられないので、こういうのは自前で用意しないといけないですよね。


というわけでまとめると、サイト内検索機能というのは、、
- 実装・運用にコストがかかる割には
- あまり使われない可能性があって、
- しかも SEM/SEO 対策次第でグーグル検索の方が高い精度でサイト内検索の代わりになるかもしれない

といった傾向が考えられるのです。 
そんな中でもコストをかけて柔軟なサイト内検索を実装/実現すべきなのか? という問題を考えていたのでした。簡易的な全文検索にするか、それ以上を求めるならグーグルの SEO 対策を強化する、でもいいのかな、と。

あらためて色んなサイトを見直してみると、サイト内検索を実装していない所も珍しくないですよね。このブログにもありません。最近は「意外となくてもいいんじゃないかなあ」と思うようになってきたのでした。

#っていうか、検索の SaaS って高すぎて個人サービスレベルじゃ手が出せない・・・ (x_x )
 

WordPressMySQL と、そして何故か IBM BlueMix の話です。

WordPress は wp-config.php ファイルにその設定を記述します。WordPress は(一般的に)MySQL をデータベースとして利用するので、この MySQL データベースの接続設定(ホスト名、DB名、ユーザー、パスワード)もこの中に記述します。具体的にはこんな感じです:
  :
define( 'DB_HOST', 'mysql.xxx.com' ); // MySQL サーバー名(IPアドレス)
define( 'DB_NAME', 'wordpress_db' ); //. MySQL データベース名
define( 'DB_USER', 'wordpress_username' ); //. MySQL ユーザー名
define( 'DB_PASSWORD', 'wordpress_password' ); //. MySQL パスワード
  :
データベースのポート番号に関する設定は特にありません。

MySQL は一般的には(デフォルト状態であれば) 3306 番ポートで待ち受けています。その場合、wp-config.php にはその指定は不要です(何も指定しなくても 3306 番ポートへ接続しに行ってくれます)。


何らかの事情で MySQL が 3306 番以外のポート(例えば 3307 番)で動いていた場合、上記設定では WordPress が MySQL に接続できないので正しく動作しません。そしてポート番号の設定項目はありません。ではどうすればいいでしょうか?


そんなに特殊な指定方法ではないので想像できると思いますが、答はこちらです。ポート番号は DB_HOST の一部として指定できます:
  :
define( 'DB_HOST', 'mysql.xxx.com:3307' );
define( 'DB_NAME', 'wordpress_db' );
define( 'DB_USER', 'wordpress_username' );
define( 'DB_PASSWORD', 'wordpress_password' );
  :

実は IBM BlueMix 環境で MySQL サービスを利用すると 3307 番ポートで稼働するので、WordPress を使うには上記のような設定が必要になります。

「そもそも IBM BlueMix 上で PHP アプリをどうやって動かすか?」についてはこちらのエントリを参照ください。


 

このページのトップヘ