跳至主要内容

14 篇文章 含有標籤「php」

檢視所有標籤

· 閱讀時間約 11 分鐘
Vincent Chi

容器化（Containerization），這是一個由 Docker 公司所發揚光大的一種技術，它能夠很好地封裝應用程式與所需函式庫，而且通常有著比 虛擬化（Virtualization） 更高的效能。

一般來說，編譯式語言都很容易被容器化，例如 C/C++ 或 Golang，這是因為只需要在容器中設定好相依函式庫（通常是指動態函式庫），其編譯出的執行檔就可以直接在容器中運行。

這對 PHP 這類直譯式語就不是個好消息，其運行環境往往受制於 Apache PHP Module 或 PHP-FPM，再加上現代 PHP 往往會整合 Composer 進行相依性套件管理，這使得其處境更加雪上加霜。

備註

Python 或 Nodejs 這類直譯式語言，往往也會藉助一些協定（例如 Python 依賴的 WSGI 或 ASGI）或工具（例如 PM2 或 Forever）來佈署。

· 閱讀時間約 10 分鐘
Vincent Chi

七月中旬，我離開了 Rosetta.ai。

作為最後幾份工作，我與同事們一起設計了一系列的 PHP 軟體工程師（後端）的題目。其中，實作題的設計是由我所主導，而我個人認為它是我設計過最優秀的題目。

因為該題目已獲公司主管同意已經公佈在 PTT 的 Soft_job 版上，所以這邊寫下當時我設計題目的理念與解析。

備註

註：雖然 PTT 的討論串到最後演變成薪資之爭模糊焦點有些可惜，不過這並不妨礙這份題目本身的設計。

· 閱讀時間約 7 分鐘
Vincent Chi

Laravel 有著優秀的預定義認證（Authentication）功能，讓開發者不必費心在重複製作用戶註冊、登入、登出等功能。

無論是早期的 laravel/ui 還是 laravel/fortify 都提供了安全、完整且方便的解決方案。

Kratos 是由 Ory Corp 所提供的開源認證解決方案，藉由設定檔的方式可以靈活設計認證模型（例如帳號密碼、第三方社群或 WebAuth 等 passwordless 的形式）

· 閱讀時間約 10 分鐘
Vincent Chi

在 2021 年中旬，我曾經寫過一篇 Laravel 環境設定，不過因為工具上有些許變化，所以在 2022 年末將其重新整理一遍。

事先聲明，本文中所寫的環境設計題專門為了我自己的工作流而打造。如果不適合你，那你是對的，請儘管改成適合你的工作流。

· 閱讀時間約 5 分鐘
Vincent Chi

蛤？PHP 字串比較還要特別寫一篇文章嗎？

會開始研究這個問題，主要是因為在 Laravel Fortify 中使用 hash_equals() 這個函式比對字串。

· 閱讀時間約 15 分鐘
Vincent Chi

網路上有大量的文章探討如何使用 Laravel Queue，可惜的是，它們通常就給個 Hello World 式的範例，並未深入探討。

本篇文章會從 Laravel Queue 的實際行為上進行分析，並且著重於「失敗」的案例。

· 閱讀時間約 8 分鐘
Vincent Chi

眾所周知，在 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 仍未見改善，這也是促使我寫下本文的動機。

· 閱讀時間約 7 分鐘
Vincent Chi

Google reCAPTCHA 是一個人類行為驗證機制，用於阻止爬蟲或類似的機器行為。

  • v1 (2007)：基於驗證碼
  • v2 (2014)：I'm not a robot 勾選框
  • v3 (2018)：對當前用戶進行評分
  • Enterprise (2020)：與 v3 類似，但加入更多功能（如密碼洩露檢測）

就目前為止，除了 Google 官方的 SDK 之外，幾乎找不到針對 reCAPTCHA enterprise 實作的 PHP 套件（大多都是 reCAPTCHA v2 及 v3）。

· 閱讀時間約 5 分鐘
Vincent Chi

隨著 MySQL 5.7 加入對 JSON 格式的原生支援，開始有許多開發團隊把 RDBMS 當 NoSQL 使用。本篇文章對於效能議題暫且擱置，顯而易見地，越自由的格式往往會帶來更沉重的維護成本。

舉例來說，目前資料庫中可能存在以下型式的資料

{
    "age": 16,
    "avatar": "avatars/avatar.png"
}

然而可能因為系統改版，需要更精準地計算用戶年齡，所以將 age 欄位改為 birth

{
    "birth": "2002-01-01",
    "avatar": "avatars/avatar.png"
}