Moje prezentacje

W mrocznych czasach musieliśmy czekać 3-4 lata, żeby zobaczyć nową wersję Javy. Teraz mamy dwa duże wydania każdego roku! Nowości z Javy możemy wykorzystać przed wydaniem kolejnego LTSa.

No dobrze, ale co się wydarzyło od czasu Javy 11?
Wyrażenia switch?
Bloki tekstowe?
Nowe funkcje w klasie String, w Streams i innych API?
O co chodzi w Shenandoah and ZGC?
AppCDS by uruchamiać aplikacje szybciej?

Jeśli wydają Ci się interesujące, dajmy razem nura w te nowości!

Wyczekowałeś Grzesiu brancza, tak jak cię prosiłam?
Wyczekowałem i pusznąłem bagfiksa, ciociu miła!

Poznałeś w tym miesiącu dwa super kul frejmłorki, które pozwolą ricznąć więcej kipiajów? Fantastycznie, a kiedy ostatnio w twym ręku był słownik? Albo jakakolwiek książka (lub czasopismo)?

Wszystko się teraz informatyzuje, takie czasy. e-Urząd, e-commerce, e-tamto, e-siamto… Żeby to wszystko zrobić i utrzymać, potrzeba rzeszy informatyków i inżynierów. (I straszą, że ma być jeszcze gorzej.) Coraz więcej rzeczy przechodzi przez ręce naszej branżuni. Ludzie narzekają na “arystokację IT”, że nie można jej zrozumieć. “Arystokracja” ma wysokie mniemanie o sobie i zadziera nosa jeszcze bardziej, bo nie po to studiowała pięć lat… itd. W tym celu coraz bardziej hermetyzuje swoje specyficzne narzecze, będące worem makaronizów, kalek językowych, nawet kanajackiej grypsery. Tymczasem celem każdej arystokracji jest także dawanie przykładu, niesienie kaganka oświaty, dążenie do gwiazd.

Nieodwołalnie nastał czas Javy 11+. (Gdyby twój szef jeszcze nie zauważył… ;-)) Prelekcja o tym jak udało się przenieść prawdziwe aplikacje serwerowe do Javy 11. Co i jak trzeba było zrobić, jak przekonać biznes, co nie było wymagane, wnioski dla innych.

Niestety wersja po polsku nie została nigdzie opublikowana.
Prezentacja (w różnych formatach i długościach) gościła m. in. na Devoxx Poland, Devoxx Ukraine, Devoxx Belgium, CodeMotion Milan, Java Developer Days, CoffeeJUG Lviv, 4Developers, Wrocław JUG i innych.

Jak programista może stwierdzić czy systemowi coś dolega patrząc wyłącznie na jego wejście i wyjście? Jeśli chcesz to wiedzieć (i za bardzo nie nie przeszkadza Ci standup), przyjdź i zobacz. Terapia jest bezpieczna! ;-)

Jedną ze szkół zapoznawania się z systemem jest długie i namiętne czytanie dokumentacji, przerywane rzucaniem okiem do kodu. Inną szkołą jest zanurkowanie w model danych (często w bazie) i posurfowanie po interfejsie użyszkodnika. Są to dwa naturalne końce systemu, legendarne wejście i wyjście. Poprzez oglądanie stanu tychże końców można sprawdzić, czy w środku jest zdrowe trawienie, czy niezdrowy proces gnilny. Wnikliwa egzaminacja pozwala stwierdzić obecność “DDDozy pospolitej”, “stringozy złośliwej”, “biegunki regexowej” czy też “syndromu nie-zrobione-u-nas”. Niestety, czasem do infekcji dochodzi już na etapie życia płodowego programisty (czytaj: w szkole). Zapraszam na kurację. Przeczyszczającą. (Czyli naturalny ciąg dalszy “Passwords. Do you keep them safe?”)

Zdaniem niektórych codzienna praca programisty polega przede wszystkim na rozwiązywaniu problemów, a nie używaniu narzędzi. Moim zdaniem wykorzystywanie właściwych narzędzi nie tylko rozwiązuje problemy, ale pozwala wyeliminować wiele z nich. Trochę to trwało nim uświadomiłem sobie, że o ile żadne narzędzie nie jest złotym młotkiem, o tyle niektóre są dla mnie prawdziwymi punktami G*. Używanie ich daje prawdziwą satysfakcję podczas reagowania na “kolejne wymaganie biznesowe”. Chciałbym Wam pokazać moje zawodowe punkty G i pomóc znaleźć wasze. Oraz wskazać co brak tych punktów możne oznaczać w kolejnej “fantastycznej” ofercie pracy, którą właśnie otrzymaliście.

