加快 ls 的速度

看到「When setting an environment variable gives you a 40x speedup」這篇在講 ls 的速度。

文章是由 StanfordSherlock 發出來的,不過看起來跟電視劇沒關係,從網站上的標語「The HPC cluster for all your computing needs」可以看出是 HPC 相關的單位。

在 HPC 環境裡面可以預期單一目錄裡會有很多檔案,所以使用者跑來抱怨 ls 的速度就不算太意外了。不過這次使用者有提到在他自己的 laptop 上跑 ls 反而很快:

It all started from a support question, from a user reporting a usability problem with ls taking several minutes to list the contents of a 15,000+ entries directory on $SCRATCH.

Having thousands of files in a single directory is usually not very file system-friendly, and definitely not recommended. The user knew this already and admitted that wasn’t great, but when he mentioned his laptop was 1,000x faster than Sherlock to list this directory’s contents, of course, it stung. So we looked deeper.

直接跳到後面的結論... 原因是出自於因為需要顯示不同顏色,而需要透過 lstat() 查詢額外的檔案性質 (可執行、setuid 以及 setgid 這些資料),導致速度變慢:

From 13s with the default settings, to 0.3s with a small LS_COLORS tweak, that’s a 40x speedup right there, for the cheap price of not having setuid/setgid or executable files colorized differently.

Of course, this is now setup on Sherlock, for every user’s benefit.

透過設定 LS_COLORS='ex=00:su=00:sg=00:ca=00:',可以讓 lstat() 消失,所以被放進 Sherlock 的預設值了... 而沒有遇到這個問題的環境 (像是有設計好對應的目錄結構),或是想要維持原來的樣子的人,則可以 unset 掉這個值讓輸出還是有色彩差異 :o

對投影片的程式碼加上色彩

在「Syntax highlighting in presentations」這邊用了一些迂迴一點的方法來加上色彩:

pygmentize -O style=xcode -o output.rtf input.js

這邊介紹的方式是用 Pygments 把程式碼轉成 rtf,然後再 copy & paste 貼到投影片上,有點硬但還算 okay 的方案吧...

Dropbox 的文件掃描功能

算是講 Dropbox 的「Dropbox 的 Document Detecting」這篇的續集,在抓出文件位置後講顏色的校準:「Fast Document Rectification and Enhancement」。

要怎麼把左邊的原始圖轉換成右邊的圖,包括了座標轉換以及顏色校準:

顏色校準的部份講到了這張很有名的圖。在圖片上,A 與 B 的區塊顏色是相同的,但你校準出來的時候必須跟人腦的感覺相同:

Here’s a great illustration of this “illusion,” in which the two tiles marked A and B have the same pixel values, but appear to be very different:

這是最後的成果,左邊是原始圖,中間是將背景改成白色,其他顏色保留,而右邊則是試著修正顏色:

Left: the original image. Middle: an enhanced image, with the background becoming white and the foreground preserved in exact R, G, B values. Note that the colors appear faded. Right: an enhanced image that tries to correct for the perceptual discrepancy.

應該是在 Dropbox 裡面的專案,是個有不少數學可以玩的專案...

自適應演算法與 A/B Testing

Hacker News Daily 上看到三年前的舊文章,講自適應演算法取代常見的 A/B testing:「20 lines of code that will beat A/B testing every time」。

就拿原文裡面的例子來說明,我想要測試 "Buy Now!" 這個按鈕的顏色來得知哪個顏色的 click rate 最高,而我有 Orange、Green 以及 White 三種顏色為候選。

一開始我初始值都設為「展示了 1 次,被點擊了 1 次」,所以每個點擊率都是 100%:

OrangeGreenWhite
1/1 = 100%1/1=100%1/1=100%

然後你的網站上只要展示「點擊率最高的那個顏色」,並且記錄下來展示次數與點擊率就好,而整個過程會是自適應而被自動被淘汰掉,最後可能會變成這樣,就會固定是綠色的了:

OrangeGreenWhite
114/4071 = 2.8%205/6385=3.2%59/2264=2.6%

而這樣做的好處是節省人力成本:你不需要 A/B Testing 完後再人工介入修改。

