Hacktoberfest 2022

W tym roku ponownie uczestniczyłem w Hacktoberfest. Początkowo wydarzenie traktowałem sceptycznie. Zresztą słusznie, bo problem mało istotnych commitów i spamu jak najbardziej istnieje. Potem jednak stwierdziłem, że to fajny motywator, żeby coś zrobić w open source. Zabawę z Hacktoberfest zacząłem więc w 2020, z repozytoriami nie uczestniczącymi oficjalnie w Hacktoberfest.

W zeszłym roku dołączyłem do firmowego wydarzenia. W ramach gry we własną grę, bawiliśmy się w zbieranie jak największej ilości gwiazdek. Czyli robienie commitów do repozytoriów z ich jak największą ilością. W duchu fair play, czyli bez spamu i poprawiania literówek. Trochę taki CTF.

Zatem w pełnym wymiarze uczestniczyłem w Hactoberfest 2021. Mógłbym dodać and all I got was this lousy t-shirt. Bowiem po spełnieniu warunków na odpowiednią liczbę commitów można było wybrać nagrodę – koszulkę lub zasadzenie drzewa. Lubię t-shirty, więc wybrałem koszulkę, mimo średniego koloru. Przy okazji dowiedziałem się, ile kosztuje darmowa koszulka po przejściu przez cło i Pocztę Polską. Otóż w 2021 przy deklarowanej wartości przesyłki $5,95, naliczono 5 zł VAT oraz 8,5 zł opłaty pocztowej. Razem 13,5 zł, czyli mniej więcej połowa wartości paczki. Zaś sama paczka dotarła w marcu 2022. Dowód:

Opłaty za koszulkę Hacktoberfest - Poczta Polska
Opłaty za koszulkę Hacktoberfest. Źródło: fot. własna

Nie powinno zatem dziwić, że w tym roku wybrałem posadzenie drzewa zamiast koszulki. Tegoroczny Hacktoberfest to trochę kontynuacja poprzedniego. Znowu zbieranie gwiazdek z ekipą z firmy. Z drugiej strony jest to powrót do korzeni, bo moje tegoroczne commity to głównie tłumaczenia do tldr. A przecież przygodę z open source zaczynałem od tłumaczeń w ramach Polish Debian Documentation Project, potem tłumaczyłem na polski w ramach GNU Polish Translation Team.

Oczywiście były też commity związane z kodem, oczywiście w Pythonie. I tu spostrzeżenie, że ludzie potrafią znaleźć błąd, zdebugować go, znaleźć miejsce, gdzie powinien być poprawiony i… założyć issue, wszystko pięknie opisując. Nie oceniam bo przyczyny mogą być różne, choć dziwię się, bo nakład pracy na założenie issue na GitHub z pięknym udokumentowaniem błędu i debugiem jest IMVHO większy, niż poprawka w kodzie. W każdym razie widać, że warto commitować i poprawiać takie drobne błędy.

VSCodium na Debianie

Jak pisałem wcześniej, nadchodzi koniec edytora Atom. Z pewnych względów, na maszynie służbowej i tak zacząłem korzystać z Visual Studio Code . Dlatego postanowiłem przyspieszyć proces migracji także na prywatnej maszynie. VSC nie było złe, więc zgodnie z zapowiedzią dałem szansę VSCodium.

Czym jest VSCodium?

VSCodium to fork microsoftowego Visual Studio Code, zbudowany z otwartego kodu źródłowego, dostępny na wolnej licencji. Dodatkowo pozbawiony dodatków od Microsoft służących do zbierania telemetrii/śledzenia. Poza tym, wszystko powinno działać tak samo.

VSCodium logo
Źródło: https://vscodium.com/

Instalacja VSCodium

Na początek instalacja pod Debianem. Z tego co widzę, na Ubuntu będzie identycznie. Szczęśliwie dostępne jest repozytorium pakietów deb. Skorzystałem z opisu instalacji spod tego linka: https://www.linuxcapable.com/how-to-install-vscodium-on-debian-11-bullseye/. Wersja skrócona poniżej.

Dodajemy klucz GPG do zaufanych:

curl https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo/raw/master/pub.gpg | gpg --dearmor > /etc/apt/trusted.gpg.d/vscodium.gpg

Dodajemy źródło pakietów:

echo "deb https://download.vscodium.com/debs vscodium main" > /etc/apt/sources.list.d/vscodium.list

Po tym zostaje już tylko aktualizacja danych o repozytoriach i instalacja pakietu codium:

apt update; apt install codium

Wtyczki z marketplace

Nieprzypadkowo napisałem, że wszystko powinno działać tak samo. Słowo powinno powinno dać do myślenia. Otóż po instalacji pozwoliłem sobie „ściągnąć” konfigurację, a w zasadzie używane wtyczki, z marketplace od kolegi z pracy, korzystającego z VSC. Mocno się zdziwiłem, bo większość potrzebnych wtyczek, tych od Microsoft, nie była w VSCodium dostępna do instalacji. Nie drążyłem wtedy tematu i po prostu zainstalowałem VSC.

