Seuraava oli lähetetty ennen ApeeScape-apurahat naiskehittäjille .

Kehittäjänä on jännittävää ja haastavaa pysyä ajan tasalla tekniikan uusimpien suuntausten kanssa. Joka päivä uudet kielet, kehykset ja laitteet kiinnittävät huomiomme ja kannustavat keskusteluja tapaamisissa, foorumeissa ja keskusteluissa. Kehittäjäyhteisömme koostuu kuitenkin ihmisistä, ei työkaluista, ja on kiehtovaa tutkia sen sosiopoliittisia näkökohtia (paremmasta sanasta puuttuessa; 'sosiaalinen' liittyy yleensä sosiaalisiin verkostoihin nykyään).

ApeeScapella käytiin äskettäin mielenkiintoisia keskusteluja siitä, kuinka paljon naiset osallistuvat avoimeen lähdekoodiin ja mikä saattaa estää heitä osallistumasta enemmän, joten olemme tutkinut asiaa . Osallistuessani keskusteluun Breanden Beneschottin ja Bozhidar Batsovin kanssa ihmettelin: Bozhidar on yksi GitHubin suurimmista avoimen lähdekoodin kirjoittajista. Missä minä olen? Jos tarkistat yleisöni GitHub-tili tästä päivästä lähtien lähinnä pieniä testiprojekteja käytin luokassa oppilailleni. Ne ovat puolivalmiita eivätkä ehdottomasti edusta taitojani tai asiantuntemustani. (Sinun on otettava sanani tästä.) Jos joku harkitsisi palkkaamistani sen perusteella, mitä hän voi löytää tältä tililtä, ​​minulla olisi kai vaikea ansaita elantoni. Silti olen ollut ammattimainen kehittäjä yli 20 vuotta, ja jokapäiväisessä työssäni olen käyttänyt enemmän avoimen lähdekoodin ohjelmistoja kuin mitä haluan muistaa. Ajan myötä olen hakkeroinut Linux-ytimen taivuttamaan sen johonkin tiettyyn tarpeeseen, säätän jokaisen ostamani reitittimen ja NAS: n, odotin kärsivällisesti kuukausia Raspberry Pi -luettelossa saadaksesi käteni siihen ja saamaan kotitekoinen domotiikka kuten pidän siitä. Silti mikään näistä muutoksista ja testeistä ei koskaan päässyt GitHubiin avoimen lähdekoodin käyttöön. Lisäksi virheen korjaamisesta yhdessä Tomcatin ensimmäisistä versioista en ole koskaan osallistunut avoimen lähdekoodin projektiin. Utelias, eikö olekin?

Voisit ajatella, että se on vain ajan tai kiinnostuksen puutetta, mutta tiedän, että ei ole. Henkilökohtaisten projektieni osalta olen saattanut ajatella, ettei kukaan voi todella olla kiinnostunut tekemistään, mutta enimmäkseen pelkkä ajatus julkaista työni siellä, kaikkien nähtäväksi ja jälkipolvien kannalta. Ja vaikka voit aina repiä henkilökohtaisen projektin GitHubilta, sinä päivänä, kun yrität osallistua laajasti saatavilla olevaan avoimen lähdekoodin projektiin, ei ole paluuta. Entä jos koodini ei ole tarpeeksi hyvä? Entä jos en ymmärtänyt ongelmaa oikein? Entä jos vetopyyntöni hylätään? Entä jos ihmiset peikkoavat minua?

Pelottako avoimen lähdekoodin julkaisu? Tweet

Nopea soittokierros kaverikehittäjien, lähinnä naisten, kanssa vakuutti pian minut, etten ole ainoa, jolla on tämä ongelma, mutta insinöörille ei ole ongelmia, vain ratkaisuja, eikö?

Tämä on tärkeä ratkaistava ongelma, koska osallistuminen avoimen lähdekoodin projektiin voi tehdä dramaattisen muutoksen:

• Urasi aikana : Monet asiakkaat tarkastelee sosiaalista kaikkea ennen kuin päätät palkata sinut; GitHub-tilisi ja LinkedIn-ansioluettelosi ovat listan kärjessä yhdessä Facebook- ja Twitter-profiiliesi kanssa. Sinun tulisi käyttää niitä viisaasti.
• Teknisille taidoillesi : Muiden ja usein erittäin hyvien kehittäjien kirjoittaman koodikannan tutkiminen opettaa sinulle paljon. Kyky purkaa merkitys huonosti kirjoitetusta koodikannasta haastaa ja opettaa sinulle yhtä paljon.
• Pehmeistä taidoistasi : Avoimen lähdekoodin ohjelmisto on yhteistyöprosessi, ja melkein kaikki mielenkiintoiset projektit ovat tiimien rakentamia. Oppiminen työskentelemään muiden kehittäjien kanssa kaikkien käyttämillä työkaluilla, sulautumaan tiimiin, kommunikoimaan tehokkaasti, tekee sinusta suuren kehittäjän, ei vain ammattitaitoisen.
• Yhteisölle : Jokainen avoimen lähdekoodin projektiin tekemäsi bitti laskee. Mitä enemmän osallistut, sitä parempi, mutta jopa yhden pienen kirjoitusvirheen korjaaminen käännöksessä tekee lopputuotteesta paremman.
• Verkkoasi varten : Voit lähettää satoja ansioluetteloita yrityksille, mutta mikään ei toimi niin kuin sinulla olisi kollegoja, joilla on henkilökohtaisia ​​yhteyksiä. Aktiivinen osallistuminen avoimen lähdekoodin projektiin varmistaa, että tapaat ihmisiä ja saavutat heidän kunnioituksensa, ja maineesi kasvaa, mikä on korvaamatonta kaikille ammattilaisille.

Tämä on pieni henkilökohtainen matkani taistelussa tätä pelkoa vastaan. Tämän artikkelin julkaiseminen on osa itse matkaa. Kirjoitan sen toivossa, että kuka tahansa, joka on estetty kirjoittamasta blogikirjoitusta tai pelkää edes pienen panoksen antamista, huomaa, että loppujen lopuksi se ei ollut niin pelottavaa. Lisäksi sen on tarkoitus auttaa kaikkia, jotka haluavat osallistua avoimen lähdekoodin käyttämiseen, mutta eivät tiedä mistä aloittaa, joten aloitan perusasiat.

Mikä on avoimen lähdekoodin ohjelmisto ja mistä löydän sen?

Avoimen lähdekoodin ohjelmisto tai lyhyesti OSS on ohjelmisto, joka on julkaistu lähdekoodinsa kanssa ja sisältää lisenssin, jonka avulla voit muokata ja levittää sitä uudelleen. Se voidaan toimittaa mihin tahansa: verkkosivustolla, postituslistalla tai pöllön kanssa. Yleisin skenaario, josta olemme kiinnostuneita, on, kun koodipohjaa ylläpidetään yhteistyötietovarastossa. Tässä keskitymme GitHubiin, mutta on olemassa muita vaihtoehtoja, kuten SourceForge ja Bitbucket. GitHub on erittäin ystävällinen, sillä on valtava käyttäjäkunta, sitä voidaan käyttää kaikenlaisiin koodeihin ja missä tahansa käyttämässäsi kehitysympäristössä. Tärkeää on, että sitä käytetään myös laajalti ei-avoimen lähdekoodin projekteissa. Mahdollisuudet ovat, että seuraava asiakasprojekti isännöi siellä, joten tietämys sen kanssa työskentelystä on sinänsä hyödyllinen taito.

Entä jos en tiedä miten koodata?

Jos luet tätä, on todennäköistä, että haluat oppia koodaamaan. Löydät upeita kursseja useilta ilmaisilta ja maksetuilta verkkosivustoilta. Sinun pitäisi valita yksi kieli oppia; jos sinulla ei ole asetuksia, valitse JavaScript. Sinulla on jo kaikki mitä tarvitset aloittaaksesi selaimessasi, ja se on yksi yleisimmin käytetyistä ja markkinoitavimmista taidoista. Oma suosikkini on Python, jota käytetään sekä web-kehityksessä että tieteellisissä sovelluksissa. Minulla on myös henkilökohtainen suosikkikurssi, 'Johdatus tietojenkäsittelytieteen' Udacitystä . Pidän siitä, koska se on käytännön kurssi, jossa työskentelet projektissa oppimisen aikana. Löydät myös useita muita kursseja Coursera, Khan Academy ja PluralSight.

