Tuesday, 21 January 2014

REST web app Tutorial - Java Jersey - Part 1

I am going to build a simple REST/AngularJS web application which allows someone to keep track of a list of people.  It'll have the ability to get an individual, add a person and remove a person. I may expand this in the future, but for now those are my lofty goals.

This post will demonstrate how to step up the project and write a first test.

Start by building the project, from the command line run this:
mvn archetype:generate -DarchetypeArtifactId=maven-archetype-webapp -DgroupId=com.creativesci.tutorial -DartifactId=jersey -Dversion=1.0-SNAPSHOT -Dpackage=com.creativesci.tutorial.jersey -DinteractiveMode=false

Update the pom.xml dependecies section to look like this:




Now create a new file in src/test/java/com/creativesci/tutorial/jersey called PersonServiceTest.java.  This class will extend JerseyTest and we have to add a constructor.

    protected ResourceConfig configure() {
        return new ResourceConfig(PersonService.class);

Now we can add our first test method. Since we are doing baby steps we want a test which will generate the fewest number of lines of production code. I think that the get all will be the easiest to implement first, at least it will allow us to test other actions later.  I might be wrong, but I'm willing to be.

    public void testGetAllPeopleReturnsEmptyList() {
        List<Person> allPeople = target().path("person").request(MediaType.APPLICATION_JSON).get(new GenericType<List<Person>>() {});

So there is the first test, of course this currently fails to execute, but that's TDD.  Next post we'll run through creating the PersonService and Person classes so that this test can pass.

Sunday, 17 June 2012

Values-driven retrospective

The difference between personality and character is subtle, but important to note in being agile versus doing agile software development.  There are generally five key characteristics that team members can be when being agile:
  • courageous
  • honest
  • open
  • respectful
  • trustworthy
A good way to reflect on your own or a team's value characteristics occasionally is to do a values-driven retrospective.  Most of the failures associated with being agile are related to a people or cultural problem.  That may sound like a bold statement but it isn't, since you can't blame a framework for a project's failure.

Personality is easy to read and easy to fake.  Character is deeper, it is a set of rules the person follows to make decisions constantly. Observing someone's actions over a long period of time will help you determine their characteristics. Someone could act on one of the above values for a time with their personality, but if they don't adopt these characteristics as rules on how to act at work then using this retrospective our can point out how they are not being agile and help them correct it.

Saturday, 9 June 2012

Focused Code Review Timeboxed

A while ago, at the company I was working for, we wanted to start doing code reviews.  They only problem was that there was a strongly opinionated developer who would prefer to spend the reviews arguing about curly braces, brackets and spacing.  This developer would also start rewriting the code during the reviews. Obviously this discouraged the idea of further code reviews.  Until I stumbled upon this blog post: http://weromans.com/2009/focused-code-review/

I had actually just finished reading the Refactoring book by Martin Fowler, so it was well timed.  I like to use the code smells from the book and the list of software anti-patterns from wikipedia to compliment it.  Also this style of meeting does not require anyone to study the code beforehand nor does it consume loads of paper, as traditional code reviews tend to do.  There is also minimal prep work for the organizer, book a room with a projector and run a metric on the source code of the project.  The code that does the worst for the metric is the one that you will be reviewing.  The code should however be available for review before the meeting if you are inviting others not familiar with it.  e.g. if it was solo developed.

I ran the meeting as the facilitator with timeboxes like this:

  • 5 minutes -  someone familiar with the code can talk about it
  • 20 - 30 minutes - identify smells and anti-patterns
  • 5 minutes - choose which new tasks to include in the next iteration
  • 5 - 10 minutes - improve our corporate coding standards to be proactive
  • 5 minutes - retrospective on the review and pick a different metric
That's it.  You are done in about an hour.

Doing this review style solo is a great way to learn since you'll be able to pull out objects and see design patterns form.  This is a great technique for evolutionary design as well.

Thursday, 7 June 2012


This blog has no real purpose except to share my thoughts on software development.  In addition to sharing my opinion I would like to do code reviews, post challenges for myself (and possibly any readers), tutorials and some sample code.  I will try to keep my posts short for easier digestion, but may rant on occasion.