This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
I'm pleased with the score (especially that I managed to avoid the dreaded 44/80 on locking), no idea why I lost so many points on the GUI - I've done quite a lot of GUI design, and thought I would do ok in that section. I'm pleased to answer any questions about my submission. Thanks again to all the posters!
Can you share your gui design in words so we know what want wrong? I am also doing testing and things looks good in locking department but if you have any test program you can post code here (Andrew said it is okay to post test code in one of the thread). Have you done data validation at server side? (or client side only). It will be nice if you can share little bit of design choice e.g. some text from choice.txt.
Well done and enjoy
Thanks [ April 18, 2007: Message edited by: Ken Boyd ]
SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
Joined: Apr 29, 2005
I've been thinking about what could have let me down on the GUI front - I don't think it could have been the actual search screen: I used JTable as instructed, table columns were sortable, I used dropdown lists for the available hotels/locations (rather than textfields), validation on the booking number field (digits only), and i spent time making sure it all resized nicely, tooltips on all the fields, built-in user help screens, menu bar etc. I think the problem was either: 1) I used a configuration dialog which appeared when the user started the app, displaying the current parameters - the user could either accept the values, or enter new ones, then click OK and be taken to the main search screen - maybe they didn't like the fact that you always have to click through this dialog before getting to the search screen? 2) The server had no GUI (after the config dialog) - I just displayed a message via standard-output (ie. in the console window) saying the server was running, and to press ctrl-c or type 'stop' to stop the server. I really didn't see the point of having a GUI with a single 'stop' button on it, but maybe the examiner didn't agree!
I will try to dig out some locking test code, i did plenty of locking testing, probably the most useful was a test where i started hundreds of threads and had each one increment the value of a field in a single record in the db multiple times, at the end of the test i checked that the value of the field was what i expected (eg. 200 threads, each incrementing the value 100 times, the value should end up at 20,000 - if its less then there is a locking problem).
Validation of the data array was all server-side because I used a bean class to send data from the client to the server, but there was some client-side validation as well (eg on customer/booking number) to prevent unnecessary calls to the server.