2011年09月15日

jcweb 0.0.1

前からWebアプリのフレームワークを開発中と言っておりましたが、
Apache Wicket 1.5もリリースされたことに触発され、
まだまだ公開できるような代物でもないのですが、
jcwebを一時的に公開してみようかと思い立ちました。

こちら

明らかに不具合が多いので、研究程度にしか使えない
しかも速度チューニングもしていないので遅いです。
それでも興味があれば、お試しにどうぞ。
よって、使い方とかはあえて載せません。
自力でわかる方がまずはご利用いただければと思います。
これを使ったことによって何かしらの損害があったとしても、私としては何もいたしませんので、それを了承の上でダウンロードください。

ちなみにWicketみたいにWicket用のIDを埋め込むとか、HTMLにELで値を埋め込むとか、そういうことはしません。HTMLのIDをそのままJava上で利用できます。
posted by Kiruahさん at 19:14| Comment(0) | TrackBack(0) | アナウンス

2011年09月13日

kommons-lib 0.8の公開

私がプログラムを作成する上でよく使うライブラリをまとめたkommons-lib 0.8を公開します。
言語はJavaです。ライセンスはApache License 2.0です。

本当に未だドキュメントやテストは手付かずです。ごめんなさい。
自分でどうにかこうにかできる方のみご利用ください。

ダウンロードはこちらから。

主な修正点
・ExcelReaderの不具合修正
・teterの実装を開始時点のものをコミット(当然未テスト)

Javadocはこちらから。
posted by Kiruahさん at 23:39| Comment(0) | TrackBack(0) | アナウンス

2011年08月28日

kommons-lib 0.5の公開

私がプログラムを作成する上でよく使うライブラリをまとめたkommons-lib 0.5を公開します。
言語はJavaです。ライセンスはApache License 2.0です。

本当に未だドキュメントやテストは手付かずです。ごめんなさい。
自分でどうにかこうにかできる方のみご利用ください。

ダウンロードはこちらから。

主な修正点
・一部バグフィックス
・io系機能の追加
・ちょっとjavadocを書いた

ちなみにInquirerは、getter系を用意していないとか、一部テストコードの残骸が入っているのでまだ使用できない事実に気づきました。次のバージョンぐらいでは修正し利用できます。

Javadocを公開しましたので、どんな機能がありそうかは簡単に確認できるかと思います。
ほとんど書いてないレベルですが。。。

Javadocはこちらから。
posted by Kiruahさん at 22:37| Comment(0) | TrackBack(0) | アナウンス

2011年08月27日

kommons-lib 0.4の公開

私がプログラムを作成する上でよく使うライブラリをまとめたkommons-lib 0.4を公開します。
言語はJavaです。ライセンスはApache License 2.0です。

いまだにドキュメントやテストはほとんど手付かずですので、自分でどうにかこうにかできる方のみご利用ください。

ダウンロードはこちらから。

主な修正点
・一部バグフィックス
・io系機能の追加

今回までのプログラムを利用することで、S.W.F.T.電文を取り扱うプログラムの実装が多少楽になるかなぁと期待しています。
電文入力からデータの変換はできます。まだまだ想定している機能の実装までは到達できていませんので、しばらくは頻繁にバージョンアップされそうです。
車輪の再発明と言われればそれまでなのですが。。。
posted by Kiruahさん at 10:50| Comment(0) | TrackBack(0) | アナウンス

2011年08月18日

kommons-lib 0.2の公開

私がプログラムを作成する上でよく使うライブラリをまとめた
kommons-lib 0.2を公開します。
言語はJavaです。ライセンスはApache License 2.0です。

いまだにドキュメントやテストはほとんど手付かずですので、
自分でどうにかこうにかできる方のみご利用ください。

ダウンロードはこちらから。

主な修正点
・JDK1.5でも動作するようクラスファイルのバージョンを落としました。
・ExcelReaderのインタフェースを追加しました。
・Addressのバグを修正しました。今まで"A5"の5を見落としていたと思います。
・ソースの公開を忘れていましたので添付しました。
posted by Kiruahさん at 22:34| Comment(0) | TrackBack(0) | アナウンス

2011年08月13日

kommons-lib 0.1の公開

私がプログラムを作成する上でよく使うライブラリをまとめました。
これまで公開してきたannsaxやjvalueも統合しています。
言語はJavaです。ライセンスはApache License 2.0です。

まだドキュメントやテストはほとんど手付かずですので、
自分でどうにかこうにかできる方のみご利用ください。

ダウンロードはこちらから

