在 Gmail 上做 CSS 效果的問題

TechCrunch 上看到的「Gmail, We Need To Talk」這篇裡提到 Gmail 的問題,尤其是 CSS 這塊:

Each Gmail client renders email differently. You may not be aware of this, but each Gmail client has its own set of frustrating quirks. Having to deal with each version of Gmail makes creating email a nail-biting chore:

  • Gmail.com Webmail. Supports <style> but does not support ids and classes.
  • Gmail Webmail for Business. Does not support <style>.
  • Gmail App for iOS. Randomly increases font sizes by 50 percent (no <style>).
  • Gmail App for Android. Randomly ignores container widths (no <style>).
  • Gmail App for Android (for non Gmail.com addresses). Does not support background images in addition to ignoring container widths (no <style>).
  • Inbox by Gmail for Android. Randomly ignores container widths but does so differently than Gmail App for Android (no <style>).
  • Inbox by Gmail for iOS. Does not support <style> but seems to not suffer from as many quirks as other Gmail mobile apps.

這也就可以理解為什麼有時候手機上看起來怪怪的了 XD

在 Mac 上把資料備份到 Amazon Glacier 的軟體

Hacker News Daily 上看到「Freeze - the ultimate Amazon Glacier file transfer client for Mac」這個軟體,需要 Mac OS X 10.10 以上的版本才能用...

拿來丟東西應該還不錯 (方便的 client),建一個對應權限 IAM 帳號,然後把 key 丟給他用吧...

KKBOX 徵人:軟體開發中心 (i.e. Client Team)

索引:


在寫自家的介紹時,特地跑去跟軟體開發中心的主管要 Client Team 的介紹,人家交稿的速度快多了... Q_Q

Anyway,這篇是由 Client Team 的主管所寫的介紹,一樣是所有的部門都有職缺 (人力銀行上未必有開),有興趣的可以提供 resume 到 recruit at kkbox.com 這個信箱。


軟體開發中心 (Application Develop)

在 KKBOX 裡頭,我們還蠻習慣以老派的 Client/Server Side 來稱呼不同技術背景的開發人員,Client Side 說穿了就是開發 App 的那群人,只要你喊得出來的主要平台,大概就是我們負責的。

軟體開發隨著功能的演進,程式碼就會變得又肥又大,自然免不了些壞味道,面臨設計架構的難題,我們希望內部開發者能夠清楚三件事情: Design Pattern,Unit Test,和 Refactoring。上述觀念應當不用多說什麼,幾乎都變成顯學了。我們期盼透過一些原則和流程來讓開發工作變得不會那麼難以維護。

Client Side 目前共有四個 App 開發部門和 SQA 部門:

  1. Windows 開發部: KKBOX 在早期開發時,當時主流的作業系統還是 Windows XP,所採用的開發框架是 MFC,儘管技術很老,但那是個什麼事情都可以自己打造的年代,我們也樂此不疲。會用到 C++/COM 與微軟早年推出的視窗各類技術 MFC/ATL/DirectShow 。說個秘密,我們也還最低限度的維護著 KKman 呢。
  2. .NET 開發部: 主要負責的是 Windows Store App 和 Windows Phone 的開發,採用的是微軟在下個世代主推的 Universal App 開發框架來打造 KKBOX 在三個 Windows 平台的體驗。這部門需要熟悉的程式語言是 C#,部門有兩位微軟 MVP 相當熟悉微軟的平台技術,很活躍於微軟舉辦的聚會。
  3. Android 開發部: 很明顯地,就是在 Android 手機作業系統上開發 App 的部門,除了手機之外,我們也在 Tablet / STB / Smart TV 各式裝載 Android 系統的裝置上開發。需要熟悉 Java 程式語言和 Google Android SDK。這部門的開發人員很常在 Android Taipei 上出沒,分享開發心得。
  4. iOS 開發部: 聽名字應該也不用多解釋,主要就是在 Mac/iPhone/iPad 上開發 App,為了掌握最新技術每年我們都會派人前往舊金山參加 WWDC。需要會的程式語言是 Objective-C,當然蘋果力推的 Swift 也開始加入開發行列,每個月也都在 CocoaHeads 聚會中跟其他開發者閒聊。
  5. 測試開發部: 俗稱 SQA 部門,著重依據測試的原理和方法來設計測試案例,因此像是黑箱測試方法的 BVA 和 ECP,以及 MBT … 等等都是在設計測試案例時,會用到的測試原理。內部有個小組專門負責研究與建置自動化測試框架,讓各個專案可以各自依照需求建立自己的測試系統。需要熟悉 Python 程式語言,同時我們也將日常得到的心得放在「科科和測試 Testing with KK」上,提供給同樣想把軟體測試工作做好的每個人。

順道一提,除了 KKBOX 以外,還有 KKTIX,Hami Music 和日本服務 Utapass,也都是上述開發部門負責的。所以你要真的那麼愛寫 App 的話,那這裡應該蠻適合你的。

