After my last post "How to install a LSP server that supports Django" was shared, I got feedback that some fellows tried to install the LSP, but didn't get the autocomplete working as shown in my screenshot. So I continue with this article.

People often miss the detail that the core power of an LSP server comes from the static type checker (or the compiler in case of compiled languages). When you write window. then hit the Tab key, the LSP server starts to suggest the attributes of the window object. But it can only know which attributes the window object has, if the type of the window variable is inferred successfully and correctly. The later job is done by static type checker, or concretely, Mypy.

So, for a Django project, how do you set up Mypy so type inference works? Basically, it's just like adding Mypy for type checking, but with more honesty. I use the word "honesty" because some projects added Mypy but the team members try to get the green "passed" status by making Mypy skip the type checking, ignoring the errors instead of really fixing them.

Before, when developing Django-based projects, I often use VS Code. Because VS Code is getting heavier and heavier (the installation is 1 GiB now), I need to move away from it. But the first thing is to find an independent LSP server that works well enough with Django. VS Code comes with Pylance, its LSP server for Python. But Pylance is proprietary, so for another code editor, I need a different solution.

When we do programming, LSP servers are great tools. They help improve productivity by enabling accurate autocomplete in code editors, allowing us to code faster and make less mistakes. They work best with languages having a strong type system (Rust and functional programming languages, like Gleam), because the type system lets us know, at any point, which type a variable has and what members it contains. For dynamic type languages, LSP servers are often based on static type checkers (because both need to draw type information from the source code). For Python, the situation is a bit hard, because Python is so dynamic and flexible that, its type annotations cannot cover all the cases to help type checkers and LSP servers infer the type of variables. It is especially true for Django. At the time of writing, Mypy is the type checker that supports Django the best. It means that, on the LSP server side, we need one that can take advantage of Mypy. Currently, there are many type checkers + LSP servers for Python, most of which are not written in Python:

• Pyright: Written in TypeScript.

I'm a slow typist, so when programming I really need the autocomplete feature, to avoid typing a lot and making typos. When applying AI to my work, a major limitation is that the prompt input box of agent software lacks an autocomplete feature. That means when I want the assistant to fix this function or that function, I have to type out the full function or variable names, or copy them from elsewhere, instead of just typing the first 2-3 characters and pressing Tab as I do when working purely in a code editor. That's why I've always looked for a way to bring the code editor into my AI agent workflow, leveraging the editor's advantages, and I've found a workable approach.

Before discussing this method, I should reveal that the autocomplete need has already been partially solved by some command-line agents. For example, in Crush, Crush lets you call an external text editor to enter the prompt (with the shortcut Ctrl + o):

Then I just need to configure the code editor as Helix to leverage its autocomplete of previously typed words, saving typing effort. In this case, Helix is detached from the project's source code context, so it can only suggest previously typed words, not functions or variables in the source code.

Mình là người gõ chữ chậm nên khi lập trình, mình rất cần tính năng autocomplete, để khỏi phải gõ nhiều và gõ nhầm. Khi áp dụng AI vào công việc, có một hạn chế lớn là khung nhập prompt của các phần mềm agent không có tính năng autocomplete. Nghĩa là khi mình muốn trợ lý sửa hàm này hàm kia, mình phải gõ đầy đủ tên hàm tên biến, hoặc copy chúng từ bên ngoài vào, thay vì chỉ cần gõ 2-3 chữ đầu rồi bấm Tab như cách làm việc thuần tuý trên code editor. Vì vậy mình vẫn luôn tìm cách để có thể lôi được code editor vào quy trình làm việc với agent AI, tận dụng lợi thế của code editor và đã tìm được phương án tạm ổn.

Trước khi bàn đến phương pháp này thì cũng xin hé lộ là nhu cầu autocomplete cũng đã được giải quyết phần nào với một số agent ở chế độ dòng lệnh. Ví dụ trên Crush, Crush cho phép gọi text editor bên ngoài để nhập prompt (với phím tắt Ctrl + o):

Khi đó mình chỉ cần cấu hình chọn code editor là Helix để tận dụng tính năng autocomplete một từ đã nhập trước đó để đỡ công gõ. Trong trường hợp này thì Helix bị tách ra khỏi ngữ cảnh source code của dự án nên nó chỉ gợi ý được từ đã nhập chứ không gợi ý được hàm biến trong source code.

Mình thích Nushell nên cũng mong muốn trợ lý AI viết script shell bằng Nu, và gắn Nushell vào agent Crush dưới dạng MCP server để "nhắc khéo". Trong một lần cập nhật Crush gần đây thì tự dưng nó không khởi chạy Nushell MCP lên được nữa, nhưng chỉ bị trục trặc với phương vận stdio, do bất đồng giữa Crush và Nushell khi bắt tay, còn http thì vẫn bình thường. Thế là mình chuyển sang dùng Nushell MCP ở giao thức http và khám phá ra nó tối ưu hơn ở một chuyện: Có thể cài đặt để chỉ cần chạy một tiến trình Nushell MCP server và cho tất cả agent kết nối vào MCP chung này, thay vì mỗi agent khởi chạy một process MCP server như khi dùng stdio.

Khi dùng MCP ở phương vận http, agent sẽ không tự khởi chạy MCP server như đối với stdio, nên người ta ngại dùng. Nhưng đây là lúc Linux toả sáng vì trên Linux ta dễ dàng biến MCP service thành dịch vụ tự khởi động, ta không cần bận tay bận chân tắt mở MCP server mỗi khi cần dùng đến. Ý tưởng là dùng systemd để tự động bật server MCP lên.

