Neil's Note

要去呈現 three.js 的畫面需要至少這三個要素 scene (場景) camera (攝影機) renderer (渲染器) 產生物件三要素 geometry: three.js 中的物件, 包含所有的點跟面 material: 幫 geometry 加上顏色 mesh: 把 material 應用到 geometry 上面，可以直接把 mesh 放到 scene 中，讓 mesh 可以在 scene 中自由的移動 const geometry = new THREE.BoxGeometry( 1, 1, 1 ); const material = new THREE.MeshBasicMaterial( { color: 0x00ff00 } ); const cube = new THREE.Mesh( geometry, material ); scene.add( cube ); camera.position.z = 5; 上面程式碼的意思是產生一個 BoxGeometry 產生一個 0x00ff00 顏色的 material 產生一個可以放在 scene 中的 mesh, mesh 將 geometry 與 material 組合成一個可以在場景中自由控制的物件，並加入到 scene 中

Virtual Columns in InnoDB INFORMATION_SCHEMA 記錄了一些關於 InnoDB 管理的 schema 物件的 metadata, 這些資訊來自於 InnoDB 內部 system tables, 這些資訊沒辦法跟一般 table 一樣, 可以直接查詢, 傳統上的做法應該是解析 SHOW_ENGINE_INNODB_STATUS 的輸出. 不過 INFORMATION_SCHEMA 這張表有提供介面可以讓你使用 SQL 查詢這類型的資料. 這個跟 Virtual Column 有什麼關係?  Virtual Column 其實並不會儲存實體資料在 table 的 clustered index 內! 不過 Virtual Column 的 metadata 會存在 InnoDB 的 INFORMATION_SCHEMA  的 SYS_COLUMNS 內！ 舉例來說 ## 建立一張表 t 有著 a, b, c 三個欄位, c 是 virtual column CREATE TABLE t (a INT, b INT, c INT GENERATED ALWAYS AS(a+b), PRIMARY KEY(a)); ## SELECT * FROM t; +----+------+------+ | a | b | c | +----+------+------+ | 11 | 3 | 14 | +----+------+------+ ## 從 SYS_COLUMNS 中觀察 SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_COLUMNS WHERE TABLE_ID IN ( SELECT TABLE_ID FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME LIKE "t%" ); +----------+------+-------+-------+--------+-----+ | TABLE_ID | NAME | POS | MTYPE | PRTYPE | LEN | +----------+------+-------+-------+--------+

關於 CORS 最簡單的理解大概是在 A 網域的頁面呼叫了 B 網域的資源 時，會發出的跨網域請求。只要是不同的 網域 、 PORT 、 通訊協定 ，通通都算跨網域。 基於安全性考量，程式碼所發出的跨網域 HTTP 請求 (XMLHttpRequest, Fetch)，一樣也會受到 same origin policy 的限制，必須在同個網域內，否則一樣使用 CORS 的請求。 會需要注意 CORS 的 Request: XMLHttpRequest, Fetch 網頁字體 (跨網域的 css 裡面的 @font-face) WebGL 的 texture drawImage 用到的圖片 or video frames css 這裡就不多寫關於 Simple Request 與 Preflighted requests，可以直接參考 MDN  的網站。 不過當遇到 Preflighted Request 的時候有些要注意的事情。 WebKit Nightly 與 Safari Technology Preview 對 Accept、Accept-Language (en-US) 及 Content-Language (en-US) 標頭值加入了額外的限制。假如這三個 header 中有任一個擁有「非標準」值，WebKit／Safari 就不會將該請求視為 Simple Request header('Content-Type: application/json; charset=utf-8'); header('Access-Control-Allow-Origin: http://abc.com'); header('Access-Control-Allow-Methods: POST, GET, DELETE, PUT, PATCH, OPTIONS'); header('Access-Control-Max-Age: 86400'); header("Access-Control-Allow-Headers: Content-Type, Accept"); 以上述來說, 如果只想允許 http://abc.com 的網域過來的請求， 就在 Access-Control-Allo

