# Upgrading to Redmine 1.4 on CentOS 5

Brief notes on upgrading redmine from 1.1.2 to 1.4 on CentOS 5

Recently we upgraded redmine from 1.1.2 to 1.4.2. It was an activity that I had planned for a long time, but as usual things get in the way of doing that. Redmine, perhaps ruby on rails makes that easy for you, has a very well documented path for upgrades so the upgrade itself didn’t take very long, about half an hour. Of course I had run through the process already on a different machine to make sure we weren’t going to hit any odd snags due to the platform / ruby versions or whatever.

# Project Management Tools

Why we settled on redmine as our project management tool

Our main development management tool is Redmine. It has been since December 2010. We tried a lot of tools before settling on redmine. It was the only one that we ended up going back to and using. If, after a month of trying to use something, you end up not using it, then either you’re too set in your ways, or the tool isn’t good enough. Our journey to settling on redmine as our web based project management tool is a long and chequered one, and it all started in 2010.

# Fixing your mercurial mistakes after the fact

Tidying up after yourself when you screw things up in mercurial

Our source code management tool of choice is Mercurial; which is a python based DVCS. We switched back in 2009 once we’d gotten fed up with CVS. There are still a few internal projects using CVS, but these days almost all the developers are using mercurial. People always ask why we never moved to subversion and generally my answer has always been because it’s not *significantly* better than CVS. Yes it is better, it might even be CVS done right (not that this is a good advertisement for subversion); but ultimately, I need to use it on the plane or during a proof of concept with no external network access and collaborative development has to take place.

# Setting up CentOS-6 Just So

How I setup CentOS 6

The infrastructure team that we have at Adaptris is great; but sometimes when they setup a new vm image for me, there’s some things that are not quite right. I guess it’s because I’m a very particular kind of guy when it comes to how machines are setup. I thought that I’d write about how the development machines are setup. They’re setup just so which means that I can get working on them straight away1.

1. By the time I’ve finished all of this I’m happy that I can install java/ant/maven on the machine and it’ll work to my satisfaction. ↩︎

Continue reading Setting up CentOS-6 Just So

# Metadata as Parameters to Stylesheets

How to pass parameters into a stylesheet when you’re using an adapter

I’m never really been all that interested in data manipulation; one of my stock phrases is it’s just data1. From an integration perspective I might never understand the business semantics around each field in your data file. The critical part of our work is to make sure that your data gets out of System A, and gets to System B in the right format. For me, the interesting part is always understanding the esoteric limitations or complexities around the communications protocol rather than the data formatting itself. This probably goes back to messing around with protocol analyzers and gender benders (not that kind; the kind that you fit to an RS232 port) when I first started.

1. According to company lore there are quite a number of features and behaviours that are ascribed to my personality; like all things that other people say about you, I can’t quite see it myself. Still I have found myself saying It’s just data on more than one occasion. ↩︎

Powered by Hydejack v6.6.1