アカベコマイリ

HEAR NOTHING SEE NOTHING SAY NOTHING

redmine.tokyo 17 感想

November 12, 2019イベントRedmine, redmine.tokyo

2019/11/2 (土) に開催された redmine.tokyo 17 の感想。今回はひさしぶりに私も登壇した。

The future Redmine you can get today

Redmine の歴史において非常に重要な発表。新たに RedMica (レッドマイカ) というディストリビューションが登場した。これを開発するに至った背景としては以下のような感じ。

  • Redmine は活発に開発されているがリリース時期は不定である
  • My Redmine のような Redmine ホスティング サービスとしては、ユーザーへ迅速に新機能を届けたい
  • そのため定期リリースされるディストリビューションを提供することにした

私の知る例としては ECMAScript の規格策定や Node.js がある。これらはほぼ定期 (年次) リリースされるため、運用計画を立てやすい。リスクを避けて枯れたバージョンを選ぶ方針だとしてもリリース間隔が一定ならば、それを基準にした検証期間を組める。なお RedMica のリリース計画は 6 ヶ月ごと。なかなか野心的だ。

設計運用としては、ある時点の Redmine trunk スナップショットに基づく。データベースについて一切、手を加えないので互換性も確保されるとのこと。ディストリビューションであってフォークではないのだ。もちろん相互移行も可能。エンド ユーザーとしては定期リリースされる Redmine、ぐらいの認識でよいだろう。

プレゼンの終わりに質疑応答が設けられたので、質問。Redmine は公式 Docker イメージを提供しているが RedMica もそうしますか？前田さんいわく、現時点でその予定はないが前向きに検討するとのこと。ぜひ提供していただきたい。

懇親会で RedMica についてのよもやま話を前田さんから聞いたのだが、既存 Redmine コミュニティーやメイン開発者の JPL (Jean-Philippe Lang) 氏へかなり配慮していることが感じられた。ディストリビューションと位置づけたのも、そのあらわれといえる。

あなたも作れる！Redmine テーマ

ひさびさの登壇。私の参加した redmine.tokyo 14 から 17 まで Redmine のテーマ開発を中心とした講演がなかったのと、私自身が akabekobeko/redmine-theme-minimalflat2 を開発していることもあって、その知見を共有したかった。元ネタは以前ブログに書いた Redmine テーマのつくりかた。

登壇の目標として

  • ライブ コーディングする
  • 質疑応答を 5 分間、設ける

を自分に課しており、それを達成できた。

題材として紹介した akabekobeko/redmine-theme-starter は Docker (with docker-compose) と Node.js (npm) による CLI になる。これはプログラマーではない人に黒い画面などと呼ばれ、抵抗感をもたらすもの。なので説明は避けられないにしても、ライブ コーディングで実際に操作しいる場面をビジュアルとして見せて「意外になんとかなるかも？」と感じてもらえることを目指した。うまくいっただろうか？聴講された方の感想がほしい。

質疑応答についても 5 分は取れなかったが、沢渡あまねさんから質問を受けられた。内容は Docker を利用することでどのようなメリットがありますか？というもの。私からの回答としては

  • 難しいとされている Redmine の環境構築が楽になる
  • 環境設定がテキスト ファイルになるので Git などのバージョン管理と相性がよい
  • Redmine 公式 Docker イメージがある = 公式の鉄板構成を利用できる

みたいな感じのことを話した。

Redmine 全文検索の実際 〜1,000 億文字を平均 3 秒以内に検索できる、サクサクな Redmine 全文検索の作り方〜

島津製作所の大規模な Redmine へ全文検索を導入した話。題したとおり 1,000 億文字からなるデータから特定語句を平均 3 秒ほどで検索可能にする全文検索プラグインを株式会社クリアコードと共同で OSS として開発した。

プレゼンの手本のような登壇だった。専門用語が多くプログラマーでも DB やインフラ分野に触れた経験がないと難しい内容にも関わらず、スライドのわかりやすさと赤羽根さんの軽妙な語り口がすばらしい。会場は終始、歓迎的な笑いに包まれていた。もし赤羽根さんが営業にきたら、宇宙パワーのすごい石 (by.人間椅子) とか売り込まれても契約してしまいそうなぐらいだ。

全文検索プラグインについて。パフォーマンスは当然として結果表示を細かくカスタマイズ可能な点もよい。この部分だけでも Redmine 標準へ取り入れてほしいぐらいだ。課題があるとしたらインストールの難しさだろうか。通常の Rdmine プラグインと異なりミドルウェア (Mroonga など) に依存するため、インフラ面の知識を要求される。この辺の話については後述の Kohei Nakamura さん LT で触れられていた。

プログラマー的には企業内で利用することをきっかけに開発した成果物を OSS とした点も評価したい。

LT 大会

Redmine プラグイン開発と CI の matrix

リモート参加で登壇。はじめに画面共有し忘れがあったものの、以降はスムーズに進行。他のイベントでも最近は Googlt Hangouts などによるリモート化を見かける機会が増えた。技術により地理的な参加障壁が解消されるのは実にすばらしい。

Redmine プラグイン開発の動作検証における、環境の組み合わせを Circle CI で処理する話。テスト自動化において CI サービスがどれだけ効果的かを示す一例である。環境と処理を宣言的に定義することで、

  • 対象環境が明示される
  • 対象環境で網羅的に動作確認を実行できる

というメリットを享受可能。定義も YAML などテキスト ファイルが主流で Git などのバージョン管理ツールと相性がよい。ここでピン！ときた読者もいるだろう。そう、私の登壇における質疑で述べた Docker の便利さもここにある。

CI サービスについては GitHub も Actions で参入した。そしてこれは本物の IE や Safari を動かせる。

こういうのを見ると、E2E テストもいずれ CI サービスで処理するのが当たり前になるかもしれない。

全文検索プラグインのすすめ < full text search plugin >

前述の全文検索プラグインを実際に導入してみた話。ミドルウェア周りのバージョン問題やインストール手順の関係で、かなり苦労したようだ。こうした失敗と克服をまとめた話は

  • 開発者としてはつまずきポイントの対策や改善
  • ユーザーには追体験することで成功の確度をあげられる参考資料

として有用である。

それとこうしたトラブルで Twitter や Slack に助けを求めると、すぐさま助言が来るのは Redmine コミュニティーのよいところ。Slack も賑わっており ROM でも楽しめる。

カテゴリのサブプロジェクト継承対応機能追加 & Unofficial Redmine Cooking Kindle 版 令和元年創刊

2 本立て。

Redmine のカテゴリー機能はプロジェクトに属する。これは影響範囲を局所化するメリットがあるものの、階層化されたプロジェクトなら同一系統といえるため、子へ伝搬させたくなるかもしれない。これを叶えるために Redmine trunk へのパッチを作成した話。影響範囲の広すぎるトラッカーと狭いカテゴリーの間を埋める機能として有用かもしれない。

redmine.tokyo でおなじみ Unofficial Redmine Cooking を Kindle 本として出版した話。今回のイベントを記念して 24 時間無料にすることも告知された。Unofficial Redmine Cooking 活動を広める施策の一環とのこと。

Redmine と RPA

RPA と Redmine を組み合わせる話。RPA が具体的にどんなものか知らなかったのだが、登壇内容や紹介されている UiPath を見るに macOS の Automator みたいに GUI も含めて PC 操作を自動化するもののようだ。

ソフトウェア開発の世界でも E2E における GUI テストでこの種の自動化ツールを見かけることがある。プログラマーとしては目的そのものを処理するプログラムを書きたくなるが、そうせずとも

  • 操作対象が API を公開せずとも自動化できる
  • それらを組み合わせて複数アプリケーションにまたがり操作することも可能

を実現してくれるのは十分なメリットだろう。登壇の締めでも触れているが、RPA ツールとタスクの保守コストが見合うかが重要。

View Customize でユーザー／プロジェクトのカスタムフィールドを利用した個別カスタマイズの方法

カスタムフ ィールドにデータを定義、それを View customize から参照してユーザーとプロジェクト単位の特別な処理を実行する話。

登壇を聞いている最中は View customize なら localStorage か IndexedDB もよさそうだと思っていたのだけど、これらだと保存単位が Web ブラウザーになるため、Redmine ユーザーとプロジェクトならカスタム フィールドのほうが適切といえる。

