.net magazine: 2011 in review 系列精選

最精采、本年最有參考價值的網站.net magazine都包了

[JS] 2011 in review: 20 sites that pushed JavaScript to the limit

[webGL] 2011 in review: 20 sites that took 3D to the next level

[HTML5] 2011 in review: 20 HTML5 sites that changed the game

[CSS] 2011 in review: 20 CSS sites that rocked!

以上名單絕對有overlapping，Enjoy XD

那些我從github學到的事：更好的git workflow

[原文:Better git workflow - lesson learnt from github]

「Master是可以depoly的」(針對開depoly專用分支說的)
「如果你緊張就depoly到 staging」(如果你為人謹慎或者是個會讓master
掛掉的笨蛋)
「讓分支(branch)簡單」(merge/rebase一點也不好玩，又難管)
「code review? 發個pull request，然後大家討論」(明顯比開branch做feature然後再在code上做review好)
「pull request超便宜(hell cheap)不用省」(新feature、實驗甚麼的用pull request討論或實作比branch/丟到issue tracker/fork好－不行的放在一邊就好)
「優先順序(Priority)是觀察所得，不是產生或指派出來的－不然這就是必要性(necessary)而非優先順序」(全部都重要就沒有東西是重要的)
「如果這真的很重要這早就完成了。」(所以issue tracker寫太多也是無謂－有人覺得這很重要就會接手處理)
- How GitHub Uses GitHub to Build GitHub (這組slide超讚，大推~)

致世人: 簡化事物吧。如果你用簡單工具就可以有不錯+無痛的工序就用簡單工具
(反正弄的複雜都是沒人理時就別搞那麼多了)

如今Github已經做到了簡單: 簡單工具 + 更好的工序 = 超讚的產品

加上他們有著最好的管理風格: 「沒有會議，沒有死線，沒有經理」，「想工作時就工作」...而
THE ZONE™這個概念簡直是一流

Oh, I like this guy. [GLaDOS調]

Extra
1. Github有搞自己的emoji，你可以在github產品 (github, gist) 的comment位用: GitHub Emoji
2. 其實 How GitHub Uses GitHub to Build GitHub 最後一部分有很多github的小秘技
=============
貓咪定理: 如果有甚麼是我覺得很煩不想用這東西一定有甚麼問題－通常是太複雜。

Flash: 瀏覽器plugin之死

Flash Player之死是從Adobe宣佈不再做Mobile版的Flash Player開始...
新聞稿

然後是Adobe把Flex放手給Apache基金會的消息
Adobe將Flex捐贈給Apache基金會

本文要說的是從geek/網頁開發者的角度去看的Flash Player (Plugin)之死。如果不熟Flash系列、需要名詞解說或想參考一下Flash開發者的意見可以看下文
Adobe放棄開發行動平台Flash Player之我見

利申: 我是網頁開發者，而且是HTML5+CSS3+jQuery為主，外加cross-browser及cross-platform (desktop+mobile) 。
==================
通常一個plugin會死都是離不開當年Java applet的死亡方式: 慢、browser crasher、安全問題多、有取代技術 (Flash)，儘管當時Applet是很強大但依然不得人心、難逃一死。

(其實applet某些功能是Flash仍然難以取代，所以其實只是衰落而非死亡－是少了很多人用，但某些特殊Applet仍是有的)

