img-responsive

Jarosław Pałka

TBD

Lectures

In Polish JVM bytecode manipulation techniques for JVM "freaks wannabe"

This time something for young JVM Padawans, a workshop on JVM bytecode. Will start with introduction to bytecode structure (opcodes, type checking and such) and execution model, and then will dive into code generation and modification with ASM and Javaasist, how to modify your code on the fly (instrumentation with Java agents), how to survive and don't get mentally injured with Jitescript, will show how to use bytecode manipulation for fault injection tests and performance tracing with Byteman. And if time permits will end up in world of invokedynamic.

In Polish Systematyczny architekt na drodze ku planowanemu postarzaniu

"- Móżdzku, co będziemy robić dziś wieczorem?
- Dodamy następny framework Pinky. Buahahahah"


Czym jest planowane postarzanie produktu? Zapewne wielu z was spotkało się z tym określeniem, oznaczającym planowane działania mające na celu skrócenie czasu życia produktu na rynku, w mniej lub bardziej szczytnym celu. Jak to się ma do tworzenia oprogramowania?


Być może nie tak planowane, jak często chaotyczne, jednak ciągle mamy do czynienia z nieustannym procesem postarzania naszych bibliotek, kontenerów aplikacji, języków, narzędzi i API. oprócz sil wywieranych przez biznes na naszą aplikację, jest ona też po wpływem potężnych ruchów technologicznych, wynikających z nieustannych zmian w trendach tworzenia oprogramowania. Jak efektywnie uniknąć powolnego postarzania się technologicznego naszej aplikacji? Jak uniknąć wysokich kosztów, odkładanych w nieskończoność modernizacji technologicznych aplikacji? Jak uzasadnić wartość biznesową kolejnego "big up front total next generation rewrite"?


A może by tak uwolnić się od hegemoni frameworków, bibliotek i kontenerów i oddać całą władzę w ręce programistów?


Podczas prezentacji opowiem jak ważnym elementem tej strategi są właściwe "abstrakcje w kontekście", jak efektywnie oddzielić "software construction" od "infrastructure code" i "business logic" i dlaczego właściwa architektura, która pozwala podjąć decyzje technologicznie jak najpóźniej, lub nawet odłożyć je na jutro, które nie nadejdzie, może pomóc wam i przyszłym pokoleniom, tych którzy będą musieli pracować z kodem odziedziczonym po was.