Freelance Developer

Yes you can use Eclipse/PyDev as a graphical debugging tool with Python. The trick is to set up your Python environment correctly within Eclipse. When that is done you can harness the power of setting breakpoints and drawing out information of the debugger by stepping through your code.

The path

I use virtualenv when running my Django projects. This way I can set up different Django projects on my development machine and not have them clash when they have different dependencies. I.e. for reise.no I  set up virtualenv like this:

virtualenv /Users/alex/workspace/reise_noENV/

On the command line I go into this virtual environment by issuing

source /Users/alex/workspace/reise_noENV/bin/activate

In Eclipse you'll also need to set up python path to point to this environment.

After setting up your python environment we can head on over to running tests in debug mode.

Creating a debug runner

Okay, running tests in commandline mode is as easy as doing "python manage.py test". So taking that into regard we'll create a debug runner for Eclipse that does this.

Choose "Run->Debug Configurations" and we'll set up a PyDev Django runner:

From this screenshot you'll see that we have created a PyDev Django configuration. I'll name it "reise_no test views". Now you can click the "Arguments" tab and fill in "Program arguments" with what you on the command line would enter after "python manage.py". So here we'll enter "test".

Running

You can now run this configuration either via the Debug button you can find on your right in the current dialog. Or you'll find it under the bug icon. Click the small arrow next to the bug and a dropdown list with all your debug configurations should appear.

So add a couple of breakpoints in your code by right-clicking in the margin of the line where you want to break, and run your test via the debug runner. When you hit a breakpoint Eclipse should now go into Debug View.

Debug view

In the Debug View you can now step through your code with the debugger controls. The two controls you'll use the most are

• Step into (F5): Go one level deeper to see whats going on in there.
• Step over (F6): Go to the next line.

You'll also have a list of the current variables that are set. Use these to figure out whats wrong with your code.

Okay, thats it. Now get rid of all those print statements you've been so shamefully using and start using the tools at your disposal :)

I've fallen in love with #NoSQL. So I'm doing my storage with MongoDB for an application I'm working on. But since I'm also a testing zealot I had to figure out how to test my app properly, with fixtures and all.

There's already some good code out there that will help you develop your Django app using MongoDB - namely MongoKit and django-mongokit.

MongoKit is a great way to make a structure for your document. Complete with validation and all. And by combining it with django-mongokit you also get automatic test database create/drop.

models.py:

from django_mongokit.document import DjangoDocument
from django_mongokit import connection

class Country(DjangoDocument):
    structure = {
        'iso3': unicode,
        'iso2': unicode,
        'name': unicode,
    }

    required_fields = ['iso3', 'iso2', 'name']
    use_dot_notation = True

connection.register([Country])

tests.py

from django_mongokit import get_database 

from django.test import TestCase
from models import *
class ModelsTest(TestCase):
    db = get_database()
    def test_should_save_country(self):
        country = self.db.countries.Country()
        country.iso2 = u'GB'
        country.iso3 = u'GBR'
        country.name = u'UNITED KINGDOM'

        country.save()

        self.assertTrue(self.db.countries.find())

But the fun doesn't stop there. You can also easily add some fixtures by creating a python file to hold some dicts for you:

countries.py:

countries = [
{"iso2" : "AF", "iso3" : "AFG", "name" : "AFGHANISTAN" },
{"iso2" : "AL", "iso3" : "ALB", "name" : "ALBANIA" },
]

from countries import countries

class ModelsTest(TestCase):
    def setUp(self):
        db = get_database()
        db.countries.insert(countries)

    def tearDown(self):
        db = get_database()
        db.drop_collection('countries')

Greenhopper, an agile project management plugin for JIRA has been acquired by Atlassian.

This is a great plugin that creates broad agile capabilities to JIRA - which means that agile teams can use JIRA not only as a bug tracker, but also as a planning board for their sprints. It got some great reporting tools complete with burndown charts.

We implemented Greenhopper for the teams at NHST Media Group, and it really helped the execution of our agile processes

We use IRC as our main communication channel here at the office. And after setting up Bamboo as our continuous integration server I wanted to hook it up to our channel so I could get some automatic flaming of those build-breakers.

Its been some years since I last wrote anything for IRC. And the only thing I had ever programmed in before was eggdrop. But I wanted something leaner - and preferably written in python. I ended up with Kibot. It seemed to have everything I needed - namely timer support.

Bamboo have several RSS feeds you can tap into. I wanted to use the feed for all failed builds. Have the bot iterate over these items (I used feedparser for this) and send a message to a channel.

I finally ended up with Murphy. A chap who will give full notice of your shortcomings as a programmer.

You can grab the source and play around with it yourself if you like.

Now I just need to plug in an insult generator. Anyone have any ideas where I can find a particularily nasty dictionary?

I wanted a tool to write acceptance tests with. Something easy to set up, and of course, flexible. What gets churned out here at my company are webapps, so I had this in mind when I went ahead looking for the right tool. After browsing around I came to the conclusion that the tools with most drive behind them was FIT and Selenium. Here follows my encounter with them.

Read the rest of this entry »

In lieu of my task of setting up a testing workbench at our development office I've been checking out various integration servers. Focusing on Bamboo, Continuum and Hudson. What follows is an informal look on various continuous integration servers.

Read the rest of this entry »

At work I've been set at the task to evaluate and come up with a continous integration strategy. Right now we have a mish-mash of an development structure trying to utilize agile development, and using scrum to do our project management. However, test-driven development is not our native tongue, and the tools we are using aren't helping our productivity.

First of all we are looking for tools to keep our issues on track. The company I work for is a media company, delivering a range of newspapers, both digital and paper. And as a media company you have to roll with the waves, because changes come quickly in a ad-driven environment. There is a myriad of feature requests from other departments in our company. And we, as the development department have to sort out all of these and assign work effort to them. There are shared packages across domains, and there are of course domain centered ones. Things change all the time, and we need to get our QA up and running so we can handle this. So this article will in effect become a sort of lucid discussion over digital vs post-it planning boards.

Read the rest of this entry »