poniedziałek, 28 maja 2012
Wrażenia po prowadzeniu mini praktyk niestudenckich
Ostatnio, w czasie gdy większość z Was oddawała się GeeCON'owemu szaleństwu, lub spędzała kolejny nudny dzień w pracy tworząc super tajne projekty, ja miałem okazję podszlifować i wypróbować moje zdolności mentorskie (o ile takie w ogóle posiadam). Od zawsze lubiłem dzielić się swoją wiedzą z innymi. W przypadku programowania, to już na pierwszym roku studiów udzielałem korepetycji koleżankom z liceum, w zamian za ciepły obiadek :) Później zaangażowałem się w Warsztaty programowania urządzeń mobilnych przy Studenckim Kole Naukowym Informatyki Systemów Autonomicznych i Adaptacyjnych. Później zacząłem pisać tego bloga i coś tam od czasu do czasu ludziom przedstawiać w ramach JUG-ów. A teraz prowadzenie praktyki było czymś nowym dla mnie.
W minionym tygodniu dostałem od Marcin Saneckiego pod opiekę praktykanta Adriana. Uczęszcza On do technikum informatycznego i nastał taki moment, że musiał odbyć / odbębnić praktykę w zawodzie. Inni jego rówieśnicy, albo przeinstalowują systemy operacyjne w swoim liceum, albo idą do jakiegoś sklepu komputerowego składać blaszaki. Ostatecznie, jak nie mogą nigdzie znaleźć firmy, która przyjmie ich na praktykę, to idą do jakiś urzędów państwowych, gdzie można się tylko zniechęcić i uwstecznić.
Jako że Adrian nie do końca jest przekonany, co chce w życiu robić, miałem utrudnione zadanie. Miałem go zachęcić (a jeszcze lepiej przekonać go), aby szedł w stronę IT, a najlepiej programowania. Czy musiałem mu pokazać coś ciekawego, gdzie szybko widać fajny efekt pracy i co daje przyjemność samo w sobie. No i do tego miałem niewiele czasu (właściwie wyszły 2 dni po około 5 godzin). Mój praktykant miał podstawy Pascala (tzn. gdzieś tam w technikum się go kiedyś uczył) i trochę widział Html'a i Java Script'a. Ja słysząc tą ostatnią informację, trochę się przeraziłem, gdyż ja sam byłbym mocno zniechęcony do dalszej nauki po pobieżnym poznaniu JS.
Miałem więc bardzo trudny orzech do zgryzienia, gdyż młody adept sztuki programistycznej miał niewielkie doświadczenie, a musiałem w krótkim czasie coś go nauczyć i pokazać, że programowanie może być fajne i dawać satysfakcje. Zacząłem więc sobie przypominać, jak to było kiedyś ze mną, co mi dawało motywację, było łatwe, a efekt końcowy był szybko widoczny.
Mój wybór padł na Javę Micro Edition i postanowiłem stworzyć razem z Adrianem coś co by przypominało grę tank 1990. Odgrzebałem więc swoją starą prezentację na temat Tworzenia graficznego inferface’u użytkownika niskiego poziomu w J2ME, gdzie właśnie przedstawiałem jak operować prostymi obiektami dwuwymiarowymi. Prezentacja co prawda z 2009 roku, przygotowana na potrzeby wspominanych wcześniej warsztatów z J2ME, ale teraz po latach się przydała w celach szkoleniowych. Odgrzebałem też kod (jest on również przypięty do tamtej prezentacji) i pousuwałem z niego bardziej zaawansowane wynalazki, zostawiając namalowany jeden czołg i resztę szkieletu całej aplikacji. Był to nasz punkt wyjścia. Pozostałe prezentacje moje i kolegów z tego okresu można również znaleźć na slideshare.net.
Na początku wspólnej praktyki z Adrianem (i częściowo z Marcinem) przygotowaliśmy niezbędne środowisko programistyczne, czyli JDK7 (32 bit), NetBeans i dodatkowo WTK od Sony Ericsson'a (jakby standardowy emulator z nowym WIndowsem 7 nie chciał działać). Zeszło nam na to trochę czasu, ale końcem końców udało i można było zacząć zabawę.
Zaczęliśmy od jednego namalowanego czołgu. Nie tłumaczyłem w ogóle czym jest obiekt, a czym klasa a jedynie uczyłem przez analogię: „Aby przesunąć czołg trzeba wywołać na nim metodę move()...”, „tu masz wczytywanie obrazka, teraz wczytaj inny...” itd. Adrian często kopiował kod i zmieniał niewielkie fragmenty, rozszerzając w ten sposób funkcjonalność. Odwoływałem się również do języków, które on znał. Było o tablicach, praktycznym zastosowaniu pętli for i warunku if. Całość dopełniona slajdami i moją cierpliwością do tłumaczenia i poprawiania błędów składniowych. Ostatecznie dotarliśmy na koniec drugiego dnia do jeżdżącego czołgu po ładnej mapie z wykrywaniem kolizji z przeszkodami i niewyjeżdżaniem po za ekran.
Chciałem jeszcze zrobić strzelanie do cegieł, ale teraz wiem, że to trochę bardziej skomplikowana historia i mogła by on zniechęcić do dalszej nauki. Zresztą widziałem, że Adrian był już wymęczony tym kodowaniem.
Pewnie się zastanawiacie, czemu nie skorzystałem z Androida (pytał o to Jacek Laskowski na Twitterze)? Otóż żaden z nas nie posiadał telefonu z tym systemem, musiałbym wcześniej przygotować szkielet startowy (decyzja, że dzisiaj zaczynamy kodowanie wyszła bardzo spontanicznie), emulator androida dłużej startuje i miałem akurat prezentację na temat J2ME pod ręka. Technologia ta (Android w sumie też) daje nam szybką pętlę zwrotną, czyli wprowadzamy małą zmianę uruchamiamy emulator i oglądamy efekt. Dzięki temu praktykant może widzieć postęp swoich prac i kojarzyć, że napisanie pewnych linijek kodu, powoduje jakąś zmianę. Również efekt końcowy jest fajny, gdyż można wrzucić na telefon i pokazać kolegom w szkole. No i nie jest to nudna kolejna strona w HTMLu.
Całe wydarzenie uważam za udane. Czy Adrian się przekonał do kodowania? Nie wiem (ciągle czekam na feedback). Na pewno poczuł jak wygląda praca programisty i że można się przy niej zmęczyć, np. szukając babola w kodzie.
Dla zainteresowanych powtórzeniem ćwiczenia udostępniam kod na githubie. Proponuję zaczynać od rewizji 1d6ca27cc7be0507f4a9eda86e48957d1717c8d3, czyli mniej więcej od kodu z którego razem z Adrianem wychodziłem. Jest tam prezentacja przedstawiająca podstawy, jak i wyjaśniająca, co należy robić. Wrzuciłem również prezentację na slideshare.net, ale tam po kompresji prezentacja już nie wygląda tak jak powinna. Za jakiś czas udostępnię rozwiązanie w postaci kodu, jak i filmu z mojego kodowania. Materiał już nagrany, czeka tylko na post produkcję. A Was zachęcam do spróbowania swoich sił w J2ME i do zadawania pytań. Chętnie odpowiem.
sobota, 5 maja 2012
Przyszłość języków programowania, czyli kiedy i kto wygra nadchodzącą rewolucję?
Kiedyś na blogu Touching the Void przeczytałem ciekawego posta: 30 lat z życia programisty. Zaciekawił mnie ten artykuł i od jakiegoś czasu bacznie obserwuję sytuację, wypatrując następcę programowania obiektowego.
Ogółem z artykułu wynika, że co 8-10 lat jest jakaś globalna rewolucja w świecie programowania, co sprawia, że wszyscy się masowo przerzucają na dany język (czy tez bardziej ogólniej: na inny paradygmat programowania). Java już swoje przeżyła / dożywa...
Jaki język zastąpi Javę?
Ogółem świat dąży do tego, aby stworzyć taki język, że specyfikacja klienta będzie wykonywalnym programem. Niektórzy twierdzą, że wtedy programiści nie będą już potrzebni, ale pewnie nawet jak jakiś tego typu język powstanie, to i tak trzeba będzie zapisać tą specyfikację w odpowiedni sposób (czyli przez programistę). Przejawy dążenia w tym kierunku widzę w Spring Roo i w coraz popularniejszych DSL’ach (np. w Scali). Jednak raczej się nie zapowiada, aby taki kompletny język specyfikacji w najbliższym czasie powstał. Pewnie tęgie głowy na nie jednej wyższej uczelni próbują coś takiego stworzyć (albo chociaż opracować podstawy teoretyczne), ale chyba póki co chyba bez większych sukcesów – przynajmniej ja nie znam.
Wracając jednak do świata komercyjnego, to Java króluje na scenie już ponad 10 lat. Obecnie do głosu powoli dochodzą (wg. mnie i w/w. wpisu) języki funkcyjne. Wystarczy spojrzeć na to ile się o nich mówi na konferencjach. Wydaje się, że niedługo nastąpi ich czas. A może zaskoczy nas coś całkowicie innego? Może coś z kreowane przez konkurencję JVM’a? Może jakiś inny pragdygmat? Może w końcu powstaną komputery kwantowe?
Chcąc analizować popularność języków programowania warto się przyjrzeć statystykom prezentowanym na portalu tiobe.com. Ranking jest ogółem wyliczany na podstawie statystyk wyszukiwania na popularnych stronach takich jak Google, Blogger, Wikipedia, jak i na YouTube i Amazonie. Ważna jeszcze jest wartość „page hits”.
Pierwszym zaskoczeniem jest język C, który cały czas się trzyma wysoko, a teraz nawet przegonił Javę. Podobno niektóre uczelnie wyższe powoli przestają go uczyć, ale ranking ten wskazuje, że to chyba błąd.
Kolejną ciekawostką jest bardzo szybka rosnąca popularność Objectiv-C. Jednakże język ten jest skierowany do specyficznej grupy odbiorców i nie zapowiada się, aby wyszedł po za nią.
Ciekawy jest też wykres dla Rubiego. Generalnie Wujek Bob mówił, że jakiś czas temu w Stanach było najłatwiej znaleźć pracę programistom rubina, jednakże teraz ta sytuacja się już zmienia i raczej odchodzi się od tego języka. Potwierdza to wykres jego popularności.
Tak można by było jeszcze analizować i analizować, ale zostawiam to Wam do własnej oceny i interpretacji. Wróćmy do głównego wątku, czyli co z tymi językami funkcyjnymi?
Patrząc na tabelki i wykresy można dostrzec, że jeśli chodzi o programowanie funkcyjne, to najwyżej stoi Python (8. miejsce), Perl (10.) i Lisp (15.). Nie są to języki, które są tylko funkcyjne, ale posiadają również cechy innych paradygmatów programowania. Dalej w zestawieniu jest jeszcze kilka języków z paradygmatem funkcyjnym. Natomiast Scala, która jest mocno promowana na konferencjach javowych, jest dopiero 45, a Clojure znalazł się po za pierwszą 50dziesiątką. Fakt faktem Tiobe może niekoniecznie jest najlepszym wskaźnikiem do porównywania popularności języków, ale nie znam innego podobnego zestawienia, pokazującego zmianę w czasie.
Mnie zastanawia dlaczego jeszcze nie pojawił się / jaki będzie język obecnej dekady, na który by się masowo przesiadało większość firm, tworząc oprogramowanie w tym języku, zamiast w Javie. Przyszło mi do głowy kilka przyczyn.
Według mnie największym mankamentem nowych języków programowania, jest brak narzędzi. Brakuje dobrych, rozwiniętych i stabilnych środowisk IDE. W Javie mamy IntelliJ Idea, gdzie automatyczny refaktoring jest bezbolesny, narzędzie podpowiada składnie zależnie od kontekstu i wie co chcemy napisać. Eclipse jest trochę słabszym narzędziem, ale znam takich co są z niego zadowoleni. Obecne dostępne IDE tak nas rozpieściły swoimi możliwościami, że aż nie chcemy siadać do jakiegoś języka, gdzie nie ma porządnego wsparcia ze strony środowiska programistycznego. Dla tego ja osobiście mocno kibicuję Kotlin’owi, który powstaje od razu ze wspierającym go IDE - aby mu się udało.
Inną bolączką nowych języków, jest brak (lub niewielka wciąż ilość) informacji, o dużych projektach, które się udały w nowopowstałych językach. Dla przykładu Twitter z Ruby’iego przenosi swoje główne elementy na JVM’a (Więcej na ten temat we wpisie: 33 degree 2012 dzień 1). To na pewno nie przystworzyło to Rubiemu popularności, co widać na wykresie.
Innym tematem, który sam doswiadczyłem na przykładzie Scali, jest ewolucja składni w przypadku nowych języków. Niby było zapowiadane, że Scala do kiedyś tam może być niekompatybilna wstecz, ale się odechciewa, gdy uruchamiając przykłady z tutoriala / książki na nowszej wersji, starsza składnia nie jest akceptowana.
Kolejną sprawą jest to, co się obecnie uczy młodych adeptów sztuki programowania na studiach informatycznych i pokrewnych. Cały czas wiodące języki, od których się zaczyna, to C/C++ i Java. Co do języków funkcyjnych, to kojarzę że na jakimś kursie w połowie studiów był Lisp, ale do tego czasu większość już się nauczyła nie chodzić na zajęcia, a i tak mimo tego zaliczać. Zresztą jaką tu mieć motywację do nauki czegoś, gdzie nie bardzo się widzi, aby którykolwiek pracodawca wymagał tego wynalazku przy rekrutacji?
Teraz każda firma / instytucja / przedsiębiorstwo, chce mieć jakieś oprogramowanie. Najlepiej szybko dostarczone, aby móc wyprzedzić konkurencję i aby zastąpić człowieka tam gdzie się da. Powoduje to, że projektów jest coraz więcej, a na to potrzeba więcej ludzi. Kiedyś (podobno – słyszałem z opowieści starszych), na studia informatyczne było o wiele ciężej się dostać, ale przez to trafiali na nie tylko zapaleńcy. Obecnie dalej nie jest łatwo, ale miejsc jest trochę więcej i mamy alternatywę po za uczelniami państwowymi. Potrzbujemy więcej zasobów ludzkich, ale jak fajnie zuaważyl Michał Bartyzel (autor bloga od którego rozpocząłem ten wpis) w poście: Craftsmanship nie dla wszystkich?, nie potrzebujemy w projektach samych wymiataczy. Wystarczy kilku rzemieslników, a reszta to moga być przeciętniaki, którzy robią od 8 do 16 i są niereformowalni.
Tak więc mamy grupę ludzi, która chce podążać za zmianami, być na bieżąco i nie skończyć jako dinozaury. Mamy też przeciętniaków którzy będą niechętni na całkowitą zmianę języka, lub jego wprowadzenie do projektu obok Javy. Musieli by oni wówczas poznać nowa składnię, przez co poczucie ich bezpieczeńswa / pewności zostałoby zaburzone. Niby nauka nowego języka nie powinna być dla nas problemem (w końcu podczas studiow się pisało w różnych dziwnych rzeczach), ale niektórzy mają ku temu spore opory w swojej pracy.
Co do samej ilości programistów, to problem z wyszkoleniem (wyprodukowaniem) odpowiedniej ich liczby, dobrze widać na zachodzie. Przykładowo w Niemczech, powstały już takie Hochfachschule (nazwałbym to wyższą zawodówką), które szkolą osoby pod konkretne technologie. Tzn. trwają one krócej niż normalne studia, a nacisk kładą na praktykę, ograniczając teorię do minimum. Bo i po co to komu? Na studiach to jest potrzebne, bo liczy się na to, że jednak ktoś z grona studentów pójdzie w stronę doktoratu, zostanie na uczelni i będzie przekazywał zdobytej wiedzy kolejnym pokoleniom studentów, a także rozwijał dalej teorię. Wspomniani absolwenci wyższych zawodówek idą do pracy, robią co do nich należy i jakiejś szczególnej wagi do dalszego rozwoju nie przykładają.
Wydaje mi się, że przez to robi się okopy w projektach, aby na wszelki wypadek się zabezpieczyć przed niedoświadczonymi świeżakami (lub przeciętniakami), którzy potencjalnie mogą używać powierzonych im narzędzi w niewłaściwy sposób. Moim ulubionym przykładem, jest dopisywanie w Javie, podczas zachowywania modyfikowanego pliku, słowa final, w prawie wszystkich możliwych miejscach (to jest do pól klasy, argumentów metod i zmiennych lokalnych). Kiedyś może to i miało sens, jak chcieliśmy trochę na wydajności zyskać, ale obecnie zaciemnia to kod i słowo final traci przez to swoje znaczenie. Oczywiście jest to sensowne, aby przy deklaracji pól klasy używać final, jeśli tylko raz przypisujemy im wartość, ale w pozostałych przypadkach nie ma to sensu. Po prostu próbujemy się zabezpieczyć przed tego typu kodem:
Czyli ktoś chciał zmienić wartość x, zapomniał jednak jak działa przekazywanie prymitywów do metod.
Innym przykładem który lubię, jest konkatenacja Stringów za pomocą plusa. Kiedyś twierdzono, że to zło, gdyż były tworzone spore ilości chwilowych obiektów, aby zbudować jakiś dłuższy tekst. Zastępowano więc plusa takimi łańcuszkami ze StringBuilder'em. Obecnie kompilator robi to za nas, zamieniając plusa na StringBuilder’a automatycznie, a my zystujemy trochę na czytelności. I nie miał bym nic przeciwko, jeśli po takim uargumentowaniu, reguła ta, została by usunięta z findbugs’a. Jeśli jednak osoba mająca władzę, odnośnie konfiguracji tego typu narzędzi, jest niereformowalna (albo jakaś polityka jej nie pozwala), to trzeba się z tym pogodzić. A to hamuje nasz / projektu rozwój. Sprawia, że nie walczymy o zmiany, tylko z pokorą przyjmujemy na siebie to co kiedyś ktoś wymyślił i wprowadził do projektu.
A gdyby zamiast całych tych śmieszny regół, nauczyć ludzi pisać czysty kod – czy świat nie byłby lepszy? Niestety nie wszystkie firmy / projekty da się do tego przekonać (w myśl zasady nie piszesz to nie wytwarzasz wartości dodanej). Po za tym findbugs i checkstyle to swoiste baty na programistów, za pomocą których można im pokazać, że coś jest z ich kodem nie tak. Czasem pomaga to zmusić kogoś opornego do refaktoringu. Czy nowe języki programowania posiadają tego typu narzędzia? Z pewnością pomogły by im one zaistnieć.
To chyba tyle z mojej strony, jeśli chodzi o zbilżającą się rewolucję w programowaniu. Pewnie jeszcze jakieś interesujące powody by się znalazły, dlaczego ciężko jest się wybić innym językom na tyle, aby aktualny świat programowania obiektowego, wywrócić do góry nogami. Czekam na Wasze komentarze, jakie Wy macie poglądy na ten temat, jak i bacznie wypatruję następcę Javy. Jak będziecie wiedzieć, kto będzie następny, koniecznie dajcie znać!
Ogółem z artykułu wynika, że co 8-10 lat jest jakaś globalna rewolucja w świecie programowania, co sprawia, że wszyscy się masowo przerzucają na dany język (czy tez bardziej ogólniej: na inny paradygmat programowania). Java już swoje przeżyła / dożywa...
Jaki język zastąpi Javę?
Ogółem świat dąży do tego, aby stworzyć taki język, że specyfikacja klienta będzie wykonywalnym programem. Niektórzy twierdzą, że wtedy programiści nie będą już potrzebni, ale pewnie nawet jak jakiś tego typu język powstanie, to i tak trzeba będzie zapisać tą specyfikację w odpowiedni sposób (czyli przez programistę). Przejawy dążenia w tym kierunku widzę w Spring Roo i w coraz popularniejszych DSL’ach (np. w Scali). Jednak raczej się nie zapowiada, aby taki kompletny język specyfikacji w najbliższym czasie powstał. Pewnie tęgie głowy na nie jednej wyższej uczelni próbują coś takiego stworzyć (albo chociaż opracować podstawy teoretyczne), ale chyba póki co chyba bez większych sukcesów – przynajmniej ja nie znam.
Wracając jednak do świata komercyjnego, to Java króluje na scenie już ponad 10 lat. Obecnie do głosu powoli dochodzą (wg. mnie i w/w. wpisu) języki funkcyjne. Wystarczy spojrzeć na to ile się o nich mówi na konferencjach. Wydaje się, że niedługo nastąpi ich czas. A może zaskoczy nas coś całkowicie innego? Może coś z kreowane przez konkurencję JVM’a? Może jakiś inny pragdygmat? Może w końcu powstaną komputery kwantowe?
Chcąc analizować popularność języków programowania warto się przyjrzeć statystykom prezentowanym na portalu tiobe.com. Ranking jest ogółem wyliczany na podstawie statystyk wyszukiwania na popularnych stronach takich jak Google, Blogger, Wikipedia, jak i na YouTube i Amazonie. Ważna jeszcze jest wartość „page hits”.
Źródło: tiobe.com, dostęp: 04.05.2012
Pierwszym zaskoczeniem jest język C, który cały czas się trzyma wysoko, a teraz nawet przegonił Javę. Podobno niektóre uczelnie wyższe powoli przestają go uczyć, ale ranking ten wskazuje, że to chyba błąd.
Kolejną ciekawostką jest bardzo szybka rosnąca popularność Objectiv-C. Jednakże język ten jest skierowany do specyficznej grupy odbiorców i nie zapowiada się, aby wyszedł po za nią.
Ciekawy jest też wykres dla Rubiego. Generalnie Wujek Bob mówił, że jakiś czas temu w Stanach było najłatwiej znaleźć pracę programistom rubina, jednakże teraz ta sytuacja się już zmienia i raczej odchodzi się od tego języka. Potwierdza to wykres jego popularności.
Tak można by było jeszcze analizować i analizować, ale zostawiam to Wam do własnej oceny i interpretacji. Wróćmy do głównego wątku, czyli co z tymi językami funkcyjnymi?
Patrząc na tabelki i wykresy można dostrzec, że jeśli chodzi o programowanie funkcyjne, to najwyżej stoi Python (8. miejsce), Perl (10.) i Lisp (15.). Nie są to języki, które są tylko funkcyjne, ale posiadają również cechy innych paradygmatów programowania. Dalej w zestawieniu jest jeszcze kilka języków z paradygmatem funkcyjnym. Natomiast Scala, która jest mocno promowana na konferencjach javowych, jest dopiero 45, a Clojure znalazł się po za pierwszą 50dziesiątką. Fakt faktem Tiobe może niekoniecznie jest najlepszym wskaźnikiem do porównywania popularności języków, ale nie znam innego podobnego zestawienia, pokazującego zmianę w czasie.
Mnie zastanawia dlaczego jeszcze nie pojawił się / jaki będzie język obecnej dekady, na który by się masowo przesiadało większość firm, tworząc oprogramowanie w tym języku, zamiast w Javie. Przyszło mi do głowy kilka przyczyn.
Według mnie największym mankamentem nowych języków programowania, jest brak narzędzi. Brakuje dobrych, rozwiniętych i stabilnych środowisk IDE. W Javie mamy IntelliJ Idea, gdzie automatyczny refaktoring jest bezbolesny, narzędzie podpowiada składnie zależnie od kontekstu i wie co chcemy napisać. Eclipse jest trochę słabszym narzędziem, ale znam takich co są z niego zadowoleni. Obecne dostępne IDE tak nas rozpieściły swoimi możliwościami, że aż nie chcemy siadać do jakiegoś języka, gdzie nie ma porządnego wsparcia ze strony środowiska programistycznego. Dla tego ja osobiście mocno kibicuję Kotlin’owi, który powstaje od razu ze wspierającym go IDE - aby mu się udało.
Inną bolączką nowych języków, jest brak (lub niewielka wciąż ilość) informacji, o dużych projektach, które się udały w nowopowstałych językach. Dla przykładu Twitter z Ruby’iego przenosi swoje główne elementy na JVM’a (Więcej na ten temat we wpisie: 33 degree 2012 dzień 1). To na pewno nie przystworzyło to Rubiemu popularności, co widać na wykresie.
Innym tematem, który sam doswiadczyłem na przykładzie Scali, jest ewolucja składni w przypadku nowych języków. Niby było zapowiadane, że Scala do kiedyś tam może być niekompatybilna wstecz, ale się odechciewa, gdy uruchamiając przykłady z tutoriala / książki na nowszej wersji, starsza składnia nie jest akceptowana.
Kolejną sprawą jest to, co się obecnie uczy młodych adeptów sztuki programowania na studiach informatycznych i pokrewnych. Cały czas wiodące języki, od których się zaczyna, to C/C++ i Java. Co do języków funkcyjnych, to kojarzę że na jakimś kursie w połowie studiów był Lisp, ale do tego czasu większość już się nauczyła nie chodzić na zajęcia, a i tak mimo tego zaliczać. Zresztą jaką tu mieć motywację do nauki czegoś, gdzie nie bardzo się widzi, aby którykolwiek pracodawca wymagał tego wynalazku przy rekrutacji?
Teraz każda firma / instytucja / przedsiębiorstwo, chce mieć jakieś oprogramowanie. Najlepiej szybko dostarczone, aby móc wyprzedzić konkurencję i aby zastąpić człowieka tam gdzie się da. Powoduje to, że projektów jest coraz więcej, a na to potrzeba więcej ludzi. Kiedyś (podobno – słyszałem z opowieści starszych), na studia informatyczne było o wiele ciężej się dostać, ale przez to trafiali na nie tylko zapaleńcy. Obecnie dalej nie jest łatwo, ale miejsc jest trochę więcej i mamy alternatywę po za uczelniami państwowymi. Potrzbujemy więcej zasobów ludzkich, ale jak fajnie zuaważyl Michał Bartyzel (autor bloga od którego rozpocząłem ten wpis) w poście: Craftsmanship nie dla wszystkich?, nie potrzebujemy w projektach samych wymiataczy. Wystarczy kilku rzemieslników, a reszta to moga być przeciętniaki, którzy robią od 8 do 16 i są niereformowalni.
Tak więc mamy grupę ludzi, która chce podążać za zmianami, być na bieżąco i nie skończyć jako dinozaury. Mamy też przeciętniaków którzy będą niechętni na całkowitą zmianę języka, lub jego wprowadzenie do projektu obok Javy. Musieli by oni wówczas poznać nowa składnię, przez co poczucie ich bezpieczeńswa / pewności zostałoby zaburzone. Niby nauka nowego języka nie powinna być dla nas problemem (w końcu podczas studiow się pisało w różnych dziwnych rzeczach), ale niektórzy mają ku temu spore opory w swojej pracy.
Co do samej ilości programistów, to problem z wyszkoleniem (wyprodukowaniem) odpowiedniej ich liczby, dobrze widać na zachodzie. Przykładowo w Niemczech, powstały już takie Hochfachschule (nazwałbym to wyższą zawodówką), które szkolą osoby pod konkretne technologie. Tzn. trwają one krócej niż normalne studia, a nacisk kładą na praktykę, ograniczając teorię do minimum. Bo i po co to komu? Na studiach to jest potrzebne, bo liczy się na to, że jednak ktoś z grona studentów pójdzie w stronę doktoratu, zostanie na uczelni i będzie przekazywał zdobytej wiedzy kolejnym pokoleniom studentów, a także rozwijał dalej teorię. Wspomniani absolwenci wyższych zawodówek idą do pracy, robią co do nich należy i jakiejś szczególnej wagi do dalszego rozwoju nie przykładają.
Wydaje mi się, że przez to robi się okopy w projektach, aby na wszelki wypadek się zabezpieczyć przed niedoświadczonymi świeżakami (lub przeciętniakami), którzy potencjalnie mogą używać powierzonych im narzędzi w niewłaściwy sposób. Moim ulubionym przykładem, jest dopisywanie w Javie, podczas zachowywania modyfikowanego pliku, słowa final, w prawie wszystkich możliwych miejscach (to jest do pól klasy, argumentów metod i zmiennych lokalnych). Kiedyś może to i miało sens, jak chcieliśmy trochę na wydajności zyskać, ale obecnie zaciemnia to kod i słowo final traci przez to swoje znaczenie. Oczywiście jest to sensowne, aby przy deklaracji pól klasy używać final, jeśli tylko raz przypisujemy im wartość, ale w pozostałych przypadkach nie ma to sensu. Po prostu próbujemy się zabezpieczyć przed tego typu kodem:
public static void main(String[] args) {
int x = 5;
System.out.println(x);
half(x);
System.out.println(x);
}
private static void half(int x) {
x = x / 2;
}
Czyli ktoś chciał zmienić wartość x, zapomniał jednak jak działa przekazywanie prymitywów do metod.
Innym przykładem który lubię, jest konkatenacja Stringów za pomocą plusa. Kiedyś twierdzono, że to zło, gdyż były tworzone spore ilości chwilowych obiektów, aby zbudować jakiś dłuższy tekst. Zastępowano więc plusa takimi łańcuszkami ze StringBuilder'em. Obecnie kompilator robi to za nas, zamieniając plusa na StringBuilder’a automatycznie, a my zystujemy trochę na czytelności. I nie miał bym nic przeciwko, jeśli po takim uargumentowaniu, reguła ta, została by usunięta z findbugs’a. Jeśli jednak osoba mająca władzę, odnośnie konfiguracji tego typu narzędzi, jest niereformowalna (albo jakaś polityka jej nie pozwala), to trzeba się z tym pogodzić. A to hamuje nasz / projektu rozwój. Sprawia, że nie walczymy o zmiany, tylko z pokorą przyjmujemy na siebie to co kiedyś ktoś wymyślił i wprowadził do projektu.
A gdyby zamiast całych tych śmieszny regół, nauczyć ludzi pisać czysty kod – czy świat nie byłby lepszy? Niestety nie wszystkie firmy / projekty da się do tego przekonać (w myśl zasady nie piszesz to nie wytwarzasz wartości dodanej). Po za tym findbugs i checkstyle to swoiste baty na programistów, za pomocą których można im pokazać, że coś jest z ich kodem nie tak. Czasem pomaga to zmusić kogoś opornego do refaktoringu. Czy nowe języki programowania posiadają tego typu narzędzia? Z pewnością pomogły by im one zaistnieć.
To chyba tyle z mojej strony, jeśli chodzi o zbilżającą się rewolucję w programowaniu. Pewnie jeszcze jakieś interesujące powody by się znalazły, dlaczego ciężko jest się wybić innym językom na tyle, aby aktualny świat programowania obiektowego, wywrócić do góry nogami. Czekam na Wasze komentarze, jakie Wy macie poglądy na ten temat, jak i bacznie wypatruję następcę Javy. Jak będziecie wiedzieć, kto będzie następny, koniecznie dajcie znać!
czwartek, 19 kwietnia 2012
Migracja z EasyMock’a na Mockito
Dostałem wczoraj w projekcie zadanie zmigrowania testów korzystających z EasyMock’a na Mockito. Zadanie to przypadło mi, ponieważ jakiś czas temu udało mi się wprowadzić do projektu Mockito, co uważam za duży sukces, gdyż jak wiadomo inicjowanie zmian w projektach nie jest łatwe.
Poniżej przedstawiam jak mi poszło.
9:00 Zbudowałem projekt, odpaliłem testy i zapisałem ile ich jest.
9:02 Sprawdziłem, że mam tylko 3 testy wykorzystujące EasyMock’a. W tym momencie stwierdziłem, że nie ma co szukać w Google jakiegoś migratora, ściągać, instalować i zastanawiać się, jak go uruchomić. Przy tak nie wielkiej liczbie klas do zmiany szkoda zachodu i lepiej zrobić to prymitywną metodą Search & Replace.
9:16 Skończyłem migrować 1wszą klasę.
9:19 Po przyjrzeniu się klasie zrobiłem jeszcze refaktoring, bo jak nie teraz to kiedy? Później nigdy nie nadejdzie.
9:20 Zacząłem modyfikować następną klasę.
9:27 Zakończyłem migrację i refaktoring. Wziąłem się za ostatnią klasę.
9:34 Ukończyłem modyfikacje dla 3ciej klasy.
9:35 Uruchomiłem wszystkie testy – działa.
9:41 Usunąłem wpisy dotyczące EasyMock’a w pom’ach Mavenowych. Tutaj przydała się funkcjonalność „Szukaj w plikach”, jaką daje Notepad++, abym mógł wyszukać wszystkie wpisy.
9:42 Odpaliłem builda i testy w Eclipse - zakończone sukcesem.
9:43 Odpaliłem builda i testy za pomocą konsoli – również zakończone sukcesem.
9:44 Rozpocząłem proces synchronizacji z repozytorium.
9:46 Zmiany zacomitowane.
9:52 Wystartował build na serwerze CI.
10:00 Build zakończył się jednym fail’ujacym testem. Dziwne, bo lokalnie działało. Jako że nie mam dostępu do konfiguracji Jenkinsa to i tak bym nie zidentyfikował problemu. Podszedłem do problemu pragmatycznie: usunąłem nadmiarowe wywołanie verify() i nieużywanego Mocka w jednym teście.
10:08 Rozpocząłem synchronizację z repozytorium.
10:11 Zmiany zacomitowane.
10:12 Wystartował kolejny build.
10:23 Build zakończony sukcesem, banan na ustach, można iść na herbatę.
Na całe szczęście mój obecny projekt jest jeszcze we wczesnej fazie wytwarzania, więc nie było dużo do roboty. Przy czymś większym, gdzie EasyMock jest namiętnie używany, łatwiej było by napisać jakiś skrypcik robiący brudną robotę za nas. Dodatkowo mój zespół ma niewielką wiedzę odnośnie używania mock’ów (i pisania dobrych testów), więc mam kogo ewangelizować :)
Poniżej jeszcze prezentuję przekształcenia z jakich korzystałem. Nie jest to oczywiście pełen zestaw, ale może on stanowić zajawkę Waszych migracji, albo może pomóc zrozumieć różnice między tymi bibliotekami.
Do rozpatrzenia:
Przy wywołaniach verify() trzeba dopisać metodę z argumentami jaka powinna się wywołać. Albo jeszcze lepiej zastanowić się nad sensownością testu, gdyż często verify() jest zbędne. Ponadto anyTimes() zazwyczaj trzeba usunąć.
Na więcej problemów nie natrafiłem, ale zdaję sobie sprawę z tego, że przy większym systemie, gdzie EasyMock jest namiętnie wykorzystywany, może nie być tak łatwo. Przy okazji migracji można od razu wyłapać testy które są niedobrze napisane lub są niepoprawne z punktu widzenia Mockito, np. wywołanie verify() przed testowaną metodą.
Poniżej przedstawiam jak mi poszło.
9:00 Zbudowałem projekt, odpaliłem testy i zapisałem ile ich jest.
9:02 Sprawdziłem, że mam tylko 3 testy wykorzystujące EasyMock’a. W tym momencie stwierdziłem, że nie ma co szukać w Google jakiegoś migratora, ściągać, instalować i zastanawiać się, jak go uruchomić. Przy tak nie wielkiej liczbie klas do zmiany szkoda zachodu i lepiej zrobić to prymitywną metodą Search & Replace.
9:16 Skończyłem migrować 1wszą klasę.
9:19 Po przyjrzeniu się klasie zrobiłem jeszcze refaktoring, bo jak nie teraz to kiedy? Później nigdy nie nadejdzie.
9:20 Zacząłem modyfikować następną klasę.
9:27 Zakończyłem migrację i refaktoring. Wziąłem się za ostatnią klasę.
9:34 Ukończyłem modyfikacje dla 3ciej klasy.
9:35 Uruchomiłem wszystkie testy – działa.
9:41 Usunąłem wpisy dotyczące EasyMock’a w pom’ach Mavenowych. Tutaj przydała się funkcjonalność „Szukaj w plikach”, jaką daje Notepad++, abym mógł wyszukać wszystkie wpisy.
9:42 Odpaliłem builda i testy w Eclipse - zakończone sukcesem.
9:43 Odpaliłem builda i testy za pomocą konsoli – również zakończone sukcesem.
9:44 Rozpocząłem proces synchronizacji z repozytorium.
9:46 Zmiany zacomitowane.
9:52 Wystartował build na serwerze CI.
10:00 Build zakończył się jednym fail’ujacym testem. Dziwne, bo lokalnie działało. Jako że nie mam dostępu do konfiguracji Jenkinsa to i tak bym nie zidentyfikował problemu. Podszedłem do problemu pragmatycznie: usunąłem nadmiarowe wywołanie verify() i nieużywanego Mocka w jednym teście.
10:08 Rozpocząłem synchronizację z repozytorium.
10:11 Zmiany zacomitowane.
10:12 Wystartował kolejny build.
10:23 Build zakończony sukcesem, banan na ustach, można iść na herbatę.
Na całe szczęście mój obecny projekt jest jeszcze we wczesnej fazie wytwarzania, więc nie było dużo do roboty. Przy czymś większym, gdzie EasyMock jest namiętnie używany, łatwiej było by napisać jakiś skrypcik robiący brudną robotę za nas. Dodatkowo mój zespół ma niewielką wiedzę odnośnie używania mock’ów (i pisania dobrych testów), więc mam kogo ewangelizować :)
Poniżej jeszcze prezentuję przekształcenia z jakich korzystałem. Nie jest to oczywiście pełen zestaw, ale może on stanowić zajawkę Waszych migracji, albo może pomóc zrozumieć różnice między tymi bibliotekami.
import
static org.easymock.EasyMock.createMock;
import
static org.mockito.Mockito.mock;
|
createMock
mock
|
import
static org.easymock.EasyMock.expect;
import
static org.mockito.Mockito.when;
|
expect
when
|
andReturn
thenReturn
|
import
static org.easymock.EasyMock.verify;
import
static org.mockito.Mockito.verify;
|
Elementy
do usunięcia:
import
static org.easymock.EasyMock.replay;
replay
|
Do rozpatrzenia:
Przy wywołaniach verify() trzeba dopisać metodę z argumentami jaka powinna się wywołać. Albo jeszcze lepiej zastanowić się nad sensownością testu, gdyż często verify() jest zbędne. Ponadto anyTimes() zazwyczaj trzeba usunąć.
Na więcej problemów nie natrafiłem, ale zdaję sobie sprawę z tego, że przy większym systemie, gdzie EasyMock jest namiętnie wykorzystywany, może nie być tak łatwo. Przy okazji migracji można od razu wyłapać testy które są niedobrze napisane lub są niepoprawne z punktu widzenia Mockito, np. wywołanie verify() przed testowaną metodą.
poniedziałek, 16 kwietnia 2012
DevCrowd 2012
Ledwo 3 tygodnie temu zakończyło się 33 Degree, a tu już kolejna polska konferencja DevCrowd, tym razem w Szczecinie. Konferencja ta jest całkowicie jest przeciwieństwem tej Krakowskiej, jeśli chodzi o wielkość, prelegentów, atmosferę no i cenę. Nie wiedziałem, czy uda mi się wybrać na tą konferencję, ale rzuciłem temat wśród ziomków i z racji dobrego połączenia ze Szczecinem, uczestniczyliśmy w tym wydarzeniu. Przejdźmy od prezentacji.
Na początku udałem się na prezentację Sebastiana Pietrowskiego na temat programowania funkcyjnego w codziennym developmencie. Sebastian opowiadał, czym są języki funkcyjne, po co to i tak dalej. Było trochę przykładów kodu, co jak można w innych językach zrobić, wzmianka o bibliotece Guava, która kilka pomysłów funkcyjnych stara się zaadoptować w Javie.
Później była jeszcze historia na temat tego, co się stało ze słowem kluczowym GOTO i całego sporu na temat stosowalności tego wynalazku. Ciekawa jest ewolucja tej instrukcji, od assemblera, przez programowanie strukturalne (C), obiektowe i w końcu funkcyjne. W Javie słowo goto jest słowem kluczowym (nie możemy nazwać w ten sposób zmiennej), ale nie ma ono implementacji. Mamy za to break i continue, które pozwalają nam wyskoczyć z pętli. Prelegent się mocno zastanawiał, czy w językach funkcyjnych miało by to słowo kluczowe jakieś sensowne zastosowanie i jakie inne ewentualnie konstrukcje językowe mogą podobną funkcjonalność zaoferować.
Generalnie na prezentacji było trochę mało informacji przedstawionych, spodziewałem się trochę więcej. Może coś więcej bym napisał w tym wpisie, ale z racji wszczesnej godziny wyjazdu nie pomyślalem, aby spakować ze sobą notes. Co do samego prelegenta, to jeszcze musi on trochę poćwiczyć wystąpienia publiczne, gdyż było czuć jekkie zdenerwowanie i prezentacja jak dla mnie byla mało ciekawie prowadzona.
Następnie było wystąpienie Jacka Laskowskiego, którego nikomu chyba przedstawiać nie trzeba, na temat Clojure'a, Jest to temat którym Jacek się od dłuższego czasu zajmuje, opisuje na blogu i przedstawia na konferencjach. Wcześniej raczej z daleka omijałem ten wynalazek, chyba ze względu na składnię pełną nawiasów i moje słabe rozeznanie paradygmatu funkcyjnego. Ostatnio jednak się przekonuję, że trzeba się przyjrzeć temu językowi (a na pewno jakiemuś funkcyjnemu).
Co jest w Clojur'ze takiego wspaniałego? Mnie np. zachwyciła obsługa wielowątkowości, którą przedstawił Venkat na 33 degree (więcej we wpisie: 33 degree 2012 dzień 2). Jacek przedstawił jednak temat w inny sposób.
Jako że na sali byli programiści obiektowi, prelegent starał się porównać byty obecne w Javie do tych które występują w Clojure. I tak w Javie mamy klasy, które posiadają metody, a klasy są agregowane w pakiety. Innymi słowy pakiet to zbiór klas, a klasa to zbiór metod. W programowaniu funkcyjnym mamy funkcje (jako byt podstawowy), które są agregowane w pakietach. Nie wiem czy to poprawne określenie w ramach tego języka, ale to co musimy sobie uświadomić, to to, że odpowiednikiem klasy w programowaniu funkcyjnym jest pakiet. W dalszej części prezentacji Jacek udowodnił tą tezę w kodzie.
Aby dalej zrozumieć temat, prelegent kazał się zastanowić, co robimy w programowaniu obiektowym. Mianowicie tworzymy obiekty, przekazujemy je jako argumenty metod i możemy je również otrzymać jako wynik wywołania jakiejś metody. W programowaniu funkcyjnym możemy funkcję (analogicznie jak obiekt) przekazać jako argument funkcji, zwrócić jako wynik i przypisać do zmiennej (a właściwie do stałej). Porównanie to dało mi sporo do myślenia.
Dalej Jacek kodował na żywo. Pokazał, jak można wywoływać rzeczy napisane w Clojure z poziomu Javy. Można skompilować kod pisany w Clojure do bytekodu, w taki sposób, aby było to widoczne przez klasy Javowe. Do tego automatycznie się generował plik JAR, który już w sobie miał wszystkie potrzebne biblioteki wymagane przez Clojure. Dzięki temu wystarczy zaimportować plik do projektu i używać po jawowemu. Jacek przez to zachęcał do pisania po kryjomu w projekcie kodu w tym funkcyjnym języku, bo i tak będzie działało. Na pewno duże zdumienie by było podczas review takiego kodu...
Bardzo mi się jeszcze spodobało spostrzeżenie, że wszystkie języki kompilujące się do bytecodu JVM’a, to tak naprawdę dostarczają nam ten sam produkt (bytecode), ale w trochę inny sposób. Tak więc na poziomie bytekodu języki te są nie rozróżnialne! Czy Java jest w tej sytuacji jakoś uprzywilejowana? NIE! Po prostu była pierwszym językiem do generowania bytecodu.
Co do samego wystąpienia Jacka, to poziom jak zwykle wysoki, potrafił zaciekawić słuchaczy, nawiązać dialog z publiką i zmusić ją do myślenia. W tytule prezentacji było o zastosowaniach serwerowych i spodziewałem się prezentacji jakiegoś framework’a Webowego do Clojura, a był pokazany prosty serwerek, który odbierał żądania http. Więcej, co pokazał Jacek, możecie przeczytać na jego angielskojęzycznym blogu.
Następnie udałem się na warsztaty ze Scali z Łukaszem Kuczerą (@lkuczera). Były one zaplanowane na 3 godziny plus przerwa obiadowa. Początkowo Łukasz wprowadzał nas do języka, dużo o nim opowiadając. Ja kilka dni przed konferencja poczytałem trochę i coś tam napisałem sobie w Scali, aby nie być całkiem zielonym. Dzięki temu na części wprowadzającej w język wiedziałem już co nieco, przez co tematy które nie do końca rozumiałem stawały się jaśniejsze. Do tego dostałem w piątek licencję na IntelliJ IDEA, w zamian za opisanie wrażeń z 33 degree. Mogłem więc od razu zobaczyć jak nowa wersja IDEI radzi sobie ze Scalą.
Później był obiad (zapewniony przez organizatorów). Do wyboru były pierogi, lub kurczak, a całość była dostarczona w styropianach pewnie przez jakąś lokalną firmę cateringową. Dzięki temu można było z obiadem iść gdziekolwiek i wraz z Marcinem Saneckim poszliśmy na zewnątrz na słoneczko. Tam już siedział Jacek Laskowski z Sebastianem Pietrowskim na krawężniku (w pobliżu nie było ławek) i zaprosili nas do wspólnego jedzenia.
Jacek bardzo pochwalił moje wpisy na blogu i nakręcił mnie do dalszej aktywności w tym kierunku. Jeszcze inne bardzo ciekawe tematy się wywiązały, ale lepiej o nich tutaj nie wspominać ;)
Po smacznym obiadku wróciliśmy dalej poznawać zakamarki Scali. Nie będę tutaj opisywał cech języka, ani tego o czym Łukasz opowiadał, bo było tego sporo, a jako świeżak w temacie nie chciałbym nikogo wprowadzać w błąd.
Następnie uczestnicy podzielili się na 2 części i zaczęliśmy w końcu kodować. Generalnie był trochę problem z tym co chcemy napisać, ale w końcu postanowiliśmy napisać parsera wpisow na bash.org, który będzie je zapisywał w bazie danych. Tak więc jeden zespół pisał bazę, a drugi (w którym uczestniczyłem) pisał parsera dla podanej strony. Nie poszlo nam zbytnio, polegliśmy na wyrażeniach regularnych i parsowaniu html’a.
Podczas tego szkolenia zdałem sobie sprawę, jak trudno jest poprowadzić warsztat dla nowicjuszy z nowego języka programowania. Jak dobrze przygotować zadania, aby uczestnicy w ciągu kilku godzin mogli coś napisać i wyjść z warsztatów z przeświadczeniem, że się czegoś nauczyli? Odpowiedź na pytanie z pewnością nie jest łatwa. To, że się nie pamięta podstawowych konstrukcji języka i nie zna jego API, sprawia, że jednak każdy musi w domu sam usiąść z książką / tutorialem i poprostu zacząć pisać. Czy da się zrobić to jakoś podzczas kilkugodzinnego warsztatu? Nie wiem.
Na zakończenie konferencji było jeszcze rozstrzygnięcie konkursów. Firma SoftwareMill zaproponowała konkurs w którym można było wygrać SonyPlayStation3 Vita. Należało podesłać kawałek kodu, który będzie grał w papier, kamień, nożyce. Bardzo fajna akcja, jednak odpadłem w pierwszej rozgrywce. Było jeszcze losowanie 3ch licencji IntelliJ IDEA, ale już mam, wiec nie brałem nawet udziału :P
Wieczorem była jeszcze impreza pokonferencyjna. Dzięki uprzejmości Andrzeja (który prowadził i zgodził się wracać później) uczestniczyliśmy w after party. I tu było mega pozytywne zaskoczenie, gdyż po wejściu do restauracji zobaczyliśmy białe nakrycia stołów i jedzenie. Przez chwile myśleliśmy, że to jakaś inna impreza, ale zobaczyliśmy innych uczestników konferencji (koszulki konferencyjne przydają się do czegoś), a pani kelnerka jeszcze nas w tym utwierdziła. Nie mogłem się nadziwić, gdyż konferencja była w pełni darmowa, a do tego obiad w trakcie i po (można było spokojnie biegac po dokładkę) i dodatkowo sponsorowane napoje (wiadomo jakie). Wielki szacun dla organizatorów, za taką wspaniałą organizację!
Na wspomnianej afterparty było już mniej osób niż na samej konferencji, przez co atmosfera zrobiła się bardziej kameralno - społecznosciowa. Podpowiedź na przyszły rok: trzeba od razu od samego początku złączyć stoły, aby szybciej zacząć integrację z innymi. Może jeszcze warto zastosowac jakieś techniki sprzyjajace integracji? Myślę, że jest to warte rozważenia.
Z udziału w konferencji jestem bardzo zadowolony, zwłaszcza z możliwosci dowiedzenia się jak IT funkcjonuje w innych miastach (Szczecin), podzielenia sie z innymi swoimi uwagami, jaki i z ogólnego uspołecznienia, oraz możliwości spotkania innych branżowych zapaleńców. Podziękowania dla organizatorów, bo jak na darmowy event, to całość stała bardzo wysoko. Do zobaczenia (mam nadzieję) za rok.
Na początku udałem się na prezentację Sebastiana Pietrowskiego na temat programowania funkcyjnego w codziennym developmencie. Sebastian opowiadał, czym są języki funkcyjne, po co to i tak dalej. Było trochę przykładów kodu, co jak można w innych językach zrobić, wzmianka o bibliotece Guava, która kilka pomysłów funkcyjnych stara się zaadoptować w Javie.
Później była jeszcze historia na temat tego, co się stało ze słowem kluczowym GOTO i całego sporu na temat stosowalności tego wynalazku. Ciekawa jest ewolucja tej instrukcji, od assemblera, przez programowanie strukturalne (C), obiektowe i w końcu funkcyjne. W Javie słowo goto jest słowem kluczowym (nie możemy nazwać w ten sposób zmiennej), ale nie ma ono implementacji. Mamy za to break i continue, które pozwalają nam wyskoczyć z pętli. Prelegent się mocno zastanawiał, czy w językach funkcyjnych miało by to słowo kluczowe jakieś sensowne zastosowanie i jakie inne ewentualnie konstrukcje językowe mogą podobną funkcjonalność zaoferować.
Generalnie na prezentacji było trochę mało informacji przedstawionych, spodziewałem się trochę więcej. Może coś więcej bym napisał w tym wpisie, ale z racji wszczesnej godziny wyjazdu nie pomyślalem, aby spakować ze sobą notes. Co do samego prelegenta, to jeszcze musi on trochę poćwiczyć wystąpienia publiczne, gdyż było czuć jekkie zdenerwowanie i prezentacja jak dla mnie byla mało ciekawie prowadzona.
Następnie było wystąpienie Jacka Laskowskiego, którego nikomu chyba przedstawiać nie trzeba, na temat Clojure'a, Jest to temat którym Jacek się od dłuższego czasu zajmuje, opisuje na blogu i przedstawia na konferencjach. Wcześniej raczej z daleka omijałem ten wynalazek, chyba ze względu na składnię pełną nawiasów i moje słabe rozeznanie paradygmatu funkcyjnego. Ostatnio jednak się przekonuję, że trzeba się przyjrzeć temu językowi (a na pewno jakiemuś funkcyjnemu).
Co jest w Clojur'ze takiego wspaniałego? Mnie np. zachwyciła obsługa wielowątkowości, którą przedstawił Venkat na 33 degree (więcej we wpisie: 33 degree 2012 dzień 2). Jacek przedstawił jednak temat w inny sposób.
Jako że na sali byli programiści obiektowi, prelegent starał się porównać byty obecne w Javie do tych które występują w Clojure. I tak w Javie mamy klasy, które posiadają metody, a klasy są agregowane w pakiety. Innymi słowy pakiet to zbiór klas, a klasa to zbiór metod. W programowaniu funkcyjnym mamy funkcje (jako byt podstawowy), które są agregowane w pakietach. Nie wiem czy to poprawne określenie w ramach tego języka, ale to co musimy sobie uświadomić, to to, że odpowiednikiem klasy w programowaniu funkcyjnym jest pakiet. W dalszej części prezentacji Jacek udowodnił tą tezę w kodzie.
Aby dalej zrozumieć temat, prelegent kazał się zastanowić, co robimy w programowaniu obiektowym. Mianowicie tworzymy obiekty, przekazujemy je jako argumenty metod i możemy je również otrzymać jako wynik wywołania jakiejś metody. W programowaniu funkcyjnym możemy funkcję (analogicznie jak obiekt) przekazać jako argument funkcji, zwrócić jako wynik i przypisać do zmiennej (a właściwie do stałej). Porównanie to dało mi sporo do myślenia.
Dalej Jacek kodował na żywo. Pokazał, jak można wywoływać rzeczy napisane w Clojure z poziomu Javy. Można skompilować kod pisany w Clojure do bytekodu, w taki sposób, aby było to widoczne przez klasy Javowe. Do tego automatycznie się generował plik JAR, który już w sobie miał wszystkie potrzebne biblioteki wymagane przez Clojure. Dzięki temu wystarczy zaimportować plik do projektu i używać po jawowemu. Jacek przez to zachęcał do pisania po kryjomu w projekcie kodu w tym funkcyjnym języku, bo i tak będzie działało. Na pewno duże zdumienie by było podczas review takiego kodu...
Bardzo mi się jeszcze spodobało spostrzeżenie, że wszystkie języki kompilujące się do bytecodu JVM’a, to tak naprawdę dostarczają nam ten sam produkt (bytecode), ale w trochę inny sposób. Tak więc na poziomie bytekodu języki te są nie rozróżnialne! Czy Java jest w tej sytuacji jakoś uprzywilejowana? NIE! Po prostu była pierwszym językiem do generowania bytecodu.
Co do samego wystąpienia Jacka, to poziom jak zwykle wysoki, potrafił zaciekawić słuchaczy, nawiązać dialog z publiką i zmusić ją do myślenia. W tytule prezentacji było o zastosowaniach serwerowych i spodziewałem się prezentacji jakiegoś framework’a Webowego do Clojura, a był pokazany prosty serwerek, który odbierał żądania http. Więcej, co pokazał Jacek, możecie przeczytać na jego angielskojęzycznym blogu.
Następnie udałem się na warsztaty ze Scali z Łukaszem Kuczerą (@lkuczera). Były one zaplanowane na 3 godziny plus przerwa obiadowa. Początkowo Łukasz wprowadzał nas do języka, dużo o nim opowiadając. Ja kilka dni przed konferencja poczytałem trochę i coś tam napisałem sobie w Scali, aby nie być całkiem zielonym. Dzięki temu na części wprowadzającej w język wiedziałem już co nieco, przez co tematy które nie do końca rozumiałem stawały się jaśniejsze. Do tego dostałem w piątek licencję na IntelliJ IDEA, w zamian za opisanie wrażeń z 33 degree. Mogłem więc od razu zobaczyć jak nowa wersja IDEI radzi sobie ze Scalą.
Później był obiad (zapewniony przez organizatorów). Do wyboru były pierogi, lub kurczak, a całość była dostarczona w styropianach pewnie przez jakąś lokalną firmę cateringową. Dzięki temu można było z obiadem iść gdziekolwiek i wraz z Marcinem Saneckim poszliśmy na zewnątrz na słoneczko. Tam już siedział Jacek Laskowski z Sebastianem Pietrowskim na krawężniku (w pobliżu nie było ławek) i zaprosili nas do wspólnego jedzenia.
Jacek bardzo pochwalił moje wpisy na blogu i nakręcił mnie do dalszej aktywności w tym kierunku. Jeszcze inne bardzo ciekawe tematy się wywiązały, ale lepiej o nich tutaj nie wspominać ;)
Po smacznym obiadku wróciliśmy dalej poznawać zakamarki Scali. Nie będę tutaj opisywał cech języka, ani tego o czym Łukasz opowiadał, bo było tego sporo, a jako świeżak w temacie nie chciałbym nikogo wprowadzać w błąd.
Następnie uczestnicy podzielili się na 2 części i zaczęliśmy w końcu kodować. Generalnie był trochę problem z tym co chcemy napisać, ale w końcu postanowiliśmy napisać parsera wpisow na bash.org, który będzie je zapisywał w bazie danych. Tak więc jeden zespół pisał bazę, a drugi (w którym uczestniczyłem) pisał parsera dla podanej strony. Nie poszlo nam zbytnio, polegliśmy na wyrażeniach regularnych i parsowaniu html’a.
Podczas tego szkolenia zdałem sobie sprawę, jak trudno jest poprowadzić warsztat dla nowicjuszy z nowego języka programowania. Jak dobrze przygotować zadania, aby uczestnicy w ciągu kilku godzin mogli coś napisać i wyjść z warsztatów z przeświadczeniem, że się czegoś nauczyli? Odpowiedź na pytanie z pewnością nie jest łatwa. To, że się nie pamięta podstawowych konstrukcji języka i nie zna jego API, sprawia, że jednak każdy musi w domu sam usiąść z książką / tutorialem i poprostu zacząć pisać. Czy da się zrobić to jakoś podzczas kilkugodzinnego warsztatu? Nie wiem.
Na zakończenie konferencji było jeszcze rozstrzygnięcie konkursów. Firma SoftwareMill zaproponowała konkurs w którym można było wygrać SonyPlayStation3 Vita. Należało podesłać kawałek kodu, który będzie grał w papier, kamień, nożyce. Bardzo fajna akcja, jednak odpadłem w pierwszej rozgrywce. Było jeszcze losowanie 3ch licencji IntelliJ IDEA, ale już mam, wiec nie brałem nawet udziału :P
Wieczorem była jeszcze impreza pokonferencyjna. Dzięki uprzejmości Andrzeja (który prowadził i zgodził się wracać później) uczestniczyliśmy w after party. I tu było mega pozytywne zaskoczenie, gdyż po wejściu do restauracji zobaczyliśmy białe nakrycia stołów i jedzenie. Przez chwile myśleliśmy, że to jakaś inna impreza, ale zobaczyliśmy innych uczestników konferencji (koszulki konferencyjne przydają się do czegoś), a pani kelnerka jeszcze nas w tym utwierdziła. Nie mogłem się nadziwić, gdyż konferencja była w pełni darmowa, a do tego obiad w trakcie i po (można było spokojnie biegac po dokładkę) i dodatkowo sponsorowane napoje (wiadomo jakie). Wielki szacun dla organizatorów, za taką wspaniałą organizację!
Na wspomnianej afterparty było już mniej osób niż na samej konferencji, przez co atmosfera zrobiła się bardziej kameralno - społecznosciowa. Podpowiedź na przyszły rok: trzeba od razu od samego początku złączyć stoły, aby szybciej zacząć integrację z innymi. Może jeszcze warto zastosowac jakieś techniki sprzyjajace integracji? Myślę, że jest to warte rozważenia.
Z udziału w konferencji jestem bardzo zadowolony, zwłaszcza z możliwosci dowiedzenia się jak IT funkcjonuje w innych miastach (Szczecin), podzielenia sie z innymi swoimi uwagami, jaki i z ogólnego uspołecznienia, oraz możliwości spotkania innych branżowych zapaleńców. Podziękowania dla organizatorów, bo jak na darmowy event, to całość stała bardzo wysoko. Do zobaczenia (mam nadzieję) za rok.
czwartek, 5 kwietnia 2012
33 degree 2012 warsztat z Wujkiem Bobem
W ramach konferencji 33 Degree 2012, po za główną częścią konferencji (opisanej w 3 częsciach: cześć 1, część 2, część 3) wybrałem się jeszcze na warsztat Clean Code z Wujkiem Bobem. Było jakieś 27 osób na tym szkoleniu, stoły poukładane jak w szkole, czułem się jak na lekcjach. Ale przynajmniej lekcja była z nie byle kim. Szkolenie miało formę otwartego, tzn. sami mogliśmy zadawać pytania i proponować tematy, o których będziemy mówić. Niestety jakoś nikt się do tego specjalnie nie kwapił.
Na początku każdy miał się przedstawić i powiedzieć cos o sobie. Wujek Bob notował, kto ile czasu już programuje. Wynik poniżej:
Na początku była znana historyjka na temat symbolu \r\n. Jak wiadomo, w naszej dziedzinie ważne są detale. Następnie Wujek polecał książkę Kent’a Beck’a Implementation Pattern, a następnie znów mówił znaną historyjkę o odwróceniu jednego bitu w swojej głowie.
Następnie było o tym, ze minimalizacja połączeń pomiędzy modułami, ułatwia zrozumienie otoczenia klasy, którą musimy zmodyfikować. I to kod uczy nowych pracowników w projekcie, jak należy pisać. Jeżeli kod jest brzydko utrzymany, to nie ma się co spodziewać, że nowi to poprawią. Dalej będą pisać brzydko.
Później znów było o tym jak w jednej firmie robili redesign całego systemu przez 10 lat. Ledwo wczoraj to słyszałem.
Po przerwie Wujek zaczął w swoim stylu, czyli od wykładu nie na temat. Tym razem było o tym, w jaki sposób policzono odległość Ziemi do Słońca. Dalej było na temat używania słowa spróbuję (ang. try). Nie powinniśmy z niego korzystać, ponieważ dla nas oznacza ono nie, a dla naszego managera znaczy tak. Później była kolejna znana już „przypowieść” o lekarzach, którzy nie myją rąk.
W końcu pojawił się jakiś kod na ekranie. Był to kod klasy org.free.date.SerialDate. Dokładnie ten sam, który był opisywany w książce Czysty Kod. Bob bardzo dogłębnie analizował komentarz do tej klasy i sukcesywnie wywalał z niego elementy, które był tam zbędne. Prelegent używa w swoim IDE czerwonego koloru do wyświetlania komentarzy. Dzięki temu wie, gdzie ktoś miał problem z napisaniem czytelnego kodu i musiał się wspomóc komentarzem.
Później uczestnicy kursu mieli podopisywać trochę testów do tej klasy na swoich komputerach. W tym czasie prelegent chyba nagrywał fragmenty do swoich nowych filmików.
Po kolejnej przerwie Bob opowiadał kolejną znaną swoją historyjkę o artykule z gazety, że powinien on mieć nagłówek (który przekazuje główną informację), a potem są detale dla zainteresowanych. W przypadku Javy jest całkiem podobnie, jedynie zmienne definiujemy na górze klasy. Dla prelegenta jest to głupa konwencja, ale wszyscy się jej trzymają, więc trzeba programować w taki sposób.
Następnie było o długaśnej metodzie z FitNesse’a, która operowała na kilku poziomach abstrakcji i była stworzona przez kopiuj – wklej. Dalej była kolejna opowiastka, tym razem o mamie, która kazała mu sprzątać w pokoju. Analogia dla nas jest taka, że póki jesteśmy w jednoosobowym pokoju, to możemy mieć dowolnie wielkie bagno, byle byśmy się w nim odnajdowali. W przypadku gdy pracujemy zespołowo, to niestety musimy zadbać o porządek. Jeśli nie możesz wyekstrahować metody, to powinieneś ją wyekstrahować (prawdopodobniej jest nieczytelna i robi więcej niż jedną rzecz).
Dalej była wzmianka o programowaniu funkcyjnym, które jest pozbawione efektów ubocznych. Następnie było o rozróżnieniu programowania obiektowego i strukturalnego. Programowanie obiektowe ułatwia dodawanie nowych typów, ale utrudnia dodawanie nowych funkcji. Programowaniu strukturalnym jest odwrotnie. Nie oznacza to jednak, że nie da się tego łączyć. Da się, ale może to być ciężkie w utrzymaniu. Ciekawe dla mnie było jeszcze stwierdzenie, że w C można programować w sposób obiektowy, poprzez przekazywanie funkcjom innych wskaźników na funkcje.
Dalej było o metodach wieloargumentowych. Tak naprawdę problemem z metodami wieloargumentowymi jest pozycja tych argumentów. Ciężko spamiętać co na której pozycji jest, gdy metoda ma więcej argumentów. Przez to możemy zatracić swój flow w czytaniu kodu, gdyż będziemy musieli wejść na niższy poziom abstrakcji (czyli do wnętrza metody), aby sprawdzić który argument jest czym.
Dalej było o złych zależnościach czasowych w naszych aplikacjach. Przykładowo najpierw musimy wywołać metodę open(), a dopiero później możemy wywołać close(). Jedynym rozwiązaniem jakie widzi object mentor jest przekazywanie do metody otwierającej procedury, która ma się wykonać pomiędzy rzeczywistym open() a close(). Trochę gorzej jest, gdy musimy np. pracować na 2ch plikach równocześnie, bo to powoduje brzydotę kodu.
To tyle jeśli chodzi o pierwszy dzień. Wieczorem miałem to szczęście, że mogłem zjeść razem kolację (i wypić piwko) z Sebastianem i Wujkiem Bobem. Pomęczyłem go jeszcze trochę trudnymi pytaniami i oglądaliśmy razem Kraków nocą. Było to wyjątkowe przeżycie dla mnie. Dzięki Sebastian za organizację tego spotkania!
Dowiedziałem się między innymi, po co Wujek Bob na początku swoich wystąpień robi takie wstępniaki z innych dziedzin. Mianowicie chodzi o poprawę pracy umysłu ludzkiego, poprawę koncentracji i wyostrzenie abstrakcyjnego myślenia. Bob stosuje tą technikę od kilkunastu już lat.
Drugi dzień „treningu” zaczął się od różnych definicji czystego kodu. Były przedstawione te same osoby, które są opisane w książce Wujka Bob’a i ich odpowiedzi na pytanie, czym jest dla nich czysty kod.
Po pierwszej przerwie były zabawy Boba niebieskim laserem. Bardzo ciężko go otrzymać. Istnieje jednak tańsza wersja z domieszką fioletowego, ale nie jest ona taka fajna jak czysty niebieski laser. A ten zostawia ślady na tabliczkach fluorescencyjnych, a świecąc na zwykłe okulary, można zrobić sobie na chwilę okulary przeciwsłoneczne ;)
Dalej było o funkcjach. Te które często wywołujemy, powinny mieć krótkie nazwy i zazwyczaj dużo robią. Później nawiązała się dyskusja na temat używania różnych języków w kodzie, przykładowo polskiego i angielskiego. Czasem jest to wymuszone pewnymi typami projektów, gdzie jest narzucone, że kod musi być pisany po polsku. Niestety Wujek Bob nie miał zbytnio zdania na ten temat, gdyż jego ten problem nie dotyczy.
Później były jeszcze opowieści o wynalazcy notacji węgierskiej (że zarobił fortunę) i o ludzkim kodzie genetycznym.
Następnie Wujek Bob pokazywał przykład refaktoryzacji. Niestety przykład był z książki Martin’a Fowler’a Refaktoryzacja.... Prelegent refaktorował na żywo kod wypożyczalni filmowej. Prelegent zaszedł troszkę dalej niż zrobił to Fowler. To co mnie zaskoczyło, to fakt, ze na samym końcu, klasa która początkowo nazywała się Customer tak de facto powinna się nazywać Statement. Refaktoryzacja pokazała nam prawdziwe przeznaczenie klasy. Był to dla mnie jedyny szok jaki przeżyłem podczas tej prezentacji. Filmik który pokazuje to przekształcenie kodu (ale troszkę inne), został później udostępniony uczestnikom warsztatu. Morał z tego taki, że mając testy można łatwo zmienić design kodu.
Co do zasad Wujka Boba, które stosuje w swoich testach, to czasem rezygnuje on z zasady step down (aby czytać kod od góry do dołu, jak artykuł w gazecie). W testach jest dobrze umieszczać na początku własne assercje. Dzieki temu będzie wiadome, co tak naprawdę testujemy w danej klasie.
Następnie Wujek Bob opowiadał o Katach, a następnie zaprezentował Prime Factors Katę. Można sobie poszukać filmik na necie i samemu obejrzeć.
Później jeszcze robiliśmy „na sucho” problem, jak byśmy napisali algorytm sortowania? Za pomocą małych kroczków i TDD doszlibyśmy do najprostszego algorytmu bąbelkowego. Następnie Bob pokazał ze swojej strony artykuł: The Transformation Priority Premise gdzie przedstawił różne przekształcenia kodu. Twierdził on, że za pomocą tych przekształceń, można dojść z algorytmu bąbelkowego do quicksorta. Trzeba to kiedyś sprawdzić w praktyce.
Na sam koniec szkolenia był jeszcze czas na pytania publiki. Bob mówił o architekturze. Dla niego architektura to nie Tomcat, Spring, JSF i baza danych. Architektura to rozdzielenie tego co system robi (wymagania użytkownika) od technicznych „plug-in’ów” (jak Spring, UI, baza danych). I de facto to co powinniśmy testować, to architektura systemu, czyli wymagania użytkownika, a nie GUI i baza danych.
Było jeszcze pytanie co do programowania defensywnego (zabezpieczanie się w każdej metodzie na błędne parametry)? Według Wujka Boba, należy mieć zaufanie wewnątrz teamu i nie powinno się za każdym razem sprawdzać, czy jakaś wartość nie jest null’em. Natomiast pisząc zewnętrzną bibliotekę, którą będzie używał ktoś inny, należy się już oto zatroszczyć. Mówiąc kolokwialnie, musi ona być idiotoodporna.
Podsumowując dwudniowy warsztat z Robertem C. Martinem jestem trochę zawiedziony. Spodziewałem się usłyszeć więcej, niż jest napisane w książkach Clean Code i The Clean Coder. Żeby chociaż przykłady były z poza tych książek, aby były nowe opowiastki, a nie te już znane przez kogoś, kto przeczytał choć jedną ze wspomnianych książek. No i brakowało mi więcej praktyki na tym szkoleniu. Dla kogoś kto był świeży w temacie przedstawianym przez prelegenta, warsztat na pewno wydal się ciekawy i pouczający. Ja jednak spodziewałem się czegoś więcej.
Jedynie wielki autorytet, szacunek, wspólna kolacja, zdjęcie, autograf na książce i możliwość zadania wielu pytań, ratuje obraz całej sytuacji. Gdyby nie to, byłbym mocno rozgoryczony, a tak jestem nie do końca usatysfakcjonowany. Mimo wszystko cieszę się że wziąłem udział w tym szkoleniu, będę je miło wspominał. Zdjęcie z Wujkiem Bobem trzeba teraz wywołać, w ramkę i na biurku w pracy postawić, aby już nigdy nie pisać brzydkiego kodu ;)
środa, 4 kwietnia 2012
33 degree 2012 dzień 3
Dzień 1
Dzień 2
Warsztat z Wujkiem Bobem
Na początku 3ciego dnia konferencji miałem wielki dylemat na co pójść. Stwierdziłem, że z kolejnej prezentacji Venkat’a dużo nie wyniosę, a Jacka Laskowskiego pewnie jeszcze uda mi się zobaczyć w tym roku podczas innej konferencji. Ostatecznie poszedłem więc na prezentację Andreas'a Krogh'a pod tytułem: Lift from a JEE perspective. O tym framework’u słyszałem wiele dobrego (jest odporny na większość popularnych ataków) i spodziewałem się usłyszeć jak to widzi ktoś, kto go używał a siedział wcześniej w JEE (po prostu tytuł na to wskazywał).
Niestety była to moja najbardziej stracona godzina podczas całej konferencji. Prezentacja była kiepsko przygotowana (dużo tekstu, slajdy które były pomijane, XML’e z konkretną konfiguracją większości bibliotek użytych w projekcie prezentera), ale jeszcze gorzej było z samym prowadzącym, który mówił cicho monotonnie i chciało się tylko spać.
Co do treści prezentacji, to prelegent wymieniał początkowo co mu się w Javie nie podobało. Było o problemach w refaktoryzają (nie pamiętam w którym miejscu), z niedziałającymi testami GUI (przy zmianach w GUI wszystko im się sypało), z internacjonalizacją (m.in. chciano mieć w rzucanych wyjątkach komunikaty w języku natywnym prelegenta). Andreas narzekał, że nie ma w JPA standardu obsługi dla Lazy associations i że trzeba dużo kodu wygenerować na potrzeby DAO. Ponadto JSF jest pewnym standardem, ale mało kto go do końca rozumie, a alternatywne rozwiązania też mają sporo wad.
Później były przedstawiane już wcześniej wspomniane konfiguracje XMLowe i masa dziwnych rozwiązań (np. klasa JpaTextField która z JPA nie miała nic wspólnego). Generalnie prelegent brał udział w projekcie gdzie było jedno wielkie wymieszanie Javy i Scali z dodatkiem dziwnych pomysłów. Na koniec było krótkie demo i można było jedyne tam zobaczyć działanie push’a / pull'a oferowanego przez Comet. Dziękujemy temu panu, więcej nie zamierzam iść na jego prezentację.
Następnie byłem na wystapieniu Ken'a Sipe'a o MongoDB, czyli na temat bazy dokumentowej. Baza ta zawiera, dokładniej rzecz ujmując, kolekcje, które zawierają dokumenty. Prelegent pokazywał tworzenie nowej bazy i póki coś w niej nie wyląduje, to nie jest ona zapisywana na dysku.
Z MongoDB mamy możliwość zobaczenia planu wykonania zapytania. Możemy zakładać indeksy na właściwościach rozróżniających typy składowanych dokumentów i przez to poprawić wydajność. Ogółem chcąc coś wydajnie przechowywać w tej bazie, należy najpierw zrobić denormalizację.
Baza ta nie ma transakcji, przez co można bardzo łatwo ją skalować na wiele maszyn. Czyli zgodnie z CAP Theorem, tracimy na jednym, za zyskujemy na innym miejscu.
Następnie było wystąpienie Roberta C. Martina znanego bardziej jako Wujek Bob. Prezentacja była na temat 3 praw TDD. Początkowo wykład zaczął się od omówienia zasady działania lasera. Później było już powtórzenie tego co wujek pisze w swoich książkach. Było o zielonej opasce - symbolu, którego nie może zdjąć gdyż ma obsesję na temat testów i uważa siebie za profesjonalistę. Profesjonalista to ktoś taki, kto bierze na siebie odpowiedzialność za wykonywaną pracę, a managerowie potrzebują profesjonalistów w swoich zespołach.
Później było o krzywej Produktywności vs. Czas, o bagnie (w kodzie) i historia o redesign’ie systemu, czyli rozpoczęciu projektu od nowa, aby uzyskać lepszy design. Jednak zazwyczaj w takim przypadku stary zespól dalej rozwija poprzedni projekt, a ten nowy nigdy nie może dogonić starego. Sytuacja taka może trwać nawet 10 lat. Rozwiązaniem na to jest zasada skałtów, czyli poprzez niewielkie zmiany w kodzie, możemy pozbyć się tego całego bagna.
Dalej było o tym, że TDD zmusza nas do decoupling'u. Powinniśmy ufać swoim testom, analogicznie jak przy skokach spadochronowych, gdzie samemu musimy sobie odpowiednio spakować spadochron. TDD to gra z samym sobą – piszemy niedziałający test, który po chwili działa – i tak w kółko.
Co do tytułowych 3 praw TDD to nie było to: Red, Green, Refactor, a cos takiego:
- Write no production code unless you have a failing unit test.
- Do not write more of a unit test than is sufficient to fail. (And not compiling is failing.)
- Do not write more production code than is sufficient to pass.
Później było trochę pytań od publiczności, m.in. jak wprowadzać zmiany w projekcie. Bob mówił, aby zacząć od siebie i wtedy inni zobaczą, że jest to fajne i również będą tak postępować. A jak nie to iść za radą Martina Fowlera: "Change your organization or change your organization".
Co do testów akceptacyjnych to należy zrobić wszystko, aby były one szybkie. Przede wszystkim jak jeden test sprawdza logowanie, a drugi składanie zamówienia, to ten drugi powinien się obejść bez logowania. Oznacza to, że trzeba czasem podmienić pewne zachowanie system i przez to testy powinny śmigać szybciej.
Następnie była prezentacja Code Craft prowadzona w przedziwnym stylu. Mianowicie Nathaniel Schutta miał 267 slajdów na godzinne wystąpienie, co daje ponad 4 slajdy na minutę. Fakt faktem, na slajdach były pojedyncze hasła, ale były one bardzo zgrane z prelegentem.
Prelegent wymienił kilka ciekawych narzędzi, których nie znałem, jak crap4j, Crucible (do robienia review kodu), Clover (do prezentowania statystyk buildów – wykresów, pokrycia, można dużo konfigurować), Jester (do testów mutacyjnych, ciekawe jak on ma się do PIT’a) i Simian (detektor kodu pisanego metodą Copiego-Pastea).
Co do prowadzania zmian w projekcie (np. wprowadzenie FindBug’a), to prelegent przedstawił ciekawe podejście jak to robić. Nie można włączyć od razu wszystkich możliwych dobrych reguł jakie są, bo to spowoduje wyświetlanie brzydkich wykresów jakości kodu i nikt z tym nic nie będzie robił, a kod będzie dalej gnił. Trzeba na początek włączyć tylko kilka reguł, poprawić kod i sukcesywnie dołączać dalsze reguły.
Inną ciekawą rzeczą jest aktualizowane przez świeżaków Developrs handbooks, czyli dokumentów tłumaczących jak skonfigurować środowisko, jakie są standardy w projekcie itd.
Kolejnym ciekawym pomysłem, jest nagrywanie filmików, ze spotkań na których są podejmowane ważne decyzje projektowe. Jak się po jakimś czasie okazuje, że została podjęta jakaś zła decyzja w projekcie, to można zawsze wrócić do nagrania i przypomnieć sobie dlaczego tak to się stało a nie inaczej.
Następnie był wykład Jurgen Appelo pt. How to Change the World. Prelegent jest autorem książki Management 3.0 i podczas prezentacji opowiadał, jak można przekonywać innych ludzi do czegoś. Bazował na kilku książkach m.in. Influencer, Leading Changes, Fearless Change. Jedna z ciekawych metod wpływania na innych współpracowników, jest przedstawianie nowych pomyslów, podczas wspólnego jedzenia. Pewnie to wynika z tego, że rozmówca może na wtedy poświęcić więcej uwagi, niż gdy siedzi przy biurku i właśnie go wyrwaliśmy z flow.
Był jeszcze przedstawiony wykres innowacyjności, The Feedback Door (czyli karteczki przylepiane na drzwiach, aby dawać feedback) i jeszcze parę abstrakcyjnych przykładów, jak wprowadzać zmiany. Generalnie książkę autora można ściągnąć z ze strony management30.com.
Na koniec 3ciego dnia został wykład Wujka Boba. Standardowo na początku było trochę o fizyce/biologii, że ludzie mają 3 receptory koloru, a składowe RGB również są trzy.
Tym razem wykład był prowadzony kompletnie bez użycia rzutnika (kto by się tego spodziewał w tych czasach). Jedynie prelegent miał małe karteczki z notatkami do pomocy (których i tak prawie nie używał).
Bob tłumaczył nam, jak pracują obecni inżynierowie. Owocem ich pracy jest zazwyczaj jakiś dokument, który później się przekazuje dalej i ktoś go realizuje. Przykładowo architekci tworzą plan budynku, wraz z tym jak ma być urządzone wnętrze. Przekazują dokument ekipie budowlanej i ta już działa. Elektronicy przykładowo projektują płytkę / układ scalony, przekazują do fabryki i ta wytwarza gotowy produkt.
A jak to jest w naszej profesji? Co jest tym dokumentem, który generujemy i który dajemy fabryce do realizacji produktu? Okazuje się, że jedynym słusznym dokumentem wytwarzanym przez inżynierów oprogramowania jest kod źródłowy. Nie stosy dokumentacji fachowej, technicznej, analitycznej i jeszcze nie wiadomo jakiej, a kod. Kod jest zawsze aktualny i prawdziwy. Kod prawdę Ci powie. Fabryką w tym przypadku jest kompilator, który generuje zbiór bitów, czyli działającą aplikację.
Zasadniczą różnicą, pomiędzy naszą a innymi działkami szeroko pojętej inżynierii, jest to, że w naszym przypadku koszt przekazania kodu kompilatorowi, czyli wygenerowania gotowego produktu, jest zerowy. Tak więc wprowadzanie zmian jest tańsze niż w innych dziedzinach inżynierii. Przykladowo, gdyby koszt powiększenia kuchni w wybudowanym już domu (ale nie kosztem innych pomieszczeń) wynosiłby 1000 dolarów, to nikt by jakoś szczególnie nie projektował domów, a jedynie iteracyjnie je rozbudowywał.
Było jeszcze o kryzysie oprogramowania w 1968 i o dokumencie opisującym czym jest model kaskadowy. Podobno jest on na tyle fascynujący, ze każdy powinien go przeczytać.
Dalej była już znana opowiastka, że nasze obecne komputery (jeśli liczyć razem prędkość procesorów, dysków, pamięci i ich ilości) są ileś tam (10^26 jak dobrze pamiętam) razy szybsze od tych z lat 60tych. A dalej programiści piszą te same instrukcje if, for, while...
Pod koniec wykładu był jeszcze czas na pytania. Co do testowania bazy danych, to Wujek Bob ma ciekawe podejście. On generalnie uważa, że nie powinno się jej testować, albo testować w niewielkim stopniu. Generalnie na bazę danych powinno się patrzyć jak na pewną abstrakcję, gdzie są zachowywane dane. Nie powinno nas interesować jak są one składowane, a jedynie powinniśmy, na potrzeby testów, podmieniać klasy dające nam dostęp do tych danych. I tak dla przykładu: w FitNesse, który jest pisany prze Wujka Boba, bazą danych jest płaski plik.
Analogicznie powinniśmy postępować z testowaniem timeout’ów. Jest to też pewne „wejście” do systemu i powinniśmy podmienić je tak, aby testy szybciej chodziły.
I to by było na tyle jeśli chodzi o konferencję. Na koniec były podziękowania od Grześka Dudy i dla Grześka Dudy - organizatora. Ja również dziękuję, bo konferencja była super zorganizowana. Było ponad 630 uczestników, a jakiś wpadek (którym mógłby zapobiec organizator) nie było. Tablica, na której można było przyklejać karteczki, co idzie dobrze a co źle, bardzo mi się spodobała. No i fajnie były przerwy dobrane, tzn. czasem krótkie (aby zmienić tylko sale), a czasem dłuższe (aby pogadać na korytarzu).
Zostało mi jeszcze do opisania, jak wyglądał warsztat z Wujkiem Bobem w którym brałem udział. Ale to w kolejnym wpie.
Na stronie konferencji znajdziecie jeszcze relacje innych osób z 33 Degree 2012.
33 degree 2012 dzień 2
Dzień 1
Dzień 3
Warsztat z Wujkiem Bobem
Pierwszą prezentacją drugiego dnia 33 degree 2012 na którą się wybrałem, było wystąpienie Joonas'a Lehtinen'a na temat Vaadin’a. Jest to framework do tworzenia Interfejsu użytkownika dla „bogatych” aplikacji. Rozpowszechniany jest on na zasadach Apache License. Vaadin bazuje na GWT, jednak nie ma w nim RPC, serwisów dla UI, a kod renderowania widoku znajduje się po stronie serwera. Po stronie serwera przechowywany jest również stan interfejsu użytkownika, co powoduje brak trybu offline.
Po krótkim wprowadzeniu teoretycznym przyszedł czas na kodowanie na żywo. Do stworzenia projektu wymagany jest jedynie web.xml i jeden JAR. Prelegent pokazywał jak stworzyć prostą przeglądarkę / edytor stron HTML. Podobało mi się rozwiązanie Lazy Loadingu, np. gdy w rozwijanej liście, przewijając suwakiem w dół, ściągały się na życzenie potrzebne elementy. Na pewno generuje to sporo requestów do serwera, ale funkcjonalność ta mi się spodobała.
Kolejna rzecz która mi przypadła do gustu to spor ilość kontrolek, które mogą być od razu powiązane z różnymi źródłami danych. Gdy modyfikujemy jednocześnie te same źródła danych w jednym komponencie, to zmiany te są od razu widoczne w innych / różnych komponentach, które mają podpięte to samo źródło zasilania danych.
Co do dalszych zalet Vaadina, to jest fajny edytor Drag&Drop do Eclipsa / IDEI. Framework działa również na urządzeniach mobilnych i mamy od razu zdefiniowane kilka tematów kolorystycznych do wszystkich komponentów. Można pisać własne nowe komponenty (trzeba trochę grzebać w GWT) i mamy stronę skupiająca te komponenty. Można je ściągać i bezproblemowo integrować z edytorem.
Aplikacje Vaadinowe można podobno pisać w dowolnym języku działającym na JVM. Wspiera on IE6, nie trzeba instalować żadnych dodatków do przeglądarki, a samą aplikację można umieścić na dowolnym serwerze wspierającym Servlety. Na stronie framework’a jest dostępna darmowa książka do nauki, jak i tabela porównująca konkurencyjne rozwiązania. Prowadzący polecał przy okazji REFcardz DZone do nauki nowych technologii.
Co do prezentacji to była ona bardzo fajnie prowadzona, były przykłady, kodowanie, animacje pomiędzy slajdami, ale nie za dużo – dobrane z odpowiednim wyczuciem. Po prostu dobrze przygotowana prezentacja.
Następnie poszedłem na wykład Vogel’a na temat nowych funkcjonalności w Androidzie 4.0. Słychać było mocno niemiecki akcent prelegenta. Na prezentacji było trochę przykładów i kodu. Ogółem dobra prezentacja.
W nowym Androidzie dodano m.in. nową kompozycję kolorów, GridLayout, możliwość zmieniani rozmiarów widget’ów, obsługę Drag&Drop. Doszło jeszcze TextureView, Calendar API, ViewPager (do przesuwania (slidowania) ekranów), Fragments (dzięki czemu ułożenie telefonu zmienia layout) i Properties for Animation API. Jeszcze by się trochę poznajdywało, więcej na prezentacji Vogel'a.
Ciekawym rozwiązaniem jest biblioteka napisana na starsze wersje Androida, emulująca nowe gadżety. Ciekawie jak z jej używaniem.
Następnie wybrałem się ponownie na wykład Venkat’a. Tłumy szalały, miejsca pod ścianami i w drzwiach były obsadzone. Ty razem najlepszy prelegent konferencji opowiadał o programowaniu wielowątkowym. Było sporo kodowania na żywo i w dodatku jemu to wychodziło! Świadczy to o wysokim profesjonalizmie Venkat’a.
Zapamiętałem bardzo fajny trik, który może oszczędzić nam na prezentacji ewentualnych wpadek podczas kodowania na żywo. Mianowicie można tuż przez prezentacją naklepać dokładnie to do czego mamy dojść, a następnie stopniowo usuwać napisane linijki w odwrotnej kolejności, w jakiej chcemy je przedstawić. A na samej prezentacji wystarczy już wciskać kombinację Ctrl + Z i kod będzie się przyrostowo pojawiał przed oczami.
Prezentację zaczęliśmy od standardowego książkowego przykładu z klasą Account, na której można wykonać operacje deposit() i withdraw(), czyli przelać kasę z jednego konta [bankowego] na drugie. Czyli mamy prostą logikę: jeżeli na koncie jest wystarczająco kasy, to ją pobieramy i deponujemy kwotę na innym koncie. Wiadomo nikt nie chce aby znikły mu pieniądze z konta, więc trzeba dobrze to oprogramować. No i zaczęło się.
Prelegent implementował na żywo sugestie proponowane przez publiczność. Jak po chwili dotarliśmy do synchronizacji dwóch obiektów, to się okazywało, że przez to może powstać dead lock. Później rozwiązanie zaczęło ewoluować do monitora, aby ostatecznie prelegent ujawnił preferowane eleganckie rozwiązanie. Mianowicie można dodać do naszego projektu bibliotekę z Clojure’a i już możemy się cieszyć ładnymi transakcjami. Jeśli będziemy chcieli wykonać jakąś „wrażliwą” operację poza transakcją, to biblioteka rzuci nam odpowiednim wyjątkiem i trzeba będzie poprawić kod.
Rozwiązanie bardzo eleganckie i trzeba koniecznie przyjrzeć mu się z bliska. Prelegent twierdził jeszcze, że Clojure jest jedynym bezpiecznym językiem programowania dla JVM’a. Mi ta prezentacja uświadomiła, że obecnie w czasach serwerów aplikacyjnych i super framework’ów mało kiedy piszemy coś na wątkach. A wiedza ucieka. Ja z tego powodu zajrzałem do książki Core Java 2 Techniki zaawansowane (Rozdział Wielowątkowość -> Synchronizacja), aby przypomnieć sobie jak to się powinno robić w czystej Javie.
Następnie, po przerwie obiadowej udałem się na prezentację Sławomira Sobótki na temat technik w inżynierii oprogramowania. Początkowo zaczęło się od charakterystycznych terminów, które można poczytać na blogu prelegenta: 8tysiecznik, osobliwość, boska klasa, ofiary muszą być. Ale na szczęście nie było o tym :)
Sławek przedstawił kilka technik, których stosowanie ma sens w większych projektach. Część z nich w jakiś tam sposób łączy się z DDD (o którym Sławek prowadził później warsztaty), ale można je również stosować po za światem DDD. I tak baza danych nie jest modelem. Model to coś co można pokazać (np. model samochodu, domu), a nie właściwości zapisywane na temat danego modelu. Baza danych może być jedynie strukturą danych, która służy do modelowania.
Kolejną pomocną techniką, o której często zapominamy, to zastosowanie Value Object’ów. Czyli tworzymy sobie abstrakcję, przykładowo klasę Money, aby nie przekazywać wszędzie double (wiadomo dlaczego, było to na 3ch prelekcjach wałkowane). Value Object pełni w tym momencie rolę Adaptera pomiędzy typem technicznym, a domenowym.
Kolejną techniką jest stosowanie Agregatów, aby opakowywać anemiczne encje. Można dodatkowo tworzyć transformacje tego samego obiektu domenowego, zależnie w jakim kontekście jest on używany. Przykładowo pracownik magazynu i pani księgowa inaczej patrzą na ten sam byt, jakim jest faktura. Interesują ich inne dane z tej faktury, jak i mogą wykonywać odmienne operacje na niej.
Następnie było o zasadzie OCP w praktyce. Czyli powinniśmy tworzyć polityki w odpowiednich miejscach, w których mogą później przyjść zmiany. Dzięki temu nasz kod będzie łatwiej rozszerzalny, jak kiedyś przyjdzie konieczność innego sposobu wyliczania podatku, rabatu, czy wypłaty. Dobry kod powinien dać nam w tedy możliwość napisania nowej klasy, implementującej zdefiniowany interfejs, w celu spełnienia wymagania. Zyskujemy również dzięki temu na testowaniu i czytelności kodu (zamiast dopisywać kolejne if’y).
Było jeszcze m.in. zalecenie, aby umieszczać cały zły coupling w fabrykach – smutnych miejscach systemu, czyli w „czarnych dziurach”. Było jeszcze o zastosowaniu wzorców Wizytator i Kompozyt.
Podsumowując wystąpienie Sławka, stosując się do zaproponowanych prze niego technik można uzyskać logikę aplikacji z dużą liczbą zależności, ale za to z prostymi metodami. Więcej można poczytać na blogu Sławka.
Następnie chciałem iść na prezentację Jarosława Pałki, aby posłuchać o architekturze. Niestety wykład został odwołany a w jego miejsce wskoczyło cos innego. Ciężko również było się dostać inne wykłady (z powodu tłoku), więc sobie zrobiłem przerwę.
Następnie znów poszedłem na prezentację Venkat’a, tym razem na temat Scali. Prelegent pokazywał jak w Scali łatwiejsze jest używanie XML’a (nie trzeba jak w Javie całości zamykać cudzysłowami). Język ten jest zorientowany na używanie finalnych obiektów. Można kodować w stylu imperatywnym jak i funkcjonalnym. Można bez przeszkód mieszać te style.
Dalej było o różnicach pomiędzy var a val i że jest to lepsze niż final w Javie. Również nie trzeba na każdym miejscu pisać co jakim typem jest, jedynie tam gdzie jest to niezbędne. Słowo return jest opcjonalne, podobnie jak i średnik. Scala daje nam za darmo konstruktor gettery i settery. Mnie ucieszył fakt, ze nie ma metod statycznych (na pewno poprawia to testowalność kodu). Mamy za to coś takiego jak wbudowany wzorzec Singeleton w język (object). Również w Scali mamy strategię (za pomocą słwa kluczowego trait).
Na koniec dnia poszedłem jeszcze na sesję BoF m.in. Jakuba Nabrdalika na temat porażek. Cieszę się, że prelegenci nie bali się mówić o swoich niepowodzeniach. Przykładowo u nich w projekcie okazało się, że samoorganizujące się teamy nie działały najlepiej. Potrzebna była osoba decyzyjna, bo demokracja nie zawsze jest najlepsza. Było jeszcze trochę o innych porażkach. Dobrze czasem posłuchać, że nie tylko nam się coś nie udaje.
Dzień 3
Warsztat z Wujkiem Bobem
Pierwszą prezentacją drugiego dnia 33 degree 2012 na którą się wybrałem, było wystąpienie Joonas'a Lehtinen'a na temat Vaadin’a. Jest to framework do tworzenia Interfejsu użytkownika dla „bogatych” aplikacji. Rozpowszechniany jest on na zasadach Apache License. Vaadin bazuje na GWT, jednak nie ma w nim RPC, serwisów dla UI, a kod renderowania widoku znajduje się po stronie serwera. Po stronie serwera przechowywany jest również stan interfejsu użytkownika, co powoduje brak trybu offline.
Po krótkim wprowadzeniu teoretycznym przyszedł czas na kodowanie na żywo. Do stworzenia projektu wymagany jest jedynie web.xml i jeden JAR. Prelegent pokazywał jak stworzyć prostą przeglądarkę / edytor stron HTML. Podobało mi się rozwiązanie Lazy Loadingu, np. gdy w rozwijanej liście, przewijając suwakiem w dół, ściągały się na życzenie potrzebne elementy. Na pewno generuje to sporo requestów do serwera, ale funkcjonalność ta mi się spodobała.
Kolejna rzecz która mi przypadła do gustu to spor ilość kontrolek, które mogą być od razu powiązane z różnymi źródłami danych. Gdy modyfikujemy jednocześnie te same źródła danych w jednym komponencie, to zmiany te są od razu widoczne w innych / różnych komponentach, które mają podpięte to samo źródło zasilania danych.
Co do dalszych zalet Vaadina, to jest fajny edytor Drag&Drop do Eclipsa / IDEI. Framework działa również na urządzeniach mobilnych i mamy od razu zdefiniowane kilka tematów kolorystycznych do wszystkich komponentów. Można pisać własne nowe komponenty (trzeba trochę grzebać w GWT) i mamy stronę skupiająca te komponenty. Można je ściągać i bezproblemowo integrować z edytorem.
Aplikacje Vaadinowe można podobno pisać w dowolnym języku działającym na JVM. Wspiera on IE6, nie trzeba instalować żadnych dodatków do przeglądarki, a samą aplikację można umieścić na dowolnym serwerze wspierającym Servlety. Na stronie framework’a jest dostępna darmowa książka do nauki, jak i tabela porównująca konkurencyjne rozwiązania. Prowadzący polecał przy okazji REFcardz DZone do nauki nowych technologii.
Co do prezentacji to była ona bardzo fajnie prowadzona, były przykłady, kodowanie, animacje pomiędzy slajdami, ale nie za dużo – dobrane z odpowiednim wyczuciem. Po prostu dobrze przygotowana prezentacja.
Następnie poszedłem na wykład Vogel’a na temat nowych funkcjonalności w Androidzie 4.0. Słychać było mocno niemiecki akcent prelegenta. Na prezentacji było trochę przykładów i kodu. Ogółem dobra prezentacja.
W nowym Androidzie dodano m.in. nową kompozycję kolorów, GridLayout, możliwość zmieniani rozmiarów widget’ów, obsługę Drag&Drop. Doszło jeszcze TextureView, Calendar API, ViewPager (do przesuwania (slidowania) ekranów), Fragments (dzięki czemu ułożenie telefonu zmienia layout) i Properties for Animation API. Jeszcze by się trochę poznajdywało, więcej na prezentacji Vogel'a.
Ciekawym rozwiązaniem jest biblioteka napisana na starsze wersje Androida, emulująca nowe gadżety. Ciekawie jak z jej używaniem.
Następnie wybrałem się ponownie na wykład Venkat’a. Tłumy szalały, miejsca pod ścianami i w drzwiach były obsadzone. Ty razem najlepszy prelegent konferencji opowiadał o programowaniu wielowątkowym. Było sporo kodowania na żywo i w dodatku jemu to wychodziło! Świadczy to o wysokim profesjonalizmie Venkat’a.
Zapamiętałem bardzo fajny trik, który może oszczędzić nam na prezentacji ewentualnych wpadek podczas kodowania na żywo. Mianowicie można tuż przez prezentacją naklepać dokładnie to do czego mamy dojść, a następnie stopniowo usuwać napisane linijki w odwrotnej kolejności, w jakiej chcemy je przedstawić. A na samej prezentacji wystarczy już wciskać kombinację Ctrl + Z i kod będzie się przyrostowo pojawiał przed oczami.
Prezentację zaczęliśmy od standardowego książkowego przykładu z klasą Account, na której można wykonać operacje deposit() i withdraw(), czyli przelać kasę z jednego konta [bankowego] na drugie. Czyli mamy prostą logikę: jeżeli na koncie jest wystarczająco kasy, to ją pobieramy i deponujemy kwotę na innym koncie. Wiadomo nikt nie chce aby znikły mu pieniądze z konta, więc trzeba dobrze to oprogramować. No i zaczęło się.
Prelegent implementował na żywo sugestie proponowane przez publiczność. Jak po chwili dotarliśmy do synchronizacji dwóch obiektów, to się okazywało, że przez to może powstać dead lock. Później rozwiązanie zaczęło ewoluować do monitora, aby ostatecznie prelegent ujawnił preferowane eleganckie rozwiązanie. Mianowicie można dodać do naszego projektu bibliotekę z Clojure’a i już możemy się cieszyć ładnymi transakcjami. Jeśli będziemy chcieli wykonać jakąś „wrażliwą” operację poza transakcją, to biblioteka rzuci nam odpowiednim wyjątkiem i trzeba będzie poprawić kod.
Rozwiązanie bardzo eleganckie i trzeba koniecznie przyjrzeć mu się z bliska. Prelegent twierdził jeszcze, że Clojure jest jedynym bezpiecznym językiem programowania dla JVM’a. Mi ta prezentacja uświadomiła, że obecnie w czasach serwerów aplikacyjnych i super framework’ów mało kiedy piszemy coś na wątkach. A wiedza ucieka. Ja z tego powodu zajrzałem do książki Core Java 2 Techniki zaawansowane (Rozdział Wielowątkowość -> Synchronizacja), aby przypomnieć sobie jak to się powinno robić w czystej Javie.
Następnie, po przerwie obiadowej udałem się na prezentację Sławomira Sobótki na temat technik w inżynierii oprogramowania. Początkowo zaczęło się od charakterystycznych terminów, które można poczytać na blogu prelegenta: 8tysiecznik, osobliwość, boska klasa, ofiary muszą być. Ale na szczęście nie było o tym :)
Sławek przedstawił kilka technik, których stosowanie ma sens w większych projektach. Część z nich w jakiś tam sposób łączy się z DDD (o którym Sławek prowadził później warsztaty), ale można je również stosować po za światem DDD. I tak baza danych nie jest modelem. Model to coś co można pokazać (np. model samochodu, domu), a nie właściwości zapisywane na temat danego modelu. Baza danych może być jedynie strukturą danych, która służy do modelowania.
Kolejną pomocną techniką, o której często zapominamy, to zastosowanie Value Object’ów. Czyli tworzymy sobie abstrakcję, przykładowo klasę Money, aby nie przekazywać wszędzie double (wiadomo dlaczego, było to na 3ch prelekcjach wałkowane). Value Object pełni w tym momencie rolę Adaptera pomiędzy typem technicznym, a domenowym.
Kolejną techniką jest stosowanie Agregatów, aby opakowywać anemiczne encje. Można dodatkowo tworzyć transformacje tego samego obiektu domenowego, zależnie w jakim kontekście jest on używany. Przykładowo pracownik magazynu i pani księgowa inaczej patrzą na ten sam byt, jakim jest faktura. Interesują ich inne dane z tej faktury, jak i mogą wykonywać odmienne operacje na niej.
Następnie było o zasadzie OCP w praktyce. Czyli powinniśmy tworzyć polityki w odpowiednich miejscach, w których mogą później przyjść zmiany. Dzięki temu nasz kod będzie łatwiej rozszerzalny, jak kiedyś przyjdzie konieczność innego sposobu wyliczania podatku, rabatu, czy wypłaty. Dobry kod powinien dać nam w tedy możliwość napisania nowej klasy, implementującej zdefiniowany interfejs, w celu spełnienia wymagania. Zyskujemy również dzięki temu na testowaniu i czytelności kodu (zamiast dopisywać kolejne if’y).
Było jeszcze m.in. zalecenie, aby umieszczać cały zły coupling w fabrykach – smutnych miejscach systemu, czyli w „czarnych dziurach”. Było jeszcze o zastosowaniu wzorców Wizytator i Kompozyt.
Podsumowując wystąpienie Sławka, stosując się do zaproponowanych prze niego technik można uzyskać logikę aplikacji z dużą liczbą zależności, ale za to z prostymi metodami. Więcej można poczytać na blogu Sławka.
Następnie chciałem iść na prezentację Jarosława Pałki, aby posłuchać o architekturze. Niestety wykład został odwołany a w jego miejsce wskoczyło cos innego. Ciężko również było się dostać inne wykłady (z powodu tłoku), więc sobie zrobiłem przerwę.
Następnie znów poszedłem na prezentację Venkat’a, tym razem na temat Scali. Prelegent pokazywał jak w Scali łatwiejsze jest używanie XML’a (nie trzeba jak w Javie całości zamykać cudzysłowami). Język ten jest zorientowany na używanie finalnych obiektów. Można kodować w stylu imperatywnym jak i funkcjonalnym. Można bez przeszkód mieszać te style.
Dalej było o różnicach pomiędzy var a val i że jest to lepsze niż final w Javie. Również nie trzeba na każdym miejscu pisać co jakim typem jest, jedynie tam gdzie jest to niezbędne. Słowo return jest opcjonalne, podobnie jak i średnik. Scala daje nam za darmo konstruktor gettery i settery. Mnie ucieszył fakt, ze nie ma metod statycznych (na pewno poprawia to testowalność kodu). Mamy za to coś takiego jak wbudowany wzorzec Singeleton w język (object). Również w Scali mamy strategię (za pomocą słwa kluczowego trait).
Na koniec dnia poszedłem jeszcze na sesję BoF m.in. Jakuba Nabrdalika na temat porażek. Cieszę się, że prelegenci nie bali się mówić o swoich niepowodzeniach. Przykładowo u nich w projekcie okazało się, że samoorganizujące się teamy nie działały najlepiej. Potrzebna była osoba decyzyjna, bo demokracja nie zawsze jest najlepsza. Było jeszcze trochę o innych porażkach. Dobrze czasem posłuchać, że nie tylko nam się coś nie udaje.
Subskrybuj:
Posty (Atom)