Error Handling on miti99

Newsletter #89

Sat, 14 Mar 2026 00:00:00 +0700

Mời bạn thưởng thức Newsletter #89.

Hybrid Quota-Linear Rate Limiter

Tony Finch phân tích một vấn đề phổ biến với các thuật toán giới hạn tốc độ (rate limiter) tuyến tính như leaky bucket và GCRA: chúng có xu hướng “hào phóng” hơn mức cần thiết trong giai đoạn khởi động, cho phép client gửi khoảng q*a/(a-1) yêu cầu trước khi bị giới hạn khi hoạt động ở tốc độ gấp a lần cho phép.

Để giải quyết vấn đề này, tác giả đề xuất một thuật toán lai hoạt động ở hai chế độ: chế độ bursty dành cho các client có lưu lượng thấp, cho phép gửi theo đợt nhưng giới hạn tối đa một quota token mỗi cửa sổ thời gian; và chế độ smooth dành cho client có lưu lượng cao, buộc phân phối yêu cầu đều đặn hơn. Thuật toán tự chuyển đổi giữa hai chế độ khi client tiêu hết quota hoặc khi bucket phục hồi hoàn toàn. Cách tiếp cận này sử dụng ít bộ nhớ hơn so với phương pháp quota-reset, đồng thời kiểm soát quota chặt chẽ hơn so với rate limiter tuyến tính thuần túy.

Tuy nhiên, điểm thú vị là tác giả cuối cùng khuyên không nên dùng thuật toán phức tạp này. Thay vào đó, hãy cân nhắc lại bài toán để có thể sử dụng một rate limiter tuyến tính đơn giản như GCRA — vì việc đo tốc độ trung bình theo thời gian dài tự nhiên khuyến khích client hoạt động mượt mà hơn.

Điểm chính:

Rate limiter tuyến tính (GCRA, leaky bucket) có thể cho phép nhiều yêu cầu hơn dự kiến trong giai đoạn khởi động
Thuật toán lai kết hợp chế độ bursty và smooth để kiểm soát chặt chẽ hơn
Đơn giản hóa vẫn là ưu tiên hàng đầu: GCRA đủ tốt cho hầu hết các trường hợp thực tế

Go is the Best Language for AI Agents

Burak Karakan — CEO của Bruin, người có 8 năm kinh nghiệm lập trình Go — lập luận rằng Go là ngôn ngữ lý tưởng để phát triển phần mềm bằng AI agent. Lý do cốt lõi xuất phát từ bản chất của ngôn ngữ biên dịch: khi agent tạo ra mã nguồn Go bị lỗi, trình biên dịch sẽ trả về thông báo lỗi rõ ràng ngay lập tức, tạo vòng phản hồi nhanh và chính xác để agent tự sửa lỗi. Điều này khác hoàn toàn so với Python hay JavaScript — vốn chỉ báo lỗi khi chạy thực tế.

Hệ thống kiểu tĩnh của Go cũng là một lợi thế lớn: agent có thể xác minh tính đúng đắn của mã trước khi chạy, thay vì phải phụ thuộc vào các bài kiểm thử thủ công. So với Rust — ngôn ngữ biên dịch khác — Go vẫn chiếm ưu thế nhờ cú pháp đơn giản hơn, tốc độ biên dịch nhanh hơn, và lượng mã Go trong dữ liệu huấn luyện của các mô hình AI lớn hơn đáng kể. Ngoài ra, bộ kiểm thử của Go chạy cực nhanh và hoạt động nhất quán trên mọi hệ điều hành, giúp các background agent có thể xác nhận kết quả công việc mà không phụ thuộc vào môi trường chạy cụ thể.

Điểm chính:

Go biên dịch nhanh và báo lỗi rõ ràng giúp AI agent có vòng phản hồi ngắn để tự sửa lỗi
Kiểu tĩnh và cú pháp đơn giản giảm thiểu sai sót trong mã do agent tạo ra
Go chạy nhất quán trên mọi nền tảng — lợi thế lớn cho background agent và môi trường sandbox

Your Agent Needs a Harness, Not a Framework

Dan Farrelly từ Inngest.com đưa ra một góc nhìn sắc bén về kiến trúc AI agent: thay vì dùng framework, agent cần một “harness” — lớp kết nối, bảo vệ và điều phối các thành phần mà không làm thay công việc của chúng. Trong mọi ngành kỹ thuật, harness đều có vai trò như vậy: dây điện nối các cảm biến, test harness cung cấp giàn giáo kiểm thử, dây an toàn giữ bạn khi ngã. Agent runtime cũng cần điều tương tự.

