Ai dùng Linux thì cũng phải đụng vào shell, với hình thức đơn giản nhất là chạy một chương trình / lệnh nào đó từ Terminal. Khi làm việc với server không có giao diện đồ họa, mọi tác vụ quản lý phải thực hiện qua dòng lệnh thì cũng là lúc ta sử dụng shell ở mức độ nâng cao hơn. Ta sẽ cần viết một lệnh dài để thực hiện nhiều việc theo chuỗi, hoặc viết thành một file script với điếu kiện if else, với vòng lặp để thi hành nhiều tác vụ phức tạp. Tuy nhiên, thật tình mà nói thì các phần mềm shell phổ biến trên Linux như Bash, Zsh tôi đều không thích cú pháp của chúng, nên nếu cần viết lệnh dài, viết ra file script thì tôi sẽ chuyển qua viết script Python. Mọi việc thường là thế cho đến khi tôi bắt gặp Nushell...

Sau khi chạy thử vài dòng lệnh theo bài giới thiệu nhanh, tôi thấy Nu quyến rũ với tư tưởng khá mới mẻ, đó là thiết kế dữ liệu chảy qua các ống dẫn (pipe) là dữ liệu có cấu trúc, có các field, chứ không đơn giản là văn bản text như các shell truyền thống. Để hình dung được ý tưởng này, xét ví dụ sau, là chạy lệnh ls trong Nu:

❯ ls
╭───┬────────────────┬─────────┬─────────┬────────────────╮

Với hơn một nửa công việc hàng ngày là làm web, Python và JavaScript là hai ngôn ngữ mình dùng nhiều. Đây vốn là hai ngôn ngữ "kiểu động" (dynamic type), nhưng mình vẫn tận dụng hệ thống kiểu (type system) của chúng để viết như với một ngôn ngữ "kiểu tĩnh" (static type). Sau một thời gian thì mình rút ra được một số kinh nghiệm để làm việc với hai hệ này.

Thật ra, ngôn ngữ JavaScript không có ký hiệu kiểu, nên nói chính xác hơn là mình đang dùng TypeScript chứ không phải JavaScript. Trước hết, người đã làm quen với JavaScript mà được giới thiệu về TypeScript thì sẽ bật lên một câu hỏi, tại sao chúng là ngôn ngữ dynamic type thì lại mất công viết như static type làm gì. Đó là vì những ích lợi sau:

• Giúp các công cụ kiểm tra (static analysis) như MyPy, tsc hiểu được code mình, để phát hiện được bug tiềm tàng trong những trường hợp ngách mà mình chưa test.
• Giúp các trình soạn thảo (code editor, IDE) hiểu được biến đang có kiểu gì, để đưa ra gợi ý autocomplete đúng hơn.

Let's say you have a source code file on a remote machine (accessed via SSH) and you want to copy a portion of the content to your local machine. There are many ways to do this, but I want to present an effective way, as it will take advantage of Helix's very convenient block selection feature.

For example, in the following image, the window on the left is accessing a remote machine, via SSH, on which I am opening a source code file using Helix. The window on the right is an editor, e.g. Geany, of your local machine. I want to copy the source of the enable_mqtt_on_gsm_modem function to Geany. In the left window, we should use a slightly modern Terminal application, e.g. Kitty, WezTerm, Alacritty because of a feature that I will explain later.

On the source file, we'll move the cursor to any line inside the enable_mqtt_on_gsm_modem body, then press m. Helix will bring up a menu of m command, let's press a to select "Select around object". Helix then shows the menu of m a.

Giả sử bạn có một file source code trên máy ở xa (truy cập qua SSH) và bạn muốn sao chép một phần nội dung sang máy trước mặt. Có nhiều cách để làm, nhưng tôi muốn trình bày một cách hiệu quả, vì sẽ tận dụng tính năng chọn khối rất tiện lợi của Helix.

Ví dụ trong hình sau, cửa sổ bên trái là đang truy cập vào một máy ở xa, qua SSH, trên đó tôi đang mở một file source code bằng Helix. Cửa sổ bên phải là một trình soạn thảo, ví dụ Geany, của máy trước mặt. Tôi muốn sao chép source của hàm enable_mqtt_on_gsm_modem sang Geany. Cửa sổ bên trái, ta nên dùng một ứng dụng Terminal hiện đại một tí, ví dụ Kitty, WezTerm, Alacritty vì một tính năng mà tôi sẽ giải thích sau.

