暗号化に素因数分解の困難性を利用してることはよく聞くかもしれません。

しかし、実際、素因数分解しただけではそんな鍵は出てこなそうです…

もう少しだけ、どのような仕組みかをみていきたいと思います。

　sshで接続→別のサーバへ接続→更に別のサーバへ…

なんてことはないでしょうか。

接続先にrsh入れることに問題ないのであれば、
それでもいいんですが多くの場合そうもいかず。

大抵は「ログイン用の手順を保存しておいてコピペ」で済ますんですが、
長い人生それすらも煩わしくなる時もあり。

そんな時はコイツで手間を省いてみたりしてます。

【expect】
http://www.linux.or.jp/JM/html/expect/man1/expect.1.html
http://expect.nist.gov/
インストールはyumで大丈夫かと思います。
私自身そもそも「面倒くせぇ(’A`)」から始まったのでｗ

で、例えば以下をファイルに保存して、
実行件を与えて実行してみると…
※【＊＊＊】の部分は適宜修正してください

#! /usr/bin/expect

#120秒応答が無ければ終了
set timeout 120

#############################
#login（以降はこれをコピペ→ログイン情報調整）
set host 【接続先サーバーIP】
set user 【接続ユーザー】
set pass 【パスワード】
set prpt 【ログイン後のプロンプト】
spawn ssh $user@$host
expect “password:”
send “$pass\r”
expect “$prpt”
############################

#制御をユーザーに戻す
interact

はい、ログイン完了。
あとは「########」～「########」の間をコピペすると、
２度３度とsshでログインしてくれます。

実際、どういう処理になっているかというと―――

１．「spawn ssh $user@$host」で、
　コマンド「ssh $user@$host」を契機にexpectのプロセスを生成。

２．標準出力内に「password:」という文字列がくるまで待ち続ける。
こなければ「set timeout ***」で指定した秒数経過で終了。

３．「２」で待っていた文字列が見つかったら、「$pass」＋「改行(CR)」を自動で出力。

４．「interact」で制御をユーザーに戻す

のようになっています。
ただ、ココで気になるのは「２」の時点でで、
「記述した文字列と完全一致でないとダメなのか」
「初めてログインした時、証明書云々の入力を求められたら？」
という話ですが―――

———————————–
【before】
expect “password:”
send “$pass\r”
———————————–
【after】
expect {
  -re “\[Pp]assword:” {
    send “$pass\r”
  }
  “connecting (yes/no)?” {
    send “yes\r”
    exp_continue
  }
}
———————————–

例えばこのような記述で、
「複数の文字列の指定」「正規表現指定」「もう一度待つ，そのまま進む」
が可能だったりします。
ここまでくると、他のコマンドと合わせることで、
定期的に行う必要のある作業で、
手間を省けるものが結構ありそうだってのは、お解りかと思います。

ちなみに―――

expect -c ”
ecpect \”password:\”
send “$pass\r”

という記述でシェルからも呼べますので、
sed,awkなどと組み合わせてやれば、かなり色々できるかと思います。
（環境構築とかSSL申請時のCSR生成とか）
これでどなたかの日頃のイライラが少しでも減れば幸いかな…っと。

• 「欲しいのはこれじゃない！」と言われる
• システムをリリースしても、バグが多発する
• 納期が守れない
• 必死で作ったのに赤字

システム開発に関わっている人なら誰しも一度は経験していることなのではないかと思います。プロジェクトは、まさに生き物です。努力、根性も重要ですが、これをシステマティックになんとかする！それがプロジェクト管理が必要とされる所以です。
エンジニアは、技術のスキルを高めるのと同時に、チームで仕事をする上でプロジェクト管理についての知識やスキルも高める必要があると思います。そこで今回は、改めてプロジェクト管理の基礎をまとめてみたいと思います。

まずはじめに、プロジェクトの成功とは、一般的にQCDが全て満たされた時に成功したと言われます。QとはQuality（品質）、CとはCost(コスト)、DとはDelivery（納期）です。ただし、品質の達成なくして、コストと納期を守っても意味がありません。

次にプロジェクト成功のためには、次に挙げるようないくつかの条件が必要です。

• 顧客が何を求めているのかを理解し、ゴールへの合意がなされていること
• 品質、コスト、納期についての現状が把握できること
• 問題が発見された場合、それに対してのアクションをとることが可能なこと
• 顧客、メンバー間で認識の齟齬がないこと、相互に信頼関係が築かれていること
• ・・・

そして、これらを満たすために必要なアクションがプロジェクト管理であるといえます。PMBOKという、プロジェクト管理の知識体系では、そのアクションとして次の9つの管理体系を定義しています。今回は、システム開発において特に重要な、品質管理、スケジュール管理を掘り下げてみたいと思います。

1. 統合管理
2. 品質管理
3. スケジュール管理
4. コスト管理
5. スコープ管理
6. メンバー管理
7. コミュニケーション管理
8. リスク管理
9. 調達管理

「品質」の定義は難しく、バグが少ないこと、機能がたくさんあること、アフターサービスが優れていること、、、、いろんな考え方があると思いますが、視点を変えると「顧客が満足していること」、それが品質が良いと言うこともできると思います。顧客満足は、良いものを多く提供すれば上がりますが、リソースには限界があります。したがって、顧客の期待値を適切なモノにする事も一方では重要で、最小限の成果物で顧客満足を達成するのが最善だと言えます。とても難しいことではありますが。

次にスケジュール管理ですが、最も重要なのは、何を以って進捗とするのかということです。それは、測定可能な指標でなければならず、その上で予実差異を把握できる仕組みを構築することが必要です。その際ポイントとなるのは、ターゲットとマイルストーンを設けること、クリティカルパスとタスクの依存関係を見極めること、遅れと学習曲線を想定することだと思います。

いかがでしたか。今回はプロジェクト管理の基本を少しご紹介してみました。ただ、いくらプロジェクト管理をしっかりやったとしても、顧客の要望は変わり、モチベーションは上下し、想定外の問題は起きるものです。そんな時に大切なのは、計画を遵守すること以上に、変化に対応することではないでしょうか。

厳しい状況でもチーム一丸となってやり切る、1+1が2を超えるようなそんな力が必要とされ、そんな力を持っているチーム、組織は強いと思います。そんな高みを目指しながら、プロジェクトという生き物と楽しく、元気に付き合っていきたいと思います。

仕様はいたって簡単

http://twitter.com/home?status=URLエンコードしたつぶやいてもらいたい内容

こういうリンクを作るだけでOKです。

ではこれをEC-CUBEの商品詳細画面に組み込んでみます。

data/Smarty/templates/default/detail.tpl 221行目辺り

<p><a href=”<!–{$twitter|escape}–>”><img alt=”Twitterでつぶやくボタン” src=”ボタンの画像のパス” border=”0″ /></a></p>

data/class/pages/products/LC_Page_Products_Detail 277行目辺り

$tw             = SITE_URL . ‘detail.php?product_id=’ . $tmp_id . ‘ ‘ . $this->arrProduct["name"];
$this->twitter  = “http://twitter.com/home?status=” .urlencode($tw);

これでつぶやくボタンが表示されるので商品詳細画面で確認してみてください。

内容を変えたい場合は

SITE_URL . ‘detail.php?product_id=’ . $tmp_id . ‘ ‘ . $this->arrProduct["name"]

ここをつぶやいてもらいたい内容に変えてください。

以上、EC-CUBEにつぶやくボタンを設置する方法でした。

日本語に訳すと「品質管理（Quality Control）」という平々凡々な言葉になってしまうのですが、企業において社員が小グループを作り、職場環境の改善や生産品質の向上を目指して行う改善活動のことをQC活動と言います。また、QC活動を行うグループのことをQCサークル、QCサークルが活動内容を発表する手順を標準化したものを、QCストーリーと呼びます。

トヨタの「カイゼン」活動といえば、聞き覚えのある方が多いのではないでしょうか。
言わずと知れた、QCの代表例です。
・・・まだピンと来ない？わかりました。
では、百聞は一見にしかずということで、実際にやってみましょう。

これから、典型的（だと私が思っている）QCストーリーを１つ紹介します。
※簡単のためいろんなところを省いています。

1. テーマ
   　「○○システム機能追加開発における品質改善」
2. 取り上げた理由
   　○○システム2次開発では、商用リリース後に１０件ものバグが見つかってしまい、お客様より品質についてお叱りを受けることとなってしまった。3次開発の受注は決まっているものの、更なる追加開発受注のためにも3次開発での品質の改善が必須であると考えたため、今回のテーマを選択した。
3. 現状の把握
   　2次開発で発見されたバグを分類すると下図の通りとなる。

（パレート図によって、優先して対策を打つべき問題点を洗い出します。）



　デグレードによるバグが大半を占めていることがわかる。

4. 目標設定
   　（目標を設定しない場合もあるようです。）

　3次開発では、「リース後のバグ件数を5件以下に減らす」ことを目標とする。

5. 解析
   　デグレードが起きてしまった原因を分析した結果を下図に示す。

（特性要因図を用い、問題点に対して「なぜ」を繰り返し掘り下げることによって、「真の原因」を洗い出します。　※ここは特にサボっています！真の原因はたいてい１つではありません。）



6. 対策の立案
   　要因解析によって洗い出した原因に対して以下の通り対策案を立案し、実現性・効果・コストの観点から評価して対策の採否を判定した。
7. 対策の実施
   • デグレード試験項目を新たに作成する

   　　　　　バグの再テストを行う際、バグを検出した試験を再度行うだけではなく、その周辺機能についてデグレード試験項目を作成することとした。

   • 再試験項目レビューを行う

   　　　　　バグの再試験を行う際、作成した試験項目をチーム内でレビューすることとした。　

8. 効果の確認
   先述した対策をした結果、3次開発ではリリース後のバグ件数を4件に減らすことができた。
     
   よって、
   目標達成！！
    
9. 歯止め
    今回実施した対策を次開発以降も継続するため、デグレード試験項目の作成や再試験項目レビューを試験実施要領としてルール化し、グループ内へ展開した。
10. 今後に向けて
    次開発でさらにバグ件数を減らすため、デグレード以外によるバグに対しても何らかの対策を講じていきたいと考えている。

以上です。ご清聴ありがとうございました！（ﾊﾟﾁﾊﾟﾁﾊﾟﾁ）

 
・・・いかがでしたか？
すごい！うちの職場でもやった方がいい！と思いましたか・・・？思いませんよねぇ。
そうなんです。残念ながらQCサークルが有効に機能している例はおそらくごくわずかなのではないかと思います。
今回QCについてネットで調べてみても、最近はQC活動を行う企業が減ってきているだとか、廃れているだとかネガティブな記事が多く目につきました。

なぜでしょうか。

それは、QC活動の目的が本来のものから外れて、「QCストーリーを発表すること」になってしまったからだと思います。
人前で発表するなら誰でも“いいストーリー”を発表をしたいと思いますよね。
そうすると、改善活動の効果をよく見せるためにデータを捏造したり、実際は対策ありきだったにも関わらずたくさんの対策案を検討したことにしてみたり、ということが起こってしまうのです。（私もよくやったものです・・）

でも、それはそれで仕方ない面もあります。

なぜなら、そもそもQCに適したテーマがそうそう転がっているものではないからです。

身の回りで起こる問題ってたいてい、ちょっと考えればどう対処すればいいかわかりますよね。そうでなくとも、「よし、ここはひとつQCを使ってじっくり原因を分析してみよう」なんていうケースはなかなかなさそうですよね。

そういう理由もあって、QC活動をやる企業が減ってきたりしているのだと思います。。

しかし！

これは決して、QCの本質に問題があるということではありません。

トヨタのカイゼン活動がそうであるように、QCはその効力を事実示してきました。

そこで私がオススメするのが、（だいぶ前に忘れ去っていると思いますが）今回のブログのテーマ、『QC的思考』です。

改めて『○○的思考』なんていうと大層に聞こえますが、平たく言えば「頭の中でQCストーリーを展開してみよう」くらいのことです。

例えば。

もしバグが出てしまったら、ただ漫然とソースを修正するのではなく「なぜ」「なぜ」「なぜ」を繰り返して本当の原因を探ります。そうすれば、次回同じ原因でバグを作らなくてすみそうじゃないですか？ひょっとしたら同じ原因の、また別のバグに気づくことができるかもしれません。

また、（品質改善に限ったことではなく、）ちゃんとしたストーリーから導き出された結論には、説得力がこもりますよね。

みなさんも試してみてはいかがでしょうか。『QC的思考』。

私も明日から始めてみたいと思います。

年末、ブログを更新が少し滞ったのでご心配をかけたかもしれませんが…
元気すぎてお仕事が山積みになり、社員一丸となって取り組んでおりました。

おかげさまで新しいメンバーも多数加わり、キモチも新たに2010年もゲンキ良くスタートを切っております。
本年もよろしくお願いいたします。

＜このブログは、エスキュービズムのエンジニア陣が担当制で更新しています＞

さて、では、僕はセキュリティ対策の話を…と考えていたのだけど、ウイルス対策の次にセキュリティの話だと盛り上がらないなぁと思い、全く別の話題を。

最近よく「あの、新しいグーグルの携帯買わないの？」と聞かれる。
グーグルの携帯といってもドコモから出ているAndroid携帯ではなく、アメリカで発売された Nexus One のことだ。

確かに、古くは NEC Mobile Gear（通称：モバギ）に始まり、シャープ Zaurus、最近なら Willcom の es やネットブックなど、小型端末が発売される度に衝動買いしてきたモノとしては、とても気になる。めちゃめちゃ欲しい。

が、「まだ待ち」が正解な気がしている。iPhone 3GSを明らかに上回る端末がこれから登場すると思うからだ。これが新iPhoneなのか、Androidなのかはわからないけど。

ただ、まあ、ようやくスマートフォンを一般の方にも勧められる時代になったのは確かだと思う。
今までは動きが遅すぎたり、設定が複雑すぎて、一般の方には使いこなせないものばかりだったが、これらの「基本機能」は大きく改善された。つまり「使えるかどうか」ではなく、「どう使うか」の時代になったと思う。

そこで、スマートフォンの購入を迷っている方向けに、チェックリストを作ってみた。
以下の項目に多数当てはまる方は、スマートフォン、おすすめです！

• ブログ、ネットニュースをついつい見てしまう
• 天気、乗換案内、グルメ情報などを頻繁にチェックする
• 毎日、膨大な数のメールをパソコンで読んでいる
• Twitterで常につぶやかないと落ち着かない
• ToDo管理、タスク管理が必需品
• 音楽プレイヤーが肌身離せない
• 動画を持ち歩いて観るのが好き
• ゲーム好きで、PS3よりはDS派
• 趣味が写真加工などの創作活動
• 自分でプログラムが組める
• クラウドをバリバリと活用している
• デジタルなガジェットが大好き
• いつも手持ち無沙汰で、ケータイをばかり見てる

実質、日本では iPhone しか選択肢がないようなもんなので、これらの項目は iPhone を前提にしている。

ただこれらって今までのケータイでもできると言えばできる。スマートフォン（iPhone）って結局、

　「今までのケータイと何が違うんだ？」

と思われるかもしれないが、iPhoneはそれぞれの機能に特化した「アプリ」が存在するのが大きく違う。
道具は用途に特化した方が使い易い。例えば、Twitterやメールの閲覧など、パソコンよりも iPhone の方が便利だったりすることが多々ある。

iPhoneはその素晴らしいインターフェイスの上に、特定の用途に適したアプリを入れていくことで、様々な道具として化けていくのがとにかく便利なのだ。しかもその道具はユーザからの厳しい意見によって、日々アップデートされて使いやすくなっていく。iPhoneを購入して半年ぐらいだが、当初に比べて全てのアプリが（場合によっては別アプリが登場して）使いやすくなったと言っても過言ではない。

もう1つは、クラウドとの相性の良さだろう。
こちらはまだまだ一部の人しか当てはまらないかもしれないけど、Gmailやタスク管理などクラウド上にデータを置いた生活を送っている人にとっては、スマートフォンは最高に相性が良い。

ちょっとした移動時間に確認して本格的な作業は家や会社で行うという人ならば、1日の利用効率が高まりまくる。
会社に来てパソコンに電源を入れてぼ～っとしている時間が必要なくなるわけだ。

　「そんな電子データに追い立てられる人生はイヤだ」

と思うかもしれないけど、実は逆で、効率が上がった分、他のことができる時間が増えるということ。実際、僕は iPhone のおかげで、本を読める時間が増えた。

ただし、大きな注意点が1つある。
残念ながら日本ではiPhoneのキャリアは ソフトバンク なのだ。
特にドコモからの乗り換えの方は要注意、回線品質はドコモとは比べ物にならない。
頻繁に電話を使う人、圏外が多いと困る人はキャリア変更は慎重になった方が良い。

あとはおサイフケータイが使えないのもイタイかな。

まあ、何にせよ、携帯がない時代が考えられないように、スマートフォンがない時代が考えられないぐらいになる予感がする。
（携帯なくても済む人がいるように、スマートフォンなくても良いよって人もいるだろうけど）

Virus Bulletinはイギリスのサイトで、VB100という手法でアンチウィルスソフトをテストし、パスしたソフトにVB100 Certificationという認証を与えています。VB100テストは2ヶ月に1度行われ、海外ではVB100認証を何度取得した、をうたい文句にする製品があるほどメジャーな認証です。

VB100は『100種の最新かつメジャーなウィルスに対して、全てのウィルスを検知できた場合にはパス』という方法でアンチウィルスソフトを評価しています。1つでも検知できなかった場合、もしくは誤検知（False Positive：本当はウィルスが無いのにウィルスだと検知してしまうこと）があった場合はパスできません。

日本でも人気のKasperskyやEsetは毎回テストにエントリーしており、2009年の6回のテスト全てでVB100認証を取得しています。

VB100はテスト方法がシンプルで分かりやすいこと、テストが定期的に行われ、常に最新のウィルスを使用していることなどから人気があります。一方でそのシンプルさゆえに、パスした製品同士が比較しにくいという問題があります。
　
　
- AV-Comparatives
http://www.av-comparatives.org/comparativesreviews/main-tests

そこで次に紹介するのがオーストラリアのアンチウィルスソフト評価サイト、AV-Comparativesです。

AV-Comparativesでは年2回、16個のメジャーなアンチウィルスソフトの詳細なテストと比較評価を行っています。テスト項目にはウィルス検知率、誤検知率（False Positive）、パフォーマンス、さらには未知のウィルスの検知率といったものまであります。レポートの最後ではそれらを元に製品を比較し、一ツ星から三ツ星までのランク付けを行っています。

2009年11月のテストではG DATA、Kaspersky、Eset、Microsoft Security Essentials、Avast、BitDefender、eScanの7製品が三ツ星に選ばれました。
　
　
アンチウィルスソフトは数多くリリースされていますが、実際にどれが良いのかは情報が少なく、悩むことも多いのではないでしょうか。次回アンチウィルスソフトを選ぶ際は、ぜひこれらのサイトを参考にしてみてください。

今回の目次

1. ChromeOSって何？
2. ビルド環境の準備
3. ビルド
4. 使ってみる

ChromeOSって何？

Googleが開発中のオープンソースのOSです。Linuxカーネルの上に、独自のウィンドウシステムを備えています。webの閲覧とwebアプリの実行に特化したOSということで、非常に軽量なOSとなっています。

詳しいアーキテクチャについては本家のサイトを参照してください。
http://www.chromium.org/chromium-os/chromiumos-design-docs/software-architecture

ビルド環境の準備

上記のサイトに詳しい説明がありますので、それに沿って進めていきます。

http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites

http://sites.google.com/a/chromium.org/dev/chromium-os/building-chromium-os/getting-the-chromium-os-source-code

ビルド用のOSを準備

UbuntuやopenSUSEやFedoraでの準備が紹介されていますが、公式での解説はUbuntu8.04以上（最新の9.10推奨）で進められているので、Ubuntu9.10を用意することにします。

Windows上でVMwarePlayerを用いて構築しました。

■VMwarePlayer

http://www.vmware.com/jp/products/player/

■Ubuntu

http://www.ubuntulinux.jp/products/JA-Localized/download

必要なパッケージのインストール

ChromeOSのビルドに必要なパッケージをまとめて一気に入れてしまいます。

$ sudo apt-get install subversion pkg-config python perl g++ g++-multilib \
bison flex gperf libnss3-dev libgtk2.0-dev libnspr4-0d libasound2-dev \
libnspr4-dev msttcorefonts libgconf2-dev libcairo2-dev libdbus-1-dev

$ sudo apt-get install wdiff lighttpd php5-cgi sun-java6-fonts

基本的にはSSHで接続してターミナルで操作したいのと、最終的にできあがったイメージをSCPで落とす必要があるので、SSHも入れておきます。

$ sudo apt-get install ssh

ついでにiptablesも開放しておきます。一時的にしか使わないので、とりあえずINPUTとOUTPUTを全開放

$ sudo iptables -P INPUT ACCEPT

$ sudo iptables -P OUTPUT ACCEPT

ソースコードの入手

gitから落としてくる方法もありますが、結構時間がかかるので、tarで入手します。

ちなみに作業は全てユーザのホームディレクトリで進めていきます。

$ cd ~

$ wget http://build.chromium.org/buildbot/archives/chromiumos-0.4.22.8.tar.gz

ローカルリポジトリの作成

$ tar zxvf chromiumos-0.4.22.8.tar.gz

$ ln -s chromiumos-0.4.22.8 ./chromiumos

$ cd ~/chromiumos/src/scripts

$ ./make_local_repo.sh

結構時間がかかります。お茶でも飲みながらのんびり待ってください。

Chromeのバイナリを入手

ビルド時にChromeのバイナリが必要となります。

こちらもgitのリポジトリから入手する方法もありますが、面倒なのでバイナリをゲットしておきます。

$ cd ~/chromiumos/src/

$ mkdir -p build/x86/local_assets

$ cd build/x86/local_assets

$ wget http://build.chromium.org/buildbot/archives/chromium-chromiumos-r32516.zip

$ mv chromium-chromiumos-r32516.zip chrome-chromeos.zip

ビルド環境の構築

以下のスクリプトを走らせます

$ cd ~/chromiumos/src/scripts

$ ./make_chroot.sh

これで環境構築は完了です。いよいよビルドに入っていきます。

ビルド

chroot環境に入る

ビルドはchroot環境下でしか実行できないらしいです。以下のスクリプトを実行。

$ ./enter_chroot.sh

ローカルユーザアカウントを有効にする

ChromeOSはGoogleアカウントがOSのログインアカウントになります。ネットに繋がらない状況だとログインができなくなるので、この処理を入れておきます。

※ほぼChromeしか動かないOSを、ネットの環境がない状況で使用する意味があるかどうかは不明ですが。

$ cd ../platform/pam_google && ./enable_localaccount.sh USERNAME

共有ユーザのパスワードも設定しておきます

$ ./set_shared_user_password.sh

※この2つの処理は飛ばしてしまっても問題ありません。

ビルド

スクリプトを走らせるとあとは自動でやってくれます。

$ ./build_platform_packages.sh

$ ./build_kernel.sh

$ ./build_image.sh

かなり時間がかかります。

C2D E7400搭載のPCで、VMのコア割り当ては1つでしたが、軽く30分はかかりました。

マシンスペックが低いと悲しいぐらいの時間がかかりそうです。4コアCPUのPCを使って、

VMにできる限りのコアを割り当ててあげると早いかもしれません。

イメージファイルの確認

以下のフォルダにできています。

$ ~/chromiumos/src/build/images/SUBDIR

イメージを変換

USBメモリに入れるためのスクリプトと、VMware用イメージの変換スクリプトがあるので、使ってみます。

今回はVM用のものを走らせてみます。

VM用にはqemuが必要なので、まずインストール

$ apt-get install qemu

イメージをVM用に変換します。

$ cd ~/chromiumos/src/script

$ ./image_to_vmware.sh –from=~/chromiumos/src/build/images/SUBDIR

これでSUBDIR内にvm用のイメージができていますので、取り出して使ってください。

使ってみる

起動

10秒ちょいで起動しました。速い。

ログインするといきなりChromeが立ち上がります。

デスクトップ代わりのようなイメージでしょうか。Googleのサービスだけでなく、hotmailなども用意されています。

JS用のコンソールもあります

タスクマネージャらしきものも

全てがブラウザ上で動作しているところがなんとなく新しい感覚です。

現時点では日本語入力もできませんが、使い方次第では面白いことになるのではないでしょうか。

今後の開発に期待です。

触って気付いたのですが、
個人・小規模グループレベルなら、まず無料で済み、登録・操作も簡単。
数多ある安いサーバーの違う管理画面を開く位なら、
むしろ、これで統一した方がいいんじゃない？ と感じました。
　

　
1. 独自ドメインの Google Apps アカウントを作成する

（何故、独自ドメインかというと、そのドメインで自分のメールサーバを立てたいためです。）

“Google Apps” でググってサイトを探すと
(http://www.google.co.jp/apps/intl/ja/business/index.html)
このサイトに到達するかと思います。
まずは、右上の「機能比較とお申し込み」ボタンから次の画面に進みましょう。
　
次に、「無料試用を開始する」というボタンのある画面に進みますが
(http://www.google.co.jp/apps/intl/ja/business/details.html)
無料で使いたい場合は、そのボタンではなく、
すぐ下にある「Standard Edtion」（これが無料コース）というリンクを押してください。

この後は、特にハマりポイントも無いので、
自分のドメインを入力して、アカウントを作成し、
Google Apps 管理画面に到達するまでは、手なりで進むことが出来ると思います。
　
　
2. アカウントを有効にする

最初に、その独自ドメインの所有者が本当にあなたであるという証明を
Google側にしないといけません。

方法はふたつの選択肢がありますが、

a) Googleが指定するCNAMEレコードを作成する
　　　・・・つまり、Googleが指定するサブドメインを作る。
b) ドメインのドキュメントルート直下に、Googleが指定するファイルを設置する。

どちらも、ある程度ドメインやそのサーバについての権限が必要となる点に注意してください。
可能であれば、取る方法で差がないと思います。（自分は a を選択）

これで、Google Apps を使えるようになりました。
　
　
3. 独自ドメインでメールサーバを建てる

「メールアドレスを有効にする」リンクから道なりで設定を開始すると

ASPMX.L.GOOGLE.COM. 10
ALT1.ASPMX.L.GOOGLE.COM. 20
ALT2.ASPMX.L.GOOGLE.COM. 20
ASPMX2.GOOGLEMAIL.COM. 30
ASPMX3.GOOGLEMAIL.COM. 30
ASPMX4.GOOGLEMAIL.COM. 30
ASPMX5.GOOGLEMAIL.COM. 30

このように、MXレコードを7つ設定してください、という記述があります。
えっ、全部設定するのか？と思いましたが、する必要があります。
（Gmailも、落ちないように苦労してるんだなぁ、と思いました。）

で、このMXレコードが反映され次第、設定は完了です。
hogehoge@yourdomain.com にメールを送信すると届くはずです。

簡単過ぎます、感動！

メーリングリストも、「グループ」という概念を使い、リダイレクトでのMLなら生成できました。
（件名の頭に連番が付けられるような、ちゃんとしたメーリスの作成方法はわからなかった。無いかもしれません）

　
　
以上、他の機能も色々触ってみたのですが、
とにかく、滅茶苦茶簡単なので、腰が重い方も是非お試しあれ！

筆者はこれまでjQueryを好んで使っていました。一番メジャーであり、軽量かつ覚えるのも簡単で、プラグインも豊富にあるからです。ただ、とりわけ比較的大規模にJavaScriptで開発したいときに、モジュール化するのが比較的やりにくいと感じていました。簡素化のため、あえてそうしてるのだと思いますが、モジュールのインポート機能や自然なオブジェクト指向開発のためのツールが用意されていません。一方、これは、他のライブラリでは実現しているものもあります。しかし、メリットデメリットを考慮し、総合的な利便性でjQueryを選んでいました。Closure Libraryを見ると、その点でモジュール化が徹底されており、大規模開発向けな印象を受けます。そして改めて総合的に判断すると、今回はClosure Libraryに乗り換えるだけの魅力があるのではないかと感じています。

以下にClosure Libraryの主な特徴を独断と偏見で列挙したいと思います。

１．依存関係管理

Closure Libraryでの各コードファイルでは次のように、依存モジュール（ライブラリ）をインポートすることができます。

goog.provide('goog.math');

goog.require('goog.array');
goog.require('goog.math.Box');
goog.require('goog.math.Coordinate');
goog.require('goog.math.Range');
goog.require('goog.math.Rect');
goog.require('goog.math.Size');

ここでgoog.provide()関数はこのコードファイルでのパブリックなネームスペースもしくはクラスを宣言します。goog.requre()関数は他のモジュールをインポートし、このファイル内でそれらを利用できるようにします。

普通は、これら依存するコードファイルは複数のHTTPリクエストによってロードし展開します。しかし、この方法は速度的に問題があり、開発環境ではいいですが、本番環境には適していません。

そこで、calcdeps.pyというPythonのスクリプトファイルが用意されており、これを実行することによって、それら複数のコードファイルを一つのファイルにまとめ、かつ"圧縮"することができます。

2．継承

オブジェクトの継承は次のように行います。

function ParentClass(a, b) { }
ParentClass.prototype.foo = function(a) { }

function ChildClass(a, b, c) {
  ParentClass.call(this, a, b);
}
goog.inherits(ChildClass, ParentClass);

var child = new ChildClass('a', 'b', 'see');
child.foo(); // works

ChildClassのコンストラクタ内のParentClass.call(this, a, b)は親クラスのコンストラクタを呼び出す部分です。そして、goog.inherits(ChildClass, ParentClass)でChildClassをParentClassの子クラスとして定義しています。

また、固有名のParentClassではなく共通の”superClass_”変数を利用して親クラスを呼び出すこともできるようです。

ChildClass.prototype.foo = function(a) {
  ChildClass.superClass_.foo.call(this, a);
  // other code
};

[追記] Closure Libraryの継承に関しては次のブログが詳しいです：”Inheritance Patterns in JavaScript“。より自然な継承の実現やClosure Compilerと親和性が高いこと、メモリへの配慮を行っていることが分かります。

３．イベント

イベント処理は次のように行います。

goog.events.listen(this.elHeader_, goog.events.EventType.CLICK,
    this.onHeaderClick_, false, this);

１番目の引数はイベントを発動するDOMノード、
２番目の引数は捉えたいイベントタイプ、
３番目の引数はイベントが起こったときに呼ばれるリスナー関数です。

４番目の引数はcapturePhaseのみでイベントを捉えるかどうかを決め、
５番目の引数はリスナー関数内での”this”の中身を定めます。

第５引数でthisの中身を指定できるのはいいですね。

４．デバッグ

これは次のポップアップするデバッグウインドウのデモを見るのが早いかと思います：

http://closure-library.googlecode.com/svn/trunk/closure/goog/demos/debug.html

JavaScriptではFirefoxのプラグインツールであるFirebugを用いてデバッグするのが主流ですが、IE等ではまだまだデバッグツールが貧弱なので、このようなブラウザ非依存のリッチなデバッグツールがあると便利ですね。さらに、ログレベルを細かく設定できるので(参考)、特に大規模な開発で役に立つと期待されます。

４．データ管理

APIを見ると、ds.DataManagerというクラスがあり、データソースを統一的管理する仕組みが用意されているっぽいです。特に、データの変更を通知する仕組みが実装されており、これによってデータバインディングができるようになると思われます。個人的に、Flexの開発ではこのデータバインディングを重宝していて、これがJavaScriptで標準でできればと思っていました。

[追記]　よくよく見るとFlexのデータバインディングとは少し違うようですね。ただこれを利用してデータバインディング的なことはできそうです。

５．基本ライブラリ

数学やコレクション関連の基本ライブラリはかなり充実していると感じました。例えば、個人的には、ds.SortedNodeListやstructs.Poolなどの機能を独自に実装した経験があり、こういうのがあったらと思っていました。

６．ユニットテスト

ユニットテストのライブラリも標準として備わっており、非常に充実しています(この辺のクラス)。大規模開発ではテスト駆動開発は必須になってくるので、ここはやはりしっかり押さえています。

６．ブラウザ機能

ユーザインターフェースを初めブラウザ独自の機能に関わるAPIも非常に豊富です。APIドキュメントのページの右にあるDemosタブからたくさんのデモを見ることができます。

基本的な設計思想としては、各ブラウザ機能をそれぞれ抽象化し、再構築している感じです。例えば、ui.CheckBoxはチェックボックス機能を独自に実装しています(Input要素は使わず、span要素と背景画像の切り替えで実装しています)。また、JavaScriptの基本関数であるsetTimeoutやsetInterval関数の機能もこのデモにあるようなクラスで抽象化し、改良しています。

また、例えば、クロスブラウザなキャンバスライブラリやマウスホイールのハンドリングなど、jQueryでは外部ライブラリが必要だったもので、Closure Libraryで実装されたものが要所要所であり、便利かなと思います。逆に、Closure Libraryでなくて、jQueryであるようなものは一応見当たらなかったです。

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

とりあえず、以上です。全体としてJavaScriptがJAVAっぽくなった感じですが、同時に、徹底的に改良された印象を受けます。簡単な開発はjQuery、大規模な開発はClosure Libraryという流れになる気がするのですがどうでしょうか？