Vấn đề hiện tại là mỗi framework agent lại tự xây dựng lại từ đầu: retry logic, lưu trạng thái, job queue, định tuyến sự kiện. Thay vào đó, hãy dùng hạ tầng event-driven bền vững đã sẵn có — mỗi lần gọi LLM hay công cụ trở thành một “step” có thể thử lại độc lập. Nếu tiến trình chết ở vòng lặp thứ năm, bốn vòng trước đã được lưu lại. Nhóm tác giả đã xây dựng Utah (Universally Triggered Agent Harness) để minh chứng: một agent hội thoại qua Telegram/Slack với công cụ, bộ nhớ, ủy quyền sub-agent và khả năng chịu lỗi — chỉ dùng Inngest, không framework. Bài học quan trọng rút ra: quản lý ngữ cảnh (context management) mới là thử thách thực sự, không phải việc gọi LLM.

Điểm chính:

Agent cần “harness” để xử lý retry, trạng thái, concurrency — không phải thêm framework
Mỗi lần gọi LLM/công cụ là một step độc lập, có thể thử lại mà không mất kết quả trước
Quản lý ngữ cảnh (cắt bớt, nén lịch sử, cảnh báo ngân sách) là thách thức lớn nhất khi xây agent thực tế

An Interactive Intro to Quadtrees

Bài viết tương tác giải thích quadtree — cấu trúc dữ liệu dùng để tìm kiếm không gian 2D hiệu quả. Vấn đề đặt ra: khi xây dựng ứng dụng bản đồ với hàng triệu địa điểm, cách đơn giản nhất là tính khoảng cách từ vị trí người dùng đến từng điểm rồi lọc ra những điểm đủ gần — nhưng với hàng triệu điểm, cách này quá chậm.

Quadtree giải quyết bài toán bằng cách chia không gian thành 4 ô con khi một ô chứa quá nhiều điểm (vượt ngưỡng capacity), tạo thành cây phân cấp. Khi truy vấn, chỉ cần đệ quy vào các ô giao với vùng tìm kiếm — bỏ qua hoàn toàn phần còn lại. Tham số capacity điều chỉnh sự cân bằng: capacity thấp tạo cây sâu, bỏ qua nhiều vùng hơn nhưng tốn bộ nhớ; capacity cao tạo cây nông, tiết kiệm bộ nhớ nhưng mỗi ô cần duyệt tuyến tính nhiều điểm hơn. Ngoài tìm kiếm địa lý (Uber dùng để tìm tài xế gần nhất), quadtree còn ứng dụng trong phát hiện va chạm game (broad-phase collision detection) và nén ảnh theo vùng.

Điểm chính:

Quadtree chia không gian 2D thành 4 ô con đệ quy, giúp bỏ qua vùng không liên quan khi truy vấn
Tham số capacity (thường từ 4–16) ảnh hưởng trực tiếp đến độ sâu cây và hiệu năng truy vấn
Ứng dụng thực tế: tìm kiếm địa lý, phát hiện va chạm trong game, nén ảnh theo vùng

Agentic Engineering Patterns

Simon Willison — tác giả blog kỹ thuật nổi tiếng — ra mắt một hướng dẫn toàn diện về các mẫu thiết kế (pattern) khi làm việc với AI agent trong lập trình. Điều đáng chú ý là hướng dẫn phân biệt rõ ràng giữa “agentic engineering” và “vibe coding”: vibe coding là để LLM viết mã mà không cần giám sát, còn agentic engineering là kỹ sư chuyên nghiệp dùng agent để khuếch đại chuyên môn sẵn có của mình — không phải thay thế nó.

Một số pattern nổi bật: “Viết mã giờ rất rẻ” — chi phí sinh mã gần như bằng không, buộc phải định nghĩa lại “mã tốt” là mã có kiểm thử, tài liệu, xử lý lỗi đúng chuẩn; “Tích lũy những gì bạn đã biết làm” — duy trì kho ví dụ hoạt động được (blog, repo, POC) để dùng làm đầu vào cho agent, vì biết rằng điều gì đó khả thi khác với đã tự mình làm được; “Red/green TDD” — viết kiểm thử trước, xác nhận kiểm thử thất bại, rồi mới triển khai, đảm bảo agent tạo ra mã đúng chức năng và tối giản. Hướng dẫn được cập nhật liên tục mỗi tuần với 1–2 chương mới.

Điểm chính:

