Open Source: to nie jest takie straszne!

Poniższe informacje zostały opublikowane przed uruchomieniem stypendiów Toptal dla programistek.

Jako programista, bycie na bieżąco z najnowszymi trendami w technologii jest ekscytujące i trudne. Każdego dnia nowe języki, struktury i urządzenia przyciągają naszą uwagę i zachęcają do rozmów na spotkaniach, forach i czatach. Jednak nasza społeczność programistów składa się z ludzi, a nie narzędzi, i fascynujące jest odkrywanie jej aspektów społeczno-politycznych (z braku lepszego słowa; „społecznościowy” jest obecnie kojarzony z sieciami społecznościowymi).

W Toptal przeprowadziliśmy ostatnio kilka interesujących rozmów na temat tego, jak bardzo kobiety wnoszą wkład w open source i co może uniemożliwiać im większy wkład, więc zbadaliśmy tę sprawę. Będąc częścią tej rozmowy z Breandenem Beneschottem i Bozhidarem Batsovem, zacząłem się zastanawiać: Bozhidar jest jednym z najlepszych współtwórców open source na GitHub. Gdzie ja jestem? Jeśli sprawdzisz moje publiczne konto GitHub na dzień dzisiejszy, to głównie małe projekty testowe, z których korzystałem na zajęciach dla moich uczniów. Są na wpół upieczone i zdecydowanie nie reprezentują moich umiejętności ani wiedzy. (Musisz mi na to uwierzyć.) Gdyby ktoś rozważał zatrudnienie mnie w oparciu o to, co może znaleźć na tym koncie, myślę, że trudno byłoby mi się utrzymać. Mimo to jestem profesjonalnym programistą od ponad 20 lat iw mojej codziennej pracy używam więcej oprogramowania open source, niż pamiętam. Z biegiem czasu zhakowałem jądro Linuksa, aby dostosować je do konkretnych potrzeb, poprawiłem każdy router i serwer NAS, które kupiłem, cierpliwie czekałem miesiącami na liście oczekujących na Raspberry Pi, aby dostać się w swoje ręce i zdobyć moją domową domotykę jako Lubię to. Mimo to żadne z tych poprawek i testów nigdy nie trafiło na mój GitHub, aby stać się open source. Poza tym, poza naprawieniem błędu w jednej z pierwszych wersji Tomcata, nigdy nie brałem udziału w projekcie open source. Ciekawe, prawda?

Można by pomyśleć, że to po prostu brak czasu lub zainteresowania, ale wiem, że tak nie jest. Jeśli chodzi o moje osobiste projekty, może myślałem, że nikt nie może się naprawdę zainteresować tym, co zrobiłem, ale przede wszystkim sam pomysł opublikowania tam mojej pracy, aby wszyscy mogli to zobaczyć i dla potomności, bardzo mnie przeraża. I chociaż zawsze możesz zburzyć osobisty projekt z GitHub, w dniu, w którym spróbujesz wnieść swój wkład do szeroko dostępnego projektu open source, nie ma odwrotu. Co jeśli mój kod nie jest wystarczająco dobry? A jeśli nie zrozumiałem poprawnie problemu? Co się stanie, jeśli moje żądanie ściągnięcia zostanie odrzucone? Co jeśli ludzie będą mnie trollować?

Szybka rozmowa z zaprzyjaźnionymi programistami, głównie kobietami, szybko przekonała mnie, że nie jestem jedyną osobą z tym problemem, ale dla inżyniera nie ma problemów, tylko rozwiązania, prawda?

Jest to ważny problem do rozwiązania, ponieważ wkład w projekt open source może znacznie zmienić:

• Podczas Twojej kariery : Wielu klientów przyjrzy się wszystkim Twoim społecznościom, zanim zdecyduje się Cię zatrudnić; Twoje konto GitHub i CV na LinkedIn znajdują się na szczycie listy, wraz z profilami na Facebooku i Twitterze. Powinieneś ich mądrze używać.
• Dla Twoich umiejętności technicznych : Badanie kodu napisanego przez innych programistów, często bardzo dobrych, wiele Cię uczy. Umiejętność wydobycia znaczenia ze źle napisanej bazy kodu będzie wyzwaniem i nauczy Cię równie wiele.
• Dla Twoich umiejętności miękkich : Oprogramowanie open source to proces oparty na współpracy, a prawie wszystkie interesujące projekty są tworzone przez zespoły. Nauczenie się współpracy z innymi programistami za pomocą narzędzi, z których wszyscy korzystają, aby wtopić się w zespół, skutecznie komunikować się, uczyni Cię świetnym programistą, a nie tylko wykwalifikowanym.
• Dla społeczności : liczy się każdy wkład w projekt open source. Im więcej wniesiesz, tym lepiej, ale nawet naprawienie jednej małej literówki w tłumaczeniu sprawi, że produkt końcowy będzie lepszy.
• Dla Twojej sieci : możesz wysyłać setki życiorysów do firm, ale nic nie działa tak, jak współpracownicy z osobistymi kontaktami. Aktywne zaangażowanie w projekt open source zagwarantuje, że spotkasz ludzi i zdobędziesz ich szacunek, a Twoja reputacja wzrośnie, co jest nieocenione dla każdego profesjonalisty.

To moja mała osobista podróż w walce z tym strachem. Opublikowanie tego artykułu jest częścią samej podróży. Piszę to w nadziei, że każdy, kto jest zablokowany w pisaniu posta na blogu, albo boi się wnieść choćby niewielki wkład, przekona się, że w końcu nie było to takie straszne. Ma również pomóc każdemu, kto chciałby przyczynić się do open source, ale tak naprawdę nie wie, od czego zacząć, więc zacznę od podstaw.

Co to jest oprogramowanie Open Source i gdzie je znaleźć?

Oprogramowanie open source, w skrócie OSS, to dowolne oprogramowanie wydane wraz z kodem źródłowym i zawiera licencję, która pozwala na jego modyfikację i redystrybucję. Może być dostarczony w dowolne miejsce: na stronie internetowej, poprzez listę mailingową lub za pomocą sowy. Najczęstszym scenariuszem i tym, który nas interesuje, jest utrzymywanie bazy kodu we wspólnym repozytorium. Tutaj skupiamy się na GitHub, ale są też inne opcje, takie jak SourceForge i Bitbucket. GitHub jest bardzo przyjazny, ma ogromną bazę użytkowników, może być używany do każdego rodzaju kodu i z dowolnym używanym środowiskiem programistycznym. Co ważne, jest również szeroko stosowany w projektach innych niż open source. Istnieje duże prawdopodobieństwo, że Twój następny projekt klienta będzie tam hostowany, więc wiedza, jak z nim pracować, jest przydatna sama w sobie.

Co jeśli nie umiem kodować?

Jeśli to czytasz, prawdopodobnie chcesz nauczyć się kodować. Możesz znaleźć niesamowite kursy na kilku darmowych i płatnych stronach internetowych. Powinieneś wybrać jeden język do nauki; jeśli nie masz preferencji, przejdź do JavaScript. Masz już wszystko, czego potrzebujesz, aby rozpocząć korzystanie z przeglądarki internetowej i jest to jedna z najczęściej używanych i sprzedawanych umiejętności. Moim osobistym faworytem jest Python, który jest używany zarówno w tworzeniu stron internetowych, jak i w aplikacjach naukowych. Ja również mam swój ulubiony kurs dla początkujących „Wprowadzenie do informatyki” na Udacity. Podoba mi się to, ponieważ jest to praktyczny kurs, podczas którego pracujesz nad projektem podczas nauki. Możesz także znaleźć kilka innych kursów na Coursera, Khan Academy i PluralSight.

A jeśli nie znam Gita?

Jak wspomniano wcześniej, znajomość Git jest ważna, więc weź udział w zajęciach z Git. Zrób to, nawet jeśli od jakiegoś czasu pracujesz z Git; nie wiesz, ile nie wiesz o Gicie, dopóki naprawdę go nie przestudiujesz. Zrób to, jeśli nie możesz pewnie wyjaśnić, co robi polecenie rebase . Zrób to, nawet jeśli zła zmiana bazy Cię nie przeraża. Przeszedłem pełną ścieżkę Git w Code School, ale znowu możesz przeglądać inne witryny, aby uzyskać więcej opcji.

Jak wybrać projekt na GitHub?

Prawdopodobnie używasz OSS w swoim codziennym rozwoju. Wybór znanego frameworka to dobry punkt wyjścia; znasz już funkcje i sposób działania frameworka. Kiedy zagłębisz się w kod źródłowy, dowiesz się więcej i jeszcze lepiej zrozumiesz jego logikę. Jeśli istnieje technologia lub narzędzie, które szczególnie Ci się podobają, poszukaj projektów, które o niej wspominają, lub samego projektu narzędzia. W ostateczności możesz sprawdzić projekty w GitHub Showcases i zacząć od wybrania interesującej Cię kategorii.

Na przykład szybkie wyszukiwanie hasła „Malina” w wyszukiwarce GitHub pokazuje ponad 17 tysięcy repozytoriów. Łatwo się zgubić, więc poszukaj projektu z dobrą społecznością i dobrym śledzeniem problemów. Wybierając projekt, sprawdź ilość:

• Współtwórcy : kieruj reklamy na wszystko powyżej dziesięciu współtwórców. Powinno to zapewnić, że projekt cieszy się wystarczającym zainteresowaniem i nie jest po prostu małym wysiłkiem zespołowym. Jeśli jesteś nowy w OSS lub nie masz zbyt wysokich umiejętności, ogranicz swoje poszukiwania do projektów z co najwyżej pięćdziesięcioma współtwórcami; większe społeczności oznaczają większe bazy kodów i bardziej skomplikowane projekty.
• Zatwierdzenia : wybierz projekty, które mają co najmniej tysiąc zatwierdzeń, a najnowsza aktywność ma nie więcej niż tydzień. Projekt, który był nieaktywny przez miesiąc lub dłużej, jest stary i przestarzały pod względem OSS i prawdopodobnie nie otrzymasz szybko żadnych odpowiedzi. Codzienna aktywność to znak zdrowego projektu.
• Problemy : problemy są otwartymi problemami, zgłoszonymi błędami lub żądanymi funkcjami do wdrożenia. Dadzą ci punkt wyjścia i są dobrym miernikiem zainteresowania projektem.

Dowiedz się również, jaki jest główny język projektu; możesz zobaczyć statystyki języka na górnym pasku głównej strony projektu. Poświęć trochę czasu na zapoznanie się z tonem dyskusji, zobacz jak przyjazne i pouczające są komentarze. Niektóre projekty cieszą się złą sławą ze względu na ich agresywne społeczności, dlatego mogą nie być właściwym punktem wyjścia.

Wybrałem ScyllaDB, projekt kolumnowego przechowywania danych, ponieważ fascynuje mnie wszystko, co jest związane z wydajnością. Nigdy z nim nie pracowałem, ale spodziewam się, że będę mógł zagłębić się w jego bazę kodu. Może prościej jest pracować z narzędziami, które znam, ale traktuję to jako wyzwanie i okazję do nauczenia się czegoś nowego. Co do reszty, idealnie pasuje do rachunku; ma 18 współtwórców, 6,5 tys. zatwierdzeń (ostatni był 23 godziny temu w momencie pisania), 178 otwartych problemów i wydaje się aktywny.

Co mam teraz zrobić?

Najpierw sklonuj repozytorium i zainstaluj oprogramowanie na swoim komputerze, aby zorientować się, jakie są jego ruchome części. Następnie zacznij czytać problemy. Gdy poczujesz się gotowy, sprawdź, czy możesz odtworzyć problem na swoim komputerze, a następnie zacznij analizować, co powoduje, że oprogramowanie źle się zachowuje.

Innym podejściem byłoby znalezienie czegoś, co możesz sam ulepszyć lub zmodyfikować. Może zauważyłeś na przykład literówkę lub niewłaściwą czcionkę. Zdecydowałem się naprawić mały błąd, a konkretnie niewłaściwą nazwę zmiennej używaną w dokumentacji skryptu.

Wydaje się to małe, ale zła dokumentacja jest znacznie gorsza niż brak dokumentacji. Użytkownicy zainstalują ScyllaDB i wykonają kolejne kroki instalacji, będą ślepo polegać na tym, co jest napisane w tym skrypcie, i skończą w stosach frustracji. To było idealne dla moich umiejętności, a naprawienie tego będzie wymagało ode mnie śledzenia całego procesu i zaznajomienia się z bazą kodu. Naprawianie błędów jest nudne, ale to świetny początek, aby znaleźć swoją drogę do projektu.

Tworzenie widelca

To może być trywialne, ale w tej chwili, dla projektu ScyllaDB, jestem panią Nobody; ryzykowne byłoby pozwolenie mi na wprowadzanie zmian w ich kodzie bez nadzoru. To, co muszę zrobić, to utworzyć „fork” na moim własnym koncie GitHub. Oto mój widelec ScyllaDB. To mój własny plac zabaw, na którym mam dostęp do całego kodu i mogę dowolnie modyfikować pliki. Gdybym chciał stworzyć własną wersję ScyllaDB i dostosować ją do czegoś zupełnie innego niż jego pierwotny cel, mógłbym to zrobić tutaj. Tworzenie widelca jest proste; przejdź do strony głównej projektu i kliknij przycisk „widelec”. Wcale nie przerażające.

Czas naprawić błąd

Teraz czas przetestować kod na swoim komputerze i dokonać niezbędnych modyfikacji. Przede wszystkim upewnij się, że zainstalowałeś klienta Git na swoim komputerze. Następnie dodaj swój klucz publiczny SSH do GitHub i upewnij się, że został załadowany przez twojego agenta ssh. Pobranie kodu lokalnie jest proste; po prostu użyj polecenia git clone , które wskazuje na twój widelec, zamiast na główną gałąź:

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

Do tej pory powinieneś przetestować projekt na głównej gałęzi, więc zamierzasz zbudować swój kod lokalnie i przetestować go w ten sam sposób. Pamiętaj, że będziesz musiał rozwidlić wszystkie inne projekty GitHub, na których opiera się Twój projekt, ponieważ odniesienia są względne. W moim przypadku musiałem rozwidlić seastar, scylla-ami i scylla-swagger-ui.

Błąd, który muszę naprawić, jest stosunkowo prosty; dokumentacja w conf/scylla.yaml wspomina o trzech konfigurowalnych katalogach: jeden na pliki danych, jeden na dzienniki zmian i jeden, najwyraźniej nieużywany, na pamięci podręczne, wszystkie domyślnie do jakiegoś podkatalogu $CASSANDRA_HOME :

Zagłębiając się w kod, widać, że wartości domyślne są różne i, jak wspomniano w numerze 372, od którego zacząłem, nie należy używać $CASSANDRA_HOME . Weryfikuję swoją hipotezę, testując kod z kilkoma różnymi ustawieniami, usuwając ustawienie z pliku konfiguracyjnego i sprawdzając, które katalogi są używane. Gdy jestem już pewien, że wszystko jest w porządku, mogę dodać, zatwierdzić i przesłać zmodyfikowany plik:

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

Zauważ, że wprowadziłem numer wydania poprzedzony haszem w komunikacie o zatwierdzeniu. Dzięki temu GitHub automatycznie powiąże mój kod z samym problemem.

Inną ważną rzeczą do odnotowania jest to, że kiedy przeglądałem kod, zdałem sobie sprawę, że trzeci katalog, ten dla pamięci podręcznych, w rzeczywistości nie jest używany. Kuszące jest, aby pójść o krok za daleko i usunąć samo to ustawienie lub dodać komentarz, który nie jest używany, ale wykraczałby poza zakres problemu nr 372, a popełnianie czegokolwiek, co nie jest ściśle z tym związane, byłoby błędem sprawa. Musisz skupiać się na swoich zmianach i ograniczać je do wykonywanego zadania.

W tym momencie kod jest naprawiony i znajduje się na GitHub, w moim prywatnym forku. W tym miejscu pojawia się przerażająca część: poproszenie ludzi ze ScyllaDB o zaakceptowanie mojego kodu. Nazywa się to żądaniem ściągnięcia.

Ostatni krok: żądanie ściągnięcia

Lubię tworzyć pull requesty bezpośrednio z interfejsu internetowego na GitHub. Uważam, że jest to bardziej intuicyjne i odporne na błędy niż próba zrobienia tego z wiersza poleceń. Wszystko, co muszę zrobić, aby utworzyć moje żądanie ściągnięcia, to kliknąć mały zielony przycisk obok nazwy mojego oddziału:

Zauważ, że komentarz został automatycznie obliczony przez GitHub. Moja gałąź ma teraz jeden nowy zatwierdzenie, ale od czasu utworzenia mojego rozwidlenia w głównym repozytorium jest jeszcze 14 zatwierdzeń, więc kliknę zieloną ikonę po lewej stronie.

Na szczęście moje pojedyncze zatwierdzenie nie koliduje z 14 innymi, więc GitHub informuje mnie, że mogę już iść. Nie muszę dodawać żadnego innego komentarza ani wiadomości. Komunikat zatwierdzenia, choć jest bardzo krótki, mówi wszystko: co robi moja zmiana w kodzie i z czym się to wiąże. Kiedy klikam ostatni przycisk, aby potwierdzić moją prośbę, zastanawiam się, co tak przerażało mnie zaledwie kilka dni temu. W tej chwili nie ryczy na mnie żaden potwór, a płomienie piekielne nie wydają się płonąć. Szczerze mówiąc, wcale nie było straszne. W mało prawdopodobnym przypadku, gdy się pomyliłem, moja poprawka nie zostanie zaakceptowana i to będzie koniec.

Jeśli teraz sprawdzisz szczegóły problemu, zobaczysz, że GitHub automatycznie dodał uwagę, że istnieje żądanie ściągnięcia odwołujące się do tego problemu. To jest magia tego #372 w komunikacie o zatwierdzeniu. Pomoże to uniknąć marnowania czasu przez inne osoby na naprawienie czegoś, co już zostało naprawione.

Uwagi końcowe

Teraz czekam na akceptację mojego żądania ściągnięcia, otrzymam powiadomienie, gdy to się stanie. Pamiętaj, że może to zająć kilka dni, a nawet tygodni; ktoś musi przejrzeć mój kod, przetestować, czy działa zgodnie z opisem, naprawić problem i ostatecznie upewnić się, że nie wpływa negatywnie na funkcjonalność reszty kodu (czytaj: tworzy nowe błędy). Wszystko to zajmuje komuś czas, więc bądź cierpliwy. W końcu, kiedy moje żądanie ściągnięcia zostanie zaakceptowane, ScyllaDB będzie miał jednego kontrybutora więcej, jeden problem mniej, a ja będę miał swój pierwszy wkład OSS. Teraz nadszedł czas, abyś ty też tego spróbował. W końcu to wcale nie jest przerażające.