I think that the software development methodologies form a spectrum from the ones that require the most up front design to the least.  I see the most commonly used methodologies shaking out in this order (this isn’t meant to be all inclusive):

Waterfall -

• requirements, design, implement, test, release

Mini Waterfall

• requirements, design, implement, test, release, repeat

Scrum

• add known issues and wants to feature backlog, group features into sprint (2-4 weeks development), prototype as needed, development and test, repeat

Extreme & Microsoft Agile

• create user story, prototype as needed, break story into developer & designer tasks, implement and test task implementations, repeat

Cowboy Coding

• design interfaces and write code, show it to people
• I think the name makes is sound worse than it is.

Most of the time, people talk about whether to use agile methodologies or more traditional waterfall approaches.  I think this misses the more common scenario at startups, where they are often using cowboy coding to get things done.  The name doesn’t make it sound all that good, I think that “cowboy” sort of refers to the fact that developers are off writing code and no one knows what the hell they are doing.

Agile development strategies and waterfall are designed in a way to give metrics that can help non-team members have the warm and fuzzy feeling that they know how things are progessing, and are helpful to the team to some degree as well.  I’m not trying to weigh agile techniques against waterfall, as far as I’m concerned, that ship has sailed and agile is the only way to go.  I am trying to contrast the difference between formal approaches and informal approaches.  In cowboy coding, you don’t have metrics, only a system that is hopefully taking shape.  This is hard for non-team developers to project and resource against, and it’s hard for non-team people to work with.

Basically, I see cowboy coding as being the cult of the developer, and the more formal methods as being centered around project managers and other folks.

Think About The Great Startups

I don’t think that Page & Brin were having sprint meetings and working with product managers.  I don’t think that Fake and Butterfield from Flickr were sitting around having meetings all day long.  Zuckerberg understood the idea of Facebook when it was explained to him, took the idea for his own, and ran with it (so it is said).

All of these companies were probably doing their most important foundational work with cowboy coding and not that many people.  Later, they hired many more people and switched to formal development approaches to ensure that they could have developers working towards the ends sought out by the business development people, but at the start, I think they were all cowboy.

It’s just my alternate view on the whole agile vs. waterfall discussions that happen often.  What about agile vs. cowboy?  What about hiring good developers and just telling them to roll on the idea.  Okay, it’s hard to manage and won’t work on scale, but are you at scale yet?  At least think about it before you put in more process than makes sense.

java.lang.NoClassDefFoundError: org/springframework/core/NestedExceptionUtils
        at org.springframework.core.NestedRuntimeException.getMessage(NestedRuntimeException.java:67)
        at java.lang.Throwable.getLocalizedMessage(Throwable.java:267)
        at java.lang.Throwable.toString(Throwable.java:343)

Go into your /etc/init.d/tomcat file and change

# Use the Java security manager? (yes/no)
TOMCAT6_SECURITY=yes

to

# Use the Java security manager? (yes/no)
TOMCAT6_SECURITY=no

Don’t leave it like this, but it will fix your problem, you are having a file policy issue and will need to make additions to your security policy to allow web applications to read files.

• + It’s super easy to deploy to
• -The persistence feels really unatural. You just create JPA objects and use their persister, no DB create scripts
• + No DB create scripts, I think I’m going to like this once I’m used to it
• - I’m not sure how data export and migration works

Pretty neat though, you should try it out if you can still sign up for the beta.

You need a persistent class.

package com.nthread.babelhelp.datamodel;

import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;

@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class HelloGDB {
	@PrimaryKey
	@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
	private Long id;
	@Persistent
	private int count;

	public HelloGDB(int count) {
		this.count = count;
	}

	public Long getId() {
		return id;
	}

	public void setCount(int count) {
		this.count = count;
	}

	public int getCount() {
		return count;
	}
}

You have to use a singleton to keep your static PersistenceManagerFactory - if you try to instantiate it twice, you will find your app pretty unhappy.

package com.nthread.babelhelp.model;

import javax.jdo.JDOHelper;
import javax.jdo.PersistenceManager;
import javax.jdo.PersistenceManagerFactory;

public class Persistor {
	private static PersistenceManagerFactory pmfInstance =
		JDOHelper.getPersistenceManagerFactory("transactions-optional");

	public static PersistenceManager getManager() {
		return pmfInstance.getPersistenceManager();
	}
}

I just use these things from a Servlet, it’s pretty basic.

package com.nthread.babelhelp.control;

import java.io.IOException;
import java.util.List;

import javax.jdo.PersistenceManager;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.nthread.babelhelp.datamodel.HelloGDB;
import com.nthread.babelhelp.model.Persistor;

public class HelloWorldServlet extends HttpServlet {

	protected void doGet(HttpServletRequest req, HttpServletResponse resp) {
		doRequest(req, resp);
	}

	protected void doPost(HttpServletRequest req, HttpServletResponse resp) {
		doRequest(req, resp);
	}

	protected void doRequest(HttpServletRequest req, HttpServletResponse resp) {
		PersistenceManager pm = Persistor.getManager();

		String query = "select from " + HelloGDB.class.getName();
		List hellos = (List) pm.newQuery(query).execute();

		HelloGDB helloGDB = null;
		if (!hellos.isEmpty()) {
			helloGDB = hellos.get(0);
		} else {
			helloGDB = new HelloGDB(0);
		}
		helloGDB.setCount(helloGDB.getCount() + 1);
		try {
			pm.makePersistent(helloGDB);
		} finally {
			pm.close();
		}

		String str = "Current count is " + helloGDB.getCount();
		try {
			resp.getWriter().write("" + str + "");
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	}
}

The filter is a pretty lame filter called StrangeFilter. All is does is forward requests with a parameter set.

package com.nthread.sandbox;

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;

public class StrangeFilter implements Filter {

	private FilterConfig filterConfig;

	public StrangeFilter() {
		// TODO Auto-generated method stub
	}

	public void doFilter(ServletRequest request, ServletResponse response,
			FilterChain chain)
			throws IOException, ServletException {
		if ("okay".equals(request.getParameter(""))) {
			this.filterConfig.getServletContext()
				.getRequestDispatcher("/fail.html")
				.forward(request, response);
		} else {
			chain.doFilter(request, response);
		}
	}

	public void init(FilterConfig filterConfig) throws ServletException {
		this.filterConfig = filterConfig;
	}

	public void destroy() {
		// TODO Auto-generated method stub
	}
}

To test this filter without a web container is really pretty easy. You need to make use of four Mock classes provided by the Spring test framework, but basically, it’s just as easy as any other unit test. I think the code pretty much speaks for itself, so here it is.

package com.nthread.sandbox;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNull;
import static org.junit.Assert.fail;

import java.io.IOException;

import javax.servlet.ServletException;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.springframework.mock.web.MockFilterChain;
import org.springframework.mock.web.MockFilterConfig;
import org.springframework.mock.web.MockHttpServletRequest;
import org.springframework.mock.web.MockHttpServletResponse;

public class StrangeFilterTest {

	private StrangeFilter filter;
	private MockHttpServletRequest request;
	private MockHttpServletResponse response;
	private MockFilterChain chain;

	@Before
	public void setUp() throws Exception {
		filter = new StrangeFilter();
		filter.init(new MockFilterConfig());
		request = new MockHttpServletRequest();
		response = new MockHttpServletResponse();
		chain = new MockFilterChain();
	}

	@Test
	public void testDoFilterWithFail() throws IOException, ServletException {
		request.addParameter("failThis", "okay");
		filter.doFilter(request, response, chain);
		assertEquals("/fail.html", response.getForwardedUrl());
	}

	@Test
	public void testDoFilterWithoutFail() throws IOException, ServletException {
		filter.doFilter(request, response, chain);
		assertNull(response.getForwardedUrl());
	}

}

Quartz

Quartz is really the only framework that is widely supported in Java:

• It has great Spring support, outlined at http://static.springframework.org/spring/docs/2.5.x/reference/scheduling.html. This is definitely the best way to use Quartz in most cases.
• Quartz can be run programatically, but you have to write a tiny bit of code to do it. There is a quick start guide on the quartz site - basically, you need a properties file and a main class, so not that bad. Still a little harder than the spring way, so not desirable.
• It is very easy to run Quartz as a servlet - the documentation is actually contained in the Javadoc. It’s similar to the programatic method in that you need to write a properties file, but you don’t have to write a main method, and that’s a good thing.

Quartz is solid, use it if you need scheduled tasks. The Canuck’s just scored, and I’m going to watch the game now.

Code Coverage

Code coverage reports are a great way to tell if your have written enough unit tests for your code. Generally, your tests should cover at least 90% of your code, and once you have code coverage tools, you will probably feel compelled to reach high %s of coverage. I looked around at a bunch of tools and tried out what I could. There were three tools that stood out (for good reasons, coverlipse killed my eclipse install, and I don’t really recommed trying it).

Cobertura

Cobertura

Cobertura was very easy to get running with Maven, but was a little more challenging with Ant. Generally a really good tool but not that easy to integrate into eclipse, the UIs are the most visually appealing.

CodeCover

CodeCover Screenshot

CodeCover was really well integrated with Eclipse and works pretty well out of the box. Definite a plus. I didn’t really like the mechanism for adding classes, but if I used a normal Maven project setup, that would probably be fine. This is a good tool for local development, but the team tools are not that extensive.

Clover

Just for completeness, I should give the atlassian product mention. While a good product, Atlassian (the makers of Jira) at starting to be a little too expensive.

Overall, I like these tools a lot and hopefully this will help you get started with them.

97 Things Every Software Architect Should Know has a very good list of gotcha’s and rules of thumbs for software architects.

The thing that got me thinking about this was Agile Architecture, a good blog today about keeping architecture moving along during a project, always a good idea.

All of these are good reads, and it makes me think about the useless courses in software engineering I took in university where professors spent hours excitedly talking about the capability maturity model. I guess it didn’t matter, I really didn’t know how to work through a big project in school.

• A key thing with any project is that the development and design be broken up into phases that are small enough to think through and get done.
• If the tools and frameworks that you are trying to develop with are hard to use or seem like a pain to develop with, they just aren’t the right ones. There are easy to use tools for everything out there.
• In general, do a project the easiest way possible. Sometimes people try to do things because they feel like they are the “right” way to do things, even though they aren’t the easiest. These are not the right way to do things.

Keep it simple.

• JSON support, really SOAP wasn’t that much of a requirement, but all of the mature libraries support it.
• Simple to setup and develop with
• Easy to maintain services

First, I tried my old standby Apache Axis.

• I found it fairly difficult to find documentation on running Axis services in a web container. Whatever, I got through that, it’s actually pretty easy once you find the right page.
• Running JSON services is not that easy. Axis default to adding namespaces to everything, but the out of the two JSON types:
  • Badgerfish - the formatting is just wierd, and not that great for typical Javascript development
  • Mapped - this was normal, but then really didn’t work well with namespaces
• All of this really lead to having to hand edit the WSDL files to get a good result with JSON services. This really isn’t that great for maintaining.
• Also, it just seemed like too many jars were brought in by the Axis pom file

So I moved on to trying out JAX-WS from Sun.

• Setting up a SOAP based web service using these libraries was a little bit tough in terms of finding good documentation, but turned out to not be that bad.
• Building JSON with the JAX-WS was a disaster. Neither of the libraries I could find really worked at all.
  • JAX-WS Commons JSON was the first library I tried. The basic setup was pretty easy, but it just doesn’t work well with object return types. So a no go.
  • http://code.google.com/p/jsonwebservice/ was the second library I tried out - again, it just didn’t do it.

At this point, I was still developing on Axis and kind of resolving myself to having to maintain a WSDL file but I stumbled across Jersey. Jersey is Sun’s REST library, and while I wasn’t necessarily looking for a resty library:

• Jersey works! This page has a good outline of what you need to do from maven to web container.
• It’s so easy, JSON, SOAP, both super easy. Not much config, just point your web.xml at the packages with your services.
• The test framework is very well thought out too, and works well with JUnit.

And that’s it. Use Jersey, and hope that Oracle likes it (so they don’t make it disapear).

Just to give you a flavor for how it works, I’ll outline how I used it. To start, I created a JSON data file - typically this would be fed by a web service, but for getting up and running, a file is easy.

userdata.json:
{ users : [
{ name: "John Doe", email: "john.doe@nthread.com"},
{ name: "Jane Doe", email: "jane.doe@nthread.com"}
] }

Then I created a really basic web page. The page had a div where the templated HTML would be placed:

<div id=’userlist’ ></div>

And imported the jQuery & JST scripts in the header:

<script src=”scripts/jquery.min.js” type=”text/javascript”></script>
<script src=”scripts/trimpath-template.js” type=”text/javascript”></script>

Next, I created the template, which needs to be placed in a textarea. All of the templating libraries I have seen use a textarea for this, probably because it is the only place on a web page where you can avoid the browser parsing the HTML into DOM elements (which leads to escaping):

<textarea id='userlist_template' style='display:none' >
 <ul>
 {for user in users}
 <li><a href='mailto:${user.email}' >${user.name}</a></li>
 {/for}
</ul>
</textarea>

Finally, a small piece of JST & jQuery is used to load the JSON file in process it through the template:

<script type="text/javascript" >
 $(document).ready(function() {
  var data = $.getJSON("users.json", null, showData);
 });
 function showData(data) {
     var userlistTemplate = TrimPath.parseDOMTemplate("userlist_template");
     $("#userlist").html(userlistTemplate.process(data));
 }
</script>

That’s really all there is to it. This prints out the fairly unexciting:

User List

• John Doe
• Jane Doe

It really is pretty cool though, try it out.