Archive for May 8th, 2008

May 08 2008

Using FindBugs in Anger

Published by David under javaone2008

I attended a session by Bill Pugh (although sometimes it seemed more like a TB ward with all the coughing and sneezing going on) about using FindBugs on large code bases. FindBugs is a static analysis tool that analyses your class files without executing the program. Some people don’t think it should be needed but smart programmers still make dumb mistakes and FindBugs can catch these.

FindBugs can scale to very large code bases; Google has fixed more than 1000 issues discovered by FindBugs. Bill’s talk described ways of using FindBugs on a large project where the number of issues found can be overwhelming. For example, running FindBugs on Eclipse 3.4M2 discovered 36,000 issues. This can be made manageable by using FindBugs filters to filter out:

  • Low priority issues (leaves 26,000)
  • Vulnerability to malicious code (5,000)
  • issues also present in v3.3 (now down to 62 issues)

The reason the vulnrability to malicious code is filtered as this is mainly for code that will run untrusted code, like the JVM.

Another key point was to integrate FindBugs into your CI. Hudson has a good plugin that can display historical results and cause FindBugs issues to affect the health of a build. It can also notify who caused the issue.

Bill gave some typical warnings density of 0.3 - 0.6 medium or high priority warnings per 1000 LOC and about 1 - 4 other potentially relevant warnings per 1000 LOC. But don’t use these numbers to judge whether your project is good or bad!

To narrow what issues you should be investigating he suggested ignoring the low priority issues. High/medium issues are useful for ranking issues within a pattern but not across patterns, ie, don’t just look at high issues. Each bug has a category, for example, correctness (code seems clearly wrong), security (xss, sql injection), bad practice (violates good practice), dodgy code (something weird that might be wrong), i18n, etc.

We use Hudson at work, so it’s probably worth trying the plugin to see what it turns up.

No responses yet

May 08 2008

Comet

Published by David under javaone2008

Tonight I went to a very interesting BOF given by Alex Russell and Joe Walker about Comet. Also known as ‘Reverse Ajax’, Comet is a way of implementing ‘push’ technology in the browser. Basically, it is just long-lived or delayed-response HTTP connections; so a client will open an HTTP connection and then this is kept open to push data to the client. It is needed because now that many sites use Ajax it means page refreshes don’t happen as much as they used to so while parts of a page may be refreshed through ajax, other parts of the page may become out of date. It is used for things like asynchronous updates in GMail, chat in Meebo and collaborative editing in Google Docs.

It looks really cool and seems to finally be the push technology that was hyped in the 90’s.

You can’t use a normal web server like Apache as it would collapse under all the connections it would need to keep open so comet must be run on a server like Jetty that supports the techonology. However, it is possible to retrofit an existing app using an external cometd server. The original server serves a page but the clients open long-lived connections to this external cometd server (eg jetty) which then routes ‘events’ from the app server to the clients. Apparently it is quite easy to convert an existing app to use this external cometd approach.

JavaOne was the first I’d heard of this technology and it sounds really cool. They showed a fancy graph that suggested there weren’t problems with scaling the technology to many thousands of concurrent connections.

It seems like this could be used to deliver ads to pages that are heavily ajax-based and so don’t see many page refreshes and therefore ad views. Maybe we need a new ‘Comet’ tag type in OpenX.

By the way, ‘Comet’ doesn’t mean anything, it is just a bad pun.

No responses yet

May 08 2008

JavaOne Day 2

Published by David under javaone2008

I saw a great talk about jMaki which looks like an awesome lightweight framework to easily integrate ajax into your apps. It wraps common ajax libraries like jQuery, Dojo, etc. It uses the familiar convention over configuration to make things quick to develop and has multiple server-side language support, for example, PHP, JSP and Ruby. It also supplies an xml http proxy to interact with services outside of your domain.

A jMaki wiget is a bundle of: component.htm, component.js and css any of which can be edited if you want to easily customise the widgets.

jMaki implements all the best practices of YSlow such as minimizing http requests, combining css and scripts, defining css at the top and javascript at bottom and setting cache control headers as well as gzipping content.

It has plugins for eclipse and NetBeans but the demo of the NetBeans plugin was pretty cool; you can just drag and drop widgets from the palette into a jsp page and jMaki handles all the YSlow performance stuff. jMaki charting provides some neat charting widgets but one of the coolest demos was of jMaki webtop which is a widget that allows you to deploy a set of widgets and allow users to position the widgets, set properties, and connect them to services available to the application. In fact the NetBeans plugin makes it so easy it literally took me five minutes to create this simple test webtop app while waiting for the next session.

Functional Testing of Web Applications using Canoo WebTest and groovy was given by Dierk Konig, the founder of WebTest. He described four approaches to functional testing of webapps:

  • capture/replay
  • model based
  • data driven
  • scripted

Capture/replay creates a script from user action. This is a typical approach in commercial testing software but it is hardly usable at all for testing.

Capture/replay is the least cost-effective way of test automation

Model based testing uses expected vs unexpected behaviour. Data driven uses data variations on the same workflow. So you will have tables of input parameters and expected outputs but this is really good only if you just test against data variations.

WebTest uses a scripted approach which gives maximum power and flexibility but also maximum responsibility.

Dierk said they aim for running about 100 tests per minute so when the number of tests grows larger than about 1000 they split the tests up into suites which can be run in parallel using ant.

WebTest has lots of tests already including tests for PDFs, Excel and email but you can also write your own tests using either ant or groovy. Groovy is easier.

Dierk is also a commiter to the Grails project and WebTest comes integrated with Grails. He created a very simple Grails CRUD application and then running this in webtest was as simple as:

$ grails create-webtest Attendee
$ grails run-webtest

These commands created and ran automatically generated webtests.

He also demo’d the FireFox WebTest Recorder extension which can help start to build a test ‘interactively’ in the browser.

Clark Richey gave an interesting session on using DBUnit to test your database access layer code. Testing your DB access code can take a lot of code but it isn’t really ‘boilerplate’ as you have to test for corner cases and side effects. Using DBUnit can reduce the amount of code you need to write.

He gave some best practices for testing database code:

  • Multiple databases per developer (eg, _dev & _test)
  • Ensure the state of the database prior to testing
  • Test in small chunks of data
  • Don’t try to load everything into the db for a single test

DBUnit looks useful. You can define datasets in XML and there are lots of helpful methods for assertions. However there are some limitations:

  • Not useful for validating queries that don’t alter the state of the database but DBUnit can still be used for populating the test data
  • Dealing with foreign keys on autogenerated IDs is tricky - can’t really verify foreign key relationships

I liked the Java University session I had with Chris Richardson so I thought I would attend his talk on using EC2 for testing. He’d obviously read my previous post as he made a reference to me calling his accent “mutant”. Chris, I hope I didn’t cause offense! After introducing AWS and EC2 his talk was mainly about his open source framework called Cloud Tools which is a framework written in Groovy that’s used for deploying and testing Java apps on EC2. It was interesting, especially considering we’ve been using EC2 for testing at work for quite a while now.

He has a nice idea of using JetS3t to accelerate uploading of code. Basically, JetS3t is used to sync changes to code to an S3 bucket and then the deployed instances grab the code from the bucket which is obviously much faster than uploading it over DSL every time. He also has a maven plugin that gives you useful goals like deploy and db-save. It also has a JMeter goal for performance testing.

He finished off his talk with a few highlights of the Groovy language, managing to talk about Groovy GStrings without a hint of a smile.

No responses yet