33 degree 2012 dzień 1

Dzień 2
Dzień 3
Warsztat z Wujkiem Bobem

Konferencja 33 Degree 2012 zaczęła się od szybkiego 10minutowego przywitania o godzinie 9:10 przez organizatora Grześka Dudę. Potem było chwilę o platynowym sponsorze Luxoftcie i o 9:25 zaczęła się pierwsza prezentacja Raffi’ego Krikorian’a z Twittera. Opowiadał on o powodach migracji z Ruby on Rails do JVM’a.

Twitter posiada 100 Milionów użytkowników, którzy tworzą 250 Milionów twittów na dzień, co daje prawie 3000 tweetów na sekundę. Serwis ten cechuje ogromna liczba równoległych połączeń, wiele operacji I/O i nie wielka liczba obiektów trwałych. Twitter potrzebował więc wydajnego języka, do obsługi takiego obciążenia.

Początkowo serwis ten był pisany w Rubym. Sam język nie jest zły, pisze się w nim przyjemnie, szybko, jest bardzo ekspresywny. Słabym punktem są w nim garbage collector i wielowątkowość. Nie wiem jak działa zrównoleglanie w Ruby’im, ale według Raffiego nie dawało to rady, nawet na 60 rdzeniach.

Postanowiono wiec zmigrować kluczowe części systemu na wirtualna maszynę Javy. Początkowo wybór padł na Scalę. Jest ona funkcyjna, ekspresyjna, elastyczna, statycznie typowana i z dobrą współbieżnością. No i do tego jest piękna. Po za Scalą Twitter jeszcze używa Clojure’a. Było jeszcze coś wspomniane o bibliotece Finagle powstałej w Twitterze, ale nie pamiętam w jakim kontekście.

Ogółem prelegent fajnie gadał, chwilowo mikrofon nie dawał rady. Mi trochę brakowało więcej konkretów, jakie rozwiązania zostały zastosowane i co się gdzie sprawdziło. Z chęcią również bym zobaczył model bazodanowy. Było jedynie wspomniane, że dzieli się on na 4 części (Timeline storage, twitts, social graph i user storage).

Następny był wykład Ken’a Sipe pod tytułem Complexity of Complexity. Zdania na temat tego wykładu są podzielone, jednym się podobał, ale mi nie do końca. Generalnie głównym przesłaniem wykładu było to, że nie ma jednego rozwiązania dobrego do wszystkiego i należy poszukiwać najlepszej drogi.

Jak dla mnie to Ken za bardzo skakał po różnych tematach. Było o modelu dreyfus’a, CAP Theorem i jeszcze paru sprawach. Prelegent wspominał, że SOAP nie zawsze jest dobrym rozwiązaniem, gdy w danej infrastrukturze występują spore zależności pomiędzy komunikującymi się systemami. SOAP ładnie to na schemacie przedstawia, ludziom biznesu się to podoba, ale de facto te zależności dalej pozostają.

Był przykład z liczeniem: 2.0 – 1.1 (o tym więcej za chwilę), o adnotacji @Immutable z Groovi’ego i książce: Hackers & Painters. Oraz że eBay nie stosuje rozproszonych transakcji.

Podsumowując, to najważniejszy jest dobry zespół, język (z odpowiednim poziomem abstrakcji) i design aplikacji. Co do stosowanych języków, to powinny one być wygodne, łatwe, znane i proste do nauczenia przez świeże osoby w projekcie.

Następne było wystąpienie Venkat’a Subramaniam’a. Już jakiś czas temu byłem nakręcony na jego wystąpienia, gdyż były mocno wychwalane przez innych polskich blogerów (niestety nie pamiętam gdzie to czytałem). I rzeczywiście sposób prowadzenia prezentacji jest pierwszorzędny, istny majstersztyk. Prelegent zaprosił jedną osobę na scenę i czasem prowadził z nią dialog. Pytał, jak się czuje jako programista, czy odczuwa przyjemność z tego co robi.

Venkat mówił o „Pointy haired bosses” i pragmatycznych programistach. Czyli o zderzeniu dwóch światów: bezmyślnych szefów i programistów. Zastanawiałem się o co chodzi z tym pierwszym terminem, ale wystarczy spojrzeć na pewną postać z komiksów Dilberta: Pointy-haired Boss i już jest wszystko jasne.

Venkat opowiadał dalej o pewnych uniwersalnych prawdach. Porównywał managerów, do rekinów, z którymi musimy walczyć (niczym Janek Lisewski ostatnimi czasy). Ponadto najważniejsi w projekcie są... ludzie. Nie metodyki, technologie, a ludzie. Projekt nie wygrywa ze względu na proces a na ludzi. Aby wygrać ludzie muszą mieć pasję, kompetencję i odpowiedzialność.

Dwoma słowami jakich nienawidzi Venkat to „Best Practice”, jeżeli są one wypowiadane bez kontekstu. Jeśli jest inaczej to trzeba uciekać.

