Jenkins 的 Blue Ocean 計畫,改善使用者操作的友善度...

JenkinsBlue Ocean 計畫打算改善讓人頭痛很久的操作體驗了:

Blue Ocean is a new project that rethinks the user experience of Jenkins.

Jenkins 讓人頭痛有兩個面向,一個是界面很難讀,另外一個是操作流程很沒有規則,所謂「熟悉 Jenkins」其中一個很艱難的任務就是要背下一堆功能「蔵在哪邊」。而這次 Blue Ocean 想改善的事情看起來主力放在界面,對於流程修的比較少... 即使如此,這還是可以讓使用的人減少一些痛苦就是了...

成功與爆炸的表現:

在專案頁面的後面有提到 Blue Ocean 用的技術:

Blue Ocean is built as a collection of Jenkins plugins itself. There is one key difference, however. It provides both its own endpoint for http requests and delivers up html/javascript via a different path, without the existing Jenkins UI markup/scripts. React.js and ES6 are used to deliver the javascript components of Blue Ocean. Inspired by this excellent open source project (react-plugins) an <ExtensionPoint>pattern was established, that allows extensions to come from any Jenkins plugin (only with Javascript) and should they fail to load, have failures isolated.

又是個不需要用 SPA 呈現的東西跑去用 React 了...

AWS 的 ALB (Application Load Balancer)

前幾天跟 AWS 的人開會的時候得知 ALB 的 beta program,今天就看到正式公開的消息了:「New – AWS Application Load Balancer」。

最主要的是對 WebSockets 與 HTTP/2 的支援,這個需求都喊很久了:

WebSocket allows you to set up long-standing TCP connections between your client and your server. This is a more efficient alternative to the old-school method which involved HTTP connections that were held open with a “heartbeat” for very long periods of time. WebSocket is great for mobile devices and can be used to deliver stock quotes, sports scores, and other dynamic data while minimizing power consumption. ALB provides native support for WebSocket via the ws:// and wss:// protocols.

HTTP/2 is a significant enhancement of the original HTTP 1.1 protocol. The newer protocol feature supports multiplexed requests across a single connection. This reduces network traffic, as does the binary nature of the protocol.

另外是 url routing,不過目前看起來只能設 10 條,我猜可以問問能不能加吧:

An Application Load Balancer has access to HTTP headers and allows you to route requests to different backend services accordingly. For example, you might want to send requests that include /api in the URL path to one group of servers (we call these target groups) and requests that include /mobile to another. Routing requests in this fashion allows you to build applications that are composed of multiple microservices that can run and be scaled independently.

As you will see in a moment, each Application Load Balancer allows you to define up to 10 URL-based rules to route requests to target groups. Over time, we plan to give you access to other routing methods.

再來是改善了之前抱怨很多的 health check:

Application Load Balancers can perform and report on health checks on a per-port basis. The health checks can specify a range of acceptable HTTP responses, and are accompanied by detailed error codes.

改進了不少東西...

MIT 開發出靜態分析工具,找出 23 個 RoR 軟體未被發現的漏洞

MIT 弄出來的新玩意,靜態分析工具叫做 Space:「New MIT Scanner Finds Web App Flaws in a Minute」,MIT 官方的報導在「Patching up Web applications」這邊:

In tests on 50 popular Web applications written using Ruby on Rails, the system found 23 previously undiagnosed security flaws, and it took no more than 64 seconds to analyze any given program.

接下來就是什麼時候會放出來了...

AWS Device Farm 支援手機上的 Web Application 測試

AWS Device Farm 支援在 iOSAndroid 上測試 Web Application 了:「AWS Device Farm Update – Test Web Apps on Mobile Devices」。

支援愈來愈多東西了...

AWS WAF (Web Application Firewall)

Amazon 推出了 AWS WAF,也就是 Web Application Firewall:「New – AWS WAF」。

架構在 CloudFront 上的安全服務,可以想像到會依照 request 數量收費外,rule 本身也要收費,不太便宜的感覺:

AWS WAF is available today anywhere CloudFront is available. Pricing is $5 per web ACL, $1 per rule, and $0.60 per million HTTP requests.

這個收費標準看起來不像是會把 ModSecurity 預設的 rule 丟進去養... 不過 WAF 主要是用在對軟體主體沒有修改能力時的替代方案 (沒有 source code,或是線上服務緊急需要防堵),以這個角度來看的話好像還好?

另外一點也許可以找人問問看,WAF 不是設計在 ELB 上,算是策略考量嗎?

Mozilla Developer Network (MDN) 上的 JavaScript 教學

Mozilla Developer Network (MDN) 寫了一篇關於 JavaScript 的介紹文章,算是以現在的角度來教 JavaScript:「A re-introduction to JavaScript (JS tutorial)」。

不是給完全不懂的人入門看的,而是對程式語言有了解的人看的。

文章裡面不單純只是教學,還引用了許多重要的文獻,尤其是 ECMAScript 規格書。有想要考據確認規格書怎麼定義會很方便。

而最後面還提到了 browser 上 DOM 實作時的 memory leak 問題以及解法,這對於現在 single page application 的應用也愈來愈重要了。

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 的話,那這裡應該蠻適合你的。

Google 將發現安全問題的獎勵延伸到 Open Source 專案上...

Slashdot 上看到 Google 將發現安全問題的獎勵從自家產品延伸到 Open Source 專案上:「Google Offers Cash For Security Fixes To Linux and Other FOSS Projects」。

官方的公告在「Going beyond vulnerability rewards」,規則則是在「Patch Rewards – Application Security – Google」。

初期限制在這些專案上:(直接複製過來)

  • Core infrastructure network services: OpenSSH, BIND, ISC DHCP
  • Core infrastructure image parsers: libjpeg, libjpeg-turbo, libpng, giflib
  • Open-source foundations of Google Chrome: Chromium, Blink
  • Other high-impact libraries: OpenSSL, zlib
  • Security-critical, commonly used components of the Linux kernel (including KVM)

獎勵金額從 USD$500 到 USD$3133.7,這邊的 31337 應該是出自「Leet」吧...

這算是一種回饋社群的方式...

CloudFlare 的速度...

CloudFlare 是一種 CDN 服務,相較於其他 CDN 會被歸類到 AkamaiDynamic Site AcceleratorLimelight NetworksDynamic Site Platform,或是 EdgeCastApplication Delivery Network

這類型的 CDN 加速服務,如果用在完全沒有考慮最佳化的網站上,效果應該會很明顯。但如果拿到 WordPress 或是其他 open source 軟體上,反而會因為軟體已經做了不少處理,上了 CloudFlare 反而因為多了一層而變慢。

不過會變慢多少呢?有人跳下去測試寫報告了:「Cloudflare Showdown」,如果懶得看中間的數據,可以看最後的結論「Conclusion」。

如果用在已經最佳化過的網站上,用 CloudFlare 會慢不少,如果是 WordPress 及其他 open source 軟體,最好的情況是快一點點,但最差的情況會慢個幾倍... 作者下的結論是「不要用」。

跟預期差不多,動態資料的加速基本上是個商業包裝而已,真正需要加速還是得自己把可以 cache 的部份切割出來。

fPrivacy:在 Google Chrome 下調整 Facebook 應用程式可用權限

fPrivacy 的說明「Makes Facebook permissions optional.」把功能說明的很清楚,就是在授權 Facebook 權限的時候,把應用程式可用權限調低。

Plurk 為例,當 Plurk 需要 Facebook 權限時,提出需要這些權限:

你可以發現上方多了一條東西。這時候你可以把 publish_actions 勾勾拿掉 (看這個意思應該是「以我的名義貼文」的權限),按下 Update 按鈕後:

按下 Update 按鈕後,就把需求變少了。甚至你可以再拔掉 email 這組,再按 Update 按鈕:

就什麼權限都不給他了,這拿來對付過度要求權限的應用程式還蠻好用的...