Microsoft के बाद बड़ा स्विच या जीवन: हमने .NET क्यों कहा

हाल तक तक, समर्पित रूप से Microsoft .NET के बैनर को चलाया। सिल्वरलाइट, ASP.NET MVC की प्रशंसा की और चमत्कार में विश्वास किया। .NET के साथ काम करने के चार वर्षों में, वह एक विस्तृत श्रृंखला पर एक प्रमाणित डेवलपर बन गया है

टेक्नोलॉजीज: ASP.NET, WCF, WPF, ADO.NET। हालांकि, अपनी खुद की इंटरनेट एजेंसी के अस्तित्व के वर्ष के दौरान, यह चुने हुए रास्ते में निराश हो गया और एक अलग विश्वास में परिवर्तित हो गया।







"Microsoft के बाद बड़ा स्विच या जीवन" लेखों की एक श्रृंखला में, मैं Windows + .NET वेब तकनीक स्टैक से लिनक्स + रूबी से संक्रमण में हमारी टीम द्वारा प्राप्त अनुभव के बारे में बात करूंगा, साथ ही उपयोग के लिए विशिष्ट निर्देश जो पहले मदद करेगा।



मैं 3 कारणों से शुरू करूंगा जिन्होंने हमें ना कहने के लिए प्रेरित किया।

1. निर्भरता

.NET उत्पादों के साथ काम करते समय, आप अपने आप को लत के लिए बर्बाद करते हैं। भुगतान किए गए सॉफ़्टवेयर पर निर्भरता और भुगतान किए गए घटकों की एक अनंत संख्या, ग्राफिकल इंटरफ़ेस से शुरू होकर IMAP के मेल के सामान्य संग्रह के साथ समाप्त होती है।



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



यदि आप केवल हार्डवेयर खरीदने या किराए पर लेने के लिए अपने निर्णयों को मापना चाहते हैं, तो .NET आपके लिए नहीं है।

2. बंद होना

लाइसेंस के खिलाफ लड़ाई के लिए समय और संसाधनों की अतिरिक्त लागत केवल आधी परेशानी है, बहुत अधिक भयानक .NET प्रौद्योगिकी और इसके समुदाय की निकटता है।



एक भुगतान पुस्तकालय का चयन करना, एक नियम के रूप में, आपको गुणवत्ता द्वारा निर्देशित नहीं किया जाता है, लेकिन साइट पर लिखे गए विज्ञापन स्लोगन द्वारा।



अधिक महत्वपूर्ण कारकों के आधार पर एक खुले स्रोत उत्पाद की गुणवत्ता का आकलन किया जा सकता है:

• टेस्ट कवरेज।
• अपडेट की आवृत्ति।
• डाउनलोड की संख्या।
• डेवलपर्स की संख्या और व्यक्तित्व।

खुली प्रौद्योगिकियों के साथ काम करते समय, आप सीधे विकास को प्रभावित कर सकते हैं। उत्पाद विकसित करने वाले लोग सार्वजनिक रूप से जाने जाते हैं और उनके साथ सीधे संपर्क स्थापित करना आसान है। उत्पन्न होने वाली समस्या को स्वतंत्र रूप से हल किया जा सकता है, और समाधान डेवलपर्स और अन्य समुदाय के सदस्यों को परीक्षण के लिए भेजा जा सकता है।



परिणामस्वरूप, ओपन सोर्स उत्पादों को अधिक बार अपडेट किया जाता है, वे डेवलपर्स की अधिक आवश्यकताओं को ध्यान में रखते हैं, और उनकी कार्यक्षमता बंद समाधान से कई कदम आगे है।



यह ध्यान देने योग्य है कि Microsoft ने खुले स्रोत की ओर कदम उठाना शुरू कर दिया है। हालांकि, अभी तक इसे केवल ढोंगी कहा जा सकता है, क्योंकि वास्तव में केवल एक विशेष बीटा या रिलीज के अनुरूप स्लाइस बाहर रखी जाती हैं। नतीजतन, समुदाय अभी भी उत्पाद के जीवन में उदासीन है और मुंह में लार के साथ अगली रिलीज की प्रतीक्षा कर रहा है। आश्वस्त होने के लिए, मैं ASP.NET MVC प्रोजेक्ट कमिट लॉग का हवाला देता हूँ:

3. Microsoft तरीका

एक ही निकटता के कारण एक और समस्या माइक्रोसॉफ्ट की परंपरा है कि वह अपने तरीके से सब कुछ कर सकती है। यह वेब मानकों और अपने स्वयं के उत्पादों को डिजाइन करने के दृष्टिकोण के साथ समस्याओं में परिलक्षित होता है।



कल, Microsoft अपने स्वयं के जावास्क्रिप्ट ढांचे का निर्माण कर रहा था, और लाभ ने अंततः Jquery को पेश किया। ASP.NET तकनीक के बारे में भी यही कहा जा सकता है, जो ASP.NET MVC के आगमन से 5 साल पहले पूरी तरह से विफल हो गया था।



ASP.NET MVC द्वारा निर्धारित सकारात्मक प्रवृत्ति के बावजूद (एक वेब फ्रेम पूरी तरह से रूबी ऑन रेल्स को डुप्लिकेट करता है, हालांकि, एक गतिशील भाषा के आकर्षण से रहित), Microsoft अभी भी उसी रेक पर कदम रख रहा है। इसलिए, उदाहरण के लिए, नए संस्करण में, हमाल को पालने के बजाय , उन्होंने हमें रेजर का वादा किया, जो "बहुत सुविधाजनक" होगा और हर कोई "खुश" होगा।



एक समान प्रवृत्ति साधारण .NET डेवलपर्स के बीच देखी जाती है। अपवाद के बिना, वे सभी अपने प्रमाणीकरण, प्राधिकरण रूपरेखा लिखते हैं, मैन्युअल रूप से डेटाबेस में सत्र जीवन चक्र प्रबंधन को लागू करते हैं, और इस सूची को अनिश्चित काल तक जारी रखा जा सकता है। हालांकि, ऐसी पहल हमेशा परियोजनाओं की गुणवत्ता पर अच्छी तरह से प्रतिबिंबित नहीं होती है।







एक बिंदु पर, हमने महसूस किया कि हमारी परियोजनाओं में हम आधे से अधिक समय खर्च करते हैं। .NET खामियों को दूर करने और अपनी खुद की "बाइक" का आविष्कार करते हैं, जिसका विकास की समयरेखा पर बहुत नकारात्मक प्रभाव पड़ता है।



वैकल्पिक खुले स्रोत समाधानों का विश्लेषण करने के बाद, हम रूबी ऑन रेल्स फ्रेमवर्क पर बस गए, जिसमें हमारी राय में एक बहुत बड़ा और महत्वपूर्ण पेशेवर समुदाय है (आप परीक्षण के बिना शायद ही कभी एक परियोजना पा सकते हैं)।



इस श्रृंखला के बाद के लेखों में, मैं ASP.NET MVC और अन्य Microsoft उत्पादों पर रेल्स पर रूबी के लाभों के ठोस उदाहरण दिखाऊंगा, और लिनक्स दुनिया और खुली प्रौद्योगिकियों से दूर के लोगों के लिए आसानी से रूबी पर स्विच करने के निर्देश प्रदान करूंगा।