Modal dialog is a often used UI element, but in web tech, developers used to spend quite much effort to implement it, before the introduction of CSS frameworks like Bootstrap. It was tricky to position the dialog in the center of the window, to blur the content behind it. It was tricky to let user close the popup by clicking outside it.

It is until the HTML standard introduces the native <dialog> element. Now developers can create a modal popup with ease, except if their users are using Safari, which often lags behind the modern web features. Put Safari aside, now we see how to create the native modal popup in Lustre framework (Gleam language).

My use case is the post compose form of this blog. The original content is in Markdown. The form has a "Preview" button so that if I click it, a modal popup appears and loads the rendered HTML of that Markdown code.

Từ khóa return quá quen thuộc khi nó có mặt trong hầu như mọi ngôn ngữ lập trình, không chỉ được dùng ở cuối hàm như một lẽ thường, nó còn được dùng ở giữa hàm khi cần dừng chạy hàm sớm khi gặp điều kiện nào đó, ví dụ:

async def process_mqtt_message(
    topic: str, payload: bytes, pg_session: AsyncSession, red: Redis[str]
) -> ActuatorProcessResult | NodeProcessResult | None:
    if m := REGEX_TOPIC_SN_ACTUATOR_STATUS.match(topic):

Given that we have a list of items, and a "delete" button for each item. We want that when user clicks the button, a confirm dialog will appear, asking user one more time, before proceeding with API call to delete the item from the database.

Here is how to do that in Lustre (a frontend web framework in Gleam language). The dialog in this example is the HTML native dialog created by window.confirm() method, in case we want some thing quick and simple. If you want to use <dialog> element, I will write later.

First, let's write a view function to prepare the HTML:

Để nâng cao năng suất làm việc của lập trình viên thì có nhiều phương án, phương án dùng AI sinh code chỉ là một, nhưng là phương án được marketing ồn ào nhất. Cũng phải thôi, để huấn luyện các mô hình AI đó thì tốn rất nhiều tiền nên các cty chủ quản phải marketing rầm rộ, dùng tới cả chiêu bài hù dọa để cốt bán được hàng.

Vấn đề là những bài marketing làm lệch lạc phương hướng của các sinh viên rất nhiều. Thay vì tự rèn luyện về thuật toán, nghệ thuật của các ngôn ngữ, các good practices, các bí ẩn sâu xa của công nghệ để nâng trình độ của mình vượt lên AI, để có thể tự tin review và bác bỏ code do AI sinh ra, thì giờ nhiều bạn SV lại thấy tự hào vì "AI làm hết cho mình", tự hào vì dành một phần lớn trong số tiền "trợ cấp" hàng tháng để "cúng" cho AI.

Mùa Google Summer of Code năm nay, mình đọc một số proposal của các SV đăng ký dự thi, và gần 100% có giọng văn, cách trình bày của AI, nhưng phần lớn trong số đó bị loại vì lạc đề và dựa vào kiến thức cũ kĩ ko còn đúng với thực tế. Ví dụ có một đề bài là nâng cấp một bộ code cũ của dự án nọ từ Vue 2 lên Vue 3. Sinh viên ấy viết proposal để đề xuất dùng Options API thay vì Compositon API, với một trong những lý do là nếu dùng Composition API thì phải dùng công cụ Volar. Cái không thực tế ở đây là ngoài Volar thì làm gì còn công cụ LSP server cho Vue nào tốt hơn nó nữa. Các sinh viên đó thừa nhận là dùng AI để làm nhưng coi những lời của AI như thần, ko bao giờ đặt nghi vấn, vặn vẹo lại.

Vừa nãy có nói, dùng AI tạo sinh chỉ là một phương án. Phương án còn lại là gì? Là tập dùng các công cụ dòng lệnh, và các đồ chơi trên HĐH Linux (vế này ko cần nghe nếu nghề của bạn là lập trình ứng dụng Windows, iOS, MacOS). Trong phần lớn các trường hợp có dùng AI để phụ viết code thì mình suy nghĩ ra giải pháp nhanh hơn AI (và nhìn AI "thinking..." mà sốt cả ruột), nhưng mình lại gõ phím rất chậm, nên sẽ làm chậm hơn AI nếu code đó phải viết ở nhiều nơi nhiều chỗ. Tuy nhiên có nhiều trường hợp, sử dụng thành thạo các công cụ dòng lệnh thì mình đỡ phải viết code nhiều (cứ phím tắt, autocomplete mà nện) thì cuối cùng lại làm nhanh hơn AI (nếu tính cả thời gian viết prompt nhiều lần để lái AI cho làm đúng ý mình).

