window 的 hashchange (onhashchange) 事件

hashchange 是 HTML5 event,紀錄一下目前支援的情況:

目前 IE6/IE7 常見的模擬方式是透過 hidden iframe 做類似的效果...

另外在偵測瀏覽器是否有支援 hashchange 可以利用「Detecting event support without browser sniffing」這篇說明的方式偵測是否有支援特定的 event,可以避免使用 browser sniffing。

Markapl:Markup as Perl

Markaplgugod 寫的 Perl module,這是在 miyagawa (宮川達彦) 的 Sunaba 模組上看到的... 以 Perl 的語法建立 HTML。

目前 CPAN 上面 Markapl 的不是最新版 (0.11),在 GitHub 上的 Markapl 比較新... (據說是作者忘記在 release 0.11 後有 commit 了,在寫這篇文章的時候已經 release 新版,等下應該就會看到了...)

至於範例... 直接參考 Sunaba 的 View.pm 會比較快。(我故意連到特定版本,避免之後改動架構這個檔案被搬走。目前版本的 View.pm 請點這個連結)

用 Markapl 除了可以用 Perl 語法外,另外一個「好處」是強迫自己將 css 與 javascript 搬到 template 外面,因為 template 內實在是不好寫... (用「q/.../」?用「<<CSS;」然後「CSS」結尾?gosh XD)

另外補充一點,範例上都沒有 DOCTYPE,請用「outs_raw('<doctype html>');」加在 html 前即可。

用 Dist::Zilla 管理 Perl Module...

之前寫過一篇「產生 Perl Module 的工具:Module::Starter」是用 Module::Starter 管理,另外再配合其他工具上傳到 CPAN 上。前陣子在 GitHub 上亂逛的時候看到有人 Perl module 裡面只有一個 dist.iniChanges,另外就是 lib/t/,就感覺到應該是我要的東西 XD 花了一些時間測試後發現功能不多,但對於初期應該足夠了,等到熟悉後再跳到功能比較完整的管理軟體...

首先先用 dzil setup 設定環境,如果有 PAUSE 帳號的話也能夠整合進去。設定完後記得將 ~/.dzil/ 設為 700,裡面的檔案設為 600。

接下來就是建立模組,像是 dzil new Plack::Middleware::HTMLMinify 這樣的指令。建好後就把 module 寫完,然後設定 dist.ini。(文件上的說明應該夠用)

接下來可以用 dzil build 編,或是用 dzil test 測試。沒問題之後用 dzil release 上傳到 PAUSE。

基本的功能大概就這樣...

Updatedist.ini 的範例可以在 plack-middleware-htmlminify-perl 的 repository 裡看到。

jQuery 1.5.1 RC 1

jQuery 1.5.0 出來以後 (2011/1/31) 沒幾天又準備要出 1.5.1 了,剛剛在官方的公告「jQuery 1.5.1 RC 1 Released」上公佈了 1.5.1 RC 1 的連結 (讓人測試),以及大量的 bugfix 資訊...

昨天看了幾個報社的網站,發現不少網站都用 jQuery:(看首頁的部份)

而「自由時報電子報」首頁沒有看到 jQuery...

jQuery CDN failover 的方式...

之前有在其他網站上看到 failover 的技巧,但剛剛才發現 jQuery 官方網站上也用上了類似的技巧,將 Google (ajax.googleapis.com) 與 EdgeCast (code.jquery.com) 的 CDN:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script>!window.jQuery && document.write('<script src="http://code.jquery.com/jquery-1.4.2.min.js"><\/script>');</script>

雖然 jQuery 網站上是放在開頭,但放在 HTML 最後面也有一樣的效果...

AWS API 的認證方式

Amazon Web Services 有提供很多服務,有的早在「雲端風潮」前就有,有的是最近才推出的。把 AWS Documentation library 每個服務的 API 認證方式看完一遍後,只能苦笑對使用 AWS API 的人致敬...

有幾個心得與感想:

  • 文件雖然套用同一組模板 (用 frame 切開,左邊索引,右邊內容),但其中的寫法並沒有統一。理論上每個 API 都會有的 API 簽名環節在不同的文件裡可能會在不同的章節出現。
  • 認證的方式不一致:
    • 早期的服務很亂,大多都是以 SOAP 為基礎的 API,尤其是跟錢有關的這塊特別明顯 (因為 Amazon 很早就 API 化)。
    • 一開始出來的 S3 使用的是 REST 概念,簽名的值放在 HTTP Header 內,欄位名稱是 AuthorizationCloudFront 是 S3 的延伸,所以認證方式與 S3 相同。
    • 但與 S3 同時期推出的 EC2,以及後來大多數的服務,都是以 GET 為基礎。這時候兩套系統的 API 設計邏輯就不同了。
    • 最近出的 Route53,又再引入了 REST 概念,但欄位名稱為 X-Amzn-Authorization,要放的簽名格式又改變了...

這也是為什麼沒有一套 library 可以一直吃遍 AWS 服務的關係,API 的設計讓人感覺頗疲倦... XD

AWS 的 Elastic Beanstalk...

這相當於 Amazon 跳下來自己做 Java 版的 Heroku:「AWS Elastic Beanstalk: A Quick and Simple Way into the Cloud」(CTO Werner Vogels 的文章)、「Introducing AWS Elastic Beanstalk」。將整套 Amazon Web Services 的技術整合起來,變成 PaaS:「AWS Elastic Beanstalk」。

由於是 Java,所以用 Java 實做的 PHP5 又被拿出來玩了:「PHP on AWS Elastic Beanstalk」:

在 Google Search 上面可以看到一些站台了:

jQuery 對效能的調整...

TwitterjQuery 1.4.2 換到 1.4.4 以後,發現在捲頁時的效能變得很差:「About that slowness on Twitter…」。

這件事情讓 John Resig 在他的 blog 上發表了一篇文章,發現原因在「$something.find(".class")」這種用法,成為壓死駱駝的最後一根稻草:「Learning from Twitter」。主要的原因是 querySelectorAll(".class") 比起 getElementsByClassName() 慢了一些,而 Twitter 的寫法會使得這個 function 的效能明顯放大到影響整體效能的程度...

文章以及 comment 有給一些建議 (cache selector 與針對 scroll event 的處理),記起來以後應該會有幫助...

PHP 的 Heroku

在「PHP Fog Raises $1.8 Million To Be The Heroku Of PHP」裡面提到兩家:PHP FogcloudControl

兩者都是以 PHP 為底層語言基礎的平台。其中 PHP Fog 還沒開張,而 cloudControl 已經開張了,以歐洲的 EC2 為底層。

不過 cloudControl 選用 Bazaar 為版本管理系統,這點不知道是什麼考量... (PHP 是用 Subversion)