Agentic engineering là khuếch đại chuyên môn kỹ sư, không phải để LLM viết mã không kiểm soát
Tích lũy ví dụ hoạt động được là tài sản nghề nghiệp quan trọng khi làm việc với agent
Red/green TDD giúp agent tạo mã tối giản, đúng chức năng và có lưới an toàn kiểm thử

Things I Miss About Spring Boot After Switching to Go

Sushant Dhiman chia sẻ góc nhìn thực tế sau khi chuyển từ Spring Boot sang Go. Dù Go có nhiều ưu điểm, tác giả thừa nhận có những thứ trong Spring Boot mà Go chưa thể thay thế dễ dàng. Trước hết là triết lý “batteries included” của Spring Boot — hầu hết tính năng cần thiết cho môi trường production đều có sẵn và tích hợp chặt chẽ với nhau.

Cụ thể, tác giả nhớ nhất: Dependency Injection tự động qua annotation (@Service, @Autowired) thay vì phải tự nối dây thủ công qua constructor trong Go; validation khai báo với @NotNull, @Email thay vì viết điều kiện kiểm tra thủ công; và hệ sinh thái trưởng thành gồm Spring Security (xác thực JWT, OAuth), Spring Data (tự sinh câu truy vấn từ tên phương thức), Spring Boot Actuator (giám sát sức khỏe tích hợp sẵn), Spring Cloud (hỗ trợ microservices). Go có các thư viện tương đương nhưng thiếu sự gắn kết thống nhất trong một framework duy nhất.

Điểm chính:

Spring Boot tích hợp sẵn dependency injection, validation khai báo và hệ sinh thái production-ready
Go theo triết lý tối giản — linh hoạt hơn nhưng đòi hỏi tự lắp ráp nhiều thành phần hơn
Cả hai có đánh đổi rõ ràng: Spring Boot tiện lợi hơn, Go đơn giản và hiệu năng cao hơn

Design-First Collaboration with AI

Bài viết từ martinfowler.com giới thiệu phương pháp cộng tác “design-first” với AI để tránh “Implementation Trap” — bẫy mà AI sinh mã quá nhanh khiến các quyết định thiết kế quan trọng bị chôn vùi trong mã nguồn, và lập trình viên chỉ phát hiện ra bất đồng khi đọc lại mã — lúc đó đã quá tốn kém để sửa.

Giải pháp là khung năm cấp độ, không được viết mã cho đến khi cấp độ 5 được phê duyệt: (1) Capabilities — yêu cầu cốt lõi; (2) Components — các khối xây dựng và trừu tượng; (3) Interactions — luồng dữ liệu và giao tiếp; (4) Contracts — chữ ký hàm và interface; (5) Implementation — viết mã. Mỗi cấp độ chỉ kiểm tra một loại quyết định, giảm tải nhận thức đáng kể so với việc xem xét tất cả cùng lúc. Mức độ phức tạp quyết định điểm bắt đầu — tiện ích đơn giản có thể bắt đầu từ cấp 4, tính năng phức tạp bắt đầu từ cấp 1.

Điểm chính:

Đừng để AI viết mã trước khi thống nhất thiết kế — phát hiện bất đồng sớm rẻ hơn rất nhiều
Khung 5 cấp độ tách biệt từng loại quyết định thiết kế, giảm tải nhận thức khi xem xét
Phương pháp này tạo điều kiện tự nhiên cho TDD và ngăn chặn “technical debt injection”

The Two Kinds of Error

Evan Hahn đề xuất một cách phân loại lỗi đơn giản nhưng hữu ích: lỗi expected (có thể xảy ra trong vận hành bình thường, không phải lỗi của lập trình viên) và lỗi unexpected (chỉ xảy ra khi có bug). Lỗi expected bao gồm: đầu vào của người dùng không hợp lệ, mất kết nối mạng, thiếu quyền truy cập — đây là lỗi có thể phục hồi, nên trả về kết quả lỗi và ghi log ở mức WARN hoặc INFO. Lỗi unexpected bao gồm: vi phạm assertion, logic sai, dependency chưa khởi tạo — đây là dấu hiệu của bug thực sự, nên log ở mức ERROR hoặc FATAL, thậm chí nên để chương trình crash hoàn toàn.

Ranh giới giữa hai loại phụ thuộc vào ngữ cảnh: ứng dụng thử nghiệm có thể coi mọi lỗi là unexpected, hệ thống quan trọng (tàu vũ trụ) phải coi gần mọi thứ đều có thể xảy ra. Điều quan trọng là lập trình viên phải có ý thức phân loại từng lỗi thay vì xử lý tất cả theo cùng một cách.

Điểm chính:

Lỗi expected (mạng, đầu vào người dùng) nên được phục hồi và log WARN/INFO
Lỗi unexpected (bug, logic sai) nên log ERROR/FATAL và có thể crash chương trình
Phân loại có ý thức giúp thiết kế xử lý lỗi rõ ràng và đúng mức độ nghiêm trọng

Secure Go Error Handling Best Practices

Blog JetBrains GoLand tập trung vào một khía cạnh thường bị bỏ qua: xử lý lỗi an toàn bảo mật trong Go. Nguyên tắc cốt lõi là tách biệt thông tin nội bộ và thông tin công khai — tạo kiểu lỗi tùy chỉnh chứa cả thông báo nội bộ (chi tiết kỹ thuật cho lập trình viên) và thông báo công khai (thông báo an toàn cho người dùng), tránh việc lỗi nội bộ bị serialized ra HTTP response.

Các thực hành quan trọng: dùng builder pattern để kiểm soát trường metadata nào được ghi log, tránh ghi toàn bộ đối tượng request có thể chứa mật khẩu hay token; dùng opaque wrapping thay vì fmt.Errorf khi không muốn lộ chi tiết triển khai cho phía gọi; và khi truyền lỗi qua ranh giới dịch vụ, chuyển đổi sang lỗi chuẩn hóa (gRPC codes, JSON format), không bao giờ để lỗi do AI sinh ra tiếp cận API công khai. Logging nên dùng log/slog với structured logging và implement interface redaction cho các trường nhạy cảm.

Điểm chính:

Tách lỗi thành thông báo nội bộ (kỹ thuật) và công khai (an toàn) để tránh rò rỉ thông tin
Kiểm soát chặt metadata được ghi log, không ghi toàn bộ request object
API công khai chỉ trả về thông báo tĩnh, định nghĩa sẵn — không bao giờ lỗi được sinh động

AI Coding Tools, Java & Compounding Engineering

Bài viết tổng hợp từ buổi nói chuyện tại NDC Manchester 2025, với luận điểm cốt lõi: “Nếu AI tạo ra mã tệ cho bạn, đó thường là vấn đề workflow, không phải vấn đề mô hình.” Phương pháp được đề xuất là Compounding Engineering — huấn luyện AI như người cộng tác theo thời gian, tương tự onboard lập trình viên junior.

Các yếu tố chính: xóa chat thường xuyên và lưu quyết định kiến trúc vào file markdown (như CLAUDE.md) thay vì cố duy trì ngữ cảnh trong một cuộc trò chuyện dài; cập nhật “living rule files” mỗi khi sửa bug để lỗi không tái diễn; lên kế hoạch trước khi viết mã để phát hiện giả định sai ngay từ đầu; chia tính năng thành các tác vụ nhỏ, tập trung một trách nhiệm. Kỹ sư senior đóng góp giá trị qua taste — khả năng đánh giá kiến trúc và đánh đổi, điều mà AI giỏi sinh mã nhưng yếu phán xét chất lượng. Kết quả tích lũy theo thời gian; không đầu tư vào workflow thì chỉ có “mediocrity nhanh hơn”.

Điểm chính:

Mã AI kém chất lượng thường do workflow kém, không phải do mô hình
Lưu quyết định kiến trúc vào file markdown, cập nhật khi sửa bug để kiến thức tích lũy
Giá trị của kỹ sư senior nằm ở khả năng phán xét kiến trúc — thứ AI chưa làm tốt

YAML? That’s Norway Problem

Bài viết khám phá một lỗi phân tích cú pháp thú vị trong YAML: mã quốc gia NO (Na Uy) bị các trình phân tích cú pháp phổ biến chuyển thành giá trị boolean false thay vì chuỗi ký tự. Nguyên nhân là YAML xử lý một số từ tiếng Anh như yes/no, true/false, on/off dưới dạng giá trị boolean — tính năng này được giới thiệu từ YAML v1.0 (2004) nhằm làm cho tệp cấu hình dễ đọc hơn.

Dù YAML v1.2 (2009) đã loại bỏ hành vi này để tương thích với JSON, hầu hết các thư viện phổ biến như PyYAML và LibYAML vẫn triển khai theo đặc tả v1.1 — tạo ra khoảng cách lớn giữa tiêu chuẩn và thực tế sau hơn 15 năm. Người dùng có thể tránh vấn đề này bằng cách đặt chuỗi trong dấu ngoặc kép ("NO"), dùng thẻ kiểu tường minh (!!str), hoặc chuyển sang thư viện tương thích v1.2 như ruamel.yaml hay yq.

Điểm chính:

NO trong YAML bị hiểu là false do quy tắc boolean từ đặc tả v1.1
YAML v1.2 đã sửa lỗi này từ năm 2009 nhưng hầu hết thư viện chưa cập nhật
Giải pháp: dùng dấu ngoặc kép, thẻ !!str, hoặc thư viện tương thích v1.2

Bài viết đã được review và cập nhật bởi Claude Code với Opus 4.7 (1M context).

Newsletter #77

Sat, 24 Jan 2026 00:00:00 +0700

Mời bạn thưởng thức Newsletter #77.

Đừng Chuyển Tiếp Lỗi, Hãy Thiết Kế Chúng

Bài viết này phân tích sâu về các vấn đề trong xử lý lỗi hiện nay, đặc biệt là trong hệ sinh thái Rust. Tác giả chỉ ra rằng chúng ta thường “chuyển tiếp” lỗi hơn là thực sự “thiết kế” chúng - bắt lỗi, bọc (đôi khi), và ném lên stack nhanh nhất có thể. Điều này dẫn đến việc lỗi vẫn giữ nguyên thông điệp gốc nhưng mất đi toàn bộ ngữ cảnh quan trọng.

Bài viết phê phán các cách tiếp cận phổ biến như thiserror (phân loại theo nguồn gốc chứ không phải hành động), anyhow (quá tiện lợi khiến lập trình viên quên thêm ngữ cảnh), stack traces (tốn kém và chỉ hiện điểm xuất phát chứ không phải đường đi logic), và API Provide/Request (quá phức tạp với hành vi khó dự đoán). Thay vào đó, tác giả đề xuất xử lý lỗi nên được thiết kế với hai đối tượng: máy móc (cần cấu trúc phẳng, các loại rõ ràng, mã có thể dự đoán cho việc tự động phục hồi) và con người (cần ngữ cảnh phong phú, đường đi luồng, thông tin cấp độ kinh doanh để gỡ lỗi).

Điểm chính:

Xử lý lỗi nên được thiết kế dựa trên ý định: “người gọi có thể làm gì với lỗi này?” thay vì “lỗi này đến từ đâu?”
Cho máy móc: sử dụng các loại lỗi phẳng dựa trên phân loại với trạng thái rõ ràng (Tạm thời/Liên tục/ persists) thay vì chuỗi lỗi lồng nhau
Cho con người:捕获 ngữ cảnh tự động và thuận tiện, bắt buộc tại ranh giới module để không thể lười biếng
Mô hình thực tế: kết hợp cấu trúc lỗi phân loại với cơ chế theo dõi ngữ cảnh (như thư viện exn)
Sử dụng #[track_caller] để捕获 vị trí với chi phí bằng không thay vì stack traces đắt đỏ

Đồng Bộ Hóa Thời Gian Là Cơn Ác Mộng

Đồng hồ là một thứ tưởng đơn giản nhưng lại là cơn ác mộng của các kỹ sư phần mềm làm việc với hệ thống phân tán. Bài viết này giải thích tại sao không có “đồng hồ toàn cục” và cách hàng ngàn máy tính rải rác across nhiều data centers bị trôi drift apart theo thời gian. Mỗi máy tính có đồng hồ nội tại dựa trên crystal thạch anh với tần số 32768 Hz, nhưng những crystal này không hoàn hảo - sự chênh lệch nhiệt độ chỉ khoảng 10°C có thể gây ra trôi drift khoảng 110 giây mỗi năm. Kết quả là hai máy tính khởi động cùng thời gian sẽ bị lệch nhau hàng trăm mili-giây chỉ sau một ngày.

Sự lệch đồng hồ gây ra nhiều vấn đề nghiêm trọng. Ví dụ với hệ thống make phân tán, nếu đồng hồ máy client bị chậm và đồng hồ máy server chạy nhanh, file object đã biên dịch sẽ trông mới hơn file source bạn vừa edit, khiến lệnh make không biên dịch lại và những thay đổi của bạn bị bỏ qua. Hệ thống cơ sở dữ liệu còn nghiêm trọng hơn - trong hệ thống ngân hàng, nếu giao dịch rút tiền có timestamp sớm hơn giao dịch nộp tiền do đồng hồ không đồng bộ, snapshot read có thể hiển thị giao dịch rút nhưng không hiển thị giao dịch nộp, khiến khách hàng trông như đã rút tiền họ không có. Tác giả cũng thảo luận các giải pháp: Thuật toán Cristian (ước lượng độ trễ một chiều bằng một nửa vòng đi vòng về), Thuật toán Berkeley (đồng thuận giữa các máy, tính trung bình và gửi các điều chỉnh tương đối thay vì thời gian tuyệt đối), NTP với hệ thống phân tầng phân cấp (Stratum 0 là đồng hồ nguyên tử/GPS, Stratum 1-15 là các lớp phía dưới), và PTP (Giao thức Thời Gián Chính Xác) với đánh dấu thời gian bằng phần cứng đạt độ chính xác dưới micro-giây.

