開発ツール
ANTを高速に動作させる方法[開発ツール]
http://www.sdv.fr/pages/casa/html/sat.en.html
satのlibとbinのファイルをantのディレクトリにコピーすればインストール完了。 antcでコンソール起動が起動します。
Rhinoでスクリプト環境[開発ツール,できごと]:
PerlとかRubyとかスクリプト言語環境をよく使います。Javaだけで何でもやろう とするとものすごく時間がかかってしまったりします。で、Perlでプログラムを 書いてみたりするのですが、たまに書くと構文を間違えたり予約語が思い出せな いのです。やっぱりJavaの知識がたまってきているのでJavaのライブラリが使い たかったりするわけです。で、Javaのクラスライブラリを利用できるようなスク リプト言語がほしくなるわけで、自分で作ったりもしたのですが、なかなか開発 する時間が取れないので、結局、できあいのものでよさそうなのがないかと、昔 使ったスクリプト言語も含めてさがしてみたわけです。Rhino, Pnutsを使ってた こともあるのですが、Pnutsは以前痛い目にあったことがあるので使わなくなり ました。最近だとGroovyなんて言語もありますけど、おいらには難しいです^^; RhinoはJavaScriptですので、最近Ajaxなんかでバリバリ使っているためすぐに 使えました。ということでRhinoでちゃちゃっとプログラムを作ってたりしてい ます。案外便利ですよ...使い捨てプログラムばりばり増えてます^^;
それはそうと、昨日の日記でかいた今回購入した時計のお値段についてです。値 段予測してくれたみなさんどうもありがとうございます。ちなみに、私の母親は 「5000円ぐらいじゃないの?」と笑いながら言われてしまいました。やはり私の 性格をよく知っています^^;私は時計は動けばいいって思っているのでほんと 5000円ぐらいのやつでもよかったんです。
さて、今回の時計の値段は次のように推論していただけると値段に近づけたかと 思います。まず、ヒントの「7針」でデジタルが無いということから、クロノグ ラフであるということでかなり絞ることができるかと思います。そして、±3000 円というのがポイントです。実は1割程度の誤差を考えていました。でもそのま まだと価格が予測されると思ったので、1000円ほど幅を少なくしました。これに より情報量はかなりうすくなってしまってますが、この誤差に目をつけたDsuke さんは鋭い。でも3%はちょっと少なすぎですね^^; ちなみに、Dsukeさんのずば りこれ!と指摘してくださった時計はずばり店員さんがすすめてくれた時計です。 一度目の回答で一番近かったので何か考えましょうか^^; ここからは私の性格を 知らないと難しいです。まず、「けち」であること^^; 「国産メーカにこだわっ ている」ということ、「めんどくさがり」であること^^;この性格から2度めの回 答をtamotsuさんは答えてくださってますが、まさに、tamotsuさんが正解!型番 まで同じなので怖いです^^; 国産メーカに絞るだけで、CASIO, セイコー, シチ ズンの3社となります。そして、その中からクロノグラフの時計を列挙します。 「めんどくさがり」から電波調整機能があり電池交換が不要なソーラーパワー機 能があるものに絞ります。そして「ケチ」なのでその中から一番安い時計を見つ けるとそれがほぼ答えとなります。こんな感じで時計を選んでいたわけです^^;
Dsukeさんには「わかりやすい。」とほめられたのか馬鹿にされたのかわからん お言葉をいただきました。
Wagby 誰でも簡単WEBデータベース[開発ツール]:
JasmineSoftさんはちょっと前から気になる会社でしたが、こんな面白いツール を作ってました。サイボウズデヂエみたいな感じでしょうか。
業務システムやビジネスモデル関連で有名なある先生が「Excelでかなりの業務 アプリケーションの開発は可能である」と私にお話してくれたことがあるのです が、確かに規模を考えなければほとんどの業務アプリが開発できるかと思います。 「ほとんど」と言ってしまうと言い過ぎという感じですが、中小規模のアプリケ ーションは結構かけてしまうのではないでしょうか?(あくまで、深いことを考 えないように...)
細々としたシステムはたくさんあるのでこういうものでバンバン作ってしまうの はありですね...。中小企業を中心にかなりの企業で効果を発揮するツールでは あると思います。自分が考えている、「Excelレベルで改善できる簡単なITの導 入」の方法論を実現するための強力なツールになりえると思っています。
小規模かつお客様を選ぶ開発プロセス[開発ツール]:
[2006-09-07]でも書きましたが、「ゆるい」管理での開発プロセスを試行錯誤し ています。あくまで、考えている開発プロセスは「大規模向け」ではありません。 そもそも私の会社で請け負える規模はそれほど大きくないため、請け負えるレベ ルのプロジェクトで適用可能な開発プロセスをいろいろ試してみたり考えてみた りしているわけです。基本的な考え方は、
- 作業量最小で最大の効果を出すための工夫ができる。
- 無駄な作業をしない。(無駄な資料を作成しない。)
- 問題が発生したときに独りでなやまない。
ここでの開発プロセスに欠かせない基本要素は次の通りであると考えています。
- 「Task, Doing Done」管理
XP開発プロセスで有名ですから詳しくは書きませんが、考えられるタスクを見え る化して何をしている状態なのか、終わったタスクどれかをわかるようにします。
- 概要図を中心とした議論資料
A4以上の用紙、またはホワイトボードに描ききることが可能な図表現(あ くまで図)です。概要図一つが1トピックであることが望ましいです。表現方法 は基本的に自由ですが、直感的にわかる図を描く工夫をしなければなりません。 会議等ではこの概要図をベースに加筆修正を行う形で作業を進めます。概要図一 つが1トピックであることが望ましいです。会議終了後に、議論の結果が確実に わかるように表現することが大切です。議論の過程を残したいとも思っているの ですが、情報量が多くなってしまうので、あくまで結果が確実のわかるようにし ます。人間の頭脳は案外優秀なので議論の結果から過程は思い出すことができま すので^^;
- 1つの開発フェーズは「1日から1週間以内」で終わるようにし、何かしら動い
ている状況で開発を進める。
「1週間以内でできるタスクに分割する」ということ、「動きが見ることができ る」ということが重要です。1週間以上のタスクにしてしまうと規模が大きくな るため、作業内容が多くなりすぎて「見えなくなる」可能性があります。そうな ると担当者が独りで悩む時間が増える可能性もあります。そのため動く様子が見 れる程度、そして作業も一週間以内で終わる程度に機能を分割します。
1つの開発フェーズを終える毎に報告と次の開発フェーズ内容を整理するために やはり概要図を作成します。
概要図を元に議論-->概要図を修正-->実装-->報告と次のフェーズの概要図作成...
何度かこの繰り返しを行うことで開発を進めていきます。
- 納品後でもテストおよび再リリースが可能な体制を整える。
「いつまでもβバージョン」なんて言葉がありますが、まさにその通りでシステ ムは時間とともに成長(改変)されるものであるということを前提にその体制を 整える必要があるということです。
以上は、本開発プロセスの主要要素の概要です。割と当たり前のことを書いてい ますが、「図ベースで議論を進める」ということにこだわり持ちたいと思ってい ます。図で考えることもノウハウですので、これもできればまとめてみたいと思 っています。
Eclipseでコードチェック[開発ツール, できごと]:
FindBugやらEclipseをつかって今作っているシステムのチェックをしてみると... 警告が3000を超えるほど出て来た^^; う〜〜ん、あまり良いコードではないの ね...。警告理由を見ると、こちらが意図的にやっている部分も警告として出し てしまっているので、ちょっと厳しすぎる感じもしないでもないのですが、バグ も確かにいろいろ見つかりました。なんでもっと早くこのチェックを使わなかっ たのかしら。ということでコード精査中...。
UMLスケッチツール[できごと, 開発ツール]:
しまった。土曜日のうちに富士に移動するつもりが、いろいろやっていたら日曜 日になってしまい、早朝に移動しようと思って置きたまではよくて、そのあとい ろいろやっていたら、ふと眠くなってしまって、9:30になってしまいました。こ れから富士の方に移動して、用事を済ませて帰ってきます。それにしても眠い...。
UMLをスケッチするためのツールをいろいろ探索。Visioを使えばそれでOKではあ るのですが、万能なため、逆に使いずらいところがあります。Visio2003の standardだとUMLのテンプレートがついてない(と思っているのだけど...)ので http://www.phruby.com/ あたりから落としてつかっています。
MacOSとWindowsの両方で使えるものを探してみるとJavaアプリケーションで、 UMLet(http://www.umlet.com/)なんてものが見つかりました。手軽にUMLが描け るという意味では使える気がします。Violet(http://horstmann.com/violet/)な んてのもあるみたいですが、これはまだまだ完成度が低い感じがします。
ちなみに、私はUMLで仕様を書くことはほとんどないです。UMLの表記を利用して スケッチを描くことはあります。そもそも図でたくさんドキュメントを書くこと 自体が面倒なんです。めんどうくさくなくなって、しかも、UMLの意味論がお仕 事に関連する全員の頭の中に入れば使っても良いかと思っています。
さて、そろそろ富士へ移動します。
