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.
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.
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.
The usage of Artificial Intelligence is growing in every possible area. Though I have no real experience with AI, I am very interested in learning more about it and using it. AI is however a very general term that covers many different techniques ranging from heuristics such as Particle Swarm Optimisation to Machine Learning and Neural Networks. There is however a big difference between these algorithms, and what I want to discuss here is the ability to understand the outcome of the algorithm.
Crucial to good Object Orientation, is the separation of concerns and capsulation. This means your objects need a clear API that limits the way the internal state can be changed. The object itself must be responsible for the state and must guard its integrity. While the API defines what operations are allowed, these methods have restrictions of their own. It is essential that the parameters provided to these methods are within the limitations. The only solid way of checking these values is by using preconditions.
A Map is a very common data structure to use, and often you find yourself wanting to traverse over all elements in it. For this we have multiple methods:
If you are interested in both the keys and the values, the valueSet does not fit your needs as it is impossible to get the key based on the value. But which one of the remaining two ways performs the best? I did the test and found some interesting results.
When writing software we often are only focused on just that: getting the feature done. With the rise of Test Driven Development (TDD) some of us will first write tests before the actual code and this is great. Personally I like the concept of TDD, but I can’t seem to make myself adhere to it as I am always to eager to write the code instead of first write the test.
Another reason I don’t do TDD is that I find it hard to write a test for something that doesn’t even exist yet. At least the public interface should exist, but this interface can change often during my implementation because I don’t come up with a full design in the beginning.
But even though I don’t do TDD, I spend a lot of time writing unit tests, making sure all of my code is being covered and that I didn’t forget anything. I do this because this is the only way to avoid bugs in the future. Others however will spend either much less time on writing tests or none at all but will write a lot more code. To an outsider it may seem like these developers are more productive as they output more code. There are however a couple of problems with this idea.