Lại nữa, có phải đang đến lúc chi phí tính toán trở nên đắt hơn cả chi phí thời gian của lập trình viên không...
Nếu vậy thì có lẽ sắp tới, thời đại của những ngôn ngữ ưu tiên sự tiện lợi cho lập trình viên sẽ qua đi,
và có khi sẽ đến thời đại dùng LLM để viết code bằng những ngôn ngữ như C hay Rust.
https://product.kyobobook.co.kr/detail/S000201558138
Phân tích dữ liệu bằng các thư viện Python
Đây là cuốn sách do Wes McKinney, người tạo ra pandas, viết; cũng rất phù hợp làm sách nhập môn data science. Tôi đã đọc cuốn này khi ấn bản 2 vừa mới ra mắt... giờ tìm lại mới biết là đã có ấn bản 3 rồi.
Nói để tham khảo thì lần trước khi sự cố xảy ra, tất cả những nơi dùng CDN của Cloudflare đều bị sập.
Từ góc nhìn đó thì cần xem là toàn bộ bị sập hay chỉ một phần trong số đó bị sập.
Tôi hiểu tác giả bài gốc, nhưng tôi không rõ vì sao những người khác lại mỉa mai mà không có căn cứ gì.
Đây thật sự là một trong số ít cộng đồng liên quan đến phát triển còn sót lại có cả phép lịch sự.
Trong bài viết đầu tiên của tôi, tôi đã công khai nội dung tổng thể thông qua các cập nhật sau đó.
Một số người dùng (28% tổng lưu lượng) đã bị ảnh hưởng, và họ nói nguyên nhân phát sinh trong lúc cố gắng chặn lỗ hổng React Server Components.
Nếu là lập trình viên, chẳng phải không chỉ đơn thuần viết code mà còn phải có thể phân tích nguyên nhân, xây dựng logic một cách hợp lý, hoặc ít nhất cũng phải đưa ra được căn cứ rõ ràng sao?
Lý do tôi viết bình luận đầu tiên như vậy là vì sau khi kiểm tra sau lúc bài này được đăng, máy chủ tôi quản lý có gắn CDN nhưng không xác nhận được sự cố.
Phía chính thức nói là lỗi API và dashboard, vậy đó là thông tin sai sao?
Vì là lỗi dashboard nên dĩ nhiên có thể xảy ra sự cố Cloudflare, và Downdetector cũng xử lý theo hướng liên quan đến Cloudflare nên có thể báo sự cố (ngay từ đầu lần trước cũng đã sập rồi), chẳng phải là vậy sao?
Thay vì chỉ nói đúng hay sai một cách đơn giản, chẳng phải việc xác định rõ lý do mới quan trọng hơn sao?
Tôi khá đồng ý với phần trong bài viết nói rằng nó hữu ích cho việc xử lý những lỗi vặt.
Thay vì giao cho nó những việc lớn, tôi thấy mình nhận được rất nhiều sự trợ giúp từ AI khi làm những việc tuy phiền nhưng nếu xử lý trước thì về sau sẽ tiện hơn, như thêm các tính năng tiện ích nhỏ, viết script, refactor, v.v.
Ngay cả Orange Cloud không liên quan đến API cũng đã gặp sự cố trên diện rộng
Notion, LinkedIn, v.v.
Chính bạn đã đăng thông tin sai trong phần bình luận.
Bài báo đó có nêu một phần sự thật, nhưng lại dẫn sang liên kết của sự cố trước đây nên là một bài viết dễ khiến người dùng bị nhầm lẫn.
Tôi không phủ nhận mọi thứ, mà chỉ phủ nhận việc nói rằng toàn bộ đều đã sập.
Thực tế nếu nhìn vào DownDetector sau khi đã khôi phục, sẽ thấy Cloudflare vẫn còn ghi lại việc bị sập, nhưng nếu kéo xuống dưới thì Roblox hay Instagram không bị ảnh hưởng, nên tôi chỉ nói như vậy thôi.
Nếu không thể tin tài liệu chính thức của Cloudflare thì cũng đành vậy.
Có thể họ đang nói dối.
Tuy nhiên điều tôi muốn nói là những thứ dùng API của Cloudflare, dù thông qua thư viện hay dùng trực tiếp, mới là những thứ bị ảnh hưởng và gặp sự cố.
Dựa trên tài liệu chính thức.
Đây không phải là bình luận được viết ra để gây gổ.
Chỉ hiển thị là dashboard và API, nhưng Claude, website của Cloudflare, website của tôi và cả DownDetector đều đã không truy cập được.
Bây giờ có vẻ đã khôi phục nên tất cả đều vào lại bình thường rồi.
Thật đáng chán, nhưng dù sao họ cũng đã sửa được nên vẫn là điều may mắn. Có lẽ chỉ là chưa được biết đến thôi, và những trường hợp như thế này còn nhiều hơn nữa.
Giống như mọi công cụ khác, không có gì là vạn năng, nhưng tôi nghĩ Protobuf cũng là một công cụ đủ tốt.
Đặc biệt, đã có lúc tôi phải bắn dữ liệu dung lượng lớn với tần suất cao (20 lần/giây) tới nhiều ngôn ngữ phía khách hàng trong môi trường nhúng, và khi đó tôi đã xử lý gọn gàng bằng nanopb.
Lại nữa, có phải đang đến lúc chi phí tính toán trở nên đắt hơn cả chi phí thời gian của lập trình viên không...
Nếu vậy thì có lẽ sắp tới, thời đại của những ngôn ngữ ưu tiên sự tiện lợi cho lập trình viên sẽ qua đi,
và có khi sẽ đến thời đại dùng LLM để viết code bằng những ngôn ngữ như C hay Rust.
https://product.kyobobook.co.kr/detail/S000201558138
Phân tích dữ liệu bằng các thư viện Python
Đây là cuốn sách do Wes McKinney, người tạo ra pandas, viết; cũng rất phù hợp làm sách nhập môn data science. Tôi đã đọc cuốn này khi ấn bản 2 vừa mới ra mắt... giờ tìm lại mới biết là đã có ấn bản 3 rồi.
Vấn đề kỹ năng quản lý
Nếu lược đồ cũng được định nghĩa bằng DTD và phía parser có cache thì cũng sẽ có hiệu quả là lược đồ chỉ cần được truyền một lần.
Thật thẳng thắn.
Thiệt hại thực ra đến từ việc khai thác thành công lỗ hổng của React Server Components.
Vì thời điểm bài báo khá gần nhau nên tôi nghĩ hoàn toàn có thể bị hiểu nhầm.
https://www.dailysecu.com/news/articleView.html?idxno=203111
Nói để tham khảo thì lần trước khi sự cố xảy ra, tất cả những nơi dùng CDN của Cloudflare đều bị sập.
Từ góc nhìn đó thì cần xem là toàn bộ bị sập hay chỉ một phần trong số đó bị sập.
Tôi hiểu tác giả bài gốc, nhưng tôi không rõ vì sao những người khác lại mỉa mai mà không có căn cứ gì.
Đây thật sự là một trong số ít cộng đồng liên quan đến phát triển còn sót lại có cả phép lịch sự.
Trong bài viết đầu tiên của tôi, tôi đã công khai nội dung tổng thể thông qua các cập nhật sau đó.
Một số người dùng (28% tổng lưu lượng) đã bị ảnh hưởng, và họ nói nguyên nhân phát sinh trong lúc cố gắng chặn lỗ hổng React Server Components.
Nếu là lập trình viên, chẳng phải không chỉ đơn thuần viết code mà còn phải có thể phân tích nguyên nhân, xây dựng logic một cách hợp lý, hoặc ít nhất cũng phải đưa ra được căn cứ rõ ràng sao?
Lý do tôi viết bình luận đầu tiên như vậy là vì sau khi kiểm tra sau lúc bài này được đăng, máy chủ tôi quản lý có gắn CDN nhưng không xác nhận được sự cố.
Phía chính thức nói là lỗi API và dashboard, vậy đó là thông tin sai sao?
Vì là lỗi dashboard nên dĩ nhiên có thể xảy ra sự cố Cloudflare, và Downdetector cũng xử lý theo hướng liên quan đến Cloudflare nên có thể báo sự cố (ngay từ đầu lần trước cũng đã sập rồi), chẳng phải là vậy sao?
Thay vì chỉ nói đúng hay sai một cách đơn giản, chẳng phải việc xác định rõ lý do mới quan trọng hơn sao?
https://blog.cloudflare.com/5-december-2025-outage/
Cloudflare đã đăng trên blog rằng 28% lưu lượng HTTP đã nhận phản hồi 500
Bản thân tôi cũng gặp lỗi Cloudflare 500 trên dịch vụ production
Tôi khá đồng ý với phần trong bài viết nói rằng nó hữu ích cho việc xử lý những lỗi vặt.
Thay vì giao cho nó những việc lớn, tôi thấy mình nhận được rất nhiều sự trợ giúp từ AI khi làm những việc tuy phiền nhưng nếu xử lý trước thì về sau sẽ tiện hơn, như thêm các tính năng tiện ích nhỏ, viết script, refactor, v.v.
https://www.cloudflarestatus.com/incidents/k9ppxftx8bs5
Lại thêm một sự cố khác tiếp tục xảy ra.
Thật tiếc là không có phương án thay thế.
Ngay cả Orange Cloud không liên quan đến API cũng đã gặp sự cố trên diện rộng
Notion, LinkedIn, v.v.
Chính bạn đã đăng thông tin sai trong phần bình luận.
Bài báo đó có nêu một phần sự thật, nhưng lại dẫn sang liên kết của sự cố trước đây nên là một bài viết dễ khiến người dùng bị nhầm lẫn.
Tôi không phủ nhận mọi thứ, mà chỉ phủ nhận việc nói rằng toàn bộ đều đã sập.
Thực tế nếu nhìn vào DownDetector sau khi đã khôi phục, sẽ thấy Cloudflare vẫn còn ghi lại việc bị sập, nhưng nếu kéo xuống dưới thì Roblox hay Instagram không bị ảnh hưởng, nên tôi chỉ nói như vậy thôi.
Nếu không thể tin tài liệu chính thức của Cloudflare thì cũng đành vậy.
Có thể họ đang nói dối.
Tuy nhiên điều tôi muốn nói là những thứ dùng API của Cloudflare, dù thông qua thư viện hay dùng trực tiếp, mới là những thứ bị ảnh hưởng và gặp sự cố.
Dựa trên tài liệu chính thức.
Đây không phải là bình luận được viết ra để gây gổ.
Chỉ hiển thị là dashboard và API, nhưng Claude, website của Cloudflare, website của tôi và cả DownDetector đều đã không truy cập được.
Bây giờ có vẻ đã khôi phục nên tất cả đều vào lại bình thường rồi.
Hãy kiểm tra tin tức.
https://independent.co.uk/tech/…
Lần này không phải mọi thứ đều sập; có vẻ phần dùng API của Cloudflare và bảng điều khiển Cloudflare đang gặp sự cố.
https://www.cloudflarestatus.com/incidents/lfrm31y6sw9q
Thật đáng chán, nhưng dù sao họ cũng đã sửa được nên vẫn là điều may mắn. Có lẽ chỉ là chưa được biết đến thôi, và những trường hợp như thế này còn nhiều hơn nữa.
Thật sự chạm đúng vào cốt lõi.
Giống như mọi công cụ khác, không có gì là vạn năng, nhưng tôi nghĩ Protobuf cũng là một công cụ đủ tốt.
Đặc biệt, đã có lúc tôi phải bắn dữ liệu dung lượng lớn với tần suất cao (20 lần/giây) tới nhiều ngôn ngữ phía khách hàng trong môi trường nhúng, và khi đó tôi đã xử lý gọn gàng bằng nanopb.
Làm chặt chẽ như vậy thì có phải cuối cùng sẽ quay sang dùng XML không ạ haha
Đó là cà phê do chính cửa hàng của tôi làm ra, nên muốn bán được thì tất nhiên phải nói là ngon chứ.