ओह, वाकई आपने इसे बहुत बढ़िया बनाया है। मैं अभी भी इतना दक्ष नहीं हूँ, इसलिए nested menu को ठीक से संभाल नहीं पाता, लेकिन starlight यह काम सच में बहुत अच्छे से कर देता है।
नमस्ते, मैंने थोड़ा देर से देखा कि इस पर इतने सारे comments आए हैं, इसलिए अपना अनुभव साझा कर रहा हूँ।
ब्लॉग में मैं मुख्य रूप से native से Flutter में transition से जुड़ी बातें लिखता हूँ। बाद में शायद इसे फिर से विस्तार से लिखूँ, लेकिन अभी संक्षेप में साझा कर रहा हूँ।
करीब 3 दिनों में कुल 3,000 से अधिक लोगों ने इस पेज को 50,000 से ज़्यादा बार देखा।
इस project को public करने के पीछे एक दुखद वजह भी है।
हाल ही में जहाँ मैं काम करता हूँ, वहाँ कुछ restructuring की समस्या हुई। मैं तो वहीं बना रहा, लेकिन मेरे साथ काम करने वाले कुछ लोगों को job change करनी पड़ी, और मैं उन चीज़ों को, जिनमें हमारी टीम के लोग अच्छी तरह निपुण हैं, Flutter इस्तेमाल करने वाली दूसरी companies तक भी पहुँचाना चाहता था। बेशक, मैं यह कह सकता हूँ कि हमारी टीम से जो लोग move करेंगे, वे इस स्तर का काम कर सकते हैं।
इस सामग्री की बुनियाद उन guides और technologies पर बनी है, जिन्हें मैंने और मेरी टीम के साथियों ने कंपनी के अंदर लिखा था और कंपनी के projects में इस्तेमाल किया था। जब नए team members आते, तो मैं इसे उनके onboarding guide के रूप में इस्तेमाल करना चाहता था, लेकिन अभी अंदरूनी तौर पर इसकी ज़रूरत नहीं रही, इसलिए इसे पूरी तरह public कर दिया।
अभी भी इसमें बहुत-सी कमियाँ हैं और कई विषय ऐसे हैं जिन्हें कवर नहीं कर पाया, फिर भी इसे पसंद करने के लिए धन्यवाद 🙇🏻♂️
और page को बेहतर बनाने के लिए एक survey भी चल रहा है, समय मिले तो उसमें भाग लें, इसके लिए मैं सच में आभारी रहूँगा।
मैं भी, जब web payment और in-app payment दोनों उपलब्ध होते हैं, तब भी कई बार in-app payment चुन लेता हूँ। सभी payments को एक ही जगह manage कर पाना काफी बड़ा फ़ायदा है, और खासकर अगर कोई ऐसा product हो जिसे बस एक-दो बार test करना हो, तो Apple के ज़रिए payment करना ज़्यादा सुरक्षित लगता है—शायद कुछ लोगों में ऐसा एहसास भी होता है।
मैं भी इस बात से सहमत हूँ। जब HTML में जो logic जोड़ा जाता है वह vanilla न होकर अपना खुद का syntax होता है, तो यह एक बड़ी बाधा बन जाता है। साधारण UI implementation में कोई समस्या नहीं होती, लेकिन जब logic जटिल हो जाता है, तब development flexibility में फर्क आता है और learning curve को भी नज़रअंदाज़ नहीं किया जा सकता।
यह बात सच में बहुत रिलेटेबल लगती है.
किसी कंपनी के भीतर solution अपनाने की स्थिति में, अगर नई technology अच्छी लगे तो अक्सर उसी हिस्से पर ध्यान केंद्रित हो जाता है, लेकिन वास्तव में परिचित काम करने के तरीकों को बदलने में आने वाली कठिनाइयों और उसके लिए लगने वाले adaptation time पर भी साथ में विचार करना चाहिए—इस लिहाज़ से यह लेख सच में दिल को छूता है.
यह सुनने में Julia के पैदा होने की वजह वाली कहानी जैसा लगता है। लाइब्रेरीज़ को सीखना तो पड़ता है, लेकिन NumPy की कई समस्याओं को हल कर देने के मामले में यह सचमुच एक बहुत आकर्षक विकल्प लगता है।
अगर vectorization का सही इस्तेमाल न कर पाएं तो NumPy की performance बुरी तरह गिर जाती है। उन बातों को ध्यान में रखकर लिखना तनावपूर्ण भी है और मुश्किल भी।
लोगों की पसंद अलग-अलग हो सकती है, लेकिन मुझे Angular, Vue वगैरह (इन libraries? markup? सहित) के <li for> की तुलना में, vanilla JS से हैंडल किया गया JSX का .map((item) => <li>) ज़्यादा पसंद है।
https://tech.kakao.com/posts/700 यह पोस्ट देखकर मुझे लगा था कि यह Vibe Coding का एक अच्छा उदाहरण है, और संदर्भ भी कुछ वैसा ही लगता है। मैं भी आपके लिखे हुए से सहमत हूँ।
ऐसा लगता है कि अगर चेतावनी वाले अलर्ट पर भरोसा कम हो जाए, तो सच में कोई बहुत अहम चेतावनी आए तब भी लोग उसे नज़रअंदाज़ करके आगे बढ़ सकते हैं। अलर्ट की विश्वसनीयता गिरने से पैदा होने वाली समस्या आखिरकार सिर्फ़ उपभोक्ताओं के नुकसान को ही बढ़ाएगी।
धन्यवाद। उस दस्तावेज़ में जो है वह हमेशा अंतिम सही उत्तर नहीं होता, लेकिन मुझे लगता है कि उसमें इतना ज़रूर है कि बुनियाद मज़बूत की जा सके।
अगर आप कोई अच्छी service बनाकर उसे साझा करें तो अच्छा लगेगा 🙇🏻♂️
धन्यवाद! अभी भी इसमें बहुत कुछ सुधारना बाकी है, फिर भी इसे ध्यान से पढ़ने के लिए आपका धन्यवाद।
ओह, वाकई आपने इसे बहुत बढ़िया बनाया है। मैं अभी भी इतना दक्ष नहीं हूँ, इसलिए nested menu को ठीक से संभाल नहीं पाता, लेकिन starlight यह काम सच में बहुत अच्छे से कर देता है।
नमस्ते, मैंने थोड़ा देर से देखा कि इस पर इतने सारे comments आए हैं, इसलिए अपना अनुभव साझा कर रहा हूँ।
ब्लॉग में मैं मुख्य रूप से native से Flutter में transition से जुड़ी बातें लिखता हूँ। बाद में शायद इसे फिर से विस्तार से लिखूँ, लेकिन अभी संक्षेप में साझा कर रहा हूँ।
करीब 3 दिनों में कुल 3,000 से अधिक लोगों ने इस पेज को 50,000 से ज़्यादा बार देखा।
इस project को public करने के पीछे एक दुखद वजह भी है।
हाल ही में जहाँ मैं काम करता हूँ, वहाँ कुछ restructuring की समस्या हुई। मैं तो वहीं बना रहा, लेकिन मेरे साथ काम करने वाले कुछ लोगों को job change करनी पड़ी, और मैं उन चीज़ों को, जिनमें हमारी टीम के लोग अच्छी तरह निपुण हैं, Flutter इस्तेमाल करने वाली दूसरी companies तक भी पहुँचाना चाहता था। बेशक, मैं यह कह सकता हूँ कि हमारी टीम से जो लोग move करेंगे, वे इस स्तर का काम कर सकते हैं।
इस सामग्री की बुनियाद उन guides और technologies पर बनी है, जिन्हें मैंने और मेरी टीम के साथियों ने कंपनी के अंदर लिखा था और कंपनी के projects में इस्तेमाल किया था। जब नए team members आते, तो मैं इसे उनके onboarding guide के रूप में इस्तेमाल करना चाहता था, लेकिन अभी अंदरूनी तौर पर इसकी ज़रूरत नहीं रही, इसलिए इसे पूरी तरह public कर दिया।
अभी भी इसमें बहुत-सी कमियाँ हैं और कई विषय ऐसे हैं जिन्हें कवर नहीं कर पाया, फिर भी इसे पसंद करने के लिए धन्यवाद 🙇🏻♂️
और page को बेहतर बनाने के लिए एक survey भी चल रहा है, समय मिले तो उसमें भाग लें, इसके लिए मैं सच में आभारी रहूँगा।
https://tally.so/r/w559Vv
मैं भी, जब web payment और in-app payment दोनों उपलब्ध होते हैं, तब भी कई बार in-app payment चुन लेता हूँ। सभी payments को एक ही जगह manage कर पाना काफी बड़ा फ़ायदा है, और खासकर अगर कोई ऐसा product हो जिसे बस एक-दो बार test करना हो, तो Apple के ज़रिए payment करना ज़्यादा सुरक्षित लगता है—शायद कुछ लोगों में ऐसा एहसास भी होता है।
जानकारी के लिए, "Desire Paths" वास्तव में "Desire paths" था।
मैं भी इस बात से सहमत हूँ। जब HTML में जो logic जोड़ा जाता है वह vanilla न होकर अपना खुद का syntax होता है, तो यह एक बड़ी बाधा बन जाता है। साधारण UI implementation में कोई समस्या नहीं होती, लेकिन जब logic जटिल हो जाता है, तब development flexibility में फर्क आता है और learning curve को भी नज़रअंदाज़ नहीं किया जा सकता।
आपकी वजह से एक मज़ेदार लेख पढ़ने को मिला! धन्यवाद।
यह बात सच में बहुत रिलेटेबल लगती है.
किसी कंपनी के भीतर solution अपनाने की स्थिति में, अगर नई technology अच्छी लगे तो अक्सर उसी हिस्से पर ध्यान केंद्रित हो जाता है, लेकिन वास्तव में परिचित काम करने के तरीकों को बदलने में आने वाली कठिनाइयों और उसके लिए लगने वाले adaptation time पर भी साथ में विचार करना चाहिए—इस लिहाज़ से यह लेख सच में दिल को छूता है.
यह सुनने में Julia के पैदा होने की वजह वाली कहानी जैसा लगता है। लाइब्रेरीज़ को सीखना तो पड़ता है, लेकिन NumPy की कई समस्याओं को हल कर देने के मामले में यह सचमुच एक बहुत आकर्षक विकल्प लगता है।
अगर
vectorizationका सही इस्तेमाल न कर पाएं तो NumPy की performance बुरी तरह गिर जाती है। उन बातों को ध्यान में रखकर लिखना तनावपूर्ण भी है और मुश्किल भी।काफ़ी दिलचस्प है
https://sdmntprwestus2.oaiusercontent.com/files/…
लोगों की पसंद अलग-अलग हो सकती है, लेकिन मुझे Angular, Vue वगैरह (इन libraries? markup? सहित) के
<li for>की तुलना में, vanilla JS से हैंडल किया गया JSX का.map((item) => <li>)ज़्यादा पसंद है।https://tech.kakao.com/posts/700 यह पोस्ट देखकर मुझे लगा था कि यह Vibe Coding का एक अच्छा उदाहरण है, और संदर्भ भी कुछ वैसा ही लगता है। मैं भी आपके लिखे हुए से सहमत हूँ।
लगता है कि थोड़ी पुरानी Python libraries में लगभग सबमें एक जैसी समस्या होती है।
तो 3 क्या है? -> यह resource support की बात है.
ऊपर 1, 2, 4, 5 के रूप में numbering की थी, लेकिन Markdown में यह अपने-आप 1234 में बदल गया.
Next.js vs TanStack – Next.js की सीमाएँ और TanStack के फ़ायदे
हमने यह गेम^ खेला है!
^ ActiveX में बिना सोचे-समझे “हाँ” क्लिक करवाने की ट्रेनिंग
ऐसा लगता है कि अगर चेतावनी वाले अलर्ट पर भरोसा कम हो जाए, तो सच में कोई बहुत अहम चेतावनी आए तब भी लोग उसे नज़रअंदाज़ करके आगे बढ़ सकते हैं। अलर्ट की विश्वसनीयता गिरने से पैदा होने वाली समस्या आखिरकार सिर्फ़ उपभोक्ताओं के नुकसान को ही बढ़ाएगी।