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.

Mình, cái đứa rất dở viết nên đã trông cậy rất nhiều vào AI để viết.

Cũng là mình, cái đứa rất khó chịu với các bài viết nặng mùi văn AI.

Nên mình thường không thích các bài viết mình từng đăng tải trên blog này, thiệt.

Nhân ngày đi chăm người thân nằm việc, mình đang ngồi ở ghế đá hành lang, tận hưởng gió và nắng kèm một chút suy tư.

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!!

EGANY đã ứng dụng Agentic Workflow trong quy trình phát triển giao diện trên Haravan và Sapo như thế nào?
Chuyện dài tập, nên mình đặt mục tiêu mỗi tuần kể một tập nha 🫰

Bắt đầu từ tuần sau 🥲

Hôm trước mới nói vọc vạch CLI cho biết, mà tự dưng nay bị nghiện cái món này luôn roài 🤣

Đây là bộ egatheme CLI, phục vụ cho quy trình phát triển theme trên Sapo/Haravan.

Hoàng hôn đẹp vầy, hổng trốn làm thật lãng phí 😌

Dạo này đi đâu cũng thấy CLI, nên mình quyết định sẽ thử tìm tòi vọc vạch cách build CLI nó sẽ như thế nào 🤨