技術水準の向上により人はいままでにない可能性を有するに至ったが、それは人を幸福にさせる一方で、破滅的な事態を招く要因にもなりうる。時代は、高い技術力と同レベルの倫理観を人々に求めるようになってきている。

これはウェブも同じ。技術の新規性や目先の利益にとらわれない、本当の意味で人に還元できる方法を常に考えていかなくてはならない。

1. 「美しい国土」、「安全にして安心できる生活」、「豊かな社会」をつくり、改善し、維持するためにその技術を活用し、品位と名誉を重んじ、知徳をもって社会に貢献する。
2. 自然を尊重し、現在および将来の人々の安全と福祉、健康に対する責任を最優先し、人類の持続的発展を目指して、自然および地球環境の保全と活用を図る。
3. 固有の文化に根ざした伝統技術を尊重し、先端技術の開発研究に努め、国際交流を進展させ、相互の文化を深く理解し、人類の福利高揚と安全を図る。
4. 自己の属する組織にとらわれることなく、専門的知識、技術、経験を踏まえ、総合的見地から土木事業を遂行する。
5. 専門的知識と経験の蓄積に基づき、自己の信念と良心にしたがって報告などの発表、意見の開陳を行う。
6. 長期性、大規模性、不可逆性を有する土木事業を遂行するため、地球の持続的発展や人々の安全、福祉、健康に関する情報は公開する。
7. 公衆、土木事業の依頼者および自身に対して公平、不偏な態度を保ち、誠実に業務を行う。
8. 技術的業務に関して雇用者、もしくは依頼者の誠実な代理人、あるいは受託者として行動する。
9. 人種、宗教、性、年齢に拘わらず、あらゆる人々を公平に扱う。
10. 法律、条例、規則、契約等に従って業務を行い、不当な対価を直接または間接に、与え、求め、または受け取らない。
11. 土木施設・構造物の機能、形態、および構造特性を理解し、その計画、設計、建設、維持、あるいは廃棄にあたって、先端技術のみならず伝統技術の活用を図り、生態系の維持および美の構成、ならびに歴史的遺産の保存に留意する。
12. 自己の専門的能力の向上を図り、学理・工法の研究に励み、進んでその結果を学会等に公表し、技術の発展に貢献する。
13. 自己の人格、知識、および経験を活用して人材の育成に努め、それらの人々の専門的能力を向上させるための支援を行う。
14. 自己の業務についてその意義と役割を積極的に説明し、それへの批判に誠実に対応する。さらに必要に応じて、自己および他者の業務を適切に評価し、積極的に見解を表明する。
15. 本会の定める倫理規定に従って行動し、土木技術者の社会的評価の向上に不断の努力を重ねる。とくに土木学会会員は、率先してこの規定を遵守する。

（土木学会「土木技術者の倫理規定」より引用）

APC については以下が詳しい。

• http://jp.php.net/manual/ja/ref.apc.php
• http://pecl.php.net/package/APC

導入に当たって、必要（となりそう）なパッケージを apt-get でインストール（以下パッケージはすでに導入済みだったため、今回の導入に当たっての必要/不要の確認はできていない）。

# apt-get php4-dev gcc g++ make

APC の導入手順は以下のとおり。pecl コマンドが使える環境ではより簡単という話だが、Debian GNU/Linux Sarge では使えず、地道にコンパイルする方法をとった。

~# mkdir apc
~# cd apc/
~/apc# ls
~/apc# wget http://pecl.php.net/get/APC-3.0.14.tgz
~/apc# tar zxvf APC-3.0.14.tgz
~/apc# cd APC-3.0.14/
~/apc/APC-3.0.14# phpize
~/apc/APC-3.0.14# ./configure  --enable-apc
~/apc/APC-3.0.14# make
~/apc/APC-3.0.14# make install
~/apc/APC-3.0.14# ls /usr/lib/php4/20020429
apc.so    curl.so   gd.so     json.so   mysql.so
~/apc/APC-3.0.14# vim /etc/php4/apache/php.ini (以下を追記)
extension=apc.so
~/apc/APC-3.0.14# /etc/init.d/apache restart

