Async Web Application and Concept Based Architecture?

I've been brainstorming about maximum efficiency, performance, and scalability in regards to web application frameworks; none of them really seem up to the task. After reading a stackoverflow.com post about ZeroMQ (www.zeromq.org), it got me thinking about distribution of specific tasks or concepts to "mini-apps" and how that could be done.

The following mindmap shows how I've broken up a typical web application into its component concepts.

By using a technology like ZeroMQ, each concept could exchange data loosely with another. For example, the Web Application could send a message requesting an SEO header and the Tracking Concept could do something with that message and trigger a Google Analytics event, the Monitoring Concept could intercept the Google Analytics event and log it, then the Reporting Concept could ask the Monitoring Concept about its latest log and process a report. All this could happen asynchronously and in the background where even the Web Application doesn't know everything that's going on.

This idea is completely language and location agnostic. ZeroMQ can connect nearly any language "mini-app" to any other language. Let's say you have a legacy Java application and your current team of developers knows python or ruby better. Your developers could wrap the functions you want accessed in the Java application with ZeroMQ and connect using python or ruby. Also, lets say you want to leverage the processing power of many distributed computers across the United States, located in multiple colo facilities. You could run mini-apps in all the locations and as long as they have a network connection, they can talk to each other.

Imaging using a message queue to build an interface between a C#.NET 4.0 application maintained by an outside vendor using Lua or python without worrying about dlls or COM wrappers.

I am going to explore this idea a little further this weekend. Maybe there'll be a new GitHub project started using this idea... maybe...

Clean Code: A Handbook of Agile Software Craftsmanship

Bravo to the authors of Clean Code! You have written an amazing and stimulating book; at least for this coder. I've passed it on to a colleague who, after only a day, is in love with not just Clean Code, but reading itself.

To anyone who actually reads this blog, if you're a coder get this book. It will make you question how you code and make you more critical of your own code; this is a good thing. It has brought new creativity and stability to my code.

Git-SVN Bliss

So my dev team likes and knows Subversion. I like and know Git. Can they exist together? Sure!

Using git-svn, I can use git locally while they use the bloated bastard that SVN is. I can make smaller commits, push and pull between my home and work machines, and send all my commits at once to the SVN repo on our server. All while using the merging awesomeness that git has.

How easy is it to use git-svn? Extremely simple.

git svn clone http://your-svn-repo-url reponame

That sets up the repo. How to do 'svn up' and merge? git svn rebase. How to push your commits to SVN? git svn dcommit. How to change branches/tags? git reset --hard remotes/branchname. Before you reset --hard, either commit and push or stash your changes, they will get overwritten as normal.

So I get the bliss that is git, my team gets to use what they're familiar with; win-win!

Django and Templating, is it Zen?

So Django uses a template language I don't like and I don't feel like modifying Django to make it use one I like. What do I do?

First of all, why am I using Django? Because it organizes and handles my data the way I want it to. Because it is extensible and I can turn off features I don't need to use.

So what do I do?

Why not have Django output standard XML instead of HTML? I can use XML with just about anything. I can test it, validate it, parse it, hell I can do anything with XML. So here's my solution, have Django output XML using my custom namespaces and write WSGI middleware to transform the XML into HTML.

The templating language I want to use is Genshi. Its templates can be validated and tested independently of the data, big pluses for me and my team. I can write wrappers for its API and Django's internals so there is good separation there. If we decided to move to CherryPy instead of Django, all we would need to do is connect our wrapper to the API; all our custom code would be unchanged.

So here I am, on the ragged edge, Django in one hand, Genshi in the other, tying them together without tying them together... How Zen of me...