ここに保存しておけば自身で DOM 処理をせずとも View customize 経由で簡単に値を取得可能な点もよい。スライドでデメリットとして挙げている事項については

  • 入力値のデータ制約 ...JavaScript としてチェックすれば解消できる
  • 複雑な機能実現のためフィールドが増える ...フィールドを増やすかわりに入力値を構造化する、例えば JSON

という感じで対策できそう。

＜自動化時代に Redmine 活用＞

  • hin-t さん
  • 資料、見当たらず

Redmine のトラッカーとステータスをトリガーとしてコマンド実行するものと、その応用であろう、自動で電話対応するプラグインの紹介。

電話側のほうは発信機能も面白いが、その番号をチケット注釈へ記録してくれるためカスタマー サポート業務で役立ちそう。チケット駆動というと人間によるタスク管理を考えがちだが、ソフトウェアで処理可能なものなら何を対象にしてもよいわけで、ここへ電話を持ち出す発想に感心させられた。

The world of Redmine as seen from JavaScript

Redmine のバックエンドとフロントエンドについて観念的に解説する試み。

DB などの実データを扱うバックエンドに対し、その出力範囲で処理をするフロントエンドを妄想世界と位置づけている。これは処理の安全性にも関係しており、Redmine のフロントエンドは基本的に実データを扱わないため安全にカスタマイズ可能とのこと。これは今回、私の登壇で解説したテーマにも通じる。

ここ 10 年ぐらいでフロントエンド部分の機能は多機能になり、Web ブラウザーのサンドボックス内でも高度なことができるようになった。またユーザーに近いためカスタマイズ面でもユーザー環境に応じた処理を実行しやすい。例えば Web アクセシビリティーのように利便を向上するものや、ド派手な演出など。

私の開発している Redmine テーマ minimalflat2 でもプロジェクト一覧を展開可能ツリーで表示しているが、これはフロントエンド完結している。

パネル ディスカッション

メンバー内で沢渡あまねさんは初めてお会いした。ちなみに聴講時の座席は隣。自己紹介によればマネージメント系に通じているようで、著書もこのジャンルが中心。対する門屋さんもマネージメントや Redmine エバンジェリストとして長く活動されているので、白熱しそうだ。お二人をりょうまさんがモデレートし、akipii さんが補助するような感じで進行。

題に「なじむ」とあり、私が redmine.tokyo 14 で登壇した際の なじむ Redmine を思い出しながら聞いていた。

チケットを切れる人とそうでない人の違いはなにか。仕組みや教育で促進できるものなのか。これについては資料とディスカッションの分析が的確で大いに同意する。「大事なのは 議論し続けること」で締めくくられている点もよい。こうしたマネージメント話は継続してゆくことが重要なのだ。

一方でもっと身近で即物的な課題もあるのでは？と感じた。私も職場に Redmine をなじませようとしてある程度は浸透したが、依然としてチケット管理を利用しない人たちがいる。ただしそうした人たちも Wiki は熱心に書くし、Redmine と併用している Slack で積極的に発言する。ストック面からは好ましくないが口頭の議論も盛んだ。

これらの違いはなんだろう。私としては Redmine のチケット UI と操作に忌避感を抱かれているのが一因だと推測している。

この箇所はぜひ Redmine のチケット編集画面を眺めながら読んでほしいのだが、まず入力欄が多すぎる。多機能な編集機能を持つのだから当然とはいえ、普段のチケット編集において、これらの UI の内のどれだけを操作するだろうか。

対する Redmine Wiki、Slack、口頭の入力はほぼ単一である。Wiki と Slack は基本的にテキストエリアだけを意識していればよい。口頭に至っては発声するだけだ。操作対象の少なさは判断の労力を減らす。これはストレスにも相関するだろう。

チケット操作に慣れていると、どの入力欄も必要なことは理解できる。しかしそれでも題名の編集頻度は少ないから説明欄のように折りたたんでほしいし、開始日と期日を変更するのは余程のことなので隠してもよいと思っている。

