2011年10月9日日曜日

playコマンドの動作について

playの勉強会をUstで参加?したため、ちょっと色々コードリーディングして、
動作を把握していこうかなぁと思います。

まずは、playコマンドを叩いて起動する部分について。

> ./play run myApplication
と実行したときの動作。


  1. playコマンド
    1. play_command、application_path、remain_argsを取得
  2. framework/pym/play/application.py
    1. application_pathからconf/application.conf、conf/routesの存在チェック。application.confのパース
  3. framework/pym/play/cmdloader.py
    1. commands配下にあるコマンドスクリプト一覧を取得する。
    2. コマンドスクリプトのCOMMANDからplay_commandと一致するスクリプトファイルを取得する。
    3. 一致した場合はスクリプトファイルのexecuteを実行する。
    4. runの場合:base.pyの中のrunを実行し、java_cmdでplay.jarを起動する引数を作成して、Popenで子プロセスを立ち上げる。



独自コマンド追加

commandsディレクトリの中にXXXX.py(適当なファイル名)を追加して、COMMANDSに独自コマンド名のリストを定義して、executeメソッドで起動をする。


※play run 実行時のjava起動コマンドライン引数


java
-javaagent:/Users/kazuhiro/work/play/play-1.2.3/framework/play-1.2.3.jar
-Dfile.encoding=utf-8
-Xdebug
-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n
-Dplay.debug=yes
-classpath [設定するパス]
-Dapplication.path=/Users/kazuhiro/work/play/play-1.2.3/myApplication
-Dplay.id=
play.server.Server

Playframework勉強会#2まとめ(スライド)

Playframework勉強会#2のスライド一覧みたいなのがなかったので、作ってみました。
逐次アップされたら更新していきます。




時間発表者タイトル



15:05~35@ikeike443「Play! の紹介」
15:35~16:05@garbagetown さん「playdocjaのこれまでとこれから」
16:10~16:40@genki_ さん「Play!で作る業務アプリケーション構成例」
16:40~17:10@hagikuratakeshi さん「Play! + GAEで作ったアプリをPlay! + Heroku で動かすとどうなるか」



発表者タイトル
@daiksy さん「大阪勉強会の続きのはなし」
@kara_d さん「Play FrameworkでWebSocketを使ってSVGのビジュアルチャットを作ってGDD open call html5に応募してみたけど落ちました」(仮)
@mitsuhiro さん「HerokuのPlay! 対応について」(仮)
@Masahito さん「5分で説明するPlay-Scala」
@tan_go238 さん「NettyはPlay!でどう使われてるのか的な話」(仮)
@ikeike443さん「Jenkins+Play!で気軽にCI」

「プロセッサを支える技術」読了

「プロセッサを支える技術」をついちょっと前から読み始めてました。
理由は複数個あるのだが、やはり関数プログラミングの集いの場で村主さんの発表で
ハード屋さんの努力があってのことなので、それをうまく使わなければならない。(そんな風な感じ)というのを聞いて全く以てその通りと思った。

あとは、一応組み込みの会社に入っているのだからハードのことも知らないとね。ってことで。(入社して全く組み込みをやったことないが。。。。)












さて、内容はプロセッサ関連について400ページほどあるので、ある程度詳しく書かれてています。
情報処理系の試験にでてきそうな話ですね。


  • RICS , CISCキャッシュ、スーパースカラ、Out of Order、メモリ、割り込み
  • x86アーキテクチャについてCore7iなどの命令セットやキャッシュについての動作
  •  仮想化のCPUの動作について
  • マルチプロセッサについて(キャッシュコヒーレンス、スヌープ等)
  • メモリについて(これは情報処理系のテストに似た内容)
  • GPGPUについて(CUDA,OpenCLなど)

といろいろ盛りだくさんの内容になっていました。
ハードウェアに興味がある方は読んでみてよいと思いますよ。

2011年10月6日木曜日

JUnit 4.10 リリースされました。

5日前ほどにJUnit 4.10 がリリースされたので簡単にリリースノートをまとめてみました。
一応Theoriesが拡張してGenericType対応になっていくような雰囲気。

RuleChain

  • RuleChainはTestRulesの順番の指定可能

TemporaryFolder
  • TemporaryFolder#newFolder(String... folderName)が再帰でフォルダ作成可能
  • TemporaryFolder#newFile()はランダムなファイル名を作成
  • TemporaryFolder#newFolder()はランダムなフォルダ名を作成
Theories
  • Theories runnerはGeneric Typeを持つTheoryパラメータを予測しない。
  • Theoriesがjunit-contribへ移動するまで、この修正は行われない。
  • 4.9.1はrunner classに必要な機構をいくつか追加した。Theories runnerを使う場合、メソッドをdeprecatedにした。(producesType())
  • JUnitがリリースされたCommon Public Licenseはソースリポジトリ内に含まれている。
Bug fixes
  • ビルドインルールの実装
    • TemporaryFolderはruleが失敗の場合、現在の作業ディレクトリにファイルを作成すべきではない。
    • TestWatcherとTestWatchmanはAssumptionViolatedExceptionsに対してfailedをコールすべきではない。
  • Javadocのバグ
    • Assersionドキュメンテーション
    • ClassRule
    • Parameterized
  • その他
    • RunAfterに不要なコード
    • Parameterizedテストクラスは@Categoryアノテーションを持つことができるはずです。
    • エラーカウントはjunit.tests.framework.TestListenerTestで初期化されるべき。
    • AssertionFailedErrorコンストラクタはnullメッセージでsuperをコールすべきではない。
    • no-static内部テストクラスの明確なエラーメッセージ
Minor changes
  • Description,Result,Failureがシリアル可能
  • FailOnTimeoutは再利用可能で、Ruleを再利用できる。
  • 理由を指定することができるErrorCollector.checkThatのオーバーロード


2011年9月24日土曜日

JUnitのRuleパッケージについて調査

最近JUnit 4.9がリリースされました。
ClassRule,TestRuleの変更がありました。
TestWatchmanがdeprecatedになってTestWatcherに置き換わるなど。

Ruleのパッケージについて、あまり知らなかったので、調べて、まとめてみました。


TestName
現在のテストメソッドの情報等を取得する。

public class SampleClassTest {
 @Rule
 public TestName name = new TestName();
 @Test
 public void test() {
  System.out.println(name.getMethodName());
  fail("Not yet implemented");
        }
}

ErrorCollector
読んで字の通り、例外を集めて保持するクラスです。例外をaddして、最後のverifyでaddされたエラーの個数などでチェックをかけます。

public class TestExternalResource {
 @Rule
 public ErrorCollector collector = new ErrorCollector() {
  protected void verify() throws Throwable {

   System.out.println("[ErrorCollector]");
   super.verify();
  };
 };

 @Test
 public void test() {
  collector.addError(new Throwable("first thing went wrong"));
  collector.addError(new Throwable("second thing went wrong"));
  int sample = 1;
  collector.checkThat(0, is(sample));

 }
}

ExpectedException
例外を制御する構文です。@Test(expected=NullPointerException.class)と同じような意味ですが、もうちょっと
拡張性を高くしたい場合に使えます。

public class TestExpectedException {
 @Rule
 public ExpectedException thrown = ExpectedException.none();

 @Test
 public void throwsNothing() {
  // no exception expected, none thrown: passes.
 }

 @Test
 public void throwsNullPointerException() {
  thrown.expect(NullPointerException.class);
  throw new NullPointerException();
 }

 @Test
 public void throwsNullPointerExceptionWithMessage() {
  Matcher[] allowedExceptionMatchers = {
    is(NullPointerException.class),
    is(IllegalArgumentException.class) };
  thrown.expect(anyOf(allowedExceptionMatchers));
  thrown.expectMessage("happened?");
  throw new NullPointerException("What happened?");
 }

}

TemporaryFolder
/tmp以下にファイルやディレクトリをおく場合に使えるクラスです。

public class TestTemporaryFolder {
 @Rule
 public TemporaryFolder folder = new TemporaryFolder();

 @Test
 public void test() throws IOException {
  File createFile = folder.newFile("myFile.txt");
  File createFolder = folder.newFolder("subFolder");
  System.out.println("Path:" + createFile.getAbsolutePath());
  System.out.println("Path:" + createFolder.getAbsolutePath());
 }

}