Bên file nguồn, ta sẽ di chuyển con trỏ đến bất cứ dòng nào phía trong thân hàm enable_mqtt_on_gsm_modem, sau đó nhấn m. Helix sẽ hiện ra menu của lệnh m, nhấn a để chọn "Select around object". Sau đó Helix lại hiện ra menu của "m a".

Trong quá trình phát triển phần mềm, ghi log là một hoạt động quan trọng phục vụ cho người lập trình. Khi một chương trình chạy không như mong muốn, ta cần phải biết sai chỗ nào để sửa. "Ghi log" là bắt chương trình của ta "kể lại" diễn biến hoạt động của nó, giá trị của một vài biến lúc ấy, để giúp ta kiểm tra lại được chỗ nào sai.

Vậy mình thường dùng thư viện nào cho việc ghi log?

Như đã đề cập trong bài "Khởi đầu dự án Python như thế nào để thuận tiện phát triển lên", Python có một thư viện chuẩn logging, mà điểm lợi là khi các thư viện cùng dùng nó, ta có thể từ tầng ứng dụng điều chỉnh "log level" cho tầng thư viện mà không cần can thiệp vào code của thư viện ấy. Vì lẽ đó, đương nhiên các ứng dụng của mình cũng dùng logging nhưng cũng kèm thêm một số thư viện bổ trợ khác để thỏa mãn nhu cầu / sở thích cá nhân.

Một trong những nhu cầu của mình là cần màu sắc phân biệt, để truy tìm điểm cần tìm cho dễ, ít nhất là các log level cần có màu sắc khác nhau để dễ dàng lọc lựa, bỏ qua thông điệp ít quan trọng. Về khoản màu sắc thì mình ưa dùng thư viện rich. Nó thậm chí còn hơn cả mong đợi vì nó còn nhận diện và tô màu theo "kiểu dữ liệu", ví dụ dữ liệu số có màu khác, dữ liệu chuỗi, đối tượng... có màu khác.

Trong giới lập trình, "oxy hóa" là một cách nói vui ám chỉ việc viết lại (một phần hoặc toàn bộ) một phần mềm bằng ngôn ngữ Rust, đây là một lối chơi chữ, vì "Rust" còn có nghĩa là "rỉ sét", một hiện tượng do sự oxy hóa gây nên. Gần đây mình cũng mạnh dạn oxy hóa một phần nền tảng IoT nông nghiệp của AgriConnect.

Động lực khiến mình viết lại nền tảng IoT của AgriConnect bằng Rust là để giảm tải hệ thống, tăng cường khả năng chịu áp lực trong tương lai. Phần mềm mình đang nói đến ở đây có tên mã là "Hạt Thóc". Nghe tên khiêm tốn, nhỏ bé thôi nhưng nó vận hành theo kiểu SaaS (Software as a Service), tức một phần mềm sẽ vận hành cùng lúc nhiều trang trại khách hàng. Mỗi khách hàng sẽ có một không gian riêng khi thao tác, quản lý trang trại của mình, thậm chí có tên miền riêng, nhưng thực ra tất cả đều đang được phục vụ bởi một chương trình trên server. Phần mềm này vốn được viết bằng ngôn ngữ Python, framework Django, được chia ra nhiều thành phần, mỗi thành phần chạy dưới dạng một process, một service riêng. Trong hoàn cảnh đặc thù của "Hạt Thóc" thì thì mình không "oxy hoá" theo kiểu, viết lại một vài hàm nào đó bằng Rust, biên dịch dưới dạng thư viện, rồi dùng Python import thư viện đó, mà viết lại toàn bộ thành phần con luôn. "Hạt Thóc" có ba thành phần chính:

• Collector: Giao tiếp để thu thập dữ liệu cảm biến, trạng thái bật tắt của các tải, và lưu vào database.
• ControlView: Cung cấp giao diện web để người dùng vào xem dữ liệu, cấu hình trang trại, đặt lịch, hay bật tắt tải bằng tay.
• ControlCenter: Chạy ngầm để phân tích lịch, dữ liệu cảm biến để ra lệnh bật, tắt tải, kiểm tra tình trạng bất thường và phát đi cảnh báo.

Recently I rebuilt this website, using Rust as backend programming language and EdgeDB as database. EdgeDB is great, but its Rust support is still weak comparing to other languages. One very important, but missing, feature is to support named parameters in query. Fortunately, there is already a base for the support in the future. In this post, we will exploit that minimum base to let our work done.