Entä jos en tunne Gitiä?

Kuten aiemmin mainittiin, tietäen Mennä on tärkeää, joten ota Git-luokka. Tee se, vaikka olisit työskennellyt Gitin kanssa jonkin aikaa; et tiedä kuinka paljon et tiedä Gitistä, ennen kuin opit sitä todella. Tee se, jos et voi luotettavasti selittää mitä rebase komento tekee. Tee se, vaikka väärä uudelleenkäynnistys ei pelota sinua. Otin täyden Git-polku Code Schoolissa, mutta voit jälleen tutustua muihin sivustoihin saadaksesi lisää vaihtoehtoja.

Kuinka voin valita projektin GitHubissa?

On todennäköistä, että käytät joitain käyttöjärjestelmiä jokapäiväisessä kehityksessäsi. Tunnetun kehyksen valitseminen on hyvä lähtökohta; olet jo perehtynyt ominaisuuksiin ja miten kehys toimii. Kun sukelat lähdekoodiin, opit lisää ja ymmärrät sen logiikan entistä selvemmin. Jos sinulla on tekniikka tai työkalu, josta pidät erityisesti, etsi projektit, joissa se mainitaan, tai itse työkalu. Viimeisenä keinona voit tarkistaa projektit GitHub Showcasesissa ja aloittaa valitsemalla sinua kiinnostavan luokan.

Esimerkiksi pikahaku Vadelma GitHubin haussa näyttää yli 17 tuhatta arkistoa. On helppo eksyä, joten etsi projekti, jolla on hyvä yhteisö ja hyvä ongelmanseuranta. Kun valitset projektia, tarkista seuraavien lukumäärä:

• Avustajat : Kohdista mihin tahansa yli kymmeneen avustajaan. Tämän pitäisi varmistaa, että projektilla on riittävästi kiinnostusta eikä se ole vain pieni tiimityö. Jos olet uusi OSS-käyttäjä tai et ole liian ammattitaitoinen, rajaa haku vain projekteihin, joissa on enintään 50 osallistujaa. Suuremmat yhteisöt tarkoittavat suurempia kooditukia ja monimutkaisempia projekteja.
• Sitoutuu : Mene hankkeisiin, joissa on vähintään tuhat sitoutumista ja joissa viimeisin toiminta on enintään viikkoa vanha. Projekti, joka on ollut passiivinen vähintään kuukauden, on vanha ja vanhentunut OSS-termeillä, etkä todennäköisesti saa vastauksia nopeasti. Päivittäinen toiminta on merkki terveestä projektista.
• Kysymykset : Ongelmat ovat avoimia ongelmia, virheitä, joista on ilmoitettu tai joita on pyydetty toteuttamaan. Ne antavat sinulle lähtökohdan ja ovat hyvä mittari projektin kiinnostuksesta.

Selvitä myös, mikä on projektin pääkieli; näet kielitilastot projektin pääsivun yläpalkissa. Ota jonkin aikaa lukea keskustelun sävy, katso kuinka ystävällisiä ja koulutettuja kommentit ovat. Jotkut projektit ovat surullisia aggressiivisille yhteisöilleen, joten ne eivät välttämättä ole oikea lähtökohta.

minä valitsin ScyllaDB , pylväsdatan tallennusprojekti, koska minua kiehtoo data - kaikki, mikä liittyy suorituskykyyn. En ole koskaan työskennellyt sen kanssa, mutta uskon voivani sukeltaa sen koodipohjaan. Voi olla yksinkertaisempaa työskennellä tuntemieni työkalujen kanssa, mutta pidän tätä haasteena ja tilaisuutena oppia jotain uutta. Lopulta se sopii täydellisesti laskuun; sillä on 18 kirjoittajaa, 6,5 kt sitoutuu (viimeisin oli 23 tuntia sitten kirjoituksen aikana), 178 avointa ongelmaa ja se näyttää olevan aktiivinen.

