Craig Pardey

Throwing somebody under the bus (ref) is a cowardly act, and one that particularly irks me. Nobody likes to be humiliated in front of others.

I’ve seen this happen countless time when a developer will point out a bug or error of another developer and use it as an excuse for not delivering on their own work. “I couldn’t load the data because of a bug in Johnny’s code”. Bullshit. If you were a team player then you would have pulled up a chair next to Johnny and tried to fix the bug so that the project could move forward.

I’ve been using Netezza for a few months now and this post captures my opinions based on my limited experience. For context, I’m populating a Netezza database for a client. The database schema is managed by the client, and Netezza was selected prior to my involvement. Netezza is their data warehouse, but they’re also using it a little like an application database. They’re using a bi-temporal model, but that’s a subject for another post.

I’ve been over the high-level requirements and think it’ll probably take 8 weeks with 2 developers, so you should be able to deliver this by X.

Well, that’s great. Can I presume that you’re one of the two developers working on it? I didn’t think so.

Nothing irks me more than being handed a batch of work along with the timeline for delivering it. If you want to estimate my work for me, then you can also go ahead and build it.

According to the Hauppauge website, the Western Digital Live Hub works with the Hauppauge WinTV-HVR-950Q TV tuner.

It does not.

The Hauppauge app does the channel scan, but freezes when you try to change channels. In other words you have to reboot the WD Live box whenever you want to change channels. That doesn’t count as working in my books. Just sayin’…

A bit of Googling has shown that 950Q hardware Rev B may have worked, but the version commonly available in stores is Rev E. YMMV.

Spring’s gotcha-of-the-day is around using @Value to resolve property placeholders in combination with @PropertySource.

I had the following Spring Java configuration:

@Configuration  
@PropertySource("classpath:/test.properties")  
public class TestAppConfig {

    @Value("${queue.name}")  
    private String queue;
    
    @Bean(name="queue")  
    public String getQueue() {  
        return queue;  
    }  
}  

But the value in “queue” was not resolving - it returned “${queue.name}” as the value.

It turns out that I needed the following magical incantation to get it to work.

I’ve been interviewing candidates quite a bit lately and I must admit that I quite enjoy the process. I get to meet new people and learn about how they work, and things they’ve worked on, and about technologies that I haven’t used or haven’t heard of.

At Intelliware we usually conduct two separate interviews: the first is a personality/fit interview intended to answer the questions, “Can we work with this person, and would they be happy here?”. The second interview assesses their technical chops.

Spring 3.2 has some very nice features for scheduling tasks.

The pure Java way of doing this looks something like

private ScheduledExecutorService executor =
Executors.newSingleThreadScheduledExecutor();  
class ScheduledTask implements Runnable {  
    @Override  
    public void run() {  
        System.out.println("Running scheduled task");  
    }  
}

// Schedule a task every 5 seconds  
executor.scheduleAtFixedRate(new ScheduledTask(), 1, 5, TimeUnit.SECONDS);  
// If you don't do this then the JVM won't exit cleanly  
executor.shutdown();  

But now, with the snazzy new Spring scheduling annotations, it can be as simple as this

The TestNG Eclipse plugin has a feature that will convert your unit tests from JUnit to TestNG in a few simple clicks, and it works pretty well for the most part. However, I soon noticed that it was replacing Assert.assertX with AssertJUnit.assertX. Upon further inspection, this was because TestNG’s Assert uses different argument ordering. For example

// JUnit  
Assert.assertEquals(message, expected, actual);

// TestNG  
Assert.assertEquals(actual, expected, message);  

Each argument has moved.

I recently went through an exercise of converting Spring XML configuration files to Java-based configuration. The process went well for the most part, but I encountered an oddity around how to use factory beans when using Java configs.

In XML, factory beans would be used like this

<bean id="MyDataSource"  
class="org.springframework.jndi.JndiObjectFactoryBean"  
p:jndiName="jdbc/MyDataSource"  
p:resourceRef="false"  
/>  

In Java however, this has to be separated into two separate @Beans

@Bean  
public JndiObjectFactoryBean getJndiObjectFactoryBean() {  
	JndiObjectFactoryBean jndi = new JndiObjectFactoryBean();  
	jndi.setJndiName("jdbc/MyDataSource");  
	jndi.setResourceRef(false);  
	return jndi;  
}

@Bean  
public DataSource getSampleDataSource() {  
	return (DataSource) getJndiObjectFactoryBean().getObject();  
}  

Bugs caused by multi-threading can be very difficult to find. Here’s one I encountered recently.

private static MyObject INSTANCE;

public void init() {  
	if( INSTANCE == null) {  
		initInstance();  
	}  
}

private static synchronized void initInstance() {  
	if( INSTANCE != null) {  
		return;  
	}  
	INSTANCE = new MyObject();  
	INSTANCE.initThis();  
	INSTANCE.initThat();  
}  

At first glance, this code is fine. It uses a synchronized static method to create the singleton, using double-checked locking to make sure it only gets created once. But on closer inspection it is possible for the null check in init() to pass before the INSTANCE has been fully initialized.