Harry học debug

13/07/2025

Hãy tưởng tượng trái tim của cô gái là một backend service với một API bảo vệ nghiêm ngặt, và mỗi chàng trai là một client (user) gửi request để "được yêu". Dưới đây là một mô hình ví von hài hước nhưng khá hợp lý:

🩷 Backend System: Trái tim cô gái

1. Authentication Layer (Lớp xác thực)
• Trái tim cô gái không mở public API đâu!
• Một số user sẽ bị 403 Forbidden vì không đủ tiêu chuẩn (xấu trai, toxic, v.v.).
• Một số thì chỉ được trả về 401 Unauthorized vì chưa có token "niềm tin", chưa xác thực được bằng hành động thực tế.
• Một số đã từng "authenticated" rồi mà vẫn bị block → đó là do đã từng làm tổn thương cô ấy → Token revoked.

2. Rate Limiter
• Gửi request tán tỉnh dồn dập sẽ bị rate limit → 429 Too Many Requests.
• Cô ấy có thể dùng hệ thống kiểu Cloudflare WAF để chặn spam (những anh chàng nhắn 7749 tin/giờ).

3. Firewall & ACL Rules
• Có một số NACLs nội tâm đặt ra từ trải nghiệm quá khứ:
• Chặn IP vùng "bad boy"
• Chặn protocol tán tỉnh kiểu rẻ tiền như "em ăn cơm chưa?"
• Chặn các user từng có tiền sử DDoS cảm xúc (khiến cô ấy mệt mỏi vì drama).

4. Caching layer
Nếu bạn chỉ dùng lời nói ngọt ngào cũ lặp đi lặp lại, backend sẽ cache response là “Em nghe rồi!”, không trả lời nữa (kiểu như stale data).

5. Load balancer
• Nếu có quá nhiều người theo đuổi, trái tim cô ấy có thể cần load balancer để phân phối cảm xúc hợp lý.
• Nhưng thực tế, có thể backend bị overload → phản ứng lạnh lùng, delay response lâu, thậm chí timeout.

6. Business Logic Layer
Đây là nơi xử lý các tín hiệu:
• Ai kiên nhẫn, hiểu cảm xúc, có data consistency → tăng score.
• Ai hay lỗi logic (ghen tuông, thiếu hiểu biết) → bị rollback.
• State machine tình cảm có nhiều transition: từ crush → tìm hiểu → rung động → yêu.

7. Database: Tâm trí + Ký ức
• Log lại tất cả các request.
• Nếu request đủ đặc biệt, cô ấy sẽ ghi lại như 1 bản ghi yêu thích trong cơ sở dữ liệu "Trái Tim".
• Nhưng nếu làm tổn thương, hệ thống sẽ lưu trong bảng blocked_users.

8. Final Response
• Nếu tất cả validation pass:
{
"status": 200,
"message": "Em cũng thích anh ❤️"
}

• Nếu không pass:
{
"status": 400,
"message": "Không phải do anh không đủ tốt, mà là em chưa sẵn sàng."
}

Nếu bạn là một backend developer, thì để chiếm được trái tim của cô ấy, bạn phải:
• Gửi request đúng lúc (timing).
• Dùng API đúng cách (hiểu cảm xúc).
• Đảm bảo retry strategy tinh tế (không push quá đà).
• Có logging & monitoring để biết khi nào cô ấy buồn, cần bạn.

"Trái tim con gái là một microservice phức tạp. Để gọi đúng API, bạn cần hiểu cả business logic lẫn cảm xúc."

25/03/2024

Design Pattern cho ae Nodejs

25 Design Pattern JavaScript hàng đầu sẽ giúp bạn có TƯ DUY BẬC THẦY (Cách sử dụng và khi nào sử dụng). Tin tôi đi. Can u do that.

JavaScript là ngôn ngữ lập trình đa mô hình, có nhiều tính năng và phù hợp để áp dụng các Patterns thiết kế khác nhau. Đây là các mẫu thiết kế với độ khó, và khi nào sử dụng chúng...

24/03/2024

