分類: 匯入的文章

在 Smashing Newsletter 看到的，只要 <link> 標籤就可以簡單把 CSS 變成非同步讀取：

<link rel="stylesheet" href="/path/to/my.css"
        media="print" onload="this.media='all'">

有用過 Google PageSpeed Insight 分析網站的，應該都有看過如下的結果：

原因是因為瀏覽器在處理 CSS 與 JavaScript 檔案的時候會阻擋其他資源的載入。解決的 方法裡，JavaScript 類型的資源可以標示 defer 或是 async 屬性讓瀏覽器知道我們 希望可以非同步的載入執行此 JavaScript 檔案，可惜 CSS 並沒有類似的屬性可以使用。

一般處理 CSS 的載入有兩個策略：

1. 盡量把最重要的樣式內嵌(inline)在 HTML 內，
2. 用 JavaScript 動態的插入 <link> 標籤。

策略 1. 應該不難理解，因為都已經要下載 HTML 了，不如把少部份最重要的樣式直接也寫 在裡面，可以省下一次網路請求。策略 2. 則是把其他剩餘的樣式集中在一起，用 JavaScript 在網頁讀取完畢後再動態的插入 <link> 標籤讓瀏覽器套用。LoadCSS 似乎是個常用的 library 但是我沒有用過，因為我不喜歡這種需要很多 JavaScript 的解 法。

這次看到的這個方法非常簡單，原本的 CSS 標籤如下：

<link rel="stylesheet" href="/path/to/my.css">

只要再加上 media="print" 以及 onload="this.media='all'" 就可以讓瀏覽器非同步載入 CSS 了！

原理是，瀏覽器在遇到非使用中的 media 時，只會下載但是不會套用樣式，所以設定 media 為 print 可以避免套用 CSS 的時候延遲其他的資源的載入，而 onload 的部 份則是在等到其他資源都載入完畢後，才把 media 切回 all 或是 screen 讓瀏覽器 套用樣式。雖然還是需要一點點 CSS，整體看起來清爽許多，也不需要額外的 library！

如果需要支援沒有開啟 JavaScript 的瀏覽器，記得加上 fallback：

<noscript><link rel="stylesheet" href="/path/to/my.css"></noscript>

完整的範例如下：

<link rel="stylesheet" href="/path/to/my.css"
        media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="/path/to/my.css"></noscript>

我迫不及待的立刻試用了? ∎

去年年底，我利用閒暇時間¹修好了 Firefox 的 Segment Break Transformation Rules 實做(Bug 1081858)。從 Firefox 52 開始，HTML 裡面中文與中文之間的換行，瀏覽器排版時不會顯示為空白。

前陣子 Adobe 和 Google 聯手各自用不同的名字釋出了一款新的中文黑體字形，Source Han Sans 思源黑體，也叫做 Noto Sans (反腐字？)。開心試用之後，把系統字形都換過來，也開始想要怎麼樣才可以達到最佳的顯示效果，尤其是 Adobe 和 Google 曾經給 FreeType 貢獻了 CFF 字形引擎的改進，思源黑體也是以 CFF 技術設計，終於可以試試看中文的效果怎麼樣了啊！

我這邊使用 FreeType 的工具程式 ftview 來測試不同參數設定下的顯示效果，同時也附上相對應的 FontConfig 設定。可以發現不同設定下的顯示差距還蠻大的：

Auto-hinter, hintfull, grayscale anti-alias

首先是使用 FreeType 的 autohint, hintfull 其他用預設值，這應該是滿多人使用的設定，可以看到 autohinter 有很強烈的瘦身效果，把 Normal 的字變成幾乎是 Light 了。

Auto-hinter, hintslight, grayscale anti-alias

再來是使用 hintslight，許多人用以取得類似 Mac 上面的渲染效果，卻不知道 hintslight 會自動使用 autohint，這張的效果和上面類似但是略為粗了一點。思源黑體使用 hintslight 的缺點是 Normal 變細，導致和 Bold 的粗細相差太多。

Auto-hinter, hintslight, RGB LCD subpixel AA

這張的效果和上面一樣，只是啟用了 subpixel AA 所以在螢幕是 RGB 排列的 LCD 的時候會有比較銳利的感覺。

Adobe CFF native hinter, hintfull, grayscale anti-alias

這張則是使用 Adobe 去年貢獻的 CFF native hinting 引擎，這個引擎的特性是在小字的時候不但不會把字變細，反而還會加深筆劃讓字形看起來更清楚，於是 Normal 變回原本得粗細。

Adobe CFF native hinter, hintfull, RGB LCD subpixel AA

同上，只是啟用 subpixel AA 讓字形在 LCD 螢幕上看起來更銳利。

