はい。私です。
今年も世界で一番幸せではなかろうかと思われる日が来ました。
ちなみに、去年の様子はこちら。

上の写真は、8月27日生まれの人のための本です。
性格や運勢など占いチックな内容や、リラックスアロマなんかが書かれていますね。
ラッキフードはうな重。なるほど、昼はうな重にしようかなｗ。

ちなみに今回頂いたプレゼントは↓こんな感じ。

これを一人で会社まで持ってきてくれたスタッフのYにまずは感謝。
そして、今回もプレゼントを用意しくれた、りえちゃん、しんじさん、たけさん、そしてYとYのご家族にも感謝です。
どうもありがとうございました。

では、頂いた物を感謝を込めてご紹介したいと思います。

まずは、僕の生まれた日の新聞。
1964年8月27日。
たぶん日本は東京オリンピックを直前に控え、気分も高揚、さぞやエネルギーに満ち溢れていたことでしょう。
この日も今日のように暑かったのでしょうか。
ちなみに新聞は、２０歳の時と４０歳の時も併せて３枚もらいました。
裏面がラテ欄になっているので、当時が思い出されて楽しかったです。

ノリタケのお皿です。しかし、ただのお皿ではありません。
僕のブログを何度かご覧の方は気がついたかも知れませんが、このお皿は僕が愛用しているパスタ皿とおそろいのお皿なんです。
わざわざそれをYのお母様が探してきてくれたというからびっくり仰天です。
僕が入手したのは、ノリタケのアウトレットフェアだったので、今となればきっとどこにもなかったと思います。
大変貴重な頂き物となりました。

続いては、アレッシィのフライパンです。
これは以前僕がたけさんに贈ったものと同じもの。
とても使いやすくよかったとのことで、今度は僕に贈ってくれました。
なんと嬉しいことでしょう（実は、僕もすごく欲しかったのです）。
さっそく使わせてもらいますね！

次はマグカップです。
先日（といっても、ホントに数日前ですが）、壊れてしまったソラリス君（写真右）と同じです。
うれしいですよ、これは。
赤が品切れでオレンジになったようですが、オレンジもステキでいい感じです。
どうも僕のイメージカラー（赤）は、皆さんにも浸透しているようですｗ。

そしてストウブが２つ。
このタイプのストウブは珍しいですよ。蓋の形状も違うし底が深いです。
煮物などに重宝しそう。
さて、何を作ろうかな。

最後に、皆さんが気持ちね。
これが一番の贈り物です。

どうもありがとう！

半熟ってところがちょっと怖かったりもするわけですが、一度は食べてみないとね。
品川のエキュートなどで発売されているらしいですが、楽天でもお取り寄せ可能です。
http://www.rakuten.co.jp/syumpoo/
※配送日を指定しないと買えませんｗ。しかも注文日の10日後からです。
商品：1,260円＋送料710円、しめて1,970円（ちょっと微妙だなぁ）。

でもって、さっそく頂いてみました。
結論からいうと、たしかに旨いです。
フワフワのスポンジの上に、半熟のクリーム状のカステラが絶妙。
砂糖の焦げた感じの苦味（わかるかなぁ）も少しあって、実に奥深い。
包丁でカットするのはかなり大変なので、ちょっと乱暴ですが丸のままスプーンでガツガツいってしまうのもアリかもしれませんよ。

みなさんもぜひチャンスがあればお試しあれ！

現象：
Windows 7 上で Internet Explorer 8 を利用し、クライアント証明書が必要なサイトに接続すると、クライアント証明書の選択ダイアログが表示されるが、一覧に該当するクライアント証明書が表示されず、OKボタンがグレーアウトし、キャンセルボタンしか押せない状態になる。
当然キャンセルボタンを押すと証明書のエラーとなって先に進まない。
今回ウチでは、みずほビジネスWebを利用しようとしたときにこの現象に遭遇し、サポートセンターに問い合わせたのですが、今までに同様の現象はでていないということで八方塞がり状態になりました。

解決方法ですが・・・

