विषय
- 01. कोडिंग इसे और न काटें
- चौड़ाई और गहराई
- 02. बड़ी चेतावनी
- 03. इंटरनेट क्या कहता है
- माध्यम को समझें
- 04. जिन चीजों से हम निर्माण करते हैं
- 05. देवोप्स
- ढेर को समझें
- रहस्यमय काम
- आसान उपकरण
- 06. देव इसे ठीक कर देंगे... शायद
- डिबगिंग
- 07. उपयोगकर्ता क्या चाहते हैं
- प्रतिस्पर्धी बाजार
- 08. ड्राइंग और लेखन
- 09. आनंद लें
- 10. तेज रहो
- ये पसंद आया? ये पढ़ सकते हैं!
डेवलपर्स को कोड-जनरेटिंग ग्रंट वर्कर्स से अधिक होना चाहिए। हम अपने डिजिटल जीवन की और अधिक उम्मीद कर रहे हैं और यह वे लोग हैं जो इसे बनाते हैं, इसलिए सर्वश्रेष्ठ देवों को क्या जानने की आवश्यकता है? यहां वे चीजें हैं जो मुझे बहुत सारे डेवलपर्स से गायब दिखाई दे रही हैं। यह संपूर्ण नहीं है, लेकिन यह ये गुण हैं जो एक उचित कोडर को एक अद्भुत डेवलपर में बदल देते हैं।
लेकिन यह एक बात नहीं है, और यह विशेष रूप से कभी भी एक्सएमएल को पार्स करने या कोड को अनुकूलित करने की क्षमता नहीं है, यह कौशल का एक आश्चर्यजनक संग्रह है जो कोड लिखने पर पुस्तकों में नहीं पढ़ाया जाता है। वे कुछ अतिरिक्त हैं।
इस तरह वेंट क्यों? क्योंकि विकास मायने रखता है लेकिन डेवलपर्स को अक्सर एक अलग दुनिया में भेज दिया जाता है, न कि हमेशा उनके बनाने के लिए। यह कभी काम नहीं करता। विकास - कुछ भी तकनीकी - हमेशा फलता-फूलता है जब जानने वाले लोग केवल कोड से अधिक कैसे समझते हैं।
01. कोडिंग इसे और न काटें
हम ऐसी दुनिया में हैं जहां कोडिंग कम प्रभावशाली होती जा रही है। हर कोई साइट बनाता है, उनमें से कुछ कोड करते हैं लेकिन आपके पास नहीं है। यह अब केवल बेवकूफ नहीं है जो साइट, ऐप्स और सुविधाएं बना सकता है।
चूंकि वेब साथ आया था और लोग खुद को सिखा सकते थे, वहां स्वयं-सिखाए गए डेवलपर्स रहे हैं। लेकिन स्नातक भी खतरे में हैं। मुझे कंप्यूटर विज्ञान की डिग्री, एआई पाठ्यक्रम, विभिन्न मीडिया और उनके बेल्ट के नीचे कोडिंग वाले लोगों के साथ सीवी मिलते हैं लेकिन अभी भी कुछ गायब है। कभी-कभी बहुत कुछ छूट जाता है।
मैं यह कहने वाला पहला व्यक्ति नहीं हूं। 'कोडिंग इसे और न काटें' अध्याय 3 का शीर्षक है भावुक प्रोग्रामर, जो जैसी पुस्तकों के साथ व्यावहारिक सोच और सीखना प्रोग्रामर्स से कोड से परे खुद को बेहतर बनाने का आग्रह करें; टीम के जिम्मेदार और पूरी तरह से मानवीय सदस्य बनने के लिए।
चौड़ाई और गहराई
डेवलपर्स को दो तरह से बेहतर होना चाहिए: चौड़ाई और गहराई। उन्हें अपनी टीम में और उनके द्वारा निर्मित चीजों के साथ मानवीय अंतःक्रियाओं की चौड़ाई को समझने की आवश्यकता है। उन्हें उस सिस्टम की गहराई को समझने की जरूरत है जिसके साथ वे काम कर रहे हैं, ओ/एस तक।
और यह सिर्फ डेवलपर्स नहीं हैं जिन्हें इस सामान को पढ़ना चाहिए। यदि आप देवों के साथ काम कर रहे हैं, तो मुझे लगता है कि आपको उनसे अधिक की अपेक्षा करनी चाहिए। उन्हें स्केच बनाएं कि वे किस बारे में बात कर रहे हैं। उन्हें चित्रों, वस्तुओं के साथ समझाने के लिए कहें और (यह काम करता है) लोगों के कट आउट वास्तव में इसका उपयोग करने वाले मनुष्यों के लिए सिस्टम कैसा होगा।
02. बड़ी चेतावनी
मैं डेवलपर्स के बारे में नकारात्मक बात करने जा रहा हूं, लेकिन मुझे लगता है कि मुझे अनुमति है क्योंकि मैं एक हूं। इसके अलावा क्योंकि कम से कम एक बात जो मैं यहां बात करता हूं, वह उन कई डेवलपर्स के बारे में सच है जिनसे मैं मिलता हूं। हालांकि उनका काम बहुत अच्छा है और वे अपना कोड जानते हैं, समय प्रतिस्पर्धी है। आपके पास बढ़त होनी चाहिए, और यह है:
- अधिक तकनीकी बनें
तथा
- होना बहुत अधिक मानवीय
03. इंटरनेट क्या कहता है
'आवश्यक वेब विकास कौशल' के लिए गुगल करने से आप जो अपेक्षा करते हैं वह सामने आता है। फ्रेमवर्क ज्ञान, एक्स-ब्राउज़र, सीएसएस और जेएस। वे उन रूपरेखाओं को सूचीबद्ध करते हैं जिन्हें आपको जानना चाहिए, जिन प्लेटफार्मों के लिए आपको लिखना चाहिए और नए रुझानों पर आपको नजर रखनी चाहिए।
ये हमारे मीडिया हैं। वे वे सामान हैं जिनसे हम निर्माण करते हैं, लेकिन वे वह नहीं हैं जो किसी परियोजना को सफलता प्रदान करते हैं। एक डेवलपर सिस्टम के हर विवरण को समझ सकता है, आपको एपीआई की हर सुविधा और एक नई सीएसएस तकनीक बता सकता है लेकिन फिर भी कुछ अनुपयोगी पैदा कर सकता है।
माध्यम को समझें
डेवलपर्स, सभी की तरह, अपने माध्यम को समझने की जरूरत है - लेकिन उन्हें दर्शकों को भी समझना चाहिए, चाहे वे उपयोगकर्ता हों, टीम हो या अन्य डेवलपर्स। उन्हें यह समझने की जरूरत है कि उनका माध्यम दुनिया में कैसे फिट बैठता है (दूसरे शब्दों में, उत्पादन वातावरण) और इसका क्या प्रभाव पड़ता है (लोग इसका उपयोग कैसे करते हैं)।
मैंने इसे 'चौड़े और गहरे' व्यक्ति के रूप में वर्णित देखा है। व्यापक, क्योंकि आपको दुनिया को दूसरे इंसानों के साथ काम करने वाले इंसान के रूप में समझने की जरूरत है। गहरा है क्योंकि आपको परियोजना के अपने हिस्से के स्तर के नीचे पूरी तरह से तकनीकी ज्ञान की आवश्यकता है। ये डेवलपर आपकी परियोजना को एक बड़ा बढ़ावा देते हैं और परियोजना की गति को बदलते हैं, जिसके बिना आप गैर-तकनीकी कर्मचारियों को तकनीकी टीम से ओवरफ्लो होने वाले थकाऊ विवरण में उलझा हुआ पाएंगे।
04. जिन चीजों से हम निर्माण करते हैं
मैंने हाल ही में उन सभी चीज़ों की एक सूची लिखी है जिनका उपयोग हम साइट बनाने, होस्टिंग प्रबंधित करने और काम पूरा करने के लिए करते हैं ताकि शामिल होने वाले लोगों के पास अपने पहले कुछ हफ्तों में सीखने के लिए तकनीकों की एक धोखा शीट हो सके। हम इसे पढ़ रहे थे कि लोग इन बातों को जानते थे, इसलिए नए रंगरूटों को एक छलांग देने के लिए हम हर दिन हम जो कुछ भी उपयोग करते हैं उसे सूचीबद्ध करेंगे।
मुझे आधा दर्जन प्रौद्योगिकियों की उम्मीद थी लेकिन इससे कहीं अधिक समाप्त हो गया। यह सूची - 'हम क्या उपयोग करते हैं' - इसमें सामान्य सीएमएस, प्रोग्रामिंग भाषाएं और ब्राउज़र तकनीक शामिल हैं, लेकिन साथ ही ऐसे टूल का एक समूह भी शामिल है जिनका उपयोग करने वाली टीम को खुद को याद भी नहीं था। यह सब मांसपेशी स्मृति थी। कमांड लाइन पर 'गिट', 'फिंग', 'थोर' टाइप करते हुए हमने सोचा भी नहीं था कि कोई नहीं करेगा।
उपकरण बनाएँ; सीआई; संस्करण नियंत्रण के लिए git को मान लिया गया था, लेकिन CV पर पीछे मुड़कर देखने पर ये शायद ही दिखाई दिए। ट्रेंडी लोग दिखाई देंगे (और क्या यह निंदक है कि मुझे लगता है कि कुछ एजेंसियां उन्हें इसमें शामिल करती हैं?!) लेकिन अक्सर ठोस अनुभव के बिना।
ये उपकरण परियोजना के विकास में तेजी लाने के लिए महत्वपूर्ण हैं, इसलिए सुनिश्चित करें कि आपके पास अपनी भाषा, सीएमएस और कुछ ढांचे की तुलना में कहीं अधिक समृद्ध टूल सेट है। आपको तैनाती, परीक्षण, सीआई, मजबूत संस्करण नियंत्रण (टीमों में - अपने दम पर नहीं) की आवश्यकता है, और आपको केवल कुछ ट्यूटोरियल के बजाय इनकी मूल अवधारणाओं को समझने की आवश्यकता है।
05. देवोप्स
ये अतिरिक्त उपकरण और तरकीबें बड़े करीने से फिट बैठती हैं जिसे लोग 'देवोप्स' कह रहे हैं। देवोप्स दो पारंपरिक साइलो के सामने उड़ते हैं: उत्पादन, जो चीजों को चालू रखता है, और विकास, जो नई चीजें बनाता है (और अक्सर चीजों को चलाना बंद कर देता है)। साइलो का परिणाम दो शिविरों में एक दूसरे के लिए थोड़ी सहानुभूति के साथ होता है।
उत्पादन ज्ञान के बिना डेवलपर्स अक्सर ऐसे कोड का उत्पादन करते हैं जो उत्पादन के लिए उपयुक्त नहीं है, कॉन्फ़िगरेशन या सुविधाओं का उपयोग करके जो अभी तक उत्पादन स्टैक पर नहीं हैं। क्योंकि वे उत्पादन परिवेश की समस्याओं से अवगत नहीं हैं, वे उत्पादन के लिए इसे तैनात करने के बजाय सुविधा को पूरा करने के लिए कोड करते हैं।
ये छोटे विवरण दर्दनाक देरी पैदा कर सकते हैं, जो सर्वर प्रबंधन को विदेशों में भेजने की प्रवृत्ति से बढ़ा है।
ढेर को समझें
Devops अपने आप में एक बहुत बड़ा क्षेत्र है, जिसमें निरंतर तैनाती और बहुत सारे स्वचालन शामिल हैं। यह एक व्यापक सारांश है, लेकिन डेवलपर्स को जिस महत्वपूर्ण चीज को समझने की जरूरत है वह वह स्टैक है जिस पर वे चल रहे हैं। यह सर्वर व्यवस्थापक को सौंपने के लिए पर्याप्त नहीं है, आपको यह समझना होगा कि प्लेटफ़ॉर्म का आपके कोड पर क्या प्रभाव पड़ता है।
यदि आप रेल पर काम करते हैं, तो रेल कोड पढ़ें और जानें कि अपाचे द्वारा रूबी को कैसे निष्पादित किया जाता है। यदि आप जावा में काम करते हैं, तो कॉन्फ़िगरेशन विकल्पों के बारे में जानें। यदि आप पर्ल का उपयोग करते हैं, तो समझें कि पर्ल मॉड्यूल कैसे स्थापित करें और उन्हें कॉन्फ़िगर करें।
रहस्यमय काम
'हम क्या उपयोग करते हैं' सूची में यह बहुत सारी चीजें हैं, और अच्छे डेवलपर्स यह समझने के लिए छलांग लगाते हैं कि यह सब रहस्यमय काम कैसे किया जाता है। और एक बार जब वे इसे प्राप्त कर लेते हैं, तो तैनाती तेज हो जाती है, काम अधिक सुचारू रूप से तैनात हो जाता है और हर कोई बस खुश होता है।
देवोप्स की निरंतर तैनाती और संबंधित प्रथाएं इतनी मानक होती जा रही हैं कि कोई भी डेवलपर या कंपनी जो इसका अभ्यास नहीं कर रही है, वह खुद को आगे बढ़ा रही है। कोई और इसे करना शुरू कर देगा और फिर वे आपसे तेज हो जाएंगे।
आसान उपकरण
'देवोप्स' के लिए गुगल करने से आपको इन लोगों द्वारा उपयोग किए जाने वाले उपकरणों का अंदाजा हो जाता है। यह PHP और MySQL, या रेल के बारे में नहीं है। यह शिपिंग सॉफ्टवेयर और परियोजनाओं के जोखिम भरे बिट्स को जोखिम मुक्त रखने के बारे में है। वे डिप्लॉयमेंट, ऑटोमेशन पर ध्यान केंद्रित करते हैं और डेवलपर से प्रोडक्शन एनवायरनमेंट तक पाइपलाइन को यथासंभव तेजी से चलाते रहते हैं।
आप पाएंगे कि विकास की यह शैली आपको ऐसे डेवलपर देती है जो एक दूसरे के साथ और अन्य विभागों और कंपनियों के साथ बेहतर काम करते हैं। यदि वे किसी तीसरे पक्ष के एपीआई के साथ काम कर रहे हैं, तो वे दूसरी तरफ आने वाली समस्याओं को समझेंगे। सर्वर व्यवस्थापकों के साथ काम करते समय वे समझेंगे कि उन्हें क्या स्थापित करने की आवश्यकता है और पता है कि उत्पादन सर्वर पर उनकी सॉफ़्टवेयर साइटें कैसी हैं। इसका उल्टा दर्द हो सकता है...
06. देव इसे ठीक कर देंगे... शायद
'आवश्यक वेब डेवलपर कौशल' की यह खोज माइकल ग्रीर (द प्याज के सीटीओ) से एक अच्छा जवाब लाती है:
- आलस्य: दो बार कुछ भी करने से मना करना: इसके लिए एक स्क्रिप्ट या एल्गो लिखता है।
- कायरता: परीक्षण करने के लिए सोचता है, लोड और कोड प्रभाव पर चिंता करता है
- लापरवाही: लगातार नए सामान की कोशिश करता है, उसी दिन के विचारों को लॉन्च करता है
कायरता 'विस्तार पर ध्यान' का एक अच्छा तरीका है। डिबगिंग और परीक्षण एक डेवलपर के जीवन का 99 प्रतिशत है जिसका उल्लेख किसी ने नहीं किया जब उन्होंने W3Schools को मारा या कंप्यूटिंग 101 पाठ्यक्रम शुरू किया।
ऐप्स को ठीक करने की क्षमता के लिए उत्कृष्ट समस्या समाधान कौशल की आवश्यकता होती है, न कि केवल डिबगिंग कोड की। कभी-कभी प्रयोक्ताओं के इनवॉइस को डाउनलोड न कर पाने का समाधान पृष्ठ को प्रिंट करने योग्य बनाना होता है, बजाय इसके कि एक दिन पीडीएफ बनाने में खर्च किया जाए। कभी-कभी एक लिंक विकास के एक सप्ताह की जगह ले सकता है, लेकिन यह सुरुचिपूर्ण समाधान नहीं होगा यदि देव कोड की बहुत सारी पंक्तियों को लिखकर समस्याओं को पूरी तरह से हल कर रहे हैं।
कई उपकरणों के बावजूद, परीक्षण कई देवों के लिए एक अद्भुत ब्लाइंडस्पॉट है। यूनिट परीक्षण, सेलेनियम, लोड परीक्षण और प्रोफाइलिंग टूल जैसे xhprof का उपयोग करें। अपने ऐप के फ़ुटप्रिंट को छोटा रखने के लिए न्यू रेलिक जैसी चीज़ों का विश्लेषण। और इसे देव की नौकरी के सभी हिस्से पर विचार करें: यह आपका कोड है, सुनिश्चित करें कि आप जानते हैं कि यह उम्मीद के मुताबिक काम करता है।
डिबगिंग
डिबगिंग भी एक पीड़ादायक बिंदु है। डीबगर का उपयोग कैसे करें, लेकिन किसी समस्या को डीबग कैसे करें - इसलिए मैं माइकल ग्रीर की सूची में जोड़ूंगा:
- अधीरता: वास्तविक समस्या को खोजने और हल करने के लिए अप्रासंगिक जानकारी को आक्रामक रूप से अनदेखा करता है
यह सभी डिबगिंग तकनीकों की आधारशिला है। अप्रासंगिक को नजरअंदाज करना और प्रासंगिक में अर्थ खोजना। दुर्भाग्य से, कई लोग घंटों या दिनों के लिए अप्रासंगिक रूप से हथौड़े से मारने के लिए प्रवण होते हैं, एक ही चीज़ को 10 बार आज़माकर समस्या को ठीक करते हैं।
डिबगिंग पर कई किताबें हैं (दुख की बात है कि मैंने प्रकाशक को नाम नहीं दिया है) और प्रत्येक डेवलपर को उन सभी को पढ़ना चाहिए। वास्तव में एक महान देव कोड की एक पंक्ति को देखे बिना सिस्टम पर समस्याओं को डीबग कर सकता है।
07. उपयोगकर्ता क्या चाहते हैं
समझें कि आपके आस-पास के लोग क्या करने की कोशिश कर रहे हैं। कोड का आनंद लें - सीएसएस फ़ाइलों को पूरी तरह से इंडेंट करने या रेल ऐप को अनुकूलित करने की कला से प्यार करें - लेकिन याद रखें कि यह सब एक उद्देश्य के लिए है।
डेवलपर्स को व्यवसाय, संचालन और व्यावसायिक प्रक्रियाओं को समझने की आवश्यकता है क्योंकि उनकी सामग्री इसे चलाने में मदद करती है। इस ज्ञान के साथ देव ऐसे सॉफ़्टवेयर और ऐप्स बनाने में सक्षम हैं जो उपयोगकर्ताओं की सहायता करते हैं, लेकिन वे अक्सर असामान्य रूप से उत्पादक लगते हैं। यह उनके प्रकाश की तेज टाइपिंग या स्टैक के अद्भुत ज्ञान के कारण हो सकता है, लेकिन यह उनके ज्ञान के कारण होने की अधिक संभावना है कि उपयोगकर्ता क्या चाहते हैं।
प्रतिस्पर्धी बाजार
अपने मूल बिंदु पर वापस जा रहे हैं, कि विकास आसान हो रहा है और महान डेवलपर्स के लिए बाजार अधिक प्रतिस्पर्धी है कोई भी डेवलपर जो व्यावसायिक आवश्यकताओं को समझने में सक्षम है और उन्हें पूरा करने के लिए कुछ उत्कृष्ट लाने वाला है। बाजार को समझें, ग्राहक और वे लोग पैसे क्यों बांटते हैं, सभी मदद करते हैं।
डेटा को समझें और यह समय के साथ कैसे बदलेगा। डेवलपर के दिमाग में उन्हें नई तकनीकों को उन चुनौतियों के साथ जोड़ना चाहिए जो आज आपके सामने हैं या आने वाली हैं। इस तरह, जब आप एमडी या किसी क्लाइंट को कोई नया आइडिया सुझाते हैं तो यह इस पर आधारित होगा कि ग्राहक वास्तव में क्या चाहते हैं और आपको उस पर बजट/समय मिल जाएगा। (इसके विपरीत, सबसे बुरी बात यह है कि डेवलपर्स अपनी नई पसंदीदा तकनीक को हमारी सभी बीमारियों के समाधान के रूप में पेश कर रहे हैं।)
डेवलपर्स के पास बहुत अधिक नियंत्रण होता है - क्या उन्हें यह जानने की ज़रूरत है कि डेटाबेस में प्रत्येक फ़ील्ड का अंतिम उपयोगकर्ता के लिए क्या अर्थ है? यदि हम डेटा बदलते हैं, तो उपयोगकर्ता क्या देखेंगे? क्या उपयोगकर्ताओं की मदद करने का कोई बेहतर तरीका है? अक्सर डीबी व्यवस्थापकों का विचार यह है कि दुनिया उनके डेटाबेस का एक बुरा प्रतिबिंब है, बजाय इसके कि उनका डेटाबेस वास्तविक दुनिया का खराब प्रतिनिधित्व है। दुनिया गड़बड़ है और आश्चर्यजनक रूप से बढ़त के मामलों से भरी है। इससे निपटें, डीबी व्यवस्थापक।
08. ड्राइंग और लेखन
चित्र कैसा होगा, यह संवाद करने का सबसे सीधा तरीका है। डेवलपर्स को अपने विचारों को व्हाइटबोर्ड, पेपर और बियर मैट पर आकर्षित करने में सक्षम होना चाहिए।
डेवलपर्स को अपने इरादे को संप्रेषित करने के लिए कागज पर प्रोटोटाइप, स्क्रीनशॉट प्रिंट करने और उन पर स्क्रिबल करने में सक्षम होना चाहिए। उस डेवलपर पर भरोसा न करें जो सिर हिलाता है, कहता है कि वे समझते हैं और अपने संपादक को खोलते हैं।
सस्ते में विफल: सबसे अच्छा कोडिंग एक तेजी से प्रोटोटाइप के रूप में ड्राइंग के साथ शुरू होता है। अधिक बार विफल हो जाएं और सुनिश्चित करें कि आपके आस-पास के सभी देव वही करते हैं क्योंकि आपके उस तरह से सफल होने की अधिक संभावना है।
09. आनंद लें
और क्या होगा अगर आपको किसी लिंक को इधर-उधर घुमाकर किसी समस्या को हल करने में 10 घंटे खर्च करने हों? इसका आनंद लें - भले ही यह काम को पूरा करने की चुनौती ही क्यों न हो।
डेवलपर्स (या कोई भी) का सबसे खराब रवैया टीम जो हासिल करने की कोशिश कर रही है, उसके प्रति उदासीनता है। दुर्भाग्य से यह सामान्य है, क्योंकि डेवलपर्स खुद को टीम के हासिल करने से बाहर के रूप में देखते हैं। (भावुक प्रोग्रामर सवाल उठता है, 'आप अपना काम और कितना मजेदार बना सकते हैं?' - इसे आजमाएं।)
और अपना काम दिखाने के लिए तैयार रहें क्योंकि इसका उल्टा है: रूबी पर 'रूबी के अनुभव' के लिए कुछ ट्यूटोरियल आज़माकर विस्तार न करें!
वेब और ऐप विकास अभी भी एक युवा पेशा है, लेकिन कौशल सेट वास्तव में महान देवों की आवश्यकता का विस्तार हो रहा है। सभी को अधिक डेवलपर्स की उम्मीद करनी चाहिए क्योंकि जितनी जल्दी हम सभी खराब बैक रूम से बाहर आएंगे और रचनात्मक प्रक्रिया में शामिल होंगे, परिणाम उतने ही बेहतर होंगे।
10. तेज रहो
इसे एक अच्छे दौर १० तक लाने के लिए मैं एक अंतिम चीज़ जोड़ूंगा। तेज बने रहे। प्रतियोगिता खोजें। किसी भी चीज का सबसे बुरा प्रकार अलगाव में होता है।
"हमेशा हर उस बैंड में सबसे खराब आदमी बनें जिसमें आप हैं।"
सबसे खराब - वास्तव में, बहुत खराब - प्रोग्रामर, कोडर्स, डिजाइनर अपना सामान सीखते हैं और अपनी प्रशंसा पर आराम करते हैं। पेसमेकर के बिना, धीमा करना बहुत आसान है और प्रतिस्पर्धा को देखे बिना खुद को औसत से ऊपर देखने की आदत बन जाती है।
तो, बेहतर खोज कर आप सबसे बुरे बन सकते हैं। काम से बाहर की परियोजनाओं में शामिल हों, योगदान दें और प्रतिक्रिया और आलोचना की तलाश करें क्योंकि जितनी अधिक आलोचना आपको मिलेगी, उतना ही कम लोग आपको भविष्य में देंगे। जब आप अनुमान लगा रहे हैं कि वे उनसे बेहतर क्या चाहते हैं, तो आप निंजा डेवलपर हैं जो हर कोई चाहता है।
डैन फ्रॉस्ट पूर्ण-सेवा वेब कंपनी 3EV के तकनीकी निदेशक हैं, जो एक आधिकारिक AWS भागीदार है। वह सात साल से सीएमएस और वेब ऐप डेवलपमेंट में काम कर रहे हैं।
ये पसंद आया? ये पढ़ सकते हैं!
- ऐप कैसे बनाएं
- डिजाइनरों के लिए सर्वश्रेष्ठ मुफ्त वेब फोंट
- जानें कि ऑगमेंटेड रियलिटी के लिए आगे क्या है Discover
