Devoxx w Polsce - wrażenia z pierwszej edycji

Pierwszy Devoxx w Polsce (dawniej 33 Degree) odbył się w dniach 22-24 czerwca 2015, w nowo wybudowanym centrum kongresowym w Krakowie, mogącym pomieścić ponad 2000 ludzi. I to było idealne miejsce na konferencję - nowy, ładny i przestronny budynek z ogromną salą z balkonami na trzech poziomach, gdzie mogli zmieścić się wszyscy uczestnicy.

Konferencję otworzył standardowo Grzesiek Duda. W trakcie rozpoczęcia miała być krótka prezentacja Vaadin Designer’a, ale niestety był problem z połączeniem laptopa do rzutnika. Z racji ograniczonego czasu, trzeba było uwierzyć na słowo, że narzędzie jest fajne.

Pierwszy keynote poprowadził Hadi Hariri: "The Silver Bullet Syndrome". Opowiadał o tym, w jaki sposób szukamy rozwiązania starych problemów, czyli o wynajdowaniu koła na nowo, aby było bardziej okrągłe. I tak z make’a przerzuciliśmy się na ant’a, później maven’a i gradle’a… Poszukujemy idealnego rozwiązania, najlepiej naszych wszystkich problemów, czyli tytułowego silver bullet. Powoduje to następujący "cykl przetrwania w IT": nowa technologia -> wciśnięcie jej użytkownikom -> organizowanie szkoleń -> użycie na produkcji -> jak coś nie działa, to telefon do konsultanta i tak w kółko od nowa.

Hadi wyśmiewał jeszcze inne potworki jakie tworzymy, np.: AbstractSingletonProxyFactoryBean, FizzBuzzEnterpriseEdition i JavaScript:

Tak naprawdę, to powinniśmy zadać sobie pytanie, jaką to nam przyniosło wartość biznesową? Jak usprawniliśmy czyjąś pracę lub życie, a nie wymyślamy kolejne frameworki. Nasze CV powinno więc wyglądać raczej tak:

(Sorry za kiepską jakość...) 

Ostatecznie stanęło na tym, że jednak musimy ciągle uczyć się nowych rzeczy. Nagranie z prezentacji (ale nie z Devoxxa) jest dostępne na Vimeo: https://vimeo.com/130202574, a starszą wersję slajdów znalazłem tutaj: http://schd.ws/hosted_files/buildstuff14/a5/wcf.pdf

Pierwszą prezentacją po keynote na którą poszedłem było: "Principles Of Microservices", Sama Newmana. Było o The Twelve Factors, czyli o zebranych zasadach z doświadczeń, jak pisać aplikacje, które są deploy'owane w dużych ilościach, aby było łatwiej nimi zarządzać i utrzymywać.

Z rozwiązań, które warto zapisać (i może kiedyś im się w razie konieczności lub nadmiaru wolnego czasu przyjrzeć) to:

• Pact - biblioteka do testowania i definiowania kontraktów pomiędzy mikroserwisami (czyli: Consumer driven contracts) 
• ZooKeeper - do ogarnięcia utrzymania, konfiguracji itp. wielu rozproszonych systemów 
• etcd - rozproszona konfiguracja dla wielu serwisów 
• Consul - to samo (albo prawie to samo co dwa powyższe)

Sam na prezentacji przedstawił 8 zasad mikroserwisów i je wyjaśnił:

• Modelled Around Business Domain 
• Culture Of Automation 
• Hide Implementation Details 
• Decentralise All The Things 
• Deploy Independently 
• Consumer First 
• Isolate Failure 
• Highly Observable 

Najbardziej mi utkwiło w pamięci, że trzeba mieć jedną osobę, która patrzy na aplikację i co się w niej dzieje, korzysta z kibany i stosując correlation id, śledzi, co dokładnie się dzieje z danym request’em i gdzie najwięcej czasu spędza. A tutaj jakaś starsza wersja slajdów z XP Days Ukraine

Następnie pospieszyłem na "OnConnectionLost: The life of an offline web application", prowadzoną przez młodych pracowników z ThoughtWorks: Stefanie Grewenig i Johannesa Thönesa. Prelegenci tworzyli aplikacje, które musiały działać w przeglądarce i również off-line. Przykładowo aplikacja na tableta dla pracownika supermarketu, który sprawdza dostępność produktów na półkach i zamawia co trzeba. Dawniej korzystano z kartek do tego celu, ale można pójść z duchem czasu i zrobić to lepiej. Połączenie z internetem bardzo łatwo zgubić na sklepie, a zamówienie trzeba złożyć, więc warto w takim przypadku, aby aplikacja działała offline.

I tak za pomocą html5 application cache możemy zdefiniować, które zasoby powinny zostać zapamiętane po stronie przeglądarki, do działania w trybie offline. Mamy również możliwość, wymuszenia aktualizacji tych zasobów, gdy pojawią się ich nowsze wersje na serwerze. Najważniejsze, aby manifest, w którym definiujemy co ma być cachowane, sam nie został zcache'owany. W tym celu warto ustawić w nagłówkach no chache. Alternatywą dla application cache jest Service Workers, ale póki co jest to googlowy wynalazek, zaimplementowany tylko w Chromie i FF.

Jeśli chodzi o przechowywanie wprowadzonych danych offline, to mamy Web Storage i IndexedDB. W pierwszym rozwiązaniu jest sporo problemów (między innymi jak użytkownik chce otworzyć wiele zakładek naszej aplikacji) i prelegenci zalecali drugie rozwiązanie. Oferuje ono transakcyjność pomiędzy wieloma zakładkami. Niestety obecnie jest ono wspierane tylko w Chrome.

Ostatnim problemem, jaki jest do rozwiązania przy aplikacjach działających w przeglądarkach off-line, to synchronizacja danych. Warto korzystać od samego początku ze wzorca Command, czyli wszelkie zmiany, jakie wykonuje użytkownik wrzucamy do lokalnej kolejki i jak stanie się online, to je dopiero przetwarzamy na serwerze. Ewentualnie, aby nie mieć jakiś problemów z łączeniem wyników, to możemy zapisać snapshot’a aktualnego wyniku. Nie warto się spalać nad rozwiązywaniem konfliktów (o ile nie piszemy gita przez przeglądarkę), a w najgorszym wypadku możemy wyświetlić dwie wersje dokumentu i użytkownik skopiuje sobie to, co mu brakuje do nowszej wersji.

Z dalszych rad - danych wrażliwych nie powinniśmy zapisywać w przeglądarce, bo są one dostępne jawnym tekstem, a sama enkrypcja po stronie JavaScriptu może nie być najlepsza. I jeżeli decydujemy się na budowanie aplikacji działającej bez połączenia z internetami, to w pierwszej kolejności powinniśmy zadbać o działanie bez serwera i wprowadzenie wzorca Command zamiast requestów. W innym wypadku bardzo zemści się to na nas w późniejszym czasie. Slajdy można obejrzeć tutaj: http://www.slideshare.net/jthoenes/onconnectionlost-the-life-of-an-offline-web-application-craft-conf-2015

Kolejne wystąpienie pt.: "Co było pierwsze: kod czy architektura?" Sławka Sobótki rozpoczęło się od poziomów cywilizacji wg. Skali Kardaszewa, aby zachęcić słuchaczy do aktywnego słuchania. I to się z pewnością Sławkowi udało. Prelegent „zajrzał” na chwilę do umysłu programisty i architekta. Ten pierwszy w przypadku problemu wyboru rozwiązania A i B próbuje wybrać lepsze. Architekt w takim przypadku robi krok wstecz, patrzy z dalszej perspektywy i zastanawia się, czemu w ogóle mamy wybór i czy rzeczywiście musimy wybierać.

Następnie przyglądaliśmy się różnym rodzajom obrazków, jakie malują architekci, aby przejść do tego, jak je malować. Dobry podział tych obrazków jest zebrany w książce Software Architecture for Developers, a mianowicie C4:

• Context - czyli architektura korporacyjna. Pokazujemy na niej osoby korzystające z systemu, inne zależne systemy i instytucje. Odbiorcami taki obrazów są klienci i zarząd. 
• Containers - architektura wdrożenia. Tutaj mamy wszelkie techniczne zależne elementy, jak bazy danych, kolejki komunikatów, repozytoria, bazy danych, kontenery, klienci (w sensie przeglądarka, aplikacja na telefon). Jest to przydatny diagram dla administratorów, utrzymaniowców i DevOpsów. 
• Components - czyli architektura systemu. Obrazek ten pokazuje komponenty / moduły (jakkolwiek sobie zdefiniujemy czym to dokładnie jest). Jest to przydatne dla programistów, dając obraz z lotu ptaka na aplikację 
• Classes - architektura aplikacji, pokazująca wewnętrzną strukturę dokumentu, bardziej wzorce niż konkretne klasy 

Jak prezentacja Sławka będzie dostępna on-line to umieszczę tutaj odpowiednie zdjęcia.

Z praktycznych rzeczy to zapamiętałem (albo raczej sobie zapisałem) jeszcze parę rad. Jeśli korzystamy z RESTa, to powinniśmy mieć teoretycznie tylko nazwy zasobów w adresach URL. Jednak praktycznie, to warto rozważyć, co częściej się nam zmienia: zasoby czy procesy? Gdy zasoby są w systemie stabilne, to robimy RESTfull, a jak procesy to do RESTa wrzucamy czasowniki.

Connascence oznacza, że jak coś zmieniamy w jednym miejscu w systemie, to musimy to również zmienić w drugim miejscu. Przykładowo mikroserwisy nie powinny korzystać z bibliotek współdzielonych. I dodatkowo powinniśmy rozdzielać pojęcia w systemie, aby lepiej nam się rozdzielało komponenty systemu.

W ten sposób zostało przedstawione, jak tworzenie dużej architektury od początku prowadzi do kodu. Następnie Sławek spróbował pokazać podejście odwrotne, tzn. jak z naszych mikrodecyzji na poziomie kodu wyłania się nasza architektura.

Podsumowując, nie wiadomo który framework jest lepszy, ani który język programowania. Programowanie to dyscyplina polegająca na zmyślaniu - faktura to funkcja, albo faktura to obiekt… A tak to wszyscy powinniśmy się nauczyć assemblera, aby wiedzieć jak działa krzem, aby przestać toczyć wojny religijne, o to który język programowania jest lepszy...

