2014-10-28

Solarized color 8 (bright black) 與背景雷同問題

使用 Solarized 這套配色對眼睛蠻舒服的，而且有 light 或 dark 型態可以切換，跟 Base 16 或 Zenburn 比起來，我是最喜歡 Solarized。但他有個長久以來的問題，就是在 terminal 下，background 跟 color 8 (bright black) 是一樣的顏色，都是 base 03。Node.js 很多套件在彩色顯示時都會用到 bright black，一旦用到就會跟背景同色，看不見。

之前我的解法是把 background 設為 color 0，也就是真的 black，但在 Solarized 設計上，這兩色是鄰近的而不是對比色，所以雖不是同色，但仍然很難看到。後來參考了內建 Solarized theme 的 Terminator 解法，是直接把 color 8 設定成 #6a848a，這不論在 light 或 dark 模式下，反差都很清晰，是目前為止我覺得最好的解。

相關討論可以看 issue 220，這問題存在很久了但作者就是不爽解決。

2014-08-27

多核心下 nginx - node.js 的組合

目前我們網站都是寫在 node.js 上，然後用 nginx 當 reverse proxy 來接。

以四核然後有 VT 為例，nproc 看到的會是 8，此時一些相對應的 nginx.conf 設定：

1 2	worker_processes 8; worker_cpu_affinity 00010001 00010001 00100010 00100010 01000100 01000100 10001000 10001000;

worker_cpu_affinity 的值是按照 /proc/cpuinfo 內容來決定的，用來做範例的機器排列是 processor 0~3 對應到 core 0~3，然後 processor 4~7 又對應到 core 0~3，所以 processor [0, 4], [1, 5], [2, 6], [3, 7] 各自屬於同一個 core。同一個 core 可以允許 processes 互換，所以上面 worker_cpu_affinity 的意思是指定 worker 0 可以跑在 0, 4 兩個 CPU 上（第 0 跟第 4 bit 為 1），然後 worker 1 也是跑在 0, 4 上面。依此類推。

node.js 部份並沒有用 forever 來跑，而是用 upstart 來看住。相關的一些設定長這樣：

# portal.conf

start on runlevel [2345]

task

script
    NPROC=$(nproc)
    for N in $(seq $NPROC); do
        start portal-worker N=$N
    done
end script

用 portal 去跑好幾個 portal-worker 起來。而 portal-worker 則是會看執行時給的 N 值來決定怎麼跑。

# portal worker

manual

respawn

instance $N

env NODE_ENV=production
setuid www-data
setgid www-data
chdir /home/johndoe/portal
script
    test $N = 1 && exec taskset 0x11 node server.js -c config-1
    test $N = 2 && exec taskset 0x11 node server.js -c config-2
    test $N = 3 && exec taskset 0x22 node server.js -c config-3
    test $N = 4 && exec taskset 0x22 node server.js -c config-4
    test $N = 5 && exec taskset 0x44 node server.js -c config-5
    test $N = 6 && exec taskset 0x44 node server.js -c config-6
    test $N = 7 && exec taskset 0x88 node server.js -c config-7
    test $N = 8 && exec taskset 0x88 node server.js -c config-8
end script

portal-worker 的 log 都會在 /var/log/upstart 底下，例如 N=1 時，就會是 /var/log/upstart/portal-worker-1.log。另外可以看到 taskset 的邏輯基本上跟 worker_cpu_affinity 是一樣的。後面 -c 是自訂參數，用來指定不同設定檔，例如規定 node process 聽在不同的 port 上。這樣搭配 nginx 裡頭 upstream 功能就可以平均分配：

upstream portal {
	server 127.0.0.1:5001;
	server 127.0.0.1:5002;
	server 127.0.0.1:5003;
	server 127.0.0.1:5004;
	server 127.0.0.1:5005;
	server 127.0.0.1:5006;
	server 127.0.0.1:5007;
	server 127.0.0.1:5008;
}

server {
	# ...snipped...
	location / {
	proxy_pass       http://portal;
	proxy_redirect   default;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Forwarded-Host $host;
	proxy_set_header X-Forwarded-Server $hostname;
	proxy_set_header X-Forwarded-Proto $scheme;
	}
}

值得注意的是，upstart 在 12.04 有個 bug，Supplementary groups not set for user jobs，這會導致上面的 setuid www-data 不如預期，例如 user www-data 的 supplementary group 有一個 groupabc，然後某檔案設定為 groupabc 可以寫，結果 upstart 跑起來以後是寫不進去的。解法之一是改用 sudo -u www-data -E -- 來跑。14.04 就沒這問題了。

2014-06-20

MongoDB 搬空的 collections

show collections 會看到 system.indexes，只 dump 這個 collection 的話，restore 時就會做出所有 collections 但是是空的。假定每個 collection 至少都有一個 index 的話。這在做測試用的 database 時很方便。