他にも色々とやっているため、versioning_mdbやkommons-libの修正は遅れ気味です。。。
利用者は少ないと思うので、影響はないと考えていますが。
posted by Kiruahさん at 12:09| Comment(0) | TrackBack(0) | アナウンス

2011年07月23日

極論であっても、やっていることを他のことに例えてみる

「それは極論だよ」なんて言われる経験がある方もいるかもしれません。

コンピュータの世界だけではありませんが、物事を抽象化することがあります。
抽象化することは、共通部分を見つけ出すことに近しいものです。
その共通化部分を究極まで切り詰めて見つけ出し、何にでも当てはめられる法則まで持っていくことをしようとすると、その時に「それは極論だよ」と言われます。

「何にでも当てはめられる法則なんてない、そんなことは当たり前だよ」
これは当然です。言い換えれば「例外のない法律はない」みたいなものです。

でも、自身の行動の規律を考える上で、この極論まで考えるというのはとても大切だと思います。
本当に極論を考えることになっているの?と思われるかと思いますが、例を考えたいと思います。
あくまで例であって、私が言おうとしている問題とはかけ離れたところです。ですので、矛盾などを見過ごしてみていただきたいと思います。

本を読むという行動を考えます。本を読むという行動を考えた場合、

1. 本を選ぶ
2. 本を買う
3. 本を読む
4. 読書を一旦中断する
5. 読書を再開する
6. 本を読み終える

これは料理するという行動と類似しているのではないかと考えます。

1. 料理を選ぶ
2. 材料を買う
3. 料理を作る
4. 料理を一旦中断する
5. 料理を再開する
6. 料理を終える

別に問題はありません。ですが、読書と料理では、一旦中断した場合の期間に違いがあります。
読書は1年でも10年でも、本が朽ちなければ一旦中断できます。料理は?料理は1年中断したら?もしかしたらまだ食材は持つかもしれません。10年保存しますか?冷凍すれば良いかもしれませんが、冷凍できないものもあるかもしれませんし、10年も保存したらまずいものもあるでしょう。。。

単に読書を他の料理するという行動に当てはめた場合、一旦中断するというところに違いがあって、極論、それを抽象化して共通的に考えるなんてナンセンスだと言われます。
この例は、確かに無意味かもしれませんね。


ここから本題です。

AさんはIT企業でPGをやっている10年目の社員です。ある日、先輩や上司から「このプログラム、3日で確実にできる工数で、実際にその工数で普通の人はできると第三者からも評価されたものだ。だから、3日で完成させてくれ」と言われました。
即座にAさんは、「自分の力では無理です。」と答えました。「体調が悪いのか?都合が悪いのか?緊急の用でもあるのか?」と聞くと答えは、「自分には、その詳細設計書の内容は難しすぎます。」と答えました。先輩や上司は諦めて他の人を探しに行きました。。。

極論です。もし野球ファンの方がいらっしゃったら大変失礼かもしれませんが、ご容赦ください。
プロ野球の選手に例えてみてください。

Aさんはプロ野球リーグで、10年目のセンター担当の選手です。ある日、監督や先輩から「次の試合、センターで、センターにきた玉はしっかりキャッチしてくれ。普通のセンターならキャッチしているような玉は確実にだ」と言われました。
即座にAさんは、「自分の力では無理です。」と答えました。「体調が悪いのか?都合が悪いのか?緊急の用でもあるのか?」と聞くと答えは、「自分には、センターの役割は難しすぎます。」と答えました。監督や先輩は諦めて他の人を探しに行きました。。。


ただの言葉遊び、すり替えでしょう?と言われても仕方ありません。
けれど、IT業界ではそれでもずっと給料をもらえます。でも、プロ野球の世界ではAさんはもう「引退」の言葉をつきつけられるほどのことをしていると言われても仕方ないのではないでしょうか。

できないことが悪いことではありませんとだけ、付け加えさせてください。
でも、せめて「どこまでやれるかわかりませんが、やらせてください」と言うことはできます。


自分の作業を他の業界であったらどうなのだろうかと置き換えてみてください。
例えばIT業界であれば、建築業界でもいいでしょう。
今作っているシステム「仕様がずっと確定していないけど、もうすぐリリースだからこのまま10万ステップのプログラム、不具合ありでもリリースしようか」という感じで、建築業者が「ビルの構造がずっと確定していないけど、もうすぐ工期が終わりだから、このまま33階のビル、そのままオープンしようか」と例えてみてもいいと思います。


所詮、極論です。所詮、共通化してみた言葉遊びです。考え方ややり方を抽象化してみただけです。
「そうだね、言葉遊びだ。極論だから、考えることはない」と言うのは、そこは人によって主義主張あると思いますので強制しません。

