I have been working on a .NET based application using MVVM. All I can say is:  .NET seems like a very uncomfortable straitjacket to me.

So, in my spare time, I dream of making my escape. This time, I am playing with Node.js.  I won’t say much about it right now, except to say that I am playing with the idea of developing my own little library to make node code easier to write and maintain.

Code readability has become a big commitment for me. I work with so much code that is virtually unmaintainable and unreadable. It offends me. I do not mean to offend or unfairly criticize anybody that I have worked with, but I have grown frustrated by the fact that programmers do not know how to write clean, beautiful and elegant code. Bad names, bad functions, and poor architecture abound.

I like node, but the first thing I notice is that the code can get ugly pretty fast. Today, I am playing with tamejs, which makes it easier to write clean asynchronous code.  For now, I am calling my library GumMachine. More about that later.

Our current project uses the Prism framework. Only one member of our team can claim to be extremely versatile using this framework – the promise is that it allows developers to build applications that are easier to maintain.

Some members of the team are on a learning curve, but it seems to be a challenge for them. I experience the same thing a year ago on another project that was using Model-View-Presenter. In theory, the benefits are clear. In practice, not so clear yet. I find that I spend a lot of time learning and/or teaching, and I wonder what it will be like when we add new or different developers to the team.

I get tired of type errors in .NET – I have felt for a long time that the compiler is trying to protect me from making errors I would never make. But, I do not have have anything coherent to say about that right now. I just want to cite an interesting article that states that developers are more productive using Django than they are using .NET.

I have nothing to add – just want to say: I am feeling less productive in .NET than I used to. I like Python – I used it on a project over the summer. It felt great to deliver working code every day. Is it just me?

While I was there, Terry French, team leader of Canfor’s e-business effort,  expressed an opinion. I am paraphrasing after years have passed – if I do not get it right, I hope Terry will forgive me: “You code as if JavaScript were a programming language.  It is not. It’s a scripting language. It’s great for providing simple form interactions, and validating fields on submit. That’s it.”

If this blog were a trashy daytime TV talkshow, it would be one of those look-at-me-now shows. You know the kind: people who were unpopular in high school, but who have made good, confront their tormentors. Terry was a great guy to work with, but on behalf of the much maligned computer language, JavaScript, I say: look at me now!

Server side JavaScript is making a comeback.  But, wait, there’s more.  JavaScript programmers now get to deal with sophisticated concepts such as currying, callbacks, closures, array comprehensions, and test driven development in JavaScript.

And then there are those lovely libraries: JQuery, Mootools, and YUI, just to name a few. JavaScript has come a long way. What do you think of JavaScript now, Terry.

If you are interested in Javascript, check out Douglas Crockford’s videos on JavaScript at Yahoo Video.

So far, in tutorials I wrote in November of last year, we have seen that Jython allows us to write Python code that uses Java libraries, such as DB40. I altered the standard DB4O Formula One tutorial using Jython instead of Java, and showed that we can persist and retrieve objects using this technology.

I also mentioned that Django, a Python based web application framework, also runs on Jython.

Which leads us to this entry, where I will start thinking and tinkering to find a way to use DB4O with Django/Jython rather than a relational database.

I am doing this for fun, not for profit. I am not an expert with any of the technologies I am using. I stand in awe of the very talented open source programmers who precede me. I hope to learn as much as I hope to teach and share what I know, or think I know.

Persisting Objects:

In my previous example, I created Plain Old Java Objects (Pojos), and created a JAR. I used the classes in the JAR to create the objects I persisted using DB4O. I have since decided that this is not desirable. I think this creates a barrier to Python programmers who want to use Django, Python and DB4O togther.

Therefore, I have resolved to persist Python classes by providing the means to automagically inspect these classes and generate the JAR files. I shared these thoughts over a month ago.

Before writing any code, I just want to reflect on the task at hand. Let’s gather our assumptions.

• For every Python data type, there is a corresponding Java data type.
• A “simple” object is based on a class that contains primitive types only.
• A complex object contains other objects, or collections of objects.
• We may need to make two passes to persist objects – first simple objects, and then complex.
• A class contains an implementation as well as data, and we want to persist both.
• If we change the definition of a class in our project, we need to think about what happens to our previously stored objects.
• Our Jython classes must inherit from a single class only, or we will not be able to produce an equivalent Java class.

In Django, we define models, and then use a command (python manage.py syncdb) to generate the corresponding database. The database is created automagically, based on the settings in the settings file (settings.py). The model is able to perform basic operations to create, read, update and delete objects (CRUD).

We want our DB4O objects to behave in the same way – as much as possible, we do not want to violate the expectations of Django programmers who have used Django with relational databases.

In my next entry, I will try to write code that creates a Java class based on a Jython class and saves it in a file. I will keep it simple to start, and the code will evolve as we go.

Our first model will be simple – a class with a few attributes of various types. The output will be a class files – we will not worry about creating the JAR just yet.

Once we have produced a simple class file, we will produce class that make two passes and resolve inheritance issues as well as contained objects that inherit from previously defined classes.

Code to come in a day or two.

If you like what Java has to offer in terms of class libraries, but you like the Python language and its idioms, then Jython is the best of both worlds.

To prepare for my next installments on Jython, Django and DB4O, read about introspection in Python.

These seven habits for developing secure applications target PHP developers, but they constitute good advice for you, even if you are working in another language. Take heed.

There should be two steps to plugging DB4O into Django. First, we should be able to store settings in the settings.py file to specify where and how we will be storing our objects. The second step should be to create and use our models almost exactly as we would in a regular Django application. It should be that easy.

Editing Settings

It is not my goal to duplicate information you can get elsewhere. To find out how to set up a Django project, and to understand the files that are created for you, see the following tutorials.

