#phpruhr23

A soccer match lasts 90 minutes. Playing time, of course, does not include the break, for example. But there may still be injury time – or extra time? And if there is a penalty shootout, does that count towards the playing time or not? Even a simple example like this shows how difficult it is to get business rules or requirements clear, especially if you are not aware of the different views and perspectives that actually exist or must exist. In this workshop we will get to know different modeling techniques and try them out in practice in the form of role plays and collaborative modeling sessions. It is not so much about executing single methods “by the book”, but to understand them as a toolbox of possibilities, with the help of which we create good models. After all, “All models are wrong, but some are useful”. We will follow basic principles of Domain-Driven-Design like Bounded Contexts and Context Mapping and will only model in this workshop. Since we are not writing software, participation in this workshop is not only interesting for software developers, but for all roles involved in the creation process of IT solutions. — Note to organizers: I can also do the workshop in English. If you prefer this, let me know and I will provide you with a translated abstract.

This a slightly controversial topic, that brings a lot of discussions and opinions, should or should we not, aim for 100% coverage of our code? Well, there is a theory, and there is a practical study and observations. Luckily, with years of experience in writing 100% unit tests covered code, I can finally summarize to the audience what is the benefits, what is the cost, and what to expect. And finally, why are we aiming for this number 100 and not any less?

Well designed and performant API’s are one of the key aspects of good and reliable application systems. Especially when kicking of an API system it is really hard to setup and define all boundaries that are necessary to build a futureproof API. Changes later on can be time consuming and of course expensive. Therefore it is extremely important to plan the API design beforehand and to use best practices and patterns from the industry. In this session I will guide the listeners through the creation process of an API and will introduce and explain all important parts that constitute a battle tested and robust API. Things like middleware layers, security tokens are only some key points that will be presented in stage.

If you are stuck in the “we don’t have time to write tests” denial stage of grief, you should attend this talk. Together, we will work our way through anger (“why does my code not work”) , bargaining (“please, can somebody else take care of testing”), and depression (“I have a high code coverage, but even that does not help”). When we reach the “acceptance” stage, you will have understood why your appreciation of tests was flawed, and how to fix this. Don’t forget to bring a towel.

Hey, everyone is doing DevOps! We absolutely have to hire DevOps people, too! What is wrong with these and other statements about DevOps and what DevOps really is, you will learn in this talk!

How often have we heard somebody talk about their existing monolith, or ask the question “how to break down the monolith?”. Turns out: with PHP, we have never really built monoliths, because our applications were never compiled down to single executable files. Instead, we have always deployed a collection of source files – which in fact already looks a lot like microservices. So it does not surprise that our decisions to “break down the monolith” do not yield expected results – most of our prerequesites are plain wrong. It’s time to take a fresh look at how we can deal with PHP legacy code, and fix our distributed monoliths.

Software development is more than just writing down code. It combines logical thinking, creativity and craftsmanship. Craftsmanship? Under the guiding principle of the Software Craftsmanship movement, we shed light on the craftsmanship part of software development, the importance of certain tools and regular training in the form of code katas. We learn why test-driven development is actually very cheap and how Tetris and broken windows affect our software quality.

I will show in my talk (using live-coding) how quickly a simple chatbot can be created in PHP. Accordingly, the talk also covers the basics of using ChatGPT (especially “prompt engineering”). And of course in PHP. And without a pretty UI – directly on the console, as nerds love it! In summary: A first introduction to the world of AI for PHP developers and those who want to become one, using a real code example. But also for non-developers who are not afraid of the sight of code, an interesting insight into the background of ChatGPT.