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.
A common part of any application is to save data, altough there can be a big difference in the reason why you are saving data. Maybe it is just the output of the application which takes a certain input, processes it and writes some output again. But a lot of applications save data to have some kind of memory in case it is shut down, or in case of a failure. A lot of applications wouldn’t be thinkable without any way of storing data for later usage, even simple ones. I recently encountered this with the GroceriesInsight application, which currently doesn’t do much, but even then I already felt the pain of not being able to save the data.
Because of this saving data is a well known process that holds little secret. The first thing you would decide would be in what format you want to save your things, this can vary from a text format such as XML, JSON to a database. Once decided you will search for a library that makes it easy for you to write the data in a correct format. But then you are faced with how to get your data from the object to the library to save it, this problem will the be topic for this blog post.
The first thing to add is of course a way to add products and transactions as these form the core of the application. With the initial version I am aiming for a very basic form which just allows storing and retrieving data.
With the initial implementation of the Product and Transaction done, I will briefly explain how everything went, the thought process behind it and what I already know must be added in the future.
In the past I tried to contribute to an open-source C++ project, mainly because I want to keep my knowledge of C++ up-to-date. However finding an interesting project has been tough, but eventually I did find one. However, as with all projects there is a quite a big learning curve to get involved. Due to my lack of time, this never really took of.
Recently I decided to start working an a personal project, as with all of these projects they arise from a feel of need. The application I will create has as main goal to keep track of expenses. There are probably a lot of other applications that can do this, but by doing it myself I will have more control over the features.
Depending on what type of business you are active in, you either often start new projects from scratch, or not at all. In the first case you are more involved with proto-typing and experimental work whereas in the latter you are working on a product that needs to be supported, upgraded and maintained.
Starting code from scratch has a lot of benifits mostly caused by the freedom that comes with it. You are not bound to any choices made in the past, you are free to choose your own way of working that you are used to and feel comfortable with. There is also no legacy code that you need to understand and may be badly documented.
But what I want to address in this blog post is all the side-setup that is required when setting up a new project, and how important it is. Should it all be done from the start? Or can you delay it until it really becomes important?
Except from some small (personal) projects or tools, is software development a team activity. The bigger the application the more people are involed, and the longer the process is. Starting with a functional analysis all the way to operations, you have many different type of people all with their own function. However, the more the functions are split up, the harder it is to keep ownership and take responsibility and more often the blame game is played. This is simply caused by the fact that it also becomes easier to make mistakes because information is passed on multiple times, and different people will interpret things differently. But even just in development, depending on how you organise the process you can easily cause people to live on their own island.
As more and more things are being automated, our daily life becomes easier. In many cases however we have a mix of automation and manual actions, or we want to be able to intervene or correct when automation goes wrong. Whatever reason, a fully automated system is often still not feasible, and thus manual interactions needs to be allowed and taken into account during design and implementation. But what exactly are the implications of this?