Trong công ty chúng tôi, hai dự án đang sử dụng Git để quản lý client, trong khi ba dự án còn lại vẫn dùng SVN. Các lập trình viên thường ưa chuộng Git, nhưng tại sao SVN vẫn tồn tại? Vấn đề chính nằm ở chỗ: trong quá trình phát triển client, đội ngũ thiết kế và mỹ thuật luôn gặp trở ngại trong việc tiếp cận Git. Ngay cả những dự án đã chuyển sang Git, các nhà thiết kế vẫn phản ánh rằng Git dễ gây ra lỗi hơn SVN và họ thường xuyên gặp phải các vấn đề không tự giải quyết được.

Dự án MMORPG của công ty chúng tôi gần đây đã gặp phải vấn đề nghiêm trọng về giới hạn bộ nhớ. Trong cuộc họp ngày hôm qua, chúng tôi đã thảo luận về hướng giải quyết. Tôi xin chia sẻ lại phương án cải tiến đã đề xuất thông qua bài viết này.

Vấn đề cụ thể như sau: Trên các thiết bị di động và máy tính bảng hiện nay, hệ điều hành chỉ dành cho ứng dụng khoảng 500MB bộ nhớ khả dụng. Khác với môi trường PC, thiết bị di động sử dụng cơ chế phân vùng hoán đổi (swap partition) để xử lý các nhu cầu bộ nhớ đột biến tạm thời. Tuy nhiên, thiết bị phải đảm bảo hoạt động của các dịch vụ hệ thống (các tiến trình nền ưu tiên cao), do đó khi xảy ra các tác vụ bất ngờ như nhận cuộc gọi, nhận thông báo đẩy… hệ thống có thể chiếm dụng thêm bộ nhớ, dẫn đến việc buộc dừng ứng dụng đang chạy để giải phóng tài nguyên.

Lại một bài blog nữa về chủ đề trình gỡ lỗi Lua ư? Đúng vậy! Nhưng lần này không phải sản phẩm tự phát triển như trước nữa :)

Hồi cuối năm ngoái mình từng chia sẻ cách xây dựng bộ gỡ lỗi Lua “sang chảnh” trong bài viết: “Làm thế nào để tạo một trình debug Lua hoàn hảo?”. Như mình đã viết: “Dĩ nhiên kỳ vọng nó trở thành một công cụ gỡ lỗi đồ họa đẹp mắt trong thời gian ngắn là điều khó khả thi, trừ khi có sự tham gia của các chuyên gia front-end.”

Một vài cập nhật mới nhất của sproto

Sproto là một giao thức định dạng dữ liệu mà tôi thiết kế với ý tưởng tương tự như Google Protocol Buffers. Trải qua nhiều năm sử dụng Protocol Buffers trong các dự án của mình, tôi dần nhận ra một thực tế thú vị: công cụ này được thiết kế chủ yếu cho các ngôn ngữ biên dịch tĩnh và không thực sự phù hợp với tính linh hoạt của các ngôn ngữ động. Điều đó khiến nó không được ưa chuộng như JSON trong môi trường ngôn ngữ động.

Sau gần 8 tháng kể từ ngày phát hành chính thức phiên bản 1.0 vào ngày 1 tháng 8 năm 2016, hệ thống Skynet đã không ngừng được cải tiến với hàng loạt cập nhật nhỏ tích lũy qua thời gian. Đến thời điểm hiện tại, chúng tôi nhận thấy đây chính là lúc thích hợp để chuẩn bị cho phiên bản nâng cấp 1.1.

Đáng ghi nhận là cộng đồng Skynet ngày càng phát triển mạnh mẽ hơn, với sự gia nhập của nhiều doanh nghiệp mới lựa chọn nền tảng này làm cơ sở cho các hệ thống phát triển của họ. Chúng tôi xin gửi lời cảm ơn sâu sắc đến toàn thể cộng đồng đã ủng hộ và đóng góp cho sự phát triển của Skynet trong suốt thời gian qua.

Trong thiết kế ban đầu của skynet, mục tiêu là xây dựng một hệ thống phân tán có khả năng xóa nhòa ranh giới giữa các actor chạy trên cùng một máy và các actor ở hai đầu mạng. Để đạt được điều này, mô hình master/slave đã được thiết kế. Bằng cách sử dụng 4 byte để biểu diễn địa chỉ actor, trong đó 8 bit cao là mã nút và 24 bit thấp là ID nội bộ của tiến trình. Nhờ đó, mỗi actor (được gọi là dịch vụ trong skynet) đều có địa chỉ duy nhất trong toàn hệ thống, bất kể nó nằm trong tiến trình nào. Khi gửi tin nhắn, người dùng không cần quan tâm đích đến là trong cùng tiến trình hay phải qua mạng.