Adam Roman – „Dlaczego AI nigdy nie zastąpi ludzi w IT?”
Adam Roman – informatyk, pracownik naukowy w Instytucie Informatyki i Matematyki Komputerowej Uniwersytetu Jagiellońskiego, gdzie kieruje Zakładem Inżynierii Oprogramowania. Ekspert w zakresie inżynierii jakości oprogramowania. Jako reprezentant UJ, w ramach ISO bierze udział w pracach nad normą ISO 29119 – Software Testing Standard. Współautor sylabusów ISTQB: Poziom podstawowy, Analityk testów oraz Techniczny analityk testów. Autor wielu artykułów oraz książek z zakresu testowania oprogramowania. Prelegent na wielu konferencjach, m.in. EuroSTAR, Testwarez, Code Europe. Wiceprezes zarządu Stowarzyszenia Jakości Systemów Informatycznych.
„Dlaczego AI nigdy nie zastąpi ludzi w IT?”
W swoim wystąpieniu omówię kluczowe aspekty, które sprawiają, że sztuczna inteligencja (AI) mimo swoich zaawansowanych możliwości, nie jest i – co ważniejsze – nigdy nie będzie (!) w stanie całkowicie zastąpić ludzkiej pracy, szczególnie w kontekście tworzenia i testowania oprogramowania. Tę być może dla wielu kontrowersyjną tezę poprę argumentami z zakresu nauk ścisłych, a także filozofii. Argumentacja będzie oparta na głębokich i wysoce nietrywialnych rezultatach z zakresu logiki i ogólnej metodologii nauk, ale przedstawię ją w sposób zrozumiały dla każdego, ponieważ idee stojące za tą argumentacją są bardzo proste do zrozumienia.
Łukasz Reszke – „Zapomniana sztuka programowania obiektowego”
Na codzień pracuje w @arkency gdzie ratujemy projekty klasy legacy i szerzymy wiedzę o dobrych praktykach w świecie Railsowym. Wierzę w to że zrozumienie problemu i zaprojektowanie modelu dostosowanego do jego rozwiązania pozwala na stworzenie dobrego produktu dla biznesu. Produktu, który będzie zrozumiały i latwy do rozwijania dla innych programistów. Stad naturalnie ciągnie mnie do takich technik jak DDD i EventStorming.
„Zapomniana sztuka programowania obiektowego”
W bezkresie narzędzi i frameworków których musimy się uczyć jako programiści zdarza nam się zapomnieć o fundamentach. Jednym z nich jest powoli zapominana sztuka programowania obiektowego. Na nowo odkryjemy kanony jej piękna. Razem przypomnimy sobie zasady, którymi warto się kierować aby nie popełniać programistycznego faux pas. Nie będziemy ich cytować niczym na rozmowie rekrutacyjnej. Zamiast tego skupimy się na konkretnych przykładach.
Mike Wojtyna – „My design is better than yours: bridging the gap between tactical modeling and business”
I’m a software architect with a passion for creating great products 🌱. In my work I combine business and technical skills to deliver outstanding results to my clients. Domain-driven design & Test-driven development are some of my favorite tools. My code is clean and easy to modify, thanks to the modular, loosely coupled design achieved by continuous TDD iterations backed by a deep understanding of business needs.
„My design is better than yours: bridging the gap between tactical modeling and business”
Engineers have a tendency to create emotional connections with their models. At best, this can end up with a lot of pointless discussions, at worst escalate to nearly-religious wars in the defense of „”the only right model”. So… Are we doomed to repeat these nonsensical fights all the time? Fortunately, there’s an entity that can decide which model is better. It’s called business.
During this presentation I’m going to show you how you can avoid analysis paralysis, pointless discussions, common design pitfalls and creating overengineered, often totally unnecessary code. Together, we’ll bridge the gap between tactical modeling and true business drivers.
Maks Operlejn- „LLM 101 – wprowadzenie do świata modeli językowych”
Jestem absolwentem Informatyki i Uczenia Maszynowego na Politechnice Gdańskiej, obecnie pracuję jako Machine Learning Engineer w firmie deepsense.ai. Zawodowo i prywatnie skupiam się głównie na dużych modelach językowych i ich szerokim zastosowaniu. Zajmuję się wdrażaniem spersonalizowanych systemów RAG (wykorzystując zarówno modele komercyjne, jak i open-source), a także opracowywaniem i testowaniem agentów programujących. Współpracowałem także z twórcami biblioteki LangChain, skupiając się na kwestiach związanych z prywatnością danych wejściowych dla modeli językowych. Poza pracą odczuwam ciągłą potrzebę poznawania nowych kultur – przejawia się to głównie w podróżach i nauce języków obcych. Dodatkowo, kompulsywnie kupuję książki, na których czytanie często brakuje mi czasu 📚.
„LLM 101 – wprowadzenie do świata modeli językowych”
Nieustający hype na wielkie modele językowe (LLM) i ich niewątpliwa użyteczność sprawiły, że dla wielu ludzi korzystanie z nich stało się codziennością. Studenci z pomocą ChataGPT piszą swoje prace magisterskie, amatorzy kuchni uczą się piec chleb (co, szczerze mówiąc, niezbyt polecam), a ja sam upewniam się, że nie popełniłem głupich błędów stylistycznych w tym opisie. W świecie programistów, modele od OpenAI i konkurencji są użyteczne do rozwiązywania prostych zadań – Stack Overflow nie ma już monopolu w tym zakresie. Co więcej, Dolina Krzemowa i nie tylko, pełne są startupów, które – z większym lub mniejszym sukcesem – zalewają rynek produktami z „AI” w nazwie.
Mimo powszechnej obecności LLM w naszym otoczeniu (a szczególnie na LinkedIn, ugh 🙄), niewielki odsetek ludzi faktycznie wie, co kryje się za ich działaniem. Spróbuję zatem zarysować ten temat i odpowiedzieć na kilka kluczowych pytań:
- Jak działa architektura uczenia głębokiego będąca podstawą każdego LLMa (Transformery, multi-head attention)
- Dlaczego LLM tak dobrze wchodzi w interakcję z użytkownikiem, formatując odpowiedzi odpowiednio do potrzeb, a jednocześnie potrafi unikać pytań natury… mało etycznej? (RLHF)
- Czy możemy wytrenować własny LLM do naszych celów? (modele open-source, fine-tuning)
- Jak LLM może korzystać ze źródeł zewnętrznych (np. z internetu lub firmowego Confluence), nie mając do nich dostępu w czasie treningu? (bardzo krótko o RAG)
Postaram się przedstawić ten temat w sposób jasny, intuicyjny i bez wchodzenia w złożoną matmę – zapraszam!
Jarek Pałka – „Z manuskryptów starożytnych inżynierów – bazy danych”
Od ponad 20 lat w branży IT jako administrator baz danych, programista, architekt, manager
i „inżynier od spraw katastrof”.
Brałem udział w małych, średnich i nonsensownie dużych projektach, prowadzonych
zgodnie zasadami „waterfall”, Agile oraz przy braku jakichkolwiek metodyk – z tym samym
zawsze skutkiem. Wszystko to doprowadziło mnie do wniosku, że nieważne co robisz,
ważne byś robił to dobrze, w najprostszy z możliwych sposobów i przy użyciu właściwych
narzędzi, które wykonają pracę za Ciebie. W międzyczasie dałem się porwać ideom TDD
oraz Software Craftmanship, do granic możliwości wyeksploatować tak piękne w swej
prostocie pomysły jak REST i NoSQL. Porzuciłem je, by zgłębić tajniki „system thinking” i
zachwycić się siłą, jaką niesie ze sobą „metafora” oraz by odkryć, że rządzą nami te same
prawa „natury”.
Niepokorny wyznawca kościoła JVM, badacz bytecode’u i JIT oraz wszelkiej maści
parserów, interpreterów i kompilatorów. Na co dzień walczący o lepszą wydajność w Neo4j.
Od czasu do czasu można usłyszeć moje niskiej jakości żarty na temat architektury na
konferencjach w Polsce.
W wolnych chwilach trener w Symentis, autor bloga na
http://geekyprimitives.wordpress.com/ oraz samozwańczy dyktator w radach programowych
wielu konferencji.
„Z manuskryptów starożytnych inżynierów – bazy danych”
Kolejne warstwy frameworków, abstrakcji i pudru. Pozwalają nam dostarczać skomplikowane rozwiązania w skończonym czasie. Nasi dziadkowie mogliby nam pozazdrościć łatwości z jaką udaje nam się budować złożone systemy.Jednak często zapominamy o tym jak wiele zawdzięczamy starożytnym inżynierom. Spróbujmy poznać ich tajemnice, zapisane w manuskryptach.Bazy danych są sercem naszych systemów, gdyż dane są krwiobiegiem naszych organizacji.Zabiorę Was w cudowną i nostalgiczną podróż przez świat architektury baz danych. Rozłożymy bazy danych na poszczególne komponenty by w pełni docenić piękno tych cudów inżynierii.Zaczniemy od szybkiego kursu historii najnowszej, czyli dlaczego i kiedy pojawiła się koncepcja baz danych.By następnie przejść do technik organizacji danych na dysku. Poznać tajniki zarządzanie pamięcią i techniki zapewnienia izolacji zapisów czyli locking protocols.Dowiesz się jak bazy danych zapewniają spójność i trwałość danych z pomocą „transaction logs” i „write-ahead logs”. Nie pominiemy też dyskusji o indeksach (w tym B+tree), wykonywaniu zapytań i optymalizacji planów zapytań.Mam nadzieję, że ta prezentacji pozwoli wam lepiej zrozumieć jak budować aplikacje i optymalizować wydajność systemów. dzięki zrozumieniu jakie prawa rządzą światem baz danych.Będzie też czas na filozoficzne rozmyślania o sensie istnienia i odpowiedź na pytanie dokąd zmierzamy.
Piotr Przybył – „GenAI, vector / semantic / hybrid search, RRF, NLP, LLM, RAG, FUD, FOMO, and other buzzwords”
Software Gardener, Java Champion, Testcontainers Community Champion.
„GenAI, vector / semantic / hybrid search, RRF, NLP, LLM, RAG, FUD, FOMO, and other buzzwords”
Here you are: a Java developer with some experience, and everyone around seems to be talking about LLM, NLP, RAG and other AI related stuff. From one end you’re somewhat afraid of this, because JPA is nowhere among these acronyms and they say AI might take your job next month. OTOH you’re also tired, because every news, every social platform is bombarding you with all flavours of AI so much that you’re scared to open your fridge (who knows, AI might be among groceries now?)
Wouldn’t it be great to have the buzzwords deciphered, so that you can reason about them without having a PhD in AI or data science first?
Certainly! Please join me for this talk, fellow Java developer, to see how technologies you already know (like Elasticsearch), and some maths, can help you tackle all this with no big fear.
Mateusz Wojczal – „O czym nie powie nam metryka 100% Code Coverage?”
Full-stack web developer/DevOps od 2005 roku. Zaczynając jako ekspert od ActionScript przez całą swoją karierę zdobywał doświadczenie komercyjne kodując w PHP, JavaScript, Node.js i innych technologiach, o których już nikt nie pamięta, aby ostatecznie wybrać TypeScript jako wszechstronny język. Od samego początku związany z tworzeniem aplikacji i stron internetowych, desktopowych opartych o technologie webowe, a także mało i wielkoformatowych ekspozycji multimedialnych i interaktywnych. Od 2011 założyciel software house Qunabu, od 2019 Chief Technology Officer Escola. Twórca pierwszego headlessowego open sourcewego systemy klasy LMS o nazwie Wellms. Autor podcastów technologicznych Escola DevTalk i Filozofii programowania, promotor dzielenia się wiedzą. Trener warsztatów, Juror hackatonów i wielokrony prelegent konferencji technologicznych. Organizator Gdańsk TypeScript Meetup, Zafascynowany funkcyjnym programowaniem, testowaniem automatycznym, historią programowania i DevOpsem.
„O czym nie powie nam metryka 100% Code Coverage?”
Metryka 100% pokrycia kodu (code coverage) stała się często używanym buzzwordem w świecie rozwoju oprogramowania, sugerującym doskonałą jakość testowania. Jednak warto pamiętać, że osiągnięcie pełnego pokrycia kodu nie gwarantuje, że wszystkie możliwe przypadki testowe zostały uwzględnione. Skupienie się wyłącznie na metryce 100% code coverage może prowadzić do nadmiernego skomplikowania testów lub tworzenia testów, które w rzeczywistości nie sprawdzają istotnych aspektów kodu. Ważne jest, aby używać metryki code coverage jako jednego z wielu wskaźników jakości testów, równocześnie skupiając się na znalezieniu i eliminowaniu rzeczywistych słabych punktów w testowaniu i zapewnieniu kompleksowego sprawdzenia logiki i funkcjonalności aplikacji.
Testy mutacyjne to rodzaj testów oprogramowania, które polegają na wprowadzaniu celowo wprowadzanych błędów (tzw. mutacji) do kodu programu w celu oceny jakości testów jednostkowych. W ramach testów mutacyjnych, program jest poddawany serii mutacji, a następnie uruchamiane są testy, aby sprawdzić, czy testy wykryją te zmiany.
Fuzz testing, znane również jako testowanie oparte na przypadkowości, to technika testowania oprogramowania, która polega na wprowadzaniu losowych, zniekształconych lub nieprawidłowych danych wejściowych do programu w celu wykrycia błędów lub luk w zabezpieczeniach. Fuzz testing pozwala na zautomatyzowane generowanie ogromnej liczby testów, co może pomóc w wykryciu trudno dostrzegalnych błędów w oprogramowaniu.