Blog - Dat Le

Pentomino và Sudoku: tự tạo đề, in A4 rồi chơi

Mon, 26 Oct 2026 17:00:00 GMT

Tôi vừa làm thêm hai trò chơi nhỏ: Pentomino và Sudoku. Lần này, phần tôi muốn giới thiệu nhất là generator: công cụ tự sinh đề, để mỗi lần muốn chơi lại có một thử thách mới, không phải đi tìm đề có sẵn.

Pentomino: tạo đề xếp hình của riêng bạn

Với Pentomino Generator, bạn xếp các mảnh ghép sao cho phủ kín bàn, không chồng lên nhau. Bạn có thể chọn hình dạng bàn hoặc tự chặn bớt ô, sinh bộ mảnh ghép phù hợp, rồi tạo đề theo độ khó mong muốn. Có cả tùy chọn yêu cầu đề chỉ có một lời giải.

Bản in A4 có bàn chơi và các mảnh để cắt rời: in ra, lấy kéo cắt là có một bộ xếp hình bằng giấy. Bạn cũng có thể in kèm lời giải để đối chiếu sau.

Sudoku: không chỉ có bảng 9×9

Sudoku Generator có 15 biến thể, từ Sudoku cổ điển đến Killer, Jigsaw hay Samurai, cùng nhiều mức độ khó. Một điểm vui nữa là bạn có thể xem lại từng bước máy đã tạo ra đề.

Bạn có thể tạo nhiều đề, chọn in 1, 2 hoặc 4 đề mỗi trang và để lời giải ở trang riêng. In trên giấy A4 hoặc lưu thành PDF là có ngay một tập đề để dành.

Tạo đề trên máy, chơi trên giấy

Cả hai đều có giao diện tiếng Việt, không cần tài khoản hay cài đặt. Mỗi trò cũng có player để chơi ngay trong trình duyệt, nhưng đó chỉ là lựa chọn thêm: sinh đề, in A4 rồi rời màn hình mới là cách chơi tôi muốn gợi ý lần này.

Thử tạo vài đề, chuẩn bị giấy bút (và một chiếc kéo nếu chọn Pentomino), rồi chơi lúc rảnh nhé.

Captain Tsubasa II Password Generator: Tuổi thơ được làm lại bằng AI

Sun, 11 Oct 2026 02:00:00 GMT

Nếu lớn lên vào những năm 90, rất có thể Captain Tsubasa Vol. II: Super Striker (キャプテン翼II スーパーストライカー) đã là một phần tuổi thơ của bạn. Game ra mắt trên Famicom/NES do Tecmo phát hành năm 1990, dựa trên bộ manga nổi tiếng của Yoichi Takahashi. Nó biến bóng đá thành một trò chơi căng thẳng theo từng lệnh: chọn một chiêu, tiêu hao guts, rồi hy vọng người hùng của bạn tung được Drive Shot hay Cyclone trước khi thủ môn kịp cản phá.

Với thế hệ millennial, đó không chỉ là một trò chơi. Đó là băng game cắm vào chiếc máy mượn của bạn, là câu chuyện bằng tiếng Nhật mà ta không đọc được, và là người bạn ngồi bên cạnh cùng mày mò từng nút bấm một.

Màn hình password

Game không có pin lưu. Muốn chơi tiếp lần sau, bạn phải ghi lại một password gồm 18 ký tự là các chữ kana của Nhật rồi nhập vào màn hình nhập mã. Password đó lưu lại mọi thứ: vòng đấu bạn đã đến, level và kinh nghiệm của các cầu thủ, các cú sút đặc biệt, và cả guts của Misugi.

Ngày ấy, password hoặc là chép từ tạp chí, hoặc là mất luôn. Ngày nay ta có thể tự tạo password cho riêng mình.

Công cụ

Tôi làm một công cụ tạo password để bạn có thể bắt đầu từ bất kỳ vòng đấu nào, với level cầu thủ tùy ý:

Mở Captain Tsubasa II Password Generator

Bạn có thể làm gì với nó:

Chọn vòng đấu. Cả 33 vòng đấu chính thức đều được liệt kê cùng đối thủ, từ Fluminense ở vòng mở màn đến Brazil ở vòng chung kết World Cup.
Tinh chỉnh từng nhóm cầu thủ. Đặt Level và Exp cho từng nhóm trong mười nhóm. Các cầu thủ hiển thị thay đổi theo vòng đấu hiện tại: São Paulo, Nankatsu hoặc Nhật Bản.
Mở khóa khả năng. Bật hoặc tắt Cyclone Shot, Drive Overhead Shot, và việc guts của Misugi có thấp hơn 100 hay không.
Thử vận may. Random match tạo ngẫu nhiên toàn bộ thiết lập, với level cầu thủ phù hợp với vòng đấu đã chọn. Hai lựa chọn khác mở rộng phạm vi: không cân bằng, mỗi nhóm có một level ngẫu nhiên riêng nằm giữa mức khó và mức dễ của vòng đấu, cộng thêm 3 level ở mỗi đầu; hoặc ngẫu nhiên hoàn toàn, mỗi level được chọn ở bất kỳ đâu từ mức hợp lý thấp nhất đến cao nhất của vòng đấu.
Theo dõi ngay trong game. Password cập nhật khi bạn gõ, còn Game input screen tô sáng đúng phím cần bấm tiếp theo. Dùng < và > để lần lượt đi qua cả 18 ký tự.
Đổi ngôn ngữ. Màn hình nhập mã có thể hiển thị theo kana tiếng Nhật hoặc theo bộ ký tự của bản tiếng Anh.

Mọi thứ chạy ngay trong trình duyệt của bạn, không cần cài đặt gì và không gửi dữ liệu đi đâu cả.

Làm lại với AI

Tôi không phải người nghĩ ra thuật toán. Nó đến từ password generator của cah4e3, còn chi tiết thuật toán được ghi công cho Gennadiy_Master. Công cụ đó đã phục vụ cộng đồng rất tốt, nhưng giao diện của nó đã lỗi thời.

Với sự hỗ trợ của AI, tôi xây dựng lại chính thuật toán đó bằng HTML, CSS và JavaScript thuần, với giao diện gọn gàng và hiện đại hơn: nút tăng giảm và thanh trượt thay cho các ô nhập thô, bàn phím nhập được tô sáng, tooltip giải thích từng tùy chọn, và bố cục dùng tốt trên điện thoại.

Bên trong, password đóng gói level, kinh nghiệm, vòng đấu, các cờ và một seed 6 bit thành 18 giá trị 6 bit. Sau đó nó cộng thêm checksum, xáo trộn các giá trị bằng một bảng thay thế, rồi dịch từng giá trị theo một độ lệch tăng dần. Seed không ảnh hưởng gì trong game, nhưng đổi seed sẽ cho bạn một password khác mà vẫn hợp lệ với cùng một thiết lập.

Giờ thì hãy lấy emulator của bạn (hoặc chiếc máy Famiclone cũ ấy), chọn vòng đấu, và ghi vài bàn cho đỡ nhớ.

Lưu ý: Bạn có thể chơi game này trực tuyến tại https://www.retrogames.cc/nes-games/c/index.html.

Ba trò chơi nhỏ: tìm chữ, tìm số và tìm con vật

Fri, 11 Sep 2026 17:00:00 GMT

Tôi làm ba trò chơi nhỏ cho những lúc muốn vừa chơi, vừa rèn khả năng quan sát. Cả ba đều có thể in ra giấy A4 để chơi cùng nhau.

Mê cung chữ: Tìm những từ ẩn trong bảng chữ do bạn tự tạo.
Mê cung con vật: Tìm các chuỗi con vật trong bảng hình, phù hợp cả với các bé chưa biết chữ.
Trò chơi tìm số: Thử tài tinh mắt với bảng số xáo trộn trong khoảng số bạn chọn.

Adaptive Sampling: Giảm 99% dữ liệu Distributed Tracing mà không mất khả năng quan sát

Sat, 02 May 2026 02:00:00 GMT