最後因為我選擇的設定是 TTF 字形使用 autohint + hintslight，CFF 字形則是使用 native hinter，因為雖然很多 TTF 字形有人工去 hint，可是一般來說 autohint + hintslight 比較可以保留細節，也不比人工 hint 差，而 CFF 字形因為有 Adobe 的加持，所以使用 native hinter 可以得到更好的效果。

    <match target="font">
      <edit name="rgba" mode="assign">
        <const>rgb</const>
      </edit>
      <edit name="hinting" mode="assign">
        <bool>true</bool>
      </edit>
      <edit name="lcdfilter" mode="assign">
        <const>lcddefault</const>
      </edit>
      <edit name="hintstyle" mode="assign">
        <const>hintslight</const>
      </edit>
    </match>
    <match target="font">
      <test name="fontformat"><string>CFF</string></test>
      <edit name="hintstyle" mode="assign">
        <const>hintfull</const>
      </edit>
    </match>

https://github.com/kanru/rcfiles/blob/fonts.conf

這是我目前的設定，至於你喜歡什麼樣的效果，可以再實驗看看各種不同的參數囉 ?

尋找 GCIN co-maintainer

HIME 的事件鬧的沸沸揚揚，一切的起因之一就是有人認為 HIME 會取代 Debian
裡面的 GCIN，這是什麼狀況呢？因為在 Debian 裡面把 GCIN 棄養 (orphan)
的就是我，似乎也有必要說明一下。以下提到 GCIN 都是指 Debian 裡面的 GCIN。

最早的 GCIN 維護者是 caleb，後來他因為不再使用 Debian 所以開始找其他人
幫忙維護，而我成為 Debian Developer 的初衷就是要幫助本地的使用者有習慣
好用的套件可以用，所以就接下了這個位子。當時我也有使用 GCIN 所以就算劉
老大 (eliu) 每兩三天就有新版本我也還可以跟上，只是沒有辦法把套件整理的
乾淨點，後來不用 GCIN 了，套件的更新就漸漸脫節，因為有 Luna Archiver
的存在也讓我有偷懶的藉口，最後發現花在這個套件的時間與 Debian 的
Popcon 統計不成比例，就決定把套件給棄養了。

Debian 對於被棄養的套件的處理方式是，如果沒有出什麼大問題就會由 QA
team 來管理，但是如果有人提出 RM: RoQA 的要求，因為使用者 (Popcon) 少
且無人管理，就有可能被移出 Debian，但無正當理由甚少有直接使用新專案取
代舊專案的狀況，因此 Debian 要使用 HIME 取代 GCIN 純粹是誤解而已。

後來想想也不能把 GCIN 就這樣晾著，所以我決定要再出點力，把 GCIN 納入
Debian IME Packaging Team 的管理，並誠徵對維護 GCIN 套件有興趣的人一起
來 co-maintain，讓 GCIN 的使用者可以直接用到最新、高品質的 GCIN 套件。

有興趣的人請與我聯絡，寄信到 koster@debian.org 或是
630484@bugs.debian.org 都可以。

昨天看到有人轉噗一則 StackOverflow 上面的問題，內容是問他分別用 C,
python, erlang 與 haskell 寫了 Project Euler 的第十二題，但是
haskell 版本慢得不像話，該如何改進？

以下是苦主的原始 C 語言版：

    #include <stdio.h>
    #include <math.h>
    int factorCount (long n)
    {
        double square = sqrt (n);
        int isquare = (int) square;
        int count = isquare == square ? -1 : 0;
        long candidate;
        for (candidate = 1; candidate <= isquare; candidate ++)
            if (0 == n % candidate) count += 2;
        return count;
    }
    int main ()
    {
        long triangle = 1;
        int index = 1;
        while (factorCount (triangle) < 1001)
        {
            index ++;
            triangle += index;
        }
        printf ("%ld\n", triangle);
    }

我的執行時間約為 5.48s

    % gcc -lm -o euler12.bin euler12.c
    % time ./euler12.bin 
    842161320
    ./euler12.bin  5.48s user 0.00s system 99% cpu 5.484 total

手癢想看看據說可以編譯出不錯的機器碼的 Common Lisp 速度怎麼樣，於是第
一個版本如下 (用 sbcl 執行)：

    (defun factor-count (n)
      (let* ((square (sqrt n))
             (squaref (floor square))
             (count (if (eql squaref square) -1 0)))
          (loop
             for cand from 1 to squaref
             count (eql 0 (rem n cand)) into c
             finally (return (+ count c c)))))
    (defun first-triangle-over (n)
        (loop
           for idx from 1
           sum idx into triangle
           until (>= (factor-count triangle) n)
           finally (return triangle)))
    ;; (time (first-triangle-over 1000))
    ;; Evaluation took:
    ;;   11.192 seconds of real time
    ;;   11.184699 seconds of total run time (11.184699 user, 0.000000 system)
    ;;   99.94% CPU
    ;;   30,135,882,489 processor cycles
    ;;   32,912 bytes consed
    ;;   
    ;; 842161320

