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)

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:

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).

Tốc độ mạng nội bộ không cao. Chọn server ở Singapore nhưng khi download các gói Debian từ http://mirrors.service.networklayer.com/ thì tốc độ chỉ ~200 kB/s. Nếu chọn repo http://mirror.0x.sg thì tốc độ lên tới 3MB/s.

I'm building IoT gateway based on BeagleBone Black at the startup AgriConnect, with Python as the primary programming language.

When the application grows complex, the board shows to be weak. We cannot find stronger board than BeagleBone, so the only option is to try to make our app run lighter. We try to adopt latest Python version, now is 3.6, to take advantage of optimization work in them. The latest Debian image for BeagleBone is stretch (Debian 9), which doesn't include Python 3.6 in its repository.

There are some backport packages of Python 3.6 for Debian 9, but only for amd64 arch. Fortunately they provide a build script. I can use it to build for armhf arch, which is in BeagleBone boards.

How to build for armhf? The board is weak, we should not run the build process directly on BeagleBone. It can take some days!

Các nhà cung cấp chứng chỉ số miễn phí:

• Let's Encrypt
• StartSSL
• ZeroSSL

Sau khi upgrade Ubuntu cho server, mình đã không để ý là đồng hồ trên nó bị chạy sai, cho mãi tới hôm nay vào kiểm tra mới thấy.

Lí do là các bản Ubuntu cũ, khoảng 15.04 trở về trước, sử dụng ntpdate/ntpd để cập nhật giờ với Internet, nhưng Ubuntu mới, từ 15.10, khi bắt đầu ứng dụng systemd vào quản lý quá trình khởi động thì làm cho ntpd không còn chạy chính xác nũa. Với hệ thống mới này thì nên dùng systemd-timesyncd để cập nhật đồng hồ với Internet. Lệnh do-release-upgrade dùng để nâng cấp Ubuntu không tự động chuyển đổi từ ntpd sang systemd-timesyncd cho ta, nên ta phải tự thay đổi cấu hình lấy.

Sau đây là cách làm:

B1. Sửa đổi /etc/systemd/timesyncd.conf. Ban đầu nó chỉ có:

If you build website in Python, there is high chance that you use Jinja2 for template. If your favourite IDE is Komodo Edit, how to get syntax highlight support?

Currently, Komodo Edit doesn't support Jinja2, even there is a long standing request. Some people use Django highlighter for it but it does not work well.

But there is a template language with syntax very similar to Jinja2, which not many Python developer know, is supported by Komodo. It is Twig, a PHP one and used in Symfony, Drupal. Twig's syntax resembles Jinja2 more than Django, with "function call" style and macro:

Khi viết web app bằng các ngôn ngữ script như Python, Ruby, JavaScript (NodeJS) và triển khai lên server, ta hay được khuyên cho chạy web app của ta đằng sau Nginx, tức là Nginx sẽ đứng chắn giữa web app của ta và người truy cập. Mọi truy vấn web từ người dùng sẽ đi đến Nginx, và Nginx đóng vai trò của một reverse proxy, chuyển tiếp truy vấn đến web app.

Vậy Nginx làm công việc gì, ích lợi ra sao?

Giờ ta ví dụ với web app được viết bằng Django.

Giả sử ta không có Nginx, và để các request từ phía trình duyệt người dùng gửi đến thẳng web app. Ta biết rằng, phần lớn thời gian từ lúc trình duyệt gửi request đến lúc nhận được response là dành cho việc truyền tải nội dung, thời gian xử lý để sinh ra response chỉ chiếm một phần nhỏ. Giả sử web app chỉ phục vụ một request một lần, thời gian phục vụ mỗi request là 1s (bao gồm thời gian xử lý sinh ra nội dung 100ms và còn lại là thời gian truyền tải), thì trong 1 phút, web app chỉ phục vụ được 60 request. Chưa kể, khi ấy web app cũng phải phục vụ request những file tĩnh, như các file ảnh, JavaScript, CSS, vốn không phải là mục đích chính của web app. Web app là để sinh ra nội dung động. Nếu phải phục vụ cả các file tĩnh này thì số lượng phục vụ những request để nhận nội dung HTML bị rút gọn lại rất ít. Khi ta mở một trang web, thường request nội dung HTML là 1, trong khi request file tĩnh kể trên có thể là 10, và thường file tĩnh nặng hơn nội dung HTML động nên thời gian truyền tải cũng lớn hơn, có thể tới 2s. Như vậy, với cách cài đặt như trên, 1 phút web app chỉ phục vụ 3 - 6 khách. Nếu có 1 vài khách ở xa, hay đường truyền chậm, vì khách này cũng ngốn mất thời gian của web app. Số lượng phục vụ lại càng giảm.

Recently, I upgraded Nginx in this server and after some days, I discovered that one of my PHP websites (for internal use) was not working! It just returned completely blank page (no text or HTML source), even with the script containing only phpinfo().

At first, I didn't know that it was caused by Nginx, or it is because of upgrading Nginx. I tried to look in to various log files, from Nginx's to php5-fpm but did not see anything. I configured PHP to always display error, still no help. Searching around, I found that someones in Internet also get this phenomenon, after upgrading Nginx. Some suggests to change Nginx's virtual host configuration (the files in /etc/nginx/sites-available/). So I understand that new Nginx may bring changes that old configuration file will not be compatible!

But, then there is a question: How do I know how the configuration should be, to be working with upgraded Nginx?

Well, I've just noticed that Nginx installation on Ubuntu comes with some sample in snippets/ folder: