- सॉफ़्टवेयर इंडस्ट्री और पारंपरिक सोशल मीडिया से थकने के बाद Mastodon भी आज़माया, लेकिन असल में ज़रूरत लोगों-केंद्रित टाइमलाइन की नहीं बल्कि वेब की लिखाइयों और नोटिफ़िकेशन को एक साथ देखने वाले व्यक्तिगत फीड रीडर की थी
- लक्ष्य RSS रीडर की ईमेल-इनबॉक्स जैसी जमा होती सूची नहीं, बल्कि Twitter·Mastodon होम फीड की तरह हर बार खोलने पर दिलचस्प कंटेंट बहता दिखाने वाला स्ट्रीम-आधारित इंटरफ़ेस था
- डिज़ाइन के मानदंड user experience > operations convenience > development convenience थे, और htmx·hyperscript, monolithic Web app, SQLite, Python, gevent और Huey extension जैसे ऐसे विकल्पों को प्राथमिकता दी गई जिन्हें सरलता से चलाया जा सके
- वास्तविक उपयोग के दौरान ऐप के भीतर लेख पढ़ना, बाद में पढ़ने के लिए pin, bookmark, स्रोत की प्रकाशन आवृत्ति के अनुसार सॉर्टिंग, और स्क्रॉल करते समय अपने-आप “पहले ही देखा गया” चिह्नित करने जैसी सुविधाएँ जुड़ती गईं
- लगभग 3 महीने के ढीले-ढाले काम के बाद feedi बनाया गया, और कई महीनों तक इसे “इंटरनेट का फ्रंट पेज” की तरह इस्तेमाल करते हुए उपभोग की जाने वाली जानकारी पर नियंत्रण का एहसास फिर से मिला
बर्नआउट के बाद वेब इस्तेमाल करने का तरीका फिर से खोजना
- लगातार खराब प्रोजेक्ट्स और सॉफ़्टवेयर इंडस्ट्री से मोहभंग के कारण करियर बर्नआउट का सामना करना पड़ा
- काम कम किया, नौकरी छोड़ी और इलाज शुरू किया, साथ ही खाने, व्यायाम और ध्यान जैसी आदतों को सुधारा
- कुछ समय के लिए प्रोग्रामिंग और सॉफ़्टवेयर से जुड़ी पढ़ाई से दूरी बनाई, और आख़िरी बचा सोशल मीडिया Twitter भी छोड़ दिया
- How to Do Nothing पढ़ते हुए वैकल्पिक ऑनलाइन कम्युनिटी के रूप में Mastodon को फिर से देखने का मन हुआ
Mastodon में दिखी सीमाएँ
- Mastodon algorithmic mediator के बिना कालक्रमानुसार फीड देता है, जिससे फीड पर फिर से नियंत्रण होने का एहसास मिलता है
- सॉफ़्टवेयर इंडस्ट्री और वेब को लेकर इसी तरह की असहजता महसूस करने वाले लोग RSS, BBS, digital gardens, webrings जैसे पुराने वेब तत्वों को फिर से देख रहे थे या अधिक खुला और स्वतंत्र वेब कल्पना कर रहे थे
- वास्तविक उपयोग का उद्देश्य microblogging से अधिक information hub जैसा था
- लोगों को follow करने का कारण यह था कि वे जब अपनी वेबसाइट पर कुछ पोस्ट करें तो उसकी सूचना मिल सके
- bots को follow करने का कारण link aggregator कंटेंट पाना था
- IndieWeb के social readers की अवधारणा देखने के बाद यह निष्कर्ष निकला कि ज़रूरी टूल Mastodon नहीं, बल्कि सीधे अपने हिसाब से ढाला जा सकने वाला फीड रीडर है
व्यक्तिगत रीडर के उपयोगकर्ता लक्ष्य
- सामान्य RSS रीडर की ईमेल-इनबॉक्स जैसी लंबित सूची नहीं, बल्कि ऐप खोलते ही दिलचस्प कंटेंट बहता हुआ दिखाने वाला स्ट्रीम चाहिए था
- फीड में कई स्रोत एक साथ मिले होने चाहिए थे
- ब्लॉग, मैगज़ीन, न्यूज़ साइट्स, link aggregator के लेख
- Mastodon, Goodreads, GitHub जैसे व्यक्तिगत अकाउंट नोटिफ़िकेशन
- अलग-अलग स्रोतों के डेटा फ़ॉर्मैट भिन्न होने पर भी एक जैसा रूप और अनुभव देने के लिए parsing customization की ज़रूरत थी
- पूरी तरह के IndieWeb reader की social features इस implementation के दायरे में नहीं थीं
- टिप्पणी करने के लिए दूसरा टैब खोलना समस्या नहीं था
- कंटेंट तीसरे पक्ष की साइटों पर बिखरा हो, तब भी ठीक था
- अल्पकालिक लक्ष्य यह जल्दी जाँचना था कि क्या यह टूल वेब जानकारी का मुख्य, बल्कि एकमात्र स्रोत बन सकता है; नहीं बनता तो प्रोजेक्ट तुरंत छोड़ने की योजना थी
विकास सिद्धांत और दायरा
- विकास सिद्धांत
user > ops > devथा- काम की प्राथमिकता और डिज़ाइन trade-off में development convenience से ऊपर operations convenience को रखा गया
- और उससे भी ऊपर user experience को रखा गया
- चूँकि यह व्यक्तिगत ऐप था, इसलिए “user first” का मतलब खुद इस्तेमाल करते हुए अपनी ज़रूरतें पहले पूरी करना था
- किसी आदर्श उपयोगकर्ता की कल्पना करने से अधिक उपयोगी यह लगा कि अपने लिए ergonomically उपयुक्त टूल बनाया जाए
- यह प्रोजेक्ट learning project या portfolio project नहीं होना चाहिए था
- लक्ष्य productivity नहीं, बल्कि सॉफ़्टवेयर डेवलपमेंट के आनंद से फिर जुड़ना था
- यह आनंद “कुछ बनाने” से अधिक “खुद बनाई चीज़ इस्तेमाल करने” से आना चाहिए था
- एक ही target user मान लेने से कई फ़ैसले टाले जा सके
- अभी ज़रूरी न होने वाला user authentication बाद के लिए टाल दिया गया
- Kindle पर भेजने जैसी बहुत विशिष्ट सुविधाएँ शुरुआती चरण में ही ली जा सकीं
- फीड parser customization या Mastodon login जैसी चीज़ों में programming knowledge को पूर्वशर्त माना जा सका
UI और आर्किटेक्चर का चयन
- सिर्फ़ लैपटॉप नहीं बल्कि फ़ोन पर भी पहुँच हो, इसलिए यह Web application होना ज़रूरी था
- एक ही इंटरफ़ेस से दोनों डिवाइस को सपोर्ट करने का यह किफ़ायती तरीका था
- परिचित HTML और CSS का उपयोग किया जा सकता था
- state को server पर रखकर डिवाइसों के बीच sync की समस्या हल की जा सकती थी
- Web UI को कुछ हद तक dynamic होना था, लेकिन अलग frontend application या नया framework सीखना नहीं चाहा गया
- boring tech और radical simplicity की सलाह के अनुसार server-side rendering library खोजी गई, और htmx तथा hyperscript साथ में इस्तेमाल किए गए
- operations-friendly बने रहने के लिए deployment और local setup आसान होना चाहिए था, और Docker या Nix जैसी infrastructure को पूर्वशर्त नहीं बनाना था
- Aaron Parecki द्वारा समझाया गया औपचारिक IndieWeb reader Micropub, Microsub, Webmentions जैसे कई protocol-आधारित components में बँटा है, लेकिन व्यक्तिगत उपयोग के लिए इससे development और operations जटिल होते, लाभ ज़्यादा नहीं मिलता
- नतीजतन monolithic Web application चुना गया, और install तथा configuration वाले components कम रखने के लिए database के रूप में SQLite अपनाया गया
भाषा और background tasks
- Go सरल, सर्वसुलभ, garbage collection वाला, काफ़ी तेज़, अच्छी concurrency model वाला और आसानी से deploy होने वाली binaries देने के कारण इस प्रोजेक्ट के लिए उपयुक्त लगता था
- लेकिन Go की एक पंक्ति भी पहले कभी नहीं लिखी थी, और प्रोजेक्ट को learning project में बदलना नहीं चाहा गया
- पहले से परिचित भाषाओं में सबसे तेज़ prototyping की सुविधा देने के कारण Python चुना गया
- Python में environment और dependencies, खासकर host OS libraries पर निर्भरता, एक कमी बनी रही
- periodic feed polling के लिए अलग component नहीं बढ़ाना था, और जाँच के बाद gevent तथा Huey के mini-huey extension का उपयोग कर application process के भीतर ही background tasks चलाए गए
- इसके बदले Python में HTTP, feed parsing और scraping के लिए अच्छे libraries उपलब्ध थे
टेस्ट टालने के कारण
- शुरुआत में tests न लिखने का फ़ैसला किया गया
- क्योंकि features को जोड़ने, हटाने और इधर-उधर करने के साथ प्रयोग करने की योजना थी, इसलिए unit tests के रखरखाव की लागत उसके मूल्य से अधिक लगी
- छोटे logic bugs स्वीकार्य थे, और चूँकि यह रोज़ खुद इस्तेमाल किया जाने वाला ऐप था, उम्मीद थी कि महत्वपूर्ण bugs समय के साथ सामने आ जाएँगे
- भरोसा दिलाने में integration tests अधिक मूल्यवान लगते थे, लेकिन इस प्रोजेक्ट के कई bugs बाहरी sources के integration और UI में आते थे
- integration tests कुछ bugs और regressions को पहले पकड़ सकते थे, लेकिन शुरुआती लागत के हिसाब से उनका मूल्य पर्याप्त नहीं लगा
वास्तविक उपयोग ने कैसे features तय किए
- हर दिन अंतिम उपयोगकर्ता के रूप में खुद इस्तेमाल करने से ideas, experiments और priorities तय होती गईं
- कई UI layouts और features आज़माने के बाद उपयोग का पैटर्न स्थिर हुआ
- ऐप खोलना
- मुख्य फीड स्क्रॉल करना
- बाद में पढ़ने के लिए items pin करना
- अभी पढ़ने के लिए items खोलना
- बाद में संदर्भ के लिए items bookmark करना
- ऐप छोड़े बिना लेख पढ़ने की सुविधा चाहिए थी, और एक वजह paywall तथा consent pop-ups से बचना भी था
- HTML content extraction के लिए कई Python libraries आज़माई गईं, लेकिन Firefox द्वारा उपयोग किए जाने वाले readability जितना अच्छा कुछ काम नहीं कर पाया
- readability एक JavaScript package होने के कारण वैकल्पिक dependency के रूप में Node.js जोड़ना पड़ा
फीड सॉर्टिंग और “पहले ही देखा गया” चिह्नित करना
- बुनियादी features आने के बाद भी सिर्फ़ प्रकाशन-तिथि के क्रम से दिलचस्प कंटेंट ढूँढना मुश्किल था
- कम प्रकाशित होने वाले ब्लॉग लेख Mastodon toot के पीछे दब जाते थे
- मैगज़ीन के लंबे लेख दैनिक न्यूज़ आर्टिकल्स के पीछे छिप जाते थे
- माना गया कि follow किए गए सभी sources रुचिकर हैं, इसलिए कम प्रकाशन आवृत्ति वाले sources का कंटेंट पहले दिखना चाहिए
- अगर कोई मासिक newsletter पिछले कुछ दिनों में आया हो, तो उसे microblogging या दैनिक समाचार से ऊपर दिखना चाहिए था
- sources को “frequency buckets” में वर्गीकृत किया गया और फीड को इस तरह सॉर्ट किया गया कि कम आवृत्ति वाले bucket पहले आएँ
- कम प्रकाशित होने वाला कंटेंट हर बार ऐप खोलने पर ऊपर चिपका न रहे, इसके लिए स्क्रॉल करने पर items को अपने-आप “already seen” चिह्नित करने की सुविधा जोड़ी गई
- इस तरीके से हमेशा नया कंटेंट दिखता रहा और कम होने वाले अपडेट भी छूटे नहीं
लोकल से VPS तक
- शुरुआत में लैपटॉप के terminal tab में ऐप चलाकर विकास और उपयोग साथ-साथ किया गया
- जब फीड में दिखने वाला कंटेंट पसंद आने लगा, तो इसे local network के Raspberry Pi server पर डाल दिया गया ताकि हमेशा पहुँचा जा सके
- Raspberry Pi पर लगातार इस्तेमाल होने के बाद फ़ोन से पहुँच के लिए mobile rendering सुधारी गई
- जब बाहर रहते हुए भी ऐप की कमी महसूस होने लगी, तब इसे VPS पर deploy किया गया
- VPS deployment ने टाले गए authentication और multi-user support जोड़ने पर मजबूर किया, और कुछ दोस्तों को beta testing access देना संभव हुआ
- VPS setup ने domain खरीदने और यह वेबसाइट बनाने की शुरुआत कराई, और इस तरह यह शुरुआती IndieWeb आदर्शों के और क़रीब पहुँचने की प्रक्रिया बन गया
feedi का नतीजा
- लगभग 3 महीने के ढीले-ढाले काम के बाद व्यक्तिगत फीड रीडर feedi बनाया गया
- feedi किसी पूर्ण उत्पाद से ज़्यादा Emacs configuration जैसा है, जो लगातार आधा टूटा हुआ रहते हुए भी उपयोगकर्ता के शरीर-मन के हिसाब से ढल जाता है
- productivity के नज़रिए से इसे सही ठहराना मुश्किल है, लेकिन अपनी शर्तों के हिसाब से बनाया गया टूल होने के कारण यह संतोष देता है
- कई महीनों तक feedi को “front page of the internet” की तरह इस्तेमाल किया गया
- व्यक्तिगत रीडर का उपयोग करते हुए उपभोग की जाने वाली जानकारी पर फिर से नियंत्रण मिला, दिलचस्प ब्लॉग और मैगज़ीन को सक्रिय रूप से खोजा गया, और खोज तथा आश्चर्य के लिए खुद को अधिक खुला पाया गया
1 टिप्पणियां
Hacker News की राय
urlwatch(https://urlwatch.readthedocs.io/en/latest/) सेट करना काफी मज़ेदार रहा। खासकर जब Puppeteer boilerplate से आगे बढ़कर Chrome instance के जरिए JavaScript साइट्स scrape कर पाते हैं, तो ऐसा महसूस होता है कि वेब को खींचकर देखने के बजाय उसे अपनी तरफ push करवाकर control किया जा रहा है
वेबसाइटों को बिना ज़्यादा बोझ के monitor पर रखकर सुबह सरसरी तौर पर देख लेने की ताकत बड़ी है। पसंदीदा कंपनी की job postings, मौजूदा कंपनी की hiring/deadlines, sale·restock·refurb का इंतज़ार कर रहे products, COVID wastewater stats, apartment listings, दिलचस्प GitHub releases, और अहम websites के terms में बदलाव तक track किए जा सकते हैं
निजी तौर पर मैं RSS reader और Telegram bot भी self-host करता हूँ और experiments के लिए छोटे HTTP sites भी अक्सर बनाता हूँ, इसलिए DigitalOcean $5 Droplet इस्तेमाल करता हूँ, लेकिन इसे हर दिन एक ही समय पर चलना ज़रूरी नहीं है, इसलिए laptop पर भी हो सकता है
यह personal use के लिए है, इसलिए सिर्फ अपनी रुचि के topics पर Twitter updates का summary मिलता है, और site खुद, ज़हरीली बहसें, व परेशान करने वाले ads से बचा जा सकता है
IT की मौजूदा हालत पर इतना गुस्सा है कि ठीक से व्यवस्थित करके लिखना मुश्किल है, लेकिन कभी-कभी मैं “मेरा IT प्रभारी” जैसा concept सोचता हूँ। जैसे मोहल्ले का नाई, family doctor, tailor, baker—वैसा कोई, जो digital life का एक हिस्सा संभाले
वह छोटा local infrastructure रखे, personalized feeds बनाए, privacy और digital health का ध्यान रखे, और simple interfaces या open protocols के जरिए feed reader से connect कराए। movies, लेख, memes, मज़ेदार videos तक cover करे, लेकिन core में profit-optimization algorithms नहीं, बल्कि बात करने लायक एक इंसान हो
local community द्वारा चलाए जाने वाले data center को library जैसा रखने या home internet के जरिए simple content services देने के ideas भी दिमाग में आते हैं। इसलिए Veilid(https://gitlab.com/veilid/veilid) जैसी सोच अच्छी लगी
Feediverse पर जाने के बाद लोग ज़्यादा स्वस्थ महसूस कर रहे हैं, यह सुनना पहली बार नहीं है। मैं खुद Puppeteer के ऊपर scripts और mini apps रखकर, local llamacpp से summaries और recommendations चला रहा हूँ, और आगे इसे और polish करके दोस्तों और परिवार को recommend करना चाहता हूँ
इन scripts का नाम मैंने “not a browser” रखा है। मैं ऐसा web चाहता हूँ जो HTML/CSS/JS को data के साथ serve न करे, बल्कि सिर्फ data दे और उसे कैसे दिखाना है यह user तय करे
user के खिलाफ काम करने वाले algorithms नहीं, ad-driven systems नहीं; ज्यादातर software ऐसे हैं जो user को पहले रखते हैं और open protocols की बात करते हैं। अगर आप IT industry में हैं और अपना server चला सकते हैं तो यह संभव है, लेकिन सवाल है कि जो लोग ऐसा नहीं कर सकते उनका क्या
personal “IT प्रभारी” का idea दिलचस्प है। जो लोग big tech companies और algorithms से निकलकर कुछ ज़्यादा personal इस्तेमाल करना चाहते हैं, लेकिन जिनके पास technical means नहीं हैं, क्या उन्हें ऐसी service दी जा सकती है—यह जानने की जिज्ञासा है
medical data भी ऐसा ही है। मुझे यह पसंद नहीं कि मेरे medical records MyChart और कई proprietary systems में stored हैं और मेरे पास control नहीं है। जेब में supercomputer है, फिर मैं अपने records की copy खुद क्यों नहीं रख सकता और appointments पर doctor के साथ selectively share क्यों नहीं कर सकता
यह भी अजीब है कि hospitals को अभी भी एक-दूसरे को fax करना पड़ता है। एक button से मुझे अपना data share कर पाना चाहिए। Apple Health कुछ features में इसके सबसे करीब है, लेकिन US में adoption लगभग न के बराबर दिखता है, और वह भी Apple users के पक्ष में है। health data को, भले ही Apple Health जैसी locally running form में हो, proprietary systems में बंद नहीं होना चाहिए; open protocols और implementations का ecosystem चाहिए
marketing और greed के internet पर कब्ज़ा करने से पहले थोड़े समय के लिए एक अच्छा दौर था। end users के लिए फायदेमंद apps वाले Synology NAS जैसे products, और उन्हें support करने वाला “मेरा IT प्रभारी” जुड़ जाए, तो यह अच्छी तरह काम कर सकता है
अगर structure personal data और पैसा निचोड़ने के लिए न हो, तो user के लिहाज से यह लगभग utopia होगा, लेकिन economics शायद low-margin और high-risk business जैसी होगी। जैसे file loss की liability बड़ा मुद्दा है
code एक बार लिखकर लगभग zero extra cost पर लाखों बार चलाने वाला structure है। सारी structural forces उल्टी दिशा में काम करती दिखती हैं। शायद जब AI हमारी सारी jobs replace कर देगा, तब यह उल्टा ज़्यादा संभव हो जाए
Jenny Odell की How to Do Nothing वाकई शानदार किताब है। Hacker News के सामान्य readership से थोड़ी अलग हो सकती है, लेकिन जो लोग attention economy द्वारा थोपी गई नकली “productivity” pressure महसूस करने लगे हैं, उन्हें strongly recommend करूँगा
Jenny Odell के दूसरे projects भी देखने लायक हैं। उदाहरण के लिए The Bureau of Suspended Objects(https://www.jennyodell.com/bso-cjm.html) है
इसी संदर्भ में Jenny Odell की Saving Time भी recommend करूँगा। शांत लेकिन बहुत radical किताब है, और निजी तौर पर मुझे दोनों में यह ज़्यादा बेहतर लगी। narrative ज़्यादा focused था
सिर्फ़ एक साधारण व्यक्तिगत फ़ीड से आगे, मुझे समय-सीमित और बिना ध्यान भटकाने वाली फ़ीड चाहिए
अच्छा होगा अगर यह मेरे फ़ॉलो किए हुए सभी लिखित content को इकट्ठा करे और हर दिन लगभग 30 मिनट पढ़ने लायक items का मिश्रण चुन दे। इसमें ब्लॉग पोस्ट, articles, tweets वगैरह सब शामिल होने चाहिए
ChatGPT हो या कोई और tool, उसका इस्तेमाल करके सबसे “पोषक” content छांटे और बहस-मुबाहिसे से ज़्यादा मूल्यवान content को प्राथमिकता दे। इसके बाद मैं इसे Kindle या reMarkable tablet पर भेजकर रंग, चमक-दमक और तेज़ internet से दूर पढ़ना चाहूंगा
अगले कदम के तौर पर, मैं किसी दोस्त की फ़ीड subscribe करके कभी-कभी उस फ़ीड का “guest” content भी पाना चाहूंगा
GPT summaries जोड़ने का idea अच्छा लग रहा है, और अगर दूसरों को भी रुचि हो तो मैं इसे व्यवस्थित करके share कर सकता हूं। अभी यह local में इस्तेमाल होने वाला एक साधारण JavaScript app है, लेकिन यह idea मेरे मूल खयाल से ज़्यादा शानदार लगने लगा है
शायद Douglas Engelbart थे, लेकिन agents से जुड़ी material नहीं मिल पा रही। कोई और technical expert भी हो सकता है
शुरू में automated tests न करने का जानबूझकर लिया गया फ़ैसला ध्यान खींचता है, और मैं इससे सहमत हूं। tests न लिखने पर जो अजीब-सी बेचैनी होती है, उसे पार करने में काफ़ी समय लगा, लेकिन निजी toy projects में अब मैं भी लगभग ऐसा ही करता हूं
बहुत सारे projects पहले ही दिन के आसपास मर गए। उस समय असल में momentum बनना चाहिए था, लेकिन test infrastructure और CI pipeline बनाते-बनाते उत्साह खत्म हो गया
अब मेरा नियम है कि tests की कमी सचमुच समस्या बने, तो उसी समय उन्हें जोड़ता हूं
कई developers और बड़े codebase वाले mature project में जो चीज़ ज़रूरी होती है, वह छोटे एक-person project में बोझिल हो सकती है
उसके बाद जब भी समस्या आती है, अस्थायी तौर पर test जोड़ने पर focus करता हूं
कुछ साल पहले मैंने personal project के तौर पर breathing gas analyzer बनाया और Bluetooth से connect करके data real-time दिखाने वाला software लिखा। scientific calculations ठीक-ठीक करने वाले functions के लिए unit tests बहुत उपयोगी थे, लेकिन interface के दूसरे हिस्सों के tests पीछे मुड़कर देखने पर लगभग समय की बर्बादी थे
जब यह भरोसा हो गया कि function अब और नहीं बदलेगा, तो मैंने सभी tests हटा दिए। अकेले develop करते समय manual testing ही पर्याप्त हो सकती है
भविष्य के बारे में ईमानदारी से बात करने के लिए मैंने नया anonymous account बनाया
यह post ऐसी लगी जैसे इसे भविष्य के मेरे ने लिखा हो, और मैं हैरान रह गया। लेखक से इतनी समानताएं थीं कि यकीन करना मुश्किल था
मैं burnout को समझ चुका था और अगले साल की शुरुआत में नौकरी छोड़ने की योजना बना रहा था। anonymous account बनाने की वजह भी यही थी। शायद बहुत से लोग ऐसा ही महसूस करते होंगे
और भी चौंकाने वाली बात यह है कि लेखक ने जो किया, वह लगभग वही है जिसे मैं break के दौरान करने की कल्पना कर रहा था। मैं सोच रहा था कि open web/IndieWeb में कैसे भाग लूं, और इस क्षेत्र में experiment करने के लिए app बनाने की योजना थी
दुर्लभ posts को flood में दबने से बचाने की समस्या, या कौन-सी languages और technologies इस्तेमाल करनी हैं जैसी technical चिंताएं भी मिलती-जुलती थीं। web development में मैं लगभग 10 साल पीछे हूं, लेकिन modern web technologies से कुछ बनाने का विचार भी किया था
एक तरफ, हाल की सोच और भावनाओं की पुष्टि होती महसूस होने से खुशी है। लगता है कि मैं सही रास्ते पर हूं। दूसरी तरफ, यह बात दुख देती है और जलन भी रहती है कि लेखक ने यह पहले कर लिया
उस समय मुझे अपना RSS reader चाहिए था। मौजूदा readers पसंद नहीं थे; मैं ऐसा reader चाहता था जो inbox नहीं, बल्कि सामान्य blog जैसा दिखे और जिसे मैं अपनी मर्ज़ी से design कर सकूं। इसलिए मैंने RSS feed parser बनाया और उसे अपने सामान्य blog जैसा दिखने के लिए design किया
बाद में मैंने इसे बदलकर ऐसा किया कि अगर RSS feed में सिर्फ़ summary हो, तो वह पूरा लेख खींच लाए। मैं reader के बाहर click करके पूरा लेख नहीं देखना चाहता था; चाहता था कि सब कुछ feed reader के अंदर ही हो। जब basic page scraper बन गया, तो मैंने इसे उन sites पर भी इस्तेमाल किया जिनमें RSS नहीं था, और social media के लोकप्रिय होने पर यह खास तौर पर मददगार रहा
असली social sites पर जाए बिना मैं अपनी feed में सिर्फ़ वही content देख सकता था जो मुझे चाहिए था। यह 20 साल पुरानी चीज़ है, इसलिए PHP और XSLT जैसी पुरानी technologies पर बनी है, और अभी भी वैसी ही है
खैर, मैं strongly recommend करूंगा कि खुद बनाएं। यह मज़ेदार project है। पुराना और rough है, scraping perfect नहीं है इसलिए कभी-कभी मनचाहा content नहीं दिखता, लेकिन यह मेरा है, और 20 साल से रोज़ इस्तेमाल होने वाला reader है, इसलिए मुझे पसंद है
ऐसा कोई कारण नहीं कि मिलती-जुलती कोशिश असरदार न हो। वह personal reader implement करने वाला पहला व्यक्ति भी नहीं था
दिलचस्प बात यह है कि मैंने जिस IndieWeb लेख का link दिया था, उसे फिर से सरसरी तौर पर पढ़ा तो लगा कि मैंने उसी लेख के ideas लगभग जस-के-तस दोहरा दिए थे। सलाह कुछ ऐसी थी: “सबके लिए software बनाने की कोशिश मत करो, अपने लिए बनाओ”
अगर आप इसे general-purpose बनाने और दूसरों के लिए इस्तेमाल में आसान बनाने की कोशिश करते हैं, तो आप अपनी usability को नुकसान पहुंचाने वाले समझौते कर सकते हैं या ऐसे काल्पनिक users के लिए design करने लगते हैं जो मौजूद ही नहीं हैं। मतलब है कि इसे selfishly बनाएं ताकि यह आपके लिए ज़्यादा उपयोगी हो
यह सचमुच ताज़गी भरा था। पिछले 1 साल में मैं बहुत मिलते-जुलते burnout/recovery path से गुज़रा हूं, और उपयोगी personal software बनाते हुए फिर से काम का आनंद लेने लगा
एक और बड़ा फायदा यह है कि मनचाही “non-traditional” technologies खुलकर आज़माई जा सकती हैं। modern single-binary PHP executable बनाना, production में SQLite इस्तेमाल करना, Docker के बिना deploy करना—ऐसी चीज़ें आनंद देती हैं
इस काम का असर मेरी main job पर भी पड़ा। personal repositories में नई techniques और optimizations खोजकर उन्हें अक्सर अपने काम में लाता हूं
यह दिलचस्प है कि tech लोग side में तरह-तरह की चीज़ें छेड़ते रहते हैं, और वहां से सीखी चीज़ों को अपने पेशे में उपयोगी, कभी-कभी मूल्यवान रूप में ले आते हैं। लेकिन employers कभी-कभी ऐसे प्रयासों को कमतर आंकते हैं या enthusiasm को रोकते हैं
हो सकता है मैं गलत तरह के organizations में काम करता रहा हूं। फिर भी, अच्छा है कि आपको उस spillover effect का फायदा मिला
पढ़ने/consume करने वाली चीज़ों की checklist की बजाय मुझे feed mindset पसंद है। कई सालों में मैंने कुछ RSS readers आज़माए, लेकिन लंबे समय तक किसी पर टिक नहीं पाया
लगा कि क्या सच में एक और inbox manage करने की ज़रूरत है। फिर भी feedi(https://github.com/facundoolano/feedi) को देखने का इरादा है
setup से पहले मैं बिना उद्देश्य इधर-उधर click करता रहता था कि HN पर कुछ नया post है क्या, Reuters पर है क्या। मेरा अनुभव https://news.ycombinator.com/item?id=38642092 से मेल खाता है
personal mail, mailing lists, RSS feeds सब एक जगह आ जाते हैं। अलग-अलग spools में filter करके और mutt जैसे powerful email client के साथ इस्तेमाल करें तो काफी अच्छा unified experience बन जाता है
लगता है लेखक ने कहीं से भी app access करने के लिए authentication जोड़ा है
सोच रहा हूँ कि इसके बजाय उसे VPN पर रखना, और उस VPN को कहीं से भी accessible बनाना संभव या ज्यादा आसान होगा क्या
मैं अपने personal webapp को safely access करना चाहता हूँ, लेकिन सबसे आसान तरीका खोज रहा हूँ। authentication देखते ही concepts, protocols और libraries की भूलभुलैया जैसा लगता है, और मैं उसे maintain नहीं करना चाहता
घर के Raspberry Pi पर Home Assistant जैसे कुछ apps host किए हैं, और उस Pi व phone पर Tailscale install किया है; यह बहुत अच्छा काम करता है। authentication में बस “हर device पर Tailscale में login” करना पड़ता है
अपने devices से secure network बनाने की आसानी के मामले में Tailscale की सच में बहुत जोरदार recommendation करूँगा
दूसरे websites से clip किए गए text snippets host करने वाली मेरी application को “protect” करने के लिए यह पर्याप्त है
तरीके कई हैं, लेकिन सार यह है कि VPN endpoint और webapp को एक ही जगह रखें, जैसे same machine या same network पर, और बाकी जगहों से webapp access को restrict करें
Caddy को इस तरह configure किया है कि वह केवल internal network या VPN से आए requests को reverse proxy करे, वरना 404 return करे। इसलिए अगर आप VPN या home network पर नहीं हैं, तो कुछ भी दिखाई नहीं देता
आप guests के लिए network खुला रखते हैं या कौन-सी services चला रहे हैं, इस पर निर्भर करते हुए VLAN या अलग guest network की ज़रूरत हो सकती है। घर पर चलने वाली कई services में अपना password authentication भी है, और उसे VPN restriction के साथ use करता हूँ
यह configuration वह तरीका है जो मुझे पहले सूझा था, इसलिए मेरे expertise से बाहर के कारणों से यह unsafe हो सकता है। फायदा यह है कि उसी compose file में Pi-hole भी चलता है, तो phone के VPN से connect होते ही remote ad blocking भी “free” में मिल जाती है
Tailscale का setup आसान है और UI भी अच्छा है, लेकिन iOS पर battery बहुत खाता था, इसलिए बंद कर दिया। “किसी और के server पर trust” करना भी मुद्दा है, लेकिन battery problem न होती तो सुविधा के लिए शायद अतिरिक्त risk ले लेता
WireGuard app में एक convenient feature भी है। आप specify कर सकते हैं कि कुछ networks पर, जैसे घर पर, इसे न चलाए, ताकि बाहर निकलते ही अपने-आप on हो जाए और घर आते ही off हो जाए
यह cruising yacht पर जिसकी ज़रूरत मुझे लगती थी, उससे हैरान करने वाली हद तक मिलता-जुलता है। खासकर खुले समुद्र में connectivity intermittent होती है, इसलिए दो और चीज़ें हों तो बिल्कुल सही रहेगा
जैसे LTE signal वाली किसी island के पास से गुजरते समय थोड़ी देर connection मिले, तब अभी sync करें दबा सकना चाहिए। साथ ही default रूप से Readability processing और local cache होनी चाहिए, ताकि images सहित सारा content offline पढ़ा जा सके