Jen Looper
4 years ago
parent
5aed76219d
commit
5e694c53c4
@ -0,0 +1,315 @@
|
||||
# गिटहब का परिचय
|
||||
|
||||
इस पाठ में GitHub की मूल बातें शामिल हैं, जो आपके कोड में परिवर्तनों को होस्ट और प्रबंधित करने के लिए एक मंच है।
|
||||
|
||||
|
||||
> [टोमोमी इमुरा](https://twitter.com/girlie_mac) द्वारा स्केचनेट
|
||||
|
||||
## पूर्व व्याख्यान प्रश्नोत्तरी
|
||||
[पूर्व व्याख्यान प्रश्नोत्तरी](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/3?loc=hi)
|
||||
|
||||
## परिचय
|
||||
|
||||
इस पाठ में, हम कवर करेंगे:
|
||||
|
||||
- आपके द्वारा मशीन पर किए गए कार्य को ट्रैक करना
|
||||
- दूसरों के साथ परियोजनाओं पर काम करना
|
||||
- खुला स्त्रोत सॉफ़्टवेयर खोलने में योगदान कैसे करें
|
||||
|
||||
### आवश्यक शर्तें
|
||||
|
||||
शुरू करने से पहले, आपको जांचना होगा कि क्या Git स्थापित है। टर्मिनल में लिखे:
|
||||
`git --version`
|
||||
|
||||
यदि गिट स्थापित नहीं है तो , [गिट डाउनलोड करे](https://git-scm.com/downloads). फिर, टर्मिनल में अपनी स्थानीय Git प्रोफ़ाइल सेट करें:
|
||||
* `git config --global user.name "your-name"`
|
||||
* `git config --global user.email "your-email"`
|
||||
|
||||
यह जाँचने के लिए कि क्या Git पहले से कॉन्फ़िगर है आप टाइप कर सकते हैं:
|
||||
`git config --list`
|
||||
|
||||
आपको एक GitHub खाते, एक कोड एडिटर (जैसे Visual Studio कोड) की आवश्यकता होगी, और आपको अपना टर्मिनल (या: कमांड प्रॉम्प्ट) खोलने की आवश्यकता होगी।
|
||||
|
||||
[Github.com](https://github.com/) पर नेविगेट करें और यदि आप पहले से नहीं हैं, तो एक खाता बनाएं या लॉग इन करें और अपना प्रोफ़ाइल भरें।
|
||||
|
||||
✅ GitHub दुनिया में एकमात्र कोड भंडार नहीं है; अन्य हैं, लेकिन GitHub सबसे अच्छा ज्ञात है
|
||||
|
||||
### तैयारी
|
||||
|
||||
आपको अपने स्थानीय मशीन (लैपटॉप या पीसी) पर एक कोड परियोजना के साथ एक फ़ोल्डर की आवश्यकता होगी, और GitHub पर एक सार्वजनिक भंडार, जो दूसरों की परियोजनाओं में योगदान करने के लिए एक उदाहरण के रूप में काम करेगा।
|
||||
|
||||
---
|
||||
|
||||
## कोड प्रबंधन
|
||||
|
||||
मान लें कि आपके पास कुछ कोड प्रोजेक्ट के साथ स्थानीय रूप से एक फ़ोल्डर है और आप संस्करण नियंत्रण प्रणाली - git का उपयोग करके अपनी प्रगति को ट्रैक करना शुरू करना चाहते हैं। कुछ लोग आपके भविष्य के लिए एक प्रेम पत्र लिखने के लिए git का उपयोग करने की तुलना करते हैं। अपने प्रतिबद्ध संदेशों को दिनों या हफ्तों या महीनों के बाद पढ़कर आप याद कर पाएंगे कि आपने निर्णय क्यों लिया, या "रोलबैक" में बदलाव किया - यानी जब आप अच्छा "कमिट मैसेज" लिखते हैं।
|
||||
|
||||
### कार्य: एक रीपाज़टॉरी और कमिट कोड बनाएं
|
||||
1. **GitHub पर रीपाज़टॉरी बनाएँ**. GitHub.com पर, रिपॉजिटरी टैब में, या नेविगेशन बार टॉप-राइट से, **नया रेपो** बटन ढूंढें।
|
||||
|
||||
1. अपने रिपॉजिटरी (फ़ोल्डर) को एक नाम दें
|
||||
1. **रिपॉजिटरी बनाएं** चुनें।
|
||||
|
||||
1. **अपने कार्यशील फ़ोल्डर में नेविगेट करें**. अपने टर्मिनल में, उस फ़ोल्डर पर स्विच करें (जिसे निर्देशिका के रूप में भी जाना जाता है) जिसे आप ट्रैक करना चाहते हैं, लिखे :
|
||||
|
||||
```bash
|
||||
cd [फ़ोल्डरका नाम]
|
||||
```
|
||||
|
||||
1. **एक गिट रिपॉजिटरी को प्रारंभ करें**. आपके प्रोजेक्ट मे लिखे:
|
||||
```bash
|
||||
git init
|
||||
```
|
||||
|
||||
1. **अवस्था जांच**. अपने भंडार प्रकार की स्थिति की जांच करने के लिए लिखे:
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
आउटपुट कुछ इस तरह दिख सकता है:
|
||||
|
||||
```output
|
||||
Changes not staged for commit:
|
||||
(use "git add <file>..." to update what will be committed)
|
||||
(use "git checkout -- <file>..." to discard changes in working directory)
|
||||
|
||||
modified: file.txt
|
||||
modified: file2.txt
|
||||
```
|
||||
|
||||
आमतौर पर एक `git status` कमांड आपको ऐसी चीजें बताती है जैसे रेपो में _saved_ होने के लिए कौन सी फाइलें तैयार हैं या इस पर ऐसे बदलाव हैं जिन्हें आप जारी रखना चाहते हैं।
|
||||
|
||||
1. **ट्रैकिंग के लिए सभी फाइलें जोड़ें**
|
||||
इसे स्टेजिंग फाइल / फाइल को स्टेजिंग एरिया में जोड़ना भी कहा जाता है।
|
||||
|
||||
```bash
|
||||
git add .
|
||||
```
|
||||
|
||||
`Git add` और `.` तर्क इंगित करता है कि आपकी सभी फाइलें और ट्रैकिंग के लिए परिवर्तन होगया है।
|
||||
|
||||
1. **ट्रैकिंग के लिए चयनित फ़ाइलें जोड़ें**
|
||||
|
||||
```bash
|
||||
git add [फ़ाइल या फ़ोल्डर का नाम]
|
||||
```
|
||||
|
||||
जब हम एक बार में सभी फ़ाइलों को कमिट नहीं करना चाहते हैं, तो यह हमें केवल स्टेजिंग क्षेत्र में चयनित फ़ाइलों को जोड़ने में मदद करता है।
|
||||
|
||||
1. **सभी फाइलों को अनस्टेज करें**
|
||||
|
||||
```bash
|
||||
git reset
|
||||
```
|
||||
|
||||
यह कमांड हमें एक ही बार में सभी फ़ाइलों को अस्थिर करने में मदद करता है।
|
||||
|
||||
1. **किसी विशेष फ़ाइल को अनस्टेज करें**
|
||||
|
||||
```bash
|
||||
git reset [फ़ाइल या फ़ोल्डर का नाम]
|
||||
```
|
||||
|
||||
यह कमांड हमें केवल एक विशेष फ़ाइल को एक बार में अनस्टेज करने में मदद करती है जिसे हम अगले कमिट के लिए शामिल नहीं करना चाहते हैं।
|
||||
|
||||
1. **अपना काम जारी रखना**. इस बिंदु पर आपने फ़ाइलों को तथाकथित _स्टैजिंग एरिया_ में जोड़ा है।एक जगह जहां Git आपकी फ़ाइलों को ट्रैक कर रही है। परिवर्तन को स्थायी करने के लिए आपको फ़ाइलों को _कॉमित_ की आवश्यकता होती है। ऐसा करने के लिए आप `git commit` कमांड के साथ एक _कमिट _ बनाते हैं। एक _कमिट_ आपके रेपो के इतिहास में एक बचत बिंदु का प्रतिनिधित्व करता है। _कमिट_ बनाने के लिए निम्नलिखित टाइप करें:
|
||||
|
||||
```bash
|
||||
git commit -m "पहला कमिट"
|
||||
```
|
||||
|
||||
यह आपकी सभी फ़ाइलों को "पहला कमिट" संदेश को जोड़ता है। भविष्य के कमिट संदेशों के लिए आप अपने विवरण में यह बताना चाहेंगे कि आपने किस प्रकार का परिवर्तन किया है।
|
||||
|
||||
1. **अपने स्थानीय Git रेपो को GitHub से कनेक्ट करें**. आपके मशीन पर एक Git रेपो अच्छा है, लेकिन कुछ बिंदु पर आप अपनी फ़ाइलों का बैकअप कहीं और रखना चाहते हैं और अन्य लोगों को भी अपने रेपो पर आपके साथ काम करने के लिए आमंत्रित करते हैं। ऐसा करने के लिए एक महान जगह GitHub है। याद रखें कि हमने पहले ही GitHub पर एक रेपो बना लिया है, इसलिए हमें केवल अपने Git रेपो को GitHub के साथ जोड़ना है। कमांड `git remote add` बस यही करेगा। निम्न कमांड टाइप करें:
|
||||
|
||||
> ध्यान दें, इससे पहले कि आप कमांड टाइप करें अपने रिपॉजिटरी URL को खोजने के लिए अपने GitHub रेपो पेज पर जाएं। आप इसे नीचे दिए गए कमांड में उपयोग करेंगे। अपने GitHub URL से `repository_name` बदलें।
|
||||
|
||||
```bash
|
||||
git remote add origin https://github.com/username/repository_name.git
|
||||
```
|
||||
|
||||
यह आपके द्वारा पहले बनाए गए GitHub रिपॉजिटरी को इंगित करते हुए "origin" नाम का एक _remote_, या कनेक्शन बनाता है।
|
||||
|
||||
1. **GitHub पर स्थानीय फ़ाइलें भेजें**. अब तक आपने स्थानीय रेपो और गिटहब रेपो के बीच एक _कनेक्शन_ बनाया है। चलो निम्न कमांड `git push` के साथ इन फाइलों को गिटहब को भेजें, जैसे:
|
||||
|
||||
```bash
|
||||
git push -u origin main
|
||||
```
|
||||
|
||||
यह आपकी "मैन" शाखा में GitHub को आपके कमिट भेजता है।
|
||||
|
||||
1. **अधिक परिवर्तन जोड़ने के लिए**. यदि आप परिवर्तन करना जारी रखना चाहते हैं और उन्हें GitHub पर धकेलना चाहते हैं, तो आपको निम्नलिखित तीन आदेशों का उपयोग करने की आवश्यकता होगी:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "अपना संदेश यहाँ लिखें"
|
||||
git push
|
||||
```
|
||||
|
||||
> टिप, आप उन फ़ाइलों को रोकने के लिए एक `.gitignore` फ़ाइल भी अपनाना चाह सकते हैं जिन्हें आप GitHub पर दिखाने से रोकना चाहते हैं - जैसे नोट्स आप उसी फ़ोल्डर में संग्रहीत करते हैं, लेकिन सार्वजनिक रिपॉजिटरी में कोई स्थान नहीं है। आप `.gitignore` फाइल के लिए टेम्प्लेट में [.gitignore टेम्प्लेट](https://github.com/github/gitignore) पे पा सकते हैं
|
||||
#### कमिट संदेश
|
||||
|
||||
एक महान Git कमिट विषय पंक्ति निम्नलिखित वाक्य को पूरा करती है:
|
||||
यदि लागू किया जाता है, तो यह प्रतिबद्ध होगा <आपकी विषय पंक्ति यहां>
|
||||
|
||||
विषय के लिए अनिवार्य, वर्तमान काल का उपयोग करें: "परिवर्तन" न "बदला गया" और न ही "परिवर्तने"।
|
||||
विषय के रूप में, शरीर में (वैकल्पिक) भी अनिवार्य, वर्तमान काल का उपयोग करते हैं। शरीर में परिवर्तन के लिए प्रेरणा शामिल होनी चाहिए और पिछले व्यवहार के साथ इसके विपरीत होना चाहिए। आप `क्यों` को समझा रहे हैं,` कैसे` को नहीं।
|
||||
|
||||
✅ GitHub के आसपास सर्फ करने के लिए कुछ मिनट लें। क्या आप वास्तव में महान कमिट संदेश पा सकते हैं? क्या आप वास्तव में न्यूनतम पा सकते हैं? आपको क्या संदेश लगता है कि एक कमिट संदेश देने के लिए सबसे महत्वपूर्ण और उपयोगी है?
|
||||
|
||||
### कार्य: सहयोग करें
|
||||
|
||||
गिटहब पर चीजें डालने का मुख्य कारण अन्य डेवलपर्स के साथ सहयोग करना संभव बनाना था।
|
||||
|
||||
## दूसरों के साथ परियोजनाओं पर काम करना
|
||||
|
||||
अपनी रिपॉजिटरी में, यह देखने के लिए कि आपकी परियोजना अनुशंसित सामुदायिक मानकों की तुलना कैसे करती है, `इनसाइट्स > कम्यूनिटी` पर जाएँ।
|
||||
|
||||
यहाँ कुछ चीजें हैं जो आपके GitHub रेपो में सुधार कर सकती हैं:
|
||||
- **विवरण**. क्या आपने अपनी परियोजना के लिए एक विवरण जोड़ा?
|
||||
- **README**. क्या आपने एक README जोड़ा? GitHub एक [README](https://docs.github.com/articles/about-readmes/) लिखने के लिए मार्गदर्शन प्रदान करता है।
|
||||
- **योगदान दिशानिर्देश**. आपके प्रोजेक्टका [योगदान दिशानिर्देश](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/) है,
|
||||
- **आचार संहिता**. एक [आचार संहिता](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
|
||||
- **लाइसेंस**. शायद सबसे महत्वपूर्ण बात, एक [लाइसेंस](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
|
||||
|
||||
|
||||
इन सभी संसाधनों से टीम के नए सदस्यों को लाभ मिलेगा। और वे आम तौर पर इस तरह की चीजें हैं जो आपके कोड को देखने से पहले भी नए योगदानकर्ताओं को देखते हैं, यह पता लगाने के लिए कि क्या आपका प्रोजेक्ट उनके लिए अपना समय बिताने के लिए सही जगह है।
|
||||
|
||||
✅ README फाइलें, हालांकि उन्हें तैयार करने में समय लगता है, अक्सर व्यस्त रखवाले द्वारा उपेक्षित कर दिए जाते हैं। क्या आप एक विशेष रूप से वर्णनात्मक का एक उदाहरण पा सकते हैं? नोट: कुछ अच्छे [READMEs बनाने में मदद करने के लिए कुछ उपकरण हैं](https://www.makeareadme.com/) जिन्हें आप आज़माना चाहते हैं।
|
||||
|
||||
### कार्य: कुछ कोड मर्ज करें
|
||||
|
||||
डॉक्स में योगदान करने से लोगों को परियोजना में योगदान करने में मदद मिलती है। यह बताता है कि आप किस प्रकार के योगदान की तलाश कर रहे हैं और प्रक्रिया कैसे काम करती है। योगदानकर्ताओं को GitHub पर आपके रेपो में योगदान करने में सक्षम होने के लिए कई चरणों से गुजरना होगा:
|
||||
|
||||
|
||||
1. **अपने रेपो को फोर्क करना** आप शायद लोगों को अपनी परियोजना को _fork_ करना चाहेंगे। फोर्किंग का अर्थ है उनके GitHub प्रोफाइल पर अपनी रिपॉजिटरी की प्रतिकृति बनाना।
|
||||
1. **क्लोन**.वहां से वे इस परियोजना को अपनी स्थानीय मशीन से जोड़ देंगे।
|
||||
1. **एक शाखा बनाएँ**. आप उन्हें अपने काम के लिए एक _शाखा_ बनाने के लिए कहना चाहेंगे।
|
||||
1. **एक क्षेत्र पर उनके परिवर्तन पर ध्यान दें**.योगदानकर्ताओं से एक समय में एक चीज़ पर उनके योगदान पर ध्यान केंद्रित करने के लिए कहें - इस तरह से संभावना है कि आप उनके काम में विलय कर सकते हैं। कल्पना कीजिए कि वे एक बग फिक्स लिखते हैं, एक नई सुविधा जोड़ते हैं, और कई परीक्षण अपडेट करते हैं - क्या होगा यदि आप चाहते हैं, या केवल 3 में से 2, या 3 में से 1 परिवर्तन लागू कर सकते हैं?
|
||||
|
||||
✅ ऐसी स्थिति की कल्पना करें जहां शाखाएं विशेष रूप से अच्छे कोड लिखने और शिपिंग करने के लिए महत्वपूर्ण हैं। आप किन मामलों का उपयोग कर सकते हैं?
|
||||
|
||||
> ध्यान दें, वह परिवर्तन हो जो आप दुनिया में देखना चाहते हैं, और अपने काम के लिए भी शाखाएँ बनाएँ। आपके द्वारा किया गया कोई भी शाखा उस शाखा पर बना दी जाएगी जिसे आप वर्तमान में "चेक आउट" कर रहे हैं। कौन सी शाखा है यह देखने के लिए `git status` का प्रयोग करें।
|
||||
|
||||
चलो एक योगदानकर्ता वर्कफ़्लो के माध्यम से चलते हैं। मान लें कि योगदानकर्ता पहले से ही रेपो को _फोर्क_ और _क्लोन_ कर चुका है, इसलिए उनके पास अपने स्थानीय मशीन पर काम करने के लिए तैयार गिट रेपो है:
|
||||
|
||||
1. **एक शाखा बनाएँ**.एक शाखा बनाने के लिए कमांड `git branch` का उपयोग करें जिसमें वे परिवर्तन होंगे जो उनके योगदान के लिए हैं:
|
||||
|
||||
```bash
|
||||
git branch [शाखाका-नाम]
|
||||
```
|
||||
|
||||
1. **कार्यशील शाखा पर स्विच करें**. निर्दिष्ट शाखा में स्विच करें और `git checkout` के साथ कार्य निर्देशिका को अपडेट करें:
|
||||
|
||||
```bash
|
||||
git checkout [शाखाका-नाम]
|
||||
```
|
||||
|
||||
1. **काम करो**. इस बिंदु पर आप अपने परिवर्तन जोड़ना चाहते हैं। निम्नलिखित आदेशों के बारे में Git को बताना न भूलें:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "मेरे परिवर्तन"
|
||||
```
|
||||
|
||||
यह सुनिश्चित करें कि आप अपनी खातिर एक अच्छा नाम दें, साथ ही साथ आप जिस रेपो में मदद कर रहे हैं उसका रखवालाका भी।
|
||||
|
||||
1. **`main` शाखा के साथ अपने काम को मिलाएं**. कुछ बिंदु पर आप काम कर रहे हैं और आप `main` शाखा के साथ अपने काम को जोड़ना चाहते हैं। `main` शाखा इस बीच बदल सकती है, इसलिए सुनिश्चित करें कि आपने इसे निम्न कमांड के साथ नवीनतम में अपडेट किया है:
|
||||
|
||||
```bash
|
||||
git checkout main
|
||||
git pull
|
||||
```
|
||||
|
||||
इस बिंदु पर आप यह सुनिश्चित करना चाहते हैं कि कोई भी _टकराव_, परिस्थितियां जहां Git आसानी से आपके कामकाजी शाखा में होने वाले परिवर्तनों को _संयोजित_ नहीं कर सकती है। इसलिए निम्न आदेश चलाएँ:
|
||||
|
||||
```bash
|
||||
git checkout [शाखाका-नाम]
|
||||
git merge main
|
||||
```
|
||||
|
||||
यह आपकी शाखा में `main` से सभी बदलाव लाएगा और उम्मीद है कि आप अभी भी जारी रख सकते हैं। यदि नहीं, तो VS कोड आपको बताएगा कि गिट कहां _उलझन_ में है और आप यह कहने के लिए प्रभावित फाइलों को बदल देते हैं कि कौन सी सामग्री सबसे सटीक है।
|
||||
|
||||
1. **अपना काम GitHub को भेजें**. अपने काम को GitHub में भेजने का मतलब है दो चीजें। अपनी शाखा को अपने रेपो में धकेलना और फिर एक पीआर, पुल अनुरोध को खोलें।
|
||||
|
||||
```bash
|
||||
git push --set-upstream origin [शाखाका-नाम]
|
||||
```
|
||||
|
||||
उपरोक्त कमांड आपके फोर्क्ड रेपो पर शाखा बनाता है।
|
||||
|
||||
1. **एक पीआर खोलें**. अगला, आप एक पीआर खोलना चाहते हैं। आप GitHub पर फोर्केड रेपो में नेविगेट करके ऐसा करते हैं। आपको GitHub पर एक संकेत दिखाई देगा जहां यह पूछता है कि क्या आप एक नया PR बनाना चाहते हैं, आप उस पर क्लिक करते हैं और आपको एक इंटरफ़ेस पर ले जाया जाता है जहाँ आप प्रतिबद्ध संदेश शीर्षक बदल सकते हैं, इसे अधिक उपयुक्त विवरण दे सकते हैं। अब रेपो के अनुरक्षक आप इस पीआर को देखेंगे और _उँगलियाँ पार_ कर जाएँगे जो आपके पीआर को सराहेंगे और _मर्ज_ करेंगे। अब आप एक योगदानकर्ता हैं, याय :)
|
||||
|
||||
1. **साफ - सफाई**. अपने को सफलतापूर्वक मर्ज करने के बाद _सफाई करना_ अच्छा माना जाता है। आप अपनी स्थानीय शाखा और उस शाखा को साफ़ करना चाहते हैं जिसे आपने GitHub में धकेल दिया है। पहले इसे निम्नलिखित कमांड के साथ स्थानीय रूप से हटा दें:
|
||||
|
||||
```bash
|
||||
git branch -d [शाखाका-नाम]
|
||||
```
|
||||
|
||||
सुनिश्चित करें कि आप अगले फोर्केड रेपो के लिए GitHub पृष्ठ पर जाएं और उस दूरस्थ शाखा को हटा दें जिसे आपने अभी पुश किया था।
|
||||
|
||||
`पुल अनुरोध` एक मूर्खतापूर्ण शब्द की तरह लगता है क्योंकि वास्तव में आप परियोजना में अपने परिवर्तनों को आगे बढ़ाना चाहते हैं। लेकिन अनुरक्षक (परियोजना स्वामी) या कोर टीम को परियोजना की "main" शाखा के साथ विलय करने से पहले आपके परिवर्तनों पर विचार करने की आवश्यकता है, इसलिए आप वास्तव में एक अनुचर से परिवर्तन के निर्णय का अनुरोध कर रहे हैं।
|
||||
|
||||
एक पुल अनुरोध समीक्षा, टिप्पणियों, एकीकृत परीक्षणों और अधिक के साथ एक शाखा पर पेश किए गए मतभेदों की तुलना और चर्चा करने का स्थान है। एक अच्छा पुल अनुरोध एक प्रतिबद्ध संदेश के समान नियमों का पालन करता है। आप समस्या ट्रैकर में किसी समस्या के संदर्भ को जोड़ सकते हैं, जब उदाहरण के लिए आपका कार्य किसी समस्या को हल करता है। यह आपके अंक की संख्या के बाद एक `#` का उपयोग करके किया जाता है। उदाहरण के लिए `# 97`।
|
||||
|
||||
🤞उंगलियों ने पार कर दिया कि सभी चेक पास हो गए और परियोजना के मालिकों ने परियोजना में आपके बदलावों को मर्ज कर दिया🤞
|
||||
|
||||
GitHub पर संबंधित दूरस्थ शाखा से सभी नए कमिट के साथ अपनी वर्तमान स्थानीय कार्य शाखा को अपडेट करें:
|
||||
|
||||
`git pull`
|
||||
|
||||
## कैसे खुला स्रोत में योगदान करे
|
||||
|
||||
सबसे पहले, आप के हित के GitHub पर एक रिपॉजिटरी (या **रेपो**) ढूंढें और जिसमें आप बदलाव में योगदान करना चाहते हैं। आप इसकी सामग्री को अपनी मशीन पर कॉपी करना चाहेंगे।
|
||||
|
||||
✅'शुरुआती-अनुकूल' रेपो को खोजने का एक अच्छा तरीका है, ['good-first-issue' द्वारा खोज करना](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
|
||||
|
||||
|
||||
|
||||
कोड को कॉपी करने के कई तरीके हैं। एक तरीका है रिपॉजिटरी की सामग्री को "क्लोन" करना, HTTPS, SSH का उपयोग करना, या GitHub CLI (कमांड लाइन इंटरफ़ेस) का उपयोग करना।
|
||||
|
||||
अपना टर्मिनल खोलें और रिपॉजिटरी को क्लोन करें जैसे:
|
||||
`git clone https://github.com/ProjectURL`
|
||||
|
||||
प्रोजेक्ट पर काम करने के लिए, सही फ़ोल्डर पर जाएँ:
|
||||
`cd ProjectURL`
|
||||
|
||||
आप [Codespaces](https://github.com/features/codespaces), GitHub के एम्बेडेड कोड एडिटर / क्लाउड डेवलपमेंट एन्वायरमेंट, या [GitHub Desktop](https://desktop.github.com/) का उपयोग करके पूरी परियोजना भी खोल सकते हैं ) का है।
|
||||
|
||||
अंत में, आप ज़िप फ़ोल्डर में कोड डाउनलोड कर सकते हैं।
|
||||
|
||||
### GitHub के बारे में कुछ और दिलचस्प बातें
|
||||
|
||||
आप GitHub पर किसी भी पब्लिक रिपॉजिटरी को स्टार, पहरा और/या "फोर्क" कर सकते हैं। आप शीर्ष-दाएँ ड्रॉप-डाउन मेनू में अपने तारांकित रिपॉजिटरी पा सकते हैं। यह बुकमार्क करने जैसा है, लेकिन कोड के लिए।
|
||||
|
||||
परियोजनाओं में एक मुद्दा ट्रैकर है, ज्यादातर "इश्यू" टैब में गिटहब पर जब तक कि अन्यथा इंगित नहीं किया जाता है, जहां लोग परियोजना से संबंधित मुद्दों पर चर्चा करते हैं। और पुल अनुरोध टैब वह है जहां लोग उन परिवर्तनों की चर्चा और समीक्षा करते हैं जो प्रगति पर हैं।
|
||||
|
||||
परियोजनाओं की चर्चा फ़ोरम, मेलिंग सूचियों, या चैट चैनलों जैसे स्लैक, डिस्कोर्ड या आईआरसी में भी हो सकती है।
|
||||
|
||||
✅ अपने नए GitHub रेपो के चारों ओर एक नज़र डालें और कुछ चीजों को आज़माएं, जैसे कि सेटिंग्स को संपादित करना, अपने रेपो में जानकारी जोड़ना और एक प्रोजेक्ट बनाना (जैसे कंबन बोर्ड)। बहुत कुछ है जो आप कर सकते हैं!
|
||||
|
||||
---
|
||||
|
||||
## 🚀 चुनौती
|
||||
|
||||
एक दूसरे के कोड पर काम करने के लिए एक दोस्त के साथ जोडे। सहयोगी रूप से एक परियोजना बनाएँ, कोड बनाएँ, शाखाएँ बनाएँ, और परिवर्तनों को मर्ज करें।
|
||||
|
||||
## व्याख्यान उपरांत प्रश्नोत्तरी
|
||||
[व्याख्यान उपरांत प्रश्नोत्तरी](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/4?loc=hi)
|
||||
|
||||
## समीक्षा और स्व अध्ययन
|
||||
|
||||
[ओपन सोर्स सॉफ्टवेयर में योगदान](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution) के बारे में और पढ़ें।
|
||||
|
||||
[गिट चिटशीट](https://training.github.com/downloads/github-git-cheat-sheet/).
|
||||
|
||||
अभ्यास, अभ्यास, अभ्यास। GitHub में [lab.github.com](https://lab.github.com/) के माध्यम से सीखने के शानदार रास्ते उपलब्ध हैं:
|
||||
|
||||
- [GitHub पर पहला सप्ताह](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
|
||||
आपको और भी उन्नत प्रयोगशालाएँ मिलेंगी।
|
||||
|
||||
## असाइनमेंट
|
||||
|
||||
[GitHub प्रशिक्षण प्रयोगशाला पर पहला सप्ताह](https://lab.github.com/githubtraining/first-week-on-github) पूरा करे
|
||||
@ -0,0 +1,318 @@
|
||||
# Inleiding van GitHub
|
||||
|
||||
Deze les behandelt de basisprincipes van GitHub, een platform voor het hosten en beheren van wijzigingen in uw code.
|
||||
|
||||
|
||||
> Sketchnote by [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Quiz voorafgaand aan de lezing
|
||||
[Quiz voorafgaand aan de lezing](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/3)
|
||||
|
||||
## Inleiding
|
||||
|
||||
In deze les behandelen we:
|
||||
|
||||
- het volgen van het werk dat u op uw machine doet
|
||||
- samen met anderen aan projecten werken
|
||||
- hoe u kunt bijdragen aan open source software
|
||||
|
||||
### Vereisten
|
||||
|
||||
Voordat u begint, moet u controleren of Git is geïnstalleerd. In het terminal typ:
|
||||
`git --version`
|
||||
|
||||
Als Git niet is geïnstalleerd, [download Git](https://git-scm.com/downloads). Stel vervolgens uw lokale Git-profiel in de terminal in:
|
||||
* `git config --global user.name "uw-naam"`
|
||||
* `git config --global user.email "uw-email"`
|
||||
|
||||
Om te controleren of Git al is geconfigureerd, kunt u het volgende typen:
|
||||
`git config --list`
|
||||
|
||||
U heeft ook een GitHub-account nodig, een code-editor (zoals Visual Studio Code) en u moet uw terminal openen (of: command prompt).
|
||||
|
||||
Navigeer naar [github.com](https://github.com/) en maak een account aan als u dat nog niet heeft gedaan, of log in en vul uw profiel in.
|
||||
|
||||
✅ GitHub is niet de enige coderepository ter wereld; er zijn anderen, maar GitHub is de bekendste
|
||||
|
||||
### Voorbereiding
|
||||
|
||||
U heeft zowel een map met een codeproject op uw lokale computer (laptop of pc) als een openbare repository op GitHub nodig, die als voorbeeld zal dienen voor hoe u kunt bijdragen aan de projecten van anderen.
|
||||
|
||||
---
|
||||
|
||||
## Code beheer
|
||||
|
||||
Laten we zeggen dat u lokaal een map hebt met een of ander codeproject en u wilt beginnen met het volgen van uw voortgang met git - het versiebeheersysteem. Sommige mensen vergelijken het gebruik van git met het schrijven van een liefdesbrief aan uw toekomstige zelf. Als u uw commitberichten dagen of weken of maanden later leest, zult u u kunnen herinneren waarom u een beslissing heeft genomen, of een wijziging "terugdraaien" - dat wil zeggen, wanneer u goede "commitberichten" schrijft.
|
||||
|
||||
### Taak: maak een repository en leg code vast
|
||||
|
||||
1. **Maak een repository op GitHub**. Zoek op GitHub.com, in het tabblad repositories, of in de navigatiebalk rechtsboven, de knop **new repo**.
|
||||
|
||||
1. Geef uw repository (map) een naam
|
||||
1. Selecteer **create repository**.
|
||||
|
||||
1. **Navigeer naar uw werkmap**. Schakel in uw terminal naar de map (ook bekend als de directory) die u wilt beginnen met volgen. Typ:
|
||||
|
||||
```bash
|
||||
cd [naam van uw map]
|
||||
```
|
||||
|
||||
1. **Initialiseer een git-repository**. In uw project, typ:
|
||||
|
||||
```bash
|
||||
git init
|
||||
```
|
||||
|
||||
1. **Controleer de status**. Om de status van uw repository te controleren, typ:
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
de output kan er ongeveer zo uitzien:
|
||||
|
||||
```output
|
||||
Changes not staged for commit:
|
||||
(use "git add <file>..." to update what will be committed)
|
||||
(use "git checkout -- <file>..." to discard changes in working directory)
|
||||
|
||||
modified: file.txt
|
||||
modified: file2.txt
|
||||
```
|
||||
|
||||
Typisch vertelt een `git status` commando u dingen zoals welke bestanden klaar zijn om _opgeslagen_ te worden naar de repo of bevat veranderingen die u misschien wilt behouden.
|
||||
|
||||
1. **Voeg alle bestanden toe voor tracking**
|
||||
Dit wordt ook wel staging-bestanden/ bestanden toevoegen aan het staging-gebied genoemd.
|
||||
|
||||
```bash
|
||||
git add .
|
||||
```
|
||||
|
||||
Het `git add` plus `.` argument geeft aan dat al uw bestanden en wijzigingen voor tracking geselecteerd zijn.
|
||||
|
||||
1. **Voeg geselecteerde bestanden toe voor tracking**
|
||||
|
||||
```bash
|
||||
git add [bestands- of mapnaam]
|
||||
```
|
||||
|
||||
Dit helpt ons om alleen geselecteerde bestanden aan het staging-gebied toe te voegen als we niet alle bestanden tegelijk willen vastleggen.
|
||||
|
||||
1. **Unstage alle bestanden**
|
||||
|
||||
```bash
|
||||
git reset
|
||||
```
|
||||
|
||||
Dit commando helpt ons om alle bestanden tegelijk te unstagen.
|
||||
|
||||
1. **Unstage een bepaald bestand**
|
||||
|
||||
```bash
|
||||
git reset [bestands- of mapnaam]
|
||||
```
|
||||
|
||||
Dit commando helpt ons om alleen een bepaald bestand tegelijk te unstagen dat we niet willen opnemen voor de volgende commit.
|
||||
|
||||
1. **Uw werk voortzetten**. Op dit punt heeft u de bestanden toegevoegd aan een zogenaamd _staging-gebied_. Een plek waar Git uw bestanden bijhoudt. Om de wijziging permanent te maken, moet u de bestanden _commiten_. Om dit te doen maakt u een _commit_ aan met het `git commit` commando. Een _commit_ vertegenwoordigt een besparingspunt in de geschiedenis van uw repo. Typ het volgende om een _commit_ te maken:
|
||||
|
||||
```bash
|
||||
git commit -m "eerste commit"
|
||||
```
|
||||
|
||||
Dit commit al uw bestanden door het bericht "first commit" toe te voegen. Voor toekomstige commitberichten wilt u meer beschrijvend zijn in uw beschrijving om over te brengen wat voor soort wijziging u heeft aangebracht.
|
||||
|
||||
1. **Verbind uw lokale Git-repo met GitHub**. Een Git-repo is goed op uw computer, maar op een gegeven moment wilt u ergens een back-up van uw bestanden hebben en ook andere mensen uitnodigen om met u aan uw opslagplaats te werken. Een geweldige plek om dat te doen is GitHub. Onthoud dat we al een repo op GitHub hebben gemaakt, dus het enige dat we hoeven te doen, is onze lokale Git-repo verbinden met GitHub. Het commando `git remote add` zal precies dat doen. Typ de volgende commando:
|
||||
|
||||
> Let op: voordat u de opdracht typt, gaat u naar uw GitHub-repo-pagina om de repository-URL te vinden. U gebruikt het in het onderstaande commando. Vervang `repository_name` door uw GitHub-URL.
|
||||
|
||||
```bash
|
||||
git remote add origin https://github.com/username/repository_name.git
|
||||
```
|
||||
|
||||
Dit creëert een _remote_, of verbinding, genaamd "origin", wijzend naar de GitHub-repository die u eerder heeft gemaakt.
|
||||
|
||||
1. **Stuur lokale bestanden naar GitHub**. Tot nu toe heeft u een _verbinding_ gemaakt tussen de lokale repo en de GitHub-repo. Laten we deze bestanden naar GitHub sturen met het volgende commando `git push`, zoals zo:
|
||||
|
||||
```bash
|
||||
git push -u origin main
|
||||
```
|
||||
|
||||
Dit stuurt uw commits in uw "main" tak naar GitHub.
|
||||
|
||||
1. **Om meer wijzigingen toe te voegen**. Als u door wilt gaan met het aanbrengen van wijzigingen en ze naar GitHub wilt pushen, hoeft u alleen maar de volgende drie commando's te gebruiken:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "typ hier uw commitbericht"
|
||||
git push
|
||||
```
|
||||
|
||||
> Tip, misschien wilt u ook een `.gitignore`-bestand adopteren om te voorkomen dat bestanden die u niet wilt volgen, verschijnen op GitHub - zoals dat notitiesbestand dat u opslaat in dezelfde map maar geen plaats heeft op een openbare repository. U kunt sjablonen voor `.gitignore` bestanden vinden op [.gitignore templates](https://github.com/github/gitignore).
|
||||
|
||||
#### Commit berichten
|
||||
|
||||
Een geweldige onderwerpregel voor een commitbericht van Git maakt de volgende zin compleet:
|
||||
Indien toegepast, zal deze commit <uw onderwerpregel hier>
|
||||
|
||||
Gebruik voor het onderwerp de gebiedende wijs, tegenwoordige tijd: "verander" niet "veranderd" noch "veranderingen".
|
||||
Net als in het onderwerp, gebruik in het lichaam (optioneel) ook de imperatieve tegenwoordige tijd. Het lichaam moet de motivatie voor de verandering opnemen en dit contrasteren met eerder gedrag. U legt het `waarom` uit, niet het `hoe`.
|
||||
|
||||
✅ Neem een paar minuten de tijd om rond GitHub te surfen. Kunt u een echt geweldig commitbericht vinden? Kunt u een echt minimale vinden? Welke informatie is volgens u het belangrijkst en nuttigst om over te brengen in een commitbericht?
|
||||
|
||||
### Taak: Samenwerken
|
||||
|
||||
De belangrijkste reden om dingen op GitHub te zetten, was om het mogelijk te maken om samen te werken met andere ontwikkelaars.
|
||||
|
||||
## Samen met anderen aan projecten werken
|
||||
|
||||
Navigeer in uw repository naar `Insights > Community` om te zien hoe uw project zich verhoudt tot aanbevolen communitystandaarden.
|
||||
|
||||
Hier zijn enkele dingen die uw GitHub-repo kunnen verbeteren:
|
||||
- **Omschrijving**. Heeft u een beschrijving voor uw project toegevoegd?
|
||||
- **README**. Heeft u een README toegevoegd? GitHub biedt richtlijnen voor het schrijven van een [README](https://docs.github.com/articles/about-readmes/).
|
||||
- **Richtlijn voor bijdragen**. Heeft uw project [richtlijnen voor bijdragen](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/),
|
||||
- **Gedragscode**. Een [Gedragscode](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
|
||||
- **Licentie**. Misschien nog belangrijker, een [licentie](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
|
||||
|
||||
|
||||
Al deze middelen zullen nieuwe teamleden helpen. En dat zijn typisch het soort dingen waar nieuwe bijdragers naar kijken voordat ze zelfs maar naar uw code kijken, om erachter te komen of uw project de juiste plek is om hun tijd door te brengen.
|
||||
|
||||
✅ README-bestanden, hoewel ze wat tijd nodig hebben om voor te bereiden, worden vaak genegeerd door drukke beheerders. Kunt u een voorbeeld vinden van een bijzonder beschrijvende? Opmerking: er zijn enkele [tools om goede README's te maken](https://www.makeareadme.com/) die u misschien zou willen proberen.
|
||||
|
||||
### Taak: voeg een code samen
|
||||
|
||||
Documenten voor bijdragen helpen mensen bij te dragen aan het project. Het legt uit wat voor soort bijdragen u zoekt en hoe het proces werkt. Bijdragers moeten een reeks stappen doorlopen om bij te dragen aan uw repo op GitHub:
|
||||
|
||||
|
||||
1. **Uw repo forken** Waarschijnlijk wilt u dat mensen uw project _forken_. Forken betekent het maken van een replica van uw repository op hun GitHub-profiel.
|
||||
1. **Kloon**. Van daaruit zullen ze het project naar hun lokale computer klonen (clone).
|
||||
1. **Maak een tak**. U zult ze willen vragen om een _tak_ voor hun werk te creëren (branch).
|
||||
1. **Richt hun verandering op één gebied**. Vraag bijdragers om hun bijdragen op één ding tegelijk te concentreren - op die manier is de kans groter dat u hun werk kan _samenvoegen_ (merge). Stelt u voor dat ze een bugfix schrijven, een nieuwe functie toevoegen en verschillende tests bijwerken - wat als u slechts 2 van de 3 of 1 van de 3 wijzigingen wilt of kunt implementeren?
|
||||
|
||||
✅ Stelt u een situatie voor waarin takken bijzonder cruciaal zijn voor het schrijven en verzenden van goede code. Welke use-cases kunt u bedenken?
|
||||
|
||||
> Let op: wees de verandering die u in de wereld wilt zien, en maak ook takken voor uw eigen werk. Alle commits die u maakt, worden gemaakt op de tak waar u momenteel naar "uitgecheckt" bent. Gebruik `git status` om te zien welke tak dat is.
|
||||
|
||||
Laten we een workflow voor bijdragers doorlopen. Veronderstel dat de bijdrager de repo al _geforkt_ en _gekloond_ heeft, zodat ze een Git-repo hebben klaar om aan te werken, op hun lokale computer:
|
||||
|
||||
1. **Maak een tak**. Gebruik het commando `git branch` om een branch te maken die de wijzigingen bevat die ze willen bijdragen:
|
||||
|
||||
```bash
|
||||
git branch [taknaam]
|
||||
```
|
||||
|
||||
1. **Overschakelen naar werkende tak**. Schakel over naar de gespecificeerde tak en update de werkdirectory met `git checkout`:
|
||||
|
||||
```bash
|
||||
git checkout [taknaam]
|
||||
```
|
||||
|
||||
1. **Werken**. Op dit punt wilt u uw wijzigingen toevoegen. Vergeet niet om Git erover te vertellen met de volgende commando's:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "mijn veranderingen"
|
||||
```
|
||||
|
||||
Zorg ervoor dat u uw commit een goede naam geeft, zowel voor u als voor de beheerder van de repo waarmee u helpt.
|
||||
|
||||
1. **Combineer uw werk met de `main` tak**. Op een gegeven moment bent u klaar met werken en wilt u uw werk combineren met dat van de `main` tak. De `main` tak kan ondertussen veranderd zijn, dus zorg ervoor dat u deze eerst bijwerkt naar de laatste versie met de volgende commando's:
|
||||
|
||||
```bash
|
||||
git checkout main
|
||||
git pull
|
||||
```
|
||||
|
||||
Op dit punt wilt u er zeker van zijn dat alle _conflicten_, situaties waarin Git niet gemakkelijk de veranderingen kan _combineren_ plaatsvinden in uw werkende tak. Voer daarom de volgende opdrachten uit:
|
||||
|
||||
```bash
|
||||
git checkout [taknaam]
|
||||
git merge main
|
||||
```
|
||||
|
||||
Dit brengt alle wijzigingen van `main` naar uw tak en hopelijk kunt u gewoon doorgaan. Als dit niet het geval is, zal VS Code u vertellen waar Git _in de war_ is en verandert u gewoon de betrokken bestanden om te zeggen welke inhoud het meest accuraat is.
|
||||
|
||||
1. **Stuur uw werk naar GitHub**. Het verzenden van uw werk naar GitHub betekent twee dingen. Uw tak naar uw repo pushen en vervolgens een PR, Pull Request openen.
|
||||
|
||||
```bash
|
||||
git push --set-upstream origin [taknaam]
|
||||
```
|
||||
|
||||
Het bovenstaande commando maakt de tak op uw geforkte repo.
|
||||
|
||||
1. **Open een PR**. Vervolgens wilt u een PR openen. U doet dat door naar de geforkte repo op GitHub te navigeren. U ziet een indicatie op GitHub waar het vraagt of u een nieuwe PR wilt maken, u klikt erop en u wordt naar een interface geleid waar u de titel van het commitbericht kunt wijzigen, geef het een meer geschikte beschrijving. Nu zal de beheerder van de repo die u heeft geforkt deze PR zien en, _vingers gekruist_, zullen ze uw PR waarderen en _samenvoegen_. U bent nu een bijdrager, yay :)
|
||||
|
||||
1. **Opruimen**. Het wordt als een goede gewoonte beschouwd om _op te ruimen_ nadat u met succes een PR hebt samengevoegd. U wilt zowel uw lokale tak opruimen als de tak die u naar GitHub hebt gepusht. Laten we het eerst lokaal verwijderen met het volgende commando:
|
||||
|
||||
```bash
|
||||
git branch -d [taknaam]
|
||||
```
|
||||
|
||||
Zorg ervoor dat u naar de GitHub-pagina gaat voor de geforkte repo en verwijder de externe tak die u er zojuist naartoe hebt gepusht.
|
||||
|
||||
`Pull request` lijkt een gekke term, omdat u uw wijzigingen echt in het project wilt pushen. Maar de onderhouder (projecteigenaar) of het kernteam moet rekening houden met uw wijzigingen voordat u deze samenvoegt met de "main" tak van het project, dus u vraagt echt om een wijzigingsbesluit van een onderhouder.
|
||||
|
||||
Een pull request is de plek om de verschillen die op een tak zijn geïntroduceerd te vergelijken en te bespreken met recensies, opmerkingen, geïntegreerde tests en meer. Een goed pull request volgt ongeveer dezelfde regels als een commitbericht. U kunt een verwijzing naar een probleem (issue) toevoegen in de issue tracker, bijvoorbeeld wanneer uw werk een probleem oplost. Dit doet u met een `#` gevolgd door het nummer van uw probleem. Bijvoorbeeld `# 97`.
|
||||
|
||||
🤞Duimen dat alle controles slagen en de projecteigenaar(s) uw wijzigingen in het project samenvoegen🤞
|
||||
|
||||
Update uw huidige lokale werkende tak met alle nieuwe commits van de corresponderende remote tak op GitHub:
|
||||
|
||||
`git pull`
|
||||
|
||||
## Hoe u kunt bijdragen aan open source
|
||||
|
||||
Laten we eerst een repository - of: repo - op GitHub zoeken die voor u interessant is en waaraan u een wijziging zou willen bijdragen. U zult de inhoud ervan naar uw machine kopiëren.
|
||||
|
||||
✅ Een goede manier om 'beginnersvriendelijke' repos te vinden, is door [te zoeken op de tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
|
||||
|
||||
|
||||
|
||||
Er zijn verschillende manieren om code te kopiëren. Een manier is om de inhoud van de repository te "klonen" door HTTPS, SSH of de GitHub CLI (Command Line Interface) te gebruiken.
|
||||
|
||||
Open uw terminal en kloon de repository op deze manier:
|
||||
`git clone https://github.com/ProjectURL`
|
||||
|
||||
Schakel naar de juiste map om aan het project te werken:
|
||||
`cd ProjectURL`
|
||||
|
||||
U kunt ook het hele project openen met [Codespaces](https://github.com/features/codespaces), GitHub's ingesloten code-editor /cloud-ontwikkelomgeving of [GitHub Desktop](https://desktop.github.com/).
|
||||
|
||||
Ten slotte kunt u de code downloaden in een gecomprimeerde map.
|
||||
|
||||
### Nog een paar interessante dingen over GitHub
|
||||
|
||||
U kunt elke openbare repository op GitHub een ster geven, bekijken en/of "forken". U kunt uw repositories met ster vinden in het vervolgkeuzemenu rechtsboven. Het is net als bladwijzers, maar dan voor code.
|
||||
|
||||
Projecten hebben een issue tracker, meestal op GitHub in de "Issues" tab, tenzij anders aangegeven, waar mensen problemen bespreken die verband houden met het project. En op het tabblad Pull Requests bespreken en beoordelen mensen lopende wijzigingen.
|
||||
|
||||
Projecten kunnen ook worden besproken in forums, mailinglijsten of chatkanalen zoals Slack, Discord of IRC.
|
||||
|
||||
✅ Kijk eens rond in uw nieuwe GitHub-repo en probeer een paar dingen, zoals het bewerken van instellingen, het toevoegen van informatie aan uw repo en het maken van een project (zoals een Kanban-bord). U kunt veel doen!
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Uitdaging
|
||||
|
||||
Koppel met een vriend om aan elkaars code te werken. Creëer gezamenlijk een project, fork code, maak takken en voeg wijzigingen samen.
|
||||
|
||||
## Quiz na de lezing
|
||||
[Quiz na de lezing](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/4)
|
||||
|
||||
## Beoordeling en zelfstudie
|
||||
|
||||
Lees meer over [bijdragen aan open source software](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
|
||||
|
||||
[Git-cheatsheet](https://training.github.com/downloads/github-git-cheat-sheet/).
|
||||
|
||||
Oefenen, oefenen, oefenen. GitHub heeft geweldige leertrajecten beschikbaar via [lab.github.com](https://lab.github.com/):
|
||||
|
||||
- [Eerste week op GitHub](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
|
||||
U zult ook meer geavanceerde labs vinden.
|
||||
|
||||
## Toewijzing
|
||||
|
||||
Voltooi [de eerste week op GitHub-trainingslaboratorium](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
@ -0,0 +1,317 @@
|
||||
# Introdução ao GitHub
|
||||
|
||||
Esta lição cobre os fundamentos do GitHub, uma plataforma para hospedar e gerenciar alterações em seu código.
|
||||
|
||||
|
||||
> Sketchnote por [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Quiz Pré-Aula
|
||||
[Quiz Pré-Aula](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/3)
|
||||
|
||||
## Introdução
|
||||
|
||||
Nesta lição vamos falar sobre:
|
||||
|
||||
- rastreando o trabalho que você faz em sua máquina
|
||||
- trabalhando em projetos com outros
|
||||
- como contribuir com software de código aberto
|
||||
|
||||
### Pré-requisitos
|
||||
|
||||
Antes de começar, você precisará verificar se o Git está instalado. No terminal, digite:
|
||||
`git --version`
|
||||
|
||||
Se o Git não estiver instalado, [baixe o Git aqui](https://git-scm.com/downloads). Em seguida, configure seu perfil Git local no terminal:
|
||||
* `git config --global user.name "your-name"`
|
||||
* `git config --global user.email "your-email"`
|
||||
|
||||
Para verificar se o Git já está configurado, você pode digitar:
|
||||
`git config --list`
|
||||
|
||||
Você também precisará de uma conta do GitHub, um editor de código (como o Visual Studio Code) e abrir seu terminal (ou: prompt de comando).
|
||||
|
||||
Navegue para [github.com](https://github.com/) e crie uma conta, caso ainda não o tenha feito, ou faça login e preencha o seu perfil.
|
||||
|
||||
✅ O GitHub não é o único repositório de código do mundo; existem outros, mas o GitHub é o mais conhecido
|
||||
|
||||
### Preparação
|
||||
|
||||
Você precisará de uma pasta com um projeto de código em sua máquina local (laptop ou PC) e de um repositório público no GitHub, que servirá como um exemplo de como contribuir com os projetos de outras pessoas.
|
||||
|
||||
---
|
||||
|
||||
## Gerenciamento de código
|
||||
|
||||
Digamos que você tenha uma pasta localmente com algum projeto de código e deseja começar a monitorar seu progresso usando git - o sistema de controle de versão. Algumas pessoas comparam o uso do git a escrever uma carta de amor para o seu futuro eu. Lendo suas mensagens de commit dias, semanas ou meses depois, você será capaz de se lembrar por que tomou uma decisão, ou "reverter" uma mudança - isto é, quando você escreve boas "mensagens de commit".
|
||||
|
||||
### Tarefa: Faça um repositório e conmmit o código
|
||||
|
||||
1. **Crie um repositório no GitHub**. No GitHub.com, na guia de repositórios ou na barra de navegação superior direita, encontre o botão **new repo** .
|
||||
|
||||
1. Dê um nome ao seu repositório (pasta)
|
||||
1. Selecione **create repository**.
|
||||
|
||||
1. **Navegue até sua pasta de trabalho**. Em seu terminal, mude para a pasta (também conhecida como diretório) que deseja iniciar o rastreamento. Digite:
|
||||
|
||||
```bash
|
||||
cd [nome da sua pasta]
|
||||
```
|
||||
|
||||
1. **Inicialize um repositório git**. No seu projeto, digite:
|
||||
|
||||
```bash
|
||||
git init
|
||||
```
|
||||
|
||||
1. **Cheque status**. Para checar o status de seu repositório, digite:
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
a saída pode ser parecida com esta:
|
||||
|
||||
```output
|
||||
Changes not staged for commit:
|
||||
(use "git add <file>..." to update what will be committed)
|
||||
(use "git checkout -- <file>..." to discard changes in working directory)
|
||||
|
||||
modified: file.txt
|
||||
modified: file2.txt
|
||||
```
|
||||
|
||||
Geralmente o comando `git status` diz a você coisas como quais arquivos estão prontos para serem _salvos_ para o repo ou tem alterações que você pode querer persistir.
|
||||
|
||||
1. **Adicionar todos os arquivos para rastreamento**
|
||||
Isso também é chamado de arquivos de teste / adição de arquivos à área de teste.
|
||||
|
||||
```bash
|
||||
git add .
|
||||
```
|
||||
|
||||
O argumento `git add` plus `.` indiciona todos os seus arquivos e alterações para rastreamento.
|
||||
|
||||
1. **Adicionar arquivos selecionados para rastreamento**
|
||||
|
||||
```bash
|
||||
git add [nome do arquivo ou pasta]
|
||||
```
|
||||
|
||||
Isso nos ajuda a adicionar apenas os arquivos selecionados à área de teste quando não queremos enviar todos os arquivos de uma vez.
|
||||
|
||||
1. **Unstage todos os arquivos**
|
||||
|
||||
```bash
|
||||
git reset
|
||||
```
|
||||
Este comando nos ajuda a unstage todos os arquivos de uma vez.
|
||||
|
||||
1. **Unstage um arquivo em particular**
|
||||
|
||||
```bash
|
||||
git reset [nome do arquivo ou pasta]
|
||||
```
|
||||
|
||||
Este comando nos ajuda a remover stage de apenas um arquivo específico de uma vez que não queremos incluir no próximo commit.
|
||||
|
||||
1. **Persistindo no seu trabalho**. Neste ponto, você adicionou os arquivos a um local chamado _staging area_. Um lugar onde o Git está rastreando seus arquivos. Para tornar a mudança permanente, você precisa _committar_ os arquivos. Para fazer isso, crie um _commit_ com o comando `git commit`. Um _commit_ representa um ponto na história do seu repo sendo salvo. Digite o seguinte para criar um _commit_:
|
||||
|
||||
```bash
|
||||
git commit -m "first commit"
|
||||
```
|
||||
|
||||
Isso confirma todos os seus arquivos, adicionando a mensagem "first commit" (primeiro commit). Para mensagens de commit futuras, você desejará ser mais descritiva em sua descrição para transmitir que tipo de mudança você fez.
|
||||
|
||||
1. **Conecte seu repositório Git local com GitHub**. Um repositório Git é bom em sua máquina, mas em algum momento você vai querer fazer backup de seus arquivos em algum lugar e também convidar outras pessoas para trabalhar com você em seu repositório. Um ótimo lugar para fazer isso é o GitHub. Lembre-se de que já criamos um repositório no GitHub, então a única coisa que precisamos fazer é conectar nosso repositório Git local ao GitHub. O comando `git remote add` fará exatamente isso. Digite o seguinte comando:
|
||||
|
||||
> Antes de digitar o comando, vá para a página do repositório GitHub para encontrar o URL do repositório. Você o usará no comando abaixo. Substitua `repository_name` pelo seu URL do GitHub.
|
||||
|
||||
```bash
|
||||
git remote add origin https://github.com/username/repository_name.git
|
||||
```
|
||||
|
||||
Isso cria um _remote_, ou conexão, chamada "origin" apontando para o repositório GitHub que você criou anteriormente.
|
||||
|
||||
1. **Envie arquivos locais para GitHub**. Até agora, você criou uma _conexão_ entre o repositório local e o repositório GitHub. Vamos enviar esses arquivos para o GitHub com o seguinte comando `git push`, assim:
|
||||
|
||||
```bash
|
||||
git push -u origin main
|
||||
```
|
||||
|
||||
Isso envia seus commits em seu branch "principal" para o GitHub.
|
||||
|
||||
1. **Para adicionar mais mudanças**. Se quiser continuar fazendo alterações e enviando-as para o GitHub, você só precisará usar os três comandos a seguir:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "digite sua mensagem de commit aqui"
|
||||
git push
|
||||
```
|
||||
|
||||
> Dica, você também pode adotar um arquivo `.gitignore` para evitar que arquivos que você não deseja rastrear apareçam no GitHub - como aquele arquivo de notas que você armazena na mesma pasta, mas não tem lugar em um repositório público. Você pode encontrar modelos para arquivos `.gitignore` em [modelos .gitignore](https://github.com/github/gitignore).
|
||||
|
||||
#### Mensagens de Commit
|
||||
|
||||
Uma ótima mensagem de Git commit completa a seguinte frase:
|
||||
Se aplicado, este commit irá <sua mensagem de commit aqui>
|
||||
|
||||
Para o assunto use o tempo presente imperativo: "mudar" e não "mudou" nem "muda".
|
||||
Assim como no sujeito, no corpo (opcional) também use o tempo presente imperativo. O corpo deve incluir a motivação para a mudança e contrastar isso com o comportamento anterior. Você está explicando o `porquê`, não o` como`.
|
||||
|
||||
✅ Reserve alguns minutos para navegar no GitHub. Você consegue encontrar uma mensagem de commit realmente ótima? Você pode encontrar uma ruim? Quais informações você acha que são as mais importantes e úteis para transmitir em uma mensagem de commit?
|
||||
|
||||
### Tarefa: Colabore
|
||||
|
||||
O principal motivo para colocar coisas no GitHub foi possibilitar a colaboração com outros desenvolvedores.
|
||||
|
||||
## Trabalhando em projetos com outras pessoas
|
||||
|
||||
Em seu repositório, navegue até `Insights> Community` para ver como seu projeto se compara aos padrões recomendados da comunidade.
|
||||
|
||||
Aqui estão algumas coisas que podem melhorar seu repositório GitHub:
|
||||
- **Descrição**. Você adicionou uma descrição para o seu projeto?
|
||||
- **README**. Você adicionou um README? O GitHub fornece orientação para escrever um [README](https://docs.github.com/articles/about-readmes/).
|
||||
- **Guia de Contribuição**. Seu projeto tem um [guia para contribuição](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/),
|
||||
- **Código de Conduta**. Um [Código de Conduta](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
|
||||
- **Licença**. Talvez o mais importante, a [licença](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
|
||||
|
||||
|
||||
Todos esses recursos irão beneficiar a integração de novos membros da equipe. E esses são normalmente o tipo de coisas que os novas pessoas colaboradoras olham antes mesmo de olhar para o seu código, para descobrir se o seu projeto é o lugar certo para elas passarem o tempo.
|
||||
|
||||
✅ Arquivos README, embora levem tempo para serem preparados, são freqüentemente negligenciados por pessoas mantenedores ocupadas. Você pode encontrar um exemplo particularmente descritivo? Nota: existem algumas [ferramentas para ajudar a criar bons READMEs](https://www.makeareadme.com/) que você pode querer experimentar.
|
||||
|
||||
### Tarefa: Dar merge em algum código
|
||||
|
||||
Documentos contribuintes ajudam as pessoas a contribuir para o projeto. Ele explica quais tipos de contribuições você está procurando e como funciona o processo. As pessoas colaboradoras precisarão seguir uma série de etapas para poder contribuir com seu repo no GitHub:
|
||||
|
||||
|
||||
1. **Bifurcando seu repo** Você provavelmente vai querer que as pessoas _fork_ seu projeto. Bifurcação significa criar uma réplica de seu repositório em seu perfil GitHub.
|
||||
1. **Clone**. A partir daí, elas clonarão o projeto em sua máquina local.
|
||||
1. **Crie um branch**. Você vai querer pedir a elas que criem um _branch_ para seu trabalho.
|
||||
1. **Concentre sua mudança em uma área**. Peça aos colaboradores para concentrarem suas contribuições em uma coisa de cada vez - dessa forma, as chances de você se _mergir_ no trabalho delas são maiores. Imagine que elas escrevam uma correção de bug, adicionem um novo recurso e atualizem vários testes - e se você quiser ou só puder implementar 2 de 3, ou 1 de 3 alterações?
|
||||
|
||||
✅ Imagine uma situação em que os branches são particularmente críticos para escrever e distribuir bons códigos. Em quais casos de uso você consegue pensar?
|
||||
|
||||
> Nota, seja a mudança que você deseja ver no mundo e crie ramificações para o seu próprio trabalho também. Todos os commits que você fizer serão feitos no branch em que você está atualmente “check-out”. Use `git status` para ver qual branch é.
|
||||
|
||||
Vamos analisar o fluxo de trabalho de uma pessoa colaboradora. Suponha que ela já _forked_ e _cloned_ o repo para que ela tenha um repositório Git pronto para ser trabalhado, em sua máquina local:
|
||||
|
||||
1. **Crie um brancj**. Use o comando `git branch` para criar um branch que conterá as mudanças que pretendem contribuir:
|
||||
|
||||
```bash
|
||||
git branch [branch-name]
|
||||
```
|
||||
|
||||
1. **Mudar para o branch de trabalho**. Mude para o branch especificado e atualize o diretório de trabalho com `git checkout`:
|
||||
|
||||
```bash
|
||||
git checkout [branch-name]
|
||||
```
|
||||
|
||||
1. **Trabalhe**. Neste ponto, você deseja adicionar suas alterações. Não se esqueça de contar ao Git sobre isso com os seguintes comandos:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "minhas mudancas"
|
||||
```
|
||||
|
||||
Certifique-se de dar ao seu commit um bom nome, para seu bem e também para os mantenedores do repo no qual você está ajudando.
|
||||
|
||||
1. **Combine seu trabalho com o branch `main`**. Em algum ponto, você concluiu o trabalho e deseja combinar seu trabalho com o do branch `principal`. O branch `main` pode ter mudado enquanto isso, certifique-se de primeiro atualizá-lo para o mais recente com os seguintes comandos:
|
||||
|
||||
```bash
|
||||
git checkout main
|
||||
git pull
|
||||
```
|
||||
|
||||
Neste ponto, você quer ter certeza de que quaisquer _conflitos_, situações em que o Git não pode _combinar_ facilmente as mudanças aconteçam em seu branch de trabalho. Portanto, execute os seguintes comandos:
|
||||
|
||||
```bash
|
||||
git checkout [branch_name]
|
||||
git merge main
|
||||
```
|
||||
|
||||
Isso trará todas as mudanças de `main` em seu branch e esperançosamente você pode simplesmente continuar. Caso contrário, o VS Code dirá onde o Git está _confundido_ e você apenas alterará os arquivos afetados para dizer qual conteúdo é o mais preciso.
|
||||
|
||||
1. **Envie seu trabalho para o GitHub**. Enviar seu trabalho para o GitHub significa duas coisas. Enviando seu branch para o repo e, em seguida, abra um PR, Pull Request.
|
||||
|
||||
```bash
|
||||
git push --set-upstream origin [branch-name]
|
||||
```
|
||||
|
||||
O comando acima cria o branch em seu repositório bifurcado.
|
||||
|
||||
1. **Abra um PR**. Em seguida, você deseja abrir um PR. Você faz isso navegando até o repositório bifurcado no GitHub. Você verá uma indicação no GitHub onde pergunta se você deseja criar um novo PR, você clica nele e é levado a uma interface onde pode alterar o título da mensagem de commit, dê-lhe uma descrição mais adequada. Agora, a mantenedora do repo que você bifurcou verá este PR e _dedos cruzados_, eles apreciarão e _mergirão_ seu PR. Agora você é uma pessoa contribuidora, eba :)
|
||||
|
||||
1. **Limpeza**. É considerado uma boa prática _limpar_ após mesclar com sucesso um PR. Você deseja limpar seu branch local e o branch que você enviou para o GitHub. Primeiro, vamos excluí-lo localmente com o seguinte comando:
|
||||
|
||||
```bash
|
||||
git branch -d [branch-name]
|
||||
```
|
||||
|
||||
Em seguida, vá para a página GitHub do repositório bifurcado e remova o branch remoto que você acabou de enviar para ele.
|
||||
|
||||
`Pull request` parece um termo bobo porque na verdade você deseja enviar suas alterações para o projeto. Mas a pessoa mantendo o repo ou equipe central precisa considerar suas mudanças antes de fundi-las com o branch "principal" do projeto, então você está realmente solicitando uma decisão de mudança de uma pessoa mantenedora.
|
||||
|
||||
Uma PR é o lugar para comparar e discutir as diferenças introduzidas em um branch com revisões, comentários, testes integrados e muito mais. Uma boa PR segue aproximadamente as mesmas regras de uma mensagem de commit. Você pode adicionar uma referência a um problema no rastreador de problemas, quando seu trabalho, por exemplo, corrige um problema. Isso é feito usando um `#` seguido pelo número do seu problema. Por exemplo `# 97`.
|
||||
|
||||
🤞 Dedos cruzados para que todas as verificações sejam aprovadas e as pessoas proprietárias do projeto deem merge nas suas alterações no projeto🤞
|
||||
|
||||
Atualize seu branch de trabalho local atual com todos os novos commits do branch remoto correspondente no GitHub:
|
||||
|
||||
`git pull`
|
||||
|
||||
## How to contribute to open source
|
||||
|
||||
First, let's find a repository (or **repo**) on GitHub of interest to you and to which you'd like to contribute a change. You will want to copy its contents to your machine.
|
||||
|
||||
✅ A good way to find 'beginner-friendly' repos is to [search by the tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
|
||||
|
||||
|
||||
|
||||
There are several ways of copying code. One way is to "clone" the contents of the repository, using HTTPS, SSH, or using the GitHub CLI (Command Line Interface).
|
||||
|
||||
Open your terminal and clone the repository like so:
|
||||
`git clone https://github.com/ProjectURL`
|
||||
|
||||
To work on the project, switch to the right folder:
|
||||
`cd ProjectURL`
|
||||
|
||||
You can also open the entire project using [Codespaces](https://github.com/features/codespaces), GitHub's embedded code editor / cloud development environment, or [GitHub Desktop](https://desktop.github.com/).
|
||||
|
||||
Lastly, you can download the code in a zipped folder.
|
||||
|
||||
### A few more interesting things about GitHub
|
||||
|
||||
You can star, watch and/or "fork" any public repository on GitHub. You can find your starred repositories in the top-right drop-down menu. It's like bookmarking, but for code.
|
||||
|
||||
Projects have an issue tracker, mostly on GitHub in the "Issues" tab unless indicated otherwise, where people discuss issues related to the project. And the Pull Requests tab is where people discuss and review changes that are in progress.
|
||||
|
||||
Projects might also have discussion in forums, mailing lists, or chat channels like Slack, Discord or IRC.
|
||||
|
||||
✅ Take a look around your new GitHub repo and try a few things, like editing settings, adding information to your repo, and creating a project (like a Kanban board). There's a lot you can do!
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Challenge
|
||||
|
||||
Pair with a friend to work on each other's code. Create a project collaboratively, fork code, create branches, and merge changes.
|
||||
|
||||
## Post-Lecture Quiz
|
||||
[Post-lecture quiz](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/4)
|
||||
|
||||
## Review & Self Study
|
||||
|
||||
Read more about [contributing to open source software](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
|
||||
|
||||
[Git cheatsheet](https://training.github.com/downloads/github-git-cheat-sheet/).
|
||||
|
||||
Practice, practice, practice. GitHub has great learning paths available via [lab.github.com](https://lab.github.com/):
|
||||
|
||||
- [First Week on GitHub](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
|
||||
You'll also find more advanced labs.
|
||||
|
||||
## Assignment
|
||||
|
||||
Complete [the First Week on GitHub training lab](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
@ -0,0 +1,191 @@
|
||||
# Introduction aux langages de programmation et aux outils du métier
|
||||
|
||||
Cette leçon couvre les bases des langages de programmation. Les sujets abordés ici s'appliquent à la plupart des langages de programmation modernes d'aujourd'hui. Dans la section «Outils du métier», vous découvrirez des logiciels utiles qui vous aideront en tant que développeur.
|
||||
|
||||
|
||||
> Sketchnote by [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Pre-Lecture Quiz
|
||||
[Pre-lecture quiz](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/1)
|
||||
|
||||
## introduction
|
||||
|
||||
Dans cette leçon, nous aborderons:
|
||||
|
||||
- Qu'est-ce que la programmation?
|
||||
- Types de langages de programmation
|
||||
- Éléments de base d'un programme
|
||||
- Logiciel et outillage utiles pour le développeur professionnel
|
||||
|
||||
## Qu'est-ce que la programmation?
|
||||
|
||||
Pla programmation (également appelée codage) est le processus d'écriture d'instructions sur un appareil, tel qu'un ordinateur ou un appareil mobile. Nous écrivons ces instructions avec un langage de programmation, qui est ensuite interprété par l'appareil. Ces ensembles d'instructions peuvent être désignés sous différents noms, mais *programme*, *programme informatique*, *application (application)* et *exécutable* sont quelques noms courants.
|
||||
|
||||
Un *programme* peut être tout ce qui est écrit avec du code; les sites Web, les jeux et les applications téléphoniques sont des programmes. Bien qu'il soit possible de créer un programme sans écrire de code, la logique sous-jacente est interprétée sur le périphérique et cette logique a probablement été écrite avec du code. Un programme qui *exécute* ou *exécute du code* exécute des instructions. L'appareil avec lequel vous lisez actuellement cette leçon exécute un programme pour l'imprimer sur votre écran.
|
||||
|
||||
✅ Faites une petite recherche: qui est considéré comme le premier programmeur informatique au monde?
|
||||
|
||||
## Langages de programmation
|
||||
|
||||
Les langages de programmation ont un objectif principal: permettre aux développeurs de créer des instructions à envoyer à un appareil. Les appareils ne peuvent comprendre que le binaire (1 et 0), et pour *la plupart* les développeurs, ce n'est pas un moyen très efficace de communiquer. Les langages de programmation sont un vecteur de communication entre les humains et les ordinateurs.
|
||||
|
||||
Les langages de programmation se présentent sous différents formats et peuvent servir à des fins différentes. Par exemple, JavaScript est principalement utilisé pour les applications Web, tandis que Bash est principalement utilisé pour les systèmes d'exploitation.
|
||||
|
||||
*Les langues de bas niveau* nécessitent généralement moins d'étapes que les *langues de haut niveau* pour qu'un appareil interprète les instructions. Cependant, ce qui rend les langages de haut niveau populaires, c'est leur lisibilité et leur support. JavaScript est considéré comme un langage de haut niveau.
|
||||
|
||||
Le code suivant illustre la différence entre un langage de haut niveau avec JavaScript et un langage de bas niveau avec le code d'assembly ARM.
|
||||
|
||||
```javascript
|
||||
let number = 10
|
||||
let n1 = 0, n2 = 1, nextTerm;
|
||||
|
||||
for (let i = 1; i <= number; i++) {
|
||||
console.log(n1);
|
||||
nextTerm = n1 + n2;
|
||||
n1 = n2;
|
||||
n2 = nextTerm;
|
||||
}
|
||||
```
|
||||
|
||||
```c
|
||||
area ascen,code,readonly
|
||||
entry
|
||||
code32
|
||||
adr r0,thumb+1
|
||||
bx r0
|
||||
code16
|
||||
thumb
|
||||
mov r0,#00
|
||||
sub r0,r0,#01
|
||||
mov r1,#01
|
||||
mov r4,#10
|
||||
ldr r2,=0x40000000
|
||||
back add r0,r1
|
||||
str r0,[r2]
|
||||
add r2,#04
|
||||
mov r3,r0
|
||||
mov r0,r1
|
||||
mov r1,r3
|
||||
sub r4,#01
|
||||
cmp r4,#00
|
||||
bne back
|
||||
end
|
||||
```
|
||||
|
||||
Croyez-le ou non, *they're both doing the same thing*: impression d'une séquence de Fibonacci jusqu'à 10.
|
||||
|
||||
✅ Une séquence de Fibonacci est [defined](https://en.wikipedia.org/wiki/Fibonacci_number) comme un ensemble de nombres tels que chaque nombre est la somme des deux précédents, à partir de 0 et 1.
|
||||
|
||||
## Éléments d'un programme
|
||||
|
||||
Une seule instruction dans un programme est appelée une *instruction* et aura généralement un caractère ou un interligne qui marque où l'instruction se termine, ou *se termine*. La façon dont un programme se termine varie avec chaque langue.
|
||||
|
||||
La plupart des programmes reposent sur l'utilisation des données d'un utilisateur ou d'ailleurs, où les déclarations peuvent s'appuyer sur des données pour exécuter des instructions. Les données peuvent modifier le comportement d'un programme, de sorte que les langages de programmation proposent un moyen de stocker temporairement des données pouvant être utilisées ultérieurement. Ces données sont appelées *variables*. Les variables sont des instructions qui demandent à un appareil d'enregistrer des données dans sa mémoire. Les variables des programmes sont similaires à celles de l'algèbre, où elles ont un nom unique et leur valeur peut changer avec le temps.
|
||||
|
||||
Il est possible que certaines instructions ne soient pas exécutées par un périphérique. C'est généralement par conception lors de l'écriture par le développeur ou par accident lorsqu'une erreur inattendue se produit. Ce type de contrôle d'une application la rend plus robuste et maintenable. Généralement, ces changements de contrôle se produisent lorsque certaines décisions sont respectées. Une instruction courante dans les langages de programmation modernes pour contrôler la manière dont un programme est exécuté est l'instruction `if..else`.
|
||||
|
||||
✅ Vous en apprendrez plus sur ce type d'énoncé dans les leçons suivantes
|
||||
|
||||
## Outils du métier
|
||||
|
||||
[](https://youtube.com/watch?v=69WJeXGBdxg "Tools of the Trade")
|
||||
|
||||
Dans cette section, vous découvrirez certains logiciels que vous pourriez trouver très utiles au début de votre parcours de développement professionnel.
|
||||
|
||||
Un **environnement de développement** est un ensemble unique d'outils et de fonctionnalités qu'un développeur utilisera souvent lors de l'écriture d'un logiciel. Certains de ces outils ont été personnalisés pour les besoins spécifiques d'un développeur et peuvent changer au fil du temps si un développeur change de priorités dans ses projets professionnels ou personnels, ou lorsqu'il utilise un langage de programmation différent. Les environnements de développement sont aussi uniques que les développeurs qui les utilisent.
|
||||
|
||||
### éditeurs
|
||||
|
||||
L'éditeur est l'un des outils les plus cruciaux pour le développement logiciel. Les éditeurs sont l'endroit où vous écrivez votre code et parfois où vous exécuterez votre code.
|
||||
|
||||
Les développeurs comptent sur les éditeurs pour quelques raisons supplémentaires:
|
||||
|
||||
- *Débogage* Découverte des bogues et des erreurs en parcourant le code, ligne par ligne. Certains éditeurs ont des capacités de débogage ou peuvent être personnalisés et ajoutés pour des langages de programmation spécifiques.
|
||||
- *Mise en évidence de la syntaxe* Ajoute des couleurs et la mise en forme du texte au code, le rend plus facile à lire. La plupart des éditeurs permettent une coloration syntaxique personnalisée.
|
||||
- *Extensions et intégrations* Ajouts spécialisés pour les développeurs, par les développeurs, pour accéder à des outils supplémentaires qui ne sont pas intégrés à l'éditeur de base. Par exemple, de nombreux développeurs ont également besoin d'un moyen de documenter leur code et d'expliquer comment il fonctionne et installeront une extension de vérification orthographique pour vérifier les fautes de frappe. La plupart de ces ajouts sont destinés à être utilisés dans un éditeur spécifique, et la plupart des éditeurs proposent un moyen de rechercher les extensions disponibles.
|
||||
- *Personnalisation* La plupart des éditeurs sont extrêmement personnalisables, et chaque développeur aura son propre environnement de développement unique qui répond à ses besoins. Beaucoup permettent également aux développeurs de créer leur propre extension.
|
||||
|
||||
#### Éditeurs et extensions de développement Web populaires
|
||||
|
||||
- [Visual Studio Code](https://code.visualstudio.com/)
|
||||
- [Code Spell Checker](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker)
|
||||
- [Live Share](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare-pack)
|
||||
- [Prettier - Code formatter](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode)
|
||||
- [Atom](https://atom.io/)
|
||||
- [spell-check](https://atom.io/packages/spell-check)
|
||||
- [teletype](https://atom.io/packages/teletype)
|
||||
- [atom-beautify](https://atom.io/packages/atom-beautify)
|
||||
|
||||
### Navigateurs
|
||||
|
||||
Un autre outil crucial est le navigateur. Les développeurs Web comptent sur le navigateur pour observer comment leur code s'exécute sur le Web, il est également utilisé pour afficher les éléments visuels d'une page Web qui sont écrits dans l'éditeur, comme le HTML.
|
||||
|
||||
De nombreux navigateurs sont livrés avec des *outils de développement* (DevTools) qui contiennent un ensemble de fonctionnalités et d'informations utiles pour aider les développeurs à collecter et capturer des informations importantes sur leur application. Par exemple: si une page Web contient des erreurs, il est parfois utile de savoir quand elles se sont produites. DevTools dans un navigateur peut être configuré pour capturer ces informations.
|
||||
#### Navigateurs et outils de développement populaires
|
||||
|
||||
- [Edge](https://docs.microsoft.com/microsoft-edge/devtools-guide-chromium?WT.mc_id=academic-13441-cxa)
|
||||
- [Chrome](https://developers.google.com/web/tools/chrome-devtools/)
|
||||
- [Firefox](https://developer.mozilla.org/docs/Tools)
|
||||
|
||||
### ligne de commande
|
||||
|
||||
Certains développeurs préfèrent une vue moins graphique pour leurs tâches quotidiennes et comptent sur la ligne de commande pour y parvenir. Le développement de code nécessite une quantité importante de saisie, et certains développeurs préfèrent ne pas perturber leur flux sur le clavier et utiliseront des raccourcis clavier pour basculer entre les fenêtres du bureau, travailler sur différents fichiers et utiliser des outils. La plupart des tâches peuvent être effectuées avec une souris, mais un avantage de l'utilisation de la ligne de commande est que beaucoup peut être fait avec des outils de ligne de commande sans avoir besoin de permuter entre la souris et le clavier. Un autre avantage de la ligne de commande est qu'elle est configurable et que vous pouvez enregistrer votre configuration personnalisée, la modifier ultérieurement et également l'importer sur de nouvelles machines de développement. Parce que les environnements de développement sont si uniques à chaque développeur, certains éviteront d'utiliser la ligne de commande, certains s'y fieront entièrement, et certains préfèrent un mélange des deux.
|
||||
|
||||
### Options de ligne de commande populaires
|
||||
|
||||
Les options de la ligne de commande varient en fonction du système d'exploitation que vous utilisez.
|
||||
|
||||
*💻 = est préinstallé sur le système d'exploitation.*
|
||||
|
||||
#### Windows
|
||||
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/overview?view=powershell-7?WT.mc_id=academic-13441-cxa) 💻
|
||||
- [Command Line](https://docs.microsoft.com/windows-server/administration/windows-commands/windows-commands?WT.mc_id=academic-13441-cxa) (also known as CMD) 💻
|
||||
- [Windows Terminal](https://docs.microsoft.com/windows/terminal/?WT.mc_id=academic-13441-cxa)
|
||||
- [mintty](https://mintty.github.io/)
|
||||
|
||||
#### MacOS
|
||||
|
||||
- [Terminal](https://support.apple.com/guide/terminal/open-or-quit-terminal-apd5265185d-f365-44cb-8b09-71a064a42125/mac) 💻
|
||||
- [iTerm](https://iterm2.com/)
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/install/installing-powershell-core-on-macos?view=powershell-7?WT.mc_id=academic-13441-cxa)
|
||||
|
||||
#### Linux
|
||||
|
||||
- [Bash](https://www.gnu.org/software/bash/manual/html_node/index.html) 💻
|
||||
- [KDE Konsole](https://docs.kde.org/trunk5/en/applications/konsole/index.html)
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-7?WT.mc_id=academic-13441-cxa)
|
||||
|
||||
#### Popular Command Line Tools
|
||||
|
||||
- [Git](https://git-scm.com/) (💻 on most operating sytems)
|
||||
- [NPM](https://www.npmjs.com/)
|
||||
- [Yarn](https://classic.yarnpkg.com/en/docs/cli/)
|
||||
|
||||
### Documentation
|
||||
|
||||
Lorsqu'un développeur souhaite apprendre quelque chose de nouveau, il se tournera très probablement vers la documentation pour apprendre à l'utiliser. Les développeurs s'appuient souvent sur la documentation pour les guider dans la manière d'utiliser correctement les outils et les langages, et également pour acquérir une connaissance plus approfondie de son fonctionnement.
|
||||
|
||||
#### Documentation populaire sur le développement Web
|
||||
|
||||
- [Mozilla Developer Network](https://developer.mozilla.org/docs/Web)
|
||||
- [Frontend Masters](https://frontendmasters.com/learn/)
|
||||
|
||||
✅ Faites des recherches: maintenant que vous connaissez les bases de l'environnement d'un développeur Web, comparez-le et comparez-le à l'environnement d'un concepteur Web.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Défi
|
||||
|
||||
Comparez quelques langages de programmation. Quelles sont certaines des caractéristiques uniques de JavaScript par rapport à Java? Et COBOL vs Go?
|
||||
|
||||
## Quiz post-conférence
|
||||
[Quiz post-conférence](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/2)
|
||||
|
||||
## Révision et auto-étude
|
||||
|
||||
Étudiez un peu les différentes langues disponibles pour le programmeur. Essayez d'écrire une ligne dans une langue, puis refaites-la dans deux autres. Qu'apprenez-vous?
|
||||
|
||||
## Affectation
|
||||
|
||||
[Lire la documentation](assignment.fr.md)
|
||||
@ -0,0 +1,192 @@
|
||||
# प्रोग्रामिंग भाषाओं और व्यापार के उपकरण का परिचय
|
||||
|
||||
यह पाठ प्रोग्रामिंग भाषाओं की मूल बातें शामिल करता है। यहां शामिल विषय आज की अधिकांश आधुनिक प्रोग्रामिंग भाषाओं पर लागू होते हैं। 'टूल ऑफ़ ट्रेड' सेक्शन में, आप उपयोगी सॉफ़्टवेयर के बारे में जानेंगे जो आपको डेवलपर के रूप में मदद करता है।
|
||||
|
||||
|
||||
>[टोमोमी इमुरा](https://twitter.com/girlie_mac) द्वारा स्केचनेट
|
||||
|
||||
## पूर्व व्याख्यान प्रश्नोत्तरी
|
||||
[पूर्व व्याख्यान प्रश्नोत्तरी](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/1?loc=hi)
|
||||
|
||||
## परिचय
|
||||
|
||||
इस पाठ में, हम कवर करेंगे:
|
||||
|
||||
- प्रोग्रामिंग क्या है?
|
||||
- प्रोग्रामिंग भाषाओं के प्रकार
|
||||
- एक प्रोग्राम के बुनियादी तत्व
|
||||
- पेशेवर डेवलपर के लिए उपयोगी सॉफ्टवेयर और टूलिंग
|
||||
|
||||
## प्रोग्रामिंग क्या है?
|
||||
|
||||
प्रोग्रामिंग (कोडिंग के रूप में भी जाना जाता है) एक डिवाइस, जैसे कि कंप्यूटर या मोबाइल डिवाइस, को निर्देश लिखने की प्रक्रिया है। हम इन निर्देशों को एक प्रोग्रामिंग भाषा के साथ लिखते हैं, जो तब डिवाइस द्वारा व्याख्या की जाती है। निर्देशों के इन सेटों को विभिन्न नामों से संदर्भित किया जा सकता है, लेकिन *प्रोग्राम*, *कंप्यूटर प्रोग्राम*, *एप्लिकेशन(ऐप)*, और *निष्पादन योग्य* कुछ लोकप्रिय नाम हैं.
|
||||
|
||||
एक *प्रोग्राम* कुछ भी हो सकता है जो कोड के साथ लिखा गया है; वेबसाइट, गेम और फ़ोन ऐप प्रोग्राम हैं। हालांकि, कोड लिखे बिना प्रोग्राम बनाना संभव है, अंतर्निहित तर्क की व्याख्या डिवाइस से की जाती है और उस तर्क को कोड के साथ लिखे जाने की सबसे अधिक संभावना है। एक प्रोग्राम जो *रनिंग* या *एक्जीक्यूटिंग कोड* निर्देश कर रहा है। जिस उपकरण के साथ आप वर्तमान में इस पाठ को पढ़ रहे हैं, वह आपकी स्क्रीन पर प्रिंट करने के लिए एक प्रोग्राम चला रहा है।
|
||||
|
||||
✅ थोड़ा अनुसंधान करें: कौन दुनिया का पहला कंप्यूटर प्रोग्रामर माना जाता है ?
|
||||
|
||||
## प्रोग्रामिंग भाषाएँ
|
||||
|
||||
प्रोग्रामिंग भाषाओं का एक मुख्य उद्देश्य है: डेवलपर्स को डिवाइस पर भेजने के लिए निर्देशों का निर्माण करना। डिवाइस केवल बाइनरी (1s और 0s) को समझ सकते हैं, और *सबसे अधिक* डेवलपर्स के लिए जो संवाद करने का एक बहुत ही कुशल तरीका नहीं है। प्रोग्रामिंग भाषाएं मनुष्य और कंप्यूटर के बीच संचार के लिए एक वाहन हैं।
|
||||
|
||||
प्रोग्रामिंग भाषाएँ विभिन्न स्वरूपों में आती हैं और विभिन्न उद्देश्यों की पूर्ति कर सकती हैं। उदाहरण के लिए, जावास्क्रिप्ट का उपयोग मुख्य रूप से वेब अनुप्रयोगों के लिए किया जाता है, जबकि बैश मुख्य रूप से ऑपरेटिंग सिस्टम के लिए उपयोग किया जाता है।
|
||||
|
||||
*निम्न स्तर की भाषाएं* आमतौर पर निर्देशों की व्याख्या करने के लिए एक उपकरण के लिए * उच्च स्तरीय भाषाओं की तुलना में कम चरणों की आवश्यकता होती है। हालांकि, उच्च स्तरीय भाषाओं को लोकप्रिय बनाने वाली इसकी पठनीयता और समर्थन है। जावास्क्रिप्ट को एक उच्च स्तरीय भाषा माना जाता है.
|
||||
|
||||
निम्न कोड जावास्क्रिप्ट के साथ एक उच्च स्तर की भाषा और एआरएम विधानसभा कोड के साथ निम्न स्तर की भाषा के बीच अंतर को दर्शाता है।
|
||||
|
||||
```javascript
|
||||
let number = 10
|
||||
let n1 = 0, n2 = 1, nextTerm;
|
||||
|
||||
for (let i = 1; i <= number; i++) {
|
||||
console.log(n1);
|
||||
nextTerm = n1 + n2;
|
||||
n1 = n2;
|
||||
n2 = nextTerm;
|
||||
}
|
||||
```
|
||||
|
||||
```c
|
||||
area ascen,code,readonly
|
||||
entry
|
||||
code32
|
||||
adr r0,thumb+1
|
||||
bx r0
|
||||
code16
|
||||
thumb
|
||||
mov r0,#00
|
||||
sub r0,r0,#01
|
||||
mov r1,#01
|
||||
mov r4,#10
|
||||
ldr r2,=0x40000000
|
||||
back add r0,r1
|
||||
str r0,[r2]
|
||||
add r2,#04
|
||||
mov r3,r0
|
||||
mov r0,r1
|
||||
mov r1,r3
|
||||
sub r4,#01
|
||||
cmp r4,#00
|
||||
bne back
|
||||
end
|
||||
```
|
||||
|
||||
मानो या न मानो, *वे दोनों एक ही काम कर रहे हैं*: 10 तक एक फाइबोनैचि अनुक्रम मुद्रित करना।
|
||||
|
||||
✅ एक फाइबोनैचि अनुक्रम को संख्याओं के एक सेट के रूप में [परिभाषित](https://en.wikipedia.org/wiki/Fibonacci_number) किया जाता है जैसे कि प्रत्येक संख्या दो पूर्ववर्ती का योग है, जिसकी शुरुआत 0 और 1 से होती है।
|
||||
|
||||
## एक प्रोग्राम के तत्व
|
||||
|
||||
किसी प्रोग्राम में एक निर्देश को एक *स्टेटमेंट* कहा जाता है और इसमें आमतौर पर एक कैरेक्टर या लाइन स्पेस होता है, जो उन सिरों को चिह्नित करता है, जहां से निर्देश समाप्त होता है, या *टर्मिनेट* होता है। कैसे एक कार्यक्रम समाप्त होता है प्रत्येक भाषा के साथ बदलता रहता है।
|
||||
|
||||
अधिकांश प्रोग्राम उपयोगकर्ता या कहीं और से डेटा का उपयोग करने पर निर्भर करते हैं, जहां कथन निर्देशों को पूरा करने के लिए डेटा पर भरोसा कर सकते हैं। डेटा बदल सकता है कि कोई प्रोग्राम कैसे व्यवहार करता है, इसलिए प्रोग्रामिंग भाषाएँ अस्थायी रूप से डेटा को संग्रहीत करने का एक तरीका है जो बाद में उपयोग किया जा सकता है। इस डेटा को *वैरिएबल* कहा जाता है। चर ऐसे कथन हैं जो किसी डिवाइस को उसकी मेमोरी में डेटा को बचाने का निर्देश देते हैं। कार्यक्रमों में विविधताएं बीजगणित में लोगों के समान हैं, जहां उनका एक अनूठा नाम है और समय के साथ उनका मूल्य बदल सकता है।
|
||||
|
||||
एक मौका है कि कुछ बयानों को डिवाइस द्वारा निष्पादित नहीं किया जाएगा। यह आमतौर पर डिज़ाइनर द्वारा लिखा जाता है जब डेवलपर द्वारा लिखा जाता है या जब कोई अप्रत्याशित त्रुटि होती है तो दुर्घटना से। किसी एप्लिकेशन का इस प्रकार का नियंत्रण उसे अधिक मजबूत और बनाए रखने योग्य बनाता है। आमतौर पर नियंत्रण में ये परिवर्तन तब होते हैं जब कुछ निर्णय मिलते हैं। `if..else` स्टेटमेंट आधुनिक प्रोग्रामिंग भाषाओं में एक सामान्य विवरण यह नियंत्रित करने के लिए कि प्रोग्राम कैसे चलाया जाता है।
|
||||
|
||||
✅ आप बाद के पाठों में इस प्रकार के कथन के बारे में अधिक जानेंगे
|
||||
|
||||
## व्यापार के उपकरण
|
||||
|
||||
[](https://youtube.com/watch?v=69WJeXGBdxg "व्यापार के उपकरण")
|
||||
|
||||
इस अनुभाग में, आप कुछ सॉफ़्टवेयर के बारे में जानेंगे जो आपको अपने व्यावसायिक विकास की यात्रा शुरू करने के दौरान बहुत उपयोगी लग सकते हैं .
|
||||
|
||||
एक **विकास पर्यावरण** उपकरण और सुविधाओं का एक अनूठा सेट है जो एक डेवलपर सॉफ्टवेयर लिखते समय अक्सर उपयोग करेगा। इन उपकरणों में से कुछ को एक डेवलपर विशिष्ट आवश्यकताओं के लिए अनुकूलित किया गया है, और समय के साथ बदल सकता है यदि कोई डेवलपर काम या व्यक्तिगत परियोजनाओं में प्राथमिकताएं बदलता है, या जब वे एक अलग प्रोग्रामिंग भाषा का उपयोग करते हैं। विकास का वातावरण डेवलपर्स के रूप में अद्वितीय है जो उनका उपयोग करते हैं।
|
||||
|
||||
### एडिटर्स
|
||||
|
||||
सॉफ्टवेयर विकास के लिए सबसे महत्वपूर्ण उपकरणों में से एक एडिटर्स है। एडिटर्स वे होते हैं जहाँ आप अपना कोड लिखते हैं और कभी-कभी जहाँ आप अपना कोड चलाते हैं।
|
||||
|
||||
डेवलपर्स कुछ अतिरिक्त कारणों से एडिटर्स पर भरोसा करते हैं:
|
||||
|
||||
- *डिबगिंग* कोड के माध्यम से कदम से, लाइन के द्वारा बग और त्रुटियों की खोज करना। कुछ एडिटर्स में डिबगिंग क्षमताएं होती हैं, या उन्हें विशिष्ट प्रोग्रामिंग भाषाओं के लिए अनुकूलित और जोड़ा जा सकता है।.
|
||||
- *सिंटेक्स हाइलाइटिंग* कोड के लिए रंगों और पाठ स्वरूपण को जोड़ता है, यह पढ़ना आसान बनाता है। अधिकांश एडिटर अनुकूलित सिंटैक्स हाइलाइटिंग की अनुमति देते हैं.
|
||||
- *एक्सटेंशन और एकीकरण* डेवलपर्स के लिए जो अतिरिक्त हैं, डेवलपर्स के लिए, अतिरिक्त टूल तक पहुंच के लिए जो कि आधार एडिटर में निर्मित नहीं हैं। उदाहरण के लिए, कई डेवलपर्स को अपने कोड को दस्तावेज करने और यह समझाने का तरीका भी चाहिए कि यह कैसे काम करता है और टाइपोस की जांच के लिए वर्तनी जांच एक्सटेंशन स्थापित करेगा। इनमें से अधिकांश परिवर्धन एक विशिष्ट एडिटर के भीतर उपयोग के लिए हैं, और अधिकांश एडिटर उपलब्ध एक्सटेंशन की खोज करने का एक तरीका है।
|
||||
- *अनुकूलन* अधिकांश एडिटर अत्यंत अनुकूलन योग्य हैं, और प्रत्येक डेवलपर का अपना विशिष्ट विकास वातावरण होगा जो उनकी आवश्यकताओं के अनुरूप होगा। कई भी डेवलपर्स को अपना विस्तार बनाने की अनुमति देते हैं।
|
||||
|
||||
#### लोकप्रिय एडिटर्स और वेब डेवलपमेंटका एक्सटेंशन
|
||||
|
||||
- [Visual Studio Code](https://code.visualstudio.com/)
|
||||
- [Code Spell Checker](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker)
|
||||
- [Live Share](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare-pack)
|
||||
- [Prettier - Code formatter](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode)
|
||||
- [Atom](https://atom.io/)
|
||||
- [spell-check](https://atom.io/packages/spell-check)
|
||||
- [teletype](https://atom.io/packages/teletype)
|
||||
- [atom-beautify](https://atom.io/packages/atom-beautify)
|
||||
|
||||
### ब्राउज़र्स
|
||||
|
||||
एक अन्य महत्वपूर्ण उपकरण ब्राउज़र है। वेब डेवलपर ब्राउज़र पर भरोसा करते हैं कि यह देखने के लिए कि उनका कोड वेब पर कैसे चलता है, इसका उपयोग वेब पेज के दृश्य तत्वों को देखने के लिए किया जाता है जो एडिटर में लिखे गए हैं, जैसे की HTML।
|
||||
|
||||
कई ब्राउज़र *डेवलपर टूल*(DevTools) के साथ आते हैं, जिसमें डेवलपर्स को अपने एप्लिकेशन के बारे में महत्वपूर्ण अंतर्दृष्टि एकत्र करने और कैप्चर करने में मदद करने के लिए उपयोगी सुविधाओं और जानकारी का एक सेट होता है। उदाहरण के लिए: यदि किसी वेब पेज में त्रुटियां हैं, तो कभी-कभी यह जानना उपयोगी होता है कि वे कब हुए। एक ब्राउज़र में DevTools इस जानकारी को पकड़ने के लिए कॉन्फ़िगर किया जा सकता है।
|
||||
|
||||
#### लोकप्रिय ब्राउज़रों और DevTools
|
||||
|
||||
- [Edge](https://docs.microsoft.com/microsoft-edge/devtools-guide-chromium?WT.mc_id=academic-13441-cxa)
|
||||
- [Chrome](https://developers.google.com/web/tools/chrome-devtools/)
|
||||
- [Firefox](https://developer.mozilla.org/docs/Tools)
|
||||
|
||||
### कमांड लाइन टूल्स
|
||||
|
||||
कुछ डेवलपर्स अपने दैनिक कार्यों के लिए कम ग्राफ़िकल दृश्य पसंद करते हैं और इसे प्राप्त करने के लिए कमांड लाइन पर भरोसा करते हैं। विकासशील कोड के लिए महत्वपूर्ण मात्रा में टाइपिंग की आवश्यकता होती है, और कुछ डेवलपर्स कीबोर्ड पर अपने प्रवाह को बाधित नहीं करना पसंद करते हैं और डेस्कटॉप विंडो के बीच स्वैप करने के लिए कीबोर्ड शॉर्टकट का उपयोग करेंगे, विभिन्न फ़ाइलों पर काम करेंगे, और टूल का उपयोग करेंगे। अधिकांश कार्यों को एक माउस के साथ पूरा किया जा सकता है, लेकिन कमांड लाइन का उपयोग करने का एक लाभ यह है कि माउस और कीबोर्ड के बीच स्वैपिंग की आवश्यकता के बिना कमांड लाइन टूल के साथ बहुत कुछ किया जा सकता है। कमांड लाइन का एक और लाभ यह है कि वे कॉन्फ़िगर करने योग्य हैं और आप अपने कस्टम कॉन्फ़िगरेशन को सहेज सकते हैं, इसे बाद में बदल सकते हैं और इसे नई विकास मशीनों में भी आयात कर सकते हैं। क्योंकि विकास वातावरण प्रत्येक डेवलपर के लिए बहुत अनूठा है, कुछ कमांड लाइन का उपयोग करने से बचेंगे, कुछ इस पर पूरी तरह से भरोसा करेंगे, और कुछ दोनों का मिश्रण पसंद करते हैं।
|
||||
|
||||
### लोकप्रिय कमांड लाइन विकल्प
|
||||
|
||||
आपके द्वारा उपयोग किए जाने वाले ऑपरेटिंग सिस्टम के आधार पर कमांड लाइन के विकल्प अलग-अलग होंगे.
|
||||
|
||||
*💻 = ऑपरेटिंग सिस्टम पर प्रीइंस्टॉल्ड आता है.*
|
||||
|
||||
#### विंडोज
|
||||
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/overview?view=powershell-7?WT.mc_id=academic-13441-cxa) 💻
|
||||
- [Command Line](https://docs.microsoft.com/windows-server/administration/windows-commands/windows-commands?WT.mc_id=academic-13441-cxa) (also known as CMD) 💻
|
||||
- [Windows Terminal](https://docs.microsoft.com/windows/terminal/?WT.mc_id=academic-13441-cxa)
|
||||
- [mintty](https://mintty.github.io/)
|
||||
|
||||
#### मैक ओएस
|
||||
|
||||
- [Terminal](https://support.apple.com/guide/terminal/open-or-quit-terminal-apd5265185d-f365-44cb-8b09-71a064a42125/mac) 💻
|
||||
- [iTerm](https://iterm2.com/)
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/install/installing-powershell-core-on-macos?view=powershell-7?WT.mc_id=academic-13441-cxa)
|
||||
|
||||
#### लिनक्स
|
||||
|
||||
- [Bash](https://www.gnu.org/software/bash/manual/html_node/index.html) 💻
|
||||
- [KDE Konsole](https://docs.kde.org/trunk5/en/applications/konsole/index.html)
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-7?WT.mc_id=academic-13441-cxa)
|
||||
|
||||
#### लोकप्रिय कमांड लाइन टूल्स
|
||||
|
||||
- [Git](https://git-scm.com/) (💻 अधिकांश ऑपरेटिंग साइटम पर)
|
||||
- [NPM](https://www.npmjs.com/)
|
||||
- [Yarn](https://classic.yarnpkg.com/en/docs/cli/)
|
||||
|
||||
### प्रलेखन
|
||||
|
||||
जब कोई डेवलपर कुछ नया सीखना चाहता है, तो वे इसका उपयोग करने के तरीके जानने के लिए प्रलेखन की ओर रुख करेंगे। डेवलपर्स अक्सर टूल और भाषाओं का सही तरीके से उपयोग करने के लिए, और यह भी कि यह कैसे काम करता है के गहन ज्ञान प्राप्त करने के लिए मार्गदर्शन के लिए प्रलेखन पर भरोसा करते हैं।
|
||||
|
||||
#### वेब विकास पर लोकप्रिय प्रलेखन
|
||||
|
||||
- [Mozilla Developer Network](https://developer.mozilla.org/docs/Web)
|
||||
- [Frontend Masters](https://frontendmasters.com/learn/)
|
||||
|
||||
✅ कुछ शोध करें: अब जब आप एक वेब डेवलपर के वातावरण की मूल बातें जानते हैं, तो इसकी तुलना करें और वेब डिजाइनर के वातावरण के साथ इसके विपरीत करें।
|
||||
|
||||
---
|
||||
|
||||
## 🚀 चुनौती
|
||||
|
||||
कुछ प्रोग्रामिंग भाषाओं की तुलना करें। जावास्क्रिप्ट बनाम जावा के कुछ विशिष्ट लक्षण क्या हैं? COBOL बनाम GO के बारे मे?
|
||||
|
||||
## व्याख्यान उपरांत प्रश्नोत्तरी
|
||||
[व्याख्यान उपरांत प्रश्नोत्तरी](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/2?loc=hi)
|
||||
|
||||
## समीक्षा और स्व अध्ययन
|
||||
|
||||
प्रोग्रामर के लिए उपलब्ध विभिन्न भाषाओं पर थोड़ा अध्ययन करें। एक भाषा में एक पंक्ति लिखने का प्रयास करें, और फिर इसे दो अन्य में फिर से लिखें। आप क्या सीखते हैं?
|
||||
|
||||
## असाइनमेंट
|
||||
|
||||
[डॉक्स पढ़ना](assignment.hi.md)
|
||||
@ -0,0 +1,12 @@
|
||||
# Lectura de documentos
|
||||
|
||||
## Instrucciones
|
||||
|
||||
Hay muchas herramientas que un desarrollador web puede necesitar, muchas de ellas se encuentran en la [Documentación de MDN - Herramientas del lado del cliente](https://developer.mozilla.org/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Overview). Seleccionar 3 herramientas que no sean las comentadas en el articulo, explicar por que un Desarrollador Web las debería usar, buscar una herramienta que pertenezca a esta categoria y compartir la documentación. No utilizar los ejemplos de herramientas brindados en la documentación de MDN.
|
||||
|
||||
|
||||
## Rubrica
|
||||
|
||||
Ejemplo | Adecuado | Necesita mejorar
|
||||
--- | --- | -- |
|
||||
| Explicar por qué el Desarrollador web usará la herramienta | Explicar como el desarrollador deberia usar la herramienta| Por qué un desarrollador usaría la herramienta. |
|
||||
@ -0,0 +1,11 @@
|
||||
# Lire la documentation
|
||||
|
||||
## Instructions
|
||||
|
||||
Un développeur Web peut avoir besoin de nombreux outils qui se trouvent sur le [Documentation MDN pour l'outillage côté client](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Overview). Sélectionnez 3 outils non traités dans la leçon, expliquez pourquoi un développeur Web l'utiliserait, recherchez un outil qui relève de cette catégorie et partagez sa documentation. N'utilisez pas le même exemple d'outil sur les documents MDN.
|
||||
|
||||
## Rubrique
|
||||
|
||||
Exemplaire | Adéquat | A besoin d'amélioration
|
||||
--- | --- | -- |
|
||||
| Expliqué pourquoi le développeur Web utiliserait l'outil | Expliqué comment, mais pas pourquoi le développeur utiliserait l'outil | N'a pas mentionné comment ou pourquoi un développeur utiliserait l'outil |
|
||||
@ -0,0 +1,11 @@
|
||||
# De Documenten lezen
|
||||
|
||||
## Instructies
|
||||
|
||||
Er zijn veel tools die een webontwikkelaar nodig heeft en die staan in de [MDN-documentatie voor client-side tooling](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Overview). Selecteer 3 tools die niet in de les worden behandeld, leg uit waarom een webontwikkelaar deze zou gebruiken en zoek naar een tool die onder deze categorie valt en deel de documentatie ervan. Gebruik niet hetzelfde toolvoorbeeld voor MDN-documenten.
|
||||
|
||||
## Rubriek
|
||||
|
||||
Voorbeeldig | Voldoende | Moet Worden Verbeterd
|
||||
--- | --- | -- |
|
||||
|Uitgelegd waarom webontwikkelaar een tool zou gebruiken| Uitgelegd hoe, maar niet waarom de ontwikkelaar de tool zou gebruiken| Niet vermeld hoe of waarom een ontwikkelaar een tool zou gebruiken |
|
||||
@ -0,0 +1,11 @@
|
||||
# Lendo a documentação
|
||||
|
||||
## Instruções
|
||||
|
||||
Existem muitas ferramentas que uma pessoa desenvolvedora de web pode precisar que estão na [documentação MDN para ferramentas do lado do cliente](https://developer.mozilla.org/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Overview). Selecione 3 ferramentas não abordadas na lição, explique por que uma dev Web as usaria, procure uma ferramenta que se enquadre nesta categoria e compartilhe sua documentação. Não use o mesmo exemplo de ferramenta em documentos MDN.
|
||||
|
||||
## Rubrica
|
||||
|
||||
Exemplar | Adequado | Precisa de melhorias
|
||||
--- | --- | - |
|
||||
| Explicado por que uma pessoa desenvolvedora de web usaria a ferramenta | Explicou como, mas não por que uma pessoa desenvolvedora de web usaria a ferramenta | Não mencionou como ou por que uma pessoa desenvolvedora de web usaria a ferramenta |
|
||||
@ -0,0 +1,13 @@
|
||||
# Soma Nyaraka
|
||||
|
||||
## Maagizo
|
||||
|
||||
Msanidi wa wavuti anaweza kuhitaji zana nyingi ambazo zinaweza kupatikana kwenye [Hati ya MDN ya Utengenezaji Upande wa Mteja](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Overview).
|
||||
|
||||
Chagua zana 3 ambazo hazijafunikwa kwenye somo, eleza ni kwanini msanidi wa wavuti atatumia, pata zana ambayo iko kwenye kitengo hiki, na ushiriki nyaraka zake. Usitumie zana sawa ya sampuli kwenye hati za MDN.
|
||||
|
||||
## Kichwa
|
||||
|
||||
| Nakili | Inatosha | Inahitaji kuimarishwa |
|
||||
| ------ | ---------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
|
||||
| Imefafanuliwa kwanini msanidi wa wavuti atatumia zana hiyo | Imefafanuliwa jinsi, lakini sio kwa nini msanidi programu atatumia zana | Haikutaja jinsi au kwa nini msanidi programu atatumia zana |
|
||||
@ -0,0 +1,11 @@
|
||||
# 阅读文档
|
||||
|
||||
## 说明
|
||||
|
||||
[MDN 客户端工具文档](https://developer.mozilla.org/zh-CN/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Overview)中介绍了需要 Web 开发者可能需要用到的工具。从中选取三种本节课中没有提到的工具，并说明为什么 Web 开发者需要用到它们，搜索其中一种工具并给出它的文档。不要直接使用 MDN 中给出的示例。
|
||||
|
||||
## 评价表
|
||||
|
||||
| 优秀 | 良好 | 尚可进步 |
|
||||
| --- | --- | --- |
|
||||
| 解释了 Web 开发者为什么需要这些工具 | 解释了开发者如何使用这些工具，但却没有解释为什么需要它们 | 既没有解释为什么使用这些工具，也没有给出使用它们的方法 |
|
||||
@ -0,0 +1,11 @@
|
||||
# 閱讀技術文件
|
||||
|
||||
## 說明
|
||||
|
||||
網頁開發人員所需要使用的工具套件可以參考 [MDN Client端技術開發文件](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Overview)。 請選擇三種未被本課程提及的工具，試解釋為何網頁開發人員使用它，並搜尋其相關的工具與它的技術文件。這些資料不能出現在前述的 MDN 文件當中。
|
||||
|
||||
## 學習評量
|
||||
|
||||
| 優良 | 普通 | 待改進 |
|
||||
| ------------------------------ | -------------------- | ------------------------------ |
|
||||
| 解釋為何網頁開發人員會用此工具 | 只解釋工具的使用方法 | 未提及工具的使用意義與使用方法 |
|
||||
@ -1,11 +1,15 @@
|
||||
# Analyze a non-accessible web site
|
||||
# Analyze an inaccessible site
|
||||
|
||||
## Instructions
|
||||
|
||||
Identify a web site that you believe is NOT accessible, and create an action plan to improve its accessibility. Your first task would be to identify this site, detail the ways that you think it is inaccessible without using analytic tools, and then put it through a Lighthouse analysis. Take the results of this analysis and outline a detailed plan with a minimum of ten points showing how the site could be improved.
|
||||
Identify a website that you believe is NOT accessible and create an action plan to improve its accessibility.
|
||||
Your first task would be to identify this site, detail the ways in which you think it is inaccessible without using analytical tools, and then submit it to a Lighthouse analysis. Capture a pdf of the results of this analysis and outline a detailed plan with a minimum of ten points showing how the site could be improved.
|
||||
|
||||
## Rubric
|
||||
## Table to test site accessibility
|
||||
|
||||
| Criteria | Exemplary | Adequate | Needs Improvement |
|
||||
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | --------------------------- |
|
||||
| student report | includes paragraphs on how the site is inadequate, the Lighthouse report captured as a pdf, a list of ten points to improve, with details on how to improve it | missing 20% of the required | missing 50% of the required |
|
||||
| Criteria | Exemplary | Adequate | Need to Improve |
|
||||
|----------|-----------|----------|----------------|
|
||||
| | missing <10% of what is required | missing 20% of what is required | missing 50% of what is required |
|
||||
|
||||
----
|
||||
Student Report: includes paragraphs on how inaccessible the site is, the Lighthouse report captured in pdf, a list of ten points to improve, with details on how to improve it
|
||||
|
||||
@ -0,0 +1,227 @@
|
||||
# सुलभ वेबपृष्ठ बनाना
|
||||
|
||||
|
||||
> [टोमोमी इमुरा](https://twitter.com/girlie_mac) द्वारा स्केचनेट
|
||||
|
||||
## पूर्व व्याख्यान प्रश्नोत्तरी
|
||||
[पूर्व व्याख्यान प्रश्नोत्तरी](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/5?loc=hi)
|
||||
|
||||
> वेब की शक्ति अपनी सार्वभौमिकता में है। विकलांगता की परवाह किए बिना सभी तक पहुंच एक आवश्यक पहलू है।
|
||||
>
|
||||
> \- सर टिमोथी बर्नर्स-ली, W3C निदेशक और वर्ल्ड वाइड वेब के आविष्कारक
|
||||
|
||||
यह उद्धरण सुलभ वेबसाइट बनाने के महत्व पर पूरी तरह से प्रकाश डालता है। एक एप्लिकेशन जिसे सभी द्वारा एक्सेस नहीं किया जा सकता है वह परिभाषा बहिष्करण द्वारा है। वेब डेवलपर्स के रूप में हमें हमेशा ध्यान में रखना चाहिए। शुरू से इस पर ध्यान केंद्रित करने से आप अपने तरीके से अच्छी तरह से सुनिश्चित कर पाएंगे कि हर कोई आपके द्वारा बनाए गए पृष्ठों तक पहुंच बना सके। इस पाठ में, आप उन टूल्स के बारे में जानेंगे जो यह सुनिश्चित करने में आपकी मदद कर सकते हैं कि आपकी वेब एसेट्स सुलभ हैं और एक्सेसिबिलिटी को ध्यान में रखते हुए कैसे बनाया जाए।
|
||||
|
||||
## उपयोग करने के उपकरण
|
||||
|
||||
### स्क्रीन रीडर
|
||||
|
||||
सबसे प्रसिद्ध पहुँच उपकरणों में से एक स्क्रीन रीडर हैं।
|
||||
|
||||
[स्क्रीन रीडर](https://en.wikipedia.org/wiki/Screen_reader) आमतौर पर दृष्टि हानि वाले लोगों के लिए उपयोग किए जाते हैं। जैसा कि हम एक ब्राउज़र सुनिश्चित करने में समय बिताते हैं, हम जो जानकारी साझा करना चाहते हैं, उसे ठीक से बता देते हैं, हमें यह भी सुनिश्चित करना चाहिए कि स्क्रीन रीडर भी ऐसा ही करे।
|
||||
|
||||
इसके सबसे मूल में, एक स्क्रीन रीडर ऊपर से नीचे तक एक पृष्ठ को श्रव्य रूप से पढ़ेगा। यदि आपका पृष्ठ सभी पाठ है, तो पाठक एक ब्राउज़र में इसी तरह से जानकारी को बताएगा। बेशक, वेब पेज शायद ही कभी विशुद्ध रूप से टेक्स्ट होते हैं; वे लिंक, ग्राफिक्स, रंग, और अन्य दृश्य घटक शामिल होंगे। यह सुनिश्चित करने के लिए ध्यान रखा जाना चाहिए कि यह जानकारी स्क्रीन रीडर द्वारा सही ढंग से पढ़ी जाए।
|
||||
|
||||
प्रत्येक वेब डेवलपर को स्क्रीन रीडर के साथ खुद को परिचित करना चाहिए। जैसा कि ऊपर प्रकाश डाला गया है, यह वह क्लाइंट है जिसे आपके उपयोगकर्ता उपयोग करेंगे। बहुत कुछ उसी तरह से जिससे आप परिचित हैं कि ब्राउज़र कैसे संचालित होता है, आपको यह सीखना चाहिए कि स्क्रीन रीडर कैसे संचालित होता है। सौभाग्य से, स्क्रीन रीडर अधिकांश ऑपरेटिंग सिस्टम में निर्मित होते हैं।
|
||||
|
||||
कुछ ब्राउज़रों में अंतर्निहित टूल और एक्सटेंशन भी होते हैं, जो टेक्स्ट को जोर से पढ़ सकते हैं या कुछ बुनियादी नौवहन सुविधाएँ भी प्रदान कर सकते हैं, जैसे कि [ये एक्सेसिबिलिटी-केंद्रित एज ब्राउज़र टूल](https://support.microsoft.com/en-us/help/4000734/microsoft-edge-accessibility-features)। ये महत्वपूर्ण एक्सेसिबिलिटी टूल भी हैं, लेकिन स्क्रीन रीडर्स से बहुत अलग तरीके से काम करते हैं और स्क्रीन रीडर टेस्टिंग टूल्स के लिए इनसे गलती नहीं होनी चाहिए।
|
||||
|
||||
✅ स्क्रीन रीडर और ब्राउज़र टेक्स्ट रीडर आज़माएं। विंडोज पर [नैरेटर](https://support.microsoft.com/en-us/windows/complete-guide-to-narrator-e4397a0d-ef4f-b386-d8ae-c17bf109bdb1) डिफ़ॉल्ट रूप से शामिल है, और [JAWS](https://webaim.org/articles/jaws/) और [NVDA](https://www.nvaccess.org/about-nvda/) भी इंस्टॉल किए जा सकते हैं। MacOS और iOS पर, [VoiceOver](https://support.apple.com/guide/voiceover/welcome/10) डिफ़ॉल्ट रूप से स्थापित है।
|
||||
|
||||
### ज़ूम
|
||||
|
||||
आमतौर पर दृष्टि दोष वाले लोगों द्वारा उपयोग किया जाने वाला एक अन्य उपकरण जूमिंग है। जूमिंग का सबसे मूल प्रकार स्थिर ज़ूम है, जिसे 'कंट्रोल + प्लस साइन (+)' या स्क्रीन रिज़ॉल्यूशन कम करके नियंत्रित किया जाता है। इस प्रकार का ज़ूम पूरे पृष्ठ को आकार देने का कारण बनता है, इसलिए एक अच्छा उपयोगकर्ता अनुभव प्रदान करने के लिए [उत्तरदायी डिज़ाइन](https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Responsive_Design) का उपयोग करना महत्वपूर्ण है बढ़े हुए ज़ूम स्तर पर।
|
||||
|
||||
एक अन्य प्रकार का ज़ूम स्क्रीन और पैन के एक क्षेत्र को बढ़ाने के लिए विशेष सॉफ़्टवेयर पर निर्भर करता है, बहुत कुछ वास्तविक आवर्धक कांच का उपयोग करने जैसा। विंडोज पर, [Magnifier](https://support.microsoft.com/en-us/windows/use-magnifier-to-make-things-on-the-screen-easier-to-see-414948ba-8b1bc-d3bd-8615-0e5e32204198) में बनाया गया है और [ZoomText](https://www.freedomscientific.com/training/zoomtext/getting-started/) अधिक सुविधाओं और एक बड़ा उपयोगकर्ता आधार के लिए एक तृतीय-पक्ष आवर्धन सॉफ्टवेयर है। दोनों macOS और iOS में एक अंतर्निहित आवर्धन सॉफ्टवेयर होता है जिसे [ज़ूम](https://www.apple.com/accessibility/mac/vision/) कहा जाता है।
|
||||
### कंट्रास्ट चेकर्स
|
||||
|
||||
कलर-ब्लाइंड यूजर्स या ऐसे लोग जिन्हें कम कंट्रास्ट कलर देखने में दिक्कत होती है, उनकी जरूरतों का जवाब देने के लिए वेब साइट्स पर रंगों को सावधानी से चुना जाना चाहिए।
|
||||
|
||||
✅ ब्राउज़र एक्सटेंशन के साथ रंग उपयोग के लिए उपयोग की जाने वाली वेब साइट का परीक्षण करें, जैसे कि [WCAG का कलर चेकर](https://microsoftedge.microsoft.com/addons/detail/wcag-color-contrast-check/idahaggnlnekelhgplklhfpchbfdmkjp?hl=en-US)। आप क्या सीखते हैं?
|
||||
|
||||
### लाइटहाउस
|
||||
|
||||
अपने ब्राउज़र के डेवलपर टूल क्षेत्र में, आपको लाइटहाउस टूल मिलेगा। वेब साइट की पहुंच (साथ ही अन्य विश्लेषण) का पहला दृश्य प्राप्त करने के लिए यह उपकरण महत्वपूर्ण है। हालांकि यह विशेष रूप से लाइटहाउस पर भरोसा नहीं करना महत्वपूर्ण है, एक आधार रेखा के रूप में 100% स्कोर बहुत मददगार है।
|
||||
|
||||
✅ अपने ब्राउज़र के डेवलपर टूल पैनल में लाइटहाउस ढूंढें और किसी भी साइट पर विश्लेषण चलाएं। आपको क्या मिला ?
|
||||
|
||||
## पहुंच के लिए डिजाइनिंग
|
||||
|
||||
पहुँच एक अपेक्षाकृत बड़ा विषय है। आपकी सहायता करने के लिए, कई संसाधन उपलब्ध हैं।
|
||||
|
||||
- [सुलभ यू - मिनेसोटा विश्वविद्यालय](https://accessibility.umn.edu/your-role/web-wevelopmentation)
|
||||
|
||||
हालांकि हम सुलभ साइटों को बनाने के हर पहलू को कवर नहीं कर पाएंगे, नीचे कुछ मुख्य सिद्धांत हैं जिन्हें आप लागू करना चाहते हैं। प्रारंभ से एक सुलभ पृष्ठ डिजाइन करना **हमेशा** सुलभ है और इसे सुलभ बनाने के लिए मौजूदा पृष्ठ पर वापस जाना आसान है।
|
||||
|
||||
## अच्छे प्रदर्शन के सिद्धांत
|
||||
|
||||
### रंग सुरक्षित पट्टियाँ
|
||||
|
||||
लोग दुनिया को विभिन्न तरीकों से देखते हैं, और इसमें रंग शामिल हैं। अपनी साइट के लिए एक रंग योजना का चयन करते समय, आपको यह सुनिश्चित करना चाहिए कि यह सभी के लिए सुलभ हो। रंग पट्टियाँ बनाने के लिए एक महान [टूल कलर सेफ है](http://colorsafe.co/)।
|
||||
|
||||
✅ एक वेब साइट की पहचान करें जो रंग के उपयोग में बहुत समस्याग्रस्त है। क्यों?
|
||||
|
||||
### सही HTML का उपयोग करें
|
||||
|
||||
सीएसएस और जावास्क्रिप्ट के साथ किसी भी तत्व को किसी भी प्रकार के नियंत्रण की तरह बनाना संभव है। `<span>` का उपयोग एक `<button>` बनाने के लिए किया जा सकता है, और `<b>` हाइपरलिंक बन सकता है। हालांकि यह शैली के लिए आसान माना जा सकता है, यह एक स्क्रीन रीडर के लिए कुछ भी नहीं बताता है। पृष्ठ पर नियंत्रण बनाते समय उपयुक्त HTML का उपयोग करें। यदि आप हाइपरलिंक चाहते हैं, तो `<a>` का उपयोग करें। सही नियंत्रण के लिए सही HTML का उपयोग करना शब्दार्थ HTML का उपयोग करना कहलाता है।
|
||||
|
||||
✅ किसी भी वेब साइट पर जाएं और देखें कि डिजाइनर और डेवलपर HTML का सही उपयोग कर रहे हैं या नहीं। क्या आपको एक बटन मिल सकता है जो एक लिंक होना चाहिए? संकेत: अंतर्निहित कोड देखने के लिए अपने ब्राउज़र में राइट क्लिक करें और 'व्यू पेज सोर्स' चुनें।
|
||||
|
||||
### एक वर्णनात्मक शीर्षक पदानुक्रम बनाएँ
|
||||
|
||||
स्क्रीन रीडर उपयोगकर्ता [शीर्षकों पर बहुत भरोसा करते हैं](https://webaim.org/projects/screenreadersurvey8/#finding) जानकारी खोजने और एक पृष्ठ के माध्यम से नेविगेट करने के लिए। वर्णनात्मक शीर्षक सामग्री लिखना और अर्थ हेडिंग टैग का उपयोग करना स्क्रीन रीडर उपयोगकर्ताओं के लिए आसानी से नेविगेट करने योग्य साइट बनाने के लिए महत्वपूर्ण है।
|
||||
|
||||
### अच्छे दृश्य सुराग का उपयोग करें
|
||||
|
||||
सीएसएस एक पृष्ठ पर किसी भी तत्व के देखो पर पूर्ण नियंत्रण प्रदान करता है। आप बिना किसी आउटलाइन या बिना हाइपरलिंक के टेक्स्ट बॉक्स बना सकते हैं। दुर्भाग्यवश उन सुरागों को हटाना किसी ऐसे व्यक्ति के लिए अधिक चुनौतीपूर्ण हो सकता है जो उन पर निर्भर करता है जो नियंत्रण के प्रकार को पहचानने में सक्षम हो।
|
||||
|
||||
## लिंक टेक्स्ट का महत्व
|
||||
|
||||
हाइपरलिंक्स वेब नेविगेट करने के लिए मुख्य हैं। नतीजतन, स्क्रीन रीडर सुनिश्चित करना लिंक को ठीक से पढ़ सकता है, जिससे सभी उपयोगकर्ता आपकी साइट को नेविगेट कर सकते हैं।
|
||||
|
||||
### स्क्रीन रीडर और लिंक
|
||||
|
||||
जैसा कि आप उम्मीद करेंगे, स्क्रीन रीडर्स लिंक टेक्स्ट को उसी तरह से पढ़ेंगे जैसे वे पृष्ठ पर किसी अन्य टेक्स्ट को पढ़ते हैं। इसे ध्यान में रखते हुए, नीचे प्रदर्शित टेक्स्ट पूरी तरह स्वीकार्य लग सकता है।
|
||||
|
||||
> छोटा पेंगुइन, जिसे कभी-कभी परी पेंगुइन के रूप में जाना जाता है, दुनिया का सबसे छोटा पेंगुइन है। अधिक जानकारी के लिए [यहां क्लिक करें](https://en.wikipedia.org/wiki/Little_penguin)।
|
||||
|
||||
> छोटा पेंगुइन, जिसे कभी-कभी परी पेंगुइन के रूप में जाना जाता है, दुनिया का सबसे छोटा पेंगुइन है। अधिक जानकारी के लिए https://en.wikipedia.org/wiki/Little_penguin पर जाएं।
|
||||
> ** नोट ** जैसा कि आप पढ़ने वाले हैं, आपको ** कभी भी ** लिंक नहीं बनाना चाहिए जो ऊपर की तरह दिखते हों।
|
||||
|
||||
याद रखें, स्क्रीन रीडर एक अलग सेट के साथ ब्राउज़रों से अलग इंटरफ़ेस हैं।
|
||||
|
||||
### URL का उपयोग करने में समस्या
|
||||
|
||||
स्क्रीन रीडर पाठ पढ़ते हैं। यदि टेक्स्ट में URL दिखाई देता है, तो स्क्रीन रीडर URL को पढ़ेगा। सामान्यतया, URL सार्थक जानकारी नहीं देता है, और कष्टप्रद ध्वनि कर सकता है। यदि आपका फ़ोन कभी श्रव्य रूप से URL के साथ टेक्स्ट संदेश पढ़ता है, तो आपको इसका अनुभव हो सकता है।
|
||||
|
||||
### "यहाँ क्लिक करें" के साथ समस्या
|
||||
|
||||
स्क्रीन पाठकों के पास एक पृष्ठ पर केवल हाइपरलिंक पढ़ने की क्षमता होती है, उसी तरह एक दृष्टिहीन व्यक्ति लिंक के लिए एक पेज स्कैन करेगा। यदि लिंक टेक्स्ट हमेशा "यहां क्लिक करें" है, तो सभी उपयोगकर्ता सुनेंगे "यहां क्लिक करें, यहां क्लिक करें, यहां क्लिक करें, यहां क्लिक करें, यहां क्लिक करें ..." सभी लिंक अब एक दूसरे से अप्रभेद्य हैं।
|
||||
|
||||
### अच्छा लिंक टेक्स्ट
|
||||
|
||||
अच्छा लिंक टेक्स्ट संक्षेप में बताता है कि लिंक के दूसरी तरफ क्या है। उपरोक्त उदाहरणों में छोटे पेंगुइन के बारे में बात करते हुए, लिंक प्रजाति के बारे में विकिपीडिया पृष्ठ पर है। वाक्यांश *थोड़ा पेंगुइन* सही लिंक टेक्स्ट के लिए बना देगा क्योंकि यह स्पष्ट करता है कि कोई व्यक्ति इस बारे में सीखेगा कि क्या वे लिंक पर क्लिक करते हैं - छोटे पेंगुइन।
|
||||
|
||||
> [छोटा पेंगुइन](https://en.wikipedia.org/wiki/Little_penguin), जिसे कभी-कभी परी पेंगुइन के रूप में जाना जाता है, दुनिया का सबसे छोटा पेंगुइन है।
|
||||
|
||||
✅ उन पृष्ठों को खोजने के लिए कुछ मिनटों के लिए वेब सर्फ करें जो अस्पष्ट लिंकिंग रणनीतियों का उपयोग करते हैं। अन्य, बेहतर-लिंक्ड साइटों के साथ उनकी तुलना करें। आप क्या सीखते हैं?
|
||||
|
||||
#### खोज इंजन नोट्स
|
||||
|
||||
अपनी साइट को सुनिश्चित करने के लिए एक अतिरिक्त बोनस के रूप में सभी के लिए सुलभ है, आप खोज इंजन को आपकी साइट पर भी नेविगेट करने में मदद करेंगे। खोज इंजन पृष्ठों के विषयों को जानने के लिए लिंक पाठ का उपयोग करते हैं। इसलिए अच्छे लिंक टेक्स्ट का उपयोग करना सभी की मदद करता है!
|
||||
|
||||
### ARIA
|
||||
|
||||
निम्नलिखित पृष्ठ की कल्पना करें:
|
||||
|
||||
| Product | Description | Order |
|
||||
| ------------ | ------------------ | ------------ |
|
||||
| Widget | [Description]('#') | [Order]('#') |
|
||||
| Super widget | [Description]('#') | [Order]('#') |
|
||||
|
||||
इस उदाहरण में, वर्णन और आदेश के पाठ की नकल करना किसी ब्राउज़र का उपयोग करने वाले व्यक्ति के लिए समझ में आता है। हालाँकि, स्क्रीन रीडर का उपयोग करने वाला कोई व्यक्ति केवल संदर्भ के बिना *विवरण* और *आदेश* दोहराता है।
|
||||
|
||||
इस प्रकार के परिदृश्यों का समर्थन करने के लिए, HTML [एक्सेसिबल रिच इंटरनेट एप्लिकेशन (ARIA)](https://developer.mozilla.org/docs/Web/Accessibility/ARIA) नामक विशेषताओं का एक सेट का समर्थन करता है। ये विशेषताएँ आपको स्क्रीन पाठकों को अतिरिक्त जानकारी प्रदान करने की अनुमति देती हैं।
|
||||
|
||||
> ** नोट **: HTML के कई पहलुओं की तरह, ब्राउज़र और स्क्रीन रीडर समर्थन भिन्न हो सकते हैं। हालांकि, अधिकांश मेनलाइन क्लाइंट ARIA विशेषताओं का समर्थन करते हैं।
|
||||
|
||||
जब पृष्ठ का प्रारूप आपको अनुमति नहीं देता है, तो लिंक का वर्णन करने के लिए आप `aria-label` का उपयोग कर सकते हैं। विजेट के लिए विवरण के रूप में सेट किया जा सकता है
|
||||
|
||||
``` html
|
||||
<a href="#" aria-label="Widget description">description</a>
|
||||
```
|
||||
|
||||
✅ सामान्य तौर पर, ऊपर वर्णित शब्दार्थ मार्कअप का उपयोग ARIA के उपयोग को बढ़ा देता है, लेकिन कभी-कभी विभिन्न HTML विजेट के लिए कोई शब्दार्थ समतुल्य नहीं होता है। एक अच्छा उदाहरण एक पेड़ है। एक पेड़ के लिए कोई HTML समतुल्य नहीं है, इसलिए आप इस तत्व के लिए एक उचित भूमिका और aria मान के साथ जेनेरिक `<div>` की पहचान करते हैं। [ARIA पर MDN प्रलेखन](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA) में अधिक उपयोगी जानकारी है।
|
||||
|
||||
```html
|
||||
<h2 id="tree-label">File Viewer</h2>
|
||||
<div role="tree" aria-labelledby="tree-label">
|
||||
<div role="treeitem" aria-expanded="false" tabindex="0">Uploads</div>
|
||||
</div>
|
||||
```
|
||||
|
||||
## इमेजिस
|
||||
|
||||
यह बिना कहे चला जाता है कि स्क्रीन रीडर स्वचालित रूप से पढ़ने में असमर्थ हैं कि एक छवि में क्या है। यह सुनिश्चित करना कि छवियां सुलभ हैं, बहुत काम नहीं करता है - यह वही है जो `alt` गुणकी विशेषता है। सभी सार्थक चित्रों में यह बताने के लिए कि वे क्या हैं, एक `alt` गुण होना चाहिए।
|
||||
छवियां जो विशुद्ध रूप से सजावटी हैं, उनके पास एक खाली स्ट्रिंग के लिए उनके `alt` विशेषता होनी चाहिए:`alt=""`। यह स्क्रीन पाठकों को अनावश्यक रूप से सजावटी छवि की घोषणा करने से रोकता है।
|
||||
|
||||
✅ जैसा कि आप उम्मीद कर सकते हैं, खोज इंजन भी यह समझने में असमर्थ हैं कि एक छवि में क्या है। वे ऑल्ट टेक्स्ट का भी इस्तेमाल करते हैं। तो एक बार फिर, सुनिश्चित करना कि आपका पृष्ठ सुलभ है, अतिरिक्त बोनस प्रदान करता है!
|
||||
|
||||
## थे कीबोर्ड
|
||||
|
||||
कुछ उपयोगकर्ता माउस या ट्रैकपैड का उपयोग करने में असमर्थ हैं, इसके बजाय एक तत्व से दूसरे तक टैब के लिए कीबोर्ड इंटरैक्शन पर निर्भर हैं। आपकी वेब साइट के लिए यह महत्वपूर्ण है कि आप अपनी सामग्री को तार्किक क्रम में प्रस्तुत करें ताकि एक कीबोर्ड उपयोगकर्ता प्रत्येक इंटरैक्टिव तत्व तक पहुँच सके क्योंकि वे एक दस्तावेज़ को स्थानांतरित करते हैं।यदि आप अपने वेब पेजों को सिमेंटिक मार्कअप के साथ बनाते हैं और उनके विज़ुअल लेआउट को स्टाइल करने के लिए CSS का उपयोग करते हैं, तो आपकी साइट कीबोर्ड-नेवीगेबल होनी चाहिए, लेकिन इस पहलू को मैन्युअल रूप से जांचना महत्वपूर्ण है। [कीबोर्ड नेविगेशन रणनीतियों](https://webaim.org/techniques/keyboard/) के बारे में अधिक जानें।
|
||||
|
||||
✅ किसी भी वेब साइट पर जाएं और केवल अपने कीबोर्ड का उपयोग करके इसके माध्यम से नेविगेट करने का प्रयास करें। क्या काम करता है, क्या काम नहीं करता है? क्यों?
|
||||
|
||||
## सारांश
|
||||
|
||||
कुछ के लिए सुलभ वेब वास्तव में 'विश्वव्यापी वेब' नहीं है। आपके द्वारा बनाई जा सकने वाली साइटों को सुनिश्चित करने का सबसे अच्छा तरीका शुरू से ही सुलभता सर्वोत्तम प्रथाओं को शामिल करना है। जबकि अतिरिक्त चरण शामिल हैं, इन कौशल को अपने वर्कफ़्लो में शामिल करने का मतलब होगा कि आपके द्वारा बनाए गए सभी पृष्ठ सुलभ होंगे।
|
||||
|
||||
---
|
||||
|
||||
## 🚀 चुनौती
|
||||
|
||||
इस HTML को ले लो और इसे फिर से संभव के रूप में सुलभ होने के लिए फिर से लिखना, आपके द्वारा सीखी गई रणनीतियों को देखते हुए।
|
||||
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>
|
||||
Example
|
||||
</title>
|
||||
<link href='../assets/style.css' rel='stylesheet' type='text/css'>
|
||||
</head>
|
||||
<body>
|
||||
<div class="site-header">
|
||||
<p class="site-title">Turtle Ipsum</p>
|
||||
<p class="site-subtitle">The World's Premier Turtle Fan Club</p>
|
||||
</div>
|
||||
<div class="main-nav">
|
||||
<p class="nav-header">Resources</p>
|
||||
<div class="nav-list">
|
||||
<p class="nav-item nav-item-bull"><a href="https://www.youtube.com/watch?v=CMNry4PE93Y">"I like turtles"</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtle">Basic Turtle Info</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtles_(chocolate)">Chocolate Turtles</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="main-content">
|
||||
<div>
|
||||
<p class="page-title">Welcome to Turtle Ipsum.
|
||||
<a href="">Click here</a> to learn more.
|
||||
</p>
|
||||
<p class="article-text">
|
||||
Turtle ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="footer">
|
||||
<div class="footer-section">
|
||||
<span class="button">Sign up for turtle news</span>
|
||||
</div><div class="footer-section">
|
||||
<p class="nav-header footer-title">
|
||||
Internal Pages
|
||||
</p>
|
||||
<div class="nav-list">
|
||||
<p class="nav-item nav-item-bull"><a href="../">Index</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="../semantic">Semantic Example</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<p class="footer-copyright">© 2016 Instrument</span>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
## व्याख्यान उपरांत प्रश्नोत्तरी
|
||||
[व्याख्यान उपरांत प्रश्नोत्तरी](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/6?loc=hi)
|
||||
|
||||
## समीक्षा और स्व अध्ययन
|
||||
|
||||
कई सरकारों के पास सुलभता आवश्यकताओं के संबंध में कानून हैं। अपने देश की पहुंच कानूनों पर पढ़ें। क्या शामिल है, और क्या नहीं है? एक उदाहरण है [यह सरकारी वेब साइट](https://accessibility.blog.gov.uk/).
|
||||
|
||||
## असाइनमेंट
|
||||
|
||||
[एक गैर-सुलभ वेब साइट का विश्लेषण करें](assignment.hi.md)
|
||||
|
||||
क्रेडिट: [Turtle Ipsum](https://github.com/Instrument/semantic-html-sample) साधन द्वारा
|
||||
@ -0,0 +1,229 @@
|
||||
# Toegankelijke webpagina's maken
|
||||
|
||||
|
||||
> Sketchnote door [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Quiz voorafgaand aan de lezing
|
||||
[Quiz voorafgaand aan de lezing](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/5)
|
||||
|
||||
> De kracht van het web zit in zijn universaliteit. Toegang voor iedereen, ongeacht hun handicap, is een essentieel aspect.
|
||||
>
|
||||
> \- Sir Timothy Berners-Lee, W3C-directeur en uitvinder van het World Wide Web
|
||||
|
||||
Deze quote benadrukt perfect het belang van het creëren van toegankelijke websites. Een applicatie die niet voor iedereen toegankelijk is, is per definitie uitsluiting. Als webontwikkelaars moeten we altijd rekening houden met toegankelijkheid. Door deze focus vanaf het begin te hebben, bent u goed op weg om ervoor te zorgen dat iedereen toegang heeft tot de pagina's die u maakt. In deze les leert u over de tools die u kunnen helpen ervoor te zorgen dat uw webitems toegankelijk zijn en hoe u kunt bouwen met toegankelijkheid in gedachten.
|
||||
|
||||
## Tools om te gebruiken
|
||||
|
||||
### Schermlezers
|
||||
|
||||
Een van de bekendste toegankelijkheidstools zijn schermlezers.
|
||||
|
||||
[Schermlezers](https://nl.wikipedia.org/wiki/Schermlezer) zijn veelgebruikte clients voor mensen met een visuele beperking. Omdat we er tijd voor besteden om ervoor te zorgen dat een browser de informatie die we willen delen correct overbrengt, moeten we er ook voor zorgen dat een schermlezer hetzelfde doet.
|
||||
|
||||
In de basis leest een schermlezer een pagina hoorbaar van boven naar beneden. Als uw pagina alleen uit tekst bestaat, zal de lezer de informatie op dezelfde manier overbrengen naar een browser. Webpagina's zijn natuurlijk zelden louter tekst; ze bevatten links, afbeeldingen, kleur en andere visuele componenten. Er moet voor worden gezorgd dat deze informatie correct wordt gelezen door een schermlezer.
|
||||
|
||||
Elke webontwikkelaar moet vertrouwd raken met een schermlezer. Zoals hierboven aangegeven, is het de client die uw gebruikers zullen gebruiken. Net zoals u bekend bent met hoe een browser werkt, moet u leren hoe een schermlezer werkt. Gelukkig zijn schermlezers in de meeste besturingssystemen ingebouwd.
|
||||
|
||||
Sommige browsers hebben ook ingebouwde tools en extensies die tekst hardop kunnen voorlezen of zelfs enkele basisnavigatiefuncties bieden, zoals [deze op toegankelijkheid gerichte Edge-browserhulpmiddelen](https://support.microsoft.com/nl-nl/microsoft-edge/toegankelijkheidsfuncties-in-microsoft-edge-4c696192-338e-9465-b2cd-bd9b698ad19a). Dit zijn ook belangrijke toegankelijkheidstools, maar ze werken heel anders dan schermlezers en ze mogen niet worden aangezien voor testtools voor schermlezers.
|
||||
|
||||
✅ Probeer een schermlezer en browsertekstlezer. Op Windows is [Narrator](https://support.microsoft.com/nl-nl/windows/volledige-handleiding-voor-verteller-e4397a0d-ef4f-b386-d8ae-c172f109bdb1) standaard inbegrepen, en [JAWS](https://webaim.org/articles/jaws/) en [NVDA](https://www.nvaccess.org/about-nvda/) kunnen ook worden geïnstalleerd. Op macOS en iOS is [VoiceOver](https://support.apple.com/guide/voiceover/welcome/10) standaard geïnstalleerd.
|
||||
|
||||
### Zoom
|
||||
|
||||
Een ander hulpmiddel dat vaak wordt gebruikt door mensen met een visuele beperking, is zoomen. De meest basale manier van zoomen is statische zoom, bestuurd via `Control + plusteken (+)` of door de schermresolutie te verlagen. Dit type zoom zorgt ervoor dat het formaat van de hele pagina wordt aangepast, dus het gebruik van [responsive design](https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Responsive_Design) is belangrijk om een goede gebruikerservaring te bieden bij verhoogde zoomniveaus.
|
||||
|
||||
Een ander type zoom is afhankelijk van gespecialiseerde software om een deel van het scherm te vergroten en te pannen, net zoals bij het gebruik van een echt vergrootglas. Op Windows is [Magnifier](https://support.microsoft.com/nl-nl/windows/vergrootglas-gebruiken-voor-een-betere-zichtbaarheid-op-het-scherm-414948ba-8b1c-d3bd-8615-0e5e32204198) ingebouwd en [ZoomText](https://www.freedomscientific.com/training/zoomtext/getting-started/) is vergrotingssoftware van derden met meer functies en een groter gebruikersbestand. Zowel macOS als iOS hebben ingebouwde vergrotingssoftware genaamd [Zoom](https://www.apple.com/nl/accessibility/vision/).
|
||||
|
||||
### Contrast checkers
|
||||
|
||||
Kleuren op websites moeten zorgvuldig worden gekozen om tegemoet te komen aan de behoeften van kleurenblinde gebruikers of mensen die moeite hebben met het zien van kleuren met een laag contrast.
|
||||
|
||||
✅ Test een website die u graag gebruikt voor kleurgebruik met een browserextensie zoals [WCAG's color checker](https://microsoftedge.microsoft.com/addons/detail/wcag-color-contrast-check/idahaggnlnekelhgplklhfpchbfdmkjp?hl=en-US). Wat leer je?
|
||||
|
||||
### Lighthouse
|
||||
|
||||
In het ontwikkelaarstoolgedeelte van uw browser vindt u de Lighthouse-tool. Deze tool is belangrijk om een eerste beeld te krijgen van de toegankelijkheid (en ook andere analyses) van een website. Hoewel het belangrijk is om niet uitsluitend op Lighthouse te vertrouwen, is een score van 100% erg nuttig als uitgangspunt.
|
||||
|
||||
✅ Zoek Lighthouse in het ontwikkelaarstoolpaneel van uw browser en voer een analyse uit op elke site. wat ontdek je?
|
||||
|
||||
## Ontwerpen voor toegankelijkheid
|
||||
|
||||
Toegankelijkheid is een relatief groot onderwerp. Om u te helpen, zijn er tal van bronnen beschikbaar.
|
||||
|
||||
- [Accessible U - University of Minnesota](https://accessibility.umn.edu/your-role/web-developers)
|
||||
|
||||
Hoewel we niet elk aspect van het maken van toegankelijke sites kunnen behandelen, staan hieronder enkele van de kernprincipes die u wilt implementeren. Het ontwerpen van een toegankelijke pagina vanaf het begin is **altijd** gemakkelijker dan teruggaan naar een bestaande pagina om deze toegankelijk te maken.
|
||||
|
||||
## Goede weergaveprincipes
|
||||
|
||||
### Kleur veilige paletten
|
||||
|
||||
Mensen zien de wereld op verschillende manieren, inclusief kleuren. Wanneer u een kleurenschema voor uw site selecteert, moet u ervoor zorgen dat het voor iedereen toegankelijk is. Een geweldig [hulpmiddel voor het genereren van kleurenpaletten is Color Safe](http://colorsafe.co/).
|
||||
|
||||
✅ Identificeer een website die erg problematisch is in het gebruik van kleur. Waarom?
|
||||
|
||||
### Gebruik de juiste HTML
|
||||
|
||||
Met CSS en JavaScript is het mogelijk om elk element eruit te laten zien als elk type besturingselement. `<span>` kan worden gebruikt om een `<button>` te maken en `<b>` kan een hyperlink worden. Hoewel dit misschien als gemakkelijker te stylen wordt beschouwd, brengt het niets over op een schermlezer. Gebruik de juiste HTML bij het maken van besturingselementen op een pagina. Als u een hyperlink wilt, gebruik dan `<a>`. Het gebruik van de juiste HTML voor de juiste besturing wordt het gebruik van Semantische HTML genoemd.
|
||||
|
||||
✅ Ga naar een website en kijk of de ontwerpers en ontwikkelaars HTML correct gebruiken. Kunt u een button vinden die een link zou moeten zijn? Tip: klik met de rechtermuisknop en kies 'View Page Source' in uw browser om de onderliggende code te bekijken.
|
||||
|
||||
### Maak een beschrijvende kophiërarchie
|
||||
|
||||
Gebruikers van schermlezers [zijn sterk afhankelijk van koppen](https://webaim.org/projects/screenreadersurvey8/#finding) om informatie te vinden en door een pagina te navigeren. Het schrijven van beschrijvende koptekst en het gebruik van semantische koptags zijn belangrijk voor het maken van een gemakkelijk navigeerbare site voor gebruikers van schermlezers.
|
||||
|
||||
### Gebruik goede visuele aanwijzingen
|
||||
|
||||
CSS biedt volledige controle over het uiterlijk van elk element op een pagina. U kunt tekstvakken zonder omtreklijn of hyperlinks zonder onderstreping maken. Helaas kan het verwijderen van die aanwijzingen het voor iemand die van hen afhankelijk is, uitdagender maken om het type controle te herkennen.
|
||||
|
||||
## Het belang van linktekst
|
||||
|
||||
Hyperlinks zijn essentieel voor het navigeren op internet. Als gevolg hiervan kunnen alle gebruikers door uw site navigeren door ervoor te zorgen dat een schermlezer links correct kan lezen.
|
||||
|
||||
### Schermlezers en links
|
||||
|
||||
Zoals u zou verwachten, lezen schermlezers linktekst op dezelfde manier als andere tekst op de pagina. Met dit in gedachten kan de onderstaande tekst volkomen acceptabel aanvoelen.
|
||||
|
||||
> De Dwergpinguïn, ook wel bekend als de sprookjespinguïn, is de kleinste pinguïn ter wereld. [Klik hier](https://nl.wikipedia.org/wiki/Dwergpingu%C3%AFn) voor meer informatie.
|
||||
|
||||
> De Dwergpinguïn, ook wel bekend als de sprookjespinguïn, is de kleinste pinguïn ter wereld. Bezoek https://nl.wikipedia.org/wiki/Dwergpingu%C3%AFn voor meer informatie.
|
||||
|
||||
> **OPMERKING** Zoals u gaat lezen, moet u **nooit** links maken die er als hierboven uitzien.
|
||||
|
||||
Onthoud dat schermlezers een andere interface zijn dan browsers met een andere set functies.
|
||||
|
||||
### Het probleem met het gebruik van de URL
|
||||
|
||||
Schermlezers lezen de tekst. Als er een URL in de tekst voorkomt, leest de schermlezer de URL. Over het algemeen geeft de URL geen zinvolle informatie over en kan deze vervelend klinken. Mogelijk heeft u dit ondervonden als uw telefoon ooit een sms-bericht met een URL hoorbaar heeft gelezen.
|
||||
|
||||
### Het probleem met "klik hier"
|
||||
|
||||
Schermlezers hebben ook de mogelijkheid om alleen de hyperlinks op een pagina te lezen, net zoals een ziende een pagina zou scannen op links. Als de linktekst altijd "klik hier" is, hoort de gebruiker alleen "klik hier, klik hier, klik hier, klik hier, klik hier, ..." Alle links zijn nu niet meer van elkaar te onderscheiden.
|
||||
|
||||
### Goede linktekst
|
||||
|
||||
Een goede linktekst beschrijft in het kort wat er aan de andere kant van de link staat. In het bovenstaande voorbeeld over Dwergpinguïns, is de link naar de Wikipedia-pagina over de soort. De zin *Dwergpinguïns* zou zorgen voor perfecte linktekst, omdat het duidelijk maakt wat iemand zal leren als ze op de link klikken - Dwergpinguïns.
|
||||
|
||||
> De [Dwergpinguïn](https://nl.wikipedia.org/wiki/Dwergpingu%C3%AFn), ook wel bekend als de sprookjespinguïn, is de kleinste pinguïn ter wereld.
|
||||
|
||||
✅ Surf een paar minuten op internet om pagina's te vinden die obscure koppelingsstrategieën gebruiken. Vergelijk ze met andere, beter gekoppelde sites. Wat leer je?
|
||||
|
||||
#### Aantekeningen bij zoekmachines
|
||||
|
||||
Als extra bonus om ervoor te zorgen dat uw site voor iedereen toegankelijk is, helpt u zoekmachines ook bij het navigeren op uw site. Zoekmachines gebruiken linktekst om de onderwerpen van pagina's te leren. Het gebruik van goede linkteksten helpt dus iedereen!
|
||||
|
||||
### ARIA
|
||||
|
||||
Stelt u de volgende pagina voor:
|
||||
|
||||
| Product | beschrijving | Volgorde |
|
||||
| ------------ | ------------------ | ------------ |
|
||||
| Widget | [beschrijving]('#') | [Volgorde]('#') |
|
||||
| Super widget | [beschrijving]('#') | [Volgorde]('#') |
|
||||
|
||||
In dit voorbeeld is het zinvol om de tekst van de beschrijving en volgorde te dupliceren voor iemand die een browser gebruikt. Iemand die een schermlezer gebruikt, hoort echter alleen de woorden *beschrijving* en *volgorde* herhaald zonder context.
|
||||
|
||||
Om dit soort scenario's te ondersteunen, ondersteunt HTML een set attributen die bekend staan als [Accessible Rich Internet Applications (ARIA)](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA). Met deze attributen kunt u aanvullende informatie verstrekken aan schermlezers.
|
||||
|
||||
> **OPMERKING**: Zoals veel aspecten van HTML, kan de ondersteuning van browser en schermlezer variëren. De meeste mainline-clients ondersteunen echter ARIA-attributen.
|
||||
|
||||
U kunt `aria-label` gebruiken om de link te beschrijven als het formaat van de pagina dat niet toestaat. De beschrijving voor widget kan worden ingesteld als
|
||||
|
||||
``` html
|
||||
<a href="#" aria-label="Widget description">beschrijving</a>
|
||||
```
|
||||
|
||||
✅ Over het algemeen vervangt het gebruik van semantische opmaak zoals hierboven beschreven het gebruik van ARIA, maar soms is er geen semantisch equivalent voor verschillende HTML-widgets. Een goed voorbeeld is een boom. Er is geen HTML-equivalent voor een boomstructuur, dus identificeert u de generieke `<div>` voor dit element met een juiste rol en aria-waarden. De [MDN-documentatie over ARIA](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA) bevat meer nuttige informatie.
|
||||
|
||||
```html
|
||||
<h2 id="tree-label">File Viewer</h2>
|
||||
<div role="tree" aria-labelledby="tree-label">
|
||||
<div role="treeitem" aria-expanded="false" tabindex="0">Uploads</div>
|
||||
</div>
|
||||
```
|
||||
|
||||
## Afbeeldingen
|
||||
|
||||
Het spreekt voor zich dat schermlezers niet automatisch kunnen lezen wat er in een afbeelding staat. Ervoor zorgen dat afbeeldingen toegankelijk zijn, kost niet veel werk - daar gaat het bij het `alt`-attribuut om. Alle betekenisvolle afbeeldingen moeten een `alt` hebben om te beschrijven wat ze zijn.
|
||||
Voor afbeeldingen die puur decoratief zijn, moet het `alt`-attribuut worden ingesteld op een lege tekenreeks: `alt=""`. Hiermee wordt voorkomen dat schermlezers de decoratieve afbeelding onnodig aankondigen.
|
||||
|
||||
✅ Zoals u zou verwachten, kunnen zoekmachines ook niet begrijpen wat er in een afbeelding staat. Ze gebruiken ook alt-tekst. Dus nogmaals, ervoor zorgen dat uw pagina toegankelijk is, levert extra bonussen op!
|
||||
|
||||
## Het toetsenbord
|
||||
|
||||
Sommige gebruikers kunnen geen muis of trackpad gebruiken, maar vertrouwen op toetsenbordinteracties om van het ene element naar het andere te gaan. Het is belangrijk dat uw website uw inhoud in een logische volgorde presenteert, zodat een toetsenbordgebruiker toegang heeft tot elk interactief element terwijl ze door een document bladeren. Als u uw webpagina's bouwt met semantische opmaak en CSS gebruikt om hun visuele lay-out op te maken, moet uw site toetsenbord-navigeerbaar zijn, maar het is belangrijk om dit aspect handmatig te testen. Meer informatie over [strategieën voor toetsenbordnavigatie](https://webaim.org/techniques/keyboard/).
|
||||
|
||||
✅ Ga naar een website en probeer er doorheen te navigeren met alleen uw toetsenbord. Wat werkt, wat werkt niet? Waarom?
|
||||
|
||||
## Overzicht
|
||||
|
||||
Een web dat voor sommigen toegankelijk is, is niet echt een 'world-wide web'. De beste manier om ervoor te zorgen dat de sites die u maakt, toegankelijk zijn, is door vanaf het begin de best practices voor toegankelijkheid op te nemen. Hoewel er extra stappen bij betrokken zijn, betekent het opnemen van deze vaardigheden in uw workflow dat alle pagina's die u maakt, toegankelijk zijn.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Uitdaging
|
||||
|
||||
Neem deze HTML en herschrijf deze zodat deze zo toegankelijk mogelijk is, gezien de strategieën die u hebt geleerd.
|
||||
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>
|
||||
Example
|
||||
</title>
|
||||
<link href='../assets/style.css' rel='stylesheet' type='text/css'>
|
||||
</head>
|
||||
<body>
|
||||
<div class="site-header">
|
||||
<p class="site-title">Turtle Ipsum</p>
|
||||
<p class="site-subtitle">The World's Premier Turtle Fan Club</p>
|
||||
</div>
|
||||
<div class="main-nav">
|
||||
<p class="nav-header">Resources</p>
|
||||
<div class="nav-list">
|
||||
<p class="nav-item nav-item-bull"><a href="https://www.youtube.com/watch?v=CMNry4PE93Y">"I like turtles"</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtle">Basic Turtle Info</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtles_(chocolate)">Chocolate Turtles</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="main-content">
|
||||
<div>
|
||||
<p class="page-title">Welcome to Turtle Ipsum.
|
||||
<a href="">Click here</a> to learn more.
|
||||
</p>
|
||||
<p class="article-text">
|
||||
Turtle ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="footer">
|
||||
<div class="footer-section">
|
||||
<span class="button">Sign up for turtle news</span>
|
||||
</div><div class="footer-section">
|
||||
<p class="nav-header footer-title">
|
||||
Internal Pages
|
||||
</p>
|
||||
<div class="nav-list">
|
||||
<p class="nav-item nav-item-bull"><a href="../">Index</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="../semantic">Semantic Example</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<p class="footer-copyright">© 2016 Instrument</span>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
## Quiz na de lezing
|
||||
[Quiz na de lezing](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/6)
|
||||
|
||||
## Beoordeling en zelfstudie
|
||||
|
||||
Veel regeringen hebben wetten met betrekking tot toegankelijkheidseisen. Lees de toegankelijkheidswetten van uw thuisland. Wat wordt er gedekt en wat niet? Een voorbeeld is [deze overheidswebsite](https://accessibility.blog.gov.uk/).
|
||||
|
||||
## Toewijzing
|
||||
|
||||
[Analyseer een niet-toegankelijke website](assignment.nl.md)
|
||||
|
||||
Credits: [Turtle Ipsum](https://github.com/Instrument/semantic-html-sample) door instrument
|
||||
@ -0,0 +1,228 @@
|
||||
# Criando Webpages Acessíveis
|
||||
|
||||
|
||||
> Sketchnote por [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Quiz Pré-Aula
|
||||
[Pre-lecture quiz](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/5)
|
||||
|
||||
> O poder da Web está em sua universalidade. O acesso de todos, independentemente de deficiências, é um aspecto essencial.
|
||||
>
|
||||
> \- Senhor Timothy Berners-Lee, Diretor da W3C e inventor da World Wide Web
|
||||
|
||||
Esta citação destaca perfeitamente a importância de criar sites acessíveis. Um aplicativo que não pode ser acessado por todos é, por definição, excludente. Como pessoas desenvolvedoras da web, devemos sempre ter a acessibilidade em mente. Tendo esse foco desde o início, você estará no caminho certo para garantir que todos possam acessar as páginas que você cria. Nesta lição, você aprenderá sobre as ferramentas que podem te ajudar a garantir que seus programas da web sejam acessíveis e como construir tendo a acessibilidade em mente.
|
||||
|
||||
## Ferramentas para uso
|
||||
|
||||
### Leitores de Tela
|
||||
|
||||
Uma das ferramentas de acessibilidade mais conhecidas são os leitores de tela.
|
||||
|
||||
[Leitores de Tela](https://pt.wikipedia.org/wiki/Leitor_de_tela) são clientes comumente usados por pessoas com deficiência visual. Como gastamos tempo garantindo que um navegador transmita adequadamente as informações que desejamos compartilhar, também devemos garantir que um leitor de tela faça o mesmo.
|
||||
|
||||
Basicamente, um leitor de tela lê uma página de cima para baixo de forma audível. Se sua página for totalmente de texto, o leitor transmitirá as informações de maneira semelhante a um navegador. Claro, as páginas da web raramente são puramente texto; elas conterão links, gráficos, cores e outros componentes visuais. Deve-se ter cuidado para garantir que essas informações sejam lidas corretamente por um leitor de tela.
|
||||
|
||||
Toda pessoa desenvolvedora da web deve se familiarizar com um leitor de tela. Conforme destacado acima, é o cliente que seus usuários utilizarão. Da mesma forma que você está se familiarizando com o funcionamento de um navegador, deve aprender como funciona um leitor de tela. Felizmente, os leitores de tela são integrados à maioria dos sistemas operacionais.
|
||||
|
||||
Alguns navegadores também possuem ferramentas e extensões integradas que podem ler texto em voz alta ou até mesmo fornecer alguns recursos básicos de navegação, como [essas ferramentas do navegador Edge com foco em acessibilidade](https://support.microsoft.com/help/4000734/microsoft-edge-accessibility-features). Essas também são ferramentas de acessibilidade importantes, mas funcionam de maneira muito diferente dos leitores de tela e não devem ser confundidas com ferramentas de teste de leitores de tela.
|
||||
|
||||
✅ Experimente um leitor de tela e um leitor de texto do navegador. No Windows [Narrator](https://support.microsoft.com/windows/complete-guide-to-narrator-e4397a0d-ef4f-b386-d8ae-c172f109bdb1) é includso por padrão. [JAWS](https://webaim.org/articles/jaws/) e [NVDA](https://www.nvaccess.org/about-nvda/) também podem ser instalados. No macOS e iOS, [VoiceOver](https://support.apple.com/guide/voiceover/welcome/10) vem instalado por padrão.
|
||||
|
||||
### Zoom
|
||||
|
||||
Outra ferramenta normalmente usada por pessoas com deficiência visual é o zoom. O tipo mais básico de zoom é o zoom estático, controlado por `Ctrl + sinal de mais (+)` ou diminuindo a resolução da tela. Este tipo de zoom faz com que a página inteira seja redimensionada, portanto, usar [design responsivo](https://developer.mozilla.org/docs/Learn/CSS/CSS_layout/Responsive_Design) é importante para fornecer uma boa experiência do usuário em níveis de zoom aumentados.
|
||||
|
||||
Outro tipo de zoom depende de um software especializado para ampliar uma área da tela e panoramizar, de maneira muito parecida com o uso de uma lente de aumento real. No Windows, [Magnifier](https://support.microsoft.com/windows/use-magnifier-to-make-things-on-the-screen-easier-to-see-414948ba-8b1c-d3bd-8615-0e5e32204198) vem de fábrica, e o [ZoomText](https://www.freedomscientific.com/training/zoomtext/getting-started/) é um software de ampliação de terceiros com mais recursos e uma base de usuários maior. Tanto o macOS quanto o iOS têm um software de ampliação integrado chamado [Zoom](https://www.apple.com/accessibility/mac/vision/).
|
||||
|
||||
### Verificadores de contraste
|
||||
|
||||
As cores nos sites precisam ser cuidadosamente escolhidas para atender às necessidades de usuários daltônicos ou pessoas que têm dificuldade em ver cores de baixo contraste.
|
||||
|
||||
✅ Teste um site que você goste de usar com uma extensão de navegador para verificar o contraste das cores, como por exemplo o [WCAG's color checker](https://microsoftedge.microsoft.com/addons/detail/wcag-color-contrast-check/idahaggnlnekelhgplklhfpchbfdmkjp?hl=en-US). O que você aprendeu?
|
||||
|
||||
### Lighthouse
|
||||
|
||||
Na área de ferramenta do desenvolvedor do seu navegador, você encontrará a ferramenta Lighthouse. Esta ferramenta é importante para obter uma primeira visão da acessibilidade (bem como outras análises) de um site. Embora seja importante não depender exclusivamente do Lighthouse, uma pontuação de 100% é muito útil como base.
|
||||
|
||||
✅ Encontre o Lighthouse no painel Dev Tools do seu navegador e execute uma análise em qualquer site. o que você descobriu?
|
||||
|
||||
## Criando Designs para acessibilidade
|
||||
|
||||
Acessibilidade é um tópico relativamente amplo. Para te ajudar, existem vários recursos disponíveis.
|
||||
|
||||
- [Accessible U - University of Minnesota](https://accessibility.umn.edu/your-role/web-developers)
|
||||
|
||||
Embora não possamos cobrir todos os aspectos da criação de sites acessíveis, a seguir estão alguns dos princípios básicos que você deseja implementar. Projetar uma página acessível desde o início é **sempre** mais fácil do que voltar a uma página existente para torná-la acessível.
|
||||
|
||||
## Boas práticas de display
|
||||
|
||||
### Paletas de cores seguras
|
||||
|
||||
As pessoas veem o mundo de maneiras diferentes, e isso inclui cores. Ao selecionar um esquema de cores para o seu site, você deve garantir que ele seja acessível a todos. Uma ótima [ferramenta para gerar paletas de cores é Color Safe](http://colorsafe.co/).
|
||||
|
||||
✅ Identifique um site que seja muito problemático no uso de cores. Porque esse site é problemático?
|
||||
|
||||
### Use o HTML correto
|
||||
|
||||
Com CSS e JavaScript é possível fazer com que qualquer elemento se pareça com qualquer tipo de controle. `<span>` poderia ser usado para criar um `<button>`, e `<b>` poderia se tornar um hiperlink. Embora isso possa ser considerado mais fácil de estilizar, não transmite nada para um leitor de tela. Use o HTML apropriado ao criar controles em uma página. Se você quiser um hiperlink, use `<a>`. Usar o HTML certo para o controle certo é chamado de usar HTML semântico.
|
||||
|
||||
✅ Vá a qualquer site e veja se os designers e desenvolvedores estão usando HTML corretamente. Você consegue encontrar um botão que deveria ser um link? Dica: clique com o botão direito e escolha 'Exibir código-fonte da página' em seu navegador para ver o código subjacente.
|
||||
|
||||
### Crie uma hierarquia descritiva de títulos
|
||||
|
||||
Pessoas usuárias de leitores de tela [dependem muito de títulos](https://webaim.org/projects/screenreadersurvey8/#finding) para encontrar informações e navegar por uma página. Escrever conteúdo de título descritivo e usar tags de título semântico são importantes para criar um site facilmente navegável para usuários de leitores de tela.
|
||||
|
||||
### Use boas dicas visuais
|
||||
|
||||
CSS oferece controle completo sobre a aparência de qualquer elemento em uma página. Você pode criar caixas de texto sem contorno ou hiperlinks sem sublinhado. Infelizmente, remover esses sinais pode tornar mais difícil para alguém que depende deles ser capaz de reconhecer o tipo de controle.
|
||||
|
||||
## A importância do texto do link
|
||||
|
||||
Os hiperlinks são essenciais para navegar na web. Como resultado, garantir que um leitor de tela possa ler os links corretamente permite que todos os usuários naveguem em seu site sem problemas.
|
||||
|
||||
### Leitores de tela e links
|
||||
|
||||
Como seria de se esperar, os leitores de tela lêem o texto do link da mesma forma que leriam qualquer outro texto na página. Com isso em mente, o texto demonstrado abaixo pode parecer perfeitamente aceitável.
|
||||
|
||||
> O pequeno pinguim, também conhecido como pinguim fada, é o menor pinguim do mundo. [Clique aqui](https://en.wikipedia.org/wiki/Little_penguin) para mais informações.
|
||||
|
||||
> O pequeno pinguim, também conhecido como pinguim fada, é o menor pinguim do mundo. Visite https://en.wikipedia.org/wiki/Little_penguin para mais informações.
|
||||
|
||||
> **NOTA** Como você está prestes a ler, **nunca** deve-se criar links que se pareçam com o acima.
|
||||
|
||||
Lembre-se de que os leitores de tela são uma interface diferente de navegadores com um conjunto diferente de recursos.
|
||||
|
||||
### O problema de usar o URL
|
||||
|
||||
Leitores de tela leem o texto. Se um URL aparecer no texto, o leitor de tela lerá o URL. De modo geral, a URL não transmite informações significativas e pode parecer irritante. Você pode ter experimentado isso se o seu telefone já leu de forma audível uma mensagem de texto com um URL.
|
||||
|
||||
### O problema com "clique aqui"
|
||||
|
||||
Os leitores de tela também têm a capacidade de ler apenas os hiperlinks em uma página, da mesma forma que uma pessoa com visão examinaria uma página em busca de links. Se o texto do link for sempre "clique aqui", tudo o que o usuário ouvirá é "clique aqui, clique aqui, clique aqui, clique aqui, clique aqui, ..." Todos os links agora são indistinguíveis uns dos outros.
|
||||
|
||||
### Bom texto de link
|
||||
|
||||
Um bom texto de link descreve resumidamente o que está do outro lado do link. No exemplo acima, falando sobre pequenos pinguins, o link é para a página da Wikipedia sobre a espécie. A frase *pequenos pinguins* seria um texto de link perfeito, pois deixa claro o que alguém encontrará se clicar no link - pequenos pinguins.
|
||||
|
||||
> O [pequeno pinguim](https://en.wikipedia.org/wiki/Little_penguin), às vezes conhecido como pinguim fada, é o menor pinguim do mundo.
|
||||
|
||||
✅ Navegue na web por alguns minutos para encontrar páginas que usam estratégias de links obscuras. Compare-os com outros sites com links melhores. O que voce aprende?
|
||||
|
||||
#### Notas sobre Mecanismos de Pesquisa
|
||||
|
||||
Como um bônus adicional por garantir que seu site seja acessível a todes, você também ajudará os mecanismos de pesquisa a navegar em seu site. Os mecanismos de pesquisa usam o texto do link para aprender quais são os tópicos das páginas. Portanto, usar um bom texto de link ajuda a todos!
|
||||
|
||||
### ARIA
|
||||
|
||||
Imagine a seguinte página:
|
||||
|
||||
| Produto | Descrição | Pedido |
|
||||
| ------------ | ------------------ | ------------ |
|
||||
| Widget | [Descrição]('#') | [Pedido]('#') |
|
||||
| Super widget | [Descrição]('#') | [Pedido]('#') |
|
||||
|
||||
Neste exemplo, duplicar o texto de descrição e ordem faz sentido para alguém que usa um navegador. No entanto, alguém usando um leitor de tela ouviria apenas as palavras *descrição* e *pedido* repetidas sem contexto.
|
||||
|
||||
Para oferecer suporte a esses tipos de cenários, o HTML oferece suporte a um conjunto de atributos conhecido como [Accessible Rich Internet Applications (ARIA)](https://developer.mozilla.org/docs/Web/Accessibility/ARIA). Esses atributos permitem fornecer informações adicionais aos leitores de tela.
|
||||
|
||||
> **NOTA**: Como muitos aspectos do HTML, o suporte ao navegador e ao leitor de tela pode variar. No entanto, a maioria dos clientes principais oferece suporte a atributos ARIA.
|
||||
|
||||
Você pode usar `aria-label` para descrever o link quando o formato da página não permitir. A descrição do widget pode ser definida como
|
||||
|
||||
``` html
|
||||
<a href="#" aria-label="descrição do widget">descrição</a>
|
||||
```
|
||||
|
||||
✅ Em geral, o uso da marcação semântica conforme descrito acima substitui o uso de ARIA, mas às vezes não há equivalente semântico para vários widgets HTML. Um bom exemplo é uma Tree. Não há HTML equivalente para uma Tree, então você identifica o `<div>` genérica para este elemento com um papel apropriado e valores de aria. A [documentação MDN sobre ARIA](https://developer.mozilla.org/docs/Web/Accessibility/ARIA) contém mais informações úteis.
|
||||
|
||||
```html
|
||||
<h2 id="tree-label">Visualizador de arquivos</h2>
|
||||
<div role="tree" aria-labelledby="tree-label">
|
||||
<div role="treeitem" aria-expanded="false" tabindex="0">Uploads</div>
|
||||
</div>
|
||||
```
|
||||
|
||||
## Imagens
|
||||
|
||||
Nem é preciso dizer que os leitores de tela não conseguem ler automaticamente o que há em uma imagem. Garantir que as imagens sejam acessíveis não dá muito trabalho - é disso que se trata o atributo `alt`. Todas as imagens significativas devem ter um `alt` para descrever o que são.
|
||||
Imagens que são puramente decorativas devem ter seu atributo `alt` definido como uma string vazia:` alt = "" `. Isso evita que os leitores de tela anunciem desnecessariamente a imagem decorativa.
|
||||
|
||||
✅ Como você pode esperar, os mecanismos de pesquisa também não conseguem entender o que está em uma imagem. Eles também usam texto alternativo. Portanto, mais uma vez, garantir que sua página esteja acessível fornece bônus adicionais!
|
||||
|
||||
## O teclado
|
||||
|
||||
Alguns usuários não conseguem usar um mouse ou trackpad, em vez disso, contam com as interações do teclado para passar de um elemento para o próximo. É importante que o seu site apresente o seu conteúdo em ordem lógica para que um usuário do teclado possa acessar cada elemento interativo à medida que avança em um documento. Se você construir suas páginas da web com marcação semântica e usar CSS para estilizar seu layout visual, seu site deve ser navegável pelo teclado, mas é importante testar esse aspecto manualmente. Aprenda mais sobre [ v](https://webaim.org/techniques/keyboard/).
|
||||
|
||||
✅ Vá a qualquer site da web e tente navegar por ele usando apenas o teclado. O que funciona, o que não funciona? Porque?
|
||||
|
||||
## Resumo
|
||||
|
||||
Uma web acessível a alguns não é uma verdadeira 'rede mundial'. A melhor maneira de garantir que os sites que você cria sejam acessíveis é incorporar as práticas recomendadas de acessibilidade desde o início. Embora haja etapas extras envolvidas, incorporar essas habilidades em seu fluxo de trabalho agora significará que todas as páginas que você criar estarão acessíveis.
|
||||
---
|
||||
|
||||
## 🚀 Desafio
|
||||
|
||||
Pegue este HTML e reescreva-o para ser o mais acessível possível, de acordo com as estratégias que você aprendeu.
|
||||
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>
|
||||
Examplo
|
||||
</title>
|
||||
<link href='../assets/style.css' rel='stylesheet' type='text/css'>
|
||||
</head>
|
||||
<body>
|
||||
<div class="site-header">
|
||||
<p class="site-title">Tartaruga Ipsum</p>
|
||||
<p class="site-subtitle">O Fan Club Premier Mundial de tartarugas</p>
|
||||
</div>
|
||||
<div class="main-nav">
|
||||
<p class="nav-header">Recursos</p>
|
||||
<div class="nav-list">
|
||||
<p class="nav-item nav-item-bull"><a href="https://www.youtube.com/watch?v=CMNry4PE93Y">"Eu gosto de tartarugas"</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtle">Informações básicas sobre tartarugas</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtles_(chocolate)">Tartarugas Chocolate</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="main-content">
|
||||
<div>
|
||||
<p class="page-title">Welcome to Turtle Ipsum.
|
||||
<a href="">Click here</a> to learn more.
|
||||
</p>
|
||||
<p class="article-text">
|
||||
Turtle ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="footer">
|
||||
<div class="footer-section">
|
||||
<span class="button">Sign up for turtle news</span>
|
||||
</div><div class="footer-section">
|
||||
<p class="nav-header footer-title">
|
||||
Internal Pages
|
||||
</p>
|
||||
<div class="nav-list">
|
||||
<p class="nav-item nav-item-bull"><a href="../">Index</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="../semantic">Semantic Example</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<p class="footer-copyright">© 2016 Instrument</span>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
## Quiz Pós-Aula
|
||||
[Quiz Pós-Aula](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/6)
|
||||
|
||||
## Revisão e autoestudo
|
||||
|
||||
Muitos governos têm leis relacionadas aos requisitos de acessibilidade. Leia sobre as leis de acessibilidade do seu país. O que é coberto e o que não é? Um exemplo é [esse site de govermo](https://accessibility.blog.gov.uk/).
|
||||
|
||||
## Lição de casa
|
||||
|
||||
[Analise um site não acessível](assignment.pt.md)
|
||||
|
||||
Créditos: [Turtle Ipsum](https://github.com/Instrument/semantic-html-sample) por Instrument
|
||||
@ -0,0 +1,11 @@
|
||||
# Analyseer een niet-toegankelijke website
|
||||
|
||||
## Instructies
|
||||
|
||||
Identificeer een website waarvan u denkt dat deze NIET toegankelijk is, en maak een actieplan om de toegankelijkheid ervan te verbeteren. Uw eerste taak zou zijn om deze site te identificeren, de manieren te beschrijven waarop u denkt dat deze ontoegankelijk is zonder analytische tools te gebruiken, en deze vervolgens door een Lighthouse-analyse te laten gaan. Neem de resultaten van deze analyse en maak een gedetailleerd plan met minimaal tien punten waaruit blijkt hoe de site kan worden verbeterd.
|
||||
|
||||
## Rubriek
|
||||
|
||||
| Criteria | Voorbeeldig | Voldoende | Moet worden verbeterd |
|
||||
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | --------------------------- |
|
||||
| studentenrapport | bevat paragrafen over hoe de site ontoereikend is, het Lighthouse-rapport vastgelegd als pdf, een lijst met tien punten die verbeterd kunnen worden, met details over hoe deze te verbeteren | ontbreekt 20% van de vereiste | ontbreekt 50% van de vereiste |
|
||||
@ -0,0 +1,13 @@
|
||||
# Analise um site não acessível
|
||||
|
||||
## Instruções
|
||||
|
||||
Identifique um site que você acredita que NÃO está acessível e crie um plano de ação para melhorar sua acessibilidade.
|
||||
Sua primeira tarefa seria identificar este site, detalhar as maneiras pelas quais você acha que ele é inacessível sem o uso de ferramentas analíticas e, em seguida, submetê-lo a uma análise Lighthouse. P
|
||||
egue os resultados desta análise e esboce um plano detalhado com um mínimo de dez pontos mostrando como o site poderia ser melhorado.
|
||||
|
||||
## Rubrica
|
||||
|
||||
| Critérios | Exemplar | Adequado | Precisa Melhorar |
|
||||
| -------------- | -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------- | --------------------------- | --------------------------- |
|
||||
| relatório | inclui parágrafos sobre como o site é inadequado, o relatório Lighthouse capturado em pdf, uma lista de dez pontos a melhorar, com detalhes sobre como melhorá-lo | faltando 20% do exigido | faltando 50% do exigido |
|
||||
@ -0,0 +1,11 @@
|
||||
# 分析一个非无障碍网站
|
||||
|
||||
## 说明
|
||||
|
||||
找到一个你认为无障碍性做得不好的网站，制定一个提升其无障碍性的计划表。你的第一个任务是找到这样一个网站，并在不借助分析工具的前提下详细指出你认为它无障碍做得不好的方面，然后再使用 Lighthouse 分析工具来分析它。借助分析的结果，制定一个包含至少十点的改进该网站的详细计划。
|
||||
|
||||
## 评价表
|
||||
|
||||
| 指标 | 优秀 | 良好 | 尚可进步 |
|
||||
| --- | --- | --- | --- |
|
||||
| 书面报告 | 解释了这个网站做得不好的地方，将 Lighthouse 报告打印为 PDF 文件，至少十点可改进之处，每点详细说明了改进策略 | 缺少上述 20% 内容 | 缺少上述 50% 内容 |
|
||||
@ -0,0 +1,11 @@
|
||||
# 分析一個非無障礙網頁
|
||||
|
||||
## 說明
|
||||
|
||||
辨別一個你認為對視覺障礙者不友善的網頁，列出網頁改進的策略。你需要先發掘各個網頁，不使用分析工具的情況下判斷網頁的親和力，再套用到 Lighthouse 審核工具。將網頁的審核結果轉化成至少十點的改進計畫。
|
||||
|
||||
## 學習評量
|
||||
|
||||
| 作業內容 | 優良 | 普通 | 待改進 |
|
||||
| -------- | ----------------------------------------------------------------------------------- | --------------- | --------------- |
|
||||
| 書面報告 | 文章解釋為何網頁需要被改進，將 Lighthouse 結果轉成 pdf 檔，列出十點詳細的改進計畫。 | 缺少 20% 的內容 | 缺少 50% 的內容 |
|
||||
|
After Width: | Height: | Size: 147 KiB |
|
Before Width: | Height: | Size: 2.0 MiB After Width: | Height: | Size: 2.0 MiB |
|
After Width: | Height: | Size: 1.4 MiB |
|
Before Width: | Height: | Size: 1.6 MiB After Width: | Height: | Size: 1.6 MiB |
|
After Width: | Height: | Size: 1.6 MiB |
|
After Width: | Height: | Size: 1.5 MiB |
|
After Width: | Height: | Size: 1.5 MiB |
|
After Width: | Height: | Size: 1.5 MiB |
|
After Width: | Height: | Size: 1.4 MiB |
|
After Width: | Height: | Size: 1.7 MiB |
|
Before Width: | Height: | Size: 1.9 MiB After Width: | Height: | Size: 1.9 MiB |
Loading…
Reference in new issue