それでもうまく行かない場合は、
IEのインターネットオプションのセキュリティタブから、インターネットゾーンのレベルのカスタマイズを開き、その他の項目の中にある「既存のクライアント証明書が１つ、または存在しない場合の証明書の選択」という項目を「有効にする」（デフォルトは「無効にする」のはず）にしてみましょう。


この設定にすると、証明書の選択画面が表示されなくなり、そのまま有効な証明書が適用された状態になってくれました。

MSのサポートにある記事だとちょっと意味合いが違うようので、僕のマシンだけの問題なのかも知れませんが、どうにもこうにもうまくいかないときは試してみるのも良いかと思います。
「Windows Internet Explorer 8 では有効期限の切れたクライアント証明書がデジタル証明書の選択ダイアログに表示されません。」

ログは大体こんな感じ↓
 GET /mysqladmin/scripts/setup.php HTTP/1.1 with response code(s) 404 1 responses
 GET /phpMyAdmin-4/scripts/setup.php HTTP/1.1 with response code(s) 404 1 responses
 GET /phpMyAdmin-2.8.8/scripts/setup.php HTTP/1.1 with response code(s) 404 1 responses
 GET /phpmyadmin/scripts/setup.php HTTP/1.1 with response code(s) 404 1 responses
 GET /phpMyAdmin-2.8.4/scripts/setup.php HTTP/1.1 with response code(s) 404 1 responses
 GET /phpMyAdmin-2.6.5/scripts/setup.php HTTP/1.1 with response code(s) 404 1 responses
 GET /PMA2005/scripts/setup.php HTTP/1.1 with response code(s) 404 1 responses
 GET /phpMyAdmin-2.3.1/scripts/setup.php HTTP/1.1 with response code(s) 404 1 responses
 GET /phpMyAdmin-2.6.0-rc1/scripts/setup.php HTTP/1.1 with response code(s) 404 1 responses
 GET /phpMyAdmin-2.11.3/scripts/setup.php HTTP/1.1 with response code(s) 404 1 responses
 GET /phpMyAdmin-2.11.10/scripts/setup.php HTTP/1.1 with response code(s) 404 1 responses
・
・
・

そもそもウチではPHPは使ってないので、不正アクセスされる可能性はないのだけど、どうやらこのスキャンボットは定期的に巡回をしているらしく、多い日には3～4回くらい回ってくる。しかも１回の巡回で100回以上もスキャンをしてくるし、サーバも何台もあるので、毎日チェックしているログが見にくくなってきた。
そこで対策をしてみることにした。

1. アプリケーションレベルゲートウェイの導入
2. ApacheのDOS対策モジュール
3. IDS/IPSの導入

複数のサーバを管理している関係で、もっとも理想的なのが1.である。しかしながら、現在利用しているFirewallではアプリケーションレベルゲートウェイ機能がないので、あたらしくアプリケーションレベルゲートウェイの導入が必要だし、そもそもネットワーク環境を変更する必要も出てきそうなので却下。

2.については、mod_evasiveというApacheに組み込めるDOS対策モジュールがあるらしいので、実際に導入をしてみたが、攻撃の検出方法が今回のスキャニングではうまく適用されないことが判明した。
理由はこうだ。
DOS攻撃は一般的に短期間に非常に多くのパケットを投げつけることで攻撃を行うため、mod_evasiveでは単位時間（たとえば１秒間）内に異なるコンテンツへ何回アクセスしたか、もしくはリロードしたかで攻撃を検出するようになっている。
ところが、今回のPHPスキャニングでは１秒間に3～4回と、実にゆっくりとしたペースでスキャンをかけてくるので、正常なアクセスとの区別が難しく検出自体ができないのだ。

3.については、IDSとして著名なsnortあたりを使う方法を検討したのだが、IDSはその仕組み上、アタックを検出することはできるがそれを防御（遮断）する機能はない。それを実現するのがIPSになるのだが、これは1.のアプリケーションレベルゲートウェイと同様、仕組みが大掛かりになってしまう。

