redmine.tokyo 14 で登壇してみた

2018年5月28日 0 イベント ,

2018/5/26 (土) に redmine.tokyo 14 へ参加 & 登壇。以下、レポっす。

開場前

  • 最寄りは都営浅草線の泉岳寺駅だが、自宅からのルートだと乗り換えが面倒なので京浜東北線の田町駅へ
  • 田町駅で昼食、「いろり庵きらく」の「板そば」を頼んだらボリュームかなり多くて食べきれるか心配だったので飲み込む感じで処理
  • 国際興業三田第 2 ビル、休日なので通用口から入るとのことだが案内してくれる方がいたので迷わず入れた
  • 会場には 12:30 ぐらいに到着、着席
  • 開始までの時間に持参 PC のプロジェクター接続確認してほしいとのこと
  • ここでケーブル忘れに気づく、というか会場にあるのを期待する他力本願メソッドにも程があって、つまりは迷惑かけてしまったスミマセン
  • MacBook Air 2011 だと DisplayPort が必要、会場の方から借りて事なきを得る
  • ケーブルを貸していただいた方の顔を思い出せず @akipii 氏に託したのだが、その後どうなったのだろうか?
  • もしケーブルが戻られていない場合は補填・弁償したいので申し訳ないのですが @akabekobeko まで連絡ください
  • 会場、けっこう埋まっている
  • メイン会場はキャパ 60 人ほど、サブ会場は YouTube 配信をみる感じらしい
  • 会場のスクリーンは 2 種類、スライドと Twitter の #redmineT を映しているもの
  • ハッシュのほうは反応がリアルタイムに更新されてゆくので見てて飽きない

Redmine をちょっと便利に!プログラミング無しで使ってみる REST API

  • プログラミング無しで使ってみるREST API
  • ファーエンドテクノロジー株式会社 前田剛氏 @g_maeda
  • Redmine コミッターとして有名な方
  • curl、jq コマンドを利用して Redmine REST API を操作する
  • Redmine のデータへ Web UI を経由せずにアクセスするための手段
  • HTTP リクエストすると XML or JSON を返す
  • 例えば GET /users/1.json で user ID 1 のユーザー情報を JSON で得られる

REST API だと嬉しいこと

  • 他のシステムから Redmine を操作できる
  • 自動化、チャットボットなど
  • Web UI 操作では難しいことも実現できる

ツール例

REST API 利用準備

  • コマンドラインから API を利用
  • 今回は JSON にします
  • OS は Ubuntu か macOS を想定
  • Redmine の管理画面から「RESTによるWebサービスを有効にする」を ON にすることで許可
  • jq というツールを用意、sudo apt-get install jqbrew install jq で入手
  • アクセスできるかテストしてみる、Terminal に JSON がでれば OK

API で遊んでみる

  • ユーザー情報一覧の取得
  • curl で REST API を呼び、返された JSON を jq で整形する
  • ユーザー情報一覧を CSV に変換してみる、これも jq でいける
  • Redmine にはユーザー情報一覧のエクスポート機能がないため、このテスト時点で Redmine 以上のことを実行できていることになります
  • 応用でユーザーの一括登録もおこなえます
  • チケットの題名を正規表現で探してみる、Redmine では OR 検索できないが、正規表現ならなんでもあり

REST API 活用 TIPS

  • URL の拡張子で XML or JSON が決まる
  • コマンドラインから利用するなら処理しやすい JSON がオススメ、なにより jq が便利
  • 一部のオブジェクトはアクセスに Redmine システム管理者の権限が必要
  • デバッグには curl の -v オプションが便利、HTTP 通信内容を出力できる
  • というか -v つけないとエラー情報すらでない

質疑応答

  • Q. REST API でできて Redmine の Web UI の提供していない操作があるのはなぜ?
    • Web UI の方に手が回ってないだけです
  • Q. REST API、ドキュメントだとベータ版となっている箇所があったりするけど大丈夫?
    • ベータなどのステータスが更新されてないだけです
    • 十分にテストされている (Redmne では自動テストを重視している) ので実用上は問題ないと思われます

Redmine と他システムの連動事例

  • 資料みつけられず
  • 山崎進氏
  • 与えよさらば与えられん
  • 受けるより与えるほうが幸いである
  • 聖書にある言葉、OSS 活動の精神と考えている
  • 今日の登壇もその動機から

MS-Project から Redmine への情報移行

  • MS-Project を XML 出力
  • github に公開されている msproject-import というプラグインで Redmine にインポート

Slack と Redmine の情報移行

  • Redmine から Slack へ
    • アプリを追加する設定で incmming webhook を選択
    • Web Hook 用 URL が表示されるのでメモ
    • Redmine 側、github に公開されている redmine-slack というプラグインをインストール
    • プラグイン画面の入力欄にメモしておいた URL を指定
    • 例えばチケット登録すると Slack に通知がくる
  • Slack から Redmine へ
    • outgoing webhook を選択
    • REST API キーを入力する
    • Slack 側からチケット操作したりできる

Excel から Redmine へ

  • プラグインを利用
  • Excel 風の編集機能は Handsontable を利用
  • jQuery 経由とのこと、Redmine は標準で jQuery がバンドルされている
  • 例えば Redmine 上に非表示のテキストボックスを作成、テーブルに入力されるとテキストボックスに自動反映して Rdmine に Submit するような仕組みを使っている
  • カンマ区切りの文字列が送信されるので、サーバー側で解析して DB 反映

なじむ Redmine

  • なじむ Redmine
  • 私の登壇
  • YouTube 配信してるとのことなので YouTuber 風に「登壇してみた」とか「どーもアカベコです。今日は生放送されてるのでさしずめナマベコですかね?」みたいな感じで始める計画だったのだが…
  • akipii 氏による紹介で「アベコベさん?」と読み間違えられ、そちらのほうが面白かったので計画は破棄
  • #redmineT の書き込みとタイムキーパー用のチャイムが誤爆して何度も鳴るのがかなり気になる
  • 緊張し過ぎて時計みる余裕なかった、結果としてすこし時間オーバー

あとで #redmineT みたらよい反応が多くてホッとした。みなさん優しいですね。

LT

Redmine でデザインの強度作業 on リモートワーク

  • Redmineでデザインの共同作業onリモートワーク
  • 財部香織氏 @kaorabe
  • デザイン業務を Redmine でタスク管理している
  • ワークフロー説明、ブログ記事の場合
  • テキスト入稿、画像ラフ、Illustrator
  • 勘所
    • なるべく早く見られるもので PDCA 回すた
    • チケットにスケッチなどを添付しまくる
    • 注記で感謝を伝えることでコミュニケーションの潤滑油とする
  • …ここでチャイム
  • Redmine 同人誌出版を予定しているとのこと

途中でみえたチケット画面いい感じ。注記の区切りが吹き出しになっている箇所に惹かれる。自作テーマだろうか?

Redmine 同人誌は技術書展に出すのを目標という話をしていた。ちょうど先月、技術書展 4 に参加して刺激を受けたのと、社として関わり始めた XMLパブリッシング準研究会で 6/30 あたりに技術書展のサークル側の人と交流会を実施予定なので私としても興味ぶかい話である。

個人的には次の技術書展で Electron 本でもどうか?と考えていたのだが、この Redmine 本で参加するのも面白そうだ。私が書くとしたら minimalflat2 開発で得たテーマ開発まわりの話かな。

効果的な Redmine 導入のヒント

すごくよさそうな内容なのであとで資料を読む。

しかし 5 分の量ではない (22 ページある)。よって飛ばしまくり、しゃべりもあわせて高速化。大変そうだけどその様子が面白すぎた。時間操作系の能力者的ななにか。

LT 5 分ならスライド 10 ページ以内じゃないと厳しそう。昔、だれかに聞いた話では 1 ページ 1 分ぐらいで計算するとよいそうだ。高橋メソッドみたいな例外は除いて。

Redmine で契約を追え!

  • Redmineで契約を追え!
  • かるね氏 @nekosanz1
  • CI と向き合う事務員の戦い
  • インフラ屋の CI
  • 継続的… ではなく Configuretion Item のこと
  • 契約資料をだいじに
  • 契約のはじまりと終了
  • お客様と仕入先とかならず締結するもの
  • すべての物品はなんらかの契約書に結びつく
  • 難しいところ、数の暴力、契約数が多過ぎる
  • 時間経過による内容変化
  • ツール使えば管理できそうだけど?
    • 買ってもらえなかった…
    • なので Redmine で
  • チケット管理単位の話
  • チケットと体制
  • 1 年まわしてみて契約が迷子になることがなくなった
  • 機器や物品にチケット番号 = 契約番号を貼って管理、生きたチケット

チケット番号を物理的に貼るというのは面白い発想。Redmine が十分に浸透していればチケット番号は外部システムや現実社会でも資料へのポインターとして機能する。

Redmine 連携機能ソリューション紹介

  • スマートなテスト管理クラウド Qualityforward
  • syoshikawa0319 氏
  • QualityForward の話
  • 株式会社ベリサーブ
  • 効率的なテスト ツールを探している
  • BTS はレポートのみとおもっている
  • Quality Forword と Redmine 連携してもっと高度に管理
  • めちゃくちゃ飛ばす
  • Excel ライクな入力、集計
  • 効果など

Redmine として弱い部分をうまく補完している感じでよい。Redmine に絡めたビジネスが成立しているのだとしたら Redmine としても好ましいはず。

まったくの余談だが、大昔に在籍していたプロジェクトでベリサーブ社に検証を依頼していたのだが、やりとりのメールの宛名部分を「ベリサーブ殿」としていたのを見たメンバーの誰かが「ベリサーブでん」と読み、その音のインパクトからしばらく「〜殿」を「〜でん」と読むのが流行ったのを思い出した。

この話を懇親会でしようかと思っていたが機会なかったので、ここに記す。いい話でもなんでもないけれど。

プロジェクト管理ソフトの群雄割拠をどう勝ち抜くか?

  • 資料みつけられず
  • 岩崎成記氏
  • Redmine、MS-Project、Excel、…etc
  • これらの比較用にプロジェクト管理を定量化してみた
  • 趣味は見える化、すごい
  • 状態変化モデルなど、きちんと計測、グラフ化してて納得感ある

実データと理詰めで Redmine のメリットを見える化している点に感心。

VIEW CUSTOMIZE から REST API を使用する

  • View CustomizeからREST APIを使用する
  • もりのあさ氏 @forenoonM
  • 寝坊しました、11 時におきてびっくりしました
  • 転職して Redmine から JIRA になった
  • いろいろ困ってるけど「ぜんぶおれがなんとかする」所存らしい
  • RedmineのJavaScriptからREST APIを使用するの実践編
  • View Customize (JavaScript) から REST API を呼び出す
  • API キーはどうする?
  • 個人設定ページの内容を読み込めばよいのでは?で解決
    • これはダイアログと sesionStorage で解決できそう
    • グループ ディスカッションで一緒になったのでこれを振ったら、当初はそうしようとしたがセッションの引き回しの関係でうまく動かなかったとのこと
  • サンプル、小チケットのコメント追加時に親チケットにもコピーする

スライド中の Redmine スクリーンショットを見るに minimalflat2 を利用しているようで嬉しい。

私は Redmine プラグインに懐疑的で、それはプラグイン自体ではなく配布と互換性を担保する標準の仕組みが提供されていないためである。ただしそれを今から構築するのは難しいだろう。よって、

不具合が起きても Redmine 本体をクラッシュさせることがなく、近年の機能強化が著しい JavaScript、つまり Redmine テーマ側で補完してゆくほうがよいのでは?と考えている。

例えば minimalflat2 ではプロジェクト一覧を開閉可能なメニュー化している。これは Web フロントエンド完結しているが、REST API を利用して Redmine 本体も操作するのはどうか。

本日もこのスライド以外に REST API で Redmine Web UI にない操作をする演目があった。URL を判定すれば画面を特定できるので、例えばガントチャート画面を WBS 風に編集できるとかも画面判定して REST API でチケット期限更新するとかで実現可能なのでは。

という感じのことをこの演目を聞いて考えていた。

redmine git work in progress プラグインの紹介

リポジトリー側の操作がチケットに影響するというコンセプトが面白い。標準でも特定のコミット コメントに応じた処理 (例に挙げられている refs とか) はあるが、この分野は可能性を感じるのでもっと実験されてほしい。

Redmine とスマートスピーカーを連携させてみた

  • Redmine とスマートスピーカー連携させてみた
  • Kohei Nakamura 氏 @netazone
  • スマートスピーカーはいいぞ
  • もってる人は挙手…数人
  • もってない人は拍手…万雷の拍手
  • チケット登録めんどくさい、スピーカーに話しかけるだけでチケット登録はどうか?
  • 実演、会場の反応が熱い
  • OK, Google、チケットを… で登録とか更新する、すごい
  • 仕組みは IFTTTGoogle Assistant、Redmine 連携
  • デバイス、IFTTT、Redmine の順に処理

プログラムわからなくても、これらの要素技術で手軽にこういうのができる時代みたいな話をしていたが、まさしくそうだし、この流れは加速してゆくだろう。

最前列に置かれた猫型?のオブジェが気になっていたのだけど、これがスマート スピーカーだった。ハードウェアが絡み、しかもわかりやすいデモなので会場の受けがよい。スマート スピーカーが持つ印象面の効果は無視できない強さがある。

余談だが @nekosanz1 と @netazone は字面が似ている。

パネル ディスカッション

  • Git と Redmine をどのように連携するのが効果的か
  • 司会は松谷秀久氏 @mattani
  • パネラーは楠川智久氏、川端光義氏、NAITOH Jun 氏 @naitoh

Redmine と GitLab の連携利用

  • Redmineとgitの 連携利用事例
  • 楠川智久氏 @tkusukawa
  • Redmine プラグイン WorkTimeWikiLists などを公開してます
  • 自分たちの Git 連携方法についてお話するので、それについて意見や議論したいです
  • システム的には Redmine サーバーから GitLab の Bare リポジトリーを参照
  • Git リポジトリー運用は master で開発して std と production リポジトリーでリリースする形式

Redmine 設定については私の会社と一緒。ウチは Gitflow 風に master でリリース、開発は develop ブランチという感じで運用してる。feature も develop から生やす。

Redmine と GitHub のうまい関係

  • RedmineとGitHubをゆるく使う
  • 株式会社アジャイルウェア 川端光義氏 @agilekawabata
  • アジャイルウェアのコード管理は GitHub
  • レビュー機能が重要、GitHub の PR はそこが優秀
  • エンジニアのための最適なレビュー プロセス
    • 品質向上
    • 集中できる環境
    • エンジニア育成
  • Redmine と連携しづらい
    • Redmine は同一サーバーに Bare リポジトリが必要
  • アジャイルウェアでは
    • マネージメント管理に Redmine
    • 開発は GitHub
  • Lychee Redmine と GitHub 連携

ディスカッション

  • 松谷氏は Git 未経験、SVN と Redmine 連携は利用している
  • SVN に比べて Git のよさってなんですか?
    • 楠川 もう SVN には戻れない、merge が楽、branch 切るのが楽、分散・集約については重視していない
    • 内藤 Redmine 上で PR したい、これを SVN & レビュー プラグインでおこなうとコミットされた後になってしまう、GitHub のように merge 前に PR でレビューしたい
    • 川端 エンジニアは他の人に迷惑かけたくない、SVN だと push しかないのだが Git だと細かく branch 切って他に影響しないように作業をすすめて必要におうじて merge するスタイルなのでエンジニアにとってよい
  • Redmine リポジトリー連携としてどうか、川端さんはおこなっていない (GitHub 管理)、楠川さんはおこなっている
    • 楠川 逆に我々は PR を使っていないのでそのメリットが理解できていない、そうではない部分としてチケットと Git コミットが関連づいているのはよい
    • 川端 エンジニアの開発とコミュニケーションが GitHub 完結しているので困っていない、ただしマネージメントの Redmine との動機はとれていない、齟齬は Slack などで解決、PR に Redmine チケットのリンクをはることはある
  • 対象的な事例だが、GitHub/GitLab と Redmine の使い分け、棲み分けについて聞きたい
    • 楠川 内藤さんのところはどうですか?
    • 内藤 プライベートは GitHub、仕事では Redimine だがローカルで git-svn つかってる、HTTP で Git 公開できないので気軽につかえない
    • ここで挙手して聴者側から参加、これは Gitolite はどうか?ここで Gitolite の仕組みについて説明
    • 内藤 社内規定 (?) におけるアカウント管理の関係があり Gitolite は採用できなさそう
  • このあとも盛り上がっていたが PC のバッテリーが尽きそうなのでメモはここまで
  • 開発者としては Git と GitHub を利用したい、マネージメント層としては Redmine 的なタスク管理のほうが向く、棲み分けるもの?Redmine の機能強化で GitHub 的なもの (PR など) を取り込み一元化できないか?といった感じの話になっていた

GitHub はすでにソフトウェア開発者の中で全世界的に標準インフラ化した感がある。多少の不便があっても運用や周辺ツールでなんとかしているから Redmine に取り込むとしたらかなりの強化が必要だろう。

私としては Redmine から Git リポジトリーを簡単に作成して連携まで自動化するのが第一歩。次に PR 対応するあたりでようやく勝負の入り口という感じ。

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

  • 145 名分のアンケート公開
    • Redmine プラグインのシェアなど
  • ディスカッションは 6 人ひと組
  • 登壇内容だったり、その他 Redmine に関するよもやま話をする時間
  • もりのあさ氏などと Redmine 運用や現場の話などで盛り上がる

懇親会

  • ItalianBar KIMURAYA 品川 (キムラヤ)にて懇親会
  • redmine.tokyo の会場から徒歩 20 〜 30 分ぐらい
  • 徒歩組とタクシー組にわかれる、乗り合いならワンメーターちょっとでいけそうな感じなので私はタクシーで
  • 登壇に関する感想や Redmine 運用についていろいろと話す
  • 前田剛氏と Redmine の開発体制について議論
    • 英語力を気にせず redmine.org に参加してほしい
    • Google 翻訳と Ginger 英文チェッカー を通すぐらいでも案外、理解してもらえるのではないか、プロダクトに関する話であれば英語圏の人も拙さは汲み取ってくれるもの
    • Redmine の行く先に不安がある、バージョン系の多様に起因する開発リソース不足、互換性に縛られることで保守化して先進機能 (SPA 化など) へ取り組みにくくなっているのでは、redmine.org 自体が最新 Redmine を採用していないのは大丈夫なのか、…etc
    • 前田剛氏や他の Redmine 開発者もこうした問題点は理解しているのだが、対応に苦慮している
    • オフレコっぽい話もあったので、それは書かないでおく
  • @akipii 氏は Twitter のアイコンがヒグマ?の写真なので赤カブト的な人が来たらどうしようかと思っていたのだが、温厚そうな紳士で助かった

まとめ

自社むけなどは何度かプレゼンしたことがあるのだけど、そうではない一般向けに登壇するのは初めて。

そのため非常に緊張したのだが、結果としては登壇してよかった。

Twitter の #redmineT や懇親会での反応をみるにつけ、巧拙は気にせずリアルでもアウトプットすべきだと感じる。反応を得てこそ。ブログや Twitter でも反応してくれる人はいるが、その場で生の熱意を受けるのは特別な体験である。

以前の私はリアルな交流の内輪ノリが好きになれなくて避けてきた。しかしここ数年、現職の社長や営業の意向もあってセミナーや勉強会で交流を広めるようにしている。こういうのも視野を拡大するために必要なことだと考えるようになった。

そうした経験の一環として redmine.tokyo 登壇はよい機会で、今後も関わっていけたらな、と思っている。

Redmine テーマ minimalflat2 v1.3.5 リリース

2017年11月6日 0 開発 ,

Redmine テーマ minimalflat2 v1.3.5 をリリースした。

Redmine v3.4.3 対応

以下の問題が報告されたので

Redmine v3.4.2 と v3.4.3 の application.css を比較して変更点を反映してから修正しようとした。結果、CSS の差分はこの問題に対するものだけであることが判明。

よって Redmine v3.4.3 対応ついでに、チケット一覧のバージョン条件リストに名前の長いものがあっても省略されず表示するようになった。

マイページ画面の table が見切れる問題の修正

だいぶ前に報告されて放置してた

