मेरी वेबसाइट, 'One Binary' (2022)

 (j3s.sh)
3 पॉइंट द्वारा GN⁺ 2023-10-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • निजी वेबसाइट को single binary के रूप में बनाने से, एक व्यक्ति पूरी संरचना समझकर खुद maintain कर सकता है, जिससे मौजूदा SSG·hosting संयोजनों की dependency का बोझ घटता है
  • Hugo और GitHub Pages जैसे संयोजन service continuity, project maintenance, plugin ecosystem, deployment method, Go जैसी कई बाहरी शर्तों को आधार मानते हैं
  • मैन्युअल HTML editing सरल और स्थिर है, लेकिन common features को बार-बार संभालना कठिन होता है और workflow थकाऊ हो जाता है, इसलिए ऐसा तरीका चाहिए था जिसे अधिक मज़े से adjust किया जा सके
  • Go-आधारित dynamic site, IP दिखाने या RSS feed update करने जैसे static site में झंझट वाले कामों को server-side code से संभालती है और browser नहीं, बल्कि tools को भी तैयार HTML लौटाती है
  • निजी वेबसाइट को छोटा शुरू करके standard library और सरल tools के साथ बढ़ाना ज़्यादा टिकाऊ रहता है; बड़े framework से शुरू करने पर निजी समय में उसके साथ बने रहना मुश्किल होता है

मौजूदा वेबसाइट tools क्यों फिट नहीं बैठे

  • Ghost, Hugo, Jekyll, sr.ht और tarball, मैन्युअल HTML editing तक कई तरीके आज़माए, लेकिन वे निजी मानकों पर खरे नहीं उतरे और दिलचस्पी भी नहीं जगाई
  • सबसे महत्वपूर्ण मानक ऐसा system था जिसे एक व्यक्ति शुरू से अंत तक समझ सके और आसानी से maintain कर सके
    • पढ़ने में आसान code
    • तेज़ feedback loop
    • मज़ा और चतुराई
    • खराब होने पर खुद गहराई से जांच सकने वाली संरचना
  • Hugo जैसे static site generator (SSG) templates और Markdown को input के रूप में लेकर HTML बनाते हैं, और आम तौर पर hosting platform के साथ उपयोग होते हैं
  • Hugo और GitHub Pages के संयोजन के साथ कई maintenance conditions जुड़ी होती हैं
    • GitHub Pages service लगातार चलती रहनी चाहिए
    • GitHub Pages product लगातार maintain होना चाहिए
    • Hugo project और community documentation maintain होने चाहिए
    • plugin ecosystem पर dependency हो सकती है
    • Hugo binary को समय बीतने पर भी लगभग उसी तरीके से HTML generate करना चाहिए
    • GitHub Pages deployment mechanism लगातार काम करता रहना चाहिए
    • Go की ज़रूरत होती है
  • किसी खास Hugo version को pin करके इस्तेमाल करने का तरीका भी है, लेकिन व्यवहार में bugs की वजह से upgrade करने की ज़रूरत पड़ सकती है

मैन्युअल HTML editing के फायदे और सीमाएं

  • अपने नियंत्रण वाली machine पर वेबसाइट host करके, Vim से HTML हाथ से edit करने का तरीका भी चुना था
  • j3s.sh का पहला version इसी तरीके से बना था, और मौजूदा layout ideas में से कई यहीं से आए
  • हाथ से HTML लिखना कठिन manual labor जैसा महसूस होता है, जिससे extreme minimalism की ओर झुकाव होता है
    • styles सीधे HTML के अंदर डालना
    • पूरे site में common features को न्यूनतम रखना
    • styling से काफी बचना
  • यह तरीका सरल, स्थिर और maintain करने में आसान था
    • लिखा हुआ HTML बिना बदलाव के reuse किया जा सकता था
    • कोई external dependency नहीं थी
    • इससे भरोसा मिला कि site लंबे समय तक बनी रहेगी
  • हालांकि common features की templating को अधिक efficient तरीके से संभालना चाहता था, और मौजूदा framework के बिना मज़ेदार ढंग से adjust किया जा सकने वाला तरीका चाहिए था

Go single binary वेबसाइट

  • अगर पूरी वेबसाइट एक ही language में लिखी जाए, तो output को single binary में रखकर deploy किया जा सकता है
  • Go निजी maintenance और सरल deployment के लिए अच्छी तरह फिट होने वाला विकल्प था
    • एक व्यक्ति के लिए maintain करना आसान
    • कम dependencies इस्तेमाल करने की दिशा पर ज़ोर
    • language तुलनात्मक रूप से सरल
    • backward compatibility guarantee है
    • statically compiled binary आसानी से बनाई जा सकती है
    • ज़्यादातर 10 सेकंड से कम में compile हो जाता है
    • standard library अच्छी तरह विकसित है
  • नतीजतन j3s.sh वेबसाइट serve करने वाली एक binary बन गई

dynamic वेबसाइट से मिलने वाली सरलता

  • कुछ मामलों में static generated वेबसाइट की तुलना में dynamic generated वेबसाइट ज्यादा सरल हो सकती है
    • content generation के लिए workaround के बारे में सोचने की ज़रूरत नहीं होती
    • ज़रूरी content तुरंत generate किया जा सकता है
  • visitor का IP address output करने वाला feature Go के http.HandlerFunc से आसानी से implement होता है
    • X-Forwarded-For header पढ़ता है
    • handler को /ip path से जोड़ता है
    • जहां ज़रूरत हो, वही function call किया जा सकता है
  • static site में वही feature implement करने के लिए JavaScript जैसी external dependency की ज़रूरत पड़ सकती है, और JavaScript न होने की स्थिति भी ध्यान में रखनी पड़ती है
    • कुछ readers JavaScript चलाने से इनकार करते हैं
  • अगर server पहले से IP address शामिल HTML लौटाता है, तो client JavaScript न भी समझे तब भी सही response पा सकता है
    • browser के अलावा tools पर भी यही तरीका काम करता है
  • homepage का RSS feed वेबसाइट शुरू होने के समय generate होता है
    • दोस्तों की नई posts फिर से fetch की जा सकती हैं
    • खुद बनाया RSS feed fetcher लंबे समय तक maintenance के बिना चलता रहेगा, ऐसा माना गया
    • इसके internal behavior को ठीक-ठीक समझा गया है

deployment और शुरुआत का तरीका

  • deployment एक छोटी shell script से संभलता है
    • Git repository fetch करता है
    • local branch पीछे हो तो git merge origin/main चलाता है
    • go build से build करता है
    • binary को /usr/local/bin/j3s.sh में move करता है
    • service j3s.sh restart से service restart करता है
  • यह script cronjob के रूप में हर मिनट चलती है, ताकि repository update होने पर site फिर से build हो जाए
    • local में test करके upload करने पर 1 मिनट के अंदर public site में reflect हो जाता है
    • shell थोड़ी पता हो तो 10 सेकंड के अंदर समझ आने जितनी सरल है
  • निजी वेबसाइट आज के web में एक अलग-सा एहसास देती है, और operator जिन चीज़ों को महत्वपूर्ण मानता है उन्हें गहराई से reflect कर सकती है
  • जिन लोगों के लिए static site सही है, वे वही इस्तेमाल करें, लेकिन मिलते-जुलते values रखने वालों के लिए dynamic वेबसाइट आज़माना अच्छा फिट हो सकता है
    • छोटा शुरू किया जा सकता है
    • मज़ेदार ideas बार-बार जोड़े जा सकते हैं
    • अपनी site है, इसलिए hardcoding भी ठीक है
    • Rust, Perl, Python जैसी अपनी पसंद की language में बना सकते हैं
  • शुरुआत छोटी होनी चाहिए
    • पहले index.html बनाएं, और चुनी हुई language से उसे serve करने पर focus करें
    • RSS या Markdown बाद में, ज़रूरत होने पर जोड़ें
    • संभव हो तो standard library जैसे सबसे सरल और maintainable tools इस्तेमाल करें
    • Ruby में Rails के बजाय Sinatra, Python में Flask के बजाय Gin जैसे छोटे विकल्पों पर विचार किया जा सकता है
    • पहले यह भी आज़मा सकते हैं कि 0 libraries के साथ खुद implement किया जा सकता है या नहीं
  • बड़े framework या लगातार breaking changes देने वाले project से शुरू करने पर निजी समय में उसके साथ बने रहना मुश्किल होता है और जल्दी थकान आ सकती है
  • web को और अधिक अजीबपन, उत्साह और personality की ज़रूरत है, और dynamic वेबसाइट बनाकर देखने की कोशिश की सिफारिश की जाती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-10-23
