プログラマならできること: 7月 2010

2010年7月24日土曜日

PHP <?= ?> short_open_tag

php でつい便利だから <?= ?> を使っていると、環境を変えたときに動かなくなる場合があります。
php.ini の shrt_open_tag が On になっていないと使えないのですが、最近は <?xml ?> を扱い易くするために Off になっていることがあるようです。

MySQL 日本語を含むSQLスクリプトの実行

MySQL で日本語を含む SQL スクリプトをバッチファイルなどで実行したい場合は、以下のように
--default-character-set を指定します。
例えば UTF-8 で SQL スクリプトファイルを作成していた場合、

mysql -h localhost -P 3306 -u root -ppassword --default-character-set=utf8 < script.sql

my.cnf で予め指定しておくという方法もありますが、スクリプトをいろいろな環境で実行する場合は面倒です。

MySQL パスワードの変更

MySQL をインストール後、root のパスワードが設定されていないときはすぐに下記の SQL 文で設定しましょう。
No Password で接続後、

set password for root@localhost = password('qg2UMQtT')

'qg2UMQtT' の部分はもちろん他のパスワードを指定してください。

2010年7月23日金曜日

twitter のユーザーホーム URL (PC、携帯共用)

今まで

http://www.twitter.com/user_id

というリンクで、PC、携帯ともに問題なく user_id のホームに移動できていましたが、昨日から急に携帯サイトへのリダイレクトがうまくいかなくなったようです。
他の方法はないか探してみたところ、リンクを携帯用の

http://twtr.jp/user/user_id/

にすると PC でもきちんと

http://twitter.com/user_id

にリダイレクトしてくれます。

2010年7月19日月曜日

携帯検索エンジンへの登録　(au Googlebot-Mobile)

携帯サイトを作ったら当然携帯で検索したときに見つかって欲しいと思うことでしょう。
au 携帯の場合は Google の検索エンジンに登録されれば良いのですが、これが意外と時間がかかります。Googlebot-Mobile がなかなか来てくれないのです。モバイル用ではない Googlebot はすぐ来ますが結果は PC サイト用のインデックスに登録されるだけです。
やり方は、

　1.　Google ウェブマスターツールにログインし新しいサイトを追加します
　2. 以下のようなモバイル用のサイトマップをドキュメントルートに作成しておき、ウェブマスターツールからサイトマップを送信します。
(例: sitemap.xml)

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
　xmlns:mobile="http://www.google.com/schemas/sitemap-mobile/1.0">
<url>
  <loc>http://example.jp/</loc><mobile:mobile/>
</url>
</urlset>

そして、
　3. あとはひたすら我慢強く待つ
です。
3. については新しくサイトを作ってから Googlebot-Mobile が来るまで３ヶ月もかかったことがあります。
Googlebot-Mobile は、以下のようなユーザーエージェントで来ますが、一度 Googlebot-Mobile が来ればあとは頻繁にやって来るようになります。

66.249.71.117 HTTP_USER_AGENT=SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

209.85.238.79 HTTP_USER_AGENT=DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

(IP アドレスの違いが気になったので、GEO IP TOOLで場所を調べたところ、DoCoMo が日本からということはなく、両方とも米国のサーバから来ていました)

2010年7月17日土曜日

PHP: each　と　配列カーソル

php で配列要素に関して反復処理を行うときに私は普段

foreach ($ar as $value)
foreach ($ar as &$value)
foreach ($ar as $key => $value)

を使いますが、気まぐれに each を使うことがあります。

while (list($key, $vlaue) = each($ar))

という使い方です。
でも、配列カーソルのことを意識していないと予想外の結果となるので注意が必要です。
reset() をループの直前に行う癖をつけておくと良いでしょう。

reset($ar);
while (list($key, $vlaue) = each($ar))

これは配列カーソルがどこにあるかを予想するのは意外に大変だからです。
例えば、

function func($ar) { // $ar は値渡し(参照渡しではない)
　while (list($key, $value) = each($ar)) {
　　echo "$key => $value\n";
　}
}

という関数を作り、

$ar[0] = "a";
$ar[1] = "b";
$ar[2] = "c";
foreach ($ar as $a) {
　if ($a == "a") break;　// 1つ目で止める
}

$ar2 = $ar;　// コピーしてみる

func($ar2);  // $ar2 を値渡し

を実行するとどうなるかわかりますか？
結果は、

1 => b
2 => c

です。
foreach はループの開始に配列カーソルを先頭要素にリセットしていますが、ループを抜けるときはそのままです。それでも foreach だけ使用していれば、毎回最初にリセットされるのでループを抜けるときの配列カーソルを意識する必要はありません。
途中違う変数にコピーしていますが、このとき配列カーソルの位置も律儀にコピーされてしまいます。
func() を呼ぶときは値渡しなのですが、配列カーソルの位置も渡ってしまいます。
func() を記述している時点では、$ar の配列カーソルが先頭にないなんて予想しないでしょうが、実際には渡ってくる変数の配列カーソルの位置で結果が違ってしまいます。
ちなみに、foreach のループを途中で止めないと終了時に配列カーソルをリセットしてくれ、結果は

=> a
=> b
=> c

となります。
以上のように配列カーソルの位置を見極めるにはその配列が使われる場所を追跡しないとなりません。
each() を利用する場合は不思議なことが起こらないように最初に reset() してからということですね。

アクセス解析 (Google Analytics + Blogger)

Blogger は Google が運営しているんだからアクセス解析機能は当然あるだろうと思われるかもしれません。ところがメニューを見てもヘルプを見ても見つかりません。
Blogger にはないのです。
結局 Google Analytics を利用するのですが、Analytics は機能も豊富だし Blogger 独自のアクセス解析機能を持たせる必要はないという判断なのでしょうね。

1. http://www.google.com/intl/ja/analytics/ にアクセスします
2. 初めて利用なら「今すぐお申し込み」です
3. プロファイルを新規作成するとJava スクリプトのトラッキングコードが表示されるのでコピーします
4. Blogger の「デザイン」メニューから「HTML の編集」を選択し、テンプレートの HTML の <head> タグの直後にトラッキングコードをペーストします
5. テンプレートを保存すれば設定は完了です

2010年7月14日水曜日

クラウド利用のファイル共有（Amazon　EC2 + Serv-U)

クラウドとは何でしょうか？

多数のコンピュータシステムが雲の中にいて、それらが必要に応じて仕事をするという概念図をよく見かけます。Amazon EC2 を実際に利用してみるまで、雲の中のコンピュータを利用するには難しいシステム開発が必要で費用も随分とかかり我々中小企業には無縁のものと思っていました。

ところが,

１．一番気になる費用は月額9,000円程度から

　Standard(Small/Windows) 利用料 12円/時間
　1か月 12円*24時間*30日 = 8,640円
　1年 12円*24時間*365日 = 105,120円

　1年契約だと予約料22,750円、利用料 6円/時間 となり
　1年 22,750円 + 6円*24時間*365日 = 75,310円(6,276円/月)
　(1ドル100円換算、データセンター：シンガポール)

3年契約だともっと安くなりますし、営業日の業務時間内だけインスタンスを実行するなら費用は1/3以下になる可能性もあります。

実は他にデータの通信費もかかります。

　内向きのデータ転送 2010/11/1 まで無料
　外向きのデータ転送 1GB まで無料、その後 19円/1GB
　パブリック IP を使った転送 1円/1GB追加

さらにデータの保存場所にデータ量に応じた費用がかかりますが、大量にデータを置かない限りはそれほど高額にはならないと思われます。

２．難しく考えず専用サーバを持ったと思えばいい

クラウドを利用するにはクラウド用の難しいシステムを開発しなくてはいけないかというとそんなことはありませんでした。
Amazon EC2 はインフラ環境を提供するクラウドで、サーバマシン、OS(Linux/WIndows)、通信回線など必要なシステムを Web から購入確保し、起動停止などの制御も Web から行える仕組みです。購入したインフラ上では特に高度なシステムではなくWebサーバやメールサーバだけ運用しても構わないのです。多くの会社にお薦めしたいのはそういう使い方です。今までの考え方で言うなら上記の費用で専用サーバが持てると思えばわかりやすいかもしれません。
Web サーバを構築するだけなら他に費用はかかりません。上記費用には Windows Server OS の利用料も含まれいるのです。Linux ならコストは下がるのですが、敢えて Windows を想定しているのは最近のリモートデスクトップの使用感は素晴らしいですし、また、せっかく専用サーバを持っても Linux だと専門の人にセットアップや管理をお願いしなくてはならず、結果的にコストアップに繋がりかねません。きっと確保した専用サーバの新しい利用法を考えたりする頻度も下がることでしょう。
話はそれますが、現状のインターネット環境であればリモートデスクトップ経由での作業はローカル環境と間違えるくらいの感覚で行えます。私自身は最近のプログラム開発を全てリモートデスクトップを経由したサーバマシン上で行っており、クライアントPCや場所を選ばず作業をしています。

３．利用開始は思ったより簡単。１時間後には顧客とのファイル交換用サーバが稼働！