Jednak po szybkim zbadaniu tematu okazuje się, że nie ma najmniejszego problemu z korzystaniem z marketplace Microsoft w VSCodium. Zgodnie z tym, co piszą w dokumentacji, wystarczy w pliku

~/.config/VSCodium/product.json

dodać stosowną zawartość, czyli:

{
  "extensionsGallery": {
    "serviceUrl": "https://marketplace.visualstudio.com/_apis/public/gallery",
    "cacheUrl": "https://vscode.blob.core.windows.net/gallery/index",
    "itemUrl": "https://marketplace.visualstudio.com/items",
    "controlUrl": "",
    "recommendationsUrl": ""
  }
}

I możemy cieszyć się dostępem do wtyczek zupełnie jak w Visual Studio Code.

Wtyczki

Nie ukrywam, że bardziej podobało mi się działanie wtyczek w Atomie. Na przykład isort wywołany tamże po prostu sortował wszystkie importy. W przypadku VSC nie ma tak dobrze. Z tego co udało mi się znaleźć, można „naprawić” pojedynczy import.

Istnieje obejście, które jest podpowiadane w opisie konfiguracji wtyczki, czyli dodanie do settings odpowiedniej sekcji. Jest to nieco nieintuicyjne, bo w czytamy to będąc w… ustawieniach, czyli settings. Chodzi jednak o inne settings. Jak znalazłem pod tym linkiem, trzeba zmienić zawartość pliku

~/.config/Code/User/settings.json

Na razie tyle. Z doświadczeń w pracy wynika, że spokojnie da się żyć z VSC zamiast Atoma. Na razie pracuje mi się w VSC gorzej, ale raczej chodzi o drobną zmianę przyzwyczajeń i dokładniejsze poznanie nowego programu. Z wyboru zamiennika jestem wstępnie zadowolony.

Goodbye Atom

W roku 2014 pojawił się a hackable editor for the 21st century czyli Atom. Od początku mnie zaintrygował. Był to edytor międzyplatformowy, open source, działający w GUI, reklamowany jako rozszerzalny… Samo dobro. Pobrałem i… skasowałem, ze względu na rozmiar. Ważył bowiem grube kilkadziesiąt MB, co wydało mi się sporą przesadą.

Screenshot ze strony projektu
Screenshot ze strony projektu. Źródło: https://atom.io/

Później jednak przekonałem się do Atoma, a nawet go polubiłem. Uzbrojony w pluginy był bardzo przyjemnym narzędziem wspomagającym edycję różnych formatów plików. Więcej, niż edytorem, bardziej traktowałem go jako IDE. Choć z rasowymi IDE nie mam doświadczenia. Czy to Python, Puppet czy zwykłe YAMLe – wszystko edytowało się przyjemnie, ze stosownym kolorowaniem, linterami itp. Pamiętam, że na jednym ze szkoleń z Pythona śmiało współzawodniczył z PyCharm. IIRC wówczas jednej rzeczy nie dało się zrobić w Atomie, i jednej w PyCharmie. W każdym razie, niczego mi w Atomie nie brakowało.

Dlatego w ogłoszeniu o wygaszeniu projektu zdanie Atom has not had significant feature development for the past several years wydaje mi się dwuznaczne. Skoro program ma wszystko, co potrzebne, to co tu rozwijać? No i jeśli oparty jest o wtyczki – a tak było w przypadku Atoma – to ficzery w samym programie też stają się drugorzędne.

Tak czy inaczej, decyzja mnie nie dziwi. Skoro Microsoft ma swoje Visual Studio Code, to będzie je promował, więc po co mu wewnętrzna konkurencja? Artykuł wspomina właśnie VSC jako alternatywę. Zapewne nieprzypadkowo. Z drugiej zaś strony jak robiłem przegląd ewentualnych alternatyw w głowie, to VSC jak najbardziej się pojawiło.

Nie ukrywam, że mam pewien sentyment do Atoma i parę wspomnień z nim związanych. Towarzyszył mi przy nauce Pythona, która zbiegła się ze zmianą pracy. Był nieodłączną częścią DSP2017.

Potem spojrzałem na listę alternatyw i… nie jest wiele lepiej. Nie widzę żadnego następcy czy też zastępcy. Chwilowo najbardziej skłaniam się ku wolnej wersji VSC czyli VSCodium. Ale to bez pośpiechu. W końcu Atom jest open source, więc może jednak okaże się, że będzie utrzymywany.

UPDATE Polecę jeszcze wpis, który właśnie przeczytałem. Nie o edytorze, a o desktopie, ale jest i o edytorach (vim).