Neural Advance

Since my last post I’ve spent some time looking at all the options available to Django developers. There are a vast array of different approaches one can take and the frameworks included in the core distribution are pretty solid and well documented.

I am aware of the Pinax project which offers lots of already written Django modules but I checked fairly recently and they were still behind the Django releases by quite a margin. Whilst the project looks good and I will certainly be keeping an eye on it, I don’t think I would make use of it in a serious project. Especially considering some of the changes in Django 1.2 are so good.

One element of Django that I overlooked when initially going through the documentation was the generic views feature. At first glance this seems like either a redundant feature or one that is better used as a small prototyping feature but after closer inspection it is obvious that this is an extremely powerful tool. The fact that you can delegate the entire view code to the main Django distribution not only simplifies your application but also reduces the number of potential bugs that your application contains.

Simply put any page that either displays a list of objects of a certain model type or a single object of a certain model type is ripe for use with the generic page view feature. Thus all you need to do is implement a template and that will handle how the view is displayed, all the correct data will automatically be passed to the template for you.

The next important tool to talk about is the built in comment framework. This simplifies the process of allowing users to post comment against articles and the like. The first time I used Django I actually wrote a simple blog application that implemented this feature itself but while it was a little more flexible the comment framework is stable, well documented and maintained by more developers. Any failings of the comment framework are going to be offset by the increased time spent fixing bugs in your own implementation and possibly a poor design in the first place.

The only complaint I have is the somewhat simplistic moderation system that is currently in place. It does the trick, but is not exactly a killer feature.

The final thing I want to talk about is the cache framework and memcached. I was impressed when I saw that the cache framework included not only a site wide setting but one which allowed caching on a per view basis. This could potentially allow you some interesting possibilities to optimise certain parts of your site say during a Slashdot stampede while the rest of the site remains untouched. My only concern would be that the control does not extend to the object level as far as I can see. It certainly allows you access to a low level cache API which allows the caching of data when you need it but it would be nicer to have something to automatically cache an object given a certain set of parameters.

Anyway this has been my first post reflecting my initial exploration of the framework. I’m keen to keep going as Django really seems the perfect mix of simplicity and flexibility. Stay tuned for more information in the coming weeks.

For the last couple of weeks I have been using Django to build a website I have been meaning to work on for quite some time. I thought I would post some of my impressions of the web framework as a new user to it in the hope that someone finds it useful. I’ll save the reasons why I chose Python and Django for another post.

The first thing that I noticed was the conceptual simplicity of the Django framework. I have become accustomed to frameworks which are ridiculously complicated compared to the goal that they are actually trying to achieve. So complex in fact that instead of looking good, the authors just end up looking stupid for getting so caught up in themselves. Java and C# frameworks seem to be the worst offenders when it comes to this phenomenon.

Setting up views and mapping URLs to those views is also extremely easy and the code that then loads a template from within said view is not going to be more than a couple of line (unless you are passing a ridiculous number of variables to the template system). This enables you to setup some complex views with a bare minimum of code. Another winning feature in my mind is the ease of producing JSON output. Whilst this is a feature of the Python standard library, querying the database and then immediately parsing it into JSON format for consumption by clients or indeed your own Javascript code on your website enables you to create complex web services with the bare minimum of fuss.

One of the features I need most when it comes to web frameworks is an easy way develop the application. Some web development tools require some rather complex setup to test on your own development server but I have found Django to be amazingly simple on this front. One technique I use is to set it up to use an SQLite 3 database on the local machine and test there whilst in the process of actual development and then transfer everything to the development server, change the database settings to a PostgreSQL database server, sync the database and then test the code to make sure that everything works as expected. This has lead to a much faster and easier to manage development cycle for me as I do not have to have my development server running (for PostgreSQL and Apache) in order to test the website. Instead I simply rely on the integrated development server provided by the manage.py script.

The integration of Markdown within the Django framework also allows you to let users create rich text in comments, forum posts and messages to one another which will certainly be appreciated by them. The only slight annoyance I have with it is that you can not limit the allowed markdown syntax which means that users can post comments in a header one style which potentially ruins your SEO for a given page.

Django’s project management features are pretty good too. I tend to use BBEdit on Mac OS X for my web app development and using that applications project management along with the separation of different parts of the web application by Django ensures that you never get overwhelmed by a bunch of random files that you need to remember their purpose. This makes it easy to develop modular parts of your site (a comment system for instance) independently of the parts which will actually make use of the comment system.

Web services, as I have said earlier, are the bread and butter of Django. It is rare nowadays for any serious website to only have web browser clients. Most offer some form of integration with desktop and mobile clients.

Overall I’m highly impressed with both Django and Python as a language. As this is the first real project that I have used it in it has been an eye opener. The Python standard library complements Django perfectly and being able to use the wealth of third party Python libraries available makes just about any conceivable task that you may have easy.

