Z pamiętnika Confitury 2013 - recenzja Review your code like a Googler Darka Łuksza

Pełne "wgryzienie się" w występ Darka Łuksza zajęło mi prawie tydzień. Każdego dnia przez ostatni tydzień udawało mi się wydzielić kawałek czasu, aby wsłuchać się w prezentację na temat "Review your code like a Googler", w którym +Dariusz Łuksza przedstawiał Gerrita i jego integrację z Eclipse IDE, a z nimi powody, dla których warto rozważyć wdrożenie codziennych przeglądów kodu w Twoim zespole.

Poniżej co ważniejsze kawałki z prezentacji. Jest ich całkiem sporo, co w zasadzie udowadnia bogactwo merytoryczne prezentacji. I taka faktycznie była! Chyba się z nią zżyłem po tym prawie tygodniu oglądania i styl prezentacji Darka zaprocentuje w przyszłości wdrożeniem gerrita u mnie w zespole. Citi pracuje na CollabNet TeamForge, a Darek właśnie integruje gerrita z TeamForge w CollabNet, więc pewnie już niedługo będę mógł powiedzieć coś więcej w temacie praktycznie.

Przed każdym cytatem (wybacz Darku, jeśli nie w pełni oddałem sens wypowiedzi lub zmieniłem tu i ówdzie) jest czas - w formacie minuta:sekunda - kiedy dany kawałek się pojawi. Przy niektórych pojawia się również mój komentarz.

Niektóre z cytatów można umieścić śmiało w sygnaturze maila (!) Zdecydowanie polecam tę prezentację. Dzięki Darku!

01:06 "Tak więc zakładam, że znacie gita. Wiecie, co to jest push, pull, fetch, merge, rebase, refspec." - Akurat w moim przypadku rebase i refspec nie są znane. Do nadrobienia.

01:20 "Prezentacja nie jest dla osób, które się wstydzą swojego kodu. Wasz kod nie jest Waszą żoną. Możecie się nim dzielić. I oto chodzi."

01:29 "Dzięki temu, że na kod patrzy więcej osób, wyłapywanych jest więcej błędów. Tak samo Wy się uczycie. Uczycie też innych."

02:09 "Dzisiaj, wyjątkowo, będę używał do współpracy z Gerritem i Gitem Eclipse z Egit'em oraz Mylyn Connector. Jeżeli interesuje Was użycie z 'command line', zapraszam na prezentację Mateusza Szczap dzisiaj w Marmoladzie. Tam będzie więcej na temat, jak można jeszcze bardziej zautomatyzować proces 'code review' korzystając z komand ssh, które udostępnia Gerrit."

03:00 Wzdychając..."Ok, to 'code review'. O 'code review' słyszałem kilka ładnych lat temu."...kładzie rękę na policzku, jakby cierpiał z bólu zęba, a to tylko 'code review' :-)

03:27 "Po co robimy 'code review'? Robimy 'code review' po to, żeby minimalizować liczbę błędów. Żeby te błędy wyłapywać wtedy, kiedy one są bardzo tanie i proste do poprawienia, czyli wtedy, kiedy kod jest tworzony, kiedy dany 'feature' jest tworzony, a nie kiedy aplikacja znajdzie się na produkcji i przyjdzie 100 niezadowolonych użytkowników (o których była mowa na poprzedniej prezentacji) i powie że coś nie działa. Wtedy naprawienie tego błędu jest bardzo kosztowne i też bardzo stresujące dla nas, developerów, że coś takiego przeoczyliśmy i zapomnieliśmy o czymś takim wspomnieć."

04:00 "'code review' robimy też po to, żeby dzielić się naszą wiedzą i żeby się uczyć."

04:09 "Są osoby w zespole, które poświęcają pewien czas, żeby się dokształcać. Po to też 'code review' się robi, żeby te osoby mogły swoją wiedzę dzielić wśród zespołu, żeby ta nasza aplikacja, to nasze dziecko, nasze dzieło, które robimy było lepsze."

04:25 "Pierwszy typ 'code review' - 'post-commit review', tzw. 'formal code review'."

04:38 "Tą słynną metodologię liczenia jakości kodu przez WTF/minute. Dzisiaj zrobimy coś więcej."

05:00 "Bardzo ważnym elementem na tym zdjęciu jest...kubek z kawą, a właściwie termos." Auć! Ja kawy nie piję! Czy to miałoby oznaczać, że nie dla mnie taki zespół?! :-)

05:22 "Co po tym będzie? Potem będzie dokumentacja. Potem będzie 'bug' w 'bug trackerze', a potem będzie 'backlog'. Z mojego doświadczenia wynika, że takie błędy nie są poprawiane, o ile to nie jest to błąd bardzo duży i kosztowny, który łamie jakieś założenia aplikacji, który jest w logice biznesowej."

05:46 "W tym momencie ten kod już jest w repozytorium. Ktoś inny bazuje na tym kodzie. Co więcej ta osoba może bazować na zachowaniach tego kodu, które są błędne."

06:22 "Kolejny typ ['code review'] 'review on request'."

07:48 "Na końcu to, co ja nazywam asynchronicznym 'code review'. To, co jest możliwe do osiągnięcia z gerritem i to, co moim zdaniem jest najlepsze z możliwości, które nam oferuje aktualnie rynek."

08:45 "Teraz 'post-commit code review' vs 'pre-commit code review'."

08:55 "Reprezentacja graficzna? Jeżeli robicie 'code review' po 'commicie', kończycie z wielką toną dokumentacji i rzeczy, które zrobimy kiedyś, czyli nigdy. Jeżeli macie 'code review' przez 'committem', to macie większe ciśnienie, żeby to 'code review' zrobić, bo 'feature' nie wejdzie do aplikacji, bo klient nie będzie zadowolony, bo szef nie będzie zadowolony, bo ja nie skończę mojego zadania, bo ktoś nie zrobił mi 'code review', bo ja nie zrobiłem komuś 'code review'. Chodzi o to, żeby w tym wypadku,  musimy się do tego ['code review'] jakoś zmusić."

09:27 "To podejście ['pre-commit code review' z gerrit] daje takie narzędzie, które po prostu zmusza. Jeżeli wy nie będziecie robić 'code review', to aplikacja będzie stała w miejscu."

09:40 "Przejdźmy do gerrita."

09:42 "Czym jest gerrit? I dlaczego taki tytuł prezentacji?"

09:46 "Gerrit powstał tylko i wyłącznie dla projektu Android po to, żeby przenieść 'feeling', który jest wewnątrz Google z ich 'code review' na społeczność 'open source', na projekt Android."

10:00 "Cytat, który był na samym początku, że "żadna zmiana nie wchodzi bez 'review' do repozytorium", to jest jedna z zasad, która obowiązuje w Google. Tam każdy kod przechodzi przez 'review'."

10:35 "Gerrit jest bardzo silnie spięty z gitem. Bazuje na gicie. Możecie używać gerrita, tak jakby to był serwer gita. Nie musicie używać 'code review' związanego z gerritem. Możecie w gerricie, tak go skonfigurować, że mając 30 repozytoriów, 3 z nich będą miały 'code review', a pozostałe będzie można 'pushować' do serwera gita normalnego. Co więcej, macie możliwość ustawienia 'access controls' per 'branch', per 'branch', gdzie 'branch name' może być wyrażeniem regularnym. To nie są takie proste ustawienia ACLe, jak np. odczyt i zapis. To jest 'pushowanie merdży', 'puszowanie tagów', zmiana autora 'commitu', czyli 'puszowanie' jak ktoś inny. Tych ustawień jest sporo i ta lista przyrasta."

11:30 "Jeśli nie potrzebujecie korzystać z 'code review', a potrzebujecie serwera gita, to polecam Wam właśnie gerrita" - cóż za rym! - "Aplikacja javowa, webowa, czyli mamy znaną nam architekturę - prostokąt, prostokąt, cylinder, tj. frontend, backend, na frontendzie jest GWT, na backendzie jest Guice plus PostgreSQL."

11:56 "Dość lekkie [gerrit], zwinne. Nie potrzebujecie żadnego kontenera. Odpalacie to normalną komendą java -jar i podajecie ścieżkę do jara gerrita. Koniec. Nawet do testów bardzo fajne."

12:46 "Podejrzewam, że ten projekt [gerrit] może przeżyć samego Androida, dlatego że jest wykorzystywany do większej ilości zadań niż tylko jako system bazowy."

13:00 "Pobawmy się trochę gerritem!"

13:50 "Fred i jego IDE - oczywiście Eclipse. I co Fred chce zrobić? Fred jako, że jest nowy chce zrobić pierwszą zmianę. Niech to będzie zmiana, która będzie coś psuła." - po prostu miodzio mieć takiego nowego w zespole, co?

14:03 "Oczywiście, jak to w git'cie, zakładamy nowego 'brancha' na samym początku."

14:16 "Popsujmy sobie 'builda'."

14:20 "Każdy z nas wie, jak się najprościej psuje 'builda' - psuje się testy jednostkowe, które oczywiście mamy w aplikacji."

