Giành lại web bằng một trình đọc cá nhân
(olano.dev)- Sau khi chán nản với ngành phần mềm và mạng xã hội truyền thống, tác giả cũng thử Mastodon, nhưng thứ thực sự cần lại là một trình đọc feed cá nhân để gom bài viết và thông báo trên web, thay vì một dòng thời gian xoay quanh con người
- Mục tiêu không phải là danh sách tồn đọng kiểu hộp thư của RSS reader, mà là một giao diện dạng stream nơi mỗi lần mở ra đều có nội dung thú vị chảy qua như home feed của Twitter hay Mastodon
- Tiêu chí thiết kế là trải nghiệm người dùng > vận hành thuận tiện > phát triển thuận tiện, và ưu tiên các lựa chọn dễ vận hành như htmx·hyperscript, ứng dụng Web nguyên khối, SQLite, Python, cùng các mở rộng gevent và Huey
- Trong quá trình sử dụng thực tế, ứng dụng được bổ sung các tính năng như đọc bài ngay trong app, ghim để đọc sau, bookmark, sắp xếp theo tần suất xuất bản của nguồn, và tự động đánh dấu “đã xem” khi cuộn
- Sau khoảng 3 tháng làm việc thong thả, tác giả tạo ra feedi và dùng nó như “trang đầu của Internet” trong vài tháng, qua đó lấy lại cảm giác kiểm soát đối với lượng thông tin mình tiêu thụ
Cách dùng web được tìm lại sau burnout
- Trải qua burnout nghề nghiệp vì các dự án tệ liên tiếp và sự vỡ mộng với ngành phần mềm
- Giảm khối lượng công việc, nghỉ việc và bắt đầu điều trị, đồng thời chỉnh lại các thói quen như ăn uống, tập luyện và thiền
- Tạm thời tránh xa việc lập trình và đọc các nội dung liên quan đến phần mềm, đồng thời rời khỏi Twitter, mạng xã hội cuối cùng còn dùng
- Trong lúc đọc How to Do Nothing, tác giả quay lại xem xét Mastodon như một cộng đồng trực tuyến thay thế
Những giới hạn nhận ra từ Mastodon
- Mastodon cung cấp feed theo thời gian không qua trung gian thuật toán, tạo cảm giác lấy lại quyền kiểm soát feed
- Những người cũng cảm thấy bất mãn tương tự với ngành phần mềm và web đang nhìn lại các yếu tố web cũ như RSS, BBS, digital gardens, webrings, hoặc hình dung về một web cởi mở và độc lập hơn
- Mục đích sử dụng thực tế gần với một trung tâm thông tin hơn là microblogging
- Theo dõi người khác là để nhận thông báo khi họ đăng bài lên website
- Theo dõi bot là để nhận nội dung từ các link aggregator
- Sau khi biết đến khái niệm social readers của IndieWeb, tác giả đi đến kết luận rằng công cụ cần thiết không phải Mastodon mà là một trình đọc feed có thể tự điều chỉnh
Mục tiêu người dùng của trình đọc cá nhân
- Thứ tác giả muốn là một stream có nội dung thú vị chảy qua mỗi lần mở app, chứ không phải danh sách tồn đọng kiểu hộp thư của RSS reader thông thường
- Feed cần trộn lẫn nhiều nguồn khác nhau
- Bài viết từ blog, tạp chí, trang tin, link aggregator
- Thông báo từ các tài khoản cá nhân như Mastodon, Goodreads, GitHub
- Cần tùy biến parser để tạo ra hình thức và cảm giác nhất quán dù dữ liệu từ mỗi nguồn có dạng khác nhau
- Các tính năng xã hội của một IndieWeb reader hoàn chỉnh không nằm trong phạm vi triển khai
- Việc mở tab khác để bình luận không phải vấn đề
- Nội dung phân tán trên các website bên thứ ba cũng không sao
- Mục tiêu ngắn hạn là nhanh chóng kiểm tra xem công cụ này có thể trở thành nguồn thông tin web chính, thậm chí duy nhất hay không; nếu không thì sẽ dừng dự án ngay
Nguyên tắc phát triển và phạm vi
- Nguyên tắc phát triển là
user > ops > dev- Khi ưu tiên công việc và đánh đổi trong thiết kế, tác giả chọn sự thuận tiện trong vận hành thay vì thuận tiện cho phát triển
- Và đặt trải nghiệm người dùng cao hơn nữa
- Vì đây là app cá nhân, “ưu tiên người dùng” có nghĩa là dogfooding bằng cách tự dùng và thỏa mãn nhu cầu của chính mình trước
- Tác giả cho rằng làm một công cụ phù hợp về mặt công thái học với bản thân có lẽ hữu ích hơn là giả định ra một người dùng lý tưởng
- Dự án này không được trở thành dự án học tập hay dự án portfolio
- Mục tiêu không phải năng suất mà là kết nối lại với niềm vui của việc phát triển phần mềm
- Niềm vui đó phải đến từ “dùng thứ mình tự làm ra” hơn là chỉ “làm ra một thứ gì đó”
- Việc giả định chỉ có một người dùng mục tiêu giúp trì hoãn nhiều quyết định
- Xác thực người dùng chưa cần ngay được để lại sau
- Các tính năng rất cụ thể như gửi sang Kindle có thể được xử lý từ sớm
- Có thể mặc định người dùng có kiến thức lập trình cho các việc như tùy biến feed parser hay đăng nhập Mastodon
Lựa chọn UI và kiến trúc
- Để có thể truy cập không chỉ trên laptop mà cả điện thoại, nó phải là một ứng dụng Web
- Đây là cách tiết kiệm chi phí để hỗ trợ hai thiết bị bằng một giao diện
- Có thể dùng HTML và CSS quen thuộc
- Có thể lưu trạng thái trên server để giải quyết đồng bộ giữa các thiết bị
- Web UI cần có mức độ động nhất định, nhưng tác giả không muốn có ứng dụng frontend riêng hay phải học framework mới
- Theo lời khuyên về boring tech và radical simplicity, tác giả tìm thư viện render phía server và dùng htmx cùng hyperscript
- Để thân thiện trong vận hành, việc triển khai và thiết lập cục bộ phải đơn giản, không muốn mặc định hạ tầng như Docker hay Nix
- IndieWeb reader chính thức mà Aaron Parecki mô tả được chia thành nhiều thành phần theo các giao thức như Micropub, Microsub, Webmentions, nhưng với nhu cầu cá nhân thì điều đó chỉ làm phát triển và vận hành phức tạp hơn mà không có nhiều lợi ích
- Kết quả là tác giả chọn ứng dụng Web nguyên khối, và dùng SQLite làm cơ sở dữ liệu để giảm số lượng thành phần cần cài đặt và cấu hình
Ngôn ngữ và tác vụ nền
- Go có vẻ rất hợp với dự án này vì đơn giản, đa dụng, có garbage collection, đủ nhanh, có mô hình đồng thời tốt và binary dễ triển khai
- Nhưng tác giả chưa từng viết một dòng Go nào và không muốn dự án biến thành dự án học tập
- Trong các ngôn ngữ đã quen, tác giả chọn Python vì có thể làm prototype nhanh nhất
- Điểm yếu của Python vẫn là môi trường và dependency, đặc biệt là phụ thuộc vào thư viện của host OS
- Tác giả không muốn tăng thêm thành phần riêng chỉ để polling feed định kỳ, nên sau khi tìm hiểu đã dùng gevent và mini-huey extension của Huey để chạy tác vụ nền ngay trong process của ứng dụng
- Đổi lại, Python có sẵn nhiều thư viện tốt cho HTTP, feed parsing và scraping
Vì sao trì hoãn viết test
- Ban đầu, tác giả quyết định không viết test
- Vì định thử nghiệm bằng cách thêm, xóa và sắp xếp lại tính năng, nên chi phí bảo trì unit test được xem là lớn hơn giá trị mang lại
- Có thể chấp nhận các lỗi logic nhỏ, và vì là app tự dùng hằng ngày nên các lỗi quan trọng được kỳ vọng sẽ lộ ra theo thời gian
- Tác giả cho rằng integration test có giá trị hơn trong việc tạo độ tin cậy, nhưng nhiều bug của dự án này lại đến từ tích hợp với nguồn bên ngoài và từ UI
- Integration test có thể bắt được một phần bug và regression sớm hơn, nhưng chưa đủ giá trị để bỏ chi phí ban đầu
Việc sử dụng thực tế đã dẫn dắt tính năng ra sao
- Ý tưởng, thử nghiệm và ưu tiên được quyết định bằng việc mỗi ngày trực tiếp dùng app như người dùng cuối
- Sau khi thử nhiều bố cục UI và tính năng, một thói quen sử dụng dần hình thành
- Mở app
- Cuộn feed chính
- Ghim các mục để đọc sau
- Mở các mục muốn đọc ngay
- Bookmark các mục để tham khảo sau
- Tác giả muốn có khả năng đọc bài mà không rời khỏi app, một phần để tránh paywall và popup xin đồng ý
- Đã thử nhiều thư viện Python để trích xuất nội dung HTML, nhưng không cái nào hoạt động tốt như readability mà Firefox dùng
- Vì readability là một gói JavaScript, tác giả thêm Node.js như một dependency tùy chọn
Sắp xếp feed và xử lý “đã xem”
- Ngay cả khi đã có các chức năng cơ bản, chỉ sắp xếp theo ngày xuất bản vẫn khiến việc tìm nội dung thú vị trở nên khó khăn
- Bài blog hiếm hoi bị chìm sau các toot Mastodon
- Bài dài từ tạp chí bị chìm sau các tin tức hằng ngày
- Vì mọi nguồn được theo dõi đều là nguồn quan tâm, tác giả giả định rằng nên xem trước nội dung từ các nguồn có tần suất xuất bản thấp
- Nếu một bản tin hằng tháng vừa ra trong vài ngày gần đây, nó nên xuất hiện phía trên microblogging hay tin tức hằng ngày
- Tác giả phân loại nguồn vào các “frequency buckets” và sắp xếp feed sao cho bucket có tần suất thấp hơn hiện lên trước
- Để tránh việc nội dung hiếm cứ dính mãi trên đầu mỗi lần mở app, tác giả thêm tính năng tự động đánh dấu mục là “already seen” khi cuộn xuống
- Theo cách này, luôn có thể thấy nội dung mới mà vẫn không bỏ lỡ những cập nhật hiếm
Từ máy cục bộ lên VPS
- Ban đầu, tác giả chạy app trong một tab terminal trên laptop để vừa phát triển vừa sử dụng
- Khi bắt đầu thích những nội dung hiện ra trên feed, tác giả đưa nó lên server Raspberry Pi trong mạng cục bộ để luôn có thể truy cập
- Khi dùng thường trực trên Raspberry Pi, tác giả cải thiện rendering cho di động để truy cập tốt hơn trên điện thoại
- Đến lúc thấy nhớ app ngay cả khi ra ngoài, tác giả triển khai nó lên VPS
- Việc triển khai lên VPS buộc phải thêm xác thực và hỗ trợ nhiều người dùng vốn đã trì hoãn, đồng thời cho phép cấp quyền truy cập beta test cho vài người bạn
- Việc thiết lập VPS dẫn tới chuyện mua tên miền và tạo website này, đồng thời trở thành một bước tiến gần hơn tới lý tưởng IndieWeb ban đầu
Kết quả của feedi
- Sau khoảng 3 tháng làm việc thong thả, tác giả tạo ra trình đọc feed cá nhân feedi
- feedi giống một công cụ kiểu cấu hình Emacs hơn là một sản phẩm hoàn thiện: luôn ở trạng thái nửa hỏng nửa quen tay
- Xét dưới góc độ năng suất thì khó biện minh, nhưng nó mang lại sự hài lòng vì là công cụ được làm theo đúng điều kiện của bản thân
- Trong vài tháng, tác giả đã dùng feedi như “front page of the internet”
- Nhờ dùng trình đọc cá nhân, tác giả lấy lại quyền kiểm soát thông tin mình tiêu thụ, chủ động tìm các blog và tạp chí thú vị hơn, và mở mình ra nhiều hơn với sự khám phá và bất ngờ
1 bình luận
Ý kiến trên Hacker News
Thiết lập urlwatch(https://urlwatch.readthedocs.io/en/latest/) khá là thú vị. Đặc biệt khi vượt qua phần boilerplate của Puppeteer và có thể dùng một instance Chrome để cào các trang JavaScript, nó mang lại cảm giác kiểm soát bằng cách khiến web tự đẩy tới mình thay vì mình phải đi kéo về
Sức mạnh của việc theo dõi website một cách thoải mái rồi lướt qua vào buổi sáng là rất lớn. Có thể theo dõi tin tuyển dụng của công ty mình thích, tuyển dụng/đóng tuyển của công ty hiện tại, các sản phẩm đang chờ giảm giá·nhập lại hàng·hàng tân trang, thống kê nước thải COVID, tin rao căn hộ, các bản phát hành GitHub quan tâm, cho đến thay đổi điều khoản của những website quan trọng
Cá nhân tôi còn tự host RSS reader và bot Telegram, đồng thời hay làm các site HTTP nhỏ để thử nghiệm, nên dùng DigitalOcean $5 Droplet, nhưng vì không nhất thiết phải chạy vào cùng một giờ mỗi ngày nên dùng laptop cũng được
Vì là dùng cá nhân nên tôi chỉ nhận bản tóm tắt các cập nhật Twitter về chủ đề mình quan tâm, đồng thời tránh được chính trang đó, các cuộc khẩu chiến độc hại và quảng cáo phiền toái
Tôi quá bực với tình trạng IT hiện nay nên khó mà sắp xếp cho mạch lạc, nhưng thỉnh thoảng tôi tưởng tượng ra khái niệm “người phụ trách IT của riêng tôi”. Kiểu như thợ cắt tóc quen, bác sĩ gia đình, thợ may hay thợ làm bánh trong khu phố, nhưng là người phụ trách một phần đời sống số của mình
Họ có thể vận hành một hạ tầng nhỏ ở địa phương để tạo feed cá nhân hóa, chăm lo quyền riêng tư và sức khỏe số, rồi kết nối với feed reader thông qua giao diện đơn giản hoặc giao thức mở. Họ có thể xử lý phim, bài viết, meme, video vui nhộn, nhưng cốt lõi là có một con người để trò chuyện, chứ không phải thuật toán tối ưu doanh thu
Tôi cũng nghĩ đến ý tưởng có các datacenter do cộng đồng địa phương vận hành như thư viện, hoặc cung cấp dịch vụ nội dung đơn giản qua Internet tại nhà. Vì vậy tôi thích những ý tưởng như Veilid(https://gitlab.com/veilid/veilid)
Đây cũng không phải lần đầu tôi nghe chuyện ai đó nói rằng họ khỏe mạnh hơn sau khi chuyển sang Feediverse. Bản thân tôi đang tự chồng script và mini app lên Puppeteer, chạy tóm tắt và gợi ý bằng llamacpp cục bộ, và sau này muốn trau chuốt hơn để giới thiệu cho bạn bè, người thân
Tôi đặt tên cho các script này là “not a browser”. Tôi muốn một web không phải là nơi phục vụ HTML/CSS/JS kèm dữ liệu, mà là chỉ cung cấp dữ liệu còn việc hiển thị thế nào thì do người dùng quyết định
Không có thuật toán thù địch với người dùng, không có hệ thống dựa vào quảng cáo, và phần lớn là các phần mềm ưu tiên người dùng, nói bằng các giao thức mở. Nếu bạn làm trong ngành IT và có thể tự vận hành máy chủ thì làm được, nhưng vấn đề là những người không như vậy sẽ làm sao
Ý tưởng về một “người phụ trách IT” cá nhân rất thú vị. Tôi tự hỏi liệu có thể cung cấp dịch vụ như vậy cho những người muốn thoát khỏi các công ty công nghệ khổng lồ và thuật toán, để dùng thứ gì đó mang tính cá nhân hơn nhưng lại không có phương tiện kỹ thuật hay không
Dữ liệu y tế cũng tương tự. Tôi ghét việc hồ sơ y tế của mình bị lưu trong MyChart và nhiều hệ thống độc quyền khác mà tôi không có quyền kiểm soát. Trong túi tôi có cả một siêu máy tính, vậy tại sao tôi lại không thể tự giữ bản sao hồ sơ của mình và chỉ chia sẻ có chọn lọc với bác sĩ khi đi khám?
Việc các bệnh viện vẫn phải fax qua lại cho nhau cũng thật kỳ quặc. Đáng lẽ tôi phải có thể chia sẻ dữ liệu của mình chỉ bằng một nút bấm. Apple Health là thứ gần nhất với một số chức năng đó, nhưng có vẻ mức độ chấp nhận ở Mỹ gần như không đáng kể, mà ngay cả vậy nó cũng chỉ ưu ái người dùng Apple. Dữ liệu sức khỏe không nên bị nhốt trong các hệ thống độc quyền, kể cả dưới dạng kiểu Apple Health chạy cục bộ; cần có giao thức mở và một hệ sinh thái triển khai
Trước khi marketing và lòng tham chiếm lĩnh Internet, đã từng có một giai đoạn ngắn mà mọi thứ khá ổn. Nếu theo mô hình sản phẩm kiểu Synology NAS với các ứng dụng có lợi cho người dùng cuối, kèm theo một “người phụ trách IT của riêng tôi” hỗ trợ, thì có thể nó sẽ hoạt động tốt
Nếu không được xây dựng để rút dữ liệu cá nhân và tiền bạc của người dùng thì từ góc nhìn người dùng nó gần như là một thế giới lý tưởng, nhưng xét về kinh tế thì có lẽ đây là loại hình kinh doanh biên lợi nhuận thấp và rủi ro cao. Ví dụ như trách nhiệm khi làm mất dữ liệu là vấn đề rất lớn
Bạn viết mã một lần rồi chạy nó một triệu lần mà hầu như không tốn thêm chi phí. Mọi lực cấu trúc dường như đều vận hành theo hướng ngược lại. Có lẽ sau khi AI thay thế hết việc làm của chúng ta thì điều đó lại khả thi hơn
How to Do Nothing của Jenny Odell thật sự là một cuốn sách tuyệt vời. Có thể nó hơi khác với nhóm độc giả điển hình của Hacker News, nhưng tôi rất khuyến nghị cho bất kỳ ai bắt đầu cảm nhận áp lực “năng suất” giả tạo mà nền kinh tế chú ý áp đặt
Những dự án khác của Jenny Odell cũng đáng xem. Ví dụ như The Bureau of Suspended Objects(https://www.jennyodell.com/bso-cjm.html)
Cùng mạch đó, tôi cũng khuyên đọc Saving Time của Jenny Odell. Đó là một cuốn sách điềm tĩnh nhưng rất cấp tiến, và cá nhân tôi thấy còn hay hơn trong hai cuốn. Mạch kể của nó tập trung hơn
Vượt xa một feed cá nhân đơn giản, tôi muốn một feed có giới hạn thời gian và không gây xao nhãng
Sẽ thật tuyệt nếu nó gom toàn bộ nội dung bài viết tôi theo dõi lại, rồi chọn tổ hợp mục sao cho mỗi ngày chỉ còn khoảng 30 phút để đọc. Phải bao gồm tất cả: bài blog, bài báo, tweet, v.v.
Dù là dùng ChatGPT hay công cụ khác, tôi muốn lọc ra những nội dung “bổ dưỡng” nhất và ưu tiên thứ có giá trị hơn là các cuộc cãi vã. Sau đó tôi muốn gửi chúng sang Kindle hoặc máy tính bảng reMarkable để đọc, tránh xa màu sắc, ánh chớp và Internet tốc độ cao
Bước tiếp theo là có thể đăng ký feed của bạn bè, để thỉnh thoảng cũng nhận được nội dung “khách mời” từ feed của họ
Tôi thích ý tưởng thêm phần tóm tắt bằng GPT, và nếu người khác cũng quan tâm thì có lẽ tôi có thể sắp xếp lại rồi chia sẻ. Hiện giờ nó chỉ là một ứng dụng JavaScript đơn giản chạy cục bộ, nhưng ý tưởng này có vẻ còn hay hơn tôi nghĩ ban đầu
Hình như là Douglas Engelbart, nhưng tôi không tìm được tài liệu liên quan đến agent. Cũng có thể là một chuyên gia công nghệ khác
Tôi chú ý và đồng cảm với quyết định có chủ đích là lúc đầu không nhất thiết phải làm kiểm thử tự động. Tôi đã mất khá lâu để vượt qua cảm giác khó chịu khi không viết test, nhưng giờ với các dự án đồ chơi cá nhân tôi cũng tiếp cận tương tự
Quá nhiều dự án đã chết ngay trong ngày đầu tiên. Đó lẽ ra phải là lúc lấy đà, nhưng tôi lại mất hứng vì bận dựng hạ tầng test và pipeline CI
Giờ tôi làm theo tiêu chí là chỉ thêm test khi việc thiếu test trở thành vấn đề thực sự
Những gì bắt buộc trong một dự án trưởng thành với nhiều lập trình viên và codebase lớn có thể lại cồng kềnh trong một dự án nhỏ do một người làm
Sau đó tôi tập trung thêm test tạm thời mỗi khi phát sinh vấn đề
Vài năm trước tôi làm một máy phân tích khí hô hấp như một dự án cá nhân, và viết phần mềm kết nối qua Bluetooth để hiển thị dữ liệu theo thời gian thực. Unit test cực kỳ hữu ích cho các hàm phải tính toán khoa học chính xác, nhưng nhìn lại thì việc test các phần khác của giao diện gần như là lãng phí thời gian
Khi đã đủ chắc rằng các hàm đó sẽ không còn thay đổi nữa, tôi xóa hết test. Khi phát triển một mình, chỉ kiểm thử thủ công đôi khi cũng là đủ
Tôi đã tạo một tài khoản ẩn danh mới để có thể thành thật nói về tương lai
Tôi rất ngạc nhiên vì bài này như thể do chính tôi trong tương lai viết ra. Có quá nhiều điểm chung với tác giả đến mức khó tin
Tôi đã nhận ra mình bị burnout và đang lên kế hoạch nghỉ việc vào đầu năm sau. Đó cũng là lý do tôi tạo tài khoản ẩn danh. Chắc hẳn có nhiều người cảm thấy tương tự
Điều còn đáng ngạc nhiên hơn là những gì tác giả đã làm gần như trùng hệt với điều tôi vẫn mơ mộng muốn thử trong thời gian nghỉ. Tôi đã nghĩ về cách tham gia vào open web/IndieWeb, và dự định làm một ứng dụng để thử nghiệm trong lĩnh vực này
Ngay cả những băn khoăn kỹ thuật như làm sao để các bài đăng hiếm hoi không bị chôn vùi trong dòng lũ, hay nên dùng ngôn ngữ và công nghệ nào, cũng rất giống nhau. Mảng web dev của tôi đang chậm khoảng 10 năm, nhưng tôi cũng đã nghĩ tới chuyện thử làm gì đó bằng công nghệ web hiện đại
Một mặt, tôi thấy vui vì những suy nghĩ và cảm xúc gần đây của mình được xác nhận. Tôi có cảm giác mình đang đi đúng hướng. Mặt khác, tôi vẫn buồn và có chút ghen tị vì tác giả đã làm được trước
Hồi đó tôi muốn có RSS reader của riêng mình. Tôi ghét các reader có sẵn, và muốn một reader trông như một blog bình thường chứ không phải hộp thư đến, đồng thời có thể tùy ý thiết kế theo ý mình. Thế là tôi làm một trình phân tích RSS feed và thiết kế nó để trông giống blog thông thường của tôi
Sau đó tôi sửa nó để nếu RSS feed chỉ có phần tóm tắt thì nó sẽ lấy cả bài đầy đủ. Tôi không muốn phải nhấp ra ngoài reader để xem toàn bộ bài viết; tôi muốn mọi thứ đều nằm trong feed reader. Khi đã có một trình scraper trang cơ bản, tôi cũng dùng nó cho các site không có RSS, và nó đặc biệt hữu ích khi mạng xã hội bắt đầu bùng nổ
Tôi có thể xem đúng nội dung mình muốn ngay trong feed mà không cần vào các mạng xã hội thật. Vì là thứ đã 20 năm tuổi nên nó dùng các công nghệ cũ như PHP và XSLT, và đến giờ vẫn vậy
Dù sao thì tôi rất khuyến khích tự làm lấy. Đây là một dự án rất thú vị. Nó cũ kỹ, thô ráp, việc scraping cũng không hoàn hảo nên đôi khi không ra được nội dung tôi muốn, nhưng nó là của tôi, và tôi thích cái reader đã đồng hành với mình mỗi ngày suốt 20 năm qua
Không có lý do gì để một nỗ lực tương tự lại không có tác dụng. Tôi cũng đâu phải người đầu tiên hiện thực hóa một personal reader
Điều thú vị là khi tôi lướt lại bài viết IndieWeb mà mình từng dẫn link, tôi có cảm giác gần như chỉ đang lặp lại nguyên ý tưởng trong đó. Kiểu lời khuyên như “đừng cố làm phần mềm cho tất cả mọi người, hãy làm cho chính bạn”
Nếu bạn cố làm nó đủ phổ quát và đủ dễ cho người khác dùng, bạn có thể phải chấp nhận những thỏa hiệp làm hại chính khả năng sử dụng của mình, hoặc thiết kế cho những người dùng tưởng tượng thậm chí còn không tồn tại. Ý là hãy ích kỷ một chút để làm nó hữu ích hơn cho chính mình
Thật sự rất mới mẻ. Trong một năm qua tôi đã trải qua một hành trình burnout/phục hồi rất giống vậy, và nhờ làm ra phần mềm cá nhân hữu ích mà tôi bắt đầu thấy vui với công việc trở lại
Một lợi ích lớn khác là có thể thoải mái dùng những công nghệ “phi chính thống” mà mình muốn. Những thứ như tạo file thực thi PHP dạng single-binary hiện đại, dùng SQLite trong môi trường production, hay triển khai không cần Docker đều mang lại niềm vui
Những việc này cũng tạo hiệu ứng lan sang công việc chính. Nhiều lần tôi phát hiện ra kỹ thuật và tối ưu mới trong repo cá nhân rồi mang áp dụng vào công việc
Điều thú vị là các kỹ sư thường hay mày mò đủ thứ bên lề, rồi mang những gì học được vào công việc dưới dạng hữu ích, đôi khi còn rất có giá trị. Thế nhưng đôi khi nhà tuyển dụng lại hạ thấp những nỗ lực đó hoặc kìm hãm sự nhiệt tình
Có thể là do tôi đã làm ở không đúng kiểu tổ chức. Dù sao thì thật mừng vì bạn đã thu được lợi ích từ những hiệu ứng lan tỏa đó
Tôi thích tư duy theo feed hơn là một danh sách kiểm tra những thứ phải đọc/tiêu thụ. Tôi đã thử vài trình đọc RSS trong nhiều năm nhưng chưa gắn bó lâu dài với cái nào
Tôi từng nghĩ không biết có cần quản lý thêm một hộp thư đến nữa hay không. Dù vậy, tôi định sẽ xem thử feedi(https://github.com/facundoolano/feedi)
Trước khi thiết lập, tôi thường bấm lung tung vô định xem HN có bài mới gì không, Reuters có gì không. Trải nghiệm của tôi trùng khớp với https://news.ycombinator.com/item?id=38642092
Mail cá nhân, mailing list và RSS feed đều tập trung về một chỗ. Nếu lọc theo từng spool riêng và dùng thêm một email client mạnh như mutt thì đây là một trải nghiệm tích hợp khá dễ chịu
Có vẻ tác giả đã thêm xác thực để có thể truy cập ứng dụng ở bất cứ đâu
Thay vào đó, tôi tự hỏi liệu có thể hoặc có dễ hơn khi đặt nó sau VPN, rồi làm cho VPN đó có thể truy cập từ mọi nơi hay không
Tôi muốn truy cập an toàn vào webapp cá nhân và đang tìm cách tiếp cận đơn giản nhất. Mỗi khi nhìn vào xác thực, tôi lại thấy như một mê cung của khái niệm, giao thức và thư viện, và tôi không muốn bảo trì nó
Tôi đang host vài ứng dụng như Home Assistant trên Raspberry Pi ở nhà, rồi cài Tailscale trên Pi đó và điện thoại, và nó hoạt động rất tốt. Việc xác thực cần làm chỉ là “đăng nhập vào Tailscale trên từng thiết bị”
Xét về độ dễ để tạo một mạng an toàn giữa các thiết bị của chính mình, tôi thực sự rất khuyến nghị Tailscale
Chừng đó là đủ để “bảo vệ” ứng dụng của tôi, vốn chỉ host các mẩu văn bản được cắt từ website khác
Có nhiều cách, nhưng cốt lõi là đặt điểm cuối VPN và webapp cùng một chỗ, ví dụ cùng một máy hoặc cùng một mạng, rồi giới hạn truy cập webapp từ các vị trí khác
Caddy được cấu hình chỉ reverse proxy các request đến từ mạng nội bộ hoặc VPN, còn nếu không thì trả về 404. Vì vậy nếu không ở trong VPN hoặc mạng nhà thì sẽ không thấy gì cả
Tùy việc bạn có mở mạng cho khách hay không và đang chạy những dịch vụ nào, có thể bạn sẽ cần VLAN hoặc một mạng guest riêng. Nhiều dịch vụ tôi chạy ở nhà cũng có xác thực mật khẩu riêng, và tôi dùng nó cùng với giới hạn qua VPN
Đây là cách đầu tiên tôi nghĩ ra nên có thể vẫn không an toàn vì những lý do nằm ngoài chuyên môn của tôi. Điểm cộng là tôi cũng chạy Pi-hole trong cùng file compose, nên khi điện thoại kết nối VPN thì nghiễm nhiên có thêm chặn quảng cáo từ xa “miễn phí”
Tailscale dễ thiết lập hơn và UI cũng đẹp hơn, nhưng tôi đã dừng dùng vì nó ngốn pin nhiều trên iOS. Việc phải “tin tưởng server của người khác” cũng là một vấn đề, nhưng nếu không vì chuyện pin thì có lẽ tôi vẫn sẽ chấp nhận thêm rủi ro để đổi lấy sự tiện lợi
Ứng dụng WireGuard cũng có vài tính năng tiện. Bạn có thể chỉ định không chạy trên những mạng nhất định như ở nhà, để khi ra ngoài nó tự bật và khi về nhà thì tự tắt
Điều này gần một cách đáng ngạc nhiên với thứ tôi từng nghĩ là cần có trên một du thuyền đường dài. Đặc biệt là ngoài khơi xa, kết nối rất chập chờn, nên nếu có thêm hai thứ nữa thì sẽ gần như hoàn hảo
Cần có nút đồng bộ ngay bây giờ cho những lúc chỉ kết nối thoáng qua, như khi đi ngang một hòn đảo có sóng LTE. Ngoài ra, mặc định nó nên xử lý theo kiểu Readability và có bộ nhớ đệm cục bộ để có thể đọc offline toàn bộ nội dung, bao gồm cả hình ảnh