Amazon EC2 のコスト感や実体がわかって来たところで利用法を考えてみました。
インターネット上にはファイル交換サービスがいろいろとありますが、機密ファイルはとても預ける気にはなれない方がほとんどだと思います。今まで私の会社ではパートナーや顧客とのファイル交換のために自社内にファイル交換用サーバを置いていました。プログラム開発業務の他にファイルサーバソフトも取り扱っている関係でファイル交換用サーバは当然ながらそのソフトを利用して構築しました。しかしながら、自社内にサーバを置くには、マシンを購入し、Windows Server OS も購入し、パブリック IP アドレスを持つために月額10万円近い回線維持料を払い続ける必要があります。マシンはいずれ壊れるし、バックアップも考えなければいけないし、Windows Server も安くはありません。空調などの電気代も気になるところでしょう。何よりも問題なのは、よく考えると別に24/7で運用する必要もないのに、スイッチを切って削れるのは電気代くらいということです。
会社で取り扱っているファイルサーバソフトは Serv-U(http://www.serv-u.jp) という15年の歴史があるソフトで今ではバージョン10まで上がっており、ブラウザで簡単にファイル交換できます。管理もリモートからすべてブラウザで出来ます。非常に優れたソフトで気に入ってもいたのですが、Amazon EC2 を試すまではサーバ構築費がネックになり正直なところ中小企業には負担が大きいかなと思っていました。
でも Amazon EC2 + Serv-U の組み合わせなら一気に問題解決です。

　サーバマシンの購入は必要ありません
　ディスクは必要な分だけ何時でもすぐに確保できます
　ハードの故障は考慮する必要がありません(これぞクラウドですね)
　Windows Server OS の購入も不要です
　オフィスのインターネット接続はアクセス用の契約で十分です
　空調完備のマシンルーム確保も不要です
　そして何よりも運用時間外のコストは発生しません

さらにクラウド環境なら安全性も向上します。

　データセンターのセキュリティは非常に厳しく巨大企業しか達成できないレベルです
　顧客の機密データ取扱に対する高い基準の監査を受けています

さて実際の利用開始ですが、
Amazon EC2 では購入や制御に全く人手が介入しません。現在英語の Web ページしかありませんが、Amazon の担当者と連絡をとる必要は一切ないので英語が苦手な私でも問題なく利用開始できました。
最初だけ Windows Server が起動するのに15分ほどかかりますが、それ以外はあまり待つところはありません。クレジットカードがあればすぐに利用開始できます。

　Amazon Web Services(https://aws.amazon.com/)にアクセス
　右上の Amazon Web Services Account の Sign Up(無料)を選択
　Amazon Elastic Compute Clund(Amazon EC2) の Sing Up に進む
　クレジットカード番号と請求先住所等を登録する
　その後携帯電話の番号を入力して Call Me Now ボタンを押すとすぐに電話がかかってくる
　このときだけ緊張すると思うが、自動音声が流れるだけで内容はわからなくても問題ない
　(確か PIN コードを入力してくださいというような意味の英語)
　ボタンを押した後画面に表示されてる４桁のPINコードを電話のボンタで押せば確認完了
　海外から繋がらない携帯電話は当然無理だと思うのでその場合は固定電話で

以上で Amazon EC2 は利用可能となります。
その後、

　AWS Management Console に Sign in する
　(管理はすべてAWS Management Consoleで行えます)
　Getting Stanted の Launch Instance を選択
　Request Instances Wizard が開く
　Quick Start の中で Basic Microsft Windows Server 2008 を選択
　Instance Type で Small(ma.small, 1.7GB)、Launch Instances 選択状態で Continue を押す
　Adbanced Instance　Options はデフォルトのまま Continue を押す
　Create a new Key Pair で name を適当に入力し、Create & Download your Key Pair を押す
　PEM ファイル(プライベートキー)がダウンロードされる
　Create a new Security Group でセキュリティグループに適当な名前を付ける
　とりあえずリモートデスクトップ用の RDP/tcp/3389 がオープンになっている状態で Continue を押す
　これまでの設定内容が表示されるので確認し Launch を押して起動
　1、2分でインスタンスが起動するで画面左の Navigation から Instances を選択
　起動したインスタンスを選択し、Instance Actions の Get Windows Admin Password を選択
　すると Administrator アカウントが有効になるまで15分かかるとメッセージが出るのでしばらく待つ
　有効であれば Private Key を入力する画面になるのでダウンロードしてあったキーをペーストする
　Decrypt Password を押すとAdministrator のパスワードが表示される
　リモートデスクトップでアクセスするにはインスタンスの Public DNS にアクセスする 
　Administrator のパスワードを取得しリモートデスクトップで接続する

リモートデスクトップで接続できれば後は見慣れた Windows 画面ですが、ここで油断してはいけません。Instance Actions で Terminate を選択すると、インスタンスは消えてしまいここまでの作業は水の泡です。出来あがったインスタンスはこまめにイメージを保存する必要があります。これは Amazon Machine Images (AMI) と呼ばれ、システムを変更した度に作成します。次回起動するときは起動するイメージを選択すれば良いのです。つまり様々な時点でのフルバックアップが簡単に行え、そこから簡単に起動もできます。しかも同じイメージを元に何台でも起動できます。クラウドにサーバを設置した方が良いとお薦めする理由はここにもあります。

　Administrator のパスワードを変更する
　英語表示なのでコントロールパネルで言語を日本語に変更する
　ここでとりあえず Instance Actions の Create Image を選択しイメージが出来るのを待つ

さらに作業を続けます。

　Serv-U をインストールする
　Security Groups を選択しオープンするポートを追加する
　　ブラウザ利用のための HTTP 80 と HTTPS 443 をオープンにする
　　FTP も使うなら tcp 20 から 21 もオープン
　　パッシブモード用のポート範囲を Serv-U で指定し、同じ範囲をオープン(例 tcp 4000-4029)　
　パブリック IP を割り当てるため Elastic IP を取得
　DNS サーバで適当な名前にその IP を割り当てる
　後は Serv-U に利用者用のアカウントを作成
　ここで忘れずに Instance Actions の Create Image を行う

これで自社ファイルサーバの構築完了、運用開始です！