In the software world, there are often new technologies coming to market, new fields to explore, new techniques to use, etc. Filtering through these in itself can be a challenge. Deciding when to move forward with one in practical applications can be even harder. Many times as developers, we will be brought a problem that we can solve in a way we’ve heard about or read. This is when theoretical example attempts to meet practical implementation. We ask ourselves “Does [X] tool I read about recently solve this problem?” or “Would [Y] really work in my organization?”. This is where we can employ the proof of concept.
In a previous post, I mentioned that in order to have a successful DevOps experience, there were some key components and principles that need to be implemented. In this post, I’ll cover those components in more detail.
What I want to cover in this post is the experience that I had transitioning from a traditional development role to DevOps and what I learned to be useful in that transition. One of the nice things that I experienced with DevOps was that it pushes developers to take more ownership of their application because they are living through the pains and difficulties of running the application which in its turn pushes them to make running the app easier.
Wikipedia defines DevOps as:
DevOps (a clipped compound of “development” and “operations”) is a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.
I like to simplify this definition by saying that DevOps is when you’re not only responsible for developing the application but you’re also responsible for running and supporting the application in your testing and production environments. As opposed to the traditional way of developing where you have the luxury of developing the application then throw it over the wall to the Ops team.
Let’s start with the 800lb gorilla in the room, Java. Why Java? Well, let’s start off with the fact that it’s got a ton of community support and documentation everywhere. If you Google a programming problem, chances are within the first three results you will see an example using Java. There is also a plethora of amazing editors available. A good editor is not a replacement for knowing the tools available in a language, but it can help you in learning.
I convinced a client to upgrade the computers we were using for software development. Maybe this article will help you convince your manager to do the same!
This is an interesting question. Let’s think of it this way: Does a carpenter only use one type of saw? Does a mechanic only have one type of wrench? No. In short the answer is, as craftsmen of code, we are only as good as the tools that we know how to use; and programming languages are those tools. When it comes down to deciding on what language it is that you want to learn, the question you need to ask yourself is this. What type of developer do I want to be?
Gulp is quickly becoming the the leading task runner over grunt. If you are currently using Grunt or even worse, an ant task, then I highly recommend this topic for you. In this write up, we will quickly discuss Grunt, Gulp, and Gulp syntax.
After years of being immersed in Java development, I must admit that I got spoiled by its strong and mature ecosystem. Hence, whenever I want to pick up a new technology or programming language the following must be there:
- Support by my favorite IDE (Eclipse or IntelliJ IDEA)
- Mature building framework. It does not have to be Maven or Gradle but it needs to be at least better than Ant.
- Easy TDD. This could be the trickiest one to achieve because not only do I need a testing framework, but it must also be supported by my IDE and build tool. Moreover, it must have an adequate mocking framework.
Groovy easily satisfies those criteria right out of the box. It has awesome support by IntelliJ IDEA, Gradle is written in Groovy and you can write JUnit 3-style unit tests.
If you have ever practiced test driven development (TDD), then you are probably familiar with the TDD mantra – red, green, refactor. I’m a big proponent of TDD, but I think the TDD mantra is missing a fourth step.