flightwish.com update

First off, a big thanks to for his post that led us to some really excellent Web 2.0 graphic design tutorials and such. It was timed perfectly since we had just begun the exercise of mocking up the new site design. I’ve climbed into JavaScript and have added several new scripts that will make the site much easier to use. Our web designer is hard at work producing the graphics we will be using in the site, so far it’s looking really good. I’m really looking forward to climbing into the HTML, but there’s a scheduled power-outage in the are for the whole of tomorrow while they work on long distance power lines. So tomorrow will probably be a picnic in the forest sort of day. Here’s part of the new flightwish.com logo, just for fun πŸ™‚ :

Sometimes something blindingly obvious strikes me

A while back I made EoD SQL Query objects pool friendly if you construct them with a DataSource (which is the preferred way of doing things). This has a very interesting side effect, since now instead of:

...
UserQuery myQuery = QueryTool.createQueryImplementation(UserQuery.class);
User myUser = myQuery.getUser();
myQuery.close();
...

You can do something really cool:

public interface UserQuery extends BaseQuery {
    public static UserQuery QUERY = QueryTool.getQuery(UserQuery.class);
    ...
}

Since the Query automatically closes any Connection when it’s finished being used, and they are totally thread safe, this is a much much better way of doing things. The “getQuery” method was added this morning as a shorthand for “createQueryImplementation”. In other news, there is a new version of the software.

More Flightwish.com (Our secret project)

I’ve just started some rather major surgery on the flightwish.com code base. For the launch at the end of the month we will be completely redoing all of the web look & feel. The current one still feels a lot like a “demo”, so we’re redesigning it into something that looks as great as it feels to use. I’m also in the process of overhauling the entire database layer, since the current one chews through far to much memory for my liking. It’s moving onto EoD SQL, with a very simple caching system I’ve been working on.

Keep a look out to see what comes up at the end of the month πŸ˜‰

Embedded Database in the OS?

I used to hate databases. I really did. You’d never guess it today would you? πŸ˜›

The basic reason was: I didn’t actually understand them, and I couldn’t really code SQL. Over the past few years my use of databases has escalated dramatically, and with it: my understanding of relationships, sets and SQL. With my gain in understanding, I’ve formulated the idea that it would be really cool if the OS came with an embedded database. Each application can reference it from the same “location” (whether it be on the disk, an API, socket, pipe or whatever). Each application auto-magically gets it’s own database, and can check if it’s a “new” (unpopulated) database.

For games it would be great for stats gathering; for music software it would be great for collection management (Amarok uses SQLite); you get the idea. Once the application is uninstalled, it’s database is dumped and compressed. Archived databases are stored for say 6 months and then deleted (in case you re-install the software). Lets face it, storage on disk is cheap in most instances.

Part of these thoughts revolve around my ideas for the ideal OS, based mostly on Java (though probably native compiled for performance). Where the database could be a simple JNDI lookup for applications.

My new project launches soon!

A while back I was involved in a really revolutionary project. We were creating a pilot to demo to several major Venture Capital companies, but just as we finished the code, our intermediary screwed something up, and we wound up stranded with no money to continue the project. All involved were really depressed about it, and the project sort of faded from our minds.

A few days ago however, I checked out the pilot project and began work to take it from this “demo” phase, through to something that we will be launching in the next week or so. We own no less than 4 domains names for the project (all pretty much the same), and for the readers of my blog, I’ve got a few clues as to what we’re up to:

  • It’s sort of social networking
  • It’s very different
  • I get excited thinking about it (O.o)

I’ll give you one of the domain names, but it’s only got an “under construction” page (though we’ll be changing that as launch day get closer). Keep an eye out for this one, it’s gonna be really awsom: www.flightwish.com.

Extending @Annotations

I’ve been thinking for years (as I’m sure many programmers do): “If I designed a language, what would it be like”. As time goes on, I’ve come up with many ideas, but I find it interesting that several aspects have stayed the same:

  • C/C++/Java style syntax
  • Light weight
  • VM driven
  • Possibly even Java byte codes
  • Network friendly (move objects round a’la RMI / Serialization)

Last night I was thinking about it again, and particularly about Java annotations. I know many who hate annotation because they have been baddly abused already. I personally love them, but not everywhere, and not for everything. My main problem with annotations is that the actual meta-data, and the code that drives them are completely separate. What I want are: compile time annotations. Something more like:

@Target(ElementType.METHOD)
public @class CachedResult {
    public void run(Node target) {
        if(target instanceof MethodNode) {
            MethodNode method = (MethodNode)target;
            if(method.getParameterTypes().length > 0) {
                throw new IllegalArgumentException("Bla!!!");
            }
            
            ClassNode clazz = method.getDeclaringClass();
            
            String name = method.getName();
            String fieldName = generateFieldName(name);
            
            FieldNode node = clazz.createField(method.getReturnType(), fieldName);
            method.setName("_cached_" + name);
            method.setAccess(AccessModifiers.PRIVATE);
            
            MethodNode cacher = clazz.createMethod(method.getReturnType(), name);
            StringBuilder code = new StringBuilder();
            code.append("if(").append(fieldName).append(" == null) {");
            code.append(fieldName).append(" = _cached_").append(name).append("();");
            code.append("}");
            code.append("return ").append(fieldName).append(";");
            
            cacher.eval(code.toString());
        } else {
            throw new IllegalArgumentException("Bla!!!");
        }
    }
    
    ...
}

The above “annotation” would cause the compiler to rename the annotated method to “_cached_<methodname>”. The method would be invoked once and the result would be put in a field, which would be returned from then on. It’s a simple enough trick which would make life just that little bit easier. It’s also not terribly complex to put in a compiler. It’s simply a DOM style API for accessing the classes, fields and methods, and then being able to “eval” code into a method (also not challenging). The result: you can add new tricks to the compiler really easily.

Objects in SQL Databases

As a very long-time Java developer, and someone who has worked with many different databases (from embedded SmallSQL, to >600 table legacy Informix database, to a brand spanking new Oracle DB), I’ve also worked with lots of ways to get data in and out of the database. I’ve used JDO (in various forms), Hibernate, TopLink, my own home-grown mapping layer, direct SQL through JDBC.

I feel I can now say I’m fluent in SQL, since I’ve recently been writing SQL statements that span 20 or more lines. What i’ve come to realize is that when you put a major Object/Relational mapping layer between you and your database, you may as well be storing your data in XML files on the filesystem (having played around with both, I find that the performance is much the same). Rather use a true Object database where possible (for actually storing objects, the performance is much better than a SQL database).

The problem is that you are loosing all the power that sits in SQL. SQL is an incredibly powerful language, designed entirely for fetching and manipulating data. It’s not the performance of the mapping layer I’m concerned with, but the fact that you can no longer craft efficient SQL.

Summary: Use the right tools in the right places!