Jenkins with VS2008 + α for C++
ちょっとVS2008でC++の開発をすることになったんですが、 リポジトリの最新をとってもしばしばビルドエラーになるので、 C++弱者の自分の為にJenkinsでビルド環境を構築してみました。 どうせなので、ドキュメント自動生成も設定してみようと思います。 ちなみにOSはVS2008のMSBuild.exeがいるのでWindows上です。 それと自分はgtestを利用しているのでユニットテスト環境もあわせて構築します。 事前準備 まずは必要な環境をインストールします。インストールの詳細は省きます。 VisualStudio2008 Professional (多分Expressでもいけるかと) Jenkins Doxygen(インストーラーから) Graphvis(インストーラーから) Python2.X(インストーラーから) Jenkins以外はインストーラーでインストールを行い、パスが
私が、分散バージョン管理を使おうと思ったただ一つの理由
最近デビューしました。 たった一つの理由を挙げろといわれれば 今のプログラミング開発手法のマッチしているから に尽きる。 TDDやCIが良い例だと思う。 TDDの例 SVNの場合TDDのレッド⇒グリーン⇒リファクタリングのタイミングでコミットするには粒度が小さすぎる。 でもコミットしないと小さな不安が残る。だけど、コミットすると余計なリビジョンがかさむことになる。 分散バージョン管理であれば、レッド→グリーンになったタイミングでローカルブランチにコミット出来る。 そのあと、一つのTDD(設計工程)が終わった段階でまとめてメインブランチにpushする。 ※bazaarでのやり方がわからないんだけど（汗 自分で試行錯誤しているときは安心(グリーン)したタイミングでコミット。 で、ひと段落したらメインリポジトリへpushというのが自然な流れで実行できる。 CIの例 CIの場合に、SVNでよくやる
xDDについて考える(その1)
※このブログはデブサミ後のTwitterで話題になっていた時に下書きしていたものをそのままUPしています。 先日TDDBootCamp北陸に参加して少し考えたところもあるのですが、それは別エントリに。 最近xDD(???-driven development)という言葉が色々取り上げらています。 TDD(Test-driven development) BDD(Behavior-driven development) SDD(story-driven development) DDD(Domain-driven development) ※ここでTiDD(Ticket-driven development)のような技法を含んでいないのは、ちょっと方向性が違うかなと思ったためです。 デブサミでも話題になったそうで、Twitter上でも色々議論が流れているようですが、 ちょっといま忙しくてほと
TracのReadonlyの背景を変更する
TracにはWikiページをReadonlyにすることが出来ます。 但しReadOnlyにしたからといって、Wikiページの見た目が変更されるわけではありません。 (ADMIN権限がないユーザで編集ボタンが表示されなくなりますが) 基本的には上記の動作で困りません。 ところが、自分が編集しない意味でreadonlyにした場合でも、気が付かずに編集してしまうことがあったので、 readonly時に背景を変更するように対応してみました(プレビュー時のイメージです) ※「自分が編集しない意味でreadonlyにした場合」の例としては、例えば顧客の承認を得たような文書です。 以下、本題です。 Trac0.11では、tracプロジェクト/templatesにsite.htmlを置くことでGenshiを利用したヘッダー/フッダー/CSSのカスタマイズを行うことが出来ます。 私の環境だと複数環境Trac
私がJavaのバイトコードをJavassistで操作する時
最近、既存コードのテストコードを書きまくっています。 その中で、Easymock(classExtension)などを用いてMock化している場合に、 finalクラスをMock化できず困っていました。 何かいい方法がないかなと思っていたらhudsonの開発者である川口さんが jaavassistを利用してfinalを除去しているという記事があり、 なるほどと思って自分もその方向で対応を行うことにしました。 その際に「なぜテストを書くのか」「どうしてそんな書き方をするのか」 ということを色々考えていたので、簡単に脳みそを整理してみます。 バイトコードが使われるとき 主にフレームワーク内部やIDEで利用されている技術と聞いています。 つまり大多数の一般的な開発者には使われないという認識です。 なぜテストにおいてバイトコード操作やリフレクションを使うのか 私の主観としては、リフレクションやバイ
Tracの任意のWikiページをPDF出力するスクリプトを作ったよ(暫定版)
TracのPDF出力する方法は、以前の記事でも述べたようにいくつかあります。 が、その中で唯一日本語に対応しているTracWikiExportプラグインは、 残念な事にテーブル内に日本語構成が含まれていた場合にテーブル構造が崩れたり、 {{{#!html}}} を正しく解釈できないという微妙な問題を含んでいます。 それで困っていたので、簡単にJavaのPDF出力ライブラリのiText5を利用して作ってみました。 サラッと作っただけでまだバグバグですが、コアとなるJavaの部分だけ晒しておきます。 launchpad.netにあげているので、ここからダウンロードできます。 目標としてはAdobeAirを利用したプレビュー機能&ダウンロード機能をつけたいですね。 ちなみに、プラグインとして作らずにAPIを利用して別アプリとして作ったのは、 PDF出力する状況を考えるとTrac上にプラグインとし
agiloをインストールしたら有効化されなくてはまった
結論はGenshiのバージョンが古かったこと。 自分の場合、easy_install を利用して全環境に適用可能にするのではなく、 任意の環境のpluginsフォルダにインストールするケースが多い。 理由はいくつかあるが、もっとも大きいのは属性やスコープの違うtracを複数運用しているため。 ＃ 開発用だったり、あるいは運用用だったり、要件管理用だったり。 そんなわけでagiloも python setup.py bdist_egg でインストール→コピー→プラグイン有効化したわけだが、なぜか画面に表示されない。 agiloのsetup.pyを確認してみたが、必須モジュールのGenshiもsimplejsonもインストールしている。 install_requires=['trac >= 0.11', 'genshi >= 0.5.1, < 0.6dev', # see Genshi bug
FlashViewプラグインに引数を追加してみた
*** flashview.py.r2457 2009-09-28 14:27:54.000000000 +0900 --- flashview.py 2009-09-28 14:30:04.000000000 +0900 *************** *** 5,11 **** from cgi import escape as escapeHTML import os from trac.core import * ! from trac.wiki.api import IWikiMacroProvider def swfsize(f): magic, version, datasz = unpack("<3s1B1L", f.read(8)) --- 5,11 ---- from cgi import escape as escapeHTML import os from trac
Subversionへのコミットコメントに関して
Subversionに代表されるSCM(Source Code Management バージョン管理システム)にコミットする際に、 適当なコメントを書かれていて後で困ることが多々あります。 TracやRedmineなどBTSとチケット連携しているような場合は基本的には問題ないのですが、 そうではない場合は、コミットコメントの重要性をきちんと認識しておきたい（させておきたい）ところです。 自戒も込めて、コミットログに書くべきこと書いておきます。 ＃ これはSubversion実践入門-達人プログラマに学ぶバージョン管理に書かれていることのコピーです。 ログのポリシーで書くべきこと このリビジョンにより解決される特定の問題の状態 なぜその問題の解決が必要だったのかの簡単な説明 既知の副作用のリスト 変更したインターフェースのリスト 削除したものがあれば、その説明 他の関連するリビジョンやタグへ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
