प्रैक्टिस अभ्यास

प्रैक्टिस अभ्यास ऐसे अभ्यास हैं जो छात्रों को कोई भी समस्या हल करने देते हैं। इनका उद्देश्य यह है कि छात्र अब तक सीखे गए कॉन्सेप्ट इस्तेमाल कर सकें।

क्या आप अपना पहला प्रैक्टिस अभ्यास किसी ट्रैक में जोड़ना चाहते हैं? प्रैक्टिस अभ्यास जोड़ने के दस्तावेज़ देखिए या हमारा वॉकथ्रू वीडियो देखिए 👇

Note

ट्रैक की रूट डायरेक्टरी से ये कमांड चलाकर आप जल्दी से एक नए प्रैक्टिस अभ्यास का ढाँचा बना सकते हैं:

bin/fetch-configlet
bin/configlet create --practice-exercise <slug>

ज़्यादा जानकारी के लिए configlet create के दस्तावेज़ देखिए

मेटाडेटा

प्रैक्टिस अभ्यास का मेटाडेटा config.json फ़ाइल की exercises.practice की में परिभाषित किया जाता है। यह मेटाडेटा अभ्यास का UUID, स्लग और बहुत कुछ तय करता है।

उदाहरण

{
  "exercises": {
    "practice": [
      {
        "uuid": "8ba15933-29a2-49b1-a9ce-70474bad3007",
        "slug": "leap",
        "name": "Leap",
        "practices": ["if-statements", "numbers", "operator-precedence"],
        "prerequisites": ["if-statements", "numbers"],
        "difficulty": 1
      }
    ]
  }
}

`practices`

practices की में उन कॉन्सेप्ट के स्लग होने चाहिए जिनका अभ्यास यह प्रैक्टिस अभ्यास छात्र को सक्रिय रूप से करने देता है।

ये UI में "Practice this Concept in: TwoFer, Leap, etc" के रूप में दिखते हैं
हर कॉन्सेप्ट के लिए 3 से 8 अभ्यास चुनने की कोशिश कीजिए।
कम से कम दो ऐसे अभ्यास चुनने की कोशिश कीजिए जिनसे किसी कॉन्सेप्ट की मूल बातों का अभ्यास हो सके।
कुछ कॉन्सेप्ट बहुत आम होते हैं (जैसे strings)। ऐसे मामलों में हम कुछ अच्छे अभ्यास चुनने की सलाह देते हैं जो लोगों को उन कॉन्सेप्ट के बारे में दिलचस्प तरीकों से सोचने पर लगाएँ। जैसे, ऐसे अभ्यास जिनमें UTF-8, स्ट्रिंग जोड़ना, अक्षरों को एक-एक करके देखना आदि की ज़रूरत पड़े, ये सब अच्छे उदाहरण होंगे।

`prerequisites`

prerequisites की में वे कॉन्सेप्ट होते हैं जिन्हें छात्र ने पूरा किया हो, तभी वह इस प्रैक्टिस अभ्यास तक पहुँच सकता है।

ये UI में "Learn Strings to unlock TwoFer" के रूप में दिखते हैं
इसमें वे सारे कॉन्सेप्ट शामिल होने चाहिए जो छात्र ने कवर किए हों, ताकि वह अभ्यास को कम से कम एक मुहावरेदार तरीके से पूरा कर सके। जैसे, Ruby के TwoFer अभ्यास के लिए prerequisites में strings, optional-params, implicit-return शामिल हो सकते हैं।
जिन अभ्यासों को अलग-अलग कॉन्सेप्ट से पूरा किया जा सकता है (जैसे कोई अभ्यास loops या recursion से हल हो सकता है), उनके लिए मेंटेनर को वही एक तरीका चुनना चाहिए जिससे वे अभ्यास अनलॉक करना चाहते हैं, और साथ में ट्रैक में छात्र की यात्रा का ध्यान रखना चाहिए। जैसे, loops/recursion वाले उदाहरण में वे सोच सकते हैं कि यह अभ्यास loops के शुरुआती अभ्यास के लिए अच्छा है, या वे इसे बाद के लिए छोड़कर recursion सिखाना चाहते हैं। वे एनालाइज़र की मदद से छात्र को दूसरा तरीका आज़माने के लिए भी कह सकते हैं: "Nice work on solving this via loops. You might also like to try solving this using Recursion."

फ़ाइलें

हर प्रैक्टिस अभ्यास की अपनी एक डायरेक्टरी होती है, जो ट्रैक की exercises/practice डायरेक्टरी के अंदर होती है। प्रैक्टिस अभ्यास की डायरेक्टरी का नाम उस अभ्यास की slug प्रॉपर्टी से मेल खाना चाहिए, जो config.json फ़ाइल में परिभाषित होती है।

प्रैक्टिस अभ्यास में चार तरह की फ़ाइलें होती हैं:

दस्तावेज़ फ़ाइलें

ये फ़ाइलें छात्र को दिखाई जाती हैं, ताकि अभ्यास को समझाने में मदद मिले।