API (Application Programming Interface) là một công cụ quan trọng, giúp các lập trình viên tiết kiệm thời gian và công sức, nâng cao hiệu quả công việc và sáng tạo ra các ứng dụng mới. Trong bài viết này, chúng ta sẽ cùng khám phá top 8 nguồn API hữu ích hỗ trợ anh em developer xây dựng một số tính năng trên web/app dễ dàng hơn. 😉

API (Application Programming Interface) là một công cụ quan trọng, giúp các lập trình viên tiết kiệm thời gian và công sức, nâng cao hiệu quả công việc và sáng tạo ra các ứng dụng mới. Trong bài viết này, chúng ta sẽ cùng khám phá top 8 nguồn AP...

24/03/2024

ĐIỀU GÌ XẢY RA KHI CHÚNG TA GỬI 1 GIAO DỊCH TRÊN BLOCKCHAIN ?

[Sending section]
Trước khi 1 giao dịch (transaction) được gửi đi thì ở phía người gửi (sender) thường sẽ thực hiện một số thủ tục sau để đảm bảo tính bảo mật và toàn vẹn dữ liệu cho giao dịch:
- Data của giao dịch (bao gồm địa chỉ người gửi, địa chỉ người nhận, số lượng,...) sẽ đi qua 1 hàm hash (chẳng hạn là SHA256 cho Bitcoin hoặc Keccak256 cho Ethereum) để tạo ra chuỗi hash 256-bit.
- Chuỗi hash 256-bit đó sẽ được ký bởi private key của người gửi (sender) để tạo ra 1 chuỗi ký tự mới gọi là chữ ký số (digital signature), chữ ký số này giúp các node trên mạng xác minh người gửi giao dịch. Lúc này giao dịch được broadcast lên toàn mạng blockchain sẽ bao gồm 3 thành phần chính: data, public key và digital signature.
[Receiver section]
Phía người nhận (receiver) thực chất là các node cần xác minh giao dịch theo thuật toán đồng thuận (consensus algorithm) của mạng blockchain. Nhiệm vụ của các node lúc này khi nhận được giao dịch gửi từ người nhận (receiver) là xác nhận giao dịch trên có legit hay không và thủ tục đó gồm các bước sau:
- Dùng public key được gửi kèm trong giao dịch để giải mã digital signature thành chuỗi hash 256-bit (chính là chuỗi trước khi được ký bởi private key trước khi gửi)
- Cho data của giao dịch đi qua hàm băm (giống như cách làm ở bên phía người gửi) để tạo ra chuỗi 256-bit tương tự. Lúc này để biết các dữ liệu trên giao dịch có toàn vẹn hay không, chỉ cần so sánh 2 chuỗi 256-bit này với nhau. Nếu 2 chuỗi này giống nhau thì giao dịch toàn vẹn và đã được xác minh, còn không giống nhau thì giao dịch được xem như lỗi.

Thường thì 1 giao dịch được xem là hợp lệ và ghi vào blockchain chỉ khi trải qua > 50% số lượng node trong mạng đồng thuận và xác nhận giao dịch là hợp lệ. Tuy nhiên vẫn có một số trường hợp các mạng blockchain bị hacker tấn công khi nắm quyền > 50% các node trên mạng, khi đó các giao dịch bị thêm vào blockchain một cách không hợp lệ, đó gọi là 51% attack.

20/03/2024

Tips hữu ích cho ae khi code pet project 😄

LẬP TRÌNH VIÊN 10 TIẾNG 🕑

_____

Là một lập trình viên, chắc hẳn bạn cũng có những ý tưởng phần mềm hay, hữu ích muốn làm. Bạn hăm hở háo hức làm một cách say mê, mong muốn ý tưởng nhanh chóng trở thành hiện thực. Thế rồi bạn không đủ thời gian, được dăm bữa nửa tháng, chán rồi vứt xó.

Có bao giờ bạn lục lại đống code cũ, bạn nhận ra mình đã nghĩ được những ý tưởng đột phá ngang tầm vũ trụ, nhưng cuối cùng nhìn lại, rốt cuộc bạn tốn bao nhiêu công sức, code hoài code mãi vẫn chỉ là những dòng code dở dang, chẳng cái nào hoàn thiện.

