weighthttp
これが、先日ふれたサーバに使われているベンチ。
たしかに、apacheのテストではいまいちだったので、こっちで性能図ってみる。
http://www.iij.ad.jp/company/development/tech/activities/weighttp/
parseIntとvalueOfの違い
Integer.parseIntは、プリミティブ。Integer.valueOfは、インスタンスをそれぞれ返す。
混沌としてきた。
4月から仕事はじまりまして。まったくコードかけなかった。笑
いろいろ投げ捨てて、とりあえず、javaの並列を知りたいと言う事で、
web serverを書くことに。
現在のウェブサーバの潮流は二つあるらしい。一つは、マルチスレッドで受付を待つもの。そして、もう一つは、イベント通知のもの。
イベント通知は、昔でいう、poll/selectなんだけど、現在はC10K問題で、epollがカーネル内部に実装される(bsdだとkqueue)ことになり、実際、かなり昔にepollサーバを書いた事がある。
(epollは、ここがヒットした。http://alpha.mixi.co.jp/2007/10631/)
しかし、これでもマルチコアの恩恵は行かせないと言う事で、さらにHaskellでハンドリングをすることで、並列ライブラリの恩恵を活かすウェブサーバがあるとか、ないとか。
あえてjavaでやるのは、epollなんかが、どうやってラップされるのか知らないってこと。C言語はほんとにカーネルと密接に絡めるから、できないことはないと言っても過言ではないが、Javaはどうなんだろう?ってのが興味。(もちろん、JNI使う必要があれば、使う事になるが)
マルチスレッド型+epoll利用をあえてjavaで書く意味があるのかわからないが、とりあえず挑戦中。
CoffeescriptでHello World
わけあって、coffee scriptで開発しております。
登場当時から気になってはいたのですが、計らずしも使う事になってしまいました。
CoffeeScriptとは
JavaScriptを生成する為の上位言語です。
一般的なJava(コーヒー豆)とCoffee(抽出されたコーヒー飲料)の関係にあるかどうかは微妙ですが,そこは「うまいこと名前つけましたね」といってあげましょう。
CoffeeScriptは、JavaScriptの記述量を格段に減らすことができます。
なにはともあれ使ってみよう
セットアップは簡単。node.jsが入っていればnpmで最新版をとってこれる。
あとは、エディタ用のハイライトを(Emacsであればcoffee-mode.el)をインストールするくらいだろうか。
CoffeeScriptはあくまでJSを生成するための言語であるため、最初に流れをつかんでおく。
1. CoffeeScriptを記述。(test.coffeeとか)
2. CoffeeScriptをJSへ変換する。
ここは、コマンドラインから行う。 coffeeコマンドを使うだけ。
3. できたJavaScriptをhtmlから呼び出す。(で呼ぶだけ)
Hello Coffee
str = "Hello coffee" console.log str
これをJSへ変換する。CoffeeScriptでは、この作業をCompileと呼ぶ。
呼び出し方は次の通り。
$ coffee --compile test.coffee
これでJSが同じフォルダに生成されるので、これを覗いてみる。
// Generated by CoffeeScript 1.5.0 (function() { var str; str = "Hello coffee"; console.log(str); }).call(this);
これを動かせば、JSのデバッグコンソールにHello coffeeがでるだろう。しかし、もはや生成されたJSは見なくてもよい。昔は生成がイマイチだったため、結局デバッグは生成後のJSをみていたらしいが、いまのところ大きな不都合はない。(三項演算子くらい)
※ちなみに、現在の最新版は1.6xです。
単純な生成器だということを頭にいれておく
CoffeeScriptと付き合うのは、これを念頭に置いておく事に尽きる。これを忘れなければ大きな失敗はない。あたらしい言語ではない。JavaScriptを理解しなくてCoffeeScriptを使えれば良い!ということはない。(いまのところ)
次はbackbone.jsとCoffeeScriptとかについてかいてみたい。
StoryEditに戻る決心。
RuieはだいたいRPGらしく動作したので、とりあえずペンディング。
さて、Javaはおいといて、今日はStoryEditに戻ります。
DBの再設計と、そのラッパークラスの再設計でけっこうめんどくさい思いをしており、
そこでストップしておりました。
そして今日あることに気づく。もしやさんざん取りざたされてたDjangoってのがPythonのウェブアプリフレームワークじゃね?
というわけで、**はじめて**、Djangoに興味を持ちました。ようはPSGIとかRoR的なものでしょう。ORマッパまでついてて、なにも考えなくてもアプリできますよ。と。
しかし最初からこれらを使うほど、私は堕落してないし、急いでもおりません。
旧来の方法と比較してこその便利さ実感です。というわけでなんとしてもStoryEditをいまの状態でリリースする。githubにもあげました。
(Javaはエンドレスに脱線しそうなので一旦、StoryEdit片付ける)
追記;Djangoのウェブサイトが"Internal Server Error"。。。これはやっぱり使わなくていいよ、という神の思し召しなのだろう。
Slick2dでRPG風 Transition画面遷移
State Transition example from welovy on Vimeo.
動画とってみました。QuickTimeの画面録画って音はとれないのですね。まぁまだ著作権うんぬんがあやしいので、音はなくてヨシとしましょう。
今回はSlick2の画面遷移について。
StateBasedGame.enterState(int id, Transition start, Transition end)を用います。
上の動画のなかで、メインメニューから「はじめる」を選択して、マップ画面に遷移しますが、この際にフェードイン、フェードアウトがはいってます。ここがSlick2dのTransitionを使っている部分です。実際のコードは以下のとおり。簡単ですね♪
sbg.enterState(Ruie.MAPSTATE, new FadeOutTransition(Color.black, 1000), new FadeInTransition(Color.black, 1000));