[Linux] JMX/REST変換

TomcatのManagerにもJMXProxyがあるのでそれで良いような気はしますが、こんなのもあるようです。

via kwout

ダウンロードからは何も取れないですが、ソースのところをくだるとありそう。

[Life] ScalaでSolrj!

下のソースで、以下条件下にて、
　・Solr(v1.4-dev/今のtrunk)のサーバ相手に
　・Solr(v1.3)のsolrjライブラリで
実行すれば、ABROADのスポット情報1件をインターネットから取得してうまく日本語も投入してくれることを確認しました。

なぜv1.4のsolrjを組み込むとうまく動かないのか。。(補足:SOLR-973にタイムリーにはまっていたようで、今updateしたらサーバもsolrjもv1.4で正常動作しました!)

// >\scala-2.7.3.fin\bin\scalac -cp c:\apache-solr-1.3.0\dist\solrj-lib\commons-httpclient-3.1.jar;c:\apache-solr-1.3.0\dist\apache-solr-solrj-1.3.0.jar;c:\apache-solr-1.3.0\dist\apache-solr-core-1.3.0.jar;c:\apache-solr-1.3.0\dist\apache-solr-common-1.3.0.jar getAB.scala
// >\scala-2.7.3.fin\bin\scala -cp .;c:\apache-solr-1.3.0\dist\solrj-lib\commons-httpclient-3.1.jar;c:\apache-solr-1.3.0\dist\apache-solr-solrj-1.3.0.jar;c:\apache-solr-1.3.0\dist\apache-solr-core-1.3.0.jar;c:\apache-solr-1.3.0\dist\apache-solr-common-1.3.0.jar;c:\apache-solr-1.3.0\dist\solrj-lib\commons-logging-1.0.4.jar;c:\apache-solr-1.3.0\dist\solrj-lib\commons-codec-1.3.jar getAB

import java.util.ArrayList;
import java.util.Collection;

import scala.xml.parsing.ConstructingParser;
import scala.io.Source;
import scala.xml.PrettyPrinter;

import org.apache.solr.client.solrj.SolrServer;
import org.apache.solr.client.solrj.SolrServerException;
import org.apache.solr.client.solrj.impl.CommonsHttpSolrServer;
import org.apache.solr.common.SolrInputDocument;

object getAB {
  def main(args : Array[String]) {

 var solr = new CommonsHttpSolrServer("http://localhost:8983/solr");
    val url = "http://webservice.recruit.co.jp/ab-road/spot/v1/?key=xxx4e359bbbbe6f4&spot=000921";

    val data = Source.fromURL(url,"UTF-8");
    val elem = ConstructingParser.fromSource(data,true).document().docElem;

 var tmp1:String = (elem\"spot"\"description").text;
 //var tmp1:String = new PrettyPrinter(80 /*width*/, 2 /*indent*/).format(elem);
 //String変数(tmp1)から(UTF8エンコードな)バイトストリームで取り出し(そこから)UTF8のStringを作る
 var tmp2:String = new String(tmp1.getBytes("UTF-8"),"UTF-8");
 var tmp3:String = new String(tmp2.getBytes("MS932"),"MS932");

 //System.out.println( "ORG:\n"+tmp1 );
 System.out.println( "UTF8:\n"+tmp2 );
 System.out.println( "SJIS:\n"+tmp3 );

 var doc1 :SolrInputDocument = new SolrInputDocument();
 doc1.addField("id", "id1", 1.0f);
 doc1.addField("name", "doc1", 1.0f);
 doc1.addField("price", 10);

 var doc2 :SolrInputDocument = new SolrInputDocument();
 doc2.addField("id", "id2", 1.0f);
 doc2.addField("name", "doc2", 1.0f);
 doc2.addField("price", 20);
 doc2.addField("desc_t", tmp2);

 var docs :Collection[SolrInputDocument] = new ArrayList[SolrInputDocument]();
 docs.add(doc1);
 docs.add(doc2);

 solr.add(docs);
 solr.commit();
  }
}

お恥ずかしくも、Scalaっぽくはまったく無い書きっぷりですが、これでもJavaよりはだいぶ記述量が少ない気がします。

追伸：
　リクルートwebAPIを使うときのキーは、(ソースには)ダミーを入れています。

[Life] ScalaでJSP!

ScalaのXMLサポートを実装した"Burak Emir"さんの書かれた"ScalaでJSP(@Tomcat)"(改題)を参考に。ソースにはantのbuildが付いているので、これを使うと楽に準備できる。私は、

tomcat.home = D:\\apache-tomcat-5.5.27
servlet-api.jar = ${tomcat.home}/common/lib/servlet-api.jar

scala.home = D:\\scala-2.7.2.final
scala-library.jar = ${scala.home}/lib/scala-library.jar
scala-compiler.jar = ${scala.home}/lib/scala-compiler.jar

として実行しました。なお、以下ライブラリは「1フォルダにまるっと集めて、そこにCLASSPATH通してantしてね」とあったのでその通りに。

　・fjbg.jar(これは何?→何故か入っていなかったのでダウンロード)
　・tools.jar(JDKの中にあるライブラリ)
　・scala.jar(不明→scala-compiler.jarをコピーした)

結構すんなり。ScalaでウェブといえばWebFlavorやliftまで行ってしまう感がありましたが、これならお手軽ですね。

[Linux] EC2の管理ツール

メモっていたつもりが、書いていなかったので今更ながら。

RightScaleでは、動的にサーバ台数を増やしてゆく仕組み(RightScriptというマクロ的なもので実現する様子)を提供。
そのOSSとしてScalarというのが公開(元は商用)されているので、こっちをカスタマイズするのとどっちが便利か。

