Danny AJ

  1. 全球有愈來愈多的公司採用容器化或是 Kubernetes來管理應用程式，其中以大型企業有更為明顯的使用趨勢 2. 如同 Linux 一樣， Kubernetes 正在轉變為一個如同基本概念般的存在，愈來愈多的公司使用託管平台 3. CNCF 同時也觀察到愈來愈多組織逐漸導入各式各樣的 Cloud Native 專案來處理各種問題，譬如監控維運等 CNCF 自己的報告則是有 79% 的使用者都是使用經過認證的 Kubernetes 管理平台，其中 EKS 39%, AKS 23% 以及 Azure Engine (17%) atadog 的 2021 Serverless 顯示 Lambda 的功能使用次數相較於過去兩年來提升了 3.5 被，而這些使用量中以 Amazon Lambda 為大宗，此外 Azure Functions 以及 Google Cloud Functions 也都有明顯的成長。 參考連結: https://www.cncf.io/reports/cncf-annual-survey-2021/ 參考連結: 矽谷牛的耕田筆記

  Database — 八個 Index( 索引 ) 無法生效的 SQL 寫法 相信許多讀者一定知道 Index，也就是索引，對於資料庫的重要性，可以說一個資料庫執行效能的第一道關卡，就是將索引設定恰當。 不過相信很多朋友知道要使用索引後，執行的 SQL 語句如果包含被設定索引的欄位，則速度會變快。但可能不太清楚在什麼情況下，速度不會變快 因此，今天想跟各位朋友介紹，八個常見，但會導致 index 無法作用的 SQL 寫法，希望能幫助各位更恰當的編寫 SQL 語句: 1. 使用 NOT 、!=、not in、not like 等負向判斷詞 SELECT * FROM users WHERE name != 'John'; 2. 使用函數語句包裝被索引的欄位 SELECT * FROM users WHERE DATE(created_at) = '2022-02-28'; 這邊的範例使用 DATE() 函數，去轉換 created_at 這個欄位，因而導致無法透過原始資料，去觸發索引機制。 這邊要幫大家建構一個概念，索引會失效很重要的核心問題就是，『不要對欄位動手腳』，後續會用其他例子幫大家更釐清會有什麼情境。 3. 資料類型錯誤 SELECT * FROM users WHERE age = 30; 這邊假設 age 設定 varchar ，也就是字串型別，則 SQL 在判斷時，會『偷偷的』去做類別轉換，也就是對欄位動手腳，就會導致索引失效 4. 使用 『 %XXX% 』或是 『 %XXX 』 SELECT * FROM users WHERE name like '%john%'; 失效的原因，是因為索引運算機制中，有部分會從字元最左開始匹配，如果用範例的搜尋模式，『 最左 』的字元會無法匹配，導致失效。 5. 使用 Null SELECT * FROM users WHERE name IS NULL; Null 值對於 Index 資料管理來說是比較迥異的存在，所以通常預設是不支援的，但在部份資料庫軟體中，可以另外設定讓 Null 被納入索引中 6. 錯誤的使用 or SELECT * FROM users WHERE indexed_column > 5 or unindexed_column ...

  A Kubernetes Documentary Shares Google’s Open Source Story It’s one of the great open source success stories — and it’s been condensed into a brief oral history. https://thenewstack.io/a-kubernetes-documentary-shares-googles-open-source-story/

  連結: https://medium.com/.../unsuccessful-experience-of... 作者團隊於 2019 年要開發一個全新的 API 應用程式，當時部門的 IT 團隊計畫要將既有的 VM-Based 應用程式給轉換到 Container-Based，最後團隊使用了 RedHat 的系統，並且使用 OpenShift 做為容器管理平台。 從結果來看，該專案從 2020/05 一路到 2021/05 花了整整一年也沒有順利的將應用程式轉移到 OpenShift 中，其中的一些重點有 1. 初期建設時 RedHat 有展示過如何使用 Java 基於 Fuse 開發應用程式，但是作者團隊全部都是 .Net 的經驗，因此團隊花了很多時間來學習如何使用 Fuse 2. 2020/06 時因為團隊的進度緩慢，所以 IT 團隊尋找外部的軟體顧問，尋求如何將 .Net 從 VM 轉移到 OpenShift 3. 團隊內的開發者都不擅長學習新技術，對於學習新技術這一塊非常不行。 4. 外部團隊幫忙建置了 CI/CD 系統，然後團隊內從 2020/09 開始進行程式開發與轉移，可惜直到 2021/05 依然沒有半個產品成功的用 OpenShift 作為正式生產環境 5. 與此同時，外部團隊也撰寫了幾個 .NET 示範應用程式來展示容器化的注意事項，然而團隊本身對 Container 的知識非常薄落，所以團隊人員沒有辦法參考這些範例程式來改善自己開發過程 最後團隊內又針對不同團隊給予不同的想法 1. Application Team 2. Server Team 3. Network Team 4. IT Management Team 譬如 Application Team 的開發人員都只滿足自身的技能，而且拒絕學習新技能，誇張的是一年過後團隊內的人也沒有辦法撰寫 dockerfile 或是使用 docker build. 後續還有一些針對不同團隊的想法與總體建議，整體來說非常真實，一個血淋淋的轉換案例。 文章出自於矽谷牛的耕田筆記, 分享給大家

  視覺化系統內 iptables 規則 連結: https://github.com/Nudin/iptable_vis 主要會透過 awk 來解析系統中的規則並且產生特定輸出，接者使用別的軟體將該輸出給轉換成圖檔

  Elon Musk: SpaceX, Mars, Tesla Autopilot, Self-Driving, Robotics, and AI | Lex Fridman Podcast https://www.youtube.com/watch?v=DxREm3s1scA

 抖音創始人張一鳴：10年面試2000人，我發現混得好的人，全都有這5個特質 張一鳴：10年面試2000人，我發現混得好的人，全都有這5個特質 這篇文章是整理自字節跳動創始人張一鳴給研發&產品部門應屆畢業生的寄語。今天推薦給你，相信一定會對你有所啟發。 為何畢業多年後 原本水平差不多的同學 都拉開了差距？ 大家好。 各位都非常年輕，我今天來的時候挺有壓力。因為我畢業快11年了，看到你們，真是覺得“長江後浪推前浪”。 我去年參加了武漢的校招，感覺新一代年輕人的素質確實都非常好。我昨天就在想，今天應該跟大家分享什麼。想了想，先把題目擬出來，把喬布斯的“Stay hungry, Stay foolish”，改成“Stay hungry, Stay young”。 我想跟大家分享一下我自己畢業後的工作經歷和體會。另外，我作為面試官，過去10年裡，可能面試過小2000個年輕人。 有的和我在一家公司，有的去了別家公司，他們發展差別其實非常大。從算法層面上講，我們把這叫做“正例”和“負例”。我想分享一下：為什麼“正例”和“負例”發展差別這麼大？ 什麼是“Stay hungry, Stay young”？ “Stay hungry”，大家都知道，就是好奇心、求知若渴、上進心。但為什麼要說“Stay young”？ 我覺得年輕人有很多優點：做事不設條條框框，沒有太多自我要維護，經常能打破常規，非常努力、不妥協、不圓滑世故。 10年過去了，有的年輕人，依然保持著這些很好的特質。我覺得這就算“Stay young”。 “Stay young”的人基本沒有到天花板，一直保持著自我的成長。相反，很多人畢業後提高了技能，但到一個天花板後，就不再成長了。 我先分享我的個人經歷 我是如何在畢業第2年就成了 管理四五十人團隊的主管？ 2005年，我從南開大學畢業，加入了一家公司叫酷訊。我是最早期加入的員工之一，一開始只是一個普通工程師，但在工作第 2 年，我在公司管了四五十個人的團隊，負責所有後端技術，同時也負責很多產品相關的工作。 有人問我：為什麼你在第一份工作就成長很快？是不是你在那個公司表現特別突出？ 其實不是。當時公司招聘標準也很高。跟我同期入職的，我記得就有兩個清華計算機系的博士。 那我是不是技術最好？是不是最有經驗？我發現都不是。後來我想了想，當時自己有哪些特質。 1.我...