I’m a speaker at DOAG 2018!

DOAG-2018-Konferenz-Ausstellung-Banner-800x643-Referent-Twitter

I am very happy and grateful to announce that I will be speaking at this year’s German Oracle user conference (DOAG 2018).

It’s my very first experience as a conference speaker (even my experiences as conference visitor are quite limited) and although there is some tension it’s really a dream come true for me: I’ve always enjoyed teaching and sharing the things I’ve learned in my career as software developer.

The talk will be in German (phew, big plus for me!), but I’ll give a brief translation of the content:

Part 1: What are automated self-tests and what are they good for? Why should I invest time and energy to develop automated self-test for my database? What’s the benefit for my project/product?

Part 2: Practical advice based on a sample-project (Star-Wars setting!) how to introduce self-testing with the free open source framework utPLSQL v3:

  • Demonstration of techniques and strategies to get your existing (legacy-)projects tested
  • Examples for meaning- and useful tests and mistakes you should watch out for
  • Simple example how to develop new functionality via test-driven-development
  • Thoughs on the testing “mindset”
  • Presentation of features utPLSQL provides to help you develop reliable and automatable self-tests

Yes, of course I will talk about utPLSQL. It’s a great framework and self-testing is still  pretty underdeveloped in the database corner (at least that’s my impression).
And there is of course one very important question:

going_to_present_in_costume

If you want to find out, you should join me on Wednesday, 21th of November, 15:00 in Nuremberg (for the conference program is now online, you can mark my talk here as favourite so you don’t miss it).

Big thanks to Jacek Gebal and Ben Fischer, who both supported and encouraged me to apply in the first place. Sabine Heimsath was amazingly helpful and supportive with many questions I had as newbie during call for papers and afterwards (newbies: You would be astonished how many “pros” are extremely responsive, kind and helpful if you reach out to them in a mannered way).
I’m also very grateful that my amazing employer Smart Enterprise Solutions will support me, which is not natural for such a small company.

I am looking forward to meet some of you in Nuremberg!

 

Advertisements

BeckDesignRules for Database Developers Part 1: Passes the tests

Software design and software architecture are topics which are sometimes associated with distant, slightly mad geniuses, living in an ivory tower and regularly throwing UML diagrams to their ground crew of “normal” developers. They are seen as arcane knowledge which can only be absorbed by the most experienced, most talented “10x developers“, “rockstars” and “ninjas”.

From my experience, this point of view couldn’t be farther from reality. On the contrary I see software design and architecture as fundamental parts of any kind of development work. The moment we start writing code, we will make decisions and are creating software design, no matter if we are aware or not.
Of course there might be guidelines, there might be an architecture given by others, there might even be detailed API descriptions and an abstract design which paints the big picture, but in the end the little, daily decisions will have a huge impact on the result.

Understanding the rules of good software design is therefore a topic which affects developers of any skill and experience level.
Knowledge in that field will be extremely beneficial for every task related to software development.

Four Rules of Simple Design

Kent Beck, developer of Extreme Programming (XP) and Test-Driven Development (TDD), came up with four rules of simple software design in the late 1990s, which Martin Fowler expresses like this:

BeckDesignRules

Martin gives a great, comprehensible description in his article about the “BeckDesignRules” which is also the source of the picture above.

I will try to take a deep dive into these rules, their spirit and how they can be practically done in database development. There is also much personal interpretation from my side and I’m not entirely sure whether Kent Beck would agree on all of my thoughts (of course I hope so).

I will split this up into several blog posts (you wouldn’t believe how hard it is anyway to keep my personal goal of one post per month) and today’s post will cover the first, probably most important and impactful of Beck’s design rules:

Passes the Tests

This one is clearly about Unit-Testing, Test-Driven Development and lots of green lights in your testing report, isn’t it? It means that good software design must adopt specific patterns from XP or other agile methodologies, right?
Continue reading

Strongholds of confidence: self-testing your database

Software-Testing has always been a very important topic in professional development because software – unlike for example buildings – changes a lot from the first line of code to release and from there during its whole lifetime. Due to that constant change and its complexity every honest developer will have to accept someday, that there is no software without bugs.

The rise of agile methods, ideas like continuous integration and the urge to have more frequent releases led to an even stronger focus on modern testing-strategies (interesting blog post about correlation of release frequency and agile practices – especially including automated testing).

Unfortunately there is some kind of “holy war” about some programming techniques around testing (I will write a bit more on that in the last chapter of this blog post), but nonetheless the need for automated self-testing (be it system-, integration- or unit-testing) in todays software development is real and uncontroversial among the experts. Therefore I will use the general term of “self-testing” in this article, concentrating on the very basic idea and trying to give an introduction on how it can be done in database projects. In my impression still many of today’s database projects don’t even know about the basics of self-testing, so let me try to show you the benefits without nit-picking about specific techniques.

Continue reading