Excellent free Git tutorial


Two screencasts, about 80 and 40 minutes long are available at:


Courtesy by fellow Ottawan Bert Trojanowski. Really nice job of providing deep enough technical understanding with good illustrative examples.

If you want to get into distributed version control (which is IMHO way to go), check this out.

Free eBook on ALT.NET


It is always a nice surprise to find something that is free and actually useful on the Net :-). Like this one: a fellow Ottawan Karl Sequin wrote and generously made available as free download “Foundations of programming” eBook.

He touches many topics of various levels from high level design concepts (dependency injection) to low level “Back to Basics” – how memory allocation and pointers work. Especially the later is often neglected and overlooked (and consequently misunderstood) by younger developers who started their education with a garbage collected language such as Java or C# and never were exposed to beauty and horrors of C ๐Ÿ˜‰

The book is using .NET and C# as platform, but the applicability of the chapters goes way beyond the Windows or Microsoft world. After all, Alt.Net has very close relations with Java world.

If you have time, give it a look. Were it not free, I would say it is worth every penny. Now I can only say it is definitely worth the time you spend on it.

Thanks Karl, I hope I’ll meet you in person sometimes. The advantage of living in Ottawa is that you have lots of smart people around you :-).

After the Spring Storm


Few days ago, I have received an email asking to attend the SpringSource conference and offering $300 discount if I decide to buy before end of month. The timining was pretty ironical, considering the recent contraversy about SpringSource Entreprise Maintenance policy change. The was a heated discussion on TheServerside.com and even FAQ was compiled by Rod Johnson to explain the whole thing.

So what is the issue: SpringSource, commercial entity behind community driven Spring Framework decided to capitalize on the investment and push the community toward paid service suport contract. Whether or not it was related to funding round and VC’s entering the game, is not important. Unfortunately, the terms were not really well explained and SpringSource did initially very poor job explaining and communicating the actual change. The community overreacted and lot of people started to call for code fork, project Summer or similar – or switching to different framework.

What the change really means is that maintenance releases will not be available (as binary, official downloads) after 3 months, unless you pay for the support. It means that using new policy after let’s say release 2.0, only for three months everybody could download binary distributions of 2.0.1, 2.0.3 etc. If at the end of month 3 you would need fixes in the 2.0 branch, you would be on your own. The source code repository with 2.0 branch would still be available, with fixes committed (see later) but without tags (or labels) and certainly without pre-packaged download of 2.0.4, 2.0.5. You could compile the actual head of the 2.0 branch yourself, but it would not be clear what version you actually run.

This is actually not such terrible limitation as it may seem. Maintaining old code base and backporting the changes from trunk into fixes in branches is lot of work, requires testing and so on. SpringSource did invest a lot into the codebase and as commercial entity provides service to the users. The release management and software maintenance is slightly different type of work that developing new great release, and I can imagine that there are even less contributors and volunteers for this (seldom appreciated) kind of work. Multiply that with many branches and you’ll see the magnitude of the problem.

What did SpringSource do wrong, in my opinion is that they are taking away something that was available for the community for free and that created lot of negative sentiment. There are two ways how to push people to pay for free service – and cutting unless you pay is wrong one. Right way is to offer more on top of what is available for free, something that has value specifically for enterprise clients. There are several areas where there is a need: more and much better samples, template applications, guides, tutorials. Their availability has huge value for customers in saving development time and better quality of the products using the Spring platform.

There are several technical subtleties that are in open: the FAQ says that the changes and fixes from trunk will be available in the maintenance branches, but does not say when. Delaying changes can be powerful argument … Lack of tags in public repository also implies existence of private repository with these tags – how else could the SpringSource build the “supported releases”. The existence of two repositories in project (unless you use distributed VCS, of course) is often starting point of splitting project to payware and limited “community edition”. I hope this will not happen to Spring.

The most unfortunate impact of the maintenance policy decision may be for the Spring based opensource projects, that helped a lot to establish acceptance of the platforms over last few years. Dilema of facing either cascading changes of permanent upgrades just to keep in sync with latest trunk version, or permanently monitoring the branch to see which of the changes are important – in absence of “official” maintenance release with defined bug fixes etc can be an issue for many projects. I hope SpringSource will find workarounds and solutions for these.

