[小專案] 自動辨識藥丸數量的網站

前言 前陣子我的藥師朋友經常需要手動計數藥丸,以便進行包藥作業.這個過程既耗時又容易出錯。為了解決這一問題,我幫他設計了一個簡單的應用程式,使用 YOLOv8 模型來自動識別並計算照片中藥丸的數量,從而快速提供準確的結果 專案說明 專案的詳細介紹我把他整理到 Notion 上,裏面有更詳細的說明 Ref: GitHub Repo 系統架構 這個專案需求非常簡單,其實單純一個 Monolithic 的架構就可以應付,但為了練習看看微服務(Micro service)的切分,就嘗試將不同的功能切分成不同的服務,彼此用 Restful API 溝通 Tech Stack 簡單列一下使用到的技術 Backend Python(FastAPI) Node.js(Express) written in TypeScript Auth JWT Google Auth Redis AI Model YOLOv8 Label-Studio (Labeling Tool) Frontend React written in TypeScript PWA Storage PostgreSQL (database) Minio (Image storage) 心得 這是第一次嘗試 React 的 PWA,用 service worker 滿直覺也滿簡單的,配置一下部署到 Netlify 上,就可以把網站下載到手機桌面上充當一個 APP 使用 這是第一次嘗試 Yolov8 的模型,並使用 Label-Studio 工具作為標註,使用起來相當直覺,當有多人需要同時標註時,簡單在電腦啟動 server,然後用 ngrok 臨時建個 tunnel,開放給別人一起標註...

<span title='2024-07-29 15:50:04 +0800 +0800'>July 29, 2024</span>&nbsp;·&nbsp;2 min&nbsp;·&nbsp;214 words&nbsp;·&nbsp;Madi

Redis - 被挖礦病毒入侵攻擊的事件紀錄

前言 前幾天在 Linode 上開了一台 VPS 部署我的程式,裏頭用到 JWT token 與 Redis 作登入登出的機制,本來想說這個 VM 是做為測試用途,就沒有把 Redis 加密,也沒有限定 ip 連線,意外導致 redis 對外開放,受到挖礦病毒的攻擊,查了一下網路上的心得,發現蠻多人像我一樣一時疏忽而中招,因此寫了這篇文章來簡單紀錄一下過程。 事出必有因 整件事情的起頭是這樣,我在 VPS 上用 docker-compose 部署三個服務,分別是我的 api server、PostgreSQL、Redis,前端則是部署在 Netlify 上。 剛開始一切運行都很正常,但測試了一下馬上就發現有個小問題,我前端登入之後,沒多久 cookie 就失效被強制登出,由於我的 expire 設定 24 小時,沒道理這麼快就過期,所以直覺地去查了一下 Redis 內存的 session,看了一下記憶體用量也沒有發現什麼異常現象,就暫時沒有追蹤下去。 隔天我再測試,發現前端已經無法登入了,再次連到 VM 上看一下 api-server 的 log,發現源源不絕的 error 從 Redis 那邊不斷噴出來 1:S 15 May 2023 20:47:34.995 * Non blocking connect for SYNC fired the event. 1:S 15 May 2023 20:47:36.398 # Failed to read response from the server: No error information 1:S 15 May 2023 20:47:36....

<span title='2023-05-16 00:49:13 +0800 +0800'>May 16, 2023</span>&nbsp;·&nbsp;2 min&nbsp;·&nbsp;303 words&nbsp;·&nbsp;Madi

[閱讀筆記] Transactionally Staged Job Drain in PostgreSQL

前言 前陣子因為某接案需求要研究 Medusa 這個開源的電商專案,發現底層設計的 Event Architecture 有參考到 Transactionally Staged Job Drain 這個事務處理機制,因此拜讀了一下這篇 2017 年的文章,當時作者也在 Hacker News 上與網友有不少討論,相信對於研究底層的設計可以讓自己功力提升,因而有了這篇文章的誕生. 問題描述:Event Queue + ACID 聲明:本篇取材自 Transactionally Staged Job Drain 的整理消化,圖片皆來自於此. 文章探討的情境是: 任務佇列(Job Queue)消化的速度太快,導致後台服務(background worker)在該事務 commit 前就嘗試取用,進而無法訪問到預期可用的資料,也就是如何搭配 ACID 與 Event Queue 解決上述事務的問題. 底下是一個顯而易見的例子: BEGIN TRANSACTION; /* db_op1 */ INSERT INTO USER(id, name, age, email) VALUES (1, 'Madi', 27, 'example@gamil.com'); /* queue_job */ -- Some enqueuer worker /* db_op2 */ INSERT INTO USER(id, name, age, email) VALUES (2, 'Kevin', 20, 'example2@gamil....

<span title='2023-01-22 00:49:13 +0800 +0800'>January 22, 2023</span>&nbsp;·&nbsp;2 min&nbsp;·&nbsp;421 words&nbsp;·&nbsp;Madi