The essential tools for software developer

As a software developer I have used a ton of different tools for different purposes. However, it got me thinking, if I really need a lot of tools and what are the essential tools for software developer and what tools are rather “nice to haves”.

Editor

First, we better be able to write code. Hence, the editor is absolutely required. For Java, I’ve used different IDEs, but mostly IntelliJ IDEA. NetBeans IDE is nice. Eclipse-based IDEs shine in one way or another. I usually prefer to install JBoss Developer Studio as it provides a solid support for Java EE projects.

For one-off editing, I still use Vim and can’t get rid of it. I’m not even using the full power of the editor. I’ve tried other awesome editors at different times: Notepad++, Crimson, Atom, Sublime Text, VS Code (which I do have installed on my machine). Still, those editors haven’t got much use by me for some unknown reason.

The cool thing about the editors is that there’s so much choice!

Version Control System

In 2004 I started at one financial company as a Java developer. The first task I was assigned to was something likes this: “We have an application running in production and it has a few bugs. We need to fix those, but we don’t have the source code. Please do something?”. A disaster. They didn’t use source control properly and managed to lose it.

Today, the scenario above is very unlikely. However, I still hear stories how people store the source code in folders with suffixes _1, _2, _3 on the network drive. Argh!

Which version control system would you pick? IMO, today Git is the dominant one. However, the way people often use Git (or any other distributed VCS) by avoiding branching and playing with feature flags, they probably would be just fine by using Subversion instead :)

Issue Tracker

An issue tracker is absolutely needed for the team to plan their work, tasks, issues, etc. Now the question is in the implementation. I’ve seen tasks being tracked in MS Excel, text files, sticky notes, and other modern tools like Jira, Mingle, PivotalTracker, YouTrack, ForBugz, Bugzilla, Mantis, Trello… the list is infinite!

The thing with issue trackers is that they should support the approach you take for running the project. For a product company there are quite a few reasons to track issues. First, obviously, you need to track your work, i.e. tasks. From the project management perspective, it’s nice to have the ability to track the tasks, i.e. have the project management facilities in the task tracker. Lots of teams are happy to have it all in one so it’s easier to get an overview of the progress, especially if the tool provides Kanban style boards.

Second, good products usually have users who are eager to submit questions or bug reports. For that, most of the teams are using some kind of helpdesk software. HelpScout was the one I have used at ZeroTurnaround and can recommend. Plus, some teams make use of forum software that also serves as a channel for communication. Also, some teams expose a public issue tracker so that the users would directly submit issues there.

The above means that the issue tracker you choose is better have the required integrations available if that’s a requirement.

Continuous Integration

You write code in the editor, you test the code on your machine, you push it to Git. Someone pulls the code down, tries to run it, and it doesn’t work. Sounds familiar? Yeah, reminds me the famous “Works on my machine” excuse. Automation is absolutely required for a healthy software project. Automated builds, automated tests, automated code style checks, etc.

Previously at ZeroTurnaround, I’ve seen that the CI server was a very critical piece of project infrastructure. If a source control system want offline, it wasn’t an end of the world to them. But if the build server was down, for many developers the work pretty much stalled. Now at JetBrains, I also see that their own product, TeamCity, is a very important service internally, with many teams relying on it. Dogfooding at its best!

Continuous integration was brought to the masses by eXtrame Programming practices. Today, CI is absolutely essential to any healthy software project. Years ago it all started with automating the test execution, building the artifacts, and providing the feedback quickly. Remember CruiseControl? Or Hudson, when it appeared? CI servers have been evolving the in the past years as the notion of Continuous Delivery appeared. Better visualisation of the process is required to cope with growing complexity. Also scaling the CI server has become an important aspect of the process.

With the latest trends in CI, the build servers are eagerly implementing the notion of build pipelines (build chains in TeamCity) which provide a good overview of the process. And also the trend of 2018, I think, is running the CI tasks in a Kubernetes cluster.

Artifact repository

The build server produces the artifacts. Plenty of them. Either the artifact is a final software package, or a reusable component, or a test execution report, etc. Where would you store those artifacts with all the metadata associated with it? Today, there isn’t much choice, actually.

JFrog’s Artifactory is the dominant solution for storing binaries and managing them. Plus, the final artifacts could be promoted directly to Bintray for distribution. Sonatype’s Nexus was originally the go to solution for Java/Maven projects and added support for some other technologies as well in the recent years. Apache Archiva and ProGet are the other options but that’s pretty much it.