Tor 官方預測將會被攻擊

Tor 官方預測將會被攻擊:「Possible upcoming attempts to disable the Tor network」。

透過扣押機器的方式降低 Tor 對 client bootstrap 的承載能力:

The Tor Project has learned that there may be an attempt to incapacitate our network in the next few days through the seizure of specialized servers in the network called directory authorities.

挑弱點打...

Git 安全性更新

GitHub 發了一篇公告說明這件事情:「Vulnerability announced: update your Git clients」,而 Git 官方的公告在這邊:「[ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks)」。

這次的問題起因很好理解,就是有人可以在 repository 裡面放 .GIT 這樣的目錄名稱,配合將大小寫視為一樣的檔案系統 (Windows 系列用的 FATNTFSMac 用的 HFS+),裡面就可以放各種設定值,有機會在 checkout 下來時就執行,或是透過其他的 git 指令執行。

GitHub 在 server 端擋下來了,不過還是建議 client 端趕快更新到最新版,這些版本會從 client 端擋下這些路徑。

這次 CVE 編號是 CVE-2014-9390,不過 NIST 的資料庫裡面沒有列出來?

Google Chrome 上使用 Native Client (NaCl) 執行 Vim...

Twitter 上看到有人講:「Vim console application running using NativeClient」,實際跑起來長這樣:

只是跑起來測試,因為平常用的平台 (UbuntuMac OS X) 都有原生的 Vim 可以用...

這算是 Native Client 的火力展示嗎?

OpenSSL 的 Heartbleed 漏洞不限於 Server,也包含 Client...

Heartbleed 是惡意的 client 可以利用 OpenSSLHeartbeat Extension 漏洞取得 server 的機敏資訊。

而在「Testing for "reverse" Heartbleed」這篇說明 (並且 PoC) 這組漏洞也適用於反向的操作,也就是惡意的 server 可以取得 client 的資訊。

exploit 相較起來比正向的難一些,但還是可行並且成功做出來了。文章裡有描述怎麼實做的...

換句話說,反正手上的 OpenSSL 都趕快升級...

Amazon CloudFront 支援 EDNS-Client-Subnet

Amazon CloudFront 今天的新聞:「Improved CloudFront Performance with EDNS-Client-Subnet Support」。

目前 CDN 大多都還是靠 GeoDNS 技術達到分流技術,但另外一方面,Google 的 Public DNSOpenDNS 服務不一定在每個 ISP 都有設機房,這使得 CDN 服務無法靠 DNS server 的 IP address 正確導到離使用者 ISP 最近的 CDN (也就是原文指的 sub-optimal performance)。

EDNS-Client-Subnet 是一個 draft,讓 DNS resolver 可以把 client 的網段資訊帶給 CDN 的 DNS server,進而改善定位。

剛剛測試發現 Akamai 也支援了,在「OpenDNS: Why doesn't Akamai support the edns client subnet extension? This would allow OpenDNS and Google DNS to more effectively provide the geo location of the CDN and allow Akamai to send content to clients at higher speed.」這篇也有提到。

以前會鼓勵使用自己家的 DNS resolver 的理由又要消失一個了 :p

NaCl (Native Client) 總算要支援 ARM 了...

OSnews 上看到 NaCl 要支援 ARM 了,在這之前的版本都只能跑在 x86 family 上面:「Native client now supports ARM」。

另外在 The Chromium Blog 上也提到這件事情:「Native Client support on ARM」。

下一個預定要完成的計畫是 Portable Native Client (PNaCl),希望用 LLVM 一統江湖... XD

AWS EC2 全面支援 64bits,並補上產品線...

之前用 AWS EC2 的人常遇到的狀況是,t1.micro 記憶體太小會常常 out of memory (用 EBS 硬撐當 swap 效能不好),但 m1.small 只能跑 32bits,為他做完整的 32bits image 維護成本實在不划算,因為等到之後變大後又得改做一份 64bits 的 image,如果從 t1.micro 改用 m1.large 又嫌太大台...

現在這個問題總算是解決了:「Announcing three new Amazon EC2 features」,EC2 這次提供新功能包括:

  • 推出新的 instance 種類 m1.medium,收費是 m1.small 的兩倍,所以規格大致上也是 m1.small 的兩倍,其中記憶體是 3.5GB RAM。
  • m1.small 與 m1.medium 除了可以跑 32bits 以外,也可以跑 64bits。

於是本來的問題可以用不同方向解決:

  • 本來做的 32bits image 當 m1.small 不夠用時也可以先拿 m1.medium 擋著。
  • 既然所有 EC2 instances 都可以跑 64bits,以後只要做 64bits image 就好了。
  • 同樣的,現在用 m1.large 嫌太大台的可以降到 m1.medium 或是 m1.small。

另外這次提供 Java SSH client,可以讓你直接在 Web Console 上面一貫作業,這個就比較用不到了...