Sphinx Advent Calendar 2012 - connpass の 15日目のエントリとなります。本日は、pandocというドキュメント変換ツールの紹介です。 Sphinx を使う場合、reSTにてドキュメントを記述しますが、例えばプロジェクト管理にRedmineを導入している場合、Wikiに書きためた文章があるかと思います。RedmineのWikiは textile 記法なので、reSTにうまく変換する方法があったらいいと思いませんか？ そんな textile を reST に変換してくれるツールとして使えそうな pandoc を紹介したいと思います。 pandoc とは pandoc は、ユニバーサルドキュメントコンバータです。 textileだけではなく、入力フォーマットとして、markdown, HTMLなどいろいろあり、出力も reST, markdown はもちろ
あけましておめでとうございます。今年もよろしくお願い致します。 _(_ _)_ この記事は Vim Advent Calendar 2012 : ATND の37日目の記事です。前日は、 @ShougoMatsu さんの 暗黒美夢王が紹介するエディタアニメ 2012+おまけ でした。 (´ー｀)｡ｏ O (やばいですね) redmine クライアント まだまだ中途半端な状態ですが、新規に redmine クライアントを作ってみたので紹介します。 以前にも redmine クライアントである unite-yarm.vim を作っていて・・・ redmine のチケット一覧を表示する unite-yarm を作ってみた https://github.com/basyura/unite-yarm 地味に機能追加して使ってたんですけど コメントの表示、登録ができない priority とか sta
チケット駆動開発のアンチパターンの事例のつぶやきを見つけたのでメモ。 とても面白い。 【元ネタ】 Twitter / kobachi_dearu: チケット駆動開発は好きである。だが、身の回りを見てみると、どうも使い方がこなれていないようである。アンチパターンのようなものを見つけたので記す。 Twitter / kobachi_dearu: 【期日・バージョンのない大量の『今すぐ』チケット】 リリース直後のバグ対策など今すぐやって欲しいのはわかるが、いつ本番反映するのかという計画がない。工数の見積もりもしていない。気分の問題でやっており、今やっている作業を止めてでもやるべきか、というマネジメントができていない。 Twitter / kobachi_dearu: 【モンスターチケット】 チケットが返ってきたかと思うと、違う作業が追記されている。バグチケットが復活して「バグなおってなかった！？
« Github Notification API が出たので通知を Growl するの書いた。 | Main | plackup の --path 引数 » 最近 yuroyoro さんが作った git issue が便利でたまらない。コンソールから redmine や github の issue が操作できるし、全て CUI で完結出来る。 しかしながら、どうしても「Vim で、しかも REST 的に redmine を扱いたい！」という欲望がおさえられず、作ってしまった。 mattn/vim-metarw-redmine - GitHub https://github.com/mattn/vim-metarw-redmine/ kana さんの vim-metarw 経由で redmine を読み書きできます。動作には vim-metarw が必要です。 kana/vim-meta
percolとgit-issueを使って、redmineのチケットをブランチに切って作業するのが捗る設定 git-flowとgit-issueを使ったTiDD環境について | Technology-Gymにて、 git-flowとgit-issueを組み合わせた使い方を紹介しましたが、チケットを切るときに手動でチケット番号を入力するのがとても面倒でした。 今回は、それをpercolというパイプで渡したものをanything的な絞り込み/選択できるCLIツールを使って楽にできるようにしました。 percolについては下記を参照して下さい。 percol は入力の1行を1候補として，部分一致かつ AND 検索で絞り込みし，選択した候補を出力するコマンドです．端的に言えば Emacs の anything.el のコマンド版です． anything 的な絞りこみコマンド percol の紹介 –
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
我々BeProudのRedmineのWikiやチケットの説明文やチケットのコメント文にはreStructuredTextを使っている。RedmineのデフォルトのTextileはPythonが好きな弊社で使うのは以ての外。なので、reSTを使うようにした。そして、生のreSTしか使わなければ、出来ることが少ないので、blockdiagや、コードの構文ハイライト（Pygments）を使っている。 Redmineはテキストフォマッターを入れ換えるように作られている。プラグインを入れるとWikiやチケットの内容のフォーマットを変えることができます。BeProudではRedmine reStructuredText FormatterのRbST/docutilsブランチを使っている。 http://glacialis.postmodo.com/posts/zyd1ig インストール ここには説明し
redmineをいじれる環境を構築する機会があったので、ついでにこれまで触って来なかったnginxを使って見ることにした。僕は基本的に枯れてきたものしか使わないので、そういうことです。ついでに、unicornというものがPassengerの代わりとして注目されているようだったので、試しに導入してみた。 nginxはともかくunicornが何なのかよくわからなかったので調べてみたところ、次世代RailsサーバーUnicornを使ってみた | TechRachohttp://techracho.bpsinc.jp/bps/2010_07_09/2075がわかりやすかった。 debianのセットアップざっと触って一番高速だった、http://ftp.riken.jp/Linux/debian/debian-cd/6.0.4/amd64/iso-cd/からnetinstイメージを落として、適当にセ
# この記事は名古屋クリスマソン2011で書かれました Redmine でチケットを検索する場合 ログイン プロジェクトを選択 チケット一覧を表示、チケットを検索 チケットを選択 とやたら手数がかかります。 この手数を大幅に削減するプラグインを作成しました。 機能 Google Chrome で r 検索キーワード と打つことでチケットのタイトルと本文とURLから検索します。 環境 Redmine 1.2 以降 リポジトリ https://github.com/suer/redmine_my_search 同梱している Chrome 拡張は、Myはてブサーチをアドレスバーから検索する my-bookmark-seach.crx を改造する形で取り込ませてもらっています。 http://d.hatena.ne.jp/Cside/20111215/p1 ライセンスが明記されていないため、REA
メリークリスマス！でしたね。今年のクリスマスは ruby を書いて過ごしました。えぇ。ついに ruby デビューです。 作ってたのは Redmine のリポジトリ全文検索プラグインです。会社のプロジェクト管理サイトを Trac から乗り換えるにあたり、これ！ってのが見つけられなかった情弱です。 Trac では、full-text サーチエンジンに Hyper Estraier を使う TracRepoSearch という素晴らしいプラグインを使ってました。ということで、便乗して redmine_reposearch というプラグインを作って見ました。バックエンドも同じく Hyper Estraier です。 個人的に欲しかった機能は、 インストールステップが簡単 プロジェクト、サブプロジェクト、全プロジェクト間で検索できる Redmine のアクセス権管理に対応する MIME タイプを限定
My Activities 自分のRedmine上の活動のうち直近10件を表示します。自分の作業を振り返るのに便利です。 画面右上のアカウントメニュー内のユーザー名をクリックすることにより遷移する画面の右半分に表示される内容と同等です。 New Issues 最近作成された未着手のチケットを表示します。 表示されるチケットの条件は次の通りです。 ステータスがデフォルト値(通常は「新規」) 作成されてから7日以内 担当者が自分または担当者無し Doing Issues 作業中のチケットを表示します。 表示されるチケットの条件は次の通りです。 ステータスがデフォルト値(通常は「新規」)ではなく、かつ終了状態(通常は「終了」「却下」)ではない。 最後に更新されてから7日以内 担当者が自分 Neglected Issues 放置されている可能性が高いチケットを一覧表示します。チケットを登録したもの
gitからredmineを使えるようにするためのスクリプトはいろんな人が作ってる模様。 http://yumewaza.yumemi.co.jp/2011/08/git-redmine-integration-using-rest-api-python.html http://d.hatena.ne.jp/mzp/20110806/ticket http://d.hatena.ne.jp/authorNari/20110129/1296291322 ざっと眺めてシンプルできちんと動きそうな Git-Redmine を入れてみた。 assinged to が入っていないとエラーが出たので https://github.com/wozozo/git-redmine こっちの修正版(develop)をDLしてきた。pull requestは出ているけれど反映されなさそうだったので。 あと個人的に
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
Redmineのトラッカーやチケットの設定をする
トラッカーやチケットには、様々なパラメータを設定する事ができる。デフォルト値でも十分使える気はするが、後で分析できるように考えながら設定してみる。懲りすぎると逆に混乱するので注意が必要。。。 プロジェクト この単位でトラッカー、メンバー、ソースコード管理システムのリポジトリ、Wiki、アナウンス、文書などを登録、公開する。ソフトウェア開発の場合は、管理対象のソフトウェア毎に作成するのが普通。 今回は、主にIS仕事のタスク管理に使うので以下プロジェクトを作成した。 既存システム目標管理(AD構築など数ヶ月かけて行う作業)その他何でも入れるプロジェクトを１つ１プロジェクトで全て管理する事も考えたが、数年使い続ける事を考えると、何らかの単位で分けたほうがいい。後々公開する事も考慮。 トラッカー トラッカーは、チケットの入れ物で、チケット発行時にどのトラッカーに含めるかを選択する。(ただし、後から
トラッカー ドキュメントドキュメント書き。 調査・検証調査、検証、研究など。 機能機能の追加や変更など。 不具合／バグバグや不具合登録する。 要望ユーザーからの要望。後で「機能」や「バグ」に変化する可能性がある。 サポートユーザーからの問い合わせは、とりあえず登録。後で「要望」や「バグ」に変化する可能性がある。 障害なんらかの障害が発生したら、とりあえず登録。このチケットに関連した「不具合／バグ」のチケットが後から追加される可能性あり。 環境環境構築・環境整備や設定変更など。 アイデアアイデアを登録。 タスク上記以外は全てタスクにする。タスクのトラッカーが多い場合は、トラッカーの項目を見直す必要あり。 ステータス 未着手新規登録したチケットのデフォルトステータス。 作業に着手担当者が作業を行っている状態。 対応待ちなんらかの対応を待ってからではないと進められない保留状態。 保留対応待ち以
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