Następnie prelegent prezentował zabawne filmiki, o tym jak ludzie mogą wpływać na innych. Tłumaczył wpływ praktyk (przykład z szerokością silników rakietowych) i że zawsze powinniśmy pytać dlaczego. A do szefa to zamiast mówić, że „mamy problem”, to należy mówić, że „mamy wyzwanie”.

Venkat odwoływał się również do książek: Dreaming in Code i do The Paradox of Choice: Why More Is Less.

Prelegent mówił również, że standaryzacja rozwiązań przed innowacją, to zła droga. Najpierw należy coś wynaleźć, znaleźć kilka następnych, możliwych, ponownych zastosowań, dopiero ustandaryzować i na koniec sprzedawać. Niestety sporo rzeczy w świecie Javy nie idzie tym torem, gdyż często do danej specyfikacji (która powstawała latami), dopiero jest dopisywana implementacja. Jako przykład framework’ów, które szły tą lepszą ścieżką Venkant podał Rails’y i Spring’a.

Następnie zostały wytłumaczone różnice w językach programowania na podstawie wykresu podobnego jak poniżej.

Źródło: http://blogs.agilefaqs.com/2011/07/11/dynamic-typing-is-not-weak-typing/

Następnie było trochę praktyki, czyli ponownie lekcja liczenia. Proponuję każdemu odpalić i sprawdzić co się stanie (jeśli jeszcze ktoś nie wie).

System.out.println(2.0 - 1.1);
System.out.println(new BigDecimal(2.0).subtract(new BigDecimal(1.1)));
System.out.println(new BigDecimal("2.0").subtract(new BigDecimal("1.1")));

Przykładowo w Groovy’m mamy to za darmo.

W kolejnym przykładzie Venkant przedstawił bardziej interesujący kod:

ArrayList<Integer> numbers = new ArrayList<Integer>();
numbers.add(1);
numbers.add(2);
numbers.add(3);
numbers.remove(0);
System.out.println(numbers.size());

Podczas prezentacji dałem się nabrać i dziwiłem się z wyświetlanego wyniku. Dopiero pisząc tego posta zrozumiałem co się dzieje.

To  że Java jako język jest silnie typowany i ze statyczną kontrolą typów sprawia, że musimy się dostosowywać do kompilatora, np. poprzez deklarowanie w sygnaturze metody Checked Exceptions. Podsumowaniem całego wykładu była sentencja: „A Professional who doesn't learn to fail, fails to learn”. Let’s be a champions.

Po wykładzie był obiad, bardzo smaczny. Nieporównywalny z innymi konferencjami w których brałem udział.

Następna prezentacja na którą się udałem była o Dart’cie a przedstawiał ją pracownik Google’a, a dokładniej z Chrome’a: Mike West. Dart to nowopowstający opensource’owy język do budowania web aplikacji, kompilowany do JavaScript’u. Jest to dopiero technology preview, więc nie ma jeszcze nawet wersji alfa tego wynalazku.

Najciekawszy jest sposób powstawania języka. Mianowicie tęgie głowy wymyślają, co by tutaj dodać do języka, a społeczność dyskutuje na grupie o danej funkcjonalności i od tego zależy, czy pojawi się w języku czy nie.

Przeznaczeniem języka mają być małe i średnie aplikacje, niezależne od platformy, szeroko dystrybuowane i bez instalacji. Dart bazuje na HTML’u 5 i modelu DOM, ma być wsparcie dla testów jednostkowych. Przy języku pracuje sporo ludzi od GWT i język ma być bardziej popularny od CoffeeScript’a.

Na prezentacji było trochę kodu, ale ja osobiście jakoś się nie przekonałem i coś nie czuję aby to wypaliło. Jednakże model powstawania języka jest bardzo ciekawy. Co do samej prezentacji, to troszkę dziwna akustyka była w sali a i prelegent jakoś mało ciekawie przedstawiał temat.

Następna prezentacja była bardzo ciekawa. Andrey Breslav pracownik JetBrains’a przedstawił język Kotlin  (nazwa dokładnie taka jak polskie miasto i firma produkująca keczup). Prelegent obecnie pracuje przy tym wynalazku. Jakiś czas temu widziałem informacje o tym języku, ale się nie przyglądałem bliżej.

Język jest statycznie typowany, ogólnego przeznaczenia, open source’owy i do zastosowań przemysłowych. Kompilowany jest on do bytekodu JVM’a lub do JavaScriptu, tyle że wówczas nie można używać wszystkich bibliotek.

