Posts

Biari Workbench Technology Stack

/0 Comments/in , , /by

Over the course of developing our Workbench solution we’ve adopted a powerful set of interconnecting components. It’s worth mentioning what these are and how they fit together.

Almost all the components of the stack are free and/or open source. We want to be as platform independent as possible and not get too locked in to one technology paradigm. This means that as much as possible, parts should be as “hot swappable” as possible – which also helps encourage strong componentisation. Using components with mature and open/standardised interfaces is very necessary when you’re crossing language boundaries (most notably, Javascript-Python and Python-C++) and client/server boundaries; otherwise you risk re-inventing the wheel. Ideally each component we use should also still be in active development (in the IT world – with the odd highly venerable exception – if software is not growing and evolving, it’s usually either dying, already in it’s death throes, or extinct).

There’s an art to using the right tool for the job, and we’ve made mistakes. We over-used Mako (see Loki’s blog post) and also originally used a slightly inferior lib for the C++ xmlrpc back end; both these mis-steps were fairly easily rectified. Arguably, we probably still use too much C++ and not enough Python – the C++ line count dwarfs the Python line count by a considerable margin. One last interesting point is that, at the moment, we’re still eschewing use of an ORM (Object Relational Mapping layer – such as SQL Alchemy) – time will tell whether that is a good idea or not.

Client:

JavaScript
 – client-side browser language

jQuery
 – JavaScript library for event handling and more

Cloudmade
 – OSM map provider/server

 

Data Interchange:

JSON – JavaScript Object Notation

XML – eXtensible Markup Language

Mathematical Engines:

Mostly in C++ using STL

CppUnit
– C++ library for unit testing

OGR
 – map data library, part of GDAL – used to read map data

Libxmlrpc-c
 – C++ back end for XMLRPC – used by a running process to communicate with the front end via Python

 

Server:

Python
– language

CherryPy
 – Python-based web app framework

PostgreSQL
 – open source RDBMS

PsycoPg2
 – database adaptor for PostgreSQL/Python

XmlRPCLib
 – XML RPC (used to communicate with some of the engines)

Mako
 – Python template library

Repoze
 – Zope/WSGI Python middleware (for authentication)

 

 

The Wonders of Python

/3 Comments/in , /by

I recently wrote a little code generator in Python that takes in a schema file in XML format and expands out specially marked up tags inside C++ code. It was my first real industrial strength use of Python and (for this C++ veteran at least) I was amazed at how much I could accomplish in just 300 lines of code. In particular I liked:

  • Not having to compile!
  • List comprehensions
  • String slicing and dicing
  • Returning multiple arguments from a function
  • Some really nice constructs:
return “True” if (self.Type not in self.VariableTypes) else “False”
This one sure does flow like natural language.

Dynamic typing sometimes feels like a free for all, but I’ll gladly pay that price for the many powerful features it enables. I sure am writing “self” a lot though 🙂

I think the real epiphany moment was realising that there is essentially no real complexity inherent in the language – this is very liberating compared to C++ where you have to constantly steer clear of C++’s many dark corners (about which entire books have been written, e.g. C++ Gotchas by Stephen Dewhurst). Programming really does become less of a struggle.

A somewhat tangential link musing over Python vs C++ in the context of unit testing is this blog post, which describes approaching building a Sudoku solver. Those interested in the Sudoku-solving ability of Python should also be sure to check out this impressive presentation on AI, puzzles, and the use of ‘itertools’ in Python.