Engineering Career on miti99

Newsletter #82

Thu, 19 Feb 2026 00:00:00 +0700

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

How the Lobsters front page works

Bài viết phân tích thuật toán xếp hạng trang chủ của Lobsters - một cộng đồng tập trung vào lĩnh vực máy tính với tính năng agregate liên kết và thảo luận. Vì mã nguồn mở, tác giả đã nghiên cứu cách thức hoạt động của thuật toán sắp xếp bài viết trên trang chủ.

Công thức cốt lõi của thuật toán khá đơn giản: hotness = -1 × (base + order × sign + age), trong đó giá trị hotness càng âm thì bài viết xếp hạng càng cao. Thành phần base được tính từ tổng các điều chỉnh hotness của thẻ tag (nằm trong khoảng -10 đến +10) cộng với một khoản nhỏ khuyến khích cho bài tự viết. Một thẻ như culture hay rant có modifier âm, làm giảm thứ hạng ban đầu.

Thành phần order phản ánh mức độ tương tác thông qua logarithm của điểm số, đồng thời tính thêm điểm bình luận (mỗi upvote bình luận bằng nửa upvote bài viết). Điều này có nghĩa là tăng từ 0 lên 100 phiếu ảnh hưởng thứ hạng nhiều hơn nhiều so với tăng từ 1000 lên 1100 phiếu. Thành phần age tăng tuyến tính theo thời gian, đẩy các bài cũ xuống xếp hạng thấp dần.

Tác giả nhận xét thuật toán này hoạt động tốt - cho phép bài viết mới có thời gian hiển thị, trừng phạt nội dung chất lượng thấp tạo ra nhiều tranh căng, và đảm bảo không bài nào tồn tại quá lâu trên trang chủ. Tuy nhiên, tính cách của cộng đồng Lobsters không đến từ thuật toán mà từ sự điều_triệt có quan điểm, phạm vi hẹp về máy tính, và hệ thống mời dần dần xây dựng văn hóa. Tác giả cũng chia sẻ trải nghiệm cá nhân về sự ngắt kết nối giá trị với nhóm người dùng tích cực nhất trên site, và nhắc nhở rằng sự tham gia của từng người dùng là quan trọng - các upvote sớm có thể đưa bài viết lên trang chủ.

Software engineers can no longer neglect their soft skills

Bài viết lập luận rằng bắt đầu từ năm 2026, kỹ năng giao tiếp đã trở thành kỹ năng quan trọng nhất cho kỹ sư phần mềm - không phải là viết mã, thiết kế hệ thống hay kiến thức chuyên sâu về ngôn ngữ lập trình. AI coding agent đã trở nên rất xuất sắc, tác giả chia sẻ đã chi hơn 500 USD cho Claude Code chỉ trong tháng 12 năm ngoái và sử dụng nó cho hầu hết các tác vụ lập trình không đơn giản.

Vấn đề cốt lõi là nút thắt đã chuyển từ việc cài triển khai sang việc xác định thông số kỹ thuật. Trong thực tế, các ticket hiếm khi chứa đầy đủ yêu cầu. Để làm được điều đó, kỹ sư cần: đặt câu hỏi để làm rõ các giả định mà mọi người không nhận ra themselves, điều phối các thảo luận đánh đổi, từ chối mở rộng phạm vi mà không làm hỏng mối quan hệ, và đưa ra quyết định cho những việc không ai nghĩ đến cần quy định.

Trước đây, những kỹ năng này chỉ là tùy chọn cho individual contributor. Một số nhóm cho phép kỹ sư phát triển với kỹ năng giao tiếp trung bình nhưng kỹ năng viết mã xuất sắc. Nay, các phần không liên quan đến viết mã đang trở thành không thể thương lượng. Kỹ sư phần mềm là người giải quyết vấn đề, chúng ta tin rằng mọi vấn đề đều có giải pháp và “best practice”. Nhưng làm việc với con người phức tạp hơn nhiều. May mắn là chúng ta không thể dùng AI để cải thiện kỹ năng giao tiếp. Giao tiếp tốt đòi hỏi sự thấu cảm - điều mà chúng ta đều cần thêm trong bối cảnh hiện nay.

Dithering - Part 2

Bài viết là phần thứ hai trong series về dithering - kỹ thuật dùng để mô phỏng nhiều màu sắc hơn so với những gì thực tế có sẵn. Tác giả tập trung vào ordered dithering, một phương pháp sử dụng threshold map để quyết định màu cuối cùng của mỗi pixel. Series này chỉ bao gồm dithering grayscale xuống hai màu đen và trắng.

Tác giả giải thích cách hoạt động của threshold map: thay vì dùng một ngưỡng đơn để chuyển đổi xám thành đen hoặc trắng, ta sử dụng nhiều ngưỡng khác nhau cùng lúc. Kết quả là một hỗn hợp các pixel đen và trắng phản ánh độ sáng ban đầu - vùng sáng hơn có nhiều pixel trắng hơn, vùng tối hơn có nhiều pixel đen hơn.

Vấn đề đầu tiên là các ngưỡng được sắp xếp tuần tự tạo ra các vạch dọc không mong muốn. Giải pháp là Bayer matrix - sắp xếp lại các ngưỡng theo mẫu 2x2 tạo ra pattern cross-hatch đặc trưng, giúp phân tán đều các pixel đen và trắng. Tuy nhiên, chỉ có 4 mức ngưỡng thì chuyển giữa các sắc thái vẫn khá gắt. Tác giả giới thiệu Bayer matrix 4x4 với 16 mức ngưỡng, cho phép 16 sắc thái xám khác nhau và chuyển mượt mà hơn.

Bài viết cũng giới thiệu một số phương pháp sắp xếp threshold map khác nhau: Bayer matrix 8x8 với 64 mức cho gradient chi tiết hơn, Cluster Dot matrix tạo ra cảm giác như báo in truyền thống với các chấm tròn, và Void and Cluster - phương pháp yêu thích của tác giả với blue noise tạo ra texture tự nhiên hơn. Phần tiếp theo sẽ bàn về error diffusion, một phương pháp dithering khác không dùng map.

What came first: the CNAME or the A record?

Bài viết phân tích một sự cố DNS xảy ra vào ngày 8 tháng 1 năm 2026 khi Cloudflare cập nhật 1.1.1.1 để giảm mức sử dụng bộ nhớ. Thay đổi vô tình đã làm đảo ngược thứ tự của bản ghi CNAME trong phản hồi DNS, gây ra lỗi phân giải cho một số ứng dụng khách trên toàn Internet.

