棟的月結 | 第二回合（定期更新、動態、架構、雲技術、演算法、後端、前端、收聽/收看、英文、書籍、影視、好歌、新奇）[含淚總結.. 憋淚分享！]

Snow Hide（雪諾海德）發表於2020-03-28
架構演算法後端前端

開篇詞

大家好！以下是我在 2020 年 2 月 1 日至 29 日的所見、所聞、所學和所悟。

現在，我把它們安利給你們。

 

定期更新

動態

從我的英文部落格翻譯並遷移了一些原創文章到《Linux 管理員手冊：既簡單又深刻》專欄裡，並分別命名為

幫尤金大神從他的 Baeldung Java Weekly 裡翻譯了一些文章到《Baeldung Java 周評》專欄裡，並分別命名為

在符合許可的前提下從 Spring 官方指南里翻譯了一些文章到《Spring 官方指南》，並分別命名為：

架構

左耳聽風 | 高效溝通：Talk 和 Code 同等重要
收穫：Talk 和 Code 同樣重要、有效溝通是事業成功的必要條件、溝通及其背後原理、通過約定俗成和反饋來解決問題、應對溝通問題的方法。
評分：10
左耳聽風 | 高效溝通：溝通阻礙和應對方法
收穫：六種溝通阻礙（資訊不準確、資訊太多、缺乏互動、表達方式、二手資訊、通道被黑）、阻礙所產生的溝通問題、相應的解決辦法。
評分：10
左耳聽風 | 高效溝通：溝通方式及技巧
收穫：尊重對方、傾聽對方、控制情緒、想辦法引起對方的興趣、直達主題，強化觀點‘用資料和例項說話。
評分：10
左耳聽風 | 高效溝通：溝通技術
收穫：四大關鍵技術（邏輯、資訊、維度和共同）、維度把控、尋找共同、金句的重要性。
評分：10
左耳聽風 | 高效溝通：好老闆要善於提問
收穫：引導（讓員工找答案）、傾聽（全面接收和理解對方的資訊）、共情（站在對方立場設身處地思考和處理問題）、高維（提升自己的格局觀）、反饋（建立反饋機制）。
評分：10
左耳聽風 | 高效溝通：好好說話的藝術
收穫：跟員工溝通、跟客戶溝通、跟老闆溝通。
評分：10
左耳聽風 | 程式設計師如何用技術變現（上/下）
收穫：你把你的時間投資在哪些地方，就意味著你未來會走什麼樣的路。所以，利用好你的時間，投到一些有意義的地方吧。
評分：10
左耳聽風 | Equifax 資訊洩露（始末/看資料安全）
收穫：Equifax 資訊洩露始末、Apache Struts 漏洞相關、資料洩漏介紹以及歷史回顧、資料洩漏攻擊、專家建議、技術上的安全做法。
評分：10
左耳聽風 | 何為技術領導力？
收穫：技術重要嗎？、什麼是技術領導力？、擁有技術領導力的軟體工程師。
評分：10
左耳聽風 | 如何才能擁有技術領導力？
收穫：技術領導者需要有良好的溝通能力、組織能力、驅動力、團隊協作能力等等。
評分：10
左耳聽風 | Go 語言，Docker 和新技術
收穫：搶佔先機的公司有更大的影響力、當需求引爆時公司或個人影響力就會形成比較大的護城河、通訊/金融行業對於 PaaS 平臺的理解已經超過了網際網路公司、Go 語言和 Docker 作為 PaaS 平臺的關鍵技術前途是無限的。
評分：10
左耳聽風 | 答疑解惑：渴望、熱情和選擇
收穫：思考問題的出發點、思維方式、格局觀、價值觀、思維基因、編碼能力很重要、技術視野核技術洞察力還有技術解決問題的能力更為重要。
評分：10
左耳聽風 | 如何成為一個大家願意追隨的 Leader？
收穫：做一個好的 Leader 真的不容易，你需要比大家強很多，你需要比大家付出更多；你需要容天下難容之事，你還需要保持熱情和朝氣；你需要帶領團隊守護理想，你還需要直面困難迎刃而上。
評分：10
《檢視《左耳聽風》原文》

許式偉的架構課 | 怎樣成長為優秀的軟體架構師？
收穫：程式設計師的三個層次：搬磚工、工程師、架構師；優秀的架構師：掌控全域性；架構相關圖書：架構思維類、設計模式類、分散式系統架構設計類、重構類；該主題的兩個脈絡主線：從零開始構建整個資訊世界、過程所用的重要架構思維正規化以及如何將其運用於平常的工程實踐中；如何成長為優秀的軟體架構師：匠心、悟心。
評分：10
許式偉的架構課 | 架構設計的巨集觀視角
收穫：為什麼需要建立巨集觀視角？：如果把應用比作一座大廈，那麼我們作為大廈的架構師，需要把大廈的結構搭建好，讓程式設計師可以把磚填充進去，我們都知道，一個大廈的結構建的是否穩固，與地基密不可分。應用的基礎架構：中央處理器+儲存+一系列的輸入輸出裝置；可程式設計性（計算類、I/O類、指令跳轉類）；開放設計的外部裝置支援（電腦的 CPU 非常簡潔，只讀入和寫出資料並對其進行計算。直接用機器指令太累，沒人看懂以及沒法維護）。完整的架構是怎樣的？：服務端應用（業務架構、應用框架及各類基礎庫、中介軟體類基礎軟體/Nginx/MySQL、作業系統、程式語言、馮諾伊曼體系架構）、客戶端應用（業務架構、跨平臺應用框架及各類基礎庫、瀏覽器、HTML/XML+CSS+JS/WebAssembly、作業系統、程式語言、馮諾伊曼體系架構）。架構能力的提升，本質上是對你的知識脈絡（全身經絡）進行反覆梳理與融會貫通的過程。
評分：10
《檢視《許式偉的架構課》原文》

研發效率破局之道 | 為什麼你要關注研發效能？
收穫：研發效能的完整定義應該是：團隊能夠持續地為使用者產生有效價值的效率（效性/Effectiveness、效率/Efficiency、可持續性/Sustainability。能否長期、高效地開發出有價值的產品）。軟體開發的靈活性決定了研發效能提升的困難性。研發效能的提高，需要整個公司在研發流程、工程方法、個人效能和文化管理等方面進行精心設計。研發的高效能：研發效能、研發流程、工程方法、個人效能、管理和文化。著重 Why，深入瞭解效能實踐背後的原理，給出 How，也就是具體的實踐。
評分：10
《檢視《研發效率破局之道》原文》

MySQL 實戰 | 普通索引與唯一索引
收穫：普通索引和唯一索引的選擇、資料的查詢和更新過程、change buffer 的機制以及應用場景、索引選擇的實踐。
評分：10
MySQL 實戰 | 如何選擇索引
收穫：索引統計的更新機制、優化器存在選錯索引的可能性、索引統計資訊不準確導致的問題、在應用端用 force index 來強行指定索引。
評分：10
MySQL 實戰 | 給字串加索引
收穫：如何為郵箱欄位建立合理的索引？、字首索引對覆蓋索引的影響、其他處理方式、字串欄位建立索引的幾種方式。
評分：10
MySQL 實戰 | InnoDB 髒頁的控制策略
收穫：WAL 概念、刷髒頁操作和執行時機、隨機寫轉換成順序寫以提升資料庫效能、控制刷髒頁的方法和對應的監控方式。
評分：10
MySQL 實戰 | 日誌和索引常見問題
收穫：日誌和索引的相關問題、MySQL 內部處理命令時的三種選擇。
評分：10
MySQL 實戰 | binlog 和 redo log 的寫入機制
收穫：怎麼保證 redo log 和 binlog 是完整的、對 crash-safe 概念的清晰理解。
評分：10
MySQL 實戰 | 大查詢
收穫：MySQL 的查詢結果、傳送給客戶端的過程、邊算邊發的邏輯、不在 server 端儲存完整的結果集、會堵住 MySQL 查詢過程但不會打爆記憶體、InnoDB 引擎內部由於淘汰策略的存在所以大查詢不會導致記憶體暴漲、InnoDB 對 LRU 演算法做的改進使冷資料全表掃描對 Buffer Pool 的影響可控、業務高峰期還是不能在主庫執行全表掃描。
評分：10
MySQL 實戰 | 為什麼表資料刪掉一半，表檔案大小不變？
收穫：資料庫中收縮表空間的方法、delete 不會使表檔案變小、通過 alter table 命令來重建表以使表檔案變小。
評分：10
MySQL 實戰 | 怎麼最快地複製一張表？
收穫：物理拷貝的方式最快（全表、伺服器拷貝、都使用 InnoDB 引擎）、mysqldump 生成包含 INSERT 語句檔案的方式不適用於關聯表等複雜的條件語句（可匯出部分資料）、select … into outfile 的方式最靈活（支援所有 SQL、只能匯出一張表、表結構需要另外的語句單獨備份）。
評分：10
MySQL 實戰 | 如何正確地顯示隨機訊息？
收穫：記憶體臨時表、磁碟臨時表、隨機排序方法。
評分：10
MySQL 實戰 | MySQL是怎麼保證主備一致的？
收穫：MySQL binlog 的格式和一些基本機制、多節點、半同步、MySQL group replication、MySQL 不同格式 binlog 的優缺點、MySQL 通過判斷 server id 的方式斷掉死迴圈。
評分：10
MySQL 實戰 | MySQL是怎麼保證高可用的？
收穫：MySQL 高可用系統基礎、導致主備延遲的情況、切換策略的不同選擇、可靠性優先和可用性優先策略、建議使用可靠性優先策略、減少主備延遲以提升系統可用性。
評分：10
MySQL 實戰 | 備庫為什麼會延遲好幾個小時？
收穫：MySQL 的各種多執行緒複製策略、需要多執行緒的原因、不同複製策略的優缺點、儘量減少大事務操作，把大事務拆成小事務、binlog 協議並不是向上相容的，主備切換/版本升級時要考慮的因素。
評分：10
MySQL 實戰 | 主庫出問題了，從庫怎麼辦？
收穫：一主多從主備切換流程、從庫找新主庫位點的痛點、MySQL 5.6 版的 GTID 模式、GTID 基本概念和用法。
評分：10
MySQL 實戰 | 讀寫分離有哪些坑？
收穫：一主多從讀寫分離時的過期讀原因及應對方案、一寫多讀導致的過期讀問題、需要權衡讀寫效能。
評分：10
MySQL 實戰 | 為什麼這些SQL語句邏輯相同，效能卻差異巨大？
收穫：對索引欄位做函式操作可能會破壞索引值的有序性致使優化器決定放棄走樹索引功能、隱式型別轉換、隱式字元編碼轉換。
評分：10
MySQL 實戰 | MySQL有哪些“飲鴆止渴”提高效能的方法？
收穫：一些緊急處理的手段、儘量避免一些低效的方法、連線異常斷開是常有的事、程式碼裡要有正確地重連並重試的機制、做好 SQL 審計可以減少問題的發生、集中在 server 層的解決方法。
評分：10
《檢視《MySQL 實戰》原文》

技術領導力實戰筆記 | 最合適的技術才是最有價值的技術
收穫：優秀的人，都至少能達到：1、能夠清楚地認識到什麼東西是對的；2、在知道是對的情況下，願意去把事情做得更好。兩個必備的素質：1、全面的技術能力，不求多深，但是可以聽懂不同部門的訴求和技術方案，瞭解不同方案的技術難度；2、 優秀的溝通能力和說服能力，這一點無需多言。
評分：8
技術領導力實戰筆記 | 談談 CTO 在商業戰略中的定位
收穫：戰略必須被認可和接受。戰略宣講的三個步驟：第一步（戰略制定者從全公司層面對公司來年的目標、運營模式進行宣講）、第二步（戰略和目標分解）、最後（落地策略、資源調配）。能解決問題才是合格的 CTO（跟每個團隊，尤其是不屬於 CTO 負責的團隊進行充分的溝通，理解這些團隊的痛點，業務上的不足，設身處地的站在對方團隊的基礎上理解並接受對方的痛點，換位思考，對症下藥）。什麼樣的 CTO 才能在商業戰略上做決策？（技術上獨當一面、懂得系統是如何通過程式碼實現的、架構設計、溝通能力、很強的產品意識和商業意識）。
評分：10
技術領導力實戰筆記 | 打造自己的個人品牌，你也可以
收穫：Q：技術人可以通過哪些方法打破邊界，提升認知？（走出自己的舒適區，要學會“跨界”）、Q：怎樣從他人的經驗分享中提煉出真正對自己有價值的知識點，並在實踐中運用？（MVP 法則）、Q：技術人應該如何打造個人品牌？（越是難度高的產出，越容易受人肯定）。
評分：10
《檢視《技術領導力實戰筆記》原文》

說透敏捷 | 靈魂拷問：如何利用敏捷思維更好地解決實際問題？
收穫：瀑布模型問題：研發週期過長，導致研發跟不上業務發展的節奏、研發不能很好地響應需求變化，導致客戶滿意度低、不能很好地管控風險。其實有很多公司，他們都在有意或無意中使用了敏捷的一些實踐。是否打著敏捷的名頭，是否冠以敏捷，這本身是無所謂的，只要我們能夠用到敏捷的一些方法來幫助到自己的公司專案就好。我們已經進入 VUCA 時代：易變（volatility）、不確定（uncertainty）、複雜（complexity）和模糊（ambiguity）。
評分：9
說透敏捷 | 老生常談：你真的知道敏捷到底是什麼嗎？
收穫：敏捷的價值觀：正確理解敏捷的初心（個體和互動勝過過程和工具、可以工作的軟體勝過面面俱到的文件、客戶合作勝過合同談判、響應變化勝過遵循計劃、雖然右項有價值，但我們更重視左項）。敏捷的原則：正確理解敏捷的基石（我們最重要的目標，是通過持續不斷地及早交付有價值的軟體使客戶滿意。欣然面對需求變化，即使在開發後期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。經常地交付可工作的軟體，相隔幾星期或一兩個月，傾向於採取較短的週期。業務人員和開發人員必須相互合作，專案中的每一天都不例外。激發個體的鬥志，以他們為核心搭建專案。提供所需的環境、支援、信任，從而達成目標。不論團隊內外，傳遞資訊效果最好效率也最高的方式是面對面的交談。可工作的軟體是進度的首要度量標準。敏捷過程倡導可持續開發。責任人、開發人員和使用者要能夠共同維持其步調穩定延續。堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。以簡潔為本，它是極力減少不必要工作量的藝術。最好的架構、需求和設計出自自組織團隊。團隊定期地反思如何能提高成效，並依此調整自身的舉止表現）。敏捷的方法與實踐：正確落地敏捷的基礎（迭代計劃會議開始前，產品負責人需要準備好需求條目，使需求達到准入標準；Scrum 講究時間盒，包括迭代的週期、各個會議，這些都要遵守時間盒的約定）。敏捷 = 價值觀 + 原則 + 一系列符合價值觀和原則的方法。
評分：9
說透敏捷 | 評估診斷：成功邁出敏捷推進的第一步
收穫：評估診斷的方法步驟：第一步（挑選代表性專案）、第二步（訪談評估）、第三步（制定轉型計劃）、第四步（溝通）。評估診斷案例分析：首先（雖然有些團隊進行了敏捷嘗試，但成熟度並不高，如果用 5 分制，1 為最低，5 為最高，給他們打分，這些團隊的實踐水平均介於 1 和 2 之間）、其次（該企業未推進敏捷的團隊現在採用的是瀑布模式，對敏捷瞭解甚少）、最後（團隊在跨團隊交流方面有很大的障礙，這表現在業務人員與開發測試團隊隔離，目標不統一，且參與敏捷的投入度不夠）。
評分：9
說透敏捷 | 團隊試點（一）：讓你的敏捷實踐“事半功倍”
收穫：為什麼要做試點前的準備？（只有做好詳細、充足的準備，我們才能在推進敏捷試點時真正做到有備無患）、如何做好敏捷試點前的準備？（1. 選擇試點團隊：採納敏捷的意願相對強烈、業務價值高或採納敏捷會在短期內給團隊帶來很大收益。2. 前期準備工作細則：組織和人員、管控治理規則、需求範圍、架構、敏捷方法和工具、辦公環境設施）。
評分：8
《檢視《說透敏捷》原文》

