NX: Interchanging Database files

[Paul Tongyoo]

Hi Jolly Ranchers,
I'm coding my database file parser to be able to parse different database files given that their header/schema/data section formats match the one originally given. Since this functionality wasn't specified in the docs, would this be considered bad form for grading purposes?
I figured my parser wouldn't be very reusable if it only parsed files with schema sections defining 6 fields, each with a given field name width (in the specs). Right now my parser will take a db file with any number of fields, with a field name no longer than 32 bytes.
So, if i was asked why I did this on the essay, i'd say I wanted my parser to be able to load any db file, given it adherred to the given header/schema/data section layout so that the parser would be more reusable and I'd get some brownie points in the design section (I hope? ) . BUT it does add complexity that I'm wondering may hurt my score more than help it.
Any thoughts?
Thanks! -- Paul
(My parse algorithm isn't that complicated though. it just looks messy because i haven't commented yet )

[Mark Spritzler]

"I'd get some brownie points in the design section"
Sorry, you won't get any brownie points.
Yes I agree writing a parser that can only handle that one table is not quite how you would do it in the real world. Well, unless you were righting a down and dirty for a one time use only, then yes you might write your parser to handle just that one table. Because the trade off of how much longer it would take to write it to handle all tables is not worth that trouble.
So the only question that remains is what does the requirements say. Is it asking for that flexibility as a necessity, has to be there requirement. No, it is not, and therefore no brownie points for you, just a chance for possible losing points.
Kind of a fun game they play there, huh?
Mark

[Andrew Monkhouse]

Hi Paul,
I agree with Mark - there is no way you can get extra marks for doing something really nice. There is even a comment in the instructions:

You will not receive extra credit points for work beyond the requirements of the specification.

If there was an item under "General Considerations" for reusability of code, then you would have to look at this. However even that seems unlikely given the instruction:

The IT director does not anticipate much reuse of the first Java technology system

Having said all that though, the generic database is a very nice idea, and many people here are doing it.
Since you have already written your parser, I suggest you look at it to decide whether it fits in well, would make sense to a junior programmer, and is something you dont want to throw away.
Regards, Andrew
[ October 13, 2003: Message edited by: Andrew Monkhouse ]

[Paul Tongyoo]

argh: argh: argh: argh: argh: argh: argh: argh:
Thanks for the help guys! (No sarcasm intended -- I really mean it :-D)

[Paul Tongyoo]

"The IT director does not anticipate much reuse of the first Java technology system..." I love the inclusion of the word "much" to screw with our heads.
I like my flexible parser code; I think i'll print it out and frame it on my wall or something. As for the app, should I assume that the db file given will be used throughout the lifecycle of this app? IE can i assume that the schema of the db will remain constant (field names and byte lengths)?
Paul

[Philippe Maquet]

Hi Paul,
I disagree with Mark and (a bit) with Andrew, and ... I agree with your last post.

can i assume that the schema of the db will remain constant (field names and byte lengths)?

No, you cannot. And maintability of your design is something the grader should take into account IMO :

Instructions:
Clarity and Maintainability
A clear design, such as will be readily understood by junior programmers, will be preferred to a complex one, even if the complex one is a little more efficient. Code complexity, including nesting depth, argument passing, and the number of classes and interfaces, should be reasonable.

Unfortunately, they don't define what maintability is, but I do think that :

any database which would not handle its metadata information at a "meta level" would not be maintable

it would be hard to be understood by a junior programmer that you don't use the meta information SUN gives in the instructions (the header structure).

What I mean with point 2, is that if you don't make the effort to interpret the header in some absract and reusable way, the whole header becomes useless. And I don't think it was SUN's intent.
If I agree a bit with Andrew, that's because he wrote :

Having said all that though, the generic database is a very nice idea, and many people here are doing it.

I even think that all people here do it (maybe except Mark who is the kind of extreme-programmer who loves extreme simplicity ).
Paul, I agree with you that "not much reuse" doesn't mean much and especially when you read it in its context. Here is the whole sentence :

The IT director does not anticipate much reuse of the first Java technology system, but intends to use that system as a learning exercise before going on to a web based system.

