New Microhood

1031091735.jpg, originally uploaded by jmrodri.

After almost a month, I finally decided to install the microhood today.

I started by turning off the breaker, then removing the 6 screws from the old range hood. I had to drill two 3/8″ holes in the cabinet and a 1.5″ hole for the plug. Thankfully I didn’t have to mess with the existing duct work. I did have to tape up the old wiring and push it into the wall, since the new microhood has a plug.

The bracket had 4 springed wing bolts and 3 lag screws into the studs. To find centerline I crated my own plumb with a thread, push ping and a bolt. πŸ™‚

Liz helped me hook the microhood onto the bracket and get it screwed in from the top. Once it was in place, I plugged it in and switched the breaker. Thankfully no sparks πŸ˜€

Next text was turn on the light, followed by the fan. All worked. Last test was try out the actual microwave part. WOO HOO! nothing blew up.


Here are some of the great nuggets from the link I posted tonight.

So GWT tries to hide Javascript from Java programmers, the same way Hibernate and other ORMs try to hide the database. How many of you use ORMs? How many of you have run into this problem? On Spacewalk we ran into this a lot, so much so we gave up on Hibernate for any other than loading an object for editing, in favor of straight SQL stored in an XML file.

“This is the same basic problem with ORMs like Hibernate: Object-relational impedance mismatch. Every now and again you end up spending half a day figuring the correct combination of properties, annotations, XML and VM parameters to have a query generate the right two lines of SQL that’ll actually be performant.”

Another thing I’ve always said to my management and team members was exactly this. That’s why I’m against open coding environments.

“We all know that knowledge workers work best by getting into “flow”, also known as being “in the zone”, where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.

The trouble is, getting into “the zone” is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity.

The other trouble is that it’s so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers — especially interruptions by coworkers — all knock you out of the zone.

And as I stated in my Overengineered Project post., Java devs like to over engineer solutions in favor of flexibility that may or may not happen.

“What’s more Java programmers have a predilection with concerning themselves about swapping out layers or putting in alternative implementations that never happen.

I am a firm believer that lines of code are the enemy. “

And we’re totally guilty of these layers as well, even on project Spacewalk we can see some of these things in practice. We
have a Manager layer, a UI layer, not to mention a database layer πŸ™‚

“It’s not [sic] secret that Java programmers love their layers. No sooner do you have a Presentation Layer, a Controller Layer and a Repository Layer than someone suggest you also need a Database Abstraction Layer, a Service Layer, a Web Services Layer and a Messaging Layer.”

So what can you learn from all this? KISS!

Old overengineered project :)

I was looking through some old backups (~2003), and found a Java program I wrote to create thumbnails of photos for the website I was running at home. What a stupid idea that was, especially since I was running Linux at the time. There were plenty of programs that could do that conversion for me, not to mention running my own photo gallery wasn’t the brightest idea either. The worst part of the code is how over engineered it was for such a simple task. I was going to delete it, but I went ahead and put the project, PhotoResizer, up on github with all my other projects. Want to see how not cool it is? Sure you do, you need a good laugh right about now don’t you? πŸ™‚

So let’s take a look at some of the over-engineering. First off, I wonder where I was in my coding when I did this. It was 2003, and I was a Java weanie. I lived and breathed Java and thought it was the greatest language ever. Six years later, I know for a fact that’s just plain WRONG. As a Java weanie I used to think we always needed interfaces for everything “just in case” I needed to add another implementation.

So here’s the Configuration interface πŸ™‚ now why the hell would I want another configuration implementation? What are the odds that I’d need more than one type of config file?

public interface Configuration {
    String getProperty(String key);
    int getPropertyAsInt(String key) throws NumberFormatException;

If you have an interface that means you probably have a concrete implementation, yep I did:

package net.zeusville.core.config;
import java.util.Properties;
* @author jmrodri
* To change the template for this generated type comment go to Window -
* Preferences - Java - Code Generation - Code and Comments
public class PropertyConfigImpl implements Configuration {
    private Properties properties;
    public PropertyConfigImpl(String filename)
        throws InvalidConfigurationException {
        try {
            properties = new Properties();
            FileInputStream fis = new FileInputStream(filename);
        catch (FileNotFoundException e) {
            throw new InvalidConfigurationException("Could not find ["
                    + filename + "]", e);
        catch (IOException e) {
            throw new InvalidConfigurationException("Could not read ["
                    + filename + "]", e);
* (non-Javadoc)
* @see net.zeusville.util.Configuration#getProperty(java.lang.String)
    public String getProperty(String key) {
        return properties.getProperty(key);
    public int getPropertyAsInt(String key) throws NumberFormatException {
        return Integer.parseInt(getProperty(key));

LOL! That is certainly a lot of code to read in a .properties file. It gets better πŸ™‚ Because we all know that every interface and concrete implementation needs a factory or in my case a Manager.

public class ConfigurationManager {
    private static Configuration configuration;
    public static Configuration getConfiguration() {
        if (configuration == null)
            configuration = new PropertyConfigImpl(
        return configuration;

Wow, that’s just sad. I can’t believe I actually wrote this stuff. I’m not done yet πŸ™‚ Like Billy Mays would say ‘… but that’s not all, there’s MORE!’

How much more could I have done to over-engineer this solution? I mean I’m just wanting to create thumbnails of a directory of pictures. Just read the list of files, and for each one convert to a configurable thumbnail size, write it out. Done right? no way JosΓ© I went all out. No Java program is acceptable without THREADS! Don’t bother getting off the floor, because what I’m about to show you next will make you laugh your @$$ off.

Simple threads weren’t good enough for this high powered solution πŸ™‚ I went all out and created a queue of work items with a pool of worker threads doing the conversion. No really, that’s what I did. Check out the InterThreadQueue.

Here’s the run() method from the ImageTransformer which looks to be the guts of PhotoResizer.