Vấn đề gốc rễ nằm ở logic gộp chuỗi CNAME. Khi một số bản ghi trong chuỗi CNAME hết hạn, chỉ có phần hết hạn được giải quyết lại. Code cũ sẽ tạo danh sách mới, thêm chuỗi CNAME hiện có rồi thêm các bản ghi mới vào sau. Để tiết kiệm cấp phát bộ nhớ, code mới thay đổi bằng cách thêm CNAME vào cuối danh sách answer hiện có - khiến CNAME xuất hiện sau bản ghi A/AAAA.

Một số triển khai DNS như getaddrinfo trong glibc và quy trình DNSC trong switch Cisco sử dụng phân tích tuần tự - theo dõi tên mong đợi khi duyệt qua các bản ghi. Khi gặp CNAME, tên mong đợi được cập nhật. Nếu CNAME xuất hiện cuối cùng, các bản ghi A/AAAA bị bỏ qua vì không khớp tên, dẫn đến phản hồi rỗng. systemd-resolved không gặp vấn đề này vì nó phân tích bản ghi vào một tập hợp có thứ tự và có thể tìm kiếm toàn bộ.

RFC 1034 từ năm 1987 sử dụng cụm “possibly preface” để nói về CNAME nhưng không dùng từ khóa normative như MUST/SHOULD - RFC 2119 mới ra năm 1997. RFC cũng rõ ràng về thứ tự trong RRset nhưng mơ hồ về thứ tự tương đối giữa các RRset khác nhau trong phần thông điệp. Cloudflare đã hoàn tác thay đổi và viết đề xuất Internet-Draft để làm rõ hành vi tại IETF, giúp cộng đồng DNS điều hướng giao thức này tốt hơn.

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

Newsletter #70

Sat, 13 Dec 2025 00:00:00 +0700

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

The developer productivity paradox: Why faster coding doesn’t mean faster software delivery

Bài viết khám phá Nghịch lý Năng suất Nhà phát triển, nơi các công cụ AI giúp lập trình nhanh hơn nhưng chỉ số tổ chức lại không cải thiện. Mặc dù 90% nhà phát triển sử dụng AI và 80% cảm thấy năng suất hơn, sự bất ổn hệ thống lại tăng do AI có tỷ lệ dự đoán sai cố hữu. Vấn đề gốc rễ là chuyển đổi ngữ cảnh đã hấp thụ lợi ích năng suất, và AI giới thiệu các gián đoạn mới trong quá trình xác thực và gỡ lỗi. Giải pháp là tổ chức cần Kỹ thuật Năng suất Nhà phát triển (DPE) để củng cố hệ thống phân phối, thiết kế lại quy trình làm việc cho hiệu quả luồng công việc, và thay đổi cách đo lường từ các chỉ số hoạt động sang các chỉ số luồng/kết quả.

Điểm chính:

90% nhà phát triển dùng AI nhưng sự bất ổn hệ thống vẫn tăng
Chuyển đổi ngữ cảnh hấp thụ lợi ích năng suất từ AI
Cần framework DPE: củng cố hệ thống phân phối, thiết kế lại quy trình làm việc, đo lường kết quả
Đầu tư vào kỹ thuật nền tảng, vòng lặp phản hồi CI/CD, quản lý luồng giá trị

What Actually Makes You Senior

Kỹ năng cốt lõi phân biệt các kỹ sư cấp cao là giảm thiểu sự mơ hồ. Trong khi các kỹ sư cấp trung xuất sắc với các vấn đề được định nghĩa rõ, các kỹ sư cấp cao biến các yêu cầu mơ hồ như “cải thiện hiệu suất” thành các kế hoạch cụ thể và có thể thực hiện được. Các kỹ sư cấp cao hỏi các câu hỏi quan trọng: “Chúng ta thực sự đang cố gắng giải quyết vấn đề gì?” và “Ai là người dùng ở đây và điều gì gây khó khăn cho họ?” Họ xác định các giả định ẩn và đánh giá các nhược điểm tiềm tàng. Giá trị của họ nằm ở việc giảm thiểu rủi ro dự án bằng cách làm cho các vấn đề trừu tượng trở nên cụ thể.

Bài viết chỉ trích các phương pháp tuyển dụng hiện tại tập trung vào kỹ năng kỹ thuật thay vì giảm thiểu sự mơ hồ, lưu ý rằng nhiều kỹ sư “cấp cao” có thể giải quyết các vấn đề được định nghĩa rõ nhưng lại bị tê liệt với các thông số kỹ thuật không rõ ràng. Tác giả gợi ý rằng cấp độ cao có thể được phát triển qua thực hành, bắt đầu với các ticket mơ hồ và học cách làm rõ chúng ngay từ đầu thay vì chờ đợi người khác hoặc lập trình ngay lập tức. Công việc cấp cao thường trông vô hình khi làm tốt - các dự án đơn giản chạy trơn tru với ít bất ngờ hơn.

Điểm chính:

Kỹ năng cốt lõi: giảm thiểu sự mơ hồ, không chỉ giải quyết các vấn đề được định nghĩa rõ
Các kỹ sư cấp cao hỏi “Chúng ta thực sự đang giải quyết vấn đề gì?” và “Ai là người dùng?”
Giá trị nằm ở việc giảm thiểu rủi ro dự án bằng cách làm các vấn đề trừu tượng trở nên cụ thể
Phương pháp tuyển dụng sai lầm khi tập trung vào kỹ năng kỹ thuật thay vì giảm thiểu sự mơ hồ
Cấp độ cao có thể phát triển qua thực hành với các ticket mơ hồ

Becoming unblockable

Tác giả cung cấp các chiến lược cụ thể để trở nên “không thể bị chặn” - duy trì tiến độ về phía trước bất chấp trở ngại. Lời khuyên chính bao gồm: làm việc trên nhiều nhiệm vụ đồng thời để chuyển giữa luồng công việc khi một trong số bị chặn; sắp xếp thứ tự dự án để xử lý các rào cản tiềm tàng sớm (phần gây tranh cãi, các phụ thuộc); ưu tiên môi trường phát triển ổn định sử dụng các công cụ tiêu chuẩn để tối đa hóa thời gian hiệu quả; gỡ lỗi các vấn đề ngoài khu vực trách nhiệm thay vì chờ đợi các đội khác; xây dựng mối quan hệ với các kỹ sư trên các đội khác để có sự hợp tác không chính thức nhanh hơn; tận dụng các quản lý cấp cao làm “hỗ trợ từ trên cao” để xóa các rào cản tổ chức; và chọn các dự án phù hợp với các ưu tiên của công ty để có sự ủng hộ của nhà điều hành.