還不錯，11.192s，這個版本採用原文中給 haskell 的建議，使用 rem 而不是 mod，可以
加快一點速度。再給一點關於型別的提示，然後把第一個 function inline，第
二版可以跑出和 C 版本差不多的成績 5.563s 🙂

    (declaim (inline factor-count)) ;; <----
    (defun factor-count (n)
      (let* ((square (sqrt n))
             (squaref (floor square))
             (count (if (eql squaref square) -1 0)))
          (loop
             for cand from 1 to squaref
             count (eql 0 (rem n cand)) into c
             finally (return (+ count c c)))))
    (defun first-triangle-over (n)
        (loop
           for idx of-type fixnum from 1 ;; <----
           sum idx into triangle of-type fixnum  ;; <----
           until (>= (factor-count triangle) n)
           finally (return triangle)))
    ;; (time (first-triangle-over 1000))
    ;; Evaluation took:
    ;;   5.563 seconds of real time
    ;;   5.556347 seconds of total run time (5.556347 user, 0.000000 system)
    ;;   99.87% CPU
    ;;   14,970,270,903 processor cycles
    ;;   32,768 bytes consed
    ;;
    ;; 842161320

純粹湊個熱鬧而已，有興趣的人可以試試看把 loop 改成和原文其他語言一樣使
用遞迴來實做，大部分 Lisp 都有做 TCO，速度應該差不多…

結論：Common Lisp is awesome 😉

Let us change our traditional attitude to the construction of
programs: Instead of imagining that our main task is to instruct a
computer what to do, let us concentrate rather on explaining to human
beings what we want a computer to do.

― Donald Knuth. “Literate Programming (1984)”

Thinker 的一篇心靈與程式碼的協奏曲提到程式由後往前寫似乎比較符
合思考的方向，不禁讓我想到 Knuth 提出的 Literate Programming 方
法；其實我們思考的順序有時是跳躍式的，用 LP 的方法可以完全跳脫先後關係，
用自己喜歡的順序來寫，我覺得也可以稱為碎碎唸寫法。

用 Thinker 的同一個例子，改作 noweb 的格式，用 LP 的方法來寫，會變
成怎樣？首先定義問題：

假設問題是，function 接受一字串，裡面的每一行有兩個欄位，皆是整數。欄
位以一個空白相隔。function 必把每一行的兩個欄位的數字相乘，然後再將每
一行的結果加總。

我們需要一個接受一個字串的 function ：

    <<接受字串的 function>>=
    def mul_n_sum(data):
        <<function 內容>>
    @

這個 function 必須把每一行的兩欄數字相乘，然後相加；假設我們取得每一行
的兩個數字之後照順序存放在 field_lines 這個變數裡面，則用 sum 就可
以把兩兩相乘之後的數字加總：

    <<function 內容>>=
    <<取得每一行的兩個數字>>
    return sum([field1 * field2 for field1, field2 in field_lines])
    @

要怎麼取得每一行的兩個數字呢？首先要把每一行的字串切開：

    <<取得每一行的兩個數字>>=
    lines = data.strip().split('\n')
    @

然後被切開的每一行字串經過分割後，會變成依照

    [field1, field2],
    [field1, field2],
    [field1, field2],
    ...

順序排列的字串，所以我們還要轉換成數字才能運算：

    <<取得每一行的兩個數字>>=
    <<分割欄位>>
    field_lines = [[int(field1), int(field2)] for field1, field2 in txt_field_lines]
    @

最後，分割欄位有很多方法，因為我們已經知道輸入的格式不會錯誤，所以用簡
單的 str.split() 來切割就可以了：

    <<分割欄位>>=
    txt_field_lines = [line.split() for line in lines]
    @

這篇 blog 經過 notangle 的處理，會變成以下的 python 程式：

    # notangle -R'接受字串的 function' literate-programming.mdwn
    def mul_n_sum(data):
        lines = data.strip().split('\n')
        txt_field_lines = [line.split() for line in lines]
        field_lines = [[int(field1), int(field2)] for field1, field2 in txt_field_lines]
        return sum([field1 * field2 for field1, field2 in field_lines])

可以跟 Thinker 的結果比比看 🙂

這篇是故意使用類似的思考邏輯來寫，所以會產生相似的程式，且為了展示 LP
我最後還刻意調整了一下順序。只要換一下思考的方向，要寫出 loop 的版本也
是有可能的。重點在於隨想隨寫，邊寫程式邊紀錄思考過程。

碎碎唸的好處是不怕跳躍式的思考，想寫什麼就寫什麼，邊想邊寫，壞處是最後
組合出來的程式一般人可能沒辦法直接看懂，但是這樣寫還真的滿有趣的，有機
會一定要試試！

其他參考資料：

• Literrate Programming
• Python 版的 noweb
• PHP 版的 noweb