Ciekawa jest motywacja firmy do tworzenia kolejnego języka. JetBrains tworzy aktualnie środowiska programistyczne (IDE) dla 7 języków. Wiodącym jest to dla Javy, ale Java rozwija się bardzo powoli w stosunku do IDEI. Jako że inne języki wspierają produkty tej firmy, to postanowiono wesprzeć samego siebie. I tak oto powstaje język eliminujący niedoskonałości Javy, mający od razu wsparcie IDE do tworzenia kodu. Ponadto można bezproblemowo mieszać kod Kotlina i Javy w projekcie i nawet debugować w jednym IDE. To sprawia, że integracja i ewentualna migracja może być bezbolesna. I jest również dostępne wsparcie dla podpowiadania składni, refaktoringu itd.

Kotlin nie jest research’owym projektem, ani nie jest pod specyficzną domenę, czy może raczej pod specyficzne zastosowanie. Zanim kolejna wersja języka wyjdzie, to jest ona używana na produkcji w JetBrains. Są już nawet jakieś zewnętrzne firmy, które wykorzystują ten język.

Co do samego języka: Nie ma słowa kluczowego new, argumenty przekazywane do konstruktora są od razu zapisywane jako pola klasy, są extension functions, przeciążanie operatorów matematycznych i nie tylko, wyjątki tylko unchecked, operacje bezpieczne na występowanie null’a, inne rzutowanie pozwalające pozbyć się javowego rzutowania i switch’a, Trait’y czyli interfejsy z domyślną implementacją, a adnotacjom można nadać coś jakby alias i później używać w kodzie, co eliminuje znak ‘@’. Mają być również zaimplementowane Run-time generics.

Z ciekawostek, to kod jest kompilowany do modułów, a nie do pojedynczych plików jak w Javie, przez co można lepszą optymalizację kodu wykonać. Kto chce to może się dołączyć do Community i trochę porozwijać język.

Prezentacja była bardzo ciekawie prowadzona. Były filmiki pokazujące jak kodować (opatrzone w razie potrzeby odpowiednim komentarzem prowadzącego). I jak całość działa. Był po raz drugi przykład a odejmowaniem (2.0 – 1.1) z którym Kotlin radzi sobie podobnie jak Groovy (czyli lepiej niż Java). Prezentacja bardzo mi się podobała i uważam, że język może być ciekawą alternatywą w niedalekiej przyszłości dla Javy. Nie wiem dokładniej jak się to ma do innych obecnie coraz popularniejszych języków jak Scala, Groovy, Ruby, ale przyjrzę się jemu bliżej niedługo. Na stronie JetBrains’a można sobie przeczytać porównanie do Javy lub Scali. Widać, że język sporo czerpie inspiracji ze Scali i Grooviego. Można się jeszcze „na żywo” pobawić językiem nie instalując żadnych aplikacji wchodząc na stronę kotlin-demo.

Następnie wybrałem się na prezentację o testach którą prowadził Wojciech Seliga. Opowiadał on o swoich 10 latach testowania przy tworzeniu oprogramowania JIRA. W początkowej części prezentacji było sporo danych statystycznych, wykresów itp. I tak projekt ma: około 500 zależności, 1.5 miliona LOC, 13 tysięcy testów jednostkowych, 1000 testów z Selenium, 4000 funkcjonalnych i integracyjnych, pokrycie kodu testami na poziomie 60-80% do ~92% dla krytycznych funkcjonalności…

Wszystko to jest kompilowane i odpalane na ponad 70 maszynach w chmurze Amazona. Jednak i tak trwa to bardzo długo, a poprawa testów jeszcze dłużej, przez co zaczął się pojawiać u nich w projekcie syndrom wybitego okna. Po pewnym czasie, aby developerom wróciło zaufanie do testów, zaczęto komentować (a z czasem usuwać gdy nie szło naprawić) te testy, które za długo były czerwone – ale nie profesjonalne zachowanie.

Co do ciekawych praktyk, to dowiedziałem się o Page Object Pattern co mocno ułatwia testowanie i jest niezależne od zmian w GUI. A jeżeli już chcemy testować po GUI, to lepiej skorzystać z JQuery Selectors niż z XPatch i/lub używać ID’ków zamiast CSS’a. Dobre jest również podzielenie kodu testowego na moduły, które znajdują się w miarę blisko kodu źródłowego. Pozwala to developerom odpalać testy dotyczące danego modułu, zamiast testów dla całego systemu. Przydatne również może być mockowanie zewnętrznych systemów.

I to by było tyle jeśli chodzi o tą prezentację. Ja spodziewałem się dowiedzieć czegoś więcej, tzn. oczekiwałem przykładów, dobrych rozwiązań, stosowanych wzorców, technik, ciekawych wniosków. Jak na kogoś kto ma dziesięcioletni kontakt z testami, to wypadło bardzo słabo.

Po wykładzie chciałem iść jeszcze na sesję BOF, ale skończyło się na tym, że zacząłem rozmawiać z ludźmi na korytarzu i dołączyłem do imprezy piwnej sponsorowanej przez ZeroTurnaround wydawcę JRebel’a Bardzo mi się spodobała taka forma integracji i możliwości nawiązania kontaktów.

Podsumowanie kolejnych dni w kolejnych wpisach.