2022年11月30日，是人工智能的一個重要日子，OpenAI在這一天推出了以Transformer模型為主的ChatGPT語言模型。ChatGPT剛一推出就已經震驚世界，因為其自然語言 理解及自然語言生成，都比之前的模型有非常大的進步，不少嘗鮮者都發覺ChatGPT之語言能力，大大超出了大眾的想像。

筆者身在倫敦，讓ChatGPT以十二月冬日倫敦為題，賦詩一首。

Source

筆者兩年前連續寫了兩篇Node.js終結者，分別介紹了Deno 的設計理念，以及Deno比Node.js優勝的地方。 筆者亦在第二篇文中寫了Deno的弱點，主要在於Deno與Node.js龐大的NPM套件庫並不兼容，令現有的Node.js專案難以 轉會。而在11月13日推出的Deno版本1.28，就正正是推出了廣泛之NPM Support! 馬上支援超過130萬的npm套件。

此文是2018年筆者拙文四個原因令Linux更適合作Server的續集，旨在探討一個筆者思考多年，卻未解之難題: 就是為何Linux Desktop永遠都不受普遍用戶歡迎呢？

迄今為止，根據StatCounter的數據，Linux Desktop 在桌面及手提電腦市場只有2.81%的佔有率。

在開始探討前，先講解一點背景資料。筆者由2012年開始在常用電腦只用Linux、沒有Dual Boot也沒有Windows VM備用，到了今天剛好第十個年頭。筆者習慣使用不同Flavour的Ubuntu，在探索的過程中亦曾使用過Fedora、Debian 、Linux Mint等受歡迎的Linux發行版(Distros)。現正在使用的，是Ubuntu 的22.04 LTS版本，也就是長期支援版本(Long Term Support version)。

在這十年使用Linux旅途上，筆者也曾經向不少人推介過使用Linux，迄今為止，筆者成功影響多位人士使用Linux，無獨有偶的是，這些人都是Programmer，至於非Programmer呢？ 筆者成功說服的例子是── 0位 。 筆者在推介時往往這樣說: 「Linux Desktop 美觀，速度快、安全、穩定、方便依個人喜好設置，基本上你希望有的功能都有; 你不知道你需要的功能，安裝一兩個軟件就可以輕鬆解決。」 筆者往往得到的回答卻是: 「真的嗎？，Linux 不是很難用的嗎？要打command 先用到的。」

如果你有類似的疑問，這是既有印象在作怪，在很多人的印象，Linux是這樣的:

Source

筆者不是經常會寫關於React的文章，對上一篇寫關於React的文章已是2019年講關於以React Hooks來編寫函數式部件(Function Component)的文章， 因為在筆者看來，React自2013年推出以來，API 已經非常穩定，近年開發重點主要放在改善效能以及改善開發者體驗(DX, Developer experience)之中。 React 17 更罕見在官網之中，際出一句No new features，殊不知這一切只是為了React 18舖路。

React 18 可說是自React 16.8 推出 React Hooks 兩年多以來最大變動，其中主要變動都離不開兩個字 ⸻ 並發(Concurrency)。 也就是React 18的主要功能，都為了改善React在並發編程方程之效能支援，以及改善開發難度而設的。

"Why are there so many programming languages?" You probably asked this question when you first learned programming. It is downright confusing to see so many programming languages are around, as if they are designed intentionally in this way to confuse newcomers. If you are asking any of the working professional programmers out there, many of them are going to give you contrasting opinions: "Java is dead","Real programmers code in C++", "Ruby is a toy language" or "You are stupid if you don't code in Python".

As explained by Paul Graham's article Beating the Averages, Programming Languages are not merely seen as tools. They also influence the way programmers think about their code. Naturally, most programmers have a strong opinion on the choice of programming language, which unsurprisingly they prefer the one that they use every day.

As a programming mentor, I need to answer this question to my students on a daily basis, preferably in a clear and brief manner. It is surprising to me that there are no good existing infographic that explains how programming languages evolve to become what it looks like now. Therefore, I decided that it is a brilliant idea to create one by ourselves.

不知大家有否親歷過類似的情況：一位講者在侃侃而談，講解其公司/組識未來資訊科技發展的宏圖大計，如何使用人工智能(Artificial Intelligence)、深度學習(Deep Learning)去 提升公司效率，更可大大增加盈利云云。筆者當然亦曾在類似情景之中，每次聽到用深度學習解決問題時，筆者例必竪起耳朵，細聽到底深度學習是用作解決其公司/組識當前遇到的甚麼問題。結果往往令筆者大失所望，很多這些宏圖大計都是流於表面，花了許多時間去討論大方向，討論抽象的策略，卻不見有討論過實際運作方案的Technical Details。

