Tomasz Zieliński opowie, dlaczego po pracy warto hobbystycznie podłubać przy własnej aplikacji. Jego mobilny projekt Transportoid zdobył setki tysięcy użytkowników, zaś on sam wygrywał nagrody, trafił do telewizji, prowadził głośny spór o dostęp do informacji publicznej i opowiadał o nim w Parlamencie Europejskim.

JVM towarzyszy mi w projektach od prawie 15 lat. Łączą nas dobre chwile i złe wspomnienia, którymi będę się chciał z wami podzielić. Opowiem o 4 jeźdźcach apokalipsy którzy zamieszkują maszynę wirtualną i od czasu do czas dają znać o swojej obecności. Podstępnie zakradają się do zakamarków waszego systemu operacyjnego, procesorów i obszarów pamięci RAM, powodując że wasza aplikacja na produkcji zachowuje się jak wygłodniałe acz powolne zombie. Kim są Ci odrażający jeźdźcy? To GC, operacje I/O, wątki i interpretowany bytecode. Postaram się na przykładach pokazać narzędzia dostępne w JDK jak i w waszym systemie operacyjnym, które pozwolą wam rozpoznać z którym z nich macie do czynienia a także techniki radzenia sobie z spadkiem wydajności. Prezentacja będzie pokazywać ekstremalne przypadki, które wymagać będą nietypowych technik, jednak wszystko odbędzie się zgodnie z zasadami sztuki a pokazane rozwiązania oparte będą na API i technikach dostępnym w każdym JDK. Więc o czym tak naprawdę będzie? Usłyszycie słów kilka o „off-heap memory”, gdy wszystkie rozsądne techniki optymalizacji GC zawiodły. A także o „non-blocking IO” i „zero-copy buffers”, gdy już klasyczne IO zawiodło. Nie obędzie się bez łagodnego wstępu do java.util.concurrent.atomic.* i „lock free programming”, gdy już nie radzicie sobie z ilością wątków. A na koniec opowiem o „just-in time compilation” i jak pisać kod, który jest „JIT friendly”. To wszystko i więcej o wydajności i optymalizacji JVM, dla waszej radości i uciechy przyszłych pokoleń.

Domain-Driven Design, Test-Driven Development, Behavior-Driven Development, Data-Driven Design, Data-Driven Development, Use Case-Driven Design, Use Case-Driven Design, Architecture-Driven Design, Architecture-Driven Development, Model-Driven Development, Agile Model-Driven Development i tak dalej i tak dalej… Czy coś ci to przypomina? Mnie tak. Kiedyś mówiliśmy ze znudzeniem „$%!@ yet another framework!”. Teraz trzeba powiedzieć z tym samym znudzeniem: „%$!@ yet another mental framework!”. W trakcie prezentacji chcę pokazać, w jaki sposób pogoń za kolejnymi x-Driven Design, y-Driven Development wypacza to, co jest naprawdę ważne w programowaniu czyli umiejętność rozwiązywania problemów. Zajmiemy się również dość ważnym pytaniem: jaka jest właściwie relacja wszystkich tych „mental frameworks” do rzeczywistości, z którą spotykamy się na co dzień.

Kim jest architekt? Czasem dostajesz taki tytuł zamiast podwyżki. Czasem jest to powód do dumy a czasem nie. Zastanowimy się od innej strony: czasem bywasz architektem – co powinieneś wiedzieć i umieć? Podejdziemy również coachingowo: co ma w głowie architekt i jak rozumuje i podejmuje decyzje? Problem jest taki, że są w naszej branży trzy słowa, których nikt nie rozumie: architektura, moduł i komponent. Pokażę jakie są poziomy architektury, jak je wizualizować, po co i jakie wprowadzamy ograniczenia na każdym z poziomów. Zastanowimy się też kiedy da się zakładać z góry architekturą a kiedy może ona wyłaniać się z niskopoziomowych decyzji w kodzie. Aby móc wyłaniać architekturę poznamy nieco wzorców architektury aplikacyjnej i systemowej oraz kodowania w notatniku. Tak przy okazji: czy REST ma zawsze sens?