15:00 "Bardzo ważna rzecz. Tutaj jest taki bardzo enigmatyczny ciąg znaków - Change-Id: i same zera. Tak to musi być na początku. To jest generowane po 'commit'cie', zostanie zastąpione pewnym specjalnym numerkiem, 'hashem'. Po tej linii, Gerrit rozpoznaje 'commity'. Dzięki tej linii, on jest w stanie spiąć kolejną wersję Waszego 'patcha' z całym 'code review'."

15:36 "Możecie zmienić cały 'commit message'. Możecie zmienić dowolnie 'content', który jest w środku, ale ważne, aby ta jedna linia [z Change-Id] została niezmieniona. Teraz tam są same zera, bo zostanie zaraz wygenerowana."

16:16 "'Pushujemy' 'Push to Gerrit'. Nie bezpośrednio, tylko po prostu wybieramy tę opcję z menu."

16:25 "'Pushujemy' do specjalnego 'brancha', który się nazywa refs/for/. W tym wypadku jest refs/for/ 'master'. Podajemy docelowy 'branch', do którego ta zmiana ma trafić po samym 'code review'. Jeśli ta zmiana ma trafić do 'brancha stable' podajemy refs/for/ 'stable' zamiast 'master'."

17:44 "To, co jest fajne z gerrittem to, to, że można go bardzo łatwo spiąć z Jenkinsem. W tym momencie, po każdym 'pushu for review' odpalany jest 'job' na Jenkinsie, ewentualnie Hudsonie. 'Job' jest wykonywany i możecie go dowolnie skonfigurować - w tym wypadku po prostu odpala testy. Jeżeli zmiana się nie skompiluje, albo 'sfailują' testy, Jenkins nam taką zmianę zablokuje. W tym wypadku głosuje 'Code Review' -1, bo się posypały testy. Już w tym momencie nie musicie patrzeć na testy, patrzeć w 'diffa', widzicie to aktualnie, że ta zmiana coś psuje - nie jest gotowa, więc pomijacie ją. Omijacie jeden element z Waszego dziennego planu zadań, czyli 'code review'."

18:16 Dlaczego nagranie przechodzi w tryb dwóch paneli, gdzie lewy jest pusty?! Bardzo utrudnia oglądanie nagrania.

18:40 "Poprawmy tę zmianę...Tak samo jak wcześniej 'scommituję' używając skrótu i w tym momencie zaznaczam 'amend'."

+Dariusz Łuksza - dlaczego amend a nie po prostu kolejny commit? W końcu to jest już w historii, chociażby Jenkinsa, że coś się sypnęło i stąd kolejna zmiana.

Niestety, w pewnym momencie prezentacja gerrita zamienia się w prezentację integracji Eclipse IDE z gerritem.

21:54 "Trzeba zrobić 'push comments'. W tym momencie macie również możliwość głosowania na zmianę. Ten gerrit, który mam lokalnie skonfigurowany w ten sposób, że na 'verify' głosuje tylko i wyłącznie Jenkins. Nikt inny. Odsiewam te zmiany, które się automatycznie nie zbudują, albo nie przejdą testy. Dla mnie ważny jest tylko 'code review', czyli to, co jest w kodzie."

22:20 "Zakres, jaki mamy możliwy do zrobienia tutaj, to jest od -2 do 2. To są flagi. One nie sumują się w żaden sposób. Flaga -2 to jest jedna flaga, która jest przyklejona. Oznacza, że ta zmiana nigdy nie powinna wejść do repozytorium...Ona jest przyklejona w ten sposób, że po 'spushowaniu' kolejnego 'patchseta', który będzie coś poprawiał, -2 zostaje. W pozostałych przypadkach wszystko jest 'resetowane' do zera. -1 - drobne uchybienia w kodzie...+1 - wygląda dla mnie dobrze, ale wolę, aby ktoś jeszcze na to spojrzał...+2 - jest dla mnie ok, może iść do repozytorium. Dlaczego jest takie rozróżnienie pomiędzy +2 a +1? Dlatego, że możecie nie mieć dostępu do +2. Do każdego takiego poziomu, do każdej flagi można ustawić dostęp. Dana grupa będzie mogła tylko taką wagę ustawić."

23:38 "Co do grup - mechanizm jest dość skomplikowany, bo grupa może 'includować' grupę, może być oddelegowana, np. do LDAP. Grupa może być właścicielem innej grupy, więc poziom skomplikowania konfiguracji ACLi w gerricie jest dość wysoki."

24:35 "Zmianę można porzucić. Po prostu klikamy przycisk 'Abandon', podajemy odpowiedni komentarz, dlaczego to porzucamy. Ta zmiana zostaje w gerricie. Można ją potem wskrzesić. Ogólnie, nic z gerrita nie znika. Wszystkie komentarze, które zrobicie w gerricie i je zapiszecie są w gerricie. Wszystkie zmiany, 'patchsety', które 'pushujecie' są w gerricie. Tak więc możecie je potem odzyskać."

25:12 "Zróbmy coś bardziej skomplikowanego...Przede wszystkim zaakceptujmy jakąś zmianę, a po drugie, te zmiany będą ze sobą połączone."

28:24 "Po to się robi 'branche' tematyczne, żeby rozłączne zmiany trzymać osobno. Jeżeli zmiany między sobą zależą, 'pushujecie' je po kolei, tak jak pokazałem. Nie ważne, czy są dwa 'commity' czy 80 'commitów', 'pushujecie' je razem. Macie zapewnione przez gerrita, że 'commit' 77 wejdzie po 76."

// w tym momencie pada pytanie z sali

29:21 "Właśnie! Konflikty! Dobre pytanie."

29:28 "Z konfliktami jest w ten sposób, że gerrit część potrafi konfliktów sam rozwiązać. On używa jgita, który ma algorytm do rozwiązywania konfliktów, ale jeżeli ich nie potrafi rozwiązać, po prostu powie "sorry Winetou, ktoś tu musi przyjść i 'zmergeować'"".

30:00 ekran wraca do normalnych rozmiarów.

34:20 Koniec przykładów.

34:40 "Parę 'hintów' odnośnie 'code review'." => na slajdzie pojawiły się punkty: 'It's like TDD, review code before it hits main repository.' oraz 'Do code review on daily basis...remember when you are not reviewing other's code then application's not progressing.'

34:42 "Przede wszystkim [...] bądźcie konstruktywni i nie piszcie takich rzeczy typu 'Taki kod ja pisałem w liceum', albo 'To nigdy nie powinno wejść' bez podania dlaczego. Piszecie to tak, jakbyście pisali komentarz do kodu, a nie do osoby. Starajcie się ten kod przeglądać tak, jakby to był Wasz kod. Wasz kod, który napisaliście pół roku wcześniej, wracacie i myślicie 'Co ja tu miałem na myśli?! Gdzie ja tu mogę coś zrefaktorować? Gdzie mogę coś poprawić? Gdzie użyć nowej biblioteki, o której dowiedziałem się tydzień temu?'"

35:20 "Jeżeli dostajecie 'code review', to nie jest tak, że ktoś mówi Wam 'Jesteś głupi. Nie widziałeś tego NullPointerException?!' a raczej 'W tym kodzie jest błąd i to powinieneś poprawić. Następnym razem po prostu uważaj na to, że ta metoda zwraca nulla. Mogłeś o tym nie wiedzieć.' Chodzi o to, żeby sobie pomagać. Żeby razem to nasze małe zwierzątko zwane aplikacją wychować tak, żeby zachowywało się dobrze na produkcji."

35:46 "Code review powinno być robione codziennie." 

Scalania 7 w Javart już w tę środę - stacjonarnie i wirtualnie

Dostałem kiedyś taki komentarz dotyczący jednego z poprzednich spotkań pod szyldem scalania:

"Fajnie byłoby móc w jakiś sposób uczestniczyć w scalaniach na odległość."

I się wydarzy już w tę środę, 30 października! "Uważaj, o co prosisz, bo się spełni."

Opublikowałem właśnie zaproszenie na meetupie na Scalania 7, które będzie w kilku aspektach nowatorskie.

Po pierwsze, będzie to spotkanie w biurze firmy Javart na Postępu 21 (Park Postępu, Budynek A, 2 piętro).

Po drugie, scalania będzie dostępne również na platformie Google Hangout na moim koncie na Google+. Mam już potwierdzone trzy osoby, które sprawdzą ten rodzaj "dystrybucji" wiedzy na własnej skórze. Dzięki Danielowi, Mateuszowi i Radkowi dowiemy się, czy warto kontynuować pomysł. Dziękuję Panowie. Ktoś jeszcze chętny?

Po trzecie, planuję nagrać wprowadzenie ze spotkania, aby zachęcić do udziału większą liczbę osób.

Firma Javart zapewni nam lokal, sieć, sprzęt, kawę, herbatę i wyżywienie. Atrakcji nie powinno zabraknąć dla każdego. Zapraszam!

Relacja ze scalania 6 - niespodzianek końca nie widać