UI 以外には「操作の記録がすべて見える」のも抵抗を感じる点だろう。これは UI と関係していて、例えば編集時に「題名」がフォーカスされている状態で意図せぬ文字入力をしてから Enter を押すと、それで変更が確定する。そして履歴に晒される。

Redmine Wiki や Slack も編集は可能だが、標準では最終形だけが見える。そのため操作ミスなどで不本意なことを書いても、修正すれば「なかったことにできる」のだ。口頭も然り。こちらはそもそも意図的に記録しなければ消える。

プログラマーとしてはデータのバージョン管理になじんでいて、過程を記録することの重要性を理解しているのだが、綺麗な最終形だけを見せたいという人もかなりいる事に気付かされた。SNS で過去ログを掘り起こされるのを嫌ったり、いっそアカウントごと定期的に消す人がいたりするのも、このあたりが要因なのだろう。

以上を踏まえた即物的な解決案。

  • チケット編集画面 UI の簡素化
    • 更新頻度の高いものだけ表示して、それ以外は折りたたむ
    • 例えば注釈、作業時間、進捗率だけにする
    • ユーザーやプロジェクトによって更新頻度の違いがあるかもしれないので、設定から対象 UI を選べると更によし
  • チケット履歴を注記以外、折りたたむか非表示にする
    • 編集画面 UI と同様に存在しているが見えにくくする
    • 注記は本人ならその場で修正可能なので、Wiki や Slack のような使用感に近づくはず

これらについてはもう少し練ってから redmine.org へ提案するかもしれない。

グループ ディスカッション

時間がかなり押しており、簡単な自己紹介と一つの話題で終わる。

私のグループではプラグイン運用の問題が挙げられた。よいプラグインを見つけて業務もそれを前提に組んだのだが、更新が止まり最新の Redmine へ対応していない。そして業務は人間と組織の調整が必要なため、Redmine 側の更新を諦めるほうが容易いだろう。

これについては拡張可能な設計を採用した時点で Redmine に限らず発生すること。過去の redmine.tokyo でもよく話題に挙げられてきた。しかし残念ながらよい対策は思いつかない。私が職場の Redmine にプラグインを採用しない理由もこの点にある。

もしそれでもプラグインを入れるとしたら、

  • 小さく拡張するもの
    • なくなっても影響が小さい
    • 標準機能で代替しやすい、戻しやすい
  • 商用
    • 代表としては Lychee Redmine
    • 持続性とサポートの観点で評価する

を意識するのがよいだろう。The 凡庸、な回答だが Redmine は「タスク管理を担う = 業務の根幹をなす」ので安全第一にならざるを得ない。

まとめ

RedMica にはよい意味で驚いた。活発な開発者であり Redmine でビジネスもしている立場だからこその発想だ。JPL 氏やコミュニティーへの配慮からディストリビューションという形にしたことも素晴らしい。

定期リリースされることでユーザーが更新しやすくなり、これはフィードバックの増加にもつながるはず。そのため Redmine trunk にとってもよい影響があるのではないか。

登壇について。Redmine テーマ開発のハードルを下げたい。そしてもっと多くのテーマが作られるようになってほしい。という気持ちからスターターを公開したり、今回の登壇をおこなった。どうだろう？テーマを作りたい気持ちになった人は増えただろうか？

環境を整えても画像とか色彩のセンスがないから...と遠慮してしまう人もいるだろう。そういう人には私の minimalflat2 がそうしているように

  • 画像はアイコン フォントにする
    • Font Awesome や IcoMoon がオススメ
    • 画像をフォントに置き換える方法については minimalflat2 を参照のこと
  • 色彩
    • カラースキーム生成系サービスを利用する
    • 代表的なものだと Adobe Color や Paletton など

といった方法がある。ゲーム開発における Unity Asset Store のように、自分で作るのが難しいなら誰かが作った素材を集めてくればよい。現在はそういうサービスがたくさんある。いい時代になったものだ。もしテーマを作ってみたくなり相談したいことがあれば @akabekobeko までどうぞ。できるかぎり相談にのります。

総じて今回も楽しませていただいた。皆さん、ありがとうございます！！

Copyright © 2009 - 2023 akabeko.me All Rights Reserved.