2014年8月6日水曜日
Javaで作るシンプルなテキストチャット
WebSocketを実装しようとしたけど、双方向なプロトコルをいきなり作るのは大変そうだったので大昔に研修で見たことがあるようなテキストチャットをまず作ってみた。意外とクライアントがインプットとアウトプットでスレッドを分けないといけなかったので大変だった。ただクライアントだけが接続が切れた場合に例外が発生したりするので、タイミングによる制御が大切になってきそう。
2014年8月4日月曜日
純粋なJavaで作るHttpServer
WebサーバというとApacheやIISが必要と思うけど純粋なJavaでもHTMLを表示するだけであれば簡単に作ることができる。
com.sun.net.httpserverを使う手もあるけど勉強もかねてHttpServerを書いてみた。
ここではThreadを単純に使っているけどノンブロッキングチャネルを使う方法もあるのでこちらも試したい。
2014年8月3日日曜日
2014年8月2日土曜日
初めてのerlang
すこし前に話題になった気がするerlangを触ってみました。
色々と今までやってきた言語とは違うけどfor文がないのが辛いですね。。
そこでfor文ぽい処理を書いてみました。自分で書いたんだけどokって何だろう。。
関数脳になるのは長い道のりが必要そうです。
2014年7月30日水曜日
JavaFX8でPPMファイルのビューアを作る
JavaFX8でPPMファイルのビューアを作りました。
表示するだけであればこれで十分だと思います。
まじめに作るのであればPPMファイルの種類別の読み込み、ファイル形式のチェックなど色々細かいことをしないといけなさそうです。
2014年4月13日日曜日
Jetty9.1でWebSocket(JSR365)を使ってみる
一年ぐらい前に書いたJetty9でWebSocketを使ってみる。だとWebSocketのJavaEE仕様であるJSR365には対応できていませんでした。Jetty9.1ではJSR365に対応したようでしたので、それに準拠するように書き直しました。あまりソースはあまり変わりませんが少しシンプルになった感じがします。pom.xmlはgradleを使おうとしたのですがgradleのjetty pluginがバージョン7以降に対応できていないようです。(update jetty plugin to current jetty)
2014年3月5日水曜日
プロジェクトが遅延した場合の対処法
プロジェクト管理について珍しく考えていたので少しまとめたい。ここではプロジェクトが遅延した場合の対処法について書いてみる。ただし内容は経験のあるソフトウエア開発のみに特化しているかもしれない。
遅延が発生しないプロジェクトは見たことがない。なぜかを少し考えたところ当たり前だと気がついた。もし90%でできるタスクが100個あったとするとすべてうまくいってスケジュール通りに完了する可能性は0.002% (0.9^100*100) になりほぼ0%になる。だから何もしないでスケジュール通りにうまくいくということは嘘をついているか、すべてのタスクがほぼ機械的にできるようなものか、宝くじに当たるぐらい運がよい時になる。
プロジェクトは絶対に遅延が発生するのでもし発生した場合の対処法を考えたが魔法のような方法はなかった。もし遅延が発生した場合の対処で延々と悩むぐらいであればこの方法ぐらいしかないので機械的に対処するぐらいのほうが気が楽になるのではないかと思う。ここでは内部調整と外部調整に分けて記載してみる。
現状の人員、納期、品質を変更しない前提での調整内容をここで記載する。
残業する
単純に作業時間を長くする方法である。いきなり残業するだったので落胆の声が聞こえそうだがもっとも簡単な方法で一番とられやすい対処法だと思う。あまりやり過ぎると体調を崩したり見積もりの基準が定まらなくなるので負担にならない程度で労働基準法の範囲内ですることが前提だ。かっこよくいうと稼働を上げるとか、クラッシング(人員の追加の意味も含むがここではその意味を除く)とも言う。
並行作業する
すでに実施可能な先行タスクを並行的に行ってしまうことである。この対処法もよくとられるがうまくやらないと後戻りが発生するリスクもある。かっこ良く言うとファストトラッキングとも言う。PMBOKにもあるので真っ当な方法にも思えるが普通に考えると一人でこれをやろうとすると並行作業することになるので残業は不可避のように思う。
平準化する
一部の人に作業が集中している場合に暇な人ができるのであれば手伝ってあげる。ただ中々タスクを分解するのは難しいケースがあったり分解される方は気分はよくないように思うので皆の協力が必要だ。
効率化する
非効率なやり方をしていないかを見直して効率的なやり方があるのであればそれをもとに再見積もりをする。たとえば明らかに重複している作業がないか、自動化できないか考えてみる。
もし自分の管理の範囲内で調整がつかない場合は QCD(品質、スコープ、コスト、納期)をステークホルダーと調整する。たとえば納期が絶対であればある機能をけずるとか、単純に納期を延ばしてもらうとかの調整になる。
上記の対処法をうまくやればほとんどのケースは対応可能と考えられる。ただし最後の外部調整がうまくいかない場合は厄介なことになるだろう。正直言うと自分はこういう調整が好きじゃないしできればやりたくないので予防、調整しやすくする、メンバーで勝手にやれる方法を考えたい。
プロジェクトが遅延する理由
遅延が発生しないプロジェクトは見たことがない。なぜかを少し考えたところ当たり前だと気がついた。もし90%でできるタスクが100個あったとするとすべてうまくいってスケジュール通りに完了する可能性は0.002% (0.9^100*100) になりほぼ0%になる。だから何もしないでスケジュール通りにうまくいくということは嘘をついているか、すべてのタスクがほぼ機械的にできるようなものか、宝くじに当たるぐらい運がよい時になる。
プロジェクトが遅延した場合の対処法
プロジェクトは絶対に遅延が発生するのでもし発生した場合の対処法を考えたが魔法のような方法はなかった。もし遅延が発生した場合の対処で延々と悩むぐらいであればこの方法ぐらいしかないので機械的に対処するぐらいのほうが気が楽になるのではないかと思う。ここでは内部調整と外部調整に分けて記載してみる。
内部調整
現状の人員、納期、品質を変更しない前提での調整内容をここで記載する。
外部調整
もし自分の管理の範囲内で調整がつかない場合は QCD(品質、スコープ、コスト、納期)をステークホルダーと調整する。たとえば納期が絶対であればある機能をけずるとか、単純に納期を延ばしてもらうとかの調整になる。
上記の対処法をうまくやればほとんどのケースは対応可能と考えられる。ただし最後の外部調整がうまくいかない場合は厄介なことになるだろう。正直言うと自分はこういう調整が好きじゃないしできればやりたくないので予防、調整しやすくする、メンバーで勝手にやれる方法を考えたい。
登録:
投稿 (Atom)