Hãy thử "Quy tắc làm phần mềm trong 10 tiếng" của mình. Đây là cách mà mình bắt đầu ra được những sản phẩm nho nhỏ, tuyệt nhiên không còn dở dang project nào nữa.

Làm phần mềm theo phong cách "tàu nhanh", bí kíp đã thất truyền của chị em Trần Duy Hưng.

Với quy tắc này, tất cả những gì bạn cần làm là ngồi xuống và hiện thực hóa ý tưởng trong vòng 10 tiếng. Việc này giống như tự tố chức một cuộc thi Hackathon cho chính mình vậy.

NHỮNG QUY TẮC QUAN TRỌNG:

• Tắt hết facebook, điện thoại hay bất kỳ cái gì làm ảnh hưởng đến sự tập trung, chỉ có bạn và code.

• Không quan trọng bạn làm như thế nào, dùng công nghệ gì, chỉ cần ra sản phẩm là được.

• Bạn phải chắc chắn hoàn thành nó trong 10 tiếng.

• Nếu không đủ thời gian: không được để điều này sảy ra, bạn đã cam kết thì phải làm đúng hạn.

• Bạn chỉ có 10 tiếng để biến ý tưởng của mình thành sự thật, nếu không, bạn sẽ phải vứt bỏ nó đi và KHÔNG bao giờ được tiếp tục làm nữa.

TẠI SAO PHƯƠNG PHÁP NÀY HIỆU QUẢ:

• Vê mặt cảm xúc:

Cảm hứng ý tưởng nó mất dần đi theo thời gian, nhanh thích thì nhanh chán, 10 tiếng là đủ ngắn để bạn không bị tụt cảm xúc. Một dự án cá nhân kéo dài với một list công việc cần phải làm chỉ cho bạn cảm giác nhanh chán nản mà bỏ dở mà thôi.

• Có được sản phẩm:

Sau 10 tiếng nhanh gọn bạn đã có một sản phẩm với tính năng đủ dùng để đem đi khoe hàng với bạn bè. Ý tưởng chỉ đáng giá một xu, sản phẩm mới là quan trọng.
Code của bạn đã trở thành sản phẩm thật, có ích, chứ không chỉ là những đoạn mã vô nghĩa.

• Tập trung vào tính năng chính:

Khi đưa ra ý tưởng, chúng ta có xu hướng thêm thắt nhiều tính năng râu ria mà không thật sự cần thiết. Dưới á.p l.ự.c của deadline, bạn phải mạnh dạn bỏ đi các tính năng không cần thiết để tập trung vào tính năng chính.

• Học được nhiều thứ:

Không tốn quá nhiều thời gian, tất cả chỉ mất có 10 tiếng, nhưng bạn học được kỹ năng dứt điểm dự án, quản lý cân đong thời gian, không bỏ dở, rèn luyện phong cách làm việc kỷ luật, ra ngồn ra khoai...

CÁI CON SỐ 10 TIẾNG NGHE CÓ VẺ NGỚ NGẨN

Tại sao mình lại tin vào con số 10 tiếng thần thánh này? Bởi vì nó phù hợp với các dự án cá nhân và thời gian rảnh của mình, bạn hoàn toàn có thể tăng hay giảm để phù hợp với bạn. Miễn là sau khoảng thời gian đó, bạn có được sản phẩm hoàn thiện và không bị mất cảm hứng.

Hãy khởi đầu những cái nhỏ nhỏ, thẳng Mark viết ra facebook chắc cũng trong khoảng 10 tiếng thôi, có phải ngay từ đầu đã thiết kế cho hàng tỉ người dùng ngay được đâu.

Đây là phương pháp tuyệt vời và cực kỳ hữu ích nếu bạn thuộc kiểu người có rất nhiều ý tưởng nhưng lại cũng nhanh tụt cảm hứng.

Chúc các bạn thành công.



Nguồn: Lập trình cuộc sống

18/03/2024

EventLoop trong Javascript bao gồm 3 thành phần chính:
- Call stack
- Callback queue
- Web APIs

Ta có chương trình mẫu:
console.log('start');
setTimeout(() => {
console.log(`understand asynchronous javascript 2`);
}, 5000);
setTimeout(() => {
console.log(`understand asynchronous javascript 1`);
}, 0);
console.log('end');