Tác giả nhấn mạnh rằng việc bị chặn thường phụ thuộc vào sự chuẩn bị, các mối quan hệ, và quản lý dự án chiến lược thay vì các hoàn cảnh bên ngoài. Việc trở nên không thể bị chặn không phải là kỹ thuật mà là sự kết hợp của lập kế hoạch, xây dựng mạng lưới, và tư duy chiến lược.

Điểm chính:

Làm việc trên nhiều nhiệm vụ để chuyển đổi khi bị chặn
Sắp xếp thứ tự dự án để giải quyết các rào cản sớm
Môi trường phát triển ổn định với các công cụ tiêu chuẩn
Gỡ lỗi các vấn đề ngoài trách nhiệm thay vì chờ đợi
Xây dựng mối quan hệ liên đội để hợp tác nhanh hơn
Tận dụng các quản lý cấp cao làm hỗ trợ từ trên cao
Chọn các dự án phù hợp để có sự ủng hộ của nhà điều hành

Treat test code like production code

Bài viết lập luận rằng mã kiểm thử nên được đối xử với cùng tiêu chuẩn như mã sản xuất vì nó cần bảo trì và khả năng đọc hiểu. Các vấn đề phổ biến trong mã kiểm thử bao gồm vi phạm nguyên tắc DRY, mã zombie, các chờ đợi tùy ý, và xử lý không đồng bộ không phù hợp. Tác giả nhấn mạnh rằng các tiêu chuẩn mã hóa tồn tại chủ yếu cho sự hiểu biết của con người và khả năng bảo trì, không phải cho thực thi máy tính. Vì mã kiểm thử chiếm một phần đáng kể của cơ sở mã, áp dụng các phương pháp tốt như giữ nó DRY ngăn chặn các vấn đề như “Phẫu thuật Shotgun” nơi các thay đổi yêu cầu sửa đổi trên nhiều bài kiểm thử.

Bài viết tham khảo các Mẫu Kiểm thử xUnit như là tài nguyên toàn diện cho các phương pháp kiểm thử cụ thể và phản đối quan niệm rằng các bài kiểm thử nên là DAMP thay vì DRY, lưu ý rằng các cụm từ mang tính mô tả và có ý nghĩa không xung đột với việc tránh trùng lặp. Các ngoại lệ tồn tại, đặc biệt trong các phương pháp bảo mật - mã kiểm thử có thể mã hóa cứng mật khẩu và bỏ qua xác thực đầu vào vì nó không được triển khai đến sản xuất. Các miễn lệ đặc thù nền tảng cũng có thể áp dụng, như các quy tắc ConfigureAwait trong .NET hoặc các thể chế mồ côi trong Haskell.

Điểm chính:

Mã kiểm thử cần cùng tiêu chuẩn như mã sản xuất cho khả năng bảo trì
Các vấn đề phổ biến: vi phạm DRY, mã zombie, chờ đợi tùy ý, không đồng bộ không phù hợp
Tiêu chuẩn mã hóa phục vụ sự hiểu biết của con người, không phải thực thi máy tính
Áp dụng DRY trong các bài kiểm thử để ngăn chặn các vấn đề “Phẫu thuật Shotgun”
Ngoại lệ cho bảo mật (mã hóa cứng mật khẩu) và các quy tắc đặc thù nền tảng
Các Mẫu Kiểm thử xUnit là tài nguyên toàn diện cho các phương pháp kiểm thử

How good engineers write bad code at big companies

Bài viết giải thích tại sao các công ty công nghệ lớn lại tạo ra mã có chất lượng thấp đáng ngạc nhiên mặc dù tuyển dụng các kỹ sư có năng lực. Lý do chính là “các công ty lớn đầy rẫy các kỹ sư làm việc ngoài lĩnh vực chuyên môn của họ” do tỷ lệ nghỉ việc cao - hầu hết nhân viên chỉ ở lại “một hoặc hai năm” trước khi chuyển đến các đội khác hoặc công ty khác. Hầu hết các thay đổi mã được thực hiện bởi những người mới bắt đầu tương đối làm việc trong các cơ sở mã không quen thuộc. Các “lão làng” có kinh nghiệm bị quá tải và phát triển chuyên môn của họ là không chính thức thay vì có hệ thống.

Kỹ sư năng lực trung bình có năng lực nhưng “cố gắng làm hết sức trong một môi trường không được thiết lập để tạo ra mã chất lượng”. Các công ty công nghệ lớn cố tình ưu tiên sự linh hoạt nội bộ hơn chất lượng phần mềm. Các kỹ sư cá nhân không có sức mạnh để thay đổi động lực tổ chức này. Tác giả lập luận rằng mã xấu là không thể tránh khỏi trong các bối cảnh “kỹ thuật không thuần túy” nơi các kỹ sư làm việc dưới áp lực thời hạn trên các hệ thống không quen thuộc, đối lập với “kỹ thuật thuần túy” nơi các sai lầm chủ yếu cho thấy sự thiếu năng lực. Nguyên nhân gốc rễ là “hầu hết các kỹ sư công ty lớn bị buộc phải làm hầu hết công việc của họ trong các cơ sở mã không quen thuộc.”

Điểm chính:

Mã xấu tại các công ty lớn do các kỹ sư làm việc ngoài chuyên môn
Tỷ lệ nghỉ việc cao: kỹ sư chỉ ở lại 1-2 năm trước khi chuyển đội
Hầu hết các thay đổi được thực hiện bởi người mới bắt đầu trong các cơ sở mã không quen thuộc
Các công ty ưu tiên sự linh hoạt hơn chất lượng phần mềm
Các kỹ sư cá nhân không có sức mạnh để thay đổi động lực tổ chức
“Kỹ thuật không thuần túy” với áp限 thời hạn và hệ thống không quen thuộc tạo ra mã xấu

The Success Trap

Bài viết khám phá cách thành công có thể nghịch lý lại giới hạn tự do và các lựa chọn. Nghịch lý của Tiến bộ: Thành công cảm thấy như sự mở rộng nhưng thực sự lại thu hẹp các lựa chọn. Khi các cá nhân và tổ chức phát triển, họ đánh đổi tính có thể lựa chọn để tối ưu hóa, chuyển từ khám phá sang bảo vệ. Bẫy Thành công là một trạng thái nơi các thực thể trở nên quá giỏi trong việc khai thác các thế mạnh hiện có đến nỗi họ ngừng khám phá các cơ hội mới. Điều này tạo ra căng thẳng giữa khai thác (cải thiện những gì hoạt động) và khám phá (thử nghiệm những gì có thể hoạt động tiếp theo).

