ブログを「Google App Engine」（GAE）で構築してみました。

GAEの良い点は２つ。
・無料！（およそ1日1万PVまで無料）
・サーバ側の知識がなくてもOK！
ですので、非常に手を出しやすいクラウド環境と言えます。

使える言語は JAVA と Python だけなのがちょっと残念ですが、勉強がてらPythonでブログを動かしてみました。

まずは PythonとGAEについて学習

ブログを動かす前に、PythonとGAE上でのアプリ構築の仕方を以下のサイトで学習しました。

・Python入門
最初に、Pythonとはどういう言語なのか？を理解するのにちょうどいいです。

・スタート ガイド: Python – Google App Engine
Googleオフィシャルのチュートリアル。GAEで簡単にWEBアプリが作れるというのを実感できます。

・Webコピペ屋
基本的なCRUD（作成・読み出し・更新・削除）の実装、GAE特有のデータベース「Datastore」の使い方を、丁寧に解説しているので非常に役に立ちました。

また、入門書として「初めてのPython 第3版」というオライリー本を読みました。かなり深いところまで解説した入門書なので分厚いですが、一通り眺めておくと、後々、役に立ちそうです。

GAEでブログを動かそう

GAE で動作するブログシステムはいくつかあります。（参考：GAE上で動くブログエンジンまとめ）
その中でも見た目と機能がシンプルで、かつソースコードも見やすそうな「Bloggart」を利用しました。

Bloggartのインストール、といってもそれほど面倒なことはなく、config.py（設定ファイル）を適宜編集してあげればOKです。
インストールについては、下記のブログを参考にしました。
・プログラマの実態: Bloggart を動かしてみる
・Bloggartのインストールから初期設定まで – The Windup Nano on GAE

画像のアップロードについて

Bloggartには、画像のアップロード機能がありません。ですが、GAEで画像などの容量の大きなファイルを扱うために Blobstore という機能がありますので、これを利用してアップロード機能を追加しました。

・Google App Engine で Blobstore を使ってみる – present

問題なのは、Blobstore は課金を有効にしないとGAE上で使用できないところです。（ローカルの開発環境であればBlobstoreも使用できます）
ですが、課金を有効にした上で、無料使用に収まる程度に押さえておけば問題ないだろうということで、僕は1日あたりの予算を0.1$に設定しました。

Bloggartのソースコードを読む

GAEでは、データの転送量やCPUの使用時間によって使用料金が決まってきます。ですので、負荷をかけない効率的なソースコードがすることが大切です。

また、Datastoreに都度アクセスするよりもキャッシュ（Memcache）を利用した方が負荷が減ります。BloggartでもMemcacheを利用して、負荷を減らしているので、自分でアプリを制作する際にも参考になります。

久々にFlashのお勉強を再開しています。割とよく見るようなものを習作として作ってみました。CPUに負荷かけまくりなので、もうちょい精進します……

CakePHPでハマったのでメモ。バージョンは1.2.0.7296 RC2。
HABTMのテーブルを検索する方法と、そのときのpagenateを正しく取得する方法です。

いわゆるBlogの記事に複数のタグを付けるとして、
以下のようなテーブルがあるとします。
————————————
posts
-id
-title

posts_tags
-post_id
-tag_id

tags
-id
-name
————————————

記事のタイトルとタグの名称の両方をLIKEで検索します。

コントローラのposts_controller.phpのsearchメソッドのなかで、paginateでデータを引っ張ってきます。
paginateのjoinsの指定で、posts_tagsとtagsをINNER JOINしてあげて、conditionsでLIKE検索の条件を渡してあげます。

