どうもプロジェクトでバッチ処理を実行するための仕組みを
自分で作らなくちゃいけなくなる気配です。
要件をいろいろ検討すると、自作しないといけなさそう。
めんどくさ。。
こんなときみんなどうしてるんでしょう?
自分で作らなくちゃいけなくなる気配です。
要件をいろいろ検討すると、自作しないといけなさそう。
めんどくさ。。
こんなときみんなどうしてるんでしょう?
以下のようなクラスを作ってみました。
例えば、META-INF/classes.lstというファイルに、
以下のようにクラス名をリストアップ
しておきます。
仕掛け自体は非常に単純なのですが、
これで、Jarファイルをクラスパスに通すだけで、そのJarのMETA-INF/classes.lst
に書いてあるクラスを取得できるようになります。
LiQ Containerと組み合わせるとプラグインぽい仕組みを簡単に作ることが
できて便利そうなので、LiQ Container本体にこっそり入れるかどうか
考え中です。
例えば、META-INF/classes.lstというファイルに、
以下のようにクラス名をリストアップ
しておきます。
---- jp.liq.sample.AImpl1 jp.liq.sample.AImpl2 java.lang.String ----以下のようなコードで上記のクラスが取得できます。
----
ClassDiscoverer discover = new ClassDiscoverer();
discover.addClassList("META-INF/classes.lst");
int cnt = 0;
for(Class c: discover.classes().isA(A.class)) {
assertTrue(A.class.isAssignableFrom(c));
cnt++;
}
assertEquals(2, cnt);
----ここではインタフェース「A」のサブクラスのみを取得しています。仕掛け自体は非常に単純なのですが、
これで、Jarファイルをクラスパスに通すだけで、そのJarのMETA-INF/classes.lst
に書いてあるクラスを取得できるようになります。
LiQ Containerと組み合わせるとプラグインぽい仕組みを簡単に作ることが
できて便利そうなので、LiQ Container本体にこっそり入れるかどうか
考え中です。
話しかけるな宣言はあり、とかいっときながら、
昨日、自分がちょっと息抜きしたいときに、
話しかけるなオーラ前回の人に、ついちょっかいだしてしまいました。
反省。
昨日、自分がちょっと息抜きしたいときに、
話しかけるなオーラ前回の人に、ついちょっかいだしてしまいました。
反省。
最近、そういう病気が再発してしまったようです。
すでに似たようなものがあるのに、自分で新しく作りたくなってしまうという
病気。
LiQ Containerの使い勝手の最終確認をかねて、最近ちまちまコード書いてます。
すでに似たようなものがあるのに、自分で新しく作りたくなってしまうという
病気。
LiQ Containerの使い勝手の最終確認をかねて、最近ちまちまコード書いてます。
最近聞いた話なのですが、お役所系の案件は、1個のでかい案件を1社がまるごと受注するのは
良くない、とされているらしく、分割して発注する、という流れになっているそうです。
その分割の仕方というのが、なんと「工程で分割」になっている模様。
分割発注自体は、意図はわからんでもないし、よいと思うんですが、
工程で切っちゃうのは止めた方がいいとおもうんだけどな。
やってみないと分からないですが、
上流担当会社と下流担当会社の間での調整あるいは責任の押し付けあいに、
かなりの手間がかかりそう。そして、そのコストは国民の血税でまかなわれる訳で。。
良くない、とされているらしく、分割して発注する、という流れになっているそうです。
その分割の仕方というのが、なんと「工程で分割」になっている模様。
分割発注自体は、意図はわからんでもないし、よいと思うんですが、
工程で切っちゃうのは止めた方がいいとおもうんだけどな。
やってみないと分からないですが、
上流担当会社と下流担当会社の間での調整あるいは責任の押し付けあいに、
かなりの手間がかかりそう。そして、そのコストは国民の血税でまかなわれる訳で。。
うちのプロジェクトのメンバは朝会のときたまに
「今日は集中して作業したいので話かけないでください」とか宣言してますが、
私はこれは「あり」だと思っています。
コミュニケーションは大事とはいえ、集中力が生産性を生む局面も多々あるわけですから、
自分の判断で最初に宣言して集中モードに入るのであれば、
1日くらいそういう日があってもメリハリがついて良いと思うのです。
「今日は集中して作業したいので話かけないでください」とか宣言してますが、
私はこれは「あり」だと思っています。
コミュニケーションは大事とはいえ、集中力が生産性を生む局面も多々あるわけですから、
自分の判断で最初に宣言して集中モードに入るのであれば、
1日くらいそういう日があってもメリハリがついて良いと思うのです。
プログラミングでも、プロジェクトマネジメントでも、私が「うまくできた」
と感じるときには、必ず実際になにか行動を起こす前に頭の中に良いイメージが出来上がってます。
プログラミングであれば、コードを書くまえに、
頭のなかでオブジェクトモデルが大体動作しているし、
マネジメントであれば、自分が次にとるべきアクションと、それが及ぼす
チームのコラボレーションへの影響を二手くらい先まで読めています。
ソフトウェアプロジェクトは厳しいことが多いですが、
最近はこの傾向が自分でわかってきたので、ピンチのときこそ
「明るい未来を想像すらできないのであれば、それは決して訪れない」
と自分に言い聞かせて、良いイメージがおりてくるのを待つことにしています。
そんなときは気分転換が大事だと思うので、
思い切って早くかえったり、海を見に行ったりしています。
...豊洲の海辺をうろうろしている挙動不審な男を見かけたら、それは多分私です。
生温かい目で見守ってやってください。
もし、JDKのインタフェースで一番好きなのはどれ、と問われたら、
私はおそらく「Iterable」と即答するでしょう。
最近いろいろなものをIterableにするのに凝っています。
LiQ Container にも、Iterableを利用してオブジェクトのメソッドや
フィールドを簡単に取得できる仕組みを組み込んでおります。
例えば
java.reflect.Methodそのものでなくて、Wrapperを返しているのは、
主にリフレクションAPIが返す煩雑なチェック対象例外を
LiQ Container の RuntimeExceptionでラップするためです。
以下のように書くと、"get"で始まるメソッドのみを返すことも出来ます。
持つメンバのみを取得できます。
実際使ってみると便利です、これ。
私はおそらく「Iterable」と即答するでしょう。
最近いろいろなものをIterableにするのに凝っています。
LiQ Container にも、Iterableを利用してオブジェクトのメソッドや
フィールドを簡単に取得できる仕組みを組み込んでおります。
例えば
----
for(MethodWrapper m : methods.of("hoge")) {
System.out.println(m.name());
}
----で"hoge"というStringの持つ public メソッドが全部とれるといった具合。java.reflect.Methodそのものでなくて、Wrapperを返しているのは、
主にリフレクションAPIが返す煩雑なチェック対象例外を
LiQ Container の RuntimeExceptionでラップするためです。
以下のように書くと、"get"で始まるメソッドのみを返すことも出来ます。
----
for(MethodWrapper m : methods.of("hoge").withPrefix("get")) {
System.out.println(m.name());
}
----同様にwithAnnoationというメソッドを使うと特定のアノテーションを持つメンバのみを取得できます。
実際使ってみると便利です、これ。
たまりまくった仕事を夜間バッチで片付けようと、久し振りに
夜を徹して作業中です。だんだん変なテンションになってきました。
楽しくなってきた。
夜を徹して作業中です。だんだん変なテンションになってきました。
楽しくなってきた。