ぼうメモ帳

2005-09-26

家計簿(15)

| 家計簿(15)を含むブックマーク

何気に開発は続いています。先週ぐらいからorz

前回は、関数型言語よろしくな高階関数ユーティリティクラスを作ったのですが、それがMVCモデルにしっくりこないということで、Containerクラス高階関数用メソッドを追加し、非破壊にContainerの内容を変更できるようにしました。

これで、家計簿オブジェクトを管理するContainerクラスは、filter、sort、map、foldを持ったことになり(若干、ニュアンスが異なるが)、超強力なコレクション管理を行えるようになります。さらに、Containerクラスは親子階層を保つことができ、ルートを変更すると、全ての子供へ変更が反映されるという無駄仕様を持っていますので、MVCのモデルにすると強力。

つぎは、このContainerクラスを実際にGUIに組み込んで、事実上、MとVの接続のためのコーディングを0にしたいなあという思惑です。

家計簿(16)

| 家計簿(16)を含むブックマーク

追記

家計簿オブジェクトは、データオブジェクトになる可能性が高く、種類や変更が頻繁に行われる可能性が高いということで、専用のコードジェネレータを作りました。

このコードジェネレータを通すと、Containerクラスが扱いやすいクラス構成になるため、手で書くよりも楽。

最近、RDBMSを使ったほうが速いんじゃないかと思う今日この頃。

トラックバック - http://d.hatena.ne.jp/susumu/20050926

2005-09-15

Java2D 文字列の描画

| Java2D 文字列の描画を含むブックマーク

文字列の描画が遅い。

いや、遅いわけではない。ただ、int配列を大量に生成しているために、頻繁にFullGCが発動する。そのために、アニメーションで文字列を扱うと、カクカク言い出す。もちろん、NewSizeを大きくとれば、そんなには気にならなくなるけど。

で、hprofした結果、StandardGriphVectorが怪しいとめぼしをつけた。

が、そこからどう対処したらいいのかは分からない。てか、なんで文字列を描画するだけで、あんなにも大きなint配列を生成するんだ!? 同じ文字列を連続的に描画したいんだけど、int配列の生成が一度だけに収まるようにするにはどうしたらいいんでしょうか。

MiyaMiya 2005/09/23 19:26 携帯が通じないけど、うちに一回電話ちょうだい。

トラックバック - http://d.hatena.ne.jp/susumu/20050915

2005-09-11 26歳になりましたorz

OOWeb

| OOWebを含むブックマーク

http://ooweb.sourceforge.net/

を使って少し遊んでた。

ちと、現状だと微妙マッピングまでは面白かった。けど、あまりにもできることが少ないうか、楽しむまでには至らない。

あと、HTTP.redirectがリダイレクトしてくれないんだけど、バグ

トラックバック - http://d.hatena.ne.jp/susumu/20050911

2005-09-10 エアコンが効かない このエントリーを含むブックマーク

暑いんですけど.

室温が30度って表示されてるのに,自動モードだと一切冷たい風がでないorz

風速を最大にすると,ぬるい空気が放出されるだけという罠.

死にそう.

フィルター掃除しても駄目だし.

扇風機回したほうが涼しい.

てか,6月に機種を変えたばかりのはずなのにorz

そもそも,室外機が動いていないw

すりゃ涼しくならないよw

追伸

強制ポンプダウンとかいうやつをやると,室外機が回るということが発覚.

いいのかどうかはしらんが,暑いよりはマシ.

追伸2

どうやら,試運転ボタンでよいらしい.

いま,サポートセンターに電話したら,点検修理コースだって.

あ〜 まあ,寮マネに言えば,そっちでやってくれるだろうから,いいんだけど,それまでの時間を試運転に頼らないといけないのか!? てか,試運転だと寒い.

トラックバック - http://d.hatena.ne.jp/susumu/20050910

2005-09-04

ミルク

| ミルクを含むブックマーク

掲示板システムが動作するように機能を追加する.まあ,簡易サーバ的な機能群を繋げるだけで掲示板が作れるよ,みたいなものを作ってみた.が,設定ファイル書くのめんどくせー.これは,早々にGUIで配線できるようにしないと駄目だと思った今日この頃です.