Następnie byłem chwilę na wykładzie "Using JavaScript/HTML5 Rich Clients with Java EE 7", Reza Rahmana, ale musiałem wyjść. W sumie dobrze, bo z późniejszych opinii było nieciekawie, głównie historia, jak to przez lata próbowano ożenić frontend z backendem.

Poszedłem więc na: "Technical leadership – from an expert to a leader", Mariusza Sieraczkiewicza. Nie widziałem początku, ale prelegent mówił o tym, że dobry leader powinien przygotować takie środowisko, że każdy będzie chciał w nim pracować. Następnie było o rzeczach, których każdy powinien spróbować: więcej myśleć niż tylko reagować, robić sobie codzienną retrospektywę, zrozumieć, a nie oceniać - coaching. Aby móc lepiej motywować ludzi, to powinniśmy ich lepiej poznać, jakie są ich potrzeby i zbierać feedback, a w Agile jest pełno narzędzi związanych z feedbackiem.

Na koniec Mariusz ogłosił, że pisze książkę na ten temat i szuka chętnych chcących podzielić się z nim swoimi doświadczeniami. Kontakt można znaleźć na jego blogu: http://msieraczkiewicz.blogspot.com/

Przedostatnią prezentacją pierwszego dnia konferencji była: "Caching reboot: javax.cache & Ehcache 3" prowadzona przez Louis Jacomet. Początkowo prowadzący omówił, co ile czasu zabiera, jak przeskalujemy czas pewnych operacji komputera na bardziej ludzkie, odczuwalne i zrozumiałe jednostki. Miało to na celu uświadomienie sobie, że naprawdę potrzebujemy cache w aplikacji. Następnie było o zmianach w EhCache w wersji 3 w stosunku do wersji 2. Mianowicie Java doczekała się ustandaryzowanego Caching API ujawniającego się pod numerem JSR-107. I nowa wersja EhCache’a implementuje tą specyfikację, przez co wsteczna kompatybilność została złamana.

W standardzie JSR-107 nie ma zdefiniowanych ustawień dla Capacity control, ani Locking Options. Dalej było demo, jak łatwo można korzystać z EhCache. Jest możliwość modyfikowania ustawień w trakcie działania aplikacji. Problemem jest jedynie odpowiednia konfiguracja, a mianowicie dobranie odpowiednich wartości. Jedyne co prowadzący mógł polecić, to pójście na produkcję i obserwowanie zachowania. Największym wyzwaniem przy implementacji EhCache’a jest założenie, że błąd w cache’u nie powinien skutkować wyjątkiem do użytkownika (aplikacji). Prezentacja całkiem fajna.

Na końcu dnia poszedłem na prezentację Adama Warskiego pt. "Supler: complex web forms, not so complex". Adam jak zwykle w wielkim stylu przedstawił rozwiązanie, które stworzył wraz z zespołem w SoftwareMill’u. Supler jest narzędziem, które spaja frontend w JavaScripcie z backendem Scalowym. Pomaga generować formularze (nawet zagnieżdżone i skomplikowane), a jednocześnie nie jest związany z żadnym frameworkiem. Było przez cały czas live demo i niewiele slajdów. Trochę mi umknęło jak ożenić to rozwiązanie z jakimś frejmworkiem JS. Gdybym musiał tworzyć formularze w Scali, to z pewnością bym pozytywnie rozważył użycie Suplera w projekcie.

Podsumowując pierwszy dzień konferencji, to trzymał poziom, ale czegoś mi zabrakło. Początkowy wykład był mocno motywujący i dający do myślenia, Sławek Sobótka bardzo fajnie opowiedział o malowaniu architektury, ale to było bardzo miękkie. O EhCache i Suplerze była całkiem niezła, ale tego drugiego raczej nie będę mógł zastosować praktycznie w najbliższym czasie. Zabrakło mi trochę jakiejś mocno technicznej prezentacji na temat czegoś nowego, świeżego, lub wywracającego myślenie do góry nogami.

Voxxed Days Vienna 15

Ledwo zakończył się ChamberConf, a tu już czas na Voxxed Days Vienna 15. Była to moja pierwsza zagraniczna konferencja, nie licząc Code Retreatów. Wejściówkę wygrałem w losowaniu, więc czemu by nie pojechać? W końcu z Wrocławia do Wiednia jedzie się tak długo, jak jeszcze całkiem niedawno jechało się do Warszawy.

Konferencję otworzył Greg Young z tematem Polyglot Data. Była to powtórka z Wrocławia, między innymi opowieść o programiście, co zbamałucił system obstawiania wyścigów konnych i jak można było się przed tym zabezpieczyć.

Następnie byłem na prezentacji Norberto Leite - ewangelisty z MongoDB - pt. Operational Database with Elephant Memory. Początkowo było dużo marketingowego gadania, jak to CTO, CIO, CSO i inni C* widzą bazy danych. Było bardzo dużo odniesień do wcześniejszego wystąpienia Greg'a, który trochę jechał po Mongo DB. Według Norberto, ssie ta baza danych, którą akurat używamy.

Dalej były podstawy Hadoopa (HDFS, YARN, MapReduce) oraz o Pig, Hive, Sparku, jakie są drivery do Mongo, z czym można się integrować... Miało być demo, ale nic konkretnego w końcu nie było. Merytorycznie bardzo słabo.

Później byłem chwilę na wystąpieniu Michaela Nitschingera, ale przeniosłem się na Monadic Java prowadzone przez Mario Fusco. I na początek zobaczyłem te wzory

Tak naprawdę, to monady ukrywają if'a w metodzie, dzięki czemu możemy ładniej, funkcyjnie zapisywać nasz kod. Był pokazany przykład, jak można zrobić dzięki monadom walidację obiektów, a za zadanie domowe, Mario zadał, aby napisać system transakcyjny, z wykorzystaniem monad rzecz jasna.

Prelegent jest współorganizatorem Voxxed Days Ticino. Zastanawialiśmy się w przerwie gdzie to jest (Google Maps lokalizowało Ticino w Szwajcarii i we Włoszech), ale w końcu okazało się, że chodzi o włoski region w Szwajcarii. 

Później był obiad i tu spore zaskoczenie. Część jedzenia przyjechała z Polski.

W końcu Grzesiek Duda był organizatorem tej konferencji i pewnie wychodziło taniej w ten sposób. Część napoi też przebyła sporą drogę.

Kolejny slot był słaby, odwiedziłem wszystkie sale, ale nic ciekawego nie znalazłem.

Później była druga prezentacja Grega Younga, który w zastępstwie kontynuował poranny wykład. Było m.in. o tym aby nie ufać benchmarkom, że często dane z nich przekraczają fizyczne możliwości urządzeń.

Kolejna prezentacja była Sergeya Kuksenko, który to na co dzień pracuje w Oracle i zajmuje się performance'm Javy. Mimo developerskiego charakteru jego pracy, musiał oczywiście pojawić się disclaimer na początku. 

Wykład było mało praktyczny, ale bardzo ciekawy. Było o wydajności Javy, ale na poziomie procesora. Sporo rzeczy przypomniało mi się z architektury komputerów ze studiów. Kod z przykładów jest dostępny tutaj: kuksenko/quantum, a slajdy poniżej.

"Quantum" Performance Effects from Sergey Kuksenko

Ostatni wykład był Christophera Bateya o microservisach. Prelegent przedstawiał, jak to on w projekcie zbudował system, będąc świadomym problemów wynikających z rozproszenia aplikacji. Jednak wszelakie przypadki, że część systemu nie działa, albo są lagi na sieci miał przetestowane.

I tak do symulowania problemów z siecią korzystali z saboteur, a do mockowania web serwisów WireMock. Spore streszczenie prezentacji Christophera można znaleźć na jego blogu: Building fault tolerant services: Do you handle timeouts correctly?

Sama prezentacja nie była jakaś fajna, czegoś w niej brakowało...

Na koniec było jeszcze piwo sponsorowane prze TypeSafe. Niestety nie mogłem zostać za długo, ale z tego co wiem, to impreza trwała długo.

Co do samej imprezy, to miała  ona na celu rozruszanie lokalnej społeczności. Merytorycznie daleko jej było do tych najlepszych konferencji - była to typowa lokalna inicjatywa, która jak na pierwszy raz wyszła całkiem spoko.

ChamberConf wrażenia jako organizator, prelegent i uczestnik w jednym

W końcu się zebrałem, aby napisać relację z ChamberConf. Była to pierwsza konferencja organizowana przez Wrocławski JUG. Sam również po raz pierwszy miałem okazję uczestniczyć w organizacji takiego wydarzenia. Ostatnie 2 tygodnie przed wydarzeniem do łatwych nie należały...

Z założenia konferencja miała być bez sponsorów, czyli bez wszelakich konkursów, stoisk, prezentów itp. Początkowo konferencja była planowana na 65 osób, ale ostatecznie wyszło 80. Miejsce było niezwykłe, bo to były psychiatryk (gdzieś niedaleko jest jeszcze działający oddział), a jednocześnie bardzo ładny zamek, z dala od wielkich miast i cywilizacji. Konferencja trwała dwa dni, ale sporo osób przyjechało już w piątek wieczorem, więc nieoficjalnie zaczęło się trochę wcześniej.

Na pierwszej prezentacji w sobotę Tomka Borka i Jacka Jagieły pt. To nie zawsze wina aplikacji, robiłem za pilot do przełączania slajdów, ponieważ żaden wskaźnik nie chciał akurat współpracować z Ubuntu. Slajdy można sobie przejrzeć na prezi.com, jak i na slideshare. Z prezentacji wynikało, że należy pamiętać o monitoringu aplikacji i infrastruktury, bo często problemy z wydajnością nie leżą w naszym kodzie. Fajne było zadawanie pytań na koniec przez prelegentów do publiczności, czyli w odwrotnym kierunku niż zwykle.

Następnie Adam Warski opowiadał o Reactive Manifesto z użyciem Akki. Było trochę wstępu teoretycznego i sporo kodowania na żywo. Występ się trochę przedłużył, ale zależało nam na tym, aby konferencja nie miała sztywnych ram.

Następnie Konrad Malawski opowiadał o algorytmach głosowania w sieci. Było m.in. o Paxosie (którego prawie nikt nie rozumie), jak i jego uproszczonych wersjach. Początkowo bałem się, że to będzie prezentacja czysto akademicka, ale koniec końców okazało się, że bodajże raft consesus jest gdzieś tam w Akkce zaimplementowany.

