DevCrowd 2014

W tym roku udało mi się ponownie (bo po raz drugi) zawitać na konferencję DevCrowd do Szczecina. Nie jest to kolos kalibru GeeCona czy 33rd Degree, ale tworzy ona swój własny specyficzny klimat. Przygotowano nawet aplikację na androida, pomagającą w podjęciu decyzji, na którą prelekcję wybrać się aktualnie. A do wyboru były dwie równoległe ścieżki.

Rozpoczęcie konferencji przeciągnęło się mocno, przez co do obiadu wszystkie wystąpienia zostały przesunięte o kilkanaście minut. Na szczęście po obiedzie wszystko wróciło na swoje miejsce.

Na początek udałem się na prezentację Macieja Opały i Wojtka Erbetowskiego pt. Designing API for Mobile App. Jak więc projektować serwerowe API dla aplikacji mobilnych? Przede wszystkim z powodu powolnych łączy komórkowych, problemów z zasięgiem, przemieszczania się użytkownika, należy ograniczyć liczbę przesyłanych danych do minimum. Jeśli wystawiamy po stronie serwerowej RESTa, to lepiej jest przesyłać dane za pomocą JSONa niż XMLa. W przykładzie prelegentów, pozwoliło to na zmniejszenie wielkości wiadomości o 37%.

Warto również korzystać z Cache’a Http po stronie serwera, jak i Androida. W telefonie można w tym celu skorzystać z tych narzędzi: retrofit, OkHttp i HttpResponseCache. Dobrym sposobem na zmniejszenie rozmiaru paczki danych przesyłanej przez sieć, jest skorzystanie z kompresji GZIPa. Trzeba jednak uważać, gdyż dla małych plików, może ona nie opłacać się.

