Open Source: Nu este atât de înfricoșător!

Următoarele au fost postate înainte de lansarea Burselor Toptal pentru dezvoltatori feminini.

În calitate de dezvoltator, este interesant și provocator să fii la curent cu cele mai recente tendințe în tehnologie. În fiecare zi, noi limbi, cadre și dispozitive ne captează atenția și stimulează conversațiile în întâlniri, forumuri și chaturi. Cu toate acestea, comunitatea noastră de dezvoltatori este formată din oameni, nu din instrumente, și este fascinant să-i explorezi aspectele sociopolitice (în lipsa unui cuvânt mai bun; „social” tinde să fie asociat cu rețelele sociale, în prezent).

La Toptal, am avut recent câteva conversații interesante despre cât de mult contribuie femeile la open source și ce le poate împiedica să contribuie mai mult, așa că am investigat problema. După ce am făcut parte din acea conversație cu Breanden Beneschott și Bozhidar Batsov, m-am întrebat: Bozhidar este unul dintre cei mai importanți colaboratori open source pe GitHub. Unde sunt? Dacă îmi verificați contul public GitHub de astăzi, este vorba în principal de proiecte de testare mici pe care le-am folosit în clasă pentru studenții mei. Sunt pe jumătate coapte și cu siguranță nu sunt reprezentative pentru abilitățile sau expertiza mea. (Va trebui să mă credeți pe cuvânt în acest sens.) Dacă cineva ar lua în considerare să mă angajeze pe baza a ceea ce poate găsi în acel cont, cred că mi-ar fi greu să-mi câștig existența. Cu toate acestea, sunt un dezvoltator profesionist de mai bine de 20 de ani și, în munca mea de zi cu zi, am folosit mai mult software open source decât îmi doresc să-mi amintesc. De-a lungul timpului, am spart nucleul Linux pentru a-l adapta la o anumită nevoie, am modificat fiecare router și NAS pe care le-am cumpărat, am așteptat cu răbdare luni de zile pe lista de așteptare pentru Raspberry Pi pentru a pune mâna pe el și a-mi obține domotica de casă ca Imi place. Cu toate acestea, niciuna dintre aceste modificări și teste nu a ajuns vreodată la GitHub-ul meu pentru a deveni open source. De asemenea, în afară de remedierea unei erori în una dintre primele versiuni de Tomcat, nu am contribuit niciodată la un proiect open source. Curios, nu-i așa?

Ai putea crede că este doar lipsă de timp sau de interes, dar știu că nu este. În ceea ce privește proiectele mele personale, poate m-am gândit că nimeni nu ar putea fi cu adevărat interesat de ceea ce am făcut, dar în mare parte doar ideea de a-mi publica lucrarea acolo, pentru ca toată lumea să o vadă și pentru posteritate, mă sperie foarte mult. Și, deși poți oricând să distrugi un proiect personal din GitHub, în ​​ziua în care încerci să contribui la un proiect open source disponibil pe scară largă, nu există cale de întoarcere. Ce se întâmplă dacă codul meu nu este suficient de bun? Ce se întâmplă dacă nu am înțeles corect problema? Ce se întâmplă dacă cererea mea de extragere este respinsă? Dacă oamenii mă trollează?

O rundă rapidă de apeluri cu prieteni dezvoltatori, în mare parte femei, m-a convins curând că nu sunt singurul cu această problemă, dar pentru un inginer nu există probleme, ci doar soluții, nu?

Aceasta este o problemă importantă de rezolvat, deoarece contribuția la un proiect open source poate face o diferență dramatică:

• În timpul carierei tale : Mulți clienți se vor uita la toate rețelele sociale înainte de a decide să te angajeze; contul tău GitHub și CV-ul tău LinkedIn sunt în fruntea listei, împreună cu profilurile tale de Facebook și Twitter. Ar trebui să le folosești cu înțelepciune.
• Pentru abilitățile tale tehnice : Examinarea unei baze de cod scrise de alți dezvoltatori, și adesea foarte bune, te învață multe. Abilitatea de a desprinde sensul dintr-o bază de cod scrisă prost vă va provoca și vă va învăța la fel de multe.
• Pentru abilitățile tale : software-ul open source este un proces de colaborare și aproape toate proiectele interesante sunt construite de echipe. A învăța să lucrezi cu alți dezvoltatori prin instrumentele pe care toată lumea le folosește, să te integrezi cu echipa, să comunici eficient este ceea ce te va face un dezvoltator excelent, nu doar unul calificat.
• Pentru comunitate : Fiecare bit cu care contribuiți la un proiect open source contează. Cu cât contribuiți mai mult, cu atât mai bine, dar chiar și repararea unei mici greșeli de tipar într-o traducere va îmbunătăți produsul final.
• Pentru rețeaua dvs .: puteți trimite sute de CV-uri către companii, dar nimic nu funcționează ca să ai colegi cu legături personale. Implicarea activă într-un proiect open source vă va asigura că cunoașteți oameni și le veți câștiga respectul, iar reputația dvs. va crește, ceea ce este de neprețuit pentru orice profesionist.