為何會出現這樣的現象呢？筆者認為是因為由於普遍大眾對資訊科技界認識不深，有一些科技用語由於聽起來很厲害，就往往成為含混的重災區。人工智能看起來很科幻，Deep Learning(深度學習)聽起來也很莫測高深，作為一個Pitching的題目也很吸引，所以往往就通通「炒成一碟」，務求提過所有科技Buzzword，演講就可平安過關。

甚麼才算是人工智能​

人工智能其實有悠長歷史，由上世紀50年代開始就已有人工智能的概念，定義也有廣義與狹義之分。這是一張筆者數年前分享的示意圖。

在世上大多數的技術行業，工作之箇中技術都往往是行業機密，因為這關乎商業利益，斷不會隨便公開予大眾。例如著名廚師的食譜、半導體的生產技術、礦產開採技術等等，誠然在今日互聯網世代，這些技術之相關知識很多時亦可在網上窺得端倪，但往往只是在表面輕輕帶過，箇中奧妙，都不足為外人道。在這一點Programmer則與其他行業不太相同，因為有開源軟件(Open source software)之存在。對世上數千萬Programmer 而言，閱讀、使用、參考其他Programmer的工作是很稀鬆平常的事，即使是世界級Programmer所編寫之程式碼，也很容易在Github 等網站閱讀得到，基本上不存在知識壁疊。很大部份日常Programming常用之程式庫(Programming library)，正是以開源的方式，在社群之中共享，在各種技術行業之中，這是一個相當獨特的技術生態。

NPM Wombat Reference

就以筆者最熟悉的Npm packages為例，NPM上2019年就有超過一百萬個packages，每月總下載次數達500億次，因此可以肯定地說，不論一個軟件工程師是如此出類拔萃，使用他人所寫的程式庫乃是不可避免。

既然使用他人所寫之程式如此必要，我們更應有一套行之有效的方法，去判斷一個library是否適合手頭上之專案，否則當專案太依賴該library之後，造成與程式庫間之依賴耦合(Dependency Coupling)，到時想再改回來，就已經恨錯難返了。

既然活用他人之程式這樣重要，那有何原則可以判斷應該如何挑選library呢？筆者在下筆這篇文章之前，都在網絡上搜尋過類似文章，發覺這個重要問題，竟然很少人談及過，筆者就斗膽在此分享一些個人經驗，希望可以幫到正在閱讀的你。

筆者看來，揀選library 可遵從以下五大原則，並將一一以例子詳加解釋:

近一兩年由於政治局勢、肺炎疫情，大家閒賦在家，不知是否因為在家工作的緣故，很多人都乘勢進修學習新技能。筆者認為，學習新技能，當然要以個人興趣為最大前題，因為學習源自於興趣，人只有在學習自己最有興趣的事情上，才會有動力去不斷改善。而最常提起的，就是編程(Programming)的技能，連香港知名求職網站Jobsdb亦撰文指出IT工作平均薪酬加幅跑贏大市。有一些可能想移民外地的朋友，發覺IT技能(尤其是軟件開發、數據科學等技能)似乎不只在香港渴市，在世界各地亦有類似渴市的情況，也就是對擁有編程技能的人而言，移民世界各地，都比較容易找到工作，這對有意移居外地的人而言，確是一個喜訊。

Source

筆者由開始在Coding Bootcamp一行創業以來，固然在教學上得到不少滿足感，始終這一行是為了幫助同學轉行而存在的，因此當同學成功找到一份軟件工程師的工作，滿足感的確是無與倫比。 然而，在這趟旅程之上，常常都收到不少質疑，絕大多數更是來自於業界同行。 因此，本文就集中回應一下，解答一下大家的疑惑。

上回講到三個Deno比Node.js優勝的地方，今次我們將會繼續介紹Deno這個初生之犢的優勢!

Node.js 使用NPM VS Deno 無中央資料庫​

Node.js的模組(Module)，主要是存在NPM之上，也許不少開發者不知道，其實NPM是一間公司，專為開發者提供存放私人模組(private module)的服務。而2020年3月時Github也收購了NPM，也就是代表現行大多數的Node.js 模組，都在Microsoft的控制之下。這無疑代表NPM本質也是一個中央資料庫，所以當間中NPM因技術問題而無法供開發者下載模組的話，Node.js開發者就會哀鴻遍野，因為NPM就是一個Single point of failure(單點故障)。

有編程經驗的人，都一定會聽聞過Node.js，Node.js基于Chrome的V8引擎開發，本身能夠運行JavaScript，在前端開發(Frontend Development)、後端開發(Backend Development)、Android及iOS開發(Android & iOS Development)，都有Node.js的蹤影，更帶起全JS開發的潮流，也就是大家常常在Youtube上看到的MEAN Stack(Mongodb,Express,Angular,Node.js)，也是以Node.js為中心發展起來的。