說透中臺 | 來龍去脈：中臺為什麼這麼火？
收穫：2008～2015：孕育。2015 關鍵詞：阿里巴巴中臺戰略誕生。2017 關鍵詞：橫空出世。2018 關鍵詞：全面爆發。2019 迷霧仍然存在。
評分：9
說透中臺 | 中臺種類：你聽說的中臺真的是中臺嗎？
收穫：主流代表：業務資料雙中臺（業務中臺、資料中臺）。非主流系列（技術中臺、研發中臺、移動中臺、管理中臺、組織中臺）。
評分：9
說透中臺 | 中臺定義：當我們談中臺時到底在談些什麼？
收穫：企業為什麼要建中臺？（網際網路時代，使用者才是商業戰場的中心，為了快速響應使用者的需求，藉助平臺化的力量可以事半功倍。中臺化是平臺化的下一站，是平臺不斷對於自身治理演進、打破技術邊界、逐漸擁抱業務、容納業務、具備更強的業務屬性的過程。中臺關注為前臺業務賦能，真正為前臺而生。）、Pace-Layered 角度劃分的三類（SOR/Systems of record：後臺、SOI/Systems of innovation：前臺、SOD/Systems of differentiation：中臺）。給中臺下個定義：企業級能力複用平臺（1. 企業級、2. 能力、3. 複用、4. 平臺）。
評分：10
說透中臺 | 萬事預則立：中臺建設前必須想清楚的四個問題
收穫：中臺建設前必須想清楚的四個問題（中臺建設的願景是什麼？：這個願景是需要所有的角色，上到企業管理層，下到每一位中臺的相關人員都要明確並達成一致的。中臺的使用者和客戶是誰？：中臺建設雖然需要兼顧各方的利益，但更多主要還是解決企業管理層對於公司長期生存與可持續發展的恐懼與焦慮問題。中臺的錢由誰出？：眾籌模式（從業務前臺集資，有錢的捧個錢場沒錢的碰個人場，能出預算的出預算，能出人的出人，來組建中臺團隊，然後再反過來服務於前臺業務團隊）、投融資模式（產品的建設前期先由投資方出資，按照產品的建設目標經過一段時間的建設期，相對成熟之後，再逐漸地讓使用者使用，最終通過對於使用者的服務，讓使用者滿意，實現收入並收回企業投資且盈利的模式。目前大部分的創業公司都是採用類似的模式，相信你也很熟悉了））、中臺的目標怎麼驗證？：目前業界有一些中臺的考核標準我們可以作為參考，例如阿里巴巴的中臺考核就是設計成：40% 穩定性 +25% 業務創新 +20% 服務接入量 +15% 客戶滿意度。
評分：9
《檢視《說透中臺》原文》

DDD 實戰課 | 領域驅動設計：微服務設計為什麼要選擇DDD？
收穫：軟體架構模式的演進（第一階段是單機架構、第二階段是集中式架構、第三階段是分散式微服務架構）。微服務設計和拆分的困境（微服務拆分困境產生的根本原因就是不知道業務或者微服務的邊界到底在什麼地方。DDD 核心思想是通過領域驅動設計方法定義領域模型，從而確定業務和應用邊界，保證業務模型與程式碼模型的一致性）。為什麼 DDD 適合微服務？（DDD 包括戰略設計和戰術設計兩部分：戰略設計主要從業務視角出發、戰術設計則從技術視角出發）。DDD 與微服務的關係（DDD 主要關注：從業務領域視角劃分領域邊界，構建通用語言進行高效溝通，通過業務抽象，建立領域模型，維持業務和程式碼的邏輯一致性。微服務主要關注：執行時的程式間通訊、容錯和故障隔離，實現去中心化資料管理和去中心化服務治理，關注微服務的獨立開發、測試、構建和部署。）。
評分：10
DDD 實戰課 | 領域、子域、核心域、通用域和支撐域：傻傻分不清？
收穫：如何理解領域和子域？（領域就是用來確定範圍的，範圍即邊界。我們把劃分出來的多個子領域稱為子域，每個子域對應一個更小的問題域或更小的業務範圍。領域建模和微服務建設的過程和方法基本類似，其核心思想就是將問題域逐步分解，降低業務理解和系統實現的複雜度）、如何理解核心域/通用域和支撐域？（核心域：決定產品和公司核心競爭力的子域。通用域：同時被多個子域使用的通用功能子域，例如認證、許可權等沒有企業特點限制無需定製的系統。支撐域：既不包含核心競爭力功能也不包含通用功能的子域，例如資料程式碼類的資料字典等系統）。
評分：10
DDD 實戰課 | 限界上下文：定義領域邊界的利器
收穫：什麼是通用語言？：在事件風暴過程中，通過團隊交流達成共識的，能夠簡單、清晰、準確描述業務涵義和規則的語言就是通用語言。什麼是限界上下文？進一步理解限界上下文（領域邊界就是通過限界上下文來定義的）、限界上下文和微服務的關係（我們將限界上下文內的領域模型對映到微服務，就完成了從問題域到軟體的解決方案）。
評分：9
《檢視《DDD 實戰課》原文》

即時訊息技術剖析與實戰 | 架構與特性：一個完整的IM系統是怎樣的？
收穫：從一個簡單的聊天系統說起（1. 使用者眼中的聊天系統：使用者賬號、關係鏈、聯絡人的列表、訊息、聊天會話；2. 開發者眼中的聊天系統：首先是客戶端、其次是接入服務（連線保持、協議解析、Session 維護和訊息推送）、之後是業務處理服務（訊息的儲存、未讀數變更、更新最近聯絡人）、接著是儲存服務（賬號資訊、關係鏈，以及訊息本身）、最後是外部介面服務（將訊息給到第三方外部介面服務，來通過手機作業系統自身的公共連線服務來進行作業系統級的“訊息推送”，通過這種方式下發的訊息一般會在手機的“通知欄”對使用者進行提醒和展示））。接入服務和業務處理服務獨立拆分（第一點是接入服務作為訊息收發的出入口，必須是一個高可用的服務，保持足夠的穩定性是一個必要條件。第二點是從業務開發人員的角度看，接入服務和業務處理服務進行拆分有助於提升業務開發效率，降低業務開發門檻）。IM 系統都有哪些特性？（1. 實時性：保證訊息實時觸達是互動場景的必備能力。2. 可靠性：不丟訊息、訊息不重複。3. 一致性：“多使用者”“多終端”的一致性體驗能大幅提升 IM 系統的使用體驗。4. 安全性：“資料傳輸安全”“資料儲存安全”“訊息內容安全“三大保障方面提供全面隱私保護）。
評分：10
即時訊息技術剖析與實戰 | 訊息收發架構：為你的App，加上實時通訊功能
收穫：訊息儲存（訊息索引和訊息內容：訊息傳送方和訊息接收方，內容表/索引表。聯絡人列表：最近聯絡人表。）、訊息收發通道（訊息傳送通道：IM 服務端提供一個 HTTP 協議的 API 介面、客戶端和 IM 服務端維護一個 TCP 長連線。訊息接受通道：藉助 TCP 的全雙工能力，也就是能同時接收與傳送資料的能力）、訊息未讀數（兩個概念：多少未讀訊息、我和某個聯絡人有多少條未讀訊息）。
評分：9
《檢視《即時訊息技術剖析與實戰》原文》

專案管理實戰 | 角色轉換：程式設計師做專案管理的三大誤區
收穫：誤區 1：凡事恨不得事必躬親（成功施加影響的三個層次，分別是讓人知道要做（Awareness）、有動力做（Desire）和有能力做（Ability））。誤區 2：追在別人屁股後面做監工（要明確目標，建立機制，並讓這個機制運轉起來，最終在專案組形成一種良性的秩序）。誤區 3：拿著錘子，看哪裡都是釘子。
評分：9
專案管理實戰 | 十大領域五大過程組（上）：程式設計師必須要了解的專案管理常識
收穫：專案管理的歷史（甘特圖、關鍵路徑法）。什麼是專案管理？（專案管理就是變理想為現實，化抽象為具體的一門科學和藝術）。專案管理的十大知識領域（1. 干係人管理：如何管理干係人？2. 範圍管理：做什麼？3. 進度管理：花多長時間？4. 成本管理：花多大代價？5. 質量管理：達到什麼要求？6. 資源管理：有多少內部資源？7. 採購管理：有多少還要買？8. 溝通管理：如何管理溝通？9. 風險管理：如何應對風險？10. 整合管理：如何實現整體最優？）。
評分：9
專案管理實戰 | 十大領域五大過程組（下）：程式設計師必須要了解的專案管理常識
收穫：專案管理的五大過程組：1. 啟動過程組（千里之行，始於足下。啟動過程組意味著正式開始一個專案，或者是開始一個專案中的新階段，包括識別干係人和制定專案章程兩個子過程。正式宣告一個新專案或新階段的開始，公開確認專案章程，包括明晰各方干係人的期望和訴求，設定願景目標和重要里程碑，確定責任分工和溝通機制等。）、2. 規劃過程組（運籌帷幄，決勝千里。規劃就是要把願景目標轉化為可落地的行動方案和工作路線。）、3. 執行過程組（言出必行，行之必果）、3. 執行過程組（言出必行，行之必果）、4. 監控過程組（審時度勢，沉著應變）、5. 收尾過程組（慎終如始，則無敗事。不管專案成功與否，“趁熱”覆盤都是極為重要的一步。）。網際網路專案管理的職責定位（保目標、助決策、提效能、促協作）。提效能是要去關注和消滅團隊中的低價值工作所引發的效能痛點。促協作則是著眼於使用各種專案管理方法和工具，讓高價值工作者可以更好地合作。保目標、助決策是要打通從戰略到執行的閉環，提效能、促協作則是打通上下游協同的閉環。
評分：10
《檢視《專案管理實戰》原文》
 

雲技術

