Astrotion

Sau khi sắp xếp lại 47 bài viết cũ theo nhóm mới, mình push lên, hồ hởi mở trang dự án ra xem timeline. Trống trơn. "Chưa có bài viết nào."

Lạ ở chỗ: mọi thứ đều báo thành công. Đây là bài ghi lại một tiếng đồng hồ đi tìm một con bug giả vờ rằng nó không tồn tại.

Triệu chứng: thành công giả

Blog này lưu nội dung trên Cloudflare D1. Cơ chế: mình push markdown lên GitHub, một webhook bắn sang con worker, worker đọc file rồi ghi vào database.

Mình mở log của webhook ra. Nó trả về , kèm . Nhìn là biết: 33 file, đồng bộ xong. Đáng lẽ phải vui. Nhưng dữ liệu thì không hề đổi.

Bài học đầu: đừng tin status code, đi xem sự thật

Thay vì ngồi đoán, mình đi kiểm chứng bằng thứ thật nhất — trang đang chạy. Mở thẳng đường dẫn category mới trên production: . Mở category cũ: vẫn còn nguyên mấy bài đáng lẽ đã chuyển đi.

Kết luận lạnh người: database chưa thay đổi gì cả. Cái kia là một lời nói dối.

Manh mối nằm trong một chữ "false"

Mình đọc kỹ lại cái response. Có một dòng: .

Đối chiếu với code: con số chỉ đếm số file có trong gói webhook — không phải số bản ghi thực sự được viết. Còn mới là cờ báo "có ghi được cái gì không". Nó là . Tức là: nhận 33 file, ghi được 0.

Một con số đếm "đã nhận" mà mình tưởng là "đã làm xong". Đó là cái bẫy.

Manh mối thứ hai: cái gì vẫn chạy

Mình để ý: mấy bài mình đăng nhanh qua Telegram thì vẫn lên bình thường. Chỉ bài push qua git mới hỏng.

Hai con đường này khác nhau ở một điểm: Telegram đẩy thẳng nội dung vào, còn git thì worker phải tự đi đọc file từ repo — mà repo này để riêng tư. Đọc repo riêng tư thì cần một cái token.

Đến đây thì lộ. Cái token đó đã hết hạn. Mỗi lần worker đi đọc file, GitHub trả về . Worker nuốt gọn cái lỗi đó, trả , bỏ qua file — rồi vẫn thản nhiên báo ra ngoài.

Cái mình sửa không chỉ là cái token

Thay token mới thì 33 bài vào database ngay. Nhưng mình dừng lại lâu hơn ở một câu hỏi: vì sao một thất bại toàn tập lại trông như thành công?

Nên mình sửa luôn con webhook: nếu có file cần đọc mà ghi được con số 0, nó phải báo lỗi to — trả về mã lỗi thật kèm gợi ý "token có thể đã hết hạn", để lần giao webhook hiện đỏ lòm trong lịch sử thay vì xanh giả. Một cái dối trá còn nguy hiểm hơn một cái lỗi thật, vì nó khiến mình tin sai trong im lặng.

Mình rút ra gì

• "Đã nhận" không phải "đã xong". Một metric đếm sai chỗ sẽ nói dối bạn rất tự tin.
• Verify bằng artifact thật, đừng bằng status code. Trang chạy thật mới là sự thật; chỉ là lời hứa.
• Lỗi phải ồn ào. Fail lặng lẽ là loại bug đắt nhất — nó giả vờ mọi thứ đều ổn cho tới khi bạn tình cờ phát hiện.

Mình mất gần một tiếng cho một dòng chữ mà lẽ ra phải đỏ ngay từ đầu. Giờ thì nó đỏ thật.

Mình vừa làm một đợt refactor lớn cho chiếc blog này: đổi từ blog cá nhân tổng hợp sang portfolio build-in-public. Bài này ghi lại quá trình — không phải để khoe kết quả, mà để chốt lại cách mình nghĩ khi làm.

Vì sao đổi

Blog cũ trộn quá nhiều thứ: nhật ký đời thường, ghi chú học, workflow... lướt vào không biết mình là ai. Mình muốn nó nói rõ một điều: một PM/Solopreneur học bằng cách làm, build sản phẩm công khai. Định hướng mới: cho thấy cách mình nghĩ, không chỉ thứ mình ship.

Nguyên tắc: soft relaunch, không đập đi xây lại

