I’ve been using Windows 7 on one of my machines for a while now, and I’m still finding nice new features which make the Windows experience more enjoyable. I am definitely sold on it. As the Linux zealots are keen to point out, it isn’t perfect, but then neither will the new Ubuntu be. I use and develop both open and closed source software and believe in using the right tool for the right job. The Vista experience is sufficiently different to XP (and there is no upgrade path) that the choice between replacing your OS with Ubuntu or Windows 7 becomes very real. Certainly I would argue there are pros and cons for both choices, and that simply accepting the latest Windows operating system because that’s what new computers come with is no longer necessary.
For home users who are just interested in surfing the internet, writing a few emails, chatting on msn and sharing their holiday photos Ubuntu becomes a very tempting proposition. The TCO of Ubuntu for these users will be far less than Windows 7; the initial training may be a little more extensive, but that will be offset by free licensing and no return visits to clear up the inevitable viruses and spyware that all Windows home computers end up with.
Businesses, gamers and Windows tinkerers are however much more likely to be better off with Windows 7. It’s fast, some users I’ve spoken to have described it as faster than XP (particularly in starting up and shutting down). It’s compatible, anything which runs on Vista will run on 7 – well nearly anything, and software authors will be keen to tell you they haven’t tested it yet. It has only a few different concepts to Vista, and Microsoft are advertising the new features on prime time national TV for us.
So although I am an open source advocate, I’m also an advocate of choosing the right tool for the right job. And although I may not admit this at my local LUG, Windows can be the right tool. I’m certainly looking forward to Ubuntu 9.10 though, and will be putting it on some machines as soon as I return from my vacation.
Drupal 6 has a problem with running a site on multiple domains. The files directory is typically set to /sites/$domain, which is fine until you start accessing a site using a different domain. The resulting mess depends upon which modules you are using to serve your images, but an example url that might be generated is /sites/example.org.uk/files/sites/example.com/files/1.jpg and this obviously does not exist in the file system.
If you’ve moved the site rather than want both domain names to be valid then it’s easy to fix
"UPDATE FILES SET filepath = REPLACE(filepath,'sites/example.com/files/','sites/example.co.uk/files/');"
However to get both working requires some jiggery pokery with symlinks. The exact urls generated by Drupal will depend upon the module you are using and the domains you are wanting to serve from, but ln -s is your friend. Imagecache is the worst offender I have come across so far, with symlinks needed for each size of image, however other modules (and themes) will handle things differently.
The Worth Way in Yorkshire is absolutely terribly managed. There I’ve said it. It’s not properly mapped, it’s been moved and even blocked off by farmers, signposts are missing and it uses the same colour signs as the Millenium Way which merges with it. The publicity on it dates back to 2005, and it feels somewhat abandoned. This is a real shame because it takes in some rather nice countryside and villages, and should be enjoyed by a lot more people (I met two other hikers on the entire route last week).
I’ve added what I can of the route to OpenStreetMap, and intend to re-walk the entire route with gps so I can produce a new map, but it needs more than I can give. It needs somebody to challenge the land owners who have re-routed or blocked paths and it needs the council to spend some money on adding signposts. Now that we’re members of the Keighley Town Centre Association we might have some weight in getting this lovely route some tlc.
The BBC News website has an article linking climate change to CO2 levels today. Their claim is that high levels of CO2 20 million years ago caused major climate change. This is problematic for two reasons: first of all if there was no industry 20 million years ago then increasing and decreasing levels of CO2 is natural. Secondly, if changing levels of CO2 isn’t natural then maybe it was the climate change that caused the increase in CO2 and not the other way round.
The global temperature has been increasing over the past 15 years, not decreasing. Whilst CO2 levels may cause climate change, we can only really expect it to change in one direction – it can’t do one thing 20 million years ago and then do something different now unless there are other factors.
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.