Các nghiên cứu trường hợp bao gồm: một kỹ sư cấp cao ngừng xây dựng công việc thực hành do thăng tiến sự nghiệp; Kodak thất bại trong việc đón chụp nhiếp ảnh kỹ thuật số mặc dù phát minh ra nó; và Radiohead cố tình tái tạo lại sau “OK Computer”. Các giải pháp bao gồm: thể chế hóa sự tò mò trong các tổ chức; duy trì nhiều bản sắc và tư duy người mới bắt đầu; đánh giá tốc độ học tập cao hơn sự ổn định hiệu suất; và thực hành “quản lý” - nắm giữ thành công một cách nhẹ nhàng và tối ưu hóa cho sự đổi mới.

Điểm chính:

Thành công thu hẹp lựa chọn thay vì mở rộng chúng
Bẫy thành công: quá giỏi khai thác hiện có, ngừng khám phá cơ hội mới
Căng thẳng giữa khai thác (cải thiện hiện tại) và khám phá (thử nghiệm tương lai)
Các giải pháp: thể chế hóa tò mò, duy trì tư duy người mới bắt đầu
Đánh giá tốc độ học tập hơn sự ổn định hiệu suất
“Tự do, không phải thành tựu, là thước đo thành công thực sự”

Writing a good CLAUDE.md

Bài viết giải thích rằng các tệp CLAUDE.md rất quan trọng để đưa Claude vào làm quen với cơ sở mã của bạn vì các LLM không có trạng thái và không biết gì về dự án của bạn khi bắt đầu phiên. Tệp nên bao gồm CÁI GÌ (ngăn xếp công nghệ, cấu trúc), TẠI SAO (mục đích), và LÀM THẾ NÀO (phương pháp làm việc) của dự án.

Các khuyến nghị chính bao gồm: ít hơn là nhiều hơn - giữ hướng dẫn tối thiểu vì các LLM có thể tuân theo khoảng 150-200 hướng dẫn một cách nhất quán, với các mô hình nhỏ hơn cho thấy sự suy giảm hiệu suất theo cấp số nhân; giữ nó súc tích - nhắm mục tiêu dưới 300 dòng, lý tưởng là dưới 60 dòng như cách tiếp cận của HumanLayer; tính phổ quát - chỉ bao gồm các hướng dẫn liên quan đến tất cả các nhiệm vụ để ngăn Claude bỏ qua nội dung; tiết lộ tiến bộ - lưu trữ các hướng dẫn cụ thể của nhiệm vụ trong các tệp riêng biệt và tham chiếu chúng thay vì bao gồm mọi thứ trong CLAUDE.md; tránh sử dụng Claude làm công cụ lint - sử dụng các công cụ lint truyền thống thay vì thực thi kiểu mã dựa trên LLM tốn kém; và tạo thủ công - không tự động tạo CLAUDE.md vì nó là “điểm đòn bẩy cao nhất của bộ điều khiển”.

Bài viết lưu ý rằng Claude thường bỏ qua CLAUDE.md khi cho rằng nội dung không liên quan, được củng cố bởi các lời nhắc hệ thống nói với Claude không phản hồi trừ khi “rất liên quan đến nhiệm vụ của bạn.”

Điểm chính:

CLAUDE.md cần thiết để onboarding Claude vào codebase
LLM có thể tuân theo 150-200 hướng dẫn nhất quán
Giữ dưới 300 dòng, lý tưởng dưới 60 dòng
Chỉ bao gồm hướng dẫn phổ quát cho tất cả các nhiệm vụ
Sử dụng tiết lộ tiến bộ - tham chiếu các tệp riêng biệt
Không tự động tạo - tạo thủ công là điểm đòn bẩy cao nhất

We should all be using dependency cooldowns

Bài viết lập luận rằng các thời gian chờ phụ thuộc là một cách miễn phí, dễ dàng và cực kỳ hiệu quả để giảm thiểu phần lớn các cuộc tấn công chuỗi cung ứng mã nguồn mở. Tác giả phân tích dòng thời gian tấn công điển hình, cho thấy cơ hội của kẻ tấn công thường rất nhỏ - thường chỉ vài giờ đến vài ngày giữa việc phát hành các gói độc hại và việc chúng bị loại bỏ bởi các kho lưu trữ thượng nguồn.

Các cuộc tấn công chuỗi cung cấp hầu hết tuân theo một mô hình tương tự: xâm phạm → phát hành phiên bản độc hại → người dùng tự động cập nhật → nhà cung cấp phát hiện → thượng nguồn loại bỏ. Các cửa sổ tấn công thường dưới một tuần (8/10 cuộc tấn công được phân tích là <7 ngày). Cuộc tấn công xz-utils là một trường hợp ngoại lệ đáng kể với khoảng 5 tuần.

Các thời gian chờ trì hoãn cập nhật phụ thuộc theo một khoảng thời gian nhất định, cho phép các nhà cung cấp bảo mật xác định các mối đe dọa trước khi người dùng áp dụng chúng. Đơn giản để thực hiện với cấu hình như cooldown: default-days: 7. Lợi ích bao gồm: hiệu quả thực nghiệm chống lại các cuộc tấn công có tầm nhìn cao; miễn phí để thực hiện với các công cụ như Dependabot, Renovate; khuyến khích hành vi tích cực từ các nhà cung cấp bảo mật; và có thể ngăn chặn 80-90% sự tiếp xúc với nỗ lực tối thiểu.

Điểm chính:

Phụ thuộc cooldown miễn phí, dễ dàng và hiệu quả chống tấn công chuỗi cung ứng
Cửa sổ tấn công thường dưới 7 ngày cho hầu hết các cuộc tấn công
Đơn giản thực hiện: chỉ cần cấu hình cooldown days
Miễn phí với Dependabot, Renovate và các công cụ tương tự
Có thể ngăn chặn 80-90% sự tiếp xúc với nỗ lực tối thiểu

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

Newsletter #5

Tue, 04 Mar 2025 00:00:00 +0700

Chào các bạn, cuối tuần rồi MiTi hơi lười nên không lên bài. Mời các bạn thưởng thức Newsletter #5 nhé!

5 Advanced Java Reflection Techniques for Dynamic Programming

Bài viết “5 Advanced Java Reflection Techniques for Dynamic Programming” của Aarav Joshi đi sâu vào sức mạnh của Java Reflection API, cho phép developer kiểm tra và thao tác cấu trúc của classes và objects trong runtime. Bài viết trình bày 5 kỹ thuật nâng cao: truy cập private members (cẩn trọng); tạo dynamic instances của classes sử dụng tên classes được xác định ở runtime; sử dụng custom annotations để thêm metadata và xử lý nó trong runtime (ví dụ: logging); tạo dynamic proxies để triển khai cross-cutting concerns như logging hoặc transaction management; và thao tác bytecode ở runtime với các thư viện như ByteBuddy để sửa đổi classes trong runtime. Mặc dù các kỹ thuật này mang lại sự linh hoạt và khả năng mở rộng, bài viết nhấn mạnh tầm quan trọng của việc sử dụng chúng một cách thận trọng do các vấn đề tiềm ẩn về maintainability và performance. Reflection là một công cụ mạnh mẽ cho developer Java để tạo ra các ứng dụng dynamic và thích ứng.

Mistakes You Apparently Just Have to Make Yourself

Bài viết liệt kê những sai lầm mà dường như ai cũng phải tự mình trải qua, bất chấp những lời khuyên. Đó là những “kiến thức không thể chuyển giao,” những điều bạn phải tự “chạm vào bếp nóng” mới tin.

Tác giả đưa ra các ví dụ như: viết lại code từ đầu vì nó quá tệ; nghĩ rằng thêm độ phức tạp vào sẽ giúp phần mềm dễ quản lý hơn; sử dụng công nghệ mới nhất cho một vấn đề chưa từng thấy; tin rằng thêm network hops sẽ làm hệ thống nhanh hơn; nhầm lẫn giữa việc xây dựng hệ thống và dự án mã nguồn mở; viết wrapper cho command line tool; đánh giá thấp sự quan trọng của các khía cạnh khác ngoài lập trình; chỉ tập trung vào functional tests; triển khai code bằng version control tool; nhầm lẫn giữa decoupling logic và separation vật lý; tin rằng quan liêu có thể giải quyết mọi vấn đề hoặc không giải quyết được gì; và gộp code của hai team chỉ vì họ dùng cùng một danh từ.

Tác giả kết thúc bằng một lời quảng cáo hài hước cho startup Skyliner, như một chiếc “áo trói” để giúp bạn tránh lặp lại những sai lầm này.

Service Reliability Mathematics

Bài viết “Service Reliability” làm rõ rằng việc đơn giản hóa độ tin cậy dịch vụ thành tỷ lệ phần trăm duy nhất bỏ qua nhiều sắc thái quan trọng. Tác giả Matt Rickard nhấn mạnh rằng không phải tất cả thời gian ngừng hoạt động đều như nhau, và tác động của nó thay đổi theo thời gian và bối cảnh kinh doanh. Mỗi “nine” (9) bổ sung trong độ tin cậy đòi hỏi nỗ lực kỹ thuật và độ phức tạp hoạt động tăng lên theo cấp số nhân, thường đòi hỏi các thay đổi kiến trúc cơ bản.

Bài viết chỉ ra những giả định ẩn sau các con số độ tin cậy, chẳng hạn như phân phối đồng đều các lỗi theo thời gian và bỏ qua các tình huống suy giảm một phần. Nó cũng nhấn mạnh các trade-off kỹ thuật liên quan đến việc theo đuổi độ tin cậy cao hơn, chẳng hạn như tốc độ phát triển so với sự ổn định và chi phí so với dự phòng.

Bài viết kết thúc bằng cách kêu gọi các kỹ sư xem xét tác động kinh doanh thực tế của các loại lỗi khác nhau và tập trung vào việc cung cấp giá trị nhất quán cho người dùng đồng thời duy trì các hoạt động kỹ thuật bền vững, thay vì mù quáng theo đuổi các con số độ tin cậy tùy ý. Các phương pháp tiếp cận hiện đại đang chuyển sang các số liệu sắc thái hơn như error budget và SLO (Service Level Objectives) dựa trên trải nghiệm người dùng.

How to write a good design document

Bài viết “How to Design Document” đưa ra lời khuyên hữu ích về cách viết tài liệu thiết kế hiệu quả. Tài liệu thiết kế, theo tác giả, là một báo cáo kỹ thuật phác thảo chiến lược triển khai của một hệ thống trong bối cảnh trade-offs và constraints. Mục tiêu chính là thuyết phục người đọc (và quan trọng nhất là chính tác giả) rằng thiết kế này là tối ưu trong tình hình hiện tại.

Tác giả so sánh việc viết tài liệu thiết kế với việc viết một chứng minh toán học. Để đạt được hiệu quả cao nhất, cần tuân thủ tổ chức tốt, tương tự như tổ chức code. Người viết nên tránh tạo ra “spaghetti design docs” bằng cách đảm bảo mọi câu văn đều liên kết và dễ hiểu. Mục tiêu là không gây bất ngờ cho người đọc, giúp họ cảm thấy giải pháp rõ ràng ngay cả khi nó đòi hỏi nhiều suy nghĩ phức tạp.

Bài viết cũng nhấn mạnh tầm quan trọng của việc nắm bắt được tâm lý của người đọc và dự đoán những phản đối có thể xảy ra. Hơn nữa, cần chỉnh sửa để loại bỏ mọi từ ngữ thừa thãi, vì sự chú ý của người đọc là một nguồn tài nguyên hạn chế. Tác giả khuyến khích việc thực hành bằng cách đánh giá các tài liệu khác và chắt lọc ý tưởng thành các tweet ngắn gọn.

Cuối cùng, bài viết gợi ý tổ chức tài liệu thành các bullet point có thể tóm tắt trong một câu duy nhất và sử dụng footnote cho các chi tiết phức tạp để không làm gián đoạn mạch chính của tài liệu.

Picking your battles when you are hyper-rational

Wes Kao chia sẻ về xu hướng phổ biến của những người có tư duy logic cao (hyper-rational operators): tập trung vào việc “đúng về mặt kỹ thuật” mà bỏ qua hiệu quả thực tế. Bài viết khuyến khích bạn nên suy nghĩ về bức tranh lớn hơn thay vì cố gắng sửa những lỗi nhỏ nhặt hoặc giải thích quá nhiều chi tiết không cần thiết.

