Có một bận, tôi ôm trong tay một bộ CSDL của website nọ, với nhiều thông tin danh tính người thật. Để tránh cho dữ liệu danh tính bị lộ, hưởng ứng tinh thần của Luật An Ninh Mạng, tôi quyết định phải làm xáo trộn dữ liệu đó để nó không còn phản ánh danh tính thật nữa. Cụ thể là tôi sẽ ghi thêm vài kí tự bừa bãi vào cột email, cho nó thành email "xạo" hết.

Nói tới nhu cầu này thì cách dễ nhất là viết đoạn code cho nó chạy một vòng lặp, lặp qua các dòng của bảng dữ liệu, tại mỗi dòng lấy ra cột email, ghi nội dung mới vào rồi lưu lại. Cách đó dễ, nhưng hơi cơ bắp, không tinh tế, sẽ chậm khi bảng dữ liệu hơi lớn. Tôi quyết định thử phương án tạo hàm tùy thêm cho hệ CSDL đó, để có thể sửa tất cả trong một câu truy vấn (query) duy nhất, ví dụ:

UPDATE web_users SET email = my_func(email)

Trong quá trình phát triển ứng dụng cho hệ thống nhúng, do sự hạn chế của thiết bị, đôi khi có những việc lắt nhắt làm tốn mớ thời gian. Sau đây mình liệt kê một số mẹo để đi tắt, giúp tiết kiệm thời gian cho công việc. Các hướng dẫn này chỉ dành cho hệ điều hành Linux (như Ubuntu).

1. Chia sẻ Internet từ laptop cho máy tính nhúng

Đây là tình huống mà bạn đang phát triển ứng dụng cho máy tính mini (NUC, Raspberry Pi, Beagle Bone...) và chủ yếu dùng mạng dây (chưa setup wifi hoặc máy đó không có card wifi). Đôi lúc bạn cần phải xách nó đi đâu đó (để trình diễn demo, để cài đặt lại chẳng hạn) mà chỗ đó không có router để cấp mạng, bạn có thể chia sẻ Internet từ laptop (laptop đang kết nối Internet qua wifi) cho nó. Để cho ngắn gọn, mình sẽ gọi máy tính nhúng là RPi trong bài này.

Nguyên lý của việc này là biến laptop của bạn thành một thiết bị router mạng đơn sơ, tạo một mạng con với RPi, do laptop của bạn quản lý.

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:

Năm 2020 quả là một năm với nhiều biến động lớn, quy mô rung chuyển toàn cầu, tiêu điểm là dịch cúm CoVid-19 khiến nhiều cường quốc mất mặt và một nước "ít quan trọng" như Việt Nam trở thành điểm sáng. Hòa chung xu thế đó mình cũng tung ra một phần mềm "Made in Viet Nam" nhưng hướng đến người dùng quốc tế. Chém thế thôi chứ nó thật ra xuất phát từ nhu cầu cá nhân.

CoBang là phần mềm quét mã QR dành cho desktop Linux. Mã QR đang ngày càng phổ biến, nó là phương tiện để trao đổi thông tin khó viết và khó nhớ. Một trong những hoàn cảnh mình bị buộc phải đụng đến mã QR là khi mình cần kết nối vào một mạng wifi nhưng không biết password. Thông tin wifi đó thì có lưu trong điện thoại nhưng điện thoại không cho xem password (một quan điểm kì cục của những người thiết kế HĐH điện thoại ban đầu). May thay hồi đó mình dùng điện thoại Xiaomi và nó nó chức năng chia sẻ thông tin wifi qua mã QR. Trong khi những phần mềm quét mã QR có ra rả trên Android thì trên Linux lại rất hiếm. Lí do của sự hiếm này là khi nói đến "quét mã QR", người ta chỉ hình dung đến việc cầm điện thoại lên soi thôi. Hồi đó trên laptop mình dùng QtQR nhưng khá cùi và có bug. Điều đó làm nảy sinh nhu cầu bức thiết là phải tạo một phần mềm mới. Dù nhu cầu là có nhưng vì có nhiều công việc gấp hơn nên mình đành trì hoãn đến năm nay mới bắt tay vào làm, nhân dịp muốn tìm một luồng gió mới thay cho công việc làm web hàng ngày.

Do cũng khá am hiểu những lớp công nghệ bên dưới desktop Linux nên mình dễ dàng hình dung được việc cần dùng những thư viện, công nghệ gì bên dưới và liên kết chúng ra sao. Thành tố quan trọng nhất là GStreamer, một thư viện/framework xuất sắc của thế giới Linux. Nó giúp hiện thực hóa ý tưởng của mình về cách luồng media vận hành ra sao: Sau khi lấy nguồn video liên tục từ webcam thì dòng video sẽ được chia làm 2 nhánh, một nhánh cho hiển thị lên cửa sổ giao diện, nhánh kia thì cho tách ra từng frame, lấy ảnh, và cho vào thư viện ZBar để soi tìm mã QR. Về giao diện đồ họa thì mình đi ngược với hot trend "cross-platform" để gắn bó với GTK, một thư viện native trên Linux.

