@ruacondepzaj cảm ơn bạn đã góp ý

Theo mình hiểu thì ở đây sẽ khai triển n! thành các thừa số nguyên tố. Do đó 5>2 nên số lượng số có tách thành thừa số nguyên tố chứa số 5 sẽ ít hơn số 2. Do đó số lượng số 2 trong phân tích nguyên tố sẽ nhiều hơn số lượng số 5.

Cảm ơn bạn 😅

@quangduc123 Đúng ra khi bạn dùng relation thì function của bạn phải là courses(). Bạn có thể lấy courses của user đăng nhập và query bằng cách này nữa

$request->user()->courses()->where('title', '=', 'từ khoá bạn cần tìm')->where('courses.status', '=', 'status')->paginate()->toArray();

Tham khảo: https://laravel.com/docs/10.x/eloquent-relationships#defining-relationships

@dangcq17 cảm ơn bạn. theo bạn thì trong 3 cách mình nên ưu tiên dùng cách nào để truy vấn nhanh hơn và tiện hơn

@quangduc123

Course::whereRelation('user', 'id', Auth::user()->id)->where('title', '=', 'từ khoá bạn cần tìm')->where('courses.status', '=', 'status')->paginate();

bạn tham khảo thử nhé

hoặc

Course::whereHas('user', function (Builder $query) {
    $query->where('id', 'Auth::user()->id');
})->where(...)->where(...)
->paginate()

@dangcq17 có cách nào thông qua hàm course hoặc user để lấy ko ạ

Anh ơi cho em hỏi tiếng anh như nào thì đi PV được ạ. Em đi pv thì có chỗ họ ok có chỗ họ chê tiếng anh của em. Giờ em cũng không biết làm sao để cải thiện

cảm ơn bác 😂

tks

@mrfrank yeah, you're correct. 2 deployments are using the same code and when users want to chat, all their requests are routed to the chat deployment.

Hi Minh, I was recommended your writings by a friend and I can say that they are really amazing to read. I do have a question about the part where you had to have a different deployment to handle chat. Is all the code in this deployment the same as the one handling users, posts, comments? It's just that when users want to chat, all their requests are routed to the chat-deployment?

Cảm ơn bác nha, cười sặc máu luôn )

Cảm ơn bạn rất nhiều

Chào bạn, cảm ơn bạn đã quan tâm đến bài viết, Phương thức asyncio.create_task được dùng để tạo một Task instance và lên lịch để chạy nó một cách độc lập. Còn asyncio.gather được sử dụng để chạy nhiều task cùng một lúc. Về cách sử dụng sẽ tuỳ theo các trường hợp cụ thể, nếu các task của bạn không phụ thuộc lẫn nhau thì bạn nên sử dụng gather để có thể chạy cùng một lúc. Và ngược lại, nếu các task của bạn phụ thuộc lẫn nhau, task sau phải đợi những kết quả các kết quả trước để tiếp tục thực hiện. Về cách sử dụng cụ thể những methods trong module asyncio, mình đang tìm hiểu và sẽ có sớm có những bài viết chi tiết sau, hy vọng có thể giúp bạn.

Thanks bác, cùng theo dõi phần tiếp theo nha 😁

Hi bạn

Câu hỏi 1: Bạn có thể đọc phần 2.2, đó chính là cách bạn đề cập đến và đây cũng là cách mình ưu tiên hơn. Câu trả lời sẽ là: Việc chia các step ra hay gộp chung OTP vào action request là do ông SA định nghĩa ngay từ đầu, cách nào cũng được miễn là thực hiện theo best practice.

Câu hỏi 2: Việc chỉnh sửa HTTP response là khả thi và là dễ. Ngày nay dev đặt rất nhiều logic ở front-end và tiến hành validate users input ở front-end thậm chí còn cẩn thận hơn ở back-end. Một số dev nghĩ rằng như thế là đủ để ngăn chặn người dùng tuỳ tiện nhập input, nhưng nó chỉ đúng ở front-end. FE không cần phải đối phó với nó miễn là back-end làm tốt việc của nó. Việc đặt 1 số validation ở FE bạn cứ hiểu đơn giản là tăng trải nghiệm người dùng cũng được, chứ "đối phó" ở FE cũng gần như chẳng để làm gì !

Có gì đâu em, đơn giản là (bất kể) action nào cần phải có OTP mới thực hiện được, thì nay user thực hiện thoải mái. Vì thiếu sót trong việc verify nonce value của back-end.

Bài viết khá dễ hiểu nhưng theo mình nên có thêm phần thiết lập virtual env và thiếu phần tạo user để đăng nhập khi launch airflow (airflow users create --username <username> --password

--role <role> --email <email>).

Hôm trước mình cũng vọc Gitlab CI. Cũng ngon Nhưng khi dựng Multi-Modul thì Pipeline lại bị oẳng luôn. Mình cũng thêm đoạn Artifacts để để lại paths rồi Bạn có thể suggest mình fix issue này không?

@thaond1205 Mà bạn chưa thấy nói đến Gitlab - Runner