Creating a dummy Debian package for Subversion (svn)

Since I've installed Subversion, I've been looking around for a good wiki and ticket management system so that I can get the whole 'development environment' setup on my home server.

I installed Wikipedia's MediaWiki at work, after our Instiki wiki came unstuck and left me with a whole load of nothing after it decided to stop writing archives to disk for about 5 weeks! MediaWiki is a little heavyweight for what I need, so I started to look around. I noticed on the Ruby on Rails website that they had a pretty simple ticket system, and after some investigation it turned out to the the open source Python-based Trac.

Trac also has a rather pretty Subversion repository browser so it seemed perfect for the small home projects that I want to develop.

I went to 'apt-get' Trac on my Debian Stable server, only to find that it wanted to install Subversion as a dependency even though I had a later version installed from source.

The Debian package management system works great so long as you don't install any applications from source, if you do it doesn't know they are installed and so will try to install over the top of your newer version.

What you need to do is create a 'dummy package' to fool the Debian package management system into thinking that it's installed a valid package. Here's how I made a Subversion package for my latest 'built from source' version 1.2.1 of Subversion.

First you need install the equivs package, this provides all the tools to be able to build Debian packages that apt-get & dpkg can understand and install.

apt-get install equivs

Now that equivs is installed, you need to generate the templates that are used to build the package. Run equivs-control and pass in the name of the package that you want to create. In my case I wanted to emulate the Subversion package that Trac wanted to install which was named 'subversion'.

equivs-control subversion

This creates a 'subversion' file in the directory that you ran the equivs-control command from. Edit this file as follows:

* Leave the top three lines:

Section: misc
Priority: optional
Standards-Version: 3.5.10

* Change the following lines: (note: the Subversion I installed was 1.2.1, hence the "Version: 1.2.1-1" value)

Package: subversion
Version: 1.2.1-1
Maintainer: Andrew Beacock <andrew@andrewbeacock.com>
Architecture: all
Description: A dummy Subversion package to fool Debian's package management system into thinking that the 'built from source' version is an official Debian package.

* Remove all these lines:

Pre-Depends: <packages>
Depends: <packages>
Recommends: <packages>
Suggests: <package>
Provides: <(virtual)package>
Copyright: <copyright file; defaults to GPL2>
Changelog: <changelog file; defaults to a generic changelog>
Readme: <README.Debian file; defaults to a generic one>
Extra-Files: <additional files for the doc directory, commaseperated>

Save the file, quit back to the console and then run the equivs-build command to build the package.

equivs-build subversion

As long as you've done everything right, it will start to generate all the install scripts that are required by Debian packages, and ends up creating an equivs directory (that can be safely deleted) and the package itself - subversion_1.2.1-1_all.deb.

Now install this package using dpkg as you have it locally and apt-get would get the wrong version from the internet.

dpkg -i subversion_1.2.1-1_all.deb

You now have Subversion registered in Debian's package management system. To prove it, run dpkg -l subversion, there should be "ii" to the left of the listing for "subversion". This means that you can now install Trac without it stomping over your existing 'latest version' of Subversion.

A future post will document the steps involved to build Trac from source, but using the Debian package management system to install all the dependant components...

Technorati Tags: , , , ,

Ruby to replace Java - or compliment it?

I've been singing Ruby's praises ever since I started researching the language a couple of years ago. I've not written much Ruby code, picked up the 1st pickaxe book, read it a couple of times, then the next year came round so I've now got the 2nd edition!

I've written a few Ruby 'scripts' (no objects or classes) and have been impressed with how quickly I have been able to get it to do my bidding compared to Java. One application running on Linux needed to read some data from a Postgresql database, generate a Windows Zip file then FTP it to a remote server. When I thought about coding this in Java I started to shiver, Java's strong point has never been it's ease to interact with the command line, and FTP libraries are not part of the java. or javax. packages.

Several people have asked "so are you saying that Java is rubbish and we should all move to Ruby?". My basic answer is "no, but I want to really get into a scripting language and Ruby seems OO enough for me to get into it fairly easily".

Dave Thomas (one of the Pragmatic Programmers) said it best recently when he said "not exclusively: you're likely to want to use Rails as well as Java." Dave has started a number of posts around this topic the first is titled "Is Ruby Better Than ...?".

Java and Ruby are similar in some respects and different in others, if I need to write some quick utility scripts or manipulate some text files then Ruby would be my choice. If I need to access some middleware message queues and fit into an existing application server infrastructure then Java would be the language of choice.

At the end of the day, it's all down to adding strings to your bow, sometimes the choice is just which strings to invest your time and effort in...

Technorati Tags: , , , ,

Feedback from yesterday's AgileNorth conference.

Note: This is a long post as I've tried to get down all my notes, please skip this post unless you really want to read all my view of the AgileNorth conference!



These are my notes from yesterday's AgileNorth conference held in Preston in the north west of the UK. It was a full day and to be honest, I was knackered! It's funny how listening and talking all day really tires you out. There were approximately 50 people, which seemed about right for the size of venue.

What is Agile? by Kevin Rutherford

The day started with introductions from Phran Ryder (chairman) and Katie Taylor (secretary) covering the format of the day, followed by the day's keynote from Kevin Rutherford, who ran his discussion as a number of agile iterations.

We all added 'requirements' (topics to potentially cover) to the board, then Kevin suggested a number of them that he would get through in the first 'iteration' (10 minute speaking block). It covered a whole host of topics, but two key factors jumped out at me:
* Measure and track the number of running, tested features completed per week (or month) so that you can track how well you are doing with some real 'hard and fast' data.
* Create an interface to management that gives them all the data that they need to do their job, but allows you to do XP within your team.

Fitting Agile Teams in a non Agile Organisation by Lindsay McEwan & Gavin Hope

This session was the main one that I was interested in when signing up for the conference and they didn't disappoint.

They started with a look at how to get a 'team' together that really gels as a team, noted that the environment is very important, they moved into a separate room from the rest of the development department and created their own workspace.

The whole team's work revolves around the 'task board', a large pin board where tasks and stories 'to do' were pinned on one side, and then moved to the 'done' side once completed. It gave a very easy way to see where everyone was up to, and what was outstanding. They have daily stand up meetings where the cards are moved so that everyone is aware of what is being worked on.

They have a 1-hour project retrospective at the end of each iteration (each iteration lasted 2 weeks) to review both technical and personal issues that had surfaced during that time. This allows the team to correct any problems early on before they become big issues. A recommended book was "Project Retrospectives: A Handbook for Team Reviews" by Norm Kerth.

Time management was driven by the task board, items are either to do or done, there is no "90% complete" concept. The daily stand up meeting includes task tracking progress. Only one task is worked on by a developer at any one time - this stops tasks backlogging with one person if they get stuck on a different task.

The whole team are involved in the planning meeting so that all parts of the team are aware of the requirements and features. The tasks are broken down into 2-4 hour lumps, this allows easier tracking and monitoring of the team's 'velocity'. A graph of the time spent delivering business value is derived from the completion of the task cards, this is then used to estimate the number of tasks the team can handle during the next iteration. They suggested that if you get someone who is hung up on the code in a perfectionist way - "the code's just not quite right..." then a good question to ask is "Who is the judge of quality?" - it could be the end user, the support team, etc. Maybe 'good enough' is ok in this situation.

They had major problems trying to implement the 'on-site customer' idea, it just didn't work for them. What was happening was that the customer was reporting a problem to sales, and they would report a solution to technical. What the customer got was usually not what they wanted. They are now trying to gain access to the real customer problems by putting their staff on placements at their customer sites.

They had problems initially with customer support requests. They were tracking the amount of time the requests where taking to resolve, this lead to support tasks being looked upon as "getting in the way of real work". Their solution to this was to add the support request as a regular task to the board, and then track how many support tasks were being completed each week. They then factored the average number of support tasks per iteration into the planning for subsequent iterations.

15% slack time was added to each iteration for continuous improvements and planning for the future. Recommended reading was "Slack" by Tom DeMarco and "Lean Software Development: An Agile Toolkit" by Mary & Tom Poppendieck.

Managing Agile Projects by Jim Sutton.

Jim's presentation focused on how and why his company needed to go agile and some of the difficulties faced when trying to do so. The title lead me to believe that it was going to be more 'down to earth' on how to manage the team on a day to day basis.

None the less it was a good presentation, here is a list of the items that I pulled from it:
* Break the cycle - do one thing VERY differently!
* Try the daily stand up meeting
* Have a "cut the crap" card that can be held up when discussions get too woolly
* Use 2 week iterations, monthly is just too long
* Sales and marketing departments are still very non-agile, this can be a problem

Refactoring by Ivan Moore & Duncan Pierce.

This was my 'developer' session of the day, where Ivan and Duncan along with the 20 (or so) audience performed a live refactoring of some very poorly written java code. Ivan was using Eclipse to edit the code, and was quite a wizard at using the refactoring tools on offer. It was mostly a discussion-led session with not a lot of things to note down but I learnt a lot about using the refactoring tools and how to spot code that was ripe for refactoring. Suggested reading was "Working Effectively with Legacy Code" by Michael Feathers and the "Refactoring Workbook" by Bill Wake.

All in all it was a fantastic day, and really re-energised me into 'the agile way'. Now I need to figure out how to introduce agile and XP into the company I work for...

Technorati Tags: , , , , , , , , , ,

Off to the AgileNorth conference tomorrow

I'm off to the AgileNorth conference tomorrow, which is "a conference for local technical and business staff who wish to learn and share their experiences of becoming and being agile."

It's a 1-day event in Preston in the north west of the UK covering a range of topics including "What Is Agile?", "Test Driven Development", and "Refactoring". I'm particularly looking forward to the "Fitting Agile Teams in a non Agile Organisation".

I'll let you know how it goes...

Technorati Tags: , , ,

Constants in CSS - it's like waiting for a bus

I'm more of a server-side programmer really, and don't deal that much in client-side stuff like CSS and JavaScript, but I try to keep an eye on what is going on in those areas as they tie so closely to the backend stuff.

I was reading the lunchroom blog a few weeks ago where Scott was talking about how he's modified Jim Weirich's Ruby Builder object to be able to express CSS files in Ruby so that you can implement things like CSS constants among other things.

Then a week later Eric Meyer posts about Shaun Inman's update to CSS-SSC. Which funnily enough is another way to achieve CSS constants (CSS-SSC stands for "Cascading Style Sheets Server-Side Constants")

It's just like London buses... ;)


Technorati Tags: , , , , , ,