I interpret that sentence as "He doesn't anticipate much reuse because it's a learning exercise.". And it's a fact that the more you'll try to make reusable pieces of code, the more you'll face technical challenges and the best will be your learning exercise. Code reusability is a quality per se, and I don't think you should be penalized because of it.
Just an example : I decided to use sockets instead of RMI. A socket implementation may be rather simple (and Andrew convinced me that it could even be simpler than a RMI one), but I designed a network framework based on sockets with reusability in mind : without any change (and without any sleep() between connections as in the SUN's RMI implementation, Andrew ), it supports from hundreds to thousands concurrent connections on all known platforms (to achieve this, the way threads are allocated and reused must be parametrable through properties), and it supports callbacks and message broadcasting. Used in the assignment, the two latter features make the application "easier to use" and "ease of use" should weight 40 points in the new assignements.
(Just an example of ease of use brought by callbacks : when an administrator changes the listen port (or the IP address) on the server, all connected clients are aware of that change, in such a way that they'll present the right connection parameters to the user the next time they'll connect).
Mark, here is an excerpt taken of one of my three books on SCWCD :

What I hear, I forget. What I see, I remember. What I do, I understand.
Confucius.

I love it.
So you'll understand that I tried to maximize my learning process, because I had all to learn in Java when I started. Now given my current experience, if I had to start again, I'd probably choose the simplest way of getting certified as you suggest. Because I would do it so faster than I did, but also because I think (it's just a guess) that to get the highest possible score, an extreme position in that area (simplicity vs usefull functionalities) may help. In other words, do it amazingly simple or amazingly functional, but do it in an amazing way. Anyway, we'll see soon, because I should be ready to upload within the next three weeks.
Be sure I'll make a good guinea-pig for complex designs !
Best,
Phil.
[ October 14, 2003: Message edited by: Philippe Maquet ]

[Mark Spritzler]

"I disagree with Mark "
Phillipe always disagrees with me, no matter what I say. I say it's sunny outisde, he says it's raining.
Actually sometimes doing just what is required is a huge learning process for some people. They always overdo their tasks, and end up paying for it in the long run.
Mark

[Philippe Maquet]

Hey Mark,

Phillipe always disagrees with me, no matter what I say. I say it's sunny outisde, he says it's raining.

Sorry Mark, but I disagree. I would say that each time you say it's raining outside, I say it's sunny.

Actually sometimes doing just what is required is a huge learning process for some people. They always overdo their tasks, and end up paying for it in the long run.

Agreed !
I am just a little confused by your "Phillipe always disagrees with me". We have often quite opposite positions in threads, but I personally love that. And sometimes it happens that I am teasing you a bit, but there is a french idiom which says (I don't know the english equivalent) : "We only tease people we like".
As it's not a secret because I wrote it myself, here is what I wrote to Andrew in a PM when Max left us :

But people on all forums come in and leave, and then sometimes come back (Mark). BTW, I do think that Andrew + Mark form a quite balanced team. If it's impossible to dig into some technical discussion with Mark as we can do with you, OTOH his influence in favour of simplicity is beneficial for people like me.

Take it as you feel it, but in my mind it's a compliment.
Now, regarding this thread, I'd like to emphasize how much your posts as a bartender (same for Andrew and worst for Max as an author) may have an influence on readers design choices. If it's not my intent to put any responsability-weight on your shoulders, it's a fact that anything you may write on this forum will get a "special weight" because of your bartender status, at least for newbies. Given that, and the fact that after 4.5 months experience here on the forum, I know - as you do - that 99.9% of the candidates choose to interpret the db header, I found a bit unfair that you adviced Paul to hardcode the meta-access.
In other words, Ok, 100 x OK for your influence in favour of simplicity, but not in this case.
Best,
Phil.

[Mark Spritzler]

"Paul to hardcode the meta-access"
Actually, I told Paul that to create his db.db file he can right a one-off, and not have to make it generic.
When you are talking about accessing the db.db file for use in the application, I agree with you 100%, it is sunny, and it has to be able to access any data structure that could be in the db.db file. Maybe I mis-interpretted his question.

[Philippe Maquet]

Hi Mark,

When you are talking about accessing the db.db file for use in the application, I agree with you 100%, it is sunny, and it has to be able to access any data structure that could be in the db.db file. Maybe I mis-interpretted his question.

Great ! We should note this day as a special one : it's the first time in 4.5 months that we agree - together at the same time - that's sunny outside !

Maybe I mis-interpretted his question.

Mmh. You just lead me to read the question again, because maybe I mis-interpretted it myself :

i'd say I wanted my parser to be able to load any db file, given it adherred to the given header/schema/data section layout so that the parser would be more reusable

I understood that Paul's dilemma was :

Or I interpret the db header and I access fields in an abstract way based on the information I got from the header (field names and lengths directly and field offsets indirectly), making that "parsing" job (I don't like the "parse" word in this context BTW) reusable for other possible db accesses ;

Or I hardcode field accesses based on the information I can read (as a human) from the instructions, making that job not reusable.

Anyway Mark, we'll agree on this other sunny fact : for his sixth ten-lines-question post, Paul got hundreds lines of answers from us, including the two bartenders. And all that for free. Shame on him !
Best,
Phil.
[ October 14, 2003: Message edited by: Philippe Maquet ]