而今日的Flash Player面對的問題也是: 慢*、browser crasher、安全問題多、有取代技術 (HTML5)。
( 歷史是不斷重演的。(′_ゝ`) )
* IE是好一點有硬體加速，可是其他Browser都沒有....

然而真正替Flash Player釘蓋的是: 資源緊拙、多重解像度、沒有滑鼠鍵盤的手機和平板。

簡單來說就是: 在Mobile上是得Flash Player無所用。看影片燒電 (硬體支援不足只好去燒CPU)、一堆遊戲看到玩不到 (鍵盤操作的全滅)、網站是燒完頻寬後再加上一整個難用 (解像度問題)...所以就算Flash Player可以配合與其八字嚴重不合的Webkit engine，以desktop環境為主的Flash跟本是不配合，Flash開發者或是Flash Player要改成mobile friendly的方式也很困難。

所以Adobe的Flash派在Mobile Browser上如何努力也是玩不下去。(Apple和M$顯然是老早知道所以從來沒有在自家手機OS的Browser搞Flash支援)

在"Write Once, Run Everywhere"的理想和渴望消滅plugin的HTML5的夾擊之下，Flash在Browser應用上喪鐘已響: 網站這部分在HTML5日漸完善的世界，純Flash網站這種用家不能轉編碼、維護困難、SEO效果不良(架構、語意全滅)、Accessibility差的邪道應該被淘汰；Rich Media (Video & Audio)、傳統動畫應該可以再撐一會，在Video和Audio在戰格式、用CSS3/HTML5做動畫的IDE未完善之時可以作為過渡 (Sencha Animator、Hype、Radi、EDGE/MUSE等IDE離動畫師用的IDE太遠了)；作為Browser Game的前景則是未明－雖然為數極多的新Browser Game仍是Flash，但在Browser Game其中一大市場Facebook自己也在推HTML5時以及開發者把心力投向可以賺錢的Mobile Game的時候，Flash Game的存在價值也許是日漸下降 (儘管因為IE 6-8會死慢很多)。

是以Flash可能會是Browser Plugin橫行的時代的最後榮光: Flash作為IDE應該可以透過Air支援Desktop、LLVM轉原生App去支援Mobile、甚至是HTML支援全平台得以繼續存在，說Flash要死其實是不太正確。然而以Browser Plugin存在的Flash Player則劫數難逃－Mobile上的已死，Desktop的也難逃衰落至Applet般的命運－儘管這要數年的時間。

==================
後記:
其實本文是在barcamp當日在WebOS上惡搞一堆Flash Demo和日後再和動畫師聊天的成品。
後記之後記:
Adobe Flash Player的Developer, @mesh, 出來解畫，政治原因是有但有更多是技術上的原因: Clarifications on Flash Player for Mobile Browsers, the Flash Platform, and the Future of Flash

RIP, Steve Jobs - Thank you for a better web & real HTML5

Dear Steve,

Thank you for your innovative iPad and bringing HTML5 into the real world.
Thank you for leading Apple to push a better, beautiful web standard  (HTML5 & CSS3), and say no to Flash - it change the web again.
Thank you for making the best development machine I have. (iMac '09 / Snow Leopard)
Thank you for founding & leading the amazing Apple, Inc. Please Rest in Peace.

Best Regards,
Vinci (@vincicat)
=======================
要不是Apple推HTML5 & CSS3 + No Flash + iPad，大概沒有今天的Web: HTML5的興盛與Adobe & M$對HTML5的轉向以至今天的browser軍備競賽…
Steve，Thank you.

HTML5 Little thought: legacy template

Question came from the presentation of @codepo8:

using html5 sensibly
audio and video (video is 'coming soon')

His idea: How about moving  IE < 9 fixes to server-side? Padding with DIVs with classes and no JS for IE?

If think with Responsive Web Design...

The Idea will be: make responsive web design more responsive with legacy web browser.

The reason: even JS patch works, still, legacy browsers are too problematics to developers. (e.g. the speed, DOM incompatibility, etc)

Idea is here but the implementation is problem...may be similar to mobile template (lets call it legacy template), with much more inaccuracy. Also it may be suffer from the problem of versioning again.

IE, please die. Old version of modern browsers, please rest.

[JS] 嚇一跳的效能差異: += VS array.join

這個大概很多人沒想到，這兩件風馬牛不相干的東西可以做相同的事，而且有效能上的差異
那麼...+=和array.join其實有什麼關係呢?

1. +=可以用array.push + array.join代替
2. array.join一般來說*會比+=快

*此"一般來說"是指在市場上流通的browser的主要版本
原因...正是因為javascript的string也是immutable**的
因為其immutable特性造就string concat時大量的object生產、reference切換，其影響可以比string的長度及concat次數對整個operation的效能影響更大(和早期Java類似)
**1. 如果你有學過Java，Javascript的string和Java的String/string一樣－一旦被賦值即不可更改，要改要生新object
2. 這immutable的特性加上js對primitive object的處理手法導致string method的寫法十分古怪
數據: [Further analysis of += vs array.join, broken down by browser]
這個branchmark的string size及loop次數很夠，加上一些library的bug report，IE那部分絕對可信
觀察:

1. 在數據被足夠放大的情形下，舊版FF及Safari的array.join略快;opera及chrome v8除外，他們是+=比較快
   不過前兩者的新版也修正了
   (其實Chrome和Opera是正確的，operator應該是比較快而且+=是比較多人用的寫法..除perl派外很少人會用join吧?)
2. IE的+=慢得嚇死人...似乎IE對於object lifecycle control及code優化做的很差

結論:如果你是支援IE 6和7為主又有一定數量的string concat，你最好用array.join...
另外，IE要自己做的優化比較多
(M$實在不擅長搞script engine和string,orz)

JS加速: Speed up your JavaScript

Nicholas C. Zakas (NCZ)幾天前出完整個Javascript加速系列:
Speed up your JavaScript, Part 1
Speed up your JavaScript, Part 2
Speed up your JavaScript, Part 3
Speed up your JavaScript, Part 4
Part 1是loop (array looping優化)，Part 2是function (anonymous function加速法及Memoization)，Part 3是Memoization，Part 4是DOM(DOM DocumentFragments)＜br /> (*部分方法是很吃Ram的，注意)
[More]
關於loop另外有一篇深入探討不同的for loop寫法效能 [What's the Fastest Way to Code a Loop in JavaScript?]
關於DOM DocumentFragments，John Resig有很詳細的文章探討 [DOM DocumentFragments]