“Najlepszy algorytm do sortowania to quick sort.”
“Indeksy przyspieszają działanie bazy.”
“Dane sortuje się przy pomocy ORDER BY.”
“Dziedziczenie be, kompozycja cacy.”
“Windows to system operacyjny.”
“W bazie musisz mieć transakcje.”
“Java jest wolna.”
“Nie jedz żółtego śniegu.”
“Nie należy samemu podpisywać certyfikatów.”
“Interrupt w Javie jest skopane.”

Świat IT jest pełen mantr/prawd objawionych, przekazywanych (często w tradycji ustnej) w plemionach programistów. Bezmyślnie powtarzane z pokolenia na pokolenia (często już od uczelni) powodują bezrefleksyjne stosowanie, które może wywołać w najlepszym przypadku więcej szkody niż pożytku. W najgorszym: totalną klapę za wagony dolarów. Kontekst jest nieodzowną otoczką każdej mantry. Pozwala bez pudła odróżnić właściwe użycie od nadchodzącej plajty.

Istnieje 10 rodzajów ludzi: ci, którzy już logują i ci, którzy dopiero będą. ;-) Ale co może być fascynującego w logowaniu? To tylko dodawanie wpisów z określonym poziomem do jakiegoś pliku w /var/log, po co w ogóle ta prezentacja? Cóż, zwyczajne dodawanie linii do /var/log i śledzenie ich przy pomocy tail -f albo przeszukiwanie grepem jest takie… w stylu lat osiemdziesiątych i niewydajne. Poznajcie Grayloga: scentralizowany i rozproszony system do zarządzania dziennkami. Narzędzie, które pozwli ci gromadzić, przetwarzać, analizować dzienniki z wielu źródeł: sysloga, twojej aplikacji, Apache/nginxa, bazy danych, firewalla, itd. Umożliwi przeszukiwanie wszerz i wzdłuż, analizowanie wpisów bez względu na język/technologię, które te wpisy poczyniły. I robi to dobrze. I jest Open Source. Ta prezentacja jest o pewnych pułapkach, które można spotkać przy prawdziwym wykorzystaniu, szybkim uruchamianiu Grayloga, podłączaniu twoich aplikacji/systemów/serwerów, analizowaniu dzienników. Zasymlujemy ruch, jakieś awarie… Zamysł prezentacji jest taki, że po jej zakończeniu będziesz w stanie w poniedziałek uruchomić Grayloga u siebie w biurze i zacząć czerpać z niego profity. Poziom średnio zaawansowany.

System.out.println("Czy dobrze jest tak logować?");
logger.warn("Oczywiście nie!");

Logować czy nie logować: to NIE jest pytanie!

Postawmy sprawę jasno: wypluwanie wiadomości z dziennika bezpośrednio na wyjście standardowe / konsolę jest nie do przyjęcia.

Wszyscy chcielibyśmy żyć w idealnym świecie, w którym zarówno nasze programy, jak i ich użytkownicy, zachowują się przewidywalnie. Ale rzeczywistość pokazuje coś zgoła odmiennego: mają miejsce wypadki, których nie sposób przewidzieć, zatem powinniśmy zrobić co w naszej mocy, by się na nieprzewidywalne jakoś przygotować. Logowanie jest częścią tych przygotowań. Pozwala szybciej i łatwiej zrozumieć nasze systemy w środowisku produkcyjnym.

Niektórzy uważają, że przepis na bezpieczne hasła w aplikacji [webowej] jest prosty: trochę pomieszać, czasem trochę posolić i gotowe! Tymczasem przechowywanie haseł i innych wrażliwych danych może wymagać nieco więcej zachodu. Garść przykładów tego, czego nie robić i tego, co robić, okraszonych historiami z życia wolnego strzelca. Bezwzględne stosowanie nie jest wymagane, ale pozwala uniknąć typowych niestrawności i nadmiaru kwasu. Prezentowane przykłady będą napisane w Javie, PHP i C, dlatego zrozumie je każdy programista, bez względu na język i poziom doświadczenia. W ramach edycji rozszerzonej przemigrujemy sobie zapuszczoną bazę i puścimy parę benchmarków.