Archive for the ‘programming’ category

Difference between matching and simple Git push

2013/12/31

See https://github.com/radegast/miroadamy-dot-com/wiki/Difference-between-matching-and-simple—Git-push

Advertisements

Podcast recommendation

2010/11/24

I have find new podcast that I want to share with you. It is called “This Developer’s Life” and is produced by well known digerati Scott Hanselman and Rob Conery.

I listen to a lot of podcasts, about 50 % of them produced by Leo Laporte’s TWIT Network (This Week in Tech, Macbreak, This Week in Google, FLOSS Weekly and occasional Security Now).

What I like about Leo’s network is professionalism of audio production, usually good and interesting panel with topics that are worth listening to. Few other podcasts come even close to the TWIT level of perfection.

Except this one which is much better. Not necessarily from audio or production point of view – although they are both very good. This developers life goes way beyond what Twit does. It is not a dialog of few interesting geeks, it is story. Story nicely designed, well crafted, interwoven with really good music. It changes from dialog to story with commentaries, but keeps you interested. An episode usually
focuses on single theme and contains several stories. Topics are not technology, but the area where technology overlaps with life: motivation, audacity, highs and lows of programming career

Great selection of guests, including cybercelebrities such as John Resig or Miguel de Icaza.

I almost never listen to a podcast episode twice. For this one, I do.

Highly recommended.

http://thisdeveloperslife.com/

Excellent free Git tutorial

2009/01/02

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

http://excess.org/article/2008/07/ogre-git-tutorial/

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

2008/09/27

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

2008/09/25

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

2008/09/20

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

2008/09/08

The 97 things that every software architect should know:

http://97-things.near-time.net/wiki

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.