Tuyên bố miễn trừ: Tên các hệ thống trong bài đã được thay đổi để tránh tiết lộ thông tin mật. Mọi con số đều chính xác.

Trong hai năm qua, nhóm của tôi tại Microsoft đã tích hợp Distributed Tracing (DT) vào hầu hết các microservice quan trọng của Substrate, nền tảng vận hành Microsoft 365. DT là công cụ chúng tôi tìm đến mỗi khi một API gặp sự cố: nó cho phép xác định chính xác node đã gây ra lỗi và chỉ ra những thành phần đang kéo độ trễ lên.

DT kết hợp rất tự nhiên với một hệ thống do nhóm đối tác vận hành — Active Monitoring — một đội probe tổng hợp liên tục gọi vào các dịch vụ nội bộ và máy chủ vật lý để đảm bảo mọi thứ luôn khỏe mạnh. Khi một probe thất bại, một trace là khác biệt giữa “có chỗ nào đó đang hỏng” và “lời gọi downstream cụ thể này đã hết thời gian chờ trên chiếc máy cụ thể này.”

Bài toán mở rộng quy mô

Microsoft 365 chạy trên hàng trăm nghìn máy chủ vật lý trải khắp thế giới. Chỉ riêng Active Monitoring đã tạo ra khoảng 78 triệu request mỗi giờ ở quy mô đó. Mỗi request được lấy mẫu đều tạo ra một trace, và mỗi trace mang theo hàng chục span qua nửa tá dịch vụ. Tổng khối lượng đơn giản là quá lớn để backend DT của chúng tôi tiếp nhận, lưu trữ và truy vấn với chi phí chấp nhận được.

Vì vậy chúng tôi cần lấy mẫu (sampling). Điểm khó là ràng buộc mà Active Monitoring đặt ra:

Nếu một request tổng hợp thất bại, chúng tôi bắt buộc phải có trace của nó. Không có ngoại lệ.

Mất trace thì cảnh báo trở nên vô dụng — on-call bị gọi dậy mà không có con đường nào để tìm ra nguyên nhân gốc. Điều đó còn tệ hơn là không có cảnh báo.

Vậy thử thách thật sự không phải là “giảm dữ liệu”. Mà là: giảm dữ liệu thật mạnh tay, nhưng không bao giờ bỏ sót một request không khỏe mạnh.

Vì sao các sampler có sẵn không phù hợp

OpenTelemetry cung cấp hai nhóm chiến lược lấy mẫu. Chúng tôi đã xem xét kỹ cả hai.

Head-based: Ratio Sampler

Head-based sampling quyết định giữ hay bỏ một trace ngay khi nó bắt đầu, trước khi có bất kỳ span nào được ghi nhận. Biến thể phổ biến nhất là ratio sampler: giữ N% số trace, bỏ phần còn lại.

Ưu điểm:

Rẻ. Quyết định được đưa ra cục bộ và tức thì.
Khối lượng dữ liệu dự đoán được. Chọn 1% thì bạn nhận đúng 1%.

Nhược điểm (với trường hợp của chúng tôi):

Nó mù về kết quả. Một request không khỏe mạnh có cơ hội được giữ lại ngang với một request khỏe mạnh.
Ở quy mô toàn cầu, tỷ lệ lỗi rất nhỏ — chỉ một phần nhỏ của một phần trăm. Bất kỳ tỷ lệ nào đủ thấp để vừa ngân sách dữ liệu của chúng tôi cũng sẽ âm thầm vứt bỏ phần lớn những lỗi mà chúng tôi sinh ra để điều tra.

Tail-based Sampler

Tail-based sampling đưa ra quyết định sau khi trace kết thúc, khi đã biết kết quả. Về lý thuyết nó hoàn hảo: giữ 100% trace thất bại, bỏ 100% trace thành công.

Trên thực tế, nó có hai vấn đề hóa ra là điểm chết với chúng tôi:

Bạn phải đệm mọi span của mọi trace cho đến khi có quyết định. Bản thân bộ đệm đó đã là một chi phí lưu trữ và bộ nhớ khổng lồ — bạn chỉ chuyển vấn đề đi chỗ khác chứ chưa giải quyết nó. Ở khối lượng của chúng tôi, bộ đệm “tạm thời” sẽ lớn hơn cả backend mà chúng tôi đang cố bảo vệ.
Bạn phải biết trace kết thúc ở đâu. Tail-based sampling cần một “cái đuôi” — span cuối cùng — để kích hoạt quyết định. Microsoft 365 là một đồ thị dịch vụ rộng lớn và liên tục thay đổi. Không có một cái đuôi chuẩn duy nhất. Dịch vụ được thêm vào, đồ thị lời gọi dịch chuyển, các nhánh fan-out bất đồng bộ khiến “điểm kết thúc” trở nên mơ hồ. Bất kỳ heuristic nào chúng tôi chọn cũng sẽ lỗi thời trong vòng một quý.

Hình hài của một lời giải tốt hơn: adaptive sampling

Trong lúc đào sâu các thảo luận của OpenTelemetry và các buổi nói chuyện tại hội nghị, tôi liên tục gặp thuật ngữ adaptive sampling — ý tưởng rằng chính cấu hình của sampler nên thay đổi theo thời gian để phản ứng với những gì hệ thống đang làm. Có những gợi ý, bản phác thảo và các mô tả dài một đoạn, nhưng không có thiết kế nào đã được kiểm chứng thực chiến để chúng tôi lấy về dùng.

Vì vậy chúng tôi tự thiết kế. Nhận định cốt lõi nhỏ nhưng mạnh:

Một head-based ratio sampler thì nhanh và rẻ. Một tail-based sampler thì biết kết quả. Nếu chúng ta giữ head-based sampler, nhưng để kết quả của vài phút trước quyết định tỷ lệ của nó thì sao?

Chúng tôi chia công việc cho hai thành phần mới:

AdaptiveSampler là sampler tùy biến của chúng tôi, áp dụng cho Active Monitoring. Nó vẫn là head-based — quyết định diễn ra ngay khi trace bắt đầu, không cần đệm. Nhưng thay vì một tỷ lệ cố định duy nhất, nó giữ một bản đồ tỷ lệ theo từng server ([{serverA: 1.0}, {serverB: 0.1}, ...]) do Config System đẩy xuống. Khi một request đến server X, nó tra tỷ lệ của X rồi tung một số ngẫu nhiên: SAMPLED với xác suất đó, ngược lại DROP.
AdaptiveSamplerWorker là bộ điều khiển. Cứ 5 phút, nó đọc kết quả Active Monitoring trong 5 phút gần nhất từ MDM, chọn ra những server có ít nhất một request không khỏe mạnh (các server hot), rồi ghi một bản đồ tỷ lệ mới vào Config System: 100% cho các server hot, 10% cho tất cả server còn lại.

Sau đó Config System lan truyền bản đồ này tới mọi server Active Monitoring, nơi mỗi AdaptiveSampler nhận thay đổi và điều chỉnh hành vi ở request kế tiếp.

Cái giá phải trả là độ trễ thời gian. Nếu một server lỗi lần đầu tiên tại thời điểm T, chúng tôi sẽ không lấy mẫu nó ở mức 100% cho đến khi lần chạy kế tiếp của worker tính ra bản đồ và Config System đẩy nó xuống. Câu hỏi trở thành: độ trễ đó là bao lâu, và có chấp nhận được không?

Vì sao cách này hiệu quả ở Microsoft 365: hạ tầng sẵn có

Câu hỏi về độ trễ là chỗ thiết kế gặp may. Microsoft 365 vốn đã có hai mảnh hạ tầng mà chúng tôi có thể dựa vào:

Active Monitoring → MDM (kho metrics của chúng tôi). Kết quả probe đi vào MDM với độ trễ tối đa ~2 phút.

Config System → mọi server. Các thay đổi cấu hình lan đến mọi server trên toàn thế giới trong vòng ~5 phút.

Ghép chúng lại:

Một request không khỏe mạnh xảy ra tại thời điểm T.
Kết quả của nó có thể truy vấn được trong MDM chậm nhất vào T + 2 phút.
AdaptiveSamplerWorker đọc MDM, tính tỷ lệ mới và ghi bản đồ cập nhật vào Config System.
Cấu hình mới đến server bị ảnh hưởng chậm nhất vào T + 7 phút.
Server đó duy trì mức lấy mẫu 100% qua cửa sổ quyết định kế tiếp — chậm nhất đến T + 12 phút.

Vậy trong trường hợp xấu nhất, chỉ một request lỗi cũng cho chúng tôi một cửa sổ trace đầy đủ độ phân giải kéo dài 5–10 phút trên server gặp vấn đề, bắt đầu khoảng 7 phút sau lỗi. Đủ dài để bắt được lỗi kế tiếp nếu sự cố vẫn còn tiếp diễn — chính là trường hợp quan trọng nhất với on-call.

Thiết kế tổng quan

Bốn thành phần, một vòng lặp:

Thành phần mới duy nhất là AdaptiveSampler (sampler tùy biến, kế thừa lớp cơ sở của OpenTelemetry) và AdaptiveSamplerWorker (Azure Function, kích hoạt mỗi 5 phút). MDM, Config System và bản thân Active Monitoring đã có sẵn và do các nhóm khác duy trì. Chúng tôi không xây một nền tảng lấy mẫu — chúng tôi viết một sampler tùy biến nhỏ và một bộ điều khiển phản ứng để điều khiển nó.

Một vài lưu ý về bộ điều khiển mà sơ đồ không cho thấy rõ:

Quyết định idempotent. Mỗi lần chạy tính lại toàn bộ tập server hot từ đầu. Không có trạng thái tăng dần nào có thể bị hỏng; nếu worker sập rồi khởi động lại, lần chạy kế tiếp vẫn đúng.
Không hysteresis, có chủ ý. Một server hot tại T và yên tĩnh tại T+5 sẽ quay về 10%. Chúng tôi từng cân nhắc một cơ chế cooldown (“giữ hot thêm hai chu kỳ sau khi phục hồi”) và quyết định không làm — lượng dữ liệu thêm không đáng với độ phức tạp tăng thêm, và 5 phút đệm ở lần lỗi kế tiếp đã là đủ.
Hai tỷ lệ, không phải một đường cong. Chúng tôi từng thử thang trượt (lỗi càng nhiều → tỷ lệ càng cao) rồi bỏ. Nhị phân 100/10 dễ suy luận hơn, dễ gỡ lỗi hơn, và phần dữ liệu tiết kiệm được chủ yếu đến từ kích thước của phần fleet yên tĩnh, chứ không phải từ việc tinh chỉnh phần ồn ào.

Kết quả

Sau khi triển khai:

Giảm ~99% số trace khỏe mạnh mà backend DT tiếp nhận.
Giảm 0% số trace không khỏe mạnh Active Monitoring thu được trong cửa sổ của nó.

Trong Test ring, nơi lưu lượng không khỏe mạnh cao hơn do chủ ý thiết kế, mức tiết kiệm khá khiêm tốn — không có nhiều lưu lượng khỏe mạnh để sampler loại bỏ:

Test ring: trace khỏe mạnh chỉ giảm khiêm tốn — phần lớn lưu lượng vốn không khỏe mạnh theo thiết kế, nên sampler không có nhiều thứ để bỏ.

Trong Global ring, nơi fleet gần như hoàn toàn khỏe mạnh, mức giảm là không thể nhầm lẫn. Hãy nhìn nơi đợt triển khai đáp xuống:

Global ring: trace khỏe mạnh rơi thẳng đứng ngay khi AdaptiveSampler bắt đầu hoạt động, trong khi lưu lượng không khỏe mạnh gần như không thay đổi.

Điều rút ra

Vài điều tôi muốn chia sẻ với bất kỳ ai gặp bài toán tương tự:

Đừng chọn một sampler. Hãy chọn một vòng điều khiển. Head-based hay tail-based là một thế lưỡng phân sai lầm nếu bạn có thể đổi cấu hình lấy mẫu trong vài phút. Không gian thiết kế thú vị nằm ở tín hiệu nào điều khiển việc thay đổi cấu hình.
Tận dụng ngân sách độ trễ bạn đã có. Thiết kế của chúng tôi chỉ hoạt động vì MDM và Config System vốn đã nhanh. Nếu chúng là các hệ thống batch chạy theo giờ, cách này sẽ sụp đổ và bạn quay về với tail-based cùng mọi vấn đề của nó. Hãy biết nhịp đồng hồ của hạ tầng hiện có trước khi thiết kế bên trên nó.
“Có mất mát nhưng đúng hướng” thắng “không mất mát nhưng không đủ tiền.” Chúng tôi chấp nhận mất một lỗi thoáng qua xuất hiện lần đầu. Chúng tôi không chấp nhận mất một lỗi kéo dài. Xác định chính xác mức mất mát chấp nhận được hữu ích hơn việc đuổi theo con số không.
Adaptive sampling còn thiếu tài liệu. Ý tưởng này lưu hành trong các buổi nói chuyện tại hội nghị và các issue của OTel, nhưng khi bắt đầu tôi không tìm được bài viết thực tế nào. Nếu bạn đang thiết kế một hệ thống như vậy, lời giải có lẽ đơn giản hơn những gì tài liệu khiến nó trông như thế — của chúng tôi chỉ gồm vài trăm dòng code cho worker cộng với một câu truy vấn SQL vào MDM.

Nếu bạn đang nhìn hóa đơn DT không vừa ngân sách và một yêu cầu độ tin cậy không chịu nhượng bộ, mẫu thiết kế này đáng để thử.

Vui lên nào.

Tue, 21 Nov 2017 11:45:00 GMT

Hắn vừa feed vừa chửi. Bao giờ cũng thế, cứ feed xong là hắn chửi. Bắt đầu hắn chửi mid. Có hề gì? Đến những hai thằng đi mid. Rồi hắn chửi team. Thế cũng chả sao: team là tất cả nhưng chẳng là ai. Tức mình, hắn chửi cả cái SEA này. Nhưng cả server ai cũng nhủ “chắc nó trừ mình ra”, không ai lên tiếng cả. Tức thật! ờ! Thế này thì tức thật! Tức chết đi được mất! Đã thế, hắn phải chửi cha đứa nào không feed chung với hắn. Nhưng cũng không ai ra điều. Mẹ kiếp! Thế có phí công hắn try hard không? Thế thì có khổ hắn không? Không biết đứa chết mẹ nào lại để ra mode low priority cho hắn khổ đến nông nỗi này? A ha. Phải đấy hắn cứ thế mà chửi, hắn nghiến răng vào mà chửi “bobo putang ina mo IceFrog”. Nhưng mà biết đứa nào là IceFrog? Có mà Bruno biết. Hắn không biết, cả Steam cũng không ai biết…

Khuyết danh

Jekyll thật ấn tượng.

Mon, 20 Nov 2017 11:20:00 GMT

Với Jekyll, bạn có thể đăng blog lên GitHub hoàn toàn miễn phí.

Bạn có thể chèn đoạn code…

const express = require('express')
const app = express()

app.get('/', (req, res) => res.send('Hello World!'))

app.listen(3000, () => console.log('Example app listening on port 3000!'))

Bạn cũng có thể đính kèm hình ảnh…

hoặc nhúng một đoạn clip trên Youtube…

Hãy thử xem sao nhé :)

Demo: https://github.com/tdat00/blog

Hello World

Fri, 14 Jul 1989 12:05:00 GMT

Cậu bé hay kêu cứu…

kèm theo một đoạn code…

// Chương trình Hello World! bằng C#.
using System;
namespace HelloWorld
{
    class Hello
    {
        static void Main()
        {
            Console.WriteLine("Hello World!");

            // Giữ cửa sổ console luôn mở khi chạy ở chế độ debug.
            Console.WriteLine("Press any key to exit.");
            Console.ReadKey();
        }
    }
}

csharp