Pierwszy wykład był sponsorowany przez Akamai, tytuł miał po angielsku, więc spodziewając się zła koniecznego (czyli typowej reklamy jakiegoś produktu, za którą ktoś sporo zapłacił) odpuściłem sobie ten wykład. Pozwiedzałem wówczas stanowiska sponsorskie, zgarniając co się dało. Miałem również możliwość porozmawiania z pracownikami firmy e-point, którzy ostatnio wypuścili OneWebSQL. Jest to framework, tworzący na podstawie modelu danych, klasy encji, DAOsy i tak dalej. Taki ORM, tylko że dostajemy wygenerowany kod, którego ręcznie nie modyfikujemy, a jedynie wywołujemy to co nam jest potrzebne. Widziałem wcześniej filmik prezentujący to rozwiązanie, na którym wykorzystywano PowerDesigner’a do przygotowania modelu danych. Dowiedziałem się, że wsparcie dla kolejnych narzędzi jest w drodze, w tym generowanie kodu na podstawie istniejącego schematu bazy. Czy odniesie to sukces komercyjny - zobaczymy.
Po godzinie 10 była prezentacja Grześka Dudy na temat produktywności. Okazuje się, że najbardziej produktywni jesteśmy do kilku godzin po przebudzeniu i powinniśmy ten czas jak najlepiej spożytkować. Powinniśmy wtedy kodować, analizować problemy i wszystko to, co wymaga od nas dużego wysiłku intelektualnego. Nie powinniśmy wtedy czytać e-maili, oglądać YT ani grać w gry.
Kolejna sprawą jest podział zadań do wykonania na:
1) ważne i pilne
2) ważne i niepilne
3) nieważne i pilne
4) nieważne i niepilne.
O podziale tym można chyba przeczytać w każdej książce dla menagierów i na temat zarządzania sobą w czasie.
Kolejna sprawa to automatyzacja wszystkiego co się da. I Grzesiek nie miał tutaj na myśli automatycznych testów (bo to jest jasne ze to trzeba robić) ale optymalizację powtarzających się co jakiś czas czynności. Przykładem jest test Selenium, który może coś tam aktualizować w Eclipse.
Powinniśmy również unikać robienia 2ch rzeczy równocześnie, chyba że angażujemy do tego 2 półkule mózgowe. Inaczej nie wpływa to dobrze na wydajność. Część małych rzeczy możemy zrobić, czekając na przystanku na autobus, jak np. zadzwonić do mamy.
Następnie Grzesiek krytykował Pomodoro Technique. Uważa on, że 25 min. to za mało. W tym czasie dopiero się rozkręcamy i nie zdążymy zrobić nic konkretnego. Jedyny sens robienia pomidora, to notowanie co nam przeszkadza i jak często. Przydatne tutaj mogą być również narzędzia do analizy, która aplikacja jak długo jest otwarta, np. RescueTime. Inna ciekawa aplikacja to Pocket (Formerly Read It Later), do zapamiętywania tego, co chcemy przeczytać (aby zminimalizować liczbę otwartych zakładek w przeglądarce). Zacząłem ją od teraz stosować. Przydaje się zwłaszcza, gdy w pracy są niektóre strony poblokowane.
Gdy już przeanalizujemy, co nam przeszkadza w pracy, to najczęściej okazuje się, że są to e-maile. Dobrze jest więc wyłączyć wszelkie powiadomienia o nowych wiadomościach, aby nie wychodzić z flow. Potwierdzam z doświadczenia, że to pomaga. Kolejna powiązana kwestia to moment odpisywania na e-maile. Zasada three.sentenc.es mówi, że jeśli jesteśmy w stanie odpisać w 3ch zdaniach, to można zrobić to zaraz po przeczytaniu wiadomości. Jeśli mamy więcej do napisania, to lepiej pogadać. No i oczywiście pisząc bezwzrokowo jesteśmy w stanie zyskać 30% na produktywności (w dłuższym okresie czasu).
Jeśli chodzi o oprawę organizacują, to całkiem fajnie się oglądało prezentację z góry, tj. z balkonu. Niestety nie wiedziałbym o tej możliwości, gdyby Tomek Dziurko (jeden z organizatorów) mi o tym nie powiedział. Ogółem brakowało mi trochę oznaczeń gdzie co jest. Przykładowo dopiero ze zdjęć się dowiedziałem że gdzieś były stare konsole (a może to i lepiej że nie wiedziałem). Następnym razem proszę o więcej oznaczeń, lub schematyczny rzut z góry z zaznaczonymi ciekawymi miejscami.
Następnie byłem na Kędzierzawych testach z kontraktami Cezarego Bartoszuka. Prelegent prezentował bibliotekę CoFoJa. Pomysł kontraktów nie jest nowy, ale pomimo czasu nie przyjął się. Dla mnie te kontrakty to bardziej ciekawostka, niżeli coś co chciałbym stosować. Przypominają mi one słówko kluczowe assert, gdyż tak jak asserta kontrakty można wyłączyć, a korzystać z nich powinniśmy jedynie w trakcie testów. No i nie mamy wsparcia dla refaktoryzacji, a długość definicji pojedynczego pola w klasie mocno rośnie. Jak dla mnie lepiej wykorzystać TDD i BeanValidation jak już coś musimy walidować.
Jeśli chodzi o kędzierzawość, to prelegent przedstawił jeszcze testy z Yeti Test. I to narzędzie już bardziej mi podeszło. Potrafi ono generować sporo losowych testów jednostkowych dla naszego kodu, z uczuleniem na błędne i skrajne wartości. Yeti dobrze współpracuje z kontraktami, ale można go oczywiście stosować oddzielnie.
Co do wad prezentacji można zaliczyć przepełnienie sali. Wiem że była wcześniej ankieta, na co kto chce iść i na tej podstawie były przydzielane sale, ale to przepełnienie świadczy o trochę za dużej liczbie uczestników całej konferencji.
Następnie udałem się na zwinne szacowanie Piotra Burdyło. Było o szacowaniu całości projektu, a nie pojedynczych zadań. Prelegent opowiadał o prawie Parkinsona i syndromie studenta.
Co do szacowania Piotrek zdefiniował kilka zasad, których się trzyma:
- Szacuj po ludzku
- Mierz rzeczy które są mierzalne
- Różne szacunki wymagają różnych metryk
- Bliska przyszłość - dużo szczegółów, daleka przyszłość - mało szczegółów
Prelegent czerpie też sporo z Agile Manifesto i twierdzi że weryfikacja jakości oszacowania jest bez sensu. Wynika to z częstego wypełniania zestawienia czasu pracy pod koniec miesiąca, a także z niedokładności tego wypełnienia. Bo co np. zrobić, gdy kolega z zespołu przyjdzie do nas po pomoc? Zatrzymać aktualny stoper i włączyć inny? No i gdzie de facto upychać wszelkie przeszkadzajki (e-maile, wypełnianie czasu pracy, inne korporacyjne pierdoły, piłkarzyki...)? Nie chce nam się tego aż tak dokładnie notować, gdyż nie jest to warte swego zachodu.
Na koniec była jeszcze ciekawa metoda szacowania całego projektu. Mianowicie piszemy na karteczkach nasze historyjki i je kolejno przyklejamy na tablicy. Kolejną karteczkę umieszczamy w miejscu, które będzie wskazywało, na ile nowa historyjka jest trudniejsza od poprzednich. Na koniec dzielimy tablicę na kilka części i przyporządkujemy historyjkom odpowiednie punkty. Te które są na granicy ponownie analizujemy czy raczej są większe czy mniejsze. Na koniec jeszcze sporo pytań, aż prelegent nie dotarł do końca prezentacji.
Następnie ponownie udałem się na prezentację miękką, tym razem odnośnie Retrospekcji autorstwa Michała Bartyzela. W sali tej był mały problem ze światłem, mianowicie było go za dużo, a przez to slajdy niewidoczne. Na szczęście prelegent więcej gadał niż pokazywał. Widać że Michał ma bardzo dobrze opanowaną sztukę publicznych wystąpień, swobodnie stoi na scenie i bardzo szybko dostosowuje się do aktualnych wydarzeń na sali. Przykładowo raz zaczął się witać ze spóźnialskimi, a gdy mówił o nowych postanowieniach, to jako przykład podał, aby się więcej nie spóźniać na prezentacje (oczywiście ktoś akurat wchodził na salę).
Prelegent zachęcał do robienia małych, osobistych retrospekcji codziennie. Ma to na celu wytworzenia w nas wyrzutów sumienia, które później powinny nas zmotywować do poprawy naszych małych grzeszków. No i odpowiedni powinniśmy definiować swoją pokutę, czyli nie "poprawię swoje szacowania", a "będę szacował za pomocą przedziałów".
Było jeszcze o tym czym jak nie powinny wyglądać retrospekcje. Nie jest to terapia grupowa, gdzie wylewamy swoje żale i idziemy zadowoleni do domu. Po retrospekcji powinny pójść konkretne ustalenia i zmiany.
Na koniec było jeszcze o pytaniach C5:
1. Co zacząć robić?
2. Co przestać robić?
3. Czego robić więcej?
4. Czego robić mniej?
5. Co robić inaczej?
Kolejny wykład na który się udałem był o tym jak uwolnić się od "if" Tomka Nurkiewicza. Są dwa powody dla którego powinniśmy się ich pozbywać. Poprzez duże zagęszczenie instrukcji warunkowych tracimy na czytelności i na szybkości (na poziomie CPU, ale to temat na osobny wpis).
Było sporo przykładów z kodem i refaktoringu na żywo. Bardzo często sprawdzamy za pomocą if'ow, czy pewne wartości nie są null'em. Zamiast tego lepiej stosować Null Object. Dodatkowo chcąc pozbyć się obsługi opcjonalnych argumentów warto stworzyć metody z mniejszą liczbą argumentów, które później wywołują docelową metodę, przekazując właśnie Null Object.
Fajnym ułatwieniem, jakie pokazał Tomek, było Simplify. Przykładowo poniższy kod:
Zostanie przekształcony do:
System.out.println("bbb");
Ważne by kursor przed naciśnięciem Alt + Enter, w jedynym słusznym środowisku, znajdował się na if'ie.Kolejnym przykładem był refkatoring kodu wywołujący pewne zadanie (Task) w wątku i bloku synchronizowanym lub nie. Prelegent ładnie przerefaktorował kod pełen if'ów na synchronizowany dekorator Taska, kod Taska i klasę tworzącą odpowiednie wątki. czyli dostaliśmy ładne rozdzielenie odpowiedzialności.
Później było o tym gdzie używać if'ów. Było na temat tego pytania: Get rid of ugly if statements i sensowności różnych implementacji. Polecam przejrzeć wątek, zwłaszcza odnośnie wielomianu 45 stopnia.
Kolejnym przykładem było porównywanie dat i jeśli daty się nie zmieniają w wymaganych, to czasem dla czytelności lepiej je zahardkodować. Jeśli musimy te daty wczytać skądś, to lepiej skorzystać z Chain of responsibility.
Na koniec było jeszcze trochę na temat wizytatora (odwiedzającego). Wzorzec ten pomaga nam się pozbyć instanceof i rzutowania w dół. Gdy przyjdzie nam dodać nowy typ to jednak trzeba wszystkie dotychczasowe klasy o jedną metodę rozszerzyć.
Co do samej organizacji, to lampa w środkowym rzutniku była mocno wypalona, przez co obraz był nieostry. Na szczęście były jeszcze dwa po bokach i po ściemnieniu światła można było wygodnie się gapić, na to prelegent robił.
Co do samej prezentacji, to bardzo mi się podobała - dużo wiedzy, szybkie tępo, brak nudy, praktyczna wiedza.
Następnie było wystąpienie Pawła Cesara Sanjuana Szklarza na temat złożonych architektur bez podziału na warstwy. Prelegent przedstawiał swoje rozwiązanie dotyczące wstrzykiwania zdalnych wywołań w ramach innych maszyn wirtualnych Javy. Ma to na celu unikniecie kudu, który tylko deleguje zdania dalej. Nie będę się tutaj więcej rozpisywał, kod do przejrzenia jest tutaj: github.com/paweld2/Service-Architecture-Model.
Na koniec był jeszcze wykład "How to be awesome at a Java developer job interview" Wojciecha Seligi Opowiadał on, jakie cechy powinien mieć kandydat na stanowisko w jego firmie (lub ogółem w firmie która chce mieć tylko najlepszych w swoim fachu). Wykład sponsorowany, ale wzbudził wiele kontrowersji.
Pierwsza sprawa to języki (ale nie programowania). Powinniśmy znać język klienta, dla którego będziemy pracować, język firmy w której będziemy pracować i oczywiście angielski.
Później prelegent przedstawiał dwa typy kandydatów, których nie lubi. Pierwszy z nich to certyfikowani analfabeci, którzy mają górę certyfikatów, ale niewielką wiedzę. Brakuje im znajomości pakietu java.util.concurrent, Garbage Collectora, zarządzania zasobami w JVM, programowania sieciowego, wielowątkowego i stosu IP.
Swoją opinię na ten temat przedstawił już Koziołek we wpisie Rozbrajamy minę.... Ja od siebie dorzucę, że rzeczywiście wg. mnie nie każdy musi znać java.util.concurrent. Znajomość wątków i podstawowych metod synchronizacji jest jednak konieczna, a nieznajomość nowego kodowania wielowątkowego zazwyczaj wynika z używania starej wersji Javy w projekcie, jak i przerzucenia sporej odpowiedzialności na serwer aplikacji, w przypadku typowego programowania webowego. I w typowych obecnych projektach rzadko się wątki wykorzystuje. A w pracy są przecież potrzebni przedewszystkim typowi rzemieślnicy, którzy wyrzeźbią wymagania funkcjonalne klienta, które bardzo często kończą się na wczytaj, pokarz, zmodyfikuj, sprawdź, zapisz…
Analogicznie ma się sprawa do znajomości GC i zarządzania zasobami. Jak już w projekcie się zdarzy, że coś tam trzeba pogrzebać, to robi to część zespołu i nie każdy ma okazję wtedy poeksperymentować. Nawet jak już się będzie tym szczęśliwcem, to po kilku miesiącach już się nic nie pamięta. Co do stosu IP to pamiętam, że model OSI ma 7 warstw a TCP/IP 4, które jakoś tam odpowiadają jedne drugim. Ale na rozmowie kwalifikacyjnej na stanowisko kodera javy nie przypomniałbym sobie za nic nazw tych warstw i nawet nie przyszło by mi do głowy, aby sobie o tym przypominać.
Z drugiej strony powinniśmy równać w górę a nie w dół, więc trzeba będzie kiedyś wrócić do tych tematów i je ogarnąć.
Kolejny typ kandydata do pracy, którego Wojciech nie lubi to Astronauci którzy mają o sobie nie wiadomo jakie mniemanie.
Dalej było o umiejętnościach typowo technicznych, jakie powinien posiadać dobry kandydat. Nie będę ich tutaj wymieniał a jedynie odeślę do prezentacji. Jak kolejnym razem przyjdzie mi się zmierzyć z jakimś rekruterem, to na pewno przypomnę sobie tą prezentację przed rozmową. Warto też przeczytać komentarz autora pod prezentacją, czyli odpowiedź na stawiane zarzuty. Rzeczywiście prezentacja wywołała sporo emocji - bardzo mnie to cieszy, cel prelegenta osiągnięty - brawo!
Prelegent polecał jeszcze książkę Java Concurency in practice. A z dalszą częścią prezentacji już ciężko się nie zgodzić. Feedback po rozmowie powinien być telefoniczny (choć e-mailowy też mi się podoba), na rozmowie powinno być prawdziwe kodowanie, a rekrutacje powinni przeprowadzać najlepsze osoby z firmy, choćby się paliło i waliło w projekcie. Ponadto najlepsi chcą pracować tylko z innymi najlepszymi, lub jeszcze lepszymi.
Było jeszcze o trudnych pytaniach od kandydatów, czyli o ścieżkę rozwoju, możliwości awansu i gwarancję stabilności. Pytania te nauczyły nas stawiać korporacje, które na dzień dobry mydlą oczy takim lukrem (ścieżki kariery, awansu, rozwoju, szkolenia, wyjazdy i inne benefity).
Co do różnicy zdań jeszcze, to Wojtek szuka profesjonalistów, ale sam nie jest bez skazy. Już podczas pisania relacji z tegorocznej konferencji 33 degree, zwracałem uwagę na usuwanie testów, jeśli są przez dłuższy czas czerwone. Raczej nie po to ktoś się wysila aby napisać test, aby go potem usunąć, gdy nie działa. A druga sprawa (o której wtedy zapomniałem napisać) to niby 10 lat doświadczenia w tworzeniu testow, a na prezentacji (tej z 33 degree) był kod testu, gdzie na zmianę były wywoływane testowane metody, assercje, metody, assercje itd. I nazywane było to testem jednostkowym...
Na sam koniec było trochę reklamy, ale skoro to wykład sponsorowany to nich będzie. Mimo że się w kilku punktach nie zgadam z prezenterem, to prezentację uważam za bardzo udaną i wartościową, gdyż bylem ciekaw spojrzenia z punktu widzenia osoby rekrutującej.
Po ostatnim wykładzie było losowanie nagród, podziękowania itd.
Wieczorem jeszcze udałem się na imprezę integracyjną. Była wynajęta kręgielnia wraz ze sponsorowanymi grami piwem i pizzą. Czyli nikt nam nie przeszkadzał i można było się spokojnie zrelaksować.
Wielkie brawa dla organizatorów, wolontariuszy i innych zaangażowanych w konferencję. Dobra robota. Co do minusów to już Koziołek pisał o braku foyer, przez co z powodu natłoku ludzi ciężko było się przemieszczać w trakcie dziesięciominutowych przerw. Ale i tak fajnie że mój postulat z poprzedniego roku na temat wydłużenia przerw został spełniony, więc więcej nie narzekam. Brakowało mi jeszcze oznakowań (albo ich nie widziałem) / planu sal, klimy. Lekkie przepełnienie uczestników utrudniało przemieszczanie się pomiędzy wykładami, a w powidle było za dużo światła (brak zasłoniętych żaluzji). Widać było, że organizatorzy się bardzo starali, ciągle biegali i mieli kupę roboty. Jeszcze trochę i nie będzie czego poprawiać.
Podobne wypisy można znaleźć na stronie konferencji.
Brak komentarzy:
Prześlij komentarz