Podsumowanie statystyk repozytoriów projektów zgłoszonych do DSP

Oto podsumowanie statystyk repozytoriów projektów zgłoszonych do tegorocznego DSP. Pokazałem je światu na początku kwietnia. Stronę ze statystykami można znaleźć tutaj.

Statystyki nie będą już dłużej uaktualniane, ponieważ konkurs się skończył. Ostatnie uaktualnienie zostało zrobione z danymi na 31 maja 2017 roku. Dodatkowo 1 czerwca dołożyłem filtr, który zawęża wyniki tak, by można było oglądać tylko finalistów DSP. Jeśli czas mi pozwoli, po wyłonieniu dwudziestki, której projekty i blogi zostaną poddane pod publiczne głosowanie, dołożę jeszcze jeden filtr, w którym będzie tylko ta dwudziestka.

Disclaimer

Statystyki nie są doskonałe. Kilka osób, które podały błędne linki do repozytoriów w profilach na DSP, nie ma żadnych statystyk, chociaż robiły commity. Przyjąłem też założenie, że wszyscy będą rozwijali projekt na jednym branchu, a wiem o przynajmniej jednej osobie, która dała mi znać na Slacku, że rozwijała też drugi branch, który nie został podliczony.

Statystyki były zliczane między 1 marca i 31 maja. Statystyki z GitHuba (forki, gwiazdki) pochodzą z 1 czerwca rano.

Statystyki takie jak te mogą nie oddawać sprawiedliwości projektowi. Nie są one wyznacznikiem jakości. Gdyby płacono nam od linijki napisanego kodu, powstawałyby naprawdę złe projekty.

Podium

Niestety, ze względu na to, że wiele osób wrzuca do repozytorium kod bibliotek będących zależnościami, nie można uczciwie określić, jak wygląda klasyfikacja pod względem ilości dodanego w ciągu trwania projektu kodu. W tej kategorii nie będę więc próbował określić, jak wygląda podium.

Ale są inne kategorie.

Commity

W tej kategorii zwycięzcą jest Michał Kortas, który zrobił aż 532 commity w czasie trwania konkursu. Na drugim miejscu jestem ja z 228 commitami. Trzecie miejsce zajął w tej kategorii Michał Sakwa, który zrobił 209 commitów. Zwycięzca w tej kategorii zrobił więcej commitów, niż zdobywcy dwóch następnych miejsc.

Gwiazdki

Jeśli chodzi o gwiazdki na GitHubie, bezapelacyjnym zwycięzcą jest JustinDB autorstwa Mateusza Macieszka. Zwycięski projekt zdobył do zakończenia konkursu 44 gwiazdki. Na drugim miejscu jest Artemis Entity Tracker autorstwa Kamila Dąbrowskiego, który zdobył 16 gwiazdek. Podium z 13 gwiazdkami zamyka gra Evil Slime City autorstwa Mateusza Kupilasa.

Dni z commitami

Jeśli chodzi o regularność commitów, to pierwsze miejsce przypada mi. Commitowałem przez 83 dni z 92 dni, przez które trwał konkurs. Na drugim miejscu znajduje się Michał Sakwa, który commitował przez 60 dni. Na miejscu trzecim jest Paulina Kaczmarek, która commitowała przez 56 dni.

Co ciekawe, podium we wszystkich trzech kategoriach, które, jak sądzę, było sens tu badać, są identyczne dla finalistów i dla ogółu uczestników.

Ciekawostki

Tak jak poprzednio, tak i tym razem, napiszę o paru ciekawostkach, które dają się zauważyć w konkursie.

  • Tylko 23 uczestników konkursu zrobiło ponad 100 commitów, a tylko 80 uczestników – ponad 50 commitów.
  • Trzech finalistów (czyli osób które napisało 20 postów, w tym minimum 10 o projekcie), nie zrobiło ani jednego commitu w czasie trwania konkursu.
  • Jedno repozytorium uczestnika miało ponad 500 MB, 3 kolejne miały ponad 200 MB, a 5 kolejnych – ponad 100 MB. Dla porównania, moje repozytorium miało 3,5 MB.
  • Przynajmniej jedną gwiazdkę w momencie zakończenia konkursu miało 162 uczestników i 68 finalistów. Przynajmniej 5 gwiazdek miało tylko 14 uczestników i 9 finalistów.
  • Kobiety stanowią 9.6% uczestników i 10.8% finalistów.

Zakończenie

I to tyle, jeśli chodzi o temat statystyk projektów DSP. Pozostawię je w internecie w celach historycznych. Jeśli ktoś chce być z nich usunięty, może się ze mną skontaktować mailowo. Zapraszam do przeglądania.

Podsumowanie obecności mojej i Star Trek API w DSP

Oto krótki post podsumowujący mój udział w DSP z projektem Star Trek API.

Postępy projektu

Przez trzy miesiące projekt zdecydowanie posunął się do przodu.

Przez marzec i kwiecień napisałem parsery do sześciu encji: lokalizacje, jedzenie, organizacje, książki, serie książek i kolekcje książek. Przez cały maj przygotowywałem stronę Star Trek API, której odpalenie zaanonsowałem w poprzednim poście. Można ją obejrzeć tutaj.

Dane liczbowe

Przez czas trwania projektu udało mi się napisać 22 posty, z 27, których napisanie założyłem sobie w pierwszym poście. Większość z postów, które nie powstały, nie powstały dlatego, że tematy, które przygotowałem, wydały mi się za słabe, a miałem krótką listę rezerwową.

Wykonałem w sumie 228 commitów. Commitowałem przez 83 dni z 92 dni, przez które trwał konkurs. W kwietniu i w maju commitowałem codziennie. Dodałem do repozytorium ponad 69 tysięcy linii, a usunąłem 20 tysięcy linii. To lepsza średnia, niż w miesiącach poprzedzających konkurs.

Wrażenia z blogowania

Ciężko było mi znaleźć odpowiednią ilość tematów do postów, i to mimo tego, że zaczynałem z okoła 20 tematami na początku marca. Część z nich się jednak wykruszyło, a nowe nie dochodziły tak szybko, jak bym chciał. Miałem tutaj i tak dużo łatwiej, niż ci uczestnicy konkursu, którzy projekty zaczynali z końcem lutego lub na początku marca. Miałem doświadczenia zbierane od października zeszłego roku.

Myślę, że po okresie konkursu będzie sukcesem, jeśli opublikuję na blogu jeden wpis w miesiącu. Tym niemniej, blog zostaje w sieci. Na pewno do czegoś mi się przyda.

STAPI – plany na przyszłość

Star Trek API, jak już zapowiadałem w marcu, będzie kontynuowane. To dalej zadanie, które mnie fascynuje, i projekt, który chcę mieć w swoim portfolio – jako programista i jako fan Star Treka.

DSP – podsumowanie

W samym konkursie brakowało mi jakichś punktów przełomowych i kogoś, kto prowadził by narrację nad całością. Konkurs trwał, były rozmowy na Slacku, obserwowaliśmy swoje projekty i blogi, ale brakowało jednego miejsca, w którym to wszystko by się spinało. Ale być może to tylko moje wrażenie, bo po prostu nie uczestniczyłem zbytnio w żadnych aktywnościach z innymi uczestnikami i wolałem siedzieć w swojej niszy.

A teraz – czekamy na oba głosowania, i oczywiście na galę finałową!

Star Trek API jest już w sieci!

Star Trek API trafiło w końcu do sieci!

Zmiana priorytetów

Ostatni miesiąc poświęciłem w dużej mierze na doprowadzanie do działania strony głównej STAPI. Musiałem napisać dokumentację API, dorobić zliczanie statystyk encji i statystyk użycia endpointów, napisać trochę tekstów na stronę i pozamykać TODO, które oczekiwały na lepsze czasy. Tym niemniej dziś, w dniu końca konkursu, strona jest gotowa do pokazania światu.

Serwer

STAPI zostało postawione na serwerze dedykowanym Kimsufi. Tutaj moje doświadczenie było słabe. Na stronie Kimsufi.pl widnieje przechwałka, że serwer zostanie uruchomiony w 120 sekund. Uruchomienie mojego zabrało prawie 3 dni. Zamówiłem go w piątek po 17:00. 20 minut później wysłałem maila ponaglającego do supportu, który pozostał bez odpowiedzi aż do 14:30 w niedzielę. Wtedy dostałem odpowiedź, że w 120 sekund stawiane są serwery dla powracających klientów, a od nowych zazwyczaj wymaga się dokumentów potwierdzających tożsamość. U mnie obyło się bez wysyłania dokumentów, ale weryfikacja płatności trwała do 16:15 w poniedziałek. Przez cały poniedziałek wysłałem 4 kolejne maile ponaglające, które pozostały bez odpowiedzi.

System

System operacyjny w Kimsufi instaluje się przez webowy panel administracyjny. Na system wybrałem Ubuntu, które znam stosunkowo najlepiej. Na początku zainstalowałem wersję 17.04 (Zesty Zapus), ale ponieważ tutoriale na blogach, z których korzystałem, nie były z nią kompatybilne, cofnąłem się do wersji 16.04 (Xenial Xerus), która jest LTS-em.

Java i Oracle

Po tym, jak zainstalował się system, trzeba było zainstalować Javę 8. To robi się trzema łatwymi do wygooglania poleceniami, więc nie będę się nad tym rozwodził.

Grubszy problem wystąpił z bazą danych Oracle XI 11g, która nie jest oficjalnie wspierana na Ubuntu. Ponieważ jednak wśród wspieranych przez Oracle’a dystrybucji Linuxa nie było żadnej, którą można było zainstalować z panelu Kimsufi, postanowiłem pójść za najlepiej widocznym w Google tutorialem na temat instalacji Oracle’a na Ubuntu, jaki znalazłem. Jedyne, co musiałem zmienić w całej procedurze (napisanej dla Ubuntu 12.04), to sposób zaktualizowania parametrów jądra. Zamiast polecenia sudo service procps start, które nie chciało działać, wykonałem polecenie sysctl --system.

Deployment

Następnie trzeba było zasilić bazę z gotowego dumpu, który wygenerowałem kilka dni temu, oraz wrzucić wygenerowany plik WAR na Tomcata. Na tym etapie życia projektu proces deploymentu jest jeszcze mocno ręczny, ale w przyszłości na pewno go sobie zautomatyzuję. Na tę chwilę z automatu podmieniam tylko propertisy i generuje dumpa z innym schematem, niż schemat źródłowy, ale paczkę i bazę wgrywam z palca.

Problemy

Nic nigdy nie działa od pierwszego strzału, i tak samo było tym razem. Po wrzuceniu WAR-a na Tomcata nie było widać dokumentacji, ponieważ kontrakty nie były kopiowane do paczki. Ponadto okazało się, że część endpointów nie odpowiada, ponieważ ich nazwy były krótsze, niż sześć znaków, i leciał wyjątek, bo nie zabezpieczyłem się przed trywialnym StringIndexOutOfBoundsException.

Podsumowanie

Cieszę się, że udało mi się postawić stronę w ostatniej chwili. Dzięki temu lepiej widać, ile udało mi się zrobić przez ostatnie miesiące, i ile jeszcze pracy przede mną. Dodatkowo mam nadzieję, że sprawdzi mi się podejście release early, release often, i fandom Star Treka zainteresuje się tym projektem, zanim przyjdzie mi skończyć go w pojedynkę. Chociaż wcale się przed tym nie uchylam.

CodeNarc – linter do Grooviego

Gdy zaczynałem pracę nad Star Trek API, naturalnym wydało mi się zastosowanie jakiegoś lintera do Javy. Wybór padł na popularny Chekstyle. To żadne zaskoczenie, ale ponad połowa kodu, który w tej chwili znajduje się w repozytorium projektu, to kod testów napisanych w Spocku, czyli w efekcie w Groovym. Udało mi się znaleźć tylko jeden linter do Grooviego, CodeNarc, który opiszę w tym poście.

Instalacja

Jeśli budujemy projekt za pośrednictwem Gradle’a, jak w moim przypadku, instalacja ogranicza się do dodania do Gradle’a pluginu:

apply plugin: 'codenarc'

I skonfigurowania:

codenarc {
configFile = "$rootDir/codenarc.groovy" as File
toolVersion = '0.26.0'
}

Następnie trzeba stworzyć plik codenarc.groovy w katalogu głównym projektu, lub w dowolnym innym, jeśli wskażemy go w konfiguracji. Gdy to zrobimy, mamy dostępne dwie nowe komendy:

gradle codenarcMain
gradle codenarcTest

Pierwsza komenda sprawdza, czy produkcyjny kod w Groovim jest zgodny z aktywowanymi w CodeNarcu regułami, a druga robi to samo dla kodu testów. Ponieważ w projekcie nie mam żadnego kodu produkcyjnego w Groovym, przy walidacji kodu posługuję się tylko tą drugą komendą.

Dodatkowo teraz, gdy wywołujemy komendę gradle check, wykonywane są też walidacje pochodzące z CodeNarcu.

Konfiguracja

Cała konfiguracja Codenarcu odbywa się we wspomnianym już pliku codenarc.groovy. Alternatywnie można skorzystać z konfiguracji przez plik z propertisami, ale ja wybrałem plik Groovy.

Postanowiłem zacząć od wrzucenia pliku ze wszystkimi regułami domyślnie włączonymi, i po kolei rezygnować z tych, które uznałem za bezcelowe lub niemające znaczenia. Mimo wszystko nie zrezygnowałem z dużej liczby reguł, ponieważ kod testów jest z natury prostszy, niż kod produkcyjny, a więc nie tak wiele rzeczy trzeba było poprawiać, żeby walidacje przechodziły.

Ostatecznie mój plik z regułami wygląda tak.

Wyłączone reguły