Phần sau đây sẽ hướng dẫn cách cài đặt MCP server Lightpanda thay vì Nushell vì ngay hôm mình viết bài này thì Nushell lại có một cập nhật khiến MCP http không bắt tay được với Crush nhưng stdio thì được.

Lightpanda là một trình duyệt dành cho agent AI, nhẹ và chạy nhanh, dùng cho hoàn cảnh không cần render đồ hoạ. Lightpanda được viết mới từ đầu, không phải fork từ Chromium hay Firefox.

Laptop có một cái bất tiện là khi đang gõ phím, thỉnh thoảng vô tình lòng bàn tay quệt vào touchpad và di con chuột đi khiến chữ nhảy lung tung. Thế nhưng laptop của mình lại không có nút để bật tắt touchpad. Vậy phải làm sao?

May cái là Linux rất uyển chuyển, cho phép mình dùng lệnh / viết script để bật tắt, rồi gán chúng cho phím tắt nào đó.

Repo dưới đây cung cấp hai script để bật tắt touchpad trong hai môi trường, GNOME và Niri.

GNOME thì mình dùng chiêu này nhiều năm nay, bây giờ thì hỗ trợ thêm cho Niri.

Crush là phần mềm agent AI ưa thích của mình, nhưng trước giờ mình vẫn có một băn khoăn về việc phải lưu key API của các nhà cung cấp mô hình LLM trong file cấu hình trần trụi. Từ phiên bản 0.85, Crush thay đổi cách lưu và đọc cấu hình, và mình đã thấy cơ hội để lưu key API một cách an toàn hơn.

Trước đây mình có một bài viết "Sử dụng model AI LLM host trong nước" và bạn có thể thấy Crush lưu cấu hình trong một file JSON và ta phải để key API ở dạng nguyên văn trong đó, ví dụ:

{
  "providers": {

Mình làm website, mỗi lần làm xong một tính năng mới, hay sửa một tính năng bị lỗi, sẽ phải mở website, thao tác lại các bước để xem "chắc ăn" chưa. Nhiều khi việc sửa code thì dễ, nhanh nhưng việc test thủ công kiểu này thì lâu, nhất là những tính năng nằm trong sâu, phải đi qua nhiều bước mới vươn tới. Bởi vậy tìm cách kết hợp với agent AI cho nó gánh bớt.

Do mình chủ yếu làm việc bằng truy cập từ xa (xem bài "Làm việc từ xa bằng máy tính ở nhà"), dùng Terminal, nên hầu hết các giải pháp "dùng AI agent điều khiển trình duyệt" ngoài kia là không phù hợp với mình. Cụ thể:

• Mình luôn dùng agent AI trên Terminal. Các agent trong VS Code, Zed mình không muốn đụng đến.

• Khi làm việc kiểu truy cập từ xa thì trình duyệt và agent chạy trên hai máy khác nhau nên đa số giải pháp (agent tích hợp trong code editor) cũng không phù hợp.

In previous posts, "Define UI comprising Dropdown in Blueprint for modern GTK apps" and "Define UI comprising ListView in Blueprint for modern GTK apps", I presented how to use list widgets in Blueprint. Now we look at a different, but more compact topic, the keyboard shortcut.

In a desktop app, the user is expected to do a lot of work with the keyboard alone, not always reaching for the mouse. So a good app should have many keyboard shortcuts. For example, a Ctrl+V to paste, a Ctrl+S to save, an F1 to show help, etc. Most GUI toolkits have built-in support for this. GTK is no exception. There are two ways to assign a keyboard shortcut to an action in GTK 4:

• The simplest one is the application's accelerator, set via gtk_application_set_accels_for_action(). You define the action on the application (with the app. prefix), then call that function with a list of accelerator strings. But this is not declarative, you have to write code.
• A more flexible way is to use a Gtk.ShortcutController, to which you add one or more Gtk.Shortcut objects. Each Shortcut binds a trigger (a key combination) to an action. This is what we will learn in this post, because it is declarative and we can describe the shortcut in the Blueprint file alongside the rest of the UI.

Từ khi phong trào vibe code ra đời, dịch vụ GitHub thường bị quá tải (do sự khai thác quá mức từ các agent AI), cao điểm là cách đây mấy hôm, quy trình CI/CD ở công ty mình bị tê liệt khi GitHub không thể cấp phát các runner để chạy CI/CD. May sao công ty dùng server bare-metal, còn dư công suất nên mình ngắt ra một phần, dựng các container Incus để chạy runner self-hosted cho GitHub Actions. Bài này sẽ hướng dẫn cách setup.

Tại sao là Incus?

Incus là chương trình quản lý tạo và chạy container hoặc máy ảo. Mình cần có nhiều GitHub Runner để chạy được nhiều job CI/CD cùng lúc. Giải pháp là chia nhỏ máy thật ra thành nhiều "máy ảo", và cài GitHub Runner trong đó. Tuy nhiên, tạo máy ảo virtual machine như trên QEMU, VirtualBox thì hơi cồng kềnh, một "system container" sẽ gọn nhẹ hơn. Nói về container, có lẽ cái tên Docker được biết đến rộng rãi nhất, nhưng nó không phải là giải pháp container duy nhất, lại càng không phải cái đầu tiên. Mình dùng Incus vì mình cần "system container", là loại container chạy được systemd bên trong để quản lý nhiều dịch vụ mà không cần sửa đổi gì. Nói thêm một chút, loại container được tạo bởi Docker là "application container", hướng đến đóng gói một ứng dụng cụ thể nên nó không thể chạy systemd bên trong và khi dùng nó để chạy các phần mềm database như Postgres, Redis, người ta phải dùng thêm mấy lệnh "của nợ" như sau: