把所有在 CSS 裡面「有名字」的顏色都呈現出來

前幾天在 Hacker News Daily 上看到「Show HN: A color picker for named web colors (arantius.github.io)」這個作品,把 CSS 裡面有名字的顏色都呈現出來:「Named Colors Wheel」。

移動上去可以看到每個顏色在 CSS 被定義的名稱與色碼,另外從 html code 裡面可以看到他參考了「<named-color>」這份資料。

另外在 Hacker News 上的這則留言也讓我笑的蠻開心的,greenyellow (在黃色 yellow 的左邊) 與 yellowgreen (在 greenyellow 的右上) 的差異:

Also: Finally, a tool to help me decide between greenyellow and yellowgreen.

另外看到這種圖會讓我想到四色定理 (Four color theorem),不過跟這個主題沒什麼關係就是了...

可以自己調整的黑白照片上色服務

Hacker News Daily 上看到 Palette 這個服務,作者在 Hacker News 上有提到你可以提供一些句子調整顏色:「Show HN: I made a new AI colorizer (palette.fm)」。

Hi HN, I’m Emil, the maker behind Palette. I’ve been tinkering with AI and colorization for about five years. This is my latest colorization model. It’s a text-based AI colorizer, so you can edit the colorizations with natural language. To make it easier to use, I also automatically create captions and generate filters.

作者有把一些作品貼在 Reddit 上面,可以參考 https://www.reddit.com/user/emilwallner/?sort=top 這邊,看起來已經有一陣子了...

用顏色區分程式碼裡面的括弧

Hacker News Daily 上看到 VSCode 改善了 bracket pair colorization 效率的文章,才想到我的 Vim 好像沒裝這個功能:「Bracket pair colorization 10,000x faster」。

VSCode 這邊主要是引入了新的資料結構改善了計算量,有興趣的可以看一下:

Efficient bracket pair colorization was a fun challenge. With the new data structures, we can also solve other problems related to bracket pairs more efficiently, such as general bracket matching or showing colored line scopes.

我這邊則是去找 Vim 上的套件,目前看到是「Rainbow Parentheses Improved」這個,裝起來拿 PHP 程式碼看了一下還行,這樣就不用在那邊算哪個左括弧對應到右括弧...

GitHub 的 Dark Mode 辨識度太低的問題

GitHub 推出 Dark Mode 後我就馬上切過去,但用了兩天後覺得辨識度太差就換回來了,剛剛在 Hacker News Daily 上看到不只我抱怨這個問題:「GitHub Dark Mode is Too Dark」,在 Hacker News 上的討論也可以翻翻:「 GitHub Dark Mode is too Dark (karenying.com)」。

裡面分析了 SpotifyFacebookYouTube 以及 GitHub 的配色盤,然後算出對比度,可以看到 GitHub 的配色上的確是差了不少...

目前 GitHub 上的 Theme 功能是掛 beta,應該還是有機會改,看看會不會修的好一點...

加快 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%:

Orange Green White
1/1 = 100% 1/1=100% 1/1=100%

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

Orange Green White
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),但這個數字不需要太即時,只要量大就會準確,所以技術上也可以解決...