Wes đưa ra hai ví dụ cụ thể: một về việc làm rõ các vấn đề về múi giờ với recruiter, và một về việc giải thích lý do nhầm lẫn với hệ thống thanh toán cho bộ phận tài chính. Trong cả hai trường hợp, Wes gần như đã gửi những email dài dòng, giải thích rõ ràng sự nhầm lẫn, nhưng sau đó nhận ra rằng việc này không mang lại giá trị thực tế.

Thay vào đó, Wes đã chọn những phản hồi ngắn gọn, tập trung vào việc giải quyết vấn đề trước mắt. Bài viết đặt ra câu hỏi: Liệu lời giải thích này có giúp chúng ta tiến gần hơn đến mục tiêu không? Liệu bối cảnh này có giúp ích cho người khác hay chỉ chứng minh rằng tôi đúng về một điều không quan trọng? Tôi đang phục vụ cuộc trò chuyện, hay cái tôi của mình?

Bài viết kết luận rằng, mặc dù có những lúc cần làm rõ sự nhầm lẫn, nhưng đối với những vấn đề nhỏ và không quan trọng, tốt hơn hết là nên bỏ qua và tập trung vào mục tiêu chính.

Measuring Programmer Influence, Kinda Sorta

Craig Tataryn từ Tidy First thảo luận về cách sử dụng dữ liệu để đánh giá đóng góp của lập trình viên trong một team lớn, dù ông khẳng định không có câu trả lời đáng tin cậy và rõ ràng. Dữ liệu chỉ có thể cung cấp gợi ý về các loại tác động nhất định từ những hành vi cụ thể. Ông cảnh báo rằng việc sử dụng dữ liệu này để xếp hạng, sa thải, thăng chức hoặc thưởng sẽ làm mất đi tính tin cậy của nó ngay lập tức.

Phân tích dựa trên dữ liệu từ dự án React cho thấy việc tạo file và thay đổi file tuân theo phân phối Pareto, tức là một số ít lập trình viên tạo ra phần lớn các file và những file này cũng được thay đổi nhiều nhất. Để xác định những người có ảnh hưởng đáng kể, tác giả kết hợp cả số lượng file được tạo và số lần các file đó được người khác thay đổi. Những người tạo nhiều file mà những file đó được chỉnh sửa nhiều sẽ được coi là có ảnh hưởng lớn hơn.

Ông đưa ra một số cách sử dụng tốt dữ liệu này, như xác định vị trí của bạn so với đồng nghiệp, tìm người để mentor, hoặc xác định những người có ít quyền lực hơn so với tác động thực tế của họ. Tuy nhiên, ông cũng cảnh báo về những cách sử dụng xấu, như dùng dữ liệu để thưởng, đặt hạn ngạch, thăng chức hoặc sa thải. Ông nhấn mạnh rằng nhiều đóng góp quan trọng không thể được ghi lại bằng số liệu và việc quá tập trung vào số liệu có thể dẫn đến những hành vi không mong muốn.

Tóm lại, bài viết khuyến khích sử dụng dữ liệu một cách cẩn thận và luôn ghi nhớ mục tiêu thực sự là tạo ra tác động tích cực, thay vì chỉ tập trung vào số liệu.

Building personal software with Claude

Trong bài viết này, tác giả chia sẻ trải nghiệm sử dụng Claude để chuyển một phần của Emacs package sang Rust, giúp giảm thời gian thực thi từ 90 giây xuống còn 15ms. Điều đáng nói là Claude đã thực hiện gần như toàn bộ dự án dưới sự giám sát của tác giả mà không cần anh phải viết nhiều code.

Ban đầu, tác giả chỉ kỳ vọng Claude sẽ là một công cụ hỗ trợ nhỏ, tương tự như một công cụ tìm kiếm tài liệu tốt hơn và Stack Overflow. Tuy nhiên, Claude đã vượt xa những kỳ vọng đó. Tác giả đã tải file obsidian.el lên và yêu cầu Claude viết một chương trình Rust để tăng tốc hàm obsidian-update. Claude đã đọc khoảng 1000 dòng Emacs Lisp, xác định 200 dòng liên quan, thiết kế định dạng JSON và chuyển logic sang khoảng 150 dòng Rust. Mã này thậm chí còn biên dịch và chạy ngay lần đầu tiên.

Tác giả cũng yêu cầu Claude viết code Emacs để sử dụng chương trình Rust, sử dụng tính năng “advice” để vá obsidian.el. Kết quả cũng rất ấn tượng, chỉ có một lỗi nhỏ được Claude sửa nhanh chóng. Toàn bộ dự án chỉ mất một buổi chiều.

Tác giả nhấn mạnh rằng LLM đang cải thiện với tốc độ chóng mặt và việc sử dụng chúng giúp giảm chi phí code. Tuy nhiên, sự hiểu biết về code, kiến trúc tốt và thiết kế vẫn rất quan trọng. Ông cũng gợi ý rằng có thể sẽ trở nên quan trọng hơn bao giờ hết khi viết code dễ xóa để có thể yêu cầu LLM tạo lại từ đầu khi cần thiết.

Tóm lại, bài viết cho thấy tiềm năng của LLM trong việc giúp các nhà phát triển xây dựng phần mềm cá nhân một cách nhanh chóng và hiệu quả, đồng thời giải phóng họ khỏi những công việc nhàm chán như xử lý các hệ thống xác thực phức tạp và cập nhật các framework mới nhất.

Bonus: Vài ảnh hay ho đến từ ByteByteGo

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

Newsletter #4

Thu, 27 Feb 2025 00:00:00 +0700

Chào các bạn, tuần rồi mình có tìm thấy kha khá bài, nhưng cho vào cùng một newsletter thì lại quá dài. Nên hôm nay mình đăng thêm 1 newsletter giữa tuần nữa nhé ^^.

Management Mantras

Bài viết này tập trung vào những nguyên tắc quản lý quan trọng để xây dựng một môi trường làm việc hiệu quả và trách nhiệm. Dưới đây là một số điểm chính:

Đừng “ban ơn” cho ai: Mọi người nên tập trung vào công việc quan trọng nhất của họ và được hỗ trợ bởi những người có trách nhiệm. Việc “giúp đỡ” có thể là dấu hiệu của sự nhầm lẫn, thiếu sót trong quy trình hoặc làm việc không hiệu quả.
Nhân viên không cần lòng thương hại: Các công ty không nên tỏ ra ban phát cho nhân viên. Thay vào đó, hãy coi những gì bạn làm cho nhân viên là phần thưởng xứng đáng hoặc là một phần trách nhiệm của bạn để hỗ trợ đội ngũ.
“Tôi có thể sửa nó”: Đừng đổ lỗi cho người khác khi mọi việc không thành công. Hãy chịu trách nhiệm và tìm cách giải quyết vấn đề. Nếu các dự án bạn tham gia liên tục thất bại, bạn cần xem xét lại năng lực của mình.
Quản lý là công việc hàng ngày: Quản lý hiệu quả đòi hỏi sự nỗ lực liên tục để thúc đẩy mọi người, giải quyết xung đột và đưa ra phản hồi. Đó là sự tích lũy của những hành động nhỏ hàng ngày chứ không phải những quyết định lớn hiếm hoi.

The Ultimate Guide to Programming Languages: Choosing the Right Tool for the Job

Bài viết này cung cấp một cái nhìn tổng quan về một số ngôn ngữ lập trình phổ biến nhất trong năm 2025, giúp người đọc đưa ra quyết định sáng suốt khi lựa chọn ngôn ngữ phù hợp cho dự án của mình.

Điểm chính:

Python: Dễ học, đa năng, phù hợp cho machine learning, khoa học dữ liệu, phát triển web, và tự động hóa.
JavaScript: “Ông vua” của web, không thể thiếu cho phát triển giao diện người dùng, full-stack development (với Node.js) và ứng dụng đa nền tảng (với Electron và React Native).
Java: “Trâu cày” của doanh nghiệp, ổn định, có khả năng mở rộng cao, bảo mật, phù hợp cho các ứng dụng quy mô lớn, phát triển Android và backend.
C++: “Cường quốc hiệu năng”, thích hợp cho hệ thống lập trình, game engine, và các ứng dụng thời gian thực.
Rust: Ngôi sao đang lên, tập trung vào an toàn bộ nhớ và hiệu năng cao, phù hợp cho hệ thống lập trình, WebAssembly và mật mã.
Xu hướng năm 2025:
- Python vẫn là dẫn đầu trong machine learning, nhưng Julia đang nổi lên trong các tác vụ quan trọng về hiệu năng.
- Solidity và Rust là những người chơi chính trong lĩnh vực blockchain.
- Kotlin Multiplatform và Flutter (Dart) đang được ưa chuộng để thống nhất phát triển ứng dụng di động, web và desktop.

Tóm lại: Bài viết nhấn mạnh rằng việc lựa chọn ngôn ngữ lập trình phù hợp phụ thuộc vào yêu cầu của dự án, kinh nghiệm của nhóm và mục tiêu dài hạn. Mặc dù không có ngôn ngữ nào phù hợp với mọi trường hợp, nhưng việc hiểu rõ điểm mạnh và hạn chế của từng ngôn ngữ có thể giúp đưa ra quyết định thông minh hơn.

Discovery Coding

Bài viết giới thiệu “Discovery Coding” (tạm dịch: Lập trình khám phá) như một phương pháp tiếp cận vấn đề bằng cách viết code trước, thay vì cố gắng thiết kế hoặc suy nghĩ trước. Tác giả so sánh phương pháp này với việc “viết khám phá” trong văn học, nơi tác giả khám phá ra câu chuyện trong quá trình viết.

Điểm chính:

Khái niệm “Discovery Coding”: Thay vì bắt đầu với một kế hoạch chi tiết, người lập trình khám phá suy nghĩ về bối cảnh, các mối quan hệ trong hệ thống và viết code để hiểu rõ vấn đề.
Đối lập với “Outlining”: Discovery Coding trái ngược với phương pháp lập trình dựa trên outline, nơi người lập trình lập kế hoạch chi tiết trước khi viết code.
Không phải là Bottom-Up Design: Tác giả nhấn mạnh rằng Discovery Coding không giống với thiết kế từ dưới lên (bottom-up design).
Lợi ích: Ngay cả đối với những người thích lập trình theo outline, Discovery Coding có thể giúp tránh việc áp dụng các giải pháp quen thuộc và buộc họ phải hiểu rõ các ràng buộc của hệ thống.
Công cụ hỗ trợ: Các công cụ hỗ trợ lập trình trực tiếp trong một hệ thống đang chạy (live programming) và trực quan hóa code có thể rất hữu ích cho người lập trình khám phá.
Lời kêu gọi: Tác giả kêu gọi cộng đồng lập trình chấp nhận và tôn trọng sự khác biệt trong cách tư duy của mỗi người, và không nên coi phương pháp tiếp cận kém tổ chức hơn là một phương pháp kém hiệu quả.

Tóm lại: Bài viết giới thiệu một phương pháp tiếp cận lập trình mới, tập trung vào việc khám phá và hiểu vấn đề thông qua quá trình viết code, và khuyến khích sự chấp nhận sự đa dạng trong cách tư duy của các lập trình viên.

Building a best-selling game with a tiny team

Bài viết này tóm tắt một tập của podcast “The Pragmatic Engineer” với khách mời Jonas Tyroller, một trong hai nhà phát triển của trò chơi indie thành công “Thronefall”. Thronefall là một trò chơi chiến lược tối giản kết hợp phòng thủ tháp và xây dựng vương quốc, đã bán được 1 triệu bản trong năm đầu tiên ra mắt.

Điểm chính:

Thành công của Thronefall: Một trò chơi indie được phát triển bởi chỉ hai người đã bán được 1 triệu bản, chứng tỏ tiềm năng của thị trường game indie.
Kỹ năng đa dạng: Để thành công trong vai trò nhà phát triển game indie, cần có nhiều kỹ năng khác nhau, bao gồm thiết kế, phát triển, sáng tác nhạc, marketing và xây dựng cộng đồng.
Không cần tuân thủ nghiêm ngặt các best practices: Các best practices trong kỹ thuật phần mềm như code review và unit test không phải lúc nào cũng cần thiết cho các game indie nhỏ.
Xây dựng nhiều game: Để trở nên giỏi trong việc xây dựng game, cần xây dựng nhiều game khác nhau, từ đơn giản đến phức tạp.
Công cụ hỗ trợ: Các công cụ như Unity giúp việc xây dựng game trở nên dễ dàng hơn bao giờ hết.
Pathfinding: Một trong những thách thức lớn nhất trong quá trình phát triển Thronefall là tìm đường đi (pathfinding) cho các đơn vị trong game.
ChatGPT: ChatGPT có thể được sử dụng để tạo code khung, dịch code và trả lời các câu hỏi về các chủ đề không quen thuộc.
Tìm sự cân bằng: Để thành công, game indie cần tìm được sự cân bằng giữa sở thích cá nhân và tính thị trường.

