Anh nhận hết các kèo

anh có nhận trainee để thi chứng chỉ này không anh, em xin 1 chân ạ ♥️

theo mình nghĩ là nên tự code, tuy nhiên cậu cậu xác định được mục đích

vậy lên thường kết hợp cả 2 cách, mạng dùng vpn và truy cập vào web có reverse proxy =))😁

Sao cậu không đục vào con core r chuyển tiền luôn cho đẹp chain 🙌

mình có ý kiến là liệu mình có thể hash nhiều hơn 1 lần không, nhằm tăng tính khó cho phía hacker :v kết hợp với việc append chuỗi random vào mật khẩu gốc như bạn đề cập.

Bài viết này đã cứu tôi một bàn thua trông thấy. Đã chạy kịp deadline 11h sáng nay. Cảm ơn anh nhé !

Không phải bắt bẻ gì nhưng mà vscode không phải là IDE nhé 😅

Chính Microsoft cũng nhận nó chỉ là code editor thui 😁

Proof

e phải check terminal của laravel echo server xem nó in ra j nhé e, vì frontend connect tới cái đó chứ ko phải tới laravel

Rainbow table thì liên quan gì đến hash collision nhỉ?

Nên thay object cache bằng Map trong JS sẽ tối ưu hơn.

Hi anh, với 1 người chưa có kinh nghiệm nodeJS em cũng chưa hiểu lắm cách để chạy được full đoạn code trên , mong anh hướng dẫn ạ

Anh ơi xem giúp e vs ạ, ban đầu e có làm dự án laravel mix vuejs thì realtime được nhưng sau đó e tách ra thành 2 dự án thì lại không được, bên backend có lắng nghe, lưu vào quêue và chạy được queue:work, laravel-echo-server start cũng hiển thị event đó nhưng phía frontend thì ko lắng nghe được và ko join vào channel.

file ChatLayout.vuejs

file echo.js (vì báo lỗi Echo.channel nên e theo hướng dẫn trên mạng để tạo file này)

em đang chạy cổng mặc định localhost:8000 của laravel

Dạ cảm ơn anh đã phản hồi ạ, em đã thử hết cả 2 phương án trên thì đều không được. Email thì em đều sử dụng email cá nhân của em và không dùng để spam. Em thử tạo tài khoản mới bằng mail em dùng để làm việc thì đều không được luôn ạ. Mong anh hồi đáp ạ ❤

khá nhỉ sinh viên sắp ra trường mà hơn người ngồi làm việc lặp đi lặp lại chục năm. Nghĩ mà chán cái bản thân mình

MVVM dường như phát triển mạnh mẽ khi các thư viện UI binding nở rộ, cùng với sự tách biệt của FE dev như một team có thể làm việc độc lập.

CQRS không chỉ tách các request Query và Command riêng ra, nó còn là về mặt kiến trúc giải pháp. Thiết kế hệ thống đảm nhận vai trò đọc và vai trò ghi tách biệt. Ví dụ:

Với các phần mềm thông thường, chúng ta thường làm việc đọc và ghi trên cùng 1 database. Việc tách request thành query và command tất nhiên không cải thiện gì về mặt hiệu năng, mà chỉ là về cấu trúc code.

Đối với các hệ thống cần hiệu năng đặc biệt (như là lượng query cao, hoặc lượng command cao, hoặc cả hai), chúng ta sẽ thiết kế giải pháp để việc đọc và ghi không ảnh hưởng đến hiệu năng của nhau. Đối với hệ thống chỉ đọc cao, đơn giản nhất là thêm cache. Các query sẽ được điều thướng sang cache storage. Các command thì sẽ vẫn đọc từ DB. Các command thực chất vẫn thực hiện query nếu cần. Các hệ thống yêu cầu cả đọc, cả ghi thì thường dùng Event Sourcing + CQRS (Hệ thống đọc và ghi lấy dữ liệu từ Event Source và hoạt động tương đối độc lập cả về hosting).

Nói chung, thiết kế để đọc và thiết kế để ghi riêng biệt.

Thực ra bạn vẫn có thể đăng ký 1 concrete class và inject nó vào 1 class khác

Khi dùng DI, chúng ta không biết 1 class được khởi tạo thế nào vì DI đã ẩn giấu nó đi. Thực tế là chúng ta không cần biết việc đó. Trước khi dùng DI, chúng ta thường tự khởi tạo một class hoặc viết một Factory, hoặc Singlton. Chuối khởi tạo này có thể rất phức tạp. Một bộ mã nguồn áp dụng MVC và 3-tiers, từ controller phải khởi tạo service class, từ service class phải khởi tạo DAL class, DAL class lại sử dụng một config utility class. Chuỗi phụ thuộc này làm thủ công sẽ dễ lỗi và khó phát triển. Nếu một class có đến 2 constructor thì mọi việc còn dễ nhầm lẫn hơn nữa.

DI cũng phát huy sức mạnh của Dependency Inversion và Liskov Substitution.

Mình cảm ơn nhé ^^ Follow mình để đọc thêm nhiều bài viết hay nhé

Cho em góp ý anh ơi:)) cái gì không phải tên thuật ngữ hay tên riêng thì anh viết tiếng việt đi anh, nửa anh nửa việt kì quá @@