Trzy ostatnie dni spędziłem na konferencji wroc_love.rb w moim rodzinnym mieście, w związku z czym czasu na pisanie bloga i rozwijanie projektu było niewiele. Nie zamierzam teraz wstawiać podsumowania całej konferencji (prawdopodobnie stanie się to na blogu głównym), jednak chciałem w jakiś sposób nawiązać do tego wydarzenia. Stanie się to za pośrednictwem pewnego lightning talka.

Zanim jednak przejdę do rzeczy, krótkie wprowadzenie. Zawsze bardzo ceniłem ludzi, dla których programowanie nie jest celem samym w sobie. Mam tu na myśli osoby, które z wykształcenia są kim innym, niż informatykiem (lub mają dodatkowe wykształcenie). Pozwala to nie tylko na świeższe spojrzenie, lepsze rozumienie niektórych domen itd., ale też stwarza warunki dla mariażu różnych, wydawałoby się bardzo odległych dziedzin, co bardzo często daje fascynujące rezultaty.

Autorka talka, o którym wspominałem, jest psychologiem z wykształcenia, nazywa się Gosia, jest programistką i, jak się właśnie dowiedziałem, również startuje w Daj Się Poznać. Jej prezentacja była co prawda o mentoringu młodszych programistów, a właściwie o jednym jego aspekcie, ale myślę, że równie dobrze można go odnieść do takich indywidualnych projektów, jakie wykonujemy na DSP.

Instant reward

Powyższe sformułowanie kiedyś bardzo często pojawiało się w tutorialach do rozmaitych frameworków czy bibliotek, podkreślając że możemy bardzo szybko podziwiać rezultaty swoich działań. Rzeczywiście, dzisiejsze programowanie nie przypomina nijak np. programowania WinAPI w C, gdzie, o ile pamiętam, trzeba było napisać tonę boilerplate'u, by tylko zobaczyć puste okno. Obecnie zwykle bardzo szybko przechodzimy do kodowania właściwej logiki biznesowej (ciekawych rzeczy), o czym zresztą już pisałem.

To dobrze. Gosia bowiem mówiła o mechanizmie nagrody za wysiłek, nawiązując przy tej okazji do prac Pawłowa1. Przekonywała nas (moim zdaniem bardzo słusznie), że początkującym programistom należy tak dobierać zadania, by mogli stosunkowo szybko zobaczyć efekt swojej pracy. Podobnie moim zdaniem powinniśmy traktować siebie, kiedy planujemy sobie roadmap naszego projektu na DSP.

Pisał o tym zresztą Konrad Kokosa, sugerując stosowanie zasady Minimal Viable Product. Chodzi zasadniczo o dokładnie to samo – aby tak planować prace, by widać było efekty działań, a nie realizując wyznaczony długofalowy plan, licząc że na koniec wszystko się uda i zadziała (na 90% się albo nie uda, albo się zniechęcimy po drodze).

Przestrzegam jednak przed opacznym rozumieniem tego fragmentu:

Nie brniemy w tygodniowe wybieranie idealnej biblioteki, idealnej architektury, idealnej nazwy i idealnego wszystkiego innego. Piszemy szybko działający prototyp i później go rozwijamy.

Nie róbmy byle jak! Decyzje projektowe podjęte na początku często rzutują bardzo mocno na kształt całości i cholernie trudno może je być odkręcić2. Dlatego nad pewnymi kwestiami warto się pochylić na dłużej, by nie popełnić błędu, który sprawi w przyszłości tyle problemów, że będziemy gotowi rzucić projekt i wyjechać w Bieszczady.

Co tam w projekcie?

Na razie niewiele, jeśli ktoś spojrzy na historię commitów na Githubie. Rzeczywiście, postępu mierzonego w LOC3 nie ma. Stoję jednak właśnie przed jedną z poważnych decyzji, które mogą w dużym stopniu decydować o kształcie całości.

Aby mieć w mojej aplikacji odświeżanie relacji na żywo, mogę zastosować trzy podejścia:

  • Polling – technika sprawdzona, ale niezbyt nowoczesna, często stosunkowo kosztowna (dużo niepotrzebnych requestów), mało fascynująca i nie przekazująca zmian w czasie rzeczywistym. To ostatnie jednak nie skreśla jej całkowicie, gdyż w przypadku transmisji tekstowej opóźnienia rzędu 5-10 sekund nadal można uznać za "na żywo".
  • WebSockets – modne, zgrabne, wydaje się naturalnym wyborem. Ale... WebSockety wnoszą do projektu swoje problemy. Jakie? O tym może w osobnym poście, jednak pewne ich aspekty sprawiają, że wydają mi się nie być najlepszym wyborem. Dodatkowo potęguje to uczucie fakt, że w zasadzie nie potrzebuję komunikacji dwustronnej.
  • Server-Sent Events – rzecz z którą dotychczas do czynienia nie miałem. W tym momencie wydają się być naturalną odpowiedzią na moje potrzeby, ale muszę wykonać jeszcze pewien research na ich temat, nim podejmę tę decyzję.

I tak to mniej więcej wygląda. Mam nadzieję, że ten blokujący moment rozwoju projektu uda się szybko zostawić za sobą i przejść do bardziej bezstresowych faz programowania. Tymczasem jednak najpierw muszę odespać konferencyjny networking z ostatnich dwóch nocy ;)


  1. Tak, tego od psów. 

  2. Chyba że ma się potwornie dużo samodyscypliny, by dokładnie wszędzie stosować maksymalnie dużo abstrakcji, tak aby z każdą decyzją wiązać się jak najmniej. To jednak oddala znacząco perspektywę zobaczenia rezultatów swoich działań. 

  3. Lines of Code