これは困った。いっそ、アクセスしてくるファイルをこちらで偽装し、そいつにパケットを遮断させるプログラムを組み込むかと考えたときに、fail2banの存在を知った。
fail2banを簡単に説明すると、サーバ上の各種ログファイルを監視し、予め指定したパターンに一致したものを見つけたときに、予め決めておいたアクションを起こすことができるサービスである。
アクションにはIPTablesを使ったパケットの遮断の他、管理者へのメール送信なども用意されているので、今回の目的にもうまく合致しそうである。

実際の導入作業は、こちらのサイトを参考にさせていただいた。
Fail2banでDoSアタック/DoS攻撃 対策

Pythonのバージョンが2.3.4のCentOS4に実装する際はRPMのソースからコンパイルが必要。CentOS5ではPythonが2.4以降なので、そのままバイナリが適用可能であった。

具体的な設定であるが、今回はjail.confに[php-attack]というjailを作成してみた。検出後のアクションとしてはIPTablesによるパケット遮断と、検出通知メール送信の２つを組み込んである。

# Ban attackers that try to use PHP's attack(nosuichfile.php)

[php-attack]

enabled = true
port = http
filter = php-attack
action = iptables[name=PHPAttack, port=http, protocol=tcp]
mail[name=php-attack, dest=ここに自分のメールアドレス]
logpath = /var/log/httpd/access_log←Apacheのaccess_logの場所
bantime = 600←遮断時間は600秒
maxretry = 1

実際のフィルタはfilter.dフォルダ内に、php-attack.confという名前で以下のように作成した。

# Fail2Ban configuration file
#
# Author: Katsumi Takahashi
# Version 1
#

[Definition]

# Option: failregex
# Notes.: regex to match this kind of request:
#
# 193.27.193.XXX - - [01/Aug/2010:18:07:58 +0900] "GET /nosuichfile.php HTTP/1.1" 404 ・・・
#
#failregex = ^<HOST> -.*"(GET|POST) \/nosuichfile.php HTTP\/.*$←これはヤメ
failregex = ^<HOST> -.*"(GET|POST) .*.php HTTP\/.*$
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =

この中の、failregexで指定した文字列が不正アクセスの検出パターンである。今回はスキャンボットが最初にアクセスしてくるnosuichfile.phpを使って検出するようにしてみた。
2010/8/9追記
どうやら今回のボットは、途中でパケットが戻ってこないことを検出すると、IPアドレスを動的に変更して続きをスキャンしてくることが判明。そのため、phpファイルにアクセスしてきたらとりあえず全て止めてしまうようにパターンを書き換えてあります。ただし、これだとphpを使っているサイトではすべてブロックされてしまうので、正規表現に詳しい方はちゃんとパターンを作っておくと良いでしょうｗ。

実際にパケットを遮断するタイミングだが、仕組み上ログに書き込まれてからでないと処理はできない。
そこで、fail2banがログをチェックするタイミングが重要になるのだが、これはjail.conf内の"backend"パラメータで指定が可能なようだ。
指定できるのは"gamin"、"polling"、"auto"の３種類である。もっとも高速（と思われる）のが"gamin"で、これはファイルの変更を監視するGaminサービスが別途必要となる。"auto"の指定+Gaminがない場合、もしくは"polling"を指定した場合は、fail2banが定期的にログをチェックしながら処理を行う。
今回はとりあえずデフォルトの"auto"で運用してみた。

＜結果＞

Gaminについては全く知識がなかったのだが、
yum list gamin
で確認してみたところ、CentOS5ではGaminサービスがインストールされているようだ。
ただし実際にはログをチェックするまでのタイムラグが発生しているようで、結果的にスキャンのいくつか（10～20程度）は遮断されずにログに載ってきてしまった。ただ、それでも対策前に比べれば圧倒的に減っているようだ。

とりあえず片っぱしから制覇してみたいという衝動に駆られますが、東京からだとちょっと遠いなぁ。

