Câu "người viết README là người duy nhất không thể test nó" tóm đúng vấn đề. Danh sách lỗi version drift kiểu README ghi Node 16 trong khi package.json đòi >=20.11 là thứ CI bắt được khá dễ, chỉ cần một job chạy lại các bước setup trong container sạch.
Ý giữ scene identifier ổn định giữa các bản sửa là chi tiết dễ bị bỏ qua. Nếu đổi một câu mà scene bị coi như object mới thì việc so sánh caption với hình minh họa gần như vô nghĩa. Ví dụ notebook bên trái hay bên phải cũng cho thấy rõ thứ cần kiểm tra là quan hệ giữa script và hình, không phải hướng nào đúng.
Tách test extraction và matching thành hai lớp là ý rất thực tế. Mình thích điểm không được biến ô trống thành giá trị đoán chỉ để qua rule completeness, vì một match gọn gàng có thể che mất dòng nguồn bị thiếu. Fixture nhỏ với mỗi dòng test một hành vi (dấu phẩy trong mô tả, số âm) cũng dễ review hơn nhiều.
Ý billing, provisioning, CRM và analytics từng là các hệ thống rời rạc rồi chuyển sang nền tảng API-first là điểm rõ nhất của bài. Với các team bán dịch vụ tích hợp, biết trước một operator đang chạy những công cụ nào giúp câu hỏi đầu tiên cụ thể hơn nhiều. Nói rõ là sản phẩm của bọn mình: StackShortlist làm danh sách một lần các công ty B2B đang dùng một công nghệ bạn chọn (3,500+ technologies), kèm bằng chứng và một người liên hệ có tên, 19 USD cho 100 công ty. Nó không theo dõi thay đổi stack. https://stackshortlist.dev
Điểm bản WebAssembly xử lý file ngay trong trình duyệt thay vì upload lên cloud là lý do chính để thử tool này cho hợp đồng hay form có thông tin nhạy cảm. Gộp cả việc sắp xếp trang, ký và bảo vệ file vào một chỗ cũng đỡ phải chuyển tài liệu qua nhiều dịch vụ như bài nói.
Phần lưu ý về Bitmap rất đáng chú ý: ID 1 tỷ là Redis phải cấp phát khoảng 120MB dù phần lớn bit đều là 0. Với hệ thống có ID không liên tiếp, có thể map ID sang một dãy số liên tiếp trước khi SETBIT, hoặc chuyển sang HyperLogLog nếu chấp nhận sai số khoảng 0.81% như bài nói.
Mình cũng chạy pgvector local suốt giai đoạn beta, đỡ hẳn tiền. Có điều khi chuyển từ Llama 3 8B local sang API thật thì chất lượng câu trả lời RAG khác khá xa, nên prompt tối ưu trên local nhiều khi phải chỉnh lại. Bạn có giữ một bộ câu hỏi test cố định để so sánh hai bên không?
Cảm ơn bạn đã ghi lại rất chi tiết, kiểu "test repo" này dạo gần đây gặp khá nhiều. Mình bổ sung vài thói quen đơn giản cho anh em freelancer: trước khi cài thì đọc package.json xem các script preinstall, postinstall, prepare; chạy npm install --ignore-scripts lần đầu; và nếu phải chạy thử thì làm trong container hoặc VM không có SSH key, ví crypto hay token GitHub. Thêm nữa, khách thật thường không ép chạy repo ngay trước khi bàn scope và hợp đồng, bị hối thúc kiểu đó là nên dừng lại kiểm tra.
Bài viết hay, ví dụ workflow fix bug rất dễ hình dung. Mình nghĩ phần khó nhất khi chuyển sang agentic là cách tính tiền. SaaS truyền thống tính theo seat, còn khi agent làm thay người thì số seat giảm, nên nhiều bên chuyển sang tính theo task hoặc theo kết quả. Nhưng "kết quả" phải đo được và khách phải đồng ý cách đo, không thì tranh cãi hóa đơn liên tục. Thêm một điểm nữa là audit log: mỗi hành động agent làm (tạo ticket, mở PR, gửi Slack) nên ghi lại kèm lý do và cho phép rollback, khách doanh nghiệp gần như luôn hỏi cái này trước khi cho agent quyền ghi. Bạn có định viết tiếp phần pricing không?
Cách dùng Signed URL gọn thật, bỏ được cả cột token lẫn job dọn rác. Mình bổ sung hai điểm hay gặp khi chạy thật. Thứ nhất, một số bộ lọc email doanh nghiệp (Outlook Safe Links, Mimecast...) tự mở link trong mail để quét, nên nếu route verify chỉ cần GET là xác thực luôn thì user có thể được verify mà chưa hề bấm. Mình hay cho GET hiện trang có nút xác nhận, rồi POST mới cập nhật email_verified_at. Thứ hai, nhớ cấu hình TrustProxies khi chạy sau load balancer hoặc Cloudflare, không thì URL bị ký theo http mà user mở bằng https, hasValidSignature sẽ báo sai. Cảm ơn bạn đã chia sẻ.
Lab đi từng bước rất dễ làm theo. Hai góp ý nhỏ: (1) nếu docker compose publish cổng dạng 3000:3000 thì Docker mở trên 0.0.0.0 và tự chèn rule iptables, vượt qua cả ufw; NSG của Azure đang chặn nên lab vẫn an toàn, nhưng khi chuyển sang VPS khác chỉ dùng ufw thì cổng 3000 và 3306 sẽ lộ ra Internet. Đổi thành 127.0.0.1:3000:3000 và bỏ publish cổng MySQL là chắc nhất. (2) Sơ đồ kiến trúc đầu bài ghi PostgreSQL :5432 và Backend :8080, còn todo-list-app thực tế chạy app và mysql, nên sửa lại sơ đồ để người mới đỡ bối rối.
Quy tắc chỉ tính những gì tệ đi so với snapshot trước là chi tiết rất hay, tránh được rất nhiều rollback oan. Một trường hợp nên cân nhắc: với site WooCommerce hoặc site có form đăng ký, khôi phục cả database sẽ xóa luôn đơn hàng hay dữ liệu khách gửi vào trong khoảng giữa lúc sao lưu và lúc rollback. Có thể bật maintenance mode trong suốt bước 3 và 4 để không có ghi mới, hoặc ít nhất ghi nhận max ID của bảng đơn hàng trước khi cập nhật và cảnh báo người dùng nếu có bản ghi mới phát sinh trước khi restore. Thêm nữa, nếu site có cron WP chạy trong lúc cập nhật, nên tạm tắt DISABLE_WP_CRON hoặc cron hệ thống để tránh job chạy trên code đang thay dở.
Bài viết gọn và dễ theo. Mình góp thêm kinh nghiệm thực tế: nên giữ init() thật nhẹ, tránh mở kết nối DB hay gọi mạng trong đó, vì lỗi ở init() không trả về error được mà chỉ có panic, và nó chạy cả khi chạy test nên test sẽ chậm hoặc fail khó hiểu. Những gì cần cấu hình thì mình hay chuyển sang một hàm New/Setup gọi tường minh từ main. Còn import _ "pkg" chỉ để kích hoạt init() thì nên dùng ở main package thôi, đừng rải trong thư viện.
Ý tưởng chạy README trong container sạch rất thực tế. Vài góp ý nhỏ: (1) GitHub tự tắt workflow schedule nếu repo không có hoạt động trong 60 ngày, nên với repo ít commit thì cron hàng tuần có thể im lặng ngừng chạy mà không ai biết; (2) nên chạy thêm một bản với ubuntu:latest bên cạnh bản ghim 24.04, vì người dùng mới thường cài bản mới nhất và lỗi hay xuất hiện ở đó trước; (3) một chuyện ngoài lề: từ đoạn mermaid đầu tiên trở đi, bài đang bị lỗi định dạng, các code block hiển thị thành chữ thường với thụt lề rất sâu, có lẽ do dấu ``` đóng bị thụt vào. Sửa lại sẽ dễ đọc hơn nhiều, nội dung thì rất đáng.
Series rất chắc tay. Mình bổ sung vài điểm hay vấp khi dùng logical replication để nâng cấp version: DDL không được replicate nên phải chạy schema trên subscriber trước và giữ đồng bộ thủ công; sequence cũng không được sync, nên trước khi cutover cần setval lại các sequence bên subscriber, không thì insert đầu tiên sẽ trùng khóa. Bảng không có primary key thì phải đặt REPLICA IDENTITY (ví dụ FULL) mới replicate được UPDATE/DELETE. Cuối cùng nhớ drop subscription và replication slot sau khi xong, slot bỏ quên sẽ giữ WAL làm đầy ổ đĩa bên publisher.
Cảm ơn bạn đã tổng hợp. Mình thêm vài lưu ý thực tế khi viết record SPF: mỗi domain chỉ được có đúng một TXT record bắt đầu bằng v=spf1, có hai record là SPF permerror ngay. Nên kết thúc bằng ~all trong giai đoạn đầu, khi đã chắc chắn liệt kê đủ nguồn gửi thì mới chuyển sang -all. Cơ chế ptr thì RFC 7208 khuyên không dùng nữa. Và nhớ đếm số include, vì mỗi include lồng nhau đều tính vào giới hạn 10 DNS lookup.
Bài viết dễ hiểu. Mình bổ sung một điểm hay bị bỏ qua: SPF có giới hạn 10 lần DNS lookup, domain dùng nhiều dịch vụ gửi (CRM, helpdesk, newsletter) rất dễ vượt quá và bị permerror, lúc đó SPF coi như fail dù record nhìn vẫn đúng. Ngoài ra DMARC cần alignment, tức domain trong From phải khớp với domain của SPF hoặc DKIM, chứ pass SPF bằng domain của nhà cung cấp thì DMARC vẫn fail. Mọi người nên để p=none và đọc báo cáo rua vài tuần trước khi lên quarantine/reject.
Bài tóm tắt gọn, dễ theo cho người mới. Góp vài điểm từ tài liệu của HikariCP: (1) với driver hỗ trợ JDBC4 như MySQL Connector/J thì không nên đặt connectionTestQuery, Hikari sẽ dùng Connection.isValid() nhanh hơn, phần 7.1 có thể gây hiểu nhầm; (2) maxLifetime nên ngắn hơn wait_timeout của MySQL hoặc timeout của load balancer/proxy vài chục giây, nếu không sẽ gặp lỗi connection đã bị đóng phía server; (3) Hikari khuyến nghị để minimumIdle bằng maximumPoolSize (pool cố định) cho tải ổn định. Ngoài ra khi chạy nhiều instance, tổng maximumPoolSize của mọi instance phải nhỏ hơn max_connections của database, đây là lỗi hay gặp khi scale ngang.
Phân tích khá công bằng, nhất là ý sản phẩm mất đi câu trả lời rõ ràng khi cố làm all-in-one. Với những ai đang cân nhắc rời Mailchimp sang Brevo hay MailerLite, có một phần hay bị bỏ quên: nhớ xuất cả danh sách unsubscribed, bounced và cleaned chứ không chỉ contact đang active, rồi nhập vào suppression list của nền tảng mới. Nếu không, chiến dịch đầu tiên sẽ gửi lại cho những địa chỉ đã hỏng hoặc đã từ chối, tỷ lệ bounce và báo spam tăng vọt ngay tuần đầu. Ngoài ra nên cấu hình SPF, DKIM, DMARC cho domain trên nền tảng mới và tăng dần khối lượng gửi trong vài tuần thay vì gửi toàn bộ danh sách ngay.
Cảm ơn bạn đã tổng hợp. Mình thêm vài lưu ý thực tế khi viết record SPF: mỗi domain chỉ được có đúng một TXT record bắt đầu bằng v=spf1, có hai record là SPF permerror ngay. Nên kết thúc bằng ~all trong giai đoạn đầu, khi đã chắc chắn liệt kê đủ nguồn gửi thì mới chuyển sang -all. Cơ chế ptr thì RFC 7208 khuyên không dùng nữa. Và nhớ đếm số include, vì mỗi include lồng nhau đều tính vào giới hạn 10 DNS lookup.
THẢO LUẬN
Câu "người viết README là người duy nhất không thể test nó" tóm đúng vấn đề. Danh sách lỗi version drift kiểu README ghi Node 16 trong khi package.json đòi >=20.11 là thứ CI bắt được khá dễ, chỉ cần một job chạy lại các bước setup trong container sạch.
Ý giữ scene identifier ổn định giữa các bản sửa là chi tiết dễ bị bỏ qua. Nếu đổi một câu mà scene bị coi như object mới thì việc so sánh caption với hình minh họa gần như vô nghĩa. Ví dụ notebook bên trái hay bên phải cũng cho thấy rõ thứ cần kiểm tra là quan hệ giữa script và hình, không phải hướng nào đúng.
Tách test extraction và matching thành hai lớp là ý rất thực tế. Mình thích điểm không được biến ô trống thành giá trị đoán chỉ để qua rule completeness, vì một match gọn gàng có thể che mất dòng nguồn bị thiếu. Fixture nhỏ với mỗi dòng test một hành vi (dấu phẩy trong mô tả, số âm) cũng dễ review hơn nhiều.
Ý billing, provisioning, CRM và analytics từng là các hệ thống rời rạc rồi chuyển sang nền tảng API-first là điểm rõ nhất của bài. Với các team bán dịch vụ tích hợp, biết trước một operator đang chạy những công cụ nào giúp câu hỏi đầu tiên cụ thể hơn nhiều. Nói rõ là sản phẩm của bọn mình: StackShortlist làm danh sách một lần các công ty B2B đang dùng một công nghệ bạn chọn (3,500+ technologies), kèm bằng chứng và một người liên hệ có tên, 19 USD cho 100 công ty. Nó không theo dõi thay đổi stack. https://stackshortlist.dev
Điểm bản WebAssembly xử lý file ngay trong trình duyệt thay vì upload lên cloud là lý do chính để thử tool này cho hợp đồng hay form có thông tin nhạy cảm. Gộp cả việc sắp xếp trang, ký và bảo vệ file vào một chỗ cũng đỡ phải chuyển tài liệu qua nhiều dịch vụ như bài nói.
Phần lưu ý về Bitmap rất đáng chú ý: ID 1 tỷ là Redis phải cấp phát khoảng 120MB dù phần lớn bit đều là 0. Với hệ thống có ID không liên tiếp, có thể map ID sang một dãy số liên tiếp trước khi SETBIT, hoặc chuyển sang HyperLogLog nếu chấp nhận sai số khoảng 0.81% như bài nói.
Mình cũng chạy pgvector local suốt giai đoạn beta, đỡ hẳn tiền. Có điều khi chuyển từ Llama 3 8B local sang API thật thì chất lượng câu trả lời RAG khác khá xa, nên prompt tối ưu trên local nhiều khi phải chỉnh lại. Bạn có giữ một bộ câu hỏi test cố định để so sánh hai bên không?
Cảm ơn bạn đã ghi lại rất chi tiết, kiểu "test repo" này dạo gần đây gặp khá nhiều. Mình bổ sung vài thói quen đơn giản cho anh em freelancer: trước khi cài thì đọc package.json xem các script preinstall, postinstall, prepare; chạy npm install --ignore-scripts lần đầu; và nếu phải chạy thử thì làm trong container hoặc VM không có SSH key, ví crypto hay token GitHub. Thêm nữa, khách thật thường không ép chạy repo ngay trước khi bàn scope và hợp đồng, bị hối thúc kiểu đó là nên dừng lại kiểm tra.
Bài viết hay, ví dụ workflow fix bug rất dễ hình dung. Mình nghĩ phần khó nhất khi chuyển sang agentic là cách tính tiền. SaaS truyền thống tính theo seat, còn khi agent làm thay người thì số seat giảm, nên nhiều bên chuyển sang tính theo task hoặc theo kết quả. Nhưng "kết quả" phải đo được và khách phải đồng ý cách đo, không thì tranh cãi hóa đơn liên tục. Thêm một điểm nữa là audit log: mỗi hành động agent làm (tạo ticket, mở PR, gửi Slack) nên ghi lại kèm lý do và cho phép rollback, khách doanh nghiệp gần như luôn hỏi cái này trước khi cho agent quyền ghi. Bạn có định viết tiếp phần pricing không?
Cách dùng Signed URL gọn thật, bỏ được cả cột token lẫn job dọn rác. Mình bổ sung hai điểm hay gặp khi chạy thật. Thứ nhất, một số bộ lọc email doanh nghiệp (Outlook Safe Links, Mimecast...) tự mở link trong mail để quét, nên nếu route verify chỉ cần GET là xác thực luôn thì user có thể được verify mà chưa hề bấm. Mình hay cho GET hiện trang có nút xác nhận, rồi POST mới cập nhật email_verified_at. Thứ hai, nhớ cấu hình TrustProxies khi chạy sau load balancer hoặc Cloudflare, không thì URL bị ký theo http mà user mở bằng https, hasValidSignature sẽ báo sai. Cảm ơn bạn đã chia sẻ.
Lab đi từng bước rất dễ làm theo. Hai góp ý nhỏ: (1) nếu docker compose publish cổng dạng 3000:3000 thì Docker mở trên 0.0.0.0 và tự chèn rule iptables, vượt qua cả ufw; NSG của Azure đang chặn nên lab vẫn an toàn, nhưng khi chuyển sang VPS khác chỉ dùng ufw thì cổng 3000 và 3306 sẽ lộ ra Internet. Đổi thành 127.0.0.1:3000:3000 và bỏ publish cổng MySQL là chắc nhất. (2) Sơ đồ kiến trúc đầu bài ghi PostgreSQL :5432 và Backend :8080, còn todo-list-app thực tế chạy app và mysql, nên sửa lại sơ đồ để người mới đỡ bối rối.
Quy tắc chỉ tính những gì tệ đi so với snapshot trước là chi tiết rất hay, tránh được rất nhiều rollback oan. Một trường hợp nên cân nhắc: với site WooCommerce hoặc site có form đăng ký, khôi phục cả database sẽ xóa luôn đơn hàng hay dữ liệu khách gửi vào trong khoảng giữa lúc sao lưu và lúc rollback. Có thể bật maintenance mode trong suốt bước 3 và 4 để không có ghi mới, hoặc ít nhất ghi nhận max ID của bảng đơn hàng trước khi cập nhật và cảnh báo người dùng nếu có bản ghi mới phát sinh trước khi restore. Thêm nữa, nếu site có cron WP chạy trong lúc cập nhật, nên tạm tắt DISABLE_WP_CRON hoặc cron hệ thống để tránh job chạy trên code đang thay dở.
Bài viết gọn và dễ theo. Mình góp thêm kinh nghiệm thực tế: nên giữ init() thật nhẹ, tránh mở kết nối DB hay gọi mạng trong đó, vì lỗi ở init() không trả về error được mà chỉ có panic, và nó chạy cả khi chạy test nên test sẽ chậm hoặc fail khó hiểu. Những gì cần cấu hình thì mình hay chuyển sang một hàm New/Setup gọi tường minh từ main. Còn import _ "pkg" chỉ để kích hoạt init() thì nên dùng ở main package thôi, đừng rải trong thư viện.
Ý tưởng chạy README trong container sạch rất thực tế. Vài góp ý nhỏ: (1) GitHub tự tắt workflow schedule nếu repo không có hoạt động trong 60 ngày, nên với repo ít commit thì cron hàng tuần có thể im lặng ngừng chạy mà không ai biết; (2) nên chạy thêm một bản với ubuntu:latest bên cạnh bản ghim 24.04, vì người dùng mới thường cài bản mới nhất và lỗi hay xuất hiện ở đó trước; (3) một chuyện ngoài lề: từ đoạn mermaid đầu tiên trở đi, bài đang bị lỗi định dạng, các code block hiển thị thành chữ thường với thụt lề rất sâu, có lẽ do dấu ``` đóng bị thụt vào. Sửa lại sẽ dễ đọc hơn nhiều, nội dung thì rất đáng.
Series rất chắc tay. Mình bổ sung vài điểm hay vấp khi dùng logical replication để nâng cấp version: DDL không được replicate nên phải chạy schema trên subscriber trước và giữ đồng bộ thủ công; sequence cũng không được sync, nên trước khi cutover cần setval lại các sequence bên subscriber, không thì insert đầu tiên sẽ trùng khóa. Bảng không có primary key thì phải đặt REPLICA IDENTITY (ví dụ FULL) mới replicate được UPDATE/DELETE. Cuối cùng nhớ drop subscription và replication slot sau khi xong, slot bỏ quên sẽ giữ WAL làm đầy ổ đĩa bên publisher.
Cảm ơn bạn đã tổng hợp. Mình thêm vài lưu ý thực tế khi viết record SPF: mỗi domain chỉ được có đúng một TXT record bắt đầu bằng v=spf1, có hai record là SPF permerror ngay. Nên kết thúc bằng ~all trong giai đoạn đầu, khi đã chắc chắn liệt kê đủ nguồn gửi thì mới chuyển sang -all. Cơ chế ptr thì RFC 7208 khuyên không dùng nữa. Và nhớ đếm số include, vì mỗi include lồng nhau đều tính vào giới hạn 10 DNS lookup.
Bài viết dễ hiểu. Mình bổ sung một điểm hay bị bỏ qua: SPF có giới hạn 10 lần DNS lookup, domain dùng nhiều dịch vụ gửi (CRM, helpdesk, newsletter) rất dễ vượt quá và bị permerror, lúc đó SPF coi như fail dù record nhìn vẫn đúng. Ngoài ra DMARC cần alignment, tức domain trong From phải khớp với domain của SPF hoặc DKIM, chứ pass SPF bằng domain của nhà cung cấp thì DMARC vẫn fail. Mọi người nên để p=none và đọc báo cáo rua vài tuần trước khi lên quarantine/reject.
Bài tóm tắt gọn, dễ theo cho người mới. Góp vài điểm từ tài liệu của HikariCP: (1) với driver hỗ trợ JDBC4 như MySQL Connector/J thì không nên đặt connectionTestQuery, Hikari sẽ dùng Connection.isValid() nhanh hơn, phần 7.1 có thể gây hiểu nhầm; (2) maxLifetime nên ngắn hơn wait_timeout của MySQL hoặc timeout của load balancer/proxy vài chục giây, nếu không sẽ gặp lỗi connection đã bị đóng phía server; (3) Hikari khuyến nghị để minimumIdle bằng maximumPoolSize (pool cố định) cho tải ổn định. Ngoài ra khi chạy nhiều instance, tổng maximumPoolSize của mọi instance phải nhỏ hơn max_connections của database, đây là lỗi hay gặp khi scale ngang.
Phân tích khá công bằng, nhất là ý sản phẩm mất đi câu trả lời rõ ràng khi cố làm all-in-one. Với những ai đang cân nhắc rời Mailchimp sang Brevo hay MailerLite, có một phần hay bị bỏ quên: nhớ xuất cả danh sách unsubscribed, bounced và cleaned chứ không chỉ contact đang active, rồi nhập vào suppression list của nền tảng mới. Nếu không, chiến dịch đầu tiên sẽ gửi lại cho những địa chỉ đã hỏng hoặc đã từ chối, tỷ lệ bounce và báo spam tăng vọt ngay tuần đầu. Ngoài ra nên cấu hình SPF, DKIM, DMARC cho domain trên nền tảng mới và tăng dần khối lượng gửi trong vài tuần thay vì gửi toàn bộ danh sách ngay.
Cảm ơn bạn đã tổng hợp. Mình thêm vài lưu ý thực tế khi viết record SPF: mỗi domain chỉ được có đúng một TXT record bắt đầu bằng v=spf1, có hai record là SPF permerror ngay. Nên kết thúc bằng ~all trong giai đoạn đầu, khi đã chắc chắn liệt kê đủ nguồn gửi thì mới chuyển sang -all. Cơ chế ptr thì RFC 7208 khuyên không dùng nữa. Và nhớ đếm số include, vì mỗi include lồng nhau đều tính vào giới hạn 10 DNS lookup.