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.

I will be speaking at JavaOne 2015

I'll be speaking at JavaOne this year again! This time I have 2 talks accepted:

CON3597 - Having Fun with Javassist. This is merely a live coding session where I demonstrate various uses of the Javassist library for Java bytecode manipulation. I've delivered this talk multiple times and every time it is different as it turns out quite interactive and attendees usually ask questions right in the middle of the talk so I have to adjust the content as I go. Usually it's quite fun, so I enjoy presenting this talk.

CON6699 - What's the Best IDE for Java EE? I'm not sure how this one turns out - it's so much to talk about and so little time. I'll be presenting this talk along with Max Rydahl Andersen and Adam Bien. This time we're focusing solely on Java EE. Basically - it's and overview of what's available for Java EE users in Eclipse, NetBeans IDE, and IntelliJ IDEA.

Both the talks can be found in the content catalogue for JavaOne.

IDE Fanboys

I just leave it here...

JavaOne 2013 - Apples and Oranges: The Highlights of Eclipse, IntelliJ IDEA, and NetBeans

IDE Project Files In Version Control - Yes or No? Of Course, Not!

NB! This topic is mostly related to Java projects. The situation might be a little different in case of other technologies and IDEs.

Just recently I had some discussions with the clients who were claiming that they keep IDE project files in version control system hence they avoid any changes to those files. For reference, those are Eclipse generated .project and .classpath. From my point of view it is a bad practice by all means, however I usually prefer to collect some information on the topic before I say it loudly. So I asked from my G+ and Twitter followers, IDE project files in version control - Yes/No? Surprisingly, I've got quite a number of responses, so I decided to summarize the information as a blog post.

Basically, the answer to this question isn't binary, yes or no, but it also could be "yes, but... " or "no, if...". So there might be some argument why someone prefers one way or another.

The vast majority of the answers is "No, no, noooooooo!! Never!". And just a couple of answers were "yes" with some weak arguments of why someone should keep those files in version control.

Here are some yes answers first.

Bad stuff. Seems that the team isn't really competent with the tools. The project should be easy to setup and why on earth I should press 100500 buttons to setup a project. If this is the case, the first thing that team lead should do, is to simplify the project structure, setup and build process. No excuses there.

Yeah, yeah, I can already hear some arguments like "but we have a complex project" or "this is the way our setup is done". Bullsh*t!

OK, there is some optimization for the setup, IDE specific though. If all the team members use the same setup, it might even make sense for those who want to keep hands off the console.

Here's another one:

"Specific Eclipse plugins" - yeah! that's is actually an argument for not keeping the files in version control! Eclipse plugins usually modify .project files as they add a "nature" or any other project specific settings to the configuration. And actually, IntelliJ does the same, but (let me bash to tools a bit) IntelliJ can suggest the settings as you open a project from scratch. And with Eclipse, you have to do that manually. What if your colleague uses some awesome eclipse plugin that makes modifications to .project file, and you hate that plugin and do not want to install it, and the .project file is in version control? Here's just a simple example that you could see while exporting a project with existing project files:

This is so annoying to resolve this kind of problems. And all you want to do is just to open the project and proceed with your normal work.

Here's more:

Currently, I use IntelliJ and the rest of the team uses Eclipse. And I absolutely do not care if they put the project files into version control, because I will import it into my IDE in two clicks anyway. So the assumption that "absolutely yes, given that the team is working with the same IDEs" is wrong, and no viable argument here as well. 

However, here we have some much more interesting ideas:

Wow, this is really interesting one - "those that define formatting or source code". Indeed! In cases when you work on varions projects for different clients, the requirements and code styles might be quite different and it makes sense even to keep this kind of files in version control, so you can share it with the team and restore the code style settings if you lost them. Good point here!

However, you can probably see the vector of my post now.

So the point is, IDEs support Maven quite well, so why on earth I would need to keep the IDE settings in version control if we already have what we need: pom.xml. IntelliJ and NetBeans cope with that quite well, and Eclipse also, if you use JBoss Tools.

But what if I'm a Maven hater? (I really am). Here's an interesting conversation:

Oh sure, Gradle that is! Well, the IDE support isn't there yet. Luckily, STS provides a nice Gradle plugin for Eclipse, but the support for IntelliJ and NetBeans isn't quite there yet.

However, my claim is that Maven or Gradle isn't the prerequisite to avoid the project files in version control. The real prerequisite is the simple setup of you project and a clean structure, so that importing the project is just a couple of clicks. Then you can cope with any kind of project, even if it doesn't contain pom.xml.

And here's what most of them say about the topic:

Myself, I have tried both ways - keeping the project files in version control and not checking them in, and my take is that under no circumstances it is a good idea to check the project files in. Again, a much better solution is to keep your project structure clean and simple, which might be harder than to check the files into version control, but much more beneficial on the long run.

Thanks everyone for the input! Take care...

Installing Erlybird Netbeans Plug-In

Nivir asked me how to install erlybird plug-in for Netbeans. So here's the guide.

1. Have your favorite Netbeans distro installed.


2. Download and unzip the erlybird distribution. This one, for instance.


3. Select "Plug-ins" from the "Tools" menu of Netbeans, and select the "Downloaded" tab in the dialog that appeared. Then you can hit "Add Plugins..." and select all the files that were extracted from the erlybird distro.
   
   

That's it just hit the "Install" button now on the bottom-left and the plug-in gets installed.


4. After the plug-in gets installed, it will take quite some time for it to initialize. So be patient.
   
   

Erlybird: the Erlang plug-in for Netbeans

Erlybird looks very fine while working in Netbeans. Unfortunately Erlide (the Erlang plug-in for eclipse) wasn't that smooth.



The strange thing about the plug-in settings is that it shows itself like if it would be a JRuby plug-in:



What could be done better, I think, is when I run a script, instead of the erl interpreter I could choose a function to be used to start the script. So it could look like any other program I'm running in IDE.

The NetBeans Day @ JAZOON

The real name for the event was NetBeans Day - Get to know the only Java IDE you need. I didn't expect it to be very interesting but at the end of the day I can say that there were a lot of good things to pick up from this tutorial. So what was it really about:

• NetBeans new and Cool by Romal Strobl. At the talk Roman showed what are the new things that were added to NetBeans 6.1 and some tricks and tips how to use the IDE. From my point of view, NetBeans is just copying the best features from IntelliJIDEA and eclipse. The IDE looks nice, the features are reasonable, but isn't it plagiarism in respect to the other IDE vendors?! FWIW, personally I do like NetBeans even more that eclipse.


• Isolating Performance Bottlenecks and Memory Leaks by Peter Gassmann. This was an in-depth review of NetBeans Profiler which is really easy to use, and specially with Java 6. I have to give it a try! :)


• SwingApplication Framework and Beans Binding by Roman Strobl. This was about JSR-295 (Beans Binding) and JSR-296 (Swing Application Framework). In fact both of this specs look promising in sense of desktop application development. There's a very good suport for that in NetBeans also, which is cool! But what disturbs me is that in the resource injection, which is claimed to be "automatic", you have to write some code (e.g. call a method setName(String) for a Swing component that needs some some configuration. In my opinion this is not really automatic way to do things and there should be more elegant solution. Writing your own Java code to make things work "automatically" - this is kind of a stupid thing.


• Incorporating Animation and Media using JavaFX by Rags Srinivas. I cannot tell why but I still being skeptic about JavaFX. It looks lika Sun is positioning JavaFX as a technology for cross-client UI development. That's OK. But as a language, JavaFX looks very odd. For small UIs it may be a nice tool, but I doubt that for the larger apps it will be very complicated to use and the code will be hard to follow. The technology is still in development and Sun promised to finalize it by the end of the year.


• NetBeans Mobility by Roman Strobl. This is the most interesting feature in NetBeans perhaps that I have seen this time. Constructing the application workflow visually using NetBeans is something I was really missing at the days when I did some J2ME development. Definitely, if I'd had to develop and application for mobile phone today, I'd used NetBeans just for this feature! A very nice feature of NetBeans Mobility Pack is that it provides some basic support for game development, and this is something that I was missing the most!

Roman Strobl was the guy who made the day. The presentations were very well prepared and we gotta thank Roman for that :). The only thing that I would suggest is to add more live coding to the presentations.
So to conclude, I'm quite satisfied with the sessions and I've picked up some useful stuff as well.