Tridentfield

OSXのSpotlightは確かに便利なのだけど、オープンソースとかの大量のソースコードを置いておくとそれまでも検索対象となってしまうため、非常にうざい。そういう時は特定のディレクトリをSpotlightの検索対象から外すようにしている。

「システム設定」の「Spotlight」の「プライバシー」から検索対象から外すディレクトリを追加する事が出来る。

  

HTML5のHistory APIについて調べてみた。

History APIはJavascriptからブラウザのヒストリ情報を操作するためのAPIで、ページの全体的な更新なしにロケーション情報のURLを書き換える事ができ、今までのAjaxのページの一部のみを更新するような場合に対して、アプリケーション側からローケーションバーのURLを設定する事が出来るようになり、1つのURLに対して1つのリソースというWebの大原則に従う事ができるようなる。
手前味噌のこちらのサンプルでは、Ajaxを使用してページの一部を更新しているが、ロケーションバーの値が変わり、ブラウザの進む、戻るによって、表示内容が切り替わっている事が確認できる。

History APIで重要なのは、

1. historyオブジェクト
   URLの履歴を管理しているオブジェクト。
2. popstateイベント
   ユーザーのブラウザの進む、戻る操作時に発生するイベント。

の二つ。簡単に説明すると、URLを書き換えたい場合にhistoryオブジェクトにURLをスタックし、ブラウザの進む、戻るイベント時にhistoryオブジェクトから渡ってきた繊維先のURLに対応した処理を行う。

サンプルの動作を例に説明すると、”pege1(もしくはpage2)”のクリックイベントで、コンテンツを切り替える処理を呼び出し、historyオブジェクトにURLをスタックさせる。このサンプルでは<a>タグを使用しているので、このまま処理を抜けると、ページ全体が遷移してしまうのでpreventDefault()メソッドで<a>タグによる画面遷移を止める。

function menuItemClickHandler(e)
{
	swapContents(this.href);
	history.pushState(null, null, this.href);
	e.preventDefault();
}

メニューのクリックイベント時から呼ばれるコンテンツを切り替える処理では、遷移先のURLを読み込んで画面の一部を書き換える。このサンプルではページ本体のURLが渡ってきた場合は、初期値を設定するようにしている。そうしないと、自分のURLが渡ってきたときに、自分自身をページに表示してしまうからだ。

function swapContents(url)
{
	if (url.indexOf('index.html') >= 0) {
		document.getElementById('contents-body').innerHTML = defaultContents_;
	} else {
		var xhr = new XMLHttpRequest();
		xhr.open('GET', url, false);
		xhr.send(null);
		if (xhr.status == 200) {
			document.getElementById('contents-body').innerHTML = xhr.responseText;
		}
	}
}

次に、ブラウザの進む、戻る処理が発生したときのイベントを定義する。進む、戻る操作が発生したときに”popstate”イベントが発生するので、このイベントタイプにコンテンツを切り替えるswapContentsメソッドを呼ぶようにしている。

	window.addEventListener('popstate',
		function(e) {
			swapContents(location.pathname);
		}, false
	);

このHistory APIを使えば、比較的問題になっていたAjaxを使用したリッチクライアントの進む、戻る処理に対応する事ができるので、HTML5の中でも地味に便利な機能なのでないかと思う今日この頃。

ソースコードはこちらのgithubで共有しています。

参考サイト：
History API – Dive Into HTML5 (日本語訳)

僕はシステム開発に携わるプログラマで、主にサービス層から上位のクライアント層をメインに開発してきた。もちろんDBも扱うのだけど、いまいちDBの中身がブラックボックスっぽくて深入りする気になれず、少し距離を置いていた。

ところが、最近は超大量データを処理するSQLをチューニングする必要がでてきて、真剣にデータベースの挙動について理解しないといけない状況になっていた矢先にこの本を同僚から紹介された。

“データベースパフォーマンスアップの教科書 基本原理編” (エンコアコンサルティング)

この本はよくあるSQLについてではなく、データベースそのものの概念や挙動について論理的に書かれているのでDBに対して深い理解が得られた。特に、実行計画から分かる細かいDBの動作や、最適なジョイン方法についての考察など、今までさほど深く考えずにいた内容に対して論理的に説明されているので、すいすい頭に入ってくる。

結局、実践に勝るものはないと思うのだけど、こうした論理的にDBを理解できていることで、予めパフォーマンスの良いSQLを書けたり、テーブル構成やインデックスの張り方などを設計段階から意識できるようになれるだろう。特にテーブル構成や、レコードの引き方はアプリケーションロジックにも大きな影響を与えるので、このあたりを設計段階の初期から考えられると開発後期にありがちなパフォーマンスチューニングによる大幅なSQLの書き換えや、テーブル変更はグッと抑えられるはず。

SQLはある程度書けるけど、もう一段階上のレベルのDB設計やSQLを書けるようになりたい人にはお勧めの一冊です。