Sign in Subscribe
Albert Chen

Albert Chen

PHP/後端工程師學習與面試指南
backend

PHP/後端工程師學習與面試指南

前言 每位後端工程師的工作資歷、工作環境與學習經歷都不一樣，大家心中對於後端工程師應該具備什麼技能、學習路線規劃和程度上 Junior/Senior 的定義也不相同。 本文旨在分享筆者個人在這幾年在軟體開發一路上學習路線的經驗，與近幾年累計大約超過百人以上的面試經歷提供大家在學習路線和未來面試過程中有個參考依據。 文章標題命名為 PHP/後端工程師主要是個人工作經歷上習慣使用的主要語言為 PHP，但是本文的內容也能適用在其他後端語言（如：NodeJS, Golang, Python 等），應該說 PHP 和其他語言的工程師除了使用語言的表層差別外，本質上在 Web 中所面臨與要解決的後端問題其實相去不遠。 工程師職級定義 在不同行業或公司中對於工程師 Junior 與 Senior 定義的標準都不相同，為了對齊下面段落中對於職級標準，本文借用 Avance Venture Lab 所分享的工程師職級定義，由比較抽象的層次來定義不同職級的標準： avancevl.github.io/_main/people/engineering_level.md at master ·
18 min read
在 PHPUnit 中測試 protected 和 private 方法
php

在 PHPUnit 中測試 protected 和 private 方法

前言 就理論上沒有理由要針對已封裝的方法進行測試，對於那些 protected 和 private 方法一般會採取間接的測試方法。意即透過測試 public 方法來驗證裡面所呼叫的封裝方法是否符合預期邏輯，而對外部使用者來說，針對 public 方法的單元測試便會順便包含到這些封裝方法的測試，封裝方法本身就是 public 方法的一部分，他們也不需要去分辨哪些是封裝過的邏輯，因為只需要關注 public 方法即可。 封裝本身代表著：針對外部使用者本來就不需要了解，也根本不了解的成員或方法進行隱藏。單元測試本身就是模擬外部使用者的動作，那當然也只需要對測試目標 public 的方法進行模擬與驗證。 如果你發現測試 public 方法無法協助你測到所有想測試的封裝方法，大部分代表在設計本身上就有問題或是那些 protected 和 private 方法在現階段是沒有必要的，屬於 over design。 這其實也是 TDD 提倡的精神，如果全部的測試都符合預期，就代表功能完成了。而且按照測試來撰寫的程式，幾乎不會出現測試無法涵蓋的程式，因為程式本來就是為了滿足測試而撰寫的。
3 min read
Swoole - 基本概念
swoole

Swoole - 基本概念

Process 與 Thread Process（行程、進程、處理程序）與 Thread（執行緒、線程）是作業系統中相當重要的概念。因為他們相對比較抽象，且通常 PHP 開發者對於兩者的概念較薄弱，但是在 Swoole 開發中會運用大量 Process 與 Thread 的觀念，所以在開始學 Swoole 之前對於他們必須有基本的了解。 Process Process 是一個程式執行後實體化的概念，在分時系統年代中 Process 是程式運作的基本單位。一個程式可以產生多個 Process（一對多關係），若干 Process 有時可能與同一個程式相關聯，且每個 Process 皆可以同步（循序）或非同步（平行）的方式獨立執行。Process 需要一些資源才能完成工作，如：CPU、記憶體、
8 min read
透過 Swoole 加速 Laravel 效能
swoole

透過 Swoole 加速 Laravel 效能

Laravel 的速度瓶頸 雖然 Laravel 非常的強大與優美，但是對於 PHP 這種直譯式腳本語言來說，像 Laravel 這種複雜及龐大的框架會使得速度比起原生的 PHP 還要慢上許多，常見的優化方式有以下幾種： * 使用 Laravel 提供的指令來做快取優化 php artisan optimize php artisan config:cache php artisan route:cache php artisan optimize 在 Laravel 5.5 中已經列為 deprecated，無實際作用（不需要了）。 * 使用 Opcahce 加速 PHP 在每次執行時都會由 Zend 引擎先編譯成 OpCode。最後 Zend 虛擬機再執行
4 min read
Swoole 相關學習資源整理
swoole

Swoole 相關學習資源整理

有鑒於 Swoole 學習資源在網路上較為分散，所以特地整理關於 Swoole 的一些學習資源供參考。 官方資源 * 說明文件：https://wiki.swoole.com/ * API 文件：https://rawgit.com/tchiotludo/swoole-ide-helper/english/docs/index.html * 討論區：http://group.swoole.com/ * 英文文件：https://github.com/swoole/swoole-docs 官方的文件資源可能有部分內容並不是最新版本的說明 非官方資源 * Awesome Swoole： https://github.com/swooletw/awesome-swoole * Easy Swoole：https://linkeddestiny.gitbooks.io/easy-swoole/
1 min read
PHP 的性能猛獸 - Swoole
swoole

PHP 的性能猛獸 - Swoole