Tóm lại: Bài viết cung cấp cái nhìn sâu sắc về quá trình phát triển game indie, nhấn mạnh tầm quan trọng của sự đa năng, khả năng thích ứng và sự hiểu biết về thị trường. Nó cũng cho thấy rằng các công cụ và kỹ thuật mới có thể giúp các nhà phát triển game indie tạo ra các sản phẩm thành công.

Serving a billion web requests with boring code

Bài viết chia sẻ kinh nghiệm xây dựng hệ thống API phục vụ hàng triệu người dùng mỗi ngày cho trang web so sánh kế hoạch Medicare của chính phủ Mỹ. Tác giả nhấn mạnh tầm quan trọng của việc sử dụng các công nghệ “nhàm chán” (đã được chứng minh và đáng tin cậy) và tập trung vào sự đơn giản, rõ ràng trong thiết kế và code.

Điểm chính:

Ưu tiên sự “nhàm chán”: Tác giả coi việc lựa chọn công nghệ “nhàm chán” (boring technology) là kim chỉ nam. Các công nghệ được chọn bao gồm:
Postgres: Nền tảng cơ sở dữ liệu đáng tin cậy.
Golang: Ngôn ngữ lập trình hiệu quả, đơn giản và dễ học.
React: Framework frontend phổ biến và được biết đến rộng rãi.
Kiến trúc module: Backend được chia thành ba module lớn (druginfo, planinfo, beneinfo), mỗi module có cơ sở dữ liệu riêng và giao tiếp qua gRPC.
gRPC: Mặc dù có một số khó khăn với tooling, gRPC giúp định nghĩa interface bằng code và tạo các công cụ, interface thay đổi đồng bộ. grpc-gateway cho phép phục vụ các yêu cầu web.
Tính tương thích ngược: Tuân thủ nghiêm ngặt yêu cầu tương thích ngược, chỉ thêm và không xóa các trường khỏi interface và cơ sở dữ liệu.
Tìm kiếm faceted: Sử dụng Postgres để triển khai tìm kiếm faceted bằng cách xây dựng chuỗi truy vấn SQL dựa trên các điều kiện.
ETL: Quy trình ETL được tự động hóa bằng shell script và cron job, tạo cơ sở dữ liệu mới hàng ngày từ dữ liệu đầu vào.
Logging: Sử dụng request ID để theo dõi các yêu cầu và zerolog để ghi log.
Documentation: Tạo một cuốn sách về cách hệ thống hoạt động bằng Sphinx, được đồng nghiệp đóng góp và sử dụng rộng rãi.

Bài học:

Chất lượng phần mềm có thể được viết dưới các ràng buộc của chính phủ.
Sự đơn giản, rõ ràng và các công nghệ đã được chứng minh có thể giúp xây dựng các hệ thống quy mô lớn.
Đội ngũ làm việc tích cực, sáng tạo và gắn kết là yếu tố quan trọng để thành công.

Java Language Evolution in 2025 - Inside Java Newscast #84

Video này trình bày các hướng phát triển của ngôn ngữ Java trong năm 2025, tập trung vào các cải tiến và tính năng mới được phát triển thông qua Project Amber.

Điểm chính:

Project Amber: Giới thiệu về Project Amber và mục tiêu cải thiện Java.
Flexible Constructor Bodies (Thân hàm tạo linh hoạt): Cho phép thực hiện các lệnh trước khi gọi super() hoặc this() trong hàm tạo.
Simplified Main (Hàm main đơn giản hóa): Giúp viết code Java dễ dàng hơn, đặc biệt là cho các script nhỏ.
Module Imports (Nhập module): Đơn giản hóa việc quản lý và sử dụng các module.
Primitive Patterns (Pattern cho kiểu dữ liệu nguyên thủy): Cải thiện khả năng sử dụng pattern matching với các kiểu dữ liệu nguyên thủy trong instanceof và switch.
Deconstruction (Phân rã cấu trúc): Khám phá tiềm năng của việc phân rã cấu trúc để trích xuất dữ liệu từ các đối tượng.
Withers: Thảo luận về việc sử dụng “withers” để tạo các bản sao của record với các giá trị đã sửa đổi.
String Templates (Chuỗi mẫu): Cập nhật về tiến độ phát triển của tính năng chuỗi mẫu.
Miscellaneous Work (Các công việc khác): Đề cập đến các công việc khác, bao gồm cải tiến serialization.

Tóm lại: Video cung cấp một cái nhìn tổng quan về các cải tiến quan trọng dự kiến sẽ có mặt trong Java năm 2025, giúp các nhà phát triển Java nắm bắt được hướng phát triển của ngôn ngữ và tận dụng các tính năng mới.

Valhalla - Java’s Epic Refactor

Video cung cấp một bản cập nhật chi tiết về Project Valhalla, một dự án quan trọng nhằm hiện đại hóa hệ thống kiểu của Java, mang lại hiệu năng tốt hơn và đơn giản hóa việc lập trình. Brian Goetz giải thích các tính năng mới và mục tiêu của dự án.

Protecting your time from predators in large tech companies

Bài viết đặt ra nhiều câu hỏi thú vị về tương lai của lập trình dưới tác động của AI, nhấn mạnh rằng AI sẽ thay đổi cách chúng ta viết code, nhưng vẫn chưa rõ chính xác như thế nào.

Hands-On Career: The Evolution of a Java Champion

Bài viết khám phá cách AI tạo sinh có thể hỗ trợ các nhà phát triển trong việc phát triển sự nghiệp, đồng thời nhấn mạnh tầm quan trọng của việc sử dụng AI một cách có ý thức, đánh giá kết quả cẩn thận và tiếp tục phát triển các kỹ năng cần thiết để thành công trong kỷ nguyên AI. Nó cũng nêu bật tầm quan trọng của việc hiểu rõ các hạn chế của AI và sử dụng nó như một công cụ hỗ trợ, thay vì một sự thay thế hoàn toàn cho trí tuệ con người.

Token Bucket Rate Limiter (Redis & Java)

Bài viết cung cấp hướng dẫn chi tiết về cách triển khai thuật toán Token Bucket Rate Limiter bằng Redis và Java, bao gồm cả ví dụ code, cách thiết lập môi trường kiểm thử và các test case để đảm bảo tính chính xác.

Bonus?

Huhu, đợt này hỏng có bonus nào hết nha mọi người :<

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