AWS | 方案架構助理 | 聯合身份驗證的使用場景
收穫：企業訪問亞馬遜雲資源、移動及 Web 應用、中心化身份識別管理（亞馬遜雲賬戶）。
評分：9
AWS | 方案架構助理 | 訊息推送服務（SNS）
收穫：SNS 基礎：與多個亞馬遜雲服務整合、SNS 與 CloudWatch 相結合可以給管理員傳送重要的提醒、可以被用於移動端提示推送；SNS 元件：Topic、Subscriber、Publisher。
評分：10
AWS | 方案架構助理 | 訊息佇列服務（SQS）
收穫：推送型別：短輪詢、長輪詢、更少的空 API 呼叫。
評分：10
AWS | 方案架構助理 | 彈性轉碼器
收穫：作業佇列、定義了輸入物件的作業、預設轉碼配置、用於傳送作業狀態變更提醒的管道。
評分：8
AWS | 方案架構助理 | 互動式 SQL 查詢服務（Athena）
收穫：能夠查詢結 S3 中的結構化、半結構化以及無結構化資料；可以查詢多種亞馬遜雲日誌，包括流日誌以及負載均衡日誌；無法對資料做變更。
評分：8
AWS | 方案架構助理 | 彈性大資料處理（EMR）
收穫：大規模併發處理大資料、擁有零個或多個核心節點、主節點對節點叢集進行管理、任務節點可選，可用來執行任務。
評分：9
AWS | 方案架構助理 | 流資料捕獲載入服務（Kinesis 以及 Firehose）
收穫：流、分片、資料記錄。
評分：8
AWS | 方案架構助理 | 資料倉儲（Redshift）
收穫：PB 級規模資料倉儲方案、用於分析負載的列資料庫、專屬於 OLAP、多資料庫資料收集、可從 S3 載入資料，反之亦然。
評分：9
AWS | 方案架構助理 | 雲監控（CloudWatch）
收穫：一小時指標將被保留 455 天；五分鐘指標將被保留 63 天；一分鐘指標將被保留 15 天；可以與警報器結合使用。
評分：10
AWS | 方案架構助理 | 雲監控日誌（CloudWatch Logs）
收穫：指標過濾、日誌過濾器、日誌事件、日誌組、日誌流。
評分：10
AWS | 方案架構助理 | 雲資源呼叫記錄（CloudTrail）
收穫：使用者/角色或服務的行為將被記錄於此；事件管理；記錄控制皮膚事件（使用者登入、配置安全、安全組變動）或資料事件（S3 物件級別事件、Lambda 函式級別事件）。
評分：10
AWS | 方案架構助理 | 網路流量資訊統計（VPC Flow Logs）
收穫：用於捕獲 VPC 進出流量的後設資料；可被置於網路卡、子網或整個 VPC 中，並可捕獲捕獲點中的後設資料及其中的任意內容；其不提供實時捕獲並且不對流量本身進行捕獲操作，而僅捕獲流量的後設資料；其不捕獲 DNS 伺服器、Windows 許可認證、169.254.169.254 地址、DHCP 流量以及 VPC 路由器。
評分：10
AWS | 方案架構助理 | 計劃事件通知（CloudWatch Events）
收穫：事件目標：EC2 例項、Lambda 函式、階躍函式狀態機、SNS 主題、SQS 佇列。
評分：10
AWS | 方案架構助理 | 金鑰管理託管（KMS, Key Management Service）
收穫：提供了區域的、安全的金鑰管理以及加解密服務。
評分：9
AWS | 方案架構助理 | 雲應用部署（Elastic Beanstalk）
收穫：支援多種主流語言及 Web 容器；適用於：以及小的開銷來進行應用環境的評審、當使用其所支援的某種語言並可以新增其指定的配置時；不適用於：當需要對底層基礎設施進行操作時、當需要 Chef 等運維工具的支援時。
評分：9
AWS | 方案架構助理 | 自動化雲應用部署（OpsWorks）
收穫：Chef 配置管理及部署平臺的實現；將 CloudFormation 等底層細節移除，但不太像 Elastic Beanstalk；可以以層疊的形式來建立一個資源棧並對資源進行單元式管理；其元件包含：棧、層、例項、應用、選單。
評分：10
AWS | 方案開發助理 | 亞馬遜雲全域性基礎設施
收穫：賬戶與服務層：主賬戶、管理員使用者；物理與網路層：邊緣節點；區域：空間集；空間：資料中心集；結合虛擬私有云的空間。
評分：9
AWS | 方案開發助理 | 共享責任模型
收穫：我們的責任：IAM、雙重認證、密碼/金鑰輪換、訪問顧問、信譽顧問、安全組、基於資源的策略、訪問控制列表、虛擬私有云、埠掃描是違規的，即使是在你自己的環境中進行的、作業系統層補丁；亞馬遜雲的責任：物理伺服器層及以下、物理環境安全及保護（火災/停電/自然災害/管理）、根據業界標準來退役儲存裝置、個人資料安全、網路裝置安全及訪問控制列表、API 端點部署 SSL、洪流攻擊抵禦、EC2 例項及欺騙攻擊抵禦（入站出站過濾）、EC2 例項虛擬環境隔離（物理裝置上的例項是獨立的）。
評分：10
AWS | 方案開發助理 | 計算服務概覽
收穫：EC2（雲虛擬伺服器）、ECS（受監管的容器服務）、Elastic Beanstalk（PaaS）、Lambda（無伺服器計算）。
評分：8
AWS | 方案開發助理 | 儲存服務概述
收穫：RDS (SQL)、DynamoDB (NoSQL)、ElastiCache（高效能）、Redshift（資料倉儲）。
評分：8
AWS | 方案開發助理 | IAM 基礎
收穫：用於管理：使用者、組、角色、訪問策略、Api 金鑰、根據使用者指定密碼策略及 MFA 要求。
評分：9
AWS | 方案開發助理 | IAM 策略
收穫：管理員登入、高階使用者、只讀訪問。
評分：8
AWS | 方案開發助理 | IAM 使用者
收穫：預設情況下拒絕訪問所有云服務；擁有唯一的訪問憑證；顯式拒絕會覆蓋顯式允許的許可權。
評分：8
AWS | 方案開發助理 | IAM 組
收穫：可用於分配許可權策略；易於進行雲資源的訪問管理。
評分：8
AWS | 方案開發助理 | IAM 角色
收穫：分配給雲資源的許可權，例如 EC2 訪問 S3 的許可權。
評分：9
AWS | 方案開發助理 | 安全令牌服務（STS）
收穫：授予信任的使用者臨時憑證用以訪問雲資源；臨時憑證的有效期為幾分鐘至幾小時；憑證過期後即無效；請求呼叫 STS API 時，憑證將以三個元件形式返回：安全令牌、訪問鑰 ID、訪問金鑰；STS API 呼叫：AssumeRole、AssumeRoleWithWebIdentity、AssumeRoleWithSAML、GetFederationToken、GetSessionToken。
評分：9
AWS | 方案開發助理 | IAM API 金鑰
收穫：要求在以下場景中使用：AWS 命令列介面（CLI）、PowerShell 工具、AWS SDK、通過 API 直接呼叫雲服務；API 金鑰是一次性的；AWS 不會重新生成同一組訪問鑰；必須與一個使用者關聯之後才能使用；角色不擁有 API 憑證；AWS 控制檯中只能看到訪問金鑰號，加密金鑰號用不可見；反啟用現有訪問金鑰集之後方能生成新的一套；永遠不要在 EC2 例項中建立或儲存 API 金鑰。
評分：10
AWS | 方案開發助理 | 鑰管理服務（KMS）
收穫：概念：使用者主金鑰（CMKs）：由客戶管理、由 AWS 管理；資料金鑰：對大量資料進行加密操作、CMK 可以生成/加密/解密資料金鑰、KMS 不管理或儲存資料金鑰，需要自行管理、KMS 不能用資料金鑰來加密資料；信封加密：通過資料金鑰加密的純文字資料、使用金鑰加密金鑰（KEK）來對資料金鑰加密、KEK 可被另一個 KEK 加密，但最終會有一個主的金鑰（特指 KMS CMK）以加密一個或多個金鑰；KMS API 行為：加密、解密。
評分：8
AWS | 方案開發助理 | 應用安全評估（Inspector）
收穫：自動安全評估服務；以測試 EC2 例項的網路訪問狀態及例項中應用的安全狀態；可在開發及部署管道或靜態生產系統中自動進行安全漏洞評估；以定期進行開發及運維中的安全檢查。
評分：8
AWS | 方案開發助理 | 使用者池和身份池
收穫：使用者池：Cognito 裡的使用者目錄、池裡的使用者可以通過 Cognito 或第三方身份識別供應商來登入至 Web 或移動應用、可以通過 SDK 來訪問使用者成員的目錄；身份池：可獲取臨時憑證來訪問雲服務（諸如 S3 和 DynamoDB）、支援匿名訪客使用者以及可以使用該服務盡情使用者鑑權的身份識別供應商（Cognito 使用者池、Facebook/Google 等社交媒體登入、Amazon 登入、OpenID（OIDC）供應商、SAML 身份識別供應商、開發者認證身份識別）。
評分：10
AWS | 方案開發助理 | 身份識別聯盟及使用者身份池
收穫：Cognito 身份識別：給應用使用者建立唯一身份標識、使用自己的驗證過程或 Google/Facebook 等供應商來進行身份識別的驗證、儲存移動使用者資料、藉助 Sync 來使用獲取的憑證進行資料同步；Cognito 使用者資料同步（Sync）：在多移動裝置及 Web 之間同步使用者資料、客戶端庫將資料快取至本地；Cognito 用途：SDK（Android/iOS、JavaScript、其他 SDK）。
評分：9
AWS | 方案開發助理 | EC2 基礎
收穫：可伸縮伺服器；由不同的例項型別以及大小所組成；例項配置：模擬傳統伺服器，但為方便伸縮性及彈性而擁有可隨時委託及退役的能力；主要組成部分：雲機器映象（AMI）、例項型別（算力、記憶體、網路頻寬）、網路介面（公有、私有或彈性 IP 地址）、儲存（彈性快儲存（EBS）、彈性檔案系統（EFS）、例項儲存（臨時儲存））；三大類 AMI：社群版映象（免費使用，作業系統）、商店映象（付費使用，包含許可軟體）、我的映象（自己建立的映象）；例項型別：通用用途（T2，M5，M4）、算力優化（C4，C5）、記憶體優化（X1e，X1，R4）、計算加速（P3，P2，G3，F1）、儲存優化（H1，I3，D2）。
評分：10
AWS | 方案開發助理 | EC2 選購
收穫：按需付費；預留例項；空閒例項；獨立主機。
評分：8
AWS | 方案開發助理 | EC2 例項配置
收穫：EC2 IP 地址：私有 IP 地址、公有 IP 地址、彈性 IP 地址；啟動指令碼與使用者資料/後設資料：啟動指令碼（定製的用於在例項啟動之後執行的指令碼）、使用者資料文字框（將要在啟動時執行的指令碼放入其中）。
評分：10
AWS | 方案開發助理 | EC2 儲存基礎
收穫：彈性快儲存（EBS）基礎：持久的、網路附加儲存、可備份為快照、預設在多空間中有副本、通常掛在至 /dev/sda1 或 /dev/vxda；EBS 效能：每秒輸入輸出（IOPS）、IOPS 單位（）；初始化 EBS 卷：從 EBS 快照建立的卷必須初始化、在第一次讀取卷中的儲存塊時會進行初始化操作，將產生 50% 的效能影響、在生產環境中可以手工讀取所有的塊以避免首次讀取時所產生的效能影響；EBS 卷：普通用途 SSD、讀寫加強版 SSD、吞吐量優化版 HDD 及冷 HDD、EBS 磁碟（老版）；例項儲存塊卷：底層硬體附加在執行例項的主機上的虛擬裝置、例項儲存卷為臨時資料、例項終止或關閉之後資料被清除、例項重啟後資料還在、並非被所有例項型別支援；EBS 快照：本質是遞增的、只儲存最近快照的變更、原快照刪除後資料還存在於其他快照中、只按每個快照的增量資料收費，但先前的資料依然存在、可用於建立完全還原的 EBS 卷、頻繁對資料建立快照可提高續航力、應在非生產環境或非高峰時期進行；彈性檔案系統（EFS）：優勢（可同時被多個例項訪問、當機房通過 Direct Connect 連線至 VPC 時，該服務可被掛載至機房的伺服器、可在空間伸展至 PB 級時仍保持低延遲以及高吞吐率、按使用率付費）、安全（通過 POSIX 許可權來管控檔案系統訪問、VPC 進行網路訪問控制，IAM 進行 API 訪問控制、使用 KMS 對資料進行加密）、用途（大資料分析、多媒體處理工作流、Web 服務及內容管理）。
評分：9
AWS | 方案開發助理 | EC2 金鑰對
收穫：使用金鑰對建立並授權之後方可登入例項；SSH 使用 .pem 金鑰檔案來登入 Linux 例項。
評分：9
AWS | 方案開發助理 | 彈性負載均衡
收穫：將入站流量分發至不同伺服器；由一個 EC2 服務來自動將入站流量分發至與其關聯的所有例項；可將流量負載均衡至多個可用空間中的多個例項上；允許直接將 SSL 證照應用至負載均衡器以減少例項的算力開銷會話狀態維護：推薦用類似於 ElastiCache 這樣的快取服務來進行會話狀態的維護。
評分：10
AWS | 方案開發助理 | EC2 API 行為/錯誤及亞馬遜雲共享職責模型
收穫：客戶負責管理例項的軟體層安全；亞馬遜雲負責管理例項的虛擬層及物理層安全。
評分：9
AWS | 方案開發助理 | VPC 基礎
收穫：基礎 VPC 網路；VPC 優勢；預設 VPC；VPC 限制：每個區域 5 個、每個區域 5 個網管、每個區域 50 個客戶閘道器、每個區域 50 個 VPN、每個區域 200 個路由表 / 每個表 50 個條目、5 個彈性 IP、每個 VPC 500 個安全組、每個安全組 50 條規則、每個網路介面 5 個安全組。
評分：10
AWS | 方案開發助理 | VPC 網路基礎
收穫：閘道器：允許 VPC 裡的例項與網際網路進行通訊、水平擴充套件，冗餘和高可用；閘道器規則：VPC 同一時間只能有一個閘道器、當 VPC 中有正在使用的雲服務時不能與閘道器進行解綁操作、當 VPC 中有需要訪問外網服務的雲服務時，需要繫結一個閘道器；路由表：包含一堆路由規則，用於定向網路流量、包含兩個元件（目的地、目標）；子網掩碼：每個可用空間中可新增一至多個子網掩碼、一個子網掩碼對應一個可用空間，不能處在多個可用空間中、公有子網掩碼擁有網際網路路由、私有子網掩碼不擁有網際網路路由。
評分：9
AWS | 方案開發助理 | VPC 安全基礎
收穫：網路訪問控制列表：運作於網路/子網掩碼層、支援子網掩碼的進出流量允許拒絕規則、無狀態，出站流量必須是允許的、以數字形式處理規則來決定是否放行流量、作為VPC 的安全可選層扮演防火牆角色，以在多個子網掩碼之間進行入站出站流量的管控。
評分：10
AWS | 方案開發助理 | VPC 網路之高可用與容錯
收穫：自伸縮：根據選定 Cloudwatch 指標的變化來自動新增或減少例項；自伸縮兩大元件：啟動配置（當自伸縮組需要觀察額外的例項時，需要用到 EC2 模版）、自伸縮組（最少/多例項數、啟動例項所處的 VPC 及可用空間、啟動例項是否從 ELB 接收流量、伸縮策略、SNS 簡訊提醒）。
評分：10
AWS | 方案開發助理 | VPC 網路之堡壘機和 NAT 閘道器
收穫：堡壘機：為私有子網掩碼內的例項而部署在公有子網掩碼上的例項、可以作為私有子網掩碼內例項的一個入口、需要變得堅不可摧、可以在不借助 VPN 的情況下作為 SSH 的訪問點；NAT 閘道器：為私有子網掩碼內的例項而設計的，可將其路由至網際網路、處在私有子網掩碼內的例項很安全，但其卻無法下載軟體或進行軟體更新的操作；NAT 閘道器必須：建立於公有子網掩碼內、作為自由子網掩碼路由表的一部分；NAT 例項：對應其 NAT 閘道器所描述的單一用途、通過配置一個實際的 EC2 例項以區分執行來完成相同的工作、即將成為亞馬遜雲裡的一個歷史遺留產物、試題裡可能還有其相關的問題。
評分：8
AWS | 方案開發助理 | 應用負載均衡
收穫：應用負載均衡：在應用層（HTTP/HTTPS）做路由決策、支援基於路徑的路由，可以為監聽器配置規則以將請求基於其所持有的 URL 進行轉發、支援基於主機的路由，可以為監聽器配置規則以將請求基於 HTTP 頭部中的主機欄位進行轉發、支援將請求路由至單例項上的多個應用、我們可以以埠不同但目標組相同的方式來註冊每個例項或 IP 地址；經典負載均衡：在傳輸層（TCP/SSL）或應用層（HTTP/HTTPS）做路由決策、支援經典版 EC2 例項。
評分：9
AWS | 方案開發助理 | 網路負載均衡
收穫：在傳輸層（TCP/SSL）做路由決策、每秒可處理百萬級請求、再不修改頭資訊的情況下對請求進行轉發、支援動態主機對映、擁有可以處理不穩定工作負載以及擴充套件至百萬級請求的能力、為負載均衡提供靜態 IP 地址支援，可以為每個子網掩碼分配單獨的彈性 IP 地址。
評分：10
AWS | 方案開發助理 | 動態埠
收穫：ALB 和 NLB 支援動態埠：單 EC2 例項可能會執行多個容器、每個容器都被隨機地分配了一個埠號、這些埠並非靜態的、重啟的容器可能會收到新的埠號、動態埠由目標組來分配、目標組追蹤每個例項上接受流量的埠列表並指引負載均衡器以將流量均衡分發至這些埠、由於其對動態埠的支援，第二代負載均衡器更適用於將流量路由至容器服務。
評分：10
AWS | 方案開發助理 | Lambda 基礎
收穫：伺服器計算平臺；核心概念是 Lambda 函式或 Lambda 函式包；可以方便地與其他雲服務相整合；支援多種開發語言；適用於：類似於 S3 桶變更或 DynamoDB 表更新等事件驅動任務、流處理以及資料倉儲技術處理、物聯網以及移動後端、Web 應用 API。
評分：9
AWS | 方案開發助理 | Lambda 函式與事件
收穫：事件有：經過 API 閘道器的 HTTP API 請求、Cloudwatch 排程事件、S3 檔案上傳、DynamoDB 流變更、通過 CLI 或 SDK 的直連呼叫、其他事件源；函式有：應用程式碼、程式碼的應用依賴，庫/配置以及其他依賴；程式設計模型：控制程式碼檔案與函式、事件、上下文、日誌與異常、執行時指定概念；呼叫型別：同步、非同步；函式配置：語言環境、控制程式碼、記憶體、最大執行持續時間、許可權、環境變數、VPC、死信佇列、併發、標籤。
評分：9
AWS | 方案開發助理 | Lambda 版本與別名
收穫：版本：擁有獨立的 ARN、KaTeX parse error: Unexpected character: '' at position 59: …不同版本之間進行流量分發操作；̲好處：方便的開發工作流以及階段…{aws:使用者名稱}/*）。桶策略：附加至桶的策略、策略中的所有許可權被應用至桶中的所有物件，除了由非桶所有者的外部使用者建立的物件、可以用來進行 IAM 使用者或其他 AWS 賬戶的授權訪問、指定了桶使用者允許或禁止的操作（匿名使用者進行授權訪問、指定可以進行如 PUT 或 DELETE 等特定操作的使用者、限制基於 IP 地址的訪問）。S3 訪問控制列表：可與桶以及物件共用、無法拒絕或授予條件式許可權、物件 ACL 的使用場景（管控非桶所有者所有的物件訪問、管控物件級別的許可權以及物件區分的許可權、允許外部賬戶來管控物件策略）。罐裝式 ACL：公有讀（允許向外共享物件）、aws-exec-read（允許 EC2 從 S3 獲取 AMI 捆綁）、XML 形式編寫。
評分：9
AWS | 開發助理 | S3 加密
收穫：兩種保護資訊的方式：中途/客戶端加密（使用客戶端主鍵、使用 AWS KMS 管理的客戶主鍵/CMK）、靜止加密（S3 管理的鍵/SSE-S3、KMS 管理的鍵/SSE-KMS、客戶提供的鍵/SSE-C）。
評分：9
AWS | 開發助理 | S3 物件版本管控
收穫：S3 版本控制：預設情況所有桶和物件禁用版本控制、版本控制一旦啟用，其只能被暫停而不能被完全禁用、暫停版本控制只會防止建立新版本、所有現有版本的物件將保持它們的老版本、版本控制只能在桶級別進行設定並被應用至桶內的所有物件、生命週期策略可被應用至物件的特定版本。啟用 S3 版本控制：現有物件將保持不變、新增物件將自動地被賦予唯一的版本編號、每個新版本將被當成一個全新的物件進行計費。刪除版本控制的物件：標準工作流（只對最新版本做刪除標記、直接訪問物件時返回 404、依然可以通過指定特定版本號來獲取指定版本的物件）、永久刪除一個版本（傳送刪除請求時指定版本號）。恢復版本控制的物件：刪除當前版本（提取先前版本，直到你想要的版本為止）、複製舊版本（將物件先前版本複製到相同桶、以新版方式將其新增至桶、複製的版本變成當前版本、所有物件的版本被預留）。
評分：10
AWS | 開發助理 | S3 物件型別與冰河儲存
收穫：儲存型別：標準（通用，所有用途的儲存、預設儲存選項、11 個 9 永續性、4 個 9 可用性、最昂貴的儲存型別）、低冗餘儲存（RRS：非關鍵，可再生的物件、4 個 9 永續性、4 個 9 可用性、比標準儲存型別便宜些）、不常訪問（S3-IA：標準-IA、單空間-IA、不常訪問的，但必須能立即可用的物件、11 個 9 永續性、3 個 9 可用性、比標準和低冗餘儲存型別便宜些）、冰河（可通過生命週期管理來切換至其中、長期歸檔的儲存，不適合用來做備份、可能需要花上數小時來提取物件、11 個 9 永續性、最便宜的儲存型別，成本非常低、三種提取資料的級別：加急，1-5 分鐘；標準，3-5 小時；大批量：5-12 小時）。
評分：10
AWS | 開發助理 | S3 生命週期策略
收穫：預設情況下，禁用桶/物件的生命週期。可定製以適應公司的資料儲存策略。很好地用於物件儲存的自動化管理以達成更高的成本效益。可通過結合版本控制來很好地建立歸檔和備份方案。
評分：9
AWS | 開發助理 | S3 部署靜態網站
收穫：提供了低成本/高可靠的靜態網站部署服務。包含 HTML/CSS 以及 JS 檔案還有圖片和字型。建立靜態網站時可指定首頁以及錯誤檔案。提供一個網站的唯一 URL 端點，其格式取決於所處區域。Route 53 可對映人類可讀的域名至部署靜態網站的桶，特別適合於 DNS 故障轉移解決方案。
評分：9
AWS | 開發助理 | S3 啟用跨站資源共享（CORS）
收穫：允許某個域名裡的 Web 應用訪問另一個域名裡的資源。通常指的是某個桶裡所部署的 Web 應用可以訪問另一個桶裡的資源。每個桶都能設定 CORS。
評分：8
AWS | 開發助理 | DynamoDB 概述
收穫：核心特性：完全可控的 NoSQL 資料庫、一致的和快速的效能、方便搭建並與其他服務進行通訊、靜止加密可選加密。熱門用例（物聯網：後設資料儲存、遊戲：會話資訊儲存、移動端：使用者資料儲存）。費用：核心收費部分（額定寫吞吐率、額定讀吞吐率、索引資料儲存）、其他收費因素（保留容量、自動伸縮、全域性表：複製寫容量單元、按需備份：按月每 GB 儲存收費、按需儲存：按每 GB 恢復收費、加速器：按每小時使用例項收費、流：按每 100k 讀收費）。
評分：9
AWS | 開發助理 | DynamoDB 核心概念
收穫：分割槽鍵：每張表都要求有一個分割槽鍵、條目的分割槽鍵也被稱作雜湊屬性、分割槽鍵屬性必須為標量，只能存放一個值、在一個內部雜湊函式裡使用分割槽鍵以決定在哪存放分割槽資料。排序鍵：表不要求有排序鍵、條目的排序鍵也被稱作範圍屬性、範圍鍵必須為標量，只能存放一個值、在使用分割槽鍵來決定存入的分割槽資料後，排序鍵被用來對分割槽中的資料進行排序操作。主鍵：簡單主鍵，只有分割槽鍵、組合主鍵，分割槽鍵和排序鍵。條目：一組在表中其他條目間可被唯一標識的一組屬性、每個條目是一或多個屬性並且可被想像成關係型資料庫中的行。屬性：基本資料元素，於其他資料庫中的資源以及列類似。
評分：9
AWS | 開發助理 | DynamoDB 額定吞吐率
收穫：一個應用能夠從一張表或索引消費的最大容量。當吞吐率到達上限時，請求將被阻塞。可以同時使用自動伸縮來避免被阻塞（按需提升容量、週期性降低容量）。根據讀和寫容量單元來測量。額定吞吐率被設定於表級別但被拆分和消費於分割槽層。意味在其他分割槽正常運作的情況下特定分割槽可能缺少需要的容量。分割槽：在分割槽中儲存資料、分割槽為儲存表的 SSD 分配並自動在多空間進行復制、分割槽數量取決於表吞吐率容量以及現有分割槽的儲存大小。讀：讀容量單元被消費的原因（使用 GetItem 和 BatchGetItem 操作時、使用 Query 操作時、使用 Scan 操作時）、一個讀容量單元等於一個 4KB 或以下大小的條目的每秒讀操作（強一致性）、單個條目的讀操作大小總是進位至距離 4KB 最近的大小、最終一致性讀只需要讀容量單元一半的大小。
評分：8
AWS | 開發助理 | DynamoDB 讀操作
收穫：GetItem：根據條目的主鍵來高效地從一張表中讀取單個條目。BatchGetItem：可從一或多張表讀取至 100 個條目（請求中的每個條目均使用 GetItem 操作來處理、每個條目都獨立地進行進位操作以供讀容量單元使用）。Query：以相同的分割槽鍵值來讀取條目、同時，我們能用排序鍵來高效地對條目進行排序操作、所有返回的條目均被當作單個讀操作，計算所有條目總大小並進位至下一個 4KB 邊界。Scan：讀一個表中的所有條目、考慮的是條目評估的大小，而不是其所返回的條目的發小。最終一致性和強一致性讀：最終一致性不保證獲取的是當前寫入表中的資料、強一致性保證獲取的是當前寫入的資料。
評分：9
AWS | 開發助理 | DynamoDB 區域性與全域性的二級索引
收穫：二級索引：允許高效地查詢非主鍵屬性、每個二級索引只關聯一張表、表可以有多個二級索引、自動維護二級索引，索引根據表的變化而變化。本地二級索引（LSI）：為表提供了排序鍵的選擇、LSI 主鍵為組合鍵（主鍵和排序鍵）、每個本地二級索引可作為另一個排序鍵、每個 LSI 自動與基表保持同步、本地二級索引的讀和寫容量竊取自基表的容量、LSI 必須在建表時建立。全域性二級索引：每個全域性二級索引可作為另一種方式以查詢使用了不同分割槽以及不同排序鍵的資訊、類似於 LSI，每個 GSI 自動與基表保持同步、無法進行強一致性讀、不與主表共用讀和寫容量，其擁有自己的 WCU 和 RCU 額定吞吐量、可在建表後建立 GSI。
評分：9
AWS | 開發助理 | DynamoDB 條件寫與原子計數器
收穫：寫：WCU 在增/改/刪時被消費、一個 WCU 等於一個 1KB 或以下大小的條目的每秒寫操作、總是進位至距離 KB 最近的大小、多個條目要求多個 WCU。原子計數器：寫是有序的以至於可以對現有值進行遞增操作以實現類似於網站訪問記錄之類的用途，失敗的操作可以被重試，但重試會產生條目被更新兩次的風險並且可能出現少算或多算的情況。條件寫：當寫條件成功時可以使用條件寫來進行額外控制、只有當正在寫入的條目屬性符合一或多個預期的條件時才成功。
評分：9
AWS | 開發助理 | DynamoDB 的常見錯誤與限制
收穫：ThrottlingException：可能是在快速地嘗試著對錶進行增、刪或改操作。ProvisionedThroughputExceededException：表的吞吐量不足以支撐當前的讀及寫運算元量。ResourceNotFoundException：請求的表不存在，或正在建立中的狀態。限制：二級索引、額定吞吐率、表、條目與屬性、特定 API 限制。
評分：9
AWS | 開發助理 | DynamoDB 加速器（DAX）
收穫：記憶體加速器：被設計用於伸縮和效能、毫秒級響應、某些特定場景會要求微秒級響應、為最終一致性資料提供快速的響應時間，高訪問量的應用可從加速器的高速記憶體效能獲益、加速器的應用場景（需要有響應時間儘可能最快的讀、一些需要頻繁讀取的小部分條目、讀密集型，成本敏感、針對大量資料集的重複讀需求）。
評分：10
AWS | 開發助理 | DynamoDB 節流問題
收穫：根據每個條目的分割槽鍵來在多個分割槽中對其進行儲存、每個分割槽與表共用額定讀（RCU）/寫（WCU）吞吐率、當請求發出時，其路由至正確的分割槽以獲取資料，並且被請求的分割槽容量決定了是允許或阻塞（拒絕）該請求、一些阻塞是應該被應用預測並處理的、導致阻塞的原因（表分割槽接收到不可數的請求量，熱分割槽。容量限制：表本身不具有足夠的容量來服務多個分割槽上的請求）、阻塞過多的結果（在應用沒有重試寫的情況下丟失資料。過度嘗試寫導致的慢處理。在寫被阻塞及讀未被阻塞時資料可能會過期）。解決阻塞問題：逐步提升表的額定容量、確保審查表的全域性二級索引容量，索引阻塞是表阻塞的兩倍、實現錯誤重試以及指數退避 - 該技巧在重試之間使用逐漸延長等待時間來應對連續的錯誤響應以幫助提升應用的可靠度，亞馬遜雲 SDK 內建了該邏輯，當使用其他 SDK 時請考慮手工對其進行實現、儘可能均勻地分發讀和寫操作至多個表中、實現一個快取方案，類似於 DAX 或 Elasticache。分割槽底線：只提供 3000 RCU 和 1000 WCU、只持有 10 GB 資料、不可被刪除，哪怕容量或儲存的資料減少了、拆分後，其當前吞吐率和資料一分為二，新建兩個分割槽、並非所有分割槽的額定吞吐率都是一樣的。
評分：10
AWS | 開發助理 | DynamoDB 流結合 Lambda
收穫：新增/更新或刪除的表項、新的流記錄反映了表的變更、新的流記錄觸發 Lambda 函式、Lambda 函式讀流記錄並將其傳送至 CloudWatch 日誌。流捕捉表項級別變更的時間順序序列並將該資訊儲存至日誌並儲存 24 小時、應用可以訪問該日誌並檢視近乎實時變更之前或之後顯現的資料項、當對錶啟用流時，DynamoDB 捕獲該表資料項的任何變更資訊、近乎實時方面允許構建的應用消費這些流並可對內容進行操作、亞馬遜云為 DynamoDB 及其流維護分離的端點。
評分：10
AWS | 開發助理 | DynamoDB 按需自動伸縮
收穫：為 DynamoDB 表建立應用自伸縮策略、DynamoDB 釋出消費的容量指標至 CloudWatch、若表消費容量超出一定時間的目標利用率則 CloudWatch 觸發告警並通過 Amazon SNS 將其傳送給使用者、CloudWatch 告警觸發應用自伸縮來評估你的伸縮策略、應用自伸縮釋出一個更新表請求以調整你的伸縮策略、DynamoDB 處理更新表請求，動態增減表額定吞吐容量以靠近使用者的目標利用率。
評分：9
AWS | 開發助理 | RDS 基礎
收穫：完全可管控的關係型資料庫服務、無法訪問資料庫底層作業系統、向傳統方式那樣連線至 RDS 資料庫伺服器、具有稽核/調整硬體容量大小的能力以按需伸縮、可啟用多空間部署以實現備用及高可用方案、利用只讀複製來減輕主庫的負載、將組織的資料存至表、關聯表間具有定義的關係、支援的庫（MySQL、MariaDB、PostgreSQL、Oracle、MS SQL Server、Aurora）、Aurora 是亞馬遜自家產的庫，與 MySQL 完全相容，比 MySQL 快五倍並且比商用資料庫便宜很多。
評分：9
AWS | 開發助理 | 加密 RDS 資料庫
收穫：通過為 RDS 例項啟用加密選項以加密 RDS 例項及快照、被加密的資料還包括 DB 例項的底層儲存/其自動備份/只讀複製/及快照、無需更改資料庫客戶端應用來使用加密、使用 KMS 來管理 RDS 資源所用的加解密金鑰、可以使用 KMS 來建立加密金鑰並定義其使用策略、使用信封加密的兩層結構（唯一資料金鑰加密客戶資料、KMS 主金鑰加密資料金鑰）。
評分：9
AWS | 開發助理 | Redshift 是什麼
收穫：PB 級資料倉儲服務、完全可控及可伸縮、通常用於大資料分析，其可被整合至絕大多數商業智慧工具中（Jaspersoft、Microstrategy、Pentaho、Tableau、Business Objects、Cognos）。
評分：8
AWS | 開發助理 | ElastiCache 和快取策略
收穫：ElastiCache 基礎（完全可控的用於快取資料庫語句查詢結果以提升資料庫效能的記憶體快取引擎、適用於大量的、高效能的或高併發的查詢、可用於管理 Web 會話及快取動態生成的資料、可用的引擎（Memcached、Redis）、構建的應用需要與 Reids 或 Memcached 協作、MySQL 有與 Memcache 協作的外掛）、快取策略（懶載入（當快取未命中時將資料寫入、避免持有不被請求的資料、不與其他策略共用時其所持有的資料會比較穩定）、直接寫（有新寫入或更新的資料時就更新快取、讓快取保持最新資料、可在應用裡新增等待時間操作、無 TTL 時可能會有很多不會被讀取的快取資料）、新增 TTL（懶載入和直接寫的一個折中方案、快取資料的過期時間、讀到過期資料時應用檢查底層資料庫裡對應的值、不保證資訊的新鮮度，但其也防止資料腐敗並允許快取來檢查對應資料在底層資料庫裡的值））。
評分：9
AWS | 開發助理 | SNS 介紹
收穫：SNS 基礎、SNS 元件、SNS 優勢、SNS 主題、SNS 訂閱者、SNS 釋出者。
評分：8
AWS | 開發助理 | SNS 資源訪問管理
收穫：SNS 訪問控制策略。
評分：8
AWS | 開發助理 | SNS 訊息資料
收穫：SNS 訊息、訊息體、訊息屬性。
評分：9
AWS | 開發助理 | 移動應用：SNS 移動裝置推送
收穫：SNS 移動端推送、移動端推送提醒服務。
評分：8
AWS | 開發助理 | SNS API 行為及錯誤
收穫：SNS API 行為。
評分：7
AWS | 開發助理 | SQS 基礎
收穫：兩種輪詢型別、其他 SQS 重要事實、SQS 生產者、SQS 佇列、SQS 消費者。
評分：10
AWS | 開發助理 | SQS 資源訪問管理
收穫：SQS 基於資源的訪問控制策略。
評分：8
AWS | 開發助理 | SQS 輪詢型別
收穫：短輪詢、長輪詢。
評分：8
AWS | 開發助理 | SQS 訊息資料
收穫：訊息特徵及限制、重要的訊息元件、訊息生命週期。
評分：9
AWS | 開發助理 | SQS API 行為及錯誤
收穫：建立、獲取、設定、接收、更改、刪除。
評分：9
AWS | 開發助理 | SWF 基礎
收穫：SWF 元件、SWF 及 SQS、SWF 及 Step 函式。
評分：9
AWS | 開發助理 | Step 函式基礎
收穫：Step 函式元件、Step 函式優勢。
評分：8
AWS | 開發助理 | Step 函式狀態型別及轉換
收穫：AWS Step 函式狀態型別（任務、抉擇、失敗/成功、通過、等待、並行）、AWS Step 函式轉換（基本轉換、輸入輸出）。
評分：9
AWS | 開發助理 | API 閘道器基礎
收穫：API 閘道器主要特性、API 閘道器優勢、API 閘道器資源、API 閘道器方法。
評分：9
AWS | 開發助理 | API 閘道器部署及階段
收穫：部署、階段。
評分：7
AWS | 開發助理 | API 閘道器快取及監控
收穫：API 閘道器快取、API 閘道器 CloudWatch。
評分：8
AWS | 開發助理 | CloudWatch 基礎
收穫：EC2 指標、S3 指標、ELB 指標。
評分：9
AWS | 開發助理 | CloudFormation 基礎
收穫：模版、棧。
評分：7
AWS | 開發助理 | CloudFormation 資源及棧
收穫：資源、棧。
評分：8
AWS | 開發助理 | CloudFormation 函式
收穫：固有函式、常見固有函式。
評分：8
AWS | 開發助理 | 引數儲存基礎
收穫：系統管理器引數儲存基礎、引數儲存 API 行為、常見 API 行為。
評分：9
AWS | 開發助理 | 亞馬遜雲共享責任模型
收穫：基礎設施服務、容器服務、抽象服務。
評分：9
AWS | 開發助理 | 信譽顧問
收穫：核心檢查建議。
評分：8
AWS | 開發助理 | 加固資料
收穫：S3（桶級或物件級許可權、啟用版本控制、副本、服務端加密、客戶端加密）、EBS（副本、備份、微軟加密、TruCrypt 加密、Linux 加密、SafeNet ProtectIV 加密）、RDS（MySQL、Oracle、單項函式）、Glacier（服務端加密、唯一加密金鑰）、DynamoDB（原始二進位制檔案、Base-64 加密字串欄位）、EMR（無 HDFS 拷貝服務端加密、應用級加密、混合）。
評分：9
AWS | 開發助理 | 安全地解除資料及裝置
收穫：請求刪除、審查塊儲存、嘗試讀。
評分：8
AWS | 開發助理 | 資料傳輸保護
收穫：突發資訊洩漏、資料完整性妥協、對等身份妥協、AWS 管理控制檯。
評分：8
AWS | 開發助理 | 加固作業系統應用
收穫：建立自定義 AMI、引導應用、管理補丁、不要在 AMI 上存放憑據、保護環境不受惡意程式侵擾。
評分：8
AWS | 開發助理 | 測試安全性
收穫：防火牆、Web 應用防火牆、基於主機的 ID/IP、記錄所有東西。
評分：8
AWS | 開發助理 | AWS 架構良好的框架
收穫：不要猜測你的用量需求、在生產級對系統進行測試、自動化以簡單化架構實驗、允許演進式架構、資料驅動架構、隨時做好伸縮準備。
評分：9
AWS | 開發助理 | AWS 良好框架的五大支柱
收穫：卓越運維、安全性。
評分：9
 

演算法

當月無
 

後端

當月無
 

前端

當月無
 

收聽/收看

得到學習計劃 | 高考複習節奏被打亂，怎麼辦？
收穫：八條戰術打法：1. 嚴格要求自己按照規劃的作息時間起居、學習；2. 把省出來的上學、放學路上的時間，用於戶外體育活動，增強體質，提高免疫力；3. 把各科學習時間與所在省份統一安排的高考時間吻合，讓自己的大腦開始逐漸適應不同科目考試時段，並 “培育” 大腦興奮點；4. 按照規劃學習時，一定要先收起手機等移動通訊工具；5. 開始做一套題目（試卷）前，不要急於對答案；6. 萬一此次停課時間較長，可以獨立研究一下所在省市的歷屆高考真題；7. 每天關心一下疫情狀況和收看新聞也需要排上學習議程；8. 組建線上學習小組。
評分：9
得到學習計劃 | 如何打造一個反派角色？
收穫：如果你成功的話，觀眾會和你的主人公同喜同悲，跟隨他走到天涯海角。也就是說：一個電影成功的要點是要觀眾與主人公共情。傳播學心理實驗的兩個發現：發現一（觀眾對於影視角色道德觀的判斷，是隨著對人物的好惡而變化的。也就是說：如果你喜歡一個角色，你對他不道德行為的容忍度會增加）、發現二（“相對道德觀”：儘管觀眾不贊成壞主人公的行為，但是當他周圍的環境和人物比他更壞、更不道德時，觀眾會選擇支援主人公）。英雄和惡魔只是一線之隔，道德和罪惡在於一念之差。我們和世界可以相互毀滅，也可以相互成就。因為最終成就一個人的，並不是善或惡的本性，而是在善事和惡事之間，人做出的一次次選擇。
評分：10
得到學習計劃 | 瞭解電影不一樣的意義，人間值得
收穫：電影不僅僅是一種藝術形態，也是一個讓人夢想成真的地方。可能這就是為什麼李安會說，他在拍電影的時候，反而覺得電影裡的世界比現實更真實。除了重構現實，電影在一些重大的歷史節點，也發揮了非常重要的社會作用。這些導演的努力也換來了想要的結果，美國民眾形成了一股集體意識，那就是美國正在參與一場正義之戰。電影哪裡僅僅是一種藝術形式，它在現代史上承擔的東西太多了，從個人的希望，到一個國家的團結，我們每多瞭解一點，就會覺得人間值得。
評分：9
得到學習計劃 | 音樂是怎麼變成免費午餐的
收穫：真正從事網路盜版的團隊還很容易脫罪。而下載盜版音樂，則是一代人的集體行為。這也正是盜版很難追罪的原因。MP3 技術超前於它所在的時代，它天生適合音樂產業，卻長期被音樂行業打壓，在市場上所獲甚少。直到網際網路時代來臨，它才被檔案共享亞文化團體發現，並廣泛使用，但卻成了盜版音樂的代名詞。
評分：8
得到學習計劃 | 為什麼越理解人性，就越能解決問題？
收穫：越能理解人性，就越能解決商業問題：《道德與市場》、《天主教世界》。越能理解人性，越能解決技術問題：《俞軍產品方法論》、《增長思維 30 講》。越能理解人性，越能解決社會問題：《警察：街角政治家》。
評分：8
得到學習計劃 | 家庭背景聲 - 關鍵時刻演講 - 總序
收穫：《我們將戰鬥到底》、《在陣亡將士葬禮上的演講》、《申辯》、《不自由，毋寧死》、《葛底斯堡演說》、《我有一個夢想》、《支援 “物種起源” 的學說》、《論不合作》、《探索的動機》、《在巴黎索邦代表大會的致辭》。
評分：8
得到學習計劃 | 家庭背景聲 - 寬容 - 總序
收穫：《先驅者》、《蘇格拉底》、《伊拉斯謨》、《拉伯雷》、《布魯諾》、《斯賓諾莎》、《伏爾泰》、《萊辛》、《托馬斯潘恩》、《寬容的出路》。
評分：8
得到學習計劃 | 家庭背景聲 - 傅雷家書 - 總序
收穫：《一九五四年一月十八日至十九日晚：遠行》、《一九五四年十月二日：正視人生的低調》、《一九五五年一月二十六日：赤子之心》、《一九五五年五月八日：對手，鏡子與夥伴》、《一九五六年二月二十九日夜：偉大的心，真誠的愛》、《一九五九年十月一日：愛國家》、《一九六〇年八月二十九日：冷靜、容忍與愛情》、《一九六一年九月十四日：父母心》、《一九六二年三月八日：戀愛中的博敏》、《一九六五年二月二十日：偉大音樂與中國傳統》。
評分：9
得到學習計劃 | 家庭背景聲 - 哈佛畢業演講 - 推薦序
收穫：《傾聽內心的低語》、《未來並非在劫難逃》、《永遠別向複雜低頭》。
評分：9
得到學習計劃 | 家庭背景聲 - 西方名家經典散文 - 羅振宇推薦序
收穫：最經典的作品，最優秀的聲音表演者。
評分：8

邏輯思維第 110 期 | 大門口的野蠻人
收穫：人類的繁榮到底是怎麼來的、日本經濟衰落之謎、老而不死是為賊、大航海精神何在、邁阿密：靠罪犯和流浪漢繁榮起來的都市、創新：低素質者與高素質者的雙人舞、患上 “日本病” 的香港何去何從。
評分：9

賣桃者說第 36 期 | Deadline 的魅力
收穫：霍夫施塔特定律：即使你考慮到了霍夫施塔特定律，專案的實際完成時間總是比預期的要長；布魯克定律：為已經延期的軟體專案增加人手只會讓專案延期得更厲害；時間的力量：一個新的團隊，無論多麼拼命，多麼才華橫溢，只要是需要協作開發的專案，初期基本上很難做到保質保量按時釋出；Deadline 的魅力：一種行之有效的專案進度管理方式，就像武俠小說裡的月夜斬一樣，偶爾用一下，威力驚人。但不能常用，否則會適得其反。
評分：9
賣桃者說第 37 期 | 如何讀好一本書
收穫：1. 這本書到底在談什麼？2. 作者具體說了什麼，怎麼說的？3. 這本書說的有道理嗎？是全部有道理，還是部分有道理？4. 這本書跟你有什麼關係？四個漸進層次：1. 基礎閱讀；2. 檢視閱讀；3. 分析閱讀；4. 主題閱讀。
評分：10
賣桃者說第 38 期 | 為什麼獲得提拔的不是你？
收穫：可能是因為你沒有展現出把事情做成的能力吧。
評分：9
賣桃者說第 39 期 | 我是如何收集知識的
收穫：讀書、好記性不如爛筆頭、稍後讀，而不是稍後再也不讀。
評分：10
賣桃者說第 40 期 | 把 Linux 核心當成一家軟體外包公司的老闆
收穫：作業系統其實就像一個軟體外包公司，其核心就相當於這家外包公司的老闆。所以接下來的整個課程中，請你將自己的角色切換成這家軟體外包公司的老闆，設身處地去理解作業系統是如何協調各種資源，幫客戶做成事情。
評分：9
賣桃者說第 41 期 | 年初做的計劃，你完成了多少？
收穫：OKR 的好處在於，對於目標提出了可度量的關鍵結果。它是一種非常實用的工具，大部分目標驅動的場景都可以使用，你的新年計劃自然也不例外。
評分：8
賣桃者說第 42 期 | 如何高效完成自己的計劃？
收穫：第一個關鍵點，目標要確定且具備可行性；第二個關鍵點，不要貪心，目標最好不要超過 5 個，每個目標下面的關鍵成果定在 2-4 個比較合適；第三個關鍵點，組成目標的關鍵結果要做到明確且定量；第四個關鍵點，定期 Review 你的計劃，並根據情況做出調整。
評分：10
賣桃者說第 43 期 | 影響了我二十年的三個原則
收穫：一、閉環原則；二、誰難受誰推進原則；三、Think bigger。
評分：10
賣桃者說第 44 期 | 發生故障後要不要追責？
收穫：只要不是設計高壓線，或者造成了不可挽回的損失，一定要優先鼓勵肯定，傳遞信任，而不是批評和處罰。當然，定責該怎麼定就怎麼定，但不要懲罰，畢竟，我們的最終目的是從根本上反思，找出問題的根源，避免下次再犯，而不是懲罰人。
評分：9
賣桃者說第 45 期 | 深入淺出資料庫索引
收穫：索引常見模型、InnoDB 的索引模型、索引維護。
評分：10
賣桃者說第 46 期 | 極客時間手記一：產品之難
收穫：你有你的計劃，世界自有計劃。產品之難，難於上青天。發揮自己的長板，讓別人補足你的短板，這就是現代的木桶理論。做到產品的確定性，需要付出巨大的努力。只有這樣，你可能把事情做對、做好，最終將產品呈現到大眾的眼前。
評分：10
賣桃者說第 47 期 | 極客時間手記二：我們要做什麼樣的產品
收穫：第一、精益現有業務。第二、需要做一款真正意義上的網際網路產品。
評分：8
賣桃者說第 48 期 | 極客時間手記三：找到合適的人
收穫：3F 原則：Friend / 朋友、Family / 家人、Fool / 傻子。構建自己的影響力和資源池：1. 多輸出、多分享；2. 幫助別人。團隊的組織結構：1. 大公司團隊構成；成長型公司團隊構建；3. 創業公司團隊構建。
評分：9
賣桃者說第 49 期 | 極客時間手記四：構建技術基礎服務
收穫：1. 根基：技術基礎服務（流暢、穩定）。2. 如何構建基礎服務（規劃產品要有長遠的打算、成熟的技術要儘快引入、考慮同型別技術在不同應用場景下的使用、要重構程式碼，而不是重寫程式碼、要把變化集中在某個領域、要做好 Code Review 和研發計劃）。3. 大公司和創業公司的不同（基礎服務、業務系統、使用的程式語言、各個終端技術、本地只搭建測試環境、生產服務都放公有云）。
評分：10
賣桃者說第 50 期 | 風險管理：不能盲目樂觀，凡事都應該有B計劃
收穫：什麼是風險管理？：風險 = 損失 x 發生概率、風險管理重要嗎？：被動應對（風險已經發生，造成了問題才被動應對）、有備無患（事先制定好風險發生後的補救方案，但沒有任何防範措施）、防患未然（對可能的風險做出防範，並把風險防範作為專案任務的一部分）、如何做好風險管理？：1. 培養風險意識（專案中的任務，不能盲目樂觀，都思考一下它最壞的結果是什麼，如果最壞的結果不能接受，就說明要有個 B 計劃，考慮風險管理）、2. 管理風險（第一步：風險識別，識別可能的風險、第二步：風險量化，對風險進行評估量化、第三步：應對計劃，對風險制定應對策略、第四步：風險監控，對風險進行監控預警）。
評分：9
賣桃者說第 51 期 | 極客時間手記五：產品的構建和釋出（上）
收穫：1. 從 MVP 到 PMF。2. 萬丈高樓平地起，盤龍臥虎高山齊。3. 產品釋出了，什麼都沒有發生。
評分：9
賣桃者說第 52 期 | 極客時間手記六：產品的構建和釋出（下）
收穫：1、增長模型。2、口碑營銷和事實營銷（口碑營銷、事實營銷）。3、神奇時刻。4、設定里程碑。5、副產品。6、閉環。7、管理員視角和使用者視角。8、關注使用者的長期價值和本質需求。
評分：9
賣桃者說第 53 期 | 如何把 GitHub 帳號打造成社交名片？
收穫：整理你的 GitHub 賬號、參與開源專案、打造自己的開源專案。
評分：8
賣桃者說第 54 期 | 你有錯失恐懼症嗎？
收穫：1. 梳理的資訊獲取渠道、2. 與自己和解，承認你的時間和精力有限、3. 根據谷歌的 70-20-10 原則規劃自己的時間、4. 思維上的斷舍離。
評分：10
賣桃者說第 55 期 | 程式設計師練級攻略：技術資源集散地
收穫：個人技術部落格、油管頻道、各大公司技術部落格、論文。
評分：10
賣桃者說第 56 期 | 自由軟體之父理查德·斯托曼
收穫：他的三個主要成就：開發了 Emacs 編輯器、GNU 通用公共許可證、Copyleft，所有 GNU 程式都應遵循 “Copyleft” 原則。
評分：9
賣桃者說第 57 期 | 為什麼你總是看起來很忙？
收穫：有理想，但不忙著實現，那就是幻想。
評分：8
賣桃者說第 58 期 | 你在解決問題還是在製造問題？
收穫：在遇到問題的時候一定要先判斷以下，這個問題是真實的需求，還是自己製造出來的偽問題，甚至是麻煩。如果是後者，那還是幹掉問題本身好了。
評分：9
賣桃者說第 59 期 | 我們能從失敗中學到什麼？
收穫：看穿而不是看到，要聚焦，要取捨，要直面競爭，不要去做小數點後面的事情。
評分：10
賣桃者說第 60 期 | 最近極客時間釋出的幾個新功能
收穫：專欄和視訊課程的詳情頁和目錄都進行了全面的改進、視訊課程增加了下載功能、多級留言、其他四個使用技巧（搖一搖、搜尋入口、內容分享功能入口、學習軌跡、連續播放和後臺播放）。
評分：9
賣桃者說第 61 期 | 你會主動跟你的上級溝通嗎？
收穫：定期溝通和反饋、提前做好準備、注意上級的能力邊界、根據不同的場景使用不同的溝通工具。
評分：9
賣桃者說第 62 期 | 有準備的面試才能拿到更好的 Offer
收穫：求職型別、面試準備、（1. 明確自己現有的知識領域和目標職位的匹配程度、2. 技能準備、3. 目標公司）、簡歷、面試過程（你為什麼離開、你為什麼來這、你為什麼總跳槽、你為什麼這麼長時間不跳槽、你有什麼優點、你的長期規劃、你的短期規劃）、反饋。
評分：10
賣桃者說第 63 期 | 自律的人生和自律的程式
收穫：自律人生（推遲滿足感、承擔責任、尊重事實和保持平衡）、自律程式碼（定義含義明確的介面、無副作用函式和指責單一原則、概念輪廓原則）。
評分：10
賣桃者說第 64 期 | 你對推薦演算法的認知，也許都是錯的
收穫：誤區一：推薦演算法是根據使用者點選率來推薦。誤區二：冰箱都買完了還推薦冰箱，點了不喜歡還推薦，演算法一點都不聰明。誤區三：推薦演算法會導致 “資訊繭房”。誤區四：推薦演算法發展的很快，未來可以洞察人性，無所不能。誤區五：演算法都是公開的，競爭壁壘不高。
評分：10

極客新聞 | 蘋果詳解 Face ID 的安全性
收穫：Face ID 使用了多個神經網路，分為面部識別和抗欺騙兩類。面部識別神經網路可以應對使用者穿戴帽子、圍巾、眼睛、隱形眼鏡以及格式太陽鏡的情形；而抗欺騙神經網路則是防止使用照片或者面罩來解鎖手機。
評分：8
極客新聞 | 微軟加入量子計算的競爭
收穫：微軟的量子計算平臺預覽版將包括一個量子計算模擬器，以及一種整合在 Visual Studio 種的量子計算程式設計新語言。根據微軟介紹，該平臺的拓撲量子位元計算執行時間更長、一致性更好並且誤差更小。
評分：10
極客新聞 | Reddit 是如何面試工程師的？
收穫：招聘流程五步驟：簡歷篩選、電話面試、現場面試、Offer 傳送、入職報到；現場面試六輪：三輪技術，三輪 QA；現場技術面試兩方面：程式碼和演算法，系統設計；回答技術問題時：可以適當求助面試官；QA 面試三環節：環節一（候選人 AMA，Ask Me Anything，面試和被面者可以問對方任何問題，相互加深對對方的瞭解）；環節二（跨職能面試，非基礎設施的工種需要和產品團隊打交道，需要具備良好的溝通能力和解決衝突的能力，可以問有關產品線的問題）；環節三（從更高層次以及候選人專案經驗來評估候選人與職位的匹配情況，候選人可以問專案情況、公司架構以及團隊路線圖等問題）。
評分：10
極客新聞 | 如何理解逆變測試？
收穫：生產程式碼應該總是越來越泛化，而測試程式碼應該越來越具體。這就促進了解耦。這樣就是逆變，兩個程式碼流沿著泛化軸向著相反的方向演化，直到沒有新的沉降試驗可以編寫。
評分：8
極客新聞 | 英偉達釋出人工智慧相關新專案
收穫：Holodeck 是一款 CAD 工具；TensorRT 3 是一款 AI 推理軟體；Drive PX Pegasus 是一款應用於自動駕駛的人工智慧系統；Pegasus 將四個強大的處理器組合在一個車牌大小的裝置上。
評分：9
極客新聞 | Gartner：2020 年 AI 將創造 230 萬個就業機會
收穫：隨著 NLP（自然語言處理）技術的快速發展，聊天機器人在識別使用者意圖、瞭解使用者需求方面也表現得越發優秀。經 Gartner 研究發現，基於語音搜尋的查詢是增長最快的移動搜尋型別。語音和視覺搜尋正在加速移動瀏覽器和移動 APP 的交易增長，在許多電商網站上，基於這兩者的交易額已經佔據交易總量的 50%，這一趨勢還將在 2018 年及以後持續進行。
評分：8
極客新聞 | 谷歌大腦團隊的研究方法
收穫：谷歌大腦團隊也堅信培養下一代科學家非常有意義，它每年接受超過 50 名實習生，併為他們進行機器學習領域的研究提供指導；同時還啟動了谷歌大腦學員計劃，為對機器學習研究感興趣的人群提供進修渠道。
評分：7
極客新聞 | 安卓統一推送聯盟正式在京成立
收穫：聯盟的建立將進一步完善中國安卓生態的建設。聯盟讓終端廠商、App 開發商、第三方推送服務平臺的資源得到整合，減少矛盾和利益衝突，形成協同的產業鏈發展格局，助力推送服務體系的建設，讓中國的安卓生態更加健康和穩定。
評分：8
極客新聞 | 微軟攜手亞馬遜釋出深度學習庫 Gluon
收穫：機器學習的潛力只有在所有開發人員都可以訪問的情況下才能體現。目前，構建和訓練機器學習模型仍然需要大量的專業技能，而 Gluon 讓構建神經網路和訓練模型像構建應用一樣簡單。
評分：7
極客新聞 | 姚期智：工業界有望反向助力 AI 理論突破
收穫：需要整合大資料、自然語言分析、影像識別等諸多人工智慧技術，本質上是將已有的知識點按照需求進行整合。
評分：9
極客新聞 | QQ 空間已在生產環境中使用 QUIC 協議
收穫：谷歌通過大規模的效能分析訪問，相較於 TCP 而言，QUIC 的效能有了真正的進步。而與 HTTP/2 相比，QUIC 協議棄用了 TCP 而改用了 HTTP/2 在傳輸層所遇到的一些效能瓶頸，同時又具有 HTTP/2 的特性。目前的劣勢是瀏覽器支援度比較差。
評分：7
極客新聞 | 演算法比資料更重要，AlphaGo Zero 完勝舊版
收穫：最大的突破在於實現了 “白板理論”。嬰兒是一塊白板，可以通過後天學習和訓練來提高智力。人工智慧（AI）的先驅圖靈認為，只要能用機器製造一個類似於小孩的 AI，然後加以訓練，就能得到一個近似成人智力，甚至超越人類智力的 AI。而自學成才的 AlphaGo Zero 正是實現了這一理論。
評分：10
極客新聞 | Spring Data Kay 釋出最新正式版
收穫：同時釋出的還有 Spring for Apache Kafka 2.0，也是以 Spring 5 和 Java 8 為基準，支援事務、Kafka Streams API，並更新了 Kafka 客戶端，能夠更好地支援測試，改進了錯誤處理方式。
評分：9
極客新聞 | SaaS 與 IaaS 推動全球公有云收入增長
收穫：到 2021 年有 70% 的公有云服務收入將被前 10 大公有云廠商所主導。在 IaaS 方面，亞馬遜、微軟和阿里巴巴已經佔據強有力的市場地位。
評分：8
極客新聞 | Docker 宣佈將支援 Kubernetes
收穫：Docker 容器被稱為容器執行時的事實標準，但在容器編排上，Kubernetes、Mesos 和來自 Docker 官方的 DockerSwarm 一直處於競爭狀態，而來自谷歌的 Kubernetes 以其高效、簡便、高水平的可移植性等優勢佔領了絕大部分市場。。
評分：8
極客新聞 | 谷歌釋出 Android Instant Apps SDK 1.1
收穫：當使用者需要使用或瀏覽某個未安裝的應用時，系統可以自動載入其中的內容並開啟它。在這個過程中，使用者不需要安裝這個應用，這在很大程度上方便了使用者，也為手機省去了安裝所需的記憶體。
評分：8
極客新聞 | GitHub 釋出 2017 年度開發者報告
收穫：一、GitHub 使用者數已達 2400 萬。二、GitHub 上最後歡迎的程式語言：JavaScript 第一，Python 第二，Java 第三。三、近 70 萬中國開發者加入 GitHub。四、上百萬學生和老師把 GitHub 當成學習與教授的地方。五、TensorFlow 當選最火熱專案。
評分：8
極客新聞 | 庫克：學習程式設計比學習英語更重要
收穫：無論是政治家還是科技公司高管，越來越多的知名人士都在強調程式設計的重要性，程式設計已經成為大家心目中非常重要的一種技能。。
評分：8
極客新聞 | 谷歌釋出文件資料庫 Firestore
收穫：用於移動、網路和伺服器應用的文件資料庫。
評分：8
極客新聞 | MDN 成立產品顧問委員會 PAB
收穫：近幾年，各家瀏覽器之間的合作多了很多，前端開發者的日子也好過了很多，希望這樣的合作繼續下去，讓瀏覽器相容不再成為問題。
評分：8
極客新聞 | 張建鋒：網際網路第三波浪潮來襲
收穫：智聯網、新一代人及自然互動、機器智慧。
評分：9
極客新聞 | 阿里巴巴開源 AliOS Things，佈局物聯網
收穫：全棧物聯網作業系統。
評分：8
極客新聞 | 2017 全球 Chrome 瀏覽器加密網頁突破 70%
收穫：現在，HTTPS 加密已經比過去更簡單、更便宜，不僅能夠保證網站服務的效能，也能保護使用者的敏感資料。
評分：9
極客新聞 | IBM 開源 Java 微服務執行時環境 Open Liberty
收穫：Open Liberty 與其他應用伺服器最大的不同之處，首先在於配置的簡易性，他們努力讓配置變得簡單易用，配置檔案可以被提交到版本控制系統裡，這樣就可以和程式碼放在一起了，這對於 DevOps 來說是一個好訊息。
評分：8
極客新聞 | 100% 程式碼覆蓋還值得追求嗎?
收穫：函式覆蓋率 > 分支覆蓋率 > 語句覆蓋率。
評分：9
極客新聞 | 如何成為 10x 資料科學家？
收穫：首先，要了解業務。其次，要了解資料。最後，要了解程式碼設計。
評分：8
極客新聞 | Visual Studio 15.4 釋出，新增多平臺支援
收穫：延續了支援 。NET Standard 2.0 和通用 Windows 平臺即 UWP 的承諾。.Net Standard 2.0 支援是微軟推動跨平臺應用開發和程式碼重用戰略的重要一環。
評分：8
極客新聞 | Uber 開源資料流分析平臺 AthenaX
收穫：能將各查詢編譯為可靠、高效的分散式應用，同時管理該應用的完整生命週期，這允許使用者僅專注於最為核心的業務邏輯。其大大簡化了流分析任務處理方式，使得所有技術水平的使用者都能將大規模流分析應用，快速引入到自己的生產環境中，幫助大家輕鬆構建起自己的。
評分：7
極客新聞 | Bustle 的 GraphQL 實踐
收穫：首先解決了人員溝通檔案。GraphQL 為 API 或文件的變更提供了開箱即用的解決方案。它是一門比 REST 更加嚴謹的 API 開發語言，它強制你開發出更好的 API，同時可以自動生成文件。它自帶的 API 瀏覽器（explorer）完全是自動化的，節省了開發時間，加快了開發速度。
評分：8

每日一課 | 如何快速對應用系統做一個 360 度的畫像診斷?
收穫：程式消耗 CPU；記憶體利用率暴增；資料庫連線數被耗盡；各種 OOM；執行緒死鎖；鎖爭用；上下文切換太頻繁。
評分：10
每日一課 | 支付系統中，有哪些技術問題可能會引發資金損失？
收穫：問題的產生：人為操作不當、系統邏輯錯誤、併發場景處理不當、網路異常、查詢和通知問題、介面冪等性問題、狀態同步問題、重複提交問題；前後端防重：前端防重（禁掉提交按鈕、資料庫加索引、Redis 加鎖、token 校驗）、後端防重（資料庫樂觀鎖、有限狀態機、白名單）。
評分：10
每日一課 | webpack 構建如何更合理地實現多頁面打包？
收穫：一、 制定合理的 entry 匹配規則；二、實現 entry 的動態計算；三、根據 entry 的 key 值增加對應的 html-webpack-plugin。
評分：9
每日一課 | 面試中如何通過 HashMap 展示你在資料結構方面的功底？
收穫：資料結構中的 Hash 表和 Hash 演算法；Hashmap 裡為什麼能夠一槍命中；重寫 hashcode 方法和 equals 方法；面試中引出相關話題的技巧。
評分：9
每日一課 | iOS 如何優雅地協同滾動多個子 ScrollView？
收穫：1. 如何實現多個滾動檢視互不干擾的滾動，交接時保持流暢？：layoutSubviews 函式；2. 在滿足協同流暢滾動的同時，需要考慮哪些通用的優化處理？：效能上滾動流暢、結構上易於擴充套件、複用、預載入。
評分：9
每日一課 | 新聞類 App 是如何展示資訊內容的？
收穫：如何兼顧多端統一的內容展示，保證敏捷開發？如何突破瓶頸，優化展示邏輯，提升展示的速度？面對複雜的互動內容，如何進一步優化互動體驗？。
評分：9
每日一課 | 如何對 JS 檔案進行型別檢查？
收穫：引入 TypeScript；好的編輯器：VS Code：JSDoc、d.ts 檔案、jsconfig.json。
評分：10
每日一課 | Vue 中修改了陣列數值，為什麼介面沒有更新？
收穫：由於 JavaScript 的限制，Vue 不能檢測以下陣列的變動：當你利用索引直接設定一個陣列項時，例如：vm.items[indexOfItem] = newValue；當你修改陣列的長度時，例如：vm.items.length = newLength。
評分：9
每日一課 | Java 中將介面和實現放在同一層裡對嗎？
收穫：無環依賴原則（ADP）、穩定依賴原則（SDP）、抽象穩定原則（SAP）、依賴倒置原則（DIP）、主介面卡 Driving Adaptor、次介面卡 Driven Adaptor、端點（介面）。
評分：10
每日一課 | C++ 中如何深入理解左值、右值與右值引用？
收穫：右值：xvalue（Expiring Value，將亡值）、prvalue（Pure Right Value、純右值）；純右值：函式返回的臨時變數值、字面量值、lambda 表示式；將亡值：在 C++ 版本中新引入的跟右值引用相關的表示式型別；使用基於右值引用的語義轉移過程：省去重新分配記憶體空間的過程，可以在一定條件下提升應用的整體執行效率；RVO 與 NRVO：編譯器廠商會同時使用的編譯器優化技術，以對函式的物件返回值型別進行臨時值上的優化；常量左值型別（const T&）的好處：可以被進行取地址操作；將亡值：資源能夠被重新使用的物件（“std::move” 函式的返回值；返回值被標記為右值引用（&&）的函式）。
評分：8
每日一課 | 如何快速設計出一套實用的監控系統？
收穫：要監控的層面：基礎設施（硬體、網路、作業系統/容器、主機）、中介軟體和公共服務（JVM、MySQL、Redis、Tomcat、Nginx）、應用服務（服務狀態、服務錯誤數、呼叫鏈、訂單狀態類、耗時類、實時統計類）。
評分：10
每日一課 | C++11 中簡單好用的新語法特性有哪些？
收穫：auto 關鍵字（有時會出 BUG）：型別佔位符。decltype 關鍵字：匿名列舉類、匿名結構體、匿名聯合體、增強模版泛型的能力。基於範圍的 for 迴圈：冒號前（用於進行迭代的具體變數）、冒號後（將要被迭代值的具體範圍）。其他好用特性：lambda 表示式、 constexpr 關鍵字、智慧指標。
評分：8
每日一課 | 如何從容地應對生產事故？
收穫：一、事故洞察；二、事故分析；三、事故升級；四、事故應對；五、事故覆盤；六、完善方案池；七、故障演練；解決事故的參與者。
評分：10
每日一課 | 如何利用有效的資源扛住 618 大促流量？
收穫：梳理清楚部署及呼叫情況、外網閘道器機房部署比例、對介面呼叫情況進行梳理、介面重要程度識別、識別業務風險點（制約效能上限）、效能測試報告、分層優化。
評分：10
每日一課 | TLS1.3 原理以及在 Nginx 上的應用
收穫：橢圓曲 DH 金鑰交換、魏爾斯特拉斯橢圓函式、蒙哥馬利曲線。
評分：8
每日一課 | 究竟要不要使用 React Hooks？
收穫：Class、fx 元件 + React Hooks（解決程式碼複用問題：高階元件、函式作為子元件。最大的好處：關注分離、程式碼複用）。
評分：8
每日一課 | React 中如何實現模組的按需載入？
收穫：React.lazy（載入中、載入完成、可以被 Suspense 進行處理）、import（動態 import、動態載入模組、ES6 語法規範）、Suspense。
評分：9
每日一課 | 如何快速對請求鏈路的關鍵點進行網路問題排查？
收穫：確認是否存在佇列阻塞、Linux 系統檔案控制程式碼、核心檔案增大軟限制和硬限制。
評分：9
每日一課 | HTTP/2 能帶來哪些效能提升？
收穫：HTTP 協議的五個精準定位、五個特點所帶來的新問題、問題解決途徑。
評分：10
每日一課 | 服務發現技術是如何演進出來的？
收穫：集中式代理、客戶端嵌入式代理、主機獨立程式代理。
評分：10
每日一課 | JavaScript 中如何優雅地實現函式防抖？
收穫：定義 debounce 函式，並接受 fn 和 timeForWait 兩個引數。
評分：9
每日一課 | JavaScript 中如何封裝一個具有自動失敗重試功能的 HTTP 模組？
收穫：async 和 await 來實現。
評分：10
每日一課 | 如何理解現代釋出策略？以 Kubernetes 為例
收穫：蠻力（Brute Force）釋出、滾動釋出（Rolling Update）、藍綠髮布（Blue/Green 釋出）、金絲雀釋出（Canary）、A/B 測試。
評分：10
每日一課 | 前端 Router 是怎麼實現的？
收穫：使用 URL 的 hash 來模擬一個完整的 URL。利用瀏覽器的 history API。
評分：10
每日一課 | 為什麼 CSS 要放在 header 底部，JavaScript 要放在 body 底部？
收穫：為了提高使用者體驗。
評分：8
每日一課 | 使用 Vue 開發小程式是怎麼做到的？
收穫：小程式渲染原理、使用 Vue 開發小程式、實現思想。
評分：9
每日一課 | 大廠前端面試中經常提到的 Promise 要如何實現？
收穫：Promise/A+ 規範內容：每個例項只能有三個狀態（Pending、Fulfilled、Rejected）、只能從 Pending 到 Fulfilled 或 Pending 到 Rejected、狀態變化不可逆、可以被呼叫多次並返回一個 Promise 物件、內部儲存一個 value 值，用來儲存上次執行的結果值、如果報錯，則儲存的是異常資訊。
評分：10
每日一課 | 如何讀懂 Babel 轉換出的 JavaScript 程式碼?
收穫：Babel 的基本構成（.babelrc 配置檔案包含：presets 和 plugins、.babelrc 配置檔案包含：presets 和 plugins）。Babel 是如何讀懂 ECMAScript6 程式碼的（轉換 const 和 let 成 var；箭頭函式裡的 this 指向的是外層物件；引數擴充套件符；模組化寫法）。
評分：8
每日一課 | 如何利用 ClassPath 解決 Java 開發工程問題？
收穫：設定 ClassPath、IDEA 啟動時，-classpath 引數裡的內容、IDEA 啟動應用前、覆蓋類時，應用的 -classpath 分為三部分、IDEA 啟動測試時，它的 ClassPath 有三部分、ClassPath 知識點、IDE 啟動時，ClassPath 的順序、ClassPath 的順序。
評分：9
《檢視《每日一課》原文》

編輯訓練營 | 為什麼說編輯要重視文字規範？
收穫：文字規範：“小” 錯誤，有 “大” 成本。對症下藥，才能真正解決問題：1. 不拒絕問題，才能進一步解決問題、2. 如何改掉 “粗心” 的毛病，提升文字質量？、你可能不是 “粗心”，而是知識體系有欠缺、好編輯，應該有文字潔癖；參考資料：《標籤符號用法》、《出版物上數字用法》、《新華字典》、《圖書編輯校對實用手冊》、《作者編輯常用標準及規範》。
評分：10
編輯訓練營 | 如何發現並糾正文章語病？
收穫：一、何謂病句及正確句子的語法結構。二、病句出現的常見雷區。三、最常見的四大病句型別：1. 語序不當（常發於：並列定語與賓語）（讓長定於先行、短定語緊貼賓語）、2. 結構混亂（常發於：主語、謂語、狀語、賓語）（抽離主句中的主語，將該主語套在每個半句上，如果半句中缺失主語不能與抽離的主語吻合，就一定產生了主語的偷換）（謂有否，賓狀不可否）；3. 成分殘缺（常發於：代詞、賓語）或贅餘（常發於：代詞、介詞）（砍掉句子中所有的定、狀、補及各種從句，保留下來的主、謂、（賓）是否能獨立成句，如果不能，則一定出現了成分殘缺）（先定位清楚補足語內（比如例子中的後半句）是否包含主、謂、（賓）等成分）（只有當 ”對於“ 接定於成分或單獨的主語內容，那麼才是正確的語境）；4. 搭配、指代不當（常發於：介詞、動詞、代詞、關聯詞）。四、語病 Checklist（因此，為了更好地幫你記憶正確的語法結構，我也為你建立了一個簡單的 ”語病 Checklist“，如果你的句子出現了以下任一問題，那基本上可以斷定 80% 以上的可能性會是病句）；長句子系列；用詞系列。五、培養你的語感。
評分：8
編輯訓練營 | 到底該怎麼理解技術採用生命週期？
收穫：技術採用生命週期：第一類人群稱為創新者、第二類人群稱為早期採用者、第三類人群稱為早期大眾、第四類人群稱為晚期大眾、第五類人群稱為落後者。跨越鴻溝。衡量方法：InfoQ 的可以做些什麼（報導一些成功案例、解決方案，也可以多做一些深入淺出的文章幫助大家入門）、怎麼才能知道技術發展到了哪個階段（藉助 QCon、ArchSummit 大會，與 300 為不同行業，不同領域，不同規模公司的主要技術負責人溝通，瞭解他們對於目前我們所關注技術的採用情況。對溝通情況資料進行整理，計算對應技術的採用率，並根據採用率資料，把相關技術對應到技術採用生命週期中。與行業關鍵意見領袖溝通，對於上述客觀計算出的技術採用生命週期曲線做主觀層面的微調）。推薦書籍：《創新的擴散》
評分：8
編輯訓練營 | 如何取一個好的文章標題？
收穫：標題是文章的第一句話，它決定使用者是否對你產生興趣。什麼是好標題？：好的標題應該是 “真實可信” 的、具有 “衝突感” 的、能和使用者產生 “共鳴” 的。怎麼取一個好標題？：1. 巧用數字，把複雜的概念具像化、2. 設定懸念，引發使用者好奇心、3. 擴大外沿，增加潛在受眾群體、4. 移動端、Web 端，相同內容兩種標題。當在微信公眾號等移動端展示時，標題的衝突性很受使用者喜歡（但現在已經不好使了）。好標題三大要素總結：真實可信、營造衝突感、引發共鳴。
評分：8
編輯訓練營 | 怎麼才能寫出一篇好新聞？
收穫：什麼是好新聞：用概括的敘述方式，以簡明扼要的文字，迅速及時地報導新近發生的、有價值的事實，使一定人群瞭解。好新聞的三個關鍵部分：概括的敘述方式、簡明扼要的文字（誰、何時、何地、何事、為何）；迅速及時地報導新近發生的事（快是王道）；有價值的事實，使一定人群瞭解（要幫助使用者去甄選、判別值得他們關注的新聞）。養成刷線索的習慣的幾個維度：Hacker News、Reddit 等聚合類線索源，當天的重磅、熱點事件；你所關注公司、人的社交媒體；你所負責技術領域的一些公司技術部落格、技術網站或者開發者社群；三個關鍵點：文字簡潔（新聞事件補充背景資訊，從而讓資訊更為豐滿）、快（想要比別人快，就要比別人勤奮）、有價值（提升技術敏感度，多找專家去採訪、交流、吃飯聊天）。如何寫一個好的正文：提出三個使用者可能產生的疑惑，同時確保你已經就這些疑惑提供增量資訊。
評分：9
編輯訓練營 | 和專家溝通出現衝突時，我該怎麼辦？
收穫：溝通不暢，很可能只是準備不足？：首先，關於目的、其次，關於溝通物件、再次，準備內容你預設場景了嗎？、最後，自己的狀態（你能做到每次溝通前都 “重啟” 自己的狀態嗎？）。不會傾聽就不會溝通，太誇張了吧？：對他人真心好奇，就這麼簡單。用資料說話，到底有多厲害？：你有一個論點，那就要有幾個論據來支撐，最好的論據當然是資料和事實了。坦誠溝通，能解決所有問題嗎？：坦誠溝通不一定能解決所有的問題，但這是通往解決所有問題的唯一路徑。
評分：9
編輯訓練營 | 如何快速找到各個領域的專家？
收穫：高效的搜尋技巧：Google hacking（1. 搜尋指定網站的內容、2. 搜尋特定型別的文件、3. 對關鍵詞進行邏輯運算，以找到更精確的結果）、最常用的三種 Google hacking 技巧（1. 通過相關引數來匹配具體需求、2. 用邏輯運算來進行關鍵片語合、3. 特殊符號）、通過哪些渠道找講師（1. 技術會議、現在技術論壇（meetup）；2. 技術媒體 / 部落格 / 公眾號文章作者 / 技術社群；3. 技術圖書作者或譯者；4. GitHub 開源專案貢獻者；5. 微博等社交網站；）、如何與意向講師取得聯絡（1. 多從個人主頁找資訊；2. 儘可能地多蒐集和這個老師相關的資料，然後組合多個關鍵詞進一步檢索；3. 留意會議的演講視訊或者演講文稿的開頭和結尾；4. 擅用其他查詢工具；5. 猜測微信 ID；6. 進一步確認是否有共同好友）。
評分：8
《檢視《編輯訓練營》原文》
 

英文

導師盒 | 做自己的老闆
收穫：做自己懂的喜歡的又容易產生收益的事業。
評分：10
導師盒 | 危機管理 - 埃裡克·德岑霍爾
收穫：由於大眾認知的偏差，你無法滿足所有人，只要照顧好那 18% 與你產生共鳴的市場足矣。
評分：9
導師盒 | Instagram 高階營銷 - 丹·弗萊什曼
收穫：釋出高質量內容：業務相關、符合實際情況、讓讀者愉悅；關注：常人覺得有趣的內容（非政治類、非種族歧主義類）、看競爭對手在做的事、看其他人在做的事。
評分：9
導師盒 | 三個能即時增加網站任意頁面的參與度的高階技巧 - 亞歷克斯·莫爾
收穫：技巧一、有一個好的標題：為什麼訪客需要看這個介面：頂部顯示能給終端使用者帶去的好處、以訪客為中心、處在頂部並居中、兩個重要的好處（更優惠、更快）、五至十二個單詞（包含數字資訊）。技巧二、進行 A/B 測試，但別被它騙了：A/B 測試是一個工具，不是一個信仰、主要的問題是顯著性差異、太多其他變數以及一些工具的非正規歸納方式、比沒有資訊還糟糕的是相信誤導類資訊、可能有用的代替方法（A/A-B/B 測試）。技巧三、不要強迫方可做決定：避免交叉設計，這會帶來決策疲勞、大多數人不是因為他們不喜歡你的產品而不去購買，而是因為拖延症、避免兩列布局、使其易用並可用（不是掃描或抓取資訊）。
評分：10
導師盒 | 病毒視訊剖析 - 泰·洛佩茲
收穫：主要故事主題（M.S.T.）：學的越多，賺的越多。釋出的資訊需要有 70%（可預測） 與 MST 一致，其餘的 30%（不可預測） 可以隨機一些，如果一切都可預測，那將很乏味。為 MST（吸引眼球） 選擇一個行業（收益）：UFC/拳擊=Underdog、Tai Lopez 教育=學得多賺得多、Rock Entertainment=Loveble Big Strong Guy、PewDiePie Video Game=Joker/Crazy。尤拉回路命運：讚揚、業餘時做的事情、敵人的補充、成長的環境、個性測試。
評分：10
導師盒 | 用 Snapchat 來推廣公司業務 - 克里斯·瑞克特
收穫：每天釋出到 Snapshot 的內容將成為其故事的一部分。故事可以使人相信你說的話。由於大家在預設情況下都是靜音檢視每個訊息，所以如果釋出的是視訊內容，請新增字幕。確保只發布圈內相關的訊息。
評分：9
導師盒 | 給網站引入更多流量 - 佈雷特·費爾勒
收穫：釋出線性的小測試。使用正確的語言。
評分：8
導師盒 | 如何為你的品牌引入大流量 - 安東尼·馬塞洛內
收穫：1. Instagram 的價值（好內容、直接訪問至影響人物、切換至商務賬戶）。2. 對標你的服務（普通的頁面、個人的頁面）
評分：9
導師盒 | 銷售的科學 - 傑爾曼·加西亞弗雷斯科博士
收穫：理性大腦（做所有的決定、等紅綠燈、做數學題）。情緒大腦。原始大腦/爬蟲類腦（產生恐懼以啟用防禦機制並失去理智）。兩種銷售人：操作性銷售人員（他們的最終目的是賣東西）、關係型銷售人員（激發信任、客戶願意與其保持聯絡、在銷售之前提升多巴胺等正向奇妙感覺的等級）。使客戶開心的們買賣：讓客戶產生緊迫感，再給其提供可消除緊張情緒的服務或產品，使其感受到被多巴胺環繞的感覺，並自發完成銷售。
評分：10
導師盒 | 租或買房住 - 泰·洛佩茲
收穫：沒有什麼錢的情況下，就租房住。或者有錢的情況下，把買房的錢拿去投資、創業。貝索斯拿著七萬存款去創辦而不是買房，所以他損失了幾百萬而不是幾百億。投資房產之前先親身去實地居住一段時間，如果好租的話，就可以買。
評分：10
導師盒 | 擴充現有業務 - 克里斯·瑞克特
收穫：初期只逐個招聘技能緊缺的職位進行遠端辦公。把每件事當成事業來做，假設你一直都有很多潛在客戶。從小買賣開始，售賣類似 MVP 的產品，見效後逐步改進並提供新的收費服務或產品。
評分：10
導師盒 | 睡得更好 - 肖恩·史蒂文森
收穫：沒有時間鍛鍊，就有時間的病。
評分：10
導師盒 | 正向思維培訓 - 馬克·達瑪
收穫：心理學：讓有問題的人正常。正向心理學：讓正常的人更好。精神韌性的組成成分：愛、高興、感激、希望、自豪。
評分：10
導師盒 | 你的飲食與你的大腦 - 傑爾曼·加西亞弗雷斯科博士
收穫：習慣改變：漸漸改變、偶爾來一次欺騙日（頓欺騙餐）。最大的敵人：果糖（水果）、自由基（氧化）、葡萄糖。
評分：10
導師盒 | 商務旅行技巧 - 奧斯汀·迪斯特爾
收穫：全球入境計劃、匯率、信用卡。
評分：6
導師盒 | 在播客上被預約 - 科林·湯普森
收穫：能接觸到更多的人、為客戶著想，給他們提供有用的資訊。
評分：9
導師盒 | 從報紙上獲得宣傳 - 尤利西斯·奧蘇納
收穫：不能付錢給貢獻者/記者/編輯或給其送禮物、巴結的結果（拉黑、壞印象）、可以付錢給做 SEO 的人、四大謬論（殺手級故事、需要連線、需要大量的信用度、欠你一個故事）、沒有獲得報導的情況下應該首先去的地方（successstory.com、pressstory.com、influencive.com、huffingtonpost.com、thriveglobal.com）。
評分：9
 

書籍

反脆弱：從不確定性中獲益
第 1 章 - 達摩克利斯之劍和九頭蛇怪
收穫：生活中的一半事物未被命名、命名的必要性、反脆弱性的原型、領域獨立就是領域依賴。
評分：9
反脆弱：從不確定性中獲益 - 納西姆·尼古拉斯·塔勒布
第 2 章 - 隨處可見的過度補償和過度反應
收穫：知識分子往往關注的是隨機性（脆弱性）帶來的負面反應，而非正面反應（反脆弱性）。對挫折的過度反應所釋放出來的多餘能量成就了創新！。如何在跑馬比賽中取勝。論暴亂、愛和其他意料之外壓力受益者的反脆弱性（你的堡壘築得越高，我們就越有力量）。請將該書列為禁書：資訊的反脆弱性。
評分：10
第 3 章 - 貓與洗衣機
收穫：壓力就是知識（反之，知識也可以是壓力）— 有機體與機械 — 在現代化主宰了 200 年後，現在該喚醒我們體內的野性了。複雜系統：壓力源即資訊、機械體或有機體/生物體或非生物體（機械體，非複雜系統：需要持續修復和維護、厭惡隨機性、無須恢復、相互依賴性低或沒有、壓力導致材料疲勞、常用導致老化/消耗、在衝擊下會反應不足、時間只會帶來老化。有機體，複雜系統：自我修復、喜歡隨機性/小幅變化、在受壓後需要恢復、相互依賴性高、缺乏壓力導致萎縮、閒置導致老化、在衝擊下會反應過度、時間帶來老化和衰老）。均衡，不再均衡：針對兒童的犯罪（我們不僅厭惡壓力，也不理解壓力，殊不知，徹底消除波動和變化只會危害生命、生活、科學和智慧。除了傷害孩子，我們還會危害社會和我們的未來。旨在減少兒童生命中的變化和波動的舉措卻也會降低我們這個所謂的 “偉大的全球化社會” 中的多元性和差異性）。受到翻譯的懲罰：一個能說流利英語的人，舉著一塊把我的名字拼錯的牌子，在機場迎接我，沒有壓力、沒有歧義，不用使用任何從醜陋的教科書上接觸到的俄語、土耳其語、克羅埃西亞語或波蘭語。觀光化：我們現代人的生活要收到諸多條條框框的約束，即使在我們的休閒時間（週五晚上看歌劇、某個晚上參加約定好的聚餐、預定的活動、預定的笑聲。再次嘆息，我們住在 “金色” 的監獄裡）。對機遇的祕密渴望：如果我能預測我未來每一天的軌跡，那麼我會感覺自己身體的一部分已經死了；現代生活中充斥著原本可以避免的慢性應激損傷。大自然才是偉大的反脆弱專家。
評分：10
第 4 章 - 殺死我的東西卻讓其他人更強壯
收穫：對一個人具有反脆弱性的東西，對其他人而言則是脆弱性的 — 我們何時引入了想的太多、做得太少的理念 — 失敗是為了他人的成功 — 終有一天，你會收到感謝信。反脆弱性的層級：進化和不可預測性（進化最有趣的一面是，它是依賴反脆弱性實現的；它喜歡壓力、隨機性、不確定性和混亂 — 而個體生物則相對脆弱，基因庫正是利用衝擊來確保優勝劣汰，提高整體的適應力）、有機體即群體，群體即有機體（當你禁食的時候，壞的蛋白質將首先被分解，並通過你自己的身體再生，這個過程被稱為細胞自噬）。錯誤，謝謝你：從他人的錯誤中學習（彼此負相關/獨立的錯誤發生會降低未來犯錯的概率。自然是在非系統性的錯誤中學習和改進的）、怎樣成為特里莎修女（犯罪的人要比那些從來沒犯過罪的人更可靠。犯了很多錯誤的人要比那些從來沒有犯過錯的人更可靠）。為何整體厭惡個體（要讓經濟具有反脆弱性，並經歷所謂的進化，每個獨立的企業都有必要是脆弱的，面臨著奔潰的風險進化需要有機體死亡，並被其他有機體取代，以實現整體改善，或淘汰適應力不如其他有機體的生物）：。殺不死我的，會殺死其他人：我和我們（如果不打破個體的利益，整個經濟體就無法生存；一味地保護是有害的，為了個體的利益制約進化的力量似乎毫無必要）、美國創業者日（創業就是一個高風險、英雄式的活動，對經濟的增長，甚至僅僅是生存來說都至關重要）。
評分：10
外賣戰略：搶佔餐飲的下一個主戰場 - 閆寒
第 1 章終局思維看外賣 - 餐飲行業發展趨勢和外賣發展趨勢分析
收穫：選擇行業和選擇股票的邏輯差不多，我們都要在它價格尚低且處於高速增長時入手。
評分：9
第 1 章終局思維看外賣 - 外賣爆發式增長的原因
收穫：堂食和外賣的依賴元素不同。餐飲行業的發展依賴一個重要元素：飲食文化。外賣行業不光要做飯給你吃，還需要能夠在 “你在家，我在餐廳” 的時候順利溝通訂單和服務需求。
評分：9
 

影視

濕婆神/眾神之神 第1集
感想：中國神話裡有七仙子，印度神話裡有七仙人…
評分：9
 

好歌

Thank U, Next - Ariana Grande
Eastside - Benny Blanco, Halsey, Khalid
Shower - Becky G
Cool Again - Shoffy, Prince Fox
 

新奇

百日編碼挑戰計劃：#100DaysOfCode
每天花一小時在編碼上，持續一百天。
百天挑戰計劃：#100DaysOfX Challenges
一個打卡一百天的地方，建議不要同時接收超過 2-3 個挑戰，包括但不限於：健康、編碼、設計、音樂、閱讀、寫作、烹飪、健身、瑜伽等分類。
CSS 顏色漸變：uiGradients
如題所示，這是一個提供了很多種 CSS 漸變色程式碼的網站。

 

末了

希望你在吸收了這些精華之後，能與我一起，茁壯成長…

下期我們，不見不散！

相關文章