I've never been to latin america (unless Florida counts). I've never been to Mardi Gras either. But this is the time of the year when the news is filled with pictures of Carnival in Brazil and other great places. And I think it's awesome.
Public displays of non-inhibition are not always pretty but the pictures of the various Carnival celebrations are truly splendiferous. Just a nice reminder that the accepted American narrative of normal and appropriate behavior is clearly deficient.
( Feb 23 2004, 12:03:00 PM PST )
Constants Abuse Hard-coding string and numeric values into application logic is often problem-plagued. I tcan lead to duplication, which leads to maintenance nightmares, which can lead to increased substance abuse, drinking, crack cocain... it's a treacherous road. Don't go there.
It's a pretty common (and usually, good) practice amongst java programmers to organize all of the little magic values that application logic depends on into a class that defines public constants. However, this can lead to another problem: constants bloat. Cases where the developer needs to define a constant that is only accessed by one component (let's just call a single class and its instances "one component" for the time being) but stores it in a shared centralized constants class is another form of substance abuse. It's constants abuse.
I would really prefer to see constants with a limited scope of applicability confined to that scope. For instance, if it's only used by one class -- define it in that class, not the shared centralized beast. If it's only used by a cluster of classes that work on a particular area, perhaps there's already a bean that they all know about; the constant may be better suited for that bean than a class shared system-wide.
Confine the scope of your constants definitions to where they are useful and save yourself and your colleagues maintenance headaches down the road.
( Feb 23 2004, 10:55:14 AM PST )