Archives

You are currently viewing archive for May 2007

[@上海] 26 May 2007 はてなブックマーク - 歯磨き粉が有毒な件に付いて Twitterでつぶやく

歯磨き粉が有毒な件に付いて

歯磨き
CNN:米当局、中国製歯磨き剤を検査へ 他国での毒物検出を受け
産経:米が中国産練り歯磨き検査 パナマなどで有毒物質検出

ブランド名が不明とか書いてあったので調べてみました。(っていうか産経とかちゃんと調べて公表しろよ、不明とか書くなっての)
中国问题牙膏巴拿马被查获
Mr.CoolExcelというブランドだそうです。
このブランドは、あんまり有名でないようで知合いも見たことないそうです。

一連の工業用ジエチレングリコールと同様の原因のようで・・・。
やはり中国で安いものに良いものはないようです。(高いからといって良い物とは限りませんが・・・)

[メモ] 19 May 2007 はてなブックマーク - JavaScriptでもロギング Twitterでつぶやく

JavaScriptでもロギング

Ajaxを利用していてデバッグ時にSystem.out並なalertに辟易してたのでログを作ろうかと思ったら、やっぱりあったw
Log4jライクな方法で利用できる。当然、AppenderやらLogレベルもある。

Log4JS
http://log4js.sourceforge.net/

ちょっと気になるのは、デバッグレベルあげたとき負荷は下がるだろうか・・・・。
#つまりLog4jみたいにログコード埋め込みっぱなしでよいのかなーってこと

[Java] 17 May 2007 はてなブックマーク - FlatXmlDataSetでnull値 Twitterでつぶやく

FlatXmlDataSetでnull値

ただのメモ。
DBUnitのFlatXmlDataSetでnull値を利用したいときはこういう感じでリプレースしてやると可能。
ReplacementDataSet dataSet = new ReplacementDataSet(
new FlatXmlDataSet(…));
dataSet.addReplacementObject("[NULL]", null);

http://dbunit.sourceforge.net/components.html

[Programing] 09 May 2007 はてなブックマーク - IronRuby on DLR Twitterでつぶやく

IronRuby on DLR

下記の記事から、これはどっかで既出だったけど、SunがJRuby開発者を雇ったのとNetBeansでRubyをサポートするそうです。
あと、先日マイクロソフトがIronRubyを発表しました。
これは.NETのCLR上で動くDLR(DynamicLanguageRuntime)上で動作する実装のようです。
先のIronPythonも同じ原理で、DLR上ではRuby、Python、JavaScript(JScript)、VBが動作すると書いてあります。
つまりCLR上で構築するんではなくスクリプト言語用のプラットフォームをDLRに共通化してあるみたいです。
#VBって動的型言語だったのか・・・wまあそういえなくもないか

これらはMicrosoftMIXで発表されたSilverlightに伴って明らかになった話で、Microsoftのブログでは.NETライブラリをこれらの動的言語から利用できて、Silverlightのアプリがクロスプラットフォームでかけるよーみたいなことを言ってます。

Microsoft Announces IronRuby
MIX 07 - Silverlight shines brighter!