.docs/introduction.md: अभ्यास की पृष्ठभूमि और परिवेश बताती है (वैकल्पिक)
.docs/introduction.append.md: मौजूदा परिचय के बाद जोड़ने के लिए अतिरिक्त परिचय (वैकल्पिक)
.docs/instructions.md: अभ्यास के निर्देश देती है (आवश्यक)
.docs/instructions.append.md: मौजूदा निर्देशों के बाद जोड़ने के लिए अतिरिक्त परिचय (वैकल्पिक)
.docs/hints.md: छात्र को अभ्यास में अटकने पर आगे बढ़ने में मदद करने के लिए संकेत देती है (वैकल्पिक)

मेटाडेटा फ़ाइलें

ये फ़ाइलें छात्र को नहीं दिखाई जाती हैं, बल्कि अभ्यास का मेटाडेटा परिभाषित करने के लिए इस्तेमाल होती हैं।

.meta/config.json: अभ्यास की मेटा जानकारी रखती है (आवश्यक)
.meta/design.md: अभ्यास का डिज़ाइन बताती है (वैकल्पिक)
.meta/tests.toml: जानकारी रखती है कि कौन-कौन से टेस्ट लागू किए गए हैं (वैकल्पिक)

अप्रोच फ़ाइलें

ये फ़ाइलें अभ्यास के अप्रोच बताती हैं।

.approaches/introduction.md: अभ्यास के सबसे आम अप्रोच का परिचय (वैकल्पिक)
.approaches/config.json: अप्रोच का मेटाडेटा (वैकल्पिक)
.approaches/<approach-slug>/content.md: अप्रोच का विवरण (वैकल्पिक)
.approaches/<approach-slug>/snippet.txt: अप्रोच दिखाने वाला स्निपेट (वैकल्पिक)

आर्टिकल फ़ाइलें

ये फ़ाइलें अभ्यास के आर्टिकल बताती हैं।

.articles/config.json: आर्टिकल का मेटाडेटा (वैकल्पिक)
.articles/<article-slug>/content.md: आर्टिकल का विवरण (वैकल्पिक)
.articles/<article-slug>/snippet.md: आर्टिकल दिखाने वाला स्निपेट (वैकल्पिक)

अभ्यास फ़ाइलें

भाषा के हिसाब से अलग फ़ाइलें, जैसे इम्प्लीमेंटेशन और टेस्ट फ़ाइलें। इन फ़ाइलों के नाम ट्रैक के हिसाब से अलग होते हैं।

टेस्ट सूट: हल के सही होने की जाँच करता है।
स्टब इम्प्लीमेंटेशन: छात्रों को शुरुआत करने की जगह देता है।
उदाहरण इम्प्लीमेंटेशन: एक ऐसा उदाहरण इम्प्लीमेंटेशन देता है जो सारे टेस्ट पास करता है।
अतिरिक्त फ़ाइलें: यह सुनिश्चित करती हैं कि टेस्ट चल सकें।

उदाहरण

exercises
└── practice
    └── isogram
        ├── .approaches
        |   ├── for-loop
        |   |   ├── content.md
        |   |   └── snippet.txt
        |   ├── config.json
        |   └── introduction.md
        ├── .articles
        |   ├── performance
        |   |   ├── content.md
        |   |   └── snippet.md
        |   └── config.json
        ├── .docs
        |   ├── introduction.md
        |   ├── instructions.md
        |   └── hints.md
        ├── .meta
        |   ├── config.json
        |   ├── design.md
        |   ├── tests.toml
        |   └── Example.cs (example implementation)
        ├── Isogram.cs (stub implementation)
        └── IsogramTests.cs (tests)

फ़ाइल: `.docs/introduction.md`

उद्देश्य: छात्र को अभ्यास की पृष्ठभूमि और परिवेश से परिचित कराना।

उपस्थिति: अगर अभ्यास एक ऐसा Problem Specifications अभ्यास लागू करता हो जिसमें introduction.md फ़ाइल है, तो आवश्यक

अगर अभ्यास किसी Problem Specifications अभ्यास को लागू करता है, तो इस फ़ाइल की सामग्री उस Problem Specification अभ्यास की introduction.md फ़ाइल से मेल खानी चाहिए। configlet में यह सुविधा है कि वह इस फ़ाइल की सामग्री अपने आप सिंक कर सके।

अगर अभ्यास किसी Problem Specifications अभ्यास पर आधारित नहीं है, तो इन बातों का ध्यान रखिए:

Exercism की सामग्री को सबके लिए सुरक्षित बनाना हमारे लिए बहुत ज़रूरी है, इसलिए कहानियाँ उचित हैं या नहीं, यह तय करते समय हम अक्सर सतर्कता की तरफ झुकते हैं। हम यह ध्यान रखते हैं कि क्या मर्ज कर रहे हैं, पर हम मानते हैं कि यह समझना मुश्किल है कि किसी को क्या समस्याजनक लग सकता है। इसलिए हम हमेशा मान लेंगे कि आप नेक इरादे से काम कर रहे हैं, और समीक्षा में किसी भी दिक्कत को बिना टकराव के पकड़ने की पूरी कोशिश करेंगे। अगर आप कोई कहानी हमसे जाँचना चाहें, तो @exercism/leadership को मेंशन कीजिए और हम साथ में देखेंगे। यहाँ कुछ मार्गदर्शक बातें हैं:

