Golomb coding

Hacker News 上看到 id=40008133 這篇提到 Golomb coding 覺得很有趣,花了些時間把演算法以及使用的場景搞清楚...

Golomb coding 用在 input 是數字 (或是 fixed size 時硬當作一個數字處理),而且大多數的資料都偏小的情境下,像是「I don't get Golomb / Rice coding: It does make more bits of the input, or does it?」這邊解釋 Golomb coding 時提到的:

they reduce the average length per encoded value compared to fixed-width encoding, if the encoded values are from a large range, but the most common values are generally small (and hence are using only a small fraction of that range most of the time).

Golomb coding 演算法上用到了兩個特殊的表達方式,Unary codingTruncated binary encoding

Unary coding 很簡單,把 n 表達成 n 個 bit 的 1,再加上一個 0,所以 3 表達成 1110,7 表達成 11111110

Unary coding 最主要就是要用到他只用一個 bit 0 來表達 n = 0 的情況。

Truncated binary encoding (中文維基百科剛好有條目:「截斷二進制編碼」) 則是很有趣的一個 encoding 方式。先提到傳統的方式,在表示 n 種可能的組合 (0, 1, ..., n-1) 時,會需要 \lceil\log_2 {n}\rceil bit 表達,像是 n = 5 時,會需要 3 個 bit 表達,從 000001010011100

Truncated binary encoding 則是找到一個方法,編碼成 00 (對應到 0)、01 (1)、10 (2)、110 (3)、111 (4),針對 n = 0~2 的部分只用 2 bits 表示,省下 1 個 bit。

Truncated binary encoding 的重點在於在可能性非 2^n 的情況下,要怎麼省儲存空間。

而 Golomb coding 需要預先指定一個 M,對於每一個 x 輸入,拿 M 去除他,就會得到一個商 q 與餘數 r

x = M * q + r

這邊把商 q 用 Unary coding 表示,餘數 r 用 Truncated binary encoding 表示,就是 Golomb coding 了。

而就如同前面提到的,Golomb coding 會用在資料數字都偏小的情況,當 M 挑的夠好就可以讓 q 常常是 0 或是 10 而省下空間。

這剛好就對到「The simple beauty of XOR floating point compression (clemenswinter.com)」這則提到的東西,在處理 time-series data 時就有機會用這個方式搭配處理...

Python 的 Black

Hacker News 上看到 Black 這個幫你處理 Python 程式碼的工具:「Black, the uncompromising Python code formatter, is stable (pypi.org)」。

Black is the uncompromising Python code formatter. By using it, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.

然後從 Hacker News 上討論的情況看起來大家都覺得很不錯?好像可以看看能不能拿來用...

另外一個在討論的時候看到學到的東西,是 git blame --ignore-revs-file 這個功能,可以在 git blame 時濾掉某些 commit,剛好拿來過濾 reformatting commit:

Ignore revisions listed in file, which must be in the same format as an fsck.skipList. This option may be repeated, and these files will be processed after any files specified with the blame.ignoreRevsFile config option. An empty file name, "", will clear the list of revs from previously processed files.

挑 Coding 字型的網站

Hacker News Daily 上看到「Coding Font by Typogram – Find Your True Love of Coding Fonts」這個,可以直接用二選一的方式挑出自己喜歡的 coding 的字型...

不過我的習慣是偶而就會換個字型,對我來說更有用的是字型列表,另外網站也提供了界面可以看:

  • Anonymous Pro
  • Azeret Mono
  • B612 Mono
  • Courier Prime
  • Cousine
  • Cutive Mono
  • DM Mono
  • Fira Code
  • Fira Mono
  • IBM Plex Mono
  • Inconsolata
  • JetBrains Mono
  • Major Mono Display
  • Nanum Gothic Coding
  • Noto Sans Mono
  • Nova Mono
  • Overpass Mono
  • Oxygen Mono
  • PT Mono
  • Roboto Mono
  • Share Tech Mono
  • Source Code Pro
  • Space Mono
  • Syne Mono
  • Ubuntu Mono
  • VT323
  • Xanh Mono

裡面有些字型以前連用都沒用過,看起來可以找來用看看... 不過看了一輪發現有些字型應該不是為了 coding 用的,像是 Space Monofixed 就會把 fi 連在一起而且只佔一格:

然後我自己用 15px 玩了一輪選到了 Azeret Mono,看起來可以裝起來用看看...

Python 的 code formatter:Black

Black 是一套 Python 上的 Code Formatter,可以幫你重排程式碼以符合 coding style 與 coding standard,比起只是告訴你哪邊有錯來的更進階...

記得以前好像不是掛在官方帳號下面的,翻了一下發現在 Hacker News 上的「https://news.ycombinator.com/item?id=17151813」這則可以看到,去年在 ambv 的 repository 上,現在則是被導到 python 的組織下了 :o

目前還是掛 beta,另外有不少 practice 讓人不太舒服,像是 Hacker News 上「https://news.ycombinator.com/item?id=19939806」這邊提到的:

Against my better judgment I'll bite.
I super dislike black's formatting, and I think it's really rare to actually see it in codebases. It wraps weirdly (sometimes not at all). I'd prefer to use yapf, but last I checked it still crashes on "f-strings".

Here's a small example:

    basket.add({
        apple.stem
        for satchel in satchels
        for apple in satchel
    })
Black formats this as:
    basket.add(
        {
            apple.stem
            for satchel in satchels
            for apple in satchel
        }
    )
        
I've never seen Python code like that.
I totally believe using a formatter is good practice. Black is in a challenging position of coming into a community with a lot of existing code and customs, and I get that. But I also think that's an opportunity, rather than having to guess at what is good, there's a wealth of prior art to look at. I wish it had done this, rather than essentially codify the author's style.

看起來還有很多可以調整的,然後也可以考慮用看看... 以前是 3rd-party 還可以丟著不管,現在帶有官方色彩得看一下 :o

18F 丟出 CSS 的代碼風格指南

好幾個禮拜前的東西,這幾天才上 Hacker News:「Introducing the CSS coding style guide」。

18F 是美國政府的官方單位,取名自辦公室所在的地址:(取自 Wikipedia 的「18F」說明)

Its name refers to its office location in northwest Washington, D.C., on 18th and F Streets.

不只是定義了 CSS Coding Style Guide,還給了 SCSS Lint 工具使用:

The styleguide provides a method of linting Sass (SCSS) code to ensure it conforms to the rules in the styleguide.

阿肯色州成為第一個要求高中教 coding 的州

Slashdot 上看到「Arkansas Is Now the First State To Require That High Schools Teach Coding」,報導自「Arkansas is Now the First State to Require That High Schools Teach Coding」。

2015~2016 這個年度將會開始招募大量教師,在高中內教 coding,大約花費一億五千萬台幣。

Training programs for teacher preparation will be available, but with the majority of the infrastructure already primed, the execution of this new law should hopefully be painless and seamless.

推行到高中啊...

PHP-CS-Fixer 1.0 出版!

PHP-CS-Fixer 正式釋出 1.0 版:「PHP CS Fixer finally reaches version 1.0」。

原作者提到了之前的版本以 regular expression 為底,而這三個月有了大改變,現在的版本是以 token 來判斷:

The current stable version of PHP-CS-Fixer was released in August 2014 and it is still based on regular expressions, two years after the first public release. But in the last three months, things got crazy mainly because of Dariusz Ruminski. He did a great job at rewriting everything on top of a parser based on the PHP tokens, helped by 21 other contributors.

這邊寫一下用法:

php-cs-fixer fix /path --level=psr2

這樣會把目錄下的所有 .php 檔都清過一次。目錄的部份也可以用檔名,表示只處理一個檔案。

檢查程式碼是否符合 PSR-2 的工具:PHP_CodeSniffer (phpcs)

PHP_CodeSniffer 是套檢查 PHP 程式碼是否符合規範的工具。


WordPress 3.8.1 的 index.php 跑 PSR-2 測試。

想要測試的人可以用 Vagrant 安裝測試,我用 Docker 弄了老半天弄不起來,就跑去用 Vagrant 測試了...

(話說回來,Vagrant 與 Docker 真的是測試的神器,反正要弄一個 Ubuntu 平台上測試就是拿這兩個東西出來測...)

由於系統內的 PHP_CodeSniffer 不一定夠新,舉例來說,Ubuntu 12.04 的 php-codesniffer 只有 1.1.0,而掃 PSR-1 的程式出現在 1.3.5,PSR-2 出現在 1.4.0

安裝 c9s 所維護的 phpbrew 通常是還蠻常見的選擇。裝完後再用 pear install PHP_CodeSniffer 裝進去就有 phpcs 可以用了。

phpcs 預設是用 PEAR standard,可以指定 --standard=PSR2 強迫他使用 PSR-2 規則:

phpcs --standard=PSR2 foo.php

也可以直接強迫換成 PSR-2,然後再看設定有沒有改成功:

phpcs --config-set default_standard PSR2
phpcs --config-show

除了可以檢查單一檔案外,也可以丟路徑進去整個檢查:

phpcs foo/

PHP 的 PSR-{0,1,2} 中文版翻譯...

查資料的時候發現有人已經翻譯好 PSR-{0,1,2}:

想要快速了解 PSR 在定義什麼,可以直接看中文版,如果有覺得不懂的地方再去翻英文版的原文敘述。

關於可維護的 PHP 專案:PHP-FIG 的 PSR-0、PSR-1、PSR-2

一個組織裡要導入 coding standatd & coding style 時是功夫最少的時候,除非有特殊理由,不然我一向都是建議:

不要自己發明 coding standard 與 coding style,如果社群的規範合理,就照著社群的規範走。

社群中比較完整的包括:

兩份大多數的規範是相同的 (因為 community 已經有習慣了),不過現在感覺起來 PHP-FIG 比較熱鬧一點 (參與的人來自不同的專案),如果讓我推薦的話我會建議用 PSR-{0,1,2}。

Reply to「寫出好維護的 PHP 程式碼」。