Month: February 2014

在 S3 上儲存大量資料時要注意的事情

印象中要在 Amazon S3 上面存大量資料時需要注意 key 的命名，用 Google 找了找發現官方的「Request Rate and Performance Considerations」這篇。

文章中有提到這是對有大量存取需求時才需要注意的事項：

The guidelines in this section apply if you are routinely processing 100 or more requests per second. If your typical workload involves only occasional bursts of 100 requests per second or more, you don't need to follow the guidelines in this section.

不過平常即使沒有需要大量存取，還是可以照著做，因為應該不會有負面影響。如果能照著上面的方式先做，之後也許會受益...

由於 Amazon S3 是使用 key-prefix 當作 partition 的依據，所以 prefix 的值對於效能很重要。官方推薦的幾種方法都是對 key-prefix 下手：

  • 對整個 path + filename 的字串 hash 後當作 prefix。舉例來說，examplebucket/2013-26-05-15-00-00/cust1234234/photo1.jpg hash 後加到前面，名稱變成 examplebucket/232a-2013-26-05-15-00-00/cust1234234/photo1.jpg。
  • 將最前面一段 reverse string。像是把 2134857/data/start.png 變成 7584312/data/start.png。

90 年代的網站...

前天看到的「Only 90s Web Developers Remember This」文章裡面在懷舊 (?)：

  • 1x1.gif
  •           
  • Dotted underlines, border effects
  • DHTML
  • Pixel fonts
  • Buttons

然後在 Facebook 上看到 zonble 貼的：「DHTMLConf」，太讚了 XDDD

讓人懷念的東西... XDDD

巴西與歐盟決定自己拉海底光纜...

為了避免美國的監聽，歐盟與巴西決定自己拉海底光纜：「Brazil, Europe plan undersea cable to skirt U.S. spying」。

目前計畫從葡萄牙的里斯本 (Lisbon) 拉到巴西的福塔雷薩 (Fortaleza)，而且巴西總統 Dilma Rousseff 挑明了就是對美國的監控有意見：

We have to respect privacy, human rights and the sovereignty of nations. We don't want businesses to be spied upon,

能做到什麼程度還是個問題，但這對於解決網路過度中心化 (以美國為中心) 應該有幫助？

WordPress.com 上的電子商務平台

WordPress.com 上的商務帳號 (WordPress.com Business) 可以架設各種電子商務平台了：「WordPress.com Business Users: eCommerce Has Arrived!」。

由 WordPress.com 出手感覺就差很多，以前要自己找人兜半天，這樣就省下一大堆功夫了...

Buffalo 推出三台以 dd-wrt 為號召的機器...

在「Buffalo Launches Three Open Source DD-WRT Wireless Routers」這邊看到 Buffalo 推出三台以 dd-wrt 為號召的機器。

Buffalo 官方的新聞稿在「Buffalo Introduces Open Source DD-WRT Wireless Networking Solutions」這邊。

在美國機器是三年保，另外加上免費 24/7 基本技術支援的電話：

  • AirStation™ AC 1750 Gigabit Dual Band Open Source DD-WRT Wireless Router WZR-1750DHPD is available now at an estimated MSRP of $189.99.
  • AirStation™ N600 Gigabit Dual Band Open Source DD-WRT Wireless Router WZR-600DHP2D will be available in early March at an estimated MSRP of $109.99.
  • AirStation™ N300 Open Source DD-WRT Wireless Router WHR-300HP2D will be available in early March at an estimated MSRP of $59.99.

這價錢看起來普普通通，等出來了再看評價吧 XD

PHP Composer 的安全性問題

Composer 是 PHP 上新一代的套件管理軟體。

Composer 與之前各種方案不同的地方在於，後面掛了 Packagist 這個 PHP package archivist，讓使用者很方便的取得套件 (以及更新)。

其中有一個功能是 replace，表示我所開發的這個套件「宣稱」可以取代其他套件 (通常是 API compatible)。

看到這個功能的時候，以為是要讓 Packagist 能夠串起連結。畢竟偶而會發生「這個套件最新版是 2008 年了，到底有沒有後續維護啊」的情況。如果 Packagist 官方網站可以串起連結，可以節省開發者時間，而且也可以利用 Packagist 上的熱門度來決定要用哪一個後繼者。

但實際上與預期的不同，Composer 的預設值是會「自動」尋找更新並且真的使用，也就是前幾天被丟出來的議題：「Composer is wide open with a massive security vulnerability」。

攻擊者只要在 Packagist 上面上傳一堆含有惡意程式碼的套件 (並且利用 replace 宣稱可以取代 ZF2 或是 Laravel)，受害者在 composer update 的時候就有機會抓到這些有惡意程式碼的套件。

而最糟糕的是，主要開發者認為這不是問題，還寫了一大篇文章顧左右而言他之後說「錯覺啦～」：「Composer: Replace, Conflict & Forks Explained」：

Replace is not a bug. Don’t run composer update in automated systems. Forks are allowed on Packagist. Don’t be an idiot when publishing a fork. Got an unexpected fork on update? Your dependencies conflict with the original package. Use conflict (syntax like require) in your composer.json to blacklist the fork and see an explanation of the dependency issue.

於是發現問題的人就爆炸了。

依照往例，vendor 不覺得是問題的安全漏洞，只能把事情弄大爆出來逼 vendor 修。

修正在「Limit Replace / Provides to packages required by name in root package or any dep」這裡。最新版的 Composer 裡已經納入這個修正了。

用 browserify 將 npm 的函式庫包到瀏覽器上用...

browserify 可以將用到的程式碼都包成一包，拿到瀏覽器上使用。

舉個例子離說，先寫了一個 a.js：

(function(){
    var el = document.getElementById('output');

    var j2x = require('json2xml');
    el.innerText = j2x({a: 1});
})();

其中可以看到直接拿 require() 把 json2xml 抓進來。但在瀏覽器裡要自己處理有哪些 dependency 很麻煩，就用 browserify 拉出來：

browserify a.js -o a.bundle.src.js

生出來的 a.bundle.src.js 就可以拿到瀏覽器裡使用了！如果需要的話，還可以用 JS Compressor 再壓起來再拿到瀏覽器裡使用。

最後補充一下，browserify 的安裝方式很簡單：

npm install browserify

就是這樣而已。

Domain Sharding 的調整...

Domain Sharding 是針對以往瀏覽器常見的「加速技巧」(workaround)，目的是突破瀏覽器對單一 domain 的最大連線速限制。像是 IE{6,7} 在 HTTP/1.1 上的限制是 2。

Steve Souders 在 2008 年整理的「Roundup on Parallel Connections」就有列出當時各瀏覽器的限制。而在 Browserscope 的 Network 可以看到更多新的數字。

而隨著環境一直在改變，桌機限制的連線數也逐漸調高，以及 SPDY 的發展，再加上行動平台的比重愈來愈高，本來的 Domain Sharding 技巧需要重新審視。

在 Etsy 的「Reducing Domain Sharding」這篇文章中提到他們決定減少 Domain Sharding 的數量 (由四個變成兩個)，而改善了反應時間：

  • 在圖片較多的頁面上約減少 50ms～80ms，在一般頁面則是減少 30ms～50ms。
  • 在行動平台上減少 500ms。

這兩個改善使得每次造訪的點閱率多了 0.27 page。

尤其是行動平台上對 Domain Sharding 的敏感程度，讓現在設計網站的人要考慮的更多了...