掌握 Redmine 的活動指標:繪製熱度圖

我們平常使用 Redmine 來管理專案,當需要進行 Review 或討論如何改善時,常常需要基於 Redmine 的數據。由這些數據分析,也能得知團隊執行狀況是否順利。但是 Redmine 本身並沒有整合 Dashboard 的功能,因此需要透過 RESTful API 來取得專案資料,再使用第三方軟體繪製成圖表。

安裝 python-redmine

由於 Python 是我熟悉的腳本語言,選擇用 Python 來進行 Proof of Concept,首先安裝相關的 Python 套件

python -m pip install python-redmine

如果電腦有支援 pip 指令,可以直接用

pip3 install python-redmine

來安裝。

Windows 的 pip 使用可能跟 Ubuntu 不同,至少我還沒找到用法,這邊選擇用 option-m 的模組執行方式,來執行 python 內的 pip module,效果跟 pip 相同,只是命令比較不直覺。

登入 redmine

python-redmine 已經將 redmine 的 API 指令封裝成 python 的語法,直接調用即可,我們先使用帳號密碼登入 redmine

from redminelib import Redmine
redmine = Redmine('http://demo.redmine.org', username='foo', password='bar')

第一個參數填入 redmine 所在的 url,後面帶自己的帳號與密碼,如果無法登入,可以參考官網說明,請管理員將 REST API 打開。

取得 issue 列表

我的目標是取得 redmine 上的所有 issue。其中包含 assign 給我的 issue 量、我已經處理完成的 issue 量,藉此來觀察專案的成果。

首先是 assign 給我的數量

issues = redmine.issue.filter(
    project_id='demo',
    status_id='*',
    assigned_to_id=me
)
print("Total opened count is: " + str(issues.total_count))

filter 可以設定要取回的 issues 條件;我要取回的是在 demo 專案下、任意狀態、assign 給我的 issues。

同樣的,我們也可以取得我已經完成的 issue

issues_closed = redmine.issue.filter(
    project_id='demo',
    status_id='closed',
    assigned_to_id='me'
)
print("Total closed count is: " + str(issues_closed.total_count))

畫出 Heatmap

接著,我希望可以將平常在 redmine 上的活動畫成 heatmap,畢竟對專案而言,活躍度是非常重要的指標,而活躍度的指標之一就是更新頻率。遍歷所有的 issue,查詢底下的 journal 是否是由我發出,如果是的話,在 heatmap data array 的對應欄位 +1,藉此統計活動狀況。

import re
import datetime
import numpy
week_start = int(datetime.date(2019, 3, 3).strftime("%V"))
week_end = int(datetime.date(2019, 8, 31).strftime("%V"))
week_duration = week_end - week_start + 1
journal_ken = 0
data_arr = numpy.zeros((7, week_duration))
p = re.compile("(\d{4})-(\d{2})-(\d{2})")
for issue in issues:
    for resource in issue.journals._resources:
        if not resource['user']['name'] == "Ken Chen": continue
        match = p.match(resource['created_on'])
        if not int(match.group(1)) == 2019: continue
        journal_ken += 1
        week = int(datetime.date(2019, int(match.group(2)), int(match.group(3))).strftime("%V"))
        weekday = int(datetime.date(2019, int(match.group(2)), int(match.group(3))).strftime("%w"))
        data_arr[weekday][week - week_start] += 1
print("Total journal of Ken is: " + str(journal_ken))

week_start 、 week_end 、 week_duration 用來限制時間範圍,使用正則表達式來判斷 journal 的時間是否落在指定的區段, journal_ken 用來統計總數。

得到資料陣列後,就能使用 seaborn 畫成圖

import seaborn as sns; sns.set()
import matplotlib.pyplot as plt
ax = sns.heatmap(
    data_arr
)
plt.show()

修飾 Heatmap

預設圖片跟想要呈現的效果有段落差,如果直接拿出去,大概會立刻被打槍,這邊需要進行一些美化,使用 seaborn 的參數來調整

data_masks = numpy.zeros((7, week_duration))
for i in range(7):
    for j in range(week_duration):
        if data_arr[i][j] == 0: data_masks[i][j] = 1
ax = sns.heatmap(
    data_arr, 
    cmap = 'Blues', 
    mask=data_masks, 
    yticklabels = ["Sun","Mon","Tue","Wed","Thu","Fri","Sat"], 
    linewidths = 1, 
    square = True,
    cbar = False
)
ax.set_ylim(0,7)
plt.show()

修改顏色;加入遮罩遮掉值是 0 的區段;加入 y 軸標示;加粗格線;讓顯示的區塊為方形;拿掉色彩條。 ax.set_ylim 則是因為 matplotlib 本身的 Bug 會導致圖片只畫一半

如果不想用開發中的版本,要不就等 3.1.2 版,要不就退回 3.1.0 版,要不就使用 ax.set_ylim 。我不太想動版本,只好乖乖使用指令來調整。

當一切就緒後,我們就可以得到

小結

稍微用 python 開個小小的 side project,就能體會到用 python 來驗證概念的威力。由於有完整的生態系,python 適合快速開發,快速驗證,很快就能知道自己的想法是否行得通,不用花費一堆時間蓋完基礎建設後,才發現由於需要的 API 沒開出來,導致專案 Fail。

資料視覺化真的是很有意思的題目,如果有機會的話,很想將整個團隊的資料即時視覺處理,跑專案時只要進到戰情室就能一目了然。

最後,我對 python 不支援 var++ 的用法有點意見,對 C 語言的工程師來講不太友善。

Reference

Read more

Weekly Issue 第 15 期:Go 語言從 1.25 支援 Flight Recorder

最近安排旅遊計畫,會到 Brisbane 居住三個月,突然跟熟悉的環境分開,用陌生眼光看待周圍一切,真是個特別的體驗。 世界依然在轉動,只是用了不同速度,反映在每週週報上,是項目變少了,可是內容變長了。 🗞️ 熱門新聞 Flight Recorder in Go 1.25 Go 1.25 開始支援 Flight Recorder。 以前要抓 trace,都是要等到事發後才能抓,有沒有可能事發前抓呢?有,原理很簡單,配置一塊記憶體存放臨時的 trace,如果符合條件,輸出持久化,否則丟棄,這就是 Flight Recorder。 官方給的範例很讚,像 slow request 這類例子,常常是處理 request 時遇到問題,在沒有 Flight Recorder

By Ken Chen

Weekly Issue 第 14 期:Product Hunt 已死

近期台灣技術圈新聞應該要算 Vibe Coding,無獨有偶的是,HN 上也談到類似的議題:行銷跟技術的界線在哪?哪些東西可以包裝成商品販售,哪些則是應該要有基本的自我審核? 🗞️ 熱門新聞 Product Hunt is Dead 有位產品創辦人寫了篇 Blog,標題比較聳動:Product Hunt 已死。 我沒特別 Follow Product Hunt,只有偶爾看看,但看完還是五味雜陳。依照文中所說,當你在 Product Hunt 發布產品後,會有一堆人來跟你說需不需要買讚,這讓我想到以前書市買榜的例子。 有人可能會覺得這是行銷,只是對我來說,行銷跟欺騙還是兩回事。我比較不確定的是,假設今天換個場景,改為無傷大雅的善意謊言,我會同意嗎? ✨ 科技觀點 How to Lead in a Room Full of Experts

By Ken Chen

Weekly Issue 第 13 期:Google 無須出售 Chrome

Chrome 的判決出來了,Google 不用分拆,只需要保障競爭者能跟它公平競爭。 這個判決有指標意義,所有人都知道 Google 長期利用 Chrome 數據改善它的搜尋引擎,讓其他廠商處於競爭劣勢。要解決這問題,最簡單方式是要求 Google 出售 Chrome,而法官在仔細評估後,給出相當審慎的判決。 我喜歡這種法律見解,具有實務與原則的平衡,法律條文不應該是照本宣科。 🗞️ 熱門新聞 Google Can Continue Paying for Firefox Search Deal, Judge Rules 以前很少注意 Chrome 的新聞,剛好最近判決出來了,看了一些。 最驚訝的是,Mozilla 有 85% 的年度收入是由 Google 給的,如果判決禁止 Google 出錢成為瀏覽器預設的搜尋引擎,將直接影響到 Mozilla

By Ken Chen

Weekly Issue 第 12 期:Bear 修改授權條款

通常開源專案需要面對長期維護的問題,而長期維護需要人力(開發者)物力(伺服器與基礎建設),個人開發者來說是個負擔。有些專案會有企業贊助,有些專案則是替用戶提供顧問與服務來收費維持。 這期選了 Bear 修改授權的新聞,也因為這則新聞,順道看了 Sentry 的授權模式。我們都希望擁有健康的開發生態,而授權條款很大程度左右了這點。 🗞️ 熱門新聞 Bear changes license to Elastic License Blog 平台工具 Bear 修改授權,原本是 MIT,現在改用 Elastic License。 看開發者的說法,原因是有人搭便車,fork 完直接部署成服務賣錢。開源不是免費勞工,這樣確實有點過分。Elastic License 的差別是不准以託管方式提供服務,算是補上這個洞。 相對 AGPL 來講,有時這種個人開發的小型專案,也不追求產業影響力,直接用 EL

By Ken Chen