Archive for April 2007

You should write blogs


YOU should write blogs.

Even if nobody reads them, you should write them. It’s become pretty clear to me that blogging is a source of both innovation and clarity. I have many of my best ideas and insights while blogging. Struggling to express things that you’re thinking or feeling helps you understand them better.


Quote of the day


C++: an octopus made by nailing extra legs to a dog.
(Steve Taylor).

When C++ is your hammer, everything starts to look like your thumb.
(Unknown author).

I guess somebody got pretty fustrated with good ole C++ ­čÖé

Time to leave CVS ?


A friend sent me link two days ago making me aware that Mozilla decided to change the source code control system (= SCCS) they use. When such large and important project as Mozilla moves ahead and changes something so basic and fundamental to development as the SCCS, there must be good reason behind it. What was even more interesting was the system selected: no, it was not Subversion, but something much less established – Mercurial. Actually, until they selected it I was barely aware of its existence.

For many years, the synonym for Version Control was CVS. At least in the open source area and really large projects, CVS was the SCCS. Then things started to change and today if you look around in large open source projects, you will see that CVS and Subversion probably still lead but several really large projects are using very different tools e.g. Linux kernel is using  Git.

So – is it time to review our technology toolkit in such basic tool as source code control ? Writing is on the wall – in one of the few remaining computer magazines in Chapters I glanced over today (forgot the name, something Linux related) – was a review of the current free version control systems. The article was comparing and evaluating RCS, CVS, Subversion, GIT, Bazaar, Monotone. In their evaluation the best marks were assigned to Subversion – it got 9/10 points. Mainly because ecosystem, support, documentation, user base and add-on/tools support. The next runner up was one of the new kids on the block – distributed version control system (DVCS) named Bazaar. Good old CVS ended up with 6 points and granddaddy RCS with 3/10.

Among the new tools, two important new trends are visible: new approaches to workflow by using distributed and decentralized VCS (= DVCS) rather than central server based and shift of the implementation platform from traditional very low level languages (C) and low level static languages (C++, Java) to dynamic and interpreted scripting languages.

Using dynamic, high level languages for the SCCS is natural result of increasing computing power of hardware – which makes speed and memory limitations disappear – as well as new, more complex usage scenarios which need more complicated software to address it. The dynamic languages such as Python or Ruby also have excellent support for networking and support most of communication protocols right out of the box and allow inherent portability between all supported platforms. This was often an issue for older systems written in C/C++. Bazaar – for example – is written in Python and can therefore runs on almost any platform.The shift towards decentralized and distributed systems is a logical continuation of the trend that started with abandoning the explicit (reserved) check-out mode of work. Anybody remembers the joys of Visual SourceSafe and issues when your colleague left for two weeks vacations and left checked-out few critical files ? In the systems using reserved checkout, every programmer had read-only copy of the code and could edit only files explicitly checked out – and checkout was limited to at most one person at any given time. The big change of CVS was allowing everybody having all code writable (in his/her own sandbox) and allowing parallel changes to the same file. The simultaneous changes from different people were merged using two step process – update (transfer the changes from repository to local sandbox) and commit – upload the local changes to single, central repository. The possible conflicts were resolved between update and commit.

What is the fundamental difference between centralized and decentralized VCS ? In my limited understanding of how the DVCS work (as I have not worked with any of them yet on real project): unlike with CVS where there was one central repository and every developer had local copy of single state only (sandbox), with DVCS every developer has own copy of whole repository and therefore access to all versions of all files without depending on the centralized server. Every node is a repository and every commit is (or can be) local. Rather than synchronizing the local sandbox with the central repository, the independent repositories are synchronized. Nodes can synchronize directly as long as the changes are made available to other nodes by “publishing” them- usually using HTTP or SSH/FTP. The content of your repository will thus depend on number of nodes you synchronized with – and their own synchronization history.

New models of interaction are just one of the new features emerging. The DVCS can easily simulate workflows and processes from the traditional VCS but also allows several workflows impossible with VCS – like committing changes and getting differences without any connectivity to remote repository. (To be completely fair, you can do that to certain extent with Subversion – because latest status from repository is locally cached, you can always do diff and see local changes made – or undo them, but only for one revision). The DVCS is also very flexible – allows very dynamic creation of groups and branches and does not have single point of failure.

So what is the answer for the question from the title ? Should we throw away traditional VCS and start using new distributed decentralized tools ? I am not sure. With flexibility and freedom comes overhead and responsibility. Synchronizing large repositories can be expensive – both in time and network bandwidth. What is more important, it may require changes to the project management style and additional effort invested into keeping codebase under control – see the Development metodologies in Bazaar manual. When no repository is central, it is much harder to say where is the latest, most complete version of the system’s code. And – unless you address it with your process – it may be hard to tell whether it is currently even available. The DVCS seems to make sense mostly when the team is very large and geographically distributed. I do not see many advantages for the smaller development team working in one location – other than fixing several CVS/Subversion annoyances and possibly providing better and easier merging. What is also important is tools availability and IDE integration. All this need to be better understood. Right now the answer for me to whether to switch: no.┬á But to start looking into DVCS and evaluating to see the pros and cons – absolutely yes.

Nice comparison of features of the various SCCS is available here.

Synchronizing GCalendar and Thunderbird


Another important step forward for all who are looking for alternatives to replace Outlook. With latest Thunderbird 2.0rc1 release it is now possible to add calendaring capability to Thunderbird (using the Lightning add-on) with Google calendar synchronization that works even with iCal invitations :-). Really nice.

The author’s blog at seems to be down, but cached version is available.

Credits and thanks to Joel for finding it.

Kurt Vonnegut – R.I.P.


It is a sad news – Kurt Vonnegut Jr., one of the great sci-fi writers, died at the age of 84.

Thanks for all the great hours spent reading many of great books he wrote over last 55 years. I guess that best way how to show respect is re-read something he wrote – like this one.

Quote of the day


Goal is a dream with a deadline.

Found on the Net – probably by┬áNapoleon Hill

Gems and bookmarks


This was one great weekend ! Easter should be more often than once a year, I guess. Unlike Christmas, there was no shopping craziness before and much less overeating danger. Not counting overdose of chocolate, of course, but that’s OK.

I managed do mostly nothing for about one day – up to Friday evening. Then I dived into the Ruby and Ruby on Rails world. After reading this and one third of this book, I like Ruby even more. I actually did write some code – not much, but rewrote some of my old Python scripts I use to manage files and repositories. The new Ruby version is shorter and IMHO more elegant (even with my limited command of Ruby idioms), much better readable – albeit a bit slower than Python version. But that does not change my very positive impression of new language. In addition to these (and btw, the mixin’s are so great it is even scary), I learned to love the Rake and gem tools. Gem is pre-packaged Ruby component, managed as unit, that can be installed and updated remotely using the gem tool. It solves the problem of versioning – something I wished Java had from the beginning. It also provide similar functionality as the GAC in .NET: allows side-by-side existence of multiple versions of the same component and makes component available to other programs. Very clever, very convenient. Same story as with the language – gem is something similar that Perl did have with CPAN, but it is just cleaner, nicer and polished …

Rake is Ruby’s own version of make (or Ant or msbuild if you wish). It uses DSL – domain specific language, similarly as Ant or make do, but the language is neither make-file based, nor XML based. It is high-level Ruby code, specifying the tasks, targets and dependencies – but in case you need it, full power of Ruby is available. Martin Fowler wrote a nice intro to Rake, see also this, this and Joe White’s blog – on ‘life, .NET and cats’ – all great and worthy subjects ­čÖé

I have also discovered the lots of new powerful gems and Ruby based programs: for example another implementation of Cruise Control – not in Java or C#, but in Ruby (can be used to build anything, including Java or .NET), own version of Lucene named Ferret

Real eye-opener was however Rails. It contains many excellent ideas that would make lots of sense in any environment – for example configuration free version of Hibernate, testing that goes way beyond unit test of business objects, clever way how to manage database schema versioning, lots of Spring flexibility in MVC processing – without Spring complexity. I am still learning and discovering new things, but as soon as I am comfortable enough with it, I will do a lunch-and-learn on Rails and specifically on these features that transcend the Ruby environment.

As I was reading, I kept adding bookmarks to my delicious account which now holds unbelievable 2110 links. In order to improve sharing the bookmarks, I have decided to create Thinknostic common bookmark repository where I could share the subset of the bookmarks using the ‘My network’ feature and for:SOMENAME labels. Thinknostic account is publicly accessible at

If you want to see what is there – just browse. We start small, rather than dumping all my bookmarks – I will be adding them as I review and clean up the taxonomy. Feel free to submit your recommendations – there is no need to change anything on you bookmarking habits – if you are using If not – consider giving it a try. There are many good reasons why this is a good idea – I tried to summarize them here:

You can contribute two ways:

a) if you want, you can become part of the Thinknostic “bookmark club” by adding thinknostic to your network
b) whenever you find something of common interest, tag it (in addition to other tags that classify the link) by for:thinknostic (no spaces, one word)

The a) and b) are independent: you can suggest links regardless whether you are member of Thinknostic network of not ….

When you label a bookmark with for:thinknostic, it will first appear in the Inbox and somebody with administrative access to the account will eventually move the link to the collection and possibly re-tag. More details onhow this all works are at: