2014年10月05日

WebAPIの基礎1

ASP.NET WebAPIでは個々のAPIをコントローラを作ってリクエストを処理する。

基本的な実装は以下のようになりそうだ。
世間的には珍しい、VBソースで。


Imports System.Net
Imports System.Web.Http

<RoutePrefix("api/sample")> _
Public Class SampleController Inherits ApiController

<Route("{id}")> _
Public Function Gets(ByVal id As Integer) As IHttpActionResult
'なんらかの処理
Return Ok(id)
End Function

<Route("name/{id}")> _
Public Function GetNames(ByVal id As Integer) As IHttpActionResult
'なんらかの処理
Return Ok(id + 10)
End Function

End Class


うまく、REST設計ができれば、こんな風にならないかもしれないが、
単純に考えると、1つのコントローラーで似たようなURLで複数のGETメソッドを実装したりするだろう。
上記では、/api/sample/1と/api/sample/name/1。
その場合、属性ルーティングを使うとシンプルにできる。

使わないと、アクセス時に
「要求に一致する複数のアクションが見つかりました」というエラーになる。
同じI/Fのメソッドが存在すると、どちらにマッピングすればよいか分からないからだ。
コンパイル時に検出できると助かるんだけど、さすがにそこまでの機能はない。

個々のメソッドにRoute属性を付加して、URLの一部を明記しておくと、
リクエスト時に該当するメソッドが呼び出される動きになる。
さらに、RoutePrefix属性で共通部分を定義できる。

これだけ理解すれば、正常ケースのGETメソッドについては、あとは返す内容だけ。
…で、いいんですかね??

少し参考にしました。
http://www.atmarkit.co.jp/ait/articles/1312/16/news056.html
posted by Thoughter at 12:10| Comment(0) | TrackBack(0) | ASP.NET | このブログの読者になる | 更新情報をチェックする

2013年02月16日

FileSystemのrename