The security aspect of software development becoming more and more critical. I think, automated security checks will become an absolute requirement for any software as well. The trend that has been ongoing for years now and binary repositories, such as Artifactory and Nexus, are actually integrating with the services that provide such vulnerability checks. So, don’t be that guy, use the binary repository!

Summary

I have listed 4 categories of tools that I think are essential to any software project:

• an editor,
• a version control system,
• CI server,
• and an artifact repository

I didn’t mention build tools, compilers, static code verifiers, etc, but those are the small tools that will be used by developers anyway. And if not, some of the tools I’ve mentioned can replace or provide such functionality as a bundled feature.

Setting up JRebel for WebSphere AS in Docker environment

Getting any Java application server up and running in the development environment is usually a fairly simple task. You can just download the zip archive, and start the contain either from command line or via IDE integration. Configuring JRebel agent for the server is also quite straightforward. However, there are some exceptions to that. For instance, if you’d like to try JRebel on WebSphere AS and you are using MacOS, then you will have to take another route.

WebSphere Application Server is available for Linux and Windows platforms, but not for MacOS. The good news is that there is a WebSphere Docker image that you can use for development.

The developerWorks' article demonstrates it pretty clearly, what needs to be done in order to get WebSphere running in Docker and deploy a web application. With the help of the article I have assembled a demo project that deploys a Petclinic application on WebSphere running with JRebel in Docker container.

Let me explain some interesting bits of the outcome.

First of all, we need to derive from the base image, package the application archive into the new image, and make sure that WebSphere will deploy the application when it starts:

#Dockerfile
FROM ibmcom/websphere-traditional:profile
COPY target/petclinic.war /tmp/petclinic.war
RUN wsadmin.sh -lang jython -conntype NONE -c "AdminApp.install('/tmp/petclinic.war', \
'[ -appname petclinic -contextroot /petclinic -MapWebModToVH \
[[ petclinic petclinic.war,WEB-INF/web.xml default_host]]]')"

As you’ve noticed, it is not enough just to copy the application archive to some folder. You also need to invoke a script to actually deploy the application: call wsadmin.sh by providing it a snippet of Jython code.

Next, as we want to enable JRebel, we also need to package the agent binary into the image, and also we need to modify JVM arguments of the application server. Hence, the corresponding Dockerfile will get a little more complicated:

#Dockerfile
FROM ibmcom/websphere-traditional:profile
COPY ["jrebel-7.1.2","/tmp/jrebel"]
RUN wsadmin.sh -lang jython -conntype NONE -c "AdminConfig.modify(AdminConfig.list('JavaVirtualMachine', \
AdminConfig.list('Server')), [['genericJvmArguments', \
'-Xshareclasses:none -agentpath:/tmp/jrebel/lib/libjrebel64.so']])"
COPY target/petclinic.war /tmp/petclinic.war
RUN wsadmin.sh -lang jython -conntype NONE -c "AdminApp.install('/tmp/petclinic.war', \
'[ -appname petclinic -contextroot /petclinic -MapWebModToVH \
[[ petclinic petclinic.war,WEB-INF/web.xml default_host]]]')"

The Dockerfile above packages JRebel distribution into the image. That’s an easy part. The hard part was to figure out how to configure JVM arguments. In WebSphere, JVM arguments are set via server.xml configuration which is quite unusual. Normally, a developer would use an administrative user interface to modify the parameters, but in our case we need the arguments to be in the right place right at the start. Hence we need to do some Jython scripting via wsadmin again.

Now that the Dockerfile is ready, we can build and run the new image. In the terminal:

$ docker build -t waspet .
$ docker run -d -p 9043:9043 -p 9443:9443 -v `pwd`:/tmp/petclinic -v ~/.jrebel:/home/was/.jrebel waspet

The docker run command above also maps a few directories: a project folder and JRebel’s home folder. We map the project folder because JRebel agent could then see if any resource is updated. JRebel’s home folder (~/.jrebel) includes cached resources, so that if we would have to restart the Docker image then the application will start faster the next time.

Now it is possible to use JRebel to update the application instantly, without restarting the application server or redeploying the application. For the full list of instructions, see the README.md file in GitHub repository.