2015 m. gegužės 5 d.

PyConLT 2015: Mano atviro kodo veikla

Mano pranešimo, sakyto PyConLt [0] 2015 metu tekstas. Kadangi teksto mintinai nesimokinau, tai jis šiek tiek skiriasi nuo to, kurį realiai pasakojau.

[0] http://pycon.lt/

Skaidrės:


Įžanga

Šiandieną aš jums šiek tiek papasakosiu apie savo atviro kodo veiklą. Tiksliau kažkurią jos dalį. Pradžioje norėjau temą pavadinti "Mano atviro kodo veikla arba vieno atnaujinimo istorija". Bet tokia tema atsiduoda klišiniu sovietinių laikraščių pavadinimu.

Dar norėjau pavadinti pagal Lietuvos žiniasklaidoje įprastas pavadinimų konstravimo gaires. Ką nors tokio, kaip "Programuotojas pabandė dalyvauti Django ekosistemoje ir neslėpdamas agonijos nustebo". Bet paskui nusprendžiau, kad gal kiti neskaito tiek daug Lietuvos naujienų portalų kaip aš. Tai palikau pretenzingą pavadinimą "Mano atviro kodo veikla".

Apie ką

Šitas pranešimas bus nelabai techniškas. Jis bus apie tą "vieno atnaujinimo istoriją", kurios paminėjimo neliko pavadinime.

Tai bus istorija apie mano vieną kodo pakeitimą, kuris galiausiai pateko į Django kodo bazę. Ta istorija turės įrodyti, kad prie atviro kodo projektų (net ir tokių svarbių ir garsių kaip web karkasas Django) gali dirbti ir gana nestabilios... Ir nevisai stabilių ir ne visada adekvačių poelgių žmogus. Toks kaip aš. O jei jau galiu aš, tai reiškia, kad jūs tai jau tikrai galite. Žinoma, neprivalot.

Atnaujinimas

Štai čia ir yra visas tas mano Django kodo atnaujinimas. Apie kurį aš jums papasakosiu.

Jo. Šita viena raidė. Aš pasakosiu apie vieną raidę.

EuroPython 2014

Istorija prasideda 2014-aisiais metais. Aš buvau EuroPython 2014 konferencijoje. Man patiko. Konferencija trunka 7 dienas. 5 pirmos konferencijos dienos yra pranešimų dienos. Paskutinės 2 konferencijos dienos yra skirtos atviro kodo projektų sprintams.

Kodo sprinto apibrėžimas. Tai nėra, kad gale konferencijos visiems moksliukams-programuotojams liepia greitai bėgti trumpas distancijas. Ir visi geek'ai ir kompiuterastai bėga suplūkę ir šnopuoja. O žiūrovai rodo pirštais, juokiasi ir už gerą reginį aukoja pinigus atviram kodui. Ne. Kodo sprintai nėra tai.

Atviro kodo sprintas šiek tiek primena SCRUM sprintą. Tai grupės žmonių susibėgimas (virtualiai ar gyvai) ir bendras darbas ties kažkokiu projektu ar projekto dalimi. Apibrėžtas laike. Tarkim, EuroPython 2014 būna 2 dienos.

Labai gerai dalykas. Tokia svarbi konferencija kaip EuroPython beveik garantuoja, kad bus projektų core programuotojai. Ir jie galės padėti įsivažiuoti ir greitai priimti pakeitimus.

Kas labai svarbu pradedantiesiems, nes labai lengva numušti entuziazmą, ilgomis laukimo pauzėmis.

Django kodo sprintas: nuorodos

Dabar pauzė istorijoje. Dabar aš šiek tiek supažindinsiu jus, kaip pradėti krapštytis prie Django projekto.

Dokumentacija. Django laimi dėl dokumentacijos. Tarkim, kartais sunku Python naujokui, norinčiam pradėti dirbti prie internetinių projektų, rekomenduoti ką nors kito nei Django. Ne dėl to, kad aš manyčiau, jog Django yra geriausias web karkasas. Beje, aš nemanau, kad jis geriausias.

Tačiau aš vis tiek rekomenduočiau Django. Dėl vienos paprastos priežasties. Dokumentacija. Jie turi turbūt vieną iš geriausią dokumentacijų. Bet kokio programavimo projekto. Ar tai būtų komercinis, ar atviro kodo.

