アカベコマイリ

HEAR NOTHING SEE NOTHING SAY NOTHING

redmine.tokyo 15 所感

November 14, 2018イベントRedmine, redmine.tokyo

2018/11/10 (土) に参加した redmine.tokyo 15 のレポート。前回は登壇したが今回は聴講のみ。

開場前

  • 前回の参加で会場までの交通と時間を把握したつもりだったが、到着はギリギリになった
  • そのため田町駅でそばを食べるのを諦めてコンビニのサンドイッチに
  • 前回登壇していたのと Twitter でキャラ作りの一貫として前回と同じ格好でゆく、と書いたためか受け付けで私だと個体識別された
  • 時間ギリギリのため最後方端に座る、そのためスライドの下 1/3 ぐらいが見えない...

Redmine 4.0 新機能ピックアップ

Redmine 4.0 アウトライン

  • 機能追加とバグ修正は約 200 件、2018/11/9 時点の進捗率は 98%
  • Ruby on Rails 5.2 移行により多くのプラグインが要修正となるだろう
  • MySQL 5.1、PostgreSQL 9.1 以前がサポート外
    • RHEL/CentOS 6 系の yum 標準リポジトリーで入らないバージョン
    • 私が職場で運用している Redmine 環境が CentOS 6 系なので移行しなければならない
    • CentOS 7 へ移行するとして、ついでに Redmine と MySQL を Docker コンポーネント化することも検討したい
  • バージョン番号による変化の話
    • セマンティック バージョニング的な運用
    • Major = フレームワーク更新など大きな影響のあるもの、数年に一度
    • Minor = 多数の機能追加、年に数回
    • Patch = バグ修正や軽微な改善、発表にはなかったが過去の運用を見るに随時

新機能ピックアップ

  • Textile/Markdown プレビューのタブ化
    • GitHub のような感じになる
    • タブ切り替えでページ全体ロードにならなければ便利そう
    • 従来の下側表示は見辛かった
    • うちの Redmine は Markdown にしてあるので、チケットや Wiki に書くときはリアルタイム プレビュー付きエディター (Atom や vscode など) で編集してから貼り付けてた
    • 小〜中規模の文ならこの新プレビューでまかなえそう
  • コンテキストメニュー表示用アイコン
    • チケット一覧がコンテキストメニュー対応しているのに気づきにくい
    • そのため、メニュー表示アイコンを追加した
    • 確かにこの機能、教えるとビックリされる
    • メニューはチケット一覧から一気に担当やステータスを変えられるなど便利なので、この改善により周知されてほしい
  • チケットのウォッチャーで自分以外も選択可能に
    • この機能を前提とした新しい管理手法ができるかも？
    • 少し興味がある程度でウォッチャーに追加するような運用をしていると、フィルターとして有効に機能させるのは難しいそう
  • ユーザーのフィルターにロック中ユーザーを表示
    • 例えば退職したユーザーが担当になっているチケットを探せる
    • 昨年、ちょうどこの用途でこの機能を求めていた時期があった...
  • 親プロジェクトから子プロジェクトのチケットを作成
    • プロジェクト子へ切り替えずに済む
    • プロジェクトを細かく階層化しているなら便利そう
    • うちは極力、浅い階層に収める運用なので使い機会はなさそう
  • コメントの表示順が新しい順なら編集フォームを上に表示
    • 私はこの表示順で使用しているため、待望の機能だ
    • これまでフォームが最下段になるのは地味にストレスだった
    • 前述のプレビュー タブ化と並んで嬉しい
  • チケットリンクの新書式
    • ##123 と書くとトラッカーと題名も表示される
    • 議事録や Release Notes ページにチケット一覧を作成するなどで役立ちそう
    • いままでは普通のリンクでこれをおこなっていた
    • 普通のリンクだと題名変更などで手動追従が面倒だった、自動になるのはありがたい
  • 添付ファイルを連続プレビュー
    • プレビューに前へ次へボタンが追加
    • これらのボタンで前後移動できる
    • 画像はサムネイル表示して興味あるものだけクリックする感じだったから、プレビュー モードがあることを初めて知った
  • 添付された動画・音声ファイルの再生
    • プレビュー画面で再生可能になった
    • この流れで YouTube や Twitter 埋め込みにも対応してほしい
  • CSV エクスポート時にエンコード選択
    • CP932 以外も選択可能に
    • Excel 以外で読むため UTF-8 にできたりする
  • ユーザー一覧の CSV エクスポート
    • チーム単位をまとめてユーザー追加する際に便利そう
    • 受託などで取り引き先の関係者をまとめて追加する、という用途も考えられる
  • ガントチャート右クリックでコンテキスト メニューを表示
    • メニューからステータスや担当者の変更がおこなえる
    • ガントチャートを利用する動機づけの一助になるだろう
  • ガントチャートの表示幅リサイズ
    • ドラッグ & ドロップで変更可能になった
    • コンテキスト メニュー編集とこの機能の流れで、将来はグラフも標準でドラッグ & ドロップによる伸縮編集されることを期待する
  • マイページに活動ブロックを追加
    • マイページ、うちでは意外に使っている人がいるので喜ばれそう
  • リポジトリ画面のファイルと差分表示をタブで切り替え可能に
    • レビュー時に便利そう
    • 編集フォームやこれなど、画面遷移する箇所はタブ化を推進するのかな？
    • SPA 対応は難しくても静的に読み込んでおいたものをタブ切り替えするようにしておけば、画面遷移のストレスをなくせる
    • SPA 化の布石にもなるだろう、タブ切り替えを React や Vue のコンポーネント描画に移行すればよいので
  • シンタックス ハイライト対応言語が大幅に増えた
    • 約 20 から約 130 に
    • ライブラリーを CodeRay から Rogue へ移行した
    • Apache や nginx 設定ファイルなども対象に
    • これまで対応言語が少なすぎて指定なしにせざるを得ない場面が多々あったから非常に嬉しい
  • 動作環境の変更
    • 冒頭で触れていた環境面の話の詳細
    • MySQL 5.1 以前がサポート外に
    • PostgreSQL 9.1 以前がサポート外に
    • RHEL/CentOS 6 系は要注意
    • Ruby 2.5 対応、2.2.1 以前はサポート外
  • Redmine 4.0 は...
    • もうすぐリリース予定
    • 地味だが品質向上と小改善を重ねたバージョン

おまけ

  • Redmine に新機能が追加されるまで
    1. 誰かが redmine.org にチケットを作る
    2. 何かのきっかけ、ここで Redmine への疑問ツイートに前田氏がリプライしているスクリーンショット
    3. 誰かがパッチを書く
    4. 誰かがコミット
    5. 次期バージョンに入る
  • redmine.org のチケットは日本語 OK
    • 日本語で書いても Google 翻訳などを利用した英訳を併記してくれればよい
    • チケットを書くのが楽 (心理面でも) だし、日本人の開発者に意図が伝わりやすい
    • 私も GitHub issues で Google 翻訳に頼ることがある
    • 最近は精度もよくなってるので機械翻訳してから露骨な誤訳を手直し、というのは負担が少なくてよい

View customize 1.2.0 の紹介

View customize plugin について

  • Redmine の画面をカスタマイズ可能
  • 特定の画面に対して JavaScript や CSS を埋め込む
  • これを利用してプロジェクトのヘッダーを変更したり画面の動作を変えられる
  • Web フロントエンド部分を操作するだけ、というのがポイントで Redmine を再起動せずにカスタマイズできる
  • 参考 View customize pluginを使いこなす

v1.2.0

  • リリース内容
    • コード挿入一を選択可能に
    • ユーザーやプロジェクト情報へ JavaScript からアクセス可能に
    • ローカライズ対応、日本語リソースを追加した
    • コメント欄を追加、一覧表示でコメントがあればそちらを表示
    • 一覧をソート可能に
    • ...etc
  • コード挿入位置の選択 (Insertion position)
    • Insertion position という項目を追加、コードをヘッダー以外の場所へ埋め込める
    • 挿入位置を利用した制御について紹介
    • Redmine の操作で DOM 構造が変化した際、挿入位置によっては一緒に再構築されるためデータ変更に自動で追従できる
    • 埋め込み位置が存在しないページではコード埋め込み処理がスキップされる
    • スキップを応用して Path pattern (埋め込み対象ページ) を .* で全対象にしておき、Insertion position で制御するテクニックもあり
  • ユーザーやプロジェクト情報へ JavaScript からアクセス可能に
    • Twitter でこの情報は動的 or 静的取得のどちらだろう？と書いたら静的だと教えていただいた
    • 静的ゆえリアルタイムな変更追従は無理だが実運用で困ることは滅多にないだろう
    • ViewCustomize.context から参照可能
    • 情報が増えたことにとり View customize 側を変更しなくてもユーザーの JavaScript で処理できる範囲が広がる
    • 例えばグループ情報を利用してスクリプトの適用を特定ユーザーに限定する、など
  • カスタムフィールドを使った制御
  • ユーザーのカスタムフィールド
    • ユーザー自身が情報を追加できるのは大きい
    • 他システムやサービスの token を入力して、それと連携するとか
  • ローカライズ対応
    • 日本人にとって UI などが母国語でないだけで利用時のハードルが上がる、これを解消
    • 他の言語もがんばりたい
  • 一覧をソート可能に、コメント欄を追加
    • View customize 一覧の項目にコメントがあればそれを、なければ従来どおりコードを表示するようになった
    • 説明を書く際、従来はコード冒頭にコード ドキュメントとして記述するしかなかったが、これからはコードと切り離されたコメントを管理できようになったためコードを汚さずに済む

redmine導入における効果的なヒント

導入ヒントの概要

  • マズローの欲求 5 段階説などをベースに図示
    • チームのふるまい、利用したい業務、定着までの難敵を整理
    • 難敵の解決や利用業務の定着に必要な「さくせん」を考案、ここで「とくぎ」の概要をまとめる
    • 「さくせん」に基づき「とくぎ」を詳細化
  • 前回の LT に続き、国産 RPG などでよく用いられる「さくせん」や「とくぎ」などの語を採用
  • 目的を達成する動機づけとして近年ゲーミフィケーションの引用される機会が増えた
  • ゲームに親しむものとしては、楽しみながら自然とゲーム攻略のために分析や対策を練っているもので Redmine のようなタスク管理システムも似た存在だと感じている
  • よってゲーム、特に RPG やストラテジー系シミュレーションの世界観は Redmine の理解に有効ではなかろうか？

効果的な導入に向けての研究方針

  • チームのふるまいと対象業務 = マズローの欲求 5 段階説
  • 難敵 = TOC の抵抗の 6 階層
  • さくせん = 難敵の克服、対象業務の精度・成熟度の向上と維持
  • とくぎ = 武器と防具、仲間、魔法

本編

  • マズローの欲求 5 段階説と TOC の抵抗の 6 階層について
  • 難敵を克服して対象業務の制度と熟練度をあげる
  • マズローの話
  • TOC、あとで調べる
  • 自律的ナレッジを目指すために
  • 抵抗の 6 階層について、よくある意見をまとめてみる
  • 「さくせん」と「とくぎ」の内訳
  • 心理的安全性の話
    • 心理的安全性は意図的に作るものではなく後からついてくるもの
    • チケットや Wiki に何かを書いておくと、誰かがそれを見て助けてくれる
    • これは心理的安全性を意図したものではなく、課題や問題を衆目に晒すことにより結果として助けを得られたことになる
    • このような体験が重なることで、課題は問題を自己検閲 (こんなの書いて意味あるのだろうか？的な) するよりもいっそ書き出したほうがよい = 忌憚なく出力する = 心理的安全性が確保された状態になるのではないか
  • 仲間の話
    • どういう人が関わると Redmine をうまく回せるか？
    • 職場ではここに挙げられてるような活動をしている、Redmine 管理者であり、方針の提案やヘルプもおこなう
    • 前回の私の登壇でもこのあたりの話をした
  • 人に聞くなチケットに聞け
    • いま私の職場でも課題になっている問題
    • Redmine 以外にも Slack があるため、そちらで作業依頼と相談がおこなわれる
    • Slack ならテキストな分、まだよくて口頭もかなり多い
    • 部署単位で席が近いゆえ、口頭のほうが早いというのもある
    • テキストで対話することに抵抗を持っている人が多いと感じる
    • テキストはきちんと推敲されたものにしなければ、という雰囲気
    • もっと気軽に、という話を常々しているのだけど長年の文化的なものなのでなかなか理解されない
    • プログラマーであれば BTS としての導入動機があり、チケット蓄積で過去の仕様決定やバグ修正の考察を知れるため「チケットに聞け」の利点をわかりやすく体感できるのだが...
    • これを「説明」するのではなく、なんとか「体験」させたいのがここ数年の私の課題
    • うちの場合、Wiki はよく使われているので「Wiki に聞け」は受け入れられている感じ
    • Wiki は書きっぱなし可能だが、チケットで「対話」するのに抵抗があるのだろう
  • Redmine アップデート センターはよ
    • この意見は様々な人が言及してる
    • インストールと互換検証が自動化されたうえで導入されれば、プラグインやテーマを積極採用できる
    • うちはプラグインによる環境破壊 (実際、Redmime が起動しなくなった経験を何度もしている...) を避けるため排除しているのだが、本当は導入したい
    • アップデート センターやプラグインとテーマの配布システムを構築する気がないのであれば、著名プラグイン (前述の View customize とか) を本体に取り込んでほしいものだ
    • Redine を Docker 運用すれば気軽に環境を捨てたり再構築できるため、本体・本家に頼らずプラグイン運用しやすくなるかもしれない
  • 発表速度
    • 前回のブログで速度について書いたためか、登壇後に今回の速度はどうだった？と氏に尋ねられる
    • 前回を 2 倍速としたら今回は 1.2 倍速と回答

Redmine使いが注目したJIRAの機能

JIRA のイケてる機能

  • カスタムフィルター
    • Redmine でもおなじみ、チケットなどをフィルタリングするための機能
    • ベーシック モードは Form UI を操作する、よくある形式
    • JQL という簡易スクリプトで条件式をかける
    • 複雑な UI を用意するのではなく、いっそスクリプトで対応しようというのが面白い
    • ありがちな AND と OR 以外に WAS というのがある、現在または過去にその値が設定されているか？という機能
    • スクリプトは学習コストこそ嵩むが自由度は高く、テキストなので理解していないユーザーとも共有しやすい (コピペで済む) メリットがある
  • アジャイル機能
    • かんばん
    • バックログとスプリント
    • レポート機能が強力、分析好きにはたまらないだろう、企業や大きなチームを対象としているであろう商用ソフトウェアらしさともいえる
  • イベントと通知
    • イベント = チケットの内部フック
    • イベント単位のメール通知、Redmine に比べてかなり細かく挙動を制御できるようだ
  • チケット ワークフロー
    • ステータス遷移のカスタマイズ
    • ワークフローのダイアグラム表示がよい感じ
    • Redmine のマトリクス形式も「この範疇を超えることはやるべからず」という複雑化を防ぐためのギプスとして好ましいとは思うけど、複雑にならざるを得ないならダイアグラムかスクリプトを必要とするだろう
    • 簡易的な承認フローの実装

Confluence 連携

アップデート機能

  • 標準でアドオンのインストールと更新を自動管理する仕組みが提供されている
    • アドオン登録することでサブスクリプションによる収益を期待できる
    • これはアドオンを継続的にメンテナンスする動機づけになる
    • 結果、アドオンが死ににくい
  • アドオンはマーケットプレイスで提供
  • ビジネスとして回せているらしく、もりのあさ氏の企業で導入しているアドオンは結構な額を支払っているとのこと
  • Redmine にもこうなって欲しくはあるが、大手資本とビジネス専任者がいないと企画倒れになるだろう
  • Redmine が参考にするとしたら WordPress.com あたりか

困ったところ

  • WBS が組みづらい
    • エピック、ストーリー or タスク、サブ タスクの計 3 階層まで
    • Redmine のように階層を細かく深く管理できない
  • 機能が多すぎて稼働させるまで時間がかかる
    • 「とりあえず動かす」には心理的に重い
    • Redmine だとプロジェクトの立ち上げは機能的にも心理的にも軽すぎて縛りを入れないと雑にプロジェクトを量産できる問題がある、うちも社員個人が Wiki を分けるためだけにプロジェクトを量産してて収束させるのに苦労した
    • WBS もそうだけど、ゆるさと厳しさ (縛り) のさじ加減は難しい
  • 大半はシステム管理者しか触れないため負荷が集中する
    • Redmine だとプロジェクト単位の管理者に機能管理の相当部分を委譲できるから分割統治に向く
    • 一方、運用ルールを明確にしないとプロジェクト管理者ごとに全くことなる運営をしてプロジェクト間のやりとりで問題になったりする
    • 完全な専任を立てられれば JIRA の一極集中も悪くはない
    • 私は分割統治の利点のほうが大きいと思うので Redmine 方式でルール縛りするほうが好み

ある工場の Redmine 2018 ー私が愛用しているプラグインー

最近のできごと

  • Redmine 絡みで IoT やってる
  • 前回のデモは面白かった
  • 今回のデモ、スマートフォンのロックを解除してください、ショートしました？、で失敗 (会場笑)

いいプラグインを使おう

  • プラグインを使うと魅力的な機能が入る
    • しかしバージョンアップ検証が大変
    • でもプラグインを使いたい
    • いいプラグインを使えばいい
    • プラグインの信用度をもって「いい」としている
    • 評価が高かったりちゃんとメンテされていたり
  • 使用しているプラグインの紹介
    • 今回登壇で紹介された View customize や Issue Template など
  • プラグイン使わない派の私としては色々と考えさせられた登壇
    • 私がプラグインを使わない理由は互換性と環境破壊
    • 本登壇で「いいプラグイン」とされているものなら「現在は」問題はないだろう
    • しかし「これからは」については作者に委ねられている
    • Redmine のシステムとして互換性を自動検証する仕組みがないと「作者の努力」に依存することとなり、ここが不安
    • これさえ解決すれば入れたいプラグインはいくつもある
    • WordPress プラグインの場合、自動更新、互換性の自動検証、ユーザー レビューがあるため安心して利用できる
    • Redmine として導入しやすいのは互換性の自動検証だろう、Manifest 的な設定を用意して対応バージョン範囲を明記し、それが本体と一致しないなら無効化すればよい
    • 環境破壊の問題はグループ ディスカッションでも議論した

LT

プロジェクト管理ソフトの群雄割拠をどうやって勝ち抜くか？②

  • 岩崎成記氏
  • 資料
  • リソース予約プラグイン
  • JavaScript の fullcalendar を使用
  • プラグイン開発メモ
  • Ruby on Rails 学習 400、開発 300 時間を費やす
  • Ruby on Rails 以外にも DB など広範な知識が必要
  • よい IDE 見つからず、エディタによる開発、毎回 Redmine リロード
  • テスト環境を用意するもの大変
  • プラグインではなくテーマだが動作確認は Docker がオススメ
    • Redmine コンテナを sameersbn/redmine にすれば複数バージョンも同時に試せる
    • 私は Docker Compose で sameersbn/redmine と mysql を連携して動かしてる
    • ファイル システムのマウント方法による違いのためか、Vagrant だと CSS/JS が更新されても Redmine 本体をリロードするまで反映されないが Docker は Web ブラウザーのリロードで即時反映される
    • Docker は起動と終了も高速なので気軽に動作テストできて嬉しい
  • Vagrant なら onozaty 氏の Redmine Vagrant Box シリーズがよい
    • Redmine のバージョン追従も迅速
    • Docker 移行前はこれを利用していた