Następnie był obiad i ostania prezentacja pierwszego dnia, Michała Bartyzela pt. Z czym mierzą się zespoły? Michał opowiadał sporo swoich doświadczeń i trudności jakie spotykamy w naszej pracy, oraz jak zmieniał się jego światopogląd na przestrzeni lat.

Następnie było unconference, czyli coś co nie wiedzieliśmy czy się uda czy nie. Ale wychodzi na to że się udało. Było sporo pytań do Konrada, rozmów o pracy zdalnej, CQRSie i inne, a to wszystko w luźnej atmosferze. Później całość się przeniosła na kolację i dalsze rozmowy z ludźmi zwłaszcza nowopoznanymi.

Drugi dzień rozpocząłem od zapowiadanego morsowania. Niestety nikt chętny się nie zgłosił, chociaż o 2:00 w nocy ktoś się podobno deklarował. Może za mało przypominałem uczestnikom o tym temacie...

Drugiego dnia udałem się na Archi-Katę do Tomka Borko. Warsztat był na kartkach bez użycia komputerów, ale zmuszał do sporego myślenia, a później dyskusji i oceniania prac innych. Bardzo fajny warsztat.

Równolegle do warsztatów była ścieżka z prezentacjami. Tam frekwencja była mniejsza, ale podobno bardzo sprzyjało to żywej dyskusji.

Po przerwie obiadowej sam prowadziłem warsztaty. Jak się okazało, był to jedyny temat związany z Java, gdyż inne były o Scali, architekturze lub miękkie. Chyba trzeba będzie zmienić Java User Group na JVM User Group. Warsztat był rozszerzoną powtórką z Warsjawy. Sam na początku warsztatu się czegoś nowego nauczyłem, a mianowicie poznałem: Presentation Assistant, dzięki któremu można było wyświetlać wciskane skróty na ekranie. Kiedyś jak szukałem takiego narzędzie pod windę, to każde okazywało się jakieś kiepskie. A wspomniany plugin pokazywał skróty w wersji na Winde i Mac'a.

Implementowaliśmy ten sam problem co na Warsjawie, czyli StringCalculator. I jak doszliśmy do wydarzeń regularnych, to znów zaczeły się schody. Okazje się, że jak "ma się jakiś problem, który rozwiązujemy za pomocą regexpa, to de facto rozwiązujemy dwa problemy". Jakoś w końcu udało się wybrnąć z tego, ale nie było łatwo. Sam kilka dni przed konferencją zaimplementowałem problem, rozwiązanie (pewnie nieidealne) dostępne na githubie: mstachniuk/StringCalculatorKata. A slajdy poniżej:

Szkoda tylko, że nie wszyscy uczestnicy dotrwali do końca, ale wiadomo - niedziela i trzeba było wrócić z tego końca świata do domu. Mój warsztat trochę się przedłużył, ale to ze względu na masę pytań. Na koniec było czuć zmęczenie, ale i zadowolenie.

Podsumowując konferencję wypadła bardzo dobrze. Pierwszy dzień był mocny i miał służyć owocnym rozmowom podczas unconference. Ten cel został osiągnięty. Drugi dzień wypadł już trochę słabiej, więc pewnie można coś w nim poprawić. Można to ewentualnie tłumaczyć znakomitym pierwszym dniem. Mam nadzieję do zobaczenia za rok!

Duplikowanie bloku kodu w IntelliJ Idea

Dzisiaj mam do zaprezentowania mały lifehack w IntelliJ Idea. Wyszło to podczas przygotowywania (a raczej odświeżania) mojego warsztatu na konferencję ChamberConf'15, której też jestem współorganizatorem (wraz z ekipą z Wrocławskiego JUGa).

Otóż gdy się przesiadałem (dawno dawno temu) z Eclipse'a do Idei, to z początku denerwował mnie sposób duplikowania linii w kodzie. Ale nie o sam skrót klawiaturowy mi chodzi (Ctrl + D który to w starym środowisku usuwał linię), a o sposób duplikowania zaznaczonego kodu. A działa to tak:

Wiem, że mógłbym szybciej zaznaczyć dany fragment za pomocą Ctrl + W, ale wówczas efekt końcowy jest mniej zauważalny.

Generalnie powielany fragment kodu jest wstawiany zaraz za zaznaczeniem. Kiedyś bardzo mnie to denerwowało ale z czasem się przyzwyczaiłem i jakoś z tym żyłem. Ale dzisiaj rano znów zaczęło mnie to irytować... Zacząłem przeglądać YouTrack dla Idei i pogrzebałem trochę w ustawieniach.

Jak patrzymy na mapowanie klawiszy to mamy "Duplicate Line or Block" jak i "Duplicate Lines". Pod pierwszą pozycję jest podpięty skrót Ctrl + D. Gdy go stamtąd usuniemy i użyjemy w drugiej opcji, to otrzymamy ostrzeżenie o konflikcie:

Klikamy na "Leave" i uzyskujemy poniższy efekt działania Ctrl + D:

Jak widać, ten sam (tak samo zaznaczony) fragment kodu, po wciśnięciu magicznej kombinacji, wstawia się w nowej linii!

Mam nadzieję, że ten prosty wpis się spodobał. Jak chcesz poznać więcej trików, to zapraszam na wspomnianą już konferencję: ChambeConf'15, lub odezwij się bezpośrednio do mnie.

Warsjawa 2014 podsumowanie nr 2 i dawanie feeedback’u

W moim przedostatnim wpisie: Warsjawa 2014, czyli ja jako prowadzący 2 warsztaty umieściłem materiały z których korzystałem podczas tych warsztatów i opisałem swoje pierwsze wrażenia. Teraz czas na kolejną ostatnią część podsumowania, ponieważ już jakiś czas temu spłynęły do mnie wyniki ankiety przeprowadzonej przez organizatorów. A jest się czym pochwalić :-D Poniżej zamieszczam fragmenty korespondencji, którą otrzymałem od organizatorów.

Odnośnie Upiększ swoje testy. Testowanie jednostkowe dla średnio zaawansowanych

Your workshop was among best workshops of Warsjawa 2014! 

Here comes the results: 

number of feedbacks: 8 

average grade (1 to 5, higher is better): 4.63 

feedback comments: 

- A lot of knowledge presented, but a bit too fast. 

- Bardzo fajne i przydatne warsztaty - fajnie zorganizowane 

- Z warsztatów jestem bardzo zadowolony. Poznałem nowe, lepsze metody testowania, których mam nadzieje użyć w codziennej pracy. Projekt na githubie znacznie ułatwił cala sprawę. Dziękuje :) 

- Workshop was as described. From a begginer point of view approach : from simplest libraries to most helpful was realy good.

Co to dla mnie oznacza? Że dostałem 5 głosów z oceną 5 i 3 z oceną 4, lub jakiś inny wariant dający sumę 37. Przy ośmiu głosach daje to właśnie oceną 4.63 (a dokładniej 4.625). Bardzo się cieszę tak wysoką oceną, która w tym momencie trochę rekompensuje ogrom trudu włożonego w przygotowanie tegoż warsztatu.

Odnośnie Poznaj lepiej swoje środowisko programistyczne i zwiększ swoją produktywność z IntelliJ Idea

Here comes the results: 

number of feedbacks: 6 

average grade (1 to 5, higher is better): 4.5 

feedback comments: 

- Prawdziwe warsztaty, bardzo ciekawie poprowadzone na konkretnym przykładzie. Nie mam do nich żadnych uwag. 

- Miałem iść na C/C++ in Android Apps. Jednak mnogość instalowania narzędzi zniechęciła mnie (była sobota 16:00)... dosłownie na 1 minutę przed startem warsztatu przyszedłem tutaj. I nie żałuje. Skrótów wszystkich nie zapamiętałem, ale wiem dokładnie co można za ich pomocą osiągnąć. Formuła warsztatu wymagała ciągłego zaangażowania oraz umożliwiała świetną zabawę w poprawienie kodu kogoś innego :) Prelegent bardzo pozytywnie nastawiony do życia i moim zdaniem niezły kozak jeżeli chodzi o Intelli :) 

- Very good workshop, I learned a lot about the Intellij Idea.

Tutaj ocena nie jest już tak wysoka, ale i tak jest dobrze. Zwłaszcza że warsztat był w sobotę pod koniec dnia i większość już pewnie myślała o wieczornym piwie. Bardzo mnie tutaj ucieszyła druga opisowa opinia jednego z uczestników. Dzięki - kimkolwiek jesteś.

Podczas analizowania feedbacku od uczestników moich warsztatów naszły mnie jednak smutne przemyślenia. Ludzie bardzo niechętnie dają opinię zwrotną drugiej osobie! Trzeba się o nią wręcz dopraszać i ciągnąć za język. Szkoda, że system głosowania na Warsjawie nie zadziałał, bo on mógłby dać trochę szerszy obraz oceny warsztatu. A tak, to ankietę pokonferencyjną – jak widać powyżej – mało komu chce się wypełnić. Nie wiem czy to wynika z naszej introwertycznej natury, nieśmiałości, poprawności politycznej, czy z problemu z wyrażaniem swoich odczuć? Przecież na co dzień przekzujemy dalej swoje opinie na temat kodu naszych współtowarzyszy projektu. Przecież robicie Code Review? A może nie?

W każdym bądź razie prelegenci, czy też prowadzący warsztaty – zwłaszcza Ci poczatkujący – oczekują jakiejś zwrotnej opinii na temat swojej pracy! Wierzę w możliwość ciągłego udoskonalenia się i poprawiania swoich zdolności, aby kolejnym razem wypaść lepiej.

W jaki sposób wiec najlepiej zbierać konstruktywne opinie o sobie i swojej pracy? Jak masz jakieś pomysły to koniecznie pisz w komentarzach!

Chcę jeszcze dokonać publicznej konstruktywnej samooceny (aby dać przykład, jakie potknięcia warto wytykać) i napisać, co poszło mi nie tak na moich warsztatach, aby następnym razem nie popełnić tego samego błędu. Na pierwszym warsztacie zapomniałem puścić powitalny filmiki od organizatorów. Niestety, ale tuż przed samymi warsztatami musiałem trochę pozmieniać bazę w git’cie (mam na myśli rebase, ale nie mam pojęcia jak to można na polski przetłumaczyć), aby historia na publicznym repo nie wyglądała później tak:

After reabse of 12 branches on master in #git pic.twitter.com/cQDWtdEtDJ
— Marcin Stachniuk (@MarcinStachniuk) September 22, 2014