Mitä teen nyt?

Ensinnäkin kloonaa arkisto ja asenna ohjelmisto koneellesi saadaksesi käsityksen sen liikkuvista osista. Aloita sitten lukea ongelmat. Kun olet valmis, tarkista, pystytkö toistamaan ongelman koneellesi ja aloita sitten analysoida, mikä saa ohjelmiston toimimaan väärin.

Toinen lähestymistapa olisi löytää jotain, jota voit parantaa tai muokata itse. Ehkä huomasit kirjoitusvirheen tai esimerkiksi väärin kohdistetun fontin. Valitsin korjata pienen virheen, erityisesti väärän muuttujan nimen, jota käytetään a: ssa käsikirjoituksen dokumentaatio .

Näyttää siltä, ​​että pieni, mutta väärä dokumentaatio on paljon pahempi kuin ei dokumentaatiota. Käyttäjät asentavat ScyllaDB: n ja seuraavat asennusvaiheet, he luottavat sokeasti siihen, mikä on kirjoitettu kyseiseen komentosarjaan, ja päädyt turhautumiseen. Tämä sopi täydellisesti kykyihini, ja sen korjaaminen vaatii minua seuraamaan koko prosessia ja tutustumaan hieman koodipohjaan. Virheenkorjaus on tylsää, mutta se on hieno alku löytää tie projektiisi.

Haarukan luominen

Tämä voi olla triviaalia, mutta tällä hetkellä ScyllaDB-projektissa olen rouva Kukaan; olisi riskialtista antaa minun tehdä muutoksia heidän koodiinsa ilman valvontaa. Minun on tehtävä luotava “haarukka” omalle GitHub-tililleni. Täällä on minun ScyllaDB-haarukka . Se on oma leikkikenttä, jossa minulla on pääsy kaikkeen koodiin, ja voin muokata tiedostoja haluamallani tavalla. Jos halusin luoda oman version ScyllaDB: stä ja muokata sitä tekemään jotain täysin erilaista kuin alkuperäinen tarkoitus, voisin tehdä sen täällä. Haarukan luominen on helppoa; siirry projektin pääsivulle ja napsauta 'haarukka' -painiketta. Ei lainkaan pelottavaa.

Aika korjata vika

Nyt on aika testata koodi tietokoneellasi ja tehdä tarvittavat muutokset. Ensinnäkin, varmista, että olet asentanut Git-asiakas koneellasi. Lisää sitten julkinen SSH-avain GitHubiin ja varmista, että ssh-agenttisi on ladannut sen. Koodin hankkiminen paikallisesti on helppoa; käytä vain git clone haarukalle osoittava komento päähaaran sijaan:

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

Nyt sinun olisi pitänyt testata projekti päähaaralla, joten aiot rakentaa koodisi paikallisesti ja testata sitä samalla tavalla. Muista, että joudut haaroittamaan kaikki muut GitHub-projektit, joihin projektisi perustuu, koska viitteet ovat suhteellisia. Minun täytyi haastaa haarukka seastar, scylla-ami ja scylla-swagger-ui.

Korjattava vika on suhteellisen yksinkertainen; asiakirjat conf/scylla.yaml mainitsee kolme määritettävää hakemistoa: Yksi datatiedostoille, yksi sitoutuslokeille ja yksi, ilmeisesti käyttämättömälle, välimuistille, jotka kaikki ovat oletusarvoisesti jonkin $CASSANDRA_HOME

Sukeltamalla koodiin se osoittaa, että oletusarvot ovat erilaiset, ja kuten aloituksessa julkaisussa # 372 mainittiin, $CASSANDRA_HOME ei tule käyttää. Vahvistan hypoteesini testaamalla koodin parilla eri asetuksella, poistamalla asetuksen config-tiedostosta ja tarkistamalla, mitä hakemistoja käytetään. Kun olen riittävän varma siitä, että kaikki on oikein, voin lisätä, sitouttaa ja työntää muokatun tiedoston:

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