1 2	mongodump -d mydb -c system.indexes mongorestore -d mydb dump/mydb

2014-06-20

Golang import path `all`

go help packages 可以看到三個 reserved names 如下：

- "main" denotes the top-level package in a stand-alone executable.

- "all" expands to all package directories found in all the GOPATH
trees. For example, 'go list all' lists all the packages on the local
system.

- "std" is like all but expands to just the packages in the standard
Go library.

實際使用起來有如下的一些可能，不過最好用 root 裝 go，免得影響到 std libraries.

更新全部 go get -u all
清掉全部 build 出的 libraries go clean -i all
install 全部 go install all

2014-06-11

善用 exec redirection

寫 shell script 時常碰到 list 不好處理的問題，裡面如果包含空白之類的 IFS 區隔，一不小心就會發生意外。例如目錄中包含 My Music 這個目錄，用以下的 shell script 處理 ls -1 時，就會分別印 My 跟 Music。

1
2
3

for f in `ls -1`; do
    echo $f
done

解法可以用 read 讀入變數：

1
2
3

ls -1 | while read f; do
    echo $f
done

如果需要複雜一些的篩選，甚至處理有 \n 在裡頭的檔案，那可以用 find -print0：

find -mindepth 1 -maxdepth 1 -print0 | \
    while read -d $'\0' f; do
    echo $f
done

但這又有個討厭的地方，就是在迴圈中如果需要用到 stdin 就出錯了，因為 stdin 是接到 find 的 stdout。解法會動用到 process substitution 跟 exec redirection 用來改變環境的 file descriptor 設定。

exec 3< <(find -mindepth 1 -maxdepth 1 -type d -print0)
while read -d $'\0' f <&3-; do
    echo $f
done

主要差異是第一行，<(COMMAND) 的用意是把 find 的輸出接到一個 named pipe 或者是 /dev/fd 之下當成一個檔案（詳情請參閱 info bash），而 exec 3< 的意思則是用 fd 3 打開這個檔案。下一行 read 後面接的 <&3- 是把 fd 3 move 到 read 的 stdin，這樣就不會影響到 loop 中的 stdin 了。

2014-03-17

中文字型大不易

個人習慣的閱讀用字型為 sans-serif，為求搭配，中文字也想採用無襯線的黑體或圓體。然而這件事情卻是超乎想像的困難，原因在於以下需求：

繁體部份不得為 GB 18030 寫法。（參考 GB 18030 就在你身邊）若非為此，文泉驿系列字型，就是很好的選擇。
簡繁字體需同源。這是由於 UTF-8 中簡繁字有許多共用，若 fontconfig 先指定繁體字集，再 failover 到簡體，而兩者風格不一致，那麼在顯示簡體文章時，若在繁體字集中先找到字，就會直接使用，找不到的話就會用簡體字集。這會導致整個版面交錯排列來自兩個字集的字型，此時若不一致，就會非常難看。譬如這種慘況：

在 Ubuntu 13.10 中直接可找到的繁體黑體或圓體，比如 fonts-cwtex-heib 或 fonts-cwtex-yen 都有跟簡體字型不一致的問題。反倒是如果不要求要無襯線字體，fonts-arphic-uming 就已經解決了，因為簡、繁、香港字型皆有提供。

Apple 的黑體-繁跟黑体-简，以及微軟的正黑體，其實都符合這些需求，但 Ubuntu 套件中的中文字型則不然。

Update 2018/08/21:

Google 的 Noto CJK 符合以上所有需求，且有襯線與無襯線皆提供。

2014-02-14

Big Integer in JavaScript

應該很多人都知道 JavaScript 的數值型別沒有整數，一併都是 double precision 64-bit 浮點數。但實際運作起來還是很討厭啊：

> b = parseInt('9007199254740992', 10); // 2^53
9007199254740992
> typeof(b);
'number'
> b + 1;
9007199254740992
> b = parseInt('9007199254740994', 10);
9007199254740994
> typeof(b);
'number'
> b + 1;
9007199254740996
> 'wtf?'
'wtf?'
> b = parseInt('18446744073709551616', 10); // 2^64
18446744073709552000
> isNaN(b)
false
> isFinite(b);
true

Reference: http://ecma262-5.com/ELS5_HTML.htm#Section_8.5

其實已經不準確了，但沒有錯誤訊息。這裡我本想做的事情是 JSON parse/stringify facebook user id，據 Facebook blog 說的長度是 64 bits. 當然會有人建議乾脆存成字串啦，但除非移民太空，不然其實不可能超過 64 了。在找支援的套件時，都不是很熱門，感覺怕怕的。後來看到 json-bignum，內部是直接用字串存，簡單，看了一下覺得還可以，但當然在比較之類的就要小心了，例如相等的話要先 toString() 之後才能比。

2014-01-13

Ordered Spec in PyMongo