ところで、そのSilverlightって何だと・・・w
紹介ページを見ると、クロスプラットフォームで、.NETで、リッチでインタラクティブなアプリケーションをスクリプト言語(AJAX, VB, C#, Python, and Ruby)で書けますぜ!と言ってます。<嘘クセエ
要するに、Flashに対抗する物で、FlashではActionScriptだけだけどMicrosoftは色々いけちゃうよって物だと理解しました。

あ、あとSunがJavaFX Scriptという新しいスクリプト言語を発表するそうです。もちろんJDK6のScriptエンジンで動くはず。
これはまあ、出遅れた感があるような気がしなくもない・・・・

こうしてみると.NETとJavaで言語プラットフォーム戦争が始まってますね。

[Book] 07 May 2007 はてなブックマーク - 「JavaからRubyへ」読了。 Twitterでつぶやく

「JavaからRubyへ」読了。

読み終わりました。
久々に一息で読みました。
↑空いた時間をつなぎ合わせつつだったので時間が掛かってしまった。

ここまでドキドキして技術書を読んだのはEffectiveJava以来でした。
細かな技術的説明はさておき、何が得られるか、どうやるべきかにおいて多くの道しるべを与えてくれました。
また最初の印象通り、全体としてRubyが全て!という訳でもなく非常にバランスがとれた内容でした。

感想として、今現在LAMPとJavaで行なわれているWEB開発の中間部分は、ごっそりとRails(Ruby)に移行していくと思いました。
つまり、PHPはよりラピッドな簡易構築、Javaはよりエンタープライズな重量級インフラ系に押しやられ、いわゆるWEBアプリケーションと呼ばれる本流部分はRailsに置き換わるだろうということです。

もちろん、全てがRails一色になるとは思いませんがかなりの部分がRailsに取って代わられると思います。

当面の目標として、(本書で言うところの)政治的リスクはあるものの、ちょうど良いサイズのアプリケーションをRails化してみようと思います。また中期的にはRubyのできるオフショアを目指して行きます。
↑よりコストを低減させ競争力を強化する助けになると確信しました。

Rubyに興味を持つ人にとって、この本は非常に対費用効果が高いと思います。経費でも何でも使って是非購入すべきです。

では

[Book] 03 May 2007 はてなブックマーク - 「JavaからRubyへ」の3章までの感想について Twitterでつぶやく

「JavaからRubyへ」の3章までの感想について

java2ruby
遅ればせながら、角谷さんが翻訳をされた「JavaからRubyへ —マネージャのための実践移行ガイド」を入手しました。
全てを読み終わらないうちに、待ちきれずに書いてしまいます。今ちょうど第3章を読み終わったところですが、その内容は私を打ちのめすのに充分でした。

まずはRubyが如何にすばらしいのかという点よりも、私が愛してやまないJavaの見て見ぬふりをしていた点をズバリ指摘している部分に衝撃を受けました。


1,Javaは生産性が低いという事実
2,WEBアプリを作るに当たって最適解ではない事実
3,Javaの再利用性の幻想


これらについて私は以下のように感じました。
1について、これは認めたくない事実であり、事実と直感的に知りながら目をそらしていた事実です。実際、Javaにおいては厳密な型定義と規格の準拠に多くの時間が費やされます。
特にそれに伴うコンパイルと複雑なデプロイ、またはビルドツールの設定作業は、宗教めいた儀式と化して私のテックマン(*1)としてのプライドに安心と尊厳を与えてくれます。
その点を除けば、残念ながらこの崇高な時間は明らかに無駄であり開発プロセスから省かれるべき儀式です。
恥ずかしながら、私は周辺技術をマスターしそれを扱えることが、大事な仕事であると勘違いをしていました。

ある中国人エンジニアの言った「Javaは面倒くさいですよ。」という言葉が深く突き刺さります。私はそのとき単にそれを「技術が低いからでる言葉」であると切り捨てました。
しかし確かに、Springの設定も、WARのデプロイも、Mavenによるビルドも面倒であり本質的では無いことを認めます。


2については否定のしようもありません。むしろ、しばらく前から自分でも社内において下記のような(私的には)敗北宣言を出していました。
「少なくともWEBサイトの構築においてJavaはPHPより向いているとは口が裂けても言えません。個人的にはJavaでやりたいが、この案件は明らかにPHPでやるべきです。」

そして3,私は、時々インタフェース主義は全てを達観したスーパーエンジニアでなければ対応できないのではなかろうかと思うことがあります。つまり「精兵主義の軍隊に精兵がいなかった事(*2)」というわけです。
少なくとも私は今に至るまで、ミクロな規模を除いて有効な再利用がされているところを見たことがありません。
反論される人がいると思います。でもよく考えてみてください、インタフェースを修正したことはありませんか?絶対にあるはずです。
どんなにDAOとServiceを綺麗に分離してDIコンテナによりシンプルにしても、開発中WEB層からの呼び出し時にインタフェースの修正をしたことがあるはずです。(そもそもバイトコードインジェクションによるAOPという技術がそれを証明しています。)

ミクロな視点でのインタフェースの利用に文句はありませんが、これを業務ロジックに適用すると破綻をきたしているのに疑いはありません。なぜなら業務ロジックは生き物であり外的容認により変化し、また新たに発見されるからです。

本書でも繰り返し述べているように、Rubyが全ての最適解にはなり得ないでしょうが、少なくともこれまでJavaだけを見ていた私にとっては開発の本質を取り戻す良い機会になる事だけは間違いないです。

さて、続きを読まなければ・・・・ww
#上海までこの本を持ってきてくれたH君、ありがとう。

*1 アイザック・アシモフのファウンデーションシリーズにおいてホーバー・マロウが訪ねた銀河帝国の原子力発電のエンジニア、ホーバー・マロウは下記のように表現している。
「かれらはもはや自分たちの巨大技術すら理解できなくなっているんだぞ。」

*2 山本七平による「日本はなぜ敗れるのか」で引用されている小松真一による敗因21ヵ条の第一条より
「精兵主義の軍隊に精兵が居なかった事。然るに作戦その他で兵に要求される事は、全て精兵で無ければできない仕事ばかりだった。武器も与えずに。米国は物量に物言わせ、未訓練兵でもできる作戦をやってきた」
«Prev || 1 || Next»