蘇庫馬語翻譯語言翻譯公司譯文出處：http://luolei.org/2014/02/
the-technology-behind-the-nytimes-com-redesign-chinese/
本文為簡體中文版從新修飾為繁體中文版翻譯
除譯文中整段漏譯的部分以外，其餘盡可能遵守譯文的譯法，
只點竄繁體中文習用辭彙、以及鉦昱翻譯社小我習慣不翻譯的名詞翻譯
______________________________________________________________________
原文網址：[The Technology Behind the NYTimes.com Redesign][Origin]
[Origin]: http://open.blogs.nytimes.com/
2014/01/08/the-technology-behind-the-nytimes-com-redesign
紐約時報英文網站本年進行了一次改版，
此次改版不單單是給一艘大船從新刷了遍油漆那麼簡單，
除了外觀上的從新設計，鉦昱翻譯社們也對程式碼進行了大量的重構，
採用了新的框架，讓網站更快，
也為今後程式碼的保護、進級便當性進行了從頭設計。
Reed Emmons，是這次改版的負責人，
在這篇文章將分享我們若何讓紐約時報這首老船更快更酷。
很少有機會可以或許在像紐約時報這麼老資曆和規模的網站
進行一場「從頭來過」的重構和設計工作，
我這裡說的從頭來過，不單單是視覺設計上的從頭設計，
更是一個重新發現全部數位傳媒平台。
紐約時報的前次一次視覺改版是在 2006 年，
然則我們得回溯到 2000 千禧年才有如斯範圍的從底層的重構和改版。
鉦昱翻譯社們決議重構用戶端和辦事端以支撐鉦昱翻譯社們新的服務、設計和新聞報道，
好比說更佳的網站機能、 responsive layout 等等。
儘管有些舊有的程式碼照舊保存或進行了深度重構，
大部分老的程式碼都被刪除或僅僅是用來做參考。
靜態頁面發布：歷史的教訓
------------------------
直到今天為止，紐約時報的大部份網頁內容還是靜態 html 頁面，
這些頁面貯存在我們數據中間的硬碟上。
當編輯發布一篇新的文章時，會生成和寫入一個 html 文件。
我們具有本身的 html 模板，可讓我們憑據需求添加分歧的插件翻譯
當一篇文章要 render 的時辰，引擎會主動添加告白並 render。
這套系統的速度和機能足以撐持紐約時報網站的高流量，
所以到今天為止，也不是特別需要進級這套系統。
這套系同一個很大的不足就是缺少動態節制性翻譯
網頁的 html 是固定的，然則其中的 script 和 stylesheet 是需要絡續改變的，
我們的前端開辟團隊必需保護歷史上建立的每套模板。
這也導致了為什麼一個兩年前發布的新聞跟上週發布的文章，會存在一些分歧。
我們團隊的一個前端架構師 Eitan Konigsburg，
在去年的開放日流動曾就鉦昱翻譯社們的技術架構歷史做過度享。
一個更伶俐的 layout
--------------------
為了適應更高級和複雜的設計，
我們構建了本身的 responsive JavaScript 引擎，
可讓我們按照本身的需求利用分歧的 media queries 斷點，
這個引擎可以經由過程直接在 html 中添加分歧的 class
來實現 responsive 設計翻譯同時，我們利用了 LESS 預處理，
使得 css 更容易保護的同時也知足了鉦昱翻譯社們大部份用戶的瀏覽器兼容性需求。
儘管對於用戶來講，網站的轉變十分精細，
然則一篇文章在分歧的設備和瀏覽器，可以產生 20 種分歧的 responsive 轉變翻譯
以下為我們使用LESS 的一個例子。
.ribbon {
...
// responsive
// 1020
.viewport-medium-50 & {
.offset(0翻譯社 1, 0, left);
}
// 1200
.viewport-large-20 & {
.offset(0, 2, 0翻譯社 left);
}
}
憑據分歧的分辯率和裝備偏向，鉦昱翻譯社們的框架可以主動襯著出分歧的界面，
還可以憑據需求添加分歧類型的廣告，
每篇文章對應的網頁有跨越 100 個可以自界說點竄的處所翻譯
構造化 JavaScript
-----------------
這次重構需要大量的 JS 程式碼重寫以支撐大量的訂製功能。
一個功能壯大的前端框架是十分有需要的，
這可讓我們利用分歧的 JS 佈局而且能精良兼容共存翻譯
Backbone.js 和 RequireJs 給我們提供了一套框架和標準。
我們選擇 Backbone 因為它提供了使人滿意的靈活性和自界說性。
jQuery、Modernizr、SockJS、Underscore.js 和 Hammer.js
是鉦昱翻譯社們使用的一些 library，
我們一樣使用了如 Mocha 和 Chai 來進行測試。
除此之外，我們還利用了一些其他的新技術：
* 使用 Backbone mixins 來削減反複的程式碼
* 從根基的 view 拓展所有 Backbone view（和 model）
* Throttling / debouncing expensive events like scroll and resize
新的 PHP rendering framework
-----------------------------
切換到一個對動態內容要求更好的網站，鉦昱翻譯社們需要利用一個新的襯著引擎，
可以快速地辦事大量分歧需求的文章。
現有的 PHP framework 供應了堅實的基礎，但是我們仍然選擇從新構建一個翻譯
為了滿足訂製服務不同的內容需求，
鉦昱翻譯社們在開辟的時候利用考慮到增加靈動性的需求，
我們的 framework 必需動態顯現分歧的 layout 和設定在統一頁的能力。
新 framework 簡化了開辟，
還讓鉦昱翻譯社們可以僅用幾行程式碼就可以建立壯大的應用程式。
現在開發一個運用可以使用已有的組件，顯著地減少了開發時候翻譯
另外，可用 module 的重複利用，節流了我們的大量的時候。
提高辦事器端快取速度
--------------------
有如斯多的動態頁面，
我們的平台需要一個壯大的 reverse proxy 來包管 PHP 後台不會潰散翻譯
客歲五月紐約時代的動作網站的 Varnish 系統成功給了鉦昱翻譯社們信心，
我們相信 Varnish 也是這次我們的最好選擇翻譯
Varnish 是高度可設定，從服務器快取中讀取速度極大地加速了。
它使得那些經常變化的界面能被快取更短時候。
前端優化
--------
利用 Grunt，鉦昱翻譯社們優化了我們的代碼，減少了 HTTP 要求，
此刻我們的文章頁包括被同步下載的三個緊縮 CSS 和 JS 檔，
比擬之前的 80 多個沒精簡過的檔案，這是一個明顯的改良。
在網頁的底部，我們利用 RequireJS 非同步步加載多個文件進行前端 render。
無 Cookie 的 CDN 和快取 HEAD 的設置使得我們的讀者將下載更少的程式碼。
配合 Varnish 系統，如今我們打開一篇文章能控制在 500～1000 毫秒以內翻譯
所有的 JS 都可能造成阻塞，所以最大的性能改進來自於告白的非同步載入。
廣告是使人頭疼的，我們不能簡單地直接將代碼添加到 DOM 之中，
而不憂慮頁面的內容被籠蓋。
相反，所有的告白必需在 iFrame 和 DOMContentLoaded 載入終了後才進行載入，
以免致使頁面 render 的潛伏問題。
開辟的過程中我們還使用了圖片 sprites，
鉦昱翻譯社們所有的圖片都存在一個叫 sprite-me 的目錄下，
合營 Grunt 和 LESS 我們可以很方便地生成和使用不同的 icon 和圖片，
確定圖象的 postion 位置。
最後，我們利用 Underscore 編譯的 HTML 模板，
所以他們可以容易地 ”required”，並敏捷地 render翻譯
總結
----
現在我們的新平台包括了更壯大的發布和互動功能，
鉦昱翻譯社們還在不息地改良這個平台，不竭地迭代。
這個新平台也讓鉦昱翻譯社們的團隊能加倍急迅地進行新的學習和開發。
儘管我們還有許多遺留技術問題，但是我們已建立了一個值得依靠的技術團隊，
相信以後各人能更好地開發解決問題。
下一次，我們的團隊的其他開發者將深切介紹此次重構利用的這些手藝，
從 Websockets 到 PHP framework，盡請等候。
本譯文在 Google doc 上公然，若是您發現某些翻譯的毛病、不當，
或對某些語句有更好的翻譯，歡迎修改和潤色翻譯
https://docs.google.com/document/d/
1kEGcSm6AiUBgsPKDiHo0FJYGhEtNElA5Iagizy2vA1Q/edit?usp=sharing
--
錢鍾書： 說出來的話
http://www.psmonkey.org
比不上不說出來的話
Java 版 cookcomic 版
只暗射著說不出來的話
and more......
文章來自: https://www.ptt.cc/bbs/Translate-CS/M.1392656010.A.2E5.html有關翻譯的問題歡迎諮詢鉦昱翻譯社
|
字體：小 中 大