皆さんも、ぜひ常陸太田市に遊びに行きましょう。
ちなみに１１月第２土日曜日は、「常陸秋そばフェスティバル」が開催されますよ。

2010/9/1 修正
SPモードが始まってみたら、なんとIMEI制限はかかっていないことが判明しました。
よって、以降の記事についてはほとんど意味がないことを予めお断りしておきます。
2010/9/2 再び修正
IMEI制限解除は初日のみ（設定ミス？）で、予定通り（笑）IMEI制限復活らしいです。

では、なぜIMEI制限を解除できないのか、また解除される予定はあるのかについて勝手に考えてみた。個人の意見の範疇であることを予めお断りしておく。

IMEI制限を解除できない理由

「Androidの成長速度」
現在のAndroid端末の多くは、各メーカー側の技術力の問題もさることながら、差別化を図るために搭載した独自の機能があるがゆえに、新しいOSへの対応が難しい。
それだけではなく、キャリアとしてもAndroidの成長速度には簡単にはついていけない部分があると思われる。

たとえば、Android2.2(Froyo)で標準搭載されている「WiFiテザリング」。

WiFiテザリングとは、Android端末をWiFiルータとして利用する機能であり、WiFiに対応したパソコンやゲーム、iPadのような機器が3G経由で使えるようになる。すなわち、PocketWiFiがAndroid端末だけで実現できてしまう機能だ。

WiFiテザリングについては、従来から一部のiモード端末でも「アクセスポイントモード」として実現している機能だ。ただし、アクセスポイントモードを利用した場合は、パケ・ホーダイダブルの定額(iモードは4,410円、フルブラウザでも5,985円)は適用されず、上限はPC接続時と同様の10,395円となる。すなわち、ケータイとPCを接続した場合と同じ扱いにしている。

ところが、FroyoのWiFiテザリングを利用した場合は、現状のしくみではそれがテザリングなのか、通常のスマートフォンでのアクセスなのかを判断することができないため、テザリングされてしまっても結果的にスマートフォン定額(5,985円)で収まってしまうことになる。

ユーザにとっては嬉しいことであるが、キャリアとしては想定外の使い方となり、料金的にもネットワークのトラフィック的にも簡単には許可できない。それより何より、WiFiテザリングが可能になることで、従来の定額データ通信ユーザ市場を侵食してしまうことが心配なはずだ。

定額データ通信はいわゆる2台目需要の代表的な使い方であり、市場が飽和状態にある移動体キャリアにとっては非常に重要な位置づけである。しかもドコモの定額データ通信では音声が使えないのはもちろん、アプリケーション制限がかかっているため、SkypeのようなVoIP系サービスなどが使えない。それでもユーザは着実に増えていて、実態としては普段はそれほど使うわけではないけど、あると便利だし、2段階定額（定額データスタンダード割で1,000円～）だから契約しているというユーザが多いのではと思われる。
それに対して、現在のスマートフォン定額では基本的にアプケーション制限はかかっていない（ワイヤレスジャパン内で、spモードにおいても速度制限やポート制限はかからないことを確認）し、もちろん音声も利用できるので、従来の定額データ通信を利用する意味がそもそもなくなってしまう。

そこでデータ定額を守るための戦略が必要となる。

データ定額を守るための戦略

1つはIMEI制限である。

すなわち、ドコモの想定する利用方法の範囲内だけで動作するように設計された端末しか接続できないようにしておくことで、とりあえずWiFiテザリングのようなキャリアが想定していない使い方を防ぐという方法だ。
現在アナウンスされている情報では、Xperiaのバージョンアップは10月以降、しかもOSはWiFiテザリングがない2.1である。今後出てくる端末についてのOSバージョンは明らかになっていない部分もあるが、ドコモからFroyo端末が登場するという話は残念ながらまだ聞かない。
※Xperiaはすでにrootedがされたという情報もあるが、そこまでしてWiFiテザリングをするユーザは全体の中では非常に少数だと思われる。

一方で、長い目で見ればFroyo対応は必須。海外メーカーの次世代機では当初からFroyo搭載という情報もでてきている。よって、ドコモとしてもいつまでもFroyo未対応というわけにはいかない。

