July 20, 2020

跨平台遊戲開發嘗試貪吃蛇遊戲

好拉！我知道這張圖有點詐欺，但我就是想分享下阿！

遊戲畫面

桌面平台（Windows、Linux）

Android

遊戲專案介紹

Godot遊戲引擎我關注蠻久的了，這是第一次親自嘗試。。它是一個可以建立跨平台、跨設備的開源引擎。可以輸出成給Windows、Linux、Mac、Android、iOS甚至其他平台的遊戲。這個遊戲引擎當前可以在Steam下載。其自帶了許多範例，也可以在這裡尋找並下載或是分享。

May 31, 2020

【閱讀筆記】深度學習演算法實踐

這本書以一個個假想的案例，帶讀者看看文字分析、對話機器人、臉部辨識、表情分析、強化學習、預測與推薦。內容不深，也有一些建議，可以是作一個個簡單的案例來看。

推薦指數：★★☆☆☆
閱讀日期：2020/05/28

May 23, 2020

【閱讀筆記】編寫可讀代碼的藝術

編寫可讀代碼的藝術(The Art of Readable Code) - 閱讀筆記

這本書有些地方是不合時宜的、我不太認同的，尤其是關於JS的部份，畢竟ES6後JS這個語言本身變化得非常多。我還是想引用Bob大叔在《Clean Code》的裡寫的：

當然，本書的許多建議是具爭議性的，你或許不會完同意這些意見，…… ，我們也無法主張自己的看法就是最終的權威。……。所以先不論你是否同意我們的想法，如果你根本沒有看到，或尊重我們的看法，你應該要感到羞愧。
– by Robert C. Martin（人稱Bob大叔（Uncle Bob））。Clean Code無暇的程式碼。

總之，儘管有些部份與自己作法略有不同，但不管是內容，還是內文漫畫(cartoon¹真的話的很有趣)都有很大閱讀的價值，非常推薦！

推薦指數：★★★★☆
閱讀日期：2020/05/07

May 16, 2020

【閱讀筆記】軟體測試的藝術

《軟體測試的藝術》，寫過筆記的人也不少，但筆記畢竟主要是給自己看的，就還是紀錄一下自己認為值得反覆咀嚼的內容。值得意外的有點多，尤其是第六章節。很多我無法用一兩句話去記憶、帶過，自己尚未內化或許是原因之一，所以這篇筆記會很亂。總之，雖然剛開頭覺得有些無趣，但是強烈推薦去完整讀讀第六章節。

測試是為發現錯誤而執行程序的過程。
軟體測試更適宜被視為試圖發現程序中錯誤（假設其存在）的破壞性的過程。軟體做了其應該做的，未做其不應該做的。

推薦指數：★★★☆☆ 閱讀日期：2020/04/24

以下為筆記內容

第六章、更高級別的測試

軟體開發週期：

最終用戶轉換為書面需求（最終實現目標）(需求分析)
評估可行性與成本，消除相牴觸的用戶需求，建立優先級別和平衡關係，轉換為具體目標。(WPS、干特圖)(設計)
轉換為規格說明（外部格說明）
如果該產品是一個系統，接著就是系統設計。拆分成多的獨立的子程序、部件或子系統，並定義接口。
通過定義的每個模塊功能、模塊層次結構與接口，來設計程式或程式集合的結構。
設計一份 準確的規格說明 ，定義每個模塊的功能與接口。
經過一個或多個子步驟，將模塊接口規格說明轉換為每個模塊的原始碼。(開發)

需求規格 說明定義了為什麼要開發程序。
目標定義 了程序要做什麼，以及應做的怎樣。
外部規格說明 定義了程序對用戶的準確表現。
與後續階段相關的文檔越來越詳細地規定了程序是如何建立起來的。

測試方法、階段：

程式設計師應當避免測試自己編寫的程序。（除了單元測試外）

May 3, 2020

【閱讀筆記】代碼重構的藝術

目前在服義務役當兵，這本有點忘記啥時看完的了，印象中在入營前。總之，利用放假一點時間寫一下筆記。
喔！對了，我也看完「軟體測試的藝術」了。有時間再來寫。

六六三十六，數中有術，術中有數。
陰陽變理，機在其中。
機不可設，設則不中。
– 《三十六計》

推薦指數：★★★☆☆

本書分成三大部份：

第一部份：修改機理
第二部份：修改代碼的技術
第三部份：解依賴的技術

對我而言有幫助的在後兩個部份，但我也還在理解中。一個是個人經驗不足，有些內容沒有那麼深刻的體會。故如果你跟我一樣沒有多少重構經驗，看這本書可能也會像在霧裡看花。但我仍然覺得有些收穫，所以我會給2-3顆星。而如果你已經有一些重構經驗，但重構的有些痛苦，這本書或許會很適合你。

好的技術書籍一般有兩種情況，一種是介紹一些新奇而有趣的技術，另一種是能將現有的技術闡述或概括得通透淋漓。然而，實際上還有第三種–既非介紹新奇的技術，也非闡述紀有的技術，而是將長期實踐所證明了的大量技術手法囊括在一起。看起來琳瑯滿目五花八門，但又各有各的用武之地。這樣的書一般較少見，因為需要長期的累積和時間的洗禮。
本書正式這樣一本書。
– p.6 譯者序節錄

April 5, 2020

什麼是jQuery？前端框架盛行還需要JavaScript函式庫嗎？

本篇首發於ALPHACamp Blog(2020-03-25)
2020-04-05 更新

前端框架盛行還需要JavaScript函式庫嗎？
如果你想透過本篇文章，直截了當的知道該不該使用jQuery，可能要讓你失望了。
很難說到底應不應該使用jQuery，可能在某些情況下使用jQuery仍是最好的選擇。即使是現在的流行的三大前端框架，也是依照情況與需求使用。
了解jQuery到底是什麼、前端框架是什麼，會比要不要使用jQuery更有意義。
本篇帶你看看我了解的jQuery前世今生

瀏覽器發展歷史上出現過幾次大混戰。儘管後來有了W3C(全球資訊網協會/World Wide Web Consortium)進行標準的制定，各個瀏覽器廠商仍開發各自瀏覽器的「特異功能」吸引使用者與開發者。這些特異功能促使了瀏覽器標準的進步，也照成了開發上的困難。

為解決網路應用中不同平台、技術和開發者帶來的不相容問題，保障網路資訊的順利和完整流通，全球資訊網協會制定了一系列標準並督促網路應用開發者和內容提供者遵循這些標準。¹

2006年1月，jQuery推出了第一個版本，隨後變成為了最受歡迎的JavaScript函式庫之一²。附帶一題，我們現在熟悉的HTML5標準是在2014年正式定稿推出³，即使是現在，每年瀏覽器的標準也是快速地在變動。在後文我會在說明為何開頭我想提到這兩件事情。

什麼是jQuery? 從常見功能來看

jQuery之所以受歡迎，是因為他提供了一系列簡單方便，而且兼容的操作，省去開發人員的部份煩惱。這裡舉幾個簡單的例子：

選取器

現代瀏覽器標準分成三個部份：

HTML
CSS
ECMAScript / JavaScript

其中第三個就是常聽到的JS/Javascript。目前更正式的名稱是ECMAScript，也是今天主要jQuery主要的基礎。不同於瀏覽器腳本(Script)的標準，CSS2在以前就提供豐富易用的選擇器，讓設計人員撰寫樣式表(stylesheet)