でも、一度、この極論で自分の行動を考えてみて欲しいと思いました。


「本当に、それは極論だよ、という言葉で片付けますか?」

2011年06月21日

OutputStreamWriterやOutputStreamReaderの罠?

Javaにて、テキストファイルをオープンする際、最近ではUTF-8で記載したファイルも開くため、エンコーディングを事前に指定することも多いと思います。
本来は勝手にエンコーディングを見つけてくれると助かりますが、そういう処理も重たいですし、何よりプロジェクトにおいては共通化することがポイントだったりしますので、全体の決めでUTF-8とすることも多いでしょう。
もしかしたら、下記の内容、私のJavaの不勉強さで間違ったことを記載しているかもしれません。
その際はご容赦ください。


そういった場合に例えばPrintWriterを利用する場合、簡単には以下のように記載します。

PrintWriter pw = null;

try {
pw = new PrintWriter("ファイル名", "UTF-8");
} catch (Exception e) {
e.printStackTrace();
} finally {
if (pw != null) {
pw.close();
}
}

このように実行した場合、PrintWriterのコンストラクタは以下のコードが実行されます。

public PrintWriter(String fileName, String csn)
throws FileNotFoundException, UnsupportedEncodingException {

this(new BufferedWriter(
new OutputStreamWriter(
new FileOutputStream(fileName), csn)), false);
}

※ 出典はJDK1.6 Update 26のソースコード(Copyright (c) 2006, Oracle)です。Oracle様、記載し申し訳ございません。

ポイントは、csnに変なエンコードを入れた場合、UnsupportedEncodingExceptionが出ることです。
この例外が出る前にはFileOututStreamの処理は成功しておりインスタンスは生成済みです。
その後、OutputStreamWriterのコンストラクタで例外が発生します。
その場合、FileOutputStreamのインスタンスはどうなってしまうのでしょうか。。。
普通はそのうち運がよければガベージコレクションが発動すると思います。
ガベージコレクションが発動すればfinalize内にclose()呼び出しがあるので、そこで確保されたリソースは解放されます。が、逆にガベージコレクションが発動されるまで開放されません。
何かしらのリソースをロックしてしまう可能性がありますので、注意する必要がありそうです。


普通は文字コードの設定などはプロジェクトの初期に行ってしまい、変更はしないものです。
ですが、ふとした作業(例えば変更してはいけないところを誤って変更していたなんてこともないとは言い切れないのが、この業界です)で、エンコーディングの指定を存在し得ないものにしていたなんてこともあるでしょう。通常はUnsupportedEncodingExceptionがスローされて、それをキャッチして異常終了させるとは思います。ですが、フレームワークによっては、そういった例外をもみ消して縮退運転的なことをさせることはないでしょうか?
それも普通はシステムの異常なのだから一度は止めてということもあるでしょうが、代替手段で行い、メインサーバは停止できないこともあります。私が関わっている案件はまさに止めるわけにはいかないシステム(止めてもいいけど、その後のリカバリが遅れたら〇〇億円とかになったらとか思うと。。。)です。。。

もみ消した場合は、ファイルがロックされたままだったり、利用しているStreamの種類によってはJNIの外でメモリリークも発生し、最悪はOutOfMemoryErrorとなり得ます。

なので、面倒なのですが私は必ずこのように記載するようにしています。


public void sample(File file, String encoding) {
PrintWriter pw = null;
BufferedWriter bw = null;
OutputStreamWriter osw = null;
FileOutputStream fos = null;

try {
fos = new FileOutputStream(file);
osw = new OutputStreamWriter(fos, encoding);
bw = new BufferedWriter(osw);
pw = new PrintWriter(bw);
} catch (Exception e) {
e.printStackTrace();
} finally {
close(pw, bw, osw, fos);
}
}

// 下記は本当はF/W側共通メソッドにしています。
public void close(Closeable... closeables) {

if (closeables == null) {
return;
}

for (Closeable c : closeables) {
if (c != null) {
try {
c.close();
} catch (Throwable e) {
}
}
}
}

こうすることで、実は例外発生時のスタックトレースも分割されるので、若干の処理速度とメモリ効率を犠牲にして、障害回復のしやすさを優先しています。
同じことはOutputStreamReaderでも言えると思います。

あとは、全てのJVMでfinalize()メソッドが確実に呼ばれるかどうか分かりませんので、確実にclose()するよう心がけておけばよいと考えます。
posted by Kiruahさん at 00:12| Comment(0) | TrackBack(0) | ノウハウ

2011年06月20日

