It has been a "gung-ho" week here at a Hive, as we have pushed Colony into the ranks of Ruby on Rails, Django and similar rapid web application development frameworks.

Colony is a modularity framework, and as such, it promotes well-designed modular applications. Modular applications are normally of a large scale nature, or at least they intend to be as such, or else they needn't be modular in the first place. Due to this focus, even though we aim for simplicity, promoting rapid development wasn't exactly a top priority.

Roughly two weeks ago, after performing a demonstration of the Colony framework and the Omni platform service we're building on it, we were asked if Colony was useful as a productivity tool, in order to develop better applications in less time, and how fast we could make an application with the functionality of a specific pre-existing invoicing application. After saying we had to think it through, we went back to the drawing board.

We checked the application out and it didn't seem that complex, it could be easily done with any of the many already existing web application frameworks. But why not Colony? Just because it was built to create quality modular applications in a fair amount of time, not being able to use it for quick prototyping didn't seem to make sense. In order to push the framework further, instead of doing some math on how long we would take to make the application and probably end up being overly optimistic in our estimations, we build the whole damn thing just to be sure.

That's right, we built a Software-as-a-Service invoicing application in Colony in little more than one week (without burning the midnight oil!). It's a beta of a pre-alpha version for sure, but from here onward, its basically bug fixing (we're probably aware of most bugs by now, just have to put in the time to fix them), and usability and design improvements. The whole thing, which we branded Take the Bill just for kicks, included:

• Both application and visual design.
• All the CRUD (create, remove, update, delete) normally associated with most information systems, with this one not being an exception.
• Both regular and single sign-on authentication with OpenID, Twitter or Facebook.
• PDF report generation for invoices and others.
• Application interface and logic glued together with Ajax, for a smoother and faster user experience.
• Facebook-style full-text searching, giving the user a single search box where to look for any entity in the application, like a customer or an invoice, using any keyword related to it and without losing context.

To do this, we had to depart from the traditional way we built web applications in Colony until now. Our primary way of doing web applications was to have a Python implementation of Colony running on the server-side with all the plugins necessary to support the application's logic and deployment, which roughly meant having Object-relational-mapping, HTTP server and application logic plugins.

When the user accessed the Colony instance's HTTP server by typing the web application's URL in the browser, Colony would serve its Javascript implementation, opening up a way to provide modularity on the client-side. From here onward, the server would send all the required plugins to the browser and it would execute them in its Javascript Virtual Machine, which in the end had the effect of rendering the whole web application.

To achieve the level of modularity we usually targeted for, we didn't provide the client-side visual and logic code in the web plugin itself, but added yet another useful level of indirection by partitioning this code into a Model, a View, a Controller, and a Presentation Model, in a fashion similar to the traditional MVC design pattern, and wrap these parts in a concept we call an MVC Module.

MVC Modules are managed on the client-side by a MVC Manager, which provides lifecycle management in a manner as similar as possible to the Colony specification, but with all the particular twists required to provide modularity in visual components. Finally, in the Module's View, we would then implement the user interface using Colony Web UI, our own Javascript widget library.

This way of doing things is architecturally sound, and it's the best solution in the long run, but it's still painfully slow to develop in, as we end up only breaking it even in terms of development time by being able to avoid a lot of bugs that would come from a more ad-hoc messy approach. We have ideas on how to cut this time shorter, but they're still pending implementation.

Long story short, we could have never implemented this application in this time frame with this previous approach without overdosing on caffeine, so we took a different route this time.

No need for modularity on the client-side, so no Colony implementation on the browser. Modularity on the server-side was enough, so we threw the whole Javascript stack to the side this time... leaving only some jQuery wizardry in the plate.

Separation of concerns was made possible on the server-side due our lightweight MVC server-side framework plugins. This was enough to separate logic, static content, dynamic content and visual components, and therefore more than enough to make the whole party.

In the end, Colony is now more all-purpose than ever, which means more power to the people :). Also, we now have a prototype of a new Software-as-a-Service which can easily be shaped into a consumer-level reliable service if we decide to go in that direction, which we can use as another trophy in our showcase regardless.