20.11.2018

Gần đây tôi đang sống ở khu vực Bell Canyon, Mỹ, và sử dụng router Google Wi-Fi. Một hôm khi đang chơi bên ngoài, mẹ tôi gọi điện và hỏi liệu tôi có phải đã thanh toán bằng thẻ của bố tôi tổng cộng 2000 đô la trong bốn lần không. Tôi khẳng định rằng mình chỉ dùng thẻ cá nhân và không hề thực hiện giao dịch nào như vậy. Sau khi kiểm tra lịch sử giao dịch, tôi thấy rằng tất cả bốn lần này đều xảy ra vào giữa đêm theo múi giờ Việt Nam, mỗi lần cách nhau khoảng một giờ và số tiền gần như giống nhau. Ngay lập tức, tôi nghĩ rằng thẻ có thể đã bị đánh cắp và khuyên bố khóa thẻ lại trước khi điều tra thêm.

Sau đó, bố tôi liên hệ với ngân hàng và được thông báo rằng các khoản thanh toán này là từ Uber. Tôi kiểm tra tài khoản Uber và PayPal nhưng không tìm thấy bất kỳ dấu vết nào về các giao dịch này. Tôi cũng đọc trên mạng rằng có nhiều trường hợp kẻ gian sử dụng thông tin thẻ để cung cấp dịch vụ đi xe giá rẻ cho người khác, khiến tôi nghi ngờ rằng mình có thể đã trở thành nạn nhân của một vụ lừa đảo liên quan đến “xe ma”. Do đó, tôi đã liên hệ với dịch vụ chăm sóc khách hàng của Uber để làm rõ vấn đề.

Trong lúc chờ phản hồi từ Uber, một đồng nghiệp của tôi tại Bell Canyon nói rằng cô ấy vừa phát hiện thẻ tín dụng của mình cũng bị trừ tiền theo cùng một mô hình: bốn lần liên tiếp trong vòng một giờ, mỗi lần với số tiền tương tự, và thời gian xảy ra chỉ cách sự cố của tôi khoảng 20 phút. Chúng tôi bắt đầu cảm thấy kỳ lạ và suy đoán liệu có một phương thức trung gian nào đó hoặc thủ đoạn đặc biệt dẫn đến tình trạng này hay không. Không khí trở nên căng thẳng hơn khi chúng tôi nhận ra khả năng mạng lưới đã bị can thiệp.

Đồng nghiệp của tôi gọi cho ngân hàng và được thông báo rằng những giao dịch này thực tế là từ Lyft, nhưng ngân hàng đã từ chối giao dịch. Chúng tôi nhớ lại rằng vào thời điểm nửa đêm theo múi giờ Việt Nam, đó chính là buổi sáng sớm tại Los Angeles, khoảng tám hoặc chín giờ. Ngày đó, chúng tôi dự định gặp nhau ở trung tâm LA để lấy xe, vì vậy đã cố gắng ban ca nang tien đặt xe liên tục nhưng không thành công. Cuối cùng, một đồng nghiệp khác đã giúp chúng tôi đặt được xe. Điều đáng chú ý là số tiền bị trừ mỗi lần gần bằng với chi phí di chuyển từ Bell Canyon đến điểm đích trong thành phố.

Vậy là chúng tôi dần hiểu ra rằng, hóa ra các khoản phí này có thể do chính hoạt động đặt xe của chúng tôi gây ra. Tuy nhiên, cả Uber và Lyft đều gặp phải tình trạng không có xe nhưng vẫn trừ tiền mà không có ghi nhận đơn hàng. Sau khi phân tích kỹ hơn, chúng tôi nghi ngờ rằng vấn đề có thể xuất phát từ việc chuyển đổi giữa các thiết bị trong mạng lưới Mesh Network của Google Wi-Fi hoặc do tường lửa tích hợp đã chặn nhầm một số yêu cầu cần thiết. Dù sao thì, thay vì là một kịch bản bí ẩn, sự việc này hóa ra chỉ là một lỗi kỹ thuật. Bây giờ, tôi chỉ hy vọng dịch vụ chăm sóc khách hàng của Uber sẽ sớm hoàn trả số tiền.

Câu chuyện thứ hai liên quan đến Unity. Năm 2018 rồi mà Unity vẫn chưa có API để thông báo khi AudioSource kết thúc việc phát âm thanh. Một chức năng cơ bản như vậy nhưng lại không được cung cấp, khiến mọi người phải tìm kiếm giải pháp thay thế trên các diễn đàn. Giải pháp phổ biến nhất là lấy độ dài của AudioClip, sau đó thiết lập một coroutine để đếm ngược và gọi lại hàm callback khi hết thời gian.

Do đó, để xử lý một sự kiện đơn giản, bạn buộc phải thêm một cơ chế đếm ngược vào lớp chứa AudioSource, đồng thời đảm bảo rằng mỗi lần re-assign AudioClip, bạn phải reset lại thời gian đếm ngược. Đây là một ví dụ điển hình về cái mà tôi ghét ở Unity Pattern: để thực hiện một nhiệm vụ đơn giản, bạn phải giới thiệu các flag không cần thiết làm phức tạp cấu trúc lớp. Khi số lượng task tăng lên, các flag bắt đầu xung đột với nhau, khiến mã nguồn trở nên hỗn loạn.

Tuy nhiên, điều này không hẳn là không thể tránh khỏi. Nhưng đối với nhiều người mới làm quen, thiết kế API kiểu này ép họ viết code kém chất lượng (shit code), nohu52.win đẩy mọi thứ vào hàm Update để liên tục kiểm tra, biến nó thành một dạng lập trình hướng quy trình (procedural programming). Hệ thống còn thiếu rất nhiều thông tin cần thiết, khiến nếu không từ bỏ ngay lập tức hệ thống âm thanh mặc định (chẳng hạn chuyển sang FMOD hoặc Audio Mixer), mã nguồn dù nhìn bề ngoài gọn gàng hơn nhưng thực tế lại tiêu tốn nhiều tài nguyên hơn. Ví dụ, việc quan sát thay đổi thuộc tính thực chất chỉ là cách đưa các flag vào một nơi tập trung để quản lý.

Hy win win - game bài vọng Unity sẽ cải thiện API này trong tương lai!

Sửa đổi lần cuối vào 2025-05-01