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:
(Sorry za kiepską jakość...)
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)
- Modelled Around Business Domain
- Culture Of Automation
- Hide Implementation Details
- Decentralise All The Things
- Deploy Independently
- Consumer First
- Isolate Failure
- Highly Observable
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ć.
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
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.
Brak komentarzy:
Prześlij komentarz