C: DBA+BackEnd+Middle Ware+Linux Engineer+Cloud Architecture भी कर सकता हूँ, तो क्या इसमें भी जाना चाहिए!?

मैं भी Meta ऐप्स पर भरोसा नहीं कर सकता, इसलिए उन्हें इस्तेमाल नहीं करता और उसकी जगह केवल Secure Folder के अंदर Chrome से ही उपयोग करता हूँ

2025 का कोई पल..

A: Spring, React, Android, iOS एक ही आदमी संभालेगा
B: हर एक के लिए एक-एक आदमी, यानी कुल चार लोग रख लेते हैं?
A: मैंने कहा था एक ही आदमी रखो
B:

इंसान क्या जाने!

नौकरी पाना काफ़ी डरावना है। दूसरे नज़रिए से देखें तो यह one-person service बनाने के लिए काफ़ी मुफ़ीद भी है...

कृपया, प्लीज़, ऐसा मत करो कहने पर भी 10 में 1 बार तो ऐसे करने वाले लोग मिल ही जाते हैं -_-

अच्छा लेख साझा करने के लिए धन्यवाद।
मैं भी ऐसे ही एक solo developer के रूप में जीना चाहता हूँ।

मेरे हिसाब से hybrid app में web/app के बीच सामान्य communication का तरीका bridge होता है, यानी OS और browser लेयर पर दिए गए API के ज़रिए। मुझे नहीं लगता कि local web server ज़रूरी है।
वहाँ local web server इस्तेमाल करने से समस्या इसलिए बनी होगी कि, उदाहरण के लिए, Chrome के secret mode में localhost port के ज़रिए access करके user की anonymity तोड़ देने जैसी vulnerability संभव हो जाती है। अगर ऐसी तकनीक hybrid app में अनिवार्य है... तो hybrid app ही खत्म हो जाने चाहिए।

तेज़ फीडबैक के लिए धन्यवाद~

यह बेहद सारगर्भित लेख है। सिर्फ़ शक्तिशाली tools ही नहीं, ज़रूरत पड़ने पर ज़रूरी tools खुद बनाने की तैयारी भी रखनी चाहिए। इसलिए अगर यह अच्छी तरह चलने लगे, तो मिलने वाले फायदे भी बहुत होते हैं।

लगता है कि कोरिया में भी स्थिति कुछ ऐसी ही है। मुझे लगता है कि सिर्फ coding skill के बजाय biology + coding capability की तरह किसी दूसरे major + coding का संयोजन नौकरी पाने में ज़्यादा फायदेमंद होगा। तरह-तरह के framework और cloud के विकास, और LLM tools के आने से coding में प्रवेश की बाधा कम हो गई है (जैसे पहले assembly -> C language -> Python हुआ था), इसलिए लगता है कि coding capability के अलावा और भी कुछ आना चाहिए, तभी hiring market में प्रवेश संभव है।

आपको सलाम!

एक बार इस्तेमाल होने वाली साधारण scripts लिखते समय यह निश्चित रूप से उपयोगी है। इससे बहुत समय बचता है
ऐसे मामलों में भी यह काम आता है जहाँ समाधान करना ज़रूरी है, लेकिन बहुत अधिक समय निवेश नहीं किया जा सकता। हालांकि, अभी यह ज़्यादातर उपयोगी है, पर इंसानों की पूरी तरह जगह नहीं ले सकता। आगे यह कितना विकसित होगा, पता नहीं, लेकिन फिलहाल assistant के रूप में यह काफ़ी हद तक इस्तेमाल लायक स्तर पर है।

मास्टर्स के दौरान एक बार मेरे गाइड प्रोफेसर Google के एक पूर्व इंजीनियर के साथ खाना खाकर आए थे, और शायद वहीं से monorepo की बात सुनकर उन्होंने भी आगे से monorepo में मैनेज करने का प्रस्ताव रखा था, लेकिन उन्हें समझाकर रोकने में काफ़ी मशक्कत करनी पड़ी थी...
monorepo के कई फ़ायदे ज़रूर हैं, लेकिन हमारी लैब की प्रकृति ऐसी थी कि हमें अपने आउटपुट अक्सर बाहरी लोगों के साथ शेयर करने पड़ते थे, और अगर हम उन्हें monorepo में मैनेज कर रहे होते तो शायद यहीं सबसे ज़्यादा दिक्कत होती। multi-repo में तो बस हर आउटपुट के हिसाब से access range नियंत्रित कर सकते हैं।

अच्छा लेख है ~

अरे, मैंने इसे एक अलग तरीके से हल कर लिया। धन्यवाद!

मोनोरेपो करते समय ज़्यादातर परेशानी शायद तब होती है जब प्रोजेक्ट को पहले ही बहुत छोटे-छोटे हिस्सों में बाँट दिया गया हो। जो चीज़ मूल रूप से एक-दो प्रोजेक्ट में हो सकती थी, उसे लगभग 10 हिस्सों में बाँटकर फिर उसे मोनोरेपो में इंटीग्रेट करके मैनेज करना पड़े, तो मोनोरेपो मैनेजमेंट टूल भी इस्तेमाल करने पड़ते हैं और जटिलता भी बढ़ जाती है। बेहतर है कि प्रोजेक्ट को ही एक-दो हिस्सों में समेकित कर दिया जाए, और अगर दो से ज़्यादा प्रोजेक्ट हों भी, तो अलग मैनेजमेंट टूल इस्तेमाल करने के बजाय बस directories अलग रखकर उन्हें एक ही repository में रखने की तरह सोचा जाए, तो कहीं ज़्यादा आराम से मैनेज किया जा सकता है।

.topic_contents में min-width: 0 देने पर यह ठीक हो जाता है। min-width की वजह से सच में काफी सिरदर्द है...

शायद टेबल होने की वजह से मोबाइल लेआउट टूट रहा है।

पूरी तरह सहमत होने वाली बात है

जो आपको पसंद है, वही करें वाला हिस्सा मैं भी पहले से बहुत सोचता रहा हूँ, इसलिए इसे पढ़ते हुए पूरी तरह सिर हिलाता रहा।

आंतरिक प्रेरणा के बिना उस कठिन शुरुआती दौर को आखिर कैसे पार किया जाए