06 Jul, 2006

Eclipse Callisto and BIRT

Posted by ben 07:23 | Permalink Permalink | Comments comments (0) | Trackback Trackbacks (0) | Java

Eclipse have just released 3.2 and Callisto which is designed to help you fetch all the plugins .


This is a really good idea but it has a couple of glitches.

  • Run the find new features to install twice, first time it misses some components that are really useful (e.g. the help for BIRT)
  • For BIRT you have to manually install prototype.js - see http://www.eclipse.org/birt/phoenix/build/ . For some odd reason this only affects the Callisto version of BIRT and not the stand alone versions. Without this installed BIRT just hangs when you try and set report parameters.
  • With all the plugins installed is often runs out of memory - edit the eclipse.ini and change -Xmx256m to -Xmx512m.

07 Jun, 2006

White/Black box testing and shades of gray

Posted by ben 10:12 | Permalink Permalink | Comments comments (0) | Trackback Trackbacks (0) | Java

A great debate arose at work about what White and Black box testing, what they were for etc.

For starters here is my simple definition of testing in general

  • Testing: Checking that the solution meets the requirements of system users.

From this we then split testing into two groups

    • Blackbox: Testing that is not aware of how it works. Just that it works. (e.g. user testing)
    • Whitebox: Testing that uses knowledge of how it works to help testing (e.g. looking in the database to see if the data really saved).

    This sounds quite a simple distinction.The debate at work was about whether unit testing can be (or should be) black box. I would argue it can and at least a good chunk of it should.

    Unit testing is about testing the public interface of an object. You are testing to see if the object meets its contract (i.e. its requirements). When you write your unit tests (obviously first!) you should ideally check it meets the contract. I would argue that this sort of test is black box testing - as the user (the calling class) is checking without any necessary knowledge of the class, it meets the requirements.

    We do tend to enter shades of grey when it comes to really testing a system as running a black box test can often make testing hard. The main problems tend to be

    • Getting suitable mock objects (or real objects) to test the interface
    • The database (what state is it in).
    • The API of the object may allow us to do everything it is meant to do. However it may not allow us to test is has done them. e.g. a void doIt() function.
    • Speed (normally related to the previous two items).

    So we then muddle our clean black box test to fix these issues. Normally this involves a combination of

    • Calling/adding protected methods
    • Stubbing database implementations

    This is where we tend to get a grey test. The tests value however can only be preseved if you keep in mind your focus is to test it meets the contract.

    Finally there are valid situations where we do want to white box unit test - however I would argue these are a minority. An example would be a complex logic to generate a random string suitable for use as a username or password. This should not be exposed via a public interface (getUserName() getPassword() would be appropiate), but to prove it is working you would need to test the implementation.

    In conclusion I think you need to be clear about what you test is testing and you tests should be categorised into

    • Black Box (with shades of grey): testing the contract of the interface
    • White Box: testing the implementation.

     (More)

14 May, 2006

Review of Issue/Bug Tracking Systems

Posted by ben 14:59 | Permalink Permalink | Comments comments (0) | Trackback Trackbacks (0) | Java

I am just starting a rolling review of a few bug tracking systems. Rather than put it directly on this Blog I decided to put it on Google pages - mainly to see what they could do.

See the main review of issue trackers is at http://bgidley.googlepages.com/issuetrackers


25 Feb, 2006

Eclipse and its plugins

Posted by ben 16:49 | Permalink Permalink | Comments comments (0) | Trackback Trackbacks (0) | Java

Eclipse is coming along extremely well as an IDE - but a lot of people are not finding the plugins that make it even better.

So as I was reinstalling Eclipse I thought I would note what is worth getting.

For a start

  • Get Eclipse 3.1.2 as a download from www.eclipse.org

Then the rest we can add via the update manager.

In Eclipse choose

Help
> Software Updates
> Find and Install...
> Search for new features to install
> Add Update Site...

In the Update Manager add the Web Tools Project update site http://download.eclipse.org/webtools/updates/ . This once installed adds both BIRT (reporting), Visual Editor and TPTP (testing and profiling) to your update site list.

