YUI的劇院-羅斯Harmes：“移植的Flickr銳3”（36分鐘）
2010年11月19日，7:10上午由埃里克·米拉利亞， YUI劇院 | 開發 | 2評論 
羅斯Harmes前端工程經理為Flickr，最近完成了一個重要的表現層重寫使用YUI 3。 他是一種足以加入我們YUIConf 2010談談，重寫和他和他的團隊如何從銳3的各個組成部分中提取的最大利益。
如果下面嵌入視頻不會出現在你的RSS讀者選擇正確，請務必通過點擊觀看視頻銳劇院的高分辨率版本 。
其他最近的銳劇院視頻：
- 翁Almaer，本加爾布雷思，伊萊恩惠裡，托馬斯·沙，喬·休伊特，瑞安達爾，Tantek切利克，道格拉斯·克羅克福德：YUIConf 2010年面板討論：未來的前端工程 -翁Almaer和Ben Galbraith主持，這一傑出的面 板探索附近未來的紀律，在巨大的變化。 小組成員包括伊萊恩惠裡，Meebo的創始人和前端架構師，在Yahoo!的JavaScript架構師道格拉斯·克羅克福德Tantek切利克，技師和作家;瑞安達爾，Node.js的創造者;喬·休伊特的Facebook，Firebug的創始人和最下載移動應用程序的所有時間（Facebook的內部監督辦公室）;在雅虎的創始人托馬斯·沙，YUI。
- 菲利普·特利斯：測量與迴旋鏢網站的 -菲利普·特利斯，經過較長時間的雅虎和性能專家，討論飛去來 衡量網站性能的開源工具。
- 阿洛伊斯Reitbauer：dynaTrace AJAX版 - dynaTrace提供在Internet Explorer中的Web應用程序的性能分析的最有力的工具之一。 在這次談話中，的dynaTrace工程師阿洛伊斯Reitbauer遍歷四個使用dynaTrace接口的具體分析場景。
- DAV玻璃：Node.js的和YUI 3 - 3銳和Node.js的，一起工作，幫助我們充分認識逐步增強的承諾（和很多其他很酷的東西）。 DAV YUI團隊的玻璃顯示它是如何做的，什麼是可能的使用這些功能強大的工具。
訂閱銳戲劇：
戴維·卡爾霍恩CC圖片：
- http://www.flickr.com/photos/franksvalli/5163803072/~~V
- http://www.flickr.com/photos/franksvalli/5163195923/~~V
共享和擴展： 書籤del.icio.us Digg它！ | reddit！
2評論
很抱歉，評論已被封閉，在這個時候。
YUI庫在Twitter
翻譯
最近的帖子
檔案：
- 2012年2月 （7）
- 2012年1月 （8）
- 2011年12月 （7）
- 2011年11月 （12）
- 2011年10月 （4）
- 2011年9月 （9）
- 2011年8月 （6）
- 2011年7月 （7）
- 2011年6月 （8）
- 2011年5月 （6）
- 四月2011 （10）
- 2011年3月 （8）
- 2011年2月 （5）
- 2011年1月 （10）
- 2010年12月 （24）
- 2010年11月 （21）
- 2010年10月 （11）
- 2010年9月 （17）
- 2010年8月 （18）
- 2010年7月 （8）
- 2010年6月 （11）
- 2010年5月 （11）
- 2010年4月 （22）
- 2010年3月 （22）
- 2010年2月 （16）
- 2010年1月 （8）
- 2009年12月 （9）
- 2009年11月 （29）
- 2009年10月 （14）
- 2009年9月 （12）
- 2009年8月 （4）
- 2009年7月 （5）
- 2009年6月 （7）
- 2009年5月 （7）
- 2009年4月 （7）
- 2009年3月 （15）
- 2009年2月 （10）
- 2009年1月 （7）
- 2008年12月 （11）
- 2008年11月 （12）
- 2008年10月 （16）
- 2008年9月 （4）
- 2008年8月 （9）
- 二零零八年七月 （12）
- 2008年6月 （11）
- 2008年5月 （12）
- 二零零八年四月 （11）
- 2008年3月 （7）
- 二零零八年二月 （10）
- 2008年1月 （6）
- 2007年12月 （12）
- 2007年11月 （6）
- 2007年10月 （5）
- 2007年9月 （8）
- 二零零七年八月 （6）
- 2007年7月 （3）
- 2007年6月 （7）
- 2007年5月 （12）
- 二零零七年四月 （8）
- 二零零七年三月 （7）
- 2007年2月 （7）
- 2007年1月 （8）
- 2006年12月 （5）
- 2006年11月 （6）
- 2006年10月 （11）
- 2006年9月 （4）
- 2006年8月 （5）
- 2006年7月 （2）
- 2006年6月 （3）
- 2006年5月 （7）
- 2006年4月 （2）
- 2006年3月 （1）
- 2006年2月 （14）
評論政策
我們鼓勵貢獻意見，對博客上的談話。 請注意，雅虎可能在我們的全權，刪除的意見，如果他們是題外話，不適當的，或違反我們的服務條款 。
成為一個Yahoo!
你是一個天才的工程師，產品經理，或設計師，尋找自己沉浸在一個充滿創意和樂趣的環境嗎？ 然後來找到一個與我們的工作 。
元：
我轉貼，我無意中在錯誤的條目發送的評論。
關於縮短較長的網址時，你想過壓縮（GZIP，LZO或任何適合你的需要）和編碼的結果BASE64？ 如果是這樣，是什麼讓你決定反對它？ 可能的警告，你需要看為減壓炸彈和可能使用的URL安全方便的base64字母表。
如果有人想嘗試一下，你可以測試它在Bash
echo $QUERY_STRING | gzip -c -f - | base64 -w0喬希·戴維斯- 11月19日，2010 ＃
您好喬希，
我會後我從諾蘭考迪爾，PHP工程師在Flickr上的網址縮短算法的這個問題的回應：
“看來gzip壓縮文本的最大的勝利是當你有一個大的文本語料庫，這是有道理的，因為你這意味著最小化的編碼的開銷重複件。
編碼只是個別的文件名，然後採用base64編碼總是在一個較長的“壓縮”的版本與我的分析結果。 如果我們能夠壓縮前完整的URL發出請求（這將涉及黑客YUI3的組合加載），我們將看到更大的收益。 嘗試我們的一個長的URL，導致52％的壓縮率。 這是比我們目前的72％左右的壓縮率是相同的URL更好。 結合這兩項計劃，我們得到了42％，這是很好的壓縮。“
評論羅斯Harmes - 2010年11月22日， ＃