COFFEE HIGHFIVE 是一個可以讓你搜尋適合自己工作場所的一個服務,可以找到咖啡廳、簡餐店等,也可以自己篩選店家是否有提供 wifi 和電源插座。
雖然現在社群提供的資料還不多,希望大家看到可以幫忙補上去,讓更多人受惠。
軟體開發、伺服器和生活瑣事
COFFEE HIGHFIVE 是一個可以讓你搜尋適合自己工作場所的一個服務,可以找到咖啡廳、簡餐店等,也可以自己篩選店家是否有提供 wifi 和電源插座。
雖然現在社群提供的資料還不多,希望大家看到可以幫忙補上去,讓更多人受惠。
最後更新時間:2017/08/19
跑去大雪山的橫嶺山步道,順便記錄一下路況。
我是騎機車上山的,第一件事情就是不要完全按照 Google Maps 的建議路線行走,他會帶你去走私有土地 … (死)
從東勢沿著專一道晚上騎到恆嶺山比較上面的入口,柏油路僅有幾處破洞,大致上沒什麼安全疑慮,不過沿路有幾處有落石,建議小心行駛。
越往山上的路寬越窄,請留意會車問題,且大約中午 12 點過後便開始起霧,行駛時請務必開大燈,讓自己與對象來車都能保持行車安全!
前幾天 Google 發布了 Puppeteer:一個可以控制 Chrome Headless 的 nodejs library。
透過 demo code 可以看到要產生 PDF 也好、要做 screen shot 也好,基本上都可以在數行以內解決:
const puppeteer = require('puppeteer');
(async() => {
const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
await page.screenshot({path: 'example.png'});
browser.close();
})();
感覺就是拿來做壞事的好工具呀,也不用寫什麼 JavaScript emulator 去取得實際的網頁 DOM 狀態了 XD
官方文件已經有 Chrome Headless + Pupetteer 的網頁 debug demo:https://developers.google.com/web/updates/2017/04/headless-chrome
平常改設定檔通常都是「sudo vim xxx.conf」,不過直接切換成 root 修改檔案其實風險還蠻大的,特別是邊喝酒邊改系統的時候 (?)。
倘若不想使用 sudo vim 來修改系統設定檔時,就 vim xxx.conf 即可。雖然沒有寫入權限,但至少讀取檔案內容是沒問題的。
以一般使用者開啟系統擋時,每次做變更都會收到警告訊息「Warning: Changing a readonly file」,表示 vim 偵測到沒有權限變更檔案內容,避開非預期的異動正是避開誤寫的好方法。那當修改完成後需要寫入時,則可以使用以下指令臨時切換成 root 並寫入檔案:
:w !sudo tee %
說明一下上面那一段到底是什麼意思。
「:w」和大家所知道的寫入檔案是一模一樣的,但若後面加上其他指令,例如「:w ! tee」其實就是把預備寫入的檔案內容 pipe 給後面的指令處理,前面這個寫法就是把檔案內容丟給 console 的 tee 處理,所以可以看到 tee 檔案內容輸出到螢幕上 (stdout)。
vim 中的「%」符號代表的是正在編輯的檔案名稱,可以使用「:!echo %」指令看看會輸出什麼資料。若是「vim xxx.conf」則會印出「xxx.conf」;「vim path/to/xxx.conf」則會印出「path/to/xxx.conf」,應該不難理解。
綜合以上幾個撇步,「:w !sudo tee %」的意思,其實就是讓 vim 不要自己更新檔案,而是將檔案內容拋給以 root 身份執行的 tee,並讓 tee 寫入 vim 目前正在編輯的檔案。tee 寫完檔案以後,vim 會偵測到檔案異動並詢問是否要重新載入 (load) 更新過的檔案內容,重新載入以後就可以繼續下一個批次的修改。
一般來說,要讓 Nginx 遇到 PHP 程式時,只要按照以下寫法就可以將 request 轉接給 php-fpm 處理:
server {
location / {
try_files $uri $uri/index.html =404;
}
location ~ .php* {
root /home/www/data;
include fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}
假設 project 在 document root (如上面的就是 /home/www/data),設定方式其實不難,網路到處都可以找的到。像是 Laravel 可以參考 pretty URL 的設定方式,把 index.php 隱藏起來:
location / {
try_files $uri $uri/ /index.php?$query_string;
}
上面這個設定,可以讓 request 從「http://my.site/user/1」,被改寫為「http://my.site/index.php/user/1」,這個時候 index.php 就可以從 $_SERVER 的參數來判斷到底要走哪個 route。
但假設寫的專案沒有一個 domain name、沒辦法做 virtual host,可以讓專案根目錄當作 document root,且新的 PHP framework 都會把 index.php 放在 /public 目錄下來避免安全問題,這樣的 URL rewrite 就會出問題。
例如今天的 request 是「http://my.site/project/user/1」,在經過上面的 route 以後會被轉成「http://my.site/index.php/project/user/1」,而實際上我們需要的是「http://my.site/project/index.php/user/1」才能讓專案正確運作。
這時需要另外建立 route 規則。先把 http://my.site/project 對應到的正確檔案路徑設定好:
location ^~ /project {
# define script real path
alias /home/www/data/project/public;
try_files $uri $uri/ /project/public/index.php$uri;
}
到這邊算是設定完成一半,暫停來看一下目前 routing 的情況。請求「http://my.site/project/user/1」會被轉換為「http://my.site/project/public/index.php/project/user/1」。index.php 後半部的參數差了一點點,把「project/」片段拿掉就完成了。
這時我們再新增一條規則,使用 REGEX 來處理後面這段參數:
location @project-rule {
# 若 URI 起始為 /project/
# 把後面的參數抓出來,放在 /project/public/index.php/ 後方
rewrite ^/project/(.*)$ /project/public/index.php/$1 last;
}
調整後,完整的 Nginx URL rewrite 規則會長這樣:
location ^~ /project {
alias /home/www/data/project/public;
# 一般規則無法正確找到路徑
# 就使用 @project-rule 規則來做查詢
try_files $uri $uri/ @project-rule;
}
location @project-rule {
rewrite ^/project/(.*)$ /project/public/index.php/$1 last;
}
Nginx 的 rewrite rule 實在很難 debug,這段是自己花了數小時嘗試錯誤並觀察 $_SERVER 參數變化才找到規律的,希望多少對大家有一點幫助。