ましてや来年4月以降にドコモから出荷される製品はSIMロックフリーとなることもあり、SIMフリー端末のspモード対応というのも避けては通れない。予めWiFiテザリングを削除したり、WiFiテザリングをする場合は、上限金額を従来通り10,395円にする方法も考えられるが、これもIMEI制限があってのこと。
すなわち「あるタイミング」をもって、spモードでもIMEI制限を外すだろうと予想する。

2つめの戦略は「LTE」。
LTEについてはこちらを参照のこと。

ドコモではこのLTEを当面データ通信サービスとして展開することにしている。すなわち既存の定額データ通信ユーザを順次LTEに切り替えることで、高速で遅延の少ない通信をメリットとして定額データ通信を引き続き展開していくという戦略だ。
よって、このミッションをある程度実行に移せる段階が「あるタイミング」ではないかと想像する。

「あるタイミング」はいつか

僕はこのタイミングを来年の4月以降ではないかと予想している。もちろん、理由はSIMロックフリーである。定額データ通信のLTE移行ミッションは正直4月は早過ぎる感もあるが、現在定額データ通信ユーザの多くがスタンダード割による2年縛りであることを考えると、契約更新のタイミングでLTE対応端末へ優遇施策を準備するなどで対応は可能だろう。
また、Xperiaユーザの多くがバージョンアップを望んでいる現状を考えると、Froyo対応の限界もこの辺りではないだろうか（このタイミングではすでに3.0も出ているはずだ）。

その一方で、簡単にIMEI制限を外せるわけではないことも理解している。

spモードのIMEI制限解除は、言い換えればspモードのSIMロックフリー端末対応である。
一部のユーザでは周知の事実であるが、ドコモではすでに定額データ通信では今年の6月からIMEI制限を解除している。これはiPadがSIMフリーで販売された時を想定したものと噂されており、恒久的な対策ではないかも知れないが事実である。

同じIMEI制限解除といっても、spモードと定額データ通信では事情が異なる。
spモードはいわゆる音声通話を行うケータイとして利用されることを想定しているため、音質を含めた電波状況に非常にシビアだ。特にドコモは繋がりやすさをウリにしているため、IMEI制限解除により繋がらなくなった場合の対応はSIMロック解除とは別の問題として検討しなくてはならないだろう。
ドコモは現在、都市部などでも電波が届きやすい800MHzが利用でき、主に山間部を中心にFOMAプラスエリアとしても利用している。さらには2012年の周波数再編後では、全国で800MHz帯を利用できるのが強みだ。
ところが、この800MHz帯については、ハードウェアの対応だけでは利用ができず、ソフトレベルでも対応が必要であることが分かっている。たとえばAT&T版のNexusoneでは800MHz帯をサポートしているにもかかわらず、ソフトレベルの対応ができていないために、国内ではプラスエリアを使えないとの話も聞いている（iPhoneでも同様ではないかという話もでているようだ）。
2GHz帯でサポートできるエリアが広いのであまり心配ではないとはいえ、今後800MHz帯を積極活用していきたいドコモにとっては非常に大きな問題である。

これ以外にも、たとえばiモードサービスの多くはspモードでは提供されず、ましてやspモードのウリでもある@docomo.ne.jpアドレスの利用さえ、SIMロックフリー端末では動作保証外になることが予想される。そんな状況でspモード対応と言えるのかという疑問が出るのも当然だろう。

エリアが狭くなることや、利用できないサービスが出てくることによるユーザの不満を覚悟してIMEI制限を解除するのか、エリアやサービスを保証するためにIMEI制限を続けるのか、ここは正直よくわからない。

しかしながらユーザの視点で考えれば、IMEI制限解除は速やかに(できればspモード開始時でも)行ってもらい、エリアの制限や利用出来るサービスが限られるなどのリスクをユーザが理解した上で、ユーザが使いたい端末を選べるようになることが理想だと思うがどうだろう。

