Book Read: Pro .NET Performance

I’ve read this title several weeks ago and thinking of writing a blog post about it ever since I’ve finished it. Originally I was interested in learning something new about performance issues and resolutions in .NET, but the book managed to deliver some rather interesting and valuable content besides that. I’d say that the strongest and most useful material wasn’t about performance but CLR internals.

There were tons of information about CLR data structures and how classes and structs lied out in memory. That chapter alone worth well the price of the book. Also there was great coverage on garbage collection flavors and the concrete .NET GC implementation was explained well.

Of course performance was considered as well with some useful advice (on how to attack performance problems and how and what to measure at all), but the CLR internal parts were written and explained in a great manner, covering the latest version of .NET.

Until I find the time to read the most recent CLR via C# this book was a great refresher on the subject.

Book read: The Productive Programmer

There was a long time since I read anything „classic” in software literature. Nowadays I entertain myself with more practical stuff and less methodology or best practices. So came the thought that it’d be nice to read something that wouldn’t become obsolete in five years.

I checked the recommended readings thread at stackoverflow but I already read a lot of them so I thought Amazon would be able to help me out. I wanted to read something like The Pragmatic Programmer so I checked which books were bought together with it. After some fiddling I found the book in the title, The Productive Programmer. I thought why not I’m in desperate need of productivity. I tend to set up The Ultimate Productivity Blog on every workstation I get to work with. As its name suggests, it’s one of the single best resources of productivity materials. Be sure to check it out.

Let’s talk about the book a little. It’s a short read, about two hundred pages. It is split into two parts, the first hundred pages is full with practical advices (called mechanics in the book), and the second half is more theoretical. I’d recommend quickly skimming trough the whole first part; since it’s full of tools pretty outdated by now (the book was published in 2008). The tools which stood the test of time are mostly for Java, so they weren’t very useful to me also, but if you’re a Java guy then they could come handy. The reason for not to skip it altogether is that there are some useful advices on how to eliminate distractions which are less specific to tools.

Cover art of The Productive ProgrammerThe second part is much more interesting and it contains new and fresh advice after a lot of books in the mentioned stackoverflow reading list. The topics include unit testing and test-driven development, best practices for designing classes and organizing code, and YAGNI has a whole chapter dedicated to it.

I particularly liked the chapter titled “Question Authority” there was a nice parallel on the behavior of monkeys and humans regarding authority. The gist of the experiment with monkeys was that the experimenters punished a certain natural behavior. Then they started replacing the conditioned monkeys with new ones, and watched the old ones punish the new ones to prevent the behavior in question. When all of the originally conditioned monkeys were replaced the monkeys still punished newcomers showing the bad behavior, although they themselves didn’t know the original cause. That’s a nice example of “that’s the way it’s done” attitude. And that’s an attitude which certainly prevents positive changes in any organization.

There’s a chapter about reading classic books on software which contains useful advices, and another which tries to introduce the concepts of the classical philosophers, although the examples weren’t that good there.

As a summary I’d definitely recommend the second half of this book. It’s an easy read and contains lots of useful advices. For the first part, I wouldn’t be so sure but it definitely won’t hurt to read that either.

Book read: The Design of Everyday Things

Nowadays I’ve checked out the archives of Jeff Atwood’s Coding Horror blog, and found this highly recommended title. I remember a few years ago I read Don’t Make Me Think, and intended to read The Design of Everyday Things that time as well, but somehow forgot it.

I must confess that I had to force myself to read the book. It’s not a long read, probably 300 pages (I do my readings on Safari Books Online, with my Kindle, so page numbers don’t come into play anymore), and there is vast knowledge and practical advices but they are more like isles, separated with oceans of text.

Anyway this book made me realize just how awful designs I used to make (and of course, still make every now and then). By designs I mean my class-hierarchies and APIs that my “users” (who happen to be my co-workers) have to use. This revelation came when reading the book’s most important statement: when people can’t operate “everyday things” then it’s not they who are at fault, rather than the design of the device in question. Well, in software development code is pretty much an “everyday thing” and I’m certainly through some frustrating conversations about how exactly some of my classes should be used. And sadly, common sense didn’t make me realize that if I need to explain something then the issue doesn’t necessarily lie in the other party’s incompetence.

One might argue that source code is definitely not an artifact that’s for everyone, and whoever writes it must be educated and competent enough to be able to make sense from it, and he would be definitely right. The point is, which is well emphasized in the book, that anybody can operate a door, use a word processor, or perform other similar tasks, but mostly people are inclined with what they want to do, not the how, so you should make it as easy as possible. This is also holds true in my case as a software developer. Consider the following code, first stage of yesterday:

I bet you spot the obvious problem, how on earth do we know what 1000 represents? Well, you can just hit F12 in Visual Studio and try to figure out how I treat that value, can’t you? OK, let’s take it a step further, and document our work:

Much better, isn’t it? Well, not really that comment is destined to get out of sync with the code. I could improve the documentation of the attribute class, adding code comments for the constructor of the attribute taking that parameter, but I think we can agree that there is a better way. I’ve come up with this in the end:

I think you can’t really do more to prevent others screw up with the usage of this attribute. I must mention that documentation is in place in the class, so Visual Studio IntelliSense will grab and presents it. The point is that now the code tells what it does about itself, so you don’t have to read the documentation. Sure, there was some extra work, like creating an enum for storing time values, thinking on a more expressive name, etc. But I only have to write this class once, and it will be used thorough the application.

This is the philosophy I learned from The Design of Everyday Things.

Book read: Data Structures and Algorithms using Java

Recently I had a reminder that my algorithmic knowledge is less than stellar. This inspired me to read some books on the subject. I started with Data Structures and Algorithms using Java (note the “using” word, there’s a very similar book called Data Structures and Algorithms in Java). I thought a post would be nice on it, so here it comes.

Basically it’s a university textbook, so it’s very accessible but has some quirks. I’d note that referring to all practices, results and evolution of the software industry (the part of it which isn’t considered as academia) as good penmanship is a little bit pejorative at least. One more thing and I’ll finish my rant. I don’t like religious wars on where to put your starting braces, when I program in C# I consistently put them on a new line. When I use Java or Objective-C I always put them on the end of the line. But I didn’t even possibly think of putting them on a new line, then continue writing code on that very same line. So if you easily get frustrated by this:

public class MyJavaClassWithHorribleConventions

{  private int myField; //look at how I’m commenting


you’ll have a very rough time reading this book.

As I promised, this is the end of the rant, let’s look at the good things. The book is very accessible, with just enough theory to be able to read it after a long workday. There is very little mathematics involved, only basic algebra. There are lots of pictures showing each step of an algorithm, so you’ll get a pretty clear visual representation of what’s going on. Also, code samples as the title shows are in Java, (of course, on this level of complexity, they could be in almost any reasonable language) so it’s readable for a C# developer as well.

The books covers the big O notation, algorithm time and space analysis, basic data structures, such as arrays, linked lists, stacks, queues. A whole chapter is dedicated to hashing and hashed data structures. There is a chapter on recursion and on different types of trees (binary, AVL, red-black). There’s some coverage on sorting algorithms, but I’d expected more on the subject. The last chapter deals with graphs, and that’s all.

As a summary, as someone who doesn’t have a formal CS background and didn’t really looked up the subject of data structures, I found this book very useful. Although I’m sure I won’t stop here, but it provides a good foundation studying algorithms.