Alice Kærast

Whenever I come to test a new programming language, my application of choice is a simple in/out board.  The data storage is simple enough to not (usually) require particularly advanced database functionality, and there’s some level of network communications happening to share the data.

Today I developed this application in PHP-GTK2 with a CouchDB backend, neither of which I had used before and so most of the time spend developing was learning the intricacies of the two.  And I have to say that PHP-GTK2 is not something I plan on using again, whilst CouchDB definitely is.

The problems with PHP-GTK2 started before I began programming, php5-gtk2 is not available in the standard Ubuntu repositories and so getting a PHP-GTK2 application used on Ubuntu machines would not be easy.  You need to either compile it yourself or add a third-party repository, neither of which you want to do just to test some new software.  And even once it is installed you then need to edit php.ini.

Moving on, the documentation for PHP-GTK2 is fairly non-existent and so simple tasks like reading values of text boxes was problematic and displaying a table of data is something I gave up on.  Now I’m starting to understand the peculiarities it’s becoming an awful lot easier to use, and it is the first Linux gui-based development environment I’ve used so I’ve little to compare it to.

CouchDB in comparison was incredibly easy to get going with.  Aptitude install couchdb was all I needed to have a locally running server, then with the right PHP libraries (unfortunately not in aptitude) I could access databases in just a few lines of code.  It definitely helped to have heard Lorna Jane speak on working with web services recently, but even so CouchDB is really simple up until you need to start using Views.  They’re not quite so easy in that they involve some JSON and Javascript, but a short time spent reading the wiki or watching somebody create a view will set you going in the right direction.

So after an afternoon of mostly learning and a little coding I’m left with some code to set your in/out status and to view the in/out status of everybody else.  I’ll be implementing a C# version of this at some point soon both in order to say I’ve implemented something useful in C# and to have a working version for some clients we’re currently building a network for.  I then want to play with CouchDB replication and get Cobol talking CouchDB.

Finally, @couchdb on twitter is responsive and definitely worth following if you’re working with CouchDB.

Any worthwhile software is not just developed, it is also used and should have at least some level of governance.  The application lifecycle involves all three of these areas, and they all need to be considered when managing the software.  This post will mostly discuss processes rather than software.

There are a number of documented processes that can be used in software development such as Agile, Scrum, Kanban and Continuous Integration.  We won’t go into these in any detail as they are documented elsewhere and most opensource development teams just build their own processes.

It is vital that the project’s scope and progress is well documented.  It should be possible to track work items, look at task listings and get reports on time usage.  This is the absolute basics that any open source project should have, more corporate development teams should spend more time on time tracking and produce burndown and velocity reports (which may also be possible for some open source teams).  Shareholders shouldn’t have to ask a developer to find out the status of a project, it should all be documented.

If teams are physically working together, daily standup meetings can be a great idea.  These should address just three issues, what did we do yesterday, what are we doing today, and what’s stopping us from doing that? These meetings aren’t always suitable for every development team’s style, but some variation of them should be considered for implementation.

The process for developing the code should be considered before any programming happens.  This should include things like branching strategies and what is required before code is allowed into the software.  Branching strategies are discussed on the codeplex website amongst other places, requirements for code acceptance aren’t often talked about and will vary.  The most important thing is to not break the build, doing so will delay everybody, and so stopping people from commiting code which fails to compile (and other basic tests) is top priority.  Doing smoketesting, ensuring checkins are commented and linking checkins to jobs are other good ideas.  If people do want to checkin code which isn’t entirely working (for review or to keep safe) they should use personal repositories.