不是射精前,也不在起跑線 成功秘訣只有「刻意練習」

不是射精前,也不在起跑線 成功秘訣只有「刻意練習」
Photo Credit: UnsplashCC0 Public Domain

我們想讓你知道的是

本書以Peak為名,作者並無交代來由,但顯然代表一切突破極限的卓越成就,成功並不止於「靠父幹」或虎媽們希望子女在起跑線就勝出的世俗功名。

成功須苦幹,最少要一萬小時。紅極一時的成功秘笈《異數》(Outliner)引用三位人類技能專家對一群德國小提琴學生的研究,認為天才不止被過譽,更全屬虛構。 任何領域的翹楚必曾磨劍經年,跨越由這個「奇妙數字」把關的木人巷,才能登峰造極。即使「贏在起跑線」天生智商或身型較高,在學術或運動有先天優勢;又或「贏在射精前」出生合時,自小在季節性選拔佔先;若未曾經過長年累月的刻意練習,贏在全人類之前的莫扎特亦不會招來Salieri的妒忌。

peak

主持該經典研究的心理學教授Anders Ericsson今年四月伙伯科學作家Robert Pool出版新書 "Peak: Secrets from the New Science of Expertise" 總結30年學術成果。這位人類技能專家指出,雖然Malcolm Gladwell的「一萬小時定律」過份簡化及引伸他們23年前的研究,成功的確絕無僥倖,神童奇人的天生異稟都只是坊間流傳的神話。反之,人體和大腦擁有無窮的可塑性,即使資質平常亦能在某些領域追求卓越,甚至突破極限。

在教授生涯中最重要的一個實驗,成就中游的大學生Steve Faloon經過教授親自訓練二百多課之後,數字記憶力在兩年間飛躍至82位元,打破當時的紀錄;另一位受訓學生則止於20位元。Steve的成就顯然歸功於他自創的方法,Ericsson稱為 「有目標的練習(purposeful practice)」:有目標地開展計劃,在舒適地帶之外不斷迎難而上,但不過份冒進、監察進度以及想辦法保持動力。

在其後的重覆實驗中,Steve的長跑伙伴Dario得益於隊友分享的心得,在更短時間之內突破人類極限,能記憶100多個數位。比對Steve和Dario的突破,教授洞察到「有目標的練習」若能在一個成型的領域中發揮,學生在己掌握有效訓練技巧的導師的幫助下,更刻意地全身投入,通過測試和比賽等反饋,主動地逐一改善各環節的技能細節,不但能成大器,前途更無可限量。時至今日,已有數十人超越Steve和Dario的水平,能記憶至400多數位,Ericsson認為就是得力於由「有目標的練習」提升至上述形式的「刻意練習(deliberate practice)」。

常人連電話號碼也記不牢,但象棋高手Marc Lang卻能蒙著眼同時和四十多人對弈,只輸兩局。任何優秀技能,由驚人的智力奇蹟,到Jascha Heifetz在琴把上飛舞或Greg Louganis空中多次轉體翻騰等肢體魔法,都依賴大腦發揮思維潛力。在刻意練習的過程,學生既需要不斷創造技能細節的「思維意象(mental presentation)」,同時亦依賴由意象反饋的訊息以持續改善。西方古人以memory palace大法讓大腦牢記大量短期記憶輸入的訊息,就是思維意象技術之一。人的大腦擁有無窮的適應力,能透過刻意練習建構更好的思維意象,從而開拓可能性及改善表現。 因此,思維意象的構建是成功秘笈中的絕招,本書的基石。

「人總想相信生命中有魔法,不一定完全受制於死板沒趣的現實世界。有甚麼比天生異能而毋須苦幹更美妙?」—Anders Ericcson

人間真的沒有天才?學者30年的專注研究告訴我們,先天條件如IQ、體型或出生月份只能提供短暫的起跑優勢,人類殿堂裡的每一位能者,都曾刻意練習一萬小時,沒有例外。

本書以Peak為名,作者並無交代來由,但顯然代表一切突破極限的卓越成就,成功並不止於「靠父幹」或虎媽們希望子女在起跑線就勝出的世俗功名。

本文獲授權轉載,原文刋於《蘋果日報》What we are reading

責任編輯:周雪君
核稿編輯:歐嘉俊


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