DevCrowd 2014 – wrażenia

Wczoraj, 12 kwietnia odbyła się kolejna edycja szczecińskiej konferencji DevCrowd. Ogólnie rzecz biorąc uważam ją za bardzo udaną. Prawie każda prezentacja na której byłem podobała mi się. W tym wpisie chciałbym się podzielić kilkoma moimi refleksjami. Dotyczyć będą one przede wszystkim prezentacji, które najbardziej mi się podobały.

Na początku dwa słowa na temat organizacji samej imprezy. Stała ona na równie wysokim poziomie jak i same prezentacje. Właściwie nie ma się do czego przyczepić, może poza tym, że godziny wykładów się nieco rozjechały w stosunku do pierwotnego harmonogramu, ale to tylko szczegół.

Warto odnotować, że chyba po raz pierwszy dostępna była aplikacja mobilna w której można było oznaczyć sobie prezentacje które chciało się obejrzeć, oraz później je ocenić. Aplikacja powiadamiała odpowiednio wcześniej o zbliżającym się terminie rozpoczęcia prezentacji.

A teraz konkrety.

Designing API for Mobile App

HATEOAS - fajny czy nie fajny?
HATEOAS – fajny czy nie fajny?

Moja znajomość pisania oprogramowania mobilnego nie wychodzi poza poziom “Hello World”, liczyłem więc, że poznam perspektywę osób na codzień piszących takie aplikacje (w sensie, że mobilne – nie “Hello World”).

Prezentacja została poprowadzona przez Maćka Opałę i Wojtka Erbetowskiego. Wyszło to bardzo fajnie, chłopaki prezentowali poszczególne zagadnienia na zmianę. Zabieg ten nie pozwalałby się nudzić, nawet jeżeli sama prezentacja byłaby nieciekawa (a tak nie było!). Tłem prezentacji był jeden z systemów, które Maciek i Wojtek rozwijali w firmie w której pracują, co niejako narzuciło na prezentację konwencję “lesson learned”.

Wystąpienie rozpoczeło się od przedstawienia popularnych problemów z programowaniem aplikacji mobilnych łączących się z backendem za pomocą RESTa. Duży overhead nagłówków protokołu, czy też konieczność wysyłania całego obiektu w ramach żądania PUT (nawet jeśli potrzebujemy zaktualizować tylko jedną małą rzeczy),  to tylko niektóre z problemów.

Same platformy mobilne również nie rozpieszczają twórców –  z jednej strony review aplikacji może trwać bardzo długo a z drugiej i tak nie można zmusić użytkownika do aktualizacji do najnowszej wersji naszej aplikacji. Może to być duży problem w momencie gdy np. odkryje się błąd związany z bezpieczeństwem. Telefony same w sobie również wprowadzają pewne komplikacje – wolny procesor i słaba bateria to coś z czym trzeba się liczyć.

Rozwiązanie, które proponują chłopaki to zastosowanie cienkiego klienta (thin client) po stronie aplikacji na telefonie, tak aby jak największa część logiki znajdowała się po stronie backendu. Dzięki temu większość zmian będzie wprowadzana po stronie serwerów nad którymi mamy pełną kontrolę – możemy więc deployować często i nie czekać na zakończenie procesu review.

Z drugiej strony należy dążyć do tego aby dane pobierane przez telefon były absolutnym i niezbędnym do funkcjonowania aplikacji minimum. Json zamiast XMLa, czy kompresja gzip to tylko najbardziej oczywiste przykłady. Maciek i Wojtek słusznie jednak zauważają, że zawsze należy dokładnie się zastanowić czy optymalizacja, którą chce się wprowadzić, przynosi zysk. Czasem zdarza się tak, że będzie wręcz odwrotnie – przykładowo próba kompresji bardzo małego Json’a może spowodować, że będzie ważył więcej niż przed kompresją.

StackOverflow, GitHub i twitter jako narzędzia profesjonalnego rozwoju programisty

O co chodzi w GitHubie
O co chodzi w GitHubie

Dla mnie absolutny numer jeden tegorocznej konferencji. Jacek Laskowski opowiadał w jaki sposób wykorzystać potencjał narzędzi społecznościowych do samorozwoju programisty. Prezentacja skupiała się na trzech chyba najbardziej znanych serwisach dla developerów: StackOverflow, GitHub i Twitter, jednak wspomiał też o kilku innych. Każdy z tych serwisów ma troche inną filozofię, służy do innych celów, wymaga trochę odmiennego podejścia, dając przy tym odmienne korzyści.