Current state

As the time of this writing, if you look into edgedb-tokio, the official Rust client library, documentation and example, you will see that it only supports using positional (numbered) parameters:

Gần đây, tôi chuyển đổi website này sang viết bằng Rust và rất tâm đắc với phong cách xử trí lỗi (error handling) của Rust, khi ứng dụng vào việc viết web. tôi sẽ trình bày tại sao.

Trước Rust, hầu hết các ngôn ngữ lập trình tôi kinh qua đều dùng phong cách xử trí lỗi là exception handling. Một hàm đang chạy nửa chừng, nếu gặp lỗi sẽ bắn ra một exception và dừng ngay tại đó. Hàm nào gọi nó bên ngoài sẽ dùng cấu trúc try ... except, try ... catch để phòng bị, bắt những exception này và có hướng xử trí tương ứng khi exception xảy ra. Cách làm này có ưu điểm là không cần nghĩ nhiều, giúp lập trình viên làm nhanh, cho ra sản phẩm lẹ. Tuy nhiên nó có nhược điểm là nhìn vào signature (mô tả kiểu dữ liệu đầu vào và đầu ra) của một hàm, không có cách nào biết được hàm đó có thể bắn ra những exception nào. Rust thì khác, những lỗi nào có thể xảy ra sẽ buộc phải khai báo trong signature của hàm. Ví dụ nhìn signature của hàm dùng để parse một chuỗi thành số nguyên:

fn from_str(src: &str) -> Result<i8, ParseIntError>

Hôm nay mình vừa triển khai phiên bản mới của website này. Nhìn giao diện thì không khác gì nhưng bên trong là đã làm mới hoàn toàn. Mới từ ngôn ngữ lập trình đến database.

Website này được mình viết lại bằng ngôn ngữ Rust và dùng database EdgeDB. Phiên bản cũ được viết bằng Python, dựa trên framework Flask, và database thì dùng PostgeSQL, được viết cũng khá lâu rồi (khoảng 10 năm), lại không được chăm sóc, cập nhật (trừ một đợt cập nhật lớn về frontend năm kia) nên bộ code rất cũ. Nhân việc mình đang có hứng luyện tay nghề về Rust nên mình quyết định dùng website này làm "bài tập". Về mặt frontend thì website này áp dụng cả hai kĩ thuật:

• Server side rendering: Dùng cho các trang bên ngoài, mà khách truy cập sẽ nhìn thấy. Với các trang này thì mình dùng MiniJinja để render dữ liệu ra HTML.

Có một người bạn mà mình từng ngồi nhiều cafe để bàn về những công nghệ mới để phục vụ cho dự án công ty. Một câu hỏi mà bạn hay đặt ra là dùng ngôn ngữ lập trình gì tiếp theo. Mình thì khá dày dạn về Python và đã từng xây dựng nền móng cho những dự án Python ở công ty bạn. Tuy nhiên, mình và bạn đều đồng ý là nên mở rộng phạm vi công nghệ để thích ứng với nhiều thể loại dự án khác nhau. Đi tham vấn nhiều nơi, được nghe khen ngợi về Go nên bạn rất muốn một lần được áp dụng Go trong cty của bạn. Còn mình thì, nếu đã chọn một ngôn ngữ biên dịch và phải bỏ thời gian cá nhân ra học thì mình thà chọn Rust hơn. Tất nhiên, ý thức được độ khó của Rust nên mình chả bao giờ muốn đem Rust vào công ty của bạn cả.

Trong khi lý do thường được nêu ra để chọn Go là cú pháp đơn giản, ít keyword, dễ học, thì với mình, độ khó của Rust là thứ đáng để đầu tư. Thà chịu khó ban đầu nhưng gặt hái kết quả tốt về sau. Ngoài ra, điều khiến mình ưu ái Rust hơn Go là ở chỗ Rust không có garbage collector, không có runtime riêng, nên có thể dùng Rust để viết thư viện tầng dưới, phục vụ cho Python và các ngôn ngữ khác được, chưa kể, việc được thiết kế tốt và không có bộ runtime khiến Rust là ngôn ngữ duy nhất (ngoài C) khiến tác giả của Linux muốn thấy nó được ứng dụng vào nhân Linux. Lý do viết thư viện đã được mình hiện thực hóa, bằng một sản phẩm cá nhân là Defity, thư viện dành cho Python và dùng để nhận dạng loại file.

Hoàn cảnh ra đời