Thời buổi này điện thoại có dung lượng bộ nhớ trong lớn và việc gắn thẻ nhớ bất tiện hơn nên người dùng thường không dùng thẻ nhớ nữa. Tuy nhiên với nhu cầu quay phim, chụp ảnh lớn mà bộ nhớ trong có hạn thì cũng sẽ có một ngày ta cần chuyển bớt ảnh vào máy tính để lấy chỗ trống lưu dữ liệu mới. Vì lâu lâu mới làm một lần nên số lượng mỗi lần chuyển là rất lớn, sẽ tốn khá nhiều thời gian. Hôm nay tôi trình bày cách làm để tiết kiệm thời gian hơn. Việc này được thực hiện với điện thoại Android và máy tính cá nhân chạy hệ điều hành Ubuntu. Cách này cũng áp dụng được với các HĐH Linux khác.

Để làm việc này, ta sẽ dùng phần mềm gThumb. Việc cài gThumb thì đơn giản, chỉ cần gõ lệnh sau:

$ sudo apt install gthumb

Mấy nay nghe báo chí ca ngợi về blockchain & Web3 quá nên mình quyết định bước chân vào lĩnh vực này để tìm hiểu coi nó có ứng dụng thực tế gì không. Sau một tháng đọc tài liệu và viết code thử, mình nghĩ là đã tìm thấy câu trả lời.

Mình tìm hiểu về blockchain & Web3 với tâm thế của một người làm kĩ thuật, tức là mình không chỉ đọc khơi khơi. Mình muốn lập trình, làm ra được một ứng dụng cụ thể từ blockchain. Trong số các hệ thống blockchain, mình chọn Solana để nghiên cứu. Mình chọn nó là vì:

• Nó cho phép lập trình bằng ngôn ngữ Rust. Mình ưu tiên Rust không chỉ vì lý do cảm tính (yêu thích) mà còn vì lý do thực dụng: Đầu tư vào Rust để sau khi làm về blockchain, mình có thể sử dụng Rust để làm việc cho các mảng khác (web, hệ thống nhúng v.v...). Nếu mình theo Ethereum thì phải học ngôn ngữ Solidity, nhưng Solidity chỉ có giá trị với smart contract. Rời blockchain ra thì chẳng dùng Solidity được vào việc gì khác, phí thời gian học tập.
• Solana có tốc độ xử lý giao dịch nhanh. Theo mình, muốn có ứng dụng thực tế thì phải nhanh. Tương tự như bạn vô một website mà tải chậm thì lần sau bạn chẳng muốn ghé lại nữa.

If you are using the command-line tool for Solana blockchain, you may be tired from remembering and typing its subcommands and options. How to get auto-completion for it?

Thank to great Rust libraries, Solana CLI automatically has a feature to generate auto-completion scripts. It is just that the feature is not mentioned in documentation yet. To generate this script for your shell, just run:

$ solana completion -s <your-shell>

Gần đây, nhân có vụ lùm xùm hộ chiếu mẫu mới (màu tím than) của Việt Nam bị vài nước từ chối vì thiếu thông tin nơi sinh, mình quyết định làm công cụ online này để tra cứu nhanh: https://vietnam-personal-id.info

Hộ chiếu mẫu mới vốn đã in kèm mã định danh cá nhân, và một số thông tin cá nhân như nơi sinh, giới tính, năm sinh vốn đã được mã hóa trong mã định danh cá nhân rồi, nên nếu các cơ quan xuất nhập cảnh sử dụng công cụ này, thủ tục sẽ được giải quyết nhanh chóng.

