कोडिंग self-help किताबें उन शुरुआती लोगों के लिए ठीक हो सकती हैं जिनके पास तकनीक या implementation methods को लेकर अभी कोई ठोस दृष्टिकोण नहीं है, लेकिन मेरा मानना है कि अनुभव बढ़ने के साथ उनकी उपयोगिता कम होती जाती है। इसकी वजह यह है कि हर project और environment पर लागू होने वाला कोई पूर्ण सत्य नहीं होता, और कई बार ऐसे हालात भी आते हैं जहाँ सामान्य सिद्धांत काम नहीं करते। दूसरे सामान्य क्षेत्रों की self-help किताबों की सलाह की तरह, उनसे थोड़ा फासला रखते हुए सिर्फ वही सलाह अपनाना बेहतर लगता है जो परिस्थिति के अनुकूल हो, और सलाह का अंधाधुंध पीछा नहीं करना चाहिए।
"उपकरण बंद कर रहे हैं. नहीं हो रहा, है न? बंद ही नहीं हो रहा. मुझे यहाँ से निकलना होगा" — यह वही कृति है जिसने घरेलू meme जगत में एक यादगार संवाद छोड़ा था।
मैंने एक परिचित की कंपनी के बारे में सुना था; वह local server सेटअप करके reservation और customer management software देने वाली कंपनी थी.
उसे बने अब लगभग 20 साल हो चुके हैं, और target market स्पष्ट होने की वजह से कहा जाता है कि वह अपने उद्योग में लगभग दूसरे नंबर पर है.
यह भी cloud/web नहीं बल्कि एक service है, और तकनीकी प्रगति बहुत बड़ी नहीं रही, लेकिन फिर भी लगा कि ऐसा business भी काफ़ी अच्छा हो सकता है.
मुझे John की बात से थोड़ा ज़्यादा सहमति है.
मुझे लगता है कि असली बात यह है कि दोनों में से किसी की बात को डॉग्मा की तरह बिना शर्त मानने के बजाय यह समझते हुए आगे बढ़ना चाहिए कि वे ऐसा क्यों कहते हैं।
लगता है कि आइकन का इस्तेमाल केवल उन्हीं स्थितियों में करना चाहिए जहाँ उन्हें एक नज़र में समझा जा सके, और लंबे समय तक दबाने पर सहायक टेक्स्ट दिखाने की सुविधा भी ज़रूर होनी चाहिए।
Han/Geul दस्तावेज़ फ़ाइल फ़ॉर्मैट: HWP फ़ॉर्मैट संरचना पर एक नज़र
कोडिंग self-help किताबें उन शुरुआती लोगों के लिए ठीक हो सकती हैं जिनके पास तकनीक या implementation methods को लेकर अभी कोई ठोस दृष्टिकोण नहीं है, लेकिन मेरा मानना है कि अनुभव बढ़ने के साथ उनकी उपयोगिता कम होती जाती है। इसकी वजह यह है कि हर project और environment पर लागू होने वाला कोई पूर्ण सत्य नहीं होता, और कई बार ऐसे हालात भी आते हैं जहाँ सामान्य सिद्धांत काम नहीं करते। दूसरे सामान्य क्षेत्रों की self-help किताबों की सलाह की तरह, उनसे थोड़ा फासला रखते हुए सिर्फ वही सलाह अपनाना बेहतर लगता है जो परिस्थिति के अनुकूल हो, और सलाह का अंधाधुंध पीछा नहीं करना चाहिए।
यह नहीं भूलना चाहिए कि clean code कोई लक्ष्य नहीं, बल्कि एक साधन है।
सोच से ज़्यादा Go-आधारित फ्रंटएंड बनाना प्रभावी है। इसके use case बढ़ने की वजह वाजिब है।
लोकप्रिय Git सेटिंग विकल्प
"उपकरण बंद कर रहे हैं. नहीं हो रहा, है न? बंद ही नहीं हो रहा. मुझे यहाँ से निकलना होगा" — यह वही कृति है जिसने घरेलू meme जगत में एक यादगार संवाद छोड़ा था।
मैंने एक परिचित की कंपनी के बारे में सुना था; वह local server सेटअप करके reservation और customer management software देने वाली कंपनी थी.
उसे बने अब लगभग 20 साल हो चुके हैं, और target market स्पष्ट होने की वजह से कहा जाता है कि वह अपने उद्योग में लगभग दूसरे नंबर पर है.
यह भी cloud/web नहीं बल्कि एक service है, और तकनीकी प्रगति बहुत बड़ी नहीं रही, लेकिन फिर भी लगा कि ऐसा business भी काफ़ी अच्छा हो सकता है.
मुझे John की बात से थोड़ा ज़्यादा सहमति है.
मुझे लगता है कि असली बात यह है कि दोनों में से किसी की बात को डॉग्मा की तरह बिना शर्त मानने के बजाय यह समझते हुए आगे बढ़ना चाहिए कि वे ऐसा क्यों कहते हैं।
कॉनफ़्लिक्ट समाधान का पुन: उपयोग अच्छा है।
आखिरकार, संतुलन ही सबसे ज़रूरी है।
मैं diff करते समय
git-deltaका इस्तेमाल करके उसे TUI फ़ॉर्मैट में देखता हूँ.अगर ये सब भी झंझट लगे तो
tig.... हाहाक्या इससे भी बेहतर कुछ हो सकता है...?
उपयोगी है 👍🏻
फिर भी इसे आज़माकर देखने का मन है।
किसी भी तरह से देखें तो यह आसान समस्या को मुश्किल तरीके से हल करने जैसा लगता है...
वाकई बहुत मज़े से पढ़ा।
बहुत शानदार लोग हैं। :)
मुझे लगता था कि UK Labour Party, Conservatives से ज़्यादा वामपंथी है, हाह~
Obsidian♡
लगता है कि आइकन का इस्तेमाल केवल उन्हीं स्थितियों में करना चाहिए जहाँ उन्हें एक नज़र में समझा जा सके, और लंबे समय तक दबाने पर सहायक टेक्स्ट दिखाने की सुविधा भी ज़रूर होनी चाहिए।