As a developer I have used version numbers but never gave many thought about it until recently. I know I have had some issues with it where not explicitly enough specifying dependency version could break things with new builds. On the other hand the usage of version numbers of internal libraries was always non-existing. In this blog post I will go deeper about how I experience version numbers from a developer’s point of view.
Any software developer and even user nowadays will know the concept of version numbers. They are a way to easily identify and keep track of, well… the version of the application. But why exactly is it important to be able to do this?
In this blog post I limit myself to discussing different types of versioning systems as well as the reason to use one. In the next blog posts I will give my opinion about using such a system from both a developer’ and a user’ perspective respectively.
One of the biggest missing features of the current Object Saving Framework is that there is no native support for lists. There is a way to bypass the issue, but it’s a nasty one. In this blog post I first go into depth about how to bypass the issue, this will make it clear that native support is essential, and finally I will discuss some issues with supporting it.
Since I am no working with C++ and no longer use Java as my mainly programming language, I was wondering whether some of the past experiments would yield different results. In this blog post I will repeat the exercise of comparing floats and doubles but now for C++. Given that Java and C++ do handle types differently it is possible that the results may vary, however both languages implement floating points numbers in the same way, according to the IEEE standard.
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.