Byłoby niegrzecznie wychwalać własne dzieło, ale przywdziewając czapkę uczestnika spotkań z językiem Scala - Scalania - mogę śmiało oznajmić, że ostatnie, szóste spotkanie było jeszcze lepsze niż poprzednie (wliczając te podczas warsjawy). Na wsparcie tych słów, przytoczę opinie uczestników ze strony Scalania 6 - spotkania z językiem Scala.

Jacek Kołodziejski napisał:

"Kolejne bardzo udane scalanie i nawet się zmieściliśmy w czasie! Składam oficjalne gratulacje na ręce prowadzącego:)
Pomysł z wywoływaniem losowych ludzi do zadania z poprzedniej edycji jest bardzo ciekawy."

Co zechciał wesprzeć Piotr Kowalski swoim "lajkiem".

Andrzej Jóźwik dodał:

"Bardzo udana współpraca - praca w grupach wyzwoliła konkurowanie na ilość różnych podejść/rozwiązań. Jak widać ile osób tyle pomysłów - a scala daje duży potencjał."

Z "lajkiem" Rafała Krzewskiego.

Biorąc pod uwagę, że na spotkaniu było 15 uczestników (16 ze mną) i 4 wyraziło swój zachwyt, daje to ponad 25% zadowolonych, co uważam za solidne wsparcie mojego (być może przesadzonego tu i ówdzie) myślenia.

Daleki jestem od stwierdzenia, że to moja zasługa. Wręcz przeciwnie! Owe dzieło - scalania - wyjątkowo dobrze się samoorganizuje, a ja jedynie nadaję temu ramy spotkania. Liczba pomysłów, które mógłbym określić moimi, stanowi pewnie jedynie połowę wszystkich wdrożonych, co jest kolejnym sukcesem tej inicjatywy.

Ot, choćby ostatnie "ćwiczenia" polegające na podziale uczestników na grupy i ścisłe przestrzeganie ram czasowych. To nie są moje pomysły, a jak widać to właśnie one stanowią o doskonałości spotkania. I tak trzymać! Ja ustawiam się w roli bacznego obserwatora i "zbieracza" pomysłów, a uczestnicy, jako główni aktorzy na scenie, określają formę i kierunek rozwoju (własnego i spotkania). Widzę samych wygranych.

Dziękuję tym, którzy zabrali głos w sprawie (na meetupie), pozostałym uczestnikom, wydziałowi MIM UW, aby nie zapomnieć o sponsorze - firmie Javart. Zabrzmi banalnie, ale należy to napisać...oddawając tedy, co jest cesarskiego, cesarzowi, a co jest bożego, Bogu...że bez nich scalania nie miałyby miejsca. Dziękuję!

W zasadzie, komentarze wyżej, dają pojęcie o zmianach wdrożonych podczas ostatniego spotkania - utrzymanie podziału na 3-osobowe grupy oraz ścisłe trzymanie się agendy. Dla mnie największym sukcesem było trzymanie się czasu i wciąż jest zaskakująca łatwość, z jaką idzie to utrzymać. Chociaż niewielu potrafi rozwiązać zadanie w zadanym czasie, to nie słychać głosów, które mogłyby świadczyć, że to coś niewłaściwego. To się musi podobać każdemu!

Zaczęliśmy spotkanie o 18:10, od wprowadzenia do Scali, które poprowadził Andrzej Goławski. Dostał 15 minut i ich nie zmarnował! Trudno było znaleźć czas, aby się nudzić. Wielkie brawa dla Andrzeja.

Później "odpaliłem" nowość tego spotkania - 15-minutową rozgrzewkę, czyli sprawdzian dla osób, którzy byli na poprzednich scalaniach, a którzy "poproszeni" rozwiązywali już zrobione wcześniej zadania (niekoniecznie przez nich samych).

Jak wybierać osoby do tego sprawdzianu jest jeszcze do wypolerowania, ale z pewnością należy to utrzymać. Daje to możliwość wyjścia na scenę osobom, które zwykły trzymać się z dala od blasku fleszy, a także wdrożyć nowe osoby do mechaniki rozwiązywania zadań. Bardzo podobała mi się dyskusja z pierwszym na scenie (wybacz chwilową amnezję, bom imienia nie pomniał), aby rozwiązać zadanie, którego akurat nie robił wcześniej (bo udział w scalaniu nie musi oznaczać, że dane zadanie właśnie wtedy było robione).

W końcu nadeszła pora na przerwę żywieniową i chwilę na dyskusję. Ten element uważam za kluczowy, bo nie tylko, że można się posilić, ale przez miejsce (korytarz) i niewielką liczbę osób (poniżej 20) próbuję animować dyskusje między uczestnikami. Podczas przedostatniego spotkania mieliśmy jedno wielkie kółko, w którym każdy dzielił się swoimi wdrożeniami Scali w firmie, a na ostatnim widać już było kilka podgrup i raczej nikogo pozostawionego samemu sobie. To zdecydowany sukces scalania i odejście od tradycyjnego, opartego na slajdach i jedzeniu w ławkach, formatu spotkań Warszawskiego JUGa.

Od 19:00 można liczyć faktyczne rozwiązywanie zadań. Zgodnie z planem, na pierwszy ogień poszło P14. O 19:10 dzielimy się gistami. Poniżej zebrane propozycje.

• https://gist.github.com/qoob/7011375
• https://gist.github.com/jacekkolodziejski/7011249
• https://gist.github.com/wregab/7011387
• https://gist.github.com/dchrusciak/7011405
• https://gist.github.com/qoob/7011403
• https://gist.github.com/ajozwik/7011462

W agendzie zaplanowałem kolejną niespodziankę spotkania, ale najwyraźniej sprawność grupy sprawiła, że pojawiła się ona w propozycjach rozwiązań - napisać rozwiązanie w trzech wersjach - z użyciem dopasowania wzorców, jednolinijkowca z foldLeft/flatMap czy podobnie, oraz wersję z rekurencją ogonową. Zakładając, że jedno z wymienionych jest bieżącym rozwiązaniem, pozostałe stanowiły(by) uzupełnienie i kolejne ćwiczenie umysłowe. Zwykle dawało to trzy różne rozwiązania.

O 19:30 podeszliśmy do P15.

Właśnie wtedy uzmysłowiłem sobie kolejną nowość spotkania - baczniejszą analizę błędu podczas uruchomienia testu. Do tej pory zakładałem, że należało przeczytać test, aby dowiedzieć się, co jest wymagane w implementacji, ale już samo uruchomienie testu daje taką informację.

Uruchom polecenie ~exercises/testOnly *P15* i po prostu przeczytaj błąd, w którym napisano, czego oczekuje się od implementacji.

> ~exercises/testOnly *P15*
[info] P15Spec
[info]
[info] P15 solution should
[info] x Duplicate the elements of a list a given number of times.
[error]    an implementation is missing (S99_P15.scala:4)

Trzeba więcej?! Raczej nie. To znacznie upraszcza operowanie projektem i udział w spotkaniu. Gdyby podzielić ekran na dwa i u dołu pokazywać wynik testu, a u góry edytor, byłoby to idealne środowisko pracy. Tutaj IDE, np. IntelliJ IDEA, mogłoby spełnić pewną rolę.

I tu mnie olśniło - zaproponowałem, aby w 3-osobowej grupie był tylko jeden otwarty komputer ze zmianą osoby piszącej rozwiązanie. Moja pamięć zawodna i nie pamiętam grupy, która nie wdrożyłaby tego pomysłu.

• https://gist.github.com/pibako/7011805
• https://gist.github.com/jacekkolodziejski/7011691

O 19:50 siedliśmy przy P16.

• https://gist.github.com/jacekkolodziejski/7012173
• https://gist.github.com/ajozwik/7012102
• https://gist.github.com/anonymous/7011590

O 20:30 ogłosiliśmy spotkania koniec.

Dziękuję uczestnikom, wydziałowi MIM UW, firmie Javart oraz Tobie za przeczytanie sprawozdania. Zapraszam na kolejne spotkanie, które odbędzie się już za 2 tygodnie. Do zobaczenia!

p.s. Zachodzę w głowę, jak gromadzić rozwiązania, aby stały się częścią projektu scalania na GitHubie. Pomysły mile widziane.

Scalania 5 - wydanie specjalne i warsjawa 2013 przechodzą do historii

Projekt spotkań w formie warsztatowej o nazwie scalania odpaliłem po raz pierwszy 9 lipca 2013. Pomysł nie był nowatorski w swej formie, a wciąż nie posiada swojego konkurenta, przez co można choćby z tego powodu okrzyknąć go sukcesem. Podobnie jak warsjawę.

Kiedy 6 lat wcześniej - 21 listopada 2007 - uruchamiałem (jeszcze na tamten czas nazywaną) WarsJavę - projekt polegający na serii krótkich wykładów praktycznych, które miały być odpowiedzią na rosnące zapotrzebowanie poznawaniem technologii przez warsztaty - nie sądziłem, że może kiedykolwiek przyciągnąć ponad 500 uczestników, a dodatkowo będzie prowadzony przez grupę niesamowicie nakręconych łebków, którzy już dawno udowodnili, że jak można, to będzie i nie potrzeba ciągać za sobą balastu w postaci mojej osoby. Chwała za decyzję!

