The Integration of Laravel with Swoole (Part 4) In the previous articles you have learnt how to accelerate your Laravel applications with Swoole. But there's another bottleneck in most real use cases. You can't avoid any I/O waiting operations in
The Integration of Laravel with Swoole (Part 3) The core concept of Laravel is its IoC container. If you don't know much about Laravel's IoC Container, I highly suggest you read Laravel's Dependency Injection Container in Depth before reading this article.
The Integration of Laravel with Swoole (Part 2) In this article we're going to talk about how we can integrate Laravel with Swoole's structure in different solutions and their pros and cons. Integration Solutions Let's define our goals first: The integration
The Integration of Laravel with Swoole (Part 1) In my previous article: Speed Up Laravel on Top of Swoole on Laravel News, I have shown you a big picture why Laravel performs slow in traditional PHP lifecycle. In this series of
Laravel's Dependency Injection Container in Depth Laravel has a powerful Inversion of Control (IoC) / Dependency Injection (DI) Container. Unfortunately the official documentation doesn't cover all of the available functionality, so I decided to experiment with it and document it
swoole Speed Up Laravel on Top of Swoole What is Swoole? Swoole is a production-grade async programming framework for PHP. It is a PHP extension written in pure C language, which enables PHP developers to write high-performance, scalable, concurrent TCP, UDP,
php 在 PHPUnit 中測試 protected 和 private 方法 前言 就理論上沒有理由要針對已封裝的方法進行測試，對於那些 protected 和 private 方法一般會採取間接的測試方法。意即透過測試 public 方法來驗證裡面所呼叫的封裝方法是否符合預期邏輯，而對外部使用者來說，針對 public 方法的單元測試便會順便包含到這些封裝方法的測試，封裝方法本身就是 public 方法的一部分，他們也不需要去分辨哪些是封裝過的邏輯，因為只需要關注 public 方法即可。 封裝本身代表著：針對外部使用者本來就不需要了解，也根本不了解的成員或方法進行隱藏。單元測試本身就是模擬外部使用者的動作，那當然也只需要對測試目標 public 的方法進行模擬與驗證。 如果你發現測試 public 方法無法協助你測到所有想測試的封裝方法，大部分代表在設計本身上就有問題或是那些 protected
swoole Swoole - 基本概念 Process 與 Thread Process（行程、進程、處理程序）與 Thread（執行緒、線程）是作業系統中相當重要的概念。因為他們相對比較抽象，且通常 PHP 開發者對於兩者的概念較薄弱，但是在 Swoole 開發中會運用大量 Process 與 Thread 的觀念，所以在開始學 Swoole 之前對於他們必須有基本的了解。 Process Process 是一個程式執行後實體化的概念，在分時系統年代中 Process 是程式運作的基本單位。一個程式可以產生多個
laravel 在 Laravel 實現自動 Refresh JWT 機制 簡介 JWT JSON Web Token (JWT) 是由 Auth0 於 2015 年所提構出的一個新 Token 機制，嚴格來說 JWT 並不是一個新的技術或軟體，而是一套規範（RFC-7519）。基本上 JWT 包含以下三種資訊： Header {"alg":"HS256","typ":"JWT&
swoole 透過 Swoole 加速 Laravel 效能 Laravel 的速度瓶頸 雖然 Laravel 非常的強大與優美，但是對於 PHP 這種直譯式腳本語言來說，像 Laravel 這種複雜及龐大的框架會使得速度比起原生的 PHP 還要慢上許多，常見的優化方式有以下幾種： 使用 Laravel 提供的指令來做快取優化 php artisan optimize php artisan config:cache php artisan route:cache php artisan optimize 在 Laravel
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 PHP 也有 Day #33 - Swoole: 重新定義 PHP 這次有幸受邀擔任九月份 PHP 也有 Day 的講者來分享關於 Swoole 的一些基本應用。在這裡分享演講簡報與範例 Repo。 議題大綱 Swoole 的入門介紹與基本應用 Swoole 簡介 安裝與編譯 HTTP Server Websocket Server Async IO Memory Table Coroutine Swoole Server 模型架構解說 Master Reactor Manager Worker Task Worker
UniMD 開發紀錄 （一） 前言 由於 HackMD 提供了非常好用的線上 Markdown 共筆平台，但我們公司內部自己使用上還有其他想達到的需求，如：進階檔案共享權限、團隊的概念、檔案資料夾管理、筆記備註等功能，於是我們就決定仿效 HackMD 自己重新開發屬於自己的一套 UniMD。 開發技術 我們團隊熱愛 PHP 語言和擅長 Laravel 框架，所以和 HackMD 所採用的 NodeJS 不同，我們採用 PHP 為主要開發的技術，並且搭配 Swoole 做為我們的
swoole PHP 的性能猛獸 - Swoole 前言 PHP 發展至今已經 20 餘年，現今許多網站有相當高的比例都是以 PHP 所建構而成，然而一直以來 PHP 為人所詬病的就是他的效能問題。尤其是現今許多的開發框架雖然強大優雅，但同時也因為框架的複雜度讓 PHP 的效能更加倍放大來檢視，甚至成為許多人不選擇使用框架開發的原因。 雖然在新版的 PHP 7 中比起以往效能上有重大的突破，但在大多數人眼中 PHP 似乎始終都不是以效能為考量時的主要首選開發語言。但是接下來要介紹的 Swoole 可能會讓你重新定義 PHP，甚至更加倍地愛上他。 PHP 面對大流量或高效能需求時，也有許多優秀的解決方案，但不在本篇文章的主題內，故不細加說明。
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> <
recaptcha 深入淺出capthca驗證 傳統Capthca的演進 隨著十年前Web2.0的世界越來越發達，舉凡論壇或向留言板這樣的服務開始盛行，隨之而來的造成網路爬蟲與機器人也不斷進步，網路上開始大量出現藉由在各大論壇或留言版留垃圾廣告文的機器人興起。因此為了防堵機器人模擬人類的行為進行註冊或留言，開始出現了圖形辨識碼的技術，這項技術假使只有人類能辨別出圖形中的文字，像下面這些都是圖形驗證碼的範例: reCAPTCHA在2009年被Google收購，然後推出了在第一代的recpathca中提供了以圖形文字識別為基礎的API，供網站介接使用，而不需要耗費自己機器上的運算資源來產生圖形驗證碼的圖片，以下為架構流程圖: 但同時也因為電腦的運算能力與圖形文字識別(OCR)的不斷進步，你可以看到這些圖形加入了大量的變形、扭曲、雜訊、模糊化來使圖形驗證碼變得更加難以識別，但是這不只對機器難以識別，同時也對人類的辨讀上造成極大的阻礙。而且近年來隨著機器學習與**圖形文字識別(OCR)**的進步，甚至到後來機器辨識的結果能比人類辨識還來得更準確且快速許多，以下為辨識範例: 所以現在主流的辨識機制都已經漸漸放棄這種圖形文字的識別。 No Captcha
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的結果，他是可以解密的，所以名字上雖然叫做Hashids，但本質和hash一點關係也沒有。 Hashids在各個程式語言都有實作library，根據官網上的實作原理，
從Gandi將DNS轉移到Cloudflare Gandi Gandi是一間來自於法國的網域名稱註冊商，於2015年的時候推出繁體中文的介面，在台灣這一兩年來廣告打滿兇的，可以很常在大大小小的技術型聚會提供贊助還有優惠碼。 Gandi可能現階段對台灣人而言還很陌生，不是大多數台灣人要註冊網域時的首選，但他是ICANN最早認可的域名註冊商之一，在法國算得上是數一數二大的域名註冊商。 這次會選用Gandi是因為看上他免費的隱藏域名資訊的服務，這在很多其他域名註冊商是要收費的服務，使用了隱藏域名資訊後，你的域名在whois上看起來會像這樣: 除了姓名之外，大部分的資訊都是Gandi當作代理幫你留下資料，好處是可以避免像電話、email這種個資那麼容易就攤在陽光底下。 但Gandi在操作上就不是那麼友善，例如:你的帳號只能使用它給你的代號XX12345-GANDI，但最令人受不了的是他設定DNS紀錄的介面操作非常繁瑣，而且DNS同步時間會讓你等到天荒地老! 索性就直接將DNS交由Cloudflare來代管。 Cloudflare Cloudflare最為人所知的服務就是免費無限流量的CDN服務，但除了CDN服務外，他的DNS和SSL功能也是免費的!而且他的DNS設定頁面非常容易操作，介面設計上也比起其他的DNS提供商好用的多。 此外他還提供了免費的Flexible SSL和Full SSL，讓你使用SSL除了像SSL憑證提供商購買或使用Let's