Z tego względu gdzieś mi umknęła wiadomość od organizatorów, prosząca o puszczenie filmików. Sory!

Co do drugiego warsztatu, to trochę mniej się do niego przygotowałem (w sensie slajdów), ale na szczęście nie to było najważniejsze, co widać po ocenie. Ważne, że uczestnicy się świetnie bawili i wynieśli sporą wiedzę z warsztatu.

Błędem był jednak brak porządnej aplikacji na telefon / tablet, pokazującej odliczany czas i dającej sygnał dźwiękowy co określony interwał. W tym warsztacie było bardzo ważne, aby co 5 minut robić zmianę, ale mój budzik nie zawsze dzwonił, przez co niektórzy siedzieli dłużej przy klawiaturze. Jak ktoś ma godną polecenia aplikację, do tego na Androida, to czekam na info!

Również brak przerwy mniej więcej w połowie warsztatu był kiepskim pomysłem, gdyż to chyba szybko wymęczyło ludzi. W okolicach drugiej godziny, widziałem zmęczenie na twarzach uczestników. A przerwa tuż przed końcem warsztatów nie była wystarczająco odświeżająca.

Mogłem również się trochę lepiej przygotować z implementowanego problemu, aby w razie dojścia do ślepego zaułku (do którego doszliśmy), aby szybko z niego wyskoczyć na właściwe tory. Do poprawienia następnym razem.


Przy okazji konfitury, firma Spartez zorganizowała jeszcze konkurs dla uczestników. Zadania można było rozwiązać wcześniej online, aby nie tracić czasu na samej konferencji. Jak zobaczyłem pytania (a było ich 6), od razu wiedziałem kto wygra – i nie pomyliłem się. Mimo wszystko zostałem wyróżniony i dostałem gadżety firmowe. Niestety ucho od kubka się potłukło w transporcie, ale jakoś mi specjalnie na nim nie zależało. Liczy się satysfakcja, z rozwiązanych zadań.

Podsumowując, obydwie wysokie oceny z warsztatów motywują mnie do dalszego działania w sferze dzielenia się moją wiedzą z innymi. Jeśli więc chciałbyś, abym poprowadził któryś w/w warsztatów u Ciebie w mieście / w firmie, daj znać na priv – e-mail do mnie znajdziesz na tej stronie.

A jeśli nie miałeś/-aś okazji uczestniczenia w moich warsztatach podczas Warsjawy, to być może, niedługo będzie taka możliwość w okolicach Wrocławia. Po więcej szczegółów zapraszam na stronę: chamberconf.pl

JDK 7 i 8 64 bit + Windows 7 - problemy z połączeniem internetowym

Co jakiś czas powraca do mnie problem na mojej maszynie związany chyba z kiepską implementacją IPv6 w 64 bitowym JVM lub Windowsie. Nie wiem dokładnie gdzie leży problem, ale już drugi raz spędziłem sporo czasu, aby znaleźć rozwiązanie, wiec czas na notatkę na blogu. Kłopot się objawia tym że maven / gradle / inny DSL do ściągania połowy Internetu, ma problemy ze dociągnięciem zależności i trzeba go ubić.

Aby rozwiązać ten problem warto dodać / uaktualnić zmienną środowiskową JAVA_OPTS tak, aby znalazła się w niej poniższa flaga:

-Djava.net.preferIPv4Stack=true

W przypadku gradle’a warto to jeszcze wrzucić do pliku gradle.properties w naszym projekcie, np.:

org.gradle.jvmargs=-Xmx1024m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 -Djava.net.preferIPv4Stack=true

Teraz już powinno być lepiej, chyba ze akurat trafimy na jakąś przerwę w działaniu ogólnodostępnych repozytoriów, z których aktualnie korzystamy.

Więcej informacji:
Why do I need java.net.preferIPv4Stack=true only on some windows 7 systems?

Networking IPv6 User Guide for JDK/JRE 5.0

Warsjawa 2014, czyli ja jako prowadzący 2 warsztaty

W tym roku miałem okazję poprowadzić 2 warsztaty na Warsjawie. Wcześniej prowadziłem jedynie prezentacje (czy to w pracy czy na WrocławJUG), a w formie warsztatów to był mój pierwszy raz! I od razu 2 różne tematy!

Jak mi poszło? Uważam, że co najmniej dobrze. Wydaje mi się, że nie miałem większych potknięć, feedback zbierany od uczestników jest jak dotychczas pozytywny.

Podobne opinie słyszałem, gdy się podpytywałem uczestników, jak i przeczytałem w e-mailach. Pewnie coś więcej będę mógł się dowiedzieć (zwłaszcza liczę na uwagi krytyczne, aby wiedzieć co poprawić następnym razem), gdy uczestnicy wypełnią ankietę pokonferencyjną. Wszelakie e-maile i komentarze również mile widziane.

A tymczasem zamieszczam poniżej materiały z których korzystałem.

Upiększ swoje testy! Testowanie jednostkowe dla średniozaawansowanych.

Kod używany na warsztacie: https://github.com/mstachniuk/SolarSystem

Poznaj lepiej swoje srodowisko programistyczne i zwieksz swoja produktywnosc z IntelliJ Idea.

Kod napisany przez uczestników podczas warsztatów: https://github.com/mstachniuk/WarsjawaCodingDojo

Co do samej konferencji, to minusy (z punktu widzenia prelegenta):
- nie do końca przygotowane sale (rzutnik, nasłonecznienie, jakieś pudła)
- system do komunikacji z uczestnikami nie wysyła załączników i wiadomości nie dochodzą do wszystkich
- nie do końca udany pomysł ze szwendaniem się po knajpach po konferencji

A na plus:
- obecność zagranicznych spikerów
- wcześniejsza rejestracja dla prelegentów
- transparentnosć, co ile kosztowało
- długie przerwy, dobry timeline

I oby tak dalej, albo i jeszcze lepiej!

Rusza rejestracja na tegoroczną Warsjawę oraz moje tematy

Już niedługo (21.09.2014 21:00) ruszy rejestracja dla uczestników Warsjawy - darmowej konferencji, która składa się z samych warsztatów! Liczba miejsc jest ograniczona, dlatego warto się spieszyć, zwłaszcza, że jest szansa na warsztaty, które będzie prowadził Venkat Subramaniam! Jest to założyciel Agile Developer, autor wielu książek jak i świetny prelegent, którego mieliśmy okazję wielokrotnie oglądać na polskich konferencjach. Styl jego prezentacji jest specyficzny, a o części jego wystąpień można przeczytać na moim blogu.

Dzięki wizycie Venkata w Warszawie, udało się go zaprosić także do Wrocławia i poprowadzi on wykład Programming with Lambda Expressions w ramach WrocJUG. Będzie również warsztat: Programming Concurrency - Workshop, ale na niego nie ma już miejsc, a lista oczekujących jest długa.

Jednocześnie zapraszam na warsztaty, które sam będę prowadził w ramach Warsjawy. Poniżej przedstawiam tematy, które będę prowadził, wraz z krótkim komentarzem.

Czas: Piątek, 26 września 2014 13:00
Temat: Upiększ swoje testy. Testowanie jednostkowe dla średnio zaawansowanych

Opis: Warsztat jest przeznaczony dla średniozaawansowanych programistów Java, którzy napisali już trochę testów i chcieliby je upiększyć. Podczas warsztatu będziemy ćwiczyć tworzenie ładnej sekcji given (za pomocą Builder'ów), jak i czytelniejsze zapisywanie assercji (za pomocą Hamcrest'a, FEST'a i AssertJ). Bedzie jeszcze o testowaniu wyjątków i testach parametrycznych. Warsztat będzie prowadzony po polsku, względnie może być po niemiecku;) Wymagane jest zabranie ze sobą własnego komputera ze skonfigurowanym środowiskiem programistycznym i opcjonalnie konto na GitHub'ie (do przesyłania gist'ów).

Być może, jak starczy czasu, będzie można poćwiczyć jeszcze inne rzeczy, ale to już zależy głównie od prędkości grupy, jak i zainteresowania tym, co będą chcieli usłyszeć uczestnicy.

Czas: Sobota, 27 września 2014 16:00
Temat: Poznaj lepiej swoje środowisko programistyczne i zwiększ swoją produktywność z IntelliJ Idea

Opis: Każdy programista powinien poświęcić 10 godzin na dogłębne poznanie swojego zintegrowanego środowiska pracy, aby móc z niego efektywnie (i efektownie) korzystać! A Ty ile czasu na to poświęciłeś? Warsztat jest przeznaczony dla programistów Java, korzystających z IntelliJ Idea, lub chcących się go nauczyć. Warsztat będzie miał formę Coding Dojo, podczas którego będziemy wspólnie pisać Katę i wzajemnie uczyć się korzystania z Idei bez użycia myszki. Warsztat będzie prowadzony po polsku, względnie może być po niemiecku;) Własny komputer nie jest wymagany, gdyż będziemy kodować wspólnie na jednym, podpiętym do rzutnika. Przyda się za to notatnik i długopis do zapisywania nowopoznanych kombinacji klawiszowych.

Na pomysł tego warsztatu wpadłem po tym, jak go z wielkim sukcesem przeprowadziłem w ostatnim projekcie. Po prostu, gdy udało się kupić IntelliJ Idea dla całego zespołu (o co bardzo ciężko walczyłem - skutecznie), musiałem wdrożyć kolegów w nowe środowisko. Wcześniej pokazywałem jedynie czym się różni Idea od Eclipse'a, ale to nie to samo co praktyka przy klawiaturze. Nie chciałem również słyszeć narzekań, że teraz trzeba się na nowo uczyć wszystkich kombinacji klawiszowych.

Zebrałem więc cały zespół, wyjaśniłem zasady i poszłooo! Było bardzo intensywnie, śmiesznie i co najważniejsze pouczająco. Ludzie wychodzili wówczas z sali z ugotowaną głową, ale widziałem później, że te warsztaty bardzo im pomogły. Zebrałem również bardzo pozytywne opinie na retrospektywie.

Mam nadzieję, że na Warsjawie będzie równie gorąco.

P.S. W razie jak byście chcieli się wcześniej zapisać na warsztaty, to przeczytajcie ten status.

Implementacja Singleton’a w Javie

Ostatnio, podczas z jednej z rozmów rekrutacyjnych, dostałem pytanie, "A jak by Pan zaimplementował singleton w Javie?". Pytanie dość standardowe, mógł by je zadać każdy. Odpowiadam więc: „Klasa, z prywatnym konstruktorem, z polem statycznym o typie zadeklarowanej klasy, metoda getInstnce(), itd.”. Rekruter na to: "No dobra, a jakiś inny pomysł?".

Na szybko nie przychodziło mi jednak nic do głowy... Wtedy padło pytanie, które zmotywowało mnie do przygotowania tego wpisu: "A czytał Pan Effective Java, Joshua Bloch?". A no nie czytałem i nie sądzę, abym ją przeczytał.

Dlaczego?

Przede wszystkim uważam że ta książka jest trochę przestarzałą. Drugie wydanie pochodzi z 2008 roku i informacje w niej zawarte są trochę nieaktualne. To nie książka o wzorcach projektowych Bandy Czworga, która nie traci na swojej aktualności, a jedynie pozycja o tym jak coś tam dobrze zrobić w Javie. I tak przykładowo rozdział: "Item 51 Beware the performance of string concatenation", traktujące o tym, aby lepiej używać StringBuilder’a niż + do sklejania tekstów, jest już dawno nieaktualne! Chciałem kiedyś pisać posta o tym, ale na stackoverflow i jeszcze gdzieś tam już dawno o tym było. Nie wiem tylko od kiedy dokładnie istnieje ten mechanizm zamiany + na StringBuilder’a w Javie.

O innych dobrych praktykach, można się dowiedzieć zawsze z innych źródeł, niekoniecznie czytając wspomnianą książkę.

Dobra wróćmy do tematu wpisu. W innym rozdziale Effective Java (Item 3: Enforce the singleton property with a private constructor or an enum type), jest zalecenie, aby Singletona implementować za pomocą Enuma. Z tym rozwiązaniem spotkałem się po raz pierwszy podczas review kodu kogoś, kto czytał tę książkę. Użycie wówczas enuma w roli singletonu było dla mnie zupełnie niezrozumiałe! Musiałem dopytać autora o co chodzi.

Dlaczego nie lubię tego rozwiązania? Spójrzmy na przykładowy kawałek kodu (inspirowany Joshuą Blochem, co bym za dużo nie musiał wymyślać, jak tu mądrze użyć singletona). Kod jest i tak kiepski (obliczanie czasu), ale chodzi mi o zaprezentowanie działania omawianego wzorca.

public enum Elvis {
    INSTANCE;

    private final int ELVIS_BIRTHDAY_YEAR = 1935;

    public int howOldIsElvisNow() {
        return new GregorianCalendar().get(Calendar.YEAR) - ELVIS_BIRTHDAY_YEAR;
    }
}

public class ElvisProfitService {

    public double ELVIS_SALARY_YEAR = 70_000;

    public double calculateElvisProfit() {
        return Elvis.INSTANCE.howOldIsElvisNow() * ELVIS_SALARY_YEAR;
    }
}

No i weź tu panie przetestuj taki kod! Możemy jeszcze Elvisa statycznie zaimportować, to linijka 6 skróci się do jeszcze mniej czytelnej formy.

return INSTANCE.howOldIsElvisNow() * ELVIS_SALARY_YEAR;

Ktoś ma jakieś pomysły jak taki kod przetestować? Da się oczywiście, z wykorzystaniem PowerMock’a [link do rozwiązania na końcu ^1], ale chyba nie o to chodzi aby pisać nietestowany kod?

Dlaczego wolę starszą wersję tegoż rozwiązania:

public class Elvis {

    private static final Elvis INSTANCE = new Elvis();

    private final int ELVIS_BIRTHDAY_YEAR = 1935;

    private Elvis() {
    }

    public static Elvis getInstance() {
        return INSTANCE;
    }

    public int howOldIsElvisNow() {
        return new GregorianCalendar().get(Calendar.YEAR) - ELVIS_BIRTHDAY_YEAR;
    }
}

Dochodzi prywatny konstruktor, statyczna metoda getInstance() i inicjalizacja pola klasy wraz z deklaracją.

W tym przypadku kod korzystający z tego singletonu, mógłby być następujący:

public class ElvisProfitService {

    private final double ELVIS_SALARY_YEAR = 70_000;
    private Elvis elvis = Elvis.getInstance();

    public double calculateElvisProfit() {
        return elvis.howOldIsElvisNow() * ELVIS_SALARY_YEAR;
    }

    // For tests
    void setElvis(Elvis elvis) {
        this.elvis = elvis;
    }
}

W linii 4 wywołałem getInstance(), aby w przykładowym kodzie produkcyjnym było wszystko cacy. Dzięki temu, zależność ta jest definiowana jako pole w kasie i mamy setter do tego, więc możemy sobie bardzo ładnie przetestować tą funkcjonalność, bez hackowania z PowerMockiem:

public class ElvisProfitServiceTest {

    @Test
    public void shouldCalculateElvisProfit() {
        // given
        ElvisProfitService service = new ElvisProfitService();
        Elvis elvis = mock(Elvis.class);
        when(elvis.howOldIsElvisNow()).thenReturn(1);
        service.setElvis(elvis);

        // when
        double elvisProfit = service.calculateElvisProfit();

        // then
        assertEquals(70_000, elvisProfit, 0.1);
    }
}

W sekcji given mamy bardzo ładnie zdefiniowane zachowanie, za pomocą Mockito, jakie ma przyjmować masz singleton na potrzeby tego testu.

A Ty jak definiujesz (o ile to robisz) swoje singletony? Które rozwiązanie uważasz za lepsze?

---

[1] Co do rozwiązania zagadki, jak przetestować Singletona jako Enum’a, to tutaj jest odpowiednia rewizja na github’ie: SingletonInJava e714fb a kod poniżej:

@RunWith(PowerMockRunner.class)
@MockPolicy(ElvisMockPolicy.class)
public class ElvisProfitServiceTest {

    @Test
    public void shouldCalculateElvisProfit() {
        // given
        ElvisProfitService service = new ElvisProfitService();

        // when
        double elvisProfit = service.calculateElvisProfit();

        // then
        assertEquals(70_000, elvisProfit, 0.1);
    }
}

public class ElvisMockPolicy implements PowerMockPolicy {

    @Override
    public void applyClassLoadingPolicy(MockPolicyClassLoadingSettings settings) {
        settings.addFullyQualifiedNamesOfClassesToLoadByMockClassloader("com.blogspot.mstachniuk.singletoninjava.Elvis");
    }

    @Override
    public void applyInterceptionPolicy(MockPolicyInterceptionSettings settings) {
        Method method = Whitebox.getMethod(Elvis.class, "howOldIsElvisNow");
        settings.proxyMethod(method, new InvocationHandler() {
            @Override
            public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                return 1.0;
            }
        });
    }
}

Wyższy poziom produktywności w IntelliJ Idea

Ostatnio natrafiłem na nagrania z konferencji Geekout z Estonii. Zainteresowała mnie 3cia prezentacja: Mouseless Driven Development by Hadi Hariri.

Prelegent (pracownik JetBains’a) opowiadał o tym jak efektywnie kodować bez użycia myszki. Myślałem, że już dostatecznie poznałem to moje ulubione środowisko developerskie, ale jak zobaczyłem pierwszą ciekawostkę, którą pokazał Hadi, to zacząłem robić notatki. A skoro notatki to już nie wiele trzeba, aby był wpis na bloga…

Uważam, że najlepszą metodą poznawania środowiska pracy, jest patrzenie jak korzystają z niego inni. I to może być przy okazji warsztatów typu Code Retreat, Coding Dojo czy innych hackathon'ów, lub właśnie oglądając screencasty i wystąpienia z konferencji. Zachęcam do obejrzenia powyższego video (choć ten efekt z przekrzywionym obrazem z rzutnika uważam za głupi), gdyż opisałem poniżej rzeczy dla mnie nowe, tudzież te wymagające mojego odświeżenia. Warto, przed dalszą lekturą tego wpisu, znać choć połowę skrótów z IntelliJIDEA_ReferenceCard.pdf, gdyż niżej będzie o bardziej zaawansowanych zagadnieniach. A więc do dzieła!

Jak wszyscy zapewne wiedzą (albo powinni wiedzieć), Ctrl + N otwiera klasy lub pliki (gdy dwa razy naciśniemy tą kombinację, lub Ctrl + Shift + N). I tutaj nazwę możemy podawać w szelaki sposób: CamelCase, snake_case (ale dla ułatwienia ze spacją), wspomagając się gwiazdką itd. Idea będzie szukać wszystkiego co pasuje i wyświetli w logicznym porządku. W Eclipse „jakoś tam” też to działa, ale o wiele gorzej.

Ale co mnie właściwie onieśmieliło, to gdy pisząc po nazwie klasy :<numer lini> (słownie: dwukropek i numer linii), plik zostanie otworzony na żądanej pozycji! Ciekawie działa również Alt + F1, które pozwala otworzyć nam plik np. w Project View, Structure, Exporatorze Windowsa, i w innych oknach. A chcąc otworzyć plik w osobnym oknie można zamiast Entera wcisnąć Shift + Enter. A jak chcemy wyszukiwać wszędzie, to możemy to zrobić za pomocą podwójnego naciśnięcia Shift. Część tych wskazówek zaczerpnąłem ze strony JetBrains’a: Navigating to Class, File or Symbol by Name, a część z opisanego na początku video.

Do wyszukiwania użycia jakiejś zmiennej lub metody, zawsze korzystałem z Alt + F7. Jest to skrót, który swoimi korzeniami sięga TotalCommandera, a nawet Norton Commandera. Podobnie jest zresztą z Shift + F6 - rename. Natomiast jak chcemy widzieć dolnego okienka z wynikami poszukiwań, możemy skorzystać z Ctrl + F7, które to skoczy nam do pierwszego wykorzystania i zaznaczy pozostałe. A jak byśmy chcieli podświetlić wykorzystanie wielu różnych zmiennych, to na każdej możemy skorzystać z Ctrl + Shift + F7. Jeszcze podobnie zachowuje się Ctrl + Alt + F7, które to pokazuje wyniki wyszukiwania w popupie. Poniżej przykłady z mojego projektu HamcrestVsFest.

Alt + F7

Ctrl + F7. Obiekt mercury jest tworzony w lini 10, ale po raz pierwszy jest użyty w linii 20.

Ctrl + Shift + F7. Tutaj wykonane na mercury, PlanetBuilder, RotationDirection i Gases.

Ctrl + Alt + F7

