Bài viết được sự cho phép của tác giả Nguyễn Hồng Quân

Khi tôi bắt đầu bước chân vào mảng IoT đầu năm 2016, tôi bắt đầu lân la tiếp xúc với cộng đồng làm IoT Việt Nam (trên Facebook là chính). Ở Việt Nam, lực lượng tech làm IoT đa phần là dân điện tử đi lên, thế nên tôi hay gặp những câu hỏi như “nên dùng ngôn ngữ nào để lập trình nhúng” từ những bạn sinh viên mới. Tôi cũng ngạc nhiên khi thấy các bạn kháo nhau dùng NodeJS, theo phong trào.

Nếu cần dùng các ngôn ngữ biên dịch như C++, Go thì không nói. Nhưng nếu dùng ngôn ngữ thông dịch thì Python nên được dùng hơn NodeJS/JavaScript. Một khía cạnh nên tính đến là độ lớn file cần lưu trữ. Các board máy tính nhúng chạy Linux thường dùng thẻ nhớ, hoặc bộ nhớ flash trong (còn có cách gọi khác là NAND Flash, SPI Flash, eMMC) để thay thế ổ cứng (HDD) nên có dung lượng khiêm tốn. Nếu cách lưu trữ không phù hợp, có khi thư viện đã ngốn hết không gian lưu trữ đáng lẽ phải dành cho chương trình và dữ liệu (data).

Thứ nhất, cách quản lý các gói thư viện phụ thuộc của NodeJS cực kỳ tốn dung lượng, với sự trùng lắp các file thư viện.

Hình bên trên là ví dụ về cách lưu trữ thư viện khi cài bằng yarn. Tình hình còn tệ hơn nếu cài bằng npm, vốn có truyền thống không thèm phân giải mối ràng buộc phiên bản (dependency version resolve) mà cứ lồng các gói phụ thuộc vào nhau, dẫn đến câu châm biếm sau:

Ghi chú: Có vẻ, gần đây, sau khi nhận nhiều châm biếm thì npm đang cải thiện vụ quản lý thư viện này.

Xem thêm các việc làm Python hấp dẫn tại TopDev

Thứ hai, NodeJS không hỗ trợ phân phối gói thư viện ở dạng binary. Đối với cả Python và NodeJS, có nhiều thư viện được viết bằng C/C++. Khi cài đặt những thư viện này thì phải có bước biên dịch mã nguồn C/C++ đó thành file binary (*.so hay *.dll). Nếu ngôn ngữ đó không có quy chuẩn về phân phối thư viện biên dịch trước ở dạng binary, thì trình quản lý gói, sẽ phải download source code và tiến hành biên dịch ngay trên máy người dùng cuối. Và để làm việc đó thì máy người dùng cuối phải cài trước trình biên dịch, code generator (như Swig), các source code của thư viện C/C++ mà gói thư viện Python/NodeJS kia phụ thuộc vào. Như vậy là dung lượng khiêm tốn của máy tính nhúng lại phải dành chỗ cho những thứ nặng nề này.