愛宕神社の金箔御守という素敵なお守りです。
実は会社からはそう遠くもない（むしろ結構近い）のですが、一度もお邪魔したことがありません。
ここには、「出世の石段」と呼ばれる85段の古びた石段があり、ここを登り切ると見事出世をするとか。
この金箔御守、外からは分かりませんが中に金箔がバッチリ入っているキンキラお守りです。

早速スタッフルームに飾らせて頂きました。
色々とお気遣いを頂き、大変感謝しております。
ありがとうございました。

汚い字でごめんなさいね（BoogieBoardに殴り書きです）。

まず、上の部分が従来のiモードの仕組み。
ご存知のように、iモード端末はiモード契約することでiモードメールなどのサービスが利用でき、かつインターネットにも抜けられるようになっています。
逆に言えば、iモード契約がないとインターネットも使えません。

一方スマートフォンでは、従来のiモードのような仕組みが今まではなく、mopera UなどのISP（インターネットに抜けるための接続事業者）と契約することでインターネットに出ることができます。
よって、従来のiモードセンター（絵ではCiRCUSと書かれています）を通らないので、iモードメールが使えないわけです。
もっとも、インターネット側からiモードメールへのアクセスを許可する「iモード.net」というサービスがあり、これをつかうことでiモード端末以外からもiモードメールを利用することができます。Xperiaなどでも利用者が多い、「IMoNi」などがこちらを使ってスマートフォン上でiモードメールのやり取りを実現しています。

今回発表になった「SPモード」は上の図のように、ISP契約の代わりに提供されるサービスではないかなと僕は予想します。
すなわち、mopera Uなどに契約するのではなく、「SPモード」に契約することで、インターネットアクセスに加えて、従来のiモード系サービスを提供できるようにしようということです。

世間ではどうやら、iモードメールの需要（@docomo.ne.jp）が高いので、iモードメールの話が中心となっているようですが、このような仕組みを使うことで、iモード向けに提供してきたフィルタリングサービスなどもシームレスに提供が可能になります。
もしかするとiコンシェルサービスやiチャネルなども提供されるかも知れません（ウィジェットなどで）。少なくとも、現状のドコモマーケットは「SPモード」内に移動してきて、「SPモード」専用アプリなどの登場があるかも知れません。

さらに、もし「SPモード」がこの仕組みで実現されるとなると、iモード関連のサービスを司っているCiRCUS内にあるFeliCaサーバも使えることになります（おサイフケータイの仕組みについてはここでは割愛しますが、FeliCaサーバはおサイフケータイを利用する上で非常に重要な役割をもっているのです）。

今回の「SPモード」で、スマートフォンからFeliCaサーバにアクセスが可能になることで、多くの既存おサイフケータイ事業者様がスマートフォンでもサービスを利用できる道筋ができます（アプリの開発などが別途必要ですけど）。
これは山田社長がおサイフケータイスマートフォンを出すとおっしゃっていたシナリオにも合致します。

いずれにしろ、SPモードによって（端末には依存しない）iモードサービスを、課金の仕組みを含めて提供できるようになるのと、通信事業者だからこそ可能なセキュリティサービスなどの提供によって、スマートフォンユーザに対する自社の差別化に一役かうこととなりそうです。

※この記事は、僕の推測で書かれている部分も多々ありますので、その点はご了承ください。

まず、Hibernateの2.xではビット演算子がサポートされていた（ようだ）が、3.xからサポートされないとのこと。
そこで、ビット演算をユーザ関数として定義し、データベースへの接続を行うDialectをオーバーラップして、直接SQL文を吐き出すようにするとよいらしい。
と、ここまでの内容でなるほど！と思った方はすでにご自分で解決できるだろうし、そもそも書いている僕自身がこれじゃさっぱりわからないｗ。

では具体的な対策を説明していきます。
調べる内容は概ね次の通り。

1. Hibernateで利用しているデータベースがビット演算子をサポートしていること。
2. サポートしているビット演算子（通常は'&'とか）
3. Hibernate内における利用しているデータベースのDialectのクラス名

1.と2.は大丈夫ですよね。ちなみに僕の環境はSQLServer2005ですが、ビット演算子（AND）は「&」です。
3.については、Hibernateのコンフィグレーションファイル（「hibernate.cfg.xml」など、データベースの接続情報を記載するxmlファイルがあるよね、あれです）に書かれているdialectプロパティを見ると分かります。ちなみにSQLServerは、「org.hibernate.dialect.SQLServer」でした。

で、実際には２つクラスファイルを作成する必要があります。以下、SQLServerを例に説明するので、他のデータベースを使っている人は適宜読み替えましょう。

まずは1つ目のクラス「SQLServerDialect.java」。
クラス名は、先程3.で調べたものと併せておきます。

packageパッケージ名;

import org.hibernate.Hibernate;

public class SQLServerDialect extends org.hibernate.dialect.SQLServerDialect {
    public SQLServerDialect() {
        super();
        registerFunction("bitwise_and",    new BitwiseAndFunction("bitwise_and", Hibernate.INTEGER));
    }
}

ポイントは、先程3.で調べたDialectを派生（extends）させること。
「bitwise_and」というユーザ関数を追加しているわけです。

2つ目のクラスは、「BitwiseAndFunction.java」。

package パッケージ名;

import java.util.List;

import org.hibernate.QueryException;
import org.hibernate.dialect.function.SQLFunction;
import org.hibernate.dialect.function.StandardSQLFunction;
import org.hibernate.engine.SessionFactoryImplementor;
import org.hibernate.type.Type;

public class BitwiseAndFunction
    extends StandardSQLFunction implements SQLFunction {

    public BitwiseAndFunction(String name) {
        super(name);
    }

    public BitwiseAndFunction(String name, Type type) {
        super(name, type);
    }

    public String render(List args, SessionFactoryImplementor factory)
            throws QueryException {
        if (args.size() != 2) {
            throw new IllegalArgumentException("the function must be passed 2 arguments");
        }
        StringBuffer buffer = new StringBuffer(args.get(0).toString());
        buffer.append(" & ").append(args.get(1));　　// ←ここにビット演算子を指定
        return buffer.toString();
    }
}

このクラスは、ユーザ関数「bitwise_and」の中身を受け持ちます。
ポイントは、returnする直前に指定しているビット演算子をデータベースに合わせること。今回は” & ”としてあります。

最後に、先程3.で調べるときに参照したHibernateコンフィグレーションファイルの、Dialectプロパティを、今作成したDialectクラスに書き換えればOKです。

実際の使い方ですが、例えばHQL上で

where bitwise_and( X, 1 ) = 1

のように書いてしまえばOKで、これで実際のSQL上は、

where X & 1 = 1

と送られることになります。

とりあえず僕はこれでうまくいきました。
参考にしたのは、以下のサイトです。
http://javabeans.asia/2008/05/06/bitwise_operation_in_hibernate_3.html

まず一番変わったのはROMです。
ついにカスタムROMに手を出しました。
僕が入れたのは、「CyanogenMod 5.0.6-N1」。
詳しい手順などは、コムギネットさんの「Android Custom Cookbook」に書かれているので、自己責任でどうぞ。
※Wipe/FactoryResetが必要なので、データはバックアップしておかないと泣きが入ります。

で、どうだったかというと、操作性やタッチパネルの精度などがかなり良くなりました。
その一方で、うまく動作しない（もしくは他のアプリとの連携がうまくいかない）アプリがいくつかありました。
たとえば、ブラウザのSteelがうまく動作しないので標準ブラウザに戻したり、お気に入りのライブ壁紙「Shake Them All!」が動作しません。
ただ、それらのマイナス点を除いても、かなり快適になったので非常に満足しています。特に標準ブラウザは、動作はちょっと遅いものの、マルチタッチが使えるのはやはり便利です。

それともう一点、SIMをiPhone用からドコモのデータ通信用カード用に変えました。
もともとノートパソコンでのデータ通信用にA2502で使っていたのですが、N1が届いた際にテストした時はIMEI（製造番号）ではじかれて使えなかったのが、つい最近使えるようになったとの情報をもらって、早速入れ替えたわけです。
もちろん音声が使えなくなったのですが、エリアは格段に広がりましたし（これは重要）、通信速度も早くなりました。音声はもともとガラケー（じゃなかった、Feature Phone）が担当しているので、特に問題はありません。
エリアの問題は結構重要で、特にFoursquereなどを使っていると、店の中で電波がないのはかなりイラッとしますよね。もちろんドコモでも圏外はありますが、カバレッジエリアの差は都内でも大きいですからね。

これに加えて、Wireless Tether for Root Usersを使うことによって、今まで出先ではノートパソコンとA2502を接続して定額APNに接続するという作業をしていたものが、N1上でWireless Tetherのアプリを起動させるだけでネットが使えるようになりました（もちろん、ノートPC上では無線の設定が必要です）。
すなわち、N1がドコモ版Pocket WiFiを兼ねているという訳です。

ということで、かなり快適なN１ライフが始まり、ますます手放せない愛機となりました。パチパチ。
次に買い換えるとすれば、たぶんおサイフケータイ対応のAndroidが出た時でしょう。

あったよー！

森永製菓「チーズスティック」。137円でした。
他の方のブログなどを見ると大人買いをするのが普通らしいので、とりあえず６本買っておきました。

裏を返すとこんな文字が。

「お待たせしました！皆様のご愛顧により、今年はちょっとだけ長く販売いたします。」
って書いてあるよ。
去年は５月からの発売だったらしいのですが、今年は３月から売っているようです。
どうも暑い季節は苦手（アイスなのに）だそうで、暑くなる前には販売終了してしまうんでしょう。


肝心のモノはこんな感じです。
下の部分がサクサクのビスケットになっていて、チーズケーキと非常にあっています。
チーズケーキ部分にはチェダーチーズとクリームチーズがつかれており、甘さもひかえめでなるほど美味しいですね。

いずれにしろ、ファンの方の買い占めがあるらしいので、もし見つけたら買っておくことをおすすめします。

こちらのドーナツは、揚げたり焼いたりしていない『半生ドーナツ』っていうらしいです。
これ以外にもかなり華やかなドーナツがいっぱいで、正直ドーナツというカテゴリーにしてはケバケバしすぎだなぁというのが第一印象です。

箱も可愛いです。

「バニラ」 258円　※もっともシンプルなやつを選んでみました。

「マンダリンオレンジ＆マンゴー（たぶんそんな名前ｗ）」 258円

でもって結論。

これ、旨いですっ！（特に下の方）

ドーナツというよりはケーキです。甘さ控えめでかなり美味しいし、値段も手頃。
ドーナツ部分がスポンジになっているので、丸いスポンジにデコレーションをしたケーキという方がわかりやすいですね。

ちなみに玉川高島屋SCにも本日オープンだそうです。
お近くの方はぜひ。

インストールができたら早速起動！
と、行きたいところですが、まずはイヤフォンをセットしてください。
※イヤフォンなしで動かすと、単なるノイズアプリになってしまいますｗ

イヤフォンがセットできたら、いよいよ起動です。

起動するとしばらくして、上のようなシーン選択画面が出ます。
現在はプレリリース版のため、ひとつだけシーンが用意されています。
このシーンというのが、エフェクターの役割になっていて、マイクで拾った音をエフェクトしてスピーカー（イヤフォン）に出力してくれるというのが、このアプリの役割です。
どんなエフェクトになるのかはやってみないと分かりません。

では、「Echolon」というシーンを選択してみましょう。

早速何か音が聞こえてきますね。
他の人の話す声、タイピングの音など、環境音がそのままエフェクトソースになっています。
思わず笑ってしまうことマチガイなし。
真ん中の録音ボタンを押せば、録音することもできますよ。

退屈な通勤時間の楽しみ方にどうでしょう。
※あまりうるさい環境では、役に立たないかもしれません。