NX: Booking

[Linda Andersson]

Hello!
I have som problems understanding what Sun means with the dates.
If the date is 2004/02/15 and the owner field is blank.
I can then book the room to that date but not earlier than 48 hours ahead. That means from 2004/02/13.
Lets say that I book the room on that night. What happens then on the date 2004/02/16. Should I blank out the owner field and set the date field to 2004/02/16?
If I do so I will let the application check once a day if any dates is old (there are several old dates) and set them to todays date.
Do you think that my idea is correct or have I got it all wrong?
//Linda

[Philippe Maquet]

Hi Linda,
The URLyBird 48 hours issue ... one of my favourite topics !
Sorry Linda, but as I have just 5 minutes with a very slow internet connection at my parent's home, I'll just send you a few links :
https://coderanch.com/t/184127/java-developer-SCJD/certification/NX-also-hours-URLyBird
https://coderanch.com/t/184680/java-developer-SCJD/certification/Booking-hrs-Date-Canlendar
https://coderanch.com/t/184125/java-developer-SCJD/certification/NX-URLy-Bird-Hours-Rule
Warning ! In the third link, the main topic slipped to the 2/3tiers discussion , and it took me 30 seconds now before I understood myself that I was kidding (and teasing friends) in my first post there . Anyway, now that you are aware of this, you still may read it, as far as you don't forget to invert all my arguments...
Regards,
Phil.
[ January 04, 2004: Message edited by: Philippe Maquet ]

[Bharat Ruparel]

Hello Linda,
You are reading too much in-between-the-lines, I am afraid. You wrote:

Lets say that I book the room on that night. What happens then on the date 2004/02/16.

Nothing! Once the room has been booked, it stays booked.

I blank out the owner field and set the date field to 2004/02/16?

No! Is there anything in the problem statment for the project that even hints that you should do that? One key point to keep in mind is that do only what they explicitly ask you to, don't do anything which is "Nice to Have." People have lost points or even failed doing these "extra" stuff.

If I do so I will let the application check once a day if any dates is old (there are several old dates) and set them to todays date.

In a real-life scenario, and for a real-application, this would be definitely a very good thing. You don't want to do it for this assignment in my opinion. Just think about those poor graders wanting to do their job and looking to go home. You don't want them to do any more work than absolutely necessary.
This all said, it seems like you are trying to do a good job. Just focus on all the MUSTS in the problem statement. What I did is that I extracted out all those MUST statements and made a separate document. I kept referring to this document throughout my SCJD effort to keep myselft focused. These are the things that you MUST absolutely do. Don't worry about "nice to haves."
Hope this helps.
Regards.
Bharat

[Philippe Maquet]

Hi Bharat and Linda,
I have not the time to argue right now (but I'll come back later ), but well to say that I cannot agree with what Bharat wrote above (except of course that the owner field *must not* be blanked back when time spends but it's obvious I think). *MUST* things are the one for which you get automatically failed in case you don't respect them. But you have "SHOULD" things in this assignment too (or even "would be nice" things - but it's less important) which can make the difference between a "passed" and a "passed with a high score". But BTW, that's the same in the real life...
Where I could agree with you, Bharat, is that you shouldn't make *everything* you may imagine beside the "MUST" things. But what you suggest (a separate document with "MUST-ONLY" stuff, making a sort of "simplified" assignment) is not the right way IMO. The instructions are the ones we *received*, with "MUSTs", "SHOULDs" plus a few subttleties.
Best,
Phil.

[Linda Andersson]

I agree with you Bharat about that it�s stupid to fail because of "extra stuff".
If I see it the way that the given date is the only date that I can book the room (it�s possible to read the instructions that way) and when a room is booked that night it stays booked for ever. What do I then do with all the passed dates? There are rooms that were available in 2003. I can�t book them now. They will then stay unbooked and that lives me with almost no rooms to book.
How do you handle this situation?
//Linda

[Philippe Maquet]

Hi Linda,
Great ! Your 48 hours issue (including the book date issue BTW) is then solved !
These issues *are* "extra-stuff", so you just may forget about them.
I don't know if Bharat *fully* applied his "MUST-BE-ONLY" rule for himself, but if he did, you're on the right track.
Indeed, FYI, Bharat recently passed with a very decent score (367/400) : see here.
A fake issue solved in 4 posts ... isn't it nice ?
Regards,
Phil.

