Understanding Software Workflows

As Computer Engineering progress, it is foraging a new path in the world.  Companies that used engineers in the past, such as the automotive and aviation industries, have been focused on figuring out why the world is changing so quickly around them.  Computer engineers are forcing this change due to the fact that they are doing things faster and requiring much more transparency than ever before for products to be successful.

The eclipse development teams have been paying attention to this as well.  Mike Kerston covers how Eclipse is taking this problem head on at EclipseConn.  The video below also covers some of the common threads in the open and closed source communities at present.  Definitely a good watch.  Even if you don’t want to watch the whole thing, everyone should be adopting these tools (or an acceptable alternative) into any new project going forward, and if possible, retrofitting older projects to use this as well.

Git and GitHub - IMO, The hands down best from of Source Code Management (SCM) out there.  This is specifically a Distributed form.  Please ditch Subversion.
Mylyn / TaskTop - Task Management tools, very useful for a developer or a PM.  Mylyn can track your time and the files you are working for for particular task (and so much more).  TaskTop is a tool which you can purchase that works on top of Mylyn and provides you with a bunch of tools, which are just plain awesome for any freelancer.
Bugzilla / JIRA - BugZilla is open source and needs to be hosted, JIRA is closed source and hosted for you (which is free for open source project only).  Either one provides you with a solid way of tracking user stories and bugs.
Hudson / Jenkins - Essentially the same thing, as they are a fork of the same codebase, these are some of the best in Continuous Integration, and they are free (but you also have to host it).
Gerrit / Crucible - Code review tools.  Gerrit is specific to Git.  Crucible should work on Git or Subversion, but will cost you.  The upside to Crucible is you can tie it into JIRA really well.

Making the Maven Version and Subversion Version Match

Let me start this out – this is strongly discouraged. Not only by me, but by Maven and any standards that you will ever come across. Your release version should almost never be your SCM version. Some tools allow you to pull in the SCM version as a variable and use it as a maven variable. This is great, because you can inject it into places to tie your release version to your project. Note the difference. I even wrote a great article about injecting variables into WAR files here and you can use the buildnumber plugin to inject your build numbers!

But, some groups (we’ll just nickname them “Oogle” for now) are being annoying and don’t want to do full blown releases, as that might mean that they have to support old releases. I totally understand that principle, so I’m not going to knock it. But, if you don’t have a release, how does one differentiate between versions?

Well, at this mythical company Oogle, they have stated you should use their subversion revision as the way to refer to their releases. Well, we can do that, but God help us if you switch to Git or some other form of DVCS. One thing about release numbers is that they should be sequential, so that you know which version precedes another, and human readable. In many of the new DVCS flavors, they use the SHA-1 hash, which is some long string of numbers and letters that is not sequential, nor human readable. But, for now, we can work with Subversion.

So, now we have a predicament. We need to do something that Maven strongly discourages (and can’t really work with by itself – it needs to know the version, so no variables are allowed in the project version tag). Thinking about this, we could run two maven pom files. One to set the version in the second pom file, and the other does the release. Problem is when you are working with Continuous Integration. Many of the CI servers (Hudson, Jenkins, etc.) expect one pom file to be executed for a release. Hudson/Jenkins can execute an ant command followed by a maven command though… It’s getting sticky.

Rather than you following me down the rabbit hole, let me just show you the solution that I’ve come up with.

First, create a template pom file. This will overwrite your pom.xml every time the build.xml is run.

1
2
3
4
5
6
7
8
9

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.github.jlgrock</groupId>
	<artifactId>myId</artifactId>
	<version>@SVN_VERSION@</version>
	<packaging>pom</packaging>
…
</project>