Huomaa, että esitin ongelmanumeron, jota edeltää hash, sitoutumisviestissä. Tämä kehottaa GitHubia linkittämään koodini automaattisesti itse ongelmaan.

Toinen tärkeä asia on huomata, että kun tutkin koodia, tajusin, että kolmatta hakemistoa, välimuistihakemistoa, ei oikeastaan ​​käytetä. On houkuttelevaa mennä askeleen liian pitkälle ja poistaa tämä asetus itse tai lisätä kommentti, jota ei käytetä, mutta joka ei kuulu kysymyksen # 372 soveltamisalaan, ja olisi väärin sitoutua mihinkään, joka ei liity tiukasti tähän ongelma. Sinun on pidettävä muutokset kohdennettuna ja rajoitettu käsillä olevaan tehtävään.

Tässä vaiheessa koodi on kiinteä ja se on GitHubissa, yksityisessä haarukassani. Tässä tulee pelottava osa: Pyydetään ScyllaDB-ihmisiä hyväksymään koodini. Tätä kutsutaan vetopyynnöksi.

Viimeinen vaihe: vetopyyntö

Haluan luoda vetopyyntöjä suoraan GitHubin verkkokäyttöliittymästä. Minusta se on intuitiivisempaa ja virheenkestävämpää kuin yrittää tehdä se komentoriviltä. Minun täytyy vain luoda vetopyyntöni napsauttamalla pientä vihreää painiketta sivuliikkeen nimen vieressä:

Huomaa, että GitHub laski kommentin automaattisesti. Haarakonttorillani on nyt yksi uusi sitoutuminen, mutta haarukan luomisen jälkeen päätietovarastossa on vielä 14 tekemistä, joten napsautan vihreää kuvaketta vasemmalla.

Onneksi yksittäinen sitoutumiseni ei ole ristiriidassa 14 muun kanssa, joten GitHub ilmoittaa minulle, että olen hyvä mennä. Minun ei tarvitse lisätä muita kommentteja tai viestejä. Vaikka sitoutumisviesti on hyvin lyhyt, se kertoo kaiken: Mitä koodimuutokseni tekee ja mihin se liittyy. Kun napsautan viimeistä painiketta vahvistaakseni pyyntöni, ihmettelen, mikä oli, että löysin niin pelottavan vain muutama päivä sitten. Minua ei tällä hetkellä mölyä hirviö, eikä helvetin liekit näytä palavan. Rehellisesti, se ei ollut ollenkaan pelottavaa. Siinä epätodennäköisessä tapauksessa, että sain väärin, korjaustani ei hyväksytä, ja niin se on.

Jos nyt tarkistat julkaisutiedot , näet, että GitHub lisäsi automaattisesti huomautuksen, että tähän ongelmaan viitataan vetopyynnöllä. Tämä on sen 372 taika sitoutumisviestissä. Tämä auttaa välttämään muita ihmisiä tuhlaamasta aikaa korjaamaan jotain, joka on jo korjattu.

Avoin lähdekoodi ei ole ollenkaan niin pelottavaa. Tweet

Loppuhuomautukset

Odotan nyt, että vetopyyntöni hyväksytään, saan ilmoituksen, kun niin tapahtuu. Muista, että tämä voi kestää muutaman päivän, jopa viikon; jonkun on tarkistettava koodini, testattava, että se toimii kuvatulla tavalla, korjaa ongelman ja viime kädessä varmista, ettei se vaikuta haitallisesti muun koodin toimintaan (lue: luo uusia vikoja). Kaikki tämä vie jonkun aikaa, joten ole kärsivällinen. Loppujen lopuksi, kun vetopyyntöni hyväksytään, ScyllaDB: llä on yksi lisää kirjoittajaa, yksi asia vähemmän ja minulla on ensimmäinen OSS-kirjoitukseni. Nyt on aika kokeilla sitä. Loppujen lopuksi se ei ole ollenkaan pelottavaa.