An amusing take on the development ‘game’, and unfortunately, you’ve probably worked with someone like this…

3 Simple Rules that will make you a ‘Superstar’developer

NB:Read to the bottom before you get upset….

Ever since attending the SpringOne 2GX conference, I’ve been intrigued by Groovy. I’ve finally had a bit of time to start working with it, and decided to share some of the niceties of Groovy. This post is a very simple example of the differences in coding between Java and Groovy, so expect to see more as time, and my knowledge permits.

The first thing I really liked about Groovy was the removal of explicit setters and getters. I’ve always hated the clutter, and especially since it makes it harder to see if any getter/setter is doing something ‘special’, or if there are methods that aren’t setters/getters.

So, a simple bean defined like so in Java to support easier setting of variables

public class Bean {
    private long numberOfCompanies;
    private long numberOfUsersPerCompany;
    private long numberOfSecureMessages;

    public long getNumberOfCompanies() {
        return numberOfCompanies;
    }
    public Bean setNumberOfCompanies(long numberOfCompanies) {
        this.numberOfCompanies = numberOfCompanies;
        return this;
    }

	// code snipped here
}	

//used like this
    growthRequest
       .setNumberOfCompanies(1L)
       .setNumberOfUsersPerCompany(1L)
       .setNumberOfSecureMessages(2L);

becomes this in Groovy

public class bean {
    long numberOfCompanies
    long numberOfUsersPerCompany
    long numberOfSecureMessages
}

 // and gets used like this
growthRequest.identity {
   numberOfCompanies = 1L
   numberOfUsersPerCompany = 1L
   numberOfSecureMessages = 2L
}

// or like this, without defining a constructor...
	GrowthRequest gr = new GrowthRequest("numberOfCompanies:1L", "numberOfSecureMessages:2L", "numberOfUsersPerCompany:1L")

Groovy also supports the concept of a read-only property. It uses the final keyword, which is a little confusing to us Java devs, as the field isn’t final in the Java sense. A getter will be defined in the public interface of the Groovy object, but the object can still modify the value internally.

Another case that is very nice is long strings, or strings that are concatenated with variables. In Java, we have

String s = "some text that is long " +
	"and some more text that goes here" +
	someVar + " more text and more";

whereas Groovy would have

String s = """some text that is long
	and some more text that goes here
	${someVar} more text and more"""

If your string is just a regular string (i.e. no variable replacement), you can use apostrophes. If you use a single quotation mark, or triple quotation marks, then Groovy will parse the string to search for replacements. So, for performance reasons, unless you need a variable replacement, use apostrophes for strings.

The heredoc format allows for much easier test string generation. For example