最近寫 Python 存取 mongoDB 時注意到一個問題，就是在下 find 時很自然的用了 dict 來下條件，但~~其實 mongoDB 的 find 會需要注意先後次序，用來跟index 搭配~~在某些情況例如 hint，次序是有影響的。PyMongo 在這部份的說明其實蠻模糊的，相關的文件如下：

pymongo.collection

find(self, *args, **kwargs)

:Parameters:
  - `spec` (optional): a SON object specifying elements which
    must be present for a document to be included in the
    result set


bson.son

class SON(__builtin__.dict)
    SON data.

    A subclass of dict that maintains ordering of keys and provides a
    few extra niceties for dealing with SON. SON objects can be
    converted to and from BSON.

	__init__(self, data=None, **kwargs)

所以若要保留順序，就要直接用 SON 物件來當 find 的參數。建立的方法跟 dict.items() 傳回來的東西一樣，是 “list of D’s (key, value) pairs, as 2-tuples”

>>> from bson import son
>>> a = son.SON([('a', 1), ('b', 1), ('c', 1), ('d', 1)])
>>> a
SON([('a', 1), ('b', 1), ('c', 1), ('d', 1)])
>>> a.to_dict()
{'a': 1, 'c': 1, 'b': 1, 'd': 1}

2014-01-12

WXR Parser

WXR Parser 可用來分析 WordPress.com 匯出的 XML 檔案，是為了這次要搬出來然後用 Wintersmith 靜態產生 blog 頁面寫的，目前可以匯出適合 Wintersmith 使用的目錄結構。不過因為設計上 parser 跟 backend 分開，所以要擴充來產生其他格式也蠻簡單。

A simple WXR parser written in Python to parse the XML export from WordPress and store the information it in in Python’s basic data structures, i.e. dictionaries and lists. It also goes with a backend to export it in Markdown syntax suitable for Wintersmith. In its current form, it can simplify the migration from WordPress to Wintersmith, but it’s easy to be extended to export more formats.

It’s created because the author failed to find a simple one to use.

至於本來想讓 Wintersmith 支援 org-mode，這部份就不打算弄了。主要由於幾個原因：

org-mode 輸出成 html 預設是 standalone 的，也就是會匯出一個結構完整的 html 檔案。這在當成文件匯出時很不錯，但並不符合這類 static site generator 的預期。
org-mode 新版本支援直接輸出為 markdown。

2014-01-09

新居落成誌慶

張愛玲在「紅玫瑰與白玫瑰」中用了「心居落成誌喜」，好不容易搬完了家，也該來慶祝一番。

這回動用不少，首先為了該用那一個 Static site generators 就著實煩惱了好一陣子，一開始注意到 Jekyll，後來又發現 Octopress 弄得更漂亮，期間也看過 Logdown 跟 Ghost。說實在話如果考慮動態、hosting 的話，Ghost 應該是首選，界面很漂亮，又是 open source 可以自己修改。不過想來想去，為了知識管理，技術相關的文章還是在自己電腦上有一份文字檔的來得好，比較容易搜尋，故最後還是決定用靜態產生，然後丟到 github.io 的方式來做。

研究一陣 Octopress 之後決定放棄，雖然它預設產生出來的版面最順眼，但畢竟 Ruby 我不會寫，有問題也沒法改。接下來就是在 Nikola 跟 Wintersmith 之間擺盪。決定的原因，是覺得說到 web，還是當紅的 javascript 資源最多，所以決定使用 Wintersmith。

其實不論哪個平台，直接拿來開始寫都是很簡單的。真正問題在於我也想順便把原先的 blog 抓下來，看是要轉換成 org-mode 或是 markdown，免得要找以前寫的東西還得上網去查。另外也想寫個功能比較完整的 wordpress xml parser，日後如果要弄 page, category, tag 這些東西也方便改。花了好些功夫終於用 python 寫出一份，可以先把 html 的部份抽出來用 Pandoc 轉 markdown，也可把文章中引用的圖片一併抓下備用。這部份完成了以後就是漫長的微調過程， markdown 本身就有數種不同的 flavor，pandoc 與 Wintersmith 用的 marked 預設並不相同。另外 wordpress 喜歡用一些自己的 tag 例如 [sourcecode], [youtube], [slideshare] 這也會造成一些麻煩。最終成果堪用，但還不滿意，之後有空整理一下再開放出來。

原先的文章本來就已經有一部份是從再前一個自己架的 blog 移到 wordpress.com 去的，小時候寫文章習慣不是很好，程式碼引用的語法也不太一致，這次換到 markdown 以後全部整理一次，希望之後能夠就此定案。

目前版面，為了 markdown 的換行與中文美觀，採用了兩位朋友創作的 CJK-space-fix 以為換行修正，以及 dualjustify 做縱橫對齊，效果出來還不錯。可惜預設版面實在太難看，也只有等之後慢慢修正了。