Kết quả của chương trình:
start
end
understand asynchronous javascript 1
understand asynchronous javascript 2

Video dưới mô tả cách hoạt động của EventLoop trong chương trình trên.

Bài viết gốc: https://www.codemancers.com/blog/2022-10-26-how-asynchronous-js-works/

17/03/2024

[Nhật ký học Java]

Hôm nay mình học được:
1. Kiến trúc tổng quan của Spring Boot dựa trên sự kết hợp của 2 mô hình nổi tiếng là MVC và 3-tier (3 lớp)
2. Spring Boot = Presentation layer + Service layer + Data access layer
3. Mỗi layer chỉ nên xử lý với 1 dạng data nhất định để đảm báo tính đơn nhiệm (single responsibilty)
4. Có 2 loại chính:
- Public: Tức là các dữ liệu dùng để tương tác qua REST API hoặc với các service của microservice. Data dạng này thường gọi là DTO
- Private: Là các data dùng trong nội bộ ứng dụng, bên ngoài không nên biết. Data lúc này nằm trong các Domain model hoặc Entity. (Domain model là các object đại diện cho business logic, trong khi đó entity là object đại diện cho database)

Bài viết hôm nay khá hay và cũng là chủ đề quan trọng trong Spring Boot. Cụ thể chúng ta cùng tìm hiểu xem data sẽ biến đổi như thế nào khi đi qua các layer khác nhau. Và những khái niệm Entity, Domai...

14/03/2024

OPTIMISTIC ROLLUPS: GIẢI PHÁP LAYER 2 CHI PHÍ THẤP GIÀNH CHO BLOCKCHAIN 😘

Với những ưu điểm mà các mạng blockchain mang lại như tính phi tập trung, tính minh bạch, tính bảo mật,... thì nhu cầu sử dụng các mạng blockchain để giao dịch ngày càng tăng, từ đó kéo theo sự tắc nghẽn trên các mạng. Có thể hình dung giống như 1 con đường dù cho có rộng cỡ nào mà số lượng người đi qua con đường đó quá lớn cũng sẽ dẫn đến tắt nghẽn. Vậy thì lúc này, những "con đường tắt" phát huy tác dụng của nó, và layer 2 cũng có thể hiểu như 1 "con đường tắt" cho các blockchain.

Các giải pháp layer 2 thường hướng đến việc đưa các giao dịch ra ngoài chuỗi để xử lý, từ đó giúp thông lượng trên chuỗi đỡ bị ùn tắt hơn, đồng thời giúp tăng số lượng giao dịch có thể xử lý đồng thời. Hiện nay có rất nhiều các giải pháp layer 2 ra đời như state channel, plasma, validium, zk rollups,... nhưng phương pháp mình muốn giới thiệu cho mọi người hôm nay đó chính là optimistic rollup.

Roll có nghĩa là cuộn, up có nghĩa là đăng lên. Rollup ở đây có thể hiểu là hành đồng gom các giao dịch đã xử lý ở layer 2 và đăng lên lên trên layer 1 (Ethereum, Bitcoin,...). Thế còn optimistic là gì ? Optimistic chính là sự lạc quan trong cơ chế xác thực của phương pháp này. Khi các giao dịch trên layer 2 được gom lại thành batch và gửi xuống layer 1 thì phải trải qua giai đoạn thách thức (challenge period). Trong giai đoạn này, các validator tham gia xác thực giao dịch có thể đưa ra các bằng chứng gian lận (fraud proof) để tố cáo các giao dịch đang được thách thức. Nếu fraud proof của validator đó được xác nhận là đúng thì những validator rollup giao dịch đó sẽ bị phạt và ngược lại thì validator gửi fraud proof sẽ được nhận thưởng. Nếu như trải qua giai đoạn thách thức mà không có validator nào đăng fraud proof cho layer 1 thì batch giao dịch đó coi như hợp lệ và được ghi lên layer 1. Nếu bạn vẫn chưa hiểu thì nó giống như việc nếu bạn có 1 tờ tiền giả nhưng không ai chứng minh đó là tờ tiền đó là giả thì nó sẽ là tờ tiền thật.