Oto wybrane reguły, które wyłączyłem w Star Trek API, wraz z powodami wyłączenia:

  • NoTabCharacter – ponieważ w całym projekcie używam tabów.
  • AbstractClassWithoutAbstractMethod – ponieważ czasami moje klasy abstrakcyjne mają tylko pola, których wartości używane są w testach.
  • TrailingComma – w testach rzadko zmienia się kolejność w listach po ich utworzeniu.
  • ClassJavadoc – zgodnie z regułami clean code’u, piszę bardzo mało dokumentacji do kodu. Jeszcze mniej sensu miałoby pisanie jej w testach, gdzie, IMO, dostateczną dokumentację stanowią nazwy metod testowych pisane językiem naturalnym.
  • SpaceAroundMapEntryColon – wydawało mi się nienaturalne, by konstruktor mapy zapisywać jako [ : ], a nie [:]. CodeNarc jest pierwszym miejscem, gdzie spotkałem się z takim zapisem.
  • MethodSize – domyślnie metoda może mieć sto linii. W przypadku metod testowych nie ma sensu robić wygibasów, by je podzielić, zwłaszcza że są już podzielone przez bloki given, when: i then:.
  • AUnnecessaryObjectReferences – reguła zabrania odwoływania się do jednego obiektu więcej, niż domyślne 5 razy. Często natomiast w testach mam sytuację, gdy robię assercje nawet na kilkudziesięciu polach jednego obiektu. Jako alternatywę CodeNarc podaje zapis with. Ten zapis nie jest niestety wspierany przez moje IDE, więc automatyczny refaktor go nie obejmie, i nie można korzystać w bloku with z podpowiadania składni.

Przekonfigurowane reguły

Następujących reguł nie wyłączyłem, ale je przekonfigurowałem:

  • LineLength – dopuszczalna długość linii została ustawiona na 150 znaków, podobnie jak w Checkstyle’u.
  • BuilderMethodWithSideEffects – CodeNarc traktował wszystkie metody, które zaczynały się od create jako metody wytwórcze, które nie mogą mieć efektów ubocznych. Ja natomiast mam metody testowe, których opis w języku naturalnym zaczyna się od create, więc zmieniłem regułę tak, aby były brane pod uwagę tylko te metody, które zaczynają się od create, po którym następuje wielka litera.
  • PackageName – musiałem dopuścić camel case w nazwach paczek.
  • Najczęściej ignorowane reguły

    Oto lista reguł, które najczęściej ignoruję w pojedynczych metodach lub klasach:

    • LineLength – w niektórych miejscach lepiej nie łamać linii, gdy są za długie, bo czytelność jest gorsza. Używam też tego wykluczenia w przypadku testów z datatables.
    • RuntimeException – w niektórych testach asercje wykonuję w pętlach, więc rzucam z nich wyjątki. Nie widziałem potrzeby tworzenia nowego typu wyjątku tylko na ten przypadek, więc dozwoliłem rzucanie wyjątków typu RuntimeException.
    • BracesForMethod – czasami metoda ma długi opis, i wtedy jest zapisywana z trzema cudzysłowami, a nie z jednym. W tym przypadku trzeba wyłączyć regułę BraceForMethod.

    Czego można się dowiedzieć

    Podczas implementowania CodeNarcu dowiedzieć się można kilku ciekawy rzeczy. Ja dowiedziałem się następujących:

    • Ostatnie domknięcie w ciągu metod może być zapisane bez nawiasów okrągłych. Czyli .do { it.stuff() } zamiast .do({ it.stuff() }).
    • Nie powinno się zapisywać metod voidowych jako def something(), ponieważ def oznacza tyle, co Object, a metody voidowe, takie jak metody testowe, niczego nie zwracają.
    • Nie ma sensu zapisywać stringów w podwójnych cudzysłowach, jeśli nie robimy w nich interpolacji. Także z powodów wydajnościowych.

    Podsumowanie

    Zastanawiam się, ile osób używa CodeNarcu w stosunku do produkcyjnego kodu w Groovim. Na GitHubie ma on zaledwie 120 gwiazdek, w porównaniu do 1985 gwiazdek, które ma Checkstyle.

    CodeNarc na pewno poprawia jakość kodu, który piszemy. Pewnie miałbym z niego więcej użytku, gdybym w Groovim nie pisał tylko testów. Mimo wszystko pomaga, choćby w usuwaniu nieużywanych zmiennych i formatowaniu kodu.

    Najgorsze i najlepsze rzeczy na rozmowach kwalifikacyjnych

    Byłem w życiu na kilkunastu rozmowach kwalifikacyjnych. Kilka z nich zapamiętałem szczególnie, i o nich dzisiaj napiszę.

    Sześć na jednego

    Zdarzyło mi się być na rozmowie kwalifikacyjnej, gdzie umówiony byłem z jedną osobą, a przyszło sześć. Nietrudno się domyślić, że taka przewaga, połączona z faktem, że pytania zadawała mi większość osób, zakończyła się tym, że do firmy się nie