जब यह आपके व्यक्तिगत फेंक-दूर परियोजनाओं की मेजबानी करने की बात आती है, तो क्या एक सेवा और परियोजना संरचना बाहर खड़ी होती है? [बन्द है]


12

मैं Google कोड, SourceForge, BitBucket और GitHub को देख रहा हूं, क्योंकि वे बड़े खिलाड़ी लगते हैं। अब, मैंने उन सभी विशेषताओं को नहीं तोड़ा है जो वे अभी तक प्रदान करते हैं, लेकिन मैं वास्तव में विभिन्न कोड डालने के लिए एक जगह की तलाश कर रहा हूं जो मैं लिखता हूं (प्रोजेक्ट यूलर के लिए मेरा समाधान, कोड जो मैं कोड गोल्फ के लिए लिख सकता हूं / एक केंद्रीकृत स्थान में प्रोग्रामिंग स्टैक एक्सचेंज, और इसी तरह)।

तो, मेरा पहला सवाल है: इस तरह की स्थिति के लिए, क्या एक सेवा दूसरों के बीच में है?


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

मेरा दूसरा प्रश्न: क्या ऐसी कोई सीमाएँ या रूढ़ियाँ हैं जो यह निर्धारित करने के लिए मौजूद हैं कि आपको अपने कोड नमूने कैसे साझा करने चाहिए, जिन्हें आप खुले बनाने के लिए चुनते हैं, विशेष रूप से इस बात के संदर्भ में कि आप अपने भंडार का निर्माण कैसे करते हैं? मेरा विचार है कि यह आपके द्वारा चुनी गई सेवा द्वारा (समुदाय के सम्मेलनों के आधार पर) तय किया जा सकता है।

जवाबों:


10

बिट बकेट।

वे अपने फ्री पैकेज (प्लस अनलिमिटेड पब्लिक) में एक उत्कृष्ट सेवा, निजी रिपॉजिटरी प्रदान करते हैं और अपने इश्यू ट्रैकर में काफी संवेदनशील होते हैं।

वही, माइनस फ्री प्राइवेट रिपोजिटरीज़, गितुब के लिए सही हैं, लेकिन मैं गित को नापसंद करता हूं। यह एक व्यक्तिगत प्राथमिकता है, मैं git के खिलाफ वकालत नहीं कर रहा हूँ, अगर किसी अजीब कारण से आप इसे hg से अधिक पसंद करते हैं, तो Github पूरी तरह से वैध विकल्प है।

रेपो को कैसे व्यवस्थित किया जाए, इसके लिए भाषाओं को न मिलाएं यदि आप इससे बच सकते हैं। अधिकांश आईडीई इस धारणा के आसपास बनाए गए हैं कि एक परियोजना एक भाषा पर बनाई गई है (वेब ​​परियोजनाओं को छोड़कर जहां भाषा + एचटीएमएल, सीएसएस और जेएस का एक संयोजन अपेक्षित है)। मैं यह नहीं कह रहा हूं कि आईडीई सामना नहीं कर पाएगा, बस कोड पूरा होने जैसी सुविधाएँ थोड़ी धीमी होंगी क्योंकि आईडीई को प्रत्येक भाषा को संभालने के लिए डेटा लोड करना होगा।

यदि आपका रेपो सार्वजनिक है (इसलिए असीमित), तो मैं प्रति प्रोजेक्ट स्कीमा प्रति भाषा रेपो के लिए जाऊंगा, अर्थात "euler_cpp", "euler_python", आदि। यह वास्तव में मायने नहीं रखता कि आप किस सेवा का चयन करते हैं, आप कैसे अपने रिपोज को व्यवस्थित करते हैं। पूरी तरह से आप पर निर्भर है।

फ़ोल्डर संरचना के रूप में, परियोजना euler समाधान के लिए:

  • एक फ़ोल्डर प्रति समस्या, यदि आप एक ही समस्या के विभिन्न समाधान करने की योजना बना रहे हैं
  • एकल समाधान के लिए एक समस्या प्रति फ़ाइल

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