Optimistic rollup không tiêu tốn quá nhiều tài nguyên tính toán như zk rollup (vì zk rollup cần tính toán zk proof) nên chi phí giao dịch trên cách mạng optimistic rollup thường sẽ khá rẻ. Tuy nhiên vấn đề ở đây nằm thời gian thách thức. Khoảng thời gian này thường sẽ kéo dài khoảng 7 ngày, điều này làm chậm tốc độ xác thực giao dịch trên blockchain so với các giải pháp layer 2 khác.

Dù thế nhưng hiện nay, các layer 2 network thành công nhất như Arbitrum, Optimism,... đều sử dụng optimistic rollups để mở rộng cho khả năng giao dịch của Ethereum. Tất nhiên là mỗi platform đều có ưu nhược điểm riêng của nó, tùy vào mục đích sử dụng của mỗi người mà chúng ta có thể chọn những platform đáng tin cậy để sử dụng cho nhu cầu của chúng ta.

14/03/2024

AI sơ khai cũng giống như những đứa trẻ lên 5, chỉ mới học hỏi từ thế giới bên ngoài và ứng xử với thế giới một cách rất "ngây thơ", ai dạy gì thì nghe nấy, ai bảo gì làm nấy. Đứa trẻ 5 tuổi thường được bố mẹ dạy rằng ra đường thì không được nói chuyện với người lạ, cũng không được đi theo người lạ, nếu không sẽ bị "bắt cóc" mất. Có vẻ đã đến lúc con người phải dạy cho "những đứa nhóc 5 tuổi" cách để chúng tự bảo vệ bản thân 😂😂

𝐒𝐭𝐞𝐚𝐥𝐢𝐧𝐠 𝐏𝐚𝐫𝐭 𝐨𝐟 𝐚 𝐏𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧 𝐋𝐚𝐧𝐠𝐮𝐚𝐠𝐞 𝐌𝐨𝐝𝐞𝐥
[link in comment]
---
Khi AI bị ép cung

Một nhóm nhà nghiên cứu (1) đã thành công trong việc tấn công và trích xuất các thông số trọng yếu của các mô hình ngôn ngữ lớn như ChatGPT hay PaLM-2. Với dưới 20 đô la, họ đã làm cho hai "hộp đen" của OpenAI tiết lộ toàn bộ ma trận chiếu (2) của chúng. Theo đó, nhóm nghiên cứu lần đầu tiên xác nhận các mô hình Ada và Babbage có chiều ẩn (3) lần lượt là 1024 và 2048. Nhóm cũng ước tính rằng chỉ với dưới 2000 truy vấn, họ có thể tái lập toàn bộ ma trận chiếu của gpt-3.5-turbo. Công trình này bước đầu đề cập đến vấn đề phòng vệ và giảm thiểu rủi ro khi triển khai các mô hình ngôn ngữ lớn vào sản phẩm.

---
(1) gồm các vị đến từ chính Google Deepmind và OpenAI
(2) tiếng Anh: projection matrix
(3) tiếng Anh: hidden dimensions

14/03/2024

Share về tí cho ae nào muốn ôn tập DS mà chưa biết nên ôn gì 😁 Đợt này tui cũng đang phỏng vấn tùm lum nên để đây có gì lục lại xem

CẤU TRÚC DỮ LIỆU QUAN TRỌNG DÀNH CHO LẬP TRÌNH VIÊN THI ĐẤU - COMPETITIVE PROGRAMMING
----
Lập trình thi đấu đòi hỏi nền tảng vững chắc về nhiều cấu trúc dữ liệu khác nhau để giải quyết hiệu quả các bài toán thuật toán trong thời gian giới hạn. Dưới đây là danh sách các cấu trúc dữ liệu quan trọng mà các lập trình viên thi đấu cần nắm rõ:

- Mảng (Arrays): Cơ bản và được sử dụng rộng rãi để lưu trữ các phần tử cùng kiểu dữ liệu. Truy cập ngẫu nhiên hiệu quả, nhưng việc chèn và xóa có thể kém hiệu quả hơn.