[Bharat Ruparel]

Hello Linda,
You are right, somebody will have to update the availability of rooms once the date of its booking is past. As you point out in your first posting for this thread, this sort of Administrative functionality is needed to support this application. However, this is out of scope for this assignment. This still leaves you with nagging doubts and a sense of unfinished business. This is where the magic word comes in; DOCUMENTAION! What you do is document this decision in your Choices.txt file. This brings another important point that I would like to share with you. I lost 10 points out of 40 for documentation. My documentation was not very good. One of the key contributors to that score is that I didn't make notes of the trade-offs, design choices, assumptions, in-scope/out-of-scope considerations etc. as I was developing my assignment. It is extremely important that you keep making notes of these decisions as you progress through your assignment.
I do believe that documenting the lack of this Adminstrative functionality is enough and should not cause you to loose any points. On the other hand, who knows what the grader thinks is the right answer to this problem. Why give him a chance to mark you down by implementing something that he might disagree with?
Regards.
Bharat
[ January 04, 2004: Message edited by: Bharat Ruparel ]

[Nicholas Cheung]

Hi all,

You are right, somebody will have to update the availability of rooms once the date of its booking is past. As you point out in your first posting for this thread, this sort of Administrative functionality is needed to support this application. However, this is out of scope for this assignment. This still leaves you with nagging doubts and a sense of unfinished business. This is where the magic word comes in; DOCUMENTAION! What you do is document this decision in your Choices.txt file.
Why give him a chance to mark you down by implementing something that he might disagree with?

I agree with Bharat. Beside his argument, I added some of my points here.
Since we are not allow (or the client system has no need to support) adding new records, in such, if you read the records carefully, you will see that, for any given day, it is almost impossible to find a record that fits in the 48-hour requirement. So, you have a high chance that, whenever you run your application:
Case 1: Restrict the display limited to 48 hours
No record can be shown
Case 2: Restrict the booking limted to 48 hours
No record can be booked
For either case, if you implement it in either way (as the instruction said the given database file will be used for testing), the above 2 cases always occurs, and if you do not have any control signal (like properties file), you cannot disable it. So, it is very inconvenient for the marker to mark.
Beside, depends on how you defines the *high score*. I have confirmed this issue with Vlad (he has passed with 360+ marks [90+%]) that he did not implement this issue, and doucment it in the choice.txt. I guess it depends on whether we handle it in either way: really implement it or just document it. Of course, there maybe many arguments on both sides for pro and against, but I have also submitted my work using the latter choice.
Hope this help.
Nick.

[Philippe Maquet]

Hi Nick,

the above 2 cases always occurs, and if you do not have any control signal (like properties file), you cannot disable it. So, it is very inconvenient for the marker to mark.

Agreed. But AFAIK, all people who made the decision to implement it use properties to define a bookable time range. Both limits of it are optional, with a "no limit" default, in such a way that the test database still can be used.

Beside, depends on how you defines the *high score*. I have confirmed this issue with Vlad (he has passed with 360+ marks [90+%]) that he did not implement this issue, and doucment it in the choice.txt.

There is no definition of what a "high score" or a "very high score" is. Only the passing score is defined : 80%

Instructions:
This document deliberately leaves some issues unspecified, and some problems unraised. Your ability to think through these issues, in the face of realistically imperfect specifications, and come to a tenable solution is something upon which you are being graded.

So it's obvious that SUN expects a little more than all "MUST-BE". It's OK to document those issues, but implementing *a few* of them cannot hurt IMO. And BTW, what means the "coming with" above ?
Now if *you* decide to *solve* a few of those issues ("solving" meaning pointing them out *and* implementing a solution), you'll have to make a *personal choice* about which to solve among all possible ones (the other ones simply being mentioned in choices.txt). That's why I think that telling here something like : "Forget that issue, I didn't take it into account and I got a high score" is not a valid argument.
Anyway, we'll be graded by human beings. With a "MUST-BE-ONLY" development, it's possible that your grader thinks "Great ! The shortest assignment I ever saw, I'll save time with that guy !" and that you get a high score thanks to that. The same grader on another mood (or another grader), could "Mmh... This guy really did the minimum in all areas" and ... (I let you guess ).
Best regards,
Phil.
[ January 05, 2004: Message edited by: Philippe Maquet ]

[Linda Andersson]

Thanks all of you for the advices.
//Linda