अपडेट करें:

समस्या के प्रति एक फ़ाइल तभी प्रस्तावित की जाती है जब वह वास्तव में लागू होती है और इसे यूलर समस्याओं के समाधान के लिए संभावित स्कीमा के रूप में सुझाया जाता है, क्योंकि यह एकमात्र परियोजना है जो प्रश्न में निर्दिष्ट है।

Btilly की टिप्पणी के अनुसार, मैं कह रहा हूं कि बेहतर / अधिक प्राकृतिक संरचना प्रति भाषा के अनुसार तय की जानी चाहिए, क्योंकि प्रत्येक भाषा और / या मंच में फ़ाइलों और फ़ोल्डरों के संबंध में स्वयं कन्वेंशन और अभ्यास हैं।


1
फ़ोल्डर संरचना भाषा पर निर्भर होनी चाहिए। एक स्क्रिप्टिंग भाषा का उपयोग करने वाला व्यक्ति अक्सर एक फ़ाइल में कोड लिखता है जो C / C ++ में स्वाभाविक रूप से एक फ़ोल्डर में कई फ़ाइलों में लिखा जाएगा।
18

@ बीटीली राइट। मैं आपकी टिप्पणी उत्तर में जोड़ रहा हूं ...
यानि

मैं वास्तव में विशेष रूप से इस बात की तलाश नहीं कर रहा था कि किसी परियोजना के भीतर फाइलों को कैसे रखा जाए, लेकिन उपयोग की जाने वाली सेवा के भीतर कई परियोजनाओं को कैसे रखा जाए।
थॉमस ओवंस

@Thomas कैसे रेपोस को व्यवस्थित करने के लिए के रूप में ... । परंपरागत रूप से आपके पास प्रति भंडार के लिए एक परियोजना होगी। क्या आप प्रत्येक सेवा पर विशिष्ट निर्देशों की तलाश कर रहे हैं?
यानि

मैं जो कुछ भी देख रहा हूं वह प्रत्येक समुदाय के भीतर मौजूद है, अगर कोई चीज सामान्य से बाहर है। मेरे अनुभवों में, BitBucket, GitHub, और SourceForge जैसी चीजें केवल सेवाओं की तुलना में मानदंडों और सम्मेलनों के साथ समुदायों के अधिक हैं (हालांकि कुछ लोग उन्हें सेवाओं की तरह उपयोग करते हैं)।
थॉमस ओवंस

3

आप एक विकल्प भूल गए - अपने स्वयं के भंडार की मेजबानी। वास्तव में हाल तक उड़ान भरने का एकमात्र तरीका था।

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


मैंने बहुत दर्द के बिना VisualSVN के साथ ऐसा किया।
कोडी सैंड

वहाँ किया गया था कि। आप Turnkeylinux.org उपकरणों के साथ और भी अधिक प्रभावी हो सकते हैं । ।
वायट बार्नेट

3

Google कोड, SourceForge और GitHub को समय पर अलग-अलग बिंदुओं पर उपयोग करने के बाद, मैं कहूंगा कि GitHub अन्य दो की तुलना में बहुत बेहतर है:

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

इसके अलावा, Github, Gists के उपयोग के माध्यम से प्रोजेक्ट यूलर समाधान और कोड गोल्फ स्निपेट जैसी चीजों को संग्रहीत करने के लिए एकदम सही है।
मैट एलेन

1

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

यह मानते हुए कि मेरे पास एक परियोजना है जो उस बिंदु पर पहुंच जाती है जहां मैं इसे वितरित करना चाहता हूं, मैं हमेशा इसे अधिक दृश्यता के लिए बिटबकेट में स्थानांतरित कर सकता हूं। इसमें यूलर प्रोजेक्ट समाधान के लिए कोड शामिल नहीं है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.