Jacek rozpoczynał omówienie tych serwisów od dokładnego przedstawienia filozofii działania każdego z nich. Następnie przedstawiał w jaki sposób korzysta z tych serwisów aby na koniec podsumować korzyści jakie z tego wynikają.

Na pierwszy ogień poszedł Stack Overflow. Jeżeli miałbym podsumować ten serwis na podstawie prezentacji Jacka to powiedziałbym, że jest to serwis promujący filozofię “małych kroczków”. Chodzi o to, że nawet jeżeli nie znamy odpowiedzi na czyjeś pytanie to i tak jesteśmy wstanie dorzucić swoją “cegiełkę”, dzięki czemu ktoś uzyska szybciej odpowiedź:

  • Odpowiedź na pytanie nie jest nam znana, ale samo pytanie wydaje nam się wartościowe? Możemy je upvote’ować. Może wtedy więcej osób się nim zainteresuje.
  • Nie do końca rozumiemy pytanie? Możemy je skomentować prosząc autora o wyjaśnienia. Może dzięki temu pytanie stanie się jaśniejsze dla kogoś kto zna dane zagadnienie.
  • Pytanie jest w jakiś sposób nieczytelne (np. zawiera błędne formatowanie)? Zaproponujmy autorowi edycję. Może teraz będzie je łatwiej przeanalizować?

Serwis na każdym kroku zachęca nas nawet do interakcji za pomocą systemu reputacji i odznak. Nasz profil przedstawia wszystkie zdobyte przez nas “nagrody” przez co staje się swego rodzaju CV dokumentującym naszą wiedzę. System reputacji i odznak pozwala osobie postronnej (dajmy na to naszemu przyszłemu pracodawcy ;) na szybkie zorientowanie się “z kim ma doczynienia”.

Ale przecież możemy nie tylko odpowiadać na cudze pytania, ale również zadawać swoje – może to być świetne uzupełnienie standardowego zdobywania wiedzy (np. książkowej, czy z dokumentacji), ponieważ możemy poznać opinie wielu różnych osób, często dużo bardziej doświadczonych od nas w danym zagadnieniu.

Kolejny przedstawiony serwis to GitHub. W pewnym sensie “filozoficznie” jest on bardzo podobny do StackOverflow, ale skupia się bardziej na kodzie. Również i tutaj metodą “małych kroczków” za pomocą mechanizmu pull requestów możemy ulepszać cudze projekty (nawet jeżeli miało to by być jedynie poprawieniem literówki, czy usunięciem warning’a na etapie kompilacji).

Możemy się tutaj również dzielić ze światem swoim kodem. W tym samym momencie dajemy szansę innym by nam pomogli (każdy może zaproponować poprawki mechanizmem pull requestów), ale też możemy innym pomoć (bo być może nasz kod będzie dla kogoś wartościowy)

Nasz profil na GitHubie też jest swego rozdaju CV – ale bardziej pokazującym jak wykorzystujemy naszą wiedzę w praktyce pisząc kod.

Ostatnim ważnym serwisem o którym mówił Jacek jest Twitter. Tutaj z koleji ciężar jest położony na zupełnie co innego – mianowicie na komunikację z innymi. Wielką siłą tego serwisu jest ogromna łatwość w komunikacji – niezależnie od tego czy chcemy się podzielić czymś wielkim, czy zwyczajnym – wystarczy wysłać twitta. Niezależnie od tego czy chcemy skontaktować się z twórcą Scali, czy kolegą z pokoju – wystarczy wysłać twitta (no może do kolegi z pokoju łatwiej będzie po prostu się odezwać ;). Działa to też w drugą stronę i tak samo łatwo jest innym kontaktować się z nami.

Szczerze mówiąc o ile filozofia i styl działania StackOverflow i GitHuba są dla mnie jasne, o tyle narazie nie do końca jestem w stanie odnaleźć się na Twitterze.