さて,掲示板を作るにあたり感じたことを羅列する.

  1. read/writeメソッドは必要悪だったかも
  2. マルチスレッドで動かさないと駄目な部分がある

read/writeメソッドは必要悪だったかも

配線だけで機能を実現する場合,明らかにプログラムとして記述したほうがスマートに表現できるようなコントロールフローも,データフロー形式へと変換しなければならなくなり,苦痛になる.

たとえば,現状では処理の途中でとあるサービスAを利用するためには,一度メソッドを抜けて,サービスAへデータを渡し,その結果を再び別のメソッドで受けなければならなくなる.これだと,本来ひとつのメソッドとして定義したほうが見通しがよくなるにもかかわらず,サービスAを使おうとしたがばかりに,メソッドが分断されてしまうことになる.

これに対して,read/writeメソッドがあれば,単一メソッド内で擬似的にサービスAのメソッドを呼び出すことができるため,メソッド分割という悲劇は発生しない.悲しいことに,read/writeは必要悪だったのだ.

しかし,read/writeはダサすぎる.そもそも,誰がread/writeを提供するのかを真剣に検討しなければならなくなる.失敗すると,旧バージョンのDefaultFunctionalModuleのようなクラスが出現してしまい,POJOが破られてしまう.だからといって,プログラム内でサービスインスタンスを直接使用してしまうと,サービスを変更するのが大変になる.

そこで,考えました.

DIを使えば問題解決.あとは,DIをGUIでどのように表現するかが問題だ.

マルチスレッドで動かさないと駄目な部分がある

当たり前だよね.最低限,入力用スレッドは必要だったよorz

httpサーバ機能を書いてて思った.

当面の課題

  1. DIでの依存関係のGUIによる編集と,データフロー依存関係のGUIによる編集が,シームレスに行えるGUIを考える
  2. マルチスレッドを制御下に置くための機能をコンテナに追加する

マシンが欲しい

マシンが欲しいを含むブックマーク

ノートPCがイカレもーどに突入してる.新しいマシンが欲しい.

要求スペックは,Javaがひたすらに高速に動作することかなあ.そんなマシンが存在するかは別にして,欲しい...

明日,夏休みとってあるから,買いに行くかあ.問題は,自作するのは面倒ってことぐらいか.

でも,マックも欲しい... アホだな.

トラックバック - http://d.hatena.ne.jp/susumu/20050904

2005-09-03

ミルク

| ミルクを含むブックマーク

グラフシミュレータの名前を改めて,「ミルク」というよく分からない名前で,プログラム名称で開発を行ってしまった...まあ,名前に深い意味はない.ただ,なんとなくだ.

最新版のグラフシミュレータは,軽量データフロー処理コンテナ(なんだそりゃ)になる予定.いまは,プロトタイプを作成していて,技術的な問題点を明らかにしている最中.

バージョンの反省を活かし,新バージョンでは,ユーザが作成するのは次の2種類のファイルになる予定.

  1. 処理内容を記述する設定ファイル
  2. 実際の処理を行うJavaファイル

設定ファイル

設定ファイルは,処理の流れを記述します.具体的には,次のような記述になります.


<service>
  <processes>
    <class name="jp.ifdef.myanya.milk.sample.StdIn" method="eval" in="" out="java.lang.String" />
    <class name="jp.ifdef.myanya.milk.sample.StdOut" method="eval" in="java.lang.String" out="" />
    <class name="jp.ifdef.myanya.milk.sample.ProcessA" method="eval" in="java.lang.String" out="java.lang.String,java.lang.String" />
    <class name="jp.ifdef.myanya.milk.sample.ProcessB" method="eval" in="java.lang.String,java.lang.String" out="java.lang.String" />
  </processes>
  <channels>
    <channel in="0.0" out="2.0" />
    <channel in="2.0" out="3.0" />
    <channel in="2.1" out="3.1" />
    <channel in="3.0" out="1.0" />
  </channels>
</service>

上記の記述における処理の流れは,こんな感じ.

  1. 標準入力から文字列を行単位で受け取ります.(jp.ifdef.myanya.milk.sample.StdIn)
  2. 文字列を,小文字変換,大文字変換し,二つの新しい文字列を作ります.(jp.ifdef.myanya.milk.sample.ProcessA)
  3. 二つの文字列を,で結合します.(jp.ifdef.myanya.milk.sample.ProcessB)
  4. 結合した文字列を,標準出力に表示します.(jp.ifdef.myanya.milk.sample.StdOut)

Java記述

それぞれ4つのJava記述は次のような感じ.

StdIn
package jp.ifdef.myanya.milk.sample;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
public class StdIn {
  private BufferedReader input;
  private boolean finished;
  public StdIn(){
    input = new BufferedReader( new InputStreamReader(System.in) );
    finished = false;
  }
  public boolean eval( String[] out ) {
    try {
      out[0] = input.readLine();
      if( out[0] == null ) finished = true;
    }catch( IOException e ){
      finished = true;
    }
    return !finished;
  }	
}

標準入力から文字列を受け取るJavaファイルです.

ProcessA
package jp.ifdef.myanya.milk.sample;

public class ProcessA {
  public boolean eval( String in, String out0, String out1 ) {
    out0[0] = in.toLowerCase();
    out1[0] = in.toUpperCase();
    return true;
  }
}

入力された文字列を,大文字,小文字へと変換します.

ProcessB
package jp.ifdef.myanya.milk.sample;
public class ProcessB {
  public boolean eval( String in0, String in1, String[] out ) {
    out[0] = in0 + " : " + in1;
    return true;
  }
}

二つの文字列を結合します.

StdOut
package jp.ifdef.myanya.milk.sample;
import java.io.BufferedWriter;
import java.io.IOException;
import java.io.OutputStreamWriter;
public class StdOut {
  private BufferedWriter output;
  public StdOut(){
    output = new BufferedWriter( new OutputStreamWriter(System.out) );
  }
  public boolean eval( String in ) {
    try {
      output.write( in.toString() );
      output.newLine();
      output.flush();
    }catch( IOException e ){}
    return true;
  }
}

入力された文字列を,標準出力へと出力します.

実行結果

>>aaaa
>>bbbb
>>dddd
aaaa : AAAA
>>cccc
bbbb : BBBB
>>eeee
dddd : DDDD
>>ffff
cccc : CCCC
>>gggg
eeee : EEEE
>>hhhh
ffff : FFFF
>>[Ctrl+Z]
gggg : GGGG
hhhh : HHHH

一応,動いてますよ.

まとめ

見ていただければ分かるように,前グラフシミュレータでの問題点はほとんど解決されています.

  1. 不必要なコンストラクタはありません.
  2. 入出力関数でのポート指定もありません.
  3. 入出力データは,文字列に限らず何でもOKです.
  4. 無駄なtry{}catch{}もありません.(入出力時に発生するIOExceptionなどは,仕方がない)
  5. InterruptedExceptionもありません.(スレッド使ってないし)
  6. ステートマシンの分かりづらさ... これは今後の課題です.
  7. DefaultFunctionalModule...なんですか,それは.

とにかく,POJOっぽくJavaコードを書いて,設定ファイルに組み込んでしまえば,勝手に動いて,勝手に終了します.

いまのところは,こんな感じ.

追記

グラフシミュレータという名前を止めるのは,実は,大学院時代の研究をいまだに引きずっていると思われたくないってのが一番だったりして.

お手軽にフィルタ処理とかを仕掛けられる個人用アプリケーションコンテナが欲しいだけなんよね.本当なら,JBIとかに対応しているアプリケーションサーバとかを立ち上げて遊べばよいのだけど,あれは重厚すぎる.非力なノートPC上で常時立ち上げていたくないし.

で,面白そうだから作ってしまえと,かっつり作ってみたってわけ.まあ,半日で作ったものだから,物自体はあまりいい出来ではないけど,ガワは悪くないかなあと.

トラックバック - http://d.hatena.ne.jp/susumu/20050903

2005-09-02

NIOとFileOutputStream

| NIOとFileOutputStreamを含むブックマーク

2時間ぐらいかけてマイクロベンチマークを計ってたんだけど,データ追記だけを行うなら,あんまり性能が変わらなかった... ???

トラックバック - http://d.hatena.ne.jp/susumu/20050902
272607