あなたは、ねぎ派？ぶどう派？『JavaScriptで選択を便利に』

  • yamasaki24氏
  • 資料
  • Redmine の画面カスタマイズは JavaScript でおこなえる
  • 実例として複数 select box の連携をとりあげる
  • 大項目、中項目の select box がある
  • 大項目でアイテムを選ぶと中項目がそれにあわせて絞り込まれる
  • 実装の解説
  • ガントチャートのバーを動かす話、これは本体側に取り入れてほしい

Redmine本家コピー＋投票サイト作成 (Python-Redmine 利用事例)

  • y503Unavailable 氏
  • Redmine本家コピー＋投票サイト作成(Python-Redmine利用事例）
  • Redmine への要求レベルは高度化する
  • Redmine 自体に手を入れず汎用言語によりユーザー自身が手を入れられるようにする
  • Python-Redmine を利用して複数 Redmine からデータをコピー
  • チケット画面に投票とタグ機能を追加
  • 作成手順と環境について
  • Redmine は VPS に Ansible で入れている
  • Python-Redmine で外部から Redmine を操作可能

基本手順の順守

  • 齋藤氏
  • 基本手順の順守と redmine
  • マネージメントの話
  • 議事メモ
    • 私が会議のオーナーでは似たような感じで運用している
    • いわゆる議事録ドリブン
    • 事前に課題 (あれば補足も) を箇条書きした Redmine Wiki を作成、これを議事録の候補とする
    • 事前に議事録の候補を読んでもらってから会議を実行
    • 開始は議事録の候補をプロジェクターなどで投影、課題に発言や決定事項をリアルタイムに書きながら進行
    • 司会 (オーナー) は書紀を兼ねる、エディターのスクロールがそのまま会議の進行になる
    • 司会能力とタイピング速度の両方を要求されるので難しそうだが、実際は議題を読んで各人の意見をタイピングするだけでも場が持つので司会能力はそれほど必要ない
    • 議事録の候補段階で、この登壇で示された要素を書けていれば更に楽だろう
    • 逆にこの程度は用意して事前に読んでもらう (共有してもらう) ぐらいでないと、人を集めて話しても無駄な雑談や脱線が増えるだけだとも思う
  • 課題管理
    • チケット発行基準で「発生翌日までに自分で対応可能なものは除き」というのは面白い
    • 既にチケット運用できているならよいが、これからチケット管理を取り入れるチームは工数よりも手を動かしたいだろうから心理手面で導入によいルールである
    • 私は些細なメモや考えごともチケットで、というようにチケット作成の雑さを許容して「チケット運用経験」を先に積んでもらう方法を採っている
    • チケット運用 = 起票して終了する、という経験を積んでもらってからの方がタスク管理について説明しやすいと考えている
    • なにかを学習する入門方法として経験と理論のどちらを優先するか？という話
  • 計画管理
    • トップ ダウン、ボトム アップどちらを採るか？で変わる話
    • メンテナンスの負担を考慮する、というのはよい視点

小さく始めるRedmine

  • びくんびくん氏、読み上げるだけで笑みのこぼれる命名を見習いたい
  • 小さく始めるRedmine 第15回redmine.tokyo勉強会LT資料 - Speaker Deck
  • Redmine 導入にかつて失敗している
  • 再導入にあたり気をつけたこと
  • いろいろ制限する
  • プラグインも View customize ぐらい
  • 禁止事項をひたすら列挙
  • Redmine アンチパターン、よくわかる
    • リテラシーの話をすると知識を持つ側が教条主義に陥りがちで、私もそうなることがある
    • 味方を増やすのが最優先、そのためにはリテラシーよりも具体的な方法を
    • 「具体的な方法」としてルールや入力項目が多すぎるとビビらせてしまうので、本登壇のように積極的に縛って見えるもの触れるものを減らすのは有効
    • うちはトラッカーを減らした、標準で有効になってる開始日や工数、進捗率も削除したいぐらい
    • GitHub issues + 担当者、ぐらいだと受け入れてもらいやすそう

Redmine Rest API の現在の困りごと

Redmine Community on Discord (Video Message)

  • Max Johansson 氏
  • Redmine on Discord: Intro - YouTube
  • Discord の動画メッセージ
  • 設備や通信のトラブルか、Max 氏とのオンライン対話がなかなかうまくゆかず
  • 会場から Max 氏への質問、そちらでの Redmine を取り巻く状況はどのような感じか？
    • Redmine を使っている人はあまりいない、Gitlab とか使っている
    • コミュニティを立ち上げたことで状況がかわるかもしれない
    • ボランティアでやってる、今後に期待している

今後のRedmineコミュニティの方向性について

  • akipii 氏
  • 今後のRedmineコミュニティの方向性について #redmineT
  • コミュニティをどのように発展させるべきか？
  • 1 スタッフとしての意見
  • Redmine は日本人に向いているのでは？
  • 大阪と東京、ふたつのコミュニティが 2011 年からゆるく長く続いている
  • コミッターが JPL 氏を含めて 3 名というのは知らなかった
    • コミュニティーを拡大しても要望反映のリソース不足が問題になりそう
    • 3 名にしては非常によくやっているとは思うけど、心配

Redmine本、売ってみた。

  • たかのあきこ氏
  • 今回は欠席？時間がかなり押しているので登壇はスキップしてひとまずグループ ディスカッションに移行
  • 17:40 に合流、開始
  • どうやら保護者会があったそうで、そのため遅れたとのこと
  • スライドが手書きイラストになっててよい、絵が描けるのは強み
  • 本書、技術書典 5 でブースを訪れた時は売り切れていた
    • なので挨拶だけでも、と話しかけたらご厚意によりコピー本をいただいた
    • 感想は後ほど技術書典 5 感想の頒布物編としてブログに書く予定
    • 本書の感想は既に書いたのだが、他に大ボリューム本がいくつかあってなかなか記事がまとまらない...

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

Redmine テーマ開発

  • 私のほうから Redmine テーマについて議題をだす
  • redmine.tokyo 14、15 と参加したが Redmine テーマに関する話はほとんどないため
  • 今回だと Max 氏のコミュニティー話で Redmine 標準テーマのモダーン化が検討されている、というものぐらい
  • Redmine 標準テーマ以外を使っていますか？→GitHub 風テーマ (多分 makotokw/redmine-theme-gitmike) が 1 名、あと確か A1 がいて、他の人は標準テーマだった気がする
  • プラグインだと具体的な機能拡張が動機になる
  • テーマは外観が変わるだけなのと、外観の変化による違和感への抵抗により避けられているのでは？
  • 標準テーマでもそれなりな見た目なのもあるだろう
  • プラグインにも言えることだが、Redmine バージョン更新に追従できてないテーマを経験するとプラグインほどには導入動機が高くないので使用を断念するというのもありそう
  • テーマ開発の話
    • 実際に私が minimalflat2 の開発をどのようにおこなっているかデモ
    • SCSS を編集するとリアルタイムで CSS に Transpile され、Web ブラウザー表示が更新される話
    • Docker を使うと Redmine を実際に動かしながらテーマ開発できる話、こちらは Web ブラウザー自動更新できない (フック方法を検討中) ので手動更新としている

プラグインの課題

  • Redmine プラグインは専用の API を用意しておらず、直に DB や UI を操作する
  • そのため Redmine バージョン互換を意識しないと容易に環境が壊れる
  • かといって今から API を整備するか？というと難しそう
  • せめてバージョンの自動検証は実装したほうがよいのでは？
  • 既存チケットになければ私がこの案を登録するかも
Copyright © 2009 - 2023 akabeko.me All Rights Reserved.