10,000 Foot Developer

EC Tech meeting for Build Servers went with a hitch as I tried to get a BigBlueButton server up and going for collaboration. This software is open source meeting/record software, but as with all open source the price to pay is with time and inconvenience.

Two things that take a lot of time to do:

• Full documentation
• Full automation

We often have arguments about how in depth to document something. Audience is a key factor. But I think, to really get the “open source” ribbon you need someone besides advanced developers and admins to be able to use the stuff — that is, issuing api’s out of the box to create a new meeting session is, IMHO, a severe usability problem.

Big Blue Button isn’t there yet. It’s good stuff and I will use it because I paid the price, but its not there and I fear for its longetivity. For instance, in order to create new meeting instances you have to be able to understand how to execute a web api command. This sounds simple for developers — but for a regular user? The command has to include a checksum value that a user has to generate and the documentation is written pretty poorly. I went down this road last night: downloaded the software just to find out you needed to either run it in a virtual machine OR only on a version of Ubuntu.

This explains why, when I asked two professional instructors from Awesome Dudes and Euler Solutions in the Twin Cities, both balked at my meeting software requirements and said “its not trivial, us Google Hangouts.” So I finished the meeting up like that, but didn’t get to record anything.

——

The meeting was finished up at the Tomahawk Room in Chippewa Falls with a Google Hangout. I only managed to spike a Maven archetype creation of a Spring/Hibernate application, so this topic may be swung back to do again. Buildr is intriguing to me and I’ve used Gradle in some tutorials; a lot of people talk about it.

Now one thing I would like to discuss is why developers should be using a build engine like these, even if you are just spiking an application. People will argue “well Maven is too heavy duty.” Etc. I would argue that its necessary now to start an application like that in many cases. First, are you going to test? These systems give you the harness to do that. Use dependencies? Then use these. Dropping in jar files is absolutely insane these days; minimally use Ivy. The dependency charts and management of them for your imports will drive you nuts. These build tools automate all of that.

I do simple tests in a simple Eclipse project sometimes using JUnit as my “main.” But for doing anything else I start with a build tool. Groovy has “Gant” — a wrapper around Ant for its base, and using Maven is simple enough. Scala works well with SBT or Maven.

You get with build tools:

• Goals for different stages in your development: building, testing, deployment etc.
• Directory structures
• Base application soup broth(for starting out)
• Integration into build servers/build from command line = Automation
• Dependency management

These tools make life way simpler.