私が上司になったら

私はまだ上司という立場ではありませんが、先輩後輩という立場でプロジェクト内で実践したことがあります。
それは、部下(この場合は後輩ですが)の愚痴や要望、やりたい事を聞くということです。
これは酒の席であれば、酒の勢いで話しやすいこともあるでしょうが、結局聞いたことを忘れてしまいやすいです。また、メモを取らなければ、真摯に聞くという気持ちも出てこないものです。

どんな内容でも愚痴を聞きました。「やり方が良くないのではないか」、「答えは分からないけど、これはおかしい」等です。
対して私の返答は「なるほど、〜ということで認識はあっている?」「なるほど、私もそう思う。では、一度持ち帰って率直に試してみるよ」「なるほど、私は〜だと思う」という感じで答えました。

また、最初は当然後輩といえでも身構えてしまうでしょう。どうやったって意図はなんだろうかと勘ぐってしまうものです。私は先に、こう目的を切りだしています。

1. 愚痴を出しきって、少しでもストレスを出したい。
大きな声で人に聞かれたくないことでも会議室なら聞かれにくい。
2. 酒の席では真面目に聞いてあげられなくなったりする。
でも、酒の席がよければそっちでも聞くよ。
3. 自分もたくさん愚痴があって、会社や自分の上司、もちろん君にも愚痴があって、
実は聞いてもらいたい。その愚痴から君も言いたいことを言っていいし、
自分で気づかなかったより良くする方法にこっそり気づいたらラッキーかなと思った。
4. プロジェクトは結局なんとか回る。
けれど、やりたくないことをずっとやり続けて回すんじゃなく、
やりたいことをやって、それでプロジェクトが回るように配置したいんだ。
5. 一対一なのは、他の人がいると言いにくいこともあるでしょう。
だからここの話はここだけの話にしてほしい。私の分は少なくともね。

直接口頭ではもっともっと簡単にピックアップして説明しますが、ここでは色々と目的を記載しました。


多くの上司や先輩は忙しいことも多く、また業務の進め方の良い点として、結論先出しもあって
「何が問題で、どうして欲しくて、それでどうなるかを説明しろ」
「愚痴とか誰かをせめるのではなく、建設的・前向きにプロジェクトをどうしていくかを考えよう」
「だからなんなのか?ただの愚痴で終わったら何もできない」
と言われやすいです。
ですが、本当のプロジェクトの問題は、あくまでも漠然としていて、しかも下っ端ではどうしたらいいか
力も権限も人脈も何もなく、それでも一番の実態を知っているのに何もできないという状況だと、私は考えます。だから上記のように言われると、下はもう何も言えないのではなく、言わなくなります。
また、上司は部下の言葉を真面目に効いていないとも思います。
いつもは「人生相談だってなんだって乗るよ」とか「なんで俺に相談しないんだ」など飲み会で言っていても、所詮それは言葉だけだと痛感させてしまうのです。

これは後輩たちが打たれ弱いのではなく、また勇気が足りないとか、昔と変わったとかではなく、誰でもそう感じるものです。ただ、そう感じた後にどう動くかが世代や性格によって違ってきているだけなのではないかと考えています。

でも、愚痴をメインにしたら結局答えはでないでしょう。それは分かっています。
人間は思っていることを言えないことがまた、大きなストレスになってしまいます。同期やさらに下の後輩に言っているうちは良いでしょうが、それでも解消しきれないストレスとなった場合、それは行き場を失います。本当は上に投げるべきものなのにです。
何でも言える場を提供してあげることも重要です。

また、下の愚痴からプロジェクトの問題点を抽出、推敲、類推できない上司は、正直なところもう無能な上司だと言われる時代だと考えるべきでしょう。
そこにはいろいろな問題点と解決策があるはずです。ただの愚痴だと思ってしまったら、ただの愚痴です。でも「そんなところに答えもアイディアもないと思うところにアイディアがあるかもしれない」とよく上司は言うのに、愚痴からはアイディアを探さないのは、単純に自分のことややり方を批判されたくないだけではないでしょうか。
上司の度量として、真摯に後輩の指摘を愚痴でも聞き、修正していくということを見せなければ、後輩が成長しない姿をなぜ注意できるのでしょうか。
「最近の若者はなかなか理解できない」は、簡単にいえば我々先輩がなかなか勉強もせず新しいことを取り入れていないからのように後輩からは見えています。だからこそ、私は誰よりも最先端のやり方も把握しようとしています。愚痴から取り入れようというのも、その一環です。。。
愚痴では前に進まないのではなく、また愚痴では結局どうしたら良いか分からないのではなく、その愚痴から本当の問題を抽出し、解決策を考えるのもマネジメント職の仕事だと私は考えます。

