Play 2 - powrót do prostoty

Trochę obawiałem się o frekwencję na spotkaniu z racji tego, że zostało umieszczone na meetupie dopiero w sobotę i to nawet bez poprawnego tytułu, a pełen opis spotkania pojawił się dopiero w niedzielę. Później powstał event na Facebooku a na koniec zaproszenie z kalendarza Google poszło do grupowiczów subskrybujących Google Groups.

Początek spotkania - jeszcze niewiele osób

O godzinie 1750 na DMCSie był już prowadzący - to połowa sukcesu - i niestety dość mało osób - około 15tu. Szkoda byłoby gdyby na tą prezentację nie przyszło dużo ludzi. Paweł w końcu został uznany najlepszym prelegentem 2013r na JUGu! Na szczęście publiczność zaczęła się pojawiać i gdy prowadzący rozpoczął nie było już tak słabo z ilością osób. Na sam koniec prezentacji podczas losowania wejściówek na Geecona i książki od Manninga okazało się że było ponad 40 osób co chyba jest najlepszym wynikiem w tym roku.

Play uznawany jest za bardzo ciekawy projekt, wspominał o tym Matt Raible w swojej prezentacji na vJugu - Comparing JVM Web Frameworks. Paweł we wstępie powiedział, że filozofia Play przypomina programowanie w Rails - choć przyznał, że sam w RoR nie programuje. Ja osobiście zmusiłem się kiedyś do przeczytania książki Agile Web Development with Rails 3. Zmusiłem to złe słowo bo programowało się całkiem przyjemnie. Niemniej jednak poza scope książki nie przeszedłem.

Centrum sterowania prezentacją - live coding

Wracając do prezentacji, na pewno podejście a-la Rails jest dobre - prosto, lekko i przyjemnie. Tego brakowało w świecie Javy i Play2 to zmienił. A Paweł pokazał jak prosto się gra w Play2. Do tego celu wybrał prelekcję w formie live-coding. Jest to na pewno bardzo trudna forma bo jest duże ryzyko niepowodzenia. Jak coś nie działa to zaczyna się nerwowe szukanie błędów, presja publiczności robi swoje i można na prawdę położyć prezentacje. Jednak z tej konfrontacji zwycięsko wyszedł Paweł - miał przygotowane szablony kodu i tylko wklejał odpowiednie kawałki. Czasami coś nie kompilowało się, ale szybko było poprawiane na bieżąco. Prezentował też niezwykle skuteczny skrót klawiszowy w eclipse ctrl+spacja, którego prostota wywołała zachwyt części publiczności w osobie Mariusza Saramaka :).

Publiczność jeszcze dociera w trakcie

Paweł rozpoczął od pochwalenia się swoją wiedzą na temat różnicy między protokołem HTTP w wersji 1.1 a 1.0, czyli chunked encoding, którego to mechanizmu serwer wbudowany w play2 używa.
Play2 nie wymaga restartu serwera i można go też skonfigurować także w tryb autokompilacji czyli produktywność na maxa. Kolejny ciekawy feature tego frameworku to konsola w scali (lub javie) w której możemy testować kawałki kodu. Dodatkowo widzieliśmy jeszcze worksheet czyli takie żywe szablony dla scali w eclipse.

Do tetowania serwisów Paweł używał też wtyczki w chrome - o nazwie Postman.
Play 2 umożliwia szybkie pisanie ale jednocześnie kompilator jest w stanie wyłapać wiele błędów - nie walczymy z runtimem a kompilator naszym sprzymierzeńcem jest :).

Następnym elementem prezentacji było tworzenie formularzy a nawet testowanie ich bez kompletnego jeszcze widoku. Niektóre testy trzeba było zakomentować bo nie nadążały nad zmieniającym się live codingiem :) - czego oczywiście na prawdziwej produkcji nigdy byśmy nie zrobili.

Kolejne małe a fajne możliwości Play 2 to kompilacja javascript czyli kompilator dba o poprawność naszego js-a. Dodatkowo mamy z paczki funkcję zmniejszania javascript przez minify.

Aplikacja napisana w play2 jest gotowa do deploymentu w postaci jednego jara to kolejny feature jakiego na pewno powstydziliby się wymyślić poważni architekci.

W tym momencie zabrakło wody i dalszy flow był zagrożony - na szczęście woda od publiczności uratowała wieczór :)

W tym momencie Paweł pokazał jak uniknąć callback hell dzięki scali i futures and promises. Wspomniał jeszcze o WebSockets i problemach z firewallem oraz Akka czyli koncepcji aktorów do niezawodnego programowania wielowątkowego.

