タグ

tracに関するftnkのブックマーク (26)

  • RedmineとTracの比較 - wyukawa's diary

    これまた今更感のあるネタですが少し調べてみたので書いておきます。比較対象バージョンはRedmine 0.9.4とTrac 0.11.7です。 あと僕は基的にTracユーザです。といっても使い倒しているわけではありません。Redmineに関しては実戦投入したことはありません。 1. インストール これは前提条件を明確にしておかないと比較にならないので、OSはLinuxでtracdやMongrelのような開発サーバではなくApahceに連携させるという前提にします。なのでTracLightningはのぞきます。あとSubversion使う前提にします。 この前提にたつとインストールはどっちも面倒だと思います。結局体とは別にTracならmod_pythonやmod_wsgiと連携させますし、Redmineならpassengerに連携させるのでその辺が面倒だなと。 Redmineだとさらにマイ

    RedmineとTracの比較 - wyukawa's diary
  • TraMのご紹介(OSC2009発表資料)

    著作 SCRUM BOOT CAMP THE BOOK 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎 出版社:翔泳社( 2013-02-13 ) 定価:¥ 2,520 スクラム初心者に向けて基的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。 CakePHPで学ぶ継続的インテグレーション 著者/訳者:渡辺 一宏 吉羽 龍太郎 岸田 健一郎 穴澤 康裕 出版社:インプレス( 2014-09-19 ) 定価:¥ 4,320 Webアプリケーション開発における継続的インテグレーションについて、CakePHPのサンプルをベースにして、その概要から使用ツール解説、導入方法、メンテナンスまでを解説 Chef実践入門 ~コードによる

    TraMのご紹介(OSC2009発表資料)
    ftnk
    ftnk 2010/02/24
  • RectaNg.com is for sale | HugeDomains

    Working with hugedomains.com was a quick and easy process. We got to speak to multiple real people located in Colorado without having to wait on hold! Our only complaint was we felt we had to overpay more than this particular domain was worth, and we weren't able to negotiate it down to a level that we felt was fair. However, payment and delivery were seamless, and within a few hours we had all of

    RectaNg.com is for sale | HugeDomains
    ftnk
    ftnk 2010/02/24
  • TracやRedmineのチケットのページを開く anything-show-ticket をリリース! - わからん

    元ネタ : StumpWMは便利です | アクトインディ技術部隊報告書 StumpWM から BTS のチケットに一発でアクセスする工夫があったので anything でもできるようにしました。コードは手抜きです。読んでわかる人はよかったら使ってみて下さい。グローバルなソースに入れても数字を候補とする他のソースは少なそうなので anything 起動 -> チケット番号入力でいけるはずです。 anything-show-ticket - GitHub 追記 emacs から BTS のチケット番号を指定してブラウザでチケットページを開く2 で真面目に作り直しました。設定方法も書きました。

  • 仕様書をSubversionとTracで管理する - rabbit2goのブログ

    議事録をTracへ載せる話は「議事録はTracへ」に書いたけれど、今度は仕様書の話。ソフトウェア開発の構成管理にはSubversionを使っており、その中にはソースコードだけではなく、WordやExcelで作った資料も入れるようにしている。以前はサーバの共有フォルダに入れていたけれど、色々な面で問題が有ったのでSubversionとTracを使うようにした。目的は下記の通り。 仕様変更の確実な履歴管理 Wordファイル自体に変更履歴を管理する機能はあるけれど、ファイルを開いてみなければ分からないし、必ず履歴が残っているという保証も無い(誰かが変更箇所を承認してしまった等)ので、あまり使える機能ではない。確かに、短期的に変更点を知ってもらうには分かりやすくて便利なのだけど、長期的な保存に耐えうる機能ではないと思う。そこで構成管理へ入れるようにすれば、遙か昔の履歴も確実に残るので安心だ。 ソー

    仕様書をSubversionとTracで管理する - rabbit2goのブログ
  • trac-ticket.el — ありえるえりあ

    Recent entries jlineで日語を使えるようにする。 sugawara 2009-12-10 五反田Emacsの資料 sugawara 2009-10-19 trac-ticket.el sugawara 2007-11-19 Emacs Lisp 勉強会(バッファとウィンドウ編) sugawara 2007-10-22

  • RedmineとTracの機能比較 - プログラマの思索

    RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱ExcelRedmineアジャイル開発を楽々管理 - @IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。

    RedmineとTracの機能比較 - プログラマの思索
  • 第1回 Tracの紹介とプロジェクト管理 | gihyo.jp

    はじめまして、広部と申します。連載では、開発プロジェクト管理ツールとして人気の高いTracについて解説していきます。 初回は、開発者から管理者になったばかりの新米管理者になったを対象に、「⁠Tracを使うことで情報共有がやりやすくなり、開発者がプロジェクトの状況・情報に詳しくなることで、結果としてプロジェクトの管理が上手くいくようになる」ということを説明したいと思います。 Excel管理は過去の話 少し前までは、プロジェクト管理といえばExcelの表編集機能を使った管理が当たり前でした。お客様の要求事項をExcelで一覧化し、作業タスク、ソースの改版履歴、障害情報を一覧化する。この方法は簡単なため、広く使われていました。 しかし、Excelファイルは複数人で編集するのに向いているとはいえません。Excelファイルは同時に二人で編集できないだけでなく、下手に扱うと自分が編集した内容が消失す

    第1回 Tracの紹介とプロジェクト管理 | gihyo.jp
  • SubversionとTracでファイル管理の“迷宮”から脱出

    SubversionとTracでファイル管理の“迷宮”から脱出:ユカイ、ツーカイ、カイハツ環境!(2)(1/4 ページ) プロジェクトで修正/仕様変更が“迷宮”入りする理由 ソフトウェア開発を行ううえで、設計書やソースコードのバージョンをきちんと管理することは非常に重要です。構成管理(ファイル管理)を行っていないプロジェクトでは、例えば次のような問題が発生します。 2人以上の開発者が同時に成果物を編集した場合、後に編集を始めた開発者がすでに編集を行った開発者の編集内容を上書きしてしまう。結果として、修正したはずのバグや変更したはずの仕様が、設計書やソースコードに反映漏れするという事態が発生 設計書やソースコードのレビューを行って修正したはいいが、どこをどう修正したのか分かりにくく、レビュー内容の反映の確認を行っても修正漏れや修正誤りに気が付かない ソースコードを変更すると、動かなくなってし

    SubversionとTracでファイル管理の“迷宮”から脱出
  • Trac入門執筆うらばなし

    Trac入門(技術評論社) の執筆にまつわるエピソードなどをまとめました。2008/10/18 Shibya.trac 勉強会で発表しました。Read less

    Trac入門執筆うらばなし
  • 第4回 Tracではじめるバグ管理入門

    「チケットは開発を救う」と考え,2007年のITpro Challenge!にてチケット駆動開発を提唱した。Tracを使う最大の利点はチケットとリポジトリ・ブラウザを連携できることだと考えている。 前回(第2回~第3回)までの連載で,Tracのインストールと基的な設定が終わりました。これからの連載では,Tracを上手に運用するためのコツをご紹介していきます。 Tracの主な機能には,Wikiとリポジトリブラウザ,それにチケットによるタスク管理システムがあります。Wikiとリポジトリブラウザは使っていても,チケットは使っていないという方は意外に多いのではないでしょうか。そこで第4回では,チケットの一番の用途である「バグ管理」について説明します。今回の説明には,Trac 0.11(日語版)が含まれるTrac Lightningのバージョン2.0.4を使用しますが,基的な考え方は以前のバー

    第4回 Tracではじめるバグ管理入門
  • 【特集】使ってる? Issue Tracking - trac 楽々ことはじめ (1) パニックプロジェクトを生まないために | エンタープライズ | マイコミジャーナル

    プロジェクトの情報共有を支えるための重要なタスクにドキュメンテーションと文書管理がある。あなたのプロジェクトでは適切な文書管理がなされているだろうか。通常、プロジェクトからは日々多くの種類/フォーマットの文書が生み出されている。そのため、文書管理に統制の無いプロジェクトでは、どこにある何を見ればいいのかを把握することでさえ、たちまち容易ではなくなってしまう。 プロジェクトに関する情報が増えてくる前に、一人でプロジェクト開発に従事しているあなたも、チームで開発をしているあなたも、散在する情報を整理したいと考えることだろう。 「今、プロジェクトで何が問題になっていて、何を片付けないといけないか」という情報群--ToDoやタスクリストとも表現できるこれらの情報群は、プロジェクト中のさまざまなシーンで出現し、これが管理されていないプロジェクトは、ほぼ確実に混乱に陥る。問題管理で取り扱う情報の種類は

  • 第1回 Tracをオススメする,これだけの理由:ITpro

    Tracの便利さに惹かれるが,インストールに煩わしさを感じ,Tracを簡単にインストールできるTrac Lightning(旧Trac月)の開発を行う。また,日のTracコミュニティであるShibuya.tracにてユーザー補完プラグインなどのプラグイン開発にも携わる。 チーム内のタスクや分散開発におけるタスク管理の手段として,プロジェクト管理ツールのTracが注目を集めています。Tracは,Ruby on RailsやSpring IDEなどでも利用されています。連載では,開発現場を交通整理するために,Tracを利用したプロジェクト管理の効率化を,Tracの基礎から紹介していきます。 ソフトウエア開発において,プロジェクト管理はガントチャート・ベースで行われることが多いでしょう。しかし,ガントチャート・ベースの管理では,詳細を報告するために作業報告書を別途作成する必要があります。 ま

    第1回 Tracをオススメする,これだけの理由:ITpro
  • livedoor Developers Blog:チケット駆動開発の研究と実践 - livedoor Blog(ブログ)

    こんにちは、そろそろ花粉のシーズンが近づいてきて戦々恐々としている金子です。 今年も花粉対策グッズの CM に注目しているのですが、花粉鼻でブロックがいいんじゃないか?と思っています。 花粉症のくしゃみ鼻水は、人が辛いのはもちろんですが周囲にとっても気分の良いものではありませんよね。エチケットとしても花粉対策は怠らないようにしたいものです。 チケットついでに今回はチケット駆動開発の話をします。想定読者は Trac をリポジトリブラウザとして利用しているがチケットは使ったことがない人です。Trac、 Issue Tracking System という用語に馴染みのない方は、それぞれ関連リンクを用意しましたのでそちらをご覧ください。 以下、僕の経験に基づき「チケット駆動開発とは何か」「何が目的か」「どう実践したか」「結果が出たか」についてレポートします。だいたいここ二週間くらい、チームではな

  • http://www.machu.jp/posts/20080313/p01/

    ftnk
    ftnk 2008/03/16
  • mizzy.org : trac を lighttpd + FastCGI で動かす

    trac を lighttpd + FastCGI で動かす Posted by Gosuke Miyashita Wed, 17 May 2006 14:40:45 GMT このエントリ の様な経緯で、うちでは apache + tracd という構成で trac を動かしてるのですが、tracd がしょっちゅう落ちるんですよね。1日に2, 3回ぐらいは落ちる感じ。で、5分ごとに cron で tracd プロセスを監視して、落ちてたら再起動ってなことをやってるんですが、typester さん から「うちは lighttpd + FastCGI でやってるよ」というアドバイスを頂いたので、試してみました。 やったことは以下の通り。 FastCGI のインストール lighttpd のインストール lighttpd.conf を書く lighttpd の起動 1, 2 については省略。ディ

  • チケットの使い方 - Meadow - Trac

    チケットの使い方 作成されたチケットはどのように使っていくのがよいかを説明します。 筆者の個人的な見解がたぶんに含まれていますのでご注意を。 なので、ここで述べる内容に従わなきゃいけないなんてことはありません。 臨機応変に使っていきましょう。 まずはおおまかに チケットは単純で、およそ2つの状態と思ってよいでしょう new または reopened あるいは accepted などの、チケットが活きている状態 closed した、つまり完了した状態。 チケットを作成した直後は、状態として new となります。 通常のプロセスで行くと、作業担当者が acccept(担当)し、accepted 状態になります。 そして実際に作業が完了したら "resolved as 'fixed'" として、closed 状態になります。 あるいは、チケットの内容が標準外のelispパッケージによるものでme

  • チケットの書き方 - Meadow - Trac

    BTSへの登録をする上でのガイドです。 このガイドに従わなければならないわけではありませんが、 迷った時の助けになると思います。 まだ方針がはっきりしていないものなどは記載されていませんが、 随時追記していく予定です。 チケットを登録してみよう チケットを登録する際の手順は以下のようになります。 画面右上のナビゲーションバーの『チケットの作成』をクリックして チケット登録画面に移動します。 まずチケット属性を指定しましょう。 『チケットの種類』は、新しい機能の要求であれば『新機能/拡張』を、 それ以外は『不具合』を使用しましょう。 『タスク』は主に開発者が使っていきます。 『機能区分』(コンポーネント)を選択しましょう。 適切なものがあればそれを選択します。 不明なら『その他/一般』を選択しておいてください。 使用しているmeadowのバージョンも忘れずに指定しましょう。 もし複数の系列で

  • TracDoc/TortoriseSVNTrac - HirobeのHack倉庫 - Trac

    TotoriseSVNとTracの連携 TortoiseSVN1.4.0からかな? TortoiseSVNには「バグ追跡システム / 課題追跡システムとの統合」のための機能があり、 これを使うと SVNのコミット時に、Trac等バグ追跡システムのissue番号を入力するフィールドを表示する ことが出来ます。入力されたissue番号(チケットのID)はログメッセージの最後に追加されます。 その他、TortoiseSVNのログからTracのチケットを開くことも。 また、SVNのリポジトリ内のフォルダに対して設定するので、1回設定すれば そのリポジトリを使っている全員に適用することが出来ます。 (対応しているSVNクライアントを使う必要はあります) ヘルプによると、2種類設定方法があるのですが、今回はその片方を紹介。 設定方法 リポジトリで対象としたいフォルダを右クリックして、「属性」を選択し

  • 【特集】使ってる Issue Tracking - trac 楽々ことはじめ (1) パニックプロジェクトを生まないために (MYCOMジャーナル)

    プロジェクトの情報共有を支えるための重要なタスクにドキュメンテーションと文書管理がある。あなたのプロジェクトでは適切な文書管理がなされているだろうか。通常、プロジェクトからは日々多くの種類/フォーマットの文書が生み出されている。そのため、文書管理に統制の無いプロジェクトでは、どこにある何を見ればいいのかを把握することでさえ、たちまち容易ではなくなってしまう。 プロジェクトに関する情報が増えてくる前に、一人でプロジェクト開発に従事しているあなたも、チームで開発をしているあなたも、散在する情報を整理したいと考えることだろう。 「今、プロジェクトで何が問題になっていて、何を片付けないといけないか」という情報群--ToDoやタスクリストとも表現できるこれらの情報群は、プロジェクト中のさまざまなシーンで出現し、これが管理されていないプロジェクトは、ほぼ確実に混乱に陥る。問題管理で取り扱う情報の種類は