English versionKonferencja zakończyła się nie tak dawno bo w piątek. Zdecydowanie czuję się po niej nakręcony i pełen nowych pomysłów.
Konferencja trwała 3 dni (6-8 Kwietnia) i musze przyznać, że była to jedna z najlepszych na jakich dotychczas byłem.
Mogę z czystym sumieniem powiedzieć, że była porównywalna z ubiegłorocznym Google Developer Day w Pradze zarówno pod kątem merytorycznym jak i organizacyjnym. Co prawda GDD trwała 1 dzień i była doarmowa ale dojazd do Pragi też cos kosztował.
Wielkie podziękowania należą się organizatorom, zwłaszcza głównemu - Grześkowi Dudzie.
Miejsce konferencji - Best Western Hotel - to świetne miejsce na tego typu wydarzenia, dobrze wyposażone we wszystko co potrzeba, moze jedynie brakowało toalet pod którymi nieustannie stały kolejki.
Podczas konferencji mieliśmy wolny dostęp do przegryzakow różnego rodzaju i napojów - super sprawa i nie tak jak na niektórych innych konferencjach, gdzie zwylke po krótkim czasie nic już nie było na stole.
Poza tym organizatorzy postarali sie o inne bonusy jak 40% zniżkę na książki O'Reilly, 4-miesięczną licencję na JRebel, rezerwację lunchu i co ważniejsze wspaniałych prelegentów, przynajmniej jeśli chodzi o tych, w których prezentacjach uczestniczyłem.
Oto i oni..
Linda Rising - 'Deception and Estimation'Linda Rising prowadzi rubrykę Insights and Experience Reports w wydawnictwie
IEEE Software magazine. Na jej pierwszym wystąpieniu opowiadała o tym czym jest zwodniczość, czyli innymi słowy kłamstwo. Ludzie nie tylko oszukują innych ale i samych siebie. Już jako dzieci jesteśmy z tym oswajani, gdy słyszymy od najbliższych: "O.. powiedz jak bardzo kochasz ciocie Elen", albo jako dorośli ludzie w związkach, kiedy np. żona mówi do męża: "Kochanie, czy wyglądam grubo w tej sukience?". Zwykle kłamiemy w takich sytuacjach, ale wtedy nie jest to nic złego, a wręcz przeciwnie, to o wiele zdrowiej niż powiedzenie szczerej prawdy - "Tak Kochanie, jesteś gruba!" ;)
Jednak, gdy przychodzi do szacowania, oszustwo nie jest wskazane.
Po pierwsze, czy jesteśmy w ogóle w stanie dobrze oszacować? Jesteśmy z natury optymistami, odrzucamy myślenie o procesach i informacjach, które się nam nie podobają, przeinaczamy to co widzimy nawet jeśli jest to potwierdzone naukowymi dowodami. Im jestesmy inteligentniejsi tym bardziej zwodniczy. Max Planck powiedział:
'Prawda nigdy nie triumfuje – wymierają tylko jej przeciwnicy'
Zwykliśmy myśleć o sobie jak o wybitniejszych od pozostałych, mądrzejszych, zawsze mających rację. Często używamy do szacowania śmiesznych rzeczy, np. często uważa się, że dodając wiecej osób do określonego zadania uzyskamy szybsze jego zakończenie, tymczasem prawo Brooksa dowodzi przeciwnie - wydłużymy w ten sporób zadanie. Brooks dał prosty przykład, że 9 kobiet nie urodzi dziecka w jeden miesiąc(
http://en.wikipedia.org/wiki/Brooks's_law).
Zwinne metodyki projektowe mówią, że powinniśmy dzielić projekt na bardzo małe części - im mniejsze tym lepszą uzyskamy estymacje.
Wreszcie, jeśli nadal nie jesteśmy w stanie odpowiedzieć na pytania jakie pojawiają się podczas szacowania jakiegos zadania możemy wykorzystać specjalnie stworzona do tego celu strone ;)
http://estimategoat.comMatt Raible - 'Comparing JVM Web Frameworks'Matt Raible jest architektem interfejsu użytkownika specjalizującym się w szkieletach Open Source. Matt porównał kilka szkieletów: GWT, Spring MVC, Vaadin, Ruby on Rails, JSF, Wicket, Tapestry, Play.
Kiedy przychodzi nam wybrać właściwy szkielet dla naszej aplikacji należy dojść do właściwego rozwiązania drogą eliminacji. Eliminujemy te, w których nie uda się zrealizować wymagań projektowych a zostawiamy te, które pasują do tego najlepiej. Często jest tak, że podczas gdy jeden szkielet jest znakomity do realizacji oreślonej funkcjonalności, kompletnienie nadaje się dla pozostałych.
Przy wyborze szkieletu dobrze jest spojrzeć na ruch na liście mailingowej na stronie szkieletu - to świetny znacznik mówiący, czy szkielet jest używany przez innych, czy żyje. Wybór wymarłego szkieletu oznacza, że w przypadku problemów w nim znalezionych będziemy musieli naprawić je sami. Nie o to przecież nam chodzi. Raport popularności szkieletów na rok 2011 znajduje się na
http://www.zeroturnaround.com/java-ee-productivity-report-2011/Nathaniel Schutta - 'Hacking Your Brain for Fun and Profit'Znakomita prezentacja pełna pomysłów jak zwiększyć własną produktywność. Spośród wielu, zanotowałem kilka..
Obraz mózgu słuchacza odzwierciedla obraz przemawiającego do momentu, gdy słuchacz przestaje nadążać, wtedy obraz ten rozdziela się(
http://www.zeroturnaround.com/java-ee-productivity-report-2011/)
Nasz mózg jest aktywny 24/7. Nawet gdy śpimy nasz mózg nieustannie coś trawi, np. znany jest niewiarygodny przypadek Chorwackiej dziewczyny, która po przebudzeniu ze śpiączki potrafiła mówić po Niemiecku podczas, gdy nigdy wcześniej nie znała tego języka (
http://bit.ly/9t7JW9).
Naukowcy mają zadziwiające osiągnięcia w dziedzinie analizy mózgu, np. powstają aktualnie pierwsze skanery, które potrafią powiedzieć o czym osoba myślała podczas snu(
http://www.newscientist.com/article/mg20427323.500-brain-scanners-can-tell-what-youre-thinking-about.html)
Dowiedziono, że krótka drzemka potrafi zwiększyć produktywność. Thomas Edison spał ok. 4-5 godzin dziennie, ale zwykł robić drzemki w ciągu dnia. Trzymał wtedy w rękach ciężkie piłki gdy zasypiał, żeby nie wprawić się w stan głębokiego snu. Kiedy stan ten przychodził jego ręce rozluźniały się a piłki upadały z hukiem na podłoge budząc go(
http://www.wilywalnut.com/Thomas-Edison-Power-Napping.html,
http://dilbert.com/fast/2009-05-26)
Znane sa w historii przypadki ludzi, którzy byli w stanie powstrzymać sie od snu kilka dni (
http://www.youtube.com/watch?v=nSNRdvusmQs). Jednak sen jest niezbędny do prawidłowego funkcjonowania organizmu. Brak snu powoduje drastyczny spadek wydajności a nawet choroby. Dowiedziono również, że geny mają wpływ na to ile potrzebujemy snu. U niektórych osób wykryto gen bezsenności, pozwalający im funkcjonować bez snu przez długi czas.
Cała prezentacja z odnośnikami do innych źródeł jest na stronie Nathaniela:
http://ntschutta.com/slides/Hacking_Your_Brain.pdfNathaniel Schutta - 'Going mobile with jQuery'Kolejny raz Nathaniel udowodnił, że na swoich prezentacjach jest prawdzimym showman'em. Przedstawił inspirujące przykłady implementacji interfejsu aplikacji mobilnych w jQuery Mobile (
http://jquerymobile.com/). Na pewno sam tego spróbuję.
Tworzenie interfejsów mobilnych w HTML5 ma taką główna zaletę, że dostarczamy jeden kod na wiele systemów operacyjnych i wiele rodzajów urządzeń. Czasami różnica w wyglądzie między aplikacjami natywnymi a napisanymi w HTML5 jest niezauważalna. Godna uwagi jest biblioteka Pretty Mobile (
http://wdtoolbox.com/prettymobile-iphoneitouch-website-development-toolkit/) wspomniana przez jednego z uczestników prezentacji, która pomaga tworzyć interfejsy wyglądające niemal identycznie jak natywne.
Linda Rising - 'The Power of Retrospection'Po raz kolejny Linda udowodniła swoje niezwykłe zdolności prezentacyjne, tym razem podczas warsztatu.
Mówiła o retrospekcji. W projektach Agile to termin oznaczający spotkania, na których zespół podsumowuje projekt (lub jego fazę). Co ważne, w spotkaniach tych nie uczestniczą managerowie. Moga oni dopiero zobaczyć anonimowe wyniki po spotkaniu.
Główne regóły retrospekcji to:
- nie wytykamy błędów, nie zwracamy sie do konkretnych osób
- nie przyznajemy się do własnych błędów
Mówimy o problemach a nie konkretnych osobach z nimi związanych. Nie winimy nikogo za nic.
4 pytania które należy zadać sobie na retrospekcji:
1) Co działało i o czym nie chccemy zapomnieć?
2) Co powinniśmy zrobić inaczej?
3) Czego nauczyliśmy się?
4) Co jest nadal zagadką?
Kiedy mówimy co powinniśmy zrobić inaczej, powinniśmy znaleść maksymalnie 3 małe i proste do zmiany rzeczy, nawet jeśli w danej chwili nie wydaje się żeby przyniosły konkretny efekt. Często rozwiązanie przychodzi samo, gdy wcielimy te zmiany w życie.
Na spotkaniach retrospekcji miło też, gdy każdy z uczestników doceni wkład pozostałych w projekt. Wszyscy zbierają się i każda osoba mówi co podobało jej sie w pozostałych osobach, np. "Doceniam, że kiedy dostarczaliśmy projekt zostałeś w weekend w pracy nawet kiedy Twój syn miał wtedy urodziny. Bez Ciebie nie udałoby sie nam dojść do tego momentu." Prawda że budujące? ;)
Technika, która pomaga wychwycić rzeczy dobre i złe podczas trwania projektu to tzw. 'linia czasu'. O co w tym chodzi? Obojętne którego dnia podczas trwania projektu każdy jego członek może wybrać któryś spośród czterech kolorów kartek i napisać na niej jak sie czuje, opisać swój problem. Kolory to: czerwony dla złości, zielony dla wyzwania, niebieski dla szczęścia, żółty dla zaskoczenia. Kartki są potem wieszane na ścianie lub kładzione na podłodze anonimowo. Na koniec projektu albo jego fazy gdy dochodzi do retrospekcji na podstawie kartek tych można łatwo zaobserwować jak przebiegał projekt, kiedy miał najwięcej problemow (czerwone kartki) a kiedy niejasności (żółte kartki).
Jakub Nabrdalik - 'Hack your company'Jakub zaprezentował zbiór przykładów z życia jak poprawic wydajność i motywacje pracowników w firmie. Kilka wskazówek:
- tygodniowe/miesięczne warsztaty (jak code retreat) trwające ok. 1 godz.
- tygodniowe/miesięczne prezentacje, na których osoba przedstawia wybraną przez siebie technologie, trwające ok. 1 godz.
Jak przekonać szefa do takich przedsięwzięć? Jednym ze sposobów może być zaproponowanie czasu, gdy i tak produktywność nie jest zbyt wielka, czy wręcz bliska zeru, czyli ok godz. 15.00 - 16.00 w piątki. Osobiście do mnie to nie przemawia. Wolałbym żeby moi słuchacze nie byli rozpraszani przez myśli typu 'Czy to już weekend?' :) Innym uzasadnieniem może być to, że mniej doświadczeni deweloperzy uczą się przez warsztaty, poprawiając jakość dostarczanego kodu, poznając nowe technologie.
Pierwszy dzien zakończył się imprezą przy piwie :)
Drugiego dnia rozpocząłem od prezentacji
Jevgeni Kabanov - 'Do you really get Memory?'Dotyczyła wydajnośći JVM, zasady działania garbage collector, ich różnych implementacji, modelu pamięci JVM (przestrzenie young, ternured, perm), co oznacza słowo 'volatile'.
Fragmenty prezentacji, niestety w niezbyt dobrej jakości można obejrzeć tutaj:
http://www.youtube.com/watch?v=-KlYKIXBdHwhttp://www.youtube.com/watch?v=lE5djOLKTjghttp://www.youtube.com/watch?v=it9I5bIzktEHamlet D'Arcy - 'Java Boilerplate Busters'Przegląd takich bibliotek Open Source jak:
Google GuavaApache CommonsPomagają one pisać czysty i zrozumiały kod, który jest zarazem wydajny, zamiast odkrywac na nowo cos po swojemu, co zabiera sporo czasu a niekoniecznie działa bezbłędnie i wydajnie.
Dan Allen - 'Arquillian: Real Java enterprise testing'Prezentacje rozpoczął drobnymi problemami z komputerem ale mimo ok. 15 min. opóźnienia poprowadził interesujący wykład o testowaniu aplikacji enterprise w ich docelowym środowisku zamiast odizolowanym(np. zagnieżdzonego kontenera).
Narzędzie wykorzystywane w tym celu to
Aquillian wraz z
Shrinkwrap od JBoss.
Patrycja Węgrzynowicz - 'Patterns and Anti-Patterns in Hibernate'Spodziewałem sie troche innej prezentacji, tymczasem to o czym była mowa znałem już wcześniej więc osobisty zysk był niewielki, ale dla kogoś kto się wcześniej nie spotkał z problemami z izolacją transakcji i wydajnością zapytań w Hibernate wykład był z pewnością interesujący.
Jarosław Pałka - 'Architecture and programming model for NOSQL web'Po raz pierwszy spotkałem się tutaj z przykładem użycia NOSQL w realnym projekcie. Ciekawy wykład. Źródła przykłądów z prezentacji można znaleść tutaj
https://bitbucket.org/kcrimson Nie mogę się doczekać kiedy znajdę trochę czasu żeby z tym poeksperymentować. Innym cennym źródłem informacji o NOSQL jest
http://nosql.mypopescu.comJarosław pokazał jak połączyć bazę NOSQL typu klucz-wartość z tradycyjną bazą relacyjną. Ponadto ciekawa była dyskusja na temat komercyjnego użycia bazy Neo4j. Utwierdza mnie to w przekonaniu, że trend NOSQL będzie się w przyszłości cieszył coraz większym zainteresowaniem i nie jest to tylko tymczasowa moda.
Interesuję sie tym tematem od dośc niedawna i cieszę się, że w dalszej części konferencji mogłem znaleść jeszcze więcej na temat skalowalności aplikacji i NOSQL.
Matthew McCullough - 'Monitoring 10 Critical Code Quality Metrics with Sonar'Matthew zaprezentował ciekawe narzędzie -
Sonar - aplikacja enterprise do analizy kodu z webowym interfejsem użytkownika. Narzędzie jest w 90% Open Source. Pozostała część ma licencje komercyjną. Umożliwia rozszerzanie przez pluginy, rozpoznaje wiele języków programowania (nawet COBOL co było zaskoczeniem) i przedstawia się ciekawie jako narzędzie do okresowych przeglądów kodu. Użytkownik może nawigować od wyników analizy do linii kodu.
Co więcej, aplikacja posiada plugin Eclipse, dzięki któremu można synchronizować wyniki analizy z Eclipsem, łatwo nawigować do problematycznego kodu, poprawić go i komitować zmianę.
Serwer aplikacji umożliwia integrację z SVN, Git, Hudson, Apache Ant i Mavenem.
Google Chart użyto do prezentacji najczęstrzych grzechów programistów z następujących dziedzin:
- rozmiar/skomplikowanie kodu
- testy jednostkowe
- duplikacje
- standardy kodowania
- potencjalne błędy
- architektura
- komentarze
Nathaniel Shutta - 'Agile UI'Jeszcze raz świetne przemówienie. Tym razem na temat użyteczności projektów. Zaprezentował kilka przykładów złych a zarazem śmiesznych projektów z codziennego otoczenia. Główna zasadą przy projektowaniu interfejsu użytkownika jest wcielenie się w osobę, która będzie rzeczywiście tego używała. Gdzie ona pracuje? Czy jest tam głośno? Czy jest jasno?
Software powinien być intuicyjny, ponieważ nigdy nie wystarczy czasu na dodatkowe szkolenia. Co jeśli znaki są niezauważalne lub źle interpretowane?(
http://www.slate.com/id/2245644)
Slajdy z dodatkowymi odnośnikami sa tutaj:
http://ntschutta.com/slides/Agile_UI.pdfDrugi dzień zakończył Hackergarten. Jest to spotkanie, na którym developerzy pracują nad różnymi projektami Open Source. Celem jest skończenie spotkania z działającym kodem, dokumentacją, prezentacją lub czymkolwiek innym co jest pożyteczne dla projektu.
Nigdy wcześniej nie brałem udziału w czymś takim. Idea jest ciekawa, gdyż można poznać nowych ludzi, zobaczyć nad czym pracują, w jaki sposób, jakich używaja narzędzi. Bardzo pouczające. Mnie udało się np. spotkać pierwszy raz z
liquibaseFajnie też, że pojawiło się darmowe piwko i przekąski ;)
Ostatni, trzeci dzień, rozpocząłem od
Karl Rehmer - 'How Debuggers Work'Niestety mój poziom wiedzy na temat debuggerów, ich działania i projektowania nie pozwolił mi wynieść zbyt wiele z tej prezentacji. Co utkwiło mi w pamięci to, że debuggery Java znacznie sie różnią od tych dla języków natywnych, które to korzystają z
DWARF).
Debuggery Java tymczasem nie używają adresów ani kodu maszynowego a korzystają z JDWP (Java Debug Wire Protocol) lub JDI (Java Debug Interface) do komunikacji z JVM. Może być to użyteczne nie tylko do pisania debuggerów ale także do analizy działających programów, np. informacji o przestrzeni stałych, przechwytywania wykonywanych metod.
Costin Leau - 'Using Spring with non relational databases'Costina można znaleść na
http://twitter.com/costinlKolejna dawka wiedzy o NOSQL. Tym razem dowiadujemy się o wsparciu Springa w tej dziedzinie
http://www.springsource.org/spring-dataSpring Data dostarcza rozszerzeń dla baz klucz-wartość(Redis, Riak), dokumentowych(MondoDB, CouchDB), grafowych(Neo4j) z użyciem AspectJ do przezroczystego zapisywania POJO. Przykład użycia Neo4j ze Springiem to
Restaurant SocialSpring ma tez wsparcie dla Apache Hadoop - szkieletu do intensywnego przetwarzania danych, o którym w dalszej częsci relacji.
Matthew McCullough - 'Hadoop: Divide and Conquer Gigantic Datasets'Był to wstęp do Apache Hadoop. Matthew pokazał obraz VMware, króry można za darmo ściągnąć z
http://www.cloudera.com/downloads/ i zobaczyć czym to się je.
Hadoop jest idealnym rozwiązaniem dla systemów operujących na dużych plikach o rozmiarze rzędu 1TB. Im większe pliki tym wydajniejszy jest Hadoop.
Dane są rozproszone na kilku serwerach, ale jest to przezroczyste dla końcowego użytkownika, który może wykonywać polecenia z linii komend tak, jak gdyby dane były lokalnie na dysku. Użytkownik może też pisac własne metody map-reduce w Javie, które następnie są użyte do przetwarzania rozproszonych danych.
Hadoop zainspirowany został przez MapReduce i Google File System. Dokument opisujący GFS dostępny jest na
http://labs.google.com/papers/gfs.htmlMam zamiar przyjrzeć się WMware od Cloudera bliżej:)
Neal Ford - 'Abstraction Distractions'Prezentacja dostępna na
http://www.jfokus.se/jfokus11/preso/jf11_AbstractionDistractions.pdfNeal podkreślił wagę szerszego spojrzenia na przedmiot, ktorego model tworzymy. Abstrakcja nigdy nie dorówna oryginałowi. Abstrakcja która jest dobra w danej chwili, może się okazać kompletnie niedorzeczna w przyszłości, np. w przeszłości wierzono, że Ziemia jest w centrum Wszechświata i jakakolwiek inna idea była tępiona siłą. Inny przykład - jak zapisać ważne informacje, żeby przetrwały dekady? Np. pierwsze programy komputerowe były zapisywane na taśmach perforowanych. Jeden z programów, z tamtych czasów który nadal cieszy się pularnością to edytor Emacs. Jego oryginalny kod źródłowy jest zapisany na taśmach, które są przechowywane do dziś, ale żeby go odtworzyć należałoby zbudować maszynę, która potrafi te taśmy odczytać.
Ludzie zaczynają przedsięwzięcia w celu stworzenia rozwiązań, które mają przetrwać wieki. Jednym z takich jest projekt Long Now - próba stworzenia gigantycznego zegara
http://longnow.orgInnym przykładem abstrakcji (spośród wielu wymienionych przez Neala) może być klient poczty e-mail. Przez lata wiadomości składowano w strukturach folderów, aż do czasu, gdy powstał GMail i idea przypisywania etykiet do wiadomości. Pojedyncza wiadomość może mieć wiele etykiet, co jest o wiele berdziej naturalne i użyteczne niż konieczność wrzucenia jej w jeden tylko folder (naturalnie moglibysmy skopiować wiadomość do wielu folderów, ale czy nie jest to niepotrzebna komplikacja w porównaniu do abstrakcji stworzonej przez GMail?)
Rekomendowane ksiązki to
Paul Graham: 'Hackers and Painters' i
Gef Roskin: 'The Human Interface' .
Neal wspomniał też o paradoksie Blub, który można wyjaśnić jako ignorancje dla nowych rzeczy, np. ignorowanie nieznanego języka programowania przez programistę, który jest przywiązany do języka znanego przez siebie i używanego codziennie.
Michael Nygiard - 'Architect for Scale'Michael opowiedział o systemach dużej skali, partycjonowaniu i skalowalności, W tym kontekscie ponownie pojawia się NOSQL i teoria CAP wg. ktorej system może spełniać tylko maksymalnie 2 cechy jednocześnie spośród Consistency (C), Availability (A) and Partition-tolerance (P). W partycjonowaniu chodzi też o najmniejsza możliwą liczbę węzłów w klastrze i większą liczbe klastrów.
System może byc partycjonowany np. geograficznie, funkcjonalnie.
Reguła Amdahl'a została zestawiona z uniwersalnym prawem skalowalności.
To była już ostatnia prezentacja, na której byłem, bo musiałem spieszyć się na powrotny pociąg do Łodzi. Szkoda bo doszły mnie słuchy że kolejne prezentacje były niemniej ciekawe.
Strona domowa konferencji
