Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック 著者:Jared Richardson 販売元:オーム社 発売日:2006-08-26 おすすめ度: クチコミを見る これはとても良い本だと思っています。 今回のプロジェクトでは、これを参考に体制を組んだといっても過言ではない。 インフラストラクチャ ・バージョン管理 Subversion に一元化 ・ビルドスクリプト 継続インテグレーションの一部として、テスト環境発行のたびに クリーンな配置 ・テストの自動実行 unit test を、CI server で実行。 Rcov でカバレッジ測定 ・機能の追跡 週一回リリース環境での、社内受入テスト ・問題の追跡 trac による問題管理。 とりあえず、ゆるくやりたかったので。 trac にしました。 慣れたら、test link とか本格的にしたい。 金があれば、M
相対パス記法を悪用したディレクトリトラバーサル攻撃から保護するために,パス名チェックは欠かせない。しかし相対パス記法を仕様上認めるアプリケーションもある。パス名を正規化して,意図するディレクトリ/ファイルを指しているかどうかをチェックしよう。 リスト1のPerl で書かれたサンプルプログラムを見ていただきたい。ファイルを操作するアプリケーションによく見られるコーディング例である。このアプリケーションではデータファイルを「/var/data/」ディレクトリ下に配置し,そのディレクトリ下のファイルへのみアクセスすることを前提としている。1行目はこれをそのまま反映させたコーディングで,データディレクトリ「/var/data/」のパスに,参照しようとしているファイル名$fileを連結して,パス名$filepathを構築している。その後,2行目のsysopen文で$filepathにしたがいデータフ
Java におけるコード進化パターン (Code Evolution Patterns in Java) asato shimotaki <asatohan at gmail.com> 最終更新日 : 2009/6/21 (2004/4/22 より) [...] For twenty years, I spent two or three hours a day looking at pairs of things -- buildings, tiles, stones, windows, carpets, figures, carvings of flowers, paths, seats, funiture, streets, paintings, fountains, doorways, arches, friezes -- comparing them, and asking my
stoplightで最大化したターミナル上でzshとscreenとEmacsを立ち上げ、 明朝体フォントでプログラミングするbokkoです。 今回はバージョン管理システムの1つであるMercurialについて紹介します。 ウノウではSubversionとTracを組み合わせて開発を行っていますが、 僕個人では今年の春ぐらいからEmacsやzsh、screenなどの各種設定ファイルをMercurialでバージョン管理しています。 Mercurialとは? Mercurialは分散型のバージョン管理システムです。 これに対して、CVSやSubversion(以下SVN)は集中型のバージョン管理システムにあたります。 分散型と聞くと難しそうなイメージがわくかもしれませんが、 CVSやSVNに比べてると、より手軽にバージョン管理を行うことができるというのが、 Mercurialに対する僕の印象です
プロジェクトの情報共有を支えるための重要なタスクにドキュメンテーションと文書管理がある。あなたのプロジェクトでは適切な文書管理がなされているだろうか。通常、プロジェクトからは日々多くの種類/フォーマットの文書が生み出されている。そのため、文書管理に統制の無いプロジェクトでは、どこにある何を見ればいいのかを把握することでさえ、たちまち容易ではなくなってしまう。 プロジェクトに関する情報が増えてくる前に、一人でプロジェクト開発に従事しているあなたも、チームで開発をしているあなたも、散在する情報を整理したいと考えることだろう。 「今、プロジェクトで何が問題になっていて、何を片付けないといけないか」という情報群--ToDoやタスクリストとも表現できるこれらの情報群は、プロジェクト中のさまざまなシーンで出現し、これが管理されていないプロジェクトは、ほぼ確実に混乱に陥る。問題管理で取り扱う情報の種類は
2024年03月 / 02月≪ 12345678910111213141516171819202122232425262728293031≫04月 ひたすら増え続けるファイルの管理をどうするか・・・ 数日前からあれやこれやと模索、研究していたことにやっと終止符が打てました。 Windows Vista 環境で TortoiseHG(Mercurial)を利用してバージョン管理とバックアップを行うことに決めました。 デスクトップパソコンやノートパソコンなど複数台のPCを利用していると、 ドキュメントファイルや写真、動画、音楽ファイルを集中管理するには結構骨が折れるもの。 また、プログラム開発を行っているとファイルのバージョン管理は絶対しておきたいもの。 そしてハードディスクは、大切な思い出のファイルたちを引き連れてなにも告げずに突然お亡くなりになってしまうもの。 こういったことに、すべてうま
Mercurial の使い方のチュートリアル このチュートリアルは Mercurial の使い方を紹介します。 SCM ソフトウェアを使うにあたっての特定の予備知識は必要ありません。 あらかじめ Mercurial を理解する を見ておくとよいでしょう はじめに このチュートリアルを読み終われば、次のことが分かるでしょう: Mercurial を使うのに必要な基本的な考えとコマンド ソフトウェアプロジェクトに貢献する際の Mercurial の簡単な使い方 Mercurial のマニュアルページ hg(1) と hgrc(5) に目を通すことを強くお勧めします。 マニュアルページは リリース tarball にも doc/hg.1.html と doc/hgrc.5.html として含まれています。 コマンドラインで hg help <command> とタイプしても良いでしょう。 チュー
Mac用のアプリケーションは開発するのが難しいとよく言われます。 実際、難しいですし、MacOSXでの開発で使うObjective-Cも非常に変態的個性的で習得の壁も高いような気がします。 しかし、最近では少し事情も変わってきてさくさくっと開発できるようにもなってきています(もちろん、その先には大きな壁が立ちはだかってはいるのですけど)。 今回は、CoreDataというフレームワークを使って、コードを書かずに(一行も!)アプリケーションを作ってみます。 まるで魔法のようにアプリケーションが完成するので、ぜひ、実際に手を動かしてみてください。 Xcodeを起動する まず、開発環境であるXcodeを起動します。 HDD内のDeveloper/Applicationsの中に入っています。 もし、まだXcodeをインストールしていない場合は再度インストールを行う必要があります。 以下のリンク先のド
Javaのソースコードに特定の表記にしたがってコメントを書いておくと、javadocユーティリティを使ってクラス関係やコメント、APIマニュアルを生成することができる。開発で使われるAPIリファレンスの多くはこの方法で生成されたものだ。 同様にしてJavaソースコードをAPIマニュアルのように加工するソフトウェアにMavenで採用されているJXRなどをあげることができる。本稿ではこれに近いソフトウェアのひとつとして「Sorcerer」を紹介したい。19日(米国時間)に公開されたできたてほやほやのプロジェクトで、まだ開発がはじまって間もないが今後の展開が大いに期待できる。 図.1 毎度お世話になっているJDK 1.5 APIリファレンス 図.2 Sorcererで加工されたリッチなJavaソースコードリファレンス
最近、ソースコードのレビューが熱い(と思っている)。各種フレームワークの台頭によって、ソースコードの質がだいぶ均質化されているように感じるが、だからこそレビューを通じて知識の共有化をするべきだ。 パッチを表示 とは言え、まだまだレビューを支援するシステムは数少ない。そこでPerl製のこちらをご紹介。 今回紹介するオープンソース・ソフトウェアはCodestriker、Webベースのソースコードレビュー支援ソフトウェアだ。 CodestrikerはPerlで作られているソフトウェアで、Diffファイルとリポジトリのパスに従ってパッチファイルにコメントを書けるようになっている。アップロードされたパッチに対してコメントをすることで再修正、または適用という流れになる。対応しているリポジトリはSubversion/CVS/Clearcase/Perforce/Virtual SourceSafeとなっ
FlawedTheoryBehindUnitTesting - 単体テストに潜む誤った理論 目次 この文書について 単体テストに潜む誤った理論 単体テストに潜む誤った理論 この文書について "The Flawed Theory Behind Unit Testing" の日本語訳です http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... 私は Google の blogsearch 一式を使って単体テストに関する話題を拾っている。 普段は一週間に数十の blog やメーリングリストの議論に目を通す。 新しい話題もたまにはある。けれど、多くの話題は繰り返しだ。同じ主張が何度も現れる。 その中でもひときわ私を悩ませる
TopHatenarは、ブログの人気ランキングサイトです。 RSSフィード購読者数とソーシャルブックマーク獲得数という2つの指標をもとに、日本国内におけるブログの影響力を測定することができます。 対象ブログについて TopHatenarは2008年5月、はてなダイアリーのみを対象としてサービスを開始しましたが、2009年3月より、全ドメインのブログが対象となりました。 RSSフィード購読者数について TopHatenarが『RSSフィード購読者数』として表示している数値は、livedoor ReaderとFastladderにおける、ブログのRSSフィード購読者数の合計値です。 ソーシャルブックマーク獲得数について TopHatenarが『ソーシャルブックマーク獲得数』として表示している数値は、はてなブックマークにおける、ブログ内エントリーに対するブックマーク数の合計値です。 部門別ランキ
社会人になって最初に配属されたチームのコードはひどいもので, 私は同期の新入社員仲間 Y に "ひどいコードなんだ. あの先輩はろくでもない." と愚痴た. すると Y はぽつりとこう答えた. "<コードを憎んで人を憎まず> だよ." Y の言葉は私の座右の銘となった. コードと人格を切り離す. あたりまえの事に思えるけれど, いまより輪をかけて狭量だった私はひどいコードの書き手を見下していた. もちろん自分は棚にあげて. たかがコードで友情や信頼を失うのは愚かなことだ. Y はそう言うのだった. 件の先輩社員は寛大だった. 私は勢いと趣味に任せて彼のコードを書き換えていたが, 彼は文句もいわず, 雑用を押し付けてくることもなく, 他所からのメールやバグを黙々と片付けていた. 私が同じ立場なら, 間違いなく戦いの火蓋を切っていただろう. (実際, 翌年の私は毎日のように後輩と口論していた.
本日より、ricollabの語源の一つである「リコーラボ」としての活動の第一弾、郵便番号検索サービスを開始します。 同時に、このブログのサーバも社内のマシンルームから外部のデータセンターに移動して、心機一転です。読者の皆さんにはサーバの場所が変わってもあまり関係ないかもしれませんが、法定点検による停電の心配などが無くなりました。 「何でリコーが郵便番号なの?」という疑問も大いにあるかとは思いますが、いろいろなサービスで使われる情報なので応用が利くというのと、Webサービスとしてまずは小規模なところからスタートし、サーバの運営やWebサービスの提供までの設計・開発ノウハウを蓄積していこうという狙いがあります。 ただし、小規模なアプリとは言ってもただ単に日本郵便のゆうびんホームページで公開されている郵便番号データを検索できるようにするだけではつまらないので、山本がガチで設計したRESTfulな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く