- Replit – Build apps and sites with AI
- Replit is an AI-powered platform for building professional web apps and websites.
Replit का एक वर्ष का पेड सब्सक्रिप्शन
मुझे एक AI प्रोग्रामिंग टूल आज़माना था, इसलिए मैंने 12/1 तक ब्लैक फ्राइडे की सेल के दौरान सब्सक्रिप्शन ले लिया।
मैंने इसे इसलिए चुना क्योंकि मेरे पास कोई अच्छा कंप्यूटर नहीं है,
- कंपाइलर या इंटरप्रेटर को स्थानीय रूप से स्थापित करने की आवश्यकता के बिना ब्राउज़र में निष्पादन और परिणामों की जाँच करें
- सेटिंग की चिंता किए बिना प्रोग्रामिंग सीखें।
- सहयोगी कोडिंग प्रोजेक्ट। (यदि मैं लिंक साझा करता हूँ, तो हम पेयर प्रोग्रामिंग कर सकते हैं) - यदि आवश्यक हो तो कोई भी शामिल हो सकता है।
- कोड का त्वरित प्रोटोटाइप और परीक्षण।
- इंटरैक्टिव तरीके से छात्रों को कोडिंग सिखाना।
- लाइटवेट वेब एप्लिकेशन या एपीआई होस्टिंग।
मुझे इसके साथ आगे चलकर एक वीडियो भी बनाना होगा। https://replit.com/
दुनिया को देखते हैं। (विभिन्न समाचार)
अर्थव्यवस्था
2024-11-29 (शुक्र) सुबह की दिनचर्या (हान्क्योंग) : दक्षिण कोरिया ब्याज दर में कमी 3.25 -> 3.0% / आय असमानता में वृद्धि, खपत में कमी / एक्सोब्ल शोल्डर (पहनने योग्य रोबोट) / कंडीशनल स्टॉक ईटीएफ 20% वृद्धि (विदेशियों ने खरीदा है)
>> अंत में, अगर विदेशी नहीं खरीदते हैं, तो शेयर बाजार में वृद्धि का कोई तरीका नहीं है।
आईटी
- 지금 주목해야 할 ‘생성 AI 소비 트렌드’ TOP 4 | 요즘IT
- 미국의 주요 기업들이 올해 3분기 실적을 발표했습니다. 실적 발표 자리에서 소위 빅테크 기업들은 생성 AI에 대한 투자를 지속할 것임을 예고했습니다. 천문학적인 금액이 쏟아지고 있는 만큼, 생성 AI 산업을 구성하는 트렌드는 빠른 속도로 변화하고 있는데요. 이번 글에서는 지난 8월 안드레센 호로위츠가 발표한 자료를 토대로 사용자들이 실제 어떤 생성 AI 서비스를 사용하고 있는지, 소비 트렌드를 살펴보고자 합니다.
- 코드 작성 시간 절반으로 줄여줄 5가지 개발 툴 | 요즘IT
- 여러분은 매일 코드 작성과 디버깅에 얼마나 많은 시간을 소비하나요? 지금부터 소개해 드릴 AI와 자동화 툴 5가지만 제대로 활용해도 그 시간을 절반으로 줄일 수 있습니다. 개발자의 하루는 해결해야 할 문제로 가득하니까요. 코드 작성을 도와주는 GitHub Copilot부터 코드 품질을 한눈에 개선해 주는 SonarQube까지. 이 툴들은 어떻게 여러분의 개발 생산성과 코드 품질을 끌어올려 줄까요?
एक बेहतर डेवलपर बनने के लिए 10 आदतें
>> टेलीमेटिक्स/क्लस्टर प्लेटफ़ॉर्म को बनाते और बनाए रखते हुए, मैंने जो महसूस किया, वही, लेकिन मैं इसे ठीक से लागू नहीं कर सका। मुझे परिवर्तन से डरना नहीं चाहिए, और यदि मैं इसे इस तरह से छोटे-छोटे हिस्सों में विभाजित कर दूँ, तो यह संभव लगता है।
1. कमिट को इतना छोटा रखें कि आपको लगे, "क्या इतना छोटा करना चाहिए?"
क्योंकि आपको कभी नहीं पता कि आपको किसी विशिष्ट परिवर्तन को रोलबैक करने की आवश्यकता कब होगी। 6 दिन पहले की बग के सटीक स्थान को जानना और बिना किसी जटिल मर्ज कॉन्फ़्लिक्ट के केवल उस कमिट को रोलबैक करने में सक्षम होना एक बड़ी राहत देता है। मेरे लिए मानदंड सरल है: यदि कोड संकलित होता है, तो मैं इसे कमिट कर सकता हूँ।
2. केंट बेक के सिद्धांत का पालन करें: "विस्तृत परिवर्तन के लिए पहले उस परिवर्तन को आसान बनाएँ (सावधानी: यह कठिन हो सकता है), फिर आसान परिवर्तन करें।"
"विस्तृत परिवर्तन के लिए पहले उस परिवर्तन को आसान बनाएँ (सावधानी: यह कठिन हो सकता है), फिर आसान परिवर्तन करें।"
अपने सभी कमिट का आधा से ज़्यादा रिफ़ैक्टरिंग होने दें। निरंतर रिफ़ैक्टरिंग का मतलब है 10 मिनट के भीतर किए जा सकने वाले सुधारों की तलाश करना और उन्हें लागू करना। इन छोटे सुधारों के कारण, बाद में बड़ी आवश्यकताएँ आने पर उन्हें सरल परिवर्तनों से हल किया जा सकता है। बड़े पैमाने पर रिफ़ैक्टरिंग से बचना चाहिए।
3. सभी कोड ऋण है।
गैर-परिनियोजित कोड ऋण में से ऋण है। यह सुनिश्चित करना होगा कि कोड ठीक से काम कर रहा है, कम से कम अन्य कार्यों को तोड़ नहीं रहा है। परीक्षण आत्मविश्वास प्रदान करता है, और उत्पादन परिनियोजन सत्यापन प्रदान करता है। बार-बार परिनियोजित करने से होस्टिंग लागत थोड़ी बढ़ सकती है, लेकिन यह जानकर कि अंतिम काम वास्तविक प्रगति थी, यह पूरी तरह से इसके लायक है। एजाइल सिद्धांतों में से एक है, "काम करने वाला सॉफ़्टवेयर प्रगति का प्रमुख उपाय है।" यहाँ 'काम' और 'प्रगति' शब्दों का एक केंद्रीय महत्व है, इसलिए मैंने अपनी परिभाषा दी है। 'काम करना' का मतलब परिनियोजन योग्य स्तर है, और यदि कोई कोड किसी फ़ंक्शन में योगदान देता है, तो यह 'प्रगति' है।
4. क्या आप फ़्रेमवर्क के कार्यों का परीक्षण कर रहे हैं? अगर हाँ, तो मत करो।
फ़्रेमवर्क का परीक्षण पहले ही आपके मुकाबले कहीं ज़्यादा अनुभवी लोगों द्वारा किया जा चुका है, और आपको यह विश्वास करना होगा कि useState() हुक इरादे के मुताबिक काम करता है। घटकों को छोटा रखने से फ़्रेमवर्क अधिकांश मुख्य कार्यों को संभालता है, इसलिए बहुत सारे परीक्षणों की आवश्यकता नहीं होती है। घटक बड़े होने पर जटिलता बढ़ जाती है और उतने ही अधिक परीक्षण लिखने पड़ते हैं।
5. यदि कोई विशिष्ट फ़ंक्शन कहीं भी फिट नहीं होता है, तो एक नया मॉड्यूल (या क्लास या घटक) बनाएँ और बाद में उपयुक्त स्थान ढूँढ़ें।
जहाँ यह फिट नहीं होता है, वहाँ इसे जबरदस्ती फिट करने के बजाय, एक नई स्वतंत्र संरचना बनाना बेहतर होता है। सबसे खराब स्थिति में भी, एक स्वतंत्र मॉड्यूल के रूप में रहना इतना बुरा नहीं है।
6. यदि आप नहीं जानते कि एपीआई कैसा दिखना चाहिए, तो पहले परीक्षण लिखें।
यह आपको "ग्राहक" के दृष्टिकोण से, जो इस मामले में आप स्वयं हैं, सोचने के लिए मजबूर करता है। यदि आपने पहले कोड लिखा था और बाद में परीक्षण किया था, तो आप उन मामलों का पता नहीं लगा पाते जो आप पा सकते हैं। TDD के प्रति बहुत कट्टर होने की आवश्यकता नहीं है, और बड़ी इकाइयों के साथ काम करना ठीक है (जैसे: कई लाइन कोड लिखने से पहले परीक्षण पास करना)। विफल कोड की मात्रा हमेशा कम होने की आवश्यकता नहीं होती है। अगर आप जानते हैं कि आप क्या कर रहे हैं, तो सुनिश्चित करें कि सिद्धांत उत्पादकता में बाधा नहीं डालते हैं।
7. कॉपी-पेस्ट एक बार ठीक है।
दूसरी बार दोहराएँ (यानी तीसरी कॉपी) नहीं। इस समय तक, एक अच्छा सार बनाने के लिए पर्याप्त उदाहरण होंगे। समान फ़ंक्शन के कार्यान्वयन के अलग-अलग होने का जोखिम बहुत अधिक है, इसलिए एकीकरण की आवश्यकता है। कई बार एक समान फ़ंक्शन को लागू करने के बजाय, थोड़ा अजीब पैरामीटरीकरण बेहतर है। अगर यह स्थिति फिर से होती है, तो चार अलग-अलग कार्यान्वयन को एकीकृत करने की तुलना में पैरामीटर को बेहतर बनाना आसान होगा।
8. डिज़ाइन पुराने हो जाते हैं।
रिफ़ैक्टरिंग से इसकी गति को धीमा किया जा सकता है, लेकिन अंततः आपको काम करने के तरीके को बदलना होगा। जब आप उन चीज़ों को छोड़ देते हैं जिन्हें आपने पहले कीमती और गर्व किया था, तो बहुत दुखी न हों। उस समय आपने अपनी पूरी कोशिश की थी, और आपको खुद को दोषी महसूस करने की ज़रूरत नहीं है क्योंकि आपने इसे पूरी तरह से नहीं बनाया था। सॉफ़्टवेयर डेवलपमेंट का अधिकांश भाग सॉफ़्टवेयर को बदलना है। इसे स्वीकार करें और आगे बढ़ें। कोई भी सही डिज़ाइन नहीं है, और परिवर्तन सॉफ़्टवेयर डेवलपमेंट का मुख्य हिस्सा है। डेवलपर के रूप में आपकी क्षमता यह निर्धारित करती है कि आप कितनी कुशलता से परिवर्तन कर सकते हैं।
9. तकनीकी ऋण को तीन श्रेणियों में वर्गीकृत किया जा सकता है:
1) वे चीज़ें जो वर्तमान कार्य में बाधा डालती हैं, 2) वे चीज़ें जो भविष्य के काम में बाधा डालेंगी, 3) वे चीज़ें जो भविष्य के काम में बाधा डाल सकती हैं। अन्य सभी वर्गीकरण इन तीनों का सबसेट हैं। #1 से संबंधित वस्तुओं को कम करें और #2 पर ध्यान केंद्रित करें। #3 के बारे में चिंता न करें।
10. परीक्षण क्षमता अच्छे डिज़ाइन से निकटता से संबंधित है।
आसानी से परीक्षण न कर पाना यह संकेत देता है कि डिज़ाइन को बदलना होगा। कभी-कभी वह डिज़ाइन परीक्षण डिज़ाइन हो सकता है। उदाहरण के लिए, यदि em.getRepository(User).findOneOrFail({id}) को मॉक करना मुश्किल है, तो उस कॉल को एक अलग फ़ंक्शन में मॉक करने योग्य बनाना या परीक्षण उपयोगिताएँ लिखना जो एंटिटी मैनेजर विधियों को आसानी से मॉक कर सकें, बेहतर होगा। परीक्षण नहीं लिखे जाने का कारण यह नहीं है कि वे लिखना नहीं चाहते हैं, बल्कि इसलिए कि वे लिखना मुश्किल है।
टिप्पणियाँ0