Tas pats ir su pradėjimu užsiminėt atviro kodo veikla. Django dokumentacija valdo. Joje yra apmokymas (turorial'as), kaip dirbti prie Django kodo bazės.

Taip. Pažingsninis apmokymas.

Tai antra nuoroda sąraše. Pirma yra bendrinis dokumentacijos puslapis.

Aš tą apmokymą rekomenduoju perskaityti ir įvykdyti visiems, norintiems pradėti dirbti prie atviro kodo projektų, bet vis nepradedantiems, nes kažkaip neaišku, nei kaip čia pradėti, nei ko griebtis.

Net jeigu ir neketina dirbti prie Django. O gal net jeigu ir neketinate dirbti su Python iš vis.

Sekančios nuorodos.

Trečia yra Django Trac užduočių valdymo sistema. Ale Redmine. Ale Bugzilla. Ale Asana. Ar kas dabar ant bangos.

Dashboard. Čia yra tiek greitos nuorodos į tam tikrus django trac filtrus (tarkim, easy tickets), tiek šiokios tokios ataskaitos apie Django kodo progresą netolimoje praeityje.

Paskutinė nuoroda yra pakankamai sunkiai surandama. Tai yra Django Jenkins sistema. Ten galima pažiūrėti visokias nuolatinės integracijos ataskaitas. Tokias kaip kodo bazės padengimas testais. Prie šitos ataskaitos, beje, grįšiu savo istorijoje.

Django kodo sprintas: aš


Kalbant apie istoriją.

EuroPython 2014 metu aš prisijungiau prie Django sprinto. Pirma užduotis, kurią apsiėmiau, tai patobulinti dokumentaciją. Ji man buvo parekomenduota vieno Django core programuotojų.

Susikūriau Django užduočių sistemoje Trac užduotį. Parašiau ten kelis kažkokius sakinius. Žinot, pagal visą Langlų [1] kalbos tradiciją. Kiekvienas doras Langlų ekspertas posakį "Nepūsk arabų" verstų į "Don't blow arabians" ir drąsiai naudotų jį kalbėdamas su anglakalbiu.

Sukūriau prašymą įtraukti mano pakeitimus į einamą Django kodo versiją. Nu gerai -- sukūriau pull request'ą į masterį.

[1] https://eglemarkeviciute.wordpress.com/2015/04/09/langlu-kalba-weird-sounding-lithuanian-proverbsnsayings/

Tada. Tada. Kažkas paėmė tą mano pull request'ą. Pataisė mano pagal Langlų notaciją parašytus angliškus sakinius į suprantamus angliškus sakinius. Parašė man: "Ačiū -- gerai padirbėjai". Taip ir neišsiaiškinau ar ironiškai, ar ne. Ir įliejo realiai savo -- o ne mano -- tekstą į master kodo atšaką.

Tai dabar git blame ten rodo to kito programuotojo inicialus.

Supratau, kad dokumentaciją rašyti dar ne su mano įgūdžiais. Dėl to pradėjau taisyti tikro kodą.

Susiradau Django Trac paprastą klaidą. Kažkas apie django.forms.ImageField. Atsižymėjau, kad aš prie jos dirbu. Pasirašiau unit testą, kuris nepraeina.  Pataisiau kodą. Testas praeina. Valio! Sukūriau prašymą įlieti mano kodą.  Kažkas iš turinčių teises, pirma pasakė: "nu, nu, nu -- pirma suspausk commit'us į vieną, o tik po to kurk pull request'ą". Tada pats suspaudė mano atnaujinimus į vieną ir įkėlė mano kodą į Django master.

Suspausti atnaujinimus į vieną

Kartais atviro kodo projektuose (ir netik) yra reikalavimai, kad į master giją kiekvienas funkcinis atnaujinimas būtų įliejamas kaip vienas commit'as, o ne N commit'ų.

A) Taip lengviau sekti pakeitimus
B) Taip lengviau atstatyti seną versiją

Norintys žinoti kaip tai padaryti, pasiieškokite git rebase --interactive.

Bitcoin

Kaip ir minėjau, mano atnaujinimas buvo įkeltas į Django kodo bazė.

Ir gavau bitkoinų. Nes yra toks projektas kaip tip4commit. Kur kažkas gali aukoti bitkoinus atviro kodo projektams. O jau tada tas tip4commit paskirsto visiems dirbantiems prie to projekto.

[2] https://tip4commit.com/

Taigi, aš gavau nulis kablelis nulis nulisnulisnulislislisnulis N bitkoinų. Bet jų man tas tip4commit portalas neleidžia išsiimti. Nes reikia pasiekti kažkokią minimalią ribą. Minimalų kiekį. Kada jau leidžia išsiimti.

Čia reikia priminti, kad buvo gūdūs 2014 metai kai visos kriptovaliutos buvo dar ant bangos. Pvz.: Login 2014 konferencijoje buvo daug pranešimų apie kriptovaliutas. Šiemet įtariu bus viso 0 pranešimų.

Taip pat, reikia paminėti, kad pats tip4commit nėra vertinamas vienareikšmiškai. Kažkuri dalis projektų nenori būti su juo asocijuojami. Plius, yra įtarimų, kad pats projektas yra arba nelegalus, arba ant legalumo ribos. Ir dar kai kurie jį kaltina piniginėmis machinacijomis. Nes projekto savininkai gali būti, kad pasisavina dalį paaukotų pseudo-pinigų. Kas būtų visiškai neįtikėtina, nes kur gi girdėta, kad bet koks projektas susietas su bitkoinais būtų neskaidrus.

