Jakub Raczkowski 
„Przez ostatnie tygodnie łyknąłem maaasę teorii, która jak to powietrze w nadmuchanym do ostateczności baloniku, szuka ujścia” – tymi słowami podsumowałem niedawno wstrzymany cykl „Czym jest…?”. Teraz nadszedł czas aby wziąć szpilkę, rozpuknąć balon i sprawdzić co było w środku.
Kontynuując modę zapoczątkowaną w cyklu „Czym jest…?” zacznijmy od najważniejszego:
Czym tak właściwie jest tytułowy projekt?
„Gaminatorium” jako koncept, to w zasadzie odpowiedź na pytania nurtujące mnie w trakcie procesu przebranżowienia, a mianowicie:
1. Jak najwydajniej uczyć się programowania?
Aby dobrze pisać kod, trzeba pisać kod. Przeczytałem kilka książek, obejrzałem kilkadziesiąt kursów wideo, a odsłuchanych podcastów i przejrzanych artykułów nawet nie chce mi się liczyć. Ale to wszystko i tak tylko dodatek do właściwej nauki czyli odpalenia IDE, stworzenia klas, metod i zmiennych, a finalnie transformacji ich w coś co ma ręce, nogi i działa.
Gaminatorium jest właśnie takim długofalowym projektem, ukierunkowanym na praktyczne użycie uprzednio poznanej teorii.
2. Jaki projekt będzie najlepszy?
Własny. Coś co rozwiązuje twój osobisty problem będzie twoim najlepszym motywatorem.
A co jeśli nie masz pomysłu na nic takiego?
Można posiłkować się prostymi appkami z tutoriali – listy zadań, sklepy, bieda-wersje serwisów społecznościowych, ale to najczęściej proste aplikacje typu CRUD ze szczątkową logiką, które na nikim nie zrobią wrażenia. Będzie to żmudne, odtwórcze i zwyczajnie nudne.
Moim zdaniem dobrze zacząć jest od zaimplementowania jakiejś popularnej gry. Ty decydujesz co to ma być, jak to ma wyglądać i ile czasu chcesz na to poświęcić. Masz kilka tygodni? To robisz Snake’a albo prostą karciankę dla jednej osoby. Chcesz projekt na cały rok? Spróbuj stworzyć własną wariację na temat Monopoly: dla wielu graczy, z botami, z komunikacją asynchroniczną, rozbudowanymi testami i systemem osiągnięć zorientowanym aspektowo. Twój wybór.
3. Co zrobić z gotowym projektem?
Kiedy „ugotujemy” coś nowego czujemy satysfakcję… która szybko przemija. Bawimy się chwilę swoim dziełem, testujemy, dodajemy parę kosmetycznych zmian i tyle. Kod spada na najniższy krąg GitHuba, porzucony i zapomniany przez swojego stwórcę. Prawie jak w Biblii.
Ale przecież nie musi tak być.
A co gdyby powstała strona gdzie tym kodem można się pochwalić? Dać do przejrzenia innym zainteresowanym i otrzymać feedback? Albo samemu przeglądać różne prace szukając inspiracji?
Tak. Ale zastanówcie się – jak często wchodzicie na GH i przeglądacie kod nieznajomych deweloperów? Scrollujecie go jak Instagrama? Swipe’ujecie w prawo jak ciacha na Tinderze? Wpadacie tam na chwilę relaksu?
4. Jak budować swoje portfolio przez lata?
Ktoś zapyta: A po jaką cholerę? Co to, ja grafik jestem?!
Portfolio przydaje się przy znalezieniu pierwszej pracy, a potem i tak każdy rekruter patrzy przede wszystkim na doświadczenie zawodowe. Możesz przez 10 lat siedzieć przy kodzie „legacy”: klepiąc cały czas te same formułki, a w oczach pracodawcy i tak wyjdziesz na eksperta, który wart jest więcej niż mid z 3-letnim doświadczeniem, za to w 3 różnych projektach.
Jeśli też tak myślisz i marzysz o wejściu do IT żeby znaleźć swój przytulny etacik na którym nikt od ciebie nie będzie za dużo wymagał to niestety kolego, ale mam dla ciebie przykrą wiadomość:
Będziesz pierwszy do odstrzału kiedy AI wjedzie na pełnej ku*wie.
Praca w IT == ciągły rozwój. Przyjdzie taki czas, że zadania na cały 8-godzinny dzień pracy zaczniesz ogarniać w 2-godziny. Ale to wcale nie znaczy, że pozostałe 6 to tzw. „dupo-godziny” które możesz przeznaczyć na pogaduchy i społecznościówki. Wykorzystaj je na własne projekty, eksperymentuj z różnymi technologiami, baw się nimi i ucz jednocześnie.
5. Gdzie znaleźć kolegów do wspólnego programowania?
Większość z nas zaczynała od robienia tego samemu. Czujemy się wtedy komfortowo: nikt nie patrzy, nikt nie ocenia, nikt się nie wtrąca. Skupiamy się na tym, aby to nam się podobało. I nawet wydaje się nam, ze jest cudownie. Ale każdy kto choć raz zakosztuje zabawy w towarzystwie, wie że różnica jest kolosalna, a powrót do gry solo staje się ostatecznością.
Dokładnie tak samo jest z pisaniem kodu. ( ͡° ͜ʖ ͡°)
Warto budować swoją sieć kontaktów już od pierwszych chwil, jak tylko złapiemy bakcyla. Prędzej czy później przyjdzie bowiem taki moment, że będziemy potrzebować kogoś kto przejrzy nasz kod, poradzi jak dobrze skroić CV, a może nawet zaoferuje współpracę. Stara prawda jest wciąż aktualna:
Ważniejsze od tego co potrafisz,
jest to kogo znasz.
Ok, to podsumujmy co mamy do tej pory. Gaminatorium jawi się jako miejsce w sieci gdzie:
- możemy dodawać własne projekty-gry, tak aby inni użytkownicy mogli je sprawdzić i przejrzeć kod źródłowy
- w powyższy sposób możemy budować własne portfolio projektów, oprócz linka do repo na GH będzie można wrzucić w CV link do profilu na Gaminatorium
- możemy budować sieć znajomych rozpoczynając własny projekt i ogłaszając nabór do współpracy, albo dołączając do już istniejącego
W skrócie:
Gaminatorium = Kurnik + WordPress + Blablacar
Kurnik? Może kojarzycie stronę kurnik.pl z grami karcianymi, planszowymi i pokrewnymi. Można wejść tam na chwilę, pograć z nieznajomymi w Makao albo szachy i wrócić do codziennych obowiązków. Chciałbym aby tym właśnie stało się Gaminatorium dla osób nietechnicznych.
WordPress? Jeśli rozejrzycie się po tej stronie, zobaczycie masę tekstów na przeróżne tematy które łączy ze sobą postać autora i forma: tekst. Pragnę stworzyć coś podobnego, ale w miejsce tekstu wrzucałoby się własnoręcznie wymodelowane minigry – otwarte na testy, analizę kodu źródłowego i komentarze społeczności.
Blablacar? Planowana jest osobna sekcja gdzie twórcy będą mogli ogłaszać swoje projekty jednocześnie zachęcając innych do współpracy. Zupełnie jak w Blablacar – oferujesz, że jedziesz w konkretnym kierunku i możesz zabrać ze sobą kilka osób.
A jak to będzie wyglądać od strony technicznej?
Jest takie porzekadło, nawet nie tylko w IT, że każdy duży problem można rozwiązać poprzez podzielenie go na kilka mniejszych problemików. Idąc tym tokiem rozumowania zdecydowałem się na architekturę rozproszoną, czyli:
Mikroserwisy
Próbując stworzyć monolit zamknąłbym się w jednym języku programowania i jednym frameworku, za to rozbijając strukturę na zestaw serwisów luźno połączonych z bazą, umożliwiam innym twórcom samodzielny wybór środowiska. Nie będzie żadnego przeciwskazania żeby jedna gra była w całości napisana w Node.js i React, inna w Pythonie z Django, a trzecia w samym Java Script. Warunkiem jest aby były to aplikacje fullstack zawierające w sobie zarówno logikę jak i front.
Zaś co do wspomnianej „bazy” czyli głównego serwisu spinającego to wszystko w całość, to tutaj będę miał okazję wykorzystać prawie wszystkie technologie, które omówiłem do tej pory w cyklu „Czym jest…?”, mianowicie:
- Java 21 w parze z Gradle i Spring Boot
- baza SQL na Postgres obsługiwana przez Hibernate (+ Liquibase)
- autoryzacja przeprowadzana z udziałem Keycloak’a
- konteneryzacja za pomocą Docker/Docker Compose
- automatyzacje CI/CD w Jenkinsowych pipeline’ach
- RabbitMQ pośredniczący w wymianie wiadomości pomiędzy serwisami
- testy z JUnit i Mockito (i gościnnym występem Spocka)
- w planach także przećwiczenie Kubernetesa
Zaraz, zaraz! A co z frontem?!
Zacznę zagadką:
Mamy dwa identyczne projekty. Pierwszy jest tworzony przez jedną osobę, to ona zajmuje się architekturą, logiką, bazami, devopsami i frontem. Ukończenie aplikacji zajmuje jej pół roku.
Drugi projekt jest tworzony przez kilkuosobowy zespół gdzie każdy programista odpowiada za swoją dziedzinę. Praca idzie szybko i mają gotowe MVP w jeden kwartał.
Który programista jest wart więcej: ten który sam robi wszystko, czy ten co jest częścią zespołu i obrabia tylko swoją działeczkę?
???
No właśnie, wbrew logice: ten drugi, który de facto mniej się napracował. Ale właśnie o to chodzi, żeby nie odpowiadać za wszystko samemu, tylko opanować współpracę – dokładnie tak jak się to robi komercyjnie.
Tworząc ITCandidateEvaluator za wszystko wziąłem się własnoręcznie. Efekt? Projekt na nikim nie zrobił wrażenia – był mały, a użyte technologie przestarzałe. Gdybym wtedy pracował w zespole, nie dość że rezultat byłby o niebo lepszy, to jeszcze mniej bym się napocił, a więcej nauczył.
Dlatego tym razem nie jestem samolubem,
przed wyruszeniem w drogę zebrałem drużynę.
Na chwilę obecną frontendowcy Gaminatorium już ogarnęli koncept artystyczny w Figmie, modelują grafiki i tworzą szkielet architektury w React.JS. Więcej szczegółów nie podam, bo to nie moja domena i nie chcę palnąć jakiejś głupoty.
Coś jeszcze?
Myślę, że to by było na tyle. Obecnie całą swoją uwagę poświęcam Gaminatorium, dlatego blogowanie idzie niejako w odstawkę – spodziewajcie się maksymalnie dwóch wpisów na miesiąc. Co prawda nie będę opisywał kolejnych kroków w rozwoju tego projektu (tak jak to robiłem z poprzednikiem), ale za to pojawią się kolejne odcinki z serii Czym jest…? w miarę jak będę poznawał te technologie podczas prac nad serwisem. W planach takie tytuły jak:
- Czym jest Swagger?
- Czym jest Keycloak?
- Czym jest Postgres?
- Czym jest Spock?
- Czym jest Groovy?
O tych pojęciach już, co prawda, wspominałem we wcześniejszych artykułach, ale zawsze w ramach ciekawostki – tym razem skupimy się na detalach.
Kiedy piszę te słowa, prace nad Gaminatorium trwają już od trzech tygodni, a nasza drużyna liczy 6 osób: trójka Javowców (w tym ja) zajmuje się tworzeniem logiki oraz API, natomiast pozostali ogarniają HTML, CSS, JavaScript i REACTA.
Ale miejsca dla nowych członków zespołu wciąż są.
Jeśli jesteś zainteresowany wzięciem udziału w opisanym projekcie, a ponadto czujesz się na siłach dołożyć swoje trzy grosze do wspólnego kodu to skontaktuj się ze mną (najlepiej za pośrednictwem mojego profilu na LinkedIn). Z góry uprzedzam, że Gaminatorium to twór open-source, niekomercyjny i czysto hobbystyczny więc nie mogę zaoferować nic poza wsparciem i pozytywną atmosferą.
