用 jiracli 做一些基本常見的操作

公司用 Jira 在管理事情,但眾所皆知的是 Jira 的速度實在太慢 (而且沒改善過),只好找些工具來避免使用 web interface...

翻了 GitHub 後看到 toabctl/jiracli 這個用 Python 開發的軟體,可以在 command line 上對 Jira 做些簡單常見的操作 (對我最主要是 issue 與 comment 的操作),另外工具也支援使用 JQL 搜尋,所以可以透過工具拉下來後再用 grep 或是 awk 過濾...

比較需要注意的是,在第一次執行需要設定的三個參數中,password 的部分其實應該使用 API token (我這邊是 Google SSO,所以不確定一般帳號能不能用自己的密碼登入),這個部分可以在個人設定頁面裡面產生 API token。

設定檔會在 ~/.jiracli.ini 裡面,程式應該會設為 0600,不過可以檢查一下就是了...

自動校正字幕時間的軟體 subsync

看到用 Python 寫的「smacke/subsync」這個軟體,可以自動校正字幕時間:

Language-agnostic automatic synchronization of subtitles to video, so that subtitles are aligned to the correct starting point within the video.

他把上面這個變成下面這個:

因為不是用 machine learning 所以速度意外的快。演算法是對影片本身產生一個 array,然後對字幕也產生 array,最後對兩個 array 用個簡單的公式校準:

  • Discretize video and subtitles by time into 10ms windows.
  • For each 10ms window, determine whether that window contains speech. This is trivial to do for subtitles (we just determine whether any subtitle is "on" during each time window); for video, use an off-the-shelf voice activity detector (VAD) like the one built into webrtc.
  • Now we have two binary strings: one for the subtitles, and one for the video. Try to align these strings by matching 0's with 0's and 1's with 1's. We score these alignments as (# matching digits) - (# mismatched digits).

就這樣解決問題 XD

Python 上觀察 Memory Leak

Zendesk 的「Hunting for Memory Leaks in Python applications」這篇介紹了 memory_profiler 這個工具,可以比較長期的觀察記憶體使用量的問題。

首先是先看正常與疑似異常的分析:

然後可以拉出資料型態資訊:

這些資訊要找 memory leak 還是蠻粗糙的,但算是給了個方向,而且用起來算是簡單...

SQLite 的 CLI 操作工具 litecli

之前應該都是用 SQLite 提供的 cli 操作,現在有人提供支援 auto completion 與顏色的 cli 軟體了:「CLI for SQLite Databases with auto-completion and syntax highlighting」。

工具是用 Python 寫的,可以直接用 pip 安裝。

用 Py-Spy 分析 Python 程式效率

這之後應該會變成 Python community 的神器之一...

剛剛看到分析 Python 程式效率的工具,只要有 pid 或是直接包著跑就可以分析:「Py-Spy: A sampling profiler for Python programs.」,執行起來長這樣:

而且還可以直接產生火焰圖讓開發者直接確認,超友善:

在 FAQ 的地方也有提到作者開發這套軟體的原因。有些在開發環境根本看不出問題的,可以很快的透過這個工具在 production 上看:

This project aims to let you profile and debug any running Python program, even if the program is serving production traffic.

另外一個重點在於其他常見的 profiling 工具通常都要改程式引用進來使用,這通常會使得程式效率慢下來,而 Pyflame 支援的平台比較少:

While there are many other python profiling projects, almost all of them require modifying the profiled program in some way. Usually, the profiling code runs inside of the target python process, which will slow down and change how the program operates. This means it's not generally safe to use these profilers for debugging issues in production services since they will usually have a noticeable impact on performance. The only other Python profiler that runs totally in a separate process is pyflame, which profiles remote python processes by using the ptrace system call. While pyflame is a great project, it doesn't support Python 3.7 yet and doesn't work on OSX or Windows.

Python 3 內建的 lru_cache...

Twitter 上看到 Python 3 內建的 lru_cache()

從文件上可以看到預設值是 128 個:

@functools.lru_cache(maxsize=128, typed=False)

tweet 裡面有討論到 memory leak 的問題可以看一下,不過如果是拿來寫工具的話,應該不會有什麼問題...

Python 3.7.0 以及效能

這幾天 Python 3.7.0 出了,這應該是 3.x 版第一個在一般性綜合測試有機會比 Python 2.7 快的版本。這邊拿二月時有人用 3.7 的 beta 版測試結果來看:「Which is the fastest version of Python?」。其中第一個圖就是 Djangodjango_html (render) 的測試,Y 軸是時間,所以是愈低愈好:

其他的幾張可以看到不是完全被 Python 2.7 抓著打了,算是出頭天了 (???),如果是用 pyenv 的人,把 pyenv 升級到新版後就可以安裝 3.7.0 了。

合併 RRD 資料的工具

昨天把跑在 Raspberry Pi 上的 SmokePing 資料改用統一版本 (我在 GitHub 上公開的 smokeping-config.d 這個),但有些節點的 naming 改變了,所以會需要將資料整在一起。

在透過 Google 搜尋後,用的工具是「A very simple script to merge multiple RRD files, since none of those available seem to work.」這個,是一隻 Python 的程式。另外可以從程式碼裡面看到他使用了 rrdtool 這個 CLI 工具 (SmokePing 用了 RRD 格式儲存資料),所以使用這隻程式前需要先安裝 rrdtool 這個套件:

$ sudo apt install rrdtool

接下來就是照說明來轉換。由於 rrdtool 這隻程式沒有對 filename 做特殊處理 (i.e. 把 - 當作 stdin),所以會使用到 /dev/stdin 這種特殊方式來當作 input:

./simple-rrd-merge.py input-a.rrd input-b.rrd | rrdtool restore /dev/stdin output.rrd

當然,要記得先把 SmokePing 停掉再跑會比較好 XD

生出的 RRD 檔案再覆蓋回去 (我是先備份起來,以免有意外...),然後再把 SmokePing 跑起來就可以了。