HadoopでHDFS上のファイルを移動したい場合、 Fileクラスのrenameを使う方法がある。 インタフェースはこうなっている。 public boolean rename(Path src, Path dst); ここで指定するパスにワイルドカードは使えないようだ。
rename(new Path("/src/*.txt"), new Path("/dest/");
/srcの拡張子txtのファイルを/destにリネームしそうな雰囲気はあるが、何も起こらない。 戻り値booleanもTrueなので、失敗したわけではなく、単に該当無しという感じだ。 てっとり早く動かすにはワイルドカードを使わないことだ。 /src配下の該当ファイル一覧をとってきて、各ファイルについてリネームすれば動く。 ファイル一覧は、listStatusのフィルターを拡張して正規表現や後方一致で絞り込めばいい。 hdfs -mvならワイルドカードを使えるんだが。 そう簡単にはいかないらしい。
posted by Thoughter at 12:15| Comment(0) | TrackBack(0) | Hadoop | このブログの読者になる | 更新情報をチェックする

2012年12月26日

HadoopOperationsのメモ10

※以下はHadoopOperationsを読んで自分なりに理解をしたことをかいていますので、 誤りを含んでいることがあります。もちろん、意図することではありません。。。。 本文内の英文はHadoopOperationsの抜粋です。 ●第4章 Namenode consideration この付近では、NameNodeやSecondaryNameNodeなど各ノードのハードウェアスペックはどの程度が良いのか、という内容が説明されている。 NameNodeのスペックはやはり搭載メモリのサイズがポイントだ。 管理するファイルのサイズというより、ファイルの数によってサイズを見積もる必要があるのは、 よく知られたことだと思う。
Remember that the metadata contains the filename, permissions, owner and group data,
list of blocks that make up each file, and current known location of each replica of 
each block
このあとに、ファイル名が長いほど、よりメモリが必要になるという記述も。 こんなに細かい管理をしているようだ。 おおまかには、100万ブロックの管理には1GBのメモリが必要、という計算になるらしい。 と言われても、一体どれだけなんだ?と思ってしまうが。。 どこかで読んだ、1ファイルあたり100バイトや150バイトくらいになるのだろうか。 他にも書きたいことはあるのだが、 あまり書くのも気が引けるので気になった点のみとした。(今更だが)
posted by Thoughter at 22:22| Comment(0) | TrackBack(0) | Hadoop | このブログの読者になる | 更新情報をチェックする

2012年12月22日

commonsのdigesterを使用してXMLロード

今更感は否めないが、Javaのapache commons-digesterを使用して、
XMLファイルの読み込みを作成してみた。(バージョンは1.8)

XMLを読み込むには読込ルールが必要で、
それをコーディングもしくは外部ファイル(XML)で定義することになる。

やはり、外部ファイルだろうということで、そちらを選択した。

書き方はいくつかのサイトで紹介されている。
例えば、、、
http://www.syboos.jp/java/doc/xml-to-java-object-by-digester.html
http://www.h7.dion.ne.jp/~s_wat/jakarta/digester.html

ということで、少し詰まったところを以下に残すことにする。

・特定のタグが来たら、タグのテキスト(Body)を引数にして指定のメソッドを呼ぶ





ここでは、"tag/item/value"という構成のタグが出たら、
"addItemValue"というメソッドを実行するようにしている。
詰まったのは、paramcountのところだ。
このattributeを付けないと、引数無しのメソッドが呼ばれてしまう。
paramcountだから引数の数かと思って1とすると、それも外れ。(確か、タグのattributeの1つめを引数にしようとする、、だったような)
正解の0を指定すると、タグのテキストを引数としてくれる。
なんだか直感的には分かりにくい。

・ルールファイルと対象のXMLファイルを読み込む

FileInputStream ruleIn= new FileInputStream(rulePath);
Digester digester = DigesterLoader.createDigester(new InputSource(ruleIn));

FileInputStream queryIn = new FileInputStream(queryPath);
Utsuwa info = (Utsuwa) digester.parse(queryIn);


いくつかのサイトで書かれていたDigesterオブジェクトを作る方法がdeprecatedになっていた。
"createDigester(new File("sampleRule.xml").toURL())"の"toURL()"が。
なんてことはないが、代わりに上のようにすれば動く。


なんといってもメリットは、XML読み込みがルールファイルのみで柔軟に変更できることだろう。
構造が多少変わっても、ルールを変えるだけで済む。

以上とします。
ラベル:java
posted by Thoughter at 17:47| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2012年12月19日

FileのlistFilesを敢えて試した結果

Javaで、あるディレクトリ直下にあるディレクトリ・ファイルの一覧を取得したい。

その時よく使われるのは、FileクラスのlistFilesだ。

listFilesには引数無しメソッドに加えて、オーバーロードが2つあって、
それぞれFileFilterとFilenameFilterを引数にとる。

もう既に様々なサイトで使用方法は示されているけれど、
敢えて全パターンを書いてみて、一番”格好良い”のはどれか見てみた。

条件としては以下だ。
・そのディレクトリには、ディレクトリとファイルが存在しているが、必要なのはファイルのみ。
・ファイルといってもjarファイルのみが欲しい。(拡張子が.jarで判断)
・メソッドの戻りはListで欲しい。nullになっちゃう配列は嫌!

そして、こんな感じのソースを書いた。(全力で)

public class ForTest {

private static final String PATH = "U:\\test";
private static final String TARGET_EXTENTION = "jar";

public static void main(String args[]){

for (int i =0 ; i<1000; i++){
filterPatternA();
filterPatternB();
filterPatternC();
}
}

private static void filterPatternA(){
File[] farr = new File(PATH).listFiles();
List flist = new ArrayList(farr.length);
for (File file : farr){
if (file.isFile() && file.getName().endsWith(TARGET_EXTENTION)){
flist.add(file);
}
}
}

private static void filterPatternB(){
File[] farr = new File(PATH).listFiles(new FileFilter() {
@Override
public boolean accept(File f) {
return f.isFile() && f.getName().endsWith(TARGET_EXTENTION);
}
});
List flist = Arrays.asList(farr);
}

private static void filterPatternC(){
File[] farr = new File(PATH).listFiles(new FilenameFilter() {

@Override
public boolean accept(File dir, String name) {
if (!new File(dir.getAbsolutePath() + "\\" + name).isFile()) return false;
return name.endsWith(TARGET_EXTENTION);
}

});
List flist = Arrays.asList(farr);
}

}



そして、約3400ファイルあるディレクトリ(U:\test)で実行。
ついでに実行時間も計測(まぁいろんなサイトで速度は変わらん!と言っているが)。
1000回ループさせた。

平均値をとると、A:115.29ミリ秒、B:117.168ミリ秒、C:120.384ミリ秒。
誤差もいいとこ。
やるだけ無駄。速度に優劣無しと判断する。


ところで、本題はどれが一番格好良いか。
Cはあまり好きじゃないなぁ。
FilenameFilterでファイルかどうかを判断するのはスマートじゃないね、きっと。

AかBか、ぱっと見で分かりやすいのはAではないだろうか。
一覧とって判断してるのね、と直感的に分かる。

だけど、やっぱり格好良いのは、Bに決定する(謎
If文無いし。(厳密には書き方なだけだが。。。)

いやいや、AのIf文のところをリファクタリングして、
分かりやすいメソッド名を付けるのが一番格好良いでしょ!という意見もありそう。。。

そういや、該当ファイル無しのときにnullで落ちるのは愛嬌で。。。
勢いで、null判断を入れるの忘れた。

そんじゃ、甲乙つけがたしで(笑
ラベル:java
posted by Thoughter at 22:37| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は180日以上新しい記事の投稿がないブログに表示されております。