यह सुनिश्चित करने की कोशिश कीजिए कि कहानी स्वागत करने वाली हो और सबकी समझ में आए। अगर कहानी में कोई अंदरूनी मज़ाक या स्थानीय बोली के शब्द हों, तो दूसरे शब्द सोचने की कोशिश कीजिए।
ऐसे उदाहरण लिखने की कोशिश कीजिए जो सबको शामिल करें। जैसे, अलग-अलग संस्कृतियों के नाम और अलग-अलग लिंगों का ध्यान रखिए।
खुद से पूछिए कि क्या आप किसी ऐसे व्यक्ति को निजी तौर पर जानते हैं जिसे इस कहानी से ठेस पहुँचेगी। अगर हाँ, तो उसे बदलने के बारे में सोचिए।

उदाहरण

# Introduction

Bob is a lackadaisical teenager. In conversation, his responses are very limited.

फ़ाइल: `.docs/introduction.append.md`

उद्देश्य: मौजूदा परिचय के बाद जोड़ने के लिए अतिरिक्त परिचय।

उपस्थिति: वैकल्पिक

कुछ (दुर्लभ) मामलों में आप अभ्यास की introduction.md फ़ाइल को बढ़ाना चाह सकते हैं, जैसे जब अभ्यास में ऐसे टेस्ट लागू किए गए हों जो मौजूदा निर्देशों में शामिल नहीं हैं।

अगर किसी ट्रैक में Bob को गैर-ASCII संदेशों का सपोर्ट नहीं चाहिए, तो वह यह जोड़ सकता है:

# Introduction append

## Note

As part of his teenage rebellion, Bob has decided to only communicate using ASCII.

Append फ़ाइलें H1 हेडर से शुरू होनी चाहिए। यह हेडर दिखाया नहीं जाता, पर मौजूद रहना चाहिए। H1 हेडर के बाद अक्सर H2 हेडर होता है, जो सामान्य सामग्री को ट्रैक-विशेष सामग्री से अलग करने में मदद करता है।

फ़ाइल: `.docs/instructions.md`

उद्देश्य: अभ्यास के लिए निर्देश देना।

उपस्थिति: आवश्यक

अगर अभ्यास किसी Problem Specifications अभ्यास को लागू करता है, तो इस फ़ाइल की सामग्री उस Problem Specification अभ्यास की instructions.md फ़ाइल (या instructions.md फ़ाइल न हो तो description.md फ़ाइल) से मेल खानी चाहिए। configlet में यह सुविधा है कि वह इस फ़ाइल की सामग्री अपने आप सिंक कर सके।

अगर अभ्यास किसी Problem Specifications अभ्यास पर आधारित नहीं है, तो इन बातों का ध्यान रखिए:

यह सुनिश्चित करने की कोशिश कीजिए कि कहानी स्वागत करने वाली हो और सबकी समझ में आए। अगर कहानी में कोई अंदरूनी मज़ाक या स्थानीय बोली के शब्द हों, तो दूसरे शब्द सोचने की कोशिश कीजिए।
ऐसे उदाहरण लिखने की कोशिश कीजिए जो सबको शामिल करें। जैसे, अलग-अलग संस्कृतियों के नाम और अलग-अलग लिंगों का ध्यान रखिए।
खुद से पूछिए कि क्या आप किसी ऐसे व्यक्ति को निजी तौर पर जानते हैं जिसे इस कहानी से ठेस पहुँचेगी। अगर हाँ, तो उसे बदलने के बारे में सोचिए।

उदाहरण

# Instructions

Bob answers 'Sure.' if you ask him a question, such as "How are you?".

He answers 'Whoa, chill out!' if you YELL AT HIM (in all capitals).

He answers 'Calm down, I know what I'm doing!' if you yell a question at him.

He says 'Fine. Be that way!' if you address him without actually saying anything.

He answers 'Whatever.' to anything else.

फ़ाइल: `.docs/instructions.append.md`

उद्देश्य: मौजूदा निर्देशों के बाद जोड़ने के लिए अतिरिक्त निर्देश।

उपस्थिति: वैकल्पिक

कुछ (दुर्लभ) मामलों में आप अभ्यास की instructions.md फ़ाइल को बढ़ाना चाह सकते हैं, जैसे जब अभ्यास में ऐसे टेस्ट लागू किए गए हों जो मौजूदा निर्देशों में शामिल नहीं हैं।

# Instructions append

## Note

Bob's conversational partner is a purist when it comes to written communication and always follows normal rules regarding sentence punctuation in English.

फ़ाइल: `.docs/hints.md`

उद्देश्य: छात्र को अभ्यास में अटकने पर आगे बढ़ने में मदद करने के लिए संकेत देना।

उपस्थिति: वैकल्पिक

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

संकेत देखना कोई "सिफारिश किया गया" रास्ता नहीं होगा, और जब तक छात्र उसके बिना आगे न बढ़ सके, हम (हल्के-फुल्के तरीके से) उसे इस्तेमाल करने से रोकेंगे। इसलिए यह ध्यान रखने लायक है कि संकेत पढ़ने वाला छात्र थोड़ा उलझा हुआ, बोझिल और शायद निराश महसूस करेगा।

उदाहरण

## General

- There are many [built-in methods][integers] to simplify working with integers.

[integers]: https://ruby-doc.org/core-2.7.0/Integer.html

फ़ाइल: .meta/design.md

उद्देश्य: अभ्यास का डिज़ाइन बताना।

उपस्थिति: वैकल्पिक

