« 2018年7月 | トップページ | 2018年9月 »

2018年8月

2018/08/28

Redmineにタグ機能を追加するパッチが投稿された

昨日、Marius BALTEANUさんがRedmine本家にタグ機能のパッチを投稿された。
次期Ver4.0で実現できたら、Redmineをより使いやすくしてくれるだろう、と期待している。
ラフなメモ書き。

【参考】
Feature #1448: Add tags to issues - Redmine

【1】なぜ、タグ機能が重要なのか?
それは、GitHub、Gitlab、Jiraなどの他のツールを見ればよく分かる。
Twitterのハッシュタグのように、「#○○○」を書けば、勝手にリンクできて、カテゴライズ化できる。
しかも、情報を探したい時に、タグで探しやすくなる。

(自動翻訳の引用開始)
私たちの問題の多くは複数のカテゴリにまたがっています。具体的には、単にカテゴリ以外のものよりも柔軟性のあるものを検索して管理したいと考えています。

問題にタグを追加する方法があれば素晴らしいだろう。
(自動翻訳の引用終了)

Redmineにタグ機能が欲しい、という要望は10年以上前からずっと言われていた。
そのため、熱心なユーザがタグ機能を実現するプラグインを開発してくれていた。
しかし、RedmineやRailsの度重なるバージョンアップに追随できなかった経緯もあった。

【2】ついに、Marius BALTEANUさんがパッチを投稿された。
そのコメントを読むと、Redmineユーザのニーズをすごく考えていることがよく分かる。

(自動翻訳の引用開始)
私は、プラグインhttps://github.com/ixti/redmine_tagsに基づいてRedmineにタグ機能を追加する作業を始めました(これまでの2年間で寄稿しました)。
私の計画は、第1段階で問題に簡単なタグ付け機能を追加し、機能がコアに承認/追加された後、他のエンティティ(ウィキ、プロジェクトなど)に拡張し、他のすべての機能を提案することです(バルク編集タグ、着色されたタグ)などがあります。

1.第1フェーズは、以下の2つのパッチで構成されています。

タグの追加/削除
タグの追加/削除タグの表示
タグの後にチケットをフィルター
チケット一覧の項目としてのタグ
タグ書き出し(pdf、csv)

添付されたパッチを使用してテストすることができます。
私はタグを管理する権限を持っているべきかどうか(私の見地からは、編集の権限は十分です)、何か他のものがなくなっていて、それがこの第1段階にあるはずなのかどうか疑問に思っています。

2. JSライブラリを追加してUIのタグを処理する(オートコンプリートを含む)添付のパッチでは、Jean-Philippe LangがSelect2をコアに追加したくないことを知っているのでSelectize.jsを提案します。
プラグインによって使用されることはもはや維持されません。
パッチは準備ができていませんが、私はこのライブラリを使用できることを最初に確認したいと思います(他の提案は歓迎です)。
また、プロジェクトからオートコンプリートでタグを提案する必要があるかどうか確認する必要があります。
プロジェクト階層、サブプロジェクトから)。