Despite of that, forking Spring would be very bad idea. The very last thing enterprise Java needs is another framework that is esentially same or very similar than existing one. SpringSource employs brilliant engineers, Spring community also has great contributors – what is the point of splitting the forces when there is no architectural disagreement, the issue is “just money” ?

Forking also does not solve the core problem: who will be providing the community service of maintaining and building the old releases. The maintainers of Summer codebase (or whatever the name of Spring forked successor would be) will face the same dilema – choose between working for free forever or finding way how to employ enough manpower to keep the balls rolling.

I would recommend that instead of forking Spring codebase, whoever feels like it, try instead to fill in the gap and provide the “inofficial official” builds, a “community maintenance releases” as counterpart and alternative to official SpringSource maintenance releases for enterprise (== paying) customers. This would actually help the project and all projects that depend on it much more than asking them to switch.

It would also not hurt SpringSource – I am convinced that they would loose very little revenue (if any) because of that. It has been done (Centos vs RHEL). If my project would be based on Spring platform and not on commercial Java server (which it is not) and the support cost would be reasonable (which it IMHO is), I would happily pay for priviledge to have access to the people of Juergen Holler’s caliber (and many others).

Let’s face it, folks: when it comes to support and software maintenance and similar less attractive areas of our profession, there is definitely no such thing as free lunch …

Three great Git resources


Before I forget ๐Ÿ™‚

1) The Git Magic

2) Two git books Pragmatic Git Book and Git internals – nice complement each other

3) Linus Torvalds slightly offensive and very funny talk at Google

in addition to great, precise but not necessarily most digestable manual

Good read – not only for software architects


The 97 things that every software architect should know:


Actually, it’s 87 but new are still coming. You may add your piece if it is not yet there …

Milos – thanks for the link.

Objective C: I really miss namespaces


One feature that I strongly miss from Objective C are namespaces. Inability to avoid name clash between yourย  classes sometimes really stands in your way.

I am reading S. Kochan’s book “Programming in Objective C” and in one of the examples he creates the class Point. Unfortunately, there already is struct Point defined in mactypes.h.

The solution is easy – rename the darn Point to something like TKPoint … at least that is what Cocoa naming guide recommends. It is probably matter of getting used to itย  – but I still find the solution suggested by Kevin Hoffman much more elegant – too bad it is only theoretical. Much nicer than NSHack ๐Ÿ˜‰

XCode annoyances


I have started to seriously play with Objective C and XCode about week ago. So far it was very pleasant experience. I really like the language – feels like Ruby (or Smalltalk if you want) with rocket launcher: very powerful, blastingly fast and dangerous like hell. No array boundary checks as in Java :-).

The XCode was not bad experience either. Here my very long Eclipse and Visual Studio history is going a bit in the way, as the things often works quite different. Not necessarily worse, but different. It would be too early to judge it – not before I get more proficient in both Objective-C and XCode and learn more Cocoa goodness.

Two things however are so annoying, that I have to mention them right now:

1) Setting breakpoints was gamble – sometimes it worked, sometimes it did not. I could not figure out why, until I found here that you must in Preferences -> Debug switch off the ‘Lazy loading symbols’. After re-entering the breakpoints, I finally got it to behave as expected.

2) Trying to add existing files to a projects crashes the XCode with the following:

The console window shows error:

PM Xcode[34563] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '
*** -[NSAutoreleasePool stopObservingModelObject:]: unrecognized selector sent to instance 0x32da240'

which is clearly a bug. I tried to reboot (it was about time after running for over two weeks anyway), no help.

Weird is that I remember doing that before without any problems … Workaround is use drag and drop, of course, but I wish Apple would fix this Really Soon, as it is plainly embarrassing …

I have seen crashes like this in Visual Studio, but Eclipse was rock solid environment despite the very complex plugins ecosystem, so it is hard to go back to use something blowing under your hands …