Passed 386/400

I've been lurking here for the past 12 months, just wanted to say thanks to everyone who has been posting - I got my result today:

General Con: 100 100
Documentation: 70 70
OOD: 30 30
GUI: 40 26
Locking: 80 80
Data Store: 40 40
Network Server: 40 40
Total: 400 386

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!

Congratulation Robbie

What about the locking scared you?

hello friends
i have just completed my SCJP
so can i any tell what should i do or prepare to get SCJD

Thanks to all
bye

Congratulations

GREAT! I hope to be the next one.... uff... documentation is so booring...

but ok...ok... it is needed

CONGRATULATION!

Good job, nice score Robbie!

Thanks! To answer Joe - I've just read so many posts here about people getting 44/80 for locking, and no-one seemed to know the reason - I guess I got paranoid that I would fall into the same trap.

Congratulations!! well done.

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 ]

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.

Hmmm dammit... my GUI design is almost the same as yours (but mine uses textfields instead of combos for the searches)... whatever it'll stay as it is.

As regards the documentation, what does one have to do to obtain the full marks as robbie did ?

How much is approximately required in the choices.txt ?

thanks for your reply.