Mình vừa nâng cấp git-del-branches lên phiên bản v1. Đây là công cụ để chọn nhiều nhánh Git và xóa cùng lúc.

Tải về tại: https://github.com/hongquan/git-del-branches

GraphQL là một dạng thiết kế HTTP API được dùng rộng rãi. Mặt lợi của nó thì không cần bàn. Tuy nhiên mình và có thể các bạn cũng thấy hơi phiền vì nó dài dòng. Bài này sẽ giới thiệu một số phương tiện phần mềm để làm việc với nó thoải mái hơn, ở phía client.

Python: Cách dùng Pydantic để kiểm tra hợp lệ

Lấy ví dụ API của BirdWeather. Đây là kho dữ liệu của các trạm thu thập tiếng chim hót, phục vụ nghiên cứu nhận dạng chim từ tiếng hót. Ta sẽ gọi vào truy vấn stations để lấy danh sách các trạm. Một response mẫu sẽ trông như sau:

Bạn đã thích thú với Nushell, đã cài vào nhưng không thấy tính năng auto-complete? Đừng vội buồn. Đó là vì các file cài đặt Nushell hiện tại không kèm sẵn các script auto-complete. Bạn sẽ phải làm thêm tí việc tay chân để cài các script này vào.

Mặc dù yêu thích Nushell, mình phải thừa nhận rằng mức độ hỗ trợ auto-complete của Nushell chưa dồi dào bằng Fish. Nushell được thiết kế để nhận dữ liệu auto-complete từ cả các script chuyên dụng viết bằng Nu và từ cả phần mềm khác.

1. Nguồn từ phần mềm khác

Từ trong Nushell, gõ:

I often work on a remote Linux box and like to have Byobu running so that I have tab view and status bar. But somedays in mid 2024, somethings start to break when I open Helix inside Byobu and get this annoying gray background every where:

The root issue is that, Byobu runs Tmux with a configuration, and that configuration makes tmux disable some features which is needed to render Helix theme correctly. The key is the TERM environment variable. No matter which terminal emulator we use, after running Byobu, the TERM is set to screen-256color.

Gần đây nghe sự cố máy chủ DeepSeek bị lộ dữ liệu do để mở cổng database toang hoác, làm tôi nhớ đến cách triển khai ứng dụng web của mình, trong đó mình đóng cổng database luôn, chỉ cho truy cập qua Unix domain socket (dạng file), và cũng không cần tạo password, không cần nhớ, không cần giấu password. Thủ thuật này đã được nhắc đến trong một bài blog khác bằng tiếng Anh, nay dịch ra cho anh em tham khảo. Bài viết đó nói về một chủ đề rộng hơn là "cách triển khai ứng dụng web Python một cách tự động".

Gần đây tôi thấy một câu hỏi từ một đồng nghiệp Python, làm thế nào để triển khai ứng dụng Django mà không cần phải SSH thủ công vào máy chủ và chạy các lệnh. Phong cách này là "single server deployment". triển khai trên một máy chủ duy nhất, nơi bạn đặt tất cả các thành phần, từ mã ứng dụng, cơ sở dữ liệu, đến các tệp tĩnh, tệp media, trên cùng một máy chủ. Không có Docker tham gia. Với kiểu triển khai này, chúng ta sẽ cần một cách nào đó để cung cấp phiên bản mới của ứng dụng mỗi khi mã mới được đẩy lên nhánh "release" của kho lưu trữ Git.

Tại sao cần tự động hóa? Vì làm đi làm lại những việc này rất nhàm chán:

• SSH vào máy chủ, cd vào thư mục cài đặt.

Hôm nay mình thử tài DeepSeek về một số ngôn ngữ lập trình mới. Đề bài là: Hãy cho một ví dụ để cho thấy comptime trong ngôn ngữ Zig đem lại trải nghiệm lập trình tốt hơn macro của Rust.

Câu trả lời đầu tiên của DeepSeek bị mình bác bỏ (code trong hình 1), vì nó cho rằng trong Zig có thể dùng comptime để tạo cấu trúc generics trong khi Rust phải dùng macro.