導入が完了し、ここで効果測定を、、、行ってみたものの、APCデフォルト設定＋HTML読み込み速度の簡単計測では、それほど差が見られず、もう少し検証が必要そうな状況。さらに設定など調整のうえ様子を見ていくつもり。

YSlow
http://developer.yahoo.com/yslow/

YSlow のベースとなる考え方は Exceptional Performance や High Performance Web Sites (slides) に示されているが、以下13項目を実行に移すことがパフォーマンス改善につながるとしている。JavaScript/CSS を外部ファイルに、といった基本的なことのみならず、CSS はページ冒頭に、JavaScript はページ下部に、といったもう一歩踏み込んだ形で改善方法を示しているのが、興味深い。

Rules for High Performance Web Sites

1. Make Fewer HTTP Requests
2. Use a Content Delivery Network
3. Add an Expires Header
4. Gzip Components
5. Put CSS at the Top
6. Move Scripts to the Bottom
7. Avoid CSS Expressions
8. Make JavaScript and CSS External
9. Reduce DNS Lookups
10. Minify JavaScript
11. Avoid Redirects
12. Remove Duplicate Scripts
13. Configure ETags

（ Exceptional Performance より）

この個人 blog で CDN なんて無理、広告やアクセス統計で外部ドメインの JavaScript を読み込んでるので、DNS Lookup を減らしようがない、といったところはあるけど、上記に基づき、いくつか改善を行ったので、メモしておく。

改善1 – mod_gzip による gzip 化

まず Gzip 化について。Gzip 化にあたり、使用しているサーバ環境（Debian GNU/Linux Sarge）では、以下パッケージが必要になるので、apt-get でインストール。

libapache-mod-gzip
http://packages.debian.org/sarge/libapache-mod-gzip

※注
apache 2.0 以降は、mod_gzip ではなく mod_deflate を使う模様。現在の環境が、apache 1.3 系なため、mod_gzip を使う前提で話を進める。

/etc/apache/modules.conf に以下記述が追加されていることを確認する。

LoadModule gzip_module /usr/lib/apache/1.3/mod_gzip.so

apache の設定ファイルに、以下記述を追加する。

<IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_can_negotiate Yes
mod_gzip_update_static No
mod_gzip_temp_dir /tmp
mod_gzip_keep_workfiles No

mod_gzip_minimum_file_size 500
mod_gzip_maximum_file_size 0
mod_gzip_maximum_inmem_size 60000
mod_gzip_min_http 1000
mod_gzip_handle_methods GET POST

mod_gzip_dechunk yes

mod_gzip_item_include file \.css$
mod_gzip_item_include file \.js$
</IfModule>

Netscape 3-4 で gzip 化された JavaScript が読めない、といった環境ごとに細かいバグがあるようだけど、取り急ぎ放置。

改善2 – PHP 側での gzip 化

上記だけでは、HTML ファイルの gzip 化がなされないので、PHP の設定ファイル /etc/php4/apache/php.ini に以下設定を追加した。

zlib.output_compression = On

改善3 – Expires Header

次に Expires Header について。以下を apache の設定ファイルに追加することにより対応完了。

ExpiresActive On
ExpiresDefault "access plus 10 years"

改善4 – ETag

次に ETag について。以下を apache の設定ファイルに追加することにより対応完了。

FileETag none

改善5 – CSS ファイル統合

この blog では、以下3つの CSS が使われており、YUI のものだったり、WordPress のテーマ付属のものだったり、と由来は異なるが、全ページに読み込まれるものなので、main.css ということでひとつにまとめた。

• reset-fonts-grids.css
• autocomplete.css
• style.css

なお、JavaScript については、先日の 記事検索の autocomplete 化 の際に統合済み。

効果測定

上記の改善を踏まえ、http://blog.shimazu.org/ での読み込みスピードで実施前後の比較を行った。

まずページ容量について。Firebug でページ容量を比較すると、

• 改善前: 276KB
• 改善後: 148KB

ということで、同じコンテンツなのに gzip 化により半分近い容量削減となった。改善前（左）・改善後（右）のキャプチャは以下のとおり。

YSlow の Performance Grade と呼ばれる指標でも比較してみた。すると、

• 改善前: Performance Grade: F (56)
• 改善後: Performance Grade: C (75)

といった感じで、こちらも改善が見られた。詳細結果は以下のとおり。

最後に、ページ読み込み速度を、yslow のステータスバーに読み込み時間を表示する機能を使って計測した。10回計って、平均を算出、という方法で、

• 改善前: 3.9954秒
• 改善後: 3.1822秒

という数字上はそれほど差が大きくないが、体感的には少し早くなったかな？という感じがする。詳細結果は以下のとおり。

ということで、YSlow によるボトルネック洗い出しとその改善を行ったが、Gzip は設定に若干てこずったものの、その他は簡単に実行可能な改善策で、結果を見ても、これらの施策は非常に有用な印象を持った。今後開発など進めるうえで表示パフォーマンスが気になったら、まず今回のような改善策を試そうと思う。

実装完了。

YUI のコードをコピペしただけで、インタラクションがちょっと中途半端（？）だけど。詰め作業は追ってやるつもり。

実装しようとしている autocomplete とは、（いうまでもないかもだけど）検索キーワードを何文字かキータイプしただけで何らかの補足情報が出る仕組み。「何らかの補足情報」とわざとぼかして書いたのは、サイトやアプリケーションによって、中身が微妙に違うからで、以下のように「関連語・頻出語の提示」と「ダイジェスト結果の提示」に分かれる（と思われる）。

関連語・頻出語の提示

• Yahoo!（サイト）
• Google Suggest（サイト）
• Firefox の検索窓（アプリケーション）

ダイジェスト結果の提示

• Apple（サイト）
• Mac OS X Spotlight（アプリケーション）

今回やろうとしているのは、「ダイジェスト結果の提示」のほう。関連するものの呼び出しとか素敵だけど、実装が手間そうだし、それ以前にそんなに記事も多くないので、割と簡単な「ダイジェスト結果の提示」で進めることにした。

まずはサーバ側での対応から。WordPress 向けテーマファイルをいろいろ見ているうちに、うまく使えそうな以下コードがあった（一部省略）。

<?php
require("../wp-blog-header.php");
$posts = query_posts('posts_per_page=10&s='.$_GET['s'].'&what_to_show=posts');
?>
<?php
if (!$posts) {
    echo '<div>Sorry, no results.</div>';
} else {
    foreach ($posts as $post) {
        start_wp(); ?>
        <div>
            <a href="<?php echo get_permalink() ?>" title="Permanent Link to '<?php the_title(); ?>'"><?php the_title(); ?></a>
            <a href="<?php comments_link(); ?>" title="Go the the comments for this entry"><?php comments_number('0', '1', '%'); ?></a><br />
            <?php /* If 'Dunstan's Time Since' plugin is installed use it; else use default. */
            if (function_exists('time_since')) {
                echo time_since(abs(strtotime($post->post_date_gmt . " GMT")), time());
                echo ' ago';
            } else {
                the_time('F jS, Y');
            }
            ?>
        </div>
<?php
    }
}
?>

これによりでシンプルな検索結果一覧を表示できるので、JSON とか受け取りやすいフォーマットに整形すれば JavaScript や Flash などでいろんなインタラクションがつくれそう。

フロントエンドでの実装には Yahoo! UI Library: AutoComplete を使用予定。安定した動作、上下キーでフォーカス移動、そして何より、Yahoo! トップページ での利用実績が強みと思われる。

補足：
PHP コードに登場する ‘Dunstan’s Time Since’ plugin とは日時の相対表示を実現するプラグインの模様。以下から取得でき、割とシンプルな実装で、使い勝手がありそう。
http://binarybonsai.com/wordpress/time-since/

US からわざわざ来日されてのスピーチということで、都合がつけば参加するつもり。

作図ツールの導入意図として、

1. 比較的簡単に作図ができるようにすること
2. 誰もがドキュメント確認のみならず編集もできるようにすること

といったところがあるかと思われる。上記 2 点を踏まえ、以下まとめておく。

1. 比較的簡単に作図ができるようにすること

簡単に作図ができる、ということで、たとえば、基本図形がライブラリとしてまとめられ簡単操作で呼び出せるようになっていたり、図形と図形との線をコネクタとして結べるようになっていたり、とか。

この点、Adobe Illustrator は高機能ゆえに不得手であり、ウェブ制作者としても別のツールを考えてみたくなるところと思われる。Visio はもちろん得意分野だが、次の点が難点となってしまう。

2. 誰もがドキュメント確認のみならず編集もできるようにすること

ドキュメント確認のみなら PDF 形式の書き出しで対応できると思われるが、編集となると、ツールそのものの導入が必要になる。

Visio はここがネックで、作図専用ツールに 3 万円弱（ Standard の場合）のコストというのは企業は別にしても、個人では手を出しづらい。自分だけでなく、周囲にもかかるコストであることを考えると、もう少し手軽に導入できるツールを考えてみたくなりそう。

The Alternatives to Visio

Visio に代わる手軽なツールを、ということで、オープンソースのソフトウェアを中心に洗い出してみた。UML つながり？ということで、Java で、特に Eclipse の plugin として Java で書かれたソフトウェアが多かった。

Eclipse の plugin として Java で書かれたソフトウェア

• AmaterasUML
• UMLet
• Violet

Java で書かれたソフトウェア

• StarUML
• ArgoUML
• JUDE

その他

• UMLmemo
• Dia
• OpenOffice.org Draw

個人的には、OpenOffice.org Draw がなんでも機能アリで何も考えずとも手軽に使える感じがして、平凡ながら一番良いように思えた。

なお、今回の洗い出しにあたり、以下サイトが役に立った。商用ソフトウェアに代わるオープンソースソフトウェアを包括的にまとめている感じなので、また何かの機会に使っていきたい。

Open Source Alternative
Find Open Source Alternatives to commercial software

• del.icio.us・はてブ の API をたたき、JSONP (JSON with Padding) 形式のデータを出力する Ruby スクリプト
• JSONP 形式データを受け取り、整形・表示する JavaScript

の 2 つから構成される。実装にあたり、以下を参考にさせていただいた。

• Remote JSON – JSONP
• JSON with Padding
• del.icio.us / help / json / url
• はてなブックマークのAPI

以下、個別にまとめておく。

はてなブックマーク の API をたたくスクリプト

はてなの場合、自分のブログに被ブックマーク数を表示する にあるような簡単な方法があるが、画像形式で表示され、デザインの調整がきかないことから、XML-RPC で API をたたく方法をとった。作成した getHatenaBookmarkCount.rbx の内容は以下のとおり。

#!/usr/bin/ruby -w
require 'cgi'
require 'xmlrpc/client'
require 'json/pure'

cgi = CGI.new
print cgi.header("type"=>"text/html")
end_point = 'http://b.hatena.ne.jp/xmlrpc'

url = cgi.params['url'][0] ? cgi.params['url'][0] : ""
callback = cgi.params['callback'][0] ? cgi.params['callback'][0] : nil

unless url =~ /^http:\\/\\/blog\\.shimazu\\.org\\//
	exit
end

urls = [ url ]
client = XMLRPC::Client.new2(end_point)
begin
	result = client.call('bookmark.getCount', *urls)
rescue XMLRPC::FaultException => e
	data = { 'error'=>e.faultCode, 'detailed'=>e.faultString }
	print data.to_json
	exit
end

data = [ { 'url'=>url, 'total_posts'=>result[url] } ]
if callback
	print callback ,'(', data.to_json ,')'
else
	print data.to_json
end

Ruby XMLRPC はてなブックマーク件数取得API というその名もずばりな参考資料があったので、それをベースにしている。

Ruby の json ライブラリは JSON implementation for Ruby から取得でき、rubygems でのインストールも可能。C で書かれたバージョン (json) と Pure Ruby のバージョン (json_pure) があるが、なぜか Debian GNU/Linux (Sarge) に前者 (json) がインストールできず、代わって後者 (json_pure) をインストールした。

del.icio.us の API をたたくスクリプト

del.icio.us / help / json / url にあるとおり、del.icio.us では普通に JSONP 形式の API が提供されてはいるものの、URL の指定に MD5 の暗号化が必要とのこと。Paul Johnson’s implementation of MD5 in JavaScript という凄腕ライブラリはあるものの、クライアント（ブラウザ）での処理は極力減らしたいので、MD5 処理する Ruby スクリプトをはさむかたちとした。作成した getDeliciousCount.rbx の内容は以下のとおり。

#!/usr/bin/ruby -w
require 'cgi'
require 'digest/md5'
require 'open-uri'

cgi = CGI.new
print cgi.header("type"=>"text/html")

api = 'http://badges.del.icio.us/feeds/json/url/data?hash='

url = cgi.params['url'][0] ? cgi.params['url'][0] : nil
callback = cgi.params['callback'][0] ? cgi.params['callback'][0] : nil

unless url =~ /^http:\\/\\/blog\\.shimazu\\.org\\//
	exit
end

request = api + Digest::MD5.hexdigest(url)
response = OpenURI.open_uri(request).read.chomp!

if callback
	print callback ,'(', response ,')'
else
	print response
end

出力結果

両者いずれも URL と callback 関数名 をパラメータ指定して、JSONP 形式のデータを出力するようになっている。出力例は以下のとおり（わかりやすくするため整形済み）。

例：getDeliciousCount?url=http://blog.shimazu.org/archives/95&callback=getDeliciousResponse

getDeliciousResponse([{
	"hash":"f021170bb35f553b70b7f392412babe4",
	"top_tags":{},"url":"http://blog.shimazu.org/archives/95",
	"total_posts":1
}])

例：getHatenaBookmarkCount?url=http://blog.shimazu.org/archives/89&callback=getHatenaBookmarkResponse

getHatenaBookmarkResponse([{
	"url":"http:\/\/blog.shimazu.org\/archives\/89",
	"total_posts":1
}])

なお、http://blog.shimazu.org/ で正規表現をかけているのは、http://blog.shimazu.org/ 以外のドメインでの利用を制限するため（ XMLHttpRequest ではないので、クロスドメインでのアクセスが普通にできてしまうがそれを抑える目的）。

JSONP 形式データを受け取る JavaScript

データを受け取る処理を getcount.js としてまとめた。

function getDeliciousResponse(data){
if(!data||!data[0]||!data[0].total_posts){return false;}
var str = data[0].total_posts + (data[0].total_posts==1?'user':'users');
document.getElementById('delicious').innerHTML = '<a href="http://del.icio.us/url/' + data[0].hash + '">' + str + '</a>';
}
function getHatenaBookmarkResponse(data){
if(!data||!data[0]||!data[0].total_posts){return false;}
var str = data[0].total_posts + (data[0].total_posts==1?'user':'users');
document.getElementById('hatenabookmark').innerHTML = '<a href="http://b.hatena.ne.jp/entry/' + data[0].url + '">' + str + '</a>';
}
var el_delicious = document.createElement('script');
el_delicious.src = '/utils/getDeliciousCount?url=' + location.href + '&callback=getDeliciousResponse';
document.getElementsByTagName('head')[0].appendChild(el_delicious);
var el_hatena = document.createElement('script');
el_hatena.src = '/utils/getHatenaBookmarkCount?url=' + location.href + '&callback=getHatenaBookmarkResponse';
document.getElementsByTagName('head')[0].appendChild(el_hatena);

