#VDC19 Voxxed Days CERN 2019
This was the first time I attended to Voxxed Days. I was also speaker there for a short live-demo talk during lunch. And that was an awesome experience and the occasion to meet people I don’t see in Oracle User Groups conferences. Organized at CERN, the speakers were able to visit the CMS experiment (A 14,000 tonnes 100 meters underground detector, observing the result of the collision of protons accelerated in the LHC), and that probably helps to motivate the best speakers to come. And kudos to the colleagues at the organization of this event.
The event was sponsored by Oracle Groundbreakers. Oracle Switzerland offered some Cloud trials where you don’t have to put your credit card number and that’s a really good initiative, finally.
And look at the end of this post the video made by Romy Lienhard during the CMS visit and the conference.
Keynote: Robert C. Martin, aka Uncle Bob
I really enjoyed hearing Uncle Bob message. I put quotes in bold here. Today, many organizations push to faster releases, more and more feature, and unachievable deadlines. But that, unfortunately, lowers the quality of software delivered.
If we value only the lines of code, the frequency of releases, and the number of features, this apparent productivity is:
unstable productivity
and will fail one day. But who will be responsible for this failure? As a software engineer, you must not ship shit. You may think that you were forced by your manager’s unreasonable deadlines. But remember that you were hired because you know and they don’t. You must be professional and say no. Frequent releases are good only when they ensure that you ship only what works and will be stable. IT professionalism must ban the ship of code that will fail and be unmaintainable.
With my DBA eyes, I see many applications that fail to scale with more users, more data, or that break when a database upgrade reveals a bug that was hiding there. This can be solved only at the root: the quality of the design and code. Do not rely on the UAT to find those design weaknesses. Who tests concurrent updates during UAT? Who tests with the future volume of data? Who tests with the future database versions?
The Error of our Ways
A nice continuation was Kevlin Henney’s session. He is famous showing when the magic shell of software applications is failing, displaying the naked error stack, blue screen, like:
That’s part of our software maker professionalism: not only ship new features specified by the business, but also be sure to handle all the unexpected exceptions. When errors break the magic of the GUI, you will give a very bad impression of your company, and you open many security weaknesses.
In the database area, this means that if you are subject to SQL injection (because not using queries parameters with bind variables), and in addition to that you expose the database and the name of tables, then you are giving two axes to break into your system.
Have fun!
Yes, productivity can be increased by having fun. Holly Cummins from IBM explains the importance of having fun in the workplace and how to get it.
In the database area, this is probably the main reason to go to DevOps: stop that fight between Developer and DBA and be happy to work together.
Follow the link for the blog post and slides, my best part is about DevOps and Automation: Repetition is boring. Automating stuff is fun.
Deep learning in computer vision
The best demo I’ve seen so far was from Krzysztof Kudryński (Nvidia) and Błażej Kubiak (TomTom). First, showing the coding iterations to solve an image recognition pattern, like a human face wearing glasses or not.
And then face recognition, in live demo, with a mobile phone and a laptop: record one face and then be able to recognize the same person within a group of people. Beyond the computer thing, it was also a nice exposure on the demo effect, and the human factor about it. Demos fail in a talk because the conditions are different. I love this fail because of the scientific approach of the speakers to fix it. It didn’t work to record the face of an attendee in the audience. It worked when the speaker did it on himself. Then empirically find what’s different: the glasses, the light,… and finally, the fact that there were many faces in the background. Those things that you know perfectly and forget once you are face to the audience, thinking about your talk, the time, and everything…
The speakers never gave up and finally had a great working demo.
Compact Muon Solenoid, Council Chamber and Main Auditorium
Want to have a look at the venue — between Council Chamber and Main Auditorium? Here’s the video made by Romy Lienhard:
