Set’s Note

前言 記錄一些好玩的線上練習網站 CSS CSS Dinner Flexbox Froggy Flex Pirate Grid Garden Git Learn Git Branching HTTP HTTP Challenge Network The Case of the Slow Websites The Case of the Connection Timeout The Case of the DNS Update that Didn’t Work The Case of the 50ms Request Regex RegexOne SQL W3Schools SQL Exercise SQLBolt XSS XSS game

前言 因為不小心手殘把 local 的 Hexo 設定砍了… 所以藉此來紀念我的手殘及記錄一下我的 Hexo blog 做了哪些設定 設定 deploy 到 GitHub page 上 安裝套件： npm install --save hexo-deployer-git 調整 _config.yml： deploy: type: git repo: <repository url> NexT 安裝 NexT： npm install hexo-theme-next --save 將 NexT 的設定檔複製出來： cp node_modules/hexo-theme-next/_config.yml _config.next.yml 把 _config.yml 中的 theme 改成使用 NexT： theme: next Sitemap 安裝套件： npm install hexo-generator-sitemap --save 外部連結 nofollow 安裝套件： npm install hexo-filter-nofollow --save Minifier 安裝套件： npm install hexo-all-minifier --save 在 _config.yml 中加入： ...

前言 在面試的時候被問到 GIL，雖然我是直接回答說我看不懂，但是仔細想想上一次看也是快一年前了，於是想趁報到前再來挑戰一次 GIL 主要會分兩個部分來講 GIL 是什麼 GIL 會造成什麼影響 如何避免 GIL 造成的問題 總結 GIL 是什麼？ In CPython, the global interpreter lock, or GIL, is a mutex that protects access to Python objects, preventing multiple threads from executing Python bytecodes at once. The GIL prevents race conditions and ensures thread safety. A nice explanation of how the Python GIL helps in these areas can be found here. In short, this mutex is necessary mainly because CPython’s memory management is not thread-safe. ...

前言 面試的時候被考到一題情境題覺得蠻有趣的，於是決定記錄下來。 面試過程 面試官：今天有一個網站是 3-tier 的架構（前端、後端、資料庫），某天你發現首頁 load 不出來，這時候你會怎麼做？ 我：打開瀏覽器的 console 看 network 那邊的 request 狀態是怎樣。 面試官：你打開了，看到 request 沒有回傳 response，就卡著。 我：這樣看起來是後端掛了，先檢查後端的 log。 面試官：後端沒有 log，但是這個 controller 只有跟 db 撈資料，其他都沒有做。 我：那應該是後端跟 db 溝通的時候卡住了，這張表很大嗎？ 面試官：大概 10 萬筆。 我：那應該還好，db 那台的 memory 跟 CPU 都是健康的嗎？ 面試官：CPU 跟 memory 的 usage 都不超過 30%。 我：db 是 RDS 嗎？ 面試官：是。 我：RDS 可以看每條 query 跑的狀況，這條 query 跑的狀況有異常嗎？ 面試官：前幾次跑都沒問題，但是這次掛了。 我：… 面試官：那現在是什麼問題？你需要一點提示嗎？ 我：好，我要提示。 面試官：你手動連接 db 發現連不進去了。 我：那應該是 connection pool 沒設定好，需要檢查一下 connection pool 的設定。 ...

HTTP 的 method 中最常被用到的應該就是 GET 及 POST 了但是 GET 與 POST 除了使用場景不一樣之外，到底還有哪些區別呢？ 我們知道 GET 通常都透過 query string 來傳遞參數，POST 則是使用 request body但是其實 GET 也可以透過 request body 來傳遞參數，同理 POST 其實也能使用 query string（只是上述兩種方式都不推薦） GET vs POST 差異點 POST 不會被 cache，GET 會 POST 不會出現在瀏覽器的訪問記錄裡，GET 會 POST 不能被存成書籤，GET 能 HTTP GET method vs POST method

HTTPS 會加密 path, query string, request body 但是 domain name 不一定會加密（如果沒有使用 SNI 才會把 domain name 加密）

在 browser 輸入網址 browser 跟 OS 要網址的 IP address OS 向 DNS 查詢 IP address（如果有 cache 會直接回傳 IP address 給 OS） DNS 向 Name Server 查詢 IP address OS 將從 DNS/Name Server 查詢到的 IP address 回傳給 browser browser 拿到 IP address 後對 IP address 做 HTTP/HTTPS request 如果使用 HTTPS 會先使用 TLS 對憑證做認證並產生加密的 session key，並對 request 的資料內容作加密 browser 與 Server 做 TCP 的三項交握確認 Server 現在可以接收資料 Server 上的 Nginx/Apache 接收到 request，並將 request pass 到 code base 中（Python/PHP/JavaScript） code base 將 request 處理完之後回傳 response browser 接收到 response 後根據 response 的內容將頁面 render 出來

前言 最近常常在用 Python 寫爬蟲 就好奇 BeautifulSoup 不同的 Parser 之間有什麼差別 於是寫了這篇文來記錄一下 import requests from bs4 import BeautifulSoup url = "https://google.com/" resp = requests.get(url) soup = BeautifulSoup(resp.text, "html.parser") # or soup = BeautifulSoup(resp.text, "lxml") 網路上的爬蟲教學常常會看到以上兩種寫法，可以看到差別就是 html.parser 跟 lxml 這個其實是在跟 BeautifulSoup 說我們要用哪種 Parser 去解析 HTML 但是到底 BeautifulSoup 支援多少種 Parser，及每種 Parser 到底差在哪？ 於是就隨手 google 了一下發現了 StackOverflow 上的這篇 及 BeautifulSoup 的 doc 以下是不同的 Parser 的比較表格 tl;dr 速度最快：lxml 相容性最高：html5lib 剩下用：html.parser Parser 優點 缺點 html.parser Python 內建，不需額外安裝 速度跟相容性都普通 lxml 快 需要額外安裝（C dependency） html5lib 相容性最高，所有版本的 Python 都能用 慢 參考資料 BeautifulSoup: what’s the difference between ‘lxml’ and ‘html.parser’ and ‘html5lib’ parsers? Installing a parser

前言 記錄一下要怎麼在 docker 中對 PostgreSQL 備份/匯入資料 備份 PostgreSQL 在 docker 中備份 PostgreSQL 的指令如下： docker exec -t <container_name> pg_dumpall -c -U <user_name> > dump_`date +%d-%m-%Y"_%H_%M_%S`.sql 匯入 PostgreSQL 將 SQL 檔匯入 PostgreSQL 的指令如下： cat <your_dump>.sql | docker exec -i <container_name> psql -U <user_name> 參考資料 Backup/Restore a dockerized PostgreSQL database

前言 最近在 build docker image 的時候遇到 No space left on device 的問題。 因為在解的過程發現好像蠻多人都有遇過這個問題，於是就把解的過程記錄下來，希望能幫到其他人。 問題描述 今天在 build docker image 的時候出現以下錯誤： ERROR: Could not install packages due to an EnvironmentError: [Errno 28] No space left on device 因為錯誤出現在 pip install 的步驟，所以我先往 pip 的方向去找，找到以下的解決辦法： 在家目錄底下開一個新的 tmp 資料夾，讓系統使用該資料夾來解決 tmp 空間不足的問題。 使用以下命令： pip install --no-cache-dir <package_name> 選擇了第二個方法，但問題依然存在。後來發現這其實是 Docker 的暫存空間被塞滿導致的問題。 解決方案 使用 docker system prune 指令來清理 Docker 暫存空間： docker system prune 這將會刪除： 所有停止的容器 沒有被至少一個容器使用的網路 所有的 dangling images 和 build cache 若還是無法解決，則進一步檢查容器的 log 檔： du -d1 -h /var/lib/docker/containers | sort -h 找到占用空間大的 log 檔後，使用以下指令清除 log： ...