Hacker News की राय

  • मोबाइल पर वेबसाइट की चौड़ाई सही तरह से calculate नहीं हो रही, इसलिए पढ़ने के लिए बाएँ-दाएँ scroll करना पड़ता है
    और यह करते ही उससे ठीक पहले मैंने “मेरे standards बहुत ऊँचे और काफ़ी अलग हैं” जैसा वाक्य पढ़ा, तो सच कहूँ तो थोड़ी हँसी आ गई :)

    • यह HTML से sections या paragraphs जैसी structure वाली लिखाई नहीं है, बस एक साधारण text file को whitespace-preserving pre में render किया गया है, इसलिए यह एक बहुत बड़े paragraph जैसा दिखता है ¯_(ツ)_/¯
    • Safari Reader में भी formatting शून्य है, तो वह भी काफ़ी प्रभावशाली लगा
      अजीब formatting तो अक्सर देखी है, लेकिन बिल्कुल formatting न होना पहली बार देखा
    • Firefox Mobile के reading mode में यह ठीक हो गया, इसलिए असल में यह बस एक button दबाने जितनी असुविधा है
      फिर भी पहली छाप अच्छी नहीं है
    • लेखक की logic और platform के हिसाब से न बनाने वाली बात आपस में टकराती है
      समझ नहीं आता
    • मेरा भी यही विचार था
      अपने काम पर गर्व होना अच्छी बात है, लेकिन मैंने बस इसे न पढ़ने का फैसला किया

  • असली बात यह है कि “इसे simple रखना” आखिर है क्या, और “समझने योग्य” किसे कहते हैं
    ऐसे लेख दिलचस्प बहस को छोड़कर सीधे मान लेते हैं कि उनका approach simple है और उनका goal simplicity है
    abstraction, जैसे libraries या frameworks, services या APIs, जब चुने जा सकते हों, तो उनका इस्तेमाल करना ज़्यादा simple है या न करना?
    अगर उनका इस्तेमाल न करके ख़ुद बनाओ, तो पूरे system के काम करने का तरीका बेहतर समझ में आता है, इसलिए एक मायने में वह ज़्यादा simple है
    लेकिन complexity फिर भी आती है, और कई बार abstraction layer भी ख़ुद बनानी पड़ती है
    उल्टा, अगर उनका इस्तेमाल करो, तो complexity छिप जाती है, इसलिए happy path में system ज़्यादा simple लग सकता है, लेकिन वह complexity फिर भी मौजूद रहती है और छिपी होने की वजह से समझ में नहीं आती
    दोनों तरीके किसी न किसी नज़रिए से साफ़ तौर पर simple लगते हैं, लेकिन उस साफ़पन से आगे बढ़ो तो trade-offs दिखते हैं

    • मान लो तुम apple pie बनाना चाहते हो
      आम तौर पर तुम सामग्री और औज़ार खरीदते हो, और पहले से मौजूद oven में उसे bake करते हो
      लेकिन अगर apple pie शुरू से बनानी हो, तो पहले ब्रह्मांड बनाना पड़ेगा, और शायद तुम वही सबसे simple ब्रह्मांड बनाओगे जो apple pie को support कर सके
      पूरा stack ज़्यादा simple हो सकता है, लेकिन आख़िरी step यानी असली pie बनाना ज़्यादा complex हो सकता है, और उसका स्वाद भी शायद सबसे अच्छा न हो
      बदले में तुम्हें ऐसी pie मिलेगी जिसे तुम first principles से पूरी तरह समझते हो
    • यहाँ बात “simple” और “easy” के फ़र्क़ के ज़्यादा क़रीब लगती है
      Rich Hickey की यह talk आपको पसंद आ सकती है: https://paulrcook.com/blog/simple-made-easy
      किसी चीज़ को बनाना या deploy करना आसान करने के लिए features जोड़े जा सकते हैं, लेकिन उन्हीं additions की वजह से पूरी चीज़ ज़्यादा complex हो जाती है और उसे समझना या problems trace करना कठिन हो जाता है
    • इस लेख के संदर्भ में यह comment ठीक से समझ नहीं आता
      लेखक आखिर में बहुत साफ़ तौर पर कहता है कि हर कोई अपना तरीका चुने
      और यह भी कहता है कि वह ऐसे systems इस्तेमाल करके संतुष्ट नहीं है जिन्हें समझना उसके लिए मुश्किल हो या जो उसके लिए बोझिल हों
      पहले paragraph के बाद भी पढ़ना चाहिए

  • बहुत बढ़िया!
    “आप सबको भी यही करना चाहिए!” — इससे मैं बिल्कुल सहमत नहीं हूँ :)
    maintainability मेरी core values में से एक है, इसलिए आपकी तरह मैं भी अपनी cycle की maintenance ख़ुद करता हूँ
    लेकिन मेरे लिए यह इतनी ऊँची priority नहीं है, इसलिए इस तरह के चुनाव मेरे लिए समझदारी नहीं लगते
    Framework laptop हमारी अलग सोच को अच्छी तरह दिखाता है
    आप DIY दिशा में लगातार 9 score करते हैं, जबकि मैं resilience इस तरह पाता हूँ कि मेरे पास 10 साल पुराना ThinkPad backup machine है जिसमें मैं कभी भी Linux और Neovim जल्दी से चला सकता हूँ, और अगर वह भी ख़राब हो जाए तो मुझे भरोसा है कि आगे भी 100 डॉलर से कम के ThinkPad मिलते रहेंगे
    ज़रूरत पड़े तो मेरे पास इतनी computer science और mathematics की जानकारी है कि Haskell combinators से Markdown से HTML के लिए एक धीमा, अनौपचारिक और buggy parser इस्तेमाल कर सकूँ, लेकिन ऐसा दिन जल्द आता नहीं दिखता
    अगर संभव हो तो मैं आपको hire करना चाहूँगा
    आप उन बहुत से लोगों के लिए एकदम सही counterweight होंगे जो दूसरी दिशा में झुके हुए हैं

    • मैं जानना चाहता हूँ कि दूसरी दिशा में झुकाव से आपका क्या मतलब है

  • यह लेख पढ़कर सच में मज़ा आया
    लेखक अपने प्रति ईमानदार है और पाठक के प्रति गंभीर
    वह बिना बहाने अपने जैसा है, और अपने values के अनुरूप तथा ख़ुशी देने वाले तरीके से अपने goals हासिल करना चाहता है
    अगर वे values आपसे मेल नहीं भी खातीं, तब भी यह ठीक है, बल्कि यह अपने आप में सुंदर बात है
    अब आपको उन रास्तों के बारे में एक संकेत मिल गया है जिन्हें आप explore कर सकते हैं
    लेख विनम्र, humble और sincere है, और मुझे लगता है कि लेखक और यह लेख दुनिया को थोड़ा बेहतर बनाते हैं

    • गंभीर तो है, लेकिन अपने प्रति ईमानदार होने की बात लगभग उलटी लगती है
      विनम्र होने की बात भी वैसी ही है
      पूरा लेख self-congratulation के ज़्यादा क़रीब है, और बीच-बीच में /r/confidentlyincorrect जैसी झलकियाँ भी दिखती हैं
    • इस लेख को पाठकों के लिए लिखी चीज़ मानने के बजाय, इसे लेखक के आंतरिक लक्ष्यों — जैसे सीखना या control का एहसास — हासिल करने के लिए एक अभ्यास और सहायक औज़ार मानना आसान है
      पाठक तो बस एक secondary target है, इसलिए पाठक का अनुभव चाहे जितना Spartan हो, वह मुख्य बिंदु नहीं है; लेखक का अनुभव ही केंद्र में है
    • अगर आपने इसे पढ़ा है, तो क्या थोड़ा content साझा कर सकते हैं?
      लगता है मोबाइल platform से आए बहुत से लोगों ने बहुत जल्दी पढ़ना छोड़ दिया

  • मैंने बस सरसरी नज़र से देखा, और मुझे लगभग पूरा यक़ीन है कि यह व्यक्ति हमें troll कर रहा है
    वेबसाइट कहती है कि वह “plain HTML” इस्तेमाल करती है, लेकिन असल में यह plain text है
    यहाँ formatting के लिए HTML नाम की कोई चीज़ नहीं है
    न headings हैं, न paragraphs, न lists, यहाँ तक कि a tag भी नहीं है
    थोड़ा-बहुत जो HTML और CSS डाला गया है, वही साइट को और ख़राब render करता है
    लेखक troll है

    • वह element कम से कम 15 साल पहले से deprecated element के रूप में चिह्नित है

  • “मेरे standards बहुत ऊँचे और अजीब हैं,” कहते हुए यह भी कहा गया कि “यह script cronjob के रूप में हर मिनट चलती है और अगर git repository update हुई हो तो site को फिर से build करती है”
    यानी ऐसी repository को साल में 525,600 बार fetch किया जाता है जिसमें शायद साल भर में कुछ ही commits हों
    अब समझ आता है कि “अजीब” शब्द क्यों जोड़ा गया

    • अगर नया commit न हो, तो git fetch असल में लगभग एक string comparison जितना ही होता है [0], इसलिए मुझे नहीं लगता कि यह उतना महँगा काम है जितना कहा जा रहा है
      [0] https://stackoverflow.com/a/44476803
    • इस स्थिति में “अजीब” से ज़्यादा यह पागलपन के क़रीब है
      पूछना नहीं, बताना चाहिए
    • यहाँ इस बारे में बहुत ज़्यादा assumptions की जा रही हैं कि मेरा deployment कैसे काम करता है!
      मेरी सारी git repositories उसी server पर हैं जो website host करता है
      git remote fetch नहीं, बल्कि local fetch करता है, इसलिए यह लगभग तुरंत खत्म हो जाता है
      remote fetch भी होता तो भी ठीक रहता
      साल में 525,600 HTTP requests, NetworkManager के heartbeat से भी कम फ़िज़ूलखर्ची है
      Arch में default रूप से हर 30 सेकंड में 1 heartbeat request जाती है
      और संदर्भ के लिए, 8-CPU वाला default nginx server प्रति सेकंड 5 लाख से ज़्यादा HTTP requests संभाल सकता है

  • OP के लिए:
    यहाँ बहुत ज़्यादा आलोचनात्मक टिप्पणियाँ दिख रही हैं
    विनम्रता से कहूँ तो… इन्हें ज़्यादा महत्व मत दो
    आलोचना सही भी हो सकती है, लेकिन यह industry सामूहिक “ऐसा करना चाहिए” और “यही सही तरीका है” के पीछे भागते-भागते तेज़ी से बड़े पैमाने की मूर्खता की ओर बढ़ रही है
    इसमें से काफ़ी कुछ इस समय मुश्किल से शहरी दंतकथा जितना ही ठोस है
    आजकल जिसे “engineering” कहा जाता है, अगर हम उसी पर भविष्य न बना रहे होते तो उस पर हँसी आती
    मेरे पिता aerospace engineer थे, और आधुनिक software development में जिसे engineering कहा जाता है उसे देखकर शायद कब्र में करवटें बदलते
    comments section है, इसलिए हर किसी को बोलने की आज़ादी है, लेकिन निजी तौर पर industry में 25 साल बिताने के बाद ही मैं उन शोर मचाने वाली आवाज़ों को नज़रअंदाज़ कर पाया और उन दुर्लभ मौकों पर वही किया जो मुझे सही लगा
    फिर अगर बात एक personal site की हो, तो और भी ज़्यादा क्यों नहीं?
    Apple के विज्ञापन की वह पुरानी पंक्ति “पागल लोगों के लिए” अब सच से काफ़ी दूर लगती है
    इंटरनेट ऐसा बन चुका है, और जो कभी startups थे वे अब इस परिदृश्य के सबसे बड़े corporate monsters बन गए हैं, तो हैरानी भी नहीं
    Theodore Roosevelt का “arena में मौजूद आदमी” वाला उद्धरण आजकल वाकई बिल्कुल सही लगता है
    लगे रहो, OP, लगे रहो…

    • हौसला बढ़ाने के लिए धन्यवाद! खासकर HN पर, और खासकर मेरी personal website पर लिखी पोस्ट के लिए आने वाली आलोचना को मैं हल्के में लेने की कोशिश करता हूँ
      मेरी website कोई पूरी तरह optimized site नहीं है, बल्कि मेरा अपना पवित्र और अनोखा playground है
      सब कुछ मैंने खुद लिखा है और यह समय के साथ evolve होता रहता है
      यह साफ़ है कि मेरी style कभी-कभी लोगों को चुभती है, और ऐसी आलोचना की मुझे आदत है
      कभी-कभी मैं content को अपने पसंदीदा रूप में ढालने के लिए अजीब फैसले भी लेता हूँ, लेकिन मुझे लगता है कि यही बात उसे प्यारा बनाती है
      क्योंकि वह बाहर की दूसरी चीज़ों जैसी नहीं है
      इसमें कुछ खुरदरे कोने ज़रूर हैं, लेकिन “personal format” को explore करते हुए यह बेहतर होती जाएगी :)
      मेरे लिए website एक long-term art project जैसी है
      उसे लेखक का प्रतिनिधित्व करना चाहिए, और मेरे मामले में मेरी site बेझिझक मेरा प्रतिनिधित्व करती है

  • आपने अपना दिखाया, तो मैं भी अपना दिखाता हूँ
    मेरी website, game engine, और webserver एक ही binary हैं
    source, C code की 1000 lines है, और binary का size 164KB है
    पता नहीं यह इतनी बड़ी क्यों है
    webserver भी मैंने खुद ही शामिल किया है
    मौजूदा servers बहुत ज़्यादा छिपी हुई complexity जोड़ देते हैं
    नतीजे में बना German interactive fiction game यहाँ देखा जा सकता है: http://vmd34232.contaboserver.net/
    कोई tracking नहीं, कोई ads नहीं, कोई commercial purpose नहीं

    • बढ़िया है, मैंने पहले parchment.js के साथ inform7 द्वारा बनाए गए z5 files को अपनी website पर load किया था
      executable को upx से compress करके देख सकते हैं https://upx.github.io/
    • इससे मुझे अपनी site याद आ गई :)
      https://toldby.ai/
      मेरी single binary नहीं है, यह asp.net है

  • लेख में उठाए गए हर point से मैं पूरी तरह सहमत हूँ, लेकिन यह website उदाहरण के तौर पर कुछ खास अच्छी नहीं है
    website को “एक binary” कहा गया है, लेकिन deployment strategy में binary output चलाने के बजाय compilation शामिल है
    यह कहा गया है कि github pages पर निर्भर नहीं रहना, लेकिन openlibrary.org के external resources पर निर्भरता है
    कहा गया है कि खुद बनाओ तो public standards का उपयोग कर सकते हो, लेकिन thoughts/ के अंदर की .html files दरअसल plain text structures हैं जिन पर झूठा extension लगा है
    लोग जब यह रास्ता चुनते हैं तो आमतौर पर initial page load में सब कुछ ठूँसने की कोशिश करते हैं, लेकिन यहाँ dynamic तरीके से serve की जाने वाली कई static files हैं
    Golang code किसी भी response को cache नहीं करता और templates को memory में भी store नहीं करता
    go.mod file में कई dependencies हैं, और लगता है कि वे सभी इस्तेमाल भी नहीं हो रही हैं
    सबसे अहम बात, single binary spirit की आधुनिक infrastructure के मुक़ाबले कोई तकनीकी बढ़त क्या है, इस पर कोई चर्चा ही नहीं है
    निजी तौर पर मुझे यह एक अच्छा विचार लगता है, लेकिन यह उसका खराब उदाहरण है

    • असल में यह single binary है ही नहीं
      यह filesystem के साथ काम करने वाली single binary है
      सारा content filesystem में है
      “single binary” बस filesystem से content serve करने वाला एक हल्का Golang webserver है

  • कहते हैं “standards बहुत ऊँचे और अजीब” हैं, अजीब तो ठीक है, लेकिन नतीजे में बनी website की design इतनी ख़राब है कि वह text को screen पर ठीक से fit भी नहीं कर पाती, इसलिए standards तो उल्टा बहुत नीचे हैं