テーマは決めずにいろいろやっていきたいです。

HTMLの解析。特定のタグを取り出すために使われる手法が正規表現。
PHPなので、「preg_match」とかを使う。

PHPには正規表現を扱う関数として、「ereg_」系と「preg_」系が用意されてて、校舎はperl互換。それだけでなく、後者のほうが機能的に満足いく結果が得られる場合が多い（というか、使いやすい）。

で、こんなやつ。

     $pattern = '|<a href=["\']([^"\']+)["\'][^>]*>([^<]+)<|i';
     preg_match_all( $pattern,      $contents, $out,     PREG_SET_ORDER);

もちろん、aタグをひっかける。「()」で囲まれている部分はあとで参照できる。URLと、アンカーが拾えるというわけだ。

しかし、これではひっかからないものもある。「href」属性の前に「class」属性だとか「id」属性が来たら、もうこれにはひっかからない。

で、別の方法を考えなくてならなくなるわけだ。まあ、そんな感じでいろいろあるわけです。

このへんから。

Google、誰でもAndroidアプリを開発できるツール「App Inventor」 – ITmedia News
Google、コードを書かずにAndroidアプリが作れる App Inventorを公開
Google、Android向けWYSIWYG開発ツール、App Inventorを発表―その影響は？
Googleがケータイアプリ簡単作成ツール＝だれでもプログラマー時代到来？【湯川】 : TechWave
App Inventor for Android
Android App InventorにはTwitterへのシームレスな連携機能あり―さらにサードパーティーが連携機能を開発するツール提供へ
Android プログラミングがスゴい « maclalala2

グラフィカルな開発環境といったところ。

ほとんどコード書かなくていい感じ。
とはいえ、往年のVisual Basicを思い出さないこともないです。

JavaScriptのコーディングではまった話。

HTMLで改行を出力するなら<br>タグを使うのだが、フォーム内に出力する場合にはそうもいかない。input（インプット）とかtextarea（テキストエリア）とかの場合だ。

ということで、JavaScriptで改行コードを出力するためには「¥n」を使う。

HTML内にゴリゴリ書いていると、このままでは改行にならない。どうやら「¥」をエスケープしなくてはならない。

ということで、「¥¥n」とすると意図したとおりに動作するようになった。

続いて、HTML内にごりごり書いていたJavaScriptのコード部分を、jsファイルとして分離する。こうすれば、ほかのHTMLファイルでも使いまわしがきくようになる（別ファイル読み込み時もキャッシュされてるので、再読み込みが不要になる）というわけだ。

しかし、ここではまる。「&yen」がよぶんに出力されるのだ。どうやら、先のエスケープ部分が邪魔になっている模様。

ということで、あらためて「¥n」とする。

HTMLファイル内にいれる場合と、jsファイルで分離する場合では扱いが違うようだ。いまさらながらメモ。

プログラムのコードをブログに書きたい場合、エスケープとか整形とかがいろいろ面倒、とか思ってたので、プラグインを導入。

「WordPress › SyntaxHighlighter Evolved « WordPress Plugins」

たとえば、こんな感じ。

  if(!$.browser.msie){
   $.each(alist,function(){
     if($('#li'+this).html()){
      switch ( br_on ){
       case "1":
             lilist += $('#li'+this).html() + "<br />";
             break;
       case "2":
             lilist += "<li>" + $('#li'+this).html() + "</li>";
             break;
       default:
             lilist += $('#li'+this).html();
             break;
      }
      if(cr_on === "1"){lilist += "\n";}
     }
   });
  }

とりあえず、先日作っていたJavaScriptのコードを入れてみた。
内容についてはとりあえず、無視してもらうとして。

「[」と「]」で「js」をHTMLタグと同様に囲む。開始はこれで、終わりは「[/」と「]」で「js」を囲むといった具合。「js」の部分を「php」にすれば当然PHPのコードを書ける。

見た目的にはぜんぜんOK。

コードを紹介してる記事でよく見るなあ、とは思っていたけど、調べたのはつい最近。なんで、これまで気づかなかったのかと自分のアホさ加減にぐったりするほど。なんて便利！　WordPressのほかにも各種CMSに対応したプラグインがある模様。このテのものを「SyntaxHighlighter」という、ってことも最近知ったばかり。

これからはプログラミング時のメモとかも積極的に書いていこうかと思う。

「投稿が100件しかなくても、7つのうちどれを押しても、10件以上は記事がある状態なわけです。これであれば「記事がなかった」というがっかり感を感じさせません。」
「完璧を作ろうとするより、その段階で最善のものを出して、あとからどうするかを考える、というのがWebサービスを作る時に有効な手立てなのかもしれません」

なんて話が読めるのが「nanapiの初期バージョンに検索窓がなかった理由 : ロケスタ社長日記」。

やじうまWatchの「■ Webサービスの成功には「あえて機能をつけない」ことが重要？」経由で。まずはこっちを読んだほうがいいかもしれない。

「Webサービスに求められる機能をあえてつけないという考え方について考察」してる記事なんかへのリンクもあって、こっちもおもしろい。なるほどなあ。

デザイン（見た目）とかプログラミングのほうばかり考えてると、こういう視線は持てないわけで。これからなんか作るときにこのへんをよく考えてみようと思った次第。