Add the new Web Tools features to get

  • A nice XML editor
  • A XML Schema view a bit like XML Spy's or OxygenXml's
  • Web server start/stop plugins
  • Database editor/viewer

Then once installed and restarted go back into the update manager and search for more featues. You can now install BIRT, TPPT and Visual Editor.

The TPPT (see http://www.eclipse.org/articles/Article-TPTP-Profiling-Tool/tptpProfilingArticle.html
for an tutorial). Allows you to

  • Profile Code

BIRT is a reporting suite - I keep looking at it as an alternative to Jasper Reports. The report building GUI certainly seems better than anything Jasper Offer.

The Visual Editor is a Swing/SWT GUI builder - nice if you want a thick client application.


12 Feb, 2006

Web 2.0

Posted by ben 19:30 | Permalink Permalink | Comments comments (0) | Trackback Trackbacks (0) | Java

There appears to be a lot of hype about web 2.0 flying about at the moment. As every much of it doesn't live up to expectations but some of it does.

I have taken to using http://del.icio.us/bgidley for my bookmarks and from there have found a range other web 2.0 sites.

The key things that web 2.0 appears to be is a slick GUI (usually using AJAX). This in itself seems like a good thing.

From a technology perspective I find the web 2.0 frames works all a bit worrying. Moving to the web from thick clients programmers lives got so much simpler - they didn't have to worry in the main about GUI events and instead just put the page back.

Web 2.0 is going to result in some really awful application bugs of the sort when you can fill in A then B then C but if you go back to A and edit it you will 'break' the page. This sort of thing was a common problem in the Visual Basic GUI's of a few years ago.

Hopefully component frameworks like Tapestry can keep all the Web2.0 coolness locked away and thus reduce the screw up likelyhood.

The other thing that worries me is the security aspect - unchecked input and cross site scripting are the most common sorts of security bugs and with Web 2.0 the opportunity for mistakes is going to be increased.


03 Jan, 2005

Secure Web Applications

Posted by ben 13:55 | Permalink Permalink | Comments comments (0) | Trackback Trackbacks (0) | Java
I have been trying to spend a bit of time thinking about how to make security completly fool proof in web apps. AFAIK none of the frameworks appear to address this fully.

As I see it their are 3 main weak areas in Java webs applications
  1. CSS weaknesses (e.g. redisplaying HTML)
  2. Input Validation on initial input
  3. Selecting an item from the list and a naugthy user changing the id to something they cannot normally see
None of these are helped by CSS so it is quite tricky to solve

I have been working with Anite on Turbine-Review which solves 2. It basically ensures all fields have some validation run against them. This framework has now been tested and used in anger for quite a while and does solve most of this. However far too often I am seeing examples of no or 'AllwaysTrue' validators being used.

1 has been solved by Penguin (an add-on to Turbine review) and by other frameworks e.g. Tapestry. As the author of Penguin I must say I think Tapestry's approach (assume all output should be esacaped unless told otherwise) is better - but I cannot think of a way to make velocity do that.

3 does not seem to be solved by any framework - it may be Tapestry could help as it has quite a strong table model which could potentially automatically check a selected row was on the source table.

I have been looking around frameworks this seems to be a little discussed topic - it may be that most developers don't really think about this (which would explain the vast number of insecure websites around).


06 Dec, 2004

SOAP with C# and Axis

Posted by ben 16:53 | Permalink Permalink | Comments comments (0) | Trackback Trackbacks (1) | Java
I have been playing most the day getting C# to talk to Java over SOAP using AXIS. It is quite wierd how little information their is on this combination or the interoperability issues.

For a start you won't be able to use your basic java objects and SOAP really can't cope with Collections.

Then you have to deal with extremely wierd problems like C# won't accept an Array of strings from Axis. But appears to accept an array of almost any other object. Simple work around it to create a class with a string member variable and send an array of that!

It is just wierd that SOAP is actually quite poor at talking between different platforms!


19 Sep, 2004

BCS Award

Posted by ben 12:41 | Permalink Permalink | Comments comments (0) | Trackback Trackbacks (0) | Java
I seem to have been nominated for a BCS award for the work I did at the IPCC.
See the BCS web site for details of the awards.