Đây là một ứng dụng thuần front-end, viết bằng TypeScript, theo framework VueJS 3 và dùng TailwindCSS cho CSS. Ban đầu mình cho nó kết hợp với backend, là trang https://provinces.open-api.vn/ của mình, để tra cứu tỉnh thành từ mã số. Nhưng sau đó, vấn đề dữ liệu phức tạp hơn dự kiến mà một mình trang open-api.vn không đáp ứng đủ. Đó là khi cá nhân được sinh ra ở nước ngoài, thì ba chữ số đầu sẽ tương ứng với mã nước. Mã quốc gia này không thấy quy định ở nơi khác ngoài Thông tư 07/2016/TT-BCA của Bộ Công an, và lấn cấn ở chỗ là dùng tên nước theo cách gọi của tiếng Việt, ví dụ "Bờ Biển Ngà". Thế là mình phải lọ mọ viết thêm một công cụ bằng Python, kết hợp tra cứu, nhập liệu thủ công, để có được tên chính thức của quốc gia. Dữ liệu này làm xong thì cho tích hợp vào front-end luôn. Sau đó thì thấy rằng, dữ liệu mã quốc gia nặng hơn (có tới 196 nước) dữ liệu tỉnh thành mà còn nhúng vào được thì mắc mớ thì dữ liệu tỉnh thành lại phải gọi API bên ngoài để tra cứu, chưa kể trang https://provinces.open-api.vn/ đang bị vượt quá lưu lượng sử dụng nữa. Thế là dẹp backend luôn.

Một tháng sau khi Ubuntu 22.04 ra mắt, mình quyết định nâng cấp dàn server của mình, đang chạy Ubuntu 20.04, lên Ubuntu 22.04. Trong quá trình làm, một số bất ngờ nảy sinh như sau:

• Một số server của mình có chạy Mosquitto, một MQTT broker, để thu nhận dữ liệu từ các cảm biến ngoài trang trại gửi về. Sau khi nâng cấp lên Ubuntu 22.04 tự dưng không nhận được dữ liệu nữa. Ban đầu tưởng lý do không nằm ở Mosquitto vì thử publish gói tin lên từ cùng một máy vẫn thấy nhận được dữ liệu. Mất một ngày để phát hiện, hóa ra trên Ubuntu 22.04 thì Mosquitto thay đổi hành vi, mặc định nó không lắng nghe trên mọi network interface nữa mà chỉ nghe trên localhost, nên gói tin gửi từ cùng một máy thì nhận được, gửi từ bên ngoài vào thì không nhận.

• Mình sử dụng TimescaleDB làm database lưu trữ dữ liệu IoT. TimescaleDB là một extension của PostgreSQL. Trên Ubuntu 20.04 thì là PostgreSQL 12, trên Ubuntu 22.04 thì là PostgreSQL 14 nên phải tìm cách nâng cấp bộ dữ liệu đang chứa trên máy từ Postgres 12 lên 14. Bình thường nếu không cài TimescaleDB thì việc này rất nhanh chóng, dùng lệnh pg_upgradecluster là được. Nhưng khi có TimescaleDB thì mới lộ ra là lệnh này có bug, chạy không thành công. May mắn có người giải quyết vấn đề này trước và viết hướng dẫn trên mạng. Thực hiện hơi lòng vòng nhiều bước nhưng cũng thành công.

If you are using Debian/Ubuntu, having Slack installed, you will see this warning when doing apt update:

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packagecloud.io/slacktechnologies/slack/debian jessie InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C6ABDCF64DB9A0B2
W: Failed to fetch https://packagecloud.io/slacktechnologies/slack/debian/dists/jessie/InRelease  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C6ABDCF64DB9A0B2
W: Some index files failed to download. They have been ignored, or old ones used instead.

Là một nhà phát triển web, bạn có thể đã biết đến Iconify, một kho dữ liệu icon dành cho web cực kỳ phong phú, tổng hợp từ nhiều bộ khác nhau (FontAwesome, Material Design v.v...) để đưa về một cách sử dụng chung. Tôi cũng không ngoại lệ, cũng sử dụng Iconnify trong nhiều dự án, vì ngoài việc tích hợp dễ dàng vào dự án, Iconify còn cho phép trộn lẫn nhiều bộ, vì nhiều khi hình ảnh mà tôi cần không tồn tại trong bộ này mà chỉ có ở bộ kia (bạn có thể lo ngại việc trộn lẫn khiến phong cách hình ảnh không thống nhất, đành chịu, vì với người không có khả năng thiết kế thì phải chấp nhận thôi).

Để có được ưu điểm kể trên, Iconify không bắt bạn phải đóng gói hết nội dung icon của các bộ cần dùng, mà dùng cơ chế gọi API để lấy về nội dung của icon khi cần (và nội dung này cũng được lưu trữ tạm để khỏi gọi API lại nhiều lần).