然而，Node.js的作者Ryan Dahl卻在2018年六月JsConf EU之上，發表了一個題目為10個Node.js的設計錯誤的短講。出乎意料的是: 原來Ryan2012年後已離開Node.js開發工作，原因是他的興趣主要在伺服器編程(Server Programming)之上，所以轉投了Golang的懷抱，所以已一段長時間沒有用Node.js作開發工作。而更重要的是，他2012年離開時，認為Node.js作為一個後端運行JavaScript程式，已是大功告成。他萬萬沒有想過Node.js會變成今天般無所不在(ubiquitous)，因此很多設計上沒有周詳考慮，現在已經是Too late to change, Too big to fail。

螢幕截圖自影片10 things I regret about Node.js - Ryan Dahl

有一個非常常見的問題，筆者不論在日常教學工作，或是宣傳活動之中，都經常被問到。這個問題就是：「我的數學不好，可以學習寫程式嗎？」一開始筆者都不以為然，以為只是大眾對程式設計師眾多誤解中的其中一個，後來被多問幾次後，發覺為數不少的行外人，都認為寫程式的人，數學必然非常優異：反之，數學不濟的人，則絕無可能成為軟件工程師。

這個印象乍看之下，好像有點道理，平常遇見的軟件工程師之中，很多都是中學時理科班出身，大學學位即使不是電腦科學(Computer Science)，也會是其他工程系(Engineering)，或是其他純科學系(Pure Science)，甚少會遇見出身文學(Art)相關學系的工程師。這不是正正就是證明了這個數學好，寫程式才會好的現象嗎？ 筆者我本身也是一個類似例子，我本身在大學是主修物理、副修電腦科學，物理系本身是數學系以外最多數學計算的學系，這看來也與這個現象完全符合啊！

但這個看法，其實犯了一個基本的統計學謬誤，就是相關不蘊含因果關係(Correlation does not imply causation)，也就是即使觀察到很多軟件工程師數學不錯，我們也不能由此推論出「一個人先要數學好，寫程式才會好」這個因果關係，更不能推論出「一個人數學不好，寫程式就不會好」。為甚麼呢？因為數學好與寫程式好，兩者可以有個共同原因(Common Cause)，可以是純粹巧合(Coincidence)，兩者相關不代表有因果關係，更何況做數學與寫程式每天所做的事更是截然不同。

如果你統計每年美國在泳池溺水的人，與影星尼古拉斯．基治(Nicolas Cage)的作品並排的話，你會發覺有驚人的相關，難道尼古拉斯．基治拍愈多作品，就會導致更多人溺水嗎？

2018年年底，微軟公司首次在近年來超越蘋果公司，成為全球市值最高的公司，價值超過8000億美元。時間快轉至筆者動筆寫這篇文章的今天(2020年6月)，微軟依然是全球市值最高，市值高達1兆4000億美元，實在只能用天文數字來形容。

如果你不是從事資訊科技行業，你可能覺得一頭霧水，Microsoft近年在普通消費者眼中好像乏善足陳: Windows 10 變成每半年小更新旳操作系統，Windows 11 似乎永遠不會面世；Microsoft Office 也沒有大更動，基本上打開Microsoft Office 2019，整體感覺與Microsoft Office 2016分別不大，縱使不是專業投資者都會知道，科技公司的價值取決於創新，那Microsoft的創新在那裏呢？

Source

不知不覺間，筆者從事編程教育已踏入第三個半的年頭:在這段時間之中，見證了二百多位同學由編程初哥開始，經過十多星期的努力、挫折、合作，最終成為專業的程式設計師。當然，在這段時間之中，筆者亦見證了一些學寫Code失敗的情況，固然每個人的天份才能有所不同，有些同學的思考方式天生就與編程較為契合，有些同學則要花九牛二虎之力，才能成為一個專業的程式設計師。

因此，筆者由數年的觀察所得，發現學寫Code失敗的同學皆有一些共通點，因此希望在此分享，如果你有意踏入資訊科技一行，或是想報讀我們Tecky的課程，不妨留意一下自己編程有否這些自己不察覺的問題啊!

四大原因​

筆者在芸芸眾多共通點中，歸納出以下四大原因

先前三篇關於SQL的文章，分別講述了SQL的歷史、功能、誤解，這一篇筆者將會大膽預測，預測SQL的未來發展的可能方向。到底SQL在未來會是比現在更廣泛使用，成為每一個數據分析師的必備工具?還是被另外一種語言所取代？還是關聯式資料庫不會再受歡迎呢？

