Em hỏi tí, chỗ này anh maintain dùng có ổn định không ạ, em thấy spark-operator Google đã close source từ tháng 4 năm nay, em đang thấy có 1 bản cộng đồng đang phát triển, em không rõ nên dùng không https://github.com/kubeflow/spark-operator

🥰🥰♥️♥️♥️♥️👍️

web này chắc hết hạn nên được bên khác mua rồi

• chia thành nhiều thành phần thì sẽ dễ scale hơn bạn ạ, cái này cần xử lý nhiều thì scale cái đó
• lỗi ở đâu xử lý ở đó ko phải update cả kiến trúc
• đúng là tổng cộng ra thì tài nguyên sẽ có tốn hơn, ta nên cân bằng giữa chi phí vận hành + độ hiệu quả của nó. Cá nhân mình thấy thì thực tế với các app từ tầm vừa vừa đến to thì chia ra oke hơn

như bình thường mà tự setup không dùng docker thì toàn chạy full 1 chỗ luôn

Cái này thực tế là ta vẫn phải dùng 1 cái process manager kiểu như supervisor để chạy chúng nó, mỗi cái là 1 process, thì bài này mỗi cái là 1 container 😁

Bài viết hay quá, mà mình có chút thắc mắc đoạn tại sao phải chia ra nhiều service laravel nhỉ? như bình thường mà tự setup không dùng docker thì toàn chạy full 1 chỗ luôn, có phải là chia ra chung 1 source nhưng nhiều service riêng làm chức năng riêng không, vậy thì cũng tốn tài nguyên nhỉ 😂

Bài viết mới nhất của tôi về sự minh bạch. Trong nội dung PSM III, chủ đề này được nhắc đến khá nhiều. https://khiemhuynh.com/hieu-dung-su-minh-bach-trong-agile

Đây là một hướng dẫn tuyệt vời để bảo mật Mosquitto Broker bằng plugin mosquitto-go-auth và MySQL! 🚀 Tôi đã làm theo một phương pháp tương tự trên dịch vụ VPS đáng tin cậy của Vultr, và việc thiết lập diễn ra cực kỳ suôn sẻ. Hạ tầng hiệu suất cao của Vultr đảm bảo rằng cả MQTT Broker và MySQL đều hoạt động mượt mà, ngay cả khi chịu tải nặng.

Đối với những ai muốn tái tạo cách làm này, các hướng dẫn chi tiết của Vultr thực sự rất đáng giá. Họ cung cấp các tài liệu từng bước, chẳng hạn như Cách cài đặt MySQL trên Ubuntu 24.04, rất phù hợp để kết hợp với bài viết này. Việc thiết lập Go và các phụ thuộc khác trên Vultr trở nên đơn giản nhờ vào máy chủ ổn định và có khả năng mở rộng cao.

Nếu bạn đang bắt tay vào các dự án IoT hoặc MQTT, các gói VPS giá cả phải chăng của Vultrlà một điểm khởi đầu tuyệt vời. Tính linh hoạt của họ cho phép bạn mở rộng quy mô theo sự phát triển của dự án, rất lý tưởng cho cả người mới bắt đầu lẫn người dùng nâng cao. Rất khuyến khích bạn thử qua Vultr cho các triển khai như thế này! 👍

vẫn dùng ngon bạn ơi, cơ bản là do cách bạn kia xử lý thôi

e code theo cách kia của a thì thấy có mỗi cái crc là e tính ra khác so với trên trang vietqr họ tính r tạo cho :v

s vẫn k có phần 2 v a

model support mấy ngôn ngữ là những ngôn ngữ nào b

wow vip that su.

@maitrungduc1410 Cảm ơn anh 👍️

Ở laravel 11, họ abstract cho e luôn nên e ko thấy BroadcastServiceProvider, nếu e muốn dùng thì cứ Broadcast::route(), không cần phải use gì cả.

E xem trong bài này a dùng Broadcast::auth ở phần Custom broadcasting đó

bài viết copy ở đâu ra k để ý ngôn từ gây khó khăn cho người đọc

anh ơi, nếu dùng session thì cái Broadcast::route() nó được thêm ở đâu trong laravel 11 vậy ạ, em không tìm thấy BroadcastServiceProvider trong laravel 11

Thiện đã public lại video trên youtube nha anh em https://youtu.be/D7VOGwGNjQw

mình đã làm đến bước cuối cùng mà sao mình không check vào phân vùng đc mong admin chỉ giúp

Các code ví dụ chung chung chưa hiệu quả.

1. Single Responsibility Bỏ các method SendEmail, SendReport, giữ lại AddUser và cho rằng như thế UserManager là có 1 chức năng. Thế còn UpdateUser, DeleteUser, ActiveUser, DeactiveUser, AssignGroup, ResetPassword ...? Có một method không phải là Đơn nhiệm.

Responsibillity là trách nhiệm, không phải chức năng. Mỗi lớp có một trách nhiệm chứ không phải một chức năng. Trách nhiệm của UserManager là quản lý User. UserManager có nhiều hành vi thể hiện trách nhiệm của nó. Với SendEmailToUser, rõ ràng method này không phải của UserManager, cũng không phải của EmailService. Nhưng SendRegistrationEmail là một hành vi của UserManager và SendEmail là một hành vi của EmailService. SendRegistrationEmail của UserManager sử dụng SendEmail của EmailService.

2. Open/Close Sai cơ bản trong việc đặt tên hàm. Tên hàm chỉ hành động, nên nó không phải PaymentProcess mà là ProcessPayment. Việc liệt kê một chuỗi các IF là ngỡ ngẩn vì không ai viết code như thế, kể cả khi viết một hàm dài ngoằng không có abstraction. Ít nhất thì cũng phải đủ cú pháp if else, hoặc người ta dùng switch case. Và dùng if else hay switch case không vi phạm Open/Close. Không viết thế thì viết thế nào đây?

if (paymentMethod == "BTC") {
    var paymentProcessor = new BtcPaymentProcessor();
    
    paymentProcessor.ProcessPayment(paymentInfo);
} else if (paymentMethod == "VISA") {
   ....
} else {
   throw new Exception("Payment method is not supported.");
}

Phần code IPaymentService cũng sai chính tả và đặt tên không hợp lý.

dạ anh ơi, em không giỏi code, thực hiện theo thì thấy khi chạy báo lỗi nhiều lắm ạ