Với phần lớn trường hợp thì cách làm này là ổn, nhưng một số trường hợp thì nó lại gây băn khoăn. Ví dụ với một sản phẩm IoT, khi mà website đó chạy trong mạng nội bộ, để có thể tự hành khi rớt Internet, hoặc được truy cập ở vùng sâu vùng xa nơi điều kiện Internet không tốt, khi việc gọi API lấy nội dung icon có thể thất bại và ảnh hưởng xấu đến giao diện website. Với những trường hợp như thế thì tôi phải tìm cách thu thập nội dung icon và đính kèm theo website, để không phải gọi API nữa.

Cách đây mấy hôm một vài trang tin mạng đua nhau đưa tin "Thái Lan đổi tên thủ đô Bangkok thành Krung Thep Maha Nakhon". Tưởng tin giật gân nên đua nhau sao chép mà không suy nghĩ.

Thật ra chẳng có chuyện đổi tên gì cả. "Krung Thep Maha Nakhon" vẫn là tên chính thức của thủ đô Thái Lan trước giờ, người dân trong nước vẫn gọi tên đó trước giờ, nhưng gọi tắt thành "Krung Thep". Chỉ có văn bản tiếng Anh mới dùng chữ Bangkok.

Cái tên chính thức kia đọc là "Krùng Thep Ma-hả Na-khon" (chữ "Thep" phát âm với thanh cao hơn thanh ngang nhưng thấp hơn thanh sắc của tiếng Việt).

Gần đây rộ lên vụ lùm xùm của app Visafe. Lúc đầu mình không quan tâm lắm, nhưng càng ngày càng thấy nhiều người truyền bá tư tưởng sai lệch về phần mềm nguồn mở nên mình nghĩ phải viết bài này thôi, không thì họ bôi vẽ phần mềm nguồn mở thành một thứ gì đó ích kỷ mất.

Trước tiên, để biết mình có đủ kiến thức để bàn về vấn đề này không thì mình xin giới thiệu, mình theo con đường phần mềm nguồn mở khá lâu rồi (từ 2010 - 2012 gì ấy), thậm chí là một trong số ít những lập trình viên VN đi theo con đường này, đến nỗi nhiều khi cảm thấy mình hơi lẻ loi và khác người. Bản thân mình đã đóng góp code cho hàng chục dự án phần mềm nguồn mở, và các sản phẩm cá nhân của mình cũng đều mở mã nguồn ra hết (https://github.com/hongquan). Mình thậm chí còn có dăm dòng code đóng góp cho sản phẩm của Google và từng được Google gửi thư mời đến dự một hội nghị về phần mềm nguồn mở do Google tổ chức (nhưng chuyến đi đó không thành vì rớt visa).

Ý kiến mà người ta chửi về Visafe là "ăn cắp, sao chép", cho rằng việc "sao chép, đổi tên" là một hành vi xấu xa. Nhưng hỡi ôi, phần mềm gốc mà Visafe sao chép là Adguard, là một phần mềm nguồn mở cơ mà. Trái với quan niệm và tư duy "đóng" của nhiều người, việc "sao chép, sửa đổi" trong phần mềm mã nguồn mở lại là hành vi được khuyến khích. Khuyến khích nên mới mở. Sau khi sao chép, sửa đổi thì bản phái sinh đó cũng phải được mở, công khai để người khác có thể tùy ý sao chép, sửa đổi nó và duy trì mãi. Cho nên tội lỗi của Visafe có hay không là ở việc họ có mở mã nguồn ra trước khi bị tác giả của Adguard "bóc phốt" hay không. Khi phần mềm được "mở mã nguồn", nó được phát hành theo một giấy phép phần mềm nguồn mở cụ thể nào đó, như GPL, Apache, MIT v.v... Trách nhiệm của người sao chép mã nguồn đó như thế nào là tùy theo giấy phép đó quy định. Chẳng hạn giấy phép GPL yêu cầu bản phái sinh cũng được phát hành theo cùng giấy phép GPL. Các giấy phép "thoáng" hơn như Apache, MIT, BSD thì cho "mày muốn làm gì cũng được, miễn là mày ghi tên tao, người làm phần mềm gốc, và ghi nhận tên phần mềm gốc".

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