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

Vừa rồi nghỉ dịch, ngoài thông tin về dịch lan tràn khắp mạng XH, đây đó nhiều người vẫn tiếp tục những chủ đề chuyên môn của họ, như là mảng lịch sử. Chỉ trong thời gian ngắn mà mình bắt gặp một ý kiến nổi lên hai lần, ấy là có mấy bạn thấy các tên họ của người Việt đều là "gốc Tàu" xong suy luận là người Việt có gốc Trung Quốc.

Mình thì không có ý kiến gì về gốc gác họ tên, lẫn chẳng có ý kiến gì về nguồn gốc người Việt (việc đó khó quá, nên để nhiều ngành khoa học hợp tác làm). Chỉ muốn nói cách suy luận đó là hệ quả của sự "học lệch". Vì chỉ đọc sử Trung Quốc, theo dõi các chuyện văn hóa nghệ thuật của khối Đông Á nên các bạn ấy không ngờ rằng trên đời, việc một dân tộc này dùng họ tên của tiếng dân tộc khác là chuyện thường tình. Ví dụ trong Đông Nam Á này thôi, người Malay thì lấy tên từ tiếng Ả Rập (chẳng hạn thanh niên trong hình là Syed Saddiq bin Syed Abdul Rahman, còn trẻ thế mà đã làm Bộ trưởng của Malaysia rồi), người Philippines thì lấy tên gốc Tây Ban Nha, người Thái Lan, Indonesia thì lấy tên gốc tiếng Phạn (Ấn Độ). Các nước còn lại cũng thường lấy tên có một nửa gốc tiếng Phạn, Pali. Tên họ không phản ánh nguồn gốc dân tộc mà chỉ là kết quả của sự ảnh hưởng văn hóa, những tác động chính trị. Người Malay lấy tên tiếng Ả Rập vì họ cải theo đạo Islam. Người Philippines lấy tên tiếng Tây Ban Nha vì họ rơi vào sự thống trị của thực dân TBN ngay từ khi họ chưa kịp tạo dựng một nhà nước quân chủ thống nhất với nền tảng văn hóa đủ dày. Thái Lan và Indonesia thậm chí có luật bắt buộc công dân phải đặt tên sao cho chỉ được dùng các từ gốc tiếng Phạn, thành thử có nhiều người gốc Hoa nhưng lại có tên Vichai, Sri, Rahman, thay vì những Wong, Tan, Ng như bên Malaysia, Singapore.

Nhân nói về họ tên, có một điều thú vị là không như khối Đông Á, nơi "phần họ" được duy trì từ ông xuống cha, con, cháu, thì trong một số truyền thống văn hóa khác, "họ" chỉ đơn giản là "con ông X" thôi, nên sẽ thay đổi theo thế hệ (dùng tên cha lấp vào phần "họ" của con). Ví dụ như anh chàng bộ trưởng phía trên, theo https://desklib.com/document/a-leader-is-someone-who-can-identify-way/ thì cha ông tên "Syed Andul Rahman" và mẹ ông tên "Sharifah Mahani binti Syed Abdul Aziz". Chữ "bin" ở đây nghĩa là "con trai của ông..." và "binti" là "con gái của ông...". Ngoài ra thì người Myanmar vẫn còn giữ truyền thống là "không có họ".

Thỉnh thoảng mình có mối duyên ghé mắt qua các dự án Python, thấy cách sắp đặt vẫn còn chuệch choạc, không có lợi lắm cho việc phát triển tiếp diễn. Nên sau đây mình chia sẻ một số cách thức, công cụ, thư viện mà bạn nên chuẩn bị từ đầu, để công việc sau đó trở nên thoải mái hơn. Cách sắp đặt này có thể coi là chuẩn trong những năm 2020 này (nhưng có thể trở thành lạc hậu sau 5 năm nữa).

1. Quản lý các gói phụ thuộc