Cám dỗ lớn nhất là reset sạch và làm blog mới. Mình không làm vậy. Build-in-public sống bằng chiều dài thời gian — xoá lịch sử là xoá độ tin cậy. Nên mình chọn tái dùng + mở rộng:

• Giữ nguyên nền Astro SSR + Cloudflare + D1 vừa migrate xong.
• Giữ design system có sẵn, chỉ gia cố (thêm type scale, vẫn giữ màu vàng đặc trưng).
• Tái sinh component đang "mồ côi" thay vì viết mới.

Những thứ đã làm

• Homepage đổi từ feed cuộn vô tận sang curated: giới thiệu ngắn → dự án đang build → vài note gần đây. Feed đầy đủ chuyển sang trang riêng.
• Sidebar gọn lại 4 mục (Search / Home / About / Projects), social icon dồn xuống đáy, nền sáng kiểu Notion cho dễ đọc.
• Trang dự án thành case study thật: bảng metadata (status, vai trò, stack, links/demo), các phần Bối cảnh → Cách tiếp cận → Bài học → Kết quả, rồi một timeline gọn các bài build-log.
• List view cho dự án: thumbnail + status badge, đồng bộ với Gallery.

Sai ở đâu, học được gì

• Lặp UI nhiều vòng hơn mình tưởng. Một cái list view mình sửa tới 4-5 lần mới ưng. Bài học: với UI, một screenshot thật đáng giá hơn mười dòng mô tả — mình bắt đầu verify bằng ảnh thay vì đoán.
• HMR đánh lừa. Có lúc giao diện trông như vỡ, hoá ra chỉ là dev server cache CSS cũ. Mất kha khá thời gian nghi oan cho code. Restart sạch là xong.
• Không bịa số. Mục metrics chỉ hiện cái có thật (Lighthouse, dung lượng CSS); cái chưa có (user, doanh thu) thì để trống, không phịa cho đẹp.

Còn lại

Phần nền đã xong. Việc khó nhất nằm ở phía trước và không phải kỹ thuật: sắp xếp lại nội dung cũ theo 3 nhóm (Build Log / Teardown / Learning), và quan trọng nhất — giữ nhịp đăng đều. Portfolio đẹp tới đâu mà im lặng vài tháng thì cũng đọc là "bỏ dở".

Cái blog này, từ giờ, chính là một build log sống.

Có dạo Vibe Coding bắt đầu nổi lên rần rần, và mọi người bắt đầu chia sẻ nhiều về việc xây dựng website với Astro bằng Vibe Coding. Dù là một đứa lười làm nhưng lại rất FOMO, trì hoãn hoài thì tới một thời điểm mình cũng không để ngó lơ được nữa. Bắt tay vào làm thôi!!

Mình khởi đầu với ý định trải nghiệm Vibe Code với Astro để làm blog, cộng với một vài từ khoá được tiêm nhiễm vào đầu: R2, D1, Cloudflare Pages.

Và mình đặt tên dự án này là Astrotion.

Giai đoạn 1 - Định hình Blog

Version đầu tiên của blog mình build hoàn toàn với Antigravity, tài khoản Gmail Pro. Đầu tiên, do không biết bắt đầu từ đâu nên mình lên Astro theme, lựa một cái template blog có sẵn và yêu cầu AI hướng dẫn mình setup. Cũng đơn giản lắm, nên sau vài thao tác là mình đã có được một chiếc blog đầu tiên (xấu đui xấu đớn..).

Là đứa khá thích phong cách tối giản, nên mình cũng muốn blog của mình nó thể hiện được đúng cái gu của bản thân. Lượn lượn một vòng tìm ý tưởng, mình cóp nhặt được kha khá thứ từ Substack và Facebook Feed. Hành trình build blog mới thật sự bắt đầu từ đây.

Tại sao lại follow theo Substack?

• Một nền tảng dành cho những người thích viết - thích đọc, quá nổi tiếng rồi thì mình mặc định là trải nghiệm người dùng của nó thật sự tốt.
• Phần nhìn nó cũng rất hợp với gu mình, gọn gàng, vừa đủ.

Tại sao lại follow theo Facebook Feed?

• Nó lại xuất phát từ việc bản chất mình là một đứa khá ít nói - ít viết, nên mình biết chắc nếu đặt áp lực bản thân phải chia sẻ các bài viết dài dài thì..mình bỏ cuộc ngay từ những ngày đầu tiên. Nên mình đã suy nghĩ khá nhiều về việc làm sao để mình vẫn có thể chia sẻ thoải mái mà không bị áp lực bởi con chữ.
• Còn gì phù hợp hơn một hành vi như kiểu "post status sống ảo trên mạng xã hội"..cái hành vi mà mình đã được tôi luyện hơn chục năm từ 2020 đến giờ, nhỉ?

Có ý tưởng rồi, mình lại yêu cầu AI nó hiện thực hoá thôi, việc đó nó làm tốt lắm. Sau đâu đó nửa ngày feedback, tinh chỉnh thì mình ra được giao diện blog như phiên bản hiện tại nhưng ít "tính năng ẩn" hơn.

Giai đoạn 2 - Tối ưu trải nghiệm viết

Dù là một đứa rất ít khi viết, nhưng mình đã tưởng tượng đến một ngày mình chăm chỉ sản suất nội dung bằng tất cả sự nhiệt huyết thế nào, mình đã hình dung là mình có thể viết 5 đến 10 bài mỗi ngày. Nên mình tìm cách tối ưu cho những thứ gần như không bao giờ tồn tại.. Ỏoo 👉👈.

Quay lại ý chính. Ở thời điểm này, mọi bài viết đang được lưu trong thư mục contents của dự án Astrotion, đồng nghĩa mỗi lần viết mình phải lọ mọ mở Code editor lên > Mở folder dự án > Tạo file Markdown theo đúng cấu trúc Frontmatter đã quy định > Và viết.

Quy trình này không phải rào cản lớn với mình ở hiện tại, nhưng nó sẽ là vấn đề với Quỳnh ở thì tương lai, cái đứa mà sẽ viết 5-10 bài viết mỗi ngày á.. lại nữa!!

Mục tiêu mình đặt ra lúc này:

1. Viết và format Markdown thân thiện, preview nhanh được format.
2. Viết bất cứ khi nào, bất cứ đâu.
3. Viết xong xuất bản được luôn mà không cần phải lọ mọ mở máy tính để build...

Người ta làm blog để viết, còn mình làm blog để..build :)))

Nhân tiện, mình vừa thêm một tính năng mới: Chia sẻ dạng Quote (trích dẫn).
--> Chỉ cần chọn bất kỳ câu nào trong bài viết để tạo một Quote như chính ảnh này.

Nhìn cũng hay hay ha 👉👈

Bị làm biếng viết blog nhưng lại muốn có blog 👉👈.

Đây là workflow mình hay dùng để post bài nhanh lên blog, cụ thể:

1. Dựng một em Telegram Bot
2. Quăng nội dung cho em Bot
3. Bùm, bài được xuất bản trên Blog

Hợp với mấy dạng content kiểu ngẫu hứng như post này, mấy bài dài dài thì mình viết trên Obsidian, cũng chỉ một vài thao tác để xuất bản trên blog.

Workflow thì tối ưu cho từng use case rồi đó, nhưng content thì hổng có để viết.. chẹp!!

Mình vừa build xong kiến trúc mới cho chiếc blog này.

Tóm tắt:

• Trước đây: Static Site Generation
• Version 2: Server-Side Rendering

Kế hoạch tiếp theo:

• Thử nghiệm một phiên bản với Editor chính là Notion thay vì Obsidian.

Ở các bài trước, mình đã chia sẻ cách mình setup môi trường viết bài:

1. Quản lý bài viết như một CMS
2. Template tự động điền thông tin
3. Sync qua iCloud để viết trên điện thoại

Đến đây, việc viết lách cơ bản đã ổn. Nhưng vẫn còn một khâu cuối cùng: Cập nhật bài viết lên web.

Blog mình dùng Astro, nên muốn có bài mới thì phải đẩy code lên GitHub. Cloudflare Pages sẽ tự động nhận trigger từ GitHub và build lại trang web.

Bình thường, để đẩy code lên, mình phải mở Terminal gõ lệnh hoặc dùng GitHub Desktop. Nhưng việc phải chuyển qua lại giữa các ứng dụng cũng hơi bất tiện mỗi khi mình đang tập trung viết trong Obsidian.

🛠️ Giải pháp: Obsidian Git Plugin

Mình dùng plugin Obsidian Git để đơn giản hóa việc này ngay trong giao diện soạn thảo.

Cấu hình đơn giản

Mình không để mặc định mà chỉnh lại một chút trong phần settings cho phù hợp với thói quen cá nhân:

• Backup interval: Mình chỉnh về (tắt tự động backup). Mình muốn tự quyết định khi nào thì push git, tránh việc plugin tự đẩy lên git khi bài viết chưa hoàn thiện.

