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.
When writing software you will end up using frameworks and libraries to make your life easier. Even if you don’t use any frameworks or libraries you still have the language itself that can evolve over time. A nice example of this is the recent release of Java 9 which did introduce some changes that might break your software.
All of these dependencies could become a hell if you are too tight coupled to them, as they restrict you from upgrading or changing when required. It is essential that you take this into account when writing software but as always it is easier said than done.
Coordinate systems is maybe not something you are faced with every day, and might lead you more to the gaming industry, but nevertheless are coordinate systems something you will face sooner than you think. The pixels of your screen for instance already define a coordinate system. This system has the zero point in the left top corner which is similar to how we read in standard languages such as English. We start at the top and go to the bottom, and on each line we read from left to right.
The coordinate system of your screen is a bit special, as it does not allow for negative values and works only with natural numbers. Because of this implicit coordinate system something as simple as showing something on the screen already requires a conversion or mapping. In this blog post I will go into more detail as to what problems can arise and what you should take into account.
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?
An interface is often just an implicit definition as every class defines an Interface. An interface just defines the contract of the class by specifying the methods that can be invoked. Java however also has an explicit interface type which until recently adhered to this idea, but since Java 8 an interface can have a ‘default’ implementation. This idea breaks completely with what an interface is supposed to be and fades the line between an interface and an abstract class. So what is still the point of defining an interface and using default implementations?
We are looking into replacing some operations tool and we have been questioning whether this should be a web application (as it is now) or a native application. For this I did some investigation and made a clear comparison between the advantages and disadvantages of each solution. The application we have could actually be split up in two parts, one for the operations and a more advanced for diagnostics. This was key in my investigation as both serve a different audience.
My analysis is of course focused on this purpose and on the situation in which this application has to run. This may not be applicable for your situation, but I hope that my explanation and arguments are clear enough so you can filter out which ones are relevant for you.