Ruby on Rails डॉक्यूमेंट्री [वीडियो]
(youtube.com)- 37signals के Basecamp के विकास के दौरान David Heinemeier Hansson ने Ruby में अपनी जरूरत के tools खुद बनाए, और यहीं से Rails की शुरुआत हुई
- Jason Fried और David का सहयोग 2001 में 37signals ब्लॉग पर PHP से जुड़े एक सवाल से शुरू हुआ, जो आगे चलकर Basecamp backend development और Rails extraction तक पहुंचा
- Rails ने PHP जैसी तेज web development की सहजता और Java-शैली object-oriented design की कठोरता को Ruby के भीतर मिलाने की कोशिश की; इसका मुख्य स्वरूप 2003 की गर्मियों से फरवरी 2004 में Basecamp launch तक बना
- शुरुआती प्रसार में Basecamp जैसे वास्तविक product, 15-minute demo, Java से तुलना, और 37signals की प्रतिष्ठा ने मदद की; Jamis Buck, Jeremy Kemper, Tobias Lütke जैसे शुरुआती contributors और Rails core team बने
- Rails को MIT license open source के रूप में जारी किए जाने के बाद Shopify और GitHub जैसे बड़े-scale examples और 20 वर्षों से जारी community के जरिए इस दिशा को बनाए रखा गया कि छोटी teams भी बड़े web applications बना सकती हैं
37signals और David Heinemeier Hansson की मुलाकात
- 1999 या 2000 में, Jason Fried 37signals नाम की web design company चला रहे थे और Single File नाम का एक online book database side project PHP में बना रहे थे
- वे किताब से PHP सीखते हुए काफी आगे बढ़ गए थे, लेकिन एक जगह अटक गए; उस समय StackOverflow जैसी जवाब देने वाली जगह नहीं थी, इसलिए उन्होंने online मदद मांगी
- डेनमार्क के Copenhagen में web industry में काम कर रहे David Heinemeier Hansson 37signals के ब्लॉग Signal vs. Noise को लगातार पढ़ते थे, और 2001 में Jason के programming question का जवाब दिया
- David का जवाब बहुत detailed था, और Jason को लगा कि यह सिर्फ एक comment नहीं, बल्कि सच में मदद करने का रवैया है
- इसके बाद David ने Jason का पूरा code देखा और कुछ इस तरह कहा, “यह अच्छा नहीं है, चलो फिर से शुरू करते हैं”; दोनों का collaboration वहीं से शुरू हुआ
- दोनों कुछ समय तक remotely काम करते रहे और फिर Chicago के Hancock building के पास पहली बार आमने-सामने मिले; Jason याद करते हैं कि David का सफेद पहनावा बहुत अलग दिख रहा था
Basecamp बनाते हुए Rails का जन्म
- 37signals client projects को email से manage करते हुए file versions, बाकी काम, और launch readiness को track करना मुश्किल महसूस कर रही थी, इसलिए 2003 में internal use के लिए project management tool बनाने का फैसला किया
- उस समय David Copenhagen के business school के छात्र थे, इसलिए वे हर हफ्ते लगभग 10 घंटे ही काम कर सकते थे, और Basecamp backend development के बदले वे पैसे से ज्यादा Apple laptop और equipment चाहते थे
- Martin Fowler और Dave Thomas के लेखों के जरिए Ruby से परिचित हुए David को जापान से आई इस language का code pseudocode जैसा पढ़ा जाना आकर्षक लगा
- Basecamp से पहले 37signals के कामों में PHP इस्तेमाल हुआ था, लेकिन David ने Basecamp backend Ruby में बनाने का फैसला किया और Jason ने उस choice पर भरोसा किया
- David ने Rails में जो combination खोजा, वह दो चीजों का था
- PHP की तरह web पर तेजी से deploy करने की immediacy
- Java में दिखने वाले object-oriented design और patterns की intellectual rigor
- उस समय Ruby में web development और database access में मदद करने वाली libraries या frameworks बहुत ज्यादा नहीं थे, और David ने Basecamp बनाने के लिए जरूरी tools खुद बनाए
- 2003 की गर्मियों से फरवरी 2004 में Basecamp launch तक Rails का core तैयार हुआ, और Basecamp launch के बाद लगभग 6 महीनों तक code और documentation को refine करने के बाद 2004 में Rails को सार्वजनिक किया गया
शुरुआती release, विवादास्पद marketing, core team का गठन
- Rails release की तैयारी करते समय David ने code के साथ-साथ documentation quality को भी महत्वपूर्ण माना, और आंका कि पहला version पर्याप्त रूप से अच्छा होना चाहिए
- Rails पर ध्यान मिलने लगा तो David ने framework की दिशा को मजबूती से बचाने की कोशिश की, और जिन demands को वे नहीं चाहते थे, उन्हें “नहीं” कहा
- शुरुआती Rails conference में David ने अनुचित demands और failure threats पर प्रतिक्रिया के रूप में “F()c% You” slide का इस्तेमाल किया, और यह stance दिखाया कि open source कोई commercial relationship नहीं है और users दिशा dictate नहीं कर सकते
- साथ ही Rails हजारों contributors द्वारा भेजे गए अच्छे काम को अपनाते हुए बढ़ा, और ऐसा नहीं था कि David feedback और contributions को ही reject कर रहे थे
- 2004 International Ruby Conference में David ने Rails को introduce करते हुए code demo से ज्यादा Rails बनाने की वजह और programmers को बेहतर experience देने के goal पर focus किया
- शुरुआती करीब एक साल तक केवल David ही code में direct commit करते थे, और patches email और Wiki आदि से लिए जाते थे
- बाद में जिन लोगों ने ज्यादा contributions किए, उन्हें codebase access दिया गया और Rails core team बनी; Jamis Buck, Jeremy Kemper, Marcel Molina, Scott Barron, Sam Stephenson, Michael Koziarski आदि शुरुआती committers के रूप में शामिल हुए
- 37signals ने Rails core team या Rails contributors में से कुछ लोगों को hire किया, और Jamis Buck उस समय 37signals द्वारा hire किए गए पहले programmer बने जब Basecamp बढ़ रहा था
वास्तविक product और ecosystem से बना प्रसार
- Rails को शुरुआती attention दिलाने में 37signals की प्रतिष्ठा और Basecamp जैसे वास्तविक successful product ने बड़ी भूमिका निभाई
- David का मानना था कि Ruby जैसी कम-जानी-पहचानी language पर आधारित tool को promote करने के लिए शांत introduction से ज्यादा तेज आवाज की जरूरत है, और उन्होंने Java implementation और Rails implementation की तुलना करने वाली विवादास्पद material बनाई
- Rails के प्रसार में 15-minute demo, Basecamp के paid customers और growth, तथा सच में चलने वाला code साथ-साथ काम आए
- Tobias Lütke ने Canada में company शुरू करने की कोशिश के दौरान online snowboard store बनाते समय Rails को बहुत शुरुआती stage में इस्तेमाल किया, और वह project Snowdevol आगे चलकर Shopify बना
- Tobias याद करते हैं कि Rails की वजह से वे अकेले system बना सके, और उस समय online store बनाने वाली दूसरी teams की तुलना में वे खुद अधिक productive थे
- Shopify Rails से प्रभावित company है; आज भी वह latest Rails version इस्तेमाल करती है, codebase का अधिकांश हिस्सा Ruby में है, और basic folder structure भी सामान्य Rails app जैसा है
- Rails के बारे में “यह scale नहीं करता” वाली आलोचना शुरुआत से थी, लेकिन Basecamp ने real users को support किया, और Shopify, GitHub जैसे examples आने से पहले भी यह counter-argument जारी रहा कि Rails शुरू से scalable था
- Shopify को दुनिया के e-commerce के लगभग 10% हिस्से वाली large-scale service के रूप में देखा जाता है, और ऐसे अनुभव भी सामने आते हैं कि समझ नहीं आता Rails किस scale को handle नहीं कर सकता
Releases, Merb merge, और 20 वर्षों से जारी दिशा
- Rails का public release शुरुआत से open source में जाना स्वाभाविक choice था, और David का मानना था कि web work को संभव बनाने वाली बुनियाद open source tools थी, इसलिए उन्हें अपना toolbox भी share करना चाहिए
- Rails को paid product बनाने या competitive advantage के रूप में exclusive रखने की चर्चा भी हुई, लेकिन David ने फैसला किया कि MIT license open source महत्वपूर्ण है और Rails को बहुत सफल बनाना है
- Basecamp deployment के लिए Jamis Buck द्वारा बनाया गया tool आगे चलकर Capistrano नाम से स्थापित हुआ
- Rails की major release timeline इस प्रकार है
- Rails 1.0 एक महत्वपूर्ण starting point है
- Rails 1.2 को stable early release और mature web framework का रूप दिखाने वाले point के रूप में माना गया
- दिसंबर 2007 में Rails 2.0 cookie-based sessions और named scopes आदि लेकर आया
- मार्च 2009 में Rails 2.3 को ऐसी release के रूप में देखा गया जिसमें छोटे से बड़े apps तक modern web developers के लिए जरूरी tools मौजूद थे
- Rails 2.3 के समय jQuery उभर रहा था, और Rails JavaScript world की energy को अपनाने के लिए space बनाना चाहता था
- इसके बाद Ruby web framework Merb ज्यादा तेज, हल्का और कम काम करने वाले competitor के रूप में आया, और Rails developers ने उस दिशा से सीखने लायक बातें देखीं
- Rails 3.0 Merb के साथ merge तक पहुंचा, और Rails internals को configurable, recomposable और modular structure में फिर से design करने का बड़ा काम जरूरी हुआ
- Rails community ने उन लोगों को भी web applications बनाने और career बनाने में सक्षम करने पर focus किया जिनके पास computer science या programming की formal education नहीं थी
- Rails ने entry barrier कम करने और आगे चलकर company या industry में high-level programmer बनने का रास्ता देने की कोशिश की
- आज Rails website की wording की तरह, Rails “Hello World से IPO तक” छोटी team के साथ पहुंचने देने वाला framework है, और community व codebase quality को अभी सबसे बेहतर माना जाता है
1 टिप्पणियां
Hacker News टिप्पणियाँ
यह डॉक्यूमेंट्री मुझे सच में बहुत पसंद आई, और Shopify के Toby की निजी कहानी के ज़रिए one-person framework का नज़रिया अच्छी तरह उभरकर आया
“From Hello World to IPO” भी अच्छा था, और यह बात खास तौर पर प्रभावशाली लगी कि कोई भी Rails app खोलो, चाहे वह सबसे बड़ा Rails app हो या नया app, उसकी संरचना लगभग एक जैसी होती है
API और frontend stack के उलझे हुए आज के माहौल में ऐसी स्थिरता हमेशा नहीं मिलती
Rails के हालिया बदलाव इसकी मज़बूत नींव को और मजबूत बना रहे हैं, और Kamal के अलावा Solid Cache, Solid Queue जैसे infra को आसान बनाने वाले काम भी चल रहे हैं
frontend में Turbo Morphing, और mobile app में Turbo Native और Strada भी सक्रिय हैं
मैं पहले ही 7.1 पर upgrade कर चुका हूँ और Turbo Native से बना mobile app चला रहा हूँ, और Redis cache को Solid Cache से बदलकर चीज़ों को और सरल बनाने और cache को ज़्यादा समय तक रखने को लेकर भी उत्साहित हूँ
यह देखना अच्छा लगता है कि Rails community अब भी सक्रिय है, और पुराने व मौजूदा core team members framework से गहराई से जुड़े हुए हैं
मैंने Rails कभी इस्तेमाल नहीं किया, लेकिन Node.js ecosystem में जो बात मुझे सबसे ज़्यादा नापसंद है, वह है स्पष्ट conventions की कमी
एक ही framework इस्तेमाल करने पर भी संरचना हमेशा अलग होती है और सब बिखरा हुआ लगता है; अगर कोई अपवाद है तो शायद Next.js, लेकिन वह भी frontend के ज़्यादा करीब है
Ruby और Rails के आसपास developer tools भी बहुत आ रहे हैं, इसलिए उम्मीद है कि Rails 8.0 और Ruby 3.4 में भी और अच्छे बदलाव होंगे
बाद में पता चला कि वह Shopify का founder है और उसकी संपत्ति 5.5 billion dollars है, यह सुनकर हँसी आई
developers, RoR के इस पहलू को सच में बहुत कम आंकते हैं
इससे सिर्फ onboarding आसान नहीं होता, बल्कि bikeshedding भी काफी कम हो जाती है
MVC हर चीज़ के लिए सबसे अच्छा नहीं हो सकता, लेकिन ज़्यादातर मामलों में यह काफी अच्छा है
इसे मुझे आज बाद में देखना होगा
मैंने Laravel, ExpressJS, MeteorJS, Django, Flask जैसे कई frameworks आज़माए हैं, और हर एक के अपने फायदे-नुकसान थे, लेकिन tutorial follow करते-करते या अपने तरीके से बनाते-बनाते मैं हमेशा छोड़ देता था
मैंने तीन दिन पहले Rails शुरू किया, और weekend के दौरान अपने सहकर्मी को दिखाने के लिए जल्दी से एक MVP बना सका
Rails ने मुझे इस पर ध्यान देने दिया कि app को क्या करना चाहिए, न कि उसे कैसे implement करना है, और अब समझ आता है कि लोग इसे इतना क्यों पसंद करते हैं
Rails में productivity सच में बहुत ऊँची है
बहुत पहले से मेरी सबसे बड़ी शिकायत यह रही है कि जब आप conventions से बाहर जाते हैं, तो documentation कम होती है या जानकारी एक-दूसरे से टकराती है
“आशीर्वादित तरीका” ढूँढना और समझना बहुत मुश्किल हो सकता है, लेकिन शुक्र है कि ChatGPT ऐसे हिस्सों में शुरुआती दिशा देने में काफी अच्छा है
यह सच में एक शानदार डॉक्यूमेंट्री थी
मैंने पिछले कुछ सालों में Rails इस्तेमाल किया है, और छोटे team के लिए product बनाना और अच्छी तरह स्थापित patterns का पालन करते हुए business logic implement करना इसमें बहुत productive है
अगर आपको वास्तविक Rails app की संरचना के बारे में जिज्ञासा है, तो मैं Jumpstart codebase देखने की सलाह दूँगा। संरचना कैसे बनाई जाती है, यह सीखने के लिए यह अच्छा resource है
https://jumpstartrails.com/
विकल्प के तौर पर Bullet Train भी काफी अच्छा है, लेकिन इसमें बहुत सी custom libraries जुड़ी हुई हैं, इसलिए इसे “Rails way” कहना मुश्किल है
https://bullettrain.co/
मुझे लगता है कि यह Rails डॉक्यूमेंट्री और Elixir डॉक्यूमेंट्री बहुत कुछ समेट नहीं सकीं
वे छोटी हैं, इसलिए origin story बस छूकर निकल जाती है, और जहाँ उत्साह बढ़ना शुरू होता है, वहीं खत्म हो जाती हैं
community के भीतर या बाहर के लोगों को यह दिखाने के बजाय कि ये technologies कितनी शानदार हैं, यह ज़्यादा उन लोगों का ego बढ़ाने जैसा लगा जो इसमें दिखे
मैं चाहूँगा कि Elixir और Rails, दोनों पर 1 घंटा 30 मिनट की डॉक्यूमेंट्री बने, जो सिर्फ एक-दूसरे की तारीफ़ से आगे बढ़े और वर्षों की मेहनत, अलग-अलग कंपनियों में इनके उपयोग के विविध तरीकों वगैरह को भी दिखाए
यानी अगर Indie Game: The Movie जैसा format लिया जाए तो यह कहीं ज़्यादा आकर्षक होगा, और software पर और अच्छी डॉक्यूमेंट्रीज़ आनी चाहिए
David का approach कितना अनोखा था, Rails team Toby और दूसरे लोगों के ज़रिए कैसे बनी, और यह दूसरे frameworks के साथ कैसे मिला — ऐसे कई छोटे ऐतिहासिक टुकड़े थे जो कहीं और ढूँढना मुश्किल है
यह और लंबी होती तो अच्छा होता, लेकिन जैसा भी बनाया गया है, वह भी शानदार है
मैंने इसे देखा, लेकिन मुझे नहीं लगता कि इसने Rails की उपलब्धियों को पर्याप्त रूप से दिखाया
Ruby on Rails ने PHP, JSP, WebForms जैसे file-centered तरीकों से हटकर routes और MVC pattern के ज़रिए web applications बनाने का paradigm बदल दिया, और आज लगभग हर ठीक-ठाक web framework में यह तरीका मौजूद है
डॉक्यूमेंट्री ने उस हिस्से का ज़िक्र नहीं किया, लेकिन फिर भी यह देखने में मज़ेदार थी
लेकिन Struts और Rails को एक ही वाक्य में रखना भी थोड़ा अपराध जैसा लगता है, क्योंकि Rails ने उससे कहीं ज़्यादा किया
शुरुआती Rails दौर के दिग्गजों ने आधुनिक web app development के तरीके की राह बनाई
इतना तक कहा जा सकता है कि web development में Rails से पहले और Rails के बाद जैसा फर्क है
टिप्पणियाँ पढ़कर लगता है कि Rails अब सिर्फ एक उबाऊ लेकिन मज़बूत framework के रूप में पहचाने जाने से थोड़ा आगे बढ़कर फिर से कुछ लोकप्रियता पा रहा है
Rails मेरे लिए उस दौर की याद है जब मैं चीज़ें ज़्यादा मज़ेदार और ज्यादा बेतरतीब तरीके से बनाता था, और वह मेरे रास्ते के लिए एक अलग समय था
Rails में जिस बात की मैं सच में बहुत कद्र करता हूँ, वह है इसकी मज़बूत vision, और यह कि यह “enterprise-grade” applications बनाने के लिए एक और भारी-भरकम framework नहीं बन गया
यह 20 साल पुराना framework है, फिर भी समय के साथ साहसिक बदलाव करने से नहीं डरता, और अब भी बाकी चीज़ों की तुलना में punk जैसा लगता है
20 साल पहले जब मैंने Rails इस्तेमाल करना शुरू किया था, उसकी याद आ गई और मन गर्म हो गया
https://twitter.com/buger/status/1723040883325460818
मैंने 2015 से 2019 तक एक बहुत बड़े production Rails app पर काम किया, और उसके नतीजे में Rails से प्यार हो गया लेकिन Ruby से नफ़रत
अगर TypeScript या Go में Rails जैसा कुछ होता, तो web app backend के लिए कुछ और इस्तेमाल करने की वजह शायद ही सूझती
Rails Console उन सबसे बेहतरीन productivity tools में से एक है जिनका मैंने इस्तेमाल किया है
TypeScript में शायद मौजूदा Node REPL के साथ यह संभव हो, लेकिन Rails console के इतना उपयोगी होने की बड़ी वजह आखिरकार Ruby खुद है
Honeypot की डॉक्यूमेंट्री सच में बहुत अच्छी है, और मैं इसकी ज़ोरदार सिफारिश करता हूँ