इस फ़ाइल में अभ्यास के डिज़ाइन की जानकारी होती है, जिसमें उसका लक्ष्य, सिखाने के लक्ष्य, क्या न सिखाना है, और बहुत कुछ शामिल है।

यह इसलिए मौजूद है ताकि भविष्य के मेंटेनरों या कंट्रिब्यूटरों को अभ्यास के दायरे और सीमाओं की जानकारी मिले, और समय के साथ अभ्यासों को ज़्यादा जटिल बनाने की स्वाभाविक प्रवृत्ति से बचा जा सके।

उदाहरण

# Design

## Goal

The goal of this exercise is help students practice how to work with strings.

## Notes

This exercise does not contain any error handling tests.

फ़ाइल: `.meta/config.json`

उद्देश्य: अभ्यास की मेटा जानकारी रखना।

उपस्थिति: आवश्यक

इस फ़ाइल में अभ्यास की मेटा जानकारी होती है:

authors: अभ्यास के लेखक(ों) के GitHub यूज़रनेम (वैकल्पिक)
- अगर समीक्षकों की समीक्षा से अभ्यास में काफी बदलाव आए (इतना कि लगे "यह साथ में मिलकर किया गया"), तो समीक्षकों को भी शामिल कीजिए
contributors: अभ्यास के कंट्रिब्यूटर(ों) के GitHub यूज़रनेम (वैकल्पिक)
- अगर समीक्षकों की समीक्षा काम की हो, उस पर पालन हो सके या पालन किया गया हो, तो समीक्षकों को भी शामिल कीजिए।
files: इस अभ्यास में इस्तेमाल होने वाली फ़ाइलों की जगहें, अभ्यास की डायरेक्टरी के सापेक्ष (आवश्यक)
- solution: स्टब इम्प्लीमेंटेशन फ़ाइल(ें) (आवश्यक)
- test: टेस्ट फ़ाइल(ें) (आवश्यक)
- example: उदाहरण इम्प्लीमेंटेशन फ़ाइल(ें) (आवश्यक)
- editor: एडिटर में सिर्फ़ पढ़ने के लिए दिखाई जाने वाली अतिरिक्त फ़ाइलें (वैकल्पिक)
- invalidator: ऐसी फ़ाइलें जो बदलने पर किसी हल को पुराना बना देती हैं (वैकल्पिक)
language_versions भाषा के वर्शन की ज़रूरतें (वैकल्पिक)
blurb: इस अभ्यास का छोटा विवरण। इसकी लंबाई <= 350 होनी चाहिए। Markdown का सपोर्ट नहीं है (आवश्यक)
source: वह स्रोत जिस पर यह अभ्यास आधारित है (वैकल्पिक)
source_url: उस स्रोत का URL जिस पर यह अभ्यास आधारित है (वैकल्पिक)
test_runner: बताता है कि इस अभ्यास के हल टेस्ट रनर में टेस्ट होने चाहिए या नहीं। अगर न बताया जाए तो डिफ़ॉल्ट true होता है। (वैकल्पिक)
representer: इस बारे में मेटा जानकारी कि रिप्रज़ेंटर इस फ़ाइल को कैसे प्रोसेस करता है (वैकल्पिक)
- version: अभ्यास के लिए इस्तेमाल होने वाले रिप्रज़ेंटर के वर्शन का पूर्णांक (अगर पैरेंट की मौजूद हो तो आवश्यक)
icon: आइकॉन का स्लग (आइकॉन की पूरी सूची देखिए)। अगर न बताया जाए, तो अभ्यास का स्लग इस्तेमाल होगा (वैकल्पिक)
custom: अभ्यास-विशेष कोई भी गैर-मानक डेटा। इसका इस्तेमाल हर अभ्यास के लिए ट्रैक की टूलिंग का व्यवहार बदलने के लिए किया जा सकता है (वैकल्पिक)

अगर कोई व्यक्ति लेखक और कंट्रिब्यूटर दोनों है, तो उसे सिर्फ़ लेखक के रूप में ही लिखिए।

उदाहरण

{
  "authors": ["FSharpForever"],
  "files": {
    "solution": ["Bob.fs"],
    "test": ["BobTests.fs"],
    "example": [".meta/Example.fs"]
  },
  "blurb": "Bob is a lackadaisical teenager. In conversation, his responses are very limited"
}

ध्यान दीजिए:

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

फ़ाइल: .meta/tests.toml

उद्देश्य: इस बारे में जानकारी रखना कि कौन-कौन से टेस्ट लागू किए गए हैं।

उपस्थिति: वैकल्पिक

इस फ़ाइल में इस बारे में जानकारी होती है कि कौन-कौन से टेस्ट लागू किए जा रहे हैं, बशर्ते अभ्यास के problem-specifications रेपो की अपनी canonical-data.json फ़ाइल में कुछ टेस्ट परिभाषित हों।

यह इसलिए मौजूद है ताकि मेंटेनर यह ध्यान रख सकें कि कौन-कौन से टेस्ट लागू किए गए हैं, और (वैकल्पिक रूप से) यह दर्ज कर सकें कि कोई टेस्ट क्यों लागू नहीं किया गया। इसका इस्तेमाल यह पता लगाने के लिए भी किया जा सकता है कि कौन-कौन से टेस्ट लागू नहीं किए गए हैं।

