• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

NX: URLy Bird 1.3.1 48 Hours Rule

 
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello All,
I am trying to implement the 48 hours rule. Towards that, I have written a test program that is not doing what I want it to do. May be somebody can spot the problem? Here is the code:

No matter which value I add to Calendar.DATE, 2, 10, ... You name it. It always
comes out false. That is it always prints:
Today is not two days before 2003/09/13
Any ideas/insights are welcome.
Thanks.
Bharat
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello All,
Forget it! Figured it out. Here is the code:

I forgot that the month is a zero based element, therefore, you have to subtract 1 from the month read to compare it to the current date as shown above. Sometimes I don't think enough (not my forte anyway!).
I have a question though. The requirements say that:


They take bookings only within 48 hours of the start of room occupancy.


As you see above, I have added 3 = 72 hours instead of 2 = 48 hours to make sure that in a case such as above where "dateToCompare" is set for two days from today, the result comes out true instead of false. Is it OK?
Regards.
Bharat
[Andrew: Fixed code block (you left out a slash on the closing block]
[ September 11, 2003: Message edited by: Andrew Monkhouse ]
 
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Bharad,
I think it's ok. I don't understand why do you use Tokenizer. There class java.text.SimpleDateFormat. I beleive it is a bit more elegant.

Best,
Vlad
P.S. I personally decided to ignore the issue, but document it.
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Vlad,
That was the only way I know. I will look into java.text.SimpleDateFormat class. Thanks for the tip.
Regards.
Bharat
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Following up on my own thread pertaining to the 48 Hour rule. Where do you think the 48 hour rule should be applied? The client side or the server side? In other words, where do we validate the date available field against today's date? Currently I am comparing it to the date on the client. Should it be compared against the date on the server?
These last minute things!!!
Regards.
Bharat
 
Ranch Hand
Posts: 168
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bharat
Whether you perform this check on the client or the server depends on where your 'business logic' resides, as far as I can see. This is a business rule.
I can't remember whether you were a thin-client or fat-client man, but I would put it wherever the rest of your business layer is.
M
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Michael,
Not too long ago, I used to be a thin-client man. I recently converted to the fat-client religion. I have been purposely avoiding the "other" thread. I am afraid, Phil will start calling me names.
Does it mean that my code is fine? Since the business rule check is at the client end. Actually, I am not sure if I stated my question clearly enough - I am asking is it OK to just get the system date on the client so that it can be compared to whatever date the "date available" field for the record to be booked has? The reason I ask this question is that on a number of client/server systems that I have been involved in, we used to get the system date from the server since a user could easily change it on the client to "fool" the system. Then again, how far do we want to take this thing is the real issue. I don't think in real-life anybody will be developing a one random access file database system.
May be these are last minute jitters.
Thanks for your response.
Regards.
Bharat
[ October 16, 2003: Message edited by: Bharat Ruparel ]
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Bharat,

I am afraid, Phil will start calling me names.


Perhaps. But you will get Jim, Vlad, and myself all congratulating you on making the intelligent choice

I am asking is it OK to just get the system date on the client so that it can be compared to whatever date the "date available" field for the record to be booked has?


Remember to keep your solution simple. Personally I think that the current solution is designed to be used in house, so presumably the people who will be using the client software you write will be in the same timezone and will not be playing with system dates.
In a real three tier solution (web client - web server - back end server) then the middle tier could and should manage dates. But for a web based solution you might also start looking at whether you have dates in UTC format for the convience of people in other time zones.
My choice would be to just use the date on the client machine, and document that there is potential for problems, but that these problems can only be partially fixed in a two tier solution.
Regards, Andrew
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As always.
Thanks Andrew.
Bharat
 
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Bharat and Andrew,

Bharat:
I recently converted to the fat-client religion. I have been purposely avoiding the "other" thread. I am afraid, Phil will start calling me names.


Oh nooo ! I'd never do that.

Andrew:
Perhaps. But you will get Jim, Vlad, and myself all congratulating you on making the intelligent choice


As Andrew just recalled, it's a choice (at least for the new instructions). And as all of our choices must be documented, the more I read this 48-hours thread, the more I find arguments in favour of the 2-tiers design in this context, and the more I am tempted myself to join the 2-tiers camp (sorry for those guys that I mislead).

Andrew:
My choice would be to just use the date on the client machine, and document that there is potential for problems, but that these problems can only be partially fixed in a two tier solution.


The fact that you use the date on the client machine brings a very little potential problem in comparison with the big advantages of the solution :
  • In case the business rule must change on some day the system administrator is sick, CSRs may solve the issue by themselves simply by playing with their own system date.
  • Now if you made the additional right choice to store the 48-hours rule property client-side (notice that storing and managing are two different things), you get for free the two next additional benefits :
  • In case the business rule must change on some day the system administrator is not sick, changing the rule on the 20 CSR's machines will help the system administrator keep fit.
  • In case three out of the 20 CSR's get some promotion allowing them to book rooms available in the next 72 hours (the 17 other CSRs keeping the 48hours one), you'll be able to handle the new rule without changing any code neither server-side nor client-side.
  • Now even if the business rule is stored server-side but managed client-side, you get still the two next benefits :
  • When they'll move to the web next year (as we may expect from our instructions), you'll have to rewrite your business rule in a servlet, dealing once more with the low-level db API, ... making sure that you'll keep your job at least till next year.
  • If your database stores tens of thousands historical-legacy booked rooms, the fact that you filter out the few bookable records client-side will undoubtedly help the network cables to keep their optimal work temperature : we are entering in the winter and our north-canadian and russian friends should appreciate that nice side effect.


  • Why did I ever think of a 3-tiers design one day ?!
    Best,
    Phil.
    [ October 17, 2003: Message edited by: Philippe Maquet ]
     
    Bharat Ruparel
    Ranch Hand
    Posts: 493
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hello Phil,
    Glad to know that you are not offended.
    You wrote:


    As Andrew just recalled, it's a choice (at least for the new instructions). And as all of our choices must be documented, the more I read this 48-hours thread, the more I find arguments in favour of the 2-tiers design in this context, and the more I am tempted myself to join the 2-tiers camp (sorry for those guys that I mislead).


    You should. There is enough evidence on this forum and the "Sun Certification Results" forum that a two-tier design even for the "new" URLy Bird and Contractor assignments have earned people perfect or close to perfect scores. I don't specifically recall the threads, but they are there.
    Now, having a J2EE background, the three-tier solution naturally appeals to me. But then, this is just an assignment and let us go with the flow and do whatever makes the "graders" happier. That is all there is to it.
    Regards.
    Bharat
     
    Andrew Monkhouse
    author and jackaroo
    Posts: 12200
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Phil,
    ROFL
    As you noted (but did not capitalize on ) I did comment that the 48 hour issue has potential for problems, but that these problems can only be partially fixed in a two tier solution. It is probably the only thing that would make me want to look at thin client solution.
    But I do have to comment on some of your "advantages" :roll:

    Phil

  • In case three out of the 20 CSR's get some promotion allowing them to book rooms available in the next 72 hours (the 17 other CSRs keeping the 48hours one), you'll be able to handle the new rule without changing any code neither server-side nor client-side.
  • When they'll move to the web next year (as we may expect from our instructions), you'll have to rewrite your business rule in a servlet, dealing once more with the low-level db API, ... making sure that you'll keep your job at least till next year.
  • If your database stores tens of thousands historical-legacy booked rooms, the fact that you filter out the few bookable records client-side will undoubtedly help the network cables to keep their optimal work temperature : we are entering in the winter and our north-canadian and russian friends should appreciate that nice side effect



  • In case three out of the 20 CSR's get some promotion allowing them to book rooms available in the next 72 hours (the 17 other CSRs keeping the 48hours one), those of us with fat clients will be able to roll out new client software to just those three CSRs. The others will be unaffected, and there will be no outage on the server.
    Those of you with thin clients will have to rewrite part of the server, rewrite part of the client software, do complete regression testing, have an outage on the server, and teach people how they get access to the new functionality.
    Then if it is later decided that those CSRs who got the promotion are also allowed to "unbook" records, you will have to rewrite part of the server, rewrite part of the client software, do complete regression testing, have an outage on the server, and teach people how they get access to the new functionality. And so on, and so on ....
  • When we move to the web, your solution will also have to be rewritten to become a proper three tier solution. I don't really think it will be any harder to modify the fat clients into a proper 3 tier solution - in fact it is possibly easier since all the business logic is in the fat client already, and that means it can go into the Servlet / EJB where it belongs.
    Your solution will have limited business logic on the web server and most of the business logic on the database server
  • But you have to keep using the network, otherwise the electrons get lazy - later you will find that the electrons are too unfit to travel at full network speed


  • Best regards, Andrew
    [ October 17, 2003: Message edited by: Andrew Monkhouse ]
     
    Whip out those weird instruments of science and probe away! I think it's a tiny ad:
    Smokeless wood heat with a rocket mass heater
    https://woodheat.net
    reply
      Bookmark Topic Watch Topic
    • New Topic