इन्फ्यूजन एक ओपन-सोर्स टूल है जिसका उपयोग आपकी कोड फ़ाइलों में दस्तावेज़ तैयार करने के लिए किया जाता है। यह टिप्पणियाँ लिखने के लिए OpenAI gpt-4 मॉडल का उपयोग करता है। यह मेरा प्रोजेक्ट था और मैंने इसे पायथन में लिखा था।

गिटहब लिंक:
https://github.com/SychAndrii/infusion

explaner.js एक ओपन-सोर्स टूल है जिसका उपयोग आपकी कोड फ़ाइलों में कोड स्निपेट को समझाने के लिए किया जाता है। यह टिप्पणियाँ लिखने के लिए ग्रोक मॉडल का उपयोग करता है। यह मेरी टीम के साथी @aamfahid का एक प्रोजेक्ट था और उन्होंने इसे Node.JS में लिखा था

गिटहब लिंक:
https://github.com/aamfahid/explainer.js

मैं वर्तमान में सेनेका पॉलिटेक्निक में एक ओपन-सोर्स कोर्स में नामांकित हूं, जहां हमें एक अन्य व्यक्ति के साथ टीम बनाने और एक-दूसरे के कोड की समीक्षा करने और GitHub मुद्दों का उपयोग करके सुधार के लिए कुछ सुझाव देने का काम सौंपा गया था। मैं इस प्रक्रिया का वर्णन करने जा रहा हूं।

संचार का तरीका

दोनों रिपॉजिटरी के लिए उत्पन्न अधिकांश मुद्दे डिस्कॉर्ड कॉल के माध्यम से सिंक्रोनस संचार का उपयोग करके किए गए थे। उसके बाद, हमने डिस्कोर्ड संदेशों का उपयोग करके अतुल्यकालिक रूप से बात की, क्योंकि मेरे लिए बैश स्क्रिप्ट का उपयोग करके अपने प्रोजेक्ट के सेटअप को सुव्यवस्थित करना एक कठिन मुद्दा था, और जब भी मुझे यह परीक्षण करने की आवश्यकता होती थी कि यह उसकी मशीन पर काम करता है या नहीं, तो अपने टीम के साथी को कॉल करना अनावश्यक लगता था। मेरी मशीन पर डॉकर कंटेनरों और डब्लूएसएल लिनक्स सब सिस्टम का उपयोग करके परीक्षण करना अल के सिस्टम पर उनके परीक्षण के समान नहीं था, और इसने महत्वपूर्ण बगों को उजागर किया।

किसी के कोड की समीक्षा करने का अनुभव

अपने टीम के साथी के कोड की समीक्षा करते समय मुझे कुछ भी असामान्य अनुभव नहीं हुआ, क्योंकि मेरे पास Node.JS विकास के साथ बहुत अनुभव है। हालाँकि, मुझे मुद्दे बनाना और फिर तुरंत उनका समाधान सुझाना पसंद है। हमारी एक समस्या यह थी कि हम मेरे द्वारा बनाए गए मुद्दों पर लेबल लगाने की अनुमति देने का कोई तरीका नहीं ढूंढ पा रहे थे, केवल अल ही ऐसा कर सकता था, जो कष्टप्रद था।

मेरे कोड की समीक्षा करने वाले किसी व्यक्ति का अनुभव

अल ने सुधार की बहुत गुंजाइश सुझाई, खासकर मेरे सीएलआई टूल की स्थापना के मामले में। जब उन्होंने पहली बार मेरे रेपो को फोर्क किया, तो अंतिम उपयोगकर्ताओं के लिए मैन्युअल रूप से पायथन के एक विशेष संस्करण को स्थापित करना एक आवश्यकता थी, जो निश्चित रूप से एक निराशाजनक कार्य है। इसके अतिरिक्त, उन्होंने टूल के सुविधाजनक उपयोग के लिए अन्य संभावित सुधारों पर प्रकाश डाला, जैसे .env फ़ाइल शुरू करना ताकि आपको हर बार टूल शुरू करने पर अपनी एपीआई कुंजी इनपुट न करनी पड़े। मुझे अपने कोड पर अन्य लोगों से इनपुट प्राप्त करना पसंद है क्योंकि यह मुझे एक डेवलपर के रूप में विकसित होने की अनुमति देता है और यह निश्चित रूप से विकास जीवनचक्र के बारे में मेरे दृष्टिकोण का विस्तार करता है।

समीक्षा और परीक्षण के दौरान मुद्दे

हमें ज्यादातर समस्याएं मेरे टूल के साथ थीं, क्योंकि अल का सीएलआई कार्यक्रम नोड.जेएस में लिखा गया था और हम दोनों को इसके साथ काफी अनुभव है। इसके विपरीत, हम दोनों को पायथन पारिस्थितिकी तंत्र पसंद नहीं है, इसलिए हमें इसके साथ बातचीत करने में बहुत परेशानी हुई। अल के भंडार का परीक्षण करते समय, मैंने पाया कि उसके रीडमी में लिखे दस्तावेज़ भ्रामक या समझने में भ्रमित करने वाले थे, विशेषकर मॉडल और एपीआई-कुंजी विकल्प। हमें यह पता लगाने के लिए परीक्षणों और त्रुटियों की प्रक्रिया से गुजरना पड़ा कि कौन सी एपीआई कुंजी और मॉडल उसके टूल द्वारा स्वीकार किए जाते हैं। जब मेरी रिपॉजिटरी का परीक्षण करने की बात आई, तो अल के सिस्टम पर पायथन का संस्करण बहुत पुराना (2.7) था, इसलिए उसे 3.10.6 (संस्करण, मेरे टूल का उपयोग करने के लिए आवश्यक संस्करण) को मैन्युअल रूप से इंस्टॉल करना पड़ा। हालाँकि, फिर भी समस्याएँ ख़त्म नहीं हुईं। भले ही उन्होंने इसे इंस्टॉल किया था, फिर भी इसे मेरे टूल द्वारा पिपेनव के साथ बनाए गए वर्चुअल वातावरण द्वारा पहचाना नहीं जा रहा था। उसके बाद, हर बार जब हम अपने टूल को शुरू करते थे तो उसके उपयोग के लिए आवश्यक एपीआई कुंजी दर्ज करने में हमें निराशा होती थी। अंततः, README डॉक्स ने इंस्टालेशन में मदद नहीं की। हमने उनका अनुसरण करने का प्रयास किया, लेकिन हमें कुछ स्क्रिप्ट्स को PATH पर मान्यता न मिलने से संबंधित त्रुटियां मिलती रहीं। तभी मैंने निर्णय लिया कि हमें किसी प्रकार के स्वचालन उपकरण की आवश्यकता है जो आपके लिए सभी इंस्टॉलेशन करे। मैंने सोचा था कि एप्लिकेशन को डॉकराइज़ करना है, लेकिन फिर मुझे किसी तरह डॉकर वॉल्यूम को आउटपुट निर्देशिका और मेरे टूल के लिए निर्दिष्ट इनपुट फ़ाइलों में मैप करने की आवश्यकता होगी, और इससे सब कुछ दो बार जटिल हो जाएगा। इस प्रकार, मुझे याद आया कि बहुत सारे पैकेज मैनेजर वास्तव में कमांड लाइन टूल हैं, और यदि आप उन्हें GitHub रेपो क्लोन करके इंस्टॉल करते हैं, तो आपको उन्हें किसी प्रकार की बैश सेटअप स्क्रिप्ट निष्पादित करके सेट करना होगा। तो यही वह विचार था जिसे मैंने लागू करने का निर्णय लिया। अंततः, हम दोनों हमारे द्वारा दायर किए गए मुद्दों पर बग या एन्हांसमेंट जैसे लेबल निर्दिष्ट करने का कोई तरीका नहीं समझ सके।

मेरे द्वारा दायर किए गए मुद्दे

https://github.com/aamfahid/explainer.js/issues/13
https://github.com/aamfahid/explainer.js/issues/12
https://github.com/aamfahid/explainer.js/issues/11
https://github.com/aamfahid/explainer.js/issues/10
https://github.com/aamfahid/explainer.js/issues/9

मुझे जो समस्याएं मिलीं, उन्हें संक्षेप में बताने के लिए, उन्होंने ज्यादातर ऐसे मामलों को कवर किया जब इस परियोजना की रीडमी फ़ाइल में लिखे गए विकल्प वास्तव में काम नहीं करते थे, या उनके काम करने के तरीके को भ्रामक रूप से वर्णित किया गया था।

वे मुद्दे जो मेरे रेपो पर दायर किए गए थे

https://github.com/SychAndrii/infusion/issues/11
https://github.com/SychAndrii/infusion/issues/10
https://github.com/SychAndrii/infusion/issues/9
https://github.com/SychAndrii/infusion/issues/8

मेरे रेपो में पाए गए मुद्दों को संक्षेप में प्रस्तुत करने के लिए, वे ज्यादातर मेरे टूल के उपयोग की सुविधा से संबंधित थे। इसके अतिरिक्त, जब आपने मेरे टूल को वाक्यात्मक रूप से सही स्रोत कोड के साथ एक फ़ाइल प्रदान की थी, तो एक बग था, और इसने इसे एक ऐसी फ़ाइल के रूप में पहचाना जिसमें वैध स्रोत कोड नहीं है।

वे मुद्दे जिन्हें मैं ठीक करने में कामयाब रहा

मैंने अपनी सभी समस्याएं ठीक कर ली हैं। उन सभी को ठीक करने में 30 मिनट से भी कम समय लगा, लेकिन एक समस्या थी, जिसे ठीक करने में मुझे 2-3 घंटे लग गए:
https://github.com/SychAndrii/infusion/issues/8

यह अजीब लगता है क्योंकि README फ़ाइल का संवर्द्धन आसानी से प्राप्त किया जा सकता है, लेकिन अल के पहले सुझाव के अनुसार मुझे अपने टूल की इंस्टॉलेशन प्रक्रिया को पूरी तरह से रीमेक करने की आवश्यकता थी, जिसके लिए मुझे इंस्टॉलेशन के लिए 2 स्क्रिप्ट पेश करने की आवश्यकता थी - एक बैश के लिए और एक पावरशेल के लिए एक। समस्या जो मैं अधिकांश समय हल नहीं कर सका वह यह थी कि भले ही इन सेटअप स्क्रिप्ट्स ने पायथन के आवश्यक संस्करण को ठीक से स्थापित किया था, फिर भी पायथन का यह संस्करण वर्चुअल वातावरण में पारित नहीं हुआ था, जिसे आपको मेरे टूल का उपयोग करने से पहले दर्ज करना होगा। अंततः, मैंने उसे ठीक कर दिया।

मैंने क्या सीखा

मैंने निश्चित रूप से अपने README कौशल में सुधार किया है। जिस तरह से मैंने उदाहरण उपयोग प्रदान किया वह अंतिम उपयोगकर्ता के लिए बहुत भ्रमित करने वाला था। इसके अतिरिक्त, मैंने अंततः स्वयं कुछ करने के लिए बैश और पॉवरशेल भाषाओं का उपयोग किया है, किसी स्कूल असाइनमेंट के लिए नहीं, इसलिए नहीं कि यह एक आवश्यकता थी, बल्कि इसलिए कि मैं अपने टूल के साथ इंटरैक्ट करने की प्रक्रिया को सरल बनाना चाहता था। अंत में, मैंने उस भाषा का सामना करने का फैसला किया जिसे मैं बिल्कुल बर्दाश्त नहीं कर सकता - जो कि पायथन है। इसके साथ काम करना निश्चित रूप से मेरे लिए आनंददायक नहीं था, लेकिन मुझे लगता है कि अगर आप आज नौकरी ढूंढना चाहते हैं, खासकर एआई ट्रेंडिंग के साथ, तो इसका उपयोग करने में सक्षम होना आवश्यक है।