configlet टूल configlet sync कमांड के ज़रिए इस फ़ाइल को problem-specifications रेपो के डेटा के साथ अपडेट और सिंक करने का काम करता है। सिंक करते समय configlet हर उस टेस्ट के लिए, जो लागू नहीं किया गया है, पूछेगा कि उसे शामिल करना है या नहीं।

उदाहरण

# This is an auto-generated file.
#
# Regenerating this file via `configlet sync` will:
# - Recreate every `description` key/value pair
# - Recreate every `reimplements` key/value pair, where they exist in problem-specifications
# - Remove any `include = true` key/value pair (an omitted `include` key implies inclusion)
# - Preserve any other key/value pair
#
# As user-added comments (using the # character) will be removed when this file
# is regenerated, comments can be added via a `comment` key.

[3e5c30a8-87e2-4845-a815-a49671ade970]
description = "empty strand"

[a0ea42a6-06d9-4ac6-828c-7ccaccf98fec]
description = "can count one nucleotide in single-character input"

[eca0d565-ed8c-43e7-9033-6cefbf5115b5]
description = "strand with repeated nucleotide"

[40a45eac-c83f-4740-901a-20b22d15a39f]
description = "strand with multiple nucleotides"

[b4c47851-ee9e-4b0a-be70-a86e343bd851]
description = "strand with invalid nucleotides"
include = false
comment = "error handling omitted on purpose"

फ़ाइल: `.approaches/introduction.md`

उद्देश्य: अभ्यास के सबसे आम अप्रोच का परिचय

उपस्थिति: वैकल्पिक

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

उदाहरण

# Introduction

The key to this exercise is to deal with C# strings being immutable, which means that a `string`'s value cannot be changed.
Therefore, to reverse a string you'll need to create a _new_ `string`.

## Using LINQ

```csharp
public static string Reverse(string input)
{
    return new string(input.Reverse().ToArray());
}
```

For more information, check the [LINQ approach][approach-linq].

## Which approach to use?

If readability is your primary concern (and it usually should be), the LINQ-based approach is hard to beat.

फ़ाइल: `.approaches/config.json`

उद्देश्य: अप्रोच का मेटाडेटा

उपस्थिति: वैकल्पिक (जब कोई अप्रोच परिचय या अप्रोच मौजूद हो तो आवश्यक)

इस फ़ाइल में अभ्यास के अप्रोच की मेटा जानकारी होती है:

introduction: अभ्यास के अप्रोच परिचय के लेखक(ों) के GitHub यूज़रनेम (वैकल्पिक)
- authors: अभ्यास के अप्रोच परिचय के लेखक(ों) के GitHub यूज़रनेम (आवश्यक)
  - अगर समीक्षकों की समीक्षा से अभ्यास का अप्रोच परिचय काफी बदल जाए (इतना कि लगे "यह साथ में मिलकर किया गया"), तो समीक्षकों को भी शामिल कीजिए
- contributors: अभ्यास के अप्रोच परिचय के कंट्रिब्यूटर(ों) के GitHub यूज़रनेम (वैकल्पिक)
  - अगर समीक्षकों की समीक्षा काम की हो, उस पर पालन हो सके या पालन किया गया हो, तो समीक्षकों को भी शामिल कीजिए।
approaches: विस्तृत अप्रोच की सूची रखने वाला ऐरे (वैकल्पिक)
- uuid: एक V4 UUID जो अप्रोच को विशिष्ट रूप से पहचानता है। यह UUID ट्रैक के अंदर भी और सारे ट्रैकों में भी अद्वितीय होना चाहिए, और कभी नहीं बदलना चाहिए
- slug: अप्रोच का स्लग, जो छोटे अक्षरों में लिखी kebab-case स्ट्रिंग होती है। यह स्लग ट्रैक के अंदर सारे अप्रोच स्लगों में अद्वितीय होना चाहिए। इसकी लंबाई <= 255 होनी चाहिए।
- title: अप्रोच का शीर्षक। इसकी लंबाई <= 255 होनी चाहिए।
- blurb: इस अप्रोच का छोटा विवरण। इसकी लंबाई <= 350 होनी चाहिए। Markdown का सपोर्ट नहीं है (आवश्यक)
- authors: अभ्यास के अप्रोच के लेखक(ों) के GitHub यूज़रनेम (आवश्यक)
  - अगर समीक्षकों की समीक्षा से अभ्यास का अप्रोच काफी बदल जाए (इतना कि लगे "यह साथ में मिलकर किया गया"), तो समीक्षकों को भी शामिल कीजिए
- contributors: अभ्यास के अप्रोच के कंट्रिब्यूटर(ों) के GitHub यूज़रनेम (वैकल्पिक)
  - अगर समीक्षकों की समीक्षा काम की हो, उस पर पालन हो सके या पालन किया गया हो, तो समीक्षकों को भी शामिल कीजिए।
- tags: यह बताइए कि किन शर्तों पर कोई सबमिशन किसी अप्रोच से जुड़ता है। (वैकल्पिक)
  - all: ऐसे टैगों का ऐरे जो सब के सब सबमिशन पर मौजूद होने चाहिए (वैकल्पिक, जब तक any में कोई एलिमेंट न हो)
  - any: ऐसे टैगों का ऐरे जिनमें से कम से कम एक सबमिशन पर मौजूद होना चाहिए (वैकल्पिक, जब तक all में कोई एलिमेंट न हो)
  - not: इनमें से कोई भी टैग सबमिशन पर मौजूद नहीं होना चाहिए (वैकल्पिक)