I dało się? Pewnie, że się dało! Spełniło się moje marzenie o uformowaniu grupy, która organizuje się samodzielnie i potrafi uruchomić confiturę, warsjawę oraz zadbać o regularne spotkania Warszawskiej Grupy Użytkowników Technologii Java (Warszawa JUG).

Panie i Panowie, szacunek za poświęcony czas i włożony wysiłek. Jestem dumy móc pracować z Wami i korzystać z owoców Waszej pracy! Uczę się przy tym niemało. Dziękuję!

I tak zabrakło mi organizowania czegoś i padło na spotkania warsztatowe ze Scalą. Zaczęło się od poznawania języka Scali samodzielnie, aby wpaść na pomysł odpalenia scalania. Brakowało mi towarzystwa do nauki, więc zorganizowałem spotkania.

I się toczy pomalutku.

Podczas warsjawy okazało się, że projekt scalania pozwala na organizowanie spotkań regularnie na MIMUWie oraz wydanie specjalne. W zasadzie formuła scalania podczas warsjawy nie różniła się zasadniczo od tego, co doświadczam na spotkaniach regularnych, ale kolejny raz dano mi możliwość poeksperymentowania i wdrożenia kilku pomysłów.

Na wydaniu specjalnym scalania na warsjawie pojawiło się 12 osób. Żadna z osób nie uczestniczyła w poprzednich scalaniach.

Po usadowieniu się uczestników i wprowadzeniu ich w tajniki projektu scalania (co trwało około 15 minut) poprosiłem o ujawnienie się bardziej zaawansowanych programistów Scali. Szczęście mnie nie opuściło i okazało się, że osób na poziomie kursu Odersky'iego i kilku samodzielnych prób z językiem było 6 - dokładnie połowa! W ten sposób wdrożyłem w życie pomysł podziału uczestników na pary - nowicjusz i zaznajomiony ze Scalą. Stoły były jakby dopasowane do takiego pomysłu i mieściły pary doskonale.

Przeszliśmy przez P01 wspólnie, później już P02 samodzielnie (w parach), aby około 10:40 zabrać się za P03. Zauważyć można było, że tempo nie każdemu służy i było niemałym zaskoczeniem dla uczestników. Mimo wszystko nie zraził się nikt i zawzięcie widać było na twarzach.

Trzeba było widzieć te pracujące pary - ludzie pracują wspólnie, w parach w rytm expression pair programming! Widać interakcję. Moje marzenie o spotkaniach, które integrują (zamiast tylko przekazywać wiedzę) spełniało się kolejny raz.

O 11:05 przerwa.

Przeszliśmy do P12 około 11:45 i dokończyliśmy spotkanie wspólnym rozwiązywaniem zadania, które pozwoliło mi zademonstrować siłę systemu typów Scali i wymuszanie przez niego implementacji (po prostu należało spełniać wymogi kompilatora, aby ostatecznie wyłoniło się rozwiązanie). Tym wspólnym akcentem zakończyliśmy scalania 5 - wydanie specjalne na warsjawie 2013.

Po warsztacie spędziłem czas do 15:00 na dyskusjach z organizatorami, wolontariuszami, sponsorami oraz uczestnikami warsjawy. Dziękuję wszystkim za wspaniałą atmosferę.

Niech podsumowaniem mojej relacji będą trzy relacje uczestników scalań. Jak nietrudno zauważyć, pojawia się w nich nowy pomysł do wdrożenia ;-)

"Hej,

jeszcze raz dzięki za świetny sobotni warsztat. Poniżej tak jak prosiłeś moje spostrzeżenia.

Na plus:
- muszę przyznać, że przed warsztatem widziałem może z jedno "Hello World" ze Scali więc trochę obawiałem się, że polegnę na składni. Jednak krótkie wstępy teoretyczne przed zadaniami pozwoliły mi o tym zapomnieć. Dodatkowo muszę powiedzieć, że taka metoda (minimum teorii koniecznej do rozwiązania problemu + kodowanie) nauki nowego języka bardzo dobrze się sprawdza.
- tworzenie par nowicjusz + bardziej doświadczony. Można poznać nowych ludzi, czegoś się od nich nauczyć, a i może oni się czegoś nauczą od nowicjuszy przez ich świeże spojrzenie.
- krótki czas na rozwiązanie zadań. Nie pozwoliło to ślęczeć uczestnikom nad rozwiązaniem nie wiadomo ile, dzięki temu nie robiło się nudno.
- sądzę, że wspólne rozwiązanie P12 na moim przypadku (trochę przy nim poległem na kompilatorze, ale rozwiązanie zmierzało w jakimś tam dobrym kierunku jak się okazało :) ) dużo dało nie tylko mi.

Co mogłoby być inaczej, żeby było lepiej (czyli jak ktoś woli minusy):
- zabrać/schować/wyłączyć (niepotrzebne skreślić :] ) jednej osobie komputer. Zdarzało się, że zaczynaliśmy rozwiązywać problem na jednym komputerze, rzucaliśmy swoje pomysły, później następował mały zastój i praca rozpraszała się na dwa komputery. Jedna osoba na chwilę zwątpiła we wspólnie wypracowane rozwiązanie i przechodziła do realizacji własnego pomysłu. Gdyby nie było drugiego komputera dało by się tego uniknąć i wycisnąć ze wspólnej pracy w parach dużo więcej.
- trochę się rozjechaliśmy z czasem/agendą, ale to właściwe plus bo jeśli mamy jakieś pytania do zadania, pojawiają się jakieś ciekawe dyskusje lub Ty miałeś coś extra do powiedzenia to dlaczego nie? Myślę więc, że nie ma co ściśle ustalać ile zadań zrobimy na spotkaniu bo czas poświęcony na jakieś dodatkowe rozmowy, o ile nie odchodzimy za bardzo od tematu, na pewno nie jest czasem straconym :)

Ogólnie jestem bardzo zadowolony z tego warsztatu. Jak napisałem wcześniej nie miałem kontaktu ze Scalą, a z programowaniem funkcyjnym tylko akademicko (LISP, PROLOG) - jakoś do mnie ono nie trafiło. Po warsztacie trochę inaczej na to spojrzałem i pewnie będę się chciał bardziej zagłębić w ten temat. Mam nadzieję, że uda mi się pojawić na następnych scalaniach. To tyle ode mnie."

"Cześć,

Warsztaty były naprawdę fajne i to co mi się najbardziej podobało to w miarę żwawa akcja.
Zauważyłem, że czasami jak omawianie teorii trwa zbyt długo i ludzie jeszcze nie za bardzo czują, że ta teoria może im się do czegoś przydać, to lubią się wyłączać.
Tutaj tempo było w sam raz.

Dzień wcześniej zrobiłem sobie dwa pierwsze zadania na ifach. Dzięki temu, że na zajęciach padła sugestia by użyć pattern matching, łatwiej mi było zauważyć różnicę pomiędzy tymi rozwiązaniami. Być może będziecie chcieli na przyszłych spotkaniach rozwiązywać dany problem na kilka sposobów 
i omawiać różnice.

To co można poprawić to pozostawić jeden laptop na grupę aby zachęcić do większej współpracy.

pzdr,"

"Witaj,

Podobało mi się:
- praca w parach (może warto pójść jeszcze dalej i spróbować pair programmingu ze zmianą kompa co zadanie?)

Podobało mi się mniej:
- skakanie między Sublime i REPLem gdy "spełniałeś wymagania kompilatora" (może wtedy lepiej byłoby użyć jakiegoś IDE które na żywo podkreśla błędy kompilacji?)"

Zaczynam zastanawiać się, na ile zasadne byłoby myślenie, że scalania należałoby odpalić w innych częściach Polski? Już realizuję pomysł, aby odpalić scalania w pewnej firmie (ogłoszenie niebawem), ale może i należałoby zastanowić się nad innymi miastami. Może również należałoby oprzeć na scalaniach całodniowe szkolenie? A może nawet kilkudniowe? Jesteś chętna, aby podjąć wątek? Porozmawiajmy!

Scalania 6 - spotkania z językiem Scala w najbliższą środę, 16 października od 18:00

Zapraszam na szóste spotkanie z językiem Scala - Scalania 6, które odbędzie się w najbliższą środę, 16 października na MIMUWie. Szczegóły organizacyjne znajdziesz na stronie spotkania http://scalania.pl.

Rozpoczynamy o godzinie 18:00 w sali 3180.

Po ostatniej warsjawie pojawiło się w mojej głowie kilka pomysłów, które chciałbym zrealizować właśnie podczas tego spotkania. Z pewnością będzie inaczej niż podczas poprzednich spotkań, więc stali bywalcy powinni ponownie poczuć się jak nowicjusze.

Motywem przewodnim będzie praca z projektem scalania z GitHuba w obszarze zadań P14-P16 (z możliwością rozszerzenia aż do P19).

Na scenie zobaczymy Andrzeja Goławskiego, który "uzbroi" nas w niezbędne konstrukcje języka Scala potrzebne do rozwiązywania zadań.