Przedstawiony był również problem wersjonowania naszych Interface’ów. Wynika on z opóźnionego aktualizowania aplikacji na telefonach użytkowników, czyli mogą wymagać starego API. Najlepiej, aby się ono nie zmieniało, ale najczęściej jest to niemożliwe. I tak można podawać Path parameter (np. http://api.example.com/res/v1) media type (lub custom header) (np. http://api.example.com/res+v1) albo subdomenę (np. http://v1.api.example.com/res). Wszystkie rozwiązania posiadają jednak swoje wady.

Na koniec wspomniano jeszcze o narzędziu Swagger, do tworzenia dokumentacji (coś ala javadoc) dla RESTowych aplikacji.

Zawsze bałem się prezentacji, gdzie jest dwóch prelegentów. Najczęściej oznaczało to, że prowadzący zbytnio nie znają się na temacie, lub mają opory przed wystąpieniami publicznymi. Tutaj jednak wypadło to dobrze i sprawnie.

Na drugą prezentacje wybrałem wystąpienie Mateusza Kaczmarka pt. Good design makes us happy – czyli podejmij tę decyzję za mnie. Na początku Mateusz polecał książki, od których wszystko się u niego zaczęło, czyli pozycje Dona Normana (nie pamiętam którą dokładniej) i Steva Kruga Don’t Make Me Think. Na zajawkę zamieszczam prezentację z TEDa tego pierwszego Pana.



Następnie prezentacja była wypełniona przykładami, gdzie zastosowano fajne, udane pomysły, jak i przedstawiono firmowe porażki. I tak Apple swego czasu było warte więcej niż polskie PKB, Amazon stworzył przyjemny proces zakupowy, Google uznało, że wyszukiwanie musi być proste itd. Natomiast w sektorze gier, firma EA zdobyła 2 razy z rzędu tytuł najgorszej firmy roku w USA. A zasłużyła sobie na to, dzięki wypuszczaniu niedokończonych tytułów. Inaczej było w przypadku Diablo 2 i Starcrafta, na które wydawcy kazali sobie dłuuugo czekać, co zostało sowicie nagrodzone. Również Blizzard (wydawca Diablo) pokazał, jak można naprawić swoje błędy. Przykładowo firma zamknęła sklep, za pomocą którego gracze handlowali przedmiotami w grach, gdyż to psuło rozrywkę. I ogłosili to ludzie wyglądający jak gracze, a nie panowie w garniturkach.

Co więc robić aby uzyskać UX User experience? Dla ludzi biznesu trzeba wkładać więcej wykresów do naszych aplikacji, a dla szarych Kowalskich należy upraszać nasze interfejsy graficzne. Dzięki temu użytkownicy czują się bezpieczniej i będą korzystać z naszej aplikacji. Warto też podejmować typowe decyzje za użytkownika, ograniczając mu liczbę opcji do skonfigurowania, gdyż najgorzej to stracić zaufanie użytkownika, a jeszcze gorzej jego pracę.

Prezentacja fajna, aczkolwiek był to raczej wstęp do tematu, który nie jednemu zapewne uświadomił istnienie problemu. Brakowało mi bardziej konkretnych rad i wytycznych, jak tworzyć proste i przyjemne interfejsy użytkowników. Na koniec wspomniano o innej książce Steva Kruga Rocket Surgery Made Easy, traktującej o tym, w jaki sposób tworzyć testy interfejsów na użytkownikach końcowych.

Następnie udałem się na prezentację Koziołka: Jak pracować i nie zwariować. Rozmawialiśmy o tym, co najbardziej wpływa na naszą pracę (a wiec krzesło, klawiatura, dysk SSD, RAM i 2 monitory). Każdego dnia powinniśmy lepiej poznawać nasze IDE, biblioteki i narzędzia. Warto też automatyzować jak najwięcej, gdyż jesteśmy leniwi, a jak nie będziemy musieli wielokrotnie pisać tego samego, to życie będzie przyjemniejsze.

Dalej było o introwertykach, psychopatach, dzieciach autystycznych, mądrej asertywności, drugim znaczeniu słowa SCRUM, potrzebie twardego resetu, śnie i przerywnikach w pracy. Ciekawy był pomysł Koziołka, jak odliczać sobie czas w technice pomodoro. Warto do tego użyć gier na facebooku, w których coś tam po jakimś czasie można zebrać i na nowo posiać. Wymusi to na nas regularne przerwy dla umysłu. Z praktycznych narzędzi, było wspomniane o bibliotece jFairy. która to generuje losowe dane.

Była to fajna i śmieszna prezentacja.

Następnie byłem na prezentacji Bartłomieja Nićka pt. Programista to za mało. Prelegent bardzo chaotycznie mówił i w ogóle nie zrozumiałem ani grupy docelowej, ani celu prezentacji. Było coś o wadach naszego zawodu, wadach samych programistów, jak się dawniej realizowało projekty, a jak się to robi obecnie. Prezentacja bardzo nieudana. Z prezentacji jedynie utkwiła mi różnica miedzy Computer Programer a Software Developer wg. US Bureau of Labor Statistic. A więc:

Computer programmers write code to create software programs. They turn the program designs created by software developers and engineers into instructions that a computer can follow.

Software developers are the creative minds behind computer programs. Some develop the applications that allow people to do specific tasks on a computer or other device. Others develop the underlying systems that run the devices or control networks.

Następnie był smaczny obiad i wystąpienie Pawła Szulca na temat JavaScriptu. Nie wiem czy to był celowy zamysł organizatorów, aby Pawła umieścić zaraz po obiedzie, ale jak dla mnie był to strzał w dziesiątkę! Nieprzerwany potok słów Pawła nie pozwalał ani na chwilę nudy i raczej nikomu nie chciało się spać.

Prelegent przekonywał nas, że JavaScript nie jest Mordorem, którego należy się obawiać, a wystarczy poznać i zrozumieć różnice w stosunku do Javy, to będzie dobrze. Przede wszystkim JS jest językiem funkcyjnym, a nie obiektowym. To, co początkowo przeraża, to możliwość wywołania funkcji z inną liczbą argumentów niż ją zadeklarowano! I tak niezdefiniowane argumenty będą undefined, a nadmiarowe będą zignorowane. W JS każda funkcja posiada lokalną zmienną arguments, która to przechowuje wartości argumentów przekazanych nam do funkcji.

Następnie Paweł bardzo fajnie omówił sposoby wywoływania funkcji w JS i czym się one od siebie różnią. A różnią się zazwyczaj kontekstem, na rzecz którego będzie odbywać się wywołanie, tzn. możemy otrzymać coś innego pod lokalna zmienną this. I tak mamy 4 możliwości:

1.    Wywołanie bezpośrednie powoduje, że funkcja otrzyma domyślny context, w przypadku przeglądarki jest to obiekt window

function func() {
    console.log(this)};

func();
// [object Window]

2.    Wywołanie jako metoda. Polega to na przypisaniu funkcji do pola w obiekcie. Dzięki temu dostajemy metodę, którą mozemy wywołać. W tym przypadku jako this otrzymujemy obiekt na rzecz którego funkcja została wywołana.

function func() {
    console.log(this)
}

var variable = {
    property: 'value'
};

variable.method = func;
variable.method();
// Object { property="value", meth=func()}

3.    Wywołanie jako konstruktor, a więc ze słówkiem kluczowym new powoduje utworzenie pustego obiektu (dziedziczącego z prototype). Funkcja ma w takim przypadku za zadania zainicjowanie obiektu, który zostaje zwrócony jako rezultat wywołania.

function func() {
    console.log(typeof(this))
}

var obj = new func('abc');
// object

4.    Wywołanie za pomocą applay() i call(). Przydaje się ta możliwość, gdy nie chcemy kopiować funkcji do innego obiektu, aby nie powtarzać kodu. Podmienimy jednak przez to context, czyli this. Predefiniowana funkcja applay() przyjmuje poza pierwszym argumentem tablicę z argumentami, a call() przyjmuje argumenty osobno (po prostu po przecinku)

function func() {
    console.log(this)
}

var variable = {
    property: 'value'
};

func.call(variable)
// Object { property="value"}

Było jeszcze trochę o Scop’ach, Hoistingu, domknięciach i modułach. Warto swój kod Javaskriptowy testować, np. Za pomocą narzędzi jak jasmine, czy mocha. Warto również testować swój kod statycznym analizatorem, np. JSLint. A jak musimy się na szybko nauczyć tego języka, to warto się zabrać za czytanie 2-giego i 3-ciego rozdziału Secrets of the JavaScript Ninja.

Kolejną prezentacją, na którą się udałem, było wystąpienie Tomka Borka, na temat zaawansowanego testowania. Chciałem początkowo iść na SCRUM, but, ale już miałem dość miękkich prezentacji i potrzebowałem czegoś technicznego posłuchać.

Na początku Tomek przestrzegał, aby nie używać PowerMocka, gdyż jest bardzo czasożerny, gryzie się z narzędziami do testowania pokrycia kodu, rzuca kiepskie wyjątki, a przede wszystkim pomaga początkującym pisać brzydki kod.

Dalej było trochę o adnotacji Parameterized z JUnita i ich alternatywach. Ciekawie wygląda projekt zohhak, którego wcześniej nie znałem.

Prelegent opowiedział jeszcze o paru ciekawych pomysłach, dotyczących testowania. Przykładowo, gdy wystawiamy usługi RESTowe na zewnątrz, to warto sprawdzić, czy te opublikowane interfejsy nie zmieniły się. Co do adnotacji @Ignore, to powinna być przy niej data do kiedy może ona być w teście i dlaczego.

Było jeszcze o narzędziach pomagających ogarnąć nam bazę danych, tj Liquibase, DBUnit i Databene Benerator. To ostatnie narzędzie pomaga generować testowe zbiory danych.

Z innych ciekawych (albo też egzotycznych) narzędzi był wspomniany Sureassert. Działa on tylko z Eclipse i pomaga realizować ideę design by contract i ciągłego uruchamiania testów (czyli coś jak infinitest). Niestety nie jestem fanem podejścia programowania kontraktowego i rozwiązanie działa tylko w Eclipsie.

Było jeszcze wspomniane o trzech bibliotekach, pomagających w skanowaniu naszych klas w celu poszukiwania adnotacji: Scannotation, Reflections i Classindex. Na koniec prezentacji było fajne podsumowanie, pokazujące co było omawiane na prezentacji.

Na koniec organizatorzy konferencji przygotowali niespodziankę, a mianowicie zdalne wystąpienie Adama Bienia z tematem How To Tackle Java EE 7. Live streaming był bardzo dobrze przygotowany, całość była transmitowana przez platformę ustream.tv. Prelegent zmieniał tło na którym mówił i wyglądało to bardzo profesjonalnie. Inne jego prezentacje można obejrzeć tutaj: tv.adam-bien.com.

Widać że Adam ma sporo doświadczenia w tym temacie. Było sporo kodowania na żywo, niewiele slajdów (które są dostępne tutaj), a pytania z publiczności można było zadawać za pomocą twittera. Ciekawe rozwiązanie, aczkolwiek z telefonu trochę dłużej pisze się twitnięcie, przez co było spore opóźnienie w dialogu.

Co do samej prezentacji, to Adam pokazał nam, jak można łatwo i szybko zbudować projekt z wykorzystaniem Javy EE 7. Polegało to na skorzystaniu z archetypu mavenowego i wyrzuceniu połowy domyślnego pom’a. Projekt Prelegent twierdził, że nie powinno się dodawać biblioteki do projektu „na zaś”, tylko w momencie gdy naprawdę są potrzebne. Przez to czas build’a i deploymentu powinien (przynajmniej początkowo) trwać krócej.

Generalnie kodzenia było za dużo i po jakimś czasie człowiek się wyłączał i gubił w kodzie. Dla mnie był to trochę odgrzewany kotlet, gdyż podobną prezentację widziałem na JDD 2012 z tą różnicą, że wtedy była Java EE 6 na tapecie. Jeśli ktoś chce obejrzeć tą prezentację, to jest ona dostępna poniżej:

Na zakończenie było jeszcze zbieranie ankiet i losowanie nagrody.  Konferencja wypadła bardzo fajnie. Brakowało mi jedynie typowo technicznych zagadnień, no ale trudno. Może następnym razem.

I znów Global Day Of Code Retreat

Kolejny rok mija i kolejny Global Day of Code Retreat już za nami. W tym roku planowałem początkowo uczestniczyć w tym evencie w Wolfsburgu, ale ostatecznie wybrałem Berlin, aby się trochę zorientować, jak wygląda tamtejsza sytuacja projektowa i mieszkaniowa. A CR to zawsze dobra okazja do tego. To już kolejny raz (6ty, jeśli nie licząc jakiś mniejszych, wewnętrznych inicjatyw), kiedy biorę udział w tego typie wydarzeniu, więc widzę jak się ono zmienia w czasie. Rok temu prawie 200 miast na całym świecie organizowało CR, a w tym było 165 lokalizacji. Tendencja więc spadkowa.

Jako że Berlin uchodzi za bardzo Europejskie miasto(o czym wspominałem już kiedyś w poprzedniej relacji), spotkanie było prowadzone po angielsku. Jednak w międzyczasie można było usłyszeć sporo języka niemieckiego, jaki i polskiego:) Zaczęliśmy więc od sortowania uczestników bąbelkowo, aby zorientować się kto jest mocny w TDD, pair programingu, a kto jest kompletnie świeży. No i w ten sposób najlepsi zasiedli do wspólnego stanowiska pracy z kompletnymi świeżakami. Nie ma to jak nauczanie innych:)