Cách mình dùng

Khi viết xong bài, mình mở Command Palette (hoặc dùng phím tắt) rồi chọn lệnh Create backup.

Plugin sẽ tự động commit và push toàn bộ thay đổi lên GitHub. Sau đó Cloudflare Pages sẽ tự build và deploy web.

📱 Trên điện thoại thì sao?

Vì mình để toàn bộ dữ liệu trong iCloud (kể cả phần quản lý lịch sử Git), nên trên điện thoại plugin này vẫn hoạt động y hệt trên máy tính.

Workflow của mình khá đơn giản:

1. Viết bài trên điện thoại.
2. Viết xong, mở Command Palette chọn Create backup.
3. Xong.

Nhờ vậy, mình có thể tranh thủ viết và đăng bài thuận tiện hơn.

Lời kết

Hy vọng những chia sẻ này giúp bạn có thêm một vài gợi ý cho chiếc blog của riêng mình. Cảm ơn bạn đã đọc hết series này <3.

Ở bài trước Setup Obsidian Template, mình đã giải quyết xong khâu tạo bài viết.

Hiện tại blog mình mới chỉ có khoảng hơn chục bài thôi. Tuy nhiên, bắt đầu có những lúc mình muốn tìm lại một bài cũ để sửa, hoặc check xem bài nào đang viết dở, thì việc phải lướt trong danh sách file rồi mở từng cái cũng hơi thủ công.

🤔 Vấn đề: Muốn nhìn tổng quan hơn

Bình thường code editor chỉ hiện danh sách tên file. Muốn biết bài nào (nháp) hay (đã đăng), hay bài nào chưa có ảnh cover, mình phải mở file đó ra mới thấy.

Với số lượng bài ít thì không sao, nhưng mình muốn có một cái nhìn tổng quát hơn.

🛠️ Giải pháp: Properties View

Obsidian có sẵn tính năng Properties View. Hiểu đơn giản là nó gom thông tin Frontmatter của các bài viết lại và hiển thị dưới dạng bảng.

Cách bật

Trước tiên, bạn cần bật plugin Properties View trong phần Core Plugin của Obsidian.

Sau đó, bạn cần chọn folder chứa các bài viết của mình (ở đây là ), và chọn "New Base".

Sử dụng thực tế

Mình chủ yếu dùng view này để:

1. Check bài nháp: Nhìn cột , thấy cái nào đang checked thì biết là chưa đăng.
2. Check ảnh bìa: Lướt cột , thấy ô nào trống thì bổ sung.
3. Xem ngày đăng: Sort cột để xem thứ tự bài viết.

Đơn giản vậy thôi. Nó giúp mình quản lý danh sách bài viết trực quan hơn chút so với việc chỉ nhìn list file.

Một cái tiện nữa là mình có thể sửa thông tin ngay trên bảng. Ví dụ muốn publish bài nào thì bỏ tick ngay tại bảng, đỡ phải mở file.

Kết luận

Với nhu cầu blog cá nhân đơn giản, plugin Properties View có sẵn của Obsidian là đủ để mình quản lý bài viết. Không cần cài thêm plugin, không cần setup phức tạp.

Bài tiếp theo: Làm sao để viết được trên cả điện thoại lúc ra ngoài?

→ Mời bạn xem tiếp: .nosync và Symlinks tối ưu iCloud

Ở bài trước Tận dụng Obsidian làm editor chính, mình có nhắc đến "nỗi đau" khi phải gõ tay từng dòng Frontmatter cho mỗi bài viết mới.

Hôm nay mình sẽ chia sẻ chi tiết cách mình xử lý vấn đề này bằng plugin Templater.

🤔 Tại sao cần Templater?

Ban đầu mình nghĩ dùng tính năng Templates có sẵn (Core Plugin) của Obsidian là đủ. Nhưng nó quá đơn giản, chỉ chèn được ngày giờ và một vài thông tin cơ bản.

Nhu cầu của mình thì phức tạp hơn:

1. Hỏi tiêu đề ngay khi tạo: Không muốn phải click vào title để sửa.
2. Slug tự động: Mình muốn nhập tiêu đề "Cách nấu phở" thì nó phải tự sinh ra slug (bỏ dấu tiếng Việt, thay khoảng trắng...).
3. Tên file chuẩn: Tự động đổi tên file thành .

Nên mình lựa chọn cài thêm plugin Templater (với khả năng chạy JavaScript) để có thể tự động hóa quy trình này.