When “my project” is displayed in 1 column mode, the table protrudes – Issue #117

を修正した。マイページ画面を表示しながら Web ブラウザーの幅を狭めて 1 カラムにすると table が見切れる。標準テーマでは起きないとのことなので調べたら、

  • 標準テーマは body に font-size: 12px を指定している
  • そのため「たまたま」表示幅を狭めても table のコンテンツが収まる
  • minimalflat2 は特別な箇所をのぞき font-size は指定しない設計方針
  • そのため Web ブラウザーの文字サイズによっては table コンテンツがはみ出る = 見切れる

ということがわかった。短絡的に修正するなら標準テーマ同様に bodyfont-size: 12px を指定すれば済む。しかし現在の設計方針はユーザーの文字サイズを維持するためのものであり、ひとつの問題のため変えたくはない。マイページの table 限定で直すことも可能だが、ここだけ文字サイズが小さくなるのも収まりが悪い。

というわけで修正を断ろうとしたのだが、マイページをよく観察すると「ウォッチしているチケット」などの table は表示幅が狭くなったときに横スクロールバーを提供している。HTML の構造としては

<div class="autoscroll">
  <table class="list issues odd-even sort-by-updated-on sort-desc">
  </table>
</div>

こんな感じになっていて、table の親となる <div class="autoscroll">

.autoscroll {
  overflow-x: auto;
  padding: 1px;
  margin-bottom: 1.2em;
  position: relative;
}

となっているおかげでスクロール可能になっていた。ならば「作業時間」などの table もこれを指定すれば?と思うだろう。しかしわざわざ <div class="autoscroll"> が用意されていることから分かるように table へ指定してもダメだ。可変幅の table にしたければスクロールは外周の div が担当しなければならない。

というわけで theme.js 側に以下の関数を定義して実行するようにした。

// The table can be scrolled when "My Page" is displayed in one column
function setupMyPageAutoScroll () {
  $('#my-page table').each(function () {
    var parent = $(this).parent()
    if (parent.hasClass('autoscroll')) {
      return
    }

    $(this).wrap($('<div class="autoscroll"></div>'))
  })
}

<div class="autoscroll"> で囲われていない table 限定で囲いなおしている。これで無事、他の table も横スクロール可能となった。

設計的に一部の table だけスクロール可能になってるのは統一感がなくておかしいため、将来の Redmine では同様の修正が入るかもしれない。その場合でも処理的に誤動作することはないはず。

Redmine テーマ minimalflat2 v1.3.0 リリース

2017年7月16日 0 開発 , ,

Redmine 3.4 がリリースされたので minimalflat2 も対応した。

以下、開発メモ。

Stylus 定義を標準 application.css にあわせる

minimalflat2 の CSS は Stylus で記述して application.cssresponsive.css へコンパイルしている。Stylus の代表的な機能には透過的な変数参照、Mix-In、クラスのネストがあってこれまで便利に利用してきたのだけど、本バージョンからネストは控え目にした。

ネストによってクラス定義の冗長さは軽減される。例えば

#top-menu {background: #3E5B76; color: #fff; height:1.8em; font-size: 0.8em; padding: 2px 2px 0px 6px;}
#top-menu ul {margin: 0;  padding: 0;}
#top-menu li {
  float:left;
  list-style-type:none;
  margin: 0px 0px 0px 0px;
  padding: 0px 0px 0px 0px;
  white-space:nowrap;
}

のように同一 id やクラスを親としているものは

#top-menu {
  background: #3E5B76; color: #fff; height:1.8em; font-size: 0.8em; padding: 2px 2px 0px 6px;

  ul {
    margin: 0;  padding: 0;
  }

  li {
    float:left;
    list-style-type:none;
    margin: 0px 0px 0px 0px;
    padding: 0px 0px 0px 0px;
    white-space:nowrap;
  }
}

のようにネスト可能。ただしこれを徹底すると標準 application.css と定義位置が乖離してゆき、差分比較して追従するのが難しくなる。また、ときには位置の依存関係が崩れることで意図せぬ問題を引き起こす。

以上の理由からアイコン フォント用の疑似要素などを除き、標準 application.css の定義順へならうことにした。Redmine のバージョン更新があれば、最後に対応したものと最新版の application.css を差分比較して部分対応すればよい。従来もそうしていたのだが、今回の変更によりこれが更に容易となった。