DNS 階層 DNS 並不是單一伺服器，而是整個基礎架構，由一堆 name servers 在不同的階層中 在 DNS 階層中，主要有分成四個類型的伺服器類型 DNS Resolver (Recursive Resolver): 作用是接收如網頁瀏覽器、應用程式等的查詢，並將請求轉發給其他 DNS name servers Root-level name servers: 維護 top-level domain, ex:    .com  ,    .edu  ,    .us  ,  .io  等等。舉例來說，當你查詢 maper.io 的 IP 時，root-level name servers 會回傳一個擁有 .io 的 top-level domain name server 的 IP 地址列表給你。更簡單來說，root-level name servers 會告訴你 .io 要去哪個 top-level domain name server 中找，有點像是索引的概念。 Top-level domain name servers: 這些伺服器有著 authoritative name servers 的 ip。 Authoritative name servers: Authoritative name servers 是 name servers 查詢中的最後一站。如果 Authoritative name servers 能夠存取請求的記錄，則其會將已請求主機名稱的 IP 位址傳回到發出初始請求的 DNS 解析程式，也就是回傳網頁/應用程式的主機 ip。 Iterative vs recursive query resolution 有兩個執行 DNS query 的方式 Iterative: 本地端向本地/ISP, root, top-level domain, authoritative name servers 依序請求 ip 位置。 Recursive: 本地 -> root -> top-level-domain -> authoritative -> top-level-domain -> root -> ISP/本地 Caching 快取指的是將常常被請求的 resource records 暫時存

 I/O Model Synchronous I/O Blocking Non-Blocking I/O multiplexing Asynchronous I/O Blocking 跟 Non-Blocking 差異只差在 選擇 ! Blocking 以 read (read from a file descriptor) 來舉例, 從 user space 發出 read (kernel提供的 system call) 之後， 這時候就會切換到 kernel mode，kernel 會依據給定的 file descriptor 去判斷， 這個 fd 來自哪裡，接下來等待資料，因為 kernel space 跟 user space 本身就是 isolated， 這樣在 user space 的 process crash，也不會影響到 kernel space， 所以 kernel space 拿到資料之後，因為 isolated 的關係，要將資料複製到 user space 去。 在這個過程中，user space 的 read 基本上就是一直在等結果。 read 如果失敗會有 err number 可以注意 EAGAIN EWOULDBLOCK Non-blocking 就是類似一直來問 read 目前的狀態， kernel 回到 user space 可能裝置還沒準備好，或是要等之後的操作才會生效， 這時候就會發出 EAGAIN 的錯誤，EAGAIN 不代表是真的錯誤，再試一次可能就可以， I/O Multiplexing (這個邏輯跟數位邏輯的 mux 很像，故取做 IO multiplexing) multiplexing => 有多個輸入(input), 可以透過一個 select 去決定輸出 假設 Linux 要等待很多種資料, 就可以用這個概念，去監控哪個 fd 有資料， 有資料的話就挑選出來! 所以 I/O Multiplexing 本質還是 blocking，只是可以一次監聽多個 所以像網頁伺服器要監聽很多個 incoming request，就可以用這種方式處理 select 單個 process 可以被監聽的 fd 數量有限制 (跟這個 /proc/sys/fs/file-max 有關) 因為是一個一個詢問(輪詢)，所以監聽越多 f

前言 如果要客製自己的 auth gard 用來處理驗證與登入 首先可以從官網的 Authentication 中找到! 但是寫的有一點點不全面，在這邊重新整理一下。 如果是要用 jwt 登入這種，則可以直接參考官網即可！ 大致需要 自己定義的 Auth Guard 自己定義的 User Provider (後面解釋) 用來驗證的 model 建立用來驗證的 model <?php namespace App\Models\Member; use Illuminate\Database\Eloquent\SoftDeletes; use Illuminate\Foundation\Auth\User as Authenticatable; class Member extends Authenticatable { use SoftDeletes; protected $table = 'members'; /** * The attributes that are mass assignable. * * @var array */ protected $fillable = [ 'name', 'email', 'password', 'cell_phone', 'verified', 'status', 'facebook_id', 'line_id', ]; /** * The attributes that should be hidden for arrays. * * @var array */ protected $hidden = [ 'password', ]; protected $dates = [ 'deleted_at', ]; } 在這邊我主要是先建立一個 Member.php 的 model 這裡有些