Angular: A Java Developer Perspective

As mentioned in the previous blog post, I will continue with my remarks about some Angular 4 design choices, similar to what I did in the previous one. The course I followed was very in-depth about Angular 4, but there may still be things I do not know. I am not an expert in Angular 4, and my real life experience with Angular is very limited. I am aware that this may influence my opinion and cause me to dislike certain choices while better ways to do it exist. I am open to this, and please let me know if you have any comments or advise for me.

Continue reading


Typescript: A Java Developer Perspective

Recently I followed an online Angular course, giving me an in-depth experience of both TypeScript and Angular 4. This was my first experience with both technologies and they look very promising, but I can’t help to have a couple of remarks about some choices that have been made. In this blog I start with giving my opinion about some of the choices made in TypeScript. In the following blog post I will continue with my remarks about Angular 4.

Because I have only seen TypeScript in combination with Angular 4, I may confuse features by mistaking them to be part of the one or the other. I am by no means an expert in either Angular 4 or TypeScript, so please forgive me when I make mistakes like this. I would also like to hear your experiences and comments.

Continue reading

Product vs Project Approach

Software has a very unique characteristic, you create it once but can deploy it as much as you like. This goes beyond the limitation of other industries such as architecture, manufacturing, etc. In those industries you design it once, after which you can mass produce it, but the production itself has to happen every single time. Software is not bound to this as it does not deal with any physical objects. This makes software a good fit for a product approach, were it not that people have different preferences and like some customisation.

Continue reading

Factory Acceptance Tests

The product we create is a combination of hardware and software, and recently we have introduced the policy of doing a factory acceptance test (FAT) for every vehicle (AGV) that leaves our company. The FAT is meant to make sure that every vehicle that leaves the company works correctly, at least that is the theory because in practice we still have a lot of problems with getting everything working on the customer’s site. The goal of this blog post is to go into depth about the reasons for doing a FAT, the pros and cons and why it is failing for us.

Continue reading

How Tests Find Bad Code

You probably already had to write tests for someone else his code. Then you know how troublesome it can be, especially to know what you actually should verify on. But another problem that can arise is that you realise the code is just not written very well. While the main reason for tests is to verify the correctness of code, tests can also be used to test the behaviour and cleanliness of code. This is a hidden benifit of tests which is often neglected by many people.

Continue reading

Protocol Implementation

Some time ago I experienced my first time (except from once at university) where I had to implement part of the specification of a protocol. In this case it was the Modbus/TCP protocol that was partly required. For this implementation some pretty low level programming was involved. The fact is, that in our software we just use a library for the Modbus protocol, but to keep our tests light-weight and to verify the correctness of this library as well I did not want to use this library in my unit tests. I remember during university to really hate the whole messing around with particular bits at specific locations, as I just wanted something more high level that would do all the work for me, but that has changed apparently.

Continue reading

Going On Site

With the evolution of internet almost everything is accessible from your computer wherever in the world. When however dealing with applications that are installed on a customer’s server this is often different, but even when the server is accessible integration work and tests needs to be done. Doing this type of work is a lot easier when you have direct communication with the customer, besides that a customer appreciates seeing someone working on it.

How much time you can expect to go on site depends on a couple of factors which I will discuss in this post. I will also reveal some of my opinions and experiences of going on site.

Continue reading