でもどちらにせよ"遠い向こうでインスタンスを上げる"というのが普通な世界になってきましたね。

[Java] commons-fileuploadで受け取る

curlを使って、apacheのcommon-uploadで受信できる形で送信する方法。

D:\work\curl-7.16.2>curl -F "name=@test.xml" http://192.168.11.150:20050/uploader

nameのところは何でもよい(参考)。Windows版のcurlはここからダウンロードできます。

[Solr] wgetでPOSTする

以前Solrにデータ投入をする際にはcurlを使っていた(本家でもそうしていた)。
が、これは普通にwgetでも出来るんですね。

wget -q -O - --header "Content-type:text/xml; charset=utf-8" --post-file="/var/tmp/test.xml" http://localhost:20050/apache-solr-1.3.0/update

curlって、いっても標準では入っていない環境も多いので(参考ページ)。

[GoogleMap] マイマップとGoogleMapAPIと

GoogleMapのマイマップ機能はとても使いやすく、ちょろっとしたイベントの地図を作るのにベスト。だけれど、中にルート案内と作者(のマイマップへのリンク)が表示されてしまうのが玉に傷か。
これが嫌なときは、一度rss(georss/マイマップのツールバー、"GoogleEarthで表示"の左隣にある)を経由して、それをAPIで使えばよい、、のだけど、そうするとせっかく変えたアイコンが、全て同じ青いピンのに変えられてしまう様子(でもこれは仕様っぽい)。
うーん。やっぱりキチンと自前ですしょうか。

[MT] カスタムフィールド

MovableType4.1から入ったカスタムフィールドは、エクスポート機能では取り出せない様子。DBのmt_entryテーブルからとろうとしたのだが、バイナリ列で連結されており。。

ただ、入力値は普通に入っているので、Perlなどで丸呑みし、無理やり置き換えは可能。
手動で投入したときは(mt_entry_idの)シーケンス上げを忘れずに。

[Scala] Twitterの移行について

ずいぶん前の話題だが、TwitterのバックヤードScala化に関する記事の要点整理をしてみた。

＞＞前提

Twitterは、フロントはRailsに依存しており、逆にOffload観点から、キャッシュの失効処理等に、キューイングの仕組みを使った非同期処理が多数あり、それだけデーモンアプリが必要となるシステム構成。

＞＞なぜ移行？(システム的理由)

RubyはGreenThreadでカーネルスレッドを使うことはできず、プロセッサに依存してしまい、マルチコア環境での性能が出ない。これに対処するため複数プロセスを上げる方向に行くのだが、そうなるとメモリが大量に必要となり、さらにRubyのガベコレ性能が(Javaのそれに比べて)悪いこともあり、限界を感じていた。

(これに対し)JVMは、スクリプト言語が苦手とする長時間動かし続けるデーモンアプリを書く環境として適切。

また、動的型付けにより必要となる「型確認」の計算量が莫大になっていたという問題もあった。たとえば障害復旧時の処理時間が長くなりすぎていた。

JRubyへの移行も考えたが、オリジナルレベルのパフォーマンスは出ないこと、またそもそもRailsが動かなかったことから不採用とした。ただし将来的に再考の余地はあると考えている。

パフォーマンスという観点では、mutableとimmutableに注意すること。JITコンパイラはimmutableなオブジェクト(状態変化がない≒必然的にスレッドセーフとなる)であれば、最適化してゆくことができる。

＞＞なぜ移行？(その他の理由)

これまでのエンタープライズな職場を去ったあと、楽しく書いてゆきたい(表現してゆきたい)という理由から、(書いていてつまらない言語(C++など)を卒業し)Ruby等の高級言語に転向するプログラマをたくさん見てきた。

＞＞移行してどうだったか

とても上手くいった(性能向上及び動作安定化の観点から)。

静的型付けは、(Rubyでもわざわざ型宣言を使っていた位だから)まったく手間ではなかった。

actor部分とハイスケーラビリティを確保するところでいくつか問題が出たが、致命的なものはまったく無かった(良い意味で想定外)。

actorでの並列処理の記述はクライアントからの接続を受ける部分などを中心に極めて有効であった。

(中を再考している過程で)逆にactorまでは必要とせず、逆にthreadのほうが適している場合もあることが分かった。そしてこのときでも、(actorを)threadに書き戻すことは置換するレベルでありとても簡単だった(書き換えでいうと、普通にlockすればいいだけという場合も)。

いくつかパフォーマンス観点からJavaのクラスを直接利用する場面があったが、このようなことができることもScalaの利点だ。

＞＞切り替えで気をつけることは

関数型という考え方になれること(メンタリティ)。ただしこれは使っているうちに慣れてくる部分が大きい。その意味でもすぐにビジネスが絡むシステムに使うのではなくスタートアップで利用してゆくべき。

(型やその中身ベースでの)パターンマッチを使いこなせることは、効率的記述を行うためにとても重要だ。

IDEがモノによっては(Scalaの)サポートが完全ではないため注意が必要。TwitterではIntelliJとEmacsのそれを使っている。

インタプリタではなくcompile-deployが必要になることも、(慣れの問題かもしれないが)いらいらさせる原因となりうる。この点はProjectごとにケアが必要だとはいえ、JavaRebelを使えば解決できる。

＞＞その他

Scalaを選択する決断をするまでには煩悶してきた。でも(Rubyを使ってきた我々が)C++などの中級言語に移行することは、とても大きなリスクを負うことになり、かつ困難を伴うと判断した。

2009年度内には、メインどころのトラフィックを稼いでいるAPIをScalaベースに切り替える予定。