So what are you waiting for? Try it out. If you have any questions leave a comment and I’ll get back to you ASAP.

Note:

I started writing this article using Django 1.1.1 but since then Django 1.2 has been released. I have not had time to test the new release properly but some of the new additions certainly look good and a couple of small issues I had have been fixed. So upgrade if you can.

Updated: After a little bit more careful study of the AVR libc library I realised that you can just make use of the macros it contains in order to access ports etc without having any ugly defines.

I struggled to get up to speed with creating my first assembly program for my AVR device. The problem is that the tutorials and information available either target C for the AVR GCC tool chain (doesn’t help me much as I want to use assembly) or target assembly but using another assembler. There does not seem to be any specific information that I could get to work. I hope that this article will help if you find yourself in the same position.

So the first thing you need to do is build your GCC tool chain: here are some instructions. Once that is done you should be all ready to get started.

First things first, I am assuming you’ll be using avr-libc to make use of all the defines which it sets for you (register names etc), gcc, gdb and avrdude (at a minimum).

First things first I tend to define the device I am using at the top of the source file just in case. Then we need to include the AVR libc file which gives us the nice names for ports etc.

#ifndef __AVR_ATmega168__
#define __AVR_ATmega168__
#endif

#include <avr/io.h>

We include the AVR libc io.h header file so that we can use the libc defines to access the relevant ports by name rather than having to use their real address or having to define them ourselves.

Now we move on to the actual assembly program. At first I was stuck because the linker complained that no main method was declared. I found this somewhat perplexing until I remembered that you need to declare a main method using the .global statement. So don’t forget to have a section defined with a .global main.

     rjmp Init

Init:

     ser r16
     out _SFR_IO_ADDR(DDRB), r16
     out _SFR_IO_ADDR(DDRD), r16

     clr r16

     out _SFR_IO_ADDR(PORTB), r16
     out _SFR_IO_ADDR(PORTD), r16

     .global main

main: 

     sbi _SFR_IO_ADDR(PORTB), 0
     rjmp main

The above code is simply meant to turn an LED on and was (very slightly) adapted from the “AVR: An Introductory Course” book.

It is vital that you save this file with an extension of .S (that is a capital S) as that is what tells GCC to run it through the assembler.

We will compile it with the following command:

avr-gcc ledon.S -mmcu=atmega168 -Os -g -o ledon.out

you will need to substitute the atmega168 part with the correct device that you are using. Failure to do so will result in a program compiled for the wrong chip.

We then need to create a hex file from the output which we can then upload to our device using AVRdude. Use this command:

avr-objcopy -O ihex ledon.out ledon.hex

You can find out how to upload it to the device here.

And there you have it. Debugging it seems somewhat more complex if you don’t have a JTAG (such as the Arduino, I’ll need to look into getting something like the AVR Dragon before I can use AVaRICE and GDB together).

Before you start you must already have the Apple Developer Tools installed. The latest version of which can be downloaded from http://developer.apple.com/mac/ (registration required).

GNU Binutils:

cd <binutils-folder>

make install

GCC:

Make sure to download MPFR, MPC and GMP first and place then in folders (with the same name and in lower case) in the root of the GCC source directory. They will automatically be compiled along with GCC itself.

cd <gcc-folder>

make install

GDB:

cd <gdb-folder>

make install

AVaRICE:

cd <avarice-folder>

make install

References:

Building and Installing the GNU Toolchain

The following is the command that should be used for uploading a program to an Arduino Duemilanove (with an ATmega168 chip).

avrdude -c arduino -p m168 -P usb -U flash:w:<filename>

replace <filename> with the hex file you wish to upload to the board. This assumes that you want to write a file to the flash memory. You can of course verify or read from different portions of memory depending on your chip but I’ll leave you to figure that out from the AVRdude manual.

Another small note for myself here.

In order to compile for AVR devices it is essential that you define which AVR you are targeting on the command line with your version of GCC. Chances are you will be targeting an ATmega168 (use the -mmcu=atmega168 command line switch) as that seems to be the most prevalent hobby chip. It should also be noted that it is even more important when compiling code for embedded devices to use the -Wall command line option.

Also for future use the avr/delay.h file is now util/delay.h (which gets me every time).

This is primarily a note to myself so I don’t forget in the future or file away my notes into my filing system (aka the rubbish bin) and lose them.

You can use the checkinstall command like so:

sudo checkinstall

instead of the more traditional:

sudo make install

when installing self compiled packages. This will allow the Ubuntu packaging system to keep track of what was installed and allows easy removal in the future if you decide that you want to get rid of that particular item.

More information can be found in the Ubuntu Documentation:

Ubuntu CheckInstall

First of all I have to apologise for the diversion away from technology but this a subject that I feel strongly about.

The general attitudes that I see expressed constantly on the internet abhors me. People seem to regard those who have had a bad break in life with disgust. I even saw one person state that they did not want their donated organs “to be given to vagrants”. Let me be quite clear, there is very little between you and them. If you lose your job and fail to find another one (a very real problem in todays climate) and lose your house due to not being able to keep up with your mortgage payments will lead you into the same position.

