ベイエリア情報局: tarballからインストールしたソフトウェアを簡単に管理する
元Vine SPARC開発者。2003年度未踏ユース採択者。ウノウ株式会社立ち上げ時に参画して4年間CTOとして従事。退職して現在P&Aラボにて客員起業家として起業準備中。 普通 tarball からインストールする時は ./configure make sudo make install のようにインストールします。この場合は全てのファイルが /usr/local に入るわけですが、 これだと複数のソフトウェアをインストールした場合に、どのファイルがどのソフトウェアに所属するのか分からなくなって、アンインストールができなくなります。 なので僕はいつも tarball からソフトウェアをインストールする場合は、 例えば hoge というソフトウェアをインストールする場合、必ず /opt/hoge にインストールしています。 ./configure --prefix=/opt/hoge ma
スクラムは現実解 (arclamp.jp アークランプ)
アジャイル開発というとXPに代表されるようなエンジニアリング的な要素が強いように感じられる。しかし、プロジェクトマネージメントをアジャイルにすることの方が重要だと思っている。僕が気に入っているのはスクラムだ。既に書籍が出ており、かなり明確に体系化されている。スクラムのプラクティスがなにかというのはWebや本で探ってもらうとして、なぜスクラムが良いのか・なにが難しいのか、というあたりを書いてみたい。 スクラムの良さ スクラムの良さはタイムボックスによるコントロールだ。ソフトウェア開発は、要件も技術要素も非常にあいまいで、ようはやってみなくては分からないことが多い。とはいえ何も基準がないのでは混乱をきたす。そこで、ある時間枠（土日を含む30日間）を基準とする。 チームは少人数（7人前後）で構成されており、自分達で期間内の作業にコミットする。作業ゴールは必ずテスト済みの動くアプリケーションで
JUnit 実践講座 - プログラミングスタイルガイド
[ホームへもどる] [JUnit 実践講座 へもどる] JUnit 実践講座 - プログラミングスタイルガイド 2002/01/02 作成 石井 勝 目次 はじめに 実装コードとテストコードの書き方は違う テストコードで一般解を扱わないこと コメントについて リファクタリングについて メソッド名と本体について テストコードの構成 Footnotes 更新履歴 はじめに XP による開発全体にいえることですが，JUnit を使った開発では，プログラマは次の 2種類のコードを書かなくてはなりません． 実装コード 実際にソフトウェアとして実装されるコード テストコード JUnit を使って書かれるコード 僕の経験では，一般に実装コードよりもテストコードの方がコード量が多く，コードを書くのに費やされる時間もテストコードの方が長くなります．したがって，何も考えず
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
