Working Effectively with Legacy Code
Misleading title. Should be called ‘Fowler’s Refactoring + Meyer’s OOP + Mumblings’. I wouldn’t like to say I don’t recommend this one, since a lot of people found it useful – which is why I picked it up. However, to me its a time waster, everything this guy says is either obvious, blurry, or an idea from another book.
His ‘techniques’ are things that you already do subconsciously while refactoring code, and they’re really so straight forward they’re intuitive to do. example: how do you test a private method – his solution, is make it public, or rethink your design. I just “love” the rethink your design answer.
I’m not afraid stating that a book s#$%, books are the biggest time wasters when they don’t give you anything new or useful.
Practices of an Agile Developer
This book however was great. Its a light read, very fluid, nice examples. What I liked about it is some of the agile practices it offered to consider, like CI and code ownership, as well as something I already did but didn’t know it was called that way – a ‘daylog’. A daylog is where engineers (in other, more materialistic forms of engineering) keep their problems and solutions log, things that they stumbled on through out the day. The author recommends keeping such in a wiki, available to the whole team.
The author also isn’t afraid to cover awkward situations, like how do you behave when you join a new team? how do you fight the urge to point out mistakes in other’s code? how do you keep meetings short? how do you deal with management?
This one covers so much, in such a summarized form that its able to be straight to the point and be a weekend read easily.
Release It!
Seems to be a great continuation to Practices of an Agile Developer. The title here is misleading too, it should be called ‘Real world practices: the missing manual’. This book is priceless, finally someone went in there and covered real world applications pitfalls, and not only that, he went ahead and formalized a set of patterns and anti-patterns which we all engineers have grown to like. Among the pitfalls the author identifies common software ‘cracks’ – for example, in order to identify weak points in an massively consumed application, you would need to go over integration points – between systems. You would also need to take a better look at anything that involves resources. He shows real world failures, as well as a bearable analysis of them. The patterns are cataloged in a neat way too.
I’m half way through and I’m fascinated, this book would be the best present a developer can get these days – so get it NOW.
I sat today to take a look at Boo, since Oren Eini is so fond of it. The concept was nice, and it took me several hours of comparisons to see in which situations using Boo is preferable to using IronPython, and the other way around. It occurred to me that perhaps Boo was created when IronPython wasn’t mature enough – whatever the reason, I’m not sure.
In short, I didn’t come to a conclusion.
But I did have some fun. I played with the thought that using python’s native dictionary initialization syntax would be nice as a configuration file syntax (e.g. ini files).
So I whipped a sample project that would embed both Boo and IronPython and looked at the differences with usage. So far I’m liking IronPython better.
This example is ridiculously simple, but you can go ahead and tinker with the engines, its a good timekiller :).
here is a link to the project. you will need to update the references to your own local Boo and IronPython (1.x) binaries.