前言 PHP 自 1995 年發展至今已將近 30 年，經過不斷發展迭代的 PHP 語言儼然與大家古老中刻板印象的概念大相逕庭。現今的 PHP 8 除了具備許多現代化的語法與特性外，在近 10 年中 Symfony 與 Laravel 等開發社群的持續蓬勃的發展加持下，Laravel 更是成為了在跨語言的 Web 框架中人氣居高不下的開源專案，加上原本的 Wordpress、Drupal、WooCommerce 等生態也使得 PHP 一直在現今 Web 系統中始終保持很高的使用占比。 由於 PHP 先天上程式運行模型的設計與 Blocking I/O 的特性，加上許多現代的熱門 Web 框架都內建了許多功能，使得 PHP 的效能問題常常變成大家的討論議題。事實上在 PHP 7
7 min read
在Laravel/Lumen中快速整合Invisible reCPATCHA
laravel

在Laravel/Lumen中快速整合Invisible reCPATCHA

前言 在上一篇的文章中，我們提到了今年Google宣佈推出最新版的機器人識別技術-Invisible reCPATCHA，而在這片文章中將教你如何快速的在你的Laravel專案中應用這項技術。 前端驗證指南 根據Google官方的文件指南看來，其實Invisible reCPATCHA的背後驗證的技術與前一代的no captcha應該不會相差太多，使用與前一代的API相同的引入位置: https://www.google.com/recaptcha/api.js，但既然Invisible reCPATCHA是完全隱形的，那該如何觸發進行驗證動作的時機呢? 其實很簡單，API只需要和你的submit button的送出事件綁定在一起，API即可在你正式送出表單資料前與Google的驗證伺服器完成驗證，以下為Google官方文件所提供的前端範例: <html> <head> <title>reCAPTCHA demo: Simple page</title> <script src="https://www.google.com/
4 min read
深入淺出capthca驗證
recaptcha

深入淺出capthca驗證

傳統Capthca的演進 隨著十年前Web2.0的世界越來越發達，舉凡論壇或向留言板這樣的服務開始盛行，隨之而來的造成網路爬蟲與機器人也不斷進步，網路上開始大量出現藉由在各大論壇或留言版留垃圾廣告文的機器人興起。因此為了防堵機器人模擬人類的行為進行註冊或留言，開始出現了圖形辨識碼的技術，這項技術假使只有人類能辨別出圖形中的文字，像下面這些都是圖形驗證碼的範例: reCAPTCHA在2009年被Google收購，然後推出了在第一代的recpathca中提供了以圖形文字識別為基礎的API，供網站介接使用，而不需要耗費自己機器上的運算資源來產生圖形驗證碼的圖片，以下為架構流程圖: 但同時也因為電腦的運算能力與圖形文字識別(OCR)的不斷進步，你可以看到這些圖形加入了大量的變形、扭曲、雜訊、模糊化來使圖形驗證碼變得更加難以識別，但是這不只對機器難以識別，同時也對人類的辨讀上造成極大的阻礙。而且近年來隨著機器學習與**圖形文字識別(OCR)**的進步，甚至到後來機器辨識的結果能比人類辨識還來得更準確且快速許多，以下為辨識範例: 所以現在主流的辨識機制都已經漸漸放棄這種圖形文
4 min read
使用Hashids取代increment ID
hashid

使用Hashids取代increment ID

一直以來該使用increment ID或uuid當作是資料庫主鍵一直是兩派爭論不休的議題。 increment ID的優點相當的顯而易見，使用上簡易方便並具有佔用空間小及順序性等優點，個人覺得比較容易注意到的缺點大概就是id容易被外人進行猜測，雖然說這個部分應該是系統開發者應注意的事，但總覺得increment ID這種顯示方式醜醜的(或應該說太漂亮?) 此外increment ID還有一個缺點就是當你有資料轉移或合併的需求時，increment ID會讓你很容易發生id重複的問題。 反觀uuid他最大的特點就是你光從id上來看無法看出任何資訊(例如:順序)，他就長得像這樣: 05177f3c-bdf7-4b96-927d-f6f636175a27，通常他是128bit長的數字，並且用16進制表示。缺點是在很多情形下作為主鍵建立索引查詢效率低。 因此在我最近的一個專案中，我嘗試使用Hashids當作是我的替代方案，我資料表的主鍵依然是使用increment ID，但是在id暴露給外部時，他會經由Hashids幫你算成像GlaHquq0的結果，他是可以解密的，所以名字上雖
3 min read
從Gandi將DNS轉移到Cloudflare

從Gandi將DNS轉移到Cloudflare

Gandi Gandi是一間來自於法國的網域名稱註冊商，於2015年的時候推出繁體中文的介面，在台灣這一兩年來廣告打滿兇的，可以很常在大大小小的技術型聚會提供贊助還有優惠碼。 Gandi可能現階段對台灣人而言還很陌生，不是大多數台灣人要註冊網域時的首選，但他是ICANN最早認可的域名註冊商之一，在法國算得上是數一數二大的域名註冊商。 這次會選用Gandi是因為看上他免費的隱藏域名資訊的服務，這在很多其他域名註冊商是要收費的服務，使用了隱藏域名資訊後，你的域名在whois上看起來會像這樣: 除了姓名之外，大部分的資訊都是Gandi當作代理幫你留下資料，好處是可以避免像電話、email這種個資那麼容易就攤在陽光底下。 但Gandi在操作上就不是那麼友善，例如:你的帳號只能使用它給你的代號XX12345-GANDI，但最令人受不了的是他設定DNS紀錄的介面操作非常繁瑣，而且DNS同步時間會讓你等到天荒地老! 索性就直接將DNS交由Cloudflare來代管。 Cloudflare Cloudflare最為人所知的服務就是免費無限流量的CDN服務，但除了CDN服
3 min read