Poza tymi serwisami Jacek po wspominał krótko o innych: Reddit, Coursera, Travis, czy też program MEAP wydawnictwa Meaning. To wszystko sprowadza się w zasadzie do dwóch rzeczy:

  • Wchodź w interakcje z innymi. Możesz tym samym zarówno komuś pomóc jak i dać pomóc sobie.
  • Nie bój się pytać i popełniać błędów. Każdy ekspert kiedyś zaczynał od najprostszych przykładów i choć dobrze jest dzielić się swoją wiedzą, to chyba nawet lepiej jest móc pokazać ścieżkę którą się szło aby tą wiedzę uzyskać

Jak pracować i nie zwariować

Surowa estetyka slajdów Koziołka ;)
Surowa estetyka slajdów Koziołka ;)

Bartek Kuczyński znany jako Koziołek opowiadał jak stworzyć sobie warunki do wydajnej pracy. Prezentacja dotyczyła trzech obszarów:

  • Hardware – czyli sprzętu z którego korzystamy.
  • Software – czyli oprogramowania którego używamy w developmencie.
  • Bioware – czyli nas samych.

Koziołek mówił o trzech najważniejszych narzedziach programisty: krześle, klawiaturze i myszy. W miarę możliwości nie warto na nich oszczędzać, gdyż to głównie one mogą mieć wpływ na stan naszego zdrowia. Mając już świetne krzesło i wygodną klawiaturę oraz mysz warto zaopatrzyć się w dysk ssd a zaraz po nim w jak najwięcej ramu i drugi monitor.

Jeśli chodzi o oprogramowanie to ważne są dwie kwestie. Po pierwsze należy jak najlepiej opanować software. Najlepiej codziennie uczyć się w jaki sposób coś można wykonać prościej, np. skrótem klawiszowym, bądź jakąś fajną wtyczką do naszego IDE (np. Infinitest ;) Jak już staniemy się Eclipse ninja to warto przyjrzeć się wzorcom naszej codziennej pracy i zastanowić się jak ją możliwie jak najbardziej zautomatyzować. Odpalasz co dziesięć minut mvn clean install -DskipTests ? No to może owrappować tą komendę w jakiś skrypt? Lubisz TDD? No to może zainstaluj Infinitest ;)

Ostatnim, aczkolwiek nie mniej ważnym punktem prezentacji była sama osoba programisty. Hasło, które padło podczas wystąpienia koziołka “Programista też człowiek” w zasadzie dobrze podsumowuje spory fragment tej części prezentacji – istnieje mnóstwo irytujących rzeczy, które potrafią skutecznie utrudnić/obrzydzić codzienną pracę – czy to sprawy na pozór mało ważne jak psujący się ekspres do kawy, czy też duże problemy takie jak regularne zostawanie po godzinach. Ważne jest też, aby być “mądrze asertywnym”, to jest umieć negocjować wyjścia z niefajnych sytuacji (Mówisz szefie, że jutro demo dla klienta i muszę zostać po godzinach, żeby wszystko ponaprawiać? Ok, ale może w takim razie jutro po demie mógłbym pójść do domu?).

Ważne jest też aby mieć możliwość “twardego resetu” innymi słowy dobrze jest mieć coś co pozwala nam zapomnieć o pracy np. fajne hobby. Dzięki temu unikniemy wypalenia i będziemy szczęśliwszymi ludźmi.

Javascript development done right

JavaScript jest tak strasznym językiem, że nawet nie dało się złapać focusa ;)
JavaScript jest tak strasznym językiem, że nawet nie dało się złapać focusa ;)

Paweł Szulc opowiadał o tym jak programista Javy powinien radzić sobie z traumą przejścia na Mordo… JavaScript. Wszystko sprowadza się do tego, że mimo iż składniowo oba te języki są momentami bardzo do siebie podobne, to jednak podobieństwo jest tylko pozorne.

Cała prezentacja była przeglądem najbardziej problematycznych z punktu widzenia programisty Javy, koncepcji JS. Funkcje, Zakresy, mechanizm Hoistingu, Domknięcia, Obiekty i Moduły to główne punkty tej prezetnacji. Najważniejsze to pamiętać, że mimo podobieństw w nazwach i momentami podobnej składni – Java i JavaScript opierają się na innych koncepcjach a to samo pojęcie może być w nich zupełnie inaczej definiowane.

