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.
Different software engineers get motivated by doing different things. Some get motivated by fixing bugs, others like trying to break the code. Software engineers like me however, like to solve complex problems, coming up with algorithms and data structures to solve the problem the best way.
While it is easy to provide enough bugs or code to break, it is much harder to constantly provide new problems that are challenging enough. As a result I often start to feel bored at work after a couple of months, but there are ways to solve this and keep the challenge.
For those who are confused about the title, I am not going to talk about our planet (although it is essential we take care of it). The environment I am referring to is of course the development, testing, build and production environment. All these environments can be different and in most cases they are. There are a couple of reasons for this:
- You have different customers all having different hardware and software in production you have to integrate with.
- There is a difference between your company and the customer in setup, which would be very expensive to change.
- Having a full production environment for development is almost always too expensive.
So unless you are willing to change all of your environments and pay a serious price for it, your environments will differ. And while these differences can be cumbersome and make software development harder, a lot can be done to overcome most of these problems.
Ever since I started working for the new company I have been working on this type of warehouse management system, although we call it ‘material flow control’. Many things have changed since the initial design (which I wasn’t part of), the biggest one being going from a generic to a specific approach. At the moment this decision was made, my team lead also told me to forget about persistency for now and just focus on the functionality.
With all the bare functionalities implemented, it is time to start working on the presistency. This proved to be much harder simply because the design wasn’t made with persistency in mind. So my first priority was to refactor a lot of the code so it can be more easily be stored and recovered from a database. Clearly this could have been avoided and saved a week of effort for the already too tight deadline.