How to become a DevOps? @ University of Silesia (11.04.2017)

DevOps (a clipped compound of “software DEVelopment” and “information technology OPerationS“) is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes.[1][2] It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.[3][4][5]


How to become a DevOps?

What DevOps usually are responsible for? Why such a role starts to be more and more important during last time period? This speak is an approach to answer these questions. Its a talk for you if you want to find out if becoming a DevOps is right for you. You will also find out what technologies are used on daily basis and how to start career as a DevOps in world of complex systems and fast, secure deployments. Basically if this blog post looks like something interesting for you, then thinking about become a devops is a good idea.

Presentation will be held in polish.

When and Where?

11.04.2017, 14:00 – 15:30

University of Silesia, Faculty of Computer Science and Materials Science
Institute of Computer Science
41-205 Sosnowiec
Będzińska street, 39
Room B-4

Here you can find official info about event:żące/1030

How to become a DevOps? @ University of Silesia (11.04.2017)

Evolving Architecture @ 4Developers 2017

4Developers Festival, 03.04.2017, Warsaw

Track: Application Architectures II


Hotel Sangate Airport *** 
17 Stycznia Street No. 32
02 – 148 Warsaw

Here you can find more info about this great event 🙂


During development phase its very easy to cross the design boundary – we want to take care about all possibilities and potential changes that can happen in our project. On the other hand when we are under the time pressure we take shortcuts which could in the end increase cost of even simple changes. How to deal with “overdesign”? How (at the same time) don’t close for improvements and changes? When we should make crucial technical decisions and when accept technical debt? This session is about true stories, mostly about huge mistakes, but also sometimes about decisions which in the end were very successful. The session for all who don’t want to end up with project that need’s to be rewritten to add a new button. The session for all who cares.

Still not sure?

This talk is a result of last 6 years of my professional experience with more than 10 projects. And within these projects I was able to see bad things and of course … really bad things. After each of them I’d got a feeling that I will never make the same mistake again. What I’m really proud of – I kept that promise! I was making new mistakes each time 🙂 I dealt with “over-designed” systems and “under-designed”. I’ dealt  with “company frameworks” and “our own solution!”.

I would like to do retrospective about all good and bad choices that have been made in all of these projects. I really do believe that with every mistake that has been made we can be closer to deliver better software with more fun and excellence…

There is one great thing about “standard” design patterns (book by gang of four): each of them is not only a description of implementation and its name, but also description of pros&cons. This is in my opinion the most important thing about them. You have solutions with ready on plate information about their limits and possibilities. Knowing the  limits gives you much more power to deliver better and more flexible software. It’s not only about delivering solutions. It’s about providing software that can be adopted to needs, however without wasting time when it’s not necessary.

And this talk is about my vision how to find this balance in real world projects.


I did very similar talk a few weeks ago in Gliwice. This time it will be slightly different with lot of improvements.

Evolving Architecture @ 4Developers 2017