O ile o samej treści prezentacji wystarczy powiedzieć, że była to solidna porcja technicznej wiedzy, o tyle nie sposób się nie zatrzymać przy samym sposobie prowadzenia prezentacji. Paweł jest świetnym prelegentem i nie dość, że bardzo jasno przekazuje swoje myśli, to na dodatek jego prezentacje są wypełnione po brzegi dobrym humorem. Nie inaczej było i tym razem.

Scrum, but…

Pretendent do najśmieszniejszego slajdu konferencji
Pretendent do najśmieszniejszego slajdu konferencji

Matt Harasymczuk podzielił się swoimi spostrzeżeniami na temat najczęstszych błędów związanych z prowadzeniem projektów wg. metodyki Scrum. Opowiadał o różnicach między faktyczną ideą poszczególnych spotkań a tym w jaki sposób są one często rozumiane i realizowane w zespołach. Główny nacisk był tu położony na Daily Meetingi, Grooming i Retrospektywy.

Matt pokazywał również jak błędnie niekiedy jest rozumiany Agile Manifesto, który wcale nie polega na odrzuceniu wszystkich “starych” narzędzi (“prawa strona” manifestu) – a wręcz przeciwnie, należy je szanować nawet jeżeli wyżej się ceni narzędzia zwinne (“lewa strona” manifestu).

Wykład traktował również o typowych problemach, takich jak przychodzące w środku sprintu “wrzutki” (czyli zadania wrzucane przez szefa “na wczoraj”), albo problemy związane z brakiem interdyscyplinarności w zespole.

Jeżeli spróbować podsumować ideę tej prezentacji to można powiedzieć, że należy zrozumieć, że wybiórczy wybór niektórych elementów ze Scruma raczej nie przyniesie nam wiele dobrego, ale z drugiej strony dogmatyczne trzymanie się Scrum Booka również nie – bo Scrum nie jest lekarstwem na całe zło.

Mam też pewne przemyślenia związane z samym stylem prowadzenia tego wykładu. Sposób mówienia Matta przypominał nieco księdza prawiącego kazanie z ambony. Sprawiał wrażenie, że przyszedł ewangelizować w temacie Scruma, co jakoś podświadomie nastawiało mnie w opozycji do tego co mówił. Na szczęście bardzo szybko okazało się, że Matt przyszedł podzielić się rzetelną i bardzo ciekawą wiedzą. Ciekawostką niech będzie fakt, że Matt skończył swoją prezentację idealnie co do minuty mieszcząc się w wyznaczonym czasie :D

Króciutką wersję tej prezentacji można zobaczyć tutaj:

How To Tackle Java EE 7

Adam Bien zdalnie
Adam Bien zdalnie

Ostatnią z prezentacji tego dnia był występ Adama Biena. Miałem trochę obaw odnośnie tej prezetacji, gdyż była to prezentacja zdalna. Na szczęście nie było żadnych problemów z połączeniem, obraz z rzutnika był dobrej jakości a dźwięk wyraźny. Taka a nie inna forma prezentacji sprawiła, że interakcja między Adamem a słuchaczami była lekko opóźniona (pytania można było wysłać Adamowi na Twittera), ale w zasadzie wszystko poszło sprawnie.

Adam opowiadał o aplikacjach EE 7, ale w pewien przewrotny sposób. Mianowicie dowodził, że należy skupić się na logice biznesowej aplikacji. Jeżeli część domenowa będzie napisana poprawnie to overhead frameworków i bibliotek powinien być minimalny.

Po części “teoretycznej” nadaszedł czas na praktykę – Adam pokodował trochę na żywo, pokazał m.in. minimalny setup potrzebny dla aplikacji EE (który w zasadzie składa się tylko z zależności do Api Javy EE), oraz praktyczną implementację wzorca Entity Boundry Control. W międzyczasie wywiązała się drobna dyskusja na temat Dependency Injection i Testów jednostkowych.

Adam wrzucił całą prezentację na Youtube:

Podsumowanie

Jak już wspominałem na początku, właściwie wszystkie prezentacje na których byłem były warte poświeconego im czasu. Od strony organizacyjnej również wszystko było bez zastrzeżeń. Ekipa realizująca konferencję po raz kolejny staneła na wysokości zadania i nie pozostaje nic innego jak tylko czekać na kolejną edycję.

DevCrowd 2014 - koszulka
Koszulka tegorocznej edycji