Dla zainteresowanych Scalą była też wzmianka o polskim projekcie kontenera DI jako makr w Scali napisanych przez Adama Warskiego z SoftwareMill - Macwire

Tak zakończyła się prezentacja będąca nagrodą w konkursie na najlepszego speakera 2013r. Wydaje mi się, że Paweł sprostał wymaganiom jaki ten tytuł ze sobą niesie. Potwierdziły to wyniki ankiety pojugowej. Szkoda tylko, że ankietę wypełniło zaledwie 10% osób obecnych na spotkaniu.

Pytania po spotkaniu - dobry znak - było ciekawie

Na spotkaniu Paweł próbował zacząć temat inkubatora czyli prezentacji dla studentów, które jako łódzki JUG moglibyśmy robić - proszę dajcie znać jeśli bylibyście zainteresowani tym tematem. Oczywiście szukamy prelegentów na takie spotkania.

W kolejny czwartek zapraszam na prezentację Mateusza Smolarczyka o tym jak zintegorować się z serwisami społecznościowymi za pomocą OAuth.

Clean Coders Episode 10 - z innej perspektywy

Paweł Włodarski w w poprzednim poście odcinek już opisał, więc nie będę już opisywał samej prezentacji Roberta Martina.

It's a lie :)

Na pewno był to fajny odcinek, wiele osób śmiało się z idealnego projektu opisywanego przez Uncle Boba z podkładem muzycznym niczym z love story. Oczywiście Robert Martin w diabelskim przebraniu powiedział na koniec, że nie ma idealnych projektów i zawsze pojawią się nowe wymagania, których nie przewidzieliśmy. My musimy (my developerzy) jakoś sobie radzić np. poprzez częstsze iteracje i konfrontowanie tego co powstaje w tych iteracjach z klientem.

To co chciałem poruszyć w tym poście to to, że nasze inicjatywy takie jak seria z Uncle Bob-em zaczynają się rozkręcać. Symphony Teleca była sponsorem po raz drugi. Marcin, który reprezentował firmę na JUGu, na pytanie czy pierwsze spotkanie (gdy sponsorem była ST) było skuteczne, odpowiedział: "Zdecydowanie tak, mieliśmy szansę przedstawić firmę i ofertę, a 60USD to nie jest duża cena za to żeby zyskać 15 minut uwagi programistów. I ma nadzieję, że dzisiejsze ogłoszenie dotrze do odpowiedniej liczby odbiorców".

Jeśli więc czytasz tego posta to daj znać w swojej firmie czy nie znajdą 60USD na kolejne odcinki Wujka Boba? Na dzień dzisiejszy w pipeline (piękne biznesowe słownictwo - czyż nie?) jest jedna firma (innymi słowy oczekujmy niedługo Episode 11) oraz dwie, które pytały o spotkanie - być może osiągniemy porozumienie. Wujek Bob przygotował odcinków co najmniej 2 razy tyle niż zdołaliśmy zobaczyć do tej pory, więc jest jeszcze miejsce.

Android Senor Developer

Drugi aspekt tego spotkania na który zwróciłem uwagę, to że oferta, która przedstawiał Marcin była prezentowana z widełkami płacowymi (Senior Android Developer - 6.5k do 12k). Nie wiem jaka jest tu rola JUGa, pewnie żadna, choć może jakiś wpływ na to spotkania z Uncle Bob-em miały - zawsze gdy prezentowała się jakaś firma to były pytania o płacę i może zmieniliśmy trochę świat :) ?

Trzeci wniosek po spotkaniu dotyczył programowania na platformę Android - Marcin zauważył, że niewiele ludzi programuje na Androida, a przecież nie jest to trudne. Innymi słowy potrzeby są większe niż liczba osób na rynku. To zjawisko obserwuję w swojej firmie (obecnej i poprzedniej). Znane prawa ekonomii o podaży i popycie powinny działać na naszą (programistów Androida) korzyść. Tak więc zachęcam do zgłębiania tajników Andka.

Clean Coders Episode 10 - Open Closed Principle

Drugi odcinek omawiający zasady SOLID mamy już za sobą. Sponsorem była firma Symphony Teleca

1. Single responsibility principle
2. Open/closed principle
3. Liskov substitution principle (Powinien być za dwa tygodnie)
4. Interface segregation principle
5. Dependency inversion principle

Co ciekawego w odcinku

Było by cudownie gdyby tak dało się dokładać nową logikę bez rozgrzebywania starej. Wtedy moglibyśmy rzec, że nasze rozwiązanie jest otwarte na rozbudowę a jednocześnie nie musimy modyfikować tego co już jest.

