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