This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I think that anyone attempting this certification knows the difference between "1" and (byte)1 .
EDIT: Though, if you initially actually did this, I could be wrong about that. It just seemed kind of obvious to me .
If you inspect the db file with a HEX editor (which everyone should do before writing any code) you see a value of 0x00 for non-deleted records. You then immediately know that a byte value of 0 or 1 should be used.
Roel De Nijs wrote:Maybe even better would be to store this 1 in a constant, e.g. private static final byte FLAG_RECORD_IS_DELETED = 1;
Roel De Nijs wrote:I just wrote a database file reader based on the given database file structure
Well, of course , you can do that, but my point was that I think that everyone should see and understand all of the contents (and thus the format) of the database before starting to write to it. A hex editor just let's you do that without writing any code. Actually seeing the data sit there, versus only reading about what *should* be there, makes a lot of difference and I'm pretty sure you'll agree with me on this .
As another example, by using a hex editor I immediately noticed that the fields of the records where not encoded the way I had expected by reading the specification alone (this could be version specific, but in my database all fields are padded with spaces, while the spec implied they would be null terminated). So, before writing any code, I already knew the particulars about the file and was able to handle them right from the start.
Marcel van den Boer wrote:Actually seeing the data sit there, versus only reading about what *should* be there, makes a lot of difference and I'm pretty sure you'll agree with me on this .
That's true and being around here for a few years there are a lot of people having trouble with the database schema described in the instructions, so a hex editor and Roberto's database file reader come to the rescue
It wasn't like I didn't know what is in the database or that I didn't know the difference between "1".getBytes() and (byte) 1 (how did I pass SCJP in the first place?). In fact, I've used the DBFileReader tool provided on this forum and I've seen the content of the database before writing any code but I guess it was my tired head doing some really nasty stuffs there so I decided to put it here so that little things like this don't slip into other people's code due to negligence or (trying to find shortcuts, laziness). Maybe its not worth putting here anyway...
Thats why we are all advised to make back-up copies of the database before testing. I have it spread all over my PC, my external hard disk and a couple of other places too.
My database package has survived my little testing with one client. Now I will be testing with multiple clients today after which I will move to the server implementation. Where are you now on your project?
I want to ask you guys on this forum, how many lines was your Data class when you took your exam?
Oladeji Oluwasayo wrote:Thats why we are all advised to make back-up copies of the database before testing.
Oladeji Oluwasayo wrote:how many lines was your Data class when you took your exam?
I haven't taken the essay exam yet, but my Data.java is currently about 400 lines (including comments, spacing, etc). But, this does not include the code that reads and writes the database file from/to disk. My Data class simply implements DB.java, and if it is instantiated with the zero-argument constructor it has an empty record cache.
Oladeji Oluwasayo wrote:Where are you now on your project?
Basic functionality of each layer (storage, networking and presentation) is pretty much done. If I wanted to, I could glue it all together and complete the project in a few days. BUT, I'm currently more interested in playing with alternate solutions (like developing a different locking model) to gain a better understanding of the different technologies.
Only the locking codes are not present in my Data class and it has grown to 800+ lines of codes (plus comments, spaces and lots of logging code).
Well, unlike you, I'm using a system of <complete-a-component-and-test-it-before-starting-another>. You know, I don't have much time because I'm still a student and school work is really taking the little that I have (doing serious work with three other programming languages -- low-level).
Oladeji Oluwasayo wrote:Only the locking codes are not present in my Data class and it has grown to 800+ lines of codes (plus comments, spaces and lots of logging code).
Just as a reference: I needed 760 lines of code for my Data class. The Data class contains nothing more than code, comments, limited logging (start + end of each method) and the code is formatted according to the Sun (Oracle) coding conventions.
Oladeji Oluwasayo wrote:I'm using a system of <complete-a-component-and-test-it-before-starting-another>.
That's the system I used too and the one I advise to everyone who starts this assignment. And when you have limited time to spend to the assignment you'll certainly benefit from this approach.
The Data class contains nothing more than code, comments, limited logging (start + end of each method) and the code is formatted according to the Sun (Oracle) coding conventions.
Yeah I'm following Sun's coding conventions too (only that I added double blank lines between some methods, and then blank lines before and after if and for blocks within methods, just for my personal clarity) then I log some really nasty stuffs if they arise. And by the way, 800 is not so far away from 760. Thanks for you help on this forum Roel