Jak to osiągnąć? Po pierwszej eliminując zagmatwany kod proceduralny, który wiąże ze sobą w jednym miejscu wiele koncepcji. I we wspomnianym odcinku mogliśmy zobaczyć jak to zrobić w praktyce. Ale czy to wystarczy?

Otóż okazuje się, że nie! Z pozoru poprawny projekt obiektowy nie przetrwał wymagania postawionego przez mówiącego z południowym akcentem farmera (granego przez Roberta C. Martina - zresztą jak wszystkie postaci). Autor wyjścia podał dwa : Albo długo długo intensywnie myśleć i potworzyć komponenty na tak wysokim poziomie abstrakcji, że mało kto skuma o co w nich chodzi - Albo adaptować projekt w krótkich odcinkach czasu do przychodzących zmian. A ponieważ to jest grunt na dobry flame war to tutaj skończymy opis.

Za tydzień 20-03-2014

Za tydzień Play Framework.
Link na meetupie --> Link na meetupie

Clean Coders Episode 9 - The Single Responsibility Principle

Po ostatnim odcinku wprowadzającym ogólnie do zasad SOLID na pewno nie mogliśmy doczekać się przejścia do konkretów. Takie miało być spotkanie nr 9 z Robertem Martinem gdzie mieliśmy dowiedzieć się czegoś o zasadzie pojedynczej odpowiedzialności. Na DMCS zjawiło się około 30 osób.

Nawet nasz gość czyli Pan Kacper z firmy Sii był ciekaw jak wyjaśni tę zasadę Robert Martin. Potem przystąpił do prezentacji firmy.

Na spotkanie przyszło kilka nowych twarzy, być może przyciągnęło ich pojawienie się nowej firmy na JUGu? Natomiast od samej firmy usłyszeliśmy, że stawiają na rozwój własnych pracowników. Potwierdziła to Pani Ula z HR.

Do pomocy ruszył nawet Krzysztof Telka, pojawiający się regularnie na JUGu, który pracuje w Sii i przekonywał, że w firmie nie ma prawie biurokracji.

Rozmowa o firmie przeciągnęła się ponieważ pojawiło się wiele pytań ze strony publiczności m.in. o widełki płacowe na stanowisku Senior Java Developer.

Wujek Bob jak zwykle zaczął od lekcji fizyki i opowieści o dokonaniach Einsteina i o tym, że czas jest zakrzywiony. Po dość długiej tej części jednak przeszedł do opowiadania o zasadzie SRP na przykładzie klasy opisującej pracownika.

Opisał na czym polegają role, kto jest użytkownikiem, jak na tej podstawie znaleźć odpowiedzialności w systemie. Później mówił o tym co jest wartością oprogramowania. Ci co oglądają wszystkie odcinki na pewno spodziewali się odpowiedzi. Otóż wartość oprogramowania to nie tylko to w jaki sposób spełnia obecne potrzeby użytkowników, ale to z jaką łatwością może dostosować się do nowych wymagań użytkowników. A te z pewnością zmienią się.

Na koniec Robert Martin pokazał przykład w jaki sposób napisał program MasterMind. Najpierw mówił o architekturze, potem pokazał diagramy a na koniec zrobił demo. To wszystko było jednak prowokacją ze strony trenera, bo przedstawił to w klasycznym podejściu waterfall. Tak naprawdę Robert Martin przyznał zaczął od testów i gdy miał 90% kodu, to zauważył architekturę, zrobił dla niej diagram, który pokazał jako przemyślaną najpierw architekturę!

Jak sam dodatkowo przyznał najlepszy moment na tworzenie dokumentacji to sam koniec projektu!

Dla chętnych była praca domowa do przeanalizowania -jak Robert Martin rozwiązał MasterMinda http://dl.dropbox.com/u/4730299/MasterMind.zip

Podczas tego epizodu mieliśmy polski akcent w postaci Wujka Boba w toalecie ze znajomymi napisami.

Jeszcze ostatnia rzecz na która zwróciłem uwagę to kiedy Wujek zaczął opowiadać w jaki sposób rozwiązałby problem od którego zaczęliśmy ten odcinek (klasa Employee, raportowanie, zapisywanie do bazy, wyliczanie pensji). Pokazał 3 rozwiązania (m.in. fasadę), ale każde miało jakieś wady. Umiejętność wyboru najlepszego zastosowania nazwał pan Martin inżynierią oprogramowania. A to, że za każdym razem musimy podejmować decyzję przypomina mi Decisions Decisions Dana North-a.

Za 2 tygodnie kolejny odcinek - Open Closed Principle. Spotkanie będzie sponsorować Symphony Teleca. Zapraszam na meetupa.