2020 年 COVID-19 （武漢肺炎）疫情席捲全球、改變人類生活之際，家用電玩主機也邁入「第九世代」。本來以為本文不會這麼快出現，不過就在 PlayStation®5 （以下簡稱 PS5）一機難求的農曆年前，竟出乎意料的被抽到購買權，就這樣，繼三年半前的文章「第八世代：SONY PlayStation®4 Pro」之後，「憋的電玩故事」系列又有東西可以寫了。
大致上說來，第八世代與第九世代的分界感，跟第七世代剛進入第八世代一樣，一時之間看來沒有很明顯，大概再等兩三年，軟體開發技術與內容相對成熟之後，才會看得出世代差異。
這幾天在工作上遇到一件很靠北的事，實在不得不寫出來靠北一下。
前幾天收到用戶端的反應，抱怨今天的 ERP 怎麼會莫名其妙當機？單子都不能打了。到用戶端實際操作，果然真的如此。第一直覺該用戶的 Windows 作業系統環境被多餘的軟體搞亂、電腦老舊跑不動等這類原因，胡搞蝦搞了一段時間，問題似乎沒有改善。
沒多久另一個用戶端也跑來反應，一模一樣的情況，而且用戶表示前一天下班都還好好的。這時懷疑 ERP 主機可能有狀況，趕緊 LINE 去 ERP 廠商詢問，他們說昨晚的確有連線進來調整設定一些東西，但那些動作絕對不可能導致前端用戶當機。
正當還在釐清問題怎麼發生時，又有兩個用戶跑來抱怨，說 ERP 當機了，都一樣症狀，我趕緊內部調查了一下，發現竟然將近一半的電腦都有問題，但另一半的人卻完全正常，且每個作業區網皆有正常與不正常的情形，所以問題與主機無關，也與網路無關。
這個問題就像武漢肺炎一樣，突然「瞬間」爆炸，頭殼開始抱著燒，到底是什麼情可能性，會造成瞬間一半的人 ERP 同一時間掛點....是網路問題？電腦中毒？令人百思不得其解。
在前一篇文章「Linux（Ubuntu）環境開發 C/C++ 應用程式」中已獲得使用微軟 Visual Studio Code for Linux 撰寫 Paho MQTT C/C++ Client 應用程式的能力，並寫了一支 MQTT Client Sample for C++ 放在 Github 上，後續也發現文章所說的建置方式：
突然意識到，Visual Studio Code 理所當然支援 Windows 平台啊！一定也能在 Windows 平台上這麼玩才對。如果能補足這個部分，那就滿足「一套原始碼，通吃 Windows / macOS / Linux (x86/64/ARM) 全平台」全制霸的目標。在以往所接觸過的領域中，雖然 Python/NodeJS (Javascript) 也做得到，不過 Python / NodeJS 本身並非原生運行，透過即時轉譯的效能比需編譯的 C/C++ 差，「全平台通吃」的程式碼，對於希望原始碼能以原生運行的意義上來說，還是有些不同。
為了攻克「在 Linux 上撰寫的 C/C++ 程式也能在 Windows 上運行」的目標，也就花了點時間研究。本來以為應該不難，沒想到還是繞了好大一圈，又踩了不少坑，所以這部分又值得寫一篇文章來好好抱怨一番，到底坑在哪裡。
今年從 10 月 1 日開始至今有兩次連假（中秋 + 國慶），再加上自己的「沒用掉就憑空消失」的年假，這 11 天我幾乎都在休假。然而，繼前次中秋連假期間在家研究 Linux 撰寫 C/C++ 議題，這次的國慶連假可就真的很靠北，不寫一篇文章來發發怨氣實在是不爽。
一開始是「沒用掉就憑空消失」的年假，人在家還是被遙控了好幾下，其實只要能解決問題，都不算真正的靠北，換個角度，哪天換我遙控休年假中的夥伴好像也不錯。真正靠北的事，都發生在後來的三天國慶連假。
九月時工作上接到一項任務，內容是評估某硬體方案的可能性。該硬體設備廠商有提供 Windows 與 Linux 兩種方案讓客戶選擇，為了趕進度，所以直接以熟悉的 Windows 方案使用 C# 進行試作，可惜評估結果不盡人意（硬體問題）。然而在此評估過程中，也讓我意識到 Linux 可能也是商用硬體設備的選項之一，所以在中秋節連假期間，除了吃飯睡覺拉屎看電視打電動逛街人擠人之外，把剩下的時間全都花在學習建置「Linux 環境開發 C/C++」這件事情上了。四天連假結束，算是有點收獲，開篇文章把這些學習心得記錄下來，免得以後很快又忘記。
這篇文章以「在 Linux 環境下開發 MQTT C/C++ Client 應用程式」為目標情境，打造 Linux 環境下相對友善的 C/C++ 開發環境，使用 Linux 版 IDE 工具進行 C/C++ 程式開發。
自 2017 年 6 月購入 PlayStation 4 Pro（以下簡稱 PS4）以來，【Ghost of Tsushima - 對馬戰鬼】是至今唯一一款「預購衝首發」的 PS4 遊戲。從 7 月 17 遊戲上市當天至 8 月 16 日主線劇情通關，近一個月的時間，幾乎每天用 1-3 小時解放對馬島的任務，總遊戲時間大概超過 30 小時，真心覺得這是一款難得的好遊戲。
遊戲的故事背景取材自西元 1274 年的第一次元日戰爭，蒙古人入侵日本對馬島的真實歷史事件。正史用「元日戰爭」似乎帶點「中日戰爭」的味道，不過當時蒙古人在北方建國「大元」，南宋尚未滅亡。遊戲主角「境井仁」在習得強化技能後可以「大肆屌虐」蒙古軍，導致遊戲發售初期有部分 玻璃心破碎的 中國玩家不滿「辱華」而投訴要求禁售（其實遊戲中蒙古人殘忍凌虐日本人的戲份也不少啊！怎不見日本玩家跳出來靠夭咧？）。另外，由於對馬島的地理位置比較接近韓國本土，有部分 活在平行時空的 韓國愛國主義者也不滿「對馬島歸屬日本」的設定，並且該遊戲的「實體珍藏版」內容物包含一張日本視角繪製的仿古對馬島地圖，導致官方取消實體珍藏版在韓國地區的銷售，這些算是遊戲上市時意外的插曲。
遊戲一開始就以 PS4 的硬體即時演算機能，如電影運鏡的表現方式，重建當年蒙古人入侵對馬島的戰爭場面（按：後來購入 PS5 之後，才發現這段演繹動畫應該是 CG 而非即時）。然而根據正史紀載，八十名日本對馬島武士對上成千上萬又驍勇善戰的蒙古大軍，當晚日本武士就被團滅、一個不留了。不過遊戲劇情則是讓其中兩名武士存活下來（不活下來怎麼玩），且遊戲中所有登場人名全都是虛構人物。雖然倖存武士與後續「化身戰鬼解放對馬島」的故事是「假的、虛構的」，然而遊戲中對馬島地名、地理、地貌特性、島民生活型態、日本武家統治之社會結構、風氣、武士服裝、教條信仰、刀具、劍術招式、流派等等，取材大多有真實史料考據，並非胡謅亂道（遊戲裡出現的黑科技「火砲車」很明顯是虛構的，為了讓遊戲中的戰爭場景更好玩罷了）。遊戲在這些虛虛實實且無違和感的設定下，玩起來特別有說服力和帶入感。
回顧黑蘋果二號機從 2012 年 7 月誕生至今已經八年，遇到的問題不算多，2012 年採購策略正確，少繞了一些冤枉路。很不幸的這次在 macOS 11 Beta Developer Preview （簡稱 DP 版）踢到鐵板。首先，黑蘋果二號的硬體配置當初完全是以 iMac 2012 Late（iMac13,2）為目標量身打造，而這次 macOS 11 Big Sur 大幅更改核心的位置跟啟動方式，又加碼排除 2012 以前的 Mac 電腦 ，所以「舊 Mac 不能升級」與「黑蘋果無法啟動」同時發生在黑蘋果二號機上，導致除錯難度曲線瞬間陡升。
從 6月 23 日 macOS 11 發表之後一直搞不定的那幾天裡，日子真的難過。以往遇到問題時大多在 tonymacx86 爬文，然而 tomymacx86 完全禁止討論 DP 版，用 Google 搜尋的效果似乎很有限，在網路上瞎逛了幾天，後來加入臉書「我和我的黑蘋果」社團。一進社團爬了幾篇發文，很快就搞清楚問題點了，果然互動 + 滾動式的技術交流，比 Google 網海爬文的效率還高。
隨著日子漸進，問題一個一個慢慢排除，至今黑蘋果二號機已經可以順利運作 macOS 11 Big Sur DP 版，可以像往常如白蘋果升級的方式直接從 10.15 升上去，或是從自製的 USB 安裝碟進行全新安裝 macOS 11 Beta DP版。這段歷程接觸到相關的技術資訊，值得寫篇文章紀錄一下，順便發發牢騷。
美商蘋果公司於美西時間 2020 年 6 月 22 日早上 10:00 （台灣時間 6 月 23 日凌晨 01:00 ）舉辦 WWDC2020 開發者年會。而今年受到全球 COVID-19 （武漢肺炎）疫情的影響（截至 6 月 23 日全球病例突破 900 萬，死亡超過 47 萬人），改採線上發表會的形式，透過官網與多個線上影音平台同步直播。 雖然少了現場信眾們的歡呼與掌聲，不過看起來也像是包裝精美的電視節目，甚至還有配好中文字幕（簡體中文），不用像以往那樣考驗英語的聽力，這樣的發表方式反而對不在現場的觀眾來說更友善。依照往年的慣例，WWDC 2020 內容主要仍是自家作業系統的更新發表，依出場順序為 iOS(14)、iPadOS(14)、watchOS(7)、tvOS(14)、macOS(11)，最後還有一段關於 Mac 的彩蛋，而我也像近年的慣例一樣，會議還沒完就夢周公去，隔天直接找媒體懶人包看重點，才知道本次真正的重點就在結尾的彩蛋上，
而本篇文章的重點，我就放在結尾彩蛋上，對黑蘋果族群來說，這個彩蛋不僅不會讓人開心，甚至還會讓人感到失望跟沮喪，文章的主圖是拿知名電玩遊戲「The Last of US」改的，我想說的，全放在這張圖裡了。（ Fxck! Fxck... Fxck!...）
撰寫「具備用戶介面（User Interface）」的應用程式，對於我這種依賴 IDE 開發工具（Integrated Development Environment，整合開發環境）的碼農來說，就像吃飯喝水那樣的直覺，甚至於忘了第一支 Hello world 的用戶介面是怎麼做出來的。這些年來寫過 Windows、macOS、iOS（iPhone/iPad/Apple Watch/Apple TV）、Android 等平台的應用程式，早期的 Windows CE（PDA 裝置）程式開發也接觸過一段時間。然而，有個地方一直都沒碰觸，對我而言也是未知的領域，那就是 Linux 平台的用戶介面應用程式。
大致說來，每個平台都有一套最知名、最強大、最多人使用、教學資源最豐富的 IDE 工具，例如 Windows 平台有微軟官方的 Visual Studio，macOS 有蘋果官方的 Xcode，Android 平台有 Google 官方的 Android Studio。然而在 Linux 上，似乎就少了一套強而有力、專門針對 Linux 視窗環境的 IDE 工具，所以就一直不清楚，如何在 Linux 上寫一支具有用戶介面的應用程式（這裏不談 Linux 系統的瀏覽器運作 HTML5 網頁）。
前陣子工作上接手一份來自古老時代的程式碼，是用 PyQt4 寫的，功能是提供一個使用者操作介面，讓樹莓派主機透過主板 GPIO 介面去控制幾個周邊設備。原作者早已失聯，不過有留著當時的開發筆記重點。順著考古的遺跡，意外讓我補足這一塊技能，原來透過 Python + Qt，也能輕鬆寫出對應 Linux 桌面版的用戶介面應用程式。
然而，使用 PyQt 開發 Linux 版的用戶介面，依然無法像 Visual Studio、Xcode 那麼方便，中間的過程還是有些需要手動生成操作的步驟，決定開一篇文章來記錄。所以了，若是您對「開發 Linux 環境的 UI 應用」感興趣，或是想知道如何寫出「UI 介面控制樹莓派 GPIO 周邊的應用程式」，可以參考這篇文章的內容。
「遙控自家的車庫門」這個構思其實已經想了很久，直到最近過年後才實現。這兩天有空把 Arduino Code 的部分整理之後放到 Github 上，有興趣的話可以參考。詳細的技術細節就不說了，不是什麼啥高深複雜的玩意兒，底下聊聊這個構思從發想到實現過程中的點點滴滴，給一樣有興趣的人當參考。
構思緣由
兩年多前「只管出一張嘴：用 Siri 控制家裡老電器」獲得成功實現之後，有時候會想家裡面還有什麼是可以拿來用程式遙控，不久後腦筋動到車庫門上。每次回家時想打開車庫門停車，得先把車停在門口，再花點時間在公事包內翻找車庫遙控器，每日例行公事，久了覺得有點煩，希望能找出便捷快速的方法。不過控制車庫的使用條件與遙控冷氣不同，不能像上次那樣「只出一張嘴」如法泡製，原因是剛回到家不一定有 Wifi 網路，再者也有安全疑慮，萬一有人在家門口大喊「嘿！Siri」觸發家裡 Homekit 裝置就這樣輕鬆打開我家的車庫門，那玩笑就開大了。
近來 COVID-19（又稱武漢肺炎）疫情烽煙四起，最早於 2019 年末在中國湖北省武漢市「華南海鮮市場」發跡，至今（2/23）已經蔓延數十個國家，根據 CHO... 呃..不是，是 WHO 官方統計，近八萬人染病，約兩千四百多人喪生，且數字仍不斷往上飆升，似乎還沒有減緩的跡象。而台灣與對岸大陸的民間交流頻繁，又適逢總統大選、農曆年等大量人口流動，終究也無可避免的遭到波及，截至今日（2/23）已有 28 例確診，1 人死亡。
還好台灣的疫情數字目前看起來沒有當初預期的嚴重，與日、韓、新加坡、義大利等國已發生大規模社群感染現象相比，台灣的疫情仍是相對輕微，得歸功於台灣政府能及早因應，與痛切汲取 17 年前 SARS 的慘痛教訓，是至今能夠有效遏制武漢肺炎疫情快速蔓延的主要原因。然而許多專家也預言，台灣進入大規模社區感染只是時間早晚的事，即便當前防疫有成，也千萬不可掉以輕心。
其實早在一月選舉前，政府已派員至武漢參加病毒研討，在疫情尚未明朗的氛圍中，預先判斷將來演變為大規模人傳人的可能性極大（2019.12.31），更搶在比 CHO...呃..不是，是 WHO 承認疫情擴散之前祭出手段，除了針對從疫區入境的航運人口實施隔離管制，也更早宣布將口罩納入管制醫療用品。嚴禁口罩出口、徵收民間口罩工廠的出貨，全力加開口罩產線，超商限量販售等，一連串管制口罩的大動作，初期一度造成民眾恐慌，導致到處買口罩隊伍大排長龍、多數人買不到口罩、不肖商人囤貨伺機漲價、人人瘋搶口罩等亂象，史稱「口罩之亂」。直到政府祭出鐵腕，宣佈實施獨步全球的「口罩實名購買制」措施，「口罩之亂」才逐漸平息。
在口罩產量不足與疫情未大爆發階段時，實名制措施至少撐住人人有最低限度的防疫動能，避免因少數人囤積導致多數人買不到而發生更大的防疫缺口。我個人完全認同這項措施，相信已在某些未知的傳染可能途徑中，有效拖慢疫情在台灣蔓延的速度，爭取到疫情可能進入社區感染前的準備時間。
自從 SSD 這玩意被發明出來之後，使用過的人只有一句話：「回不去了」，是大幅優化電腦體驗的首選。我的黑蘋果二號電腦也在組建後不久，開始全面改用 SSD 。然而 SSD 以替代傳統機械硬碟為目標，所以最初使用傳統硬碟的 SATA 匯流排介面，這麼做的好處是用戶只需替換原來的 SATA 機械硬碟即可，但壞處是傳輸速度一下子就頂到 SATA 的肺，也就是實際上 SATA 3 每秒最高約 550 MB 的資料速率。為了突破這個限制，市面上開始有 PCIe 介面的 SSD 產品，但印象中價格也相當驚人，一般庶民根本就買不起。
當時為了想突破 SATA 資料速率瓶頸，我另外購入 HighPoint Rocket 644L 磁碟陣列卡（文章），以搭建兩顆 SATA SSD 作 RAID 0 陣列為方案，可惜實際使用時最高速度也只來到每秒 660/600 MB，並未達到兩倍的理想值，據說和這張 RAID 卡使用的 Marvell 88SE92xx 晶片等級太低有關，也這樣用了很多年。
過了一段時間，市場上開始有支援 NVMe 協議，使用 M.2 介面接口的 SSD 產品，並且從 Intel 9 系列主機板開始內建。隨著時間推進，NVMe SSD 價格越來越低，速度也越來越快，主機板內建 M.2 插槽也逐漸變成標準配置，但是對於相對老舊的 Intel 6/7/8 系列沒有內建 M.2 插槽的主機板來說，NVMe SSD 有如過眼雲煙，如夢幻泡影，即便有 M.2 轉 PCIe 轉接卡產品出現，也因為主機板沒有支援 NVMe 協議，看得到卻吃不到。
後來有神人研究出，可將 NVMe 協議加入 Intel 6/7/8 系列 UEFI BIOS 內，讓老舊的 6/7/8 系列主機板支援 NVMe SSD，不過這些老板子大多沒有 M.2 插槽，所以需要插上 PCIe 轉 M.2 轉接卡，就能使用 NVMe SSD。
日前無意間看到了相關技術文章後心裡暗癢無比，再做了點功課，砸了三張小朋友購入 SSD 與 M.2 轉 PCIe 轉卡，按圖索驥之後，最終也成功了。
說真的一點都不難，只要小心別買錯東西即可。家裡有 Intel 6/7/8 系列的老電腦，有意花點小錢裝上便宜、高速、又大容量的 NVMe SSD 再多活幾年的話，本文的方法值得一試。
在「黑蘋果技術：淺談 Clover EFI 幸運草」這篇文章中，談到了 Clover EFI 的功能、引導 Windows 7 的方法，以及如何自行編譯 Clover EFI 的方式。
自行編譯安裝檔有幾個好處。除了可放入自己喜歡的佈景主題之外，也能隨時取得最新版 Clover EFI。蘋果每年發佈新版 macOS 作業系統，通常在 Developer Preview 版發佈之後的幾個小時內，就會有大神釋出對應支援的 Clover EFI 新版原始碼，這是黑蘋果搶先體驗新版 macOS 的最快途徑，可在第一時間評估黑蘋果電腦對新版 macOS 的相容性。
如果不想自行編譯這麼麻煩，那就等大神們釋出編譯好的版本，到這裡下載安裝就行了。
然而編譯 Clover EFI 時常因作業系統環境變動、版本的差異，常常導致編譯失敗，覺得有必要再開一篇文章說明收集這些問題和解決方式，累積除錯經驗。本篇文章的閱讀方式是，依閱讀順序把最新的資訊擺在本文前面， 已確定不適用的舊資訊則畫上刪除線作為標示。閱讀時從前面開始看，有其他問題再往下看。
美商蘋果公司於美西時間 2019 年 6 月 3 日早上 10:00 （台灣時間 [此字元已屏蔽] 凌晨 01:00 ）舉辦 WWDC2019 開發者年會。照慣例又是發表蘋果自家產品的四大作業系統更新版，出場順序依序為：tvOS、watchOS、iOS、macOS...哦？不對！突然發現今年的出場順序有點不太一樣，中間多了兩個項目：iPadOS 與新版的 Mac Pro 硬體，也就是 tvOS、watchOS、iOS、iPadOS、硬體 Mac Pro，最後才是 macOS。以下用最快的速度，帶一下各個項目的亮點功能。
OpenEmu 是 macOS 上的模擬器，支援的遊戲平台不少，使用簡單，Rom 和存檔的管理功能極佳，容易上手，堪稱是 macOS 上最強的模擬器，可在 OpenEmu 官網下載安裝。然而這款模擬器預設不能玩 Sega DreamCast（以下稱 DC） 的遊戲，不過 OpenEmu 在 Github 上的專案原始碼中，卻有 Reicast 的 Core ，這意味 OpenEmu 應該是可以使用 Reicast Core 運行 Sega DC 的遊戲才對。
研究了一下，OpenEmu 是開放框架，要讓 OpenEmu 能玩上某一款主機遊戲，只要加掛兩個支援 OpenEmu 的元件檔案：插件（PlugIn）與核心（Core）。官網在 WIKI 中提到 DreamCast 屬於「Work-In-Progress ports」項目，所以在正式釋出的版本中，並未包含 DC 的 PlugIn 與 Core 檔案，所以才不能玩。既然如此，只能上網找找看了。
可惜天不從人願，找了半天始終找不到這兩個檔案，只好從原始碼下手了。而 Github 上的專案 WIKI 有編譯 OpemEmu 主程式的教學，但是編譯 Core 教學從 2014 年至今都沒再補完，網路上也沒有前人的心得，只好自己踹踹看。
踹了一整天終於成功了。從結果論來說，操作不難，步驟不多，但說真的如果沒人教你，保證一定是不斷失敗鬼打牆 LOOP ，過程中還真是 TMD 痛苦，所以才決定寫這篇文章紀錄一下，免得哪天又忘記。
在前一篇文章介紹 PHP 的 IDE 神器「PHPStorm」，表示讚不絕口，然而，神器是必須付出代價的。就像 Office365 ，PHPStorm 也採用付費訂閱制，價格分別為月費 19.9 元，年費 199 元，第二年開始還有打折...噢，差點忘了說，這個價格是美金，這樣到底是貴還是便宜，只能說看人了，像我這種不能挑食的雜食工，PHP 只佔了工作與自學的一小部分，為此投入 19.9 鎂/月 或 199 鎂/年的學費，感覺很不划算。
雖然也有「快樂擁有神器」的方式，不過，快樂的時光總是短暫，時間到了，總得找好其他備案。有另一款亦稱神級且開源的開發神器：微軟出品的 Visual Studio Code（簡稱 VS Code），它也能做到 PHP 語法自動提示、Debug 斷點調試的功能。雖然 VS Code 是微軟出的，不過這玩意卻很大方的援其他平台，在 Windows、macOS、Linux 都能使用，不像 Visual Studio 總是只出現在 Windows 平台。
嚴格說來，Visual Studio Code 的原始功能只是增強版的文字編輯器，IDE 開發工具（Integrated Development Environment，整合開發環境）常見的Debug 調試與程式碼自動提示功能，必須透過外掛才能實現。也因為外掛，VS Code 可以寫的程式語言也不僅 PHP，業界主流常見的 C/C++/JAVA/Python/Swift... 都有，或許要反過來問：VS Code 不能寫什麼？（這時候，Object-C 默默舉手...）。
說了那麼多，真正的重點是：Visual Studio Code 是免費的！
廢話說完了，進入正題。要讓 Visual Studio Code 支援 PHP 開發的做法很簡單，不過設定的方式怪怪的，一旦忘記就會鬼打牆，所以開一篇文章來紀錄。
出社會這些年寫過的程式語言也算不少，第一份工作就是 Oracle / D2K / Form 6i，用過的人都說讚！這玩意寫 Oracle 資料庫交易功能簡直是神器，寫一支具備新增修改刪除加上各欄位查詢功能的表單，只需要用滑鼠拉一拉就完成了，一行程式碼都不用寫。早期就曾經有人靠 Oracle / D2K 開發工具，大肆宣稱半年內寫出五百多支程式，績效斐然，因此踹下其他競爭者，成功搏得上市電子廠高階經理人上位，超越顛峰，掙得每年數百張配股分紅，該人最著名口頭禪「一天賣一張，一年也賣不完」，在電子業與軟體業界成為經典的傳奇故事（知道我在講誰的，請勿對號入座）。由此可知，碼農們選對開發工具是非常重要的事，甚至有機會翻轉身人生，賺進大把鈔票... 扯遠了，後來換了幾次工作，用 Visual Studio 寫 ASP.NET，用 Xcode 寫 Object-C，特定的程式語言用特定的開發工具，做出一整套完整功能的應用程式專案，似乎是理所當然的事。
然而在江湖上卻不一定事事都理所當然。比如 PHP 這玩意，很多年前就接觸了，功力一直以來都是寫幾隻小程式、做幾件小事的程度。原因是很久以前忘了在哪個網站上看到一句話：PHP 要用文字編輯器來寫。於是種下了開發 PHP 方法的錯誤認知。
最近手邊有個專案，對我來說， VS 寫後端， Xcode 寫前端，輕鬆達陣不難， 但是要改用 HTML5 + CSS3 + jQuery + PHP 來寫，這就令我開始頭疼了。
用文字編輯器撰寫 HTML5 + CSS3 + jQuery + PHP 程式，開發出專案級別的功能，可行嗎？對資質愚笨的小弟我來說，幾乎不可行！我需要一套如同 D2K / Visual Studio / Xcode 那種強大的開發工具來撰寫 PHP 程式。
於是我開始求助 Google 大神，甚至上網 PTT 徵求技術交流 / 技術交換討論等，最後選擇了 Brackets ＋PHP 外掛來開發。Brackets 功能強大，但那是指前端而言，撰寫 PHP 後端則顯得十分雞肋，試了各種外掛，頂多只會提示 PHP 的內建指令，無法偵錯，寫起 PHP 還是舉步艱難。隨著程式碼越來越多，感覺越來越吃力，覺得自己沒有用對方法。
最終讓我用對了關鍵字，找到我認為最適合的 PHP 開發工具：
日前手邊又掛掉了一顆 SSD 硬碟，回想自 2012 年開始使用 SSD 以後，花在 SSD 上的費用已經累積到兩萬多元，其中也壞了幾顆，是該好好盤點檢視一下自己的 SSD 採購策略是否有無問題，作為日後採買的依據。
自 2012 年夏天啟用的黑蘋果二號機，至今也已經六年多了。回顧這六年來 Intel 也擠了四年的牙膏，黑蘋果的 i7-3770 至今也還算夠用。但顯卡的部分，為了原生支援度的原因，手邊留著二手購入的 GTX-780 3GB 和 R9-280X 3GB 視情況交互使用。不過近年熱門的 3D 遊戲大作（EX: Forza Horizon 地平線賽車），顯卡最低要求動不動就要 GTX-970 與 VRAM >= 4GB 以上等級，於是 R9-280X 或 GTX-780 已漸漸不堪使用。你知、我知、鄉民也知，近年來顯卡主流標準已經由 NVIDIA 說了算，陸續發表 Maxwell，Pascall 架構的顯卡產品儼然成為市場主流，但 Mac 與 macOS 偏偏就是原生不支援。後來，總算，終於，千呼萬喚，AMD 陸續發表新一代的 Polaris / Vega GPU 產品，拉近與 NVIDIA 顯卡的性能差距，而 Polaris/ Vega 也陸續被 macOS 支援。
然而在這個時候，市場竟吹起了虛擬幣的泡沫，Polaris / Vega 架構有利於挖礦的特性，幾乎淪為礦工禁臠，即便顯卡價格飆漲，礦工照樣掃貨毫不手軟，導致遊戲玩家一卡難求，更別說是一切講求原生支援的黑蘋果用戶，升級顯卡變得非常不划算。不過歷史也告訴我們，礦潮之後必有礦難，吹了兩年的虛擬幣泡沫破了，如今終於有機會補足黑蘋果在顯卡上的弱勢，所以上蝦皮找了一張二手的 Vega 56 礦卡來玩，開一篇文章來簡單紀錄一下這張 Vega 56 各種資訊的抹抹角角，大多是個人心得。
2018 年 9 月 21 日，美商蘋果公司的 iPhone Xs 開賣，這也是 iPhone 產品上市的第 11 個年頭。今日新 iPhone 開賣消息在台灣的網路聲量，已經遠大於 19 年前的今天，在台灣發生的另一件大事。文章標題看似時間的標記，而它也是見證 19 年前歷史的號碼之一。
{{ article.title }}
IoT 物聯網 (2)