Dù tình hình dịch bệnh CoVid-19 căng thẳng, mình vẫn ráo riết thực hiện ý tưởng quảng bá dữ liệu mở riêng biệt của Việt Nam và đóng góp vào kho thư viện Python, mong muốn biến Python trở thành ngôn ngữ thân thiện nhất với vấn đề bản địa Việt Nam 🇻🇳

Một thư viện mình đã xuất bản gần đây là VietnamProvinces, cung cấp danh sách tỉnh thành, quận huyện, phường xã Việt Nam cùng mã số.

Lý do ra đời thư viện này là vì mình thấy nhiều công ty ở VN có nhu cầu lưu dữ liệu nghiệp vụ kinh doanh kèm thông tin địa chỉ, và để có thể lọc dữ liệu, xuất báo cáo chính xác thì các quận huyện phải phân loại dưới dạng mã số. Tuy nhiên, có thực tế là mỗi cty có một bảng mã riêng, gây khó khăn cho việc trao đổi dữ liệu qua lại giữa các cty đối tác.

Python là ngôn ngữ chính cho hệ thống backend của AgriConnect. Với đội ngũ giàu kinh nghiệm về Python, luôn đẩy sự khai thác, "bóc lột" Python đến mức cao nữa, cao nữa, nên quá trình vận hành của AgriConnect thường dẫn đến những nhu cầu "không giống ai". Một trong số đó là nhu cầu dựng một kho chứa gói thư viện Python "tại nhà". Bài dưới đây xin chia sẻ kinh nghiệm như thế.

Khi hệ thống của AgriConnect vận hành, tác vụ cài đặt các gói thư viện Python được thực hiện lặp đi lặp lại rất nhiều lần. Chúng đến từ:

• Hệ thống chạy test tự động, kích hoạt mỗi khi có code mới được đẩy lên Git.

• Việc deploy bản cập nhật đến các server nội bộ đặt rải rác ở các trang trại khách hàng.

Thỉnh thoảng tôi bắt gặp câu hỏi "Làm thế nào để lấy ảnh chụp của IP Camera bằng code Python". Hầu hết câu trả lời, của cả Tây lẫn Việt, đều là kêu người ta dùng OpenCV.

Quan điểm của tôi là, OpenCV tốt đấy, nhưng nếu chỉ để lấy ảnh chụp của camera thôi mà dùng OpenCV thì chuối quá. Thứ nhất, OpenCV là thư viện dành cho computer vision, nên nếu không khai thác gì đến tính năng đó mà ôm OpenCV vào thì nặng nề, dư thừa không cần thiết. Đằng nào thì tự OpenCV cũng không có khả năng xử lý giao thức RTSP mà nó phải gọi đến FFmpeg , nên để cho gọn ghẽ, tốt hơn là dùng thẳng FFmpeg để bắt hình camera đi. Thứ hai, tệ hơn nữa, mặc dù OpenCV sử dụng FFmpeg bên dưới, nó cũng không khai thác FFmpeg đúng cách nên có nhiều IP Camera cũng truyền video qua giao thức RTSP mà nó không lấy được. Lí do là RTSP có thể truyền trên TCP hoặc UDP, nhưng OpenCV được hardcode để gọi FFmpeg với chỉ mỗi TCP, thành ra nếu IP Camera truyền với "RTSP over UDP" thì OpenCV không lấy được.

Vậy giải pháp là gì?

Django và Flask là hai cái tên được nhắc đến nhiếu nhất khi nói về web framework của Python, đặc biệt là giữa những người mới bước chân vào thế giới Python. "Dùng Flask hay Django?" cũng là câu hỏi mà tôi hay nghe đi nghe lại trên các diễn đàn trao đổi, hỏi bài. Với kinh nghiệm về 2 thứ này, tôi viết một bài ngắn gọn, mong trả lời trước cho những ai mới chập chững bị "rắn cắn" này.

Image credit: coderseye.com

Về Flask, tôi đã 3 lần sử dụng Flask cho phần mềm của mình. Lần sử dụng đầu tiên, khoảng năm 2013, tôi làm cho một tay nghiên cứu sinh về Big Data, khi anh chàng này viết một phần mềm xử lý dữ liệu lớn (Java + Hadoop) và cần một trang web để làm giao diện điều khiển cho việc chọn dữ liệu nguồn và lấy kết quả về sau khi xử lý. Lần tiếp theo, tôi viết server phân quyền cho cổng login của mạng wifi (có các tên gọi khác là Splash page, Captive Portal, Wifi Marketing), và sản phẩm cuối cùng tôi dùng Flask là để tạo trang blog này (viết lai rai từ 2013 đến nay).

When creating tool for system administration tasks, we often have the need to execute some other command-line programs, execute some commands on remote machine, transferring data between local and remote machine via SSH. A straightforward thinking will be to implement the tool in shell. But what if you, like me, hate the syntax of shell and be happier with Python? And especially when you want to challenge yourself with the new (somehow) cool asyncio?

To have a clear picture, let's give an example that you want to implement a command like this:

ssh remote-server "pg_dump -O webdata | gzip" | gunzip | psql localdb

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.