Mateusz Wojczal
CTO Fullstack/DevOps developer.
Gdańsk, Poland
Actions
Full-stack web developer/DevOps since 2005. Starting as an expert in ActionScript, throughout my career, I have gained commercial experience coding in PHP, JavaScript, Node.js, and other technologies that nobody remembers anymore, ultimately choosing TypeScript as a versatile language. From the very beginning, I have been involved in creating web applications and websites, desktop applications based on web technologies, as well as small and large-scale multimedia and interactive exhibits. Since 2011, I have been the founder of the software house Qunabu, and since 2019, the Chief Technology Officer at Escola. I am the creator of the first headless open-source LMS system called Wellms. I am the author of the Escola DevTalk and Philosophy of Programming technology podcasts, promoting knowledge sharing. I am a workshop trainer, a judge at hackathons, and a frequent speaker at technology conferences. I am the organizer of the Gdańsk TypeScript Meetup and passionate about functional programming, automated testing, the history of programming, and DevOps. I am an evangelist of Domain Driven Design, a facilitator, and an Event Storming modeler.
Area of Expertise
Topics
Modularny Monolit. Zarządzanie projektem Open Source przy użyciu github i github actions.
Prezentacja "Modularny monolit: Zarządzanie dużym projektem Open Source przy użyciu GitHub i GitHub Actions" skupia się na omówieniu strategii zarządzania dużymi projektami Open Source poprzez wykorzystanie GitHub i GitHub Actions, skierowanych na modułowość i efektywne zarządzanie cyklem życia oprogramowania. W ciągu godziny na podstawie własnego projektu postaram się zaprezentować takie zagadnienia jak:
- Czym jest modularny monolith
- Jak zarządza się paczkami Laravel’a
- Testowanie paczek z użyciem narzędzia testbench
Statyczne testy i raportowanie (Codeclimate, phpstan, larastan) oraz pushowanie statystyk do oddzielnego repozytorium
- Testy jednostkowe i raportowanie metryk takich jak linie kodu, nowy kod bez pokrycia, statystyki pokrycia, która dokładnie linia kodu wywołała błąd regresji (codecov)
- Tworzenie bagde’y z metrykami
- Implementacja Testów mutacyjnych (Infection)
- Automatyczne generowanie dokumentacji endpointów -> openapi github pages
- Wersiojonowanie paczek (semver) wraz z Release na packagist.org
- Tworzenie obrazów dockera wraz z Release na docker hub
- Automatyczna konwersja bibliotek Release na npm
- Automatyczne generowanie deklaracji reużywalnych typów, konwersja PHP na TypeScript
- Testy end to end. Narzędzie Playwright
- Helpery usprawniające pracę z paczkami.
- Dokumentacja i skrypty do synchronizacji
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.
Poziom średnio zaawansowany
Paradygmaty programowania w najpopularniejszych językach programowania.
Paradygmaty programowania to określone sposoby myślenia o projektowaniu i pisaniu programów. Każdy paradygmat ma swoje własne podejście do tworzenia programów, które obejmuje specyficzne techniki i narzędzia. Paradygmaty programowania mają duży wpływ na kod źródłowy, ponieważ determinują sposób, w jaki programista organizuje swoją pracę i projektuje rozwiązanie problemu. Różne paradygmaty programowania wymagają od programisty zastosowania różnych konstrukcji języka, co oznacza, że kod napisany w jednym paradygmacie może wyglądać bardzo inaczej niż kod napisany w innym paradygmacie.
Według ankiety StackOverflow za rok 2022 najczęściej wykorzystywanymi językami programowania są te wieloparadygmatowe. Co to dokładnie dla nas oznacza i czy wśród najpopularniejszych języków istnieją jeszcze takie które reprezentują jeden konkretny paradygmat?
Programowanie funkcyjne w PHP
Języki używające programowanie funkcyjne de facto wprowadzają nowe funkcjonalności do innych języków, nie omijając PHP – Garbage Collection obecny w PHP był już w pierwszych wersja Lispa w 1958 roku (tak, 64 lata temu!) Niestety w PHP 8.1 nie ma jeszcze Generyków, ale pojawiły się inne funkcjonalności. Chciałabym przedstawić tą cześć konceptów używanych w FP w kontekście PHP oraz opowiedzieć w skrócie historię funkcyjnego programowania.
Programowanie funkcyjne w JavaScript/TypeScript
React aktualnie jest najpopularniejszym JavaScriptowym frameworkiem do budowania aplikacji. Niestety większość z mało i średnio zaawansowanych programistów nie zna podstaw paradygmatu na którym oparty jest ten silnik czyli Programowania Funkcyjnego, który istnieje w środowisku IT o wiele dłużej niż Programowanie Obiektowe. W swojej prezentacji postaram się pokazać skąd się takie podejście wzięło, jakie są jego założenia i dlaczego twórcy Reacta wybrali tak a nie inaczej.
ISO 27001 w 6 tygodni. Case Study
ISO 27001 to międzynarodowy standard zarządzania bezpieczeństwem informacji, określający praktyki zarządzania bezpieczeństwem informacji, które pomagają w zapewnieniu ochrony danych i systemów informatycznych wykorzystywanych w procesie tworzenia oprogramowania.
Według iso-docs średnie wdrożenie i uzyskanie certyfikatu ISO 27001 zajmuje od 6 do 12 miesięcy. Opowiem w jaki sposób można to uzyskać w 6 tygodni.
Testy mutacyjne TypeScript
Prezentacja dotycząca testów mutacyjnych w TypeScript skupia się na wprowadzeniu do testowania jednostkowego, wyjaśnieniu roli testów mutacyjnych jako narzędzia uzupełniającego, oraz omówieniu korzyści i narzędzi z nimi związanych. Prezentacja obejmuje również praktyczne przykłady i case studies, pokazując jak testy mutacyjne pomagają w wykrywaniu błędów i refaktoryzacji kodu. Całość ma na celu zachęcić do stosowania testów mutacyjnych w celu zwiększenia jakości kodu i pewności w procesie tworzenia aplikacji TypeScript.
Jak odpowiednio dobrać drivery technologiczne?
Prezentacja dotycząca doboru driverów technologicznych skupia się na kluczowych czynnikach i dobrych praktykach, które pomogą w odpowiednim doborze technologii dla projektu. Rozpoczynamy od zrozumienia kontekstu biznesowego i wymagań projektu, aby lepiej dopasować technologię do celów biznesowych. Następnie omawiamy proces oceny dostępnych technologii, uwzględniając czynniki takie jak wydajność, skalowalność, społeczność i dokumentację. Analiza ryzyka i bezpieczeństwa jest również istotnym elementem, wraz z uwzględnieniem dostępności i umiejętności zespołu. Na zakończenie prezentacji przedstawiamy zestaw dobrych praktyk, takich jak prototypowanie, testowanie proof of concept i analizę przypadków użycia, aby pomóc w skutecznym doborze driverów technologicznych. Całość ma na celu podkreślenie znaczenia odpowiedniego doboru technologii i zachęcenie do stosowania omówionych czynników i praktyk w procesie wyboru technologii.
Summary:
The presentation on selecting technological drivers focuses on key factors and best practices to aid in making informed technology choices for a project. It begins by understanding the business context and project requirements to better align technologies with business goals. The evaluation process for available technologies is then discussed, considering factors such as performance, scalability, community support, and documentation. Risk analysis and security considerations are also essential, along with the team's availability and skills. Finally, a set of best practices, including prototyping, proof of concept testing, and analyzing use cases, is presented to assist in effectively selecting technological drivers. The overall aim is to emphasize the importance of proper technology selection and encourage the application of the discussed factors and practices in the technology selection process.
Unleash the Power of Modular Monoliths for Seamless CI/CD
Wellms is the world's first open-source headless Learning management system (LMS) that puts developers as first class citizens. It is written in modern, strongly typed PHP8 & TypeScript, fully customizable and 100% focused on delivering a performant and powerful API. Those are some features how Github is helping its success
- modular monolith
- modules in github context
- Continuous Integration and Delivery with GH Actions
testing packages with various tests.
- Static Testing with tools like Codeclimate, SonarQube, etc
- Security testing
- Whitebox Unit, Integration and Behavior-driven development testing
- Black box e2e testing
- Testing your tests with mutation testing
- Testing accessibility in headless architecture
- Releasing modules to registries (npm, docker hub, packagist)
- Documenting API endpoints with OpenAPI (ex swagger) with github pages
- Documenting whole project with github pages and vuepress
- Using additional tools like automatic generation of TypeScript files from backend projects.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top