RSS Feed Subscribe to RSS Feed

 

EasyMock

EasyMock is an open source library for creating, and defining the behavior of, mock objects as part of your unit tests. This article describes how to use EasyMock (v3.0), including its record/playback approach, after setting the context with an brief introduction to unit testing in general and the associated need for mock objects.
Read more

Tags: , ,

Hamcrest Matcher

As a follow up to the Hamcrest post I made yesterday, I wanted to post an example of my own Hamcrest matcher implementation. This matcher tests if a string contains a specified number of substrings.
An example usage could be:


    String sql = "select a,b,c from tableA";
    assertThat(sql, hasNumberOfSubstrings(",", 2));

See the source code below. I have been reading up on OSS licenses recently and decided to release this using the same license as Hamcrest – the new BSD license.

I have also attached a jar which includes the associated unit tests, although you will need the hamcrest-unit-test project to compile, which can be downloaded as part of the hamcrest all-in-one jar.
Read more

Tags: , , ,

Hamcrest

Hamcrest is a framework for writing matcher objects. Matchers have a variety of uses, but are particularly useful when writing unit tests. Instead of using JUnit’s assertEquals methods, we use Hamcrest’s assertThat construct with one (or more) of the many Matchers available. For example

    assertTrue(a.equalTo(b));

becomes

    assertThat(a, equalTo(b));

A small change in this example, but Hamcrest’s benefits are many, enabling you to write much more flexible tests that are easier to read and have more meaningful failure messages.
Read more

Tags: , ,

OSCON Day4: WebSockets

The first talk of the day I attended at Day 4 of OSCON was from Sean Sullivan (Aravo), who gave a talk on “Programming WebSockets“.

Intro

WebSockets is a technology that enables bidirectional communication between web browsers and server side processes. It provides a persistent connection between client & Server, hence enabling ‘push’ abilities where you can push data/notification to browsers from the client. Other client communication options to compare it with would be Ajax
and Comet (basically Ajax with long polling).

Read more

Tags: , , , , ,

Open Source Convention in Portland, Oregon

I will be attending the week long Open Source Convention (OSCON) next week in Portland, Oregon. Looking forward to it as there is a huge variety of talks, including databases, Android, Scala, Spring, HTML5 and a bunch of Google technologies. Get in touch with me at Shaun at Abram dot com if you happen to be going along…

Selenium talk at SF JUG

I attended another great San Francisco JUG meeting tonight, this time on How to use Selenium with Maven/Ant to automate testing of web apps.

The talk was given by Chris Bedford, from Build Lackey Labs – “Automating the Monkey Work Out and the Quality In!”. Overall, I thought this was a great talk by Chris. He clearly has a huge amount of experience creating automated tests and integrating them with build tools and he gave a well structured, interesting, well delivered presentation. I have posted a copy of Chris’s slides and I think the video will be posted on the SF JUG site at some point, but I have also posted my notes from the presentation below…
Read more

Tags: , , , , ,

Data binding in Spring MVC

Two of the most important tasks carried out by Spring MVC when you submit a form are Data binding and validation.
The following article discusses data binding, including the use of custom PropertyEditors, and some of the options available for registering such editors. Most of the information discussed applies to Spring in general, but its application in Spring MVC is my primary interest.

In a future article I would like to discuss validation including the use of custom error messages.

Note that these notes relate to version 2.5.6 of Spring, the latest production code at time of writing, and depend heavily on the corresponding Spring reference docs.

Read more

Tags: ,

GTUG Campout Demos

Last night saw the end of the Google Technology Campout weekend, with about 25 or 30 groups giving demos of a lot of cool Wave apps. I particularly liked the robot/gadget that analyzed when it was time for a group of wave participants to leave the wave and meet in real life, supplying a list of possible venues to meet based on the participants’ physical location. A vocabulary analyzer from a group of brothers also looked pretty good. I also liked the h3lp application, kind of like an Onstar four your mobile phone, which pushed out alerts to selected contacts in case of an emergency. In the end, the winner was the video sharing team.

The demo for our BlipWiki project (which I blogged about here) unfortunately had technical difficulties so our presentation didn’t go so well. One of our 2 browsers couldn’t seem to connect so we didn’t get to show our Wiki updating in real time in the way we would have liked. Still, I think we had a great application at the end of the weekend, and I certainly learned a lot, met a lot of great people, and got to know Google Wave much better. A great weekend…

There are photos and videos from the weekend posted here and a write up in the San Jose Mercury News.

Tags: , , ,

GTUG Campout Follow up

I’m currently at the Google Technology User Group Camp out weekend down at Google’s offices in Mountain View. The objective of the weekend is to form a team and develop an application, using Google technologies. The demos are Sunday afternoon.

I joined the Blip Wiki team. A Blip is simply a single message within a ‘Wave’ conversation. A Wiki, of course, is a software tool that allows users to easily create, link and collaborate on documents. So, our goal with the ‘Blip Wiki’ project was to bring the incredible collaboration capabilities of Google Wave (real time updates, autocorrect context sensitive spelling etc) to the easy document setup and linkability of a Wiki.
Although Wave can certainly be used to collaboratively create documents as it is, Wave is inherently conversation focused. We wanted Blip Wiki to be inherently Document focused.

To do this however, we needed to use our own instance of a Wave server i.e. use the Google Wave Federation Prototype Server rather than the regular Wave server hosted by Google. We also needed to come up with a new client (something like tiddlywiki) and, most importantly, ensure our client can communicate with the server. Our project won the award for the most ambitious pitch at the start of the weekend!

Federation Prototype Server and example client

We got off to a good start by getting the Wave Prototype Server downloaded, building and running (it runs on top of OpenFire, a real time collaboration server that uses XMPP/Jabber). We then got the demo wave client running and talking to our server. We managed this by late Friday evening.

Client/Server protocol

Next, we created our own demo client and tried to get it interacting with our Wave server. That is when we started running into problems. First, the client/server protocol has not yet been formalized, and there don’t seem to be any definite plans to do that yet either. For example, although this Client Server Protocol White paper describes a protocol and data model, it does not give any details on the format that should be used, or suggestions on how to use it. There is a lengthy discussion in the Wave Protocol Google Group about this. For example, someone suggests that the client server protocol is just protocol buffers ‘over the wire’. But a protobuf is really just a simple data format, and while I assume ‘over the wire’ means RPC, it is all a bit vague.

Submitting changes

The client/server protocol used in the example client (a “toy’ text client) is for “illustrative purposes only”, according to this doc. We couldn’t seem to find much documentation for it, perhaps because it is not supposed to serve as a standardized example. As a result, we found it difficult to reverse engineer. So, we ended up resorting to using the Client example code to marshal our data to and from the server. The example client code in effect became a sort of interface to the server for us. A client side stub, if you will. (We had this running in the web tier servlet layer).

Receiving updates

So, after we had used the Client example code to submit changes (blip updates) to the server, our next hurdle was understanding the data that gets returned. Ideally, we would like a ‘delta’ of the data. That is, after the server has done it Operational Transformation magic, we would just like the latest and greatest version of the data to display on the client. However, this proved difficult to get from the server. Instead all I could seem to get was a non-delimited complete history of the blip. I admit that this was done using pretty hacky code. I am sure there must be another, better way!

So, we ended up taking a similar approach to the example client, and just displaying the latest submissions.

Demo ready – almost…

Right now, we have a working client and server with updates made on one user’s WikiBlip automatically showing up in another users.

It would have been really nice to be able to deploy our local Wave Server to app engine, but apparently this isn’t possible since the OpenFire jars required aren’t on the whitelist of allowed jars.
It also would have been nice to experiment with our local Wave server talking to the real Google Wave server (e.g. to have a regular wave client user be able to interact with a blip wiki), but apparently this is not possible due to authentication issues.

So, we chose a very difficult task for the weekend! But, we have a working version ready to demo and it has been a great weekend all in all.

Thank you’s

A big thank you to

  • Sriram and Sreejith, my BlipWiki teammates
  • Kevin and Van from the GTUG
  • Stephanie, Brian, Fred and all the all Googlers who made the weekend possible and great!

I will post again later with the results of the demo…

Tags: , , ,

Google Technology User Group Campout

I have signed up for the Google Technology User Group (GTUG) Campout. It is a weekend (August 7-9, 2009) of designing and coding an application, as part of a team, using Google technologies. As far as I know, Google ‘technologies’ can include things like GWT, Android, OpenSocial etc, but there will be a particular emphasis on Google Wave (due to members of the Wave team being out and about to help), and hence Google App Engine.

I am not too familiar with Wave yet, so this should be a great opportunity to get to know it better, meet a bunch of fellow techs, and hopefully produce something cool by the end of the weekend. Looking forward to it…

Registration is free, so if you are interested you can sign up at here.

Tags: , , , , ,