It's not a secret anymore!
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S: auto-failure worries... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S: auto-failure worries..." Watch "B&S: auto-failure worries..." New topic

B&S: auto-failure worries...

Ewan Livingstone

Joined: Jun 16, 2008
Posts: 14
Hello all,

Not posted here before, but I'm currently doing the last 10% of my Bodgitt & Scarper assignment implementation. Got a few niggling worries around automatic failure, and I wondered whether anyone (ideally someone who has submitted an assignment and got the result) has got any pointers on these...

1. In my database file, contrary to what the spec says, none of the field values are null-terminated. They're all padded with spaces. That is, where a field is 10 characters wide, a 3 character value such as will be represented as ('foo', followed by 7 space characters). According to the spec, it should be 'foo\0\0\0\0\0\0\0\0\0\0' (or 'foo\0' followed by 6 arbitary characters), as \0 is the ASCII NUL character.

I've developed by database file parsing code to the letter of the spec, and as a result, in the above case, my database layer will return (i.e. with the 7 spaces). In turn, as the spec requires that if the user restricts their search by name or location, the match must be exact. So if my assessor types in 'foo' as the name, it won't match .

I'm considering having a popup if zero results are found specifying that 'foo' does not match 'foo ' to try to address this, but I'm still somewhat affeared...

2. Sounds trivial, but the spec states that all classes should be javadoc'd - does this include (i.e. the database interface provided in the assignment spec)? I'm worried that if my isn't a copy-paste from my assignment, I might get auto-failed. On the other hand, I can also imagine their auto-fail script failing me if I don't have it javadoc'd.

Finally, not something I'd imagine I'd be autofailed over, but something potentially 'controversial' I've done - just wondering if I'm the first to do this...

DBMain, the database interface provided with the assignment, is just horrible for all sorts of reasons. It also doesn't tally well with the spec, as it offers field matching on a 'starts with' basis, where the spec requires field matching on an 'equals' basis. Because of this, I've opted to make my Data class implement two interfaces: DBMain, and my own database access interface, Table. While all DBMain methods work and have been tested, the application itself interfaces with the class using the Table interface and its methods. Under the bonnet, most of the logic implementing the DBMain and Table methods is the same, so there's little duplication as a result. Thoughts?
Richard Roehl

Joined: Apr 29, 2008
Posts: 11

Stop stressing!

1) The padding issue has been discussed before. You can either do as the spec says or argue that you followed what was given to you. Either way document it. They can't secretly pick the way they want it and then fail you if you choose the opposite.

2) Javadoc'ing the interface is probably a good idea. I don't see them performing a diff on the file they gave you and then blindly failing you if it doesn't match character for character. If anything I would imagine they have a pre-written test case that calls your COMPILED implementation and if that throws an error then it would be an auto-fail situation.

3) Your additional interface doesn't sound controversial to me. I personally chose to extend the interface but I did also contemplate writing a second one too. Just document your reasoning in the choices.txt file you are going to provide.

I agree. Here's the link:
subject: B&S: auto-failure worries...
It's not a secret anymore!