上一篇文章講到了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。不學正確姿勢，就會將錯誤累積，一開頭可能還好，及至後來，要將錯誤改正過來，就會難過登天。
一個經典例子，大家知道打字的正確手勢嗎？打字的正確手勢很奇怪，要用到平常不多用的手指，例如尾指或無名指，如果從未學過正確姿勢的人，可以肯定，幾乎百分百是以錯誤手勢打字。
不過人是很奇怪的生物，不論手勢多麼奇怪，久而久之就自然習慣。就算以「螳螂拳」打字的人，還是打得一樣痛快。
科技世界，尤其是資訊科技世界，普遍有一種喜新厭舊的傾向，對運用時日漸久的技術，往往會衍生出一種厭倦之感，鮮明例子就如常用的程式語言如Java、PHP，被認為不再sexy，不及新穎的Kotlin、Swift吸引。曾經風頭一時無兩的3D打印，近年亦比以往的熱潮時冷卻得多。Bitcoin熱潮，在加密貨幣價格大上大落之下，也比起一兩年前減退不少。乍看之下，好像新科技都遵從著相近之發展軌跡，難道這是每種新科技發展都必須經歷嗎？
據筆者所能找到最早的資料，第一個有關這種規律的觀察，是於1995年由一間名為Gartner的顧問公司所做，研究員發現大多數新科技都會經歷五個不同階段:
以一幅圖綜合五個時期就如下圖:
根據一項網上調查，發現超過7成用戶有超過10個網上帳戶，而大多數情況下都會於不同的帳戶重用密碼。更有3成用戶表示自己實在有太多帳戶，連自己也不清楚有多少個。縱然保安專家常常建議用戶應該為每一個帳戶設下不同的密碼，執行上卻是不切實際:一個正常千禧年代互聯網用戶，動輒就有四五十個帳戶，要以人腦記住四五十個不同帳戶的電郵已是Mission Impossible ，更何況是密碼呢？
這項調查揭示了一個嚴重的問題: 互聯網無遠弗屆，網上應用如Google、WhatsApp為人類生活方便良多，但要安全使用這些應用，就必須有一個有效的方法管理密碼，但普遍用戶對如何有效管理密碼，其實是一籌莫展。 一個良好的密碼管理(Password Management)策略，應該遵從以下幾個原則:
人類天生就會覺得自己與別不同，一句有趣句子就將這個世上普遍的錯覺綜合起來。
Everyone thinks they are unique until they have to create a username
事實也確實如此，自己名字的username總是被人捷足先登，因此很多人的username往往要加上出生日期才可以成功注冊。密碼也是同理， 人們常常以為自己的密碼很特別，不會有其他人使用，研究卻發現，很多密碼經常被世界各地的人重用:
Password系列(Password,password1)，也就是password的變種、I love you系列(不同語言的i love you變種)sunshine,happy,football)1234567,24680)98475294,00831248233)!@#$%^&,qwerty)Pa55w0rd,/\cc3$$)。不幸的是，以上的密碼通通都不安全，即使看起來不錯的置換系列，強度也不足夠，因為置換規則s -> 5、o -> 0都是早已廣為人知，也就代表駭客的密碼破解工具，早已包含此類規則。
著名的網絡漫畫xkcd就曾以password strength為題，解釋大眾對密碼強度的誤解。
如果你想學寫程式，在網上搜尋一下，不難找到不少「輕鬆學習XXX」、「YY天輕鬆學會Python」的教材及影片;去電腦書店逛一圈，很容易就可以找到「七天學會Java」等的書籍，這些教材其實都在推廣一個信念，也就是: 學寫程式很簡單，人人都可以學會。 筆者對此信念後半部深表認同，但是對前半部所謂「學寫程式很簡單」，卻真是不敢苟同。
筆者深信No pain, no gain的哲學，世上大部份有價值的事物，都必須努力才能達到，如果真是可以「YY天輕鬆學會編程」，那豈不是明天所有軟件工程師都要失業？學寫程式，就像練馬拉松一樣，人人皆可做到，只是必須要付出努力。將一樣要付出努力才能達成的事物，簡化成「XX天就可以輕鬆學成」，會令初學者初遇困難時，誤以為自己無甚天份，繼而失去學習動機。反而一早說明學習時會遇上的困難，才能為初學者提供正確的心理準備。就像你要去挑戰一座高峰，你找了一個曾經登上該座高峰的朋友請教，那朋友卻說:「很簡單的，不用訓練，人人也可以上去」，這可不是安慰說話，而是害人不淺。
近年數據科學及人工智能發展迅速，大眾開始對數據(Data)有很大興趣，甚至有「數據是未來的石油」(Data is the new oil)的講法。很容易會聽到如大數據(Big Data)、數據導向決策(Data Driven Decision)、數據化組織(Data Organization)等等與數據相關的詞語，其中重點，不外乎都是如何運用已儲存的數據，通過數據處理及數據分析，從而得出結論，幫助決策。筆者今日希望談談的，是另一個技術用語，與大數據一詞經常一齊出現，就是非結構化數據(Unstructured Data)。
筆者經常都强調軟件工程師有高下之分，不論技術或是解難能力都可以隨時日改善，亦曾大力鞭撻專家級初學者的無知，對軟件開發造成破壞。 初出茅蘆的軟件工程師及編程初學者想要改善自己技術，在茁壯成長的話，對自己技術層面有一個準確評價是至關重要，以免墮入「識少少，扮代表」的認知偏差。
開始之前，先講講本文不是關於甚麼:
本文不是談論軟件工程師的職場晉升道路，因為時至今日，不少公司還是傾向將編程作為入門職位看待，軟件工程師晉升後，就會改為以專案管理工作為主， 而綜觀現實，專案管理與編程本身大相逕庭，所需能力也不盡相同，因此筆者認為以職位討論軟件工程師成長，沒有很大的參考價值。
不諳編程或是編程初學者常常會有一個印象：就是資訊科技發展很快，一種最新技術可能數年又會變得「不再流行」，又時時會有一些新穎的科技流行語(Buzzword)，早幾年是雲端、大數據，過了一會又是數據科學、人工智能、現在又出現了所謂的區塊鏈技術。編程初學者，在沒有先前經驗的情況下，往往無所適從，不知如何是好。
要理解科技變遷的原因，最好的方法莫過於觀察科技一直以來的發展歷史：蒸汽機這個名詞，聽起上來非常十九世紀，蒸汽火車是只有老一輩才曾經坐過的交通工具，十九世紀英國發明家占士．瓦特(James Watt)改良原有蒸汽機，正式開啟工業革命的時代。蒸汽機在工業時代不可或缺，當時出現了蒸汽火車、蒸汽船、甚至蒸汽推動的汽車。二十世紀初，內燃機(Internal Combustion Engine)的發明，使傳統的蒸汽機，慢慢退出歷史舞台，今時今日的汽車及輪船，皆是由內燃機所推動的。
有留意本站博客的朋友，可能看過有一種病叫Excel病這篇文章，都知道筆者絕不贊同亂用Excel作程式用途，因為Excel本身作為試算表，最適合作財務計算，或以數據生成圖表等功用。作為程式用途，則困難重重，舉一簡單例子，要在Javascript，顯示出1至10000的所有數字，是一個編程ABC的問題，程式初哥亦能輕易解決。
for (let i = 0; i <= 10000; i++) {
console.log(i);
}
要在Excel顯示出一萬個數字，則別無他法，需要一萬行去表達。
2019-09-03 筆者按: 現時最常用之React-Redux程式庫已加入React Hooks功能，因此讀者可以詳讀 本篇後續文章React Hooks(四)理解React Hooks在Redux應用上之最新發展。
React Hooks在React16.8.0的版本正式成為React的正式功能。正如前兩篇所言，React Hooks簡化了寫複雜代碼的難度，亦令React的函數式部件(Functional Components)亦能使用state及props，可是傳說中React Hooks將會取代Redux呢？卻一直都是只聞樓梯響。這篇文章就會介紹一個筆者認為頗有前景的組件，就是在Github中的facebookincubator中的redux-react-hook。
今次要介紹的，是一個非常常見之現象，不論你 是學寫程式、學做甜品、學寫文章，又或是練習球技、體能訓練等，都會經常窺見其身影。 想像一下：你的朋友問你：「你的駕駛技巧好嗎？比較起其他司機來說如何？」如果你本身有駕駛執照，但是不常常駕車，大概你會回答：「中規中矩吧，平均水平」；經常駕駛的人，因為經驗豐富，會覺得自己是中上甚至良好之水平。然而，這個想法人人都有，卻與現實完全相悖：因為任何羣體之中，必然有一半個體在中位數(Median)以下，而一項經典的調查發現，八成的司機都認為自己的駕駛水平在平均之上，這明顯代表在駕駛技術的世界上，大部份人都有自視過高的問題，也代表其實大多數司機，無法準確判斷駕駛技術之高下。
本站文章以中文寫作，本來為方便香港讀者，在芸芸的英文文章之中，有一個另類選擇。出乎意料之外，我們近日發現多了不少台灣讀者閱讀本站文章，細想一下，大概是因為 筆者寫文好用中文科技詞𢑥，如型別推論(Type Inference)、機器學習(Machine Learning)、超文本傳輸協定(HTTP)等，台灣的軟件工程師搜尋相關的詞語，自然容易找尋到本站。然而，中文的科技詞𢑥，對不少香港軟件工程師而言，其實並不常用，那是甚麼驅使筆者會堅持使用這些中文科技詞𢑥呢？是愛？還是責任呢？
首先由歷史背景開始談起，香港作為曾經英國一百五十年的殖民地，英文一直處於官方語言的地位，在學校英文是必然主科，由幼稚園就開始就需要學習英文，因此港人習慣了言談間中英夾雜， 所謂「同朕check下」，正是無綫電視藝員陳豪飾演崇禎皇帝時，衝口而出一句「同朕check下」，以正統書面語而言，即是「幫朕檢查一下」。崇禎皇帝口出英語，眾多的電視台工作人員，竟無人發覺，可見港人中英夾雜，早已是生活的一部份。
隨著Flutter受到開發者的重視，Google於2011年推出的Dart又重新進入大家關注的視野之內，不過除了Flutter以外，其實Google的開發者早在2016年也推出過Angular Dart，讓開發者以Dart開發網站應用，不過由於Angular Dart對比TypeScript版Angular文本長期不足，因此沒有引起太多關注。Google推出Flutter，可以說為大家對Dart的信心注入了一劑强心針，大家又重新開始關注這個已有８年歷史的程式語言。
本文想介紹的是，就是到底Dart有何特色？與JavaScript比較， 又有何優劣？由於TypeScript開始於前端日漸盛行，我們亦可以趁機比較一下三種語言的異同。