目に見えるものはたったこれだけなのに、実装にやたら時間がかかってしまった。実装方法などについては、追ってまとめることにする。

追記
‘Save This Page’ 件数表示の実装 に実装詳細を記載。

ファイルの統合

長大な JavaScript を書く際、機能別にファイルを分けることは、他の言語同様、有効な管理方法のひとつであるが、production 環境において同じファイル構成をとっていると、それが通信上のボトルネックになることがある。理由は、ページローディングの際に、大量の Request/Responce が発生するため。自分で計ったわけではないが、同じコード量でも、複数ファイルに分かれているよりも、単一のファイルにまとまっていたほうが、一回の Request/Responce で済み、処理が早いという。なので複数ファイルで構成される JavaScript の deploy にあたっては、事前にファイルの統合を行うことが望ましい。

コードの圧縮化・難読化

比較的長大な JavaScript コードは、圧縮化・難読化を行うことがよいとされている。圧縮化とは、コードの改行・インデント・コメント・余分なスペースをカットして、その名のとおりファイルサイズを圧縮することを指す。難読化とは、ファイル圧縮に加え、変数名の省略化（例えば A、B、C… といった文字に置換される）を行うことで、処理内容を読みづらくすることを指す。ツールを探すと、いくつか候補があるようで、すべて検証できたわけではないが、何点か掲載しておく。

検証済み

• jsmin
• dean.edwards.name/packer/
• ShrinkSafe （以前、Dojo compressor と呼ばれていたもの）

未検証

• jscompact
• Strong JS
• Javascript Obfuscator
• Jasob JavaScript Obfuscator
• Stunnix JavaScript Obfuscator

Build

JavaScript は interpreter 言語であり、当然 compiler は通常存在しないが、比較的長大な JavaScript コードを扱う際には、Linux/FreeBSD といった環境上で GNU make を使った build 環境を用意しておくと便利といわれている。理由は、上記に挙げた「ファイルの統合」「コードの圧縮化・難読化」を自動化させるため。ファイル修正のたびに手作業で行うのは、可能であるにしても、あまり効率的とはいえず、C/C++ や Java などと同様、Makefile というかたちで、必要な処理をまとめて自動化するほうが効率的で間違いがないとされている。

Build 環境の作り方

Debian GNU/Linux を前提に記すが、他の Linux あるいは FreeBSD ならば大差はないと思われる。圧縮化ツールには、jsmin (written by C) を使用した。

開発ツールとライブラリヘッダをインストール

# apt-get install gcc g++ make libc6-dev

開発者のサイトからソースコードをダウンロードする。（2007/05/13現在の最新版は、2007/03/27であり、比較的こまめに更新されていると思われる）

# wget http://www.crockford.com/javascript/jsmin.c

コンパイル

# gcc -o /usr/local/bin/jsmin jsmin.c

Makefile の作成

# vim Makefile

以下記述例

SRC = is1.js is2.js
COMP = is.compressed.js
COMB = /tmp/tmp.js
COMMENT = "Copyright (c) 2007 Yuki SHIMAZU. All rights reserved."
all: $(COMP)
$(COMB): $(SRC)
	cat $(SRC) > $(COMB)
$(COMP): $(COMB)
	jsmin < $(COMB) > $(COMP) $(COMMENT)

以下コマンドにて、必要な処理（ファイル統合・コード圧縮化・コード難読化）が行われたファイル（is.compressed.js）が生成される。

# make

以上でファイル生成が完了。このファイルを deploy することで、通信上の効率性を改善できると思われる。

参考ページ

• JSMIN, The JavaScript Minifier
• Make を利用した JavaScript ファイルの結合・圧縮 (cl.pocari.org)
• Make を利用した JavaScript ファイルの結合・圧縮 (d.hatena.ne.jp)