FireUpFox Express -Take years off your "Profile"...-～古女房はvacuumで若返る～ SQLite ManagerがFirefox 3.5RC2で動作しなかったので、 カッとなってやった。後悔はしていない。 使用期間が長かったり、履歴・ブックマークが多いProfileほど効果を実感できるはず。 でも、もしかしたら何の効果も得られないかも。 単純に全てのProfileにSQLiteの再構築をかけて 結果を表示するだけのスクリプトですが、 念のためエラー回避機能を仕込んでおきました。 ご使用は自己責任で。 FireUpFoxExpress 0.1 ＆ FireUpFoxExpress_Silent 0.1 Universal Binary , Mac OS X 10.4.11で動作確認 (FUFE01.zip 640KB) ダウンロード 旧版
「保護」できるテストとは では、「保護」できるテストとは何でしょうか？ それは「単体テスト」、それも「自動実行できる単体テスト」です。コードを変更した際の有益なテストとして、ぱっと思いつくのは「回帰テスト」であり、業務システムには用意されていることが一般的ですが、回帰テストだけでは十分ではありません。 回帰テストは多くの場合「アプリケーションインターフェースに対して行われる」ものです。それは、改修や機能追加がすべて終わってから実行するものとして用意されています。もちろん、回帰テストには重要な意味があるのですが、コードの変更の際には、「フィードバックが得られるまでに時間がかかる」という問題があります。回帰テストは改修や機能追加がすべて終わり、実際に稼働する直前の確認のために行うものであり、コード変更をしながら随時動かして確認するものではないからです。 一方、単体テストは、当然コードのある部分
Ruby 1.9.1のメンテナンスを引き受けた当初、メンテナンスの指針として参考にできるものは多くはなかった。Ruby 1.8系のやり方を参考にしたくて、いくつか卜部さんに教えを乞うたりもした。そんなこんなで、メンテナンスする中で分かってきたこともあるのでメモする。 目標 まず、リリースブランチをメンテナンスする目標は何であるかをはっきりさせよう。メンテナンスによってどういった価値を提供するかと言っても良い。 安定した仕様の安全に機能するソフトウェアをできるだけ長期間提供すること、これが目標である。永遠に提供できれば良いのだけれども、そうもいかない。利用者が少なくなったバージョンをメンテナンスしてもメリットは少ない。メンテナンスに割ける人手も限りがある。開発されているtrunkとメンテナンスされているブランチが離れるほどにパッチの適用は難しくなり、対処すべき問題を共有することも難しくなる。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