Điểm chính:

Clock skew = sự khác biệt giữa hai đồng hồ tại một thời điểm, Clock drift = tốc độ các đồng hồ phân kỳ theo thời gian
NTP đạt độ chính xác 10-100ms trên internet công cộng, 100-500µs trên mạng LAN, nhưng bị giới hạn bởi sự bất đối xứng mạng
PTP sử dụng đánh dấu thời gian bằng phần cứng tại tầng NIC để đạt độ chính xác nano-giây, nhưng cần các switch hỗ trợ PTP
Đồng hồ logic (Lamport Timestamps, Vector Clocks)捕获 quan hệ nhân quả thay vì thời gian vật lý
Google Spanner’s TrueTime sử dụng GPS + đồng hồ nguyên tử, trả về khoảng [sớm nhất, muộn nhất] thay vì timestamp đơn
Đồng hồ logic lai (CockroachDB, YugabyteDB) kết hợp thời gian vật lý với thành phần logic
Giây nhuận sẽ bị loại bỏ vào năm 2035, nhưng hiện tại Google/AWS dùng “kéo dài giây nhuận” để trải đều qua nhiều giờ

Roadmap Học Java

Đây là một lộ trình học Java toàn diện từ cơ bản đến nâng cao. Roadmap được chia thành năm phần chính: Nền tảng (Linux, Git, IDE), Lập trình hướng đối tượng (classes, objects, inheritance, polymorphism, encapsulation, abstraction), Java cốt lõi (Collections Framework, Exception Handling, Streams), Các khái niệm nâng cao (Concurrency & Multithreading, JVM internals, Design Patterns, Dependency Injection), và Phát triển chuyên nghiệp (Testing, Build Tools như Maven & Gradle, Databases), đặc biệt là Spring Boot Framework với REST APIs, Clean Code và SOLID principles.

Điểm chính:

Bắt đầu với nền tảng: Linux basics, Git version control, và chọn IDE phù hợp (IntelliJ, Eclipse, VSCode)
Nắm vững OOP fundamentals: classes, objects, inheritance, polymorphism, encapsulation, abstraction
Thành thạo Collections Framework: Lists, Sets, Maps, Queues, Optionals, Streams
Hiểu sâu về Exception Handling: checked vs unchecked exceptions, custom exceptions
Học Concurrency & Multithreading: thread basics, concurrent collections, ExecutorService, thread pools
Tìm hiểu JVM internals và Design patterns phổ biến
Làm việc với build tools (Maven, Gradle) và databases (JDBC, schema migration)
Phát triển Enterprise Java với Spring Boot: Spring Core, Spring Data, JPA, REST APIs
Áp dụng Clean Code, SOLID principles, và best practices về API design, logging, monitoring

Hướng Dẫn Toàn Diện Triển Khai Kotlin Trong Môi Trường Java

Đây là hướng dẫn hoàn chỉnh để triển khai Kotlin từng bước, từ những bài kiểm tra ban đầu đến triển khai quy mô lớn. Adopting Kotlin trong công ty thiên về Java không phải là flipping a switch hay viết lại mọi thứ, mà là về con người, thời điểm, rủi ro và sự tin tưởng. Guide bao gồm năm phần: Bắt đầu với Kotlin cho Java developers (viết tests bằng Kotlin, dùng Kotest và MockK), Đánh giá Kotlin trong projects thực tế (start new service in Kotlin, add Kotlin modules, tránh “Java in Kotlin syntax” trap), Phát triển việc adoption Kotlin trong công ty (share examples, starter repository, pairing sessions, build community), Giúp decision-makers nói yes với Kotlin (less code, fewer defects, no rewriting, developer happiness, predictable costs), và Scaling adoption across organization (treat systems differently based on lifecycle, dùng right tools như IDE conversion, null-safety annotations, AI-assisted refactoring).

Điểm chính:

Bắt đầu nhỏ: introduce Kotlin thông qua test suite để không ảnh hưởng production
Tránh “Java in Kotlin syntax” trap: dùng extension functions thay vì static helpers, nullable types thay vì Optional, data classes thay vì boilerplate
Xây dựng community trong nội bộ: share starter repository, tổ chức clinics và pairing sessions
Thuyết phục managers: less code để maintain, fewer defects nhờ null safety, no rewriting required nhờ full Java interop
Scaling strategy: leave end-of-life apps, default new builds to Kotlin, migrate active systems step-by-step không phải big-bang rewrites
Sử dụng tools phù hợp: IDE conversion, JSpecify null-safety annotations, AI-assisted refactoring, rule-based automation

So Sánh Rust và Go Năm 2026

Bài viết này so sánh hai ngôn ngữ lập trình phổ biến Rust và Go across nhiều khía cạnh: performance, simplicity, safety, features, scale, concurrency. Tóm tắt ngắn gọn: “Rust for high stakes, Go for low costs” - Rust cho mission-critical software cần safety và reliability, Go cho việc move fast và keep costs down. Cả hai đều là compiled languages với fast, compact executables, đều có pragmatic programming style và excellent tooling cho development at scale (gofmt, rustfmt, standard build tools). Tuy nhiên, Rust prioritizes safety, correctness, efficiency với borrow checker preventing memory errors, trong khi Go prioritizes simplicity và speed of development với garbage collector và minimal syntax. Go có goroutines và channels làm concurrency cực kỳ easy, Rust có match syntax và powerful features nhưng learning curve steeper. Error handling: Go dùng explicit if err != nil, Rust dùng Option/Result types với ? operator.

Điểm chính:

Performance: Rust beat Go ở run-time benchmarks nhờ no garbage collection và closer to metal optimizations
Simplicity: Go cực kỳ easy to learn (productive sau 2 days), Rust có nhiều features hơn và learning curve steeper
Concurrency: Go nổi tiếng với goroutines và channels cho high-scale concurrent apps, Rust có rayon crate và memory safety cho concurrency
Safety: Rust’s borrow checker prevents memory safety bugs tại compile time, Go relies trên programmer discipline
Scale: Go tốt cho big organisations với distributed teams nhờ uniform style và fast build times
Garbage collection: Go has GC (simpler nhưng unpredictable pauses), Rust manual memory management (harder nhưng predictable)
Error handling: Go explicit if err != nil, Rust powerful Option/Result với ? operator
Conclusion: “Should I learn Rust or Go?” → “Yes” - learn both, mỗi ngôn ngữ excels trong domain của nó

Dependency Phổ Biến Nhất Trong Go Là Gì?

Bài viết này trả lời câu hỏi về dependency phổ biến nhất trong hệ sinh thái Go thông qua việc phân tích toàn bộ Go modules ecosystem. Tác giả đã download toàn bộ index từ proxy.golang.org (từ 2019), build một dependency graph với 40 triệu nodes và 400 triệu relationships trong Neo4j database, từ đó extract ra các thống kê thú vị. Top 10 dependencies được sử dụng nhiều nhất: testify (259,237 dependents), google/uuid (104,877), golang.org/x/crypto (100,633), grpc (97,228), cobra (93,062), pkg/errors (92,491), golang.org/x/net (76,722), protobuf (74,971), logrus (71,730), viper (64,174). Testify là library được sử dụng rộng rãi nhất, đặc biệt là cho testing. Tác giả cũng demo cách query Neo4j để find direct/transitive dependents, ví dụ như github.com/pkg/errors@v0.9.1 vẫn có 16,001 dependents trong năm 2025 dù đã bị deprecated từ lâu.

Điểm chính:

Go modules có trung bình 10 direct dependencies
Testify (github.com/stretchr/testify) là dependency phổ biến nhất với 259,237 dependents
Top dependencies bao gồm testing frameworks (testify), utilities (uuid, crypto, net), CLI tools (cobra, viper), logging (logrus)
Extended stdlib (golang.org/x/) giữ vị trí mạnh trong ecosystem
Các deprecated libraries như pkg/errors vẫn được sử dụng rộng rãi (92,491 dependents)
Neo4j graph database非常适合 analyzing dependency relationships với Cypher query language
Tác giả chia sẻ Neo4j dump via BitTorrent để community có thể chạy own queries

go.sum Không Phải Lockfile