$joins = array(
	array(
		'table' => 'posts_tags',
		'alias' => 'PostsTag',
		'type' => 'INNER',
		'conditions' => 'PostsTag.post_id = Post.id'
	),
	array(
		'table' => 'tags',
		'alias' => 'Tag',
		'type' => 'INNER',
		'conditions' => 'Tag.id = PostsTag.tag_id'
	)
);
$conditions = array(
	'OR' => array(
		'Post.title LIKE' => '%検索ワード%' ,
		'Tag.name LIKE' => '%検索ワード%' ,
	);
);
$this->paginate = array(
	'joins' => $joins,
	'conditions' => $conditions,
	//複数のpostsが引っかかるので、idでまとめる
	'group' => array('Post.id')
);

このとき、paginateでのページ送り機能が正しく動作しません。
これを回避するためモデルのpost.phpでpaginateCountメソッドを上書きします。取得するデータの総数を返してあげています。マニュアルにもさりげなく書いてあります。

→ 4.9.4 カスタムしたクエリによるページ付け

function paginateCount($conditions, $recursive) {
	$where = “”;
	if($conditions){
		$db =& ConnectionManager::getDataSource($this->useDbConfig);
		$where = $db->conditions($conditions);
	}


	$result = $this->query('SELECT Post.id FROM posts AS Post
		INNER JOIN posts_tags AS `PostsTag` ON (`PostsTag`.`post_id` = `Post`.`id`)
		INNER JOIN tags AS `Tag` ON (`Tag`.`id` = `PostsTag`.`tag_id`)’ .$where. ' GROUP BY `Post`.`id`’);

	return count($result);
}

ちなみに、CakePHPはSQL文を書かなくてもある程度は自動で組み立てくれたりしてコードを書く量は減るけど、これをやるにはどうするの？という方法を調べるのに時間がかかります。自分の中でノウハウが蓄積されていけば開発スピードは上がりそうです。

飯野賢治さんのBlogによい話が載っていたのでメモ。 きみとぼくと設計。　〜最終回「仲間との開発」〜

例えば、なにか議題となる題材があったとして、それを誰かが投げる。

すると、僕が「うーん」と考える。場合によっては誰かに訊いたりする。 訊かなくても意見が出たりして、それに対して、僕が応えたりする。 最終的に、「こうしよう」というのを、僕が決める。

たったこれだけのことでも、どういうプロセスを踏んで どう僕が迷って、悩んで、それを、どういうふうに伝えて、そして その背景にはどういう理由があって、など全部伝わる。

というのと、結果の仕様だけ伝わる というのでは、僕は、ぜんぜん開発の最終形が変わると思います。

効率ではなく、結果を求めて、そのような形で進めたほうが 最終的には、実は効率がよくなる、のです。

効率だけを求めると、そこからこぼれ落ちる要素もある、と。

（全員参加のミーティングが）週に１〜２回ですから、ぜんぶで１００回以上......もっとかな？ あったと思うのですが、僕は、毎回毎回、「異なるお菓子」を用意しました。

なるべく、違うお店で買って。もちろん、美味しいお店で買って。

たぶん、３〜４回は、忘れててダブったこともあると思いますが いつもいつも、テーブルの上には、いつもと違うお菓子が、人数ぶん置かれていました。

どんなに忙しいときも買いにいきました。 お店を選んで、どのお菓子が良いかを考えて、季節なんかも気にしたりして。

そんなことが、「面白いものを作ろう」「ちょっとでも楽しくしよう」という ゲーム開発にとって、ものすごく大事な「考え」というものに入れ替わって みんなに伝わっていったと、僕は思っています。

飯野さんは日常のちょっとしたことろに、「遊び」の要素を入れるのが抜群に上手い人という印象があります。このお菓子のエピソードも、毎回違うお菓子を用意することでミーティン参加者が「今日のおやつは何だろう！」という気持ちになって、ミーティングに参加するのがちょっと楽しくなりますもんね。

僕の所属するWEB制作会社は人数がいないので大規模サイトの案件はあまりやらないのですが、ここ最近立て続けに大規模サイトのリニューアルのお仕事が来たので、気がついたことをメモしておきます。

（09/04/08：プログラマの友人からアドバイス＆指摘があった箇所を追記しました。）

1. サイト全体を俯瞰する資料を作るべし。

いわゆるサイトマップとかディレクトリ構成表とか呼ばれるものです。大規模サイトになるとこの手の資料を見やすく作るのはなかなか難しいですが、見やすい資料があればプロジェクトメンバー全員が同じ完成系をイメージしやすくなります。

※追記：資料を作るのにマインドマップを利用してはどうかというアドバイスをもらいました。今まではExcel、プレゼン要素が大きい場合はillustratorで作っていましたが、「FreeMind」などのマインドマップツールを利用して簡単に作って情報共有するのもアリですね。
【マインドマップ → 全体を把握しやすい】という特長があるので、【全体を把握する必要があるもの → マインドマップで作る】ということです。

2. クライアントがどのように更新するか。

クライアント自身が更新業務を行う場合、そのWEBリテラシーに応じて、
・普通のHTML+CSS
・DreamWeaverのテンプレ機能
・WordPressといったCMSを使う
といった、どの技術でサイトを構築するかを決めておきましょう。それぞれのメリット／デメリットをクライアントに説明しておくことも必要です。

3. 全ページのモックアップを作るべし。

ナビゲーションデザインやページ遷移、インフォメーションデザインを意識して作りましょう。
1ページのデザイン案だけでは分からない、サイト全体を見た上での問題をこの時点であぶり出しておくのが大事。
全ページ作るのがポイントです。そうしないと潜在的な問題点が制作後半まで分からないままになります。

4. グリッドを定義するべし。

PhotoshopおよびCSSでも、明確なグリッドデザインのルールを決めておく。そうすれば複数人で制作してもデザインやHTMLソースにブレが少なくなります。

5. 原稿を管理するべし。

クライアントからもらった原稿や逐次入る修正内容をチーム内で共有しておくのに、「GoogleSites」を使うと良さそうです。（まだ使ったことはないです。。）
メールでのやり取りだと情報が散らばってしまい、情報共有のコストが無駄にかかってしまいます。
また、GoogleSitesは上記(３)のモック制作にも使えそうです。
→GoogleSitesを使って制作プロジェクトをハックしよう

6. 全体のToDoリストをまとめるべし。

ToDoは細かく設定しておくこと。例えば「問い合わせフォームを作る」にしても、それがPHPなのかPerlなのか、フォームの項目は何か、入れる文章をどうするか等....
細かく設定しておかないと、見通せない部分が出てきます。

※追記：プロジェクト管理に「バックログ」がいいんじゃないかと。まだ試していないので何とも言えませんが、ユーザインターフェイスはいい感じです。

7. 早めに技術検証をしておこう。テストファースト。

使用する技術が本番環境でキチンと動くかどうかを、初期段階でテストしておくこと。後々になってダメでしたでは、泣きを見ます。

※追記：テストファーストじゃなくて、単なる「技術検証」じゃね？と指摘されました。僕の中でテストファーストという言葉が一人歩きしていました。。でも、「技術検証」を最初にやっておくのは大事ですよ！

8. ディレクターはディレクションしかするな。

案件の規模にもよりますが、ディレクションをする人が制作までやってしまうと、どうしても全体を見ることが難しくなるのでよろしくないです。 ディレクターは社内へのインプットと社外へのアウトプットをちゃんとフィルタリングする必要があるので、そこに精力を注ぎましょう。

9. 公開前のチェックをすべし

→サイト公開前に役立つ２５のユーザビリティチェックリスト:phpspot開発日誌

こちらのリンク先にチェックリストがまとまっていますが、公開前に気づいても遅いよ！というのが幾つかありますね。。画像のALTは以外と間違えちゃっていることが多いので、気をつけましょう。

10. 運用のガイドラインをまとめるべし

サイトの更新を社内でやるのかクライアントがやるのか、はたまた社外でやるのかによりますが、サイトを運用する上で、見出しに使用しているフォントや、写真データ・PSDデータを分かりやすくまとめておきましょう。CMSを組み込んだ場合は、使い方をまとめておきましょう。