Timeout
メソッドのタイムアウト監視クラスです。メソッドの実行時間のチェック等に使います。

public class TestTimeout {
 @Rule
 public MethodRule globalTimeout = new Timeout(1000);

 @Test
 public void test() {
  for (;;)
   ;
 }

}


Verifier
テストが成功した後に、チェックする仕組みを入れたい場合このクラスを利用します。

public class TestVerifier {
 private ErrorLog error = new ErrorLog();

 @Rule
 public MethodRule verifier = new Verifier() {
  @Override
  public void verify() {
   System.out.println("[Verifier]");
   assertTrue(error.isEmpty());
  }
 };
 @Test
 public void test() {
  fail("Not yet implemented");
 }

 @Test
 public void test2() {
  error.add("sample");
 }
}



TestWatchman(TestWatcher)
テストケースの結果をテスト実施後すぐに確認したい場合に使えます。
public class TestTestWachman {
 private static String watchedLog;

 @Rule
 public MethodRule watchman = new TestWatchman() {
  @Override
  public void failed(Throwable e, FrameworkMethod method) {
   System.out.println("[watch]fail");
   watchedLog += method.getName() + " " + e.getClass().getSimpleName()
     + "\n";
  }

  @Override
  public void succeeded(FrameworkMethod method) {
   System.out.println("[watch]success");
   watchedLog += method.getName() + " " + "success!\n";
  }
 };

 @Test
 public void test() {
  fail("Not yet implemented");
 }

 @Test
 public void test2() {

 }

}


ExternalResource
外部リソースなどのアクセスをテスト前後で行いたい場合に利用します。だいたいDBにアクセスしたり、ファイルアクセスだったりすると思います。クラスをインスタンス化したら、そのクラスのテスト前後にExternalResourceのbefore,afterが実行されます。


public class SampleClassTest {
 @Rule
 public ExternalResource resource = new ExternalResource() {
  Server myServer = new Server();
  @Override
  protected void after() {
   // 外部リソースの接続解除
   System.out.println("[ExternalResrouce after]");
   myServer.disconnect();
  }

  @Override
  protected void before() throws Throwable {
   // 外部リソース接続
   System.out.println("[ExternalResrouce before]");
   myServer.connect();
  }
 };
 @Test
 public void test() {
        }
}


テストメソッドの実行前後に起動されるメソッドの順序を調べてみました。

ExternalResource Before
Before
After
【テストメソッド実行】
ErrorCollector
Verifier
TestWatchman
ExternalResource After



同じ機能っぽいじゃないか?と思うクラスがあるとは思いますが、ユースケース別に
使い分けると非常によいクラスになると思うので、うまく使い分けていきましょう。
次はhamcrestあたりかな。

2011年9月22日木曜日

EMFのOCLの実装

今時OCL?ということもあるんですが、OCLを使うケースがあるので、調査した結果を
まとめます。
EMFのモデルに対してOCLをかける仕組みです。
org.eclipse.ocl.ecoreプラグインを依存関係につけます。

  1. OCLのインスタンス生成
  2. OCLHelperを作成
  3. contextの設定
  4. 評価するオブジェクトとOCLでevaluateを実行
  5. 戻り値はObject型だが、Booleanが戻ってくるので、OCLの評価がtrue,falseかの判定する。



以下ソースコード
import org.eclipse.ocl.ecore.OCL;
import org.eclipse.ocl.ecore.OCL.Helper;
import org.eclipse.ocl.ecore.EcoreEnvironmentFactory

        OCL ocl = OCL.newInstance(EcoreEnvironmentFactory.INSTANCE);
        OCLHelper helper = ocl.createOCLHelper();
        EClass context = targetObject.eClass();
        helper.setContext(context);
        EObject object = targetObject;
        String query;
        query = "self.parameter > 100";//

        try {
            Object result = ocl.evaluate(object, helper.createQuery(query));
            logger.error("", result.getClass(), result.toString());
        } catch (ParserException e) {
            logger.error("", e);
        }


eclipseのOCL説明

今回はOCLのinvariantの判定をするケースでもう一つの方法としては、
evaluateではなくcheckメソッドを使う方法もあるらしいです。

あとは、defを使ってquery operationを定義することもできる。OCLの記述と同じように記述し、evaludateを実行すれば、同じように取得ができる。


  • OCL資料

2011年9月19日月曜日

「関数プログラミングの集い」に参加

2011/09/17日にIIJにて開催されたので、行ってきました。
資料のリンクはこちら。参加人数はPARTAKEでは170人くらい参加だったそうです。
びっくり。

OCaml,Haskellerばかりのイベント?だと思ったので、Scalaユーザは少ないかな?
と思ったんですが、使っている言語ランキングは2位でした。意外と使われているんですねぇ。

あと、結構本を書いている人とか、名前を知っている人とかが来ていたし、
懇親会で話をしていると知識が豊富だなぁ〜と思って、まだまだだと実感。
最後にコップ本争奪じゃんけん大会があったんですが、さっくり負けてしまいました。
ちゃんとamazonでクリックします。

こういう勉強会に参加すると自分はまだまだだなと再認識されますね。
日々精進です。

以下各発表を簡単に


関数プログラミングの道しるべ

関数プログラミングについて簡単と。
関数型プログラミングの定義が統一はされていないため、言語によって異なる。
「世界で最も誤解されているプログラミング言語」→JavaScript。Scheme,Lispに近い。


モナドについて

モナドの説明について聞いてみたが、いまいちぱっとわからない。doのシンタックスシュガーがあるのはわかったけど。

ITプランニングにおける関数プログラミング

OCaml, GAE + Scala(Lift) ,haEx + OCaml + Coq, F#(Windowサーバのため),Androidアプリ(Scala)
枯れていない言語の採用って客の信頼を得ていないと無理だよねぇ。
影響がないところから、関数型で成功していけば、自ずと。


COBOL meets Haskell ~ Haskellを用いたCOBOLのリバースエンジニアリングツールの開発事例

昔のデファクト言語COBOLの設計書を作る。
strafunski、sglr,Haskellを使って、COBOLのバイナリを解析し、ロジックを解析し、
変数名、関数名などを日本語に変換していく。
日本じゃまだHaskellerはいないため、インド人を引っぱってくる。


言語アップデート1


  • scala
    • 2.9についてざーっと説明
    • 並列コレクション
    • I/O プロセス処理(scala.sys.process)
    • scala Dynamic ( method_misingみたいなもの)
    • Unfilterd, BlueEyes
    • Scalaz
  • Clojure
    • Clojure1.3リリース
    • ClosureScript(node.jsも対応)
    • Clojure on Heroku
      • git push
    • Clojure ハッカソン
      • Tokyo.clj
  • Erlang
    • サーバプログラミングフレームワーク
    • 軽量プロセス
    • 末尾再帰でホットアップデート
    • エラー処理はlet it die
    • emacsが今のところいいエディタ
    • rebar,Dialyzer,Typer,Tider,QuickCheck,Erjang,riak
  • Haskell
    • GHC7.2x
    • Hackage 、Yesod vs Snap,enumerator,attoparsec, blaze-builder , text
  • F#
    • 型プロバイダ、クエリ式、シーケンス
    • 既知の外部リソース(SQLServer)に適切に型をつけてくれる。
    • Null許容型演算子の追加。追加の仕方が結構泥臭い。
    • 自動実装プロパティ
  • SML#
    • grassを作った人
    • 目的はMLを普通の言語にすること。実用的な言語
    • OS,Cライブラリと直接i連携、すべてネイティブ
    • SQLの統合、分割コンパイル、
    • Cの関数はimportすれば使える。コールバックも使える。
    • 関係、演算、クエリも第一級
    • 分割コンパイル
      • smi,smlをもとにコンパイル。バイナリはCと同じため、Cとリンクができる。
  • OCaml
    • OCaml ver.3.12.0
    • First Class Module
      • TypeSafe Plugin
    • シグネチャーの合成
    • 一般化代数的データ型
    • OCSIGENのサイト。
      • webframework oscigen server, js_ocaml
LT


  • Coq
    • Coq
    • 定理証明支援言語
    • 証明駆動開発
  • F#
    • F#はREPLのスクリプトファイルがある。

  • Paraiso計画
    • 宇宙物理のシミュレーション計算にHaskellが利用
    • 未だにFortranの遺産が沢山。