この機能は、Redmine.orgのチケット投票数のリストで1位にランクされ、120人以上のウォッチャー(この問題で80件、#2897で45件)、複数のコメントと関連する問題があります。
また、プラグインは、タグ付け機能がコアの一部である場合に役立ちます。
Redmine 4.0.0の後の次のバージョン(これはほとんど準備が整っています)でこれを行い、それを提供したいと思います。
(自動翻訳の引用終了)

【3】要約すれば、タグ機能が重要な理由は、2つある。
一つは、Redmine.orgのチケット投票数のリストで1位にランクされ、10年以上前からユーザの要望がチケットに記録され続けてきたこと。
もう一つは、タグ機能がRedmineチケットのカテゴリの代わりの機能になり、検索する時にも役立つこと。

Twitterのハッシュタグに慣れている人は多いだろうから、この機能が追加されることで、より多くのユーザがRedmineにチケットやWikiに情報を書き込むメリットを感じやすくなるだろう。
それら情報は、タグでカテゴライズでき、検索しやすくなるからだ。

このタグ機能も、Ver4.0またはVer4.1で取り込まれるといいなと思う。

また、Redmineの添付ファイルを全文検索できるパッチもVer4.1にセットされており、trunkにマージされることをユーザは待ち望んでいる。

Redmineの添付ファイルを全文検索するパッチの可能性~Redmineをナレッジシステムにするための要件とは何か?: プログラマの思索

タグ機能と合わせてリリースされたら、Redmineユーザにとっても待ち遠しいと思う。
今後も、Redmine本家の動向はチェックしておく。

| | コメント (0)

2018/08/19

モデリング技術の習得とモデリングツールの習得は表裏一体

1ヶ月前に、関西IT勉強会で「ITアーキテクチュアのセオリー」出版記念講演に出て、データモデリングの話を聞いてきた。
その講演者から、赤俊哉さんをお手本にしている、という話があり、赤俊哉さんの書籍をいくつか読んでみて、感じたことをメモ。

【ITアーキテクチュアのセオリー】出版記念講演<第64回IT勉強宴会in新大阪> | IT勉強宴会blog

赤俊哉さんの本「SE職場の真実 どんづまりから見上げた空」という本を読んだ。
著者が派遣プログラマ、ユーザ企業の社内SE、そしてユーザ企業のCIOへ築き上げたキャリア遍歴の話がメインで、自分の経験を振り返りながら、そうだなあ、と頷いていた。
その本の中で興味を惹いたのは、業務システムのリプレースの時に、有償の設計モデリングツールXupperに出会い、データモデリングを興味を持ち、データモデリングの技術習得に努め、業務システムの設計情報をXupperのリポジトリに集約させた事で、プロジェクトが成功した、という話があった。

Xupperとは? | 製品情報 | XupperII

Xupperの製品は僕も詳しくは知らない。
しかし、SoRのようなレガシー業務システムの設計情報をDOAモデリングツールのリポジトリに集約することの意義について、色々考える所があった。

SoRのような業務システムでは、どうしても上流工程の設計技術が起点になると僕は思う。
すると、DFD・ER図・CRUD表というDOAの3種の神器のような設計資料がどうしても必要になってくる。
なぜなら、業務の流れをつかむためにDFDが必要だし、データの構造をつかむためにER図が必要だし、仕様変更の影響範囲の調査やテスト設計のためにCRUD表が必要になるからだ。
しかし、それら設計資料をExcelドキュメントで手作業で作り出すのは正直面倒だ。

そこで、例えばXupperのようなモデリングツールが威力を発揮する。
設計情報がモデリングのリポジトリに一元化されていれば、そのリポジトリから、DFD・ER図・CRUD表は最新状態で出力でき、その内容を元に設計作業を効率化できる。
特に、仕様変更の影響調査では、設計情報が三位一体となったモデリングツールがなければ、システム保守でどんどんコストが増加していき、業務システムが経営環境の変化についていけなくなってしまう。

そういう観点では、DOAをマスターする事とモデリングツールを使いこなす事は表裏一体ではないか、と思う。
つまり、データモデリングを理解して自由自在に使いこなすには、モデリングツールがあればその成長速度を速められるし、他方では、モデリングツールを使いこなしていくうちにデータモデリングの技術を習得し、その作法に慣れていく、という側面があるだろう、と思う。

そういう背景やニーズが20年以上前からあるからこそ、最近、超高速開発という分野も脚光を浴びるようになったのだろうと思う。
僕は、超高速開発とは、データモデリングツールとそこから自動生成されたソースとそのシステムをシームレスにつないだもの、と思っている。
その本質は、モデリングツールで業務システムの設計情報をリポジトリ化できたからこそ、設計資料の出力だけでなく、システムの自動生成という所まで行えるのだ、という点にあるのだろう、と思う。

そんな事を考えると、モデリング技術の習得とモデリングツールを使いこなすことは表裏一体ではないか、と改めて感じる。
僕がUMLモデリングツールastahが好きな理由の一つに、そういう考え方を持っている事がある。

丁度それは、プログラミングの習得には、そのプログラミング環境の構築と習得が含まれていることと同じような気がしている。

【追記】
9/8土にastah関西の勉強会をやります。

第2回astah関西勉強会「開発現場のモデリング事例紹介」 - connpass

Mix Leap Study 特別編 -「開発現場のモデリング事例紹介」(astah勉強会) - connpass

| | コメント (0)

« 2018年7月 | トップページ | 2018年9月 »