Hatena::ブログ(Diary)

Fly me to the Juno! このページをアンテナに追加 RSSフィード Twitter

2008-02-29

プラグインのテストコードを書く(ツールバー編:v3.3)

今日は4年に1度の大肉の日。今日リリースとかやったらかっこいいのだけれども、今回も断念。へたれっぷりにがっくし。

さて、 プラグインのテストコードを書く(コマンド編:v3.3) - Fly me to the Juno!/ プラグインのテストコードを書く(ショートカット編:v3.3) - Fly me to the Juno!に引き続きテストコードの型シリーズ第3回。今回もKenichi Takahashi氏のFontSizeChangerですよー。リポジトリ

https://eclipse-study.svn.sourceforge.net/svnroot/eclipse-study/EasyFontChanger/branches/TRY-Active-View/

です。

今回のお題はツールバー-コマンド間の実行(Toolbar-Command)です。

ツールバーとコマンドの関係はplugin.xmlに次のように書きます。

 <extension
   point="org.eclipse.ui.menus">
  <menuContribution
    locationURI="toolbar:org.eclipse.ui.main.toolbar?after=additions">
   <toolbar
     id="net.shu_cream.eclipse.font">
    <command
      commandId="net.shu_cream.eclipse.font.large" (1)
      icon="icons/large.gif"
      id="large" (3)
      label="Large"
      style="push"
      tooltip="Large">
    </command>
   </toolbar>
  </menuContribution>
 </extension>
 <extension
   point="org.eclipse.ui.commands">
  <command
    categoryId="net.shu-cream.eclipse.font.category1"
    id="net.shu_cream.eclipse.font.large" (1)
    name="Large">
 </extension>

例によって(1)がToolbarとCommandを結びつけるキーです。で、今回書いたテストコードはこんな感じ。

 @Test
 public void このクラスがツールバーに登録されているか() throws Exception {
  IWorkbenchWindow[] windows = PlatformUI.getWorkbench().getWorkbenchWindows();
  for(IWorkbenchWindow w : windows){
   ApplicationWindow window = (ApplicationWindow) w;//(a)
   ICoolBarManager coolbar = window.getCoolBarManager2();
   ToolBarContributionItem contributionItem = (ToolBarContributionItem) coolbar.find("net.shu_cream.eclipse.font");
   assertNotNull(contributionItem);
   
   ToolBarManager barManager = (ToolBarManager) contributionItem.getToolBarManager();
   IContributionItem item = barManager.find("large");//(b)
   assertNotNull(item);
   assertTrue(item instanceof CommandContributionItem);
   
   CommandContributionItem commandItem = (CommandContributionItem) item;
   assertTrue(commandItem.isEnabled());

   doCommand(barManager);
  }
  
 }

 private void doCommand(ToolBarManager barManager) {
  ToolBar toolbar = barManager.getControl();
  ToolItem[] toolItems = toolbar.getItems();
  for(ToolItem toolItem : toolItems){
   if("Large".equals(toolItem.getToolTipText())){
    // execute toolbar item
    toolItem.notifyListeners(SWT.Selection, null);//(c)
   }
  }
 }

若干無理やり感が漂っているコードですが、これでもツールバーに登録されていて、きちんと動くかどうかを確認できます。

まず(a)ですが、直接インスタンスを確認するとWorkbenchWinndowクラスが返ってきています。そうです。Eclipseのウィンドウクラスです。それを無理やりJFaceのApplicationWindowクラスへキャストしているのは、WorkbenchWindowクラスがinternalだから。不要なinternalへの参照はなるだけ避けるようにしましょう。

(b)ではlargeというキー名でツールバーのアイテムを取得しています。plugin.xmlの(3)のキー名です。さらっと取得してみましょ。

(c)では実際に取得したツールバーのアイテムを実行しています。ちょっとズルいのはラベル名を取得して比較しているところでしょうか。でもそういう名前のチェックがあってもいいよねー。(と言い訳にならない言い逃れ。)

これで一応FontSizeCheckerの一機能に関してはテストが書けたのではないかと自画自賛。プラグインのテストを書くと何が一番うれしいかって、バージョンやOSなどの環境の違うEclipse上できちんと動くかどうかさらっと検証ができる点。LL系のソフトでは実働環境で動いているかどうかを確認するためのテストコードが付属することが多いですが、Eclipse Pluginでそこまで手をまわす人が少ないこの事実。Eclipse Foundationが公開しているWikiにもあんまりその辺の情報がない点が足を引っ張っているんでしょうね。

以上テストで足らない点があればご指摘くださいね。

2008-02-28

Eclipse 3.4 M5 Package Builds リリース

Eclipseは3.3からJavaプログラマ用やC/C++プログラマ用などのパッケージごとにリリースがされるようになりました。先日Eclipse 3.4 M5がリリースされたとはてダに書いた記憶があるんですが、パッケージごとのリリースが行われたのは昨日みたいです。*1Eclipseのアナウンスでは3.4 M5がリリースされた直後は何もなかったんですが、要するに、パッケージリリースが行われるまで一呼吸おいたほうが試すにしても幸せだよっていうはからいなんでしょう。

id:t-wadaさん曰く、『3.4 M4は安定版じゃないけど、特に問題なく使えるよ。』という訳なので先ほど落として使い始めました。で、ちょっと残念なお知らせが。

僕が使っているパッケージはRCP/Pluginプログラマ用のEclipseなのですが、同梱されているJUnit4のバージョンが4.3.1でhumcrestもassertThatもナイバージョンなのです。*2

パンくずナビがJavaEditorにくっついたのは楽しげなので、しばらく使い続けるつもりです。

*1Eclipse News経由で知りました。

*2:つまり3.3と変わってない

2008-02-27

プラグインのテストコードを書く(ショートカット編:v3.3)

プラグインのテストコードを書く(コマンド編:v3.3) - Fly me to the Juno!に引き続きテストコードの型シリーズ。以外に簡単にいけちゃいそう。今回はショートカット編。題材もKenichi Takahashi氏のFontSizeChanger。リポジトリ

https://eclipse-study.svn.sourceforge.net/svnroot/eclipse-study/EasyFontChanger/branches/TRY-Active-View/

です。

今回のお題はショートカット-コマンド間の実行(Binding-Command)です。ショートカットとコマンドの関係はplugin.xmlに次のように書きます。

<extension
  point="org.eclipse.ui.commands">
 <command
   categoryId="net.shu-cream.eclipse.font.category1" (2)
   id="net.shu_cream.eclipse.font.large" (1)
   name="Large">
 </command>
</extension>
<extension
 point="org.eclipse.ui.bindings">
  <key
   commandId="net.shu_cream.eclipse.font.large" (1)
   contextId="org.eclipse.ui.contexts.dialogAndWindow"
   schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"
   sequence="M1+M3+;">
  </key>
</extension>

(1)がCommandとHandlerを結びつけるキーで、(2)のカテゴリーを設定しないと環境によってはせっかく設定したCommandが動作しなくなることがあるようです。

WindowsだとM1はCtrlキー、M3はAltキーに相当します。*1で、今回書いたテストコードはこんな感じ。

  @Test
  public void このクラスがショートカットに登録されているか() throws Exception {
    IBindingService service = (IBindingService) PlatformUI.getWorkbench().getService(IBindingService.class);
    TriggerSequence[] sequences = service.getActiveBindingsFor("net.shu_cream.eclipse.font.large");
    assertEquals(1, sequences.length);
    KeyStroke s = (KeyStroke)sequences[0].getTriggers()[0];
    System.out.println(s.format());
    assertEquals("Ctrl+Alt+;",sequences[0].format());
  }

ありがたいことにorg.eclipse.ui.keys.IBindingServiceにはコマンドのIDからアクティブなキーバインドを取得できるgetActiveBindingsFor(String)というAPIが用意されているんですね。これでキーバインドを取得して、ショートカットキーの文字列を比較すれば一応テストできます。*2

IBindingServiceクラスには他にBinding IBindingService#getPerfectMatch(TriggerSequence)というAPIがあり、BindingクラスからgetParametarizedCommand()を取得すると前述のコマンドなので、それを実行してあげると(Binding - Command - Handler)の一連の流れを実行することができます。

*1:他のプラットフォームだとどうなのかなど、詳しい情報をお探しの方はHelp - Eclipse Platformのkey - sequenceの辺りを見てください。

*2:マルチOSには未対応

2008-02-26

きっと第二回(仮)チキチキ日本ペアプログラミングの会 都元亭

行ってきたー。出鼻から道を間違えるというくじかれ具合だった上に帰りも逆の方向の電車に乗ろうとする具合の方向音痴っぷりでした。いつもながら都元さん(id:daisuke-m)のモテぶりはすごい。(男だらけだけどw)

今日はid:ykhr-kokkoさんとペアを組んでプラグインのテストを書いていたんですが、結局テスト一つままならなかったです。プラグインのテストをもっと簡単にやる方法はないのかな。という感じで、はてダエントリーを蓄積していきたいと思っています。

良書(Eclipseプラグイン開発 デザインパターン×テスト駆動開発 原著名:Contribute to Eclipse)ではJUnit作者のKent Beck氏とErick Gamma氏がEclipse PluginをTDDにより実装していくなんていう離れ業をやってのけているので、興味がある人は写経するといいですよ。

広大な領域のクラスを使って縦横無尽にテストを書いてコードを書くというスタイルを貫き通しています。またこの本ではEclipseの思想にも触れられます。原著名はContribute to Eclipseですから、Eclipseに貢献しようぜ!的なノリを肌で感じることができるでしょう。原著ではEclipse 2.1を対象に書かれていますが、日本語訳されるに際してEclipse3.0.1を対象にコードが書き直されています。Eclipse内で使われているデザインパターンの解説も載っている上、サポートサイトではサンプルコードが配布されているので、一通り写経し終えた後にサンプルコードを読み直すとかなり勉強になるでしょう。

ただ、この本を読んでもプラグインを作れるかというと、この本はそういう本ではないかもなと思います。プラグインを作ったことがある人(特にJDT周りリソースを読むとかで十分かも)が読むとなるほどな!という知恵が満載ですよ。

2008-02-25

第一回チキチキ日本ペアプログラミングの会java-ja支部

行ってきました。java-ja。初参加です。懇親会で自己紹介の時に今月のPlugin勉強会をつぶした張本人*1で、最近NetBeansRuby使ってSWTアプリを書いているkompiroです。どんだけMなんだよって言われましたが、楽しかった。java-jaはアウェイなのかホームなのかと聞かれてどっちなんだろうと小一時間考えましたが、そういう難しいことはよくわかんねー、と思いました。*2

珍しくじゃんけんに勝ち続けられたのでid:t-wadaさんとペアプロできました。せっかくなのでペアチェンジを知らせるイベントタイマーを作りたいと申し出たら快く引き受けてくださり、短い時間のなかあーだこーだやっていました。結果的に出来上がってきたものは、シンプルなクラスになりました。ペアプロは普段からやってますが、解法の分からないものを相談しあいながら作るのにいい方法だと思います。逆に明確な解法が分かっている場合は無理にペアを組まなくてもいいんじゃないかと思っています。解法が明確に分かっている場合は片方が常にドライバになってしまって、リズムに乗りにくくなります。そうなると一人でソースを組んでいるほうがリズムに乗りやすくなってしまうのです。確かにタイポなどのミスは減りますけれども。これはあくまで自分の所感です。タイポはなるだけ減らすべき!ならばずっとペアで作業でもいいと思います。

TDDも一つの解法であり、このやり方でなきゃだめって思うのは違うと思うのです。TDDは確かにいい方法です。が、引き出しの一つくらいにしておいたほうがバランスが取れると思います。「かなづちを持ったら何でも釘に見える」というのはよろしくないでしょう?何でもかんでもTDDをやろうというのは釘に見えるのと同じになってしまうんではないでしょうか。TDDはテストからコードを書くことでクラスのインターフェースを切り出していきます。が、UMLを使ってモデリングをしたい派からすると、その作業は冗長なんですよね…。たぶん今回id:t-wadaさんとのペアプロで出来上がったコードは、モデリングじゃ絶対作れない自信が僕にはありますが。モデリングはモデリングで、実装を意識しなさ過ぎると動かない設計になっちゃうじゃないですか。その辺りは当人の実力なのかもしれませんが。

プログラマの道具箱にはUMLもペアプロもTDDも入りますが、チームのメンバーによって使い分ける必要があるんじゃないでしょうか。要するにメンバーが気持ちよく使える道具を使っていこうぜ!なんす。

なんてかたくまとめをしてみましたが、僕自身結構ゆるゆるなんで、java-jaのみなさまよろしくです。後半ペアを組んだイヌビームさん、Ruby教えてくださってありがとう。yamashiroさん幹事お疲れです。id:yoshioriさんJAVAはモテっすね。*3

ところで蟹なし北海道で7000Overってないよ。すげー飲み食った。*4

*1勉強会で良く集まるメンバから同じ日にやるんだけどどうしようと聞いてみたら「もうjava-jaに申し込みましたよw」といわれたので、どうせ勉強会やるんだったらより面白そうな方へ集まろうと思って。

*2:なぜか懇親会でEclipsePlugin話ばっかしてた。

*3:最近はRubyもいいし、昔からPython萌えですけれども。PerlとかPHPは…。

*4:参考:JSUGのときは2700円とかだったw

2008-02-24

およ。TrayItemにメニューが表示されないよ。

SWTのコネタ。

  • MessageDialogを表示中はTrayItem上にMenuを表示できません。
  • Shellがopenされて下記のループに入っていないとTrayItem上にMenuを表示できません。
    shell.open();
    while(!shell.isDisposed()){
      if(!display.readAndDispatch()){
        display.sleep();
      }
    }

少なくともx86.gtk.linux上では。

どうでもいいことですが、上記のwhileループはいつもどうやって書いたら良いかすぐに忘れます。Snippetを登録しておくんですが、それもワークスペースを跨いだり、環境を跨いだりすると使えないし・・・。Snippetのネットワーク共有ができたら面白いんですが。

2008-02-23

プログラミング言語を身につける話

いやー、Rubyを本格的に触ってみたのはここ2,3日ですが、良いといわれる理由がなんとなく分かってきました。書けばすぐ動かせて、『お、動いた!』っていう喜びを感じられるのはやっぱりいいですね。

しらばくたった後で、読むときに変数なのか、メソッドなのか分からないのは自分としては問題ですが、書いているときの気持ちよさっていうのは実感しました。mainメソッド書かないでもいいというのも書き方さえ気をつけておけば、後で困らないので気持ちよく書けます。

今回Rubyを書くに当たって入門書は購入していないんですが、結構それでいい気がしています。入門書を読んでいても正直物足りないんです。もうガンガン動かしては試してみるって言うのがやっぱりいい。(最初に買ったRubyの本がRailsの本だったりしますが、結局中は読んでないw。次に買ったのがるびまの添削本だったりします。これも途中で止まってますw。)

動かしているとどうやったらいいのか分からないので、ググってみます。すると入門レベルであれば必ず誰かがすでに通った道を残してくれています。だから後へ続くことができるのです。

たぶんプログラミング言語を身につけるには、読んで書くのが一番いい。プログラミング言語を学ぶ時に日本語が入ってくると日本語がS/N比を下げてしまう。そんな気がするのです。

WidgetにListenerを登録するには

なんて書いてみたけれども、『Listenerを登録する』という概念がGlimmerには存在しません。どういうことかっていうと次のコードを見てみてください。

@show_button = button {
  text "表示"
  on_widget_selected {
    @practice.visible true            
  }
  on_focus_gained{
     puts "focus_gained"
  }
  on_focus_lost{
    puts "focus_lost"
  }
}

なんかイベントハンドラみたいに書けるんですけど!登録できるリスナの呼び出し先のメソッド名がそのままハンドラ名になってるようです。これでややこしいリスナクラスを覚えなくても色々ごにょごにょできる。っていうか、この呼び出し方法ってセンスがいいとおもう。すげーなー。

2008-02-22

Glimmer使ってアジャイルプラクティスを表示するランチャを作ってみた。

やばい。かわいいよ。Glimmer。かわいいよ。

と、かいてみたもののやっぱりSWTのくせを感じずにはいられない。Shellの大きさを指定してもその通りにならない。内部のCompositeによるみたい。GridLayoutなどには対応している模様なので、Shellに設定するテキストタイトルが長いような場合を除いてはいい感じだと思った。LLはお手軽なのがいいですね。

require File.dirname(__FILE__) + "/../src/swt"

class PracticeFortune
  def todays_practice
    practices = [
    '成果をあげるのが仕事',
    # ...中略
    'みんなに知らせる'
    ];
    number = rand(practices.size)
    return "No:" << number.to_s << " " << practices[number]
  end
  include_package 'org.eclipse.swt'
  include_package 'org.eclipse.swt.layout'
  
  include Glimmer

  def launch
    @shell = shell {
      composite {
        label { 
          text "本日のアジャイルプラクティス"
        }
        label { 
          text todays_practice 
        }
      }
    }
    @shell.open
  end

end

puts PracticeFortune.new.launch

layoutを指定したい場合は

composite {
  # この部分
  layout GridLayout.new(2,true)
  label { 
    text "本日のアジャイルプラクティス"
  }
  label { 
    text todays_practice 
  }
}

と言う感じで指定します。

2008-02-21

JRuby on Eclipse RCPに一歩近づくGlimmer絶賛開発中

InfoQ本家より、Rubyを使ってSWT/JFaceのGUIを書けるGlimmerというライブラリが絶賛開発中。Eclipse Foundationにも申請中のプロジェクトらしい。ちょっと振り返ってみたら、昨年12月に見つけたプロジェクトが順調に育っているものみたい。

hello_world.rbを転載しますね。

# Copyright (C) 2007-2008 Annas Al Maleh
# Licensed under the LGPL. See /COPYING.LGPL for more details.

require "java"
require File.dirname(__FILE__) + "/../src/swt"

class HelloWorld
  include_package 'org.eclipse.swt'
  include_package 'org.eclipse.swt.layout'

  include Glimmer

  def launch
    @shell = shell {
      text "SWT"
      composite {
        label { 
          text "Hello World!" 
        }
      }
    }
    @shell.open
  end
end

HelloWorld.new.launch

compositeとかをRuby DSLで書けるのが最大の特徴らしい。どうやってListenerを登録して行くのかが興味深い。せっかくなので、環境を整えてサンプルを動かしてみました。

  1. そもそもJRubyを落としていなかったので、配布サイトから最新版のJRuby1.0.3を落とし、解凍($JRUBY_HOMEとする)
  2. $JRUBY_HOME/binにパスを通す
  3. $JRUBY_HOME/lib以下にSWTのJarを入れる(もちろんフラグメントのJarも入れる)
  4. Glimmerは中でfacetsというライブラリを使っているので、rubygemsを使って取得した。コマンドはgem install facets
  5. Glimmerのサンプルフォルダへ移動して、jruby -rubygems hello_world.rbで動きました。

JFaceも動くんで、こんなビューも作れます。結構いい感じ。

f:id:kompiro:20080222002444p:image

正直Rubyが書けるというだけの人には、SWT特有のLayoutクラスに悩まされる気がします。なのでSWT自体が万人受けはしなさそうだと思ってます。(他のGUI Widgetを知らないので、この意見は微妙かもですね。)でもJavaでほげほげクラスのインスタンスを作ってはどーだこーだやるよりはかなりよさそうです。

no title

2008-02-20

アジャイルプラクティス

昨日ひょんなことから角谷さんからEffective Java継承した!角谷印付きである。やった、これはサイン本よりも貴重だ。ありがとうございますと言うわけなので取り上げさせていただきます。正直なところ、おいらにアジャイル語れと言われるのはなんだかきついと思ってたので書けなかっただけなんですけれども。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

なるほど、アジャイルプラクティスは志の高い開発者が身につけた偉大な習慣集なんだと思います。

僕の好きなプラクティスは

  • リズムに乗る
  • ユーザの声に耳を傾ける
  • ソリューションログをつける

EclipsePlugin勉強会を月1でやっているのは『リズム』に乗りたいから。月1でみんなの顔を見れるので、仲良くやれてるんじゃないかなと勝手に思っております。勉強会のペース自体は結構無理目なペースな感じがしているんです。でも勉強会発のXOOPSディストリビュータみたいに自分達で作ったプラグインをガシガシ発表するような場になったら面白いと思うんです。

『ユーザーの声に耳を傾ける』は開発者として必須ではないかと。誰のために作っているのかわからなくなります。

『ソリューションログをつける』なんて、このはてダの目的そのもの。

ところで最近twitterを始めたんですが、followerになってくださったChrisさんはプラクティスを表示するiGoogleガジェットを作られていました。結構いい感じです。

http://dev.chrisryu.com/2008/02/agile_practice_gadget.html

同じコンセプトでEclipse Pluginを作るつもり。開発中の自戒の意味を込めてあったらよさそうじゃないですか。

2008-02-19

プラグインのテストコードを書く(コマンド編:v3.3)

TDDをしたいと思っていてもどうしてもできないことってあるじゃないですか。Eclipse Pluginの開発なんて諸にそうなんですが、振る舞いをコードに落とし込めない時はどうしようもありません。例えばツールバーをポチッと押したらアクションがあるアクションが呼ばれてエディタフォントが大きくなるっていう一連を、コードに落とし込めなかったらTDDのしようがありません。ということでPlugin開発でTDDをするにはどうすればいいかを単発的にとりあげてみようという試み。今回はコマンド編。題材はKenichi Takahashi氏のFontSizeChanger。リポジトリ

https://eclipse-study.svn.sourceforge.net/svnroot/eclipse-study/EasyFontChanger/branches/TRY-Active-View/

です。勝手にテストプラグインを作りつつ、はてダにて取り上げようという作戦。

今回のお題はコマンド-ハンドラ間の実行(Command-Handler)。plugin.xmlに書くこの結びつきを実行できているかどうか確認できれば、後はメニューから呼ぶのもショートカットから呼ぶのもできそうじゃないですか。

plugin.xmlの実体はこんな感じ(必要なところ以外省略)

   <extension
         point="org.eclipse.ui.handlers">
      <handler
            class="net.shu_cream.eclipse.font.ToLargeHandler"
            commandId="net.shu_cream.eclipse.font.large">
      </handler>
   </extension>
   <extension
         point="org.eclipse.ui.commands">
      <command
            categoryId="net.shu-cream.eclipse.font.category1"
            id="net.shu_cream.eclipse.font.large"
            name="Large">
      </command>
   </extension>

commandのid "net.shu_cream.eclipse.font.large"が同じというのを見て確認ができるとおもいます。ここのid名が間違っていた場合、呼び出す事ができなくなるので、それをあらかじめ確かめたい。そこで書くのが次のコード

public class TestToLargeHandler {
	@Before
	public void テスト実行のその前に(){
		Command.DEBUG_COMMAND_EXECUTION = true;
	}
	@Test
	public void このクラスがハンドラサービスに登録されていますか() throws Exception{
		ICommandService commandService = (ICommandService) PlatformUI.getWorkbench().getService(ICommandService.class);
		assertNotNull(commandService);
		Command command = commandService.getCommand("net.shu_cream.eclipse.font.large");
		assertNotNull(command);
		command.executeWithChecks(null);
	}
}

Command.DEBUG_COMMAND_EXECUTIONをtrueにしておくと、どのコマンドが実行されたか確認する事ができます。

2008-02-18

distutilsの使い方Tips

Pythonのドキュメントを良く読んできたわけではないのですが(ぉぃ)、Webをぶらついていたら見つけました。別にPYTHONPATHが通っているパスであれば伝家の宝刀

setup.py install 

が使えるんですね。オプションで使える--homeなどを使えば指定した場所へのインストールが完了します。注意しなければならないのが、あらかじめインストールされる先のHOME/lib/pythonなどのフォルダは作成しておいて、PYTHONPATHに通しておく必要があります。これでbata版やらtrunkのpythonものを追いかやすくなりましたとさ。

Python モジュールの別の場所へのインストール方法

2008-02-17

リーン開発の本質

病床の身で時間があるので、読書。でもかみしめながらで進まず1冊。

  • なんでテストの自動化が重要かが再度認識できました。単純作業化としてのテストの自動化じゃだめで、技法として、思考力を上げるためのテストの自動化が重要。
  • テストの自動化は間違ったときにすぐ気づくことのできるポカヨケ
  • テストの目的は『欠陥の発見』ではない。『最初から正しく』行うためのポカヨケ。探索的テストとか、性能テストとかはまた別の話。
  • 待ち行列理論は人にも適用可能。負荷が80%以上かかると応答時間が下がってくる。90%以上の人にさらに負荷をかけちゃダメですよって言う理由はすごく納得。googleの20%ルールの理由付けにもしてるけど納得。
  • ポカヨケ重要

2008-02-16

Continuous Integrationって人間に置き換えると定期的に検診すること

CI(Continuous Integration)の価値ってなかなか伝わらないよね、だからなかなか工数削ってやろうという話にならないね、と先日リーダーと話になりました。で、不調の僕が改めて思ったことをつらつらと。で、思ったのがタイトルの通り。

人は定期的に検診を受ける事を義務付けられています。小さいころはそれこそ母子手帳に生まれる前からの記録もつけられつつ、学生時代は日々の成長を記録しつつ(『柱のきずは おととしの〜』なんてのもありますね。)、大人になったらなったで、定期健診を受けるようになっていると思います。人間ドック(にはまだ行ったことないですが。)は二日かけて体中を検診しますよね。こんな感じで生きていれば何らかの検診を定期的に受けるようになっているんじゃないでしょうか。体調に現れていない不調でも、すぐに見つけられることができれば治療しやすい、または対処しやすいからだと思います。

ソフトウェアは開発を続けていれば常に変化します。いい面では機能的な成長が達成されますが、悪い面では人よりも激しく不調を起こしながら変化します。ソフトウェアの変化は人間に比べたら遥かに速い。(そりゃ人間が何人もかかって作ってるんだから。←これもつっこまれそうですがそのまま残しておく)だから常に状態を監視できるようにしておく必要があるのではないでしょうか。そのためのCIです。

たぶん検診→CIのメタファの話はどこかに既に出典があると思ったんですが、ちょっと見つけられませんでした。ご存知の方教えてください。

2008-02-15

EclipseにはPluginという呼び方が合わなくなってきたんじゃなかろうか。

EclipseのMANIFEST.MFの設定項目にはEclipse-BuddyPolicyというのがあるんですが、このポリシー、最初はどういうものなのかさっぱり分からなかったんです。EclipseのHelpを見てみると、どうもPlugin同士がもつクラスローダーを融和させるイメージを持っているんですが、そもそもPluginごとにクラスローダーが作られている事はOSGiを知るまでさっぱり知りませんでした。というか、Pluginってそんなに独立性の高いものを指し示す呼び方じゃない気がするんですよ。既存にあるものを拡張できるのがPluginですが、既存にあるものすべてを通常の設定では利用できないんですから。

なんていうか、BuddyPolicyと言っているので、一つ一つをBuddyと呼んであげるのがいい気がするんですが、気のせいでしょうか。最近のEclipsePlatformはr-OSGiなって言う、リモートのOSGi Bundleも利用できるようにする素敵な機能がが開発中らしいので。

2008-02-14

タイムスリップするのでメモ。

僕自身がただいまウィルスにやられているようです。3回お休みケテーイなので軽くメモを残しておこう。

  • Platform.isRunnable()
  • BundleClassNameIterator

以上。

2008-02-13

Hudsonに一目惚れ

CIをするための環境を調査。昔はCruiseControlとか、Continuousとか使っていましたが、かねがね噂を聞いていたHudsonを動かしてみた。今日TracHudsonPluginを見て動かそうと思ったんですけれども。これすごいですね。何がすごいって

  • ダウンロードしなくてもJava Web Startを使ってちょちょっと試せちゃう。
  • ダウンロードしてもこんなコマンド一個で動く
java -jar hudson.war
  • ちょっと試すだけだったらAPを立てずにすむ。
  • ブラウザからほとんど全ての操作ができてしまう。
  • 特にバッチとかも不要
  • crontab互換の記法を使って定時バッチを動かす事ができる
  • master/slave機能もついている
  • Tracとの統合(他にもあります)
  • プロジェクト名/buildとかで、指定しているビルドスクリプトを実行できる

特にwarなのに-jar指定で動かそうっていう発想は僕にはなかったです。良く考えてみたらJava Web StartはEclipseもいけるんじゃないかと思ったけれども、100MB単位のサイズのアプリケーションだとダウンロードがつらそうです。

Antを拡張するためのライブラリをEclipse上のAntに追加するには

そういう拡張ポイントがあります。ビルドをするEclipseに補助プラグインとして導入しましょう。

補助プラグインのplugin.xmlにはこんな感じで記述します。

<extension point="org.eclipse.ant.core.extraClasspathEntries">
<extraClasspathEntry library="myExtraLibrary.jar"/>
</extension>

あとでどうやって拡張しているか確認したいのでソースを見よう。

2008-02-12

OSGiのうれしさを擬人化してみる

相変わらず体調はよろしくないので、軽めに。(でもタイトルは結構重い気が…。)

OSGiって何がうれしいか考えてみてるんですが、一つはその場にインストールされている「サービス」をトラッキングできることがうれしいんじゃないかと。ということで、こんな状況をあてはめてみた。

  • 飛行機に乗っている最中、急患が出てCAさんが客席に向かって「お医者さんいらっしゃいませんか?」と聞いてみた。

飛行機にお医者さんが乗っかっているかどうかはCAには分かりません。が、もし乗っていればお医者さんの医療が急患に施されます。もし乗っていなくても、後からお医者さんを飛行機に乗っている最中に追加し、応急処置を施すこともできます。(バーチャルな世界の話ですよ。現実には無理ですね。)

こういうことをOSGiは実現しています。サービスを利用する側はサービス提供側の実装を完全に知らなくても、そのVMにインストールされているBundleの中に同一のサービスを提供するものがあれば、そのサービスを利用することができます。もしサービスを提供するものがなければ、後からそのサービスを登録するBundleをインストールすることで、応急処置をすることもできます。

これがもしDIコンテナだったら、「飛行機にはお医者さんが乗っている」ことをXMLなりアノテーションなりで必ず記述する必要が出てきます。なんていうんでしょう。「飛行機を運行するためには必ずお医者さんが乗っていなければならない」という誓約書が必要みたいな。

VMとアプリケーションの間にOSGiをかます事で、こんな柔軟性が生まれます。DIコンテナがDIコンテナと呼ばれる前はIoCコンテナと呼ばれていましたが、OSGiを使うとより柔軟なIoCが可能になっています。そのあたりがOSGiのうれしさの一つかなと個人的には思うんですが、うまく伝えられたでしょうか。

2008-02-11

Eclipse 3.4 M5 リリース

なんだかとてもさむぢです。風をひきました。余裕ないので一言だけ。

パンくずなびきたー!

Not Found | The Eclipse Foundation

2008-02-10

ダイチャン転職おめでとう呑み

ということで、ダイチャンことid:daiske-mさんの転職祝いとして、昨日は朝まで飲んでました。集まったのはid:itengeneerさんと世界の矢野ことid:t_yanoさん。矢野さんとは初めてお会いしたんですが、非常に気さくな方でおもしろかったです。というか、僕はコンピューター以外の世界を最近話していない、というかうまく話せなくなっていることに若干ショックを受けました。(自分の中で)脱線しますが、たとえば僕は中国の三国志とか、春秋戦国とか、殷史とか、横山光輝の漫画が描いている時代が大好きなんですが、その辺好きな人って少なくないと思うんですが、語り合ったことってあんまりないんです。みんな孔明大好きですが、結局孔明も寿命には勝てなかったですし。(そう言ってしまうと、なんだかんだで一番持っていったのは司馬家だったりするのか。)策略家の末路ってあんまりいいもんじゃないっていうのを、横山漫画で学びました。

さて、話を戻して何で転職したの?という問いにダイチャンは、「それがやりたいことだったから。いつだって俺はやりたいことをしてきたよ。薬剤師になったのも、なりたくてなったんだし。自分がその立場にないっていうものって、本当はやりたいことじゃなかったことなんだよ。(こんぴろ訳)」っていう考え方はやっぱりかっこいい。僕もそうしてます。なんか納得してもらえなかったけれど。

世界の矢野さんもWicket-jaを立ち上げられたり、いろいろされているところがさすがです。人月なんてさっさと超えろって言う言葉を偽らずに行動されているのがかっこいい。

itengeneerさんは結構きっつい言葉で同僚をdisってましたが、なんだかんだで愛を感じました。親分的な。かっこいいすよ。「死ねばいいのに」なんていいまくってましたが、いろいろ気にしているからこその言葉だと感じました。さすがおとーさんぷろぐらま。

昨日の会で集まった方は、みな意志をもって生きている人たちだと感じました。意志を持っている人は強いです。意志を持っているとぶつかることだって増えるじゃないですか。でも、自分のやりたいことだから、貫けるじゃないですか。そういう意志って抱いていた方がきっと楽しく生きられると思ってます。

僕自身はあまり言葉として表現していませんが、「みなが意志をもって生きていけるように支援するソフトウェアを作りたい」という意志を抱いています。そんなに強くなれる人って多くないよと言われそうですが、ソフトウェアが提供できるサービスの本質って、人の「行動」をよりよく「変化」することじゃないかと思うんです。最近よく使っているiKnowは、「英語を身につけたい」という人を支援するサービスだし、mixiは人と人を結びつけるサービスです。googleはWeb上のあらゆるものを検索できるようにしたことで、人と知識を結びつけました。そんな感じに、人の行動を変化させてきたんだとふと思ったんですよ。だから、僕はみなが意志をもって生きていけるように支援するソフトウェアを作りたいなと。

周りが自分の意志で行動している人たちばかりで熱くなったのか、最後の事はあんまり表だって言ってこなかったことですが、触れてみました。(言っちゃった。)

targetのdepends属性はよく考えて使う

targetで指定できるdepends属性ですが、前提条件として実行しておきたいタスクを指定しておくためのものとしてよくつかわれていますよね。タスクをまとめて実行するのには便利と言えば便利ですが、antcallで一つ一つ指定しておいたほうが使いやすかったりします。実行するtargetはantの実行時に指定できるので、ビルドプロセスの途中から実行することもできます。しかし実行するtargetにdepends属性が指定されていると、結局途中まで実行された結果を捨てて、もう一度SCMからソースを取得したりとか、まどろっこしい事になることが多いのではないでしょうか。特にAntスクリプトを書いて、スクリプト自身をデバッグしているような状況ではフィードバックが遅くなるような状況は、ぜひとも避けたい。なので、depends属性で指定するくらいだったら、一つ一つtargetを指定して実行するような、テンプレートとして実行できるtargetを別途用意しておくといいです。

具体的に書くと、

<target name="all" depends="init,build,test,deploy">
</target>
<target name="init">
    プロジェクトの初期化処理...
</target>
<target name="build" depends="init">
    <echo message="buiild start"/>
    <javac ...>
     ...
</target>

じゃなくて、

<target name="all">
    <echo message="Project build start."/>
    <antcall target="init"/>
    <antcall target="build"/>
    <antcall target="test"/>
    <antcall target="deploy"/>
    <echo message="Project build end."/>
</target>
<target name="init">
    プロジェクトの初期化処理...
</target>
<target name="build">
    <echo message="buiild start"/>
    ビルド処理
    <javac ...>
     ...
</target>

こうやって書いてみてわかったんですが、antcallで呼び出す形にしておくと、間に全然別のタスクを挟むことができますね。たとえば途中経過としての時間出力をallターゲットにだけ埋め込んでおくとか…。まぁ、Webアプリケーション開発が全盛のこの時代、mavenを使う人のほうが多いだろうということを予想しつつもこんなエントリを書いてみました。こういうことって達人プログラマーにも書いてあった気がする。

2008-02-09

海の向こうではOSGiに風がふいている

DZoneでもOSGiZoneが新たに開設されました。昨年末にOSGiのpresentationがJavaPoli2007というところで行われましたが、それがきっかけで開設されました。http://osgi.dzone.com/

ただいまOSGiZoneのリーダーは暫定でSebastien Arbogastさんがなっていますが、この方はOSGiがオープンソースアプリケーションサーバーに早く搭載されないかなという記事を書かれていてちょっとおぉとか思いました。たしかにTomcat 7にSpring-DMと適当なOSGiフレームワークが乗っかったらライブラリの取り回しとか楽になりそうだなと。Towards a mainstream Open Source OSGi application server? - DZone Java

またJava7にOSGiを組み込むべきというロビー活動があったので、ぼくも参加。ロビー活動と言ってもSun Developper NetworkにRFEとしてvoteしようって言うだけです。

Bug Database


マイコミジャーナルでもno titleとかno title取り上げられています。以前取り上げましたが、no titleが製品としてリリースされたら海外での熱はさらにたかまるでしょう。ほしいなぁ。海外発送はないので、アメリカに行けたら買ってくるんだけれども。

えーっと、OSGiって何ってもうちょっと突っ込んだ話はねーのかよって思われた方。書かせていただいた記事もリンクをさらしておきますね。(Disられましたが。)いじってみると面白いですよ。

[ThinkIT] 第1回:Javaはまだまだこれからだ! (1/3)

[ThinkIT] 第2回:OSGi仕様が実装されたEquinoxを試す! (1/3)

[ThinkIT] 第3回:体験!モジュールの動的な追加と削除 (1/3)

[Think IT] 第4回:Bundleの連携の制御の仕組みを理解しよう! (1/3)

[Think IT] 第5回:Javaはどこへ向かうのか? (1/3)

2008-02-08

環境変数をまとめてみたいときに使用するタスク

Antを使っていると、設定している環境変数が正しいものかどうかを確認したくなるときがあります。そういう時は

<echoproperties/>

を使うといいです。らくちん。

複数のプロジェクトをまとめてsvn switchするには

プラグインとか、RCPを作成しているとプラグインごとにプロジェクトを作成するので、複数のプロジェクトをブランチにSwitchしたくなることってありますよね。知らなかったんですが、Subversiveはワーキングセットごとにsvn switchすることができます。なので、ワーキングセットを作っておいて、そこに該当のプロジェクトをまとめておけば簡単にswitchができるんです。switchしている間、時間はかかりますが、一つ一つswitchしないといけないと思い込んでいたので、だいぶ楽になりました。

2008-02-07

crossnote申し込んでみました!

先日no titleとしてニュースリリースが発表されたcrossnoteですが、今日職場でデモが行われました。crossnoteの開発元であるupdate itの代表の安中さんとは、Eclipse Plugin開発勉強会でお会いし、津々浦々あって今日のこういう機会が生まれました。勉強会で知り合えた方とこうやってつながっていくっていうのはいいですね。なんか

crossnoteは一言で言うとチームでのドキュメント編集するためのツールです。誰がどんな変更をしたのかの差分表示とか、履歴管理ができます。crossnote上で作成した図であれば、それも差分表示できます。すごいっしょ。他のツールで図の差分表示ができるツールをぼくは知りません。(ぼくの知見が狭いだけなのかもわかりませんが。)

crossnoteはニュースにもあったとおり、Eclpse RCPベースのツールです。ドキュメント編集部はGEFを使って作っているそうです。だから図の差分表示ができるのも納得できました。

で、自分も使ってみたいし、せっかくなので、Eclipse Plugin開発勉強会でOSSコミュニティ向け契約に申し込んでみました。2/12から利用ができるようになるとのことなので、楽しみに待っています。

http://www.updateit.co.jp/crossnote/index.shtml

2008-02-06

稼働中のEclipseのOSGiコンソールを見ることのできるビュー

全世界のEclipseプラグイン開発者が待ちに待っていたであろうプラグインがついに公開されました。というか、正直今までPDEに含まれていなかったのが不思議。

f:id:kompiro:20080206224049p:image

プラグイン開発をしていると、時たまプラグイン同士の依存性に悩まされることがあります。なんか良く分からないけれど、プラグインが起動しなくなっているって言う時は、まさに依存性に問題がある事が多いでしょう。依存性に問題があるかどうかを確認するには、これまではEclipseを"-console"オプションをつけて起動し、diagコマンドを使って問題を発見することが多かったと思います。が、このプラグインを使うと、各プラグインの状態を確認できるだけではなく、インストールも含め、OSGiコンソール上でできる主な操作を行うことができます。

Ganymedeへ向けてPlugin Spyやこのプラグインなど、プラグイン開発関係で有用なツールが出てきてますね。

no title

2008-02-05

猛者がいた

Jython 2.2 beta1でdocutils 0.3.9を動かす

http://machine.homeunix.org/archives/03-01-2007_03-31-2007.html#7027

世の中いるもんですね。まだ暗中模索森の中なので、このページをヒントにやり続けてみます。

2008-02-04

えーっと、

The next release of setuptools includes Jython trunk support!

ってSetuptoolsOnJython - JythonWikiにかかれているのだけれども、次のバージョンのsetuptoolsでJythonのtrunkがサポートされるって事ですよね。と言うことは、Jythonでsetuptoolsを使うにはsetuptools側の対応も必要って事ですね。とりあえずPYTHONPATHをdocutilsに通すだけではうまく動いてくれなかった。docutils on Jythonもは遠いなぁ。

2008-02-03

Eclipse 3.3以降のLanguage Packについて

MergeDocプロジェクトやPleiadesというEclipseのメニューを起動時に動的に日本語化をしている柏原さんのページに、Eclipseの日本語化の現状について書かれていました。添付されているPDFを見ると、なぜIBMがLNの提供をやめたのか、とか、BABELプロジェクトが生まれた背景などが書かれていました。IBMとしては350以上もEclipse関連の製品があるので、LNを作る事は作るのだけれども、コミュニティを育てるために提供はしないという態度はそうだよねと思いました。

http://d.hatena.ne.jp/cypher256/20080203/p3

2008-02-02

Buckminster Project

先日1月30日にBuckminsterプロジェクトが、EclipseのIncubatorプロジェクトから卒業し、Technorogy Toolsプロジェクトへ移行したそうです。それに伴い、Ganimedeリリース時にBuckminster Projectも正式リリースを目指すそうです。

ブログが見つかりません

Buckminsterプロジェクトはいろいろなコンポーネントビルドしたり、構成したり、デプロイを簡単にする事を実現するためのプロジェクトです。プロジェクトに新しいメンバーが入ってくると、そのアプリケーションを構築するための環境を整えることがありました。アプリケーションを構築するためのあるライブラリはこっちから取得して、このライブラリにはこのパッチを当てて・・・。といった一連の作業を簡単にするためのツールとしてAntMavenが広く使われています。これらのツールも素晴らしいのですが、横断して使うようにできるツールがBuckminsterです。AntやMaven以外のツールも、拡張ポイントを使うことでも使えるようにしているようです。また、ライブラリの取得にはPlugin(OSGi Bundle)だけでなく、Maven Repository形式もOKですし、HTTPFTPで配布されているものも取得できる作りになってます。

とこんな感じでwktkwktkしながら見てみたんですが、プロジェクトの設定が至極メンドクサソウデス。一つのプロジェクトでもざっと見てみた感じXMLを4,5個カスタマイズして書かなければならなさそうっていうだけで正直うんざりしました。また、今のところ自動でライブラリ依存性を解決するような機構は見当たりませんでした。標準でSubversionにも対応している点はすごくいいんですけれども。まぁ、ここ最近ビルドの自動化だ、テストの自動化だとやってきたので、ここでこういうツールがサクットこういう環境を作ってしまってたら悲しいなと思いながら見ていきます。

Archived Projects | The Eclipse Foundation

2008-02-01

Eclipse Pluginのテストを自動化するには(その10:JUnit4でも自動化できた)

とりあえずコンソール上からJUnit4でテストコードを書いたテストプラグインの実行がうまく行ったのでメモ。

  1. バグレポート報告のページに添付されている『Eclipse Test Framework code』の方のパッチをEclipse3.3のテストフレームワークへpatch applyをする。
  2. テストプラグインのJUnitの指定を下記のように変更する
Require-Bundle: org.junit4
             ↓
Require-Bundle: org.junit;bundle-version=4

要するに指定するシンボル名を統一してバージョンを指定しるってこと。これはなぜかというと、今回当てるパッチはテストプラグインで指定しているJUnitのバージョンを見て、利用するプラグインを切り替える仕組みを採用しているためです。