Aceasta este mica mea călătorie personală în lupta împotriva acestei frici. Publicarea acestui articol face parte din călătoria în sine. O scriu în speranța că oricine este blocat să scrie o postare pe blog, sau se teme să nu aducă nici măcar o mică contribuție, va vedea că până la urmă nu a fost atât de înfricoșător. De asemenea, este menit să ajute pe oricine care ar dori să contribuie la open source, dar nu știe cu adevărat de unde să înceapă, așa că voi începe cu elementele de bază.

Ce este un software cu sursă deschisă și unde îl găsesc?

Software-ul open source, sau pe scurt OSS, este orice software lansat cu codul său sursă și include o licență care vă permite să îl modificați și să îl redistribuiți. Poate fi livrat oriunde: pe un site web, printr-o listă de corespondență sau cu o bufniță. Cel mai obișnuit scenariu, și cel care ne interesează, este atunci când baza de cod este menținută într-un depozit colaborativ. Aici, ne concentrăm pe GitHub, dar există și alte opțiuni, cum ar fi SourceForge și Bitbucket. GitHub este foarte prietenos, are o bază uriașă de utilizatori, poate fi folosit pentru orice fel de cod și cu orice mediu de dezvoltare pe care îl utilizați. Important este că este utilizat pe scară largă pentru proiecte non-open source. Sunt șanse ca următorul tău proiect client să fie găzduit acolo, așa că a ști cum să lucrezi cu el este o abilitate utilă în sine.

Ce se întâmplă dacă nu știu cum să codific?

Dacă citiți asta, este posibil să doriți să învățați cum să codificați. Puteți găsi cursuri uimitoare pe mai multe site-uri web gratuite și plătite. Ar trebui să alegeți o limbă de învățat; dacă nu aveți o preferință, mergeți cu JavaScript. Aveți deja tot ce aveți nevoie pentru a începe în browserul dvs. web și este una dintre cele mai utilizate și mai comercializate abilități. Preferatul meu personal este Python, care este folosit atât în ​​dezvoltarea web, cât și în aplicații științifice. De asemenea, am un curs preferat pentru începători, „Introducere în informatică” pe Udacity. Îmi place pentru că este un curs practic, în care lucrezi la un proiect pe măsură ce înveți. De asemenea, puteți găsi alte câteva cursuri pe Coursera, Khan Academy și PluralSight.

Ce se întâmplă dacă nu știu Git?

După cum am menționat anterior, cunoașterea Git este importantă, așa că, luați o clasă Git. Fă-o chiar dacă ai lucrat cu Git de ceva vreme; nu știi cât de mult nu știi despre Git până nu îl studiezi cu adevărat. Faceți-o dacă nu puteți explica cu încredere ce face comanda rebase . Fă-o chiar dacă o rebase greșită nu te sperie. Am urmat calea completă Git pe Code School, dar din nou, puteți explora alte site-uri pentru mai multe opțiuni.

Cum aleg un proiect pe GitHub?

Este probabil să utilizați ceva OSS în dezvoltarea dvs. de zi cu zi. Alegerea unui cadru familiar este un bun punct de plecare; sunteți deja familiarizat cu caracteristicile și cum funcționează cadrul. Când vă scufundați în codul sursă, veți afla mai multe și îi veți înțelege și mai clar logica. Dacă există o tehnologie sau un instrument care vă place în mod deosebit, căutați proiecte care o menționează sau proiectul instrumentului în sine. În ultimă instanță, puteți verifica proiectele pe GitHub Showcases și începe prin a alege o categorie care vă interesează.

De exemplu, o căutare rapidă pentru „Raspberry” în căutarea GitHub arată mai mult de 17 mii de depozite. Este ușor să te pierzi, așa că caută un proiect cu o comunitate bună și o bună urmărire a problemelor. Atunci când alegeți un proiect, verificați numărul de:

• Colaboratori : vizați orice lucru de peste zece colaboratori. Acest lucru ar trebui să asigure că proiectul are suficient interes și nu este doar un mic efort de echipă. Dacă sunteți nou în OSS sau nu sunteți prea priceput, limitați-vă căutarea la proiecte cu cel mult cincizeci de colaboratori; comunități mai mari implică baze de cod mai mari și proiecte mai complicate.
• Commit -uri : alegeți proiecte care au cel puțin o mie de commit-uri și în care cea mai recentă activitate nu are mai mult de o săptămână. Un proiect care a fost inactiv de o lună sau mai mult este vechi și învechit în termeni OSS și probabil că nu veți primi răspunsuri rapid. Activitatea zilnică este semnul unui proiect sănătos.
• Probleme : problemele sunt probleme deschise, erori care au fost raportate sau caracteristici solicitate de implementat. Vă vor oferi un punct de plecare și sunt o măsură bună a interesului față de proiect.

De asemenea, aflați care este limbajul principal al proiectului; puteți vedea statisticile lingvistice în bara de sus a paginii principale a proiectului. Acordați-vă timp pentru a citi tonul discuției, vedeți cât de prietenoase și educate sunt comentariile. Unele proiecte sunt infame pentru comunitățile lor agresive, așa că s-ar putea să nu fie punctul de plecare potrivit.

Am ales ScyllaDB, un proiect de stocare a datelor în coloană, deoarece am o fascinație pentru date - orice este legat de performanță. Nu am lucrat niciodată cu el, dar mă aștept să mă pot scufunda în baza de cod. Poate fi mai simplu să lucrezi cu instrumente pe care le cunosc, dar iau asta ca pe o provocare și o ocazie de a învăța ceva nou. În rest, se potrivește perfect cu factura; are 18 colaboratori, 6.5k commit (cel mai recent a fost acum 23 de ore la momentul scrierii), 178 de probleme deschise și pare activ.

Ce fac acum?

Mai întâi, clonează depozitul și instalează software-ul pe mașina dvs. pentru a vă face o idee despre părțile sale mobile. Apoi, începeți să citiți problemele. Odată ce vă simțiți pregătit, vedeți dacă puteți reproduce problema pe computer și apoi începeți să analizați ceea ce face ca software-ul să se comporte prost.

O altă abordare ar fi să găsiți ceva pe care să îl puteți îmbunătăți sau modifica singur. Poate ați observat o greșeală de scriere sau un font nealiniat, de exemplu. Am ales să repar un mic bug, în special un nume greșit de variabilă folosit în documentația unui script.

Pare mică, dar documentarea greșită este mult mai rea decât lipsa documentării. Utilizatorii vor instala ScyllaDB și vor urma pașii de instalare, se vor baza orbește pe ceea ce este scris în acel script și vor ajunge în mormane de frustrare. Acest lucru a fost perfect pentru abilitățile mele, iar remedierea lui va necesita să urmăresc întregul proces și să mă familiarizez puțin cu baza de cod. Remedierea erorilor este plictisitoare, dar este un început excelent pentru a vă găsi drumul într-un proiect.

Crearea unei furculițe

Acest lucru poate fi banal, dar în acest moment, pentru proiectul ScyllaDB, sunt doamna Nimeni; ar fi riscant să-mi permit să fac modificări codului lor fără supraveghere. Ceea ce trebuie să fac este să creez o „furcătură” în propriul meu cont GitHub. Aici este furca mea ScyllaDB. Este propriul meu loc de joacă unde am acces la tot codul și pot modifica fișierele după cum doresc. Dacă aș vrea să îmi creez propria versiune de ScyllaDB și să o modific pentru a face ceva complet diferit de scopul său inițial, aș putea face acest lucru aici. Crearea unei furculițe este simplă; accesați pagina principală a proiectului și faceți clic pe butonul „furcătură”. Deloc înfricoșător.

Este timpul să remediați eroarea

Acum, este timpul să testați codul pe computer și să faceți modificările necesare. În primul rând, asigurați-vă că ați instalat clientul Git pe mașina dvs. Apoi, adăugați cheia dvs. publică SSH în GitHub și asigurați-vă că este încărcată de agentul dvs. ssh. Obținerea codului local este simplă; Folosiți doar comanda git clone care indică către furca, în loc de ramura principală:

 git clone [email protected]:acbellini/scylla.git