W pierwszej sesji dostałem więc niemieckiego studenta, który w javie pisze od święta, studiuje coś tam powiązane z medycyną, a na co dzień klepie w php. Używa do tego Vim’a. Jest on do niego tak przyzwyczajony, że korzysta z ichniejszych skrótów klawiszowych bezpośrednio w Eclipsie. Byłem pod wrażeniem, choć wątpię, aby była to optymalna droga do wykorzystania w pełni możliwości Eclipse’a.

Drugą sesję pokodowałem z przyjacielem Szymonem, z którym wspólnie przyjechałem do Berlina. Pobawiliśmy się trochę Scalą, ale nie szło nam jakoś najlepiej. Na pewno jeszcze sporo czasu trzeba zainwestować w poznawanie tego języka, aby móc z niego swobodnie korzystać. Niestety kiepska pogoda w ostatnim czasie, brak śniegu i gorączka przedświąteczna, nie jest najlepszym czasem do nauki nowych rzeczy. Dlatego kurs na Courserze sobie troszkę odpuściłem:(

Trzecią sesję miałem sposobność spędzić z pewnym Syryjczykiem, który na co dzień jest adminem, ale chciałby robić jakieś przyjemniejsze rzeczy. Ta sesja była dla mnie bardzo wymagająca pod względem komunikacji, ze względu na mój nienajlepszy angielski, ciężki w zrozumieniu angielski partnera i jego trochę słabą wiedzę w zakresie Javy. Myślę, że ziomek się sporo ode mnie nauczył.

Po trzeciej sesji była mała retrospekcja. W grupach 3 osobowych, mieliśmy napisać na kartkach, co się nauczyliśmy i co chcielibyśmy się nauczyć. Kartki przykleiliśmy na szybę i chwilę o tym dyskutowaliśmy.

Później była przerwa obiadowa. Były kanapki, a nie porządny ciepły, pyszny obiad jak to jest w formule tego wydarzenia zapisane. No ale trudno, nie to jest przecież najważniejsze.

Na 4tej sesji znów próbowałem pisać w Scali z innym nowopoznanym kolegą z Wrocławia. Tutaj trochę ciężko było nam dojść do porozumienia, gdyż zmierzaliśmy w innych kierunkach: ja kładłem nacisk na TDD, a kolega na implementację i lukier składniowy, jak to można by lepiej i ładnie zrobić w Scali.

Po czwartej sesji musieliśmy jednak opuścić warsztaty. Podziękowania dla globalnych i kontynentalnych sponsorów wydarzenia, a także dla sponsora w Berlinie: ImmobilienScout24, gdzie odbywał się event. Podziękowania również dla Martina Klose (@martinklose), który jak zwykle stanął na wysokości zadania i dobrze poprowadził kolejny raz to wydarzenie.

A co się zmienia, jeśli chodzi o Code Retreat? W Berlińskiej edycji zastosowano fajny pomysł przy rejestracji. Należało zapłacić 15 Euro, które było później zwracane, gdy uczestnik się pojawił na spotkaniu. Motywowało to ludzi do przychodzenia, gdy już byli zapisani, a gdyby naprawdę coś komuś nagłego wypadło, to strata 15 E jest do przełknięcia. Uważam to za super pomysł.

Ponadto zauważyłem, że osoby bardziej doświadczone w TDD i w formule Code Retreat już nie tak licznie w nim uczestniczą. Może to wynika z braku chęci nauczania innych, lub są już zmęczenie problemem gry w życie? Albo stwierdzają, że już nic nowego nie mogą się nauczyć i wybierają inne, ciekawsze aktywności w tym czasie. Ciężko mi to oceniać, ale wydaje mi się, jakby młodsi niedoświadczeni uczestnicy byli bardziej widoczni na tego typu wydarzeniach. To oznacza, że nadchodzą nowi, pełni zapału i żądzy wiedzy programiści, a więc tym bardziej nie można zostawać z tyłu…

Drugi tydzień z rekaktywnym programowaniem

Dzisiaj minął pierwszy deadline na zadania z drugiego tygodnia z kursu Principles of Reactive Programming. Niestety nie udało mi się zdobyć maksa, a jedynie 8.15 z 10.00 punktów. Nie ma sensu dalej walczyć z tymi zadaniami, gdyż i tak maksymalna ocena za wysłanie rozwiązania dzień po terminie jest o 20% mniejsza, więc nic tym sposobem nie zyskam. Lepiej zabrać się za nowe wykłady i zadania, a z tego co słyszałem, to są one jeszcze obszerniejsze niż te z drugiego tygodnia.

Czemu poszło mi tak słabo? Dużo czasu straciłem na w pełni poprawną implementację Demultiplexera. Przeglądałem trochę forum kursu, widziałem tam kłótnie, co do tego w jakiej kolejności powinny być uporządkowane piny wyjściowe, a jednoznacznej odpowiedzi i wyjaśnienia nie było. Błąd, jaki popełniłem, to to, że za mało testów napisałem. Ba, nawet nie trzeba by było ich pisać, a jedynie zaadaptować te, które był dostępne na forum. Po skorzystaniu z takiego jednego testu, od razu udało mi się znaleźć błąd i zaimplementować poprawnie damultipleksera. Nie wystarczało naiwnie sprawdzać pin, na którym miał się generować oczekiwany stan wysoki, ale należało sprawdzać wszystkie piny!

W drugiej części zadania również nie do końca było jak dla mnie jasne, od czego należy zacząć i jak są generowane następne stany gry. Jakoś ta główna pętla symulacji była dla mnie zbyt zaciemniona. Ostatecznie nie udało mi się zaimplementować poprawnie na czas wszystkich reguł gry, gdyż nie chciałem nocki zarywać - wolałem się wyspać. No i też wymagania nie były dla mnie do końca jasne. Coś tam działa, kod przeszedł część testów, kilka punktów wpadło. Dla potomnych screenshot z symulacji.

Na cale szczęście limit 5ciu pierwszych punktowanych rozwiązań został zniesiony. Inaczej pewnie nie udałoby mi się osiągnąć takiego wyniku z tego zadania.

No nic, idziemy dalej, nie poddajemy się, miejmy nadzieję, że następnym razem pójdzie łatwiej.

Pierwszy tydzień kursu Principles of Reactive Programming na Coursera

Mija właśnie pierwszy (a właściwie to już drugi) tydzień kursu Principles of Reactive Programming na portalu coursera.org. Jest to kontynuacja wcześniejszego kursu (Functional Programming Principles in Scala) na tymże samym portalu, który również był prowadzony przez twórcę Scali: Martina Oderskiego.

Za pierwszy tydzień oczywiście zgarnąłem komplet punktów, mimo że żadnego video z kursu nie widziałem (to tak jakbym nie chodził na wykłady;)). Wystarczyły mi slajdy ze spotkań i trochę dokumentacji ze ScalaCheck. Jednakże nie jestem zadowolony z rozwiązań, jakie wysłałem. Nie można ich publikować, bo zabrania tego Code Honor, ale mam nieodpartą chęć zobaczenia i przedyskutowania innych rozwiązań. 

I tutaj pojawia się pytanie do Was: Czy ktoś byłby chętny na wspólną ustawkę na Google Hangouts, aby podzielić się swoimi rozwiązaniami i je przedyskutować? 

Ostatnio brałem udział (więcej o tym we wpisie: Remote Scalania 7 in Javart) zdalnie w spotkaniu organizowanym przez Jacka Laskowskiego, Scalani i ta forma (tj. Hangout) bardzo dobrze się sprawdziła. Coś podobnego (aczkolwiek bardziej skromnego) i tylko zdalnego chciałbym zorganizować, aby omawiać rozwiązania kolejnych zadań. Są chętni? Jeśli tak, to proszę o informację na priv (mstachniuk gmail com). Oczywiście spotkania muszą się odbywać po Hard Deadlinie, aby nie wpływać na wyniki rozwiązań. 

Czekam na odzew i życzę pomyślności w rozwiązywaniu zadań z kursu.

Błędne użycie Listy w Javie

Ostatnio natrafiłem na ciekawą "zagadkę" związaną z kolekcjami w Javie. Czy jest to coś nowego, czy już gdzieś było w Java Puzzlers - nie wiem. Prezentowałem ten kod kolegom z zespołu i oni nie wpadli na właściwe rozwiązanie, więc postanowiłem je tutaj opublikować.

