BitnamiのRedmineを導入した - rabbit2goのブログ
Redmineを直ぐに使いたいという要望が有ったので、Bitnamiのパッケージ（スタック）を使って導入してみた。このインストーラの良いところは、ApacheやMySQL、Rubyなどを全て含んでおり、Windowsインストーラを走らせるだけで直ぐに利用出来る点だ。面倒な設定なんてやりたくないから、取りあえず使いたいというニーズにはぴったりだと思う。 BitNamiネイティブインストーラは、Windows, Linux, Mac OS X へBitNami アプリケーションスタックを設置することを自動化します。それぞれのインストーラは、必要なソフトウェアをすべて含んでおり、まさに「箱から出して使うだけ」です（スタックといいます）。手順はシンプルです。ダウンロード。次へ、次へ、次へ、とクリック。はい、おしまい！ BitNami スタックは完全に独立しているので、あなたのシステムの他のソフトウ
仕様変更を言い出すのは誰か？ - rabbit2goのブログ
ソフトウェア開発時の仕様変更は頭が痛い問題だ。限られた時間とリソースの中で開発を進めているのに、仕様変更に伴う追加作業は「既存工程の中で吸収する」なんて言う、いかにも日本人的な対処を余儀なくされることが多い。工程が延びても、コードを書き上げテストを行って動作確認までした成果物に再び手を入れなければならないという精神的なダメージも大きいと思う。 「お客さんの要望だから仕方ない」という理由は分かるし、「仕様変更しなければ製品が売れない」という理屈も納得できる。それは正論だ。しかし、だからと言って、何度も仕様変更を続けて、開発現場に負荷をかけるやり方が正しいとは到底思えないような気がする。モノには限度というものがあり、それを越えた仕様変更は然るべき理由と共に拒否するのが当然ではないかと思う。 そんな度重なる仕様変更に腹を立てて、仕様変更の要求が来る度にTracのチケットを起票したことがある。記載
それは大いなる勘違い - rabbit2goのブログ
自分に与えられた仕事上の役割や役職が、あたかも自分の能力であるかの如く勘違いする人が時々いるので困ってしまう。 システム開発の上流工程を担当するようになった。 派遣社員や協力会社に指示を出すようになった。 開発担当からチームをまとめるリーダ役に代わった。 人望厚く周囲から尊敬される形で仕事をするのなら良いもの、これが自分の実力だと誤解した人は、やたらと態度が大きくなって周囲に威張り散らすようになるのでたちが悪い。そんな豹変ぶりを見ていると、この人の本性は所詮この程度のものなのかとガッカリしたりする。 もちろん、そのような役割を持たない人に比べたら多少なりのスキルは有るのかも知れないけれど（だからこそ任命されたわけだ）、任せてみれば実は誰にでも出来るものであったりすることが多く、抜てきの理由が「上司に気に入られたから」「単なる人事ローテーション」という程度のこともある。 本当に優れた普遍的な
Tracのwikiに図面を入れる（BlockDiag編） - rabbit2goのブログ
Tracのwikiでblockdiagを使うためのプラグインを導入した。直線や円と言ったプリミティブな図形ではなく、開発現場でそのまま使えるような図面を描けるのが特徴だ。利用環境は下記の通り。 MacOSX 10.6.7 (Snow Leopard) Trac 0.12.2 (MacPorts) Python 2.6.6 (MacPorts) BlockDiagPlugin 0.4.0 TracBlockDiagPlugin – Trac Hacks - Plugins Macros etc. 導入 blockdiagをインストール。 Bitbucket | The Git solution for professional teams % sudo /opt/local/bin/easy_install-2.6 blockdiag % sudo ln -s /opt/local/Libr
チケット駆動開発を導入しても変わらないこと - rabbit2goのブログ
Tracのようなツールを導入してチケット駆動開発を始めた人から必ず聞かれる質問の1つに、下記のようなものがある。 「チケットの数が多くて管理出来ません。やっぱりチケット駆動開発は無理です」 確かに、やること、やらねばならない事を片っ端からピックアップしてチケットへ放り込んでいくと、小さなプロジェクトでもあっという間にチケットの山が出来てしまう。沢山のチケットが並んでいるレポート画面を見るだけでも嫌になるし、ウンザリした気分にさせられるのは確かだから、このような拒否反応を示すのだろう。 でも、良く考えてみれば、これは少々変な話しだ。チケットで表現されている内容は、本質的にチケット駆動開発とは何ら関係の無く、従来からプロジェクトの中には存在していはずだ。今までの作業の中で、例えばWBSのような形でタスクの管理を行って来たのであれば、チケットは単にその形が変わっただけのものだから、チケットの数は
まずは箇条書きより始めよ - rabbit2goのブログ
昔、ソフトウェア開発のベテランの方に質問したことがある。 「どうしたら優れた開発者になれるのでしょうか？」 予想していた回答は「この本を読め」とか「あれを学べ」と言ったものだったのだけど、実際の回答は全然違っていた。 「自分の作業を箇条書きで表現出来るようになることだ」 これだけでは腑に落ちないので、その理由を聞いてみたところ、こんな説明が返ってきた。自分がやるべき範囲がどこまでなのか、何が必須項目の作業であり、何が見送り可能な項目なのか、作業に必要なものは何なのか等々を全て考えば、簡潔に箇条書きで表現できるはずだ。箇条書きで表現できないのなら、それは自分がやるべき事を自分自身で分かっていないことの証拠に他ならない。開発者は実際の作業の中でアレコレと疑問を持つはずなのに、それを確認しないまま勝手に作業を進めてしまい、後で予期せぬ問題を引き起こすことが多い。本当の開発者なら、その確認、検証、
ソフトウェアプロダクトライン開発入門セミナーに参加した - rabbit2goのブログ
昨日は産業技術総合研究所関西センターで開催された「モデル駆動開発を組み合わせたソフトウェアプロダクトライン開発入門」に参加してきた。講師はセイコーエプソンの島敏博氏。参加は30名弱で、関西地区だけではなく、名古屋や東京から来ている人もいた。これからプロダクトラインに取り組もうとしている人、モデル駆動開発をやってみたけど上手くいかなかった人、たくさんの#ifdefに困っている人など、それぞれに課題を抱えている様子だった。 講演は、プロダクトラインの考え方をどうやって管理者（会社側）に理解してもらうか？から始まって、良いモデリングの考え方や#ifdefによらない多品種展開の方法、アーキテクチャ戦略など、長年に渡って蓄積されてきたノウハウの集大成とも言えるような内容だった。もちろん、このやり方が正しいと言うわけでもないし、まだまだ課題が残されていることは事実だけど、産業界で日々ソフトウェアの開発
どの開発者に投資するのが効果的なのか？ - rabbit2goのブログ
先週のJaSST'11 Tokyoの最後のパネルディスカッションにて、正社員と派遣社員のどちらを教育すべきか？という意味の議論があった。有益な情報を社内に持ち帰ってきて横展開してくれれば誰でも良いと言う意見が出て、これはこれで正論なので特に反対意見は無く、では誰がその投資対象になるのか、具体的に言えばJaSSTのようなセミナーに行くのが望ましいのか？という話になるのだが、その時にこんな意見が出た。 自己研鑽に励んでいる人を会社としても応援すべきだ。 これはなかなか微妙な議論だと思う。JaSSTのようなセミナーに来ている人は目的意識の高い人たちばかりだから、このような主張に頷くことが多いようだ。確かに、何の問題意識も無い人より、色々考えてセミナー会場から多くの情報を持ち帰ってきてくれる人をセミナーに送り込んだ方が、会社としての費用対効果は高いだろう。 しかしながら、組織というものは複数の人間
チケット駆動開発で現場の問題を顕在化させる - rabbit2goのブログ
開発チームとしてやるべき事は、大きなものから小さなものまで全てTracのチケットに放り込んで作業を進めている。目的は下記の通り。 作業量の顕在化 チケットの更新状況を見れば、チームとしてどんな作業を進めており、どのくらいの分量が残っているのか一目瞭然だ。 作業遅延の顕在化 各チケットには期日があるし、タイムラインにはチケットの更新状況が出てくるので、作業が予定通りに進んでいるのか、遅れているのか直ぐに分かる。 作業漏れの顕在化 やるべき事は全てチケットに入っているはずだが、ふとした会話の中で、これ以外に問題が見つかることが珍しくない。このような誰にも気付かれずに存在していた問題こそが対処を要するものだ。 チケットに記載するということは「やるべき事を明確に定義する」という事に他ならない。「仕事をする」ということは実際のところ曖昧模糊としていて「やるべき事を忘れていた」とか「誰かの作業がいつの
自動車の電子安全に機能安全の進化を見る - rabbit2goのブログ
日経エレクトロニクス（2011年1月10日号）に、自動車の電子制御系に関する安全規格ISO 26262の記事が載っていた。自動車の開発には関わった経験が無いけれど、ソフトウェアの安全性がどのように捉えられているのか興味があるので目を通してみた。 ISO 26262を一言で言ってしまうと「IEC 61508を自動車向けにカスタマイズ」したものだ。機能安全に関する規格といえばIEC 61508が有名だけど、下記の理由で自動車業界では受け入れられないものだったらしい。 IEC 61508はもともと石油化学プラントなどを想定して作られた規格であるため、自動車のような大量生産品を想定した仕組みになっていなかったからである。 日経エレクトロニクス2011年1月10日号 | 日経 xTECH（クロステック） 実際のところ、機能安全に対する様々な批判（例えば、確率論に偏りすぎている等）を受けて、機能安全以
ソフトウェアプロダクトラインを阻むもの - rabbit2goのブログ
島敏博氏のブログにプロダクトラインに関する話題が載っていた。いくつもの類似ソフトウェアを継続的に同時開発していく場合、その共通部と可変部に注目して可変部分を分離し、共通部分の比率を徐々に高めていくことで、高い品質と生産性を目指すというものだ。全く新しい複数の開発をこれから始めるという非現実的な状況ではなく、既に大量のソフトウェア資産を持つ組織が、その開発の壁（品質、生産性、拡張性等）にぶつかった時にプロダクトラインを導入する際には極めて現実的な形だろうと思う。 こんな図面を見せられると、プロダクトラインを知らない人は「開発のあり方として当たり前のこと」とネガティブな評価をしがちだけど、方法論を含めて上手く導入出来ている開発組織はあまり多くないようだ。開発部門間の壁、目前に迫った納期、プライドの高い開発者、似て非なる大量の既存コード等々、プロダクトラインの導入を阻害する要因は多々有るし、また
ドメイン特化型軽量フレームワークが必要だ - rabbit2goのブログ
既存フレームワークやOSで用意されているAPIは、あらゆる処理で汎用的に使える形になっているのでいかなる目的でも使える反面、アプリケーション側から見ると必ずしも最適な形になっていない場合がある。 例えば、「ファイルから文字列を読み込んで取得する」といういかにもよく有りがちな処理が頻繁に登場するアプリケーション開発において、その処理の度に「ファイルを開いて、文字列の読み込みバッファを用意して、データを読み込んで、例外処理も忘れずに入れて...」とAPIを並べるのはかなり開発効率が悪いし、ソフトウェア開発の品質もなかなか改善しない。 このような場合は、該当処理を一箇所で行えるように共通化するとか、既存のライブラリを持ち込んで必ずこれを使うようにすれば良い。Apache Commons IOには、ズバリそのような処理を1行で済ませるための便利なAPIであるFileUtils#readFileTo
暗黙知という迷宮 - rabbit2goのブログ
Tracにはソースコード作成と同時に設計の考え方をまとめたり、関連する内容のチケットを作ったりクローズしたりしている。開発メンバー全員がこのような使い方をしてくれれば情報共有という面で有り難いのだけど、中には「リードオンリー」となって自分からは決して書こうとしない人もいる。酷い開発リーダに至っては「担当者が記載しろ、自分は内容を確認する（ので書かない）」というケースも珍しくない。ブログで情報を発信する人の数と、情報を参照して読む人の数を比較すると、圧倒的に後者のほうが多いそうだが、それは開発現場というクローズドな環境でも変わりないようだ。 仕様書を始めとする資料の作成は嫌われがちな作業であることが多く、それは仕方ないことかも知れないけれど、それならそれなりに手早く片付ける方法が有ると思う。チケット駆動開発も同様だけど、簡単に使える優れたツールが用意されているのにそれを使わない（使おうとしな
開発者のリセット症候群 - rabbit2goのブログ
ソフトウェア開発の現場でよく聞く言葉の一つに、今の問題を一旦棚上げして、最初からやり直そうというものがある。ややこしいソースコードや問題を相手にしていると、その解決方法の一つとしてやり直しを考えるらしい。例えば、こんなものだ。 度重なる修正で見通しの悪くなったソースコードを捨てて、一から作り直す。 問題山積みのプロセス改善に嫌気が差して、一旦全ての問題をリセットする。 行き詰まった議論を解決するために、決定事項を白紙に戻して再検討する。 リセットしたくなる気持ちはよく分かるけれど、仮にリセットしたところで抱えている問題は変わらないし、同じ人間が同じような思考で取り組む限り、いずれまた同じ状況に陥ることは明らかだろう。問題の根本が変わらないのだから、取り組み方を変えようがリセットしようが、本質的な問題は何一つ解決していないのだ。 組織の中で仕事を進めていると、例えば、組織が変わるとか、その管
形式仕様記述VDM++を学ぶセミナーに参加してきた - rabbit2goのブログ
昨日は某所で行われた形式仕様記述言語VDM++の基礎を学ぶセミナーに参加してきた。講師は「VDM++によるオブジェクト指向システムの高品質設計と検証」の翻訳者としても著名な酒匂寛氏。VDM++の書籍に目を通して、そのサンプルを動かす程度の経験しか無かったので、演習で色々と試せる機会が得られたのは有難かった。 VDM++の細かい文法は書籍を読めば分かるものの、実際のところは落とし穴が色々あるし、些細な疑問で行き詰まったりすることが珍しくない。今回のセミナーではそのような疑問にも講師の酒匂氏が丁寧に答えてくれたので、参加した甲斐が有った。本を読んだだけでは分からない「実際のところはこう使ったほうが便利」といった細かなノウハウを学べるのはセミナー参加のメリットだと思う。 今回のセミナーの対象範囲は、仕様記述言語としてVDM++の基礎を学び、VDMToolsを用いたモデルの評価を行うところまでだっ
MacBook Air用にEclipseのフォントサイズを変更した - rabbit2goのブログ
MacBook Air（13インチ）でEclipse v3.5を使っている。動作的には何も問題無く快適なのだけど、Airの画面解像度が高いので、今までと同じようなフォント設定ではかなり小さく見える。画面に表示される情報量は多いほど便利だけど、それにしても小さすぎる（と思う）。 ところが、エディタ部分のフォントは環境設定で簡単に変えられるものの、パッケージエクスプローラのようなエディタ以外のフォントまでは変わってくれない。一体どうやって変えるのかと設定箇所を探し回ったところ、Eclipseの設定ファイル（アプリケーションのパッケージの中）を変えれば良いと分かった。具体的には、下記のファイルに記載されているフォント指定箇所を削除すれば良い。 /Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse.ini -Dorg.eclipse.sw
チケット駆動開発の参考書「Redmineによるタスクマネジメント実践技法」 - rabbit2goのブログ
Tracを使い始めたきっかけは、情報共有用のWiki(PukiWki)、障害管理（影舞）、ソースコードビューワ(ViewVC)というツール類を一つに統合出来ると分かったからだ。元々、リポジトリ内のソースコードや障害情報をウェブブラウザ経由で参照していたのだけど、それらのURLリンクを辿って、例えば「障害情報からソースコードの該当箇所を参照」したり、「打合せ時にソースコードの該当箇所を参照」するようにしたら便利だと分かり、あちこちにリンクを貼りまくった記憶がある。当時はこんな素朴な仕組みでも快適に使っていたのだ。 しかし、一旦Tracを知ってその便利さに慣れてしまうと、もう元のツールには戻れなくなってしまった。Wikiからソースコードやチケットへのリンクが容易に作成出来て、マイルストーン毎に何の作業がどれだけ残っているのか「見える化」可能なのだ。こんな便利なツールは他に無い！と判断して、さっ
開発プロセスは終わらない - rabbit2goのブログ
ソフトウェア開発のプロジェクト開始時には「キックオフ」、完了時には「ふり返り」などと称して、プロジェクトとしてのけじめを付けたりすることが有る。開発契約などの実務上の作業は別として、プロジェクトの現場としては一区切りを付ける意味で必要だし悪くないと思う でも、継続的にソフトウェア開発に関わる立場として言えば、プロジェクト毎に開発対象は異なるにせよ「開発プロセスは終わらない」のが実状だろう。一つの開発作業が終わったら、プラス面として開発メンバーのスキル向上や技術的蓄積の増加などが上げられるし、マイナス面としては積み残し課題や技術的負債が上げられるはずだ。だから、次に行う開発プロジェクトではこの様々な蓄積と負債を共に抱えつつ作業することになり、前回の開発では実施出来なかった上手い対応が出来るはずだし、不可欠のはずだ。 言ってみれば、保守開発とか派生開発で得られた知見は次の開発へフィードバックさ
Tracのチケットは終了基準が大切 - rabbit2goのブログ
TracやRedmineを障害管理に使うことに慣れてくると、会議のアクションアイテムや各自の作業項目をチケットに入れて管理するようになってくる。いわゆるチケット駆動開発により、作業の見える化、効率化を進め、管理負荷の軽減を図るわけだ。何でもチケットに入れて整理しつつ片付けていくと、日々の業務がスムーズに進むようになるメリットは大きいと思う（ゲーム感覚と言う人もいたけど）。 このような形でチケットを使う時に大切なのは、チケットの終了（クローズ）基準だろう。障害管理ならソフトのバグを直してソースコードをコミットし、修正箇所が確認出来れば完了という極めて明確で普遍的なワークフローが存在するけれど、WBSの作業項目をチケットに放り込んで「概要仕様を検討する」なんて言う曖昧な項目を入れてしまうと、各自の認識が実は異なっていて開発途中にその違いが露呈して混乱することが珍しくない。 例えば、仕様を決めた
問題先送り体質からの決別を！ - rabbit2goのブログ
ソフトウェアの品質を改善するのに必要な姿勢は「そもそもバグを作り込まない」ことである。問題を生じさせなければ、テストでがむしゃらに頑張る必要は無いし、開発者はもちろんマネージャもテスターも誰も困らない。テストで分かるのは問題点のマイナスの度合いに過ぎず、幾らテストに頑張ったところでマイナスがプラスに変化するわけではないのだから、後工程で前工程の尻ぬぐいをするのは原理的的に間違っているのではないかとさえ思える。 もちろん、バグを作り込まないというのは理想論だろ！という指摘はある意味正しく、人間が作るものだからミスがあって当たり前のことだ。では次善の策としてどのように対処すればよいかと言えば「作ったら直ぐに見つけ出す」ことだろう。作ってから時間が経過し、どこにどのような形で埋め込まれているのか分からないバグを見つけ出すのは大変なことだ。バグの修正自体は容易だけど、多くの場合そもそもどこに問題が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
