wtfhax

Fancy form input hints with legal markup

2008-12-17T18:26:00.048Z

Update

Jason has updated his excellent hint script. I seriously recommended it. I modified the example to use his one.

It is quite common these days to use JavaScript to enhance text input fields in HTML forms. One popular technique is to display a helpful text inside the input box before it gains focus and back on blur if nothing has been typed. Something like the What are you doing at the moment? box on Facebook. As I was searching for examples on how this is commonly implemented, I was surprised to find only solutions that relied on illegal element attributes such as hint or placeholder to store the hint text.

Below is an example of invalid markup from a typical solution. Note that I am omitting the usual attributes such as id and name since they are not relevant here. Also note that there is no scripting applied to the example so there is no way to actually see the hint text (with the exception of using view source or Firebug.

Source

<label>Departure</label>
<input hint="dd.mm.yyyy" />

Output

Departure

This certainly makes the field more accessible for those who have Javascript turned on. But it otherwise useless and I am not sure how a screen reader will interpreted this. But it is nothing new to display an example hint next to an input field to aid the user. Here is how I used to do this:

Source

<label>Departure</label>
<input />
<em>dd.mm.yyyy</em>

Output

Departure dd.mm.yyyy

Actually there are more specific HTML elements for this purpose. I found the <kbd/> element to be just what I needed:

Source

<label>Departure</label>
<input />
<kbd>dd.mm.yyyy</kbd>

Output

Departure dd.mm.yyyy

I admit that the default styling is not that pretty but that is easy enough to fix with little CSS. It is also nice to use a little lighter colour on the hint than the label/input text. I will leave that to the professionals.

kbd { font-style : italic; }

I am pretty found of this last example and it is easy to use the markup to implement the same popular focus/blur hint functionality. After finding a nice jQuery input-hint plugin that works on the hint attribute and modifying it a little, I came up with a simple solution that degrades nicely. The plugin accepts a selector to find the element that is to provide the hint text. In the case of using kbd for the hint, the selector would be "+kbd".

Demo

Departure dd.mm.yyyy

Code

$(function(){
    $('#demo input').inputHint({using: '+ kbd'});
});

Python on Portals - portlet.py

2008-11-27T17:02:00.028Z

Now you can run Python on Java Portals with the help of Jython and a small project I have been working on: portlet.py.

Jython is a Java implementation of python and allows you to run python code on the JVM. This is great on its own but I haven't been able to use it in my web development work. It does support servlets through the PyServlet class. However, I prefer to use Spring controllers instead of boring vanilla servlets.

What I have been missing is to write portlets (JSR-168/268) in Python. This requires a similar dispatcher as PyServlet is for servlets, but for portlets instead. So I gave Jython a change and PyPortlet was born. Now I can enjoy the refreshing lack of Java for simple portlet development. Although I will still use the Spring Portlet MVC framework for larger projects.

Usage

Using PyPortlet to dispatch portlet requests to you python portlet is pretty simple. Here is an example of the portlet definition in portlet.xml, notice the init parameters:

    <portlet>
        <portlet-name>portletpy</portlet-name>
        <display-name>Hello Jython Portlet</display-name>
        <portlet-class>is.hax.portlet.PyPortlet</portlet-class>
        
        <init-param>
               <name>python.home</name>
               <value>/usr/local/jython2.2.1</value>
        </init-param>        
        <init-param>
         <name>python.portlet</name>
         <value>myportlet.HelloPortlet</value>
        </init-param>
        <!-- ... -->
    </portlet>

What you have to do is to specify PyPortlet as the portlet-class and provide it with location of jython and the python portlet class. The you need jython.jar on your classpath. Here is a hello world portlet:

from javax.portlet import GenericPortlet
 
class HelloPortlet(GenericPortlet):
    def render(self, request, response):
        res.writer.append('<p>Hello World, how are we?</p>')

Simple eyhh? Now you have full access to the portlet API in python. And lets not forget no restarting between editing the python code!

portlet.py

After a while I realized that it is only so much fun to use python against a Java API. After all I still need to call all those long method names and there is little support for the gems of python you get when you override __methods__. Fortunately it is simple to wrap the java APIs in a thin python layer that integrates the best of both worlds. So I added one module to the project, portlet.py, which adds the needed sugar to the cake.

Here is a very small dummy example of how it looks. More examples are on the Wiki:

from portlet import Portlet

class ExampleUse(Portlet):
    def render(self, req, res):
        res << '<p>Hello World, how are we?</p>'
        counter = req.session['counter']
        url = res.action(name='python')      

    def action(self, req, res):
        name = req['name']

Next steps

I am pretty happy with the result and I love to have a project with only one Java class (who said it couln't be done?). There are however a few things I want to add. First is a bundled portlet that allows you put the python portlet code in the portlet preferences instead of on the file system. What this means is that you could write a python portlet – Through The Web – directly on a production/staging server with no deployment needed for simple use cases. Secondly, I want to support other python scripts than portlets, so the user can simply write a simple python script without conforming to the portlet API. Again, for even simpler cases.

My initial reaction to jython has been very positive, and I am looking forward to trying out the upcoming 2.5 version. Hopefully this will run there too. There is a lot of effort in porting various popular python projects to jython but I find it at least as important to embrace existing java projects and make it easy to use them from jython. Hopefully this will be helpful to others in that direction. But there is a lot of ground to cover. My personal favorite would be python support in the Spring framework.

JAdapter 0.2 is out

2008-10-15T18:27:00.002Z

JAdapter 0.2 is now out and contains a few handy features. It is available for download here. Like last time, I want to discuss the main features.

Less configuration

It is no longer needed to pass the transformer types to JAdapter if the adapter class follows a conventional pattern and I already blogged about this here.

Optional Support for Spring Framework

To make it easy to setup the adapters and the registry when using the Spring Framework, I added a new package org.jadapter.spring that takes advantages of the autowiring beans support. Documentation on this is already on the wiki along with a recent post about the feature.

AOP Support for Transparent Dependency Transformation

The coolest feature in this release (and perhaps the most useless :) is the possibility to weave the transformer registry around objects. This is similar to the hack I described in my last post and if anything is more brutal to the Java syntax.

The main idea is that any object that is subject to transformation is weaved with the registry and the result implements all interfaces that the object can be transformed to. Then it can be freely casted to any of those interfaces, although that cast would not be legal according to the rules of inheritance.

This makes most sense if you are using some kind of a factory to create your objects. Then it is simple to pass them through a Weaver to enable this feature. There are a few implementations of the weaver interface to allow fined grained control of which objects should be weaved. I also added a Spring BeanPostProcessor to automate this in a Spring app.

This feature is probably best explained with an example:

// Create a registry with two adapters Foo -> Bar and Bar -> Csv
TransitiveAdapterRegistry registry = new TransitiveAdapterRegistry(
        new JAdapter(FooBar.class),
        new JAdapter(BarCsv.class));

// Create a AOP weaver with access to the initalised registry
Weaver weaver = new RegistryWeaver(registry);                 

// Create a new object and weave it
Foo foo = new FooBean(2);
foo = weaver.weave(foo);

assertEquals(2, foo.foo());

// Cast the object to a different type,
// the transformation to bar is done on demand
Bar bar = (Bar) foo;
assertEquals(3, bar.bar());

// Combined transitivity and weaving to transform Foo -> Csv
Csv csv = (Csv)foo;
assertEquals("3", csv.csv());

A side effect of using weaving instead of dependency injection to access a registry instance in application code is that the client code will not depend on JAdapter on compile time. If you are using a framework to instantiate your objects than it will be easy to plug this in.

I have received blended feelings about abusing the language in this manner and am looking forward for more feedback on this. Personally I think it is neat and I like it. Besides, little hacks like this put all the fun into the project.

Java Syntax hacks using Generics and Proxies: Multiple Method Invocations

2008-10-08T22:34:00.003Z

When I first learned about Aspect-oriented Programming (AOP), I had a difficult time making up my mind if it was something that interested me or not. Then after working on two small projects using AspectJ I was sure that there are great benefits in using AOP. But will AspectJ become mainstream enough that the average programmer will rely on it?

My prediction that I was not going to see much of AspectJ after joining the workforce proved partially correct. Luckly I found out that people are using dynamic AOP without requiring more than the standard JDK.

Java has this powerful thing called dynamic proxy classes and instances, which are used primeraly in frameworks as far as I know. They can act as an replacement for more heavyweight AOP implementation such as AspectJ. I didn't know about their existence while hacking Java in College so it was a refreshing to learn that I can enjoy the benefits of AOP without asking anyone for permission to introduce new tools to the development environment, which AspecJ inevitable does.

Proxies are great for things such as transactional management, lazy loading, security, caching, and other common tasks that are preferred to be kept out of the application code. However there are other interesting thing to do with proxies. One such example are traits.

I have been playing with the JDK proxies in JAdapter where I am pushing the Java syntax – for the better or worse. The first example is just a simple hack to invoke a method on multiple objects. The latter is a lot more useful as it introduces a way to use dependency transformation transparently. I started writing this to introduce this but then decided to focus on the multiple method invocation trick. The plan is to expand this into a short series. I will go into details transparent dependency transformation when I release JAdapter 0.2

Multiple Invocations of a Method Hack

This is a very simple trick that really breaks the Java syntax. It uses generics and a proxy to pack an iteration of objects and a method invocation on each object into a single statement. This is probably easier to describe using an example. Lets say we have an implementation Counter of a simple interface Incrementer, which is used to increment things.

public interface Incrementer {
    public Incrementer inc();
}

public class Counter implements Incrementer {
    private int count = 0;
 
    public Counter inc() { 
        count++; 
        return this; 
    }
    public int count() { 
        return count; 
    }
}

Now, if we have a collection of counters and want to increment them all at the same time, then we could do it using a loop and one statement:

Incrementer[] counters = new Incrementer[]{c1, c2, c3};
for(Incrementer incrementer : counters) {
    incrementer.inc();    
}

I wrote a an Iterable implementation for JAdapter, named Query (suggestions for a better name are welcome!). While doing so, I hacked around with this idea and came up with the following alternative syntax:

Query<Incrementer> counters = Query.NEW(c1, c2, c3);
counters.each().inc();

The resulting state of the counter objects will be the same in both examples. The latter could of course also be written as a one-liner: Query.NEW(c1, c2, c3).each().inc();

Lets have a better look at what the hell is going on here. First, NEW is a simple static factory that creates a new Query<T> instance where T is Incrementer in this case. Yes I know that many would use another name than NEW for this. Perhaps createInstance? Well, a programmer I greatly admire showed my this style and I really like it. But that is not important here. The important part is the call to each().

Normally you would expect to see some kind of a function type passed to each to simulate some sort of a functional style. However, if you simply want to call a method that is already defined in the type you are iterating, writing a anonymous class for that would be an overkill. Instead each() returns a proxy of type T that fakes the syntax. Now we can call the proxy like we have a single instance of Incrementer, and the proxy will do the dirty work of iterating over each and perform the invocation.

This is just a simple example of neat little hacks that are possible with proxy objects and generics. It is up to you to judge if it pays off. Many will not like the syntax of the language being bent this much. However, if you are like me then it is simply a refreshing change from the usual verbose syntax.

Spring cleaning my side project

2008-10-01T18:37:00.002Z

It is still early fall over here but I am already doing spring cleaning. Well, actually I just wanted to write a little about the new support for Spring 2.5 configuration in JAdapter.

In my first post on JAdapter I mentioned how hairy the configuration was. Now that I am a couple of weeks from releasing version 0.2, I wanted to give a quick update on how much cleaner things are becoming.

The following example demonstrates the same configuration from my previous post. There are a few things to note here. First, there is a new registry implementation undir the org.jadapter.spring package. This implementation simply delegates to beans that are automatically injected using @Autowired. Here, CustomAdapter will be injected and made available as an adapter; the TransitiveAdapterRegistry will be injected as the registry implementation. Another feature is that you can simply list all POJO classes that can act as adapters in the new bean. They are then automatically handled using reflection.

<context:annotation-config />

<bean class="com.example.CustomAdapter" />

<bean class="org.jadapter.registry.TransitiveAdapterRegistry" />
        
<bean name="adapters" class="org.jadapter.spring.SpringAdapterRegistry" >
    <property name="adapterClasses">
        <list>
            <value>net.martinaspeli.blog.ReceiptPayment</value>
            <value>net.martinaspeli.blog.RansomPayment</value>
        </list>
    </property>
</bean>

The reason for injecting an actual registry implementation into the Spring registry is both to support multiple registry implementations without bloating the Spring package. And to support another feature that I have not yet written about (but is already in trunk). More on that soon. You can read more about Spring support on the wiki. I have also updated the JavaDoc for 0.2.

After I release the final version of 0.2, which will be in two weeks, I plan to slow down the development and focus on example applications of the framework and start working on another side project that will be heavily based this work. The reason for that is that it will be a lot about object trees and performing stuff on those object using Java interfaces, which the the objects may or may not implement.

JAdapter: Convention over Configuration

2008-09-26T18:10:00.005Z

As consumers of various frameworks, most of us know how dreadful it can be to write boilerplate configuration. This configuration can often be omitted when applying the princible of convention over configuration.

When writing JAdapter, I was constantly comparing it to the Zope Component Architecture (ZCA). The result is that I did not think much about explointing the fact that I was using static typing, while ZCA does not (Zope is a Python framework).

In Zope, you provide the type information in configuration. Given the following adapter (implementation omitted):

>>> class FooBar(object):
...     def __init__(self, foo):
...         self.foo = foo

This adapter could be configured in ZCML as follows to configure it to provide the Bar interface for anything that implements Foo:

<adapter
    factory="example.FooBar"
    provides="example.Bar"
    for="example.Foo"
    />

You could move the type properties to the adapter code, but you need to provide the information in one way or another. Here is the Python code (implementation omitted):

>>> class FooBar(object):
...     implements(Bar)
...     adapts(Foo)
...
...     def __init__(self, foo):
...         self.foo = foo

Without line 2 and 3, the ZCA would not be able to use the adapter since Python is dynamically typed. In JAdapter, I would write the same adapter in plain Java:

public class FooBar implements Bar {
    
    private Foo foo;
    
    public FooBar(Foo foo) {
        this.foo = foo;
    }

So how much configuration is needed to tell the runtime that this is an adapter Foo → Bar? The type of the interface in naturally given since the interface is part of the class declaration. The adaptee type is also available in the constructor argument. The only catch is that we follow this convention when writing adapters. But the benefit of skipping verbose boilerplate configuration is definitely worth it.

Automatic resolution of adapter types

When writing introduction the the 0.1 release of JAdapter I told myself that the amount of configuration was just too much. Especially using something as Spring to configure it (which is quite verbose). Version 0.2 will introduce an automatic resolution of the type parameters. In the current trunk, the following code will suffice to create a FooBar transformer as Foo → Bar:

 Transformer<Bar,Foo> fooBar = new JAdapter<Bar,Foo>(FooBar.class);

The transformer can now be used freely to get a Bar instance:

 Bar bar = fooBar.transform(someFooObject);
 
 // or using the registry
 registry.register(fooBar);
 bar = registry.transform(someFooObject, Bar.class);

As an example is Spring. This is a configuration for a single adapter in 0.1:

<bean class="org.jadapter.JAdapter">
 <property name="factory" value="net.martinaspeli.blog.ReceiptPayment" />
 <property name="to" value="net.martinaspeli.blog.Payment" />
 <property name="for" value="net.martinaspeli.blog.Receipt" />               
</bean>

Using the automatic configuration in version 0.2, the same adapter can be declared as follows:

<bean class="org.jadapter.JAdapter">
 <constructor-arg value="net.martinaspeli.blog.ReceiptPayment" />               
</bean>

This might not be much, but I am quite happy with it. It will help a lot when the number of adapters becomes significant.

Introducing JAdapter 0.1

2008-09-18T09:35:00.006Z

I have been working on and off for the last several months on a little project called JAdapter and version 0.1 is now available. The aim of the project is to implement what I like to call a Dependency Transformation framework, for – you guessed it – Java. It borrows a lot from the Zope Component Architecture and is similar to what Martin Aspeli describes as a Java Component Architecture. The code snippets below are adapted from his article.

Dependency Transformation

A dependency transformation is a technique based on the adapter pattern and is not invented here. You write adapters that by composition adapt one interface to another. Then in the client code, you declare the transformation you depend on. The framework then takes care of finding a suitable transformer (adapter) that meets the transformation dependency and keeps a registry of available transformers. It can be viewed as a graph between types, compared to traditional tree of object types. In the object tree, you can only transform (type cast) your objects up, while in the graph allows transformation between any types as long as there is a possible transformation path available.

Note that I both talk about transformers and adapters. When I refer to an adapter then I mean a class that follows the adapter pattern, while a transformer is more generic and is simply a function that takes an input and transforms it to something different. Something you could pass to a map function.

An Example

Suppose we have two unrelated interfaces, Receipt and Payment. Your client code has access to an instance of Receipt but requires to work with Payment. Using the Adapter Pattern, one could write a simple adapter from Receipt to Payment:

public class ReceiptPayment implements Payment {
    
    private Receipt receipt;
    
    public ReceiptPayment(Receipt receipt) {
        this.receipt = receipt;
    }
    
    public void pay() {
        int amountToPay = receipt.getAmount();
        ... // perform payment operation here
    }
}

The client code can then use this to explicitly transform an instance of Receipt to Payment:

    
    public void makePayment(Receipt receipt) {
        Payment payment = new ReceiptPayment(receipt);
        payment.pay();
    }

A disadvantage of this approach is that you are tightening your client code with the implementation of ReceiptPayment. This can be solved by injecting a transformer that handles the dependency:

    
    Transformer<Payment,Receipt> receiptPayment; // inject this
 
    public void makePayment(Receipt receipt) {
        Payment payment = receiptPayment.transform(receipt);
        payment.pay();
    }

Now you only depend an a Transformer, which can be configured at runtime. This is quite important when you would have different adapters for different runtime environments, as an added value, you can now mock it too.

If you need a lot of transformers, or that you don't know the type of the adaptee at compile time, then it might be better to inject a registry of transformers. This makes it easy resolve multiple dependencies at runtime without explicitly mapping them.

    
    AdapterRegistry transformers; // inject this 

    public void makePayment(Receipt receipt) {
        Payment payment = transformers.transform(receipt);
        payment.pay();
    }

A nice property of the the transformer graph is that it is transitive. This allows us to make syllogistic inferences to resolve transformation dependencies. Suppose we have a third interface, Tax, that is unrelated to the previously defined interfaces, but you have written an adapter for Payment → Tax. Then the original client code might look something like:

    
    public void calculateTax(Receipt receipt) {
        Tax tax = new TaxPayment(new ReceiptPayment(receipt));
        tax.vat();
    }

Now you are both explicitly declaring two implementation dependencies, and the composition path. This could be replaced by the following code:

     
    public void calculateTax(Receipt receipt) {
        Tax tax = transformers.transform(receipt, Tax.class);
        tax.vat();
    }

I am not quite sure if this use case will ever arise though. But is an interesting case nonetheless. Without it you can reach the same state by calling transform twice, first to Payment, and then to Tax. Doing so requires you to know at compile time the composition path.

Benefits

Besides the benefits of loose coupling mentioned above, and the added bonus of transitive composition. Martin Aspeli mentions three key advantages of this technique.

By factoring behaviour out into separate adapters, value objects (those that store persistent or transient state) are kept as simple as possible.

Adding new behaviour simply means adding new adapters. General behaviour can be generalised into general adapters. This avoids the need to modify existing classes to add new types of behaviour. In the case of Java, this is doubly important, since Java does not support multiple inheritance. Thus, generalisable behaviour that needs to apply to multiple objects cannot be "mixed into" concrete classes by inheriting from multiple base classes (in any case, this type of design leads to very large class hierarchies and is probably best avoided).

Related to this. You can get rid of a lot of your “Managers” that you usually need to inject into your client code to access a particular functionality, which might or might not need to be configured at runtime. I am not a big fan of multiple inheritance, but this touches the point of eliminating managers that are injected all over some codebases.

By using adapter lookups to generalise code, we gain a powerful method of re-use and customisation. Quite often, there will be one standard adapter that is registered for a very general object type. More specific adapters for more specific types (e.g. subclasses of the class that the general adapter was registered for) can be registered to provide specific behaviour, overriding the general implementation. The "client code" using the adapter is none the wiser.

This is very powerful when the client code is working on a tree of arbitrary types. Consider for example writing code that outputs an HTML representation of any given object, using special treatment to collections, maps, value objects, and such. Or if you need to retrieve an object from a repository as a specific interface. The repository could be for example an object database or a Java Content Repository.

Configuration

As always, you will need to configure the components to use them. There is no specific configuration machinery in JAdapter, but you should be able to use your favorite DI framework. If you are using Spring, then configuring an adapter registry is relatively simple, although verbose:

<bean id="transformers" class="org.jadapter.registry.TransitiveAdapterRegistry">
   <property name="adapters">
       <list> <!-- declare your adapters here -->
            <bean class="org.jadapter.JAdapter">
                <property name="factory" value="net.martinaspeli.blog.RansomPayment" />
                <property name="to" value="net.martinaspeli.blog.Payment" />
                <property name="for" value="net.martinaspeli.blog.Ransom" />                  
            </bean>
            <bean class="org.jadapter.JAdapter">
                <property name="factory" value="net.martinaspeli.blog.ReceiptPayment" />
                <property name="to" value="net.martinaspeli.blog.Payment" />
                <property name="for" value="net.martinaspeli.blog.Receipt" />               
            </bean>
            <bean class="com.example.CustomAdapter" />
       </list>
   </property>
</bean>

The example above is my current style of configuring adapters. Note that the next version will not require nearly as much configuration. But as I stated in my last post, it is better to release it sooner with fewer features than not releasing it at all. Version 0.2 will will simplify this a bit with automatic configuration of the to and from type information and possibly configuration using annotations.

Since I use Spring a lot, I am throwing in optional support for it. Such as auto-wiring, bean processors, and proxies. Implementing a custom XML Schema-based configuration is also interesting, but I will need to read up on that.

Of course it is also possible to configure the registry directly in Java. The bean definition above can be defined using the infamous new operator in plain Java, for example:

JAdapter ransomPaymentAdapter = 
    new JAdapter(RansomPayment.class)
        .to(Payment.class).from(Ransom.class);

JAdapter receiptPaymentAdapter = 
    new JAdapter(ReceiptPayment.class)
        .to(Payment.class).from(Receipt.class);

AdapterRegistry transformers = 
    new TransitiveAdapterRegistry(ransomPaymentAdapter, 
                                  receiptPaymentAdapter, 
                                  new CustomAdapter());

Try It

Here, I mainly touched on two classes in JAdapter, namely TransitiveAdapterRegistry and JAdapter. These are currently the most important components of the framework and are pretty much the only thing needed to get up and running with dependency transformation. The former provides the actually dependency lookup and composition of transformations. The latter is reflection based adapter. That is, it uses normal java classes that follow the adapter pattern to the Adapter interface. This is the interface used internally by the adapter registry.

I will go in more detail into each component that makes up the framework in separate postings. I hope others will find this useful. If you are interested then grab the 0.1 Version, and check the JavaDoc.

Throw Away those Features!

2008-09-07T12:30:00.004Z

So you got excited about some programming idea and spent countless hours of your free time, coding it into reality. Then you find yourself adding some code that you don't really need, at least not for the first release. But it sure is more fun coding away than getting that initial release out of the door.

Many advocates of Test Driven Development will tell you that they always write one test, then write the code that will make that test pass (along with the rest of the tests), and continue. And by the way, throw in some refactoring while you are at it. This approach may sound all good and valid, but it can just as easily go terribly wrong. I am not talking about problems because it can be hard to write the test first, or any variant of that argument. I am talking about when you don't know when to stop writing tests and get stuck in an infinite loop of writing and passing test after test.

This might not seem like a problem, especially in a corporate environment where you have a schedule to stick to, or in a larger community where there is a clear concensus of where the project should be going. But in a solo project setting, where you are your own boss and nobody tells you that they need you code yesterday! This is not always so simple.

If you find yourself adding a new test after test that each introduces a new feature without making a release, then you are probably doing it wrong. It might be time to stop for a moment and think, do I really need to add this code? Or should I perhaps start working on getting what I already have out of the door?

The problem is that as features are added early on, getting to a release state becomes a lot harder. Not to mention the increased amount of documentation that has to be written. You also have to worry about the level of maintenance your project will require.

I have been trying to justify it to myself whether I should remove features that I have implemented while working on a small solo project. It is also a question if it too late to shave off those extra features because someone might actually be using them already. From the top of my head, here are a few reasons I want to throw those features into the bin.

Less to document

This both applies to official documentation and other sources, such as blogs. If the project contains more than five important features in the first release, then you can't really write one post about the it. On the other hand if it only has 2-3 features, then it should fit nicely in a single post.

Less to learn

Since there are fewer features, new users will have easier time getting to know your project, which will probably attract more users who would be thrown off by a large stack of undocumented features. Developers might also get involved since entry barrier is still very low.

Less to maintain

The last thing you probably want is to ship some premature features that add little value to your project, but will require time for maintenance from you, and add unnecessary complexity to your code base. As soon as a user discovers one of those features and starts using it, you better be prepared to support it!

While it is difficult to create even a first implementation, it is even more difficult to maintain the level of commitment and arrive at a stable release. – Kirill Grouchnikov

I encourage anyone who is working on a hobby project to read Grouchnikov's blog series on Surviving A Hobby Open-Source Project.

Ship It

Instead of writing one test at a time and at some arbitrary time decide that you have enough features to ship. Try to write all the tests you think you need to ship that first release. See if you could describe them all in a single blog post. Writing that post before coding might actually not be a bad idea. Only then, start writing the code.

I am not saying that you shouldn't add more test while working on that first release. The only thing keep in mind is that those tests should never or rarely introduce new functionality but instead increase test coverage.

It is to be expected that you will get fresh ideas while working on the first set of features. It might feel natural to drop whatever you are doing and implement this new cool idea. It will only take five minutes right? Forget it. Just write the damn tests that capture the idea and add it somewhere to your backlog so you can get back to it after shipping your original idea. It was the idea that got you motivated to start the project in the first place. Right? Perhaps after the big “one point ooh” you will discover that this must have feature was actually a bad idea and you can simply throw it out of the backlog.

jQuery DatePicker and Selectbox

2008-05-25T20:09:00.013Z

I have recently been drinking the jQuery kool aid. One of my favorite plugins for it is the excellent Datepicker plugin, which I am using whenever I want to display a nice calendar to users.

Last week I needed it to work on a single selectbox that listed available dates but couldn't find any documentation for it. There are some examples of a datepicker for multiple selectboxes (day/month/year), but not when you only have a single one. So here is my attempt at it.

I am using the jQuery UI 1.5 beta release, so your milage may vary since the API has changed quite a bit lately.

The Markup

The example I am working with has the following structure:

<select id="date">
   <option>Select date</option>
   <option value="2008-05-01">May 1, 2008</option>
   <option value="2008-05-03">May 3, 2008</option>
   <option value="2008-05-05">May 5, 2008</option>
   <option value="2008-05-25">May 25, 2008</option>
</select>

Datepicker primarily works with input elements so you will need to add a hidden element for it. This is kind of essential anyways if you want to have separated display format for the dates because datepicker supports only one format for each instance.

I prefer to have the value as an ISO date string and then use more user friendly format that is visible so I tend to do this anywhere the UI is important. The extra element is as simple as:

<input id="datepicker" type="hidden"/>

DatePicker, Setting the Scene

We need to tell the datepicker which dates are available from the selectbox. For performance reasons, I have created a map of available dates, which the datepicker references to determine if a date is available or not.

$(document).ready(function() {

  var dates = {};
  $('#date option').slice(1).each(function() {
      var date  = $(this).val();
      var year  = date.substring(0, 4);
      var month = date.substring(5, 7) - 1;
      var day   = date.substring(8, 10);
      dates[new Date(year, month, day)] = true;
  });
  // ...

The datepicker can now be instantiated on the hidden element and made available through its button feature:

  $('#datepicker').datepicker({
      dateFormat: 'yy-mm-dd',
      buttonImage: 'calendar.png',
      buttonImageOnly: true,
      showOn: 'button',
      // ...

Restricting DatePicker to dates in the datepicker

I already created a map of available dates, we now need to connect that data to the datepicker. This is trivial with the beforeShowDay datepicker configuration option. We simply reference the dates map to determine if the date should be allowed or not.

      beforeShowDay: function(date) {
          return [dates[date], ''];
      },

Synching the two Elements on a Change

The selectbox needs to be updated immediately when a date is selected using the datepicker. It is not as important to update the datepicker value as we are only using that for display. This means that we can get away with only updating it when we need to display it.

Both cases can be solved using options in the datepicker object, we update the selecbox with onSelect and the datepicker with beforeShow. Since I am using the ISO format on both sides, it is simply a matter of synching the values.

      onSelect: function(date) {
          $('#date').val(date);
      },
      beforeShow: function() {
          $(this).val($('#date').val());
          return {};
      }

Demo

The Complete Script

$(document).ready(function() {

    var dates = {};
    $('#date option').slice(1).each(function() {
        var date  = $(this).val();
        var year  = date.substring(0, 4);
        var month = date.substring(5, 7) - 1;
        var day   = date.substring(8, 10);
        dates[new Date(year, month, day)] = true;
    });

    $('#datepicker').datepicker({
        dateFormat: 'yy-mm-dd',
        buttonImage: 'calendar.png',
        buttonImageOnly: true,
        showOn: 'button',
        onSelect: function(date) {
            $('#date').val(date);
        },
        beforeShowDay: function(date) {
            return [dates[date], ''];
        },
        beforeShow: function() {
            $(this).val($('#date').val());
            return {};
        }
    });
});

Use the Source, Mule!

2008-05-10T10:13:00.002Z

I recently attended developers and architecture courses for Mule, the open source enterprise service bus (ESB). Compared to the competing proprietary solutions that I have used, Mule is a blessing. The number of transports that it supports is astounding and it is really easy to wire services. Almost too easy in fact.

Here are a few examples of what I am looking forward to try out in Mule.

Embed Mule in existing applications

Mule is relatively lightweight and can either be run as a standalone instance, or embedded in other Java application. This means that you can include Mule in your webapp. The advantages of that are many. You can for example use it as the web service layer for all the components in the webapp, and expose the webapp’s API as a service without any code (generated or not).

Build new applications with Mule

Since it is incredibly easy to connect bunch of services together, you can basically create new ones by wiring existing ones together using message flow logic in the Mule configuration. I am quite found of modeling programs as message flows and channels and Mule seems to fit the bill.

Reuse all existing services and build new on top of them

Mule integrates well with Spring and you can reuse all your Spring beans as services in Mule. It also supports some other containers that I am not familiar with (it does not support Guice however).

Expose any data as services directly from the Mule configuration

It is easy to connect any data you have into Mule. For example, you can expose SQL statements as services directly from the Mule configuration via JDBC. Either as an outbound endpoint using SELECT, or inbound with INSERT or UPDATE. I believe that other SQL statements or possible but I haven’t seen any examples of it. But I am definitely trying this one out.

Once the service has been configured in Mule, it is simply a matter of configuring an endpoint for it of your choice, such as SOAP, JMS, Atom, FTP, or whatever protocol you want. It is relatively easy to write a custom transport if the protocol is not supported (working on one myself in fact).

My most anticipated GSOC 2008 projects

2008-04-30T18:16:00.000Z

These are my most anticipated projects of the summer 2008, in no particular order.

The Jython compiler

Python is the language I look most forward for using on the JVM. There are other cool languages such as Scala and Groovy, but there are simply too many Python applications I want to run on the JVM and all the fancy features of those languages can not compensate for them.

Django on Jython: Supporting Python Web App Frameworks on the JVM

There have been some efforts in making Django work on Jython already and this project seems to aim on a more than just Django, but Python webapps in general.

Improvement of Zope support on Jython

Don’t know what to say about this one, except that Zope on the JVM sounds like a wet dream. And perhaps is too good to be true. But starting small and do it on package-by-package basis will go a long way.

I don’t expect to see the ZODB running on a JVM any time soon though. However, there are other solutions in the Java world that could potentially substitute it.

These projects will hopefully make it easier to integrate Python in the enterprise, which will eventually make my job a lot more fun! Other than scripting, I am really excited about leveraging all the nice web frameworks that are written in Python (three of them are mentioned in this post). This is a blessing for me since I write a lot of Java web applications.

OCQL a Query Language for ZODB

ZODB is a cool database that persists Python objects. It is the default storage backend Zope based applications, such as Plone. This project aims to add querying capabilities to it. This might be the perfect alternative to ORMs by simply getting rid of the RDBMS if it is not really needed.

I have a couple of other object database systems that I am planning on evaluating for potential projects. Comparing ZODB to them will be interesting, but they seem to be more focused on querying while ZODB is more about navigation (traversing). Expect postings on my exploration into the object database world this summer.

Flint: a simple Grok-based CMS

Grok is a cool framework built on top of Zope 3. An application like Flint could very well be what is needed to expose the power of the Zope Component Architecture to the rest of the Python community and beyond. It also has the potential to be a great starting point for a custom lightweight CMS project as an alternative to the more heavyweight but excellent Plone CMS.

If everything above falls into place, could we be running Flint on the JVM? Probably not, but if the projects above will be a success, then we are getting something truly special.

We already have a WSGI support for Java, what we need is JDBC support for the Python ORM libraries and of course, more Jython compatible packages (whatever that means). Persisting objects from either Java or Python in the same object database sounds interesting as well.

WordPress Performance Projects [benchmarking, caching]

I don’t have much to say about this except that WordPress makes an awful lot of database queries to render a page and has no caching support built-in. Any improvements here are very much welcome.

JavaScript debugger for IE

If there is one thing I hate doing, it must be debuging JavaScript code on Internet Explorer. Yes there are some debuggers available and no they are nothing compared to Firebug. I am not sure how this project will help me, but the title is just so appealing!

Buildout Builder - An automated buildout configuration system.

Buildout is great way to manage file artifacts in projects and offer a nice and intuitive way to manage all your Python package dependencies, especially compared to what we have in the non-Python world. This is extremely valuable for both deployment and development. Not to mention that will be based on Grok!