單元測試的藝術 - Ch1 單元測試基礎 - Sec. 1.5 ~ 1.81.5 一個簡單的單元測試範例其實就算沒有測試框架的輔助，我們也可以自己寫一個自動化的單元測試 舉例來說，有一個類別 SimpleParser ，裡面有一個 ParseAndSum 方法 ParseAndSum()Input輸入零個或多個逗號分開的數字所組成的字串 exaple: 1,2,3 Output 輸入不包含數字 則回傳 0 包含一個數字 則回傳該數字 包含多個數字 則回傳這些數字的相加 為了示範方便，該 fucntion 現在只能處理0個或是1個數字的情況 首先，我們有了一個已經實作了上述需求的 SimpleParser 類別 SimpleParser 1234567891011121314151617181920<?phpnamespace Src;use Exception;class SimpleParser{ public function ParseAndSum(string $number): int { if (strle ...

SQL達人的現場工作筆記 - Ch17 - 有關順序的冒險知道視窗函數有多麼好用的人可能會有「這麼方便的工具怎麼這麼晚才問世，如果能早一點出現就好了」這樣的疑問。本章節將會介紹在視窗函數問世前的 SQL 發展脈絡。 姍姍來遲的主角視窗函數於 1990 年代後半才納入 SQL 標準，且在 2000 年代才開始支援，而 MySQL 更是等到 2017 才開始支援。以下我們來看一下大致上的年代表及其發展。 視窗函數年代表 年份 發展概述 1999 Oracle 8i 與 DB2 UDB7.1 將視窗函數當成（局部的） OLAP 函數支援。 Oracle 與 IBM 共同提出讓視窗函數接受 ANSI 認證，並於 SQL:1999 納為選項。 2003 於 SQL:2003 標準化為 Full Level 2005 Microsoft 於 SQL Server 2005 開始支援 2009 PostgreSQL 於 8.4 版開始支援 2011 SQL:2011 標準化為框架 2017 MySQL 於 8.0.11(GA) 支援 所以， 為什麼視窗函數這麼晚才來 ...

SQL達人的現場工作筆記 - Ch12 - SQL程式設計的模式前言除了寫出可以運作的 SQL 外，對於 SQL 的維護也是相當重要，所以本章節將討論在撰寫 SQL 上的可讀性。 資料表設計名稱與意義在 SQL 中對應的欄位、資料表、索引應該都要賦予有意義的命名 SQL 中可以使用的三種文字 英文字母 數字 底線（ _ ） 雖然有些 SQL 系統也承認像是 $、#、* 之類的符號，但作者建議大家不要去使用，因為有可能會在需要將資料庫移植到別的系統上的時候出問題（例如：MySQL 移植到 Postgres） 另外作者也告訴大家請不要使用保留字（例如：Primary）當作命名，這會增加混亂 屬性與欄位比起將資料表涉及為 EAV(實體屬性值) 的方式，更建議將各種資料用途拆開，讓欄位去說明資料的本質 撰寫程式的方針註解在 clean code 裡面有討論到，我們應該要盡量讓命名取代註解但作者認為 SQL 絕對應該要給註解，他給出的理由有二 SQL 為宣告型語言，所以很難寫出像其他程式語言那種「能夠自己解釋自己的程式碼」 SQL 幾乎無法 step by step 去檢驗錯誤 註解的寫 ...

Laravel 中的職責鏈模式 - Middleware 背後的魔法 及 在 Query 上的應用職責練模式這篇會用到職責練模式的概念，但不會從頭講解職責練模式，如果對於這個設計模式還不熟悉，建議先理解一下再來閱讀會對理解上比較有幫助一些 職責練模式 （可以參考這邊） 用簡單又較為口語化的方式來敘述職責練模式來說，我們讓一個處理的過程拆解成像是一個產線的感覺，這一站處理完換下一站處理，每一站都可以獨自判斷自己該運作或是根據某些條件 pass 給下一站 在設計上會讓大家共同實作某個讓執行者可以執行的介面，例如 handle() ， 底下看一下大致上的示意圖 所以說，為什麼會提到職責練模式呢？ 其實，本篇的主角是一個 Laravel 官方文件也沒提及的一個類別，他叫做 Pipeline ，雖然沒有當作一個獨立的功能記載在文件上，但在 Laravel 的生命週期中卻扮演著相當重要的角色，而今天我們就是來試圖去理解它，並且將 Pipeline 獨立應用，看會發生什麼有趣的事情 Laravel Middleware以下的程式範例會使用 Laravel 官方的 github 上的程式碼，我們將會 ...

Laravel Notifications - 以 Slack 為例子故事是這樣的，最近筆者在研究如何擷取 RSS 內的資訊，並將最新資訊自動通知到 Slack 上，想寫一個訂閱 RSS 的機器人這樣的功能，於是乎在找資料的時候輾轉找到了 Laravel Notification 的 feature ，由於之前完全沒有使用過，所以就研究了一番，最後也真的有實作在自動通知的機器人的 code 裡面，以下來記錄一下學習的心得。 先來看看官方文件吧！在此先奉上官方文件 先跟著官方文件看一看這功能到底在幹嘛吧，首先官方告訴你 Notification 大致上就是可以讓你用來串接與通知有關的一些功能，內建也支援了一些 driver，例如： email, SMS, Slack… 之類的，接著開始告訴你該如何一步一步建構出這樣的功能 首先我們需要一個 Laravel 幫我們寫好的 Notification Class，於是我們一樣老方法呼叫 Artisan 幫我們把 Notification Class 建構出來 1php artisan make:notification HelloNotific ...

SOLID - SRP - 單一職責原則 （Single Responsibility Principle）這篇的主角是 SOLID 原則中的 S : 單一職責原則 （Single Responsibility Principle），由 Robert C. Martin 在 1990 年代提出 定義這邊我找到兩種定義，一種是在他出的書裡面提到的（書的連結） A class should have one, and only one, reason to change. 另一個是我在 Martin 的個人部落格中提到的 The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change. 兩種定義翻譯起來的意思其實大同小異 一個類別（軟體模組）應當只有唯一一個可以改變他的理由 這邊要特別提到，網路上有不少的文獻會將單一職責原則的定義解釋為「一個模組、類別或函式只做一件事情」，但我想這樣的解讀跟 Marti ...

晚點再說啦三部曲之四 - 精美的合作本文章使用的開發環境為 PHP : 7.3.11Laravel : 8.17.2Redis : 6.0MySQL : 8.0 前言老實說我不確定大家是不是會跟我有一樣的困擾，有的時候單獨的功能即便看懂了，也不知道該如何使用，更何況有時候的狀況是我根本連功能介紹都看不懂。即便我們好不容易知道了功能的用途，卻不知道該在什麼樣的情境下能夠聯想到可以使用。所以我在撰寫前面的文章的時候很努力的想要創造一個合理的情境，讓讀的人可以有一個想像力能夠去聯想到在什麼時候可以連結這些功能去運用。再者，筆者我在學習這一系列功能的初期根本不能夠理解這些東西的運作及個別的配合，也是經過了摸索及研究，好不容易才看得清這些功能大致上的全貌，所以我認為有時候我們必須將眼光拉遠一點，先去知道一個流程中哪個部分是負責什麼事情，再進而去理解每個部分如何達成這件事情，這樣對於學習上來說會比較容易一點。 所以呢，就像四大天王一定有五個人一樣，三部曲也是會有第四個部分，我們來將之前的三個部分給串連起來。 所以說我們來做一個「每分鐘自動寄 EDM 給所有使用者」的功能吧～ 我知道這功能聽起來很 ...

晚點再說啦三部曲之三 - Laravel Task Scheduling - 基礎篇本文章使用的開發環境為 PHP : 7.3.11Laravel : 8.16.1Redis : 6.0MySQL : 8.0 前言如上一篇所述，本篇要來探討「如何在某個時間點觸發」。 我們一樣來想像一個情境，假設今天你的客戶要做一個電商網站，他跟你說他需要在每週一收到一封上週的銷售報表，時間的結算週期為週一的凌晨00:00到週日的晚上12:00，這樣的話我們該如何去實作這樣的需求呢？ 我們可能會先想到，我們的網頁是在 Linux 上運作，那我們使用 Linux 上的 crontob 去設定週期，讓他在每週一的凌晨 00:05 去執行生成上週的報表並寄信的功能就好啦！ 的確，這可以解決問題，但當今天我們的電商網站逐漸茁壯，我們要記得報表越來越多元，每一種爆報表的時間週期也都不盡相同，而且因為流量的上升，我們常常需要開好幾台 Server 去做流量的分流，這意味著我必須在每一台 Server 上都定義相同的 crontab 才行，而如果這時候，我要新增一種新的寄送報表任務呢？又或是要更改某一個報表的寄送週 ...

晚點再說啦三部曲之二 - Laravel Artisan Console - 基礎篇本文章使用的開發環境為 PHP : 7.3.11Laravel : 8.16.1Redis : 6.0MySQL : 8.0 前言在開發的過程中，「如果我想要在特定的時間點做某些事情呢？」這種需求也相當常見，這個所謂的「某些事情」工作量可能非常龐大，很自然的我們可以想到，「要是我可以在某個時間點觸發某個動作，然後讓他把對應的工作放到某個地方慢慢消化就好了」，而「把對應的工作放到某個地方慢慢消化」這就是我們上一篇的主題，接下來我們要專注於，「如何在某個時間點觸發某個動作」 而這篇主要著重於如何處理「觸發某個動作」，而下一篇將要探討「如何在某個時間點觸發」 講到要「觸發某個動作」， Web 的開發者會很自然的想到要去寫一個可以瀏覽的網址去當作觸發的媒介，當我們瀏覽這個網址一次，就觸發對應的動作，這看起來相當合理也很直覺，但視情況而言，這種方式可能會成為一個不是很好的解決方式。 舉個例子來說吧，電商網站常常會有寄送廣告信件的功能，那們我如果將「寄送廣告給所有使用者」這個動作寫成一個網址，再讓知道網址的人瀏覽 ...

晚點再說啦三部曲之一 - Laravel Queue Job with Redis - 基礎篇本文章使用的開發環境為 PHP : 7.3.11Laravel : 8.16.1Redis : 6.0MySQL : 8.0 前言對於網站來說，一個 Request 就代表一個從頭開始生成到最後銷毀的生命週期，時常我們會遇到一種狀況 :「如果我有一件事情想要在 request 結束之後的才做呢?」舉個例子來說，試想我們有一個需求，需要在客戶下單後去寫入一個特殊的 Log ，以供之後做分析使用，而這個 Log 寫入普遍上來說又比較耗時(假設通常每一筆的寫入需耗費約一秒的時間成本)，那這樣不是會拖慢我們網站給使用者回饋的速度嗎?那麼在這種情境之下我們開如何去處理，從而節省那寶貴的一秒鐘呢? 想法其實很簡單，就像我們的日常工作一樣，有些東西不急，我們就先加入代辦事項，晚點再來做。而對於上面的需求來說，寫入特殊的 Log 並不是一定要立即更新那麼急迫的，所以我們要做的是 找一個地方，把不急的工作給放進去記錄下來 有空的時候我們就可以去這個地方把工作撿回來做完 這樣的情境與想法可以當作學習 Lar ...