A while ago, Gregory Brown brought up the idea to do a “100 Code Examples” challenge:
I liked the idea very much due to several reasons:
- The challenge will probably help me to track/be aware of what I learned
- Breaking down what I learned into small samples will reinforce the knowledge
- It will hopefully also exercise my skills to teach and share knowledge
I won’t put myself under pressure because that’s not the point of the challenge, but if I can manage I will post 1-2 examples on my blog here so the 100 Code Examples should be done in roughly a year.
The topics of the examples will most likely be related to my current work, so mainly SQL, PL/SQL and I will also try to add several examples around utPLSQL.
Every example will come with a very brief explanation of the goal and the critical snippet – hopefully annotated in a way that it’s understandable (I’d really appreciate your feedback on the latter part!).
If it’s possible I’ll also share a link to LiveSQL or a different environment where the example can be run immediately (won’t work with utPLSQL examples so easily).
Example: Primary/Secondary Lookup
We often have Primary/Secondary situations and sometimes we need an easy way to get all related entries based of a single entry’s ID.
In my Star Wars example, the Deathstar operates on several power nodes, some of them have secondary nodes in case the primary power node is no longer working.
We want to create a view one can query with the ID of any power node, no matter whether a primary or secondary, and get the full list of related power nodes as result.
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:
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!
It was a strange moment when Jacek, co-author and maintainer of utPLSQL, asked me last November if I’d like to be part of the next ODTUG CodeTalk series about PL/SQL testing. Not only that I immediately got hit by a strong impostor drive-by and felt way too low-skilled and inexperienced, the host would be Steven Feuerstein, Mr. PL/SQL himself and to that day an unreachable, a bit unreal celebrity for me.
Nonetheless I immediately agreed and tried to behave and communicate as professional and skillful as possible so I wouldn’t embarrass myself in front of the other, highly skilled and seasoned panelists of the talk.
While a good portion of tension and anxiety never faded completely I was very eager and motivated. It was also a great benefit to have Jacek continually encouraging me. Together with him and Pavel I developed a narrative and overall-theme for the talk, prepared a dedicated Star Wars demo-project which could be used for all the different parts of the CodeTalk and also did some slides.
It was fun and I got somewhat confident. I had that picture of myself in mind where I casually type code and explain in an entertaining and understandable way what I’m doing and why it’s important, switching to the prepared slides at some crucial situations. I had already done presentations in the past about technical topics in German which I think were good or at least okay. I knew what I wanted to present, built all the examples myself and therefore felt well-prepared.
We had the first meeting of all participants roughly a week before the event. I suggested to do a dry-run of my part and was encouraged to do so, while Steven would check how much time I’d need.
It was a disaster.
I couldn’t articulate one straight sentence, I mistyped the most basic statements, was constantly stammering and forgot lots of what I wanted to say, replacing it with meaningless jabbering or silence while trying to type.
To make things worse Steven told me that I just used 15 minutes when I had fought myself through about a third of what I wanted to show. I had previously estimated that my part would only take 10 minutes.
I guess it would have been much worse if the Steven, Jacek, Pavel and Stefan wouldn’t have been as kind, positive and encouraging as they were. I got lots of good advice, nonetheless I felt like I’d make them look ridiculous and they knew it.
At that point I knew very well that I had to change my approach completely.
When I started to blog, I set myself the goal to publish one article per month. Maybe it was too ambitious, maybe I’ll have to learn to write shorter blog posts (which might not be possible because the reason I blog is to get a deeper understanding of a topic and reflect on it – something hardly doable with just scratching the surface).
Fact is I wasn’t able to publish for nearly 3 months and while I have some topics rumbling in my head I won’t just throw some unbaked thoughts on a blank page to satisfy a self-made deadline. Or grow a bigger audience.
This kind of little, personal posts is the only thing I’m willing to try (thanks Nate for your encouragement).
At the moment it feels a bit like writing a diary, but I will take it as an experiment.
The thing which kept me from writing for several weeks now is an amazing open source project named utPLSQL. It’s a unit-testing framework for PL/SQL and I started using it about a year ago when I needed a tool to help me getting a very much “grown” legacy project into a stable state.
After finding a bug around windows line breaks (yes, you can develop Oracle databases on Windows) and contributing a fix I had the pleasure to get in contact with the great guys working on the project. They were incredibly nice and helpful and so it was very natural to stay in contact.
Long story short – I finally ended up being the main contributor for the java-api and command-line-interface. It definitely helped that I could build upon a very good foundation and I learned an insane amount of new things which not only helped me in my job but also widened my horizon as developer.
Yesterday we successfully released version 3.1.0 of java-api and cli. I couldn’t include everything I wanted, but we pushed the project further and it was both fun and satisfying. There are some very positive effects of contributing to open source software I experienced, but that’s stuff for a different post.
To finally give this article at least a bit of technical value I will provide some short examples of the improvements of the new command-line-interface.
“If you’re incompetent, you can’t know you’re incompetent … The skills you need to produce a right answer are exactly the skills you need to recognize what a right answer is.”
David Dunning [NYT]
Ever heard of the Dunning-Kruger-Effect? If not, you might want to change that – it’s a great scientific foundation to make fun of people who – for example – use buzzwords, obviously without knowing their meaning. It also gives you some academic ammunition when complaining about the technical incompetence of management, project lead or sales. By using the term and throwing it towards whoever you think is your opponent you can show your superiority. And isn’t it fun to insult people when they don’t even notice being insulted? Clearly a proof of your intellectual dominance, because you don’t fit into the group of incompetent people, do you? You are clever, reflected and open-minded enough not to fall to the traps of human psyche, aren’t you?
For those who don’t want to read through the linked Wikipedia-article, have this (very simplified) description:
The Dunning-Kruger-Effect describes a psychological phenomenon that people who are low-skilled in a certain topic are the most likely to think they know a lot and are skilled at least “above average”. This is due to the fact that their lack of knowledge on a subject also means they can’t recognize how much they don’t understand.
A low-skilled person can overcome these effects by education and increase of knowledge on the topic.
The other side of the effect is, that highly skilled people are the most likely to underestimate their own competence and tend to be less confident about their expertise.
There’s a lot of information and commentary about the Dunning-Kruger-effect on the internet, often in combination with fingerpointing towards extreme examples of the phenomenon (you can read “Trump” between the lines here). Most of us have seen people whose lack of experience and knowledge on the subject they presented made us feel uneasy while they themselves seemed pretty confident and happy.
And I agree that it’s fun to watch the effect on others in its full glory, but if you calm down and think about it, it can suddenly become very serious (I guess that’s the reason why the work of Prof. Dunning and Kruger was awarded by the Ig Nobel Prize for “first making people laugh, then think”).
The problem is – this is not a phenomenon reserved for others. And it’s not something only present in ridiculous and extreme examples.
I already described in a previous post why databases are different to applications from a development perspective. The most impactful difference in my opinion is, that you can deploy applications by state. You pick a certain point in your version control system, build your application and have a certain state of your application at hand.
Best case, this state is backed by a number of self-tests and has a unique version number (well, it has one by the hash of your specific commit). You take that build and can deploy it, no matter if your customer had a different version (state) of your application installed or not.
Of course this is simplified, there might be external APIs, libraries, configuration files or – who had thought – databases which prevent you from easily switching application states, but normally such constraints are relatively few.
Databases are different. You can’t preserve state in a database once it’s shipped to a customer. The moment you give it out of your hands, a database starts to change its state continuously. You cannot simply “install” a new version of your database schema on a customer database – there’s data to be preserved and in most cases it’s not even possible to clearly separate schema and data.
And yes, data changes for applications, too, but in my experience database schema is usually much tighter coupled to the data than applications are (which makes sense, doesn’t it?).
So, how do we overcome these difficulties, especially if we are aiming towards frequent releases and agile, collaborative development? Continue reading