Zastanawiasz się, czy to spotkanie dla Ciebie?! Na pewno! Świeże spojrzenie zawsze w cenie. Po prostu nie może Cię zabraknąć! Zapraszam!

Szanowny uczestniku specjalnej edycji Scalania na warsjawie

Drogi uczestniku scalania - wydanie specjalne,

Z niecierpliwością oczekuję nadchodzącej soboty, 12 października, kiedy o godzinie 9:30 będziemy mogli się spotkać na tegorocznej warsjawie, w której wspólnie weźmiemy udział w wydaniu specjalnym Scalania.

Przekonasz się na własnej skórze, że nie ma lepszego sposobu na poznanie Scali, jak obcowanie z nią w gronie podobnych zapaleńców. Odmienność spojrzenia na ten sam problem współtowarzysza i możliwość poznania powodów takiego rozumienia jest bezcenna, a jednak dostępna na wyciągnięcie ręki podczas tych spotkań.

Spotykamy się w sali 2045 na MIMUWie. Wcześniej zachęcam do udziału w oficjalnym rozpoczęciu konferencji o godzinie 9:00.

Na mój warsztat zapisało się 23 osoby i planuję zastosować wszystkie techniki uatrakcyjniania spotkań, które miałem możliwość doświadczyć podczas poprzednich 4 edycji scalania.

Zaczynamy punktualnie o godzinie 9:30. O 11:00 jest obowiązkowa 30-minutowa przerwa. To daje nam 2 bloki warsztatowe = odpowiednio 90 minut i 60 minut.

Wstępna agenda scalania - wydanie specjalne jest następująca:

CZĘŚĆ 1 :: 09:30 - 11:00 - 90 minut - część wprowadzająca/rozgrzewająca
15 minut - wprowadzenie do projektu scalania
10 minut - tematy scalowe do rozwiązania zadań
30 minut = 3 x 5 minut - rozwiązywanie zadania + 5 minut - omówienie rozwiązania
10 minut - tematy scalowe do rozwiązania zadań
25 minut = 3 x 5 minut - rozwiązywanie zadania + 5 minut - omówienie rozwiązania

PRZERWA 11:00 - 11:30 - 30 minut

CZĘŚĆ 2 :: 11:30 - 12:30 - 60 minut - część (bardziej) zaawansowana
10 minut - tematy scalowe do rozwiązania zadań
20 minut = 2 x 5 minut - rozwiązywanie zadania + 5 minut - omówienie rozwiązania
10 minut - tematy scalowe do rozwiązania zadań
20 minut = 2 x 5 minut - rozwiązywanie zadania + 5 minut - omówienie rozwiązania

RAZEM 3+3 + 2+2 = 10 zdań

Dzielenie się agendą przed spotkaniem jest nowością tego wydania. Chciałbym, aby tempo zostało dotrzymane i  tym samym proszę o wspólne pilnowanie harmonogramu, gdybym sam nie dawał z nim rady. Nie będzie lekko, ale nikt tego nie obiecywał, więc po co sobie odpuszczać! :-)

Proszę zapoznać się z projektem scalania na GitHubie. Najważniejsze, aby pobrać projekt (git clone) na swój komputer, z którym pojawisz się na warsztacie. Dodatkowo należy odpalić sbt (w wersji 0.13) i wykonać polecenia opisane w README projektu. To pozwoli nam na pracę bez konieczności dostępu do sieci, gdyby takowa zawiodła. Jako IDE będę korzystał z Sublime Text 3 i/lub IntelliJ IDEA 13. Wybór IDE pozostawia się uczestnikowi.

W miarę możliwości proszę o zabranie ze sobą przedłużacza.

O czymś powinienem jeszcze wspomnieć? Pytania? Sugestie? Komentarze? Proszę o kontakt.

Do zobaczenia na warsjawie!
Jacek

Scala scala na Scalaniu - 4-te spotkanie za nami

Zacznę od rzeczy najważniejszej - podziękowań. Dzisiejsze, czwarte spotkanie ze Scalą - Scalania 4 - było bezsprzecznym sukcesem współpracy wielu osób, o których byłoby nietaktem nie wspomnieć. Wcześniejsze nie były specjalnie inne, ale efekt dzisiejszych jest jakiś szczególny i tak mnie naszło.

Dziękuję firmie Javart za opiekę nad spotkaniem. Kolejny raz. Pozwoliło nam to na pełne oddanie się "trawieniu" wiedzy o języku Scala, zamiast walce z głodem i pragnieniem. Dzięki wsparciu firmy Javart, głód i pragnienie poszły w zapomnienie, kiedy…

pojawiła się strawa i napoje,

a na scenie kolejno nasi prelegenci we troje.

Zaczął +Andrzej Goławski. Pierwsze dziesięć minut upłynęło sprawnie i zapoznaliśmy się z metodami map, List.make, List.flatMap oraz List.zipWithIndex. Andrzej korzystał z prezi. Wyjaśnienie, przykład i kolejny, wyjaśnienie ponownie, itd. Przerwałem jego wystąpienie po tym, kiedy mój stoper oznajmił upływ 10 minut. Oklaski i wchodzi kolejny prelegent.

Na scenie pojawia się +Anita Fronczak. Anita wykorzystała Google Docs jako platformę do slajdów. Z pewnymi problemami sprzętowymi (Anity komp bez wyjścia VGA, a mój Mac kolejny raz się zawiesza przy podłączeniu do wyjścia projektora, więc Andrzej nas ratuje swoim) zaczynamy kolejne 10 minut. Anita przeprowadza nas przez tajniki krotek (ang. tuples), przypisania przez dopasowanie wzorców, Either/Left/Right i kończymy po kolejnych 10 minutach. Oklaski i wchodzi kolejny prelegent.

Ostatnim "czarodziejem" staje się +Piotr Marczewski. Tym razem jedynie IDE. Omówił klauzulę import w ramach object, typ scala.Any oraz scala.Symbol. Dokładne wpasowanie do przydzielonych 10 minut i kończymy o czasie.

Wielkie gratulacje dla naszych prelegentów! Utrzymanie materiału w ryzach 10 minut z pewnością nie było łatwe i wymagało od nich starannych przygotowań. Udało się i było super. Anita, Andrzej i Piotr zasługują na gromkie brawa.

Utrzymanie owych 10-minutówek zgodnie z ich planowanym czasem (i nazwą) okazało się strzałem w dziesiątkę! Było różnorodnie (merytorycznie i osobowościowo), sprawnie, krótko i treściwie. To zdecydowanie należy utrzymać.

I tu nowość tego spotkania - podział na trójki. W zamyśle celem trójek miało być zintensyfikowanie interakcji między uczestnikami, a to miało się przełożyć na większą porcję wiedzy dla pojedynczego słuchacza (który miał się stać aktywnym uczestnikiem). Odliczyliśmy do trzech i ostatecznie uformowały się 3 czwórki (hmmm...dlaczego nie podzieliliśmy grup na 4 trójki?!)

Sądzę, że to był hit sezonu. Praca w mniejszych grupach sprawiła, że ludzie musieli się poznać z innymi w grupie (wartość sama w sobie) oraz trudniej było utrzymać siebie w roli biernego słuchacza. Nie trzeba było być bacznym obserwatorem, aby zaobserwować zalety takiego podejścia. Wystarczy spojrzeć na zdjęcia.

Po podziale na grupy, kiedy to wszyscy się dobrze usadowili, oznajmiłem przerwę "obiadową". Postanowiłem tym samym rozruszać nasze informatyczne ciała i kolejny raz zmusić do interakcji między uczestnikami. Udało się! Po chwili uformowaliśmy koło, w którym każdy podzielił się swoimi doświadczeniami z wdrażania/użycia Scali w projektach. Szkoda, że nie mam zdjęcia z tego momentu. Trzeba było w tym wziąć udział, aby przekonać się, jak ważne są takie małe ruchy integracyjne.

Około 18:15 (tak, tak, uważny obserwator dostrzeże pewną, nieznaczną rozbieżność w czasie między tą relacją a stanem faktycznym) przeszliśmy do zadań.

I tu kolejna nowość, trzymanie się czasu na rozwiązywanie zadań. Włączyłem stoper i rozpoczęliśmy rozwiązywanie P11. Później było P12 i skończyliśmy na P13. Wymienialiśmy się rozwiazaniami za pomocą serwisu GitHub Gist. Dzięki uprzejmości MIM UW mieliśmy pełny dostęp do Internetu, więc wystarczyło poznać numer gista i można było omawiać rozwiązanie zadania. Jakoś tak czas nam upływał przy dyskusjach i ostatecznie jedynie 3 zadania udało nam się rozwiązać. Tutaj trzeba popracować nad sprawniejszą obsługą.

Kolejna edycja scalania 5 będzie specjalna, bo prowadzona podczas warsztatów warsjawa 12 października na MIM UWie. Zaczynamy o 9:30. Są jeszcze miejsce, więc gorąco zachęcam do udziału! Wystarczy napisać do mnie.

