幾個使用 LWP (WWW::Mechanize) 的好習慣...

WWW::Mechanize 是繼承 libwww-perl 中 LWP::UserAgent 的工具,所以這個方式通用於兩者...

首先是在取得資料時加上 Accept-Encoding: gzip 的 header,這可以在產生物件時指定,之後就都會送出:

my $ua = LWP::UserAgent->new;
$ua->default_header('Accept-Encoding' => 'gzip');

取回後直接透過 HTTP::Response 的 decoded_content 幫你處理:

my $res = $ua->get($uri);
my $msg = $res->decoded_content;

取回的 $msg 會是 Perl internal encoding,要變成 UTF-8 還需要透過 Encodeencode('utf8', $msg)

這樣只要 server-side 有支援 gzip 就會自動壓縮並且在本地端解開,沒壓縮也沒關係,HTTP::Response 會依照 Content-Type 處理。

Updateclkao 指出 WWW::Mechanize 預設值就會包括 gzip 設定,剛剛拿 code.jquery.com 測試沒錯。

在 Perl 裡用 LWP::UserAgent (以及繼承它的模組) 時使用 HTTPS 連線處理 CA 認證...

libwww-perl 裡的 LWP::UserAgent 可以處理 HTTPS,並利用 CA 驗證 public key 是否簽過。在 FreeBSD 下安裝 ca_root_nss 後可以在 /usr/local/share/certs/ 下看到檔案,於是可以這樣用:

#!/usr/bin/env perl
use strict;
use warnings;
use LWP::UserAgent;

INIT {
    my $ua = LWP::UserAgent->new;
    $ua->ssl_opts(SSL_ca_file =>
        '/usr/local/share/certs/ca-root-nss.crt');

    my $res = $ua->get('https://mail.google.com/mail/');
    print $res->content;
}

Debian 或是 Ubuntu 下則是透過 ca-certificates 裝到 /etc/ssl/certs/ 下,並且分成很多檔案,這時候本來的 ssl_opts 就要改成 SSL_ca_path => '/etc/ssl/certs/';

PS:FreeBSD 上因為是單檔,依照 SSL_CTX_load_verify_locations(3) 這邊的說明,沒辦法用 CApath...

MySQL HandlerSocket 的情況...

前幾天 jnlinOSDC.TW 2011 上面講了「HandlerSocket – A NoSQL Plugin for MySQL」,剛好 Percona 的 Ryan Lowe 也提到了「What’s up with HandlerSocket?」,試著分析 (並猜測) HandlerSocket 為什麼沒有被廣泛使用。

除了技術的問題外,最主要在於運作:Open Source 不是把程式丟出來就覺得沒事了,要僅可能讓使用者容易使用。

比較好運作方式是在重大的 bug 修掉之後就推出 minor version release,一方面讓一些願意整合的單位有「基準」可以整合 (像是 Percona 這樣的公司),另外一方面可以讓 community 感覺是個有在動的 project...

像是文章裡提到的兩個 bug,一個在今年年初已經修正 (write invalidate),另外一個大約兩個禮拜前修正了 (insert auto-increment),只是很多人不太清楚而已。

目前這個專案的感覺跟 Facebook 丟出來的 memcached 還蠻像的:「facebook / memcached」,Facebook memcached 的情況是很明顯「老闆說要 open source,我就丟出來吧」的感覺,原來的 community 也懶的理他,看一看有沒有可以用的 code 可以整合,然後繼續發展自己的...

CPAN 官方支援 Syntax Highlighter...

剛剛看到 CPAN 網站上直接由官方支援 Syntax Highlighter:Syntax highlighting for search.cpan.org,雖然目前的 UI 做的並不太好 (選擇 theme 的選擇條應該是上下都要有,目前只有最下方),但仍然是進步不少...

之前的 Greasemonkey script 在 Firefox 4.0 上爛掉 (因為 async loading 的關係),本來還在想要怎麼處理,現在看起來就用官方提供的就好了...

Facebook Like 的 JSON/JSONP 數據...

Hacker News 上看到這個 url:「http://graph.facebook.com/http://news.ycombinator.com」,看起來就是 Facebook Like 的 JSON output:

{
   "id": "http://news.ycombinator.com",
   "shares": 930
}

測了一下,發現可以吃 JSONP:「http://graph.facebook.com/http://news.ycombinator.com?callback=test」:

test({
   "id": "http://news.ycombinator.com",
   "shares": 930
});

暫時還想不到能拿來做什麼... 不過看起來蠻方便的 :o

header file 與 GPL(v2) 的「衍生作品」...

Slashdot 上看到 Richard Stallman 在 2003 年 1 月對於 GPLv2 header file (當時只有 GPLv2,沒有 GPLv3) 對於作品是否有「感染力」的看法:「RMS On Header Files and Derivative Works」,也就是「如果我用了 GPLv2 的 header file,是否我的 code 因此就要使用 GPLv2」的問題。

Richard Stallman 在找了律師談過之後,引用 header file 不足以成為 GPLv2 裡面定義的「衍生作品」(Derivative work):

Our view is that just using structure definitions, typedefs, enumeration constants, macros with simple bodies, etc., is NOT enough to make a derivative work.

這篇剛好回應最近有人質疑 Android 因為使用 GPLv2 header file 而軟體本身使用非 GPLv2 授權的問題:「Android Faces Serious Linux Copyright / Copyleft Issues with GPL」:

Google used Linux headers, but did not release Android under the same GPL2 license, which is the most basic precept of GPL. (Android is released under the Apache Commercial License.)

多使用 namespace::clean 與 namespace::autoclean

純粹實際驗證用:

因為 Carp 預設會將一些函式 export 到現有的 namespace 下,如果不使用 namespace::clean 或是 namespace::autoclean 這類工具幫你清除,會造成 namespace 與 object 內帶有這些函式。

結果是:

可以看到沒有 B 沒有 clean 導致外面 (package main) 可以看到 carp

其實這篇是要測 pastie 是不是比 Gist 好用... :o

非 root 環境下的 App::perlbrew 與 App::cpanminus

跟 gugod 討論後發現我之前所寫的方式有問題,所以重寫一篇...

首先是安裝 App::perlbrew 的方式:

wget --no-check-certificate http://xrl.us/perlbrew
chmod a+x perlbrew
./perlbrew install
./perlbrew init

這樣在自己的目錄下就會有 perlbrew 了,接下來是設定環境變數:

source ~/perl5/perlbrew/etc/cshrc # (for csh/tcsh)
source ~/perl5/perlbrew/etc/bashrc # (for bash)

並將自己的 ~/.cshrc 或是 ~/.bashrc 裡加入上面的 source 指令。

原來下載的 perlbrew 就可以砍掉了,然後把 Perl 5.12.3 的環境建好:

rm perlbrew
perlbrew install perl-5.12.3
perlbrew switch perl-5.12.3

接著是用 App::cpanminus (standalone) 安裝 App::cpanminus (套件):

wget --no-check-certificate -O cpanm http://cpanmin.us/
chmod a+x cpanm
./cpanm -n App::cpanminus

然後一樣把下載下來的 cpanm 砍掉:

rm cpanm

這樣可以在不碰到「CPAN」這個大模組的情況下,把基本的系統裝好...

App::perlbrew 另外的裝法

Update:這篇內容有問題,請參考「非 root 環境下的 App::perlbrew 與 App::cpanminus」這篇新的說明。

App::perlbrew 的說明,在系統已經有 Perl 的情況下,不需要先用 CPAN 裝 App::perlbrew,可以直接抓 App::perlbrew 的執行檔:

wget --no-check-certificate http://xrl.us/perlbrew 或是
curl http://xrl.us/perlbrew > perlbrew

其中 wget 要加上 --no-check-certificate 是因為檔案實際是放在 GitHub 上,而 GitHub 目前是強制 HTTPS。

接下來直接執行 perlbrew 相關的指令,通常就是:

chmod 755 perlbrew
./perlbrew init
./perlbrew install perl-5.12.3
./perlbrew switch perl-5.12.3

後面的就跟之前提到的一樣了。這樣要建立自己的 Perl 環境就更簡單了...