String s = """
	<xml>
		<entities>
			<entity>1</entity>
			<entity id="idValue">2</entity>
		</entities>
	</xml>

Keep in mind that I’m intentionally typing variables. Groovy allows for no typing as well, so the previous example could merely def s.

The conference was excellent.

The VMWare acquisition seems like it will be good for SpringSource. They want it to broaden their product offerings, and don’t have anything that directly competes. Beginning entry into Cloud computing with Cloud Foundry. You can either use it hosted by them, or install it in your own server room. All attendees will receive 48 hours of credit for use of Cloud Foundry, so I will definitely be experimenting.

Rolling out more developer editions of tools to entice us developers to use their tools. SpringSource Tool Suite is now free, and incorporates additions for their entire line. It even has a deployment tool for Cloud Foundry.

They are actively developing the Groovy/Grails Eclipse plugin as well, and are making great headway here. At the conference, the developer had a very interesting presentation on the difficulties of integrating the Groovy compiler with the Eclipse JDT compiler.

tc Server now has a developer’s edition too. In combination with the SpringSource Tool Suite, and Spring Insight, allows for digging into the actions an app took, and how long each step took. Have to do some investigation to see how well this works with a minimally Spring based app, as they used a Grails app for the demo.

Spent most of my time on the 2GX side of the conference. Decided to take the opportunity to learn more about this. Very interested in Groovy, especially since it interacts very nicely with Java. Several presentations on using Groovy to write tests for Java code, and some of the benefits possible as a result. Groovy (like other languages that are dynamic, and support closures and meta-programming) are very powerful and flexible. Groovy also requires less typing to achieve the same result as Java.

Attended 2 sessions on Gradle. The developers of Gradle developed it because of frustrations with the limitations of Maven. The developer presenting was obviously very familiar with Maven, as evidenced by his responses to questions by attendees that knew Maven very well. It leverages Maven and its central repository, and adopts Maven’s philosophy of convention over configuration BUT if you don’t like it’s convention, or want to extend it’s definitions, it is easily accomplished. Yay to a distinct integration test task, with its own classpath and dependencies!

Overall, an excellent conference, and I will post additional details as time permits.

Day 1 was mostly about registration, checking-in and the keynote. Here’s a great summary of what was covered in the keynote. KeyNote summary.

I’ve mostly been looking at Groovy sessions, and can see a lot of potential here. Will keep providing updates as the conference progresses.

Definitely want to look more at the tc Server. SpringSource/VMWare are hopeful companies will use it instead of Jboss/Websphere/…

They demo’d the new developer’s edition with Groovy and Grails, and were able to dig into all the queries. Great way to find bottlenecks when performance isn’t working well. Don’t know if it can do it with Java/Tapestry/Hibernate, but likely no reason it can’t. Obviously they’re leveraging the HtpericHQ acquisition for aspects of this.

In a previous post, a colleague was venting about having to manage the version control system with a commit token. Basically, the token is held by someone while they’re doing there commit, so that no other developer is supposed to commit, and potentially create conflicts. As a number of us are using CVS, this is a real issue. CVS handles each file individually, so it may stop the commit of only 1 file, thus leaving the repository in a broken state.

But this is only one of the reasons for having the commit token. The other major reason is ensuring that developers have tested their code with the latest version in the repository before committing. A process is in place once a developer recieves the token.

• update
• fix conflicts
• run tests
• commit

This is done to reduce the chances that broken code ends up in the central repository, thus impacting the other developers, and their productivity.

To reduce queue sizes, various guidelines can be used, such as no retrieving the token unless you’ve recently done an update and run the tests.

Bottom line, it can be managed….. BUT as others have said, is there a better way? Do we need an artificial, external locking mechanism?

The answer would appear to be no, as long as you’re willing to move to a new VCS. Of course, this has it’s own potential issues, but I’m currently spearheading an initiative on my team to start using Mercurial for our development.

Mercurial is a distributed VCS. It uses atomic commits (Subversion was one of the early implementors of this feature), and tracks renames. It also makes branching AND merging very easy.

Doing a quick experiment, if 2 developers were to commit, one would succeed, and the other would be warned that they’re attempting to create a new head. So, developer 2 would know someone else committed, and that they need to do the update/merge/test/commit cycle. So, theoretically, there would no longer be a need for an explicit commit token.

Even if the token concept is persisted, or I’m waiting for other developers to complete a large commit, I can commit my changes locally, do some more work, do another commit, and then when I’m allowed to ‘commit’ to the central repository, I merely update, test and push.

If I’m in the middle of something, I can shelve my outstanding changes to update/test/push, and then unshelve to return to where I was at.

There are many more advantages of Mercurial, and as my team starts using it next iteration, I’ll keep posting updates.

A colleague was working on a unit test the other day, and couldn’t figure out why it wasn’t working correctly. At a high level, here’s the testing code.

List<String> strings = new ArrayList<String>();
strings.put("value");

ListLikeAPIObject mockObject = mock(ListLikeAPIObject.class);

context.checking(new Expectations() {{
	exactly(2).of(mockObject).iterator();
		will(returnValue(strings.iterator());
}}

and this is the code in the class under test:

ListLikeAPIObject listObject = apiCallToGetList();
for(Iterator iter = listObject.iterator(); iter.hasNext();) {
	doSomething();
}

and the above method gets called twice during execution of the method being tested.

On the second call to listObject.iterator(), the for loop doesn’t do anything.

JMock ‘caches’ the result of the returnValue option, and returns the same object each time that method expectation is reached. The first time it’s called, strings.iterator() is at the beginning.

The next time it’s called, the iterator is now at end, so the for loop doesn’t process anything.

JMock2 has a built-in return Action for handling this case. There are several others defined (look at implementors of Action), and shortcut methods defined on Expectations. Taking advantage of this results in the following:

context.checking(new Expectations() {{
exactly(2).of(mockObject).iterator();
	will(returnIterator(strings));
}}

The returnIterator constructs a ReturnIteratorAction. The ReturnIteratorActions stores the collection, and then calls strings.iterator() everytime the mocked method is called.

I was working on a page recently that displayed a number of items for a user to choose. Visually, it displays as a long list, with checkboxes and descriptive text.

The user has the option to select/deselect all items on the page. I was doing stress testing of the page, as the client had told us there could be up to 4000 entries on the page. Don’t worry, this page will be re-designed, but for now…

I was testing in Firefox, and selecting/deselecting all items was very quick. I then tested in Internet Explorer, as our client’s mandated browsers are Internet Explorer 6 and 7 and Firefox 2.

I have IE 8 installed, and it was taking 10-12s to select/deselect all. I then asked one of my co-workers to attempt it with IE6. IE6 timed out!

Needless to say, this is unacceptable performance.

Time to dig into the javascript.

Here’s the original code:

var count = 0;
var checkboxes = document.getElementsByTagName("input");
for (var i = 0; i < checkboxes.length; i++) {
    var element = checkboxes[i];
    if (element.type == 'checkbox') {
        ++count;
    }
}

The page doesn’t have much code outside of the long list, but I had to do something, so the only thing I could see was getting the ul that contains the list items, rather than searching the entire document. So, here’s the modified code

var ulField = document.getElementById("permission.list");
var checkboxes = ulField.getElementsByTagName("input");
for (var i = 0; i < checkboxes.length; i++) {
    var element = checkboxes[i];
    if (element.type == 'checkbox') {
        ++count;
    }
}

Basically, retrieve the ul, and then search within it.

That one minor change made it so that even in IE6, the select/deselect all on 3000 items has a negligible delay.

Moral: Be as specific as possible as soon as possible, even if it doesn’t seem like it should make a difference.
Moral2: Internet Explorer’s javascript engine is slow….

When browsing through some code on one of our pages, I noticed the following:

function selectAllCheckboxes() {
    var count = 0;
    var checkboxes = document.getElementsByTagName("input");
    for (var i = 0; i < checkboxes.length; i++) {
        var element = checkboxes[i];
	if (element.type == 'checkbox') {
	    element.checked = true;
            ++count;
	}
    }
    updateSelectedCheckboxCount(count);
}

function unselectAllCheckboxes() {
    var checkboxes = document.getElementsByTagName("input");
    for (var i = 0; i < checkboxes.length; i++) {
        var element = checkboxes[i];
	if (element.type == 'checkbox') {
	    element.checked = false;
	}
    }
    updateSelectedCheckboxCount(count);
}

function updateSelectedCheckboxCount() {
    var count = 0;
    // count the number of checkboxes selected on the page
    var checkboxes = document.getElementsByTagName("input");
    for (var i = 0; i < checkboxes.length; i++) {
        var element = checkboxes[i];
	if (element.type == 'checkbox') {
	    if (element.checked == true) {
	        ++count;
	    }
	}
    }
    updateSelectedCheckboxCount(count);
}

There’s a lot of duplication there, and only 1 or 2 lines unique to each function. So I refactored the code to take advantage of the fact that Javascript supports passing functions.

Here’s the modified code.

function selectAllCheckboxes() {
    processCheckboxes( function(checkbox) { checkbox.checked = true; ++count;} );
}

function unselectAllCheckboxes() {
    processCheckboxes( function(checkbox) { checkbox.checked = false;} );
}

function updateSelectedCheckboxCount() {
    processCheckboxes( function(checkbox) { if(checkbox.checked) { ++count; } );
}

function processCheckboxes(checkboxProcessFunction) {
    count = 0;
    var ulField = document.getElementById("permission.list");

    var checkboxes = ulField.getElementsByTagName("input");
    for (var i = 0; i < checkboxes.length; i++) {
        var element = checkboxes[i];
	if (element.type == 'checkbox') {
	    checkboxProcessFunction(element);
	}
    }
    setSelectedCount();
}

This way, if the process of getting checkboxes can be improved, the code only has to be changed in one place.

So, don’t forget that javascript is a functional language…

The following table outlines how you can modify the passed parameter.

The following table shows how you can combine some of the parameters.