Co zostanie wyświetlone na konsoli przez poniższy kod? Dla utrudnienia nie podaję możliwych odpowiedzi.

public class ListTest {

    public static void main(String[] args) {
        List<String> planets = new ArrayList<String>();
        planets.add("Mercury");
        planets.add("Venus");
        planets.add("Earth");
        planets.add("Mars");
        for (String p : planets) {
            if (p.startsWith("V")) {
                print(planets);
            }
        }
    }

    private static void print(final List<String> planets) {
        Collections.sort(planets);
        for (String p : planets) {
            System.out.print(p + " ");
        }
        System.out.println("");
    }
}

Aby zobaczyć odpowiedź, zaznacz tekst w poniższym bloku:

Earth Mars Mercury Venus
Earth Mars Mercury Venus 

Dlaczego tak się dzieje? Problem leży w dwóch miejscach.

Standardowo kolekcje (w tym ArrayList) zwierają pole modCount. Jest ono inkrementowane, za każdym razem, gdy modyfikujemy naszą kolekcję. Ten kod: for (String p : planets) zostanie natomiast zamieniony na coś takiego:

Iterator<String> iterator = planets.iterator();
while (iterator.hasNext()) {
    String p = iterator.next();

Czyli zostanie utworzony Iterator, po którym będziemy iterować, aż do końca Listy. Podczas tworzenia takiego Iteratora, zapamiętywany jest aktualny licznik modyfikacji w iteratorze, który później, podczas wywołania metody next(), jest porównywany z obecną wartością. Gdybyśmy zamiast sort() wywoływali add() lub remove() to poleciałby ConcurrentModificationException. Niestety metoda sort() nie powoduje modyfikacji tego licznika! Nie pomaga nawet Collections.synchronizedList()!

Jest to "piękny" przykład efektów ubocznych, które mogą się zdarzyć w naszym kodzie, a których znalezienie może zająć sporo czasu. A może czas na niemodyfikowalne kolekcje w Javie tak jak w Scali?

Remote Scalania 7 in Javart

Właśnie się zakończyła pierwsza Remote Scalania 7 in Javart. Scalania, to projekt Jacka Laskowskiego, który polega na cyklicznych spotkaniach ludzi, chcących się wspólnie uczyć Scali. Spotkanie to było wyjątkowe, ze względu na to, że było ono pierwsze, w którym można było uczestniczyć zdalnie. Tak więc nie wychodząc z domu, mogłem się „spotkać” z innymi fanami Scali, wspólnie porozwiązywać zadania, poszerzyć swoją wiedzę i się z nimi scalić.

Generalnie w warsztacie uczestniczyły w sumie 4 osoby zdalne i ileś tam na miejscu, w siedzibie firmy Javart. Jako platformy do takiej konferencji skorzystaliśmy z Google Hangouts. Dodatkowo Jacek zrobił live stream’ing na YouTube’a, czego efektem jest filmik z pierwszej godziny spotkania: Scalania 7 in Javart. Jeśli ktoś się jeszcze waha, czy przystąpić do tej inicjatywy, to mam nadzieję, że ten filmik trochę pomoże i zachęci. Nie widziałem całego nagrania, ale generalnie ta forma Multi Video konferencji zdała egzamin.

Sam miałem wcześniej pewne obawy, czy poradzę sobie z tym kursem, czy wystarczająco znam Scalę, czy powinienem się angażować. Ale przecież w końcu zaliczyłem pierwszy kurs Martina Oderskiego: Functional Programming Principles in Scala, a i teraz szykuje się kolejny: Principles of Reactive Programming. A wiedzę należy odświeżyć. Troszkę przysiadłem wcześniej do rozwiązywanych poprzednio zadań w niedzielę, poniedziałek i wtorek, co okazało się w zupełności wystarczające.

Myślałem również, że na liście, którą rozwiązujemy, są na początku banalne zadania, a później już tylko trudniejsze. Na szczęście nie jest tak, tzn. są najpierw łatwe (z jedną gwiazdką), ale są one przeplatane trudniejszymi (dwie gwiazdki). Tych bardzo trudnych jest już zaledwie kilka. Taki rozrzut pomaga bez przeszkód na dołączenie do inicjatywy nawet od któregoś z kolei spotkania – w moim przypadku od 7mego.

Co do samego przebiegu spotkania, to uważam, że Jacek się bardzo fajnie sprawdza w roli moderatora całego zamieszania, gdzie trzeba rozmawiać z tymi, co siedzą na sali, ze zdalnymi, pokazywać obydwu grupom (miejscowym i zdalnym) kod, omawiać go a i czasem pisać. Pomimo inputu z różnych stron, Jacek był w stanie świetnie ogarnąć całość.

Podczas warsztatu miałem okazję pochwalenia się swoim rozwiązaniem (nie raz) i od razu zebrałem sporo krytycznych uwag. Ale dzięki temu, bardzo szybko się sporo nauczyłem. Pomogło mi również patrzenie na rozwiązania innych uczestników. Jak się widzi inne, dobre rozwiązanie, to się myśli: kurde, przecież to takie łatwe. Zauważyłem wcześniej u siebie (podczas rozwiązywania wcześniejszych zadań), że nauczyłem się jak działa młotek (w tym przypadku funkcje rekurencyjne z akumulatorem) i już niemal każde zdania traktowałem jak gwóźdź (czyli próbowałem każdy problem rozwiązać w ten sposób). Zobaczenie innego rozwiązania (jednolinijkowego), spowodowało u mnie odrzucenie zaślepek z oczu i późniejsze zadania próbowałem rozwiązywać już tylko w ten sposób.

Swoimi rozwiązaniami dzieliliśmy się za pomocą Gitsów. Na szczęście w IntelliJ Idei jest szybka możliwość publikacji takiego Gitsa. Dowiedziałem się też również, dzięki temu spotkaniu, że można swojego Gitsa edytować. Jest to sposób wystarczający do szybkiego podglądu rozwiązań, ale przydało by się je zbierać i wysyłać jako PR do repozytorium Jacka, aby zawsze można było sobie je później przejrzeć. Nie rozwiązaliśmy jednak problemu jak by dokładniej miało to działać.

Generalnie jeszcze na spotkaniach lokalni uczestnicy pracują w parach, ale zdalni pracowali osobno. Po prostu nie mieliśmy na szybko jakiegoś rozwiązania, jak taka pracę zorganizować. Kojarzę, ze kiedyś była możliwość takiej pracy w NetBeansie, ale na szybko nic sensownego nie znalazłem do Idei. Ewentualnie można skorzystać z TeamViewer’a, lub podobnego rozwiązania, ale to będzie dodatkowe obciążenie dla komputerów i mogą one nie dać rady. Jak dla mnie można próbować szukać jakiś możliwości zdalnego paring’u, ale nie jest to konieczne na przyszłych spotkaniach.

No i chyba na przyszłość przydało by się trochę więcej testów przygotować do każdego zadania, z warunkami brzegowymi i z niepoprawnymi danymi itp., choć obsługa tych sytuacji wyjątkowych mogła by sprawić, że 10 min na rozwiązanie problemu to za mało. Po za tym, co do ram czasowych spotkania, nie ma się do czego przyczepić. Jak dla mnie jest to idealnie zaplanowane i wykonane.

Podsumowując, dziękuję Jackowi za zorganizowanie Scalani w ten sposób, mam w zamiarze uczestnictwo w kolejnych spotkaniach. Jest jeszcze parę detali możliwych do dopracowania, ale i tak bez tego jest już super. Trzeba tylko pamiętać, aby zawczasu ściągnąć nowe testy, odpalić kompilator, aby reszta szła już sprawniej. Zachęcam również czytelników do aktywnego udziału w tej inicjatywie.

Zawsze sprzątaj po refaktoryzacji

Poniżej prezentuję pewnego potworka, na którego natknął się kolega z zespołu:

Jak to się stało? Otóż jeden z parametrów wyleciał jako zbędny i Eclipse zamienił miejsca jego użycia null'em :) Ciekawsze by było, gdyby ten warunek byłby jeszcze kiedyś spełniony.

Tak więc po każdej refaktoryzacji, należy się jeszcze dokładniej przyjrzeć wynikowi, aby nie pozostawić dziwnego smordu po sobie. Na szczęście skończyło się na kupie śmiechu i nic złego się nie wydarzyło.

Btw. Zna ktoś dobry sposób implementacji Exception Handler'a, gdzie odbyło by sie bez łańcuszka if / else / instanceof?