2010-02-02
■[java]OSGiってBuzzワードになりつつあるような。。
OSGiがエンタープライズアプリケーションに与えるインパクト - Fly me to the Helios
コメントが本体。OSGiってどうなの？って話。
id:koichik さんが言っていることが全てなんだけど。
自分もOSGiが、エンタープライズの開発に普及することはない。と思っている。
アプリケーションが、Bundleの集合でなんたらかんたらと言っているのは、何年か前に、アプリケーションはコンポーネントの組み合わせで作ることができるようになるってことを言っていたのと似てる。
システムを塊に分けて、その塊を疎に結ぶっていう考え方は、とても重要なことなんだけど、OSGiしかり、コンポーネントなんたらしかり、WEBサービスしかり、SOAしかり、ESBしかり、そんなBuzzワードや、技術の導入によって実現できるものじゃーない。
そこをすぐに勘違いする人たちがたくさんいるのが困ったところ。
使いこなすためには、適切な塊の分割と、そのインタフェース設計、適切なホットスポットの見極めるスキルが必要。
でも、こういうのに乗っかろうとしちゃう人は、このスキルがないか、スキルが必要ってことすら理解できない人たちが大半。*1
ゆえに導入して失敗する。失敗するから、コンポーネントって駄目だったよね。SOAって駄目だよね。みたいになる。よって、普及しない。
2010-01-28
■[java]Mule ESB いいかも。
昨日から、Mule を触っている。
http://www.mulesoft.org/display/MULE/Home
Mule ESB(以下、Mule)は、米MuleSoft社 が開発し、オープンソースで公開している Java製のESB。
よりハイエンドな機能を統合したエンタープライズ版も、同社から提供されていたりもする。
商業利用に際しては、MuleSoft社が、サポートをしてくれるので、いざというときも、（多分）安心。
MuleSoft直だと、英語のサポートだと思うけど、日本では、オージス総研がサポートを提供しているようです。*1
ともあれ、同じオープンソース系のESBであるServiceMixその他に比べて、開発している会社が、サポートを提供してくれるというのは、商業利用の際には、かなりの強みではないかと。
Mule ESB と、ServiceMixとの大きな違いは、ServiceMixはJBI仕様に準拠、Mule ESB は準拠でないという点。
これは、個人的には、Mule ESB 最大の利点といってもいいくらい。
しばらく、仕事で、ServiceMixを触ってたのだけど、このJBI仕様が、一昔前のEJBの悪夢を思い出させてくれる代物です。Muleの創設者もJBI仕様に難癖をつけています。
あなたはサービスを実装するために、とても重厚なAPIを実装しなければなりません。ssary. これはあなたのサービスを書くために、JBIに関して必要以上に理解しなければならないという意味です。
InfoQ: Mule創設者: JBIは目標を見失っている
JBI仕様は、ESBの内部処理や、ESB内のコンポーネントの標準化を推し進めるものと解釈しているんだけど、ESBは、システム間連携に使われるものなので、正直、外部とのコネクティビティさえ標準的であれば、内部はなんでもよいのではないかと。
標準にしたがっておけば、ほかのESBコンテナに移行できるとか、システムが特定のソフトに依存するのがイヤとか言う人がよくいるけど、
EJB全盛のころEJBコンテナを移行した例がどれほどあるのかと。JBI仕様に従ったところで、他のJBIコンテナでどれほど動作するのかと。なんかね何かというとEJBとって浮かれてた時代が思い起こされて香ばしい。
あと、ホットデプロイが、Mule ESB には無いというのが欠点とか言われているのもありますが、次期バージョンの3.0系でサポートされるとのこと。
なんか、JBI仕様の悪口になってしまったけど、ServiceMix使った後に、Mule ESB 使うと、わかると思うこの気持ち。
Mule ESBは、必要なことだけにフォーカスしている感じがする。
*1：オージスと言えば、勝手に OO界の雄 と思い込んでいるので、そのサポートにはかなり期待できるのではないかと。
2010-01-22
2010-01-20
■[java][coding]15分
10分でコーディング/Java
nullなStringを連結すると、"null" ってなるってことを忘れてて時間をロスした。
public class Cards { public String[] deal(int numPlayers, String deck) { String[] ret = new String[numPlayers]; java.util.Arrays.fill(ret, ""); for (int i = 0; i < (deck.length() - deck.length() % numPlayers); i++) { ret[i % numPlayers] = ret[i % numPlayers] + deck.charAt(i); } return ret; } public static void main(String[] args) { int p = Integer.parseInt(args[0]); String d = args[1]; Cards c = new Cards(); String[] results = c.deal(p, d); for (String r : results) { System.out.println("*" + r); } } }
そもそも、問題の内容を理解するのに、５分くらいかかってたり。。
2010-01-05
■[zsh][linux]PROMPTのカラーコード
PROMPTの設定をしようとしたとき、いつも探すのに時間がかかる上に、すぐに忘れるのでメモ。
/usr/share/zsh/functions/Misc/colors 30 black 40 bg-black 31 red 41 bg-red 32 green 42 bg-green 33 yellow 43 bg-yellow 34 blue 44 bg-blue 35 magenta 45 bg-magenta 36 cyan 46 bg-cyan 37 white 47 bg-white # 38 iso-8316-6 # 48 bg-iso-8316-6 39 default 49 bg-default
■[golang]Go のセミコロンの扱いが変わった。
09/12/22にリリースされたバージョンで、セミコロンの扱いが変わった。
今までは、セミコロンは、ブロックの末尾と、括弧の後だけ省略OKだったんだけど、
それが、セミコロンなしでもOKになった。*1
大元は、golang-nutsに投稿された以下の提案みたい。
http://groups.google.com/group/golang-nuts/browse_thread/thread/5ee32b588d10f2e9
セミコロン打たなくていいのは、かなりいい感じ。
スムースにかける。
コーディングが早くなる感じがする。
けど、上記のURLでも指摘されているけど、複数行に渡る式で演算子を前置するフォーマットがエラーになるのが、あぅー。
// この書き方はeエラー foo := f1() + f2() + f3() // こう書くのが正解 foo := f1() + f2() + f3()
演算子が前置の方が、自分は見やすいと思っているで、ちょっとなーという感じ。
セミコロンがないから、上の書き方がエラーになるのかと思いきや、セミコロンをつけても、エラー。
なので、以前のバージョンで書いたコードで、前置の演算子があるやつは軒並みコンパイルエラーになる。
そういう人の為に（だと思うけど）、gofmt を -oldparsers オプションを指定して、昔のコードを通すと、セミコロンなしのコードに変換してくれる。
例えば、以下の以前のコンパイラだと問題ないコードを
package main import "fmt" func f1() int { return 1 } func f2() int { return 1 } func f3() int { return 1 } func main() { foo := f1() + f2() + f3(); fmt.Println(foo) }
gofmt -oldparser を通すと、ご丁寧に、演算子を後置してくれる。
package main import "fmt" func f1() int { return 1 } func f2() int { return 1 } func f3() int { return 1 } func main() { foo := f1() + f2() + f3() fmt.Println(foo) }
*1：当然、ワンライナーで書くならセミコロンが必要