उदाहरण

{
  "introduction": {
    "authors": ["erikschierboom"]
  },
  "approaches": [
    {
      "uuid": "448fb2b4-18ab-4e55-aa54-ad4ed6d5f7f6",
      "slug": "span",
      "title": "Use Span<T>",
      "blurb": "Use Span<T> to efficiently reverse a string.",
      "authors": ["erikschierboom"]
    }
  ]
}

फ़ाइल: `.approaches/<approach-slug>/content.md`

उद्देश्य: अप्रोच का विस्तृत विवरण

उपस्थिति: वैकल्पिक (अप्रोच के लिए आवश्यक)

इस फ़ाइल में अप्रोच का विस्तृत विवरण होता है। इस फ़ाइल में क्या होना चाहिए, इसकी ज़्यादा जानकारी के लिए दस्तावेज़ देखिए।

उदाहरण

# Span

```csharp
Span<char> chars = stackalloc char[input.Length];
for (var i = 0; i < input.Length; i++)
{
    chars[input.Length - 1 - i] = input[i];
}
return new string(chars);
```

This `Span<T>` approach uses a `for` loop.

फ़ाइल: `.approaches/<approach-slug>/snippet.txt`

उद्देश्य: अप्रोच दिखाने वाला स्निपेट

उपस्थिति: वैकल्पिक (अप्रोच के लिए आवश्यक)

इस फ़ाइल में एक छोटा स्निपेट होता है जो अप्रोच दिखाता है। यह स्निपेट अभ्यास के Dig Deeper पेज पर दिखाया जाता है।

इसकी लाइनों की संख्या <= 8 होनी चाहिए।

इस फ़ाइल में क्या होना चाहिए, इसकी ज़्यादा जानकारी के लिए दस्तावेज़ देखिए।

उदाहरण

Span<char> chars = stackalloc char[input.Length];
for (var i = 0; i < input.Length; i++)
{
    chars[input.Length - 1 - i] = input[i];
}
return new string(chars);

फ़ाइल: `.article/config.json`

उद्देश्य: आर्टिकल का मेटाडेटा

उपस्थिति: वैकल्पिक (जब कोई आर्टिकल मौजूद हो तो आवश्यक)

इस फ़ाइल में अभ्यास के आर्टिकल की मेटा जानकारी होती है:

articles: विस्तृत आर्टिकल की सूची रखने वाला ऐरे (वैकल्पिक)
- uuid: एक V4 UUID जो आर्टिकल को विशिष्ट रूप से पहचानता है। यह UUID ट्रैक के अंदर भी और सारे ट्रैकों में भी अद्वितीय होना चाहिए, और कभी नहीं बदलना चाहिए
- slug: आर्टिकल का स्लग, जो छोटे अक्षरों में लिखी kebab-case स्ट्रिंग होती है। यह स्लग ट्रैक के अंदर सारे आर्टिकल स्लगों में अद्वितीय होना चाहिए। इसकी लंबाई <= 255 होनी चाहिए।
- title: आर्टिकल का शीर्षक। इसकी लंबाई <= 255 होनी चाहिए।
- blurb: इस आर्टिकल का छोटा विवरण। इसकी लंबाई <= 350 होनी चाहिए। Markdown का सपोर्ट नहीं है (आवश्यक)
- authors: अभ्यास के आर्टिकल के लेखक(ों) के GitHub यूज़रनेम (आवश्यक)
  - अगर समीक्षकों की समीक्षा से अभ्यास का आर्टिकल काफी बदल जाए (इतना कि लगे "यह साथ में मिलकर किया गया"), तो समीक्षकों को भी शामिल कीजिए
- contributors: अभ्यास के आर्टिकल के कंट्रिब्यूटर(ों) के GitHub यूज़रनेम (वैकल्पिक)
  - अगर समीक्षकों की समीक्षा काम की हो, उस पर पालन हो सके या पालन किया गया हो, तो समीक्षकों को भी शामिल कीजिए।

उदाहरण

{
  "articles": [
    {
      "uuid": "6db71962-62d5-448b-a980-c20ae41013ed",
      "slug": "performance",
      "title": "Optimizing performance",
      "blurb": "Explore how to most efficiently reverse a string and what the trade-offs are.",
      "authors": ["erikschierboom"]
    }
  ]
}

फ़ाइल: `.articles/<article-slug>/content.md`

उद्देश्य: अप्रोच का विस्तृत विवरण

उपस्थिति: वैकल्पिक (अप्रोच के लिए आवश्यक)

उदाहरण

# Performance

In this document, we'll find out which approach is the most performant one.

## Benchmark results

| Method |      Mean |     Error |    StdDev |    Median | Allocated |
| -----: | --------: | --------: | --------: | --------: | --------: |
|   Linq | 29.133 ns | 0.5865 ns | 0.5486 ns | 28.984 ns |      80 B |
|  Array |  4.806 ns | 0.4999 ns | 1.4739 ns |  3.967 ns |         - |

फ़ाइल: `.articles/<article-slug>/snippet.txt`

उद्देश्य: अप्रोच दिखाने वाला स्निपेट

