python的openpyxl库如何读取特定列_通过渲染一百万个网页，来了解网络是如何崩溃的...
為什么要渲染一百萬個頁面？
簡單來說，就是現如今出現一種爭議(argument)：網絡從某種程度上來說比 15 年前更慢了。原因是日益繁榮的 JS 框架、網絡字體、以及各類 polyfills 的增長，它們并沒有使得我們從更高速的計算器、更快速的網絡通信、更完備的網絡協議中獲益更多，甚至帶來了損害。
于是乎，作者團隊想證明這種說法是否是成立的，并嘗試找出導致 2020 年網站緩慢和崩潰的常見因素。
如何實現這一計劃？
作者團隊使用 Puppeteer 編寫了一個 Web 瀏覽器(Chrome)腳本，啟動 200 個 EC2 實例，讓它在周末運行，渲染排名前一百萬域名的根頁面。
從這么幾個統計指標看，這真是有夠瘋狂的。
在這個計劃中，他們跟蹤所有的 window.onerror 所捕獲的錯。
通常來說，我們都會跟蹤客戶反饋的錯誤，但是這一次，跟蹤的卻是整個網絡的錯誤！這次將有足夠的說服力：研究網頁到底是如何在實際運行中崩潰的？
最常見的錯誤
分析數據表明，大多數問題都可以被歸類。而這，就能為開發人員指引 Web 技術的未來發展方向：修復這一些小問題就可以將 Web 的報錯數量減少十倍。
這些壞家伙的 TOP10 分別是：
如 Tolstoy 所說：工作中的網址皆不相同，但是破壞它們的方式卻是一致的。如您所見，這些網絡錯誤的分布符合【齊夫定律】。此例中，有三種錯誤占了所有錯誤的極大比例。即：
引用錯誤(ReferenceError)、類型錯誤(TypeError)、語法錯誤(SyntaxError) 占所有錯誤的 85%！
顯然，造成這些錯誤的方式有很多種，錯誤消息中的特定字符串會告訴我們具體發生了什么。作為開發者，我們一定常常遇到這其中的一些，并總是對它們感到熟悉。(這個錯誤我見過~)
當然，有很多方法可以產生這些錯誤類型。錯誤消息中的特定字符串告訴我們更多有關實際發生的情況的信息。查看最常見的錯誤消息會給您一定的熟悉感。作為網絡開發人員，您之前可能已經遇到過其中一些。
讓我們來看下具體的錯誤 TOP10 又是哪些？
這些報錯都指向特定的錯誤消息，作者團隊繼續調試這些錯誤的樣本，來深入了解它們的具體錯誤情況。結果，意想不到的事情發生了：事實證明，對于引用錯誤(ReferenceError)和語法錯誤(SyntaxError)而言，有一個共通的根本原因 —— 即 資源加載失敗，對于類型錯誤(TypeErrors)，也有一個本質上的發現，即它們都屬于同一種問題。
作者團隊深入研究產生了以下文章，描述了對每個錯誤的發現：
How to resolve ReferenceError：我們可以獲取公共庫的高頻全局變量的使用趨勢，在此基礎上，構建相關聯的變量名和特定的庫來解決引用錯誤。即采用自定義高頻變量覆蓋公告庫來解決此類大部分問題。
What causes TypeError on live web sites：97% 的類型錯誤都來自于 null 或者 undefined。它們大多數是因為沒有符合第三方庫或者瀏覽器環境的依賴，或者是因為文檔對象發生錯誤導致選擇器拿不到值。
What causes SyntaxError on live web sites：開發過程中，多數的語法錯誤來自于拼寫錯誤。實際運行中，多數的語法錯誤來自網絡故障或者 JS 的編寫錯誤。
如何預測錯誤數量？
作者團隊最初用邏輯回歸和分類的方法(logistic regression classifier)，嘗試根據 JS 所調用的庫來預測網站中錯誤的存在。基于此假設，意味著只要存在某些代碼，就預示著會導致錯誤。
繼續深入分析顯示：大多數錯誤由于缺少代碼所致，所以這種方式的預測能力較低。但是，我們可以列一個分類器學習的回歸系數。這就很高級了~ 它可以顯示了這些分類選擇依賴的程度。事實上，一小段代碼在 webpack 的作用下將與一些錯誤強有力的連接起來，但它們對瀏覽器來說又是關鍵的依賴腳本。
這里還有一個結論：用于追蹤 JS 錯誤的產品有更低的錯誤數。
讓咱們來康康這些庫的回歸系數，預測是否存在錯誤。
所有庫的邏輯回歸系數，預測是否存在錯誤例如，百度統計的回歸系數大，代表缺失代碼的可能性較小，預測有更低的錯誤數。不過，本瓜懷疑和墻也有關系，因為一直在用谷歌統計，自覺更不錯啊~
網絡的錯誤恢復能力
在調研的一百萬個網頁中，有 12% 的網站存在一個或多個未處理的錯誤。這確實是一個驚人的數字。這些錯誤表明由于某些意外的情況中止了某些程序的執行，從而導致某些功能因此被破壞掉。
從 12% 也能看到 Web 的錯誤恢復能力是強大的：但無論你的錯誤是什么，它都必須足夠小以至于懶得去修復它。
數據顯示：大多數錯誤來自于運行時缺少代碼、數據、或文檔對象。很有可能是由于 Web 的綁定特性決定的：類型在運行時(后期)才被確定，而不是在編譯時(早期)就被確定。 的確，在運行時才確定類型可以使得加載各類庫更輕松自然，但它也造成了一些錯誤發生的可能：即可能出現缺少庫或者 API 發生了改變的情況。當然，運行時才確定類型不是唯一的選擇，許多語言都是在編譯時就已確定了類型。
比如 Java Applets 構建的 Web，情況將有所不同。(咱能從這個老古董里學點什么~)
如何構建不易出錯的網絡
在強類型系統的語言中嚴格要求定義類型，動態運行任何加載庫將變得艱難，尤其是當這些庫的自定義程度很高，API 很開放的情況。這不僅與來源于網絡的代碼有關，也和瀏覽器的運行時有關。
我們可以稍微回顧下 Java Applets，如果你沒有正確安裝 Java 運行環境，那么 applet 將拒絕運行直到你下載并安裝了相應的環境。在 Web 當中，你可以使用舊瀏覽器查看頁面，但有瀏覽器和網站可能在長久的迭代中逐步崩潰(即運行環境也在變化)。不過，你也可以編寫一個在當前版本瀏覽器和舊版本瀏覽器都能正常運行的網頁。根據這種思路，運行時綁定類型對于網絡的發展也是至關重要的！
2006 年，艾倫·凱(Alan Kay)和觀點研究所(Viewpoint Research Institute)發起了一項雄心勃勃的項目：以兩萬行代碼從裸機重構計算機至實現 GUI 操作系統。雖然這個項目由于資金問題中途停滯，但是最終的報告還是描述了一種運行時綁定的動態的語言的構建( late-bound references and dynamicity )—— KScript。這比 TypeScript 還要早 6 年！
艾倫·凱(Alan Kay)模仿了一個生態緊密的分布式系統，沒有緊密互鎖的耦合。
截至此處，我們還沒有得到最終的結論。靜態類型保證編譯器不出現某些類型錯誤，這是開發者喜聞樂見的。TypeScript 就很有趣了，它跨越了動態類型和靜態類型，它需要付出這樣的代價：編譯器認為編譯時期的類型可能不是運行時期的類型。
Web 的運行時綁定機制讓我們總處于落后，如果瀏覽器不支持網頁的新特性，代碼就會中斷。對于 Web 而言，這似乎比 Java Applet 模型“要么沒有，要么全有”的特點要好，在 Java Applet 中，只有在正確的運行環境裝好的情況下才能運行程序。在 2000 年代初，XHTML 有類似的情況。使用 XHTML，文檔需被要求是有效的 XML，無效的標記將導致頁面完全不顯示。當時，這種行為被許多人提倡，也許是因為無效的 HTML 被看作是導致瀏覽器有不同呈現的“主謀”。經過了十年的沉淀，有了更好的想法來標準化這些無效標記，并將它們合到了 HTML5 中。從目前的結果看，HTML5 勝過了 XHTML，JavaScript 勝過了 Java applet。
現在還有一匹黑馬，那就是 —— WebAssembly。有很多案例都是圍繞用靜態類型的語言將代碼編譯為 wasm (比如 Blazor)。我們正處在歷史潮頭，在這個時代，前端開發將不再有大量的 JS 代碼。然而，這種思路下，技術若成為一個個孤島也注定不會成功。從歷史中學習，我們似乎有必要圍繞動態找到一個更好的解決方案，并考慮運行時的綁定！
靜態類型語言能為我們提供安全性，動態類型語言又是 Web 不易出錯的關鍵。二者的平衡是最終的關鍵！數據表明，當網絡中斷時，原因是代碼沒有按預期運行，導致文檔錯誤、類型錯誤、三方庫或數據無法加載等。我們假設類型系統是解決編程問題的有辦法，它確保在編譯階段各種依賴就被做了檢查。是否存在一種人體工學(ergonomic)的方法來實現這一目標？它能允許在動態環境中執行這種檢查，同時也就能消除困擾當今網絡的大多數錯誤。
作結
首先為這個團隊的做法點贊，敢想敢做！實際上，研究崩潰只是整個研究的子課題，父課題為 JavaScript Performance in the Wild 2020，其中還包括網絡連接情況、第三方庫使用情況、頁面渲染時間、請求數、重繪次數等等，有興趣點贊，本瓜后續接著翻。
我們可以預見的是 TypeScript 是目前解決 JS 類型問題的最好解決方案！也期待有更多解決方案，解決比如引用問題、語法問題，雖然這些 ESLint 也能做，但它只是插件工具。想有更多的遐想，或許編程語言自身就得足夠強大。
Webpack 太重要了！在如今前端工程化的大環境下，開發儼然變成是對各種依賴庫的調用，而最終如何能打包成為一個“稱心”的項目在線上運行，才是關鍵中之關鍵。
就目前看，再遠一點的未來是 WebAssembly(給我往 si 里學~)。
瀏覽器是 Web 前端攻城獅一切的基礎。說一個數據：谷歌瀏覽器 2008 年發布，截至 2020 年，已有 69.89% 的市場占有率。但是，誰還記得在 1990 年代中期，網景瀏覽器 的市場占有率曾高達 90%？或許一切還未成定局！如作者所說，我們處在歷史的潮頭。瀏覽器會去往何方？咱們邊走邊看~
以降低耦合、增高內聚的設計思想來 Coding，這不止于前端，這是計算器科學！
都看到這里啦？點個贊吧？我是掘金安東尼，人不狠話也多......
看完三件事
如果你覺得本文對你有幫助，我想請你幫個忙：
公眾號后臺回復「加群」，加入算法和技術交流群，與更多讀者交流。
?
總結
以上是生活随笔為你收集整理的python的openpyxl库如何读取特定列_通过渲染一百万个网页，来了解网络是如何崩溃的...的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： cad怎么调出科创易达绿化_【每日问答2
- 下一篇： python里graphics的使用_使