2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 |
2010 | 02 | 07 |
2011 | 01 | 02 |
SQL Server 2008の教科書―基礎から実践まで学べ...
2011-01-29 (土)
■[Java][Scala][Groovy] Re: いまさらだけど、Java言語にはクロージャーがない 
id:ryoasaiさんと先日会社で話した内容が、「いまさらだけど、Java言語にはクロージャーがない」にまとめられたけれど、関数リテラルが利用できるという文法の話と、引数以外の外部変数（自由変数）が参照できるという機能の話が混ざっている気がします。
前者の意味では現在の Java 6 にはクロージャがないけれど、後者の意味では Java でも内部クラスで同様なことが実現できます。他の言語が内部的にクロージャをどう実現しているか詳しくは知りませんが、クロージャを導入する土台は既にあると考えています。C/C++ でクロージャを実現するよりはかなり敷居が低いかと。
「想像以上にガラパゴス化した日本のIT業界？」で、Groovy と Scala の比較もされているようなので、クロージャに関して、Java、Scala、Groovy の違いを整理しておこうと思います。
2011-01-09 (日)
■[Java][JPA] メタモデルなしで JPA 2.0 の Criteria API を使う 
仕様書のサンプルや Web の記事を見ると、JPA 2.0 の Criteria API を使うにはメタモデルを作らないといけないかと一瞬思うけれど、属性名を文字列で指定してもいいんですね。
メタモデルを使用する場合、
@Entity public class Customer { @Id Long id; String name; ... }
というエンティティに対して、
@StaticMetamodel(Customer.class) public class Customer_ { public static volatile SingularAttribute<Order, Long> id; public static volatile SingularAttribute<Order, String> name; ... }
のようなメタモデルを作って、
@PersistenceContext EntityManager em; CriteriaBuilder cb = em.getCriteriaBuilder(); CriteriaQuery<Customer> cq = cb.createQuery(Customer.class); Root<Customer> r = cq.from(Customer.class); cq.select(r).where(cb.equal(r.get(Customer_.name), "hoge")); List<Customer> result = em.createQuery(cq).getResultList();
のようにするみたいですが、
メタモデルを作らずに、
@PersistenceContext EntityManager em; CriteriaBuilder cb = em.getCriteriaBuilder(); CriteriaQuery<Customer> cq = cb.createQuery(Customer.class); Root<Customer> r = cq.from(Customer.class); cq.select(r).where(cb.equal(r.get("name"), "hoge")); List<Customer> result = em.createQuery(cq).getResultList();
としても良いみたいです。
自社フレームワークなどで使う場合はこちらの方が使いやすそう。
というか、アプリケーションのプログラマにこれを使いこなせっていうのは厳しくないかな? 素直に JPQL や SQL 使った方が簡単そう。
参考
- JSR 317: Java Persistence 2.0
http://jcp.org/en/jsr/detail?id=317 - Dynamic, typesafe queries in JPA 2.0 - developerWorks
http://www.ibm.com/developerworks/java/library/j-typesafejpa/ - NetBeans6.8 BetaでJPA2.0を試してみる。 - ひたすらプログラミング日記
http://d.hatena.ne.jp/hayassh/20091025/1256477014
2010-07-19 (月)
■[Test][Ruby] 直交表作成ツール 
複数条件の組合せテストで、少ないテストケースでいかに網羅率を上げて品質を確保するかという目的で、直交表というツールが利用できます（詳細は最後の参考文献を参照）。
テストの条件（因子）に対してバリエーション（水準）が2の直交表は比較的簡単に作成できます。ただし、実業務で使用するとなると、水準が10くらいは欲しいところ。そこで、勉強がてら直交表を作成するツールを作成してみました。
言語は Ruby です。作成したデータも一部置いています。
http://svn.sourceforge.jp/svnroot/glad/trunk/oa-ruby/
http://sourceforge.jp/projects/glad/svn/view/trunk/oa-ruby/
使用方法
直交表の大きさを2の対数で第1引数に指定します。水準は一般的に使いそうなものを出力します。
直交表の大きさを第1引数に指定します。水準は一般的に使いそうなものを出力します。
prompt> ruby mkOA.rb 16 "OA(16; 4^5)" ,1,2,3,4,5 1,0,0,0,0,0 2,0,1,1,1,1 ... 16,3,3,0,1,2
水準を変更したい場合は同じく2の対数で指定することができます。
水準を変更したい場合は第2引数に L^n の形式で指定することができます。
prompt> ruby mkOA.rb 32 "8^1,4^2" "OA(32; 8^1, 4^2, 2^18)" ,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 2,0,1,1,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1 ... 32,7,3,0,0,1,0,1,1,0,0,1,0,1,1,0,1,1,1,0,0,1
つぶやき
@glad2121: 直交表作成ツールできた。とりあえず L256 までは生成可能。 URL
2010-07-19 13:25:45 via web
@glad2121: L256 はこんな感じ。任意の2列を選択しても全ての組合せが網羅されている。 URL
2010-07-19 13:28:18 via web
@glad2121: 肝はやはり点線図テンプレートの作成。LinearGraphTemplate::make_graphs がそれ。1回作成して、イマイチだったらもう1回だけ検索するロジックにしてみた。L256 だと数秒で返るけど、L512 だと PC がうなって返らない。
2010-07-19 13:37:40 via web
@glad2121: ちなみに、直交表は「複数条件の組合せテストで、少ないテストケースでいかに網羅率を上げて品質を確保するか」という目的で使用します。
2010-07-19 13:40:39 via web
@glad2121: L256 よく探したらここにあった。(^^;) でも、僕が作ったのと微妙に違う。 URL
2010-07-19 13:48:27 via web
参考文献
ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方
- 作者: 吉澤正孝/秋山浩一/仙石太郎
- 出版社/メーカー: 日科技連出版社
- 発売日: 2007/07/26
- メディア: 単行本
- 購入: 3人 クリック: 56回
- この商品を含むブログ (17件) を見る
- 作者: リー・コープランド,宗雅彦
- 出版社/メーカー: 日経BP社
- 発売日: 2005/11/03
- メディア: 単行本
- 購入: 13人 クリック: 398回
- この商品を含むブログ (37件) を見る
参考URL
- HAYST法
http://hayst.com/default.aspx - 直交表を活用したソフトウェアテストの効率化 〜HAYST法の活用〜 （JaSST'05 in Osaka）
http://jasst.jp/archives/jasst05w.html#special - 直交表によるソフトウェアテスト 『ＨＡＹＳＴ法』の解説と学習
http://www.geocities.jp/ka_hayst/ - A Library of Orthogonal Arrays
http://www2.research.att.com/~njas/oadir/index.html
コメントありがとうございます。リンク先あとで見てみます。
C/C++ の現在の仕様で Java のようなクロージャもどきを作るのは難しいかなと思ったのですが、スマートポインタ使えばできるかもしれませんね。自由変数は明示的に渡す必要がありそうだけれど。
あと、var, valはGroovyの場合はJavaと同様にfinalを付けたら一応実現できそうな気がします。
っていうのが、気になったので、それこそクロージャと全く関係ないですが、scalaでの代入とかインクリメントについて書いてみました。
http://d.hatena.ne.jp/xuwei/20110130/1296360331
まぁたしかに、不便なときもあるけど、代入したあとに、さらにその値使うっていう行為自体が、手続き型っぽくて、scalaではあまりやらない(やる必要がない)から非推奨にするためにも、わざとこういう構文になってるんだと思います。
たしかに、Javaからきたひとは、最初は戸惑うとおもいますが・・・一応それなりの理由があることをいいたかったので
それとは別で
>スクリプトのままコンパイルできなかったり
ってありますけど、これってどういう意味ですか？
Groovy にも型推論導入されるんですか? 期待しています。
final の件は、可変変数より不変変数の方が手間が多いと、結局使われない気がするんですよね。
>それとは別で
>>スクリプトのままコンパイルできなかったり
>ってありますけど、これってどういう意味ですか？
object NewCounter extends Application { ... } で囲まないと scalac できないという意味です。
http://code.google.com/p/groovypptest/wiki/Welcome
あと、本文の例なら私なら
int newCounter() {
int i = 0
// ↓これがクロージャ。
return { ++i }
}
とたぶん書くと思います。別にdefと書いてもintと書いてもタイプ量は変わりませんし、Groovyですべてダックタイピングしなくてはならないという規則はないので。Java脳と言われるかもしれませんが。
ためしていませんがこれだとInteger型になるのでJavaとの互換性が向上すると思います。
それから、次期バージョンの1.8ではボックス化をできるだけ排除することで、プリミティブ関連の演算の性能が向上すると聞きました。
Scala もそうだけど、Groovy でも公開メソッドのシグネチャはちゃんと書けってことですかね。引数の型はどうされますか?
ちなみに、newCounter() の戻り値は int じゃなくてクロージャです。
たとえば、SpringのサービスやコントローラーなどをGroovyで書くならきちんとシグネチャを書くのがよいのかと思いますよ。その方がアスペクトもかけやすいなどもありますし、Javaから連携しやすいので。Scalaのように型推論とか難しいことがないため、Javaの発想で型を書くということですが。ローカル変数などはdefにしておくとか。
あと、上記の例ように、intなどの基本型は個人的にはdefよりintと宣言した方がJavaプログラムとの似ているため読みやすいと思います。この辺りはRubyの人とは考え方が異なっていると思いますが。
それから、GroovyをJavaプログラムの一部に組み込んで使う場合と純粋にスクリプトやツールとして使う場合で発想を変えるのもよいと思います。スクリプトの場合はすべてdefでやるなど。