ただし上司側も、色々と聞き出したくて聴きに行くんだけど、やっぱりなかなか話してもらえないと思うでしょう。だからこそ、自分から自分の上司の愚痴をわかり易い言葉で後輩に先に話すのです。
先に、「上司がこうだから、本当はこうしてやりたいんだけどなかなかできないんだよね。。。難しいし、君が何がやりたいかもっと明確にしてくれたら、もっと君のやりたい事をサポートできて、それを理由に上も動かせるのにさ。だから、上を動かすためにも先に君のやりたい事を教えてほしい。もしくは一緒に考えよう」と言ったりします。



ただし、全ての後輩に対してやるとこれは大きな問題です。後輩一人ひとり性格が違います。
これをやって結局言いふらしてしまう子もいるでしょうし、私生活の話に飛んだりする子もいるでしょう。
真面目な子に対してやると効果的ですし、人によって時間をうまくコントロールすることも重要です。
人それぞれの性格をどれだけ見て、その子が何をしているかをどこまで把握しているか、当然上司として求められる物です。そこまでやって、適切に愚痴を聞き、プロジェクトを回すのが必要です。


私が上司になったら、どこまでうまくやれるかは分かりませんが、こういうことをしっかりやりメンバーマネジメントを図りたいと考えています。

2011年05月24日

人に対する許容というもの

プロジェクトマネジメントはとても難しいものです。
そのなかで、メンバーのモチベーション管理やそもそものヒューマン系管理は非常に難しい物があります。

今、プロジェクトの中で、メンバーの1名が顧客からも他のメンバーからも許容されていない状態にあります。
私はそのメンバーを見ていて、感じたことがありましたのでここに記載しました。

人が人に対して、その人を受け入れられるかどうか(ここではそれを許容と呼んでいます)は3つの要素で表現できるなと感じました。これらの言葉は勝手につけましたので、心理学的にどうだとかではありません。
もしかしたら、正しい言葉があるかもしれません。申し訳ございませんが、調べておりません。
また不快に感じましたら、本当に申し訳ございませんが、ご容赦ください。

A) 生理的許容
B) 発言に対する許容
C) 行動に対する許容

生理的許容は分かりやすいですが、例えば匂いだとか見た目だとか清潔感など、直感的な面も含めたものです。こればかりはどうしようもない面も当然あります。

発言に対する許容は、その人が言ったことに対する許容です。思っていることは当てはまりません。また直接その人に言ったことでなくても、人の悪口を聞いていた人が、言っていた人をどう思うかも含まれると思います。

行動に対する許容は、その人が行ったことに対する許容です。最悪、暴力まで含まれますし、細かな癖など、小さな行動も含まれます。

ここで、例えば性格だとか、思想だとかそういうものに対する許容もあるとは思いますが、人が考えていることなどは結局見えませんし、最終的には上記A,B,Cのどれかに表れてくると考えました。


感じたことは4点あります。

1. A,B,Cそれぞれ、人によって許容可能なレベルが違います。そして数値化しにくいものでもあります。
2. 人は多くの場合、相手がA,B,Cのうちいずれか1つに当てはまると関わりたくない人になり、2つ当てはまると嫌いな人になります。
3. 友達や日常の人付き合いでは、だいたいの場合、A > B > Cの順で優先度が変わります。つまり、生理的に許容できない人ほど、日常では関わり合いたくない度合いが強くなります。
4. 対して仕事では、C > B > Aの順で優先度が変わります。仕事では生理的にというよりも、行動の許容を超える人に関わり合いたくなくなります。

私のプロジェクトのその人は、Aの生理的許容という面では、だれも嫌がっていないのですが、BとCの面で非常に嫌われています。
もちろん、仕事もとてもよくできますし、経験も知識もあります。言っていることも大体正しいでしょうし、プロジェクトの上の方に当たります。そして、面白いことに性格は実は、相手のことを考えて行動するなど、気がきき、生理的にも全く問題ないのです。
ですが、発言が攻撃的でパワハラに近く、行動もあまり褒められたものではありません。それだけで嫌われてしまっています。
逆に他の会社のメンバーはまだ行動に対する許容度の範囲内のため、その会社の方からはまだ良い人だと思われていたりです。


これを受ける部下は逆に不幸だったりと、人というものは非常に難しい物です。
今は周りの人間のモチベーションをいかに維持するか、その補完をする必要があるため、なかなか仕事が大変です。
私の余計なお世話になっている面は否定しませんが。。。