Gói phụ thuộc (dependency) là các thư viện / công cụ bên ngoài mà dự án của bạn cần. Các gói này phải được cài trước khi phần mềm của bạn có thể chạy. Ví dụ bạn làm về khoa học dữ liệu thì sẽ cần NumPy, làm web thì sẽ cần Django v.v... Việc một dự án phụ thuộc vào hàng chục gói thư viện khác là chuyện bình thường. Thông thường các gói này sẽ được liệt kê trong file requirements.txt để khi sao chép dự án sang máy khác thì biết cần cài cái gì. Tuy nhiên, file requirements.txt chỉ là hình thức tối thiểu để quản lý gói phụ thuộc. Nó không đủ để hỗ trợ tình huống phức tạp hơn. Ví dụ dự án của bạn sử dụng thư viện A phiên bản v1 và B phiên bản v2. Sau vài tháng nhu cầu nảy sinh, bạn cần thêm tính năng mới, và để làm tính năng mới, bạn cần đến thư viện C. Tuy nhiên thư viện C này cũng lại phụ thuộc thư viện A, và thư viện C đang có nhiều phiên bản, v1 đến v5, mỗi phiên bản của C sẽ thương thích với một phiên bản A khác nhau. Nếu bạn nhắm mắt chọn phiên bản mới nhất của C thì nó sẽ yêu cầu A v3. Bạn không thể mù quáng nâng cấp A lên v3 vì có thể phần mềm của bạn không tương thích và đứt gãy. Nhưng trong 5 phiên bản của C mà thử từng cái một thì rất cực. Đó là lúc bạn cần một thứ nâng cao hơn file requirements.txt.

Một công cụ hiện đại mà mình hay dùng, và khuyên dùng cho tình huống này là Poetry. Khi bạn cần thêm C vào danh sách phụ thuộc, chỉ cần chạy:

Dạo này tình hình dịch bệnh nghiêm trọng, phải ở nhà cả ngày nên mình tranh thủ làm một bộ API HTTP giúp truy cập dữ liệu mở, công cộng của Việt Nam.

Sản phẩm đầu tiên là API cung cấp dữ liệu tỉnh thành Việt Nam tại provinces.open-api.vn, ra mắt vào tháng trước:

API này dựa trên một thư viện Python, VietnamProvinces, mà mình đã xây dựng hồi còn làm việc tại SunshineTech.

Mấy bữa nay, nghe đâu cáp Internet đại dương lại bị đứt, khiến việc truy cập website nước ngoài rất khó khăn. Tuy nhiên đường truyền tại các datacenter trong nước thì vẫn nhanh như lũ về, cho nên nếu đi ké được qua đường truyền này thì ngon. Ta có thể làm việc ấy bằng cách tự dựng proxy, để "bẻ lái" đường truy cập từ nhà đến datacenter rồi từ datacenter ra thế giới.

Trước tiên, phải nhắc nhở rằng bài hướng dẫn này không dành cho tất cả mọi người, mà nó dành cho "nhà có điều kiện". "Điều kiện" ấy là bạn phải có một server trong nước. Bạn có thể tự thuê cá nhân hay xài ké server công ty. Và như thường lệ, bài hướng dẫn này áp dụng cho hệ điều hành Linux, cụ thể là Ubuntu 20.04.

Phía server

Để nói cụ thể hơn thì phần mềm proxy mà ta sẽ dùng thuộc thể loại HTTP proxy, tức là nó chỉ chuyển hướng các truy cập website (giao thức HTTP/HTTPS). Các phần mềm game, chat dùng giao thức riêng thì sẽ phải dùng các loại proxy khác.

Trước đây tôi có viết bài Dựng mạng VPN với WireGuard . Sau một thời gian sử dụng, để ý thấy do các máy con (client) của tôi thỉnh thoảng xảy ra tình trạng treo WireGuard: từ các máy khác không ping đến nó được. Vì vậy tôi lại tiếp tuc đề tài WireGuard này, giới thiệu một cách khắc phục.

Trước tiên, xin nêu vài nguyên nhân khiến VPN WireGuard bị treo:

• WireGuard của năm 2018 (lúc tôi viết bài trên) được nạp lên hệ thống dưới dạng DKMS. Như ta đã biết, khác với các giải pháp VPN thông thường, WireGuard chạy dưới dạng một driver/module của nhân Linux. Nhưng khi được phân phối ở dạng DKMS, mỗi lần máy được nâng cấp nhân mới thì module này phải trải qua quá trình build lại từ mã nguồn bên ngoài. Điều này đôi khi gây ra tình trạng, phiên bản cũ vẫn còn lơ lửng trong RAM và phiên bản mới chưa thế chân vào được, thế là WireGuard bị treo. Từ Linux 5.6 trở đi thì WireGuard đã được tích hợp vào nhân, không còn ở dạng DKMS nữa nên tình trạng này không còn.

• Network interface của WireGuard (ví dụ wg0) được khởi tạo khi máy vẫn chưa thực sự kết nối với Internet (sai thứ tự), việc kết nối với server VPN không thành công, khiến việc cấu hình không hoàn tất. Hoặc khi đang chạy ngon bỗng dưng Internet bị rớt, mất luôn mối kết nối với server. Điều này hay xảy ra với các máy con (client) vì các máy này không được đảm bảo luôn có Internet, thậm chí là không phải lúc nào cũng có điện.