QueryChartを使ってみよ〜 - almost nearly dead
Twitterでは色々つぶやいてたり、勉強会に出たりしてた割には、気がつけば二ヶ月も何も書いてないという惨状・・・ そんなこんなの二ヶ月間でしたが、Shibuya.trac第4.5回勉強会後に行われた懇親会でQueryChartPluginで着飾ったマイルストーンを何人かに見せたところ、QueryChartPluginは使ってみたいけど良く分からないという声を聞いたので使い方を紹介したいと思います。 QueryChartPluginって？ Hirobeさんの解説ページにもあるように、チケットの数を数えてチャートを表示するplug-inです。 パラメータの指定によってバーンダウン(右下がり)、バーンアップ(右上がり)のチャートが表示可能です。*1 QueryChartPluginを使うとワークフローのカスタマイズとマイルストーングラフのカスタマイズを加えると、Tracの味気なくいまいちなマイ
sqliteがバックエンドの時のTracReportを書くtips — ありえるえりあ
sqliteがバックエンドの時のTracReportを書くtips sqliteがバックエンドの時のTracReportのSQLを書くtipsです。 主なテーブル構造(ticket) CREATE TABLE ticket ( id integer PRIMARY KEY, type text, time integer, changetime integer, component text, severity text, priority text, owner text, reporter text, cc text, version text, milestone text, status text, resolution text, summary text, description text, keywords text ); CREATE TABLE ticket_custom
Mylyn＆Tracでリズムに乗ってタスクを大掃除♪
【1-2】コンテキストのアタッチ（リーダー） ■コンテキストを添付する利点とは？ コンテキストとは、タスクにより編集すべきファイル、もしくは編集したファイルを指します。コンテキストの添付を行うことにより、作業指示を出すときに、編集や確認すべきファイルを明確に伝えることができるようになります。コンテキストの添付は省略可能ですが（現に筆者は利用していませんが）、作業範囲を開発担当者に明確に伝えたい場合、利用すると便利です。 どのように便利か例を用いて説明すると、「ログイン処理の実装」というタスクがあった場合、ログイン処理を実装する空のクラスを作成し、コンテキストへアタッチしておくと、作業者はそのクラスを編集してログイン処理を実装すればいいことが分かります。 また、バグが発生した場合、失敗したテストケースをコンテキストへアタッチしておけば、バグの解析／修正担当者は、添付されたテストケースを調べて
Iwazer Report: tracのテーブル定義
いちいち、コンソールからこれをやるのも面倒なので、ここに載せておきます。 ちなみに、使っているtracのバージョンは Trac 0.10.3 Trac-Ja（インタアクト株式会社による日本語化版） sqlite> .schema CREATE TABLE attachment ( type text, id text, filename text, size integer, time integer, description text, author text, ipnr text, UNIQUE (type,id,filename) ); CREATE TABLE auth_cookie ( cookie text, name text, ipnr text, time integer, UNIQUE (cookie,ipnr,name) ); CREATE TABLE compone
Tracのワークフロー - プログラマの思索
Tracを使い始めて、Redmineと異なる視点を感じる所があったのでメモ。 【1】RedmineやTracを障害だけでなく要望も含めてタスク管理する発想は、Issue Trackingと呼ばれる。 元々、チケット駆動開発(Ticket Driven Development)は、バグ管理システム(Bug Tracking System)を汎用化した課題管理システム(Issue Tracking System)から発生した開発プロセス。 すると、障害管理で使われるステータスだけでは管理しにくい場面が出てくる。 例えば、ITILではシステム運用保守で、問題管理、インシデント管理、変更管理、リリース管理の4つの視点を提供する。 BTSのバグ管理は、問題管理と同じ。 問題管理のワークフロー(チケットの状態遷移図)は下記が普通だろう。 新規→担当→解決→検証中→検証完了→終了(リリース完了) このパ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
