Another year has passed, and even though it feels like I say this every year, what a year has it been. As is my yearly tradition at the beginning of the new year to look back on the past year and look forward to the next, so I will do this year.
During software development we use many tools such as the IDE, code coverage, static analysis and build tools. There exists many of these tools with each their advantages and disadvantages as well with differences regarding personal preference. Being able to work with tools you feel comfortable with is important for your efficiency. Because of this different people might prefer different tools, but how should this be handled when working in a team where having a uniform setup has its own advantages.
Every software developer should be familiar with some type of versioning system, be it git, Subversion, Mercurial or some other. The advantages offered by using such a system are plentiful, they are that vast that such a system is often also used for other types of documents, be it in a different format. Services such as Google Docs, OneDrive or Dropbox offer the exact same features because they have recognised that having a history of your documents goes way beyond source files.
So we all acknowledge that keeping your data in a versioning system is a good way, but this opens up a different question. How should you organise your documents? I don’t mean which folder hierarchy, which in itself is already a challenge, but I mean the actual location. It makes sense that you want to keep your files close together, but how do you categorise your documents? Based on topic, type, target audience?
One of my biggest remarks when working with Java the past few years was the lack of a strict immutability concept. The most you can do is declare your object to be final, which only prevents changing the object being pointed to and not any changes made to the object itself. I remembered that C++ offered a lot more opportunities for this and you could go crazy with the ‘const’ keyword.
However, during some quick investigation regarding this constant behaviour for the GroceriesInsight project, I discovered that I was a bit off with how C++ handles the constant behaviour of arguments passed to a function.
In my four year carreer, I recently started my third job. This may make me come over like someone who very quicky changes jobs but I never changed job for the money or some other better deal I would get at the new location. I have always decided to leave based on the work I was doing at that time, altough I must admit that in no circumstance I have ever changed to a job that was offering me less then what I had. My quick passage at jobs may sound like switching could have been the wrong choice and that the previous job wasn’t that bad after all, this is what I will elaberate on during this blog post.
At my previous job they were starting up a new project on which many different people from different locations would contribute to. To give you an idea of how distributed the team would be, it would consist of 7 people in 4 different locations. Altough we have come a long way, and communicating with people all over the world has become possible without much effort there still are some problems that could arrise.
As it goes with all software, initially you think you have it all figured out and it’s all clear, but as soon as you start writing it you realise there are a couple of things not as straight-forward as you would have liked. The implementation of the ObjectSavingFramework is no exception to this, even though it was designed to be a very simple application.
The first version only had to have 3 different concepts:
- Objects: which contains other elements (potentially other objects).
- Values: which just indicate a certain value.
- References: pointers to objects.
The references are an important aspect to avoid infinite nesting, or object duplication. An object that contains another object will have to decide whether this object is private to him, or if it is shared. If it is a private object, the whole object needs to be written as a child element, if it is shared then the reference is required. It is however this reference concept that caused most of the problems.