Today ends my second months with the new company. As a follow-up to my last post Two weeks with the new company this post will be about my latest activities, my thoughts on a few things software and the feeling for further improvements.
Working around the core
Like 4 weeks before I joined the company another developer started working for my new employer. Both of us were surprised by how things are/were handled and decided we should change a few things for the product to get better. We gave a presentation on stuff that we think should be improved and asked for officially supported time to work on those things. This presentation was the starting point of stories that we as developers can suggest to put into a sprint (scrum). There are quite a few stories that are really interesting, most of them though are kinda around the product. One for example is the implementation of database migrations and how to handle them to keep track of different versions of the database.
Database migrations
As I was the newest to the company and did not have my special fields I worked on I was assigned with this task. It was interesting to work on it and I found a nice tool that we are now going to give a try and see how it will turn out: flyway – The agile database migration framework for Java During my tests the tool supplied basically all the features we expected and it also comes with a Maven plugin. Did I just say Maven?
Build system
The build system so far is pretty much tied to Netbeans, using Ant in the background to do the work. But it is started and maintained in Netbeans only. I am not a fan of that. Don’t get me wrong, building software using the IDE should be possible for sure, but having to use the IDE to make a build is just wrong to me. So, guess what, another task I got to work on was a concept for the build system. I took a look at different continuous integration (CI) servers and came to the conclusion that we should give Jenkins a try. But before being able to use a CI server, the build has to be decoupled from Netbeans.
Here comes Maven. The developer who started 4 weeks before I joined the company has already worked on trying to build our software using Maven (in his spare time) and has come pretty far. There were a few things that needed to be fixed, changed, optimized and all that, but the ground work was done and I could build on that. It was a big advantage as this was the first time I was really using Maven as the build / dependency management tool. This week I got as far as being able to build the software from the command line (and also in Netbeans) using Maven —> Using the Maven Glassfish plugin, I could even deploy the result of the build. I find that is pretty cool and once I got to know the Maven way of thinking a bit better, which I still think I did not fully get, it was not that hard to adjust the last few things and fix a few minor hickups.
As we are using a few older versions of libraries that no one wants to take the risk of updating, we needed some kind of a local repository. These older libraries were nowhere to be found in the public repositories so we need to have them locally. Fill in Sonatype Nexus which manages software artifacts required for development, deployment, and provisioning. It can be run in an embedded server and is pretty straight forward to use. One can describe it as
- a proxy for public repositories, so you would download a dependency from Nexus rathter than a central repository. In case the dependency is not in Nexus yet, it will download it from Maven central and such and keep it for future downloads that then will not be going out of your network.
- your own repository. You can upload your own jars/libraries and let Nexus be your repository. Maven will not see a difference, in that way you can use your own custom jars/versions that are not publicly available in your own repository management system.
Both, the build system and the database migrations were pretty interesting as both were a first-time for me! I had other stuff to work on, too, but those were the main areas I was working on. So I have been mostly working around the product, though both topics will improve development and thus the product. It is good and bad at the same time, because I kinda feel like not getting to know the system better, that I am supposed to improve the infrastructure around it. I hope you understand what I mean.
Things software
Tools are only as good as you know how to work with them (I am sure there is someone famous who said that before – so don’t credit me for it). During the last two months I mainly worked in Windows 7, which isn’t that bad I have to say. I have used Linux (Debian/Ubuntu), Mac OS X and Windows (2000/XP/7) before and one of the most important tools supplied by the OS I came to like is the command line on Unix systems. So, sorry Windows, but your command line sucks – really bad in my opinion. But, there is a fix for that: Cygwin – Get that Linux feeling – on Windows! Seriously this is one of the best tools I have found I need installed on the Windows machine. But once I had it installed I was ready to rock:
tail -f -n 100 someserver.log
split -l 100 -a 4 splittedfiles/
cat something* > combinedfile.txt
How would you do that on the Windows command line? Am I just wrong about that and don’t know the right commands and it is included, too? If so, feel free to correct me, I am more than happy to learn.
CI is for Continuous Improvement
CI can have many meanings:
- Corporate Identity
- Common Interface
- Continuous Integration
I want to use CI for Continuous Improvement. As I am talking software development mostly, Continuous Integration can be ssen as a part of Continuous Improvement, because it can help you with it, a lot. I think it is really important to constantly try to get better. Especially in software development I feel there is always something one can do to improve herself, the software, the infrastructure, the performance and/or the user experience. Once you stop improving or start telling yourself: “Why should I change this, we have always done it like that!?” you should sit down, rethink and relook at the topic trying a different angle. There is always room for improvement. Always.
Sometimes you have to invest a certain amount of time (and we all know time is money) for improvement, but I think it will payoff. And even if it does not right away, sometimes it might as well be more expensive to not work on the improvement and leave it the way it is. The later you start the change, the improvement, the harder it will be and the more it will cost.
Nice coworkers
During my first two months I got the feeling that it is more like people working together. Sometimes it feels like some kind of a family. Maybe this is what it feels like to work for a startup, which I still consider us as. My colleagues also prepared my desk for my birthday which I found quite nice of them:

I think it was the right thing to take the opportunity and start this job. I will keep on working on my definition of CI and hope to get everyone on board! So here’s to the next 2 months! Let’s crush it