The assertion is an old paradigm that has been around since before the advent of object-oriented languages. An assertion is a statement that asserts that some condition is true, and causes an execution failure if the condition is not respected. It’s that simple.
Failure can be translated into an exception, a runtime error, or even a runtime failure resulting in unstoppable application termination.
Working with large systems that don’t have automated validation frameworks is a pain. So much so that many developers label them legacy even on their maiden voyage. The reality is that there exist many such systems in production today, and many more going into production hourly.
Because of this, its not uncommon to find oneself dropped into such projects. We grumble and groan and hope to get off them as quickly as possible. Well buck up, greenfields projects are a rarity so here is where we practice our trade.
I’ve been working as a software developer for nearly 10 years. During all these years, I’ve mainly worked in the field of embedded systems, where hardware and software people work very closely.
Sorry, Apple fans, but I found a problem with the Safari mobile browser.
Indeed, in one of my projects, I had to display an animation (a sprite for which I changed the viewport).
The image size was 4 MB with a width of 9600px and height of 600px. What we noticed initially is that the image in question did not appear on the iPhone nor the iPad. It was strange, because in all other platforms it appeared perfectly.
Recently a friend of mine found out she was pregnant. She was really stressed because she had a miscarriage just a little while ago. To reduce her stress level, the doctor prescribed an ultrasound (a test) even though it was early in the pregnancy.
This story made me think that, for me, TDD is a little bit like a test prescribed by a doctor. It allows me to reduce my stress level when I develop a new feature, especially when there are many unknowns.
TDD helps reduce my stress, because it allows me to step into the unknown in small steps and gradually validate that I’m going in the right direction.
I’m a big fan of immutable objects. They appeal to me for many reasons:
The immutability requires that the object be created in a consistent state. This implies that object creation must fail instead of creating an invalid object. Failure often takes the form of exceptions. I’m fine with that. In a case like this, “fail-fast” offers certain elegance.
In my current term, we are developing a web application that must run on an embedded system. The embedded system uses the Ubuntu operating system, and both the CPU and memory are limited.
During development, we faced a performance issue, but we did not really where it came from.
Initially, we used Linux’ “top” command to investigate the performance problem. However, this tool did not help us because it lacked details and the refresh rate wasn’t fast enough.
Some of you probably know the Law of Demeter, but a reminder doesn’t harm anybody:
You will say: “Theory is nice but in practice how is it expressed?”
Here is an example:
Those who know me know that I love innovation and unusual gadgets.
Just ask my friend Marc Laroche, who gave me as a gift a toilet paper dispenser… that is also a radio.
When I saw a lot of cynicism towards Google’s Project Glass, I was a little disappointed.
As a developer, I am often in contact with a strange species we call ergonomist. But I never really understood the impact they can have not only on the user experience, but also on the developer’s work.
In my current project, the user interface is created as we go. The first versions of it had not been thought ergonomically. We therefore developed the code without this mindset. In doing so, we had nine concepts of buttons included in the software application.