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

Bác xem thử ảnh này thử. Với số âm ta cũng làm tương tự, nhưng có điều sign = 1

tks

Mình có một câu hỏi mong được bạn giải đáp. Do mình dev FE và chưa có nhiều kinh nghiệm về BE và Sec nên có thể câu hỏi sẽ hơi ngớ ngẩn có gì mong bạn thông cảm.

1. Về việc BE cần trả thêm secret value sau khi nhập OTP để dùng cho Payment request tiếp theo có cần thiết không ạ. Tại sao mình k thể dùng chính OTP làm secret key cho Payment request mà lại cần tách làm 2 bước nhập OTP để lấy secrey key sau đó lấy secret key để thực hiện payment request tiếp theo.
2. Ở mục 1.2 bạn có nhắc đến việc chỉnh sửa http response, điều này có thực sự khả thi k ạ, nếu nó khả thi thì làm sao phía FE có thể đối phó được với trò này nhỉ

@jack2k1 full cả 5 apk đây nhé bạn https://drive.google.com/drive/folders/1-jf2V39yH0G-2l9njV0feRjEs00ZtzFE?usp=sharing

Thank bài viết nhé.

có phần 3 chưa bạn

Sao ko có css, js vậy ta

title 1 kiểu content 1 kiểu =)))