Până acum, ar fi trebuit să testați proiectul pe ramura principală, așa că veți construi codul local și îl veți testa în același mod. Țineți minte că va trebui să fork orice alte proiecte GitHub pe care se bazează proiectul dvs., deoarece referințele sunt relative. În cazul meu, a trebuit să bifurcăm seastar, scylla-ami și scylla-swagger-ui.

Bug-ul pe care trebuie să îl repar este relativ simplu; documentația din conf/scylla.yaml menționează trei directoare configurabile: unul pentru fișierele de date, unul pentru jurnalele de comitere și unul, aparent neutilizat, pentru cache-uri, toate fiind implicit la un subdirector al $CASSANDRA_HOME :

Scufundându-vă în cod, arată că valorile implicite sunt diferite și, așa cum se menționează în problema #372 de la care am pornit, $CASSANDRA_HOME nu ar trebui să fie folosit. Îmi validez ipoteza testând codul cu câteva setări diferite, eliminând setarea din fișierul de configurare și verificând ce directoare sunt utilizate. Odată suficient de sigur că totul este corect, pot adăuga, comite și împinge fișierul modificat:

 git add conf/scylla.yaml git commit -m 'Correct default directories values in conf/scylla.yaml #372' git push

Rețineți că am introdus numărul problemei precedat de un hash în mesajul de confirmare. Acest lucru va spune lui GitHub să conecteze automat codul meu la problema în sine.

Un alt lucru important de remarcat este că, când am cercetat codul, mi-am dat seama că al treilea director, cel pentru cache, nu este de fapt folosit. Este tentant să faceți un pas prea departe și să eliminați această setare în sine sau să adăugați un comentariu care nu este folosit, dar care ar fi în afara domeniului de aplicare al problemei #372 și ar fi greșit să comiteți ceva care nu este strict legat de aceasta problema. Trebuie să vă mențineți schimbările concentrate și limitate la sarcina în cauză.

În acest moment, codul este fix și este pe GitHub, în ​​fork-ul meu privat. Aici intervine partea înfricoșătoare: a le cere oamenilor ScyllaDB să accepte codul meu. Aceasta se numește cerere de tragere.

Pasul final: cererea de tragere

Îmi place să creez cereri de extragere direct din interfața web de pe GitHub. Mi se pare mai intuitiv și mai rezistent la erori decât încercarea de a o face din linia de comandă. Tot ce trebuie să fac pentru a-mi crea cererea de extragere este să dau clic pe micul buton verde de lângă numele sucursalei mele:

Rețineți că comentariul a fost calculat automat de GitHub. Ramura mea are acum un nou commit, dar de când mi-am creat fork-ul, există încă 14 commit-uri în depozitul principal, așa că voi face clic pe pictograma verde din stânga.

Din fericire, singurul meu commit nu intră în conflict cu celelalte 14, așa că GitHub mă informează că sunt gata de plecare. Nu trebuie să adaug niciun alt comentariu sau mesaj. Mesajul de confirmare, deși este foarte scurt, spune totul: Ce face schimbarea codului meu și cu ce are legătură. În timp ce dau clic pe ultimul buton pentru a-mi confirma cererea, mă întreb ce mi s-a părut atât de înfricoșător acum câteva zile. Nu există niciun monstru care răcnește spre mine în acest moment și flăcările iadului nu par să ardă. Sincer, nu a fost deloc înfricoșător. În cazul puțin probabil că am greșit, soluția mea nu va fi acceptată și asta va fi tot.

Dacă verificați acum detaliile problemei, puteți vedea că GitHub a adăugat automat o notă că există o cerere de extragere care face referire la această problemă. Aceasta este magia acelui #372 din mesajul de confirmare. Acest lucru va ajuta la evitarea ca alți oameni să piardă timpul pentru a repara ceva care a fost deja reparat.

Note finale

Acum aștept ca cererea mea de extragere să fie acceptată, voi primi o notificare când se va întâmpla asta. Rețineți că acest lucru poate dura câteva zile, chiar săptămâni; cineva trebuie să-mi revizuiască codul, să testeze că funcționează așa cum este descris, să remedieze problema și, în cele din urmă, să se asigure că nu afectează negativ funcționalitatea restului codului (citiți: creează noi erori). Toate acestea necesită timp cuiva, așa că ai răbdare. În cele din urmă, când cererea mea de extragere va fi acceptată, ScyllaDB va avea încă un contributor, o problemă mai puțin și voi avea prima mea contribuție OSS. Acum, este timpul să încerci și tu. La urma urmei, nu este deloc înfricoșător.