Welcome to the last entry of this blog. No I am not quitting, I am just moving. I just installed a new blog software framework. I was starting to dislike the way to interact and I wanted something that contained more out of the box. I am in the middle of moving to wordpress software. There is a very good reason to do this. I had found a great tool on the mac called MarsEdit. And again this could not be used with serendipity. I hope I did make a good choice. Since there is a lot of information in the old blog, I did not take this blog offline. It will stay to exist, but I will not make changes there anymore.
I hope to see you at the new version of the blog (check the page at http://www.gridshore.nl). You can attach you feedreader to the following url: feed://www.gridshore.nl/feed/
For a project I did a while ago we were thinking about using a branch for each developer while working on large changes/additions. Why, you ask? Well I'll try to explain, believe me I know there are alternatives but think about it before you judge.
We want to deliver version 3.0 of our application but we also want to continue creating some new usecases. Since we use test driven development, we create a test, implement functionality and run the test. After this we want to check in the stuff and let the integration test run by our continuous build. One possible obvious solution could be to use a branche for the 3.0 release and continuo working on the head.
This all sounds clear, we use subversion as an scm (Source Control Management) system. I do have one problem though. The repository is on a server of a friend of mine, I need to use an scm which I cannot use everywhere due to firewall settings. Therefore I cannot checkin code, which makes I cannot separate the different features I implement.
Last week I listened to the javaposse podcast. There was an item about distributed scm. I got interested and desided to investigate further. I had a look at Mercurial and I am still curious. I copied the following piece of text from their wiki: A distributed SCM tool is designed to support a model in which each Repository is loosely coupled to many others. Each Repository contains a complete set of metadata describing one or more projects. These repositories may be located almost anywhere. Individual developers only need access to their own repositories, not to a central one, in order to Commit changes.
Distributed SCMs provide mechanisms for propagating changes between repositories.
I installed the stuff (very easy, good manual, only 2.5 Mb or so download). There is a nice tutorial giving you the basics of using mercurial.
I am not convinced I need a distributed scm. I like the idea of having a local repository. I think this can help you when working in a gridshore project. I want to have a better look at a good workflow for such a system. How are you going to configure your continuous integration? The first thing I did was looking for a mercurial maven scm plugin. There is a very current thread in jira about maven and mercurial. I want to start an experiment with this, so if you are reading this and you have experience or good articles please post a comment or send an email.
Lots of conventionally-managed software projects do not include reliable execution by deadline, or are on budget, or to all features of the specification; it's a rare `managed' project that meets even one of these goals, let alone all three. Those projects do not appear to be market conform when it comes to cost, and those projects misses most of the time the ability to adapt to changes in technology and economic context during the project lifetime, either; the open-source community has proven far more effective on that score.
I was wondering if James Dobson statements could be backed up with our Gridshore thinking which is based upon the Open-Source community process and it can in my opinion.
Freddie van Rijswijk is manager Custom Software Development (J2EE & Web). His main interest is improving people performance and to make their and his life better by looking for ways to be better prepared for the job (education, coaching) and to avoid unnessary traveling. He's doing this by encourage Continuous Improvement by coaching and education and by applying agile and lean programming principles. The Open-Source Community Model of working his it's main inspiration.