【從學員練習影片觀察到一個關於 TDD 的有趣現象】

極速開發的課後練習作業，雖說重點是放在極速開發要學習的技巧與刻意練習的模型，但開發的方式、順序也是刻意安排成類似 TDD 的進行方式，來讓生產力最大化（TDD 本來就是幫助開發的，不是幫助測試的）

我從2位第一次上我課的學員（當然就是 #極速開發，代表他們沒上過#單元測試 跟 #TDD與持續重構），雖然他們是照著示範影片、上課教學用 TDD 在寫整個 tennis 的過程，但從他們執行測試的時間點就可以發現：

「他是用測試來驗證 production code 的正確性」，即使他先寫了測試，也不先執行，沒有看到紅燈，每次都等到 production code 寫完了，應該要綠燈時，才執行測試。

而其他上過 TDD 課的同學 ，或是上過單元測試的同學，知道測試是用來描述情境，如果現在「加入的這個情境是新的需求或需求異動，代表目前 production code 還不支援這個情境，執行測試跑出的紅燈，就是等等 production code 要完成的 #目標」

test-frist 從來都只是 TDD 其中一個小小的衍生產物，而不是全貌。TDD, 測試驅動開發 從來都是一種開發方法，而不是測試方法。

總有些人老愛把 TDD 拿來跟測試相提並論，就總是喜歡把 test-first 當作靶子打，覺得違反人性跟直覺，覺得先寫測試在很多情況下是浪費時間或是不 work，可能拿來跟一堆測試的方法論相提並論，或總是只拿回歸測試的效益來當作 TDD 的整體。抑或是陷入 isolation unit test 與 integration test (其實就是非 isolation 等級、有實際依賴的自動測試）之爭。

```
註：TDD 事實上是可以不是單元測試等級的。
```

要比較正確看待 TDD 的角度，首先要知道它是幫助開發的、它是一種開發方式（當然不是唯一一種，甚至也不會是最好的一種，因為根本沒有最好，只有剛好）

接著要了解 TDD 可能用 IPO 模型還比較貼切，input-process-output，在你開發任何功能之前，你總要先想過這件事。而先想這件事，才是 TDD 的最基本精神。

接著是怎麼把你想好的東西，變成可執行的 spec，我們只是用測試程式來「描述」你腦袋中的「IPO模型」，把 process 的過程當作一個黑箱子。

而這個 IPO 模型在結合成「使用情境」，就會帶來「高易用性 API 的好處」，只有在一開始就先想好怎麼給別人用，最後才會好用。所謂的一開始想好，指的不是預先設計一堆 class，而是 input/output 想清楚期待（一般會結合實例化需求，搭配 Given/When/Then 的 gherkin style 來把前置條件、資料、前提想好，當發生什麼事，應該是怎樣的結果），然後描述它。在紅燈定義清楚目標，綠燈完成 input/output 關係且沒弄壞前面的所有情境後，來針對 process 進行重構（事實上 Kent Beck 的 TDD by Example 更多是用 refactor 來 #完成 process。

```
註：所謂的 output 不一定只有回傳值，包含外部依賴狀態、資料的改變，甚至顆粒度小一點，針對物件導向設計的話，物件內部狀態的改變也算，只是物件內部狀態改變，驗證點要嘛是拿得到內部狀態，要嘛就是要驗證物件哪個行為會因這個內部狀態而有所不同。
```

## 戰 TDD 之前該先做好的功課
要戰 TDD，是不是至少要把 Kent Beck 的 TDD by Example 看完？

要戰 TDD，請不要拿它跟測試方法論來比，那只是一下就被人看破手腳。因為它是個開發方法論。

要戰 TDD，請不要把它的好處只限縮在跟回歸測試、自動測試的比較，因為那只是它的衍生好處，當你試過在白海報紙上 TDD 就懂，TDD 是在釐清你的思緒的同時，又可以以終為始，確保你在 production code 的每一個動作都是為了滿足某個期待的情境。

要戰 TDD，請不要去把 單元測試、整合測試捲進來，那是測試的顆粒度，那是測試的分類，TDD 從來都不是只能限於單元測試。

要戰 TDD，請不要在那邊戰他是 bottom-up ，是直接從程式/class 的角度出發，事實上 TDD 既不是 bottom-up, 也不是 top-down, （書裡面就有講這件事咩），實務上的 TDD 結合倫敦派(GOOS)跟芝加哥派(Classic TDD)，會更像 Outside-In 的進行方式，先定義好驗收情境，接著從最外部（也就是使用者看得到的部份）一路把依賴往另一邊的系統邊界推，直到推到系統以外的依賴資源（persistence 或 external API/service）

```
註： ATDD by Example 中 ATDD by Example, Kent Beck 寫的序最後的一段話。

Kent Beck:
「就像我曾說過的，TDD的一個缺點是，它可能會退化為一種用來滿足開發人員需求的編程技能。某些開發人員從更廣泛的角度來看待TDD，輕易在他們測試的不同抽象級別間跳躍。然而在ATDD中不存在歧義，這是一種加強與非編程人員溝通的技術。我們之間良好的協作關係，以及作為這種關係基礎的溝通，能夠使軟件開發更有效率。採用ATDD是向著溝通更清晰這個目標邁進的重要一步，而此書是一本全面又平易近人的入門讀物。」
```

要戰 TDD，請不要只關注在 test-frist，因為他只是用 test 來幫助你 think-first，不要邊寫邊想。然後不要過份依賴或相信你腦袋的能力，把你想好的東西具體化出來，最好可以被直接執行，最好除了你以外每個人執行出來的結果都會一樣（不管是對的，還是錯的）

要戰 TDD， 請不要把論點放在見樹不見林，如果你有看 TDD by Example 的 Part 1, Part 2 那兩個加起來共 24 個章節，就知道一開始就得把當下想到的全貌紀錄在一個「紙本」的 backlog (所謂的紙本，只是要講這並不依賴於任何工具）

而這個需求輪廓的全貌，會隨著你逐漸完成一部分一部分的情境，設計逐漸浮現後，而隨時跟著增減調整。

但不代表 TDD 就是先想到一個測試案例，就直接先幹下去了，那根本是亂搞。

以上這些，都還不是在列 TDD 的好處，而是針對那些從來沒搞懂 TDD 但又愛戰 TDD 的人一點提醒，你戰的很可能是「你誤解的 TDD」。

TDD 還有許多實務上的用途，列上我在譯者序中的一小段：

>> 測試驅動開發（Test-Driven Development, TDD）！一種以測試為開發輔助、以測試來描述需求情境、以測試來當作目標、以測試來表達期望、以測試來驗證疑問、以測試來實驗學習、以測試來溝通協作、以測試來協助設計高易用性 API 的「開發方法」。

譯者序有開放給大家看，請見：https://tdd.best/book/tdd-by-example/

拜託，要戰之前去看一下祖師爺 Kent Beck 對 TDD 的原始見解：https://www.tenlong.com.tw/products/9789864345618?list_name=srh

如果你想正確的使用 TDD 來幫助你在實務上產生許多的價值，帶來許多的好處，尤其是需求釐清、持續重構、小步快跑的部份，最好理解的培訓課就在這：https://tdd.best/courses/classic-tdd-by-example-video-training/

最後我想講一段話：
TDD 從來都不該被導入到團隊中，但它是一種很好的自我鍛鍊與學習的方式，也是一種能用很低的成本來帶來很多好處的開發方法（見下方註腳），然而它也不是適用所有的情況，但它可以讓『完美』變成一個動詞，而非不變的形容詞。

```
註：
Kent Beck 在 DHH 靠腰：《TDD is Dead》 之後寫的一篇反串文：《RIP TDD》
https://www.facebook.com/notes/1063422864115918/

我幾年前的簡易翻譯，通常也是 TDD 可以幫助你解決的問題，如下：

- Over-engineering （過度設計）
- API feedback （改善API的設計與可用性）
- Logic errors （想的跟寫的不一樣，寫的跟需求不一樣）
- Documentation （寫跟維護文件是痛苦的）
- Feeling overwhelmed （找不到切入點）
- Separate interface from implementation thinking （抽象設計）
- Agreement （確保已修正問題的證據）
- Anxiety （改東壞西的擔心受怕）

```

很久沒對 TDD 發表這種長篇大論了，因為不理解、不想理解、不同角度理解的人居多，能真的到各自的塔上用不同角度來看原義，以及實務上用它來幫助解決的問題有哪些的人，真的太少。

大部分人只想針對這個詞彙來攻訐以博得流量跟吸引目光，而不是想著「我可以用它來幫助我什麼」

問題跟需求是中性的，解決問題跟滿足需求的手段與方式有千萬種，不會只有一種，也不會有所謂的對錯，多點角度去了解不同的方法、方式，然後融會貫通，發揮綜效，在實務上用最少的成本與風險來產生最大的價值，這才是真正的目標。

導入敏捷不該是目標，導入 TDD 也不該是目標，目標永遠都是在實務上產生價值、解決問題、滿足需求。

📌5 個常用的專案管理工具：曾看過有些專案經理光用 Excel 就能管理專案，心理雖然佩服，但現在已經有更多好上手、視覺化的工具可以使用，以下按照小人物的使用經驗從簡單介紹到複雜
.
👉第 1 個 Todoist
非常容易上手，能做專案管理，也適合個人時間管理，透過待辦事項的清單，該專注的只有現在該做的事情，操作簡單的工具就等同於有效率
.
👉第 2 個 Trello
適合小團隊，把工作項目變成一張張的便利貼，透過自由拖曳和排序，可以讓團隊隨時知道工作優先順序，也能立即調整工作項目的負責人
.
👉第 3 個 Asana
當團隊規模開始變大，可以考慮使用 Asana，功能十分全面，整合了 200 多個第三方工具，例如：Google Drive, Gmail, Slack, Teams, Outlook...
.
👉第 4 個 Redmine
免費的開源工具，對於產出甘特圖、資源分配、工作追蹤很有用，但因為是開源軟體，需要自己安裝，如果團隊有工程師，也能進行客製需求的開發調整
.
👉第 5 個 Jira
目前小人物正在使用的工具，可同時進行專案管理、產品開發和問題追蹤，能夠自定義各種類型的任務，並且可以結合 GitHub，對管理代碼很有幫助
.
🔍如果團隊或是個人常常漏東漏西，使用專案管理工具會是一個好的開始，即便是團隊運作順暢，使用管理工具能夠有效降低溝通成本，透過公開資訊建立團隊信任感，並且撰寫文字紀錄可以幫助團隊再次思考
.
📍歡迎大家「 分享 」、「 收藏 」，有任何想法請留言或私訊，最後記得開啟「 小鈴鐺 」，訂閱小人物職場的最新通知
.
🗓小人物每月皆會舉辦職場相關主題免費線上講座，歡迎到個人檔案連結加入「 小人物職場好友 」，優先取得活動資訊與報名資格
.
🎈喜歡記得追蹤 @work.thinking

#上班 #上班族 #目標 #成功 #職場語錄 #人際 #職場 #不想上班 #職場人生 #自我成長 #知識 #正能量 #求職 #新鮮人 #同事 #大學生 #小人物職場 #專案管理 #專案 #專案經理 #產品經理 #todoist #trello #asana #redmine #jira #職涯 #經驗分享 #軟體

[Accelerate State of DevOps 2021 快速摘要]

找一些自己有興趣的地方, 快速用 Google 翻譯一下

主要發現

1. 表現最好的人正在成長並繼續提高標準
在我們的研究中，優秀的執行者現在佔團隊的 26%，並且縮短了他們對生產變更的準備時間。該行業繼續加速發展，團隊從中看到了有意義的好處。

2. SRE 和 DevOps 是互補的理念
利用我們的站點可靠性工程 (SRE) 朋友概述的現代運營實踐的團隊報告了更高的運營績效。優先考慮交付和卓越運營的團隊報告了最高的組織績效。

3. 越來越多的團隊正在利用雲，並從中看到了顯著的好處
團隊繼續將工作負載轉移到雲中，而那些利用雲的所有五種功能的團隊會看到軟件交付和運營 (SDO) 性能以及組織性能的提高。多雲的採用也在增加，因此團隊可以利用每個提供商的獨特功能。

4. 安全的軟件供應鍊是必不可少的，也是驅動性能的驅動因素
鑑於近年來惡意攻擊的顯著增加，組織必須從被動實踐轉變為主動和診斷措施。在整個軟件供應鏈中集成安全實踐的團隊快速、可靠和安全地交付軟件。

5. 良好的文檔是成功實施 DevOps 功能的基礎
我們第一次測量了有助於這種質量的內部文檔和實踐的質量。擁有高質量文檔的團隊能夠更好地實施技術實踐並整體表現得更好。

6. 在充滿挑戰的情況下，積極的團隊文化可以減輕倦怠
團隊文化對團隊交付軟件和實現或超越組織目標的能力有很大影響。在 COVID-19 大流行期間，具有生成性 1,2 文化的包容性團隊經歷較少的倦怠。

=========================================================

Technical DevOps capabilities

我們的研究表明，通過採用持續交付進行 DevOps 轉型的組織更有可能擁有高質量、低風險和具有成本效益的流程。

具體而言，我們衡量了以下技術實踐：
• 鬆散耦合架構
• 基於主幹的開發
• 持續測試
• 持續集成
• 使用開源技術
• 監控和可觀察性實踐
• 數據庫更改管理
• 部署自動化

我們發現，雖然所有這些實踐都改進了持續交付，但鬆散耦合的架構和持續測試的影響最大。
例如，今年我們發現，達到可靠性目標的精英執行者採用松耦合架構的可能性是低績效同行的三倍。

松耦合架構 (Loosely coupled architecture)
我們的研究繼續表明，您可以通過努力減少服務和團隊之間的細粒度依賴關係來提高 IT 性能。事實上，這是成功持續交付的最強預測因素之一。使用鬆散耦合的架構，團隊可以相互獨立地擴展、失敗、測試和部署。團隊可以按照自己的節奏前進，小批量工作，減少技術債務，並更快地從失敗中恢復。

持續測試和持續集成
與我們前幾年的發現類似，我們表明持續測試是成功持續交付的有力預測因素。達到可靠性目標的精英執行者利用持續測試的可能性是其 3.7 倍。通過在整個交付過程中結合早期和頻繁的測試，測試人員與開發人員在整個過程中一起工作，團隊可以更快地迭代和更改他們的產品、服務或應用程序。您可以使用此反饋循環為您的客戶提供價值，同時還可以輕鬆整合自動化測試和持續集成等實踐。
持續集成還改進了持續交付。達到可靠性目標的精英執行者利用持續集成的可能性是其 5.8 倍。在持續集成中，每次提交都會觸發軟件的構建並運行一系列自動化測試，這些測試會在幾分鐘內提供反饋。通過持續集成，您可以減少成功集成所需的手動和通常複雜的協調。
持續集成，由 Kent Beck 和它起源的極限編程社區定義，還包括基於主幹的開發實踐，接下來討論。

基於主幹的開發
我們的研究一致表明，高績效組織更有可能實施基於主幹的開發，其中開發人員小批量工作並經常將他們的工作合併到共享主幹中。事實上，達到可靠性目標的精英執行者使用基於主幹開發的可能性是其 2.3 倍。低績效者更有可能使用長期存在的分支並延遲合併。
團隊應該每天至少合併他們的工作一次——如果可能的話，一天多次。基於Trunk的開發與持續集成密切相關，所以你應該同時實現這兩種技術實踐，因為它們一起使用時影響更大。

部署自動化
在理想的工作環境中，計算機執行重複性任務，而人類專注於解決問題。實施部署自動化可幫助您的團隊更接近此目標。當您以自動化方式將軟件從測試轉移到生產時，您可以通過實現更快、更高效的部署來縮短交付週期。
您還可以降低部署錯誤的可能性，這在手動部署中更為常見。當您的團隊使用部署自動化時，他們會立即收到反饋，這可以幫助您以更快的速度改善您的服務或產品。雖然您不必同時實施持續測試、持續集成和自動化部署，但當您將這三種實踐結合使用時，您可能會看到更大的改進。

數據庫變更管理
通過版本控制跟踪更改是編寫和維護代碼以及管理數據庫的關鍵部分。我們的研究發現，與表現不佳的同行相比，達到可靠性目標的精英執行者進行數據庫變更管理的可能性要高 3.4 倍。此外，成功進行數據庫變更管理的關鍵是所有相關團隊之間的協作、溝通和透明度。雖然您可以從特定的實施方法中進行選擇，但我們建議，無論何時您需要對數據庫進行更改，團隊都應在更新數據庫之前聚在一起並審查更改。

監控和可觀察性
與前幾年一樣，我們發現監控和可觀察性實踐支持持續交付。成功實現可靠性目標的精英執行者的可能性是其 4.1 倍
擁有將可觀察性納入整體系統健康狀況的解決方案。可觀察性實踐讓您的團隊更好地了解您的系統，從而減少識別和解決問題所需的時間。我們的研究還表明，具有良好可觀察性實踐的團隊會花更多的時間進行編碼。對這一發現的一種可能解釋是，實施可觀察性實踐有助於將開發人員的時間從尋找問題的原因轉移到故障排除並最終回到編碼上。

開源技術
許多開發人員已經利用開源技術，他們對這些工具的熟悉是組織的優勢。閉源技術的一個主要弱點是它們限制了您將知識傳入和傳出組織的能力。例如，您不能聘請已經熟悉您組織工具的人，開發人員也不能將他們積累的知識轉移到其他組織。相比之下，大多數開源技術都有一個社區，開發人員可以使用它來提供支持。開源技術具有更廣泛的可訪問性、相對較低的成本和可定制性。達到可靠性目標的精英執行者利用開源技術的可能性是其 2.4 倍。
我們建議您在實施 DevOps 轉型時轉向使用更多開源軟件。

source: https://cloud.google.com/devops

## 影片觀看說明

由於問題較多，大家的問題也可能是你的問題，建議可以先閱讀下方的「問題總匯」區，找到時間碼 Time code 之後跳轉到自己想聽的部分，會比較有效率哦

本影片 Q&A 留言是抓取
【2020 年度回顧! 成為 Team leader? 業外收入增加? 技術能力成長? (第一次蒐集 Q&A)】https://youtu.be/BGaDN9wxbKE

## 影片中提到的專案

簡單用 React 撰寫的留言爬取篩選功能，可以自己抓去玩
https://github.com/niclin/youtube-comment-filter

## 問題總匯

00:00 開場
01:26 QA-1 - 林天寸

一直很喜歡妳的頻道，不單單是因為工程師，當然也有部分原因是自己也是走工程師這條路的。
前一年2020年開始，其實是我剛轉職工程師的第一年，在滿多地方都遇到不小的問題，在troubleshooting上面也是有許多瓶頸的。
後來除了白天上班，下班看書跟休息，偶然間看到你的影片[工程師如何自我進修]，才開始慢慢用計畫的方式取代橫衝猛幹。
不得不說，規劃時間真的是比起技術性的功力還更有成效。因為它讓你適時的放鬆跟加強，然後在工作上面才更有長進，雖然很幹話，但我2020的下半年是這樣做的。
目前在準備考取網路管理的證照CCNA，計畫是走network這一塊，還有很多要磨練的。希望也能多看你產出跟network的影片，這是私心話啦，哈哈。

02:57 QA-2 - 仔仔

1.學程式會建議從前端或是後端哪個開始學會比較好?
2.一開始投履歷如何判斷一家公司是可以成長的，而不是進去3，5年後還是那個跟剛進去程度相差不遠的自己差不多
3.跟程式相關的產業有很多(像是製造業到博弈)，可以請Nic分析一下各產業的狀況嗎?以及進去各產業前須要具備哪些程式語言或能力?
4.投履歷時看到一些公司列出所需程式語言和工具一大堆，是不是代表你沒完全具備就不要投履歷了，還是可以請Nic給個意見哪些部分還是可以投看看
5.都說工程師又宅又不會說話，為什麼Nic可以交到女朋友?

10:40 QA-3 - ANDREW NG KAR EARN

如果当写编程语言遇到瓶颈，有什么方法可以有效地避免自己陷入钻牛角尖的情况？

11:46 QA-4 - JS Lin

如果NIC現在選擇能馬上精通一項語言會是哪個？會想用來做什麼PJ？

13:13 QA-5 - Rick0

成為 team leader 後無法直接在技術上有更深入的研究和突破，這樣的變化是否值得?
是否會擔心這樣在技術上跟不上其他人，甚至被下屬看輕呢?

14:39 QA-6 - Henry蔡

因為最近是寒假期間，
我開始考慮下學期的修課，
想請教nic大大，
應該在有什麼樣的基礎上，
開始學design patterns？
我目前是碩士生，
大學非資工本科，
學過Python，
也跟過一些網路影片實作過Flask+PostgreSQL，
大學學過資料結構演算法，
但不到得心應手的程度...

16:07 QA-7 - 黃柏瑋

如何同時Handle好好幾件事
我怎麼覺得上班，然後下班假日寫寫side project後就沒啥時間了🤔🤔🤔

17:24 QA-8 - 乾太

我想問一下這年頭轉行斜槓 VTuber 還有沒有搞頭A？

18:10 QA-9 - uuu06222

之前開始關注你有知道你有面試過人的經驗, 想問一下站在面試官的角度...
面試官會不會比較注重作品需要呈現那些東西, 或是有沒有什麼禁忌是不能碰的嗎?

20:07 QA-10 - Joery Lin

想請教您對於對於給你很多成長和照顧的公司，倘若您有一個更好的機會，無論薪水或未知挑戰都大於現在公司。
您將如何做選擇，或許現在公司會給你加薪留下你。

因為自己曾放棄了許多機會

21:37 QA-11 - YangTing Zheng

Q1: 想問通常一個產品開發的週期都多長呢？負責維運和開發的工作內容是否會差很多？
Q2: 想請您簡單介紹一下資工系學生的出路/工作內容？(如PM.SA.DBA.PG.RD.MIS…或是還有其他的？）

24:16 QA-12 - RTB

Hello World

24:18 QA-13 - Barry

目前是公司MIS 很想轉職成後端工程師，但在面試上面都都時常失敗
常常在問技術關卡時就被問倒了，總覺得 要準備的東西非常的龐大
毫無準備的頭緒，總覺得一直寫side project也不是辦法

26:49 QA-14 - 因地制夷

想請教Nic 有在做投資嗎? ex 股票 想聽一些投資心得

27:13 QA-15 - 比歐

想請教 Nic 大，
在之後的工程師生涯中之後有甚麼規劃或想法嗎?
例如:開發產品創業，或是開班授課、轉做顧問之類的。

28:14 QA-16 - yongming jia

请问新手如何学编程，学完去做什么？怎么自己创业？谢谢🙏

29:33 QA-17 - Minghao Chang

是否能請您推薦用來開發的筆電？（正好最近要汰換電腦），想從今年開始養成寫side project的習慣，謝謝。

30:31 QA-18 - Guan Jun Chen

想知道像Nic這麼厲害的工程師，年薪大概落在哪裡

30:46 QA-19 - Sheng Jiang

想請問Nic，如果非資工背景但是對寫程式有熱情，想轉職當軟體工程師，會建議如何起步?

補充：像是什麼樣的人適合自學，什麼樣的人適合去補習，或者補習跟自學的情況各有哪些優劣?

謝謝Nic

## 結尾

31:49 感想

喜歡影片的話！可以幫忙點個喜歡以及分享、訂閱唷！😘

━━━━━━━━━━━━━━━━
🎬 觀看我的生活廢片頻道: https://bit.ly/2Ldfp1B
⭐ instagram (生活日常): https://www.instagram.com/niclin_tw/
⭐ Facebook (資訊分享): https://www.facebook.com/niclin.dev
⭐ Blog (技術筆記): https://blog.niclin.tw
⭐ Linkedin (個人履歷): https://www.linkedin.com/in/nic-lin
⭐ 蝦皮賣場: https://shopee.tw/bboyceo
⭐ Github: https://github.com/niclin
⭐ Podcast: https://anchor.fm/niclin
━━━━━━━━━━━━━━━━
✉️ 合作邀約信箱: niclin0226@gmail.com

#QA #工程師 #在地上滾的工程師 #前端 #後端 #轉職

香港今日社論2020年09月19日(100蚊花旦頭)
https://youtu.be/bWrL6FQ1KNE

請各網友支持, 課金巴打台
(過數後請標明所支持的節目或主持, 把入數收據WhatApps 至 : 94515353 )
- 恒生 348 351289 882
- 中銀 012 885 1 086914 9
( 戶口名: Leung Wai in Tammy)
- 轉數快FPS 3204757
- PayMe 94515353
- Paypal : tammyleung96@yahoo.com.hk

巴打台購物網址
https://badatoy.com/shop/
巴打台Facebook
https://www.facebook.com/badatoyhk/
巴打台Youtube Channel:
https://www.youtube.com/channel/UCmc27Xd9EBFnc2QsayzA12g
--------------------------------
明報社評
一年一度的台海兩岸交流平台海峽論壇今日將在福建廈門開幕，今年的海峽論壇卻因台灣最大的參與團體國民黨杯葛而有所影響。國民黨杯葛的表面理由是中央電視台女主播在播報該黨元老王金平將出席論壇的新聞時，用了「求和」的字眼，要求道歉而未果，認為有失尊嚴。但據報道，國民黨內對出席論壇本就有諸多疑慮。事件反映，經過台灣今年選舉以及國際風雲變幻，海峽兩岸、國共兩黨互信已削弱，雙方變得更加敏感、小心翼翼，稍有不慎就引發軒然大波。不過，從事後國共兩黨的反應看，雙方仍留有餘地，兩岸交流大門並未關上。海峽論壇是由國台辦、福建省政府及台灣民間團體舉辦的交流平台，自2009年起每年於福建省舉行，是目前兩岸規模最大、參與層面最廣泛的民間交流活動。大陸方面通常由全國政協主席出席致辭，台灣方面則由國民黨高層領銜出席。據報道，今年受疫情影響，台方與會人數由往年的數千人銳減至不足千人。

蘋果頭條
早前一名巴士司機執勤時帶備士巴拿，一度被警方指「藏有攻擊性武器」而遭拘捕，令社會各界譁然。有需帶備「開工架生」上班的從業員工會感到憂慮，表示會員常被截查、不知何時會誤墮法網。《蘋果》統計去年6月至今年2月逾280宗有關「帶有不同物品而被控」的案件，發現有人因帶5條索帶，被控管有攻擊性武器或工具作非法用途；記者根據尋得資料，發現此罪行完成審訊的案件，撤控率達77.3%。大律師黃俊嘉指，部份罪行檢控準則較高，需有不可抗拒的推論才可將被告入罪，「如果檢控一開始睇得仔細啲，有啲案件無必要真係打到最後」。警方最新回覆《蘋果》，由去年6月9日至今年8月31日，共有326人被控藏有攻擊性武器，較早前公佈少1人。早前巴士司機執勤時背囊被搜出士巴拿，一度以「藏有攻擊性武器」為由遭到拘捕，工具變成攻擊性武器，令不少人對「攻擊性武器」的定義存疑，亦擔憂手持工具會「被砌生豬肉」。

東方正論
本港司法制度畸形，洋法官在中國領土呼風喚雨，早就令人側目。終審法院外籍非常任法官施覺民本月初突然請辭，特首按法例撤銷其委任，有關消息昨日曝光。外媒引述當事人的辭職原因與《港區國安法》有關，反對派即不失時機地為國安法扣上「傷害法治」的帽子。其實，香港早已不是殖民地，司法刀把子早就不該由洋人把持，更輪不到外人說三道四。現在才有洋法官辭職已是「遲來的敗走」，若離職陸續有來，正是香港之幸，對法治何損之有？合則來，不合則去，本來並無甚麼稀奇，偏偏一個洋法官辭職卻吹皺一池春水，足見香港有些人的奴性仍是根深柢固。當然，外界之所以覺得稀奇，部分原因是特首去年七月才接納終審法院首席法官建議，將施覺民的任期延續三年至二○二二年七月，距離今次撤任提早近兩年；而碰巧其辭職日期正是林鄭月娥揚言香港沒有三權分立翌日，更令人添上無限聯想，一度以為是特首主動撤銷其委任。

星島社論
因應新冠肺炎疫情放緩，政府於昨日起放寬關於社交距離的抗疫措施，食肆堂食時間延長至午夜；酒吧、派對房間、卡拉OK場所及泳池等獲准重開。本報記者昨晚前往中環蘭桂坊視察，發現大部分酒吧均座無虛席，有酒吧更以半價優惠價招徠，務求於十二點前盡吸客源，個別酒吧更稱生意勝預期，達疫情前六至七成生意。不過，或因客人過多有部分出現每枱人數過多的疑違規情況。政府專家顧問許樹昌對有關情況感到憂慮，直言若一人確診，病毒便隨時蔓延開去，籲業界自律。食物及衞生局局長陳肇始亦預告，警方及食環署會於今日起展開聯合行動，加強巡查食肆、酒吧等場所。抗疫措施放寬之下，本港逐步回復過往「不夜城」的繁華景象，酒吧、派對房間、卡拉OK及泳池等場所昨日可以重開；食肆晚市堂食可延長至午夜，維持最多四人一枱。重開處所要遵守防疫措施，卡拉OK及派對房間，只有飲食期間才可豁免戴口罩，不得超過四人。

經濟社評
13類表列處所昨天起悉數重開，港府同日召開記者會展現繼續嚴格防控疫情的決心，更罕有臚列出抗疫藍圖，為冬天可能爆發更嚴峻的第4波疫情做足準備。本港首現條理清晰的抗疫6部曲，惟不少只是既有政策，要加強新思維，亟需再諮詢集思廣益，填補遺漏。隨着酒吧、泳池等成為最後一批重開的表列處所，食衞局局長陳肇始隨即公布，疫情管理措施要納入社會新常態，在在反映要一邊放寬限制，一邊嚴控疫情反彈。官方正從六大方向着手，包括化驗檢測服務、社交距離措施限制、檢疫設施、開發追蹤技術、跨境管制，以及疫苗採購。有了全民檢測的經驗，港府將可利用公營部門每日逾7,000個樣本的檢測能力，更有效率地替安老院員工、司機、餐廳員工等高危群組恒常化驗。陳肇始特別提醒年輕人要警覺，以免傳染身邊長者，惟反過來，官員也可多走一步，把耄耋長者或長期病患等體弱人士，一併列入可獲恒常檢測的特定高風險群組，防患未然。

iPad Air（技術上稱第一代iPad，而iPad Air 1為俗稱，且在2017款iPad推出之前亦有「iPad 5」之俗稱）是由蘋果公司設計、開發及銷售的iPad平板電腦，它延續9.7英寸（250公釐）配備Retina顯示器的iPad，但機型因參考了iPad Mini的設計，使得其更薄、更輕巧，2013年10月22日於美國加州舊金山發布，同年11月1日起正式發售[2]，Air的設計語言主導了之後平板的輕量化設計，所以Air系列同屬iPad系列第5個世代。（維基百科）
iPadOS是蘋果公司在iPad上使用的作業系統，最新版本iPadOS 13於2019年6月4日WWDC上發布[6][7]。 iPadOS的使用者介面是使用多點觸控來直接操作。介面操控元素包括滑動條、開關及按鈕。跟操作介面的控制包括滑動、點擊、扭捏及反向扭捏。這些所有都在iPadOS作業系統及其多點觸控介面中有具體的定義。內建的速度感知器能夠提供給部分應用程式使用，當裝置搖動時以的作出回應（常見的結果是還原指令），或以三維方旋轉（常見於切換縱向及橫向之間的螢幕模式）。2019年9月24日已正式發送更新。（維基百科）

(巧控鍵盤影片來源：Apple)

Procreate
說明譯自英文-Procreate是由Savage Interactive為iOS和iPadOS開發和發布的用於數字繪畫的光柵圖形編輯器應用程序。專為響應iPad的藝術可能性而設計，並迎合從初學者到專業人士的藝術家，它於2011年在App Store上推出。（維基百科）

Affinity Photo
說明譯自英文-Affinity Photo是由Serif開發的用於macOS，iOS和Windows的光柵圖形編輯器。它與Affinity Designer和Affinity Publisher一起屬於“ Affinity trinity”的一部分。（維基百科）
https://affinity.serif.com/en-gb/photo/