One of the great things about using Scala, is it’s a fantastic language for creating DSLs. When I really don’t like the way the code that solves a specific problem looks, I like to write the pseudo code that feels right, and then figure out how to make that work. With Scala, I have had a great deal of success in this approach. We started off defining a JSON generator DSL that looked like this:-

There was another case for jsonArray, which doesn’t involve having a field name, i.e. jsonArray { … }. Whilst attempting to find a way to implement the DSL that would satisfy this, we had to make a small compromise. The call jsonObject {…} and jsonObject(“fieldName”) {…} caused problems because the signatures of the DSL methods were indistinguishable when using them. The compromise we struck on was jsonObject() {…} and jsonObject(“fieldName”) {…}, i.e. just adding the empty parenthesis. This then is the resulting syntax, and the implementation can be found here.

This is a first cut, but as this library was introduced to solve a problem in our production app. It will be tweaked and maintained so any bugs or extra features will quickly get incorporated.

Well, I’ve written the code to effectively support the previously described testing api. It is currently part of the above project, and can be found here. It has already proved handy in adding a much needed functional test capability for Django REST models, which has already exposed a bug in the awkward to test rest_client code. As an example, here is the test:-

With the expanding usage of REST services, and a growing number of Python applications written against those services, this project is starting to gather pace again.

• It makes me more productive by removing boiler-plate code.
• There are many good libraries for Python which are very consistent, making it easy to produce complex applications with few lines of code.
• Meta programming techniques such as missing method and metaclasses make producing sophisticated frameworks easy.

These are all interesting points, but none of these things are the real reason I write Python code in preference to Java, Scala, Groovy or Ruby. The primary reason for me, is that I really enjoy writing Python applications. I think in a Pythonic way, so writing Python applications is intuitive and enjoyable. I rarely need to battle with the language to acheive what I want to do. A common question that gets asked is “What can Python do that you can’t do in Language X?”. The answer is usually “Nothing, provided you are prepared to write enough code, you can solve all the same problems. It’s just I enjoy writing Python, which means I am more engaged in solving the business problem, and therefore able to consistently get the job done faster, better, and with a greater level of satisfaction in the solution”.

I know this isn’t a scientific answer to the question, but writing software is a job done by people who aren’t mechanised robots. People need to be motivated in order to produce the best results and that includes being able to choose the tools they use based on what makes them happy. Recently it’s been my pleasure to spread a little Python love around my team mates. It’s been great to see the enthusiasm with which they have taken to using it, and the stunned awe when the see just how powerful this ‘Scripting Language’ really is. This has increased the motivation of the team, and as a result we are completing more work, to a higher standard, in a shorter time than we were previously while working in C# .NET

NOTE: I don’t recommend using maven with Scala on the Mac, because it just doesn’t play nicely. Don’t know why, but it’s broken to the point that I no longer even try to use Maven to build my scala code.

To resolve this, I’d like to add expectations of the stub http server in the same way as with defining mocks. The syntax would look something like this

So, over the next couple of weeks I’ll be putting this together, which should among other things allow me to improve the end to end testing story for djangoRESTModel.

At work we have a Django web application where the models are backed by a Java XML REST api. The application is read only, so there is no requirement to write back to the REST api.

We started with copying the data into a local DB, and using regular Django DB models, and we wanted something that would feel very similar, but use an XML REST backend. We wrote an xml_models library, which allowed us to map our models to the XML data, using a declarative style similar to the Django DB models. The library has been open sourced and can be found on sourceforge.

Here is a simple example:-

Suppose there was an API http://myaddressbook.com/addresses/{addressID} that returns the following XML

The model might be defined as

And using the finder method would be like this

That’s the basics. We are mapping much more complex relationships with collection fields, date fields and more. Take a look and let me know what you think.