SIerが実践する分散開発とバージョンコントロール - Qiita
ソースの構成 おそらく、以下のように１つのJavaプロジェクト内にすべて書くのではないでしょうか？ デメリット バッチを書いている人が、オレオレライブラリやWEBのソースを改変する可能性がある。（オレオレライブラリ、WEBも然り） プロジェクトが太って行った時に、コンパイルなどに時間がものすごくかかる。（5000以上のJavaファイルが配置されているものを見たことがある） それぞれのソースでプロジェクトを分けているものも書こうかと思いましたが、 その場合は、システムでスタックをちゃんと組んでるかな、と思ったので省略。 リポジトリのモデル 従来型の場合は、以下のパターンのどちらかではないでしょうか？ リポジトリは分けている 最終的に社内のSVNリポジトリにオフショアA、Bのソースをマージすることを想定しています。 デメリット オフショアA、Bのマージが大変 オレオレライブラリの追加モジュール
バージョンによってモジュールの依存性を管理する
APIデザインの極意 Java/NetBeansアーキテクト探究ノート NetBeans開発プロジェクト10年超の蓄積！API設計の経験や考察をまとめた一冊 この記事は、書籍『APIデザインの極意 Java/NetBeansアーキテクト探究ノート』の内容を、Think IT向けに特別公開しているものです。 直線ではないバージョン付け 最もよく使用されているソフトウェアの番号付けの方法は、自然数を基にはしていません。代わりに、ドットで区切られた10進システムを使用します。これは、ソフトウェア開発における非直線、つまり、単一方向への開発ではなく、バグ修正リリースやバグ修正リリースのバグ修正リリースなどを表す多くのブランチへ対応するために必要です。図1で示すように、バージョン2よりも機能が少ないと想定される1.1.1などのバージョンが、実際にはバージョン2より後にリリースされる可能性もあります。
UserAgent判定器 Project Woothee はじめました - たごもりすメモ
UserAgent判定ライブラリはCPANに数多くあるし他の言語でも似たようなものだと思うが、ライブラリや言語をまたがって一致した結果を返してくれるようなものは存在しない(と思う)。が、特にHadoopを使うようになってJavaの事情をある程度無視できなくなってくると、これがたいへん問題に思えてきた。Javaで書かれたUserAgent判定ロジックが欲しいが、普段書くコードはJavaではない*1ので、他の言語でも全く同じように判定してくれるライブラリが欲しい。結果が食い違っていたり、新しいUserAgentを判定したいときに片方だけ対応されて片方は置き去りになったりすると大変困る。 ということで、作った。v0.1.0。現状ではJavaとPerlの実装がある*2。 https://github.com/tagomoris/woothee https://github.com/tagomori
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
