PHP 的過去、現在與未來
這原本是我打算作為 PHP 教學系列的序章,既然該教學已經胎死腹中,不如就移花接木一下把我當年的想法記錄下來。
這個標題中的「過去」、「現在」與「未來」,其實並沒有一個明確的時間點、甚至定義也會隨時間與環境而有所變化。
這原本是我打算作為 PHP 教學系列的序章,既然該教學已經胎死腹中,不如就移花接木一下把我當年的想法記錄下來。
這個標題中的「過去」、「現在」與「未來」,其實並沒有一個明確的時間點、甚至定義也會隨時間與環境而有所變化。
容器化(Containerization),這是一個由 Docker 公司所發揚光大的一種技術,它能夠很好地封裝應用程式與所需函式庫,而且通常有著比 虛擬化(Virtualization) 更高的效能。
一般來說,編譯式語言都很容易被容器化,例如 C/C++ 或 Golang,這是因為只需要在容器中設定好相依函式庫(通常是指動態函式庫),其編譯出的執行檔就可以直接在容器中運行。
這對 PHP 這類直譯式語就不是個好消息,其運行環境往往受制於 Apache PHP Module 或 PHP-FPM,再加上現代 PHP 往往會整合 Composer 進行相依性套件管理,這使得其處境更加雪上加霜。
七月中旬,我離開了 Rosetta.ai。
作為最後幾份工作,我與同事們一起設計了一系列的 PHP 軟體工程師(後端)的題目。其中,實作題的設計是由我所主導,而我個人認為它是我設計過最優秀的題目。
因為該題目已獲公司主管同意已經公佈在 PTT 的 Soft_job 版上,所以這邊寫下當時我設計題目的理念與解析。
註:雖然 PTT 的討論串到最後演變成薪資之爭模糊焦點有些可惜,不過這並不妨礙這份題目本身的設計。
Laravel 有著優秀的預定義認證(Authentication)功能,讓開發者不必費心在重複製作用戶註冊、登入、登出等功能。
無論是早期的 laravel/ui 還是 laravel/fortify 都提供了安全、完整且方便的解決方案。
Kratos 是由 Ory Corp 所提供的開源認證解決方案,藉由設定檔的方式可以靈活設計認證模型(例如帳號密碼、第三方社群或 WebAuth 等 passwordless 的形式)
在 2021 年中旬,我曾經寫過一篇 Laravel 環境設定,不過因為工具上有些許變化,所以在 2022 年末將其重新整理一遍。
事先聲明,本文中所寫的環境設計題專門為了我自己的工作流而打造。如果不適合你,那你是對的,請儘管改成適合你的工作流。
蛤?PHP 字串比較還要特別寫一篇文章嗎?
會開始研究這個問題,主要是因為在 Laravel Fortify 中使用 hash_equals() 這個函式比對字串。
網路上有大量的文章探討如何使用 Laravel Queue,可惜的是,它們通常就給個 Hello World 式的範例,並未深入探討。
本篇文章會從 Laravel Queue 的實際行為上進行分析,並且著重於「失敗」的案例。
眾所周知,在 PHP 中 parse_url() 這個函式遲遲未支援 UTF-8,這導致一些英文、數字以外的 Host, Path, Query 及 Fragment 都會解析錯誤。
(psysh) >> parse_url('https://中文.台灣/你好嗎?我=很好&大家都很好#你呢?')
=> [
"scheme" => "https",
"host" => b"䏿__.å_°ç_£",
"path" => b"/ä½ å¥½å__",
"query" => b"æ__=å¾_好&大家é_½å¾_好",
"fragment" => b"ä½ å_¢ï¼_",
]
這個問題直到 PHP 8.1 仍未見改善,這也是促使我寫下本文的動機。
Google reCAPTCHA 是一個人類行為驗證機制,用於阻止爬蟲或類似的機器行為。
就目前為止,除了 Google 官方的 SDK 之外,幾乎找不到針對 reCAPTCHA enterprise 實作的 PHP 套件(大多都是 reCAPTCHA v2 及 v3)。
隨著 MySQL 5.7 加入對 JSON 格式的原生支援,開始有許多開發團隊把 RDBMS 當 NoSQL 使用。本篇文章對於效能議題暫且擱置,顯而易見地,越自由的格式往往會帶來更沉重的維護成本。
舉例來說,目前資料庫中可能存在以下型式的資料
{
"age": 16,
"avatar": "avatars/avatar.png"
}
然而可能因為系統改版,需要更精準地計算用戶年齡,所以將 age 欄位改為 birth
{
"birth": "2002-01-01",
"avatar": "avatars/avatar.png"
}