Dalej było o tym, jak zmaksymalizować przestrzeń na pisanie kodu. I tak prelegent, przekonywał nas, że można się obejść bez nawigation bara na górze ekranu.

To ten pasek, gdzie jest rozpisane, w jakim pakiecie i pliku aktualnie jesteśmy. Nie jest on nam potrzebny, bo możemy się dostać do niego za pomocą Alt + Home. Mi osobiście on nie przeszkadza, bo jest na tym samym poziomie, co ostatnio uruchamiana konfiguracja projektu, a to lubię widzieć.

Nie potrzebujemy również Tab’ek, gdy mamy wiele otwartych plików, bo przeglądanie ich i szukanie odpowiedniej po nazwie zajmuje wiele czasu.

Tak naprawdę potrzebujemy tylko Ctrl + E, które w bardziej czytelny sposób nam pokazuje, jakie pliki ostatnio przeglądaliśmy i szybciej je w ten sposób odnajdziemy. Jeśli zależy nam tylko na tych które ostatnio edytowaliśmy, to możemy skorzystać z Ctrl + Shift + E. Jest to ulubiony skrót prowadzącego prezentację do tego stopnia, że musi używać zewnętrznej klawiatury w laptopie, bo przycisk E mu się zepsuł. Przykłady użycia poniżej, a Tab'ki możemy całkowicie wyłączyć w ustawieniach.

Ctrl + E

Ctrl + Shift + E

Jak usunąć Tab'ki z otwartymi plikami.

Przeskakiwać pomiędzy poszczególnymi oknami w IntelliJ Idea można za pomocą Alt + <numer okienka>, widoczny przy jego nazwie. Niestety nie na wszystkie okienka wystarczyło numerków, więc jak chcemy np. dostać się do Mavena lub Bazy danych, to Ctrl + Tab jest twoim przyjacielem.

Ctrl + Tab

A jak już w ogóle byśmy chcieli tylko i wyłącznie kod widzieć, to warto się zapoznać z Prezentation Mode. Warto na Windowsie sobie zdefiniować skrót Ctrl + Shift + P jako wejście do tego trybu. Na pewno może się to przydać podczas prezentacji, jak i osobom lubiącym widzieć tylko kod na ekranie.

Następnie poznałem nowe znaczenie F4 w oknie projektu. Dotychczas używałem tego klawisza tylko do otwierania właściwości projektu, a w ten sposób można również otworzyć plik i automatycznie skoczyć do jego edycji. Jest to lepsze od oczywistego Entera, który tylko otwiera wybrany plik, ale fokus pozostaje na oknie projektu.

A co z operacjami typowymi dla myszki, jak dostrajanie wielkości okna projektu? Sam dotychczas myślałem, że jest to jedynie możliwe za pomocą myszki, ale da się też z klawiatury! To kolejne moje wielkie odkrycie z tej prezentacji, po którym mi i osobom na sali opadła szczęka. Chcąc przykładowo zmienić rozmiar widoku projektu, musimy mieć na nim focus (Alt + 1) i teraz już wciskamy tylko Ctrl + Shift + Prawo / Lewo. Okno z wynikami testu? Po porostu Alt + 4 aby uzyskać fokus i Ctrl + Shift + Góra / Dół. Na oknie z kodem to nie działa, gdyż te skróty odpowiadają za zaznaczanie tekstu i przenoszenie linii w pionie.

Było jeszcze o mulitikursorze, który swoim zasięgiem może objąć wiele wierszy. Tu już trzeba zrobić z użyciem prawego Alt’a i myszki. Ale Idea proponuje jeszcze  coś innego, a mianowicie Alt + J, które zaznacza dany tekst w pliku i tworzy multikursor. Jest jeszcze: Ctrl + Alt + Shift + J, ale jak to działa, sprawdźcie sami. Aby opuścić ten tryb edycji, trzeba wcisnąć 2 x Esc.

Warto przypomnieć o Live Templates (Ctrl + J) i Postfix templates, o których to się nie pamięta, a za pomocą których można tworzyć kod w ciekawszy sposób. Możemy również otaczać kawałek kodu różnymi konstrukcjami (np. if, try/catch, itp.) za pomocą Ctrl + Alt + T.

Warto także utworzyć własną szybka listę (Quick Lists w Settings), gdzie można wrzucić operacje, które często używamy i przypisać wywołaniu tej listy jakiś skrót klawiaturowy. Muszę sobie przygotować taką listę, z rzeczami które często potrzebuję, a nie mają domyślnego skrótu klawiaturowego.

Na koniec jeszcze pozostaje nam Ctrl + ~, które to umożliwia nam szybką zmianę, m.in. kolorów, Look and Feel jak i skrótów klawiaturowych (przykładowo na te z Eclipse’a). Może się to przydać, gdy akurat musimy zrobić Pair Programing z użytkownikiem Eclipse’a. I aby śledzić nasze postępy w niewykorzystywaniu myszki, warto się przyjrzeć statystykom z menu Help -> Productivity Guide.

A Ty jakie znasz bardziej zaawansowane i skomplikowane skróty w IntelliJ Idea? Pisz w komentarzu!

Relacja z 33 Degree 2014

Tegoroczną konferencję 33Degree rozpocząłem od wykładu Tomka Bujoka pt. 33 things you want to do better. Pierwszy poprzedzający go keynote był nudny, a drugi gdzieś już chyba widziałem lub słyszałem.

Tomek przedstawił sporo narzędzi ze swojego toolboxa, z którymi warto się zaznajomić i w razie konieczności używać. I tak było o bibliotekach: Guava, Lombok, SLF4J, Unitils (testy jednostkowe na plikach), JUnitParams, Awaitility (do testowania wielowątkowego), Byteman (ciekawy projekt do zmiany zachowania kodu produkcyjnego w locie), Spock, grape (do skryptów shelowych w Groovy’m), Git, bash i inne. Na koniec Tomek zareklamował swój projekt: babun. Jest to skonfigurowana powłoka z preinstalowanym gitem i paroma narzędziami do przyjemniejszej pracy z shellem pod Windowsem.

Z powyższych warto sobie odświeżyć Lomboka. Kiedyś już przyglądałem się tej bibliotece, ale był wtedy problem ze wsparciem dla IntellJ Idea. Teraz wygląda na to, że jest już lepiej i doszła możliwość tworzenia builderów za pomocą adnotacji.

O kolejnej prezentacji: RESTing away from hell Jakuba Janczaka nic nie napiszę, bo było nudno i nawet nic nie zanotowałem.

Kolejna prezentacja Get Back in Control of Your SQL Lukasa Edera bardzo mi się podobała. Początkowo prelegent przedstawił wady na przykładowym kodzie takich rozwiązań jak: JDBC, EJB 2 / 3 i Hibernate. Rozwiązaniem na wszystko ma być JOOQ. Narzędzie to generuje na podstawie schematu bazy danych stałe zawierające nazwy tabel, kolumn itp. Później możemy z tego korzystać za pomocą fluent API, które jest bardzo zbliżone do SQL. Właściwie jedno i drugie czyta się tak samo, tyle że w Javie dochodzi kilka kropek i nawiasów. Jeszcze przyjemniej wygląda to w Scali. A całość jest Type Safe. Jest nawet jakiś prosty mapping na obiekty POJO. Niestety JOOQ, jest rozwiązaniem komercyjnym, dla komercyjnych baz danych.

