bài viết dễ hiểu

Bài viết rấy hay. Mong anh viết bài sau về "Những bad practice như trên còn khá nhiều nữa, ví dụ như Base Service, @RequestMapping, vẫn dùng HttpServletRequest,... nhưng mình không viết ra đây" và bài về Spring Security. Em cảm ơn anh!

@thangdangblog chuẩn rồi bác ạ. khi thử làm leader mới biết các tướng lĩnh ngày xưa giỏi cỡ nào !

Đọc xong thấy cuốn ghê, bên cạnh đó cũng muốn tìm hiểu về lĩnh vực bảo mật khi đọc bài post của chủ thớt. Thank chủ thớt đã truyền cảm hứng.

Mình có nên tạo global module là schema, để tránh làm việc import MongooseModule có hợp lí hơn k bác nhỉ.

Khó nhất vẫn là cụm: tâm phục khẩu phục

Cảm ơn bạn đã ủng hộ 😆.

https://viblo.asia/p/thao-tac-xu-ly-bit-va-ung-dung-bit-manipulation-3kY4gxl9JAe

Link bài này bị lỗi rồi nhé

vậy là nếu áp dụng cho các dự án lớn là không nên ạ? tại trường em đang dạy php dở mà em thì lại tự học reactjs

Sorry chỗ này mình viết không rõ lắm, ý bạn có phải dòng này không: "Lúc này sẽ thấy các message lần lượt được route đến các consumer khác nhau trong cùng consumer group" Ý mình là các message được route đến các consumer. Ví dụ msg1 route đến consumer1, msg2 route đến consumer3, msg3 route đến consumer2. Không phải là 1 message được route đến tất cả các consumer . Mình sẽ sửa lại chỗ này cho dễ hiểu hơn.

hay quá, lâu rồi mới thấy anh viết bài lại 😁

Dạ cho em hỏi .Đoạn code trong bài viết được lấy từ đâu ạ

Mình nghĩ nên dùng Blue-green cho node-pool hay hơn là dùng ở mức Cluster. Đỡ mất công tạo cluster mới: https://cloud.google.com/kubernetes-engine/docs/concepts/node-pool-upgrade-strategies?&_ga=2.43155045.-1359959648.1678182876&_gac=1.216647140.1699979942.CjwKCAiA0syqBhBxEiwAeNx9N4kalYcaBFee-qf2nG-70b0d_q30ZAL90bBPOUXt5arJoBhjb0gD2RoCImMQAvD_BwE#blue-green-upgrade-strategy

mình thấy ở trên có 1 ý chưa hiểu lắm là: 2 consumer cùng 1 consumer group khi lắng nghe trên 1 topic thì message sẽ route đến từng consumer trong consum group. Nhưng mà ở bài trc mình lại thấy bạn có viết là trên 1 consum group thì chỉ có 1 consumer nhận được mess. Nghe 2 cái này có vẻ mâu thuẫn nhờ bạn giải thích giúp mình đang hiểu sai ở đâu.

bài viết rất hay ạ

@rockman88v thật ra thì không cần cấu hình lại storage class đâu bác, mặc định elastic stack nó sẽ nhận storage class "standard", vấn đề này có thể giải quyết bằng cách tự thêm storageClassname

volumeClaimTemplate:
  accessModes: ["ReadWriteOnce"]
  storageClassName: longpq-nfs-retain #tự thêm
  resources:
    requests:
      storage: 30Gi

hay

Đúng là những cách này tệ thật. Mọi người ai đang làm Frontend code JS thì nên tránh nhé 😁

Theo mình thấy cách tạo null object sẽ giúp kiểm soát được các giá trị mặc định của các trường một cách tốt hơn, cũng đúng như ý của Huy có nói ở trên. Làm như cách của Hoàng không sai, tuy nhiên code sẽ hơi phức tạp nếu như object của mình có nhiều cấp.

VD: obj = [{id: 1, x: {y : {z: 1}} }]

obj.find(o => o.id == 1)?.x?.y?.z ?? 'Unknown'

Dùng class như cách trên cũng ok bạn ơi. Nhưng nếu cần 1 giá trị default khác thì bạn phải tạo 1 class mới tinh và code nhìn sẽ hơi bị lặp một chút. có nhiều cách để xử lý 1 vấn đề, nên tùy từng trường hợp mình sẽ áp dụng hiệu quả các cách ạ