उपस्थिति: वैकल्पिक (आर्टिकल के लिए आवश्यक)

इस फ़ाइल में एक छोटा स्निपेट होता है जो आर्टिकल दिखाता है। यह स्निपेट अभ्यास के Dig Deeper पेज पर दिखाया जाता है।

इसकी लाइनों की संख्या <= 8 होनी चाहिए।

इस फ़ाइल में क्या होना चाहिए, इसकी ज़्यादा जानकारी के लिए दस्तावेज़ देखिए।

उदाहरण

| Method |      Mean | Allocated |
| -----: | --------: | --------: |
|   Linq | 29.133 ns |      80 B |
|  Array |  4.806 ns |         - |

फ़ाइल: स्टब इम्प्लीमेंटेशन

उद्देश्य: छात्रों को शुरुआत करने की जगह देना।

उपस्थिति: आवश्यक

स्टब ऐसा बनाइए कि छात्र को पता चले कि कोड कहाँ जोड़ना है।
कंपाइल होने वाली भाषाओं के लिए ऐसा कोड रखने पर विचार कीजिए जो कंपाइल हो सके, क्योंकि भाषा के लिए नए छात्रों के लिए कंपाइलर के संदेश कभी-कभी समझना मुश्किल होता है।
कोड जितना आसान हो सके उतना आसान होना चाहिए।
सिर्फ़ वही भाषा फीचर इस्तेमाल कीजिए जो पूर्वापेक्षाओं (और उनकी पूर्वापेक्षाओं, आदि) में सिखाए गए हों।
जब छात्र ब्राउज़र में कोडिंग करता है तो स्टब फ़ाइल उसे दिखाई जाती है, और CLI इस्तेमाल करने पर यह उसके फ़ाइल सिस्टम में डाउनलोड हो जाती है।
स्टब इम्प्लीमेंटेशन फ़ाइल(ों) के सापेक्ष पाथ .meta/config.json फ़ाइल की "files.solution" की में बताए जाने चाहिए।

उदाहरण

using System;

public static class Isogram
{
    public static bool IsIsogram(string word)
    {
        throw new NotImplementedException("You need to implement this function.");
    }
}

फ़ाइल: टेस्ट

उद्देश्य: हल के सही होने की जाँच करना।

उपस्थिति: आवश्यक

कोड जितना आसान हो सके उतना आसान होना चाहिए।
सिर्फ़ वही भाषा फीचर इस्तेमाल कीजिए जो अभ्यास की पूर्वापेक्षाओं (और उनकी पूर्वापेक्षाओं, आदि) में सिखाए गए हों।
जब छात्र ब्राउज़र में कोडिंग करता है तो टेस्ट फ़ाइल उसे दिखाई जाती है, और CLI इस्तेमाल करने पर यह उसके फ़ाइल सिस्टम में डाउनलोड हो जाती है।
Exercism पसंद करता है कि प्रैक्टिस अभ्यास Test Driven Development के ज़रिए पूरे हों। इसके लिए दो विकल्प हैं:
- टेस्ट रनर को टेस्ट उसी क्रम में चलाने होंगे जिस क्रम में वे फ़ाइल में परिभाषित हैं, और टेस्ट सूट को पहली असफलता पर रुक जाना चाहिए; या
- पहले टेस्ट के अलावा बाकी सब टेस्ट डिफ़ॉल्ट रूप से स्किप होने चाहिए।
टेस्ट फ़ाइल(ों) के सापेक्ष पाथ .meta/config.json फ़ाइल की "files.test" की में बताए जाने चाहिए।

उदाहरण

using Xunit;

public class IsogramTest
{
    [Fact]
    public void Empty_string() =>
        Assert.True(Isogram.IsIsogram(""));

    [Fact(Skip = "Remove this Skip property to run this test")]
    public void Isogram_with_only_lower_case_characters() =>
        Assert.True(Isogram.IsIsogram("isogram"));

    [Fact(Skip = "Remove this Skip property to run this test")]
    public void Word_with_one_duplicated_character() =>
        Assert.False(Isogram.IsIsogram("eleven"));
}

फ़ाइल: उदाहरण इम्प्लीमेंटेशन

उद्देश्य: एक ऐसा उदाहरण इम्प्लीमेंटेशन देना जो सारे टेस्ट पास करता हो।

उपस्थिति: आवश्यक

यह इम्प्लीमेंटेशन यह जाँचने के लिए इस्तेमाल होता है कि कोई ऐसा इम्प्लीमेंटेशन मौजूद है जो टेस्ट पास करता है। यह जान-बूझकर वह कोड नहीं है जिसे हम चाहते हैं कि छात्र निशाना बनाए।
हर ट्रैक को अपने Continuous Integration सेटअप में यह जाँचना चाहिए कि उदाहरण इम्प्लीमेंटेशन टेस्ट पास करता है।
मेंटरों को यह कोड नहीं दिखाया जाएगा।
जब छात्र ब्राउज़र में कोडिंग करता है तो उदाहरण फ़ाइल उसे नहीं दिखाई जाती, और CLI इस्तेमाल करने पर यह उसके फ़ाइल सिस्टम में नहीं डाउनलोड होती।
उदाहरण इम्प्लीमेंटेशन फ़ाइल(ों) के सापेक्ष पाथ .meta/config.json फ़ाइल की "files.example" की में बताए जाने चाहिए।

