@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

@quangpv thank 2 bác

Có công thức để tính toán đó, bạn tham khảo cái này

https://www.geeksforgeeks.org/ieee-standard-754-floating-point-numbers/

Convert online: https://baseconvert.com/ieee-754-floating-point

Tính toán cụ thể, mình từng note lại kiểu này hi vọng bạn hiểu sau khi đọc link trên.

` không dùng chuẩn

0.1 ->

bin: 0.00011001100110011001100110011001100110011001100110011010.....

dec: 0.09999..

chuẩn IEEE754

0.1 ->

binary: 0 01111011 10011001100110011001101 [32bit]

dec: 0.100000001490116119384765625

==================================================================

tính 0.1 theo IEEE 754 - 32 bit,

chọn faction (mantissa) [chỉ chọn 23 hoặc 52 bit], mình chọn 23 bit (52 bit cho IEEE754 - 64bit)

=> sign = 0 [0 cho không dấu, 1 cho có dấu]

=> phần nguyên là 0, không cần đổi sang binary

phần thập phân nhân 2 cho tới khi bằng 1.0

=> 0.0001 10011001100110011001100110011001... [vô hạn]

=> exponent = 2^(-4) // dịch chuyển dấu chấm động sang phải, dịch [trái là + /phải là -] cho đến khi có dạng 1.xyz => 1.10011001100110011001100110011001......

=> biased exponent = 127 + (-4) = 123 [binary: 01111011]

bias cho 32bit = 127, 64bit = 1023

faction: '100110011001100110011001'.length // 24, nhưng bit thứ 24 có số '1' nên bit thứ 23 phải làm tròn lên 1 (Có thuật toán làm tròn mà mình cũng không rõ cơ chế, quá phức tạp, nếu bạn check ở dạng IEEE 754 - 64 bit bạn sẽ thấy khác biệt - chuẩn xác hơn)

=> mantissa: '10011001100110011001101'

<sign> <biased exponent [dạng binary]> <mantissa>

=> 0 01111011 10011001100110011001101

decimal: 0.100000001490116119384765625

nhưng default precision của javascript thể hiện tới 19 kí tự, default precision của PHP chỉ tới 17 kí tự (muốn đúng như js phải sửa trong php.ini)

=> làm tròn dẫn tới decimal thể hiện chỉ là : 0.10000000149011612

=> Ý này cực kì quan trọng, khi bạn tính toán lý thuyết đúng nhưng sẽ bối rối bởi những ngôn ngữ lập trình format khác nhau `

quá hay