昔から、いそがしいとつい飲み食いする量がひどく増えてしまう癖だけは
なおりません。最近体重計に乗るのが怖いです。
なおりません。最近体重計に乗るのが怖いです。
fooというrubyのメソッドに、FooというJavaクラスのインスタンスを渡す例です。
----
ポイントは上の例の最後の方の[A]と[B]の2点あります。
[A]でJavaのオブジェクトをRubyのオブジェクトに変換しています。
Javaのオブジェクトのメソッドはいい感じでRubyのメソッドに変換される模様です。
[B]では、JRubyのランタイムから取得したメソッドfooを表すメソッドオブジェクトの呼び出しを行っています。
このcallメソッドのシグネチャは以下のようになっております。
-----
public IRubyObject call(ThreadContext context, IRubyObject self, RubyModule klazz, String name, IRubyObject arg)
-----
このメソッドの引数の意味がわからなくてちょっとはまりました。
いまのところ、適当な引数を渡してみたらなんとか動いた、というのが正直なところです。
第2引数と第3引数で、そのメソッドがそのオブジェクトが属するオブジェクトとモジュールを決定します。これらは、メソッド内で引数のメソッド以外のメソッド呼び出しをするときに必要になってきます。
これらの引数にnullを渡して、その呼び出し先のメソッドで上記の例のようにputsとかを呼び出すと、ぬるぽになります。
第4引数も何に使われるのか謎なのですが、多分メソッド名です。
DynamicMethod自体は自分の名前を持ってないようだったので。。。
第5引数以降はRubyのメソッドに渡す引数です。
callメソッドの実装を読み解こうとも試みたのですが、ひどくややこしいことになっていたので、それはいずれ。。
----
import java.util.ArrayList;
import java.util.Map;
import org.jruby.Ruby;
import org.jruby.RubyClass;
import org.jruby.RubyRuntimeAdapter;
import org.jruby.internal.runtime.methods.DynamicMethod;
import org.jruby.javasupport.JavaembedUtils;
import org.jruby.runtime.ThreadContext;
import org.jruby.runtime.builtin.IRubyObject;
public class JRubyTest {
private static class Foo {
public String getFoo() {
return "foo";
}
}
public static void main(String[] args) throws Exception {
Ruby ruby = JavaembedUtils.initialize(new ArrayList<String>());
RubyRuntimeAdapter evaler = JavaembedUtils.newRuntimeAdapter();
String ls = System.getProperty("line.separator");
String script =
"def foo(arg)" + ls +
" puts arg.foo" + ls +
"end";
evaler.eval(ruby, script);
Map<String, DynamicMethod> map = ruby.getClass("Object").getMethods();
DynamicMethod method = map.get("foo");
ThreadContext ctx = ruby.getCurrentContext();
RubyClass obj = ruby.getObject();
IRubyObject arg = JavaembedUtils.javaToRuby(ruby, new Foo()); //[A]
IRubyObject rv = method.call(ctx, obj, null, "foo", arg); //[B]
System.out.println(rv);
}
}----ポイントは上の例の最後の方の[A]と[B]の2点あります。
[A]でJavaのオブジェクトをRubyのオブジェクトに変換しています。
Javaのオブジェクトのメソッドはいい感じでRubyのメソッドに変換される模様です。
[B]では、JRubyのランタイムから取得したメソッドfooを表すメソッドオブジェクトの呼び出しを行っています。
このcallメソッドのシグネチャは以下のようになっております。
-----
public IRubyObject call(ThreadContext context, IRubyObject self, RubyModule klazz, String name, IRubyObject arg)
-----
このメソッドの引数の意味がわからなくてちょっとはまりました。
いまのところ、適当な引数を渡してみたらなんとか動いた、というのが正直なところです。
第2引数と第3引数で、そのメソッドがそのオブジェクトが属するオブジェクトとモジュールを決定します。これらは、メソッド内で引数のメソッド以外のメソッド呼び出しをするときに必要になってきます。
これらの引数にnullを渡して、その呼び出し先のメソッドで上記の例のようにputsとかを呼び出すと、ぬるぽになります。
第4引数も何に使われるのか謎なのですが、多分メソッド名です。
DynamicMethod自体は自分の名前を持ってないようだったので。。。
第5引数以降はRubyのメソッドに渡す引数です。
callメソッドの実装を読み解こうとも試みたのですが、ひどくややこしいことになっていたので、それはいずれ。。
を読みました。
まずは、軽く触ってみました。
Rubyスクリプトとして定義されたメソッド「foo」をJavaから呼び出して
います。標準出力には'bar'が出力されます。
package jp.liq.rest.liq_restlet;
import java.util.ArrayList;
import org.jruby.Ruby;
import org.jruby.RubyRuntimeAdapter;
import org.jruby.javasupport.JavaembedUtils;
import org.jruby.runtime.builtin.IRubyObject;
public class JRubyTest {
public static void main(String[] args) throws Exception {
Ruby ruby = JavaembedUtils.initialize(new ArrayList<String>());
RubyRuntimeAdapter evaler = JavaembedUtils.newRuntimeAdapter();
String ls = System.getProperty("line.separator");
String script =
"def foo" + ls +
" return 'bar' " + ls +
"end";
evaler.eval(ruby, script);
IRubyObject eval = evaler.eval(ruby, "foo");
System.out.println(eval);
}
}Rubyスクリプトとして定義されたメソッド「foo」をJavaから呼び出して
います。標準出力には'bar'が出力されます。
最近JRubyに興味があります。
アプリケーションの中で、Javaだと書きにくい部分をRubyで書く、
というのが魅力的に思えるからです。バージョンも1.1がリリースされて、
かなり成熟してきた感があります。
くそ忙しいなかではありますが、徐々に勉強していきたいと思っております。
とりえあえず、ソースコードをダウンロードしてきて、ビルドしてみました。
ソースツリーにnbprojectとかいうフォルダがあるところをみると、
どうも、JRubyはNetBeansを使って開発しているらしい。さすがSUN。
アプリケーションの中で、Javaだと書きにくい部分をRubyで書く、
というのが魅力的に思えるからです。バージョンも1.1がリリースされて、
かなり成熟してきた感があります。
くそ忙しいなかではありますが、徐々に勉強していきたいと思っております。
とりえあえず、ソースコードをダウンロードしてきて、ビルドしてみました。
ソースツリーにnbprojectとかいうフォルダがあるところをみると、
どうも、JRubyはNetBeansを使って開発しているらしい。さすがSUN。
Mockitoというモックオブジェクトのライブラリが良さそうです。
EasyMockなどと違って、記録-再生という手順を踏まないところが新しいです。確かに、EasyMockには多少気難しいところがあって、モックに対して記録したのとちょっとでも違うメソッド呼び出しをしてしまうと、その瞬間検証エラーになってしまいます。EasyMockで気難しくないモックを作るには、モックを作るときに指定する必要があります。
これに対して、Mockitoでは記録していないメソッド呼び出しをすることが最初から可能で、検証はあとから必要な部分だけやるイメージのようです。気難しさは後からやる検証の厳しさで調節する、という思想のようです。
Mockといいつつもスタブ的な動作を中心にさせたほうが便利だ、という現実に即している訳ですね。
EasyMockなどと違って、記録-再生という手順を踏まないところが新しいです。確かに、EasyMockには多少気難しいところがあって、モックに対して記録したのとちょっとでも違うメソッド呼び出しをしてしまうと、その瞬間検証エラーになってしまいます。EasyMockで気難しくないモックを作るには、モックを作るときに指定する必要があります。
これに対して、Mockitoでは記録していないメソッド呼び出しをすることが最初から可能で、検証はあとから必要な部分だけやるイメージのようです。気難しさは後からやる検証の厳しさで調節する、という思想のようです。
Mockといいつつもスタブ的な動作を中心にさせたほうが便利だ、という現実に即している訳ですね。
最近自分の書くメソッドのシグネチャがついつい長くなりすぎて困っています。
例えば以下のような感じ。
---
public <T extends Foo> void put(Map<Class<? extends T>, Map<Integer, ? extends T>> map, Class<T> type, T obj)
---
既にどこがメソッド名かもわからん。何か根本的に間違ってるんでしょうか？
タイピングの量が増えてしまうのはJavaのGenericsの欠点かも。
例えば以下のような感じ。
---
public <T extends Foo> void put(Map<Class<? extends T>, Map<Integer, ? extends T>> map, Class<T> type, T obj)
---
既にどこがメソッド名かもわからん。何か根本的に間違ってるんでしょうか？
タイピングの量が増えてしまうのはJavaのGenericsの欠点かも。
最近S君の薦めもあって、京極夏彦をよんでいます。
昨夜は魍魎の匣―文庫版 (講談社文庫)
を読破しました。
大層面白い本で、ついつい明け方まで一気に読んでしまい、現在大変眠い状態です。
前作の姑獲鳥の夏も面白かったですが、２作目になってさらに磨きがかかっている感じです。
文庫版でありながら持ち歩くのが億劫になるほどの厚さの分量でありながら、
冒頭から終盤まで、無数の伏線を織り交ぜながら一気に読ませる物語の構成力はただごとではありません。
この文庫自体がかなり四角い箱です。中には、物語を綴る言葉が一部の隙もなくみっしりと敷き詰められております。
京極夏彦の描く世界観は、心身二元論の世界です。
世の中には物質だけが存在し、心はその影のようなものだとするのでも、
世の中には精神しかなく、世界は精神が描き出す夢のようなものだとするのでもなく、
精神と物質の両方が、確かに存在するのだという世界観です。
いま、私たちの目の前に広がっている世界。
この世界は、目を開けば意識に上り、目を閉じれば消えてしまう。
ここから、私たちの意識が自分の外部にあるなにものかに依存することがわかります。
しかし、目を閉じていても、夢の中ではその世界のイメージを再生することが
できます。ここから、私たちの意識には自分たちの外にあるものには依存しない
なにものかも紛れ込んでいることがわかります。
私たちが世界をみるとき、半分は自分の外の対象をみていますが、
半分は自分自信をみている。
意識とは、心と物との間の関連クラスなのです。
京極夏彦の小説は必ず妖怪をモチーフにしますが、妖怪はこの関連クラスの中に湧くものらしい。妖怪を一種の道具として、この関連クラスの存在を認めなければ癒されることのない苦しみを癒していく、というのが本作に限らず京極夏彦の小説のテーマのような気がしています。
そういう意味で、おどろおどろしくもありますが、本質的にはとても優しい、救済の物語であるともいえます。実際私も忙しくて大変な状況のなかでかなり癒されました。
なにを言っているのかわからない人は、ぜひご一読を。難しいこと考えずとも文句なしに楽しめます。
昨夜は魍魎の匣―文庫版 (講談社文庫)
を読破しました。大層面白い本で、ついつい明け方まで一気に読んでしまい、現在大変眠い状態です。
前作の姑獲鳥の夏も面白かったですが、２作目になってさらに磨きがかかっている感じです。
文庫版でありながら持ち歩くのが億劫になるほどの厚さの分量でありながら、
冒頭から終盤まで、無数の伏線を織り交ぜながら一気に読ませる物語の構成力はただごとではありません。
この文庫自体がかなり四角い箱です。中には、物語を綴る言葉が一部の隙もなくみっしりと敷き詰められております。
京極夏彦の描く世界観は、心身二元論の世界です。
世の中には物質だけが存在し、心はその影のようなものだとするのでも、
世の中には精神しかなく、世界は精神が描き出す夢のようなものだとするのでもなく、
精神と物質の両方が、確かに存在するのだという世界観です。
いま、私たちの目の前に広がっている世界。
この世界は、目を開けば意識に上り、目を閉じれば消えてしまう。
ここから、私たちの意識が自分の外部にあるなにものかに依存することがわかります。
しかし、目を閉じていても、夢の中ではその世界のイメージを再生することが
できます。ここから、私たちの意識には自分たちの外にあるものには依存しない
なにものかも紛れ込んでいることがわかります。
私たちが世界をみるとき、半分は自分の外の対象をみていますが、
半分は自分自信をみている。
意識とは、心と物との間の関連クラスなのです。
京極夏彦の小説は必ず妖怪をモチーフにしますが、妖怪はこの関連クラスの中に湧くものらしい。妖怪を一種の道具として、この関連クラスの存在を認めなければ癒されることのない苦しみを癒していく、というのが本作に限らず京極夏彦の小説のテーマのような気がしています。
そういう意味で、おどろおどろしくもありますが、本質的にはとても優しい、救済の物語であるともいえます。実際私も忙しくて大変な状況のなかでかなり癒されました。
なにを言っているのかわからない人は、ぜひご一読を。難しいこと考えずとも文句なしに楽しめます。
3月から4月にかけて、事業計画、とか、利益目標だとか、そういう言葉を偉い人が口走るのを耳にします。
また金の話か、とそれを聞いて私などはうんざりする訳です。
利益を上げることは企業の存在意義、金の話をするのは別に汚いことではないのに、なぜか彼らの話に私は奇妙な違和感を覚えます。
多分世の中には、
「明日が今日と同じ日であることを望む人」と
「明日が今日と違う日であることを望む人」
の二種類の人間がいるのです。
彼らは前者、私は後者です。
これは、優劣とか善悪じゃなくて、単純に人間の性格の「違い」でしかないことです。
明日が今日と同じ日であることを望む人にとって、利益を上げることは「目的」です。
会社に対して利益という責任を果たすことによって、今日と同じ明日を迎えられることが保証されます。
利益を上げるために、どういう手段をとるかは、まぁ、どうでも良い。
明日が今日と違う日であることを望む人にとって、利益を上げることは「結果」です。
なにかユニークなサービス、プロダクト、ビジネスモデルを展開する事によって、今日と違う明日を生み出すことができます。
利益はその結果ついてくるもので、結果をはかる指標です。
だめだったらだめだったらで、多少給料が下がったりするのはやむなし、来期は目標をクリアできるように頑張ろう。
それだけです。
私は特に守るべきものもないし、明白に今日と違う明日を望む人種です。
給料が上がるとか下がるとかじゃなくて、なにか今までにないユニークな
成果をあげることで、プロジェクトを成功に近づけることができるのであれば、
残り寿命が半分になることと引き換えにする取引をしても良いとさえ思っています。
NTTデータ本体のほとんどの部署は
「今日と同じ明日を望む人」にとって居心地の良い会社です。
だから、経営陣の語るビジョンや事業計画などは、どうしても私には言い訳じみて聞こえてしまう。
そのビジョン、その事業計画でなくても、明日が今日と同じ日であれば
かれらの目的は達成されるのですから、そこには必然性と説得力が欠落しているのです。
うちの会社はそれでも、せっかくセンタンとか恥ずかしげもなく名乗ってしまってるんですから、
もっと尖って、今日と違う明日を目指す人が増えて欲しいと思うんですけどね。
少なくとも私は空気などいっさい読まずに突っ走りますが。
でも私がすごい勢いで会社批判とかしても、その結果立場が悪くなったりとかは一切ないし、
毎年それなりにお給料はあがっていたりするので、
うちの会社には意外に懐が広いというか、大らかなところもあるんですけどね。
また金の話か、とそれを聞いて私などはうんざりする訳です。
利益を上げることは企業の存在意義、金の話をするのは別に汚いことではないのに、なぜか彼らの話に私は奇妙な違和感を覚えます。
多分世の中には、
「明日が今日と同じ日であることを望む人」と
「明日が今日と違う日であることを望む人」
の二種類の人間がいるのです。
彼らは前者、私は後者です。
これは、優劣とか善悪じゃなくて、単純に人間の性格の「違い」でしかないことです。
明日が今日と同じ日であることを望む人にとって、利益を上げることは「目的」です。
会社に対して利益という責任を果たすことによって、今日と同じ明日を迎えられることが保証されます。
利益を上げるために、どういう手段をとるかは、まぁ、どうでも良い。
明日が今日と違う日であることを望む人にとって、利益を上げることは「結果」です。
なにかユニークなサービス、プロダクト、ビジネスモデルを展開する事によって、今日と違う明日を生み出すことができます。
利益はその結果ついてくるもので、結果をはかる指標です。
だめだったらだめだったらで、多少給料が下がったりするのはやむなし、来期は目標をクリアできるように頑張ろう。
それだけです。
私は特に守るべきものもないし、明白に今日と違う明日を望む人種です。
給料が上がるとか下がるとかじゃなくて、なにか今までにないユニークな
成果をあげることで、プロジェクトを成功に近づけることができるのであれば、
残り寿命が半分になることと引き換えにする取引をしても良いとさえ思っています。
NTTデータ本体のほとんどの部署は
「今日と同じ明日を望む人」にとって居心地の良い会社です。
だから、経営陣の語るビジョンや事業計画などは、どうしても私には言い訳じみて聞こえてしまう。
そのビジョン、その事業計画でなくても、明日が今日と同じ日であれば
かれらの目的は達成されるのですから、そこには必然性と説得力が欠落しているのです。
うちの会社はそれでも、せっかくセンタンとか恥ずかしげもなく名乗ってしまってるんですから、
もっと尖って、今日と違う明日を目指す人が増えて欲しいと思うんですけどね。
少なくとも私は空気などいっさい読まずに突っ走りますが。
でも私がすごい勢いで会社批判とかしても、その結果立場が悪くなったりとかは一切ないし、
毎年それなりにお給料はあがっていたりするので、
うちの会社には意外に懐が広いというか、大らかなところもあるんですけどね。