Niedaleko lotniska w Warszawie odbywa się konferencja skupiająca ponad 1200 uczestników.
33rd Degree – Conference for Java Masters 13-15 March 2013 Warsaw Poland.
Głównym tematem konferencji jest Java, ale nie tylko…
Poniżej krótka relacja z wybranych prezentacji pierwszego dnia konferencji w porządku chronologicznym.
How to make good teams great (Sven Peters)
Sven z Atlassian rozpoczął konferencję prezentacją dotyczącą cementowaniu i poprawianiu nastrojów pracy w grupie.
Chcielibyśmy, żeby ludzie cieszyli się ze swojej pracy i traktowali ja jako wyzwanie i przygodę, bo to przekłada się na produktywność, a produktywność na pieniądze. Sven pokazał 7 sposobów według Atlassiana na sprawienie, że dobre zespoły stają się jeszcze lepsze:
- Rezerwuj czas na skupioną pracę,
- Ćwicz umysł,
- Doceniaj sukcesy,
- Automatyzuj raportowanie,
- Testuj własny produkt,
- Rezerwuj czas na zrobienie czegoś co odkładasz, co jest trudne ale zrobienie tego bardzo ci ulży,
- Eksperymentuj tak, by zbudować coś działającego i zdobywaj na to czas w trakcie czasu pracy.
Według głosowania okazało się, że większość ludzi pracuje w zespołach, a 60-70% pracuje w modelu agile!
Decisions, decisions (Dan North)
Kolejnym mówcą był Dan (ten od JBehave). Miałem przyjemność uczestniczyć w szkoleniu Dana Accelarated Agile poprzedzającym konferencję i ta prezentacja stanowiła wycinek szkolenia dotyczący wzorców dotyczących podejmowania decyzji .
Dan mówi, ile kosztują decyzje w sensie utraconych korzyści i kompromisy, jakie podejmujemy podczas codziennej pracy nad rozwiązaniami i kierunkami rozwoju oprogramowania i organizacji.
Automatyzując procesy zyskujemy na czasie, ale tracimy czynnik ludzki, który potrafi zwrócić uwagę na aspekty, na które automat zwrócić uwagi nie może, np. podczas testowania człowiek zauważy zmiany które obniżają ergonomię. Innym przykładem jest strażnik patrolujący korytarz w nocy zauważy przedmiot leżący na środku przejścia, który może powodować zagrożenie, natomiast czujka ustawiona na ruch go nie wykryje. Ciekawym przykładem wyboru podanym przez Dana był dylemat czy koncentrować się na kodzie rozwiązującym problem i poszukiwaniach możliwych rozwiązań, czy pisać od razu kodu w TDD nie wiedząc z góry jakie rozwiązanie będzie właściwe. Oczywiście jeżeli ktoś potrafi eksperymentować używając TDD, to takie podejście wcale nie jest złe, ale musi być to świadoma decyzja. Czy budowanie aplikacji monolitycznej jest obecnie niewskazane, a może istnieją sytuacje takie jak aplikacje na telefon, gdzie model monolitycznego oprogramowania nadal jest optymalnym rozwiązaniem?
Busy Developer’s Guide to Iconoclasm (Ted Neward)
Amerykanin Ted przedstawił prezentację o dziwacznie brzmiącym tytule i zaskakującej treści. Zaczęło się o opowieści o edukacji w USA i budowaniu testów kompetencji skierowanym na szeregowanie ludzi podług ich przyszłego zajęcia i wskazaniu jak bardzo ten system odbiega od rzeczywistości, gdyż w globalnym świecie młodzi inżynierowie z USA wypierani są przez inżynierów z innych krajów np. Indii, Brazylii, również Polski. Podług jakiegoś z testów Ted miał zostać księdzem… cóż, może mielibyśmy dziś innego papieża gdyby Ted zechciał posłuchać wyniku testu. Komputeryzacja odbiera pracę specjalistom. Podążając tą ścieżką automatyzacja odbiera prace doktorom, prawnikom, może kiedyś programistom. „Oh, my goodness! Shut me down! Machines making machines” – nie możemy tego powstrzymać, możemy tylko się dostosować. Ci, którzy zachowają swoją pracę to ludzie kreatywni, wymyślający jak zmienić i usprawnić świat, stąd hasło „zostań ikonoklastą”, jak Leo III i stań przeciw ogólnie przyjętym kanonom.
Ikonoklaści programiści:
- Alan Key,
- Linus Torvalds,
- Dave Thomas,
- Edward Djikstra,
- Robin Milner.
Co robi ikonoklasta :
- Myśl nieszablonowo (out-of-the-box)
- Dzieli się tym co robi, jest społecznie pozytywny (socialize, familiarity, recognition)
- Działa w różnych płaszczyznach
Mózg jest najciemniejsza żarówką w pokoju, pobiera raptem 40 wat. Nasz mózg operuje na skróty, żeby ograniczyć pobór mocy. Nasza percepcja w dużej mierze zależy od naszego dotychczasowego doświadczenia. Poniższy obrazek dla każdego informatyka będzie jednoznaczny ;-) dla pozostałych już mniej.
Tak, to jest widok uniwersalnej architektury każdego systemu w IT!
Starając się być kreatywnym trzeba pamiętać o tym jak działa nasz umysł i jakie są jego ograniczenia (np. paradoks ellsberga, podążanie za tłumem, czy wpływ emocji na podejmowanie decyzji).
Leading technical change (Nathaniel Schutta)
Nathaniel próbował odpowiedzieć na pytanie jak, kiedy i w jaki sposób wprowadzać zmiany technologiczne. Co powoduje, że potrzebujemy zmiany technologii? Nie możemy podążać za wszystkimi trendami, bo obecnie nie jest to możliwe, nie starczyłoby nam czasu. Kiedyś może mogliśmy pochłaniać wszelkie materiały. Teraz już nie da się, gdyż zbyt wiele stało się dostępnych. Zmianę trzeba planować, na zmianę trzeba wpływać. Z pomocą może przyjść radar technologiczny z ThoughtWorks.
Czasami jednak nie możemy przewalczyć zmiany… Dlatego to co możemy zrobić, to wykonać ją samemu i prosić o wybaczenie. Bardzo istotne jest jak sprzedajemy zmianę ludziom, którzy podejmują decyzję. Nathan wskazał stronę http://presentationpatterns.com/ dając wskazówkę jak przygotowywać prezentacje, tak by przekonać decydentów do podjęcia ryzyka zmiany.
Architecting for continuous delivery (Axel Fontaine)
Axel twórca FlyWayDB przedstawił w pigułce jak zaplanować architekturę wprowadzania zmiany oraz aplikacji tak by osiągnąć gotowość do tzw. Continious delivery i zero downtime.
Axel wskazał kilka technik :
- Nie deployuj snapshotów,
- Używaj skryptów instalacyjnych,
- Używaj automatycznej konfiguracji z autodetekcją środowiska,
- Dla aktualizacji bazy danych używaj odpowiedniego oprogramowania (np. liquibase lub flywaydb),
- Używaj przełaczania funkcjonalności
- Unikaj branchingu w VCS raczej przykrywaj dostarczane funkcjonalności
- Stosuj replikację sesji i przełączanie
- Pisz aplikację tak by zachować kompatybilność wsteczną bazy z aplikacją przynajmniej do wersji poprzedniej
Pragmatic architecture (Ted Neward)
Ted stwierdza, że to „czym jest architektura” jest trudne do zdefiniowania oraz stała się przedmiotem żartów. Każdy pamięta scenę z filmu Matrix, gdzie architekt przedstawiany jest jako starzec z białym garniturze, który mówi tak, żeby nikt inny go nie rozumiał. Często architektura to chmurka połączona z inną chmurką, która robi jakąś magię. Mówi również o tym, że architektura oprogramowania jest trudna do zrozumienia przez ludzi spoza IT, gdyż oprogramowanie oparte jest na abstrakcjach. Odpowiada, czym jest architektura i że nie można jej rozpatrywać bezkontekstowo (nie istnieje uniwersalny młotek…). Podaje przykłady z konstruktem fabryki np. w celu parsowania pliku excela, co praktycznie zdarza się rzadko, by ktoś chciał zmienić parser. Dalej pojawił się przykład JDBC, które daje możliwość podpięcia teoretycznie dowolnej bazy danych – chociaż jest to prawie niemożliwe, gdyż żadna baza nie wspiera w pełni jednego standardu (według Dana SQL92 nie jest w pełni wspierany przez żadną bazę danych używaną w systemach produkcyjnych).
… tak mniej więcej wyglądał dzień pierwszy konferencji. Nie udało się trafić na mocno techniczne sesje, a z tych które udało się odwiedzić wynika, że głównym tematem staje się szukanie głębszej prawdy, istoty informatyki i czegoś ponad technologię.
Ewolucja postępuje, a my płyniemy z nurtem…
Już niedługo relacja z kolejnego dnia. Nie wyłączajcie odbiorników.