🛠️ Các bước Setup

Bước 1: Cài đặt Plugin

Vào Settings → Community Plugins → Tắt "Restricted mode" → Tìm và cài Templater.

Bước 2: Chuẩn bị folder chứa template

Mình tạo một folder riêng để chứa các file mẫu, ví dụ: .

Vào Settings → Templater, ở mục "Template folder location", trỏ đến folder vừa tạo.

Bước 3: Tạo file Script

Tạo một file mới trong folder template đó, đặt tên là . Copy đoạn code này vào:

Cách script này hoạt động:

1. Hỏi tiêu đề: Khi chạy, nó sẽ hiện một popup hỏi bạn "Bài này tên gì?".
2. Xử lý Slug: Nó dùng JavaScript để biến "Tiếng Việt có dấu" thành "tieng-viet-khong-dau".
3. Tự đổi tên file: File sẽ tự biến thành .
4. Đặt trỏ chuột: sẽ đưa con trỏ chuột xuống dưới cùng, sẵn sàng để bạn viết.

🚀 Sử dụng

Quy trình viết bài mới của mình giờ chỉ còn 2 bước:

1. Bấm để tạo file mới từ template (phím tắt mình gán cho Templater).
2. Nhập tiêu đề và Enter.

Bùm! File được đổi tên, frontmatter được điền, và mình có thể bắt đầu viết ngay lập tức. Mọi thứ diễn ra trong chưa đầy 5 giây.

Bạn có thể áp dụng cách này cho Daily Note, Project Note, hay bất cứ loại nội dung nào có cấu trúc lặp đi lặp lại.

Bài tiếp theo: Sau khi tạo bài viết dễ dàng rồi, làm sao để mình có thể quản lý danh sách hàng chục bài viết?
→ Mời bạn xem tiếp Quản lý danh sách bài Blog với Obsidian Properties

Blog của mình build bằng Astro. Bản chất các bài viết là file Markdown (, ) nằm trong folder .

Ban đầu mình viết blog bằng code editor. Cũng không có vấn đề gì - đằng nào cũng là edit file Markdown. Nhưng sau khoảng 10 bài, mình bắt đầu thấy một số điểm không ổn.

🤔 Vấn đề khi viết nhiều bài

1. Frontmatter lặp đi lặp lại

Mỗi bài viết Astro bắt buộc phải có YAML frontmatter:

Quy trình tạo bài mới:

1. Mở một bài cũ
2. Copy frontmatter
3. Paste sang file mới
4. Sửa tay từng field: title, slug, date...

Làm vài lần thì ổn, nhưng làm hoài thấy mất công ghê! Đặc biệt là phần slug và rename file - mình thường xuyên gõ sai hoặc quên format ngày tháng. Chưa kể việc phải xóa dấu tiếng Việt thủ công cho slug nữa.

2. Khó quản lý trạng thái bài viết

Khi có nhiều bài, mình không biết:

• Bài nào đang ở trạng thái nháp?
• Bài nào chưa có description?
• Bài nào thiếu cover image?

File explorer của code editor chỉ hiện danh sách các file . Mình phải mở từng file để kiểm tra.

3. Vẽ diagram phải dùng app khác

Khi cần vẽ ảnh minh hoạ:

1. Mình mở Excalidraw.com hoặc Figma
2. Vẽ xong export ảnh
3. Copy vào folder
4. Import ảnh vào bài viết

Mỗi lần muốn sửa lại phải lặp lại từ đầu.

4. Không đồng bộ giữa các thiết bị

Code editor chủ yếu dùng trên laptop. Muốn viết bài trên iPad hay iPhone thì mình phải vào GitHub edit trực tiếp (rất mất công), hoặc dùng app note tạm rồi về máy tính viết lại.

Trước đây mình thậm chí còn nghĩ ra workflow đăng bài qua Telegram Bot để giải quyết vấn đề này.

🚀 Kết quả

Sau khi chuyển sang Obsidian:

• Tạo bài mới từ 2-3 phút xuống còn 10 giây (plugin Templater)
• Quản lý status rõ ràng hơn (nhờ tính năng Base View có sẵn)
• Vẽ diagram tiện hơn (plugin Excalidraw)
• Viết được trên nhiều thiết bị (iCloud sync)

Bước tiếp theo là đẩy bài lên web. Mình dùng Obsidian Git plugin để commit và push ngay trong editor.

→ Xem tiếp: Git Workflow trong Obsidian