Narzędzie spodobało mi się i chętnie bym z niego kiedyś skorzystał w projekcie. Jakby ktoś chciał obejrzeć wystąpienie (ale z GeeCON'a), jest już dostępne:

A w tak zwanym międzyczasie rozwinął się gorący wątek na Wrocław JUG (wielkie brawa za reaktywację) i padło tam jeszcze parę innych narzędzi tego typu: LIQUidFORM (ale to już trochę martwy projekt) Prevayler i Querydsl.

Kolejny wykład był dosłownie sprintem po nowościach w JEE 7. Prelegent (Arun Gupta) przeleciał w 50 min po 50 nowinkach, dotykając każdego aspektu tej technologii. Dla mnie były to jedynie zmiany kosmetyczne, żadnej nowej wielkiej rewolucji.

Następnie słuchałem prezentacji Josh Longa pt. Microservices and REST with Spring Boot. Było kodowanie na żywo, ale bardzo fajnie. Prelegent zaczął od start.spring.io i pokazał jak niewiele należy samemu dopisać, aby mieć już coś działającego. Było sporo o Richardson Maturity Model i trochę o bezpieczeństwie. W międzyczasie prelegent korzystał z ciekawej wtyczki do Chrome’a do generowania zapytań RESTowych: Advanced REST client.

Dzień drugi zaczął się znów od keynotów. Pierwszy był wypełniony tabelkami z Excela i kolorowymi Clipart’ami z Worda bez konkretnego przesłania. Typowy przykład jak nie robić prezentacji... Szybko opuściłem salę.

Drugi keynote był już lepszy. Prelegent wziął na studium przypadku pisanie latarki na iOS. Najważniejsze jest, aby przy różnych przedsięwzięciach nie tylko programistycznych, odpowiedzieć sobie na pytanie „What, Whoam and Why?”

Prelegent opowiadał dalej o aplikacjach i ich interakcji z użytkownikiem. Nasza aplikacja powinna mówić do pojedynczej osoby (używać odpowiednich form gramatycznych), bo interakcja jest między użytkownikiem a sprzętem. W ten sposób uda nam się przemówić do tłumów. Nie zmienimy w ten sposób całego świata (bo nie możemy), ale zmienimy świat dla jednej osoby, a to już jest sukces. A zmieniając rzeczywistość pojedynczych osób zmieniamy świat wielu osób.

Było jeszcze o reklamach Apple które nie mówią o tym jak świetny jest ich produkt, ale uderzają w ludzkie życie, uczucia i inne wartości. Na koniec było jeszcze o córce prelegenta, która mu zmarła, przez co wykład bardzo oddziaływał na emocje prelegenta, jak i słuchaczy.

Następnie byłem na wystąpieniu Tomka Nurkiewicza na temat OLAPowej bazy danych Saiku. Bardzo fajne narzędzie do generowania raportów, trendów, wykresów itd. Wykład był fajny, było wiele przykładów użycia… Jakbym kiedyś potrzebował, to chętnie spróbuję.

Później byłem na wykładzie Jarosława Pałki na temat Patterns for Organic Architecture. Spodziewałem się, że będzie to prezentacja bardziej techniczna, z przedstawieniem konkretnych wzorców, ale było bardzo miękko, więc się zawiodłem.

Następnie byłem na prezentacji Venkat’a Subramaniam’a, który przedstawiał Projekt Nashorn. Jest to narzędzie, które kompiluje kod JavaScript’a do bytecodeu JVM. Czyli możemy sobie po stronie serwera pisać w JavaScript. Prelegent pokazywał na żywo, jak można wywoływać JS z Javy i na odwrót.

Kolejnym slotem byłem mocno zawiedziony. Najpierw byłem na prezentacji Abdelmonaim Remani dotyczącej debuggingu. Wykład był tragiczny, jak dla studentów pierwszego roku. „Aby znaleźć bug’a trzeba najpierw zlokalizować komponent w którym on jest”. Musiałem opuścić prezentację. W innych salach również nie było lepiej, gdyż sporo ludzi wędrowało wte i wewte.

W końcu wylądowałem na prezentacji dotyczącej github’a i gerrit’a Luca Milanesio. Prelegent porównywał oba systemy i przedstawił workflow, aby push’ować do innego brancha, który po przeglądnięciu się merguje z masterem. Było również wspomniane o Git review plugin, który po wypushowaniu zmian podaje linka do review. Było również o jakimś pluginie do Jenkinsa, który wspiera Gerrita. Całość można przetestować na gerrithub.io, które się integruje z naszymi repozytoriami z GitHuba.

Następnie byłem na prezentacji JavaScript Design Patterns Pratika Patela. Było o wzorcach z JS, za pomocą których możemy osiągnąć pewne elementy, które mamy w Javie. I tak przykładowo za pomocą namespace możemy utworzyć globalny obiekt, w ramach którego możemy trzymać sporo rzeczy. Należy jednak uważać, aby nam ten twór nie urósł za bardzo, bo nie będzie on odśmiecany. Było jeszcze o Mixin module (coś na kształt Dependency Injection), publish subscribre w ramach jednego kontekstu, Command (jako Aspect) i Factory (np. w backbone).

Na koniec została jeszcze zaprezentowana ciekawa stronka: TodoMVC.com na której jest napisana jedna i ta sama aplikacja z wykorzystaniem różnych bibliotek JavaScriptowych.

Trzeciego dnia keynote’y były przesunięte na koniec dnia, więc na szczęście można było je bezboleśnie pominąć. A dzień rozpocząłem od wystąpienia Jarka Ratajskiego Doing WEB development clean way, gdyż miało być duże show i ciekawy sposób prowadzenia prezentacji. I rzeczywiście było trochę strzelania do zombie i wywoływania osób z publiczności do odpowiedzi. Było również poprawianie kodu JS na żywo, ale nie do końca ono działało, ze względu na przeskalowanie ekranu.

Co do konkretów, to Jarek pokazał, że należy korzystać ze statycznej analizy kodu, zwłaszcza w dynamicznych, słabo typowanych językach jak JS, gdzie można bardzo łatwo zrobić sobie krzywdę. Takową analizę można przeprowadzić za pomocą np. jshint. Prelegent również namawiał do korzystania z frameworków JS, takich jak angularjs i do używania pluginów w przeglądarkach wspierających development.

Było również o trendach, jak kiedyś, a jak obecnie tworzy się strony internetowe. I tak na dzień dzisiejszy królują single page applications. Z narzędzi było jeszcze o Lesscss które pomaga nam generować CSS. Wartością dodaną jest możliwość tworzenia zmiennych funkcji itp. do lepszego zarządzania tymi stylami.

Prezentacja fajna w formie, ale jak na konferencję pokroju 33 Degree, to było za dużo show, a za mało konkretów. A wiem, że Jarka na pewno stać na więcej.

Później byłem na prezentacji Jakuba Kubryńskiego na temat Spring Boot. Już wcześniej o tym na konferencji słyszałem, ale postanowiłem jeszcze raz zobaczyć. Generalnie framework (a właściwie zbiór frameworków) został pomyślany dla, ostatnio dość popularnych, microserwisów. Jest również świetną baza, dla nowych projektów, gdyż trzeba bardzo mało napisać aby wystartować z aplikacją. Dodatkowo aplikacja zawiera wbudowanego tomcata lub jetty, więc można bardzo szybko ją wystartować.

Jakub pokazał możliwości frameworka i ostatnie 15 minut był live coding. Poprzez lokalne Wi-Fi można było się połączyć ze stworzoną na szybko stroną i dzięki temu prelegent mógł pokazać satystyki jakie daje nam spring boot. Prezentacja bardzo udana.

Następnie byłem na reaktywnej Javie Tomasza Kowalczewskiego. Było o bibliotece RxJava, ale jakoś mnie nie poniosło. Sposób przemawiania do mnie nie dotarł.

Na koniec konferencji byłem chyba na najmniejszym wykładzie podczas całej imprezy. Była to prelekcja Dariusza Lukszy pt. Your own full blown Gerrit plugin. Na sali było jakieś 10 osób, i wszyscy zgromadzili się bliżej prelegenta. Ale trudno się dziwić, skoro w sali obok było show Venkata.

Darek opowiadał, jak łatwo można napisać plugin do Gerrita, który wykonuje ponowny build naszego kodu na Jenkinsie. Kod można znaleźć tutaj: gerrit-retriggerme. Darek bardzo zwinnie przełączał się pomiędzy otagowanymi wersjami swojego kodu, opowiadając przy tym co się w nim zmieniło. Temat ciekawy, jakby ktoś potrzebował.

Podsumowując konferencję było bardzo gorąco, zwłaszcza w namiocie ze stoiskami sponsorskimi. Dmuchawy i otwieranie kolejnych ścian trochę pomagało, ale to i tak lepiej niż gnieździć się w wąskich korytarzach kina. Na szczęście stanowiska sponsorskie szybko reagowały na upał i załatwiały zimne napoje w kolejnych dniach konferencji.

Fajnie też, że przygotowano aplikację na telefon z rozkładem jazdy, ale brakowało mi w niej informacji o tym, kiedy, gdzie, jaki konkurs jest rozstrzygany. Pomogłoby to jeszcze bardziej promować się sponsorom konferencji. W tym roku chyba najbardziej zaszalał Luxoft, dając (prawie) każdemu uczestnikowi tableta. Wiadomo, że nie był to jakiś super sprzęt, ale zasponsorowanie tak sporej ilości urządzeń to na pewno było nie lada wyzwanie i koszt. Choć pewnie spora większość uczestników już takie zabawki dawno posiada w swoich zasobach.

Co do poziomu wykładów, to było bardzo nierówno. Nie było chyba żadnego, który by wywrócił, lub choćby zachwiał mój dotychczasowy światopogląd. Brakowało mi również bardziej praktycznych warsztatów.

Sporo czasu zajęło mi sporządzenie tej notki, ale niełatwo jest streścić 3 dni konferencji w jeden wpis. A już na dniach zbliża się Confitura. Mam nadzieję, że relacja z tej imprezy powstanie szybciej.

DevCrowd 2014

W tym roku udało mi się ponownie (bo po raz drugi) zawitać na konferencję DevCrowd do Szczecina. Nie jest to kolos kalibru GeeCona czy 33rd Degree, ale tworzy ona swój własny specyficzny klimat. Przygotowano nawet aplikację na androida, pomagającą w podjęciu decyzji, na którą prelekcję wybrać się aktualnie. A do wyboru były dwie równoległe ścieżki.

Rozpoczęcie konferencji przeciągnęło się mocno, przez co do obiadu wszystkie wystąpienia zostały przesunięte o kilkanaście minut. Na szczęście po obiedzie wszystko wróciło na swoje miejsce.

Na początek udałem się na prezentację Macieja Opały i Wojtka Erbetowskiego pt. Designing API for Mobile App. Jak więc projektować serwerowe API dla aplikacji mobilnych? Przede wszystkim z powodu powolnych łączy komórkowych, problemów z zasięgiem, przemieszczania się użytkownika, należy ograniczyć liczbę przesyłanych danych do minimum. Jeśli wystawiamy po stronie serwerowej RESTa, to lepiej jest przesyłać dane za pomocą JSONa niż XMLa. W przykładzie prelegentów, pozwoliło to na zmniejszenie wielkości wiadomości o 37%.

Warto również korzystać z Cache’a Http po stronie serwera, jak i Androida. W telefonie można w tym celu skorzystać z tych narzędzi: retrofit, OkHttp i HttpResponseCache. Dobrym sposobem na zmniejszenie rozmiaru paczki danych przesyłanej przez sieć, jest skorzystanie z kompresji GZIPa. Trzeba jednak uważać, gdyż dla małych plików, może ona nie opłacać się.

Przedstawiony był również problem wersjonowania naszych Interface’ów. Wynika on z opóźnionego aktualizowania aplikacji na telefonach użytkowników, czyli mogą wymagać starego API. Najlepiej, aby się ono nie zmieniało, ale najczęściej jest to niemożliwe. I tak można podawać Path parameter (np. http://api.example.com/res/v1) media type (lub custom header) (np. http://api.example.com/res+v1) albo subdomenę (np. http://v1.api.example.com/res). Wszystkie rozwiązania posiadają jednak swoje wady.

Na koniec wspomniano jeszcze o narzędziu Swagger, do tworzenia dokumentacji (coś ala javadoc) dla RESTowych aplikacji.

Zawsze bałem się prezentacji, gdzie jest dwóch prelegentów. Najczęściej oznaczało to, że prowadzący zbytnio nie znają się na temacie, lub mają opory przed wystąpieniami publicznymi. Tutaj jednak wypadło to dobrze i sprawnie.

Na drugą prezentacje wybrałem wystąpienie Mateusza Kaczmarka pt. Good design makes us happy – czyli podejmij tę decyzję za mnie. Na początku Mateusz polecał książki, od których wszystko się u niego zaczęło, czyli pozycje Dona Normana (nie pamiętam którą dokładniej) i Steva Kruga Don’t Make Me Think. Na zajawkę zamieszczam prezentację z TEDa tego pierwszego Pana.



Następnie prezentacja była wypełniona przykładami, gdzie zastosowano fajne, udane pomysły, jak i przedstawiono firmowe porażki. I tak Apple swego czasu było warte więcej niż polskie PKB, Amazon stworzył przyjemny proces zakupowy, Google uznało, że wyszukiwanie musi być proste itd. Natomiast w sektorze gier, firma EA zdobyła 2 razy z rzędu tytuł najgorszej firmy roku w USA. A zasłużyła sobie na to, dzięki wypuszczaniu niedokończonych tytułów. Inaczej było w przypadku Diablo 2 i Starcrafta, na które wydawcy kazali sobie dłuuugo czekać, co zostało sowicie nagrodzone. Również Blizzard (wydawca Diablo) pokazał, jak można naprawić swoje błędy. Przykładowo firma zamknęła sklep, za pomocą którego gracze handlowali przedmiotami w grach, gdyż to psuło rozrywkę. I ogłosili to ludzie wyglądający jak gracze, a nie panowie w garniturkach.

Co więc robić aby uzyskać UX User experience? Dla ludzi biznesu trzeba wkładać więcej wykresów do naszych aplikacji, a dla szarych Kowalskich należy upraszać nasze interfejsy graficzne. Dzięki temu użytkownicy czują się bezpieczniej i będą korzystać z naszej aplikacji. Warto też podejmować typowe decyzje za użytkownika, ograniczając mu liczbę opcji do skonfigurowania, gdyż najgorzej to stracić zaufanie użytkownika, a jeszcze gorzej jego pracę.

Prezentacja fajna, aczkolwiek był to raczej wstęp do tematu, który nie jednemu zapewne uświadomił istnienie problemu. Brakowało mi bardziej konkretnych rad i wytycznych, jak tworzyć proste i przyjemne interfejsy użytkowników. Na koniec wspomniano o innej książce Steva Kruga Rocket Surgery Made Easy, traktującej o tym, w jaki sposób tworzyć testy interfejsów na użytkownikach końcowych.

Następnie udałem się na prezentację Koziołka: Jak pracować i nie zwariować. Rozmawialiśmy o tym, co najbardziej wpływa na naszą pracę (a wiec krzesło, klawiatura, dysk SSD, RAM i 2 monitory). Każdego dnia powinniśmy lepiej poznawać nasze IDE, biblioteki i narzędzia. Warto też automatyzować jak najwięcej, gdyż jesteśmy leniwi, a jak nie będziemy musieli wielokrotnie pisać tego samego, to życie będzie przyjemniejsze.

Dalej było o introwertykach, psychopatach, dzieciach autystycznych, mądrej asertywności, drugim znaczeniu słowa SCRUM, potrzebie twardego resetu, śnie i przerywnikach w pracy. Ciekawy był pomysł Koziołka, jak odliczać sobie czas w technice pomodoro. Warto do tego użyć gier na facebooku, w których coś tam po jakimś czasie można zebrać i na nowo posiać. Wymusi to na nas regularne przerwy dla umysłu. Z praktycznych narzędzi, było wspomniane o bibliotece jFairy. która to generuje losowe dane.

Była to fajna i śmieszna prezentacja.

Następnie byłem na prezentacji Bartłomieja Nićka pt. Programista to za mało. Prelegent bardzo chaotycznie mówił i w ogóle nie zrozumiałem ani grupy docelowej, ani celu prezentacji. Było coś o wadach naszego zawodu, wadach samych programistów, jak się dawniej realizowało projekty, a jak się to robi obecnie. Prezentacja bardzo nieudana. Z prezentacji jedynie utkwiła mi różnica miedzy Computer Programer a Software Developer wg. US Bureau of Labor Statistic. A więc:

Computer programmers write code to create software programs. They turn the program designs created by software developers and engineers into instructions that a computer can follow.

Software developers are the creative minds behind computer programs. Some develop the applications that allow people to do specific tasks on a computer or other device. Others develop the underlying systems that run the devices or control networks.

Następnie był smaczny obiad i wystąpienie Pawła Szulca na temat JavaScriptu. Nie wiem czy to był celowy zamysł organizatorów, aby Pawła umieścić zaraz po obiedzie, ale jak dla mnie był to strzał w dziesiątkę! Nieprzerwany potok słów Pawła nie pozwalał ani na chwilę nudy i raczej nikomu nie chciało się spać.

Prelegent przekonywał nas, że JavaScript nie jest Mordorem, którego należy się obawiać, a wystarczy poznać i zrozumieć różnice w stosunku do Javy, to będzie dobrze. Przede wszystkim JS jest językiem funkcyjnym, a nie obiektowym. To, co początkowo przeraża, to możliwość wywołania funkcji z inną liczbą argumentów niż ją zadeklarowano! I tak niezdefiniowane argumenty będą undefined, a nadmiarowe będą zignorowane. W JS każda funkcja posiada lokalną zmienną arguments, która to przechowuje wartości argumentów przekazanych nam do funkcji.

Następnie Paweł bardzo fajnie omówił sposoby wywoływania funkcji w JS i czym się one od siebie różnią. A różnią się zazwyczaj kontekstem, na rzecz którego będzie odbywać się wywołanie, tzn. możemy otrzymać coś innego pod lokalna zmienną this. I tak mamy 4 możliwości:

1.    Wywołanie bezpośrednie powoduje, że funkcja otrzyma domyślny context, w przypadku przeglądarki jest to obiekt window

function func() {
    console.log(this)};

func();
// [object Window]

2.    Wywołanie jako metoda. Polega to na przypisaniu funkcji do pola w obiekcie. Dzięki temu dostajemy metodę, którą mozemy wywołać. W tym przypadku jako this otrzymujemy obiekt na rzecz którego funkcja została wywołana.

function func() {
    console.log(this)
}

var variable = {
    property: 'value'
};

variable.method = func;
variable.method();
// Object { property="value", meth=func()}

3.    Wywołanie jako konstruktor, a więc ze słówkiem kluczowym new powoduje utworzenie pustego obiektu (dziedziczącego z prototype). Funkcja ma w takim przypadku za zadania zainicjowanie obiektu, który zostaje zwrócony jako rezultat wywołania.

function func() {
    console.log(typeof(this))
}

var obj = new func('abc');
// object

4.    Wywołanie za pomocą applay() i call(). Przydaje się ta możliwość, gdy nie chcemy kopiować funkcji do innego obiektu, aby nie powtarzać kodu. Podmienimy jednak przez to context, czyli this. Predefiniowana funkcja applay() przyjmuje poza pierwszym argumentem tablicę z argumentami, a call() przyjmuje argumenty osobno (po prostu po przecinku)

function func() {
    console.log(this)
}

var variable = {
    property: 'value'
};

func.call(variable)
// Object { property="value"}

Było jeszcze trochę o Scop’ach, Hoistingu, domknięciach i modułach. Warto swój kod Javaskriptowy testować, np. Za pomocą narzędzi jak jasmine, czy mocha. Warto również testować swój kod statycznym analizatorem, np. JSLint. A jak musimy się na szybko nauczyć tego języka, to warto się zabrać za czytanie 2-giego i 3-ciego rozdziału Secrets of the JavaScript Ninja.

Kolejną prezentacją, na którą się udałem, było wystąpienie Tomka Borka, na temat zaawansowanego testowania. Chciałem początkowo iść na SCRUM, but, ale już miałem dość miękkich prezentacji i potrzebowałem czegoś technicznego posłuchać.

Na początku Tomek przestrzegał, aby nie używać PowerMocka, gdyż jest bardzo czasożerny, gryzie się z narzędziami do testowania pokrycia kodu, rzuca kiepskie wyjątki, a przede wszystkim pomaga początkującym pisać brzydki kod.

Dalej było trochę o adnotacji Parameterized z JUnita i ich alternatywach. Ciekawie wygląda projekt zohhak, którego wcześniej nie znałem.

Prelegent opowiedział jeszcze o paru ciekawych pomysłach, dotyczących testowania. Przykładowo, gdy wystawiamy usługi RESTowe na zewnątrz, to warto sprawdzić, czy te opublikowane interfejsy nie zmieniły się. Co do adnotacji @Ignore, to powinna być przy niej data do kiedy może ona być w teście i dlaczego.

Było jeszcze o narzędziach pomagających ogarnąć nam bazę danych, tj Liquibase, DBUnit i Databene Benerator. To ostatnie narzędzie pomaga generować testowe zbiory danych.

Z innych ciekawych (albo też egzotycznych) narzędzi był wspomniany Sureassert. Działa on tylko z Eclipse i pomaga realizować ideę design by contract i ciągłego uruchamiania testów (czyli coś jak infinitest). Niestety nie jestem fanem podejścia programowania kontraktowego i rozwiązanie działa tylko w Eclipsie.

Było jeszcze wspomniane o trzech bibliotekach, pomagających w skanowaniu naszych klas w celu poszukiwania adnotacji: Scannotation, Reflections i Classindex. Na koniec prezentacji było fajne podsumowanie, pokazujące co było omawiane na prezentacji.

Na koniec organizatorzy konferencji przygotowali niespodziankę, a mianowicie zdalne wystąpienie Adama Bienia z tematem How To Tackle Java EE 7. Live streaming był bardzo dobrze przygotowany, całość była transmitowana przez platformę ustream.tv. Prelegent zmieniał tło na którym mówił i wyglądało to bardzo profesjonalnie. Inne jego prezentacje można obejrzeć tutaj: tv.adam-bien.com.

Widać że Adam ma sporo doświadczenia w tym temacie. Było sporo kodowania na żywo, niewiele slajdów (które są dostępne tutaj), a pytania z publiczności można było zadawać za pomocą twittera. Ciekawe rozwiązanie, aczkolwiek z telefonu trochę dłużej pisze się twitnięcie, przez co było spore opóźnienie w dialogu.

Co do samej prezentacji, to Adam pokazał nam, jak można łatwo i szybko zbudować projekt z wykorzystaniem Javy EE 7. Polegało to na skorzystaniu z archetypu mavenowego i wyrzuceniu połowy domyślnego pom’a. Projekt Prelegent twierdził, że nie powinno się dodawać biblioteki do projektu „na zaś”, tylko w momencie gdy naprawdę są potrzebne. Przez to czas build’a i deploymentu powinien (przynajmniej początkowo) trwać krócej.

Generalnie kodzenia było za dużo i po jakimś czasie człowiek się wyłączał i gubił w kodzie. Dla mnie był to trochę odgrzewany kotlet, gdyż podobną prezentację widziałem na JDD 2012 z tą różnicą, że wtedy była Java EE 6 na tapecie. Jeśli ktoś chce obejrzeć tą prezentację, to jest ona dostępna poniżej:

Na zakończenie było jeszcze zbieranie ankiet i losowanie nagrody.  Konferencja wypadła bardzo fajnie. Brakowało mi jedynie typowo technicznych zagadnień, no ale trudno. Może następnym razem.