Confused by DVCS? Joel can help

22. March, 2010

In his last article, Joel talks how DVCS confused him and how he solved the problem. One sentence in particular should be noted:

these systems think in terms of changes, not in terms of versions.

Still confused? Read his HgInit tutorial to get you up to speed with Mercurial (or any other DVCS because they are all pretty similar at that level).

PS: I prefer Mercurial to Git for twothree reasons:

1. I need a working DCVS, not a toolbox to build one. I prefer it when a smart guy has given all the hidden issues some thought, so I don’t have to.

2. There is a simple, working Windows installer.

3. It’s written in Python.


The Python Module of the Week Blog

17. March, 2010

If you love Python, this blog is for you: Doug Hellmann posts about one Python module every week (PyMOTW). The posts contain lots of real world examples how to use a module. This week, it’s ElementTree.


Extending Tomcat WebappLoader to Share Library jars

16. March, 2010

If you’re like me and use Tomcat and you want to bring down the size of your WAR, you’re faced with one issue: All your applications need to use the same libraries (since there is only a single common/lib for everyone). So you’re either stuck with an old version or you need to upgrade all your apps at the same time. I just can see the budget guys shake their heads.

The solution is a list of directories in your context.xml which contain specific versions of the libraries you need. This way, you can install all the versions you need and each app can pick and choose.

For the complete solution, see the original article: Extending Tomcat WebappLoader to Share Library jars

OSS for teh win! 🙂


Code Bubbles

11. March, 2010

I’m always interested in new ways to display and edit code. ASCII is soooo tedious.

Code Bubbles is a new approach to cut files into fragments which can be arranged per task.


How do I make them test?

9. March, 2010

On The Daily WTF was a nice story: Unit Tested. It’s a story how someone tried developers to test their code and failed.

It’s always the same story and always the same reason: For a change in behavior, expect a year for it to become a habit. Under the best conditions.

So how do you introduce tests to developers? Here are some tips:

1. When they fix a bug, ask “Are you sure the fix is good? How do you know? Ah, you ran the code? Good. Then run the code once more but from a little test.”

2. When they discuss a new feature and can’t decide which way to go, say “How about you write a test for the feature and then try to modify the code so it makes the test pass. This way, we’ll see quickly which way works better”

3. Write some tests yourself. Make sure they run and if they fail, talk to the guy who made them fail. Help them to fix the problem. The bad solution would be to ridicule them, or punish them. Everyone makes mistakes. The tests are there to help to make less mistakes.

If the tests become another problem in the daily routine, They won’t generate enough positive energy for anyone to bother. Result: Failure.

If you meet resistance, ask yourself: What problem do I solve? Or am I just being religious? Do I test for the sake of testing? Or do the tests make everything better for everyone? Do they reduce stress or increase stress? Why?

All these questions will have different answers depending on your specific situation and the answers will help you to find your solution. Paper can’t think, you can. If some rule (out of a book or from your boss) just doesn’t make sense, then it’s your turn to come up with a solution.

There is just one thing to keep in mind and that’s the goal: Tests must help. Everything else will follow.


Managing runtime dependencies

8. March, 2010

Here is a nice post by Julian Simpson about how to manage your runtime dependencies (i.e. programs and libraries which your code expects and which you can’t handle with, say, Maven): A way to cool dependency Hell?


Spring Roo

5. March, 2010

[Update November, 5th] I tried Roo 1.1. See this blog post.

[Update March, 17th] After posting this, the guys from Roo posted the comments below. The command line parser bug is fixed, the dependencies will be fixed in the next version and they are investigating a fix I sent them for the NoClassDefFoundError. Not everything is perfect but at least they work on it 🙂

I just tried the ten minute example of Spring Roo. It took a lot more than ten minutes to get a huge exception. Oh well. Some notes:

Roo expects a vanilla Maven installation. If you’re behind a proxy like Nexus which limits what Maven can download, you loose. The Roo guys have copied everything (like log4j) in their own Maven repository under a weird name (org.apache.log4j:com.springsource.org.apache.log4j:1.2.15). So after working with Roo, you have a tainted repository with a lot of duplicate entries. Well done.

Of course, not everything has been copied. So some stuff comes from central, some from springsource. This meant half an hour setup of our Nexus server, trying to avoid to break it for the rest of the team.

When I try to run the app, I get

Caused by: org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'org.springframework.validation.beanvalidation.LocalValidatorFactoryBean#0':
Invocation of init method failed; nested exception is
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException

I see. Well, your 10 minutes is up. Oh, and there is a bug: controller all works while controller all doesn’t. The difference? There is more than one space after the command. This breaks the parser (and the TAB completion). I’d file a bug if I knew how. A prominent link on the web site (that doesn’t lead to the general SpringSource Enterprise Support) would be nice.


Java Tricks: Lazy initialization

4. March, 2010

If you’re a Java developer and you’re concerned about performance, you’ve probably encountered the (broken) double checked locking pattern (which I won’t reproduce here to make sure no one copies it accidentally. If you care, read the Wikipedia article).

Joshua Block has proposed a solution but there are a couple of fine points to it. If you don’t get it right, things are going to break in odd ways. So this should go into a helper class which handles all the boiler plate code. A post about final variables pointed me in the right direction. So without further ado, the LazyInit class:

/** Lazy initialization of a field value based on the (correct)
 * double checked locking idiom by Joschua Bloch
 * 
 * <p>See "Effective Java, Second Edition", p. 283
 */
public abstract class LazyInit<T>
{
    private volatile T field;
    
    /** Return the value.
     * 
     *  <p>If the value is still <code>null</code>, the method will block and
     *  invoke <code>computeValue()</code>. Calls from other threads will wait
     *  until the call from the first thread will complete.
     */
    public T get ()
    {
        T result = field;
        if (result == null) // First check (no locking)
        {
            synchronized (this)
            {
                result = field;
                if (result == null) // Second check (with locking)
                {
                    field = result = computeValue ();
                }
            }
        }
        return result;
    }

    protected abstract T computeValue ();
    
    /** Setter for tests */
    public synchronized void set (T value)
    {
        field = value;
    }
}

As an additional goodie, it allows you to override the value in tests. Here is how to use this code:

    private LazyInit<String> field1 = new LazyInit<String> () {
        
        @Override
        protected String computeValue ()
        {
            return "value";
        }
    };

    @Test
    public void testLazyInit () throws Exception
    {
        assertEquals ("value", field1.get ());
    }

Simple, isn’t it?


Better bug reporting

3. March, 2010

In his blog, stephan writes about the problems you can have as a bug reporter. Basically, when you encounter a bug, you’re in the middle of something that you need to get done. You don’t have time to analyze the bug, collect all the information that might be around, note it down and write a good bug report.

Instead you need to get your job done. Then, later (whenever that might be … tomorrow or in a week or next year), you can worry about the bug. Anyone wondering why bug reports are often so bad?

But there might be a pretty simple solution: Java already can dump its heap (all objects) to a file. So what we need is a way to start this dump and add a screenshot plus a short description to it. This gets stored somewhere and when we’re done with our current task, we can return to the problem, analyze it more deeply or just zip everything up and post it as a raw bug report.

Luckily Eclipse is OSS (a.k.a “Nothing is impossible if you don’t have to do it yourself.”) See Bug 304544.


OO 2.0: Reuse

25. February, 2010

What’s the most important feature of OO? Reuse.

What’s the biggest problem of Java? Reuse.

In Java, it’s considered good practice to make everything private or even final. This goes along the lines “when I open part of my API, someone might use it and this might cause problems for me later when I have to change the API”. So all fields are private. Which leads to huge lists of getters and setters which you don’t need most of the time. But you can’t omit them because if you need them, you can’t retrofit them. I guess all of us have a story where we wanted to use a class and everything was fine until we needed one more thing from that class and that thing wasn’t public or protected.

The underlying problem is that Java is based on the idea that the code is simple to parse and read. Which means that things like templates, patterns or pre-compilers aren’t supported. Even when you use annotations, you can’t modify the output at compile time. You can use load time byte-code manipulation but at compile time, the code is about as flexible as a bridge pillar.

But there is hope. The guys from the Object Teams project (OT) have created a Java-like language where you can reach into existing code and manipulate it in various ways. If you’re wondering if this is AOP with a new name or just delegation on steroids, this post will help to understand what OT is and what it’s not.

In a nutshell, OT is about reuse. If some class doesn’t provide a getter for a private field, OT can insert one for you. To get a feeling if OT can help you, I suggest to browse the blog and the examples. The stop watch example is probably the most simple to understand. The other examples look a bit incomplete or they might show that OT still has some issues with the syntax (which you’ll remember from AOP but it’s certainly not as extreme).

I, for one, will keep an eye on this project.