• Racer X (unregistered)

    Isn't Cache King in a down Economy?

  • (cs) in reply to Someone You Know
    Jake Vinson:
    According to Wikipedia, caching is a method of storing a collection of data for which the time it takes to compute said data is longer than the time it takes to retrieve from the cache.
    I have been caching all my life and didn't even know it. As far as my brain (specifically, my memory), I have been practicing Cache and Carry!
  • frustrated sysadmin (unregistered)

    You've got to to wonder sometimes how these people end up with a job coding.

    I'd love to say our place is better, but based on this - it's much worse.

    So I take up this job as sysadmin and sure enough on 1st Jan 2007 complaints start rolling in saying "we can't view our stats for today", sure enough there is no '2007' in the date drop down.

    Report it to dev and they produce a release to fix it... problem sorted (or so I thought)

    1st Jan 2008 comes, and low and behold the same complaints keep rolling in - I check the bug report I filed and yes it says that the date drop downs are now dynamic. Restart the application and sure enough 2008 appears.

    Turns out their idea of 'dynamic' isn't the same as mine. They didn't want to generate the drop down every time the page was rendered because that would be wasting CPU cycles.

    ...roll on 2009

  • (cs) in reply to anonymous
    anonymous:
    Grovesy:
    Someone You Know:
    Jake Vinson:
    According to Wikipedia, caching is a method of storing a collection of data for which the time it takes to compute said data is longer than the time it takes to retrieve from the cache.

    That is a very weirdly-constructed sentence.

    For some reason, I think while saying that sentance, one should be holding a bottle of rhum, doing a Jack Sparrow impression...

    Here in the states, we use the word 'Rum'. Google tells me that 'Rhum' is common in french areas of the world, however.

    Are those the parts of the world where they dance the "Rhumba"?

  • The Fake WTF (unregistered) in reply to Shriike
    Shriike:
    Truly Mr. T can do it all.....I never knew, why don't people attribute more to him?

    Speaking of attribution, if that statement gets deleted, we can add it back in giving TDWTF as the source now!

    I pity da fool.

  • kbiel (unregistered)

    The real WTF is that the support staff didn't write a script to automatically reboot the server at the stroke of midnight January 1 of each year. Of course, it would be best if it were a service that polled every 30 seconds or so instead of a cron job.

  • sf (unregistered) in reply to Goplat
    Goplat:
    The real WTF is that the "right" way to get the current year involves an object creation - and since this is Java, there are probably 100 other temporary objects created in the process.
    You may be joking, but you're wrong. 
    Calendar.getInstance().get(Calendar.YEAR)
    will not create a new object and it gets it from a cache (which, btw, is the rwtf.)
  • h (unregistered) in reply to Alfred

    I'd just go with the Monte Carlo approach...

    public int getCurrentYear() {
    if (random() == 0)
        currentYear = DateTime.Now().Year;
    return currentYear;
}

    That way we save a precious assignment and ensure we refresh the cache once in a while (if the value changed). I think you all forgot the original idea and lost perspective here: we need to cache so that fetching is faster...

    Amateurs.

  • (cs)

    I like to cache my whole database on startup, that way I don't have any lookups :)

  • Quicksilver (unregistered) in reply to Shriike
    Shriike:
    Truly Mr. T can do it all.....I never knew, why don't people attribute more to him?

    The Answer is simple. Because of Chuck Norris!!!

  • (cs) in reply to ParkinT
    Isn't Cache King in a down Economy?
    As far as my brain (specifically, my memory), I have been practicing Cache and Carry!

    I pity the fools who continue such jibba-jabba.

    Mr T

  • sf (unregistered) in reply to sf
    sf:
    Goplat:
    The real WTF is that the "right" way to get the current year involves an object creation - and since this is Java, there are probably 100 other temporary objects created in the process.
    You may be joking, but you're wrong. 
    Calendar.getInstance().get(Calendar.YEAR)
    will not create a new object and it gets it from a cache (which, btw, is the rwtf.)
    I stand corrected (by myself.) 
    getInstance()
    is creating a new Calendar instance each time, which, I have to admit, is pretty lame since it uses whatever the timezone and locale that is cached at the moment and which will not likely change.
  • AT (unregistered) in reply to Outlaw Programmer
    Outlaw Programmer:
    Around these parts we typically roll our own Date/Time classes that do some mojo on the value returned by System.currentTimeMillis() without having to go through DateFormats and Calendars. *fingers crossed for Java7*

    I programmed mostly in Java for over 10 years. 95% of my date-related headaches were caused by morons who wrote their own Date/Time wrapper classes, not by the Java APIs. Just sayin'...

  • CynicalTyler (unregistered)

    How long until Clock Girl replaces Irish Girl in our fickle hearts and minds?

  • (cs) in reply to ParkinT
    Jake Vinson:
    According to Wikipedia, caching is a method of storing a collection of data for which the time it takes to compute said data is longer than the time it takes to retrieve from the cache.
    In technical jargon that's known as a "cache cow".
  • (cs) in reply to AT
    AT:
    Outlaw Programmer:
    Around these parts we typically roll our own Date/Time classes that do some mojo on the value returned by System.currentTimeMillis() without having to go through DateFormats and Calendars. *fingers crossed for Java7*

    I programmed mostly in Java for over 10 years. 95% of my date-related headaches were caused by morons who wrote their own Date/Time wrapper classes, not by the Java APIs. Just sayin'...

    Now imagine that those morons never existed, and that consequently the Date/Time wrapper classes were never written.

    That, I think, leaves you with 95% of room for headaches caused by the Java API and/or dingbat excursions like J2EE, whatever flavour of RPC is current this month, etc, etc.

    Never mind. If you still suffer from date-related problems, I'd suggest choccies and a nice bunch of long-stemmed roses. It won't make your problems go away, but, hey, at least it's not Java.

  • (cs) in reply to Outlaw Programmer
    Outlaw Programmer:
    Around these parts we typically roll our own Date/Time classes that do some mojo on the value returned by System.currentTimeMillis() without having to go through DateFormats and Calendars. *fingers crossed for Java7*
    Goplat:
    The real WTF is that the "right" way to get the current year involves an object creation - and since this is Java, there are probably 100 other temporary objects created in the process.
    The real WTF is that people believe that Dates are easy and the Java API must be bad because it's complicated.

    Dates are anything BUT simple - you don't even have to go into Jewish or Buddhist calendars: timezones, leap years and daylight savings time introduce enough complexity that rolling your own date/time routines is almost guaranteed to result in bugs.

  • (cs) in reply to real_aardvark
    in technical jargon that's known as a "cache cow".
    If you still suffer from date-related problems, I'd suggest choccies and a nice bunch of long-stemmed roses.

    Fools. Suckas! You're making Mr T's head explode with that jibba-jabba. And I pity the fool who makes my head explode.

    Mr T

  • Anon (unregistered) in reply to brazzy
    brazzy:
    The real WTF is that people believe that Dates are easy and the Java API must be bad because it's complicated.

    Dates are anything BUT simple - you don't even have to go into Jewish or Buddhist calendars: timezones, leap years and daylight savings time introduce enough complexity that rolling your own date/time routines is almost guaranteed to result in bugs.

    Which is why the Java Date class implements precisely none of that. A Java Date is just a wrapper around a long value measuring milliseconds since 1970, since Sun has helpfully deprecated every other method in the class.

    Why? Because an unsuspecting user might not realize that new Date().getYear() gets a Gregorian year, and because Date did not properly handle dates before 1583.

    Yes, really. One of the reasons you can't get a year from a Date object is because it would return invalid values on certain dates before 1583.

  • (cs) in reply to suzilou
    suzilou:
    in technical jargon that's known as a "cache cow".
    If you still suffer from date-related problems, I'd suggest choccies and a nice bunch of long-stemmed roses.

    Fools. Suckas! You're making Mr T's head explode with that jibba-jabba. And I pity the fool who makes my head explode.

    Mr T

    In Soviet Russia, head explodes You!.

    Well, it's a bit lame, but we haven't seen one of those for a while. I was going for "Please give me teh bytez," or else "All your byte are belong to us..."

    Then I realised that I'm replying to the wrong thread.

    Silly me.

  • (cs) in reply to Anon
    Anon:
    Yes, really. One of the reasons you can't get a year from a Date object is because it would return invalid values on certain dates before 1583.
    And that would, of course, be so incredibly difficult for standard Java Date classes to handle if they actually took the trouble to understand locales and the Gregorian/Julian calendar and ...

    ... hmmm.

    Excuse me?

    If all you've got (which thanks to Unix's brain-dead interpretation of the Multics ideal is all we've got) is "milliseconds since 1970," exactly how do you propose to represent, say, 12:30 PM on January 1st, 1583? Please show us teh Java codez.

  • James (unregistered)

    When you're designing something as fundamental as your runtime library's basic "date" object, you've got to think through the use cases. 99+% of the time, people just want to know about seconds/minutes/hours/days/weeks/months/years relative to the current time, on the current computer, using the current locale settings. Java seems to have designed to the <1% fringe cases, and they pay for it in abominations like this one.

    There's a reason people keep bringing up DateTime.Now.Year, and it's because you can look at it with 10 minutes of programming experience and know what it's saying. You should not need to add a comment to explain something as simple as retrieving the current year.

  • Your Name * (unregistered) 
    public class True {
    private final static True instance = new True();
    public static True getInstance() {
        return instance;
    }
    private True() {
        value = Boolean.getInstance().get(true);
    }

    ...
    public int getValue() {
        return value;
    }
    ...
}
  • Long (unregistered) in reply to sf
    sf:
    sf:
    Goplat:
    The real WTF is that the "right" way to get the current year involves an object creation - and since this is Java, there are probably 100 other temporary objects created in the process.
    You may be joking, but you're wrong. 
    Calendar.getInstance().get(Calendar.YEAR)
    will not create a new object and it gets it from a cache (which, btw, is the rwtf.)
    I stand corrected (by myself.) 
    getInstance()
    is creating a new Calendar instance each time, which, I have to admit, is pretty lame since it uses whatever the timezone and locale that is cached at the moment and which will not likely change.

    The reason being, of course, that you can call setTime() on a Calendar instance so that you can use it on some other date values. If all getInstance() does is to return a cached value, your multi-threaded app would start to fail in mysterious ways.

    IMHO, getCurrentYear() is likely something that is associated with human-readable values (i.e. display a page or generating a report.) In those cases, the overhead of a single getCurrentYear() is negligible compared with the rest of the task.

  • CynicalTyler (unregistered) in reply to Long
    Long:
    IMHO, getCurrentYear() is likely something that is associated with human-readable values (i.e. display a page or generating a report.) In those cases, the overhead of a single getCurrentYear() is negligible compared with the rest of the task.
    So obviously the best way to handle this is to spawn another thread when your app starts that every 10 milliseconds or so checks what the current time is and sets a synchronized global variable for the current year, month, day, hour, and second. Then any thread can use the global as needed! No extra Objects hanging around with nothing to do but sulk until they're garbage collected!
  • Anon (unregistered) in reply to real_aardvark
    real_aardvark:
    Anon:
    Yes, really. One of the reasons you can't get a year from a Date object is because it would return invalid values on certain dates before 1583.
    And that would, of course, be so incredibly difficult for standard Java Date classes to handle if they actually took the trouble to understand locales and the Gregorian/Julian calendar and ...

    ... hmmm.

    Excuse me?

    If all you've got (which thanks to Unix's brain-dead interpretation of the Multics ideal is all we've got) is "milliseconds since 1970," exactly how do you propose to represent, say, 12:30 PM on January 1st, 1583? Please show us teh Java codez.

    I can't figure out WTF you're saying. So I'll just repeat the original point under the assumption that you're trying to suggest I'm defending Sun's overly excessive standard date implementation.

    One of the reasons Sun deprecated all the useful methods from the Date class was because it didn't handle dates before 1583 "properly", which is completely braindead. The number of usecases where anyone cares about dates a century old let along half a fucking millennium old are so few that completely altering the API to accommodate them and not common usecase is a complete WTF.

    But Sun, in their wisdom, just had to make sure that Java can properly form dates before 1583. (But you're still not allowed to use Java in nuclear reactors.)

    Since you asked, that date would be represented in Java using their GregorianCalendar as:

    new GregorianCalendar(1583, Calendar.JANUARY, 1, 12, 30);

    Note that despite "Calendar" being an abstract class that doesn't represent any specific culture's calendar, you still have hard-coded month constants. (WTF?!)

    'Course, there's no reason why Sun couldn't include that class and STILL allow you to do new Date().getYear(), but whatever.

  • ping floyd (unregistered) in reply to anonymous
    anonymous:
    Grovesy:
    Someone You Know:
    Jake Vinson:
    According to Wikipedia, caching is a method of storing a collection of data for which the time it takes to compute said data is longer than the time it takes to retrieve from the cache.

    That is a very weirdly-constructed sentence.

    For some reason, I think while saying that sentance, one should be holding a bottle of rhum, doing a Jack Sparrow impression...

    Here in the states, we use the word 'Rum'. Google tells me that 'Rhum' is common in french areas of the world, however.

    "That would be the French. Inventors of mayonaise..."

  • (cs) in reply to Grovesy
    Grovesy:
    ["Rhum"] is a common spelling in the UK
    No it isn't, unless referring to a Scottish island and even there the spelling was reformed in 1991 according to Wikipedia, though what those pesky so-and-sos at Scottish National Heritage were doing by that I don't know (or, frankly, care).
  • (cs) in reply to Anon
    Anon:
    But Sun, in their wisdom, just had to make sure that Java can properly form dates before 1583. (But you're still not allowed to use Java in nuclear reactors.)
    If it makes you feel happier, remember that you're also not allowed to use Java in nuclear reactors before 1583. Not that it's easy to get an operating license for such back then either; getting the dates right on the application forms seems to be rather difficult...
  • (cs) in reply to Your Name *
    Your Name *:
    public class True {
    private final static True instance = new True();
    public static True getInstance() { return instance; }
    private True() { value = Boolean.getInstance().get(true); }
    public int getValue() { return value; }
}
    You forgot the setValue(Boolean) method. Otherwise your code won't be able to keep up with rapidly changing modern business realities and you'll not be leveraging your key knowledge dynamics for the next-generation enterprise.
  • CynicalTyler (unregistered) in reply to Anon
    Anon:
    (But you're still not allowed to use Java in nuclear reactors.)
    I can't imagine why you would want to try using Java in one of them. I think cubicles are bad enough.
  • (cs)

    Oh well the wrong year is maybe the only thing that is apparent and noticeable. I wouldn't want to know how consistent their data is after using this for ... well ... a few years...

  • (cs) in reply to Your Name *
    Your Name *:
    public class True {
    private final static True instance = new True();
    public static True getInstance() {
        return instance;
    }
    private True() {
        value = Boolean.getInstance().get(true);
    }

    ...
public int getValue() {
    return value;
}
...

    

    }
    But what if the value of true changes?

        public int getValue() {
        if(value == Boolean.getInstance().get(true))
            return value;
        else
            value = !value;
            if(value == Boolean.getInstance().get(true))
                return value;
            else
                return Boolean.getInstance().get(FILE_NOT_FOUND);
    }
  • James A. Donald (unregistered) in reply to biziclop

    Java typically runs ten times slower, and takes up ten times as much memory as C. But you can write programs a lot faster in Java, and they are more likely to be correct, because you are considerably less likely to get memory leaks.

    The day dawns when your Java application, vital to the company's business, just cannot keep up, and so the programmer goes in and starts optimizing, whereupon disaster ensues.

    If you are really not much worried about hardware performance, but programmer importance is important, write it in Python. When the system starts to grind to a horrible halt, rewrite in C++

    Python will get you better programmer performance than Java, C++ better hardware performance. Why should one ever use Java? Certainly one should never use Java in a situation where one needs to worry about Java creating a hundred temporary objects to perform some entirely trivial operation. If you are worried about Java's propensity to create innumerable objects, it is C++ time.

  • (cs) in reply to Quicksilver
    Quicksilver:
    Shriike:
    Truly Mr. T can do it all.....I never knew, why don't people attribute more to him?

    The Answer is simple. Because of Chuck Norris!!!

    Damn it! Someone beat me to it!

    I wonder what would happen if you got them into a room together? Is that how the world is going to end?

  • ircmaxell (unregistered)

    The first rule of caching...

    Know how and WHEN to invalidate cache...

    Stale cache can be worse to an app than no cache...

  • (cs) in reply to tin
    tin:
    Quicksilver:
    Shriike:
    Truly Mr. T can do it all.....I never knew, why don't people attribute more to him?
    The Answer is simple. Because of Chuck Norris!!!
    I wonder what would happen if you got them into a room together?
    Along with Bruce Schneier?
  • (cs) in reply to suzilou

    This issue has nothing to do with languages, or calenders/date objects, it is a simple matter of not understanding caching.

    I'll let you in on a secret - time always changes. If you store a 'current' time now (as a long, or in years, or in days, or using java, or using assembler... doesn't matter how), it cannot be guarranteed to be accurate the next time it is read.

    Now, as Mr T. once told me "Never cache information which changes constantly (fool)".

    On the other hand, if you are storing a 'past' time, then that will not change. Then again, it would not need to be recalculated, and having it in any specialised cache rather than just a public/global object/variable/file/etc would make more sense.

  • Drinking At The Foo Bar (unregistered) in reply to Outlaw Programmer

    It's a stupid solution. It reminds me of offshore code where you have folks that don't understand java or any programming, just enough to get by.

  • GordonS (unregistered) in reply to Grovesy

    Rhum is not a common spelling in the UK.

    What nonsense...

  • You didn't see me right? (unregistered) in reply to GordonS

    Its a rhum do, thats for sure.

  • (cs) in reply to ping floyd

    "That would be the French. Inventors of mayonaise..."

    Mayonaise was invented by the Smashing Pumpkins. Mayonnaise, however, was invented by the Spanish in Port Mahon (mahonese). No sign of the French in either of those.

    I pity the fool.

  • (cs) in reply to Quicksilver
    Quicksilver:
    Shriike:
    Truly Mr. T can do it all.....I never knew, why don't people attribute more to him?

    The Answer is simple. Because of Chuck Norris!!!

    Nominated for lamest joke ever.

  • asifyoucare (unregistered) in reply to ircmaxell
    ircmaxell:
    The first rule of caching...

    Know how and WHEN to invalidate cache...

    Stale cache can be worse to an app than no cache...

    Agreed, and the only way to know whether the cached year value is stale is to check it against the real year. In other words, the cache has gotta go.

  • ER (unregistered)

    Okay, so what's with the picture of the blow-up sex doll (in clothes and a wig) pointing at a clock? Wouldn't a calender have made more sense? And, er, a real person?

  • (cs) in reply to anonymous
    anonymous:
    Grovesy:
    Someone You Know:
    Jake Vinson:
    According to Wikipedia, caching is a method of storing a collection of data for which the time it takes to compute said data is longer than the time it takes to retrieve from the cache.

    That is a very weirdly-constructed sentence.

    For some reason, I think while saying that sentance, one should be holding a bottle of rhum, doing a Jack Sparrow impression...

    Here in the states, we use the word 'Rum'. Google tells me that 'Rhum' is common in french areas of the world, however.

    In Spanish we call it "ron", and it's pronounced somewhat like "run", but with the strong latin "rrrrrr" sound (which may go well with the whole "Arrrrgh matey" motif).

  • matt (unregistered) in reply to CynicalTyler
    CynicalTyler:
    How long until Clock Girl replaces Irish Girl in our fickle hearts and minds?
    Replace? Never!

    (Accompany, maybe)

  • (cs) in reply to Alfred
    Alfred:
    I would assume so.

    I half expected somebody to write a snippet like this:

    public int getCurrentYear() 
{ 
  if (currentYear != DateTime.Now().Year)
    return DateTime.Now().Year;
  else
    return currentYear;
}

    That would get rid of that memory-write-intensive assignment operator.

    I'm sure it's possible to make it even more perverse (and yet still plausible) but I'll be damned as to how.

    Alfred, your code has a potential bug. What if you check currentYear and it is equal to DateTime.Now().Year, but it's a millisecond before midnight. Now, before you can return, the clock ticks. Oops! Wrong date returned.

    Better to double check:

    public int getCurrentYear() 
{ 
  if (currentYear != DateTime.Now().Year)
    return DateTime.Now().Year;
  else // Make sure date didn't change since we started.
    if (currentYear != DateTime.Now().Year)
      return DateTime.Now().Year
    else // Really make sure it didn't change.
      if (currentYear != DateTime.Now().Year)
        return DateTime.Now().Year
      else
        return currentYear;
}

    That should ensure you don't get bitten by that bug.

  • (cs) in reply to dkf
    dkf:
    If it makes you feel happier, remember that you're also not allowed to use Java in nuclear reactors before 1583. Not that it's easy to get an operating license for such back then either; getting the dates right on the application forms seems to be rather difficult...

    Oh, come on! Everybody knows that there wasn't enough government in place back in 1583 to require an operating license for a mere nuclear plant. Anybody could build and run one. My great-great-great-great-great-great-great-great-great-great (somewhere in there) grandfather had a whole chain of nuclear reactors that he started building in 1582; the first one came on line on January 1, 1583.

  • Artemus Harper (unregistered) in reply to ParkinT

    Time to put on my over engineering gloves...

    public class CurrentYear
{
   private static int year;
   private static long nextYearTime;
   
   public static int now()
   {
      long nowMillis = System.currentTimeMillis();
      if(System.currentTimeMillis() >= nextYearTime)
      {
         year = new java.util.GregorianCalendar().get(java.util.Calendar.YEAR);
         nextYearTime = new java.util.GregorianCalendar(year+1,1,1).getTimeInMillis();
      }
      return year;
   }
}

Leave a comment on “The Annual Reboot”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article