Šitie faktai, aišku, man visiškai nesutrukdė, nes aš apie juos tada dar visiškai nežinojau.

Taigi, aš ale gavau tų bitkoinų ir nusprendžiau, kad man, kaip kompiuterastui būtų į naudą su jais pasižaisti ir susipažinti iš techninės pusės.

Tai aš buvo sugalvojęs, kad man reikia kažkaip gauti ten tų bitkoinų ir tip4commit būtų puikus būdas.

Turtėjimo planas

Taigi, prieš pradėdamas turtėti, aš ne tik kvailai neišsiaiškinau projekto skaidrumo. Tuo pačiu aš dariau klaidingą prielaidą apie patį bitkoinų dalinimo algoritmą.

Aš dariau prielaidą, kad bitkoinus duoda pagal kodo atnaujinimo eilučių skaičių. O pasirodo, kad duoda tiesiog pagal commit'ų skaičių.

Remdamasis savo kvaila prielaida aš sugalvojau, kaip greitai praturtėti. Man tiesiog reikia prirašyti daug kodo.

O kur šiek tiek pro pirštus yra žvelgiama į logikos dublikavimą?

Turtėjimo planas: Unit testai

Unit testai. Čia žinoma filosofinis klausimas, bet rašant unit testus lyg ir galima dublikuoti eilutes. Man asmeniškai patinka, kai atsidarai unit testo kodo ir pačioje testo funkcijoje ar metode matai viską:

- Pradines sąlygų sukūrimas
- Testuojamos dalies paleidimas
- Visos assertFoo komandos

Dėl to, jeigu pavyzdžiui, turi 4 testus, kurie testuoja tą patį funkcionalumą, tie 4 testai turės labai panašų kodą, kurį būtų galima vadinti kodo dublikavimu. Ir tarsi reiktų iškelti į atskirą metodą. Bet tada testai taps mažiau suprantami. Trumpai, filosofinis klausimas.

Kaip jau minėjau, Django turi savo Jenkins serverį. Kuris prie visa ko leidžia testus ir generuoja kodo padengimo testais ataskaitas.

Taigi, aš susiradau django.contrib.admin Meta klasės opcijų validacinį modulį, kurio padengimas testais buvo labai mažas ir pradėjau jam rašyti unit testus.

Rašiau, rašiau

Rašiau, rašiau. Prirašiau kelis šimtus eilučių. Pamiršau aš tuos ir bitkoinus. Neberūpėjo jau man jie. Nes radau kitą skaičiuką. Ant kurio galima, kaip ant heroino kabliuotis. Tą procentą, kuris rodo kiek failas yra padengtas testais. Buvo 63% dabar yra 65%. Dar, dar reikia dar procentų.

Berašydamas turėjau nemažai pasiknaisioti po Django: tiek .contrib.admin tiek pačią šerdį (taip verčiu core. Šerdis), kad suprast, kas per velnias dedasi.

Rašiau be reikalo

Ir besiknaisiodamas radau įdomią kodo vietą. Ji teigė, kad tas modulis, kuriam unit testus aš rašau, bus apleistas (depreciated) ir ištrintas. Taigi nebeliko prasmės rašyti testus.

Beje, jau master gijoje jis yra ištrintas.

Bet

Bet. Už tai berašydamas testus, aš radau vieną tikrą klaidą.

Kodas turėtų mesti ValueError. Jis ir meta ValueError. Bet meta ne dėl to, kad Django kodas prašo mesti ValueError.

ValueError yra metamas giliau. % metodas gauna per didelį kiekį parametrų ir lūžta su ValueError. Taigi turime ValueError su blogu message atributu. Ir stack trace gauna papildomą frame'ą.

Kodo atnaujinimas

Atsimenate atnaujinimą.

Taigi, aš susikūriau sau užduotį pataisyti tą vietą. Ir prirašiau realiame kode tą vieną raidę. Dabar Django kodo bazė yra truputį geresnė, nes aš susigalvojau kvailystę.

Kodo atnaujinimas: biurokratija

Kad būti visiškai sąžiningu, tai čia yra visas kodo pokytis. Viena eilutė, keičianti Django kodą.

Visa kita -- biurokratija. Bet, mano manymu, svarbi ir reikalinga biurokratija. Pranešimas Release Notes. Ir, žinoma, unit testas.

Ačiū

Tai va. Istorijos pabaiga. Čia buvo mažas žvilgsnis į mano dalį atviro kodo veiklos.

Tikiuosi, ši istorija gali būti kaip iliustracija, kad prisidėjimas prie atviro kodo projektų neprivalo būti kažkoks įspūdingas dydžiu ir/ar vedinas kilnių tikslų ir/ar reikalaujantis nežmoniškų pastangų.

Tai tiek. Ačiū, kad išklausėte. Jeigu turite klausimų, mielai į juos atsakysiu.