Freelance Developer

After attending Kent Becks talk on JavaZone I fell into a discussion with a fellow programmer about Becks claim that on one day deploys you have to get rid of standup meetings (its about 53 minutes in).

The fellow argued that we should get rid of the standup meetings all together, regardless of iteration length. However. I think this is missing the purpose of the daily standup - to get all shareholders in the know.

You need a daily standup meeting if your iteration is a week or longer. The business model might have changed and there is usually a misunderstanding about the requirements or two. Also it's kinda handy to know about the progress on the project for all people involved. These are just some of the things that crop up under a daily standup.

However, when going to daily deploy, or even hourly deploy we just created ourselves a new information channel. The product itself.

We get instant feedback about the features that were implemented by all the users of the product. Either coming in over the phone, email or by tracking statistics.

So yeah, there is a solution for all the programmers that are grudging the daily standup, or all those other meetings: daily deploys.

Jeg var på Startup Weekend Oslo i helga. Startup Weekend er en internasjonal happening - en helg for entrepenørskap og nettverksbygging.

Kort fortalt fungerer det ved at flere av deltakerne har en idé til et produkt som de pitcher til massene. I første runde stemmer resten av deltakerne på hvilken pitch de synes høres mest spennende ut. Runde 2 krever litt mer commitment - da velger du ut hvilket team du ønsker å melde deg med det målet å utvikle et produkt i løpet av ei helg. Dette genererer flere team med personer fra ulike bakgrunner - programmerer, økonomer, markedsfolk osv.

Pitchen

Jeg hadde selv pitchet en idé - "Lag din egen avis". En idé som fikk god mottakelse, og et team begynte å samle seg rundt meg.

Resultatet av flere runder med utskifting av folk, tvil og håp og omorganisering av idéen hadde vi på lørdag formiddag spisset den til å bli "Lag din egen avis direkte sendt til din Kindle hver dag".

Arbeidet

@eivindsc begynte på et design. Jeg begynte så smått å programmere på løsningen for å se om det ville fungere teknisk, og @waionline, som vår medieviter, begynte å famle etter et godt navn. NewzUp var født. Og vi gikk live med en webside ca kl 19.00 på lørdag - 24t etter at idéen var pitchet. Websiden inneholdt kun en flott forside som skulle fungere som en tunnell til signup til vår epostliste fram til vi hadde en beta av løsningen klar. Takk til Kristian C. Berge for valg av en effektiv tekst på signup formen.

Vi begynte så å undersøke hvordan vi kunne få interesse for vårt produkt. Vi forsøkte å spre ordet via Twitter, Facebook, venner og forum.

Vår erfaring er at vi ikke fikk den responsen vi hadde forventet via sosiale medier som twitter og facebook. Forklaringen her tror jeg er at disse mediene ikke nødvendigvis fungerer så godt som reklame, men mer som en dialog i etterkant av en lansering. Et medium for å diskutere produktet i bruk - ikke for å spamme. Det er nok brukerne av disse mediene blitt alt for vant til.

Vår største gruppe av interessenter kom fra forum som hadde Kindle som topic. Og her var interessen ganske stor - med en ganske stor signup til vårt nyhetsbrev - 30% conversion rate. Og det uten å ha et produkt ferdig.

Konklusjon

Så min konklusjon er at man kjapt kan sjekke om man har en god idé til et produkt med ganske minimal investering. Design en flott forside med en signup til en lukket beta. Bruk så litt tid til å lete etter forum for å lage posts der som kan generere trafikk. Pluss twitter og en facebook page, for å supplere og at folk lettere kan gi deg tilbakemelding.

Får du en god conversion rate så er det større sjanse for at noen faktisk er interessert i produktet ditt - før du begynner å investere mye tid og penger i utviklere.

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 »