對於更複雜的例子,雖然原文沒有提到,但你可以直接展開來做,舉例來說,你假設顏色與地區兩個變數所帶出來的 click rate 不是 i.i.d.,那麼你可以針對每個 Color + Region 都存數值去比較。

當然還是有他的問題 (comment 有提到),不過可以架出一些全自動的 workaround 來解決,比起要兩階段人工介入省了不少人力。

另外可以想像在大的產品上會遇到效能問題 (因為對同樣資料大量的 read + write),但這個數字不需要太即時,只要量大就會準確,所以技術上也可以解決...

關於 CSS 中 :visited 的隱私問題

在七年半前 (2008 年八月) 寫的「利用 CSS 產生的隱私問題」文章,最近好像是因為 Rplus ChenFacebook 上的這邊提到而又有不少點擊進來,不過這個問題在 2010 年左右已經被解決了。

可以參考 MDN 上「:visited - CSS」的說明,以及當時 Mozilla 所發佈的文章:「privacy-related changes coming to CSS :visited」。

由於隱私問題,Mozilla 的作法是限制 :visited 可以改變的項目,只剩下少數與呈現方式有關的屬性可以用:

For privacy reasons, browsers strictly limit the styles you can apply using an element selected by this pseudo-class: only color, background-color, border-color, border-bottom-color, border-left-color, border-right-color, border-top-color, outline-color, column-rule-color, fill and stroke.

另外各種想要取得 :visited 的 CSS 資訊的方法,也會以沒有瀏覽過該網站重新計算,並且傳回假資料以確保還是不會洩漏:

The first change is that Gecko will lie to web applications under certain circumstances. In particular, getComputedStyle() and similar functions such as element.querySelector() always return values indicating that a user has never visited any of the links on a page.

黑白灰階照片自動上色

Hacker News Daily 上看到「Automatic Colorization」這個有趣的專案,透過演算法將黑白灰階照片自動上色。

而 training data 也很容易取得,把彩色圖片轉成黑白灰階就可以了:

Have you seen Reddit's /r/colorization sub? People use photoshop to add color to old black and white photos. This is a good problem to automate because perfect training data is easy to get: any color image can be desaturated and used as an example.

透過 Convolutional neural network (CNN) 這個演算法做的,雖然應該還是沒空去看這個...

像這張的效果不錯:

6

其中左邊是黑白灰階影像,右邊是原始圖片,而中間是算出來的結果 (training data 不包括這張圖片)。另外一張就比較明顯了:

2

這張花的顏色就差不少,但也還好。

在原始文章裡面也有分析與 Reddit 上人工上色的比較,很明顯人工上色的還是比較鮮豔,不過電腦上色還是很有趣啊...

用 ap 版本的 vim-css-color

之前是在高見龍的文章「爽爽快快學Vim(3) - Vim Plugins」裡看到這個 plugin,高見龍的文章所附上的連結就已經是 ap 版了,不過前幾天把 vim 的套件管理系統換成 Vundle 後 (參考「從 pathogen.vim 換成 Vundle...」這篇),我是用 Google 把之前裝過的套件一個一個找回來,就裝到 skammer 的版本了。

skammer 的版本問題在「Very slow.」可以看到,懶的看原因的人可以直接看 comment 裡 ap 給的 fork。

用 Vundle 的人先改掉 .vimrc 的內容,然後重新啟動 vim 後跑 :BundleClean:BundleInstall 就會裝新版了。

iTerm2 + screen (FreeBSD 上) 的 256 色

我家裡有兩台桌機在用,一台是跑 Ubuntu 11.10,另外一台是 Mac Mini (上面是 10.7),雖然 Mac 的字比較好看,但平常主要開發都還是在 Ubuntu 上,因為搞不定 iTerm2 過 GNU Screen 後只剩下標準 16 color 的問題...

中間找問題的過程就跳過去 (也忘的差不多了),最後是在「Report Terminal Type」這邊找到解法,本來是「xterm-256color」,改成「xterm」後 screen 內的 256 色就出現了:

Google 最上方的工具列換成黑色...

Google 把最上方的工具列換成黑色了,我是很喜歡這個配色 (更清楚),但有些人大概不怎麼喜歡:

但如果是 SSL 版本,好像怪怪的,上方的工具列出不來 (關掉 Adblock Plus 也是一樣),應該會有人去反應吧?