Next, create an Ant Script as build.xml at the root level of your maven project.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<project name="MyProject" default="createPomFromTemplate" basedir=".">
 
	<description>
    	This will replace the version number in the maven file with the current revision 
		within Subversion.  This requires a machine with a c-shell and subversion installed.
    </description>
 
	<property name="url">http://whatever.my.com/server/address/is/</property>
 
	<target name="createPomFromTemplate" depends="svnInfo" description="Will copy the pom-template.xml to pom.xml, making the appropriate replacements.">
		<copy file="pom-template.xml" tofile="pom.xml" filtering="yes" overwrite="yes">
			<filterset>
				<filter token="SVN_VERSION" value="${build.version}-SNAPSHOT" />
			</filterset>
		</copy>
	</target>
 
	<target name="svnInfo" description="Open a c-shell and execute a subversion command to get the current version">
		<exec executable="sh" outputproperty="build.version">
			<arg value="-c" />
			<arg value="svn --non-interactive info ${url} | grep Revision | awk '{print $2}'" />
		</exec>
	</target>
 
</project>

OK, what does this do? The svnInfo goal (btw – I think this only works on linux-style machines) will execute, via c-shell, a command to query the server for svn info. This will return a large block of text, of which, we only need a small amount of text. So, we pass this through to the grep command, followed by the awk command. The result of the grep command will be something like “Revision: 4233” and the result of the awk command should be something like “4233”. You can test this locally if you want to see each of those in action.

Next, it takes that value and shoves it into a variable (${build.version}). Then, it does a copy of the template file, searching through the template file, where I have no version but have put @SVN_VERSION@ as a placeholder. It replaces the string “@SVN_VERSION@” with “4233-SNAPSHOT”.

OK, next we have to create the pom-template that it can work on.

Now the Continuous Integration environment can execute the release plugin on the Maven pom and the release version will match the subversion version. You can test that by running ant. It will create a pom.xml for you.

Next, I do a full blown maven release with the following:

1

mvn clean release:prepare release:perform

This will release with the subversion number to the Nexus or https://github.com/jlgrock/ClosureLibrary

Is it pretty? No. Does it work and is it maintainable? Very much so.

jQuery and ImpressJs

So my buddy did a JQuery rehash for people in our company.  In my opinion, it doesn’t need to be sold.  People like JQuery cause it is easy and the learning curve to do some things is easy.  It follows the old Perl mantra: “Try to make simple things easy, and complex things possible”.  Few folks can argue with that.

More interesting, in my opinion, than the subject material, was his choice of presentation tools.  He chose to use the Impress JS library. It functions like prezi, but with WAY more configuration options (pretty much anything you can think of doing to the DOM).

He posted his presentation on his website here and put the code up on GitHub here.

WordPress Child Themes

I recently got a subscription to https://www.elegantthemes.com/.  Sometimes it’s easier to buy.  It was on the customer’s dime anyways.  I originally did this for a subdomain site for GMU for their german department (http://germanevents.gmu.edu/).  It came out pretty well.  Hopefully they do a decent job managing the content.

In general, the guys at elegant themes did a great job in designing their themes.  Since I had access to all of their themes, I grabbed a bunch of them.  I realized the most that they did a decent job when I used one of the templates on my own site (<a href=”http://jlgrock.xtreemhost.com/“>this one!</a>).  I liked it, but of course I had to customize the crap out of it.

Here was the original site: http://www.elegantthemes.com/gallery/lightbright/.

Mostly, the things that I needed to tweak were sizes, which is all contained in the CSS.  My assumption is that if you are a decent developer, and thus use my site, you are not going to be running on a 640×480 screen.  Hardly what I would consider to be unreasonable.

Since they also do a pretty good job on this site at pushing updates to customers, I didn’t want to screw that up by messing with their templates.  Low and behold, there’s a little known ability to create a “Child Theme” in WordPress.  I love it!

I looked over a bit of Theme development documentation by reading the article at http://codex.wordpress.org/Theme_Development. Followed by Child Theme development is described at http://codex.wordpress.org/Child_Themes. You can also find a simple
example that just modifies the css by following the instructions at http://op111.net/53/.

Anyways, there was one minor hickup (the Elegant Themes folks are using some funky “truncate” that also strips out formatting, which I didn’t want), but otherwise, this went really smoothly. This has adjusted the sizes and added additional features to support Facebook and Google+. I posted the code for anyone who wants to learn Child theme development or is extending anything from the Elegant Themes templates at my LightBrightChild github project.