曾經學習軟件開發的朋友，都應該在框架中，學過如何從資料庫讀取資料，而十之八九學到的方法，就是使用框架中的ORM程式庫。例如Ruby on Rails 內置了Active Record、Django內置了Django ORM、 Spring Boot則通常與 Hibernate一齊使用，C#則有一套本身的.Net Entity Framework。基本上通用的程式開發框架，都必然有自己的ORM程式庫。

ORM是甚麼呢？ORM全名是Object-Relational Mapping，中文是物件關係對映。顧名思義，就是將關聯式資料庫(Relational Database Management System)的資料，映射到物件(Object)之中，反之亦然。由於不少軟件工程師習慣使用物件導向程式語言(OO Languages)，對物件導向概念如接口 (interface)、繼承(inheritance)等都瞭如指掌，而對SQL的關聯式用法卻不甚理解。本身關聯式資料庫(Relational Database)與物件導向的編程，先天 就有不少不契合的地方，電腦科學有一個專有名詞去形容關聯式資料庫與物件導向設計之間之不協調，也就是Object-relational impedance mismatch。為數不少的物件導向概念例如接口、繼承等，在資料庫的世界，完全沒有相對應的概念。 ORM的存在意義，就是為了撫平兩者中間的不協調，將資料庫中的資料，映射到記憶體的物件之中，而無需軟件工程師再煩惱。

上一篇文章講到了SQL的發展歷史，也提到了NoSQL的出現曾經為SQL資料庫帶來不少挑戰。正是這些挑戰，令現今SQL內置功能愈來愈豐富。近年SQL資料庫功能上大有進展，其中PostgreSQL功能日臻完善，運用PostgreSQL，連帶不少大家本以為只能運用NoSQL解決的問題，也可以輕鬆解決。 因此，本文主要會以PostgreSQL作舉例，當然以下很多功能在其他SQL實作如Oracle、SQL Server 、MySQL等都已逐漸支援，因此可看成是普遍SQL在不久將來廣泛支援的功能。

由本篇開始，接連四篇都是與SQL有關的文章，會想寫SQL的原因，是因為SQL在現今軟件開發及數據科學佔有舉足輕重之地位，卻總是在背後默默無名，從未見得到像其他新興技術之關注，有見及此，筆者決定介紹SQL之特點，順便破除一些對使用SQL上常有的誤解。

-- 一條SQL綜合本文目的!
SELECT * FROM sql_knowledge AS knowledge

    INNER JOIN public_understanding AS understanding
        ON knowledge.id = understanding.sql_knowledge_id

    INNER JOIN my_understanding as my_understanding
        ON knowledge.id = my_understanding.knowledge_id

    WHERE knowledge.concept !=  understanding.concept
        AND knowledge.concept = my_understanding.concept

    ORDER BY understanding.created_at;

筆者在上年十一月React Hooks剛發佈時，就寫過關於React Hooks的應用，如何簡化開發React 應用時要寫的程式碼，之後又介紹了Redux-React-Hooks這個筆者認為有不錯前途的組件，雖然隨著React-Redux加入了React Hooks的應用，現在寫React + Redux應用，已無需再寫長長的mapStateToProps及mapDispatchToProps。

但有一個不解之謎，就是為何只要加入React Hooks，要寫的程式碼就會大大簡化呢？縱使軟件工程師都知道框架及程式庫可以減少程式碼之複雜性(Complexity)，但大家都明白這個世界是沒有免費午餐(No Free Lunch)的道理，那使用 React Hooks又有何代價呢？

編程老手與編程新手在工作時，不論效率、思維方向、甚至打字速度都截然不同，不過在學習編程的道路上，有一個方面常被忽略，就是編程手勢(Coding Practice)，有豐富實戰經驗的工程師，通常培養了良好的編程手勢，工作時，自然錯誤較少，也因為除錯得少，省略了不少寶貴的時間，整體結果也蔚然不同。

也許正是編程初學者的你會說:「我經驗尚淺，就算現在不專誠培養編程手勢，以後還有很多時間可以改善啊!」 其實Coding Practice這個詞語正正解釋了這個想法的荒謬: 不妨細想，每一種運動，都必要學習正確的姿勢:要學籃球，運球與射籃的技術不可不學;學打網球，正反手握拍也只是網球ABC。不學正確姿勢，就會將錯誤累積，一開頭可能還好，及至後來，要將錯誤改正過來，就會難過登天。

一個經典例子，大家知道打字的正確手勢嗎？打字的正確手勢很奇怪，要用到平常不多用的手指，例如尾指或無名指，如果從未學過正確姿勢的人，可以肯定，幾乎百分百是以錯誤手勢打字。

Source

不過人是很奇怪的生物，不論手勢多麼奇怪，久而久之就自然習慣。就算以「螳螂拳」打字的人，還是打得一樣痛快。

Source