最初の記事へのはてブコメントもおもしろいです。「はてなブックマーク – nanapiの初期バージョンに検索窓がなかった理由 : ロケスタ社長日記」参照。

APIを提供しているサービスを利用して、新たにサイトを立ち上げてみた。

既存サイトの下位ディレクトリに新たに設置。
既存サイトはPHP4で作ってあったのだが、新規サイトはPHP5。

レンタルサーバーを2つ借りており、一方（サーバーA）はPHP4、もう一方（サーバーB）はPHP5。サーバーBは基本的にPHP5なのだけど、.htaccessを設定することで、ディレクトリごとにPHP4を使う設定も可能。
「PHPをCGIとして動かす方法について – CORESERVER.JP:コアサーバー」

ということで、サーバーBに既存サイト＋新規サイトの両方を移動。まずは、うまくいくかを確認。なんとか稼動している模様。

問題は、PHP5メインのサーバーBでPHP4を動かすには、CGIモードにする必要があること。この場合、多少、負荷がかかるという。これは様子を見ながら対処を考えることにする。

というわけで、一部の人にデザインなどをチェックしてもらうことにするのです。感想などありましたら、ここにコメントでお願いします。

なお、既存サイトと新規サイトにはまだ相互のリンクは張っていない。テスト期間なので当然だ。では、よろしくお願いします。

PHPでプログラミング。

ショッピング系のウェブサービスで取得したXMLの要素にアクセスするわけだが、複数の商品に対して同じことをするのである。商品名と価格などを取り出すのだ。

で、それぞれの商品に対して、というところでループの方法がいくつかPHPに用意されており、同じような結果が得られる。

forを使うか、それとも、foreachを使うか。

ということが気になって調べたらこんなエントリを発見。

「PHP 配列を回すならforかforeachか | Shin x blog」

PHPの人はだいたいforeachを使うみたいです。

他の言語の人はどんな感じでしょう？　似たような構文が何種類かあるわけですよね？　perlってどうだったっけ？　長いこと触ってないので思い出せない。

なるほど、そういう方法があったか。GAEは使ってるけど、こういうのは思いつかなかった。

というのが、Google App Engine（GAE）を使ったPROXY構築の話。「Google App Engine で自分専用 Proxy – ちからの備忘録的日記」から。これ、試すだけならプログラミングそのものはまったく不要ですね。GAEのアカウントのとり方とかも解説してあります。いい記事です。時間が空いたら試してレポートしてみたいと思います。いや、各自やってみましょう。ということで。

GAEそのものについてはここから。Python、Javaが動くレンタルサーバーですね。大雑把にいえば。いや、だいぶ誤解を与えそうな表現ですが。「Google 技術を使用してスケーラブルな Web アプリケーションを作成する環境」ってとこですか。わかりにくい。

WordPressの便利なところはプラグインでカンタンに機能を拡張できることだ。

地図を載せるのに便利なのは「Lightweight Google Maps (地図プラグイン)」というもの。

緯度・経度情報をカスタムフィールドに入力すれば、その地点の地図が掲載できるのだ（カスタムフィールドについては後述）。

しかし、緯度・経度の割り出しは別途行う必要がある。これをカンタンにしてくれるプラグインもある。

「Google Maps Anywhere (地図表示)」というのがそれ。

これ自体も地図を表示するプラグインだが、地図の表示はショートコードという仕組みを使う。

このプラグインの便利なところは、記事投稿画面でキーワードによる地図検索ができて、緯度・経度の割り出しもGUIでできるところだ。別のウィンドウを開く必要もない。

で、記事に地図を入れる際には前述のとおりショートコードというWordPress独自の機能を使うのだが、単にカスタムフィールドに緯度・経度を挿入するためだけにも使用できる。これがポイント。

「Google Maps Anywhere」で緯度・経度情報をカスタムフィールドに追加、そのカスタムフィールドの情報を基に「Lightweight Google Maps」が地図を表示してくれる。記事自体になんらかの情報を入れる必要はない。

これが私がたどり着いたプラグインによるシンプルかつカンタンな地図挿入の方法だ。もちろん、ほかにもいろいろ方法があるのだけど、これに落ち着いている。

で、カスタムフィールドについてもちょっと解説。
WordPressだけでなくMovableTypeなどにも同様の仕組みがあるようなのだけども。
記事にヒモつけしたデータベースみたいなものか。キーと値のペアで、記事に情報が付加できると考えればいいかも。この情報を基にさまざまな処理が行える。処理はプログラミング次第なわけだけど、たとえば、上のLightweight Google Mapsでは、各投稿で設定したカスタムフィールドの値を複数取り出して、1つの地図（「固定の地図ページ」と呼んでいる）にマッピングするということができるようになっている。

最近は、こうして入力したカスタムフィールドの情報を基にさらに別の情報をウェブサービスから取得して表示するというプラグインを自分で作って遊んでいる。いわばマッシュアップという感じ。プログラミングの楽しみはこういうところにあるんだなあ、と思う今日この頃。

個別記事のページで表示される商品のリストをキャッシュするようにしてみました。

API使用の規約に反する可能性があるようなので、対処、といった感じ。

久々にプログラミングしてみました。