Below is a table that lists the colors available as constants in SWT. Because these colors are frequently used in SWT development, I put this together as a quick color reference - all of the colors listed can be accessed by calling display.getSystemColor( SWT.COLOR NAME).

Much to my dismay, I couldn't find a rendered version like this anywhere in Eclipse's documentation; if you know of one, let me know by adding a comment.

I’m currently investigating “part of speech” taggers (commonly referred to as simply POS taggers) and came across a relatively new Java API for POS tagging developed by the Stanford Natural Language Processing Group.  What I really like about this API is its simplicity - other POS tagger APIs have not been as simple.  However, it is understandable that many POS tagger APIs are complex because POS tagging, while relatively simple for us humans, is not easy for software.

Here's a little Java trivia....

While building some GUI screens for an Eclipse RCP application, I came across what I consider to be strange behavior in the Java language. Instead of trying to explain it, take a look at the below code:

Parent.java
================================================
public abstract class Parent
{
    public Parent()
    {
        setVarAValue();
    }
    public static void main( String args[] )
    {
        Child child = new Child();
        System.out.println( "varA = [" + child.getVarAValue() + "]" );
    }
    
    protected abstract void setVarAValue();
    protected abstract String getVarAValue();
}

class Child extends Parent
{
    private String varA = null;
    public Child()
    {
        super();
    }
    
    public String getVarAValue()
    {
        return varA;
    }

    protected void setVarAValue()
    {
        varA = "a value";
    }
}
================================================

This weekend I attended the "No Fluff Just Stuff" Software Symposium and had the good fortune of catching Scott Davis teach a session on "Real World Web Services." Scott is a terrific speaker and if you ever get the chance to listen to him, I highly recommend it - he is very entertaining and easy to listen to.

As noted by the title of this blog entry, I left the session very excited about an alternative style for constructing web services referred to as REST (stands for Representational State Transfer). The reason I'm excited is simple - I'm frustrated by the complexities of SOAP! Now, if you're thinking 'why is this guy frustrated? Building web services with SOAP is easy' let me burst your bubble: it isn't easy. Is it impossible? Of course not; is it complicated? Yes. I've recently been working on a project that utilizes SOAP based web services and I can tell you from personal experience it's not easy. Just to give you some background on myself, I am a Sun Certified Java Web Services Developer and it's still not easy. Consider this excerpt from the installation instructions for the Axis framework (a very popular web service framework):

I've been amazed recently at just how helpful and useful a java decompiler can be. If you don't know what a decompiler is, or you do but haven't taken the time to download one, let me start by saying you're missing out! A decompiler is a tool that lives up to its name - it does the opposite of a compiler by taking compiled .class files and converting them into source .java files. This is accomplished by using the Java classfile format as a key for decrypting the file into java "plain text".

The tools that do one thing, and do it really well, are usually the tools that stand the test of time.  CVS definitely fits the description of doing one thing and doing it very well.  It is one of the best, if not the best, source control system available and is utilized by millions of developers.  However, CVS by itself does not provide any reporting capabilities or quick views into high level statistics about your source code tree.  Your source code is your most important asset and being able to view statistics, high level data, and commit logs is very important to having a well rounded picture of what’s going on with your code.  And this isn’t just for developers; Project Managers and Technical Leads should especially have a deep interest in monitoring code activity.  This is because many non-system "human" processes and procedures are put into place in order to control source check-ins and at times, even lock down the source through code freezes.  Without an easy to use, high level report about source code activity, how in the world will Project Managers or Technical Leads know developers are following defined processes? The answer - they won’t.