उदाहरण

using System.Linq;

public static class Isogram
{
    public static bool IsIsogram(string word)
    {
        var lowerCaseLetters = word.ToLower().Where(char.IsLetter).ToList();
        return lowerCaseLetters.Distinct().Count() == lowerCaseLetters.Count;
    }
}

फ़ाइल: अतिरिक्त फ़ाइलें

उद्देश्य: ऐसी अतिरिक्त प्रोजेक्ट, बिल्ड या सहायक फ़ाइलें जो टेस्ट चलने के लिए ज़रूरी हों।

उपस्थिति: अगर डिफ़ॉल्ट फ़ाइलें टेस्ट चलाने के लिए काफी न हों तो आवश्यक

कुछ भाषाओं में टेस्ट चलाने के लिए अतिरिक्त फ़ाइलें ज़रूरी होती हैं। जैसे C# की प्रोजेक्ट फ़ाइलें और Node की package.json फ़ाइलें, जिनके बिना टेस्ट चलाना संभव नहीं होगा।

साझा फ़ाइलें

कुछ फ़ाइलें किसी एक अभ्यास तक सीमित नहीं होतीं, बल्कि सारे अभ्यासों पर लागू होती हैं। ज़्यादा जानकारी के लिए दस्तावेज़ देखिए।

प्रस्तुति

जब छात्र ब्राउज़र एडिटर इस्तेमाल करता है और जब CLI इस्तेमाल करता है, तो अभ्यास के दस्तावेज़ उसे अलग-अलग तरीकों से दिखाए जाते हैं। ज़्यादा जानकारी के लिए यह दस्तावेज़ देखिए।

आइकॉन

हर अभ्यास के साथ एक आइकॉन होता है। डिफ़ॉल्ट रूप से वही आइकॉन दिखाया जाता है जिसका नाम अभ्यास के स्लग से मेल खाता है। अभ्यास की .meta/config.json फ़ाइल में icon प्रॉपर्टी देकर इसे बदला जा सकता है।

अगर आप problem-specifications मेटाडेटा से कोई अभ्यास लागू कर रहे हैं, तो उस अभ्यास के लिए शायद पहले से एक आइकॉन मौजूद है। अगर नहीं, तो कृपया website-icons रेपो में इश्यू खोलिए।

भाषा ट्रैक

Jiki के साथ कोड करना सीखिए

आपकी यात्रा

आपके पसंदीदानया

Exercism के खास फायदे

कम्युनिटी वीडियो

संक्षिप्त परिचय शृंखला

इंटरव्यू और कहानियाँ

Discord

फोरम

शुरुआत करें

मेंटर बनें

डॉक्स

योगदानकर्ता

अनुवादकनया

दान करें

Exercism के बारे में

हमारा प्रभाव

GitHub सिंकरनया

इनसाइडर्स

प्रैक्टिस अभ्यास

मेटाडेटा

उदाहरण

practices

prerequisites

फ़ाइलें

दस्तावेज़ फ़ाइलें

मेटाडेटा फ़ाइलें

अप्रोच फ़ाइलें

आर्टिकल फ़ाइलें

अभ्यास फ़ाइलें

उदाहरण

फ़ाइल: .docs/introduction.md

उदाहरण

फ़ाइल: .docs/introduction.append.md

फ़ाइल: .docs/instructions.md

उदाहरण

फ़ाइल: .docs/instructions.append.md

फ़ाइल: .docs/hints.md

उदाहरण

फ़ाइल: .meta/design.md

उदाहरण

फ़ाइल: .meta/config.json

उदाहरण

फ़ाइल: .meta/tests.toml

उदाहरण

फ़ाइल: .approaches/introduction.md

उदाहरण

फ़ाइल: .approaches/config.json

उदाहरण

फ़ाइल: .approaches/<approach-slug>/content.md

उदाहरण

फ़ाइल: .approaches/<approach-slug>/snippet.txt

उदाहरण

फ़ाइल: .article/config.json

उदाहरण

फ़ाइल: .articles/<article-slug>/content.md

उदाहरण

फ़ाइल: .articles/<article-slug>/snippet.txt

उदाहरण

फ़ाइल: स्टब इम्प्लीमेंटेशन

उदाहरण

फ़ाइल: टेस्ट

उदाहरण

फ़ाइल: उदाहरण इम्प्लीमेंटेशन

उदाहरण

फ़ाइल: अतिरिक्त फ़ाइलें

साझा फ़ाइलें

प्रस्तुति

आइकॉन

`practices`

`prerequisites`

फ़ाइल: `.docs/introduction.md`

फ़ाइल: `.docs/introduction.append.md`

फ़ाइल: `.docs/instructions.md`

फ़ाइल: `.docs/instructions.append.md`

फ़ाइल: `.docs/hints.md`

फ़ाइल: `.meta/config.json`

फ़ाइल: `.approaches/introduction.md`

फ़ाइल: `.approaches/config.json`

फ़ाइल: `.approaches/<approach-slug>/content.md`

फ़ाइल: `.approaches/<approach-slug>/snippet.txt`

फ़ाइल: `.article/config.json`

फ़ाइल: `.articles/<article-slug>/content.md`

फ़ाइल: `.articles/<article-slug>/snippet.txt`