Simple I hear you say, just get another job. Aha! But there is the flaw in your thinking! It is a requirement to have a permanent address in order to get employment. No address = no employment. No employment = No money = No address. Catch-22.

So you think you could crash a friends house while you get yourself back on your feet? You would be surprised at how many so called friends will leave you standing in your hour of need.

If you are one of those people who regard people in this unfortunate situation in such a manner, you can rest assured that I count you as the biggest problem in society today. The hatred, violence and unlawfulness that pervades the popular media is down to you and your divisive attitudes. You, who most likely identify as a conservative christian, who should be holding up your ideals for others to follow such as “do unto others as you would have others do unto you”, yet you don’t. You sicken me. Your weak kneed cowardly acts of hatred towards those who are in a vulnerable situation is the complete opposite of the ideals you supposedly hold. You have no right to call yourself a christian, or indeed a member of any right thinking religious or social movement.

I don’t think that you are of any extra worth to society than these unfortunate people, in fact I think you are worthless. Your attitudes help no one and hurt far more people. I am ashamed to be associated with you by nationality or race.

I’ll probably be accused of being a hippy or being unrealistic but realism in terms of social structure is merely a result of consensus in society.

In my previous blog post I was somewhat scathing about design patterns in general that try and abstract complexity away from the programmer by providing a consistent interface from which they can work.

The problem I have with this is not so much the design pattern itself but the fact that numerous people spend countless hours on message boards and blogs discussing the relevant pros and cons of each design pattern. Most of the well established and oft used design patterns are actually just simple common sense. I have regularly found that what I was doing was actually a well established design pattern without even hearing about it previously.

If programmers follow some very basic rules such as not exposing data to parts of the program that have no need for it, reducing the number of network and / or inter-process calls made, reducing or eliminating the number of external dependencies (either external libraries or functions from unrelated parts of the code base), consistent naming conventions and making sure that an applications implement is as simple as possible (if it is a choice between a simple implementation or adding excess code to implement a so called design pattern then go with the simple implementation every time).

People get far too hung up on “proper” coding conventions when all you really need to do is strive to minimise the amount of code that you write. Less is most definitely more when it comes to programming.

The majority of design patterns are rubbish and this is shown by the uptake rate that they achieve so how do you decide if you should follow a given design pattern? If when you are designing an application you feel that it naturally follows a popular design pattern then that is fine but if you try and force an application to use a design pattern that it does not naturally follow in the hopes of producing code that is more respected amongst the software engineering community then just stop and think. Forcing something will always just result in a mass of bad code or kludges as you try and shoehorn your application to fit into the tight constraints often imposed by design patterns. Most of which are nothing more than recommendations.

I imagine that the majority of programmers follow design patterns without even realising it. Why? Because of the ultimate design pattern which I simply call “common sense”.

It has occurred to me recently that the current trends in programming and related subjects have been to push a model of “non-understanding” to the programmer. It seems strange that in a field where understanding is paramount that this approach has gathered so much steam.

Half the problem seems to stem from the idea that abstractions are easier to understand than what is really happening under the surface. Yet this somewhat simplistic idea fails to take account of the rather convoluted abstractions that are in place in computer science at the moment and the general failure of most in a knowledgeable position to be able to explain each abstraction with any level of clarity.

This can be better shown by the number of design patterns that have started to pervade the programming scene (and the object orientated programming scene in particular seems to be most at risk from abstraction madness). Most of these so called design patterns do nothing more than put common sense down into an incomprehensible mass of badly written explanation which hides the real simplicity of the programming task at hand from the programmer. Perhaps it is a case of programmers with not much to do? Or maybe they stemmed from people hunting around for a thesis topic?

In the past languages such as C were incredibly simple. They had an extremely small number of keywords and provided very little to the programmer in order to hide the complexity of the program. As time went on more and more languages started to implement abstractions, Objective-C and C with Classes (later to be renamed to C++) are two that come to mind. These languages took the simplicity of C and added in abstractions to hide some of the complexity that programmers had to deal with when they used C, such as having to deal with data directly rather than manipulating objects which controlled the data that they needed to perform operations. But by removing the simplicity of the C programming language and hiding the complexity in the language itself they effectively banished the programmer from a fuller understanding of programming concepts.

C does offer its own abstractions but they are “thin” abstractions in the sense that they are much more computer related in conception which is a subject that the vast majority of programmers are already intimately familiar with. For instance pointers are a great example. They abstract away the concept of memory addresses in a very thin and syntactically clean manner which allows programmers to express what they want with very little to obscure the meaning of the code. One only needs to step through some C code and some Objective-C code with a debugger to see the huge difference in complexity between the two. The difference being that with C the complexity is exactly where it should be. With the programmer.