Waterfall 2006
If you're not practicing agile methods, maybe that means you'd like to attend Waterfall 2006.
If you're not practicing agile methods, maybe that means you'd like to attend Waterfall 2006.
Yale University ITS Technology & Planning has two -- count 'em two! -- openings listed. Technology & Planning is a great place to work -- awesome coworkers, good working environment, neat projects. Be interested in these jobs.
If you're not reading Doctor Dobb's Journal, you're missing out on some good times.
There's a Java web programming job available at Yale Pathology. There's more to the job than just being a Java junkie, of course: "The position involves a combination of software application and database development and system administration supporting affiliated projects." Sounds like fun!
Initializing a usable object in the constructor has the tremendous virtue of enabling guaranteeing that an object will only be instantiated into a good state (illegal states detected and exceptions thrown in the constructor implementations). From that point on the object can jealously guard the validity of its state, throwing on methods with illegal arguments that would compromise its state.
I respectfully take exception to Benjamin Booth's Pragmatic Exceptions tip #6 as published in the February 2006 DDJ (page 24).
Bad. This will most likely result in seeeing the same exception message at very different points in your program's execution. The problem is, it's the same error!
"[both logging and throwing an exception] sends an ambivalent message to callers of your function. The pitcher is saying to the catcher, "I'll log this now but, well, I'm not sure, it could be fatal, perhaps you should deal with it too?" This isn't only weak minded, it's also lazy and pathetic."
Indiana University is seeking a highly motivated Senior Analyst/Programmer to work on enhancements supporting their Human Resources Management and Timekeeping systems deployed in a J2EE AIX Oracle infrastructure environment.
Your component will fail. The input will be bad. You're going to screw up and get a null pointer exception. Even if you're perfect, some imperfect person will touch your code long after you've moved on to other projects.
I got interested in automating copy constructors today and realized what perhaps is obvious and certainly others have already realized: that Spring's BeanUtils copyProperties() method can be an effective tool for quickly implementing copy constructors with support for copying appropriately from within a class hierarchy.
I found interesting Joel's post on what Computer Science is, and what it is not, and perhaps on why my career is so different from what I studied in college.
But JavaSchools also fail to train the brains of kids to be adept, agile, and flexible enough to do good software design (and I don't mean OO "design", where you spend countless hours rewriting your code to rejiggle your object hierarchy, or you fret about faux "problems" like has-a vs. is-a).
"I have never met anyone who can do Scheme, Haskell, and C pointers who can't pick up Java in two days, and create better Java code than people with five years of experience in Java, but try explaining that to the average HR drone."