Python giúp cắt bỏ những thứ nặng nề kia bằng cách định ra một phương pháp đóng gói và phân phối qua file wheel, trong đó các thư viện viết bằng C/C++ sẽ được biên dịch trước, file nhị phân thành phẩm (cùng các file metadata phụ trợ) sẽ được đóng gói và xuất bản trên kênh phân phối chính thức của Python (https://pypi.org/). Khi cài đặt trên máy người dùng cuối thì pip (trình quản lý gói của Python) chỉ việc download file đã dịch này, không phải download bộ source code C/C++, người dùng cũng không phải cài trình biên dịch và mớ mã nguồn. Vừa tiết kiệm không gian lưu trữ, vừa tiết kiệm thời gian biên dịch. Đặc biệt, vì các máy tính nhúng dùng CPU ARM, hơi yếu nên thời gian biên dịch cực kỳ lâu. Nếu bạn triển khai cho nhiều khách hàng, tức là phải cài phần mềm trên nhiều board, thì thời gian tiêu phí cho quá trình biên dịch càng lớn.

Ghi chú: Có một vài thư viện NodeJS cũng thấy nỗi nhức nhối này và họ đã workaround, bằng cách phân phối một script “installer” chứ không phân phối bản thân thư viện. Khi người dùng cài gói, script này sẽ chạy và download file binary biên dịch sẵn từ website của tác giả thư viện về. Nguồn download là website của tác giả chứ không phải kho chính thức của NodeJS (https://www.npmjs.com/).

Tham khảo tuyển dụng python Hà Nội lương cao trên TopDev

Gần đây, khi tham gia vào dự án SUSI.AI Smart Speaker, một nhiệm vụ của tôi là giảm tổng dung lượng của phần mềm trên Raspberry Pi. Tổng dung lượng ở đây là tính tất cả những thứ phải cài đặt trên Raspperry Pi (bao gồm cả hệ điều hành). Trước khi tôi tham gia, dự án đã có một script install.sh để tiến hành cài tự động các phần mềm cần thiết, cho phép người mới vào dự án có thể bắt tay lập trình luôn. Có điều, do thiếu người mạnh dẫn dắt từ đầu nên dự án trở nên lộn xộn, ngay cả file install.sh cũng không chạy thành công. Trước khi file install.sh đó được sửa (mà người phụ trách là tôi) thì một bạn thành viên đề xuất sẽ copy thẻ nhớ (chạy Raspberry Pi) của anh ta ra một file image. Tất cả những thành viên mới chỉ việc nạp image đó vô thẻ nhớ của mình rồi bắt đầu công việc. Thế nhưng, khi copy ra xong thì file đó nặng tới 16GB! Cho dù có nén kiểu gì thì dung lượng đó quá lớn một cách lố bịch. Đóng góp vào con số khủng khiếp đó là một đống những phần mềm công cụ, mã nguồn thư viện. Dó có liên quan đến AI nên phải dùng đến một số thư viện tính toán đại số, và ở dạng mã nguồn thì nó rất lớn. Chưa kể, thành viên đó lại không thạo Linux, nên dùng một công cụ Windows để tạo image thẻ nhớ, khiến không có một phương pháp tạo image tối ưu (đục bỏ phần dữ liệu rơi rớt của những file đã xóa). Đây cũng là một trong các lí do mà tôi luôn khuyên các bạn làm IoT, lập trình nhúng phải chuyển sang Linux. Sau vài tháng miệt mài sửa file install.sh, chuyển các thư viện sang dạng đóng gói binary, thậm chí đóng góp code vào cho một thư viện bên thứ ba, viết script để build hệ điều hành một cách tự động (khi chúng tôi cập nhật code mới) thì dung lượng image đã giảm đáng kể, nay còn 781MB sau khi nén.

Ngoài ra, trong quá trình làm việc tại AgriConnect, FOSSASIA thì tôi cũng build trước một số ứng dụng và thư viện thành dạng binary cho ARM, để tiết kiệm thời gian cài đặt, triển khai trên BeagleBone, Raspberry Pi. Các kho này là public nên ai có nhu cầu tương tự cũng có thể tận dụng: https://repo.fury.io/agriconnect, https://repo.fury.io/fossasia.

Bài viết gốc được đăng tải tại quan.hoabinh.vn

Xem thêm các bài viết liên quan:

Tuple Python là gì? Tìm hiểu về tuple python

Hướng dẫn từng bước lập trình web với Python

Chuyển đổi Unicode dựng sẵn & tổ hợp với Python

Tìm việc làm lập trình mới nhất trên TopDev

Bài viết được sự cho phép của tác giả Nguyễn Hồng Quân

Dạo này các ứng dụng với dữ liệu tiếng Việt đang ngày một nhiều, trong đó vấn đề sai khác giữa Unicode dựng sẵn và tổ hợp, tuy nhỏ, nhưng cũng gây mất chút kha khá thời gian debug cho những người mới vào nghề. Mình chia sẻ xíu kinh nghiệm này, để việc phát triển ứng dụng tiếng Việt trở nên trơn tru hơn, và cũng để “khoe hàng” về hệ sinh thái giàu mạnh của Python.

Tưởng tượng một tình huống sau. Ứng dụng của bạn cho người dùng nhập vào một chuỗi tiếng Việt, khi nhận được chuỗi, phần mềm sẽ dò trong cơ sở dữ liệu để chọn ra bản ghi nào ăn khớp với chuỗi đó. Cơ sở dữ liệu này được một người khác nhập liệu. Bạn đã chắc chắn rằng chuỗi đó có tồn tại trong cơ sở dữ liệu, nhưng không hiểu sao phần mềm so sánh, dò tìm không ra. Hóa ra là người nhập liệu, khi gõ chuỗi vào thì dùng Unicode tổ hợp (decomposed), trong khi người dùng lúc nhập chuỗi tìm kiếm vào thì dùng Unicode dựng sẵn (composed). Dưới dạng chuỗi byte thì hai chuỗi này không giống nhau, nên bằng biện pháp so sánh chuỗi unicode thông thường, phần mềm sẽ không nhận ra.

Lấy ví dụ một chuỗi sau, “Tiếng Việt bão táp”, nếu là Unicode dựng sẵn, khi thể hiện dưới dạng chuỗi byte, dàn theo bảng mã UTF-8, thì là chuỗi byte này:

b'Ti\xe1\xba\xbfng Vi\xe1\xbb\x87t b\xc3\xa3o t\xc3\xa1p'

Trong khi nếu là Unicode tổ hợp, khi thể hiện ở dạng chuỗi byte UTF-8, thì sẽ thành:

b'Tie\xcc\x82\xcc\x81ng Vie\xcc\xa3\xcc\x82t ba\xcc\x83o ta\xcc\x81p'

Vậy muốn so sánh hai chuỗi, phải đưa chúng về cùng một kiểu Unicode trước. Cách làm ra sao?

Trên mạng có lưu truyền một cách thô thiển là tạo một bảng đối chiếu, chuyển đổi từng chữ cái một, như ví dụ này.

Đây rõ ràng là một phương án “vai u thịt bắp”. Có một giải pháp đơn giản hơn nhiều. Trong thư viện chuẩn của Python, có module unicodedata đã có sẵn chức năng này. Ví dụ:

>>> import unicodedata

>>> to_hop = 'Tiếng Việt bão táp'                                               

>>> dung_san = unicodedata.normalize('NFC', to_hop)

>>> to_hop.encode()
b'Tie\xcc\x82\xcc\x81ng Vie\xcc\xa3\xcc\x82t ba\xcc\x83o ta\xcc\x81p'


>>> dung_san.encode()
b'Ti\xe1\xba\xbfng Vi\xe1\xbb\x87t b\xc3\xa3o t\xc3\xa1p'

Như vậy, bí quyết là dùng hàm unicodedata.normalize(), truyền vào tham trị “NFC” nếu muốn chuyển đổi thành dựng sẵn, truyền vào “NFD” nếu muốn chuyển đổi thành tổ hợp. Mẹo nhớ: Chữ “C” trong “NFC” nghĩa là “composed”, tức là “Unicode dựng sẵn”.

Thông tin sâu thêm một chút về kĩ thuật. Lấy ví dụ chữ “ế”, nếu ở kiểu “dựng sẵn” thì chữ này sẽ được dành riêng một vị trí (U+1EBF) trong bảng Unicode luôn, trong khi nếu ở kiểu “tổ hợp” thì các dấu thanh sẽ được tách ra (decomposed), đại diện bằng các ô khác trong bảng Unicode.

Để phát triển giải pháp này lên một bước nữa, ta sẽ làm cho việc chuyển đổi này xảy ra một cách tự động, vô hình trong phần mềm. Quay về tình huống kể trên, đó là tình huống trong một dự án cũ mà tôi tham gia. Tôi đã làm thêm một lớp validation để làm sạch dữ liệu đầu vào, ở cả hai khâu: khâu nhập liệu và khâu người dùng tìm kiếm, chuyển đổi chúng về Unicode dựng sẵn hết. Với mục đích kiểm tra sự hợp lệ (validate) dữ liệu ở các dự án Python thì tôi thường chọn thư viện Pydantic. Công dụng của nó là: kiểm tra sự hợp lệ dữ liệu đầu vào, nếu không hợp lệ thì hoặc là báo lỗi, hoặc là tự gò nắn cho đúng rồi nhận vào. Công dụng này tương tự như Django form.

Lấy ví dụ, ứng dụng của ta cần tiếp nhận dữ liệu bên ngoài truyền vào với cấu trúc như sau:

class Person:
    name: str
    age: int

và dữ liệu truyền vào có thể là một chuỗi JSON:

{"name": "Ếch Xanh", "age": 11}

Ta luôn cần bước kiểm tra hợp lệ, vì không thể đảm bảo lúc nào dữ liệu truyền vào cũng đúng ý, nó có thể thiếu một vài field, chuỗi dư kí tự lạ, hoặc không đúng kiểu dữ liệu (cần integer nhưng lại truyền vào string):

{"name": "Mèo Đen   ", "age": "09"}

Khi dùng Pydantic thì tôi sẽ implement cấu trúc trên như sau:

from pydantic import BaseModel                                              

class Person(BaseModel):
    name: str 
    age: int 

Dùng thử:

>>> Person.parse_obj({"name": "Mèo Đen   ", "age": "09"})                       
Person(name='Mèo Đen   ', age=9)

Để đảm bảo dữ liệu của field “name” sẽ được tự động chuyển đổi thành Unicode dựng sẵn, tôi sẽ định nghĩa một kiểu field mới cho Pydantic:

from pydantic import ConstrainedStr


class VinaStr(ConstrainedStr):
    '''
    A constrained string type which automatically normalizes Vietnamese Unicode string.

    It converts from decomposed ("tổ hợp") to composed ("dựng sẵn") Unicode.
    '''
    strip_whitespace = True

    @classmethod
    def validate(cls, value: str):
        cleaned = super().validate(value)
        if cleaned:
            return unicodedata.normalize('NFC', cleaned)
        return cleaned

Áp dụng vào class Person bên trên:

class Person(BaseModel):
    name: VinaStr
    age: int

Thử lại với dữ liệu hơi không sạch:

>>> p = Person.parse_obj({'name': ' Hoẵng Con ', 'age': '04'})

>>> p
Person(name='Hoẵng Con', age=4)

>>> p.name.encode()
b'Ho\xe1\xba\xb5ng Con'

Có thể thấy rằng ở field name, chuỗi đầu vào vừa được xóa sạch kí tự khoảng trắng dư, vừa được chuyển đổi Unicode, và field age thì chuỗi được biến thành số nguyên.

Xem lại code từ đầu với hình động cho đỡ chán:

Như vậy tôi đã trình bày xong cách chuyển đổi Unicode tổ hợp dựng sẵn trong Python, tặng kèm bí quyết về xử lý dữ liệu nói chung trong công việc. Mong rằng cộng đồng lập trình viên Việt Nam sẽ áp dụng các thói quen thực hành tốt để nâng cao chất lượng sản phẩm hơn nữa.

Đừng quên theo dõi TopDev để cập nhật các việc làm Python mới nhất nhé!

Bài viết gốc được đăng tải tại quan.hoabinh.vn

Xem thêm:

Python Là Gì? Các Bước Tự Học Lập Trình Python

Lộ trình từng bước trở thành Machine Learning Engineer

Lập Trình với Game Flappybird Python