Redmine v3.4 の Vagrant Box

テーマ開発における Redmine 上の動作確認は onozaty さん が提供している Vagrant Box を利用している。今回も Redmine v3.4 版が公開されたので、それを Vagrantfile へ指定するようにした。

Twitter 上で Vagrant Box リリースされないのかな?とつぶやいていたら迅速に対応していただけた。非常にありがたい。

Redmine v3.4.0 から間隔が空いたのは、これのすぐ後に致命的なバグを修正した v3.4.1 がリリースされたので、これを待っていたのかもしれない。

Redmine v3.4 プロジェクト一覧の謎

minimalflat2 では theme.js によりプロジェクト一覧をツリー上に開閉する機能がある。しかし Redmine v3.4 へ更新したら、これがうまく動作しない。そもそもプロジェクト名と説明文が横並びになったりする。

もしかして HTML の DOM 構造が大幅に変更された?標準テーマではどうだろう?と試したら、標準のほうでもそうなる。これは application.css にある

#projects-index {
  column-count: auto;
  column-width: 400px;
  -webkit-column-count: auto;
  -webkit-column-width: 400px;
  -webkit-column-gap : 0.5rem;
  -moz-column-count: auto;
  -moz-column-width: 400px;
  -moz-column-gap : 0.5rem;
}

という定義が原因だった。

複数カラムでグリッド状に表示するための定義らしいけど、responsive.css のほうは従来どおり縦一列である。表示幅が広ければグリッドで、ということなのだろう。しかしプロジェクト名に対して説明文が回り込んでしまうなど、好ましくない表示のされかたをする。また minimalflat2 としてはツリー表示によりプロジェクト一覧を整理する方針なのでグリッドにしなくても冗長さはおさえられる。

以上の理由から、この新しい定義は無効化することにした。プロジェクト一覧は表示幅にかかわらず、従来どおり常に縦一列になる。

モバイル用メニューのアイコン フォント対応強化

Redmine v3.4 ではアイコン画像を表示する DOM 要素に icon- を接頭辞とするクラスが統一的に指定されるようになった。指定されるだけで CSS に画像指定のないものも多数あるのだが、minimalflat2 としてはなるべくこれらにアイコン フォントを割り当てるようにした。

もっとも目立つのはモバイル用メニューのアイコンだろう。サイド メニューから移動されてきた項目以外はのきなみ icon- 接頭辞をもつため、かなり華やかになった。

モバイル用メニュー

簡易テスト用 HTML 更新

Vagrant なのか Redmine の設計なのか分からないが、VM のテーマ ディレクトリーと同期している場所で CSS が更新されても Redmine に反映されない。Web ブラウザーのリロード、スーパー リロードをしてもダメで、しかたなく vagrant reload している。

しかしこれは非常に時間がかかる。そのため Redmine の代表的な画面を静的 HTML として保存し、そこにコンパイルされた application.css などを読ませるようにして簡易テストできるようにしている。

今回も Redmine v3.4 用に HTML を保存し直して更新した。また従来のリポジトリー構成では

src/
├── debug_images/
├── favicon/
├── fonts/
├── images/
├── javascripts/
├── stylesheets/
├── stylus/
└── *.html

のように src/ 直下に全ファイルが並んでいて stylus のように開発で頻繁に書き換えるものと、静的でほとんど更新のないものが区別しにくかった。そこで

src/
├── assets/
│   ├── debug_images/
│   ├── favicon/
│   ├── fonts/
│   ├── images/
│   ├── stylesheets/
│   └── *.html
└── stylus/

のように静的リソースは assets/ へ置くようにした。最近の Web フロントエンドや Electron アプリ開発でもこのようにしている。Stylus がコンパイルした CSS と Source Maps は assets/stylesheets/ へ出力される。

assets/ がテーマとして動作するための構成をもったディレクトリーとなる。リリース用イメージ生成も、ここにあるものから必要なファイルをコピーすればよい。動的なファイルは Stylus のコンパイル結果ぐらいなので、cpx 用のフィルターも書きやすくなった。