- Danh sách liên kết (Linked Lists): Hữu ích cho việc phân bổ bộ nhớ động. Cung cấp tính năng chèn và xóa hiệu quả, nhưng truy cập ngẫu nhiên chậm hơn so với mảng.

- Ngăn xếp (Stacks): Thực hiện theo nguyên tắc "Vào sau, ra trước" (LIFO). Được sử dụng để quản lý các lần gọi hàm, đánh giá biểu thức và quay ngược lại trong các thuật toán.

- Hàng đợi (Queues): Thực hiện theo nguyên tắc "Vào trước, ra trước" (FIFO). Cần thiết để quản lý các tiến trình, duyệt BFS và các tình huống khác yêu cầu xử lý theo thứ tự.

- Cây (Trees): Cây nhị phân và Cây tìm kiếm nhị phân (BST) được sử dụng phổ biến. Cấu trúc cây tạo điều kiện tìm kiếm, chèn và xóa hiệu quả.

- Đống (Heaps): Đống nhị phân, cụ thể là Min Heap hoặc Max Heap, đóng vai trò quan trọng. Lý tưởng để triển khai hàng đợi ưu tiên và các thuật toán dựa trên đống.

- Bảng băm (Hash Tables): Hiệu quả cho việc truy xuất và chèn nhanh các cặp key-value. Băm là cần thiết cho nhiều thuật toán và lưu trữ dữ liệu khác nhau.

- Đồ thị (Graphs): Kiến thức về cả đồ thị có hướng và không hướng. Quen thuộc với các cách biểu diễn đồ thị (ma trận kề, danh sách kề) và các thuật toán duyệt đồ thị (BFS, DFS).

- Cây tiền tố (Trie): Cấu trúc cây chuyên biệt được sử dụng để tìm kiếm và lưu trữ chuỗi hiệu quả. Thường được sử dụng trong các bài toán liên quan đến từ điển và các hoạt động liên quan đến từ.

- Disjoint Set Union (Union-Find): Thiết yếu để giải quyết các bài toán liên quan đến các thành phần liên thông và kết nối động.

- Cây đoạn (Segment Tree): Được sử dụng cho các hoạt động truy vấn theo khoảng, chẳng hạn như tìm giá trị tối thiểu, tối đa hoặc tổng trong một khoảng nhất định. Quan trọng đối với các vấn đề liên quan đến khoảng.

- Cây Fenwick (Binary Indexed Tree): Hiệu quả cho các truy vấn tần suất tích lũy và cập nhật. Hữu ích trong các bài toán yêu cầu tổng tiền tố hoặc cập nhật khoảng.

- Bảng thưa (Sparse Table): Thích hợp để giải quyết các bài toán truy vấn theo khoảng một cách hiệu quả. Thường được sử dụng trong các trường hợp cần lập trình động với ghi nhớ (memoization).

- Hàng đợi ưu tiên dựa trên đống (Heap-based Priority Queue): Được sử dụng để quản lý các phần tử có độ ưu tiên. Thiết yếu cho một số thuật toán đồ thị và các vấn đề tối ưu hóa khác nhau.

- Mảng xâu hậu tố và Cây xâu hậu tố (Suffix Array & Suffix Tree): Có giá trị trong việc giải quyết các vấn đề liên quan đến thao tác chuỗi và so khớp mẫu.

- Cây tìm kiếm nhị phân cân bằng (AVL, Red-Black): Đảm bảo độ phức tạp thời gian logarit cho tìm kiếm, chèn và xóa. Hữu ích trong các trường hợp cần một cây tìm kiếm nhị phân tự cân bằng.

- Cấu trúc dữ liệu nâng cao: Tùy thuộc vào bài toán, kiến thức về các cấu trúc nâng cao như Treaps, Splay Trees và Cây tìm kiếm nhị phân tự cân bằng có thể có lợi.

Hiểu rõ điểm mạnh, điểm yếu và trường hợp sử dụng của các cấu trúc dữ liệu này là điều cần thiết cho các lập trình viên thi đấu. Khả năng thao tác và triển khai hiệu quả các cấu trúc này có thể nâng cao đáng kể kỹ năng giải quyết vấn đề trong các cuộc thi lập trình và phỏng vấn tuyển dụng.