提升程式設計師的面試力 - Ch2 - 鏈結串列(Linked List)鏈結串列(Linked List)是一種表示節點順序的資料結構。 單向串列(Singly Linked)：每個節點都指向鏈結串列中的下一個節點 雙向串列(Doubly Linked)：每個節點提供指向下一個節點及前一個節點的指標 如果我們想找到串列中的第 K 的元素的話，我們就必須迭代 K 次才能夠找到 Linked List 的優點是，當你想加入或刪除開頭元素時，可以在嘗試時間內完成 建立 Linked List123456789101112131415class LinkedListNode{ public LinkedListNode $next; public int $data; public function __construct(int $data) { $this->data = $data; } public function appendToTail(LinkedListNode $node): voi ...

大話 AWS 雲端架構 - Ch27 - Serverless 架構總覽 專注在應用，而不是架構 不免俗的要看一下各種 Xaas 的比較圖 27.2 Serverless 架構的運行生態 27.3 Serverless 在 AWS 上的 Solution 27.4 Serverless 延伸的微服務架構

大話 AWS 雲端架構 - Ch16 - ElastiCacheElasticCache 簡單來說就是單獨管理快取的一種服務 16.3 兩種常見的暫存資料操作手法Lazy-LoadingLazy-Loading 又稱延遲載入，大意上是只在有人需要資料的時候才將資料做快取，這樣下次有人需要同筆資料的時候就可以快速的回覆資料給使用者 Write-Through簡單來說，就是當我們寫入資料的時候也寫一份到快取內，則使用者需要資料的時候就可以即時反應 Lazy-Loading 與 Lazy-Loading 的比較 Lazy-Loading Write-Through 用戶第一次存取資料的時候，才寫入快取中 資料寫入資料庫的時候，同時寫一份到快取中 第一次提取時速度會比較慢 提取速度快 被動快取資料 主動快取資料 節省記憶體用量 記憶體用量大 第一次查詢資料的時候速度會較慢，另外如果資料庫資料有更新而沒有順便更新快取的話，使用者可能會取用到舊的資料 會快取很多沒有要用到的資料，且寫入資料的時候會更花時間 16.4 ElastiCache 的兩種底層引擎 - Memc ...

團隊如何交付正確的軟體 - ch8 - 提煉需求規格成功的團隊在討論關鍵實例後，不會直接使用原本的例子，他們會從中**提煉 spec(Refining the specification)**。他們會從關鍵實例中提取精華，將其轉化成清楚且明確的定義，並去除不相關的細節。 附帶實例的 Spec. 即為驗收測試 一個良好的 spec ，再與實例結合後，其實就是有效的驗收測試所描述的功能 一個優質的需求規格範例免費送貨服務 VIP 用戶購買一定量的書籍後，為其提供免運費服務。免運費服務不提供給普通用戶。 要獲得免運非服務必須要購買至少五本書籍 實例 客戶類型 購物車中的產品 送貨服務 VIP 5 本書 免費、標準 VIP 4 本書 標準 普通 10 本書 標準 VIP 5 台洗衣機 標準 VIP 5 本書、1 台洗衣機 標準 提煉需求規格時需要關注的要點理想的情況下，附帶實例的 spec 應該從業務角度明確地定義所需的功能，而不是去定義系統該如何運作，在完成了功能之後， spec 將會成為系統的說明文件 好的 spec 應該要符合下面所說的要點： 實例 ...

大話 AWS 雲端架構 - Ch4 - EC24.1 添購伺服器的流程添購實體 Server 的流程 123456789| 軟體市場| 作業系統 | 硬體規格 | 系統調校＋軟體安裝 | 硬碟擴充 | 標記資產| 防火牆建立 | 連線金鑰確認∇ 4.2 AWS 的 EC2 虛擬主機服務在 AWS 的雲端服務中有一款 EC2 服務，能夠動態租用虛擬主機(Instance)，流程上也跟購買實體主機的概念大致相同 123456789| 軟體市場 ◄---------------► AMI Marketplace (Amazon 系統映像市集)| 作業系統 ◄---------------► AMI (Amazon 系統映像)| 硬體規格 ◄---------------► Instance (虛擬主機)| 系統調校＋軟體安裝 ◄-------► Userdata (使用者資料)| 硬碟擴充 ◄---------------► EBS ()| 標記資產 ◄---------------► Tag (標籤)| 防火牆建立 ◄--------------► Secu ...

PHP8 - Match ExpressionPHP 8 新增了一種叫做 match 的方法，幾乎是可以完全取代我們原本熟知的 switch ，同時帶來了一些好處，以下我們看一段範例比較一下 switch 跟 match Switch v.s. Match 1234567891011121314151617181920212223// switchswitch ($operator) { case 'plus': $result = $a + $b; break; case 'minus': $result = $a - $b; break; case 'product': $result = $a * $b; break; case 'division': $result = $a / $b; break;}// match$result = matc ...

PHP8 - Union Types在 PHP 8 之前，雖然已經有支援 type hint ，但如果我的 function 回傳有可能不只一種型別的時候，我們只能透過 phpdoc 去描述這件事情，而且同時我可能要把原本設置的單一型別 type hint 撤除，這樣的方式在實務層面缺乏了主動的檢查機制 PHP 8 以前回傳多 type 的寫法 1234567/** * @param int|float $number * @return int|float */ public function test($number) { return $number; } 不過有一個特例，在 PHP 8 之前有支持一種多形別的 type hint ，算是我們常常用到的情形，當今天我們的變數是可以指定爲某種 type 或是 null 的時候，我們可以這樣指定 變數接受 array 或是 null 12345678/** * @param array|null $arr * @return array|null */public function test(?array ...

Testing Laravel - 測試 Middleware - 取用 url 路徑上的變數本文章使用的開發環境為PHP : 8.0.8Laravel : 8.51.0 這週在開發上遇到了一個情境，我想要對某一個 Route 的多個 Middleware 中的其中一個 Middleware 去寫測試 帶有多個 Middleware 的 Route 1234567Route::get('lets_test_middleware/{message}', function () {}) ->middleware([ OtherMiddleware1::class, WaitForTestMiddleware::class, // 測試目標 OtherMiddleware2::class, ]) ->name('lets_test_middleware'); 而我在 WaitForTestMiddleware 中則會取用到 lets_test_ ...

PHP8 - Named Arguments介紹今天來介紹一個 PHP8 新增的功能，叫做 「Named Arguments」，如字面上的意思，我們可以為一個參數做命名的動作。 簡單的示範一下 123456789public function demo($foo, $bar){}// php 8 以前demo('fooooooo', 'baaaaaar');// php 8 之後，我們可以在輸入的值前面去指定我要丟的參數demo(foo: 'fooooooo', bar: 'baaaaaar'); 優點讓執行函數的時候可以指定參數名稱有幾個好處 更好的可讀性12345public function demo($foo, $bar){}demo(foo: 'fooooooo', bar: 'baaaaaar'); 在呼叫函式的時候，我們可以很清楚的知道我們的每一個值是要給哪一個函式內的變數使用，以往我們可能會因為命名上的差異導 ...

團隊如何交付正確的軟體 - ch3 - 活的說明文件一般來說， Spec. 實例化 (Specification by Example , SBE) 有兩種比較流行的模型 以驗收測試為中心的模型 通稱為「驗收測試驅動開發」(Acceptance Test-Driven Development, ATDD) 著重自動化測試，優點是可以使開發目標更明確，也能確實防止功能退化 以系統行為規範為主導的模型 通稱為「行為驅動開發」(Behavior-Driven Development, BDD) 著重於制定系統行為的場景，透過協作來釐清 spec ，建立專案關係人與交付團隊之間的共識。此模式也認為透過自動化測試來防止功能退化相當重要。 這兩種模式沒有優劣的分別，不同模型有不同的用途在，書中提到如果團隊有許多功能品質上的問題，那麼以驗收測試為中心的模型效用比較好。當一切運行順暢，針對中期或短期軟體的交付說明來說的話，以系統行為規範為主導的模型會比較好用。 這兩個模型中主要都是將 spec 可以去做實例化，共通的好處在於，透過自動化測試來預防功能的退化。 為什麼我們需要權威的說明文件通 ...