Newsletter #88

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

A Broken Heart

Allen Pike chia sẻ một câu chuyện debug thú vị khi dashboard của ứng dụng web đột nhiên chậm đi 10 lần - từ 1 giây lên 10 giây. Sau khi loại trừ React (vốn bị nghi ngờ đầu tiên), anh phát hiện ra Safari đang dành 94% CPU cho… Layout?

Bằng phương pháp binary search với sự hỗ trợ của Claude, anh tìm ra thủ phạm: một emoji trái tim ❤️ trong nút “Send Feedback”. Hóa ra font Noto Color Emoji của Google - được sử dụng để render emoji nhất quán trên các nền tảng - gây ra bug nghiêm trọng trong Safari, khiến mỗi lần layout mất 1600ms thay vì 2ms bình thường.

Điều thú vị là bug này chỉ ảnh hưởng một số emoji cụ thể (❤️, 🤯) trong khi các emoji khác (🧺, 🫠) vẫn render nhanh bình thường. Giải pháp tạm thời: liệt kê “Apple Color Emoji” trước Noto Color Emoji trong font-family.

Điểm chính:

  • Font Noto Color Emoji sử dụng COLRv1 spec, fallback sang SVG trên Safari
  • Bug nằm trong CoreSVG của Apple, đã được báo cáo cho WebKit team
  • Coding agent giúp tạo minimal repro case nhanh hơn nhiều so với thủ công
  • Câu chuyện thú vị về cách AI vừa là nguyên nhân (gợi ý dùng font này) vừa là giải pháp (giúp debug)

Wrapping Code Comments

Một bài viết ngắn nhưng thú vị từ matklad về việc wrap code và comments. Tác giả nhận ra rằng code và comments nên được wrap ở độ rộng khác nhau: code ở khoảng 100 cột (để vừa 2 editor cạnh nhau), nhưng nội dung comments nên wrap ở 60-70 cột để dễ đọc hơn.

Điều quan trọng là comments nên wrap tương đối so với vị trí bắt đầu của comment, không phải tuyệt đối. Ví dụ: comment ở top-level có thể rộng, nhưng comment lồng sâu trong code nên hẹp hơn nhưng vẫn giữ độ rộng nội dung giống nhau.

Điểm chính:

  • Giới hạn code ở 100 cột, nội dung comments ở 60-70 cột
  • Comments nên wrap tương đối theo vị trí, không tuyệt đối
  • VS Code và Emacs đều không hỗ trợ tốt relative wrapping
  • Soft-wrapping không thể wrap đúng nếu không hiểu ý nghĩa text (ví dụ markdown lists)

How I Use Claude Code

Boris Tane chia sẻ workflow 9 tháng sử dụng Claude Code với nguyên tắc cốt lõi: không bao giờ để Claude viết code cho đến khi đã review và approve plan. Workflow gồm 3 phase:

Phase 1 - Research: Yêu cầu Claude đọc sâu codebase và viết báo cáo vào research.md. Từ khóa quan trọng: “deeply”, “in great details”, “intricacies” - để Claude không chỉ đọc hời hợt.

Phase 2 - Planning: Tạo plan.md chi tiết, sau đó thêm inline notes để sửa, reject approaches, thêm constraints. Chu trình annotation này lặp 1-6 lần với guard “don’t implement yet”.

Phase 3 - Implementation: Khi plan đã sẵn sàng, một prompt duy nhất: “implement it all. mark completed in plan. don’t stop until done.”

Điểm chính:

  • File markdown là shared mutable state giữa human và AI
  • Annotation cycle inject domain knowledge mà Claude không có
  • Single long session tốt hơn split sessions - context được build dần
  • Implementation nên boring - creative work đã xong ở planning phase
  • “I want implementation to be boring” - tất cả decisions đã được validate

Bonus

Images: RabbitMQ vs Kafka vs Pulsar REST vs GraphQL Eventual Consistency in Modern Databases Strong Consistency In Databases PostgreSQL versus MySQL Network Protocols Explained

Videos: Video: What Is Redis Really About? - ByteByteGo

Licensed under CC BY-NC-SA 4.0
Cập nhật lần cuối thg 3 13, 2026 15:42 +07
Made by miti99 with ❤️
Built with Hugo
Theme Stack thiết kế bởi Jimmy