Bài viết này làm rõ sự hiểu lầm phổ biến về go.sum trong Go modules. Nhiều người nghĩ go.sum là lockfile (như package-lock.json của Node hay Cargo.lock của Rust), nhưng thực tế go.sum chỉ là bộ nhớ đệm cục bộ cho Go Checksum Database - một ánh xạ từ các phiên bản module đến các mã băm mật mã của chúng. Những phiên bản này có thể được sử dụng hoặc không, không ảnh hưởng đến việc phân giải gói. go.sum thậm chí không được bật theo mặc định trong thiết kế modules ban đầu vì không có tác động quan sát được trên quá trình xây dựng! Mục đích duy nhất của nó là tăng cường câu chuyện bảo mật: Checksum Database đảm bảo toàn bộ hệ sinh thái chia sẻ cùng một nội dung cho một phiên bản module, bất kể cách tải xuống, và go.sum làm cho lời đảm bảo đó trở nên cục bộ và tự chứa.

Thay vào đó, hãy nhìn vào go.mod - nó đóng vai trò既是 manifest又是 lockfile. Từ Go 1.17 (tháng 8 năm 2021), go.mod bao gồm tất cả các phụ thuộc chuyển tiếp cần thiết để xây dựng module chính và các bài kiểm tra của nó. Khác với các hệ sinh thái khác với manifest (các phạm vi phiên bản phức tạp) và lockfile (các phiên bản thực tế), Go đơn giản hơn với một tệp có thể đọc được bởi con người: go.mod liệt kê tất cả các phụ thuộc (trực tiếp và chuyển tiếp) và phiên bản chính xác của chúng. Không có xung đột phụ thuộc hình kim cương, không có cách nào vô tình sử dụng tính năng được giới thiệu trong phiên bản mà các phần phụ thuộc sẽ không có, và không có cập nhật tự động lên phiên bản mới nhất của các phụ thuộc khi thêm phụ thuộc mới.

Điểm chính:

go.sum không phải lockfile, chỉ là bộ nhớ đệm cục bộ cho Go Checksum Database với các mã băm mật mã
go.mod đóng vai trò既是 manifest又是 lockfile - liệt kê tất cả các phụ thuộc và phiên bản chính xác
Từ Go 1.17, go.mod bao gồm tất cả các phụ thuộc chuyển tiếp cho module chính và bài kiểm tra
Go modules đơn giản hơn nhiều so với các lựa chọn thay thế: không có phạm vi phiên bản, không có xung đột hình kim cương, không có vấn đề đồng bộ hóa lockfile
Việc phân giải gói trong Go là tức thời nên không ai nhận thấy nó đang xảy ra
Phân tích go.mod bằng golang.org/x/mod/modfile hoặc go mod edit -json, không bao giờ phân tích go.sum
Để phân tích đồ thị phụ thuộc, dùng go.mod, không phải go.sum

Phát Triển Thông Báo Actions Cho Forgejo

Bài viết này chia sẻ kinh nghiệm đóng góp vào Forgejo - một mã nguồn tự chủ tương tự GitHub/GitLab. Tác giả cần tính năng gửi thông báo email và webhook khi CI workflow thất bại, nhưng Forgejo chưa có, nên ông ấy quyết định đóng góp. Bài viết giải thích chi tiết cấu trúc dự án Go, kiến trúc phân lớp của Forgejo, và mô hình publish-subscribe (pub-sub) được sử dụng để tránh các phụ thuộc vòng tròn. Tác giả chia quá trình thành nhiều pull requests: PR #7510 tái cấu trúc code từ layer thấp lên layer cao, PR #7491 thêm topic ActionRunNowDone vào pub-sub system, PR #7509 triển khai gửi email khi workflow thất bại/phục hồi, và PR #7508 triển khai gửi webhook. Bài viết cũng hướng dẫn chi tiết cách thiết lập môi trường phát triển: Forgejo instance, Forgejo runner, mail server (MailDev), webhook tester, và cách chạy tests với Delve debugger.

Điểm chính:

Go projects sử dụng modules (với go.mod) và packages (nhóm code), với hệ thống phân tán không có central package index như NPM
Forgejo dùng kiến trúc phân lớp 3 tầng: modules (tự chứa, có thể dùng như library), models (database abstraction), services (logic), routers (API/web UI) - code ở layer thấp không được import code ở layer cao
Pub-sub pattern giải quyết cyclic dependencies: packages gửi messages đến topics (ví dụ PullRequestReview), và các packages khác subscribe vào topics đó
Tác giả chia feature thành 4 PRs để dễ review: refactoring, thêm topic, triển khai email, triển khai webhook
Development setup cần Forgejo instance, runner, mail server (MailDev), webhook tester node script
Debug với Delve debugger, chạy unit tests và integration tests với make commands
Viết tests rất quan trọng để maintainers có thể verify code vẫn hoạt động đúng

Bonus

Hình ảnh:

Bài viết đã được review và cập nhật bởi Claude Code với Opus 4.7 (1M context).