In this entry, we are going to look at how to use the setting file in Django to store settings for DB4O. You can store anything in the settings file you like, and you can store these settings in separate settings files named prodsettings.py, devsettings.py etc. These settings are easy to retrieve from views and models.

We are going to make the following assumptions in our example: we only have one settings file, and it is called settings.py. Also, we are persisting objects to a file, and we are not using an object server.

A cllient/server mode is available in DB4O, and we will have to provide for it later. (DB4O client/server mode is covered in Chapter 8 of the book, The Definitive Guide to db4o. The chapter about client/server mode is available for free, if you are curious.)

To create settings, find your settings file, called settings.py, and add values. To see what entries look like, see below:

	# Django settings for mysite project.

	DEBUG = True
	TEMPLATE_DEBUG = DEBUG

	ADMINS = (
	    # ('Your Name', 'your_email@domain.com'),
	)

	MANAGERS = ADMINS

	DATABASE_ENGINE = ''
	DATABASE_NAME = '/path/to/file.db4o'
	DATABASE_USER = ''     # Not used with db4o in file mode.
	DATABASE_PASSWORD = '' # Not used with db4o in file mode.
	DATABASE_HOST = ''     # Not used with db4o in file mode.

	# Local time zone for this installation. Choices can be found here:
	# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
	# although not all choices may be available on all operating systems.
	# If running in a Windows environment this must be set to the same as your
	# system time zone.
	TIME_ZONE = 'America/Chicago'

	# Language code for this installation. All choices can be found here:
	# http://www.i18nguy.com/unicode/language-identifiers.html
	LANGUAGE_CODE = 'en-us'

        .  .  .  .  .  .  .

For our purposes, DATABASE_NAME will be the name of the file used by DB4O to persist objects. If you have read the DB4O documentation, you will know that you also have the option of running a server, in which case we could also use the DATABASE_HOST and DATABASE_PORT settings.

We also have the option of creating any settings we want to help us manage our application’s behavior. Django’s convention is to use capital letters for settings and to separate words with underscores.

At this point, we have enough information to find and connect to our DB4O file and we have stored it in the settings file. These settings will be used by our models to create objects and manage them. Our models will be written in such a way as to hide DB4O specific details from programmers. In my next installment, I will think about how to create a model for us to use with DB4O running in Django/Jython.

My thinking is that I will create my models in Jython, but I will create a command line script to create plain old Java objects (POJOs) and place them in a jar for us. I am lazy, and I always use Eclipse to create my jars for me. I expect to face some challenges at the command line, but I am up for it.

Therefore, the steps will be:

1. Create models in a file called models.py.
2. Run a command line command to generate a jar that contains classes for the the Java objects we want to persist. This jar will need to be in Jython’s classpath when the application runs. Corresponds to python manage.py syncdb for regular Django models.
3. Build views, and use Django just as you would to create any other Django application.

The only difference will be in the behavior of the models, but our goal will be not to violate too many expectations. Regular Django models subclass django.db.models.Model, but ours will subclass DB4OModel, a class we will create. Our DB4O should resemble Django models as much as possible.

In my next installment, let’s look at DB4OModel. What does it need to look like?

Unfortunately, we computer programmers are cursed by their own understanding of complexity. In fact, non-programmers often think complexity is a fundamental measure of our skill. The truth is that complexity is easier to achieve than simplicity. Simplicity is the Holy Grail of any framework or programming language.

I aspire to developing code that clearly and simply expresses my intentions. Simplicity is in the eye of the beholder, of course. Often, one paints oneself into a corner and then simplicity goes out the window. However, we am starting from scratch here, so let’s be hopeful.

My site stats indicate that few people have paid attention to the articles I posted by Dhananjay Nene. As I continue working with DB4O, I hope you get a chance to read these articles, especially the code examples.

The Project

For anyone who is jumping in late, the latest version of Jython, a version of Python that has been implement on the JVM, supports Django, a framework similar to Ruby on Rails. I want to demonstrate how to build a website, using Django to manage controllers and views, but I want to manage my models using DB4O.

Since I started writing about DB4O, my site has been getting visitors from about 50 different countries. But, there are few visitors from my own country, Canada. I find that interesting.

This Week

Django lets you replace parts of the framework very easily. In fact, I am quickly coming to appreciate this flexibility when I compare Django to other frameworks. Django does not force you to use its templating system, nor does it for you to use its data models. This is the flexibility we want to exploit to get DB4O working happily with Dajngo running on Jython.

This week, I want to concentrate on hiding DB40 from programmers who want to use DB4O to persist objects while using Django/Jython. The objects should save themselves, and the details should be administered from a central file. This is where I hope to get the most help from Jython as opposed to Java.

A Small Task

While I do this work, if anybody is interested in helping out, here is a task. I have managed to install Nginx on a server, and I have Django under Nginx running using FastCGI and regular Python, not Jython. To do this, I had to install Flup. My question is: can we install Flup under Jython? I would be happy to chat with anybody who either knows the answer, or is willing to investigate.

Otherwise, we will have to find another way – we could run Django in a servlet, and we could perhaps use Jetty. Any other options?

Please accept this link as my next installment. Dhananjay Nene reflects on the differences between Java and Python, and how he feels more productive using Python. He also reflects on how duck typing affects design.

Dhananjay says nothing I would not have said, and his statements have more authority than mine: he has definitely spent more time writing Java than I have. In my day job, I write C#. My current project requires me to write VB using version 1.1 of the .NET framework – yuck! (Oh well, as my wife says, momma needs a new pair of shoes.)

Also, some of you will be think about Jython performance. Performance is not everything, but if that is what you care about, then Dhananjay Nene has written this excellent article to help you understand where Jython stands compared to other languages and implementations, including Ruby. (Be sure to note that Python produces the fewest lines of code.)