Scalania 4 - spotkania z językiem Scala w najbliższą środę, 2 października

Zapraszam na czwarte spotkanie z językiem Scala - Scalania 4, które odbędzie się w najbliższą środę, 2 października na MIMUWie. Szczegóły organizacyjne znajdziesz na stronie spotkania http://scalania.pl.

Ważną zmianą w stosunku do poprzednich edycji jest godzina rozpoczęcia - 18:00. Proszę o jej zapamiętanie i przekazanie innym zainteresowanym. Jest jeszcze jedna zmiana - podział na 3-osobowe grupy, ale to akurat niech pozostanie naszą tajemnicą.

Motywem przewodnim będzie praca z projektem scalania z GitHuba w obszarze zadań P11-P16.

Na scenie zobaczymy Anitę Fronczak, Piotra Marczewskiego i Andrzeja Goławskiego, każda z osób z 10-minutowym wprowadzeniem do niezbędnych konstrukcji języka Scala.

Coraz lepiej przychodzi nam organizowanie tego rodzaju spotkań i tylko czekać, kiedy usiądziemy przy dłuższej czasowo inicjatywie, np. weekendowym hack-a-thonie. Nie może Cię zabraknąć! Zapraszam!

Scalania 3 - spotkania z językiem Scala w najbliższą środę, 11 września

Zapraszam na trzecie spotkanie z językiem Scala - Scalania 3, które odbędzie się w najbliższą środę, 11 września. Szczegóły organizacyjne znajdziesz na stronie spotkania http://scalania.pl.

Zmianą w stosunku do poprzedniej edycji będzie 15-minutowy przegląd dotychczas wykonanych zadań, których celem jest przypomnienie konstrukcji języka Scala i ich użycie w zadaniach. Ten krok ma skrócić dystans między nowymi uczestnikami spotkania, osobami, które nie były na poprzednich i wykonywały zadania samodzielnie a stałymi bywalcami. Motywem przewodnim będzie praca z projektem scalania z GitHuba, co powinno dodatkowo zachęcić uczestników do jego aktywnego użycia na potrzeby własnego samorozwoju (już pierwszy pull request został zatwierdzony - WIELKIE dzięki Rafał!)

Nie mogę się doczekać, aby sprawdzić, jak wiele się nauczyliśmy w temacie wspólnych scalań przez ostatnie dwie edycje. Wydaje się, że już niewiele można poprawić, a po prostu brakuje nam jedynie obycia z tego typu imprezami. Nie może Cię zabraknąć.

Zapraszam!

Scalowanie na Scalaniach #2 = scalowych spotkaniach po godzinach

Wróciłem do domu cały rozgrzany, aby rozmyślać o kolejnych odsłonach Scalania = spotkań z językiem Scala.

To już drugie spotkanie pod szyldem scalania i przy 60 osobach zarejestrowanych daje poczucie sensowności kontynuacji pomysłu, aby praktycznie, przez przykłady, poznawać Scalę. Idzie całkiem przyjemnie, ale wciąż nie jestem zachwycony z niewielkiego odzewu ze strony uczestników. Na szczęście dzisiaj udało mi się zamienić słowo z kilkoma i wiem, jak i dlaczego należałoby poprowadzić kolejne odsłony.

Dziękuję wszystkim uczestnikom, a w szczególności +Paweł Cesar Sanjuan Szklarz i +Grzegorz Kubiak za wprowadzenie w tajniki Scali na początku spotkania oraz firmie Javart za wsparcie sponsorskie. Sponsor sprawił, że poza wiedzą merytoryczną, mogliśmy zapomnieć (choćby na chwilę) o głodzie i pragnieniu. Dziękuję!

Nowością dzisiejszego spotkania było "odpalenie" (wcześniej planowanych na 10 minut) 15-minutowych wprowadzeń w konstrukcje języka Scala, które mogą być nieocenione przy rozwiązywaniu zadań. Z dyskusji po spotkaniu wnioskuję, że to należy utrzymać.

Co uzmysłowiono mi po spotkaniu to powód, który może być główną przyczyną, że na Scalaniach mamy taką obsadę. W końcu zadania można rozwiązywać samodzielnie w domu, na plaży, gdziekolwiek, więc po co ten trud związany z przyjściem na spotkanie?! Trudno uzasadnić to bez czegoś szczególnego. I tym szczególnym czymś okazuje się być...możliwość porównywania rozwiązań wspólnie i omawianie technik programistycznych. Dyskusja o nich wydaje się być niemożliwa do odtworzenia w samotności. To należy utrzymać.

Pomysłem na kolejną odsłonę jest wybór 3 osób z zarejestrowanych, które przygotują się do poprowadzenia wstępu niezbędny do rozwiązania kolejnych zadanek.

Padł również pomysł, aby pogrupować uczestników w 3-4 osobowe grupy, wśród których byłaby 1-2 osoby znające Scalę. W taki sposób możnaby pozwolić osobom dyskutować o rozwiązaniach w mniejszych grupach, aby później wyeksponować je dla wszystkich. Nie wiem, czy należałoby to wdrożyć już na kolejnym, trzecim spotkaniu, ale z pewnością należy to rozważyć.

Istotną zmianą w stosunku do dzisiejszego spotkania musi być utrzymanie tempa rozwiązywania zadań, tak aby już wykonane nie były rozwiązywane ponownie (co przytrafiło nam się dzisiaj). Jeszcze nie potrafię wyobrazić sobie, co zrobić z nowymi osobami do języka oraz scalania w ogólności, ale wstępnie zaproponowano stworzenie podsumowań spotkań poprzednich w postaci ściąg z konstrukcjami języka Scala, które oczekuje się od uczestników kolejnych spotkań. Z dzisiejszego dnia należy zapamiętać czym jest dopasowanie wzorców (ang. pattern matching), def do definiowania metod i kilka metod scala.collection.immutable.List.

Udoskonaleniem należałoby uważać tworzenie agendy spotkania, które powinno usprawnić komunikację między organizatorami a uczestnikami.

I ten dostęp do Internetu. Mam wrażenie, że na MIMUWie powinno być detalem, który łatwo da się obsłużyć, jeśli zająć się tym z wyprzedzeniem. Trzeba o tym koniecznie pamiętać przygotowując kolejne scalania.

Co jeszcze? Podziel się swoimi pomysłami w komentarzach poniżej, albo na forum Warszawa JUG.

Zachęcam również do nadsyłania propozycji zadań w postaci pull requestów (PR) w projekcie scalania na GitHubie. Zgłoszono mi kilka błędów w sygnaturach metod, więc liczę na kilka PRów niebawem. Wciąż ich za mało. Nie każ mi długo czekać. Proszę.

Trzecia odsłona scalania już niebawem. Bacznie obserwuj platformę spotkań grupy Warszawa JUG.

Zdjęcia ze spotkania znajdują się w moim albumie Scalania 2 na G+.

p.s. Firmy zatrudniające w Warszawie programistów scalowych: Javart, Citi, Coeditor, AdPilot i NetSprint. Jest w czym wybierać i wierzę, że wybierzesz właściwie :-)

Scalania #2 - spotkania z językiem Scala w najbliższą środę, 28 sierpnia

Zapraszam na drugie spotkanie z językiem Scala - Scalania - w najbliższą środę, 28 sierpnia. Więcej informacji logistycznych na stronie spotkania http://scalania.pl.

Największą zmianą w stosunku do poprzedniej, inauguracyjnej edycji będzie 30-minutowe wprowadzenie uczestników w konstrukcje języka Scala, które będą przydatne do rozwiązywania zadań. Dodatkowo motywem przewodnim będzie praca z projektami z GitHuba, co powinno dodatkowo zachęcić uczestników do jego aktywnego użycia na potrzeby własnego samorozwoju.

Będąc pod ogromnym wrażeniem zawartości książki Functional Programming in Scala będzie wiele zadań z rozdziału o monoidach (10. Monoids) i opóźniania wykonywania (5. Strictness and laziness).

Zapraszam!

Scalowo na Scalania 1.0

Na pierwszej edycji Scalania pojawiło się ponad 40 osób! Jak pisałem na przeddzień spotkania było przez to różnorodnie pod względem wiedzy o języku Scala, co znalazło swój oddźwięk w komentarzach na Meetupie, szczególnie pod kątem osób nowych w temacie.

I faktycznie było kilka nowych osób, które nie zraziły się jednak tłumem i wyrażały swoje potrzeby w poznawaniu składni języka czy zestawienia środowiska pracy. Brawo za aktywny udział!

Co jest zaskakujące, to trafność zapisów - prawie 100%. Na 43 osoby, które zapisały się na Meetupie na dzień spotkania, przyszło 43! To odbiega od tradycyjnego stosunku deklaracji do faktycznego udziału. Kolejne brawa za rozsądek.

Rozpoczęliśmy o 17:30 od przywitania sponsora - firmy Javart - i przedstawienia jego profilu. Potrzeb kadrowych do projektów w języku Scala jest sporo, więc zainteresowani nimi proszeni są o natychmiastowy kontakt ze sponsorem.

Dzięki Javartowi mogliśmy liczyć na (obfity!) poczęstunek oraz dwie książki „Język programowania Scala” Grzegorza Balcerka + inne gadżety mniejszego kalibru merytorycznego. Brawa dla sponsora! Już się mówi o jego dalszych akcjach okołoscalowych w projektach oraz w ramach Warszawa JUG i Scalania.

Po 15 minutach byliśmy gotowi do pierwszego zadania. Na tapetę poszło P01 (*) Find the last element of a list. Krótka dyskusja o możliwych rozwiązaniach (tutaj należałoby wesprzeć się scaladoc, ale zabrakło tego w wymaganiach i wielu nie spełniała tego warunku), aby ostatecznie spróbować rozwiązać to wspólnie. Ponownie krótka wymiana wiedzy i nadjechał Subway.

Czas jedzenia upłynął na dyskusjach o możliwych rozwiązaniach i innych sprawach scalowych.

Od około 18:30 aż do 20:30, z niewielką przerwą na zestaw pizz, rozwiązywaliśmy zadania, aby dojść do P08 (**) Eliminate consecutive duplicates of list elements.

W międzyczasie posiłkowaliśmy się wiedzą naszych ekspertów w osobach +Grzegorz Balcerek oraz +Grzegorz Kubiak. Skorzystaliśmy z niej kilkakrotnie, za co obu panom baaaaardzo dziękuję.

Formuła spotkania, a właściwie rozwiązywania zadań, kręciła się wokół schematu - krótka dyskusja o potencjalnych taktykach na rozwiązanie zadania (tutaj ponownie namawiałbym na użycie scaladoc, ale wielu go po prostu nie miało), sama próba napisania rozwiązania zadania samodzielnie przez uczestników, aby po 5-10 minutach omówić rozwiązanie. Początkowo ja omawiałem rozwiązania z niewielką pomocą publiczności, aby przy końcowych zadaniach całkowicie zejść ze sceny i pozwolić innym na napisanie rozwiązania na moim laptopie (w SublimeText 2 ze względu na podświetlanie składni), uruchomienie w Scala REPL i próbowanie rozwiązań alternatywnych.

Pomysł angażowania publiczności do prezentowania własnego rozwiązania uważam za najbardziej wartościową rzecz całego spotkania. Nie sądziłem, że się uda. Udało się i powiem, że mimo wielu osób, spotkanie udało się utrzymać w pewnych ryzach merytoryczno-logistycznych (szczególnie pod kątem zabierania głosu przez uczestników). Pełna kultura. Brawo!

Dla mnie, Scalania 1.0 było bardzo wartościowym spotkaniem społecznościowo oraz merytorycznie. Uważam, że komentarze nie pozostawiają złudzeń, że należy Scalania kontynuować, a nawet podzielić na szkółkę (dla początkujących - bez odbycia kursu Functional Programming Principles in Scala na Coursera), akademię (dla bardziej zaawansowanych) oraz hack-a-thon, scalatron czy wspólne rozwiązywanie błędów w projektach scalowych, np. kalibru Akka czy Play Framework. Właśnie takiej wiedzy potrzebowałem (przed wakacjami), aby trafniej organizować kolejne edycje Scalania, których jedynym celem jest zwiększenie zainteresowania językiem Scala i dogłębne zrozumienia jego cech (nie mylić z trait). Myślę, że jesteśmy na dobrej drodze.

A jak Tobie się podobało? Komentarze mile widziane, bo bez pomocy będzie podobnie (bo w końcu, ile jedna osoba może mieć wiedzy, jak coś zrobić dobrze?!) Liczę na bogaty (merytorycznie) strumień komentarzy.

Dziękuję wszystkim za możliwość odpalenia inicjatywy Scalania. Do zobaczenia niebawem.

Scalania - spotkania z językiem Scala

Jutro, we wtorek, 9 lipca na wydziale Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego (MIM UW) na Banacha 2 w Warszawie odbędzie się pierwsze spotkanie-warsztaty (aka kata) związane z językiem Scala - Scalania - w ramach cyklicznych spotkań warszawskiej grupy javowej (Warszawa JUG).

Po moim przejściu do Citi na stanowisko szefa zespołu programistów Scala/Clojure/Java (a może i F# niebawem) język Scala jest mi niezwykle bliski i będzie go coraz więcej wokół mnie. Stąd też pomysł, aby w miłym gronie podszkolić się z tego języka, bo podobnież najlepsza nauka możliwa jest przy dobrej zabawie w doborowym towarzystwie. W Citi, przy projektach komercyjnych, to jedno, a w ramach Warszawa JUG, to drugie. Nie mogłem odmówić sobie przyjemności skorzystać z obu miejsc. Wybaczcie zachłanność.

Patrząc na zestawienie uczestników pierwszego Scalania nie mam obaw, że dobre towarzystwo jest wliczone już w kontrakt! Na moment pisania tego wpisu swój udział zadeklarowały 43 osoby, co dwukrotnie przekroczyło moje początkowe oczekiwania (i trochę zbiło z tropu, bo pojawiły się niemałe obawy, czy da się mój pomysł zrealizować w takim tłumie).

Zaczynamy wyjątkowo o 17:30 z zestawem krótkich zadań programistycznych od Grzegorza Balcerka oraz S-99: Ninety-Nine Scala Problems. Grzegorz, z którym pracuję w Dream Teamie w Citi, zadeklarował swoją pomoc i pojawi się na spotkaniu! Nie tylko, że skorzystamy z jego zadań i jego obecności, ale wręczymy dwa egzemplarze jego książki "Język programowania Scala". Nie mam już obaw odnośnie obsady i zawartości merytorycznej.

Na spotkaniu pojawi się również Grzegorz Kubiak z Javartu, które postanowiło wejść aktywnie w organizację Scalania i ją uatrakcyjnić. Możemy liczyć na wsparcie merytoryczne Grzegorza oraz strawę! Z Javartem spotkanie będzie znacznie przyjemniejsze. Dzięki Grzesiek i nasz sponsor - Javart! Będzie doskonała okazja zamienić słowo z Grzegorzem o możliwym zaangażowaniu w projekty scalowe w Javarcie. Od dzisiaj, kiedykolwiek pomyślę o pracy ze Scalą w Warszawie na myśl przyjdą mi dwie firmy - Citi oraz Javart (kolejność nieprzypadkowa).

Więcej o samym spotkaniu na stronie Scalania.pl. Zapraszam!

Czego i jak się uczyć funkcyjnej Scali - relacja z wystąpienia na deskach Warszawa JUG

Moje pierwsze kroki w programowaniu funkcyjnym w Scali

To było moje pierwsze, deklarowane wystąpienie na deskach grupy Warszawa JUG, w którym kładłem nacisk na materiały i techniki poznawania nowego obszaru niż na samym obszarze. Programowanie funkcyjne i Scala były jedynie nośnikami, a nie meritum sprawy. I właśnie w chwili, kiedy ruszałem na spotkanie, na Ursynowie zerwało chmurę. Lało tak mocno, jakby ktoś się zawziął i postanowił nie wypuścić mnie z klatki (dosłownie i w przenośni). Istne oberwanie chmury. Nie zapowiadało się dobrze.

Miałem niemałe obawy, czy formuła mojego wystąpienia wpasuje się w oczekiwania uczestników. Z jednej strony utożsamiany jestem z tematami technicznymi (powstrzymam się od poprzedzenia ich "wysoko"), a z drugiej strony wiele osób pyta "Czego i jak się uczyć?". Postanowiłem spróbować swoich sił w prezentacji moich sposobów na efektywną naukę.

Przed spotkaniem miałem możliwość zamienić słowo z kilkoma, wcześniej nieznanymi mi osobami, które tylko wzmogły we mnie obawy o tematyce mojej prezentacji - bardziej zależało im na samej nauce Scali niż na metodach, które mogłyby w tym pomóc. I coś mi mówi, że niepotrzebnie się wsłuchiwałem w głos tłu...gawie...uczestników, bo tylko przysporzyło mi więcej nerwów niż pewności siebie. Bywa.

I zaczęło się!

Najpierw wystąpienie sponsora spotkania - firmy Decerto (również znani jako "Systemy informatyczne dla biznesu") - w osobie Tomka Kucharskiego. Dzięki Tomek za miłe słowa o mojej osobie i chwilę, w której mogłem ochłonąć (z komentarzy), ale tytuły, którymi mnie "obrzuciłeś", jeszcze bardziej wzbudziły we mnie niepokój.

Liczba uczestników i komentarze nie pozostawiały złudzeń, że musi być technicznie.

Nie było. A przynajmniej nie w mierze, która mogłaby zadośćuczynić oczekiwaniom publiczności. Bywa. Prezentacja na SlideShare a nagranie niebawem. Sugeruję obserwować forum Warszawa JUG.

Dziękuję Agnieszce, Michałowi, Jankowi, Stefanowi, Piotrowi, Julkowi, Pawłowi i pozostałym uczestnikom za podjęcie się trudu uatrakcyjnienia spotkania przez udział w dyskusjach podczas niego, czy po prostu podejście do mnie, aby przywitać się i zamienić słowo. Uścisk dłoni, bezcenne!(TM) Byłem zaszczycony móc Was gościć na moim spotkaniu i poznać Was wszystkich osobiście.

Komentarze dotyczące mojego wystąpienia znajdziesz na stronie spotkania na Meetupie. Zachęcam do komentowania i wyrażania swoich pozytywnych oraz krytycznych uwag. Niech kolejne, moje wystąpienia publiczne staną się lepsze (czytaj: dopasowane do oczekiwań uczestników, co niekoniecznie oznacza, że faktycznie będą lepsze :-))

Dziękuję wszystkim za udział. Jednocześnie zachęcam do dzielenia się własnym warsztatem poznawczym, abyśmy stali się społecznością, w której rodzą się ciekawe pomysły (zamiast naśladować czy uczyć się innych). Wciąż zdecydowanie "wynalazczości" wśród nas. Wszystko pro publico bono!

p.s. Właśnie wpadłem na ciekawy pomysł prezentacji - "Poznaję Scalę rozwiązując zagadki z Project Euler". Można również pokusić się o uruchomienie prezentacji w stylu kata z pomysłami z Any practical coding dojo/kata ideas? Kto chciałby wziąć udział w takim pomyśle - jako organizator, (współ)prowadzący czy uczestnik? Ciekawym Twojej opinii.

Moje pierwsze kroki w programowaniu funkcyjnym w Scali na 115 spotkaniu Warszawa JUG

Jutro, wtorek, 21.05.2013 o godz. 18:00 w sali 3180 w budynku wydziału MIM UW na Banacha 2 odbędzie się stopiętnaste (115) spotkanie Warszawa Java User Group, na którym przedstawię temat Moje pierwsze kroki w programowaniu funkcyjnym w Scali.

Link do rejestracji i miejsca, w którym można podyskutować o spotkaniu (przed, w trakcie i po) znajduje się na stronie spotkania.

Poniżej rozwinąłem temat mojego wystąpienia, ale uważam, że użycie "moje", "pierwsze kroki" oraz "programowanie funkcyjne w Scali" mówią same za siebie i dalsza lektura to...strata czasu.

Skoro jednak nalegasz...

Kurs "Functional Programming Principles in Scala" na Coursera dobiega końca i przez ostatnie 7 tygodni intensywnie mnie absorbował. Do tego stopnia, że pozwoliłem sobie na stosunkowo regularne zarywanie nocek w poszukiwaniu rozwiązań (!) Bolało.

Po szkoleniu "Scala i programowanie funkcyjne" Grześka Balcerka wiedziałem, że nauka nowego języka Scala i jego połączenia programowania obiektowego z funkcyjnym nie będzie lekka i pewnie dlatego postanowiłem zintensyfikować wysiłki, aby po początkowych trudach, ostatecznie poczuć klimaty nowego języka. Równocześnie uzupełniałem wiedzę lekturą pisanej właśnie książki "Functional Programming in Scala" z Manning. Rzuciłem na moment programowanie funkcyjne w Clojure na rzecz Scali, aby w ten zaowalowany sposób przeprowadzić kilku śmiałków w świat...Clojure (to taki mój "tajny" plan).

Mając pewne doświadczenie z programowaniem funkcyjnym w Clojure i F#, większość problemów nie była trudna intelektualnie, ale nowa składnia oraz niektóre problemy spędzały mi sen z powiek na długie godziny. Najbardziej zaskoczył mnie brak umiejętności przejścia z programowania funkcyjnego w Clojure na idiomatyczny kod w Scali, który łączył elementy programowania funkcyjnego z obiektowym, w którym typy miały niebagatelne znaczenie (na wzór F#, co pomagało). Najpierw trzeba mi było zapomnieć o OO w Javie na rzecz Clojure, a teraz ponownie OO z FP w wykonaniu Scali. Nie było lekko.

Nowy język to nowe konstrukcje, narzędzia, sposób myślenia i pewnie kilka innych rzeczy. Swoje dokonania opisywałem względnie na bieżąco na swoich blogach, a tym razem skorzystałem z okazji, aby przedstawić moje doświadczenia na żywo. Podczas prezentacji chciałbym zademonstrować mój własny warsztat poznawczy Scali (Sublime Text 2, sbt, Scala REPL, git) oraz sposoby rozwiązywania niektórych problemów programistycznych w Scali, które miałem okazję spotkać w kursie na Coursera.

Będzie trochę slajdów. Będzie trochę programowania na żywo. I będzie w końcu kilka spostrzeżeń, którymi chciałbym zachęcić do wymiany doświadczeń między uczestnikami. Nie sądzę, aby brakowało chętnych do poznania języka Scala oraz samego paradygmatu funkcyjnego, więc dyskusji spodziewam się całkiem sporo. Taki mam plan. Przyjdź i pomóż mi go zrealizować!

Funkcyjny maj na Coursera, Atmosphere Conference, GeeCON, Warszawa JUG oraz JEEConf

Z tygodnia na tydzień zadania w szkoleniu Functional Programming Principles in Scala w serwisie szkoleniowym Coursera stają się boleśnie trudniejsze. Coraz częściej przekraczają moje możliwości intelektualne i cierpi moja dusza (ego) oraz ciało (z powodu przeciągającego się niedostatku snu).

Ale się nie poddaję! Dam radę i ostatnie wyniki są obiecujące - już gwarantują, że za zadanie z tygodnia 6 o anagramach, w którym należy wyznaczyć wszystkie anagramy podanego zdania, otrzymam co najmniej 8,46 na 10 możliwych. Została już tylko jedna funkcja do implementacji i będę w domu. Może nawet wcześniej w łóżku!

Brakuje mi najbardziej, aby z kimś pogadać na temat programowania funkcyjnego w Scali, ale nie odpuszczam również Clojure (i rzadziej F#). Język zaczyna mieć mniejsze znaczenie, bo zależy mi najbardziej na pełnym przyswojeniu myślenia funkcyjnego. Scala, Clojure czy F# to jedynie zestaw słów, którymi mogę wyrazić "zdania" funkcyjne.

I w nadchodzący poniedziałek, 13 maja, pojawię się w Poznaniu na konferencji Atmosphere Conference 2013 z tematem Functional web development with Git(Hub), Heroku and Clojure. Temat niespecjalnie rozwijany od ostatniego mojego wystąpienia z nim podczas łódzkiej konferencji Przyszłość w IT (właśnie przez "wtopienie" ze Scalą na Courserze). Wierzę jednak, że wiedza z alternatywnego języka Scala wzbogaci tę o Clojure, co sprawi, że poziom merytoryczny wystąpienia będzie wysoki. Ciekawym komentarzy po.

Z Poznania udaję się 15 maja do Krakowa na GeeCON 2013, w trakcie którego zamierzam kontynuować mój rozwój w kontekście programowania funkcyjnego. Poza udziałem w kilku prezentacjach o Scali i Clojure, dzięki uprzejmości organizatorów poprowadzę panel dyskusyjny Functional Programming - radical thinking shift and step towards clearer and reliable software. Kiedyś już uczestniczyłem w panelu jako mówca (z twórcą Spring Framework - Rod'em Johnson'em, James'em Strachan'em oraz Ted'em Neward'em w roli moderatora), a teraz przyszło mi się zmierzyć z trudniejszą rolą - moderowaniem panelu z udziałem znawców tematu programowania funkcyjnego. To 17 maja. Liczę na pomoc, bo animowanie dyskusji bez zainteresowania nią wśród uczestników może być kolejnym (majowym) wyzwaniem.

Później na chwilę wracam do Warszawy, aby 21 maja wystąpić na deskach grupy Warszawa JUG z tematem Moje pierwsze kroki w programowaniu funkcyjnym w Scali. Nie widzę go jeszcze opublikowanego na stronie grupy, ale wstępnie mam akceptację grupy organizatorów cyklicznych spotkań, więc spodziewam się ogłoszenia niebawem. Zachęcam do udziału, bo liczę na aktywny udział obu stron - prowadzącego oraz słuchaczy - co powinno wyjść na dobre każdemu. Na pewno pomoże w zrozumieniu chociażby kilku problemów funkcyjnych, z którymi borykałem się podczas kursu Odersky'ego na Coursera, warsztatów Grześka Balcerka oraz lektury Functional Programming in Scala.

A pod koniec tygodnia, 24 i 25 maja, pojawię się w Kijowie na konferencji JEECOnf. Tam zdobędę się na wystąpienie o Clojure (Introduction to web application development in Clojure) i Scali (Introduction to functional programming in Scala). Jednocześnie o obu językach? Tego jeszcze nie było w moim wykonaniu! Nie mogłem odmówić sobie spróbowania, bo okazja do bezpośredniej wymiany doświadczeń nie zdarza się często. Będzie z pewnością bogato merytorycznie, bo w końcu będę mógł podjąć się wyjaśnienia pewnych problemów programistycznych przez pryzmat języków Java, Clojure, a teraz i Scala. Ciekawym, kiedy do mojego repertuaru dołączy F#?!

Do zobaczenia!