British GP M.Schumacher 2nd
(ToT)
Alonso との差がさらに 2 点開いてしまった...
それにしても Alonso 強いなぁ.
今回は Pole to Win に Fastest,それにスタートからゴールまでただの一度もトップを譲らない全ラップリーダーと,グランドスラム達成じゃない? 2 度目のピットストップの際に 1 周だけトップを譲ってました
これで 3戦連続の Pole to Win,4 戦連続の Pole,そして 14 戦連続の表彰台...
今季 8 戦 5 勝,2 着 3 回で連帯率 (違) 100%,失ったポイントはわずかに 6 点...
同僚の Fisichella が表彰台 2 回だけってことを考えても Alonso の強さが際だちます.
競馬風に書くと Alonso が 5300,Fisico が 1016.
単にマシンがずば抜けてるって感じじゃないのにこの強さ.
かわいげのなさも含めて (苦笑),昔の Michael を彷彿しちゃいます.
さて,Michael はこの Alonso 相手に巻き返せるのか...
巻き返してくれると信じたいなぁ.
ギャルサー
今クール一番の楽しみとなってしまったこのドラマ.
全く予想外だったなぁ.
そして,予想を遥かに超える大盤振る舞いとなったのが,えみちぃのパンチ!!
殴る,殴る,殴る!!!!
いったい何発のパンチが炸裂したのか,数えてみようかと思ったけど挫折.
50 発は超えてるよね?
これまではカリスマギャルらしく,何があっても動じない無表情なキャラだった,えみちぃ演じるレミ.
それが今回は悩ましげな表情が盛りだくさん♪
中でも,眉間にしわ寄せて
イモコって呼ぶなっつってんだろがっ!!
と,おっさんを殴る時のえみちぃの表情最高♪
それにしても立ち姿がカッコいいな.
今週は得意の「って,思われちゃうじゃん?」にたどり着かなかったのが無念ですが,殴り続けるえみちぃを堪能できたので満足です♪
そしてギャル達の会話.
飛鳥時代っつえばさ,まだパラパラとかねーよな.
ないない (笑).
それタケノコ族でギリギリっしょ (爆).
お前らバカじゃねーの.1000年前はまだ地球とか無くて,人類はみんな北京に住んでたんだよ.
(^^;;;;;
最後のはナギサ.北京は地球じゃないのかよ!!
クールなボケ具合に惚れちゃいそう♪
しっかし失敗したなぁ.
最初の 2 話くらいはマジメに見てなかったんだよなぁ.
えみちぃが出てきたところだけ拾って見たんだよなぁ.
ちゃんと見ておくべきだったよ.
無念だ.
CM NOW VOL.121
エビちゃん効果か,「モデル系 CM タレントファイル」という特集が.
特集といっても 5 ページで,CM で活躍しているタレントを軽く紹介しているだけなんですが,人選がなかなか.
モデルの名前順になっているのですが,最初のページが次の 3 人.
美樹ちゃんも CM 出てたのね.ノーチェックだったよ.心より恥じる.
そして次ページへ.
名前順でこの 3 人が揃うとは!!
あさ美ちゃんが出演してる常陽銀行の CM って見たことないよ? 茨城限定??
友里ちゃんは例によってえびフィレオ.
続いて
さらに次.
直ちんとマッキーも名前順で揃うのね.
サイズ的には直ちんは他の 4 人と一緒に 1/6 ずつ,茉希ちゃん一人だけ 2/6 とやや大きめ (友里ちゃん・もえちゃんと同サイズ).
直ちんも大きく取り上げて欲しかったなぁ.
そして最後.
- 長谷川潤
- 美香
- ヨンア
ヨンア,最近目立ってるもんね.
というわけで,大きな特集でもないし,一見の価値があるというわけでもないのですが,なんとなく嬉しくなってしまった特集でした.
それから,「読者が選んだ 行ってみたい!! 海 CM」の 3 位に友里ちゃんの ANESSA が.
3 位かぁ.1 位じゃないわけ?
でもまぁ,基本的に 10 代のタレントが強いこの雑誌,1 位が長澤まさみのカルピス,2 位が綾瀬はるかのポカリスエットじゃしょうがないか.
恒例のポスタープレゼントでは西山茉希ちゃんの 8×4 キレイが 3 名に.
週刊東洋経済 6/10 号
特集は「つかめ! 転職力」.
でもでも,そんなことはどうでもよくて,大事なのはこっち.
"エビちゃん" ビジネス大研究
日経ビジネスには大きく後れを取りましたが,東洋経済にもエビちゃんが登場.
し・か・も
さすが東洋経済,その辺のオサーン向け雑誌とは掘り下げ方が違う!!
エビちゃん大ブレークの仕掛け人の話とか出てきます.
「必要なら大物政治家まで動かす豪腕」「狙って外したプロジェクトは一つもない」−.
芸能界では半ば伝説的なマネジャー,谷口元一.
彼の「仕掛け」なくして今日のエビちゃん人気はなかった.
そうなのか,そんな凄腕の人がバックにいたのか...
この人,山田優ちゃんも所属している「ケイダッシュ」の取締役で,友里ちゃんに目を付けてモデル専門事務所「Pearl」を発足させたのだとか.
そういえば,友里ちゃん以前は「FRONT」って事務所にいたわけですが,移籍の裏には仕掛け人がいたのかぁ.
って感じで,友里ちゃんそのものというよりその背景に関する話題が中心ですが,なかなか面白かったです.
Kuina-Dao 開発記 概要
Kuina-Dao を開発中の今日この頃です.
Kuina-Dao というのは,S2Dao や S2Hibernate.Dao の Java Persistence API (JPA) 版です.
いずれは Kuina-Core という独自の JPA 実装を提供する構想もあるわけですが,その前に Hibernate や TopLink など,既存の JPA 実装上で利用できる,S2Dao のように使い勝手のいい DAO フレームワーク (っていうの?) を提供しようというのが Kuina-Dao です.
ようやく SVN へコミットを始めたので,そろそろこちらでも紹介していきます.
今のところ,ダウンロードできる形での配布は準備できていません.
興味を持って頂けた場合は,SVN からチェックアウトしてお試しください.
前提として以下のプロダクトが必要です.
- S2Hibernate-JPA
https://www.seasar.org/svn/s2hibernate
のtrunk/s2hibernate-jpa
- S2Tiger
https://www.seasar.org/svn/s2container
のtrunk/s2-tiger
- Seasar2
https://www.seasar.org/svn/s2container
のtrunk/seasar2
いずれもトランクの最新版をお使いください.
そして
- Kuina-Dao
https://www.seasar.org/svn/kuina
のtrunk/kuina-dao
をチェックアウトしてください.
なお,Kuina は JPA を使うために Java5 必須です.J2SE1.4 ではビルドできません.
例によってソースにコメント無し,ドキュメントも無し,テストケースは貧弱です (苦笑).
さて.
Kuina-Dao は S2Dao や S2Hibernate.Dao と同様にインターセプタを提供します.
それが
org.seasar.kuina.dao.interceptor.KuinaDaoInterceptor
です.
こいつを DAO のインタフェースに適用することで,JPA というか javax.persistence.EntityManager
を直接呼び出さなくてもエンティティクラスを操作できる,というのが Kuina-Dao です.
現時点では問い合わせ以外の基本的な操作のみが実装されています.
例えばこんな DAO を用意して...
public interface EmployeeDao { Employee find(int id); Employee get(int id); void persist(Employee employee); void remove(Employee employee); boolean contains(Employee employee); Employee merge(Employee employee); void refresh(Employee employee); void readLock(Employee employee); void writeLock(Employee employee); }
これに KuinaDaoInterceptor
を適用することで,EntityManager
に対する基本的な操作を行うことができます.
それぞれのメソッドが EntityManager
のどのメソッドに対応するかはすぐにお分かりかと.
これだけだと,わざわざ DAO を用意しなくても EntityManager
を使えばいいような気のせいもすることでしょう.
当然ですよね.
そんなわけで (どんなわけで?),これから問い合わせを中心に機能を充実させていきます.
最初はたぶん,Named Query のサポート.
JPA では @NamedQuery
を使って Java Persitence query language (JPQL) による問い合わせ文字列を登録しておくことができます.
@NamedQuery(name="Employee.findByName", query="SELECT e FROM Employee e WHERE e.name = :name")
通常はこれを
public class EmployeeDao { List<Employee> findByName(String name) { return em.createNamedQuery("Employee.findByName").setParameter("name", name).getResultList(); } }
みたいに使うのですが,これを
public interface EmployeeDao { List<Employee> findByName(String name); }
というインタフェースを用意するだけで済むようにします.
この際,Named Query の名前はメソッドの戻り値から得られるエンティティ名とメソッド名から,パラメータ名は引数名から解決します.
一応,アノテーションで Named Query の名前を指定できるようにするつもり.
それから,引数名を取れない環境のために,Named Parameter (:name
と書く方法) に加えて Positional Parameter (?1
と書く方法) もサポートするつもり.
Named Query は事前に問い合わせがきっちり決まっている場合に有用ですが,問い合わせ条件が可変になる場合には使えません.
そんなわけで (どんなわけで?),S2Dao や S2Hibernate.Dao 同様に,問い合わせの自動生成をサポートします.
例えば
List<Employee> find(String name, String email, String bloodType);
というメソッドの場合,実引数が null
でない項目だけを WHERE 句に加えた JPQL を作成し実行します.
JPA では Criteria が使えないため,動的に問い合わせ条件を変えるのは (難しくはないけど) 面倒なわけで,重宝するのではないかと.
最初は SELECT 文のサポートから始めますが,いずれは UPDATE・DELETE (Bulk Operation) もサポートするとか.
S2Dao の SQL コメントのように,JPQL に制御コメントを埋め込めるようにするとか.
S2Dao 同等の Native Query (SQL) もサポートするとか.
といったことを考えています.
要望などあれば,コメント・トラックバック・ML・某巨大掲示板 (笑) など,お好きなところでリクエストください.
よろしくお願いしますです〜.
Kuina-Dao 開発記 Criteria
Kuina-Dao はインタフェースに定義されたメソッドのシグネチャと実引数から動的に JPQL を作成して実行します.
でもでも,JPA には Criteria がないため,JPQL を組み立てるのが面倒です.
そんなわけで (どんなわけで?),Kuina-Dao のインフラとして Criteria を実装しました.
Kuina-Dao Criteria を使うには,まずは
import static org.seasar.kuina.dao.criteria.CriteriaOperations.*;
します.
Eclipse の場合は「Window」−「Preferences」から「Java」−「Code Style」−「Organize Import」を開いて「New Static...」で上のクラスを登録しておきます.
それでも Eclipse (3.1) は static import の扱いがイマイチで全然快適じゃないんですけどね.
ともあれ (JW),Kuina-Dao Criteria を使った一番簡単な問い合わせは次のようになります.
List<Employee> list = select().from(Employee.class).getResultList(em);
スッキリしてて簡単でしょ? (^^;
このように select()
に引数を指定しない場合は from()
句に指定したエンティティが選択されます.
これを明示的に指定すると
List<Employee> list = select("employee").from(Employee.class).getResultList(em);
となります.
ちなみに,from()
にクラスだけ指定しているので,エンティティクラス名を decapitalize したものが alias になります.
それも明示的に指定すると
List<Employee> list = select("e").from(Employee.class, "e").getResultList(em);
となります.
select()
は実は可変長引数を持つので,複数の選択リストを並べることができます.
List<Object[]> list = select("e.name", "e.email").from(Employee.class, "e").getResultList(em);
結果リストから重複を除くには selectDistinct()
を使います.
List<String> list = selectDistinct("e.bloodType").from(Employee.class, "e").getResultList(em);
結合も簡単.
from()
も可変長引数を受け取ります.その場合はクロス結合になります.
List<Object[]> list = select().from(Employee.class, Department.class).getResultList(em);
可変長引数の from()
で alias を指定するには alias()
を使います.
List<Object[]> list = select() .from(alias(Employee.class, "e"), alias(Department.class, "d")) .getResultList(em);
内部結合になると少し複雑な書き方になっちゃいます.
List<Object[]> list = select() .from(join(Employee.class).inner("employee.belongTo").inner("belongTo.department")) .getResultList(em);
alias を使うとこう.
List<Object[]> list = select() .from(join(Employee.class, "e").inner("e.belongTo", "b").inner("b.department", "d")) .getResultList(em);
いずれの場合も,結合した 3 つのエンティティの配列からなるリストが返されます.
FETCH JOIN も使えます.
List<Employee> list = select() .from(join(Employee.class, "e").innerFetch("e.belongTo", "b").innerFetch("b.department", "d")) .getResultList(em);
この場合は Employee
だけが返されます.
外部結合も同様.
List<Product> list = selectDistinct() .from(join(Product.class, "p").leftFetch("p.sales")) .getResultList(em);
この場合は selectDistinct()
しないと SQL の結果セットの行数と同じ長さのリストが返ってきます.
Hibernate の動きがそのまま JPA 仕様になったらしい.
Linda にそれはやめてと言ったんだけどなぁ.その時「それはよくないね」みたいに言ってたんだけどなぁ.
でもでも,「Pro EJB 3 Java Persistence API (isbn:1590596455)」を見ると,どうやら TopLink でも distinct しなきゃいけないみたいだし.
しくしくしく.
WHERE 句もまぁ,似たようなものです.
List<Employee> list = select().from(Employee.class) .where(eq("employee.bloodType", literal("AB"))) .getResultList(em);
ここでは血液型が AB の従業員を選択しています.
ちょっと悩ましいのは,String
引数の扱い.
上の場合,eq()
メソッドは 2 つの引数を受け取るのですが,現在そこに String
を渡すと employee.bloodType
のような Path Expression として解釈しています.
そのため,'AB'
のようなリテラルを指定するには literal()
を介する必要があります.
油断すると忘れそうなのがイマイチなのですが,String
をリテラルだと解釈すると Path Expression の時に明示的に path()
とか介さないといけなくなるのでどっちもどっちなんですよね.
いっそ String
はコンパイルエラーになるようにしようかとも思ったのですが,それはそれで面倒になるし.
この辺はまだ悩みながらやっているので,いいアイディアあったらお願いします.
where()
も可変長引数を受け取ります.
List<Employee> list = select().from(Employee.class, "e") .where(eq("e.height", 150), eq("e.weight", 45)) .getResultList(em);
このように並べると AND で繋がれます.
OR を使う場合は
List<Employee> list = select().from(Employee.class, "e") .where(or(lt("e.weight", 45), gt("e.weight", 70))) .getResultList(em);
とします.and()
もあります.いずれも可変長引数を受け取ります.
基本的な演算子やファンクションなどはだいたい揃ってます.
集計関数や GROUP BY,HAVING,ORDER BY もサポート.
List<Object[]> list = select("p.id", count("c")) .from(join(Customer.class, "c").inner("c.prefectural", "p")) .groupby("p.id") .having(ge(count("c"), 3)) .orderby("p.id") .getResultList(em);
顧客が 3 件以上ある県とその顧客数を県の ID 順に取得します.
ここで orderby()
を count()
順にすることができない気のせいが.
JPQL の BNF 的にできるとは思えない...
できそうにないといえば,
List<Integer> list = select(add("e.height", 10)).from(Employee.class, "e").getResultList();
JPQL でいうと
SELECT e.height + 10 FROM Employee AS e
みたいに SELECT 句に集約関数以外の計算式を書くことも BNF 的にできない気のせいが...
Hibernate ではできちゃうけど (苦笑).
「Pro EJB 3 Java Persistence API (isbn:1590596455)」の例には出てこないので,TopLink に配慮してできなくなってる?
ともあれ (JW),JPQL はまだまだ拡張されて完全な SQL に近づいていくんだろうなぁ (苦笑).
といった感じで,Criteria そのものはいい感じになったかなぁ,と.
それもこれも static import,可変長引数,Generics などなど,Tiger 様のおかげです.
でもでも,おかげで CriteriaOperations
は超巨大になってしまった...
今現在でも 1500 行くらいあるよ?
心より恥じる.
まだ対応ができていないのは,大きなところでは副問い合わせ.
それに関連して EXISTS とかその辺.
おいおい実装していきます.