I first learned about Ruby about 8 years ago, when another programmer that i only knew from some Linux-related forum (yup, i was a die-hard linux user at the time) kept claiming that it was one of the nicest and purest OO languages available. I kept thinking “yeah right, nobody is using Ruby for real stuff so it can’t be good”. In my defense, i was only 21 at the time and at that age a lot of people can still be quite ignorant at times (or even quite frequently). But that doesn’t change the fact that i was just plain stupid.

Fast forward 8 years, and here i am: a developer who was once convinced of the virtues of static languages, but is increasingly frustrated by both the static nature of C# (regardless of the introduction of the dynamic keyword) because of the limits it places on my creativity, as well as the entire .NET world for a variety of reasons. So i figured it was time for me to learn exactly what was so good about these dynamic languages. At first, i doubted between going for Ruby and Python. I picked Ruby, mostly because it has more momentum than Python. And since i hate learning something new from some simple online tutorials, i wanted to get some good books on the subject to make sure i really learned what it was all about. The first book i ordered was The Ruby Programming Language which seems to be the definitive guide to the Ruby language. It ought to be, with that title

Books about programming languages are generally pretty boring. It’s not the fault of the writers, or the language, it’s just because so many boring details need to be covered when learning a new language. I was very happy to see that this book certainly minimizes those boring parts. The book starts off with a quick introduction to Ruby. It very quickly goes over some code with very brief explanations as to what the code is doing. Not sure if everyone will agree on this, but for me it was like the perfect appetizer. It really made me want to learn the language thoroughly.

The next 4 chapters aren’t nearly as interesting as the introduction was. The 2nd chapter deals with the structure of Ruby code. Important, but not exactly thrilling to read. The 3rd chapter discusses some of the standard data types and you’ll also learn more about how objects work in Ruby. The stuff about objects was very interesting, but the descriptions of the data types are, as they always are, pretty boring. The 4th chapter (Expressions and Operators) and the 5th one (Statements and Control Structures) are also quite boring. But then again, i can’t possibly imagine how anyone could write about these kinds of topics in a way that is truly interesting, regardless of the programming language that is used. In fact, i’d say that these topics were dealt with in a manner that is at least less boring than how they’re usually covered in programming books. And even though those parts are not the most interesting to read, it is great reference material if you quickly need to figure out something or need to refresh your memory while working with the language.

The next 3 chapters however were (IMO) immensely interesting. Chapter 6 tells you everything you need to know about Methods, Procs, Lambdas and Closures. You might be thinking “how could that possibly be immensely interesting?”, but trust me, it is. I also think that this chapter will either strongly increase your appreciation of the Ruby language, or might be a little off putting, depending on how you generally feel about the importance of static typing vs dynamic. Most developers will see the possible dangers here and you’ll either feel fear for what people can do in a method, or you’ll love the power and flexibility while still recognizing the dangers (with an increased appreciation for automated tests, hopefully).

Chapter 7 deals with everything there is to know about classes and modules, and it’s an absolute joy to read. At this point, i really started to feel stupid for not having learned about this years ago. Lots of interesting stuff here, and the ideas it planted in my head are surely gonna hurt me frequently while coding in C# at work. Chapter 8 was even worse in this regard… it discusses Ruby’s reflection capabilities and the whole metaprogramming thing. It made my head spin, in the good way. I know i can really take serious advantage of those capabilities and i can’t wait to actually experiment with it.

The 9th chapter discusses the Ruby Platform, which is basically a succinct run down of what you can do with a lot of the standard Ruby classes. I largely skipped this chapter since the next book on my reading-list (The Ruby Way) covers all of that and more, in depth. The final chapter covers the Ruby interpreter and the general Ruby environment. It’s somewhat interesting, but nothing spectacular.

I generally approach programming language books as necessary reading (at least when you’re learning a language) but a chore at the same time. While some of the chapters in this book suffer from a lot of the same problems that you’ll find with other programming language books, it at least is less boring to read. Chapter 6 through 8 however are more than worth the cost of the book and could really change the way you think and feel about OO and if i could legally get away with it, i’d force every programmer to read those. It’s certainly not going to convince everyone, but it could open a lot of people’s eyes. This book is not only ideal to learn the Ruby language, it’ll also be an invaluable reference resource to keep on your desk as you keep taking more steps in your Ruby journey.

I already know it’s gonna take a long while before this book moves from my desk to my bookshelf.

For the past few months, i’ve kinda lost my interest in reading technical books and have been focusing on reading other books instead. I still can’t bring myself to read fiction, so i’ve focused more on stuff that you can actually learn from. I suppose it started last year when a friend of mine recommended Philip Zimbardo’s The Lucifer Effect. That book is pretty heavy, but i really enjoyed reading it and learned a lot about how people think and react to certain situations.

Then about 2 months ago someone recommended Robert Greene’s The 48 Laws Of Power. If you’ve got certain goals in your life but are not quite sure how to achieve them, then i would certainly recommend it. Hell, i’d recommend it to anyone because it’s just that good and valuable. If i had read that book back when i was stuck in Enterprise Hell, i would’ve gotten through that period with a lot less friction and a lot more results. And for the record, that book isn’t necessarily about how you should use the power that you have, or how to put yourself in a position of power, but it’s a good guide on how to protect yourself against people who have power or are trying to gain power at your (or other people’s) expense.

That book lead me to The 50th Law which is a collaborative effort between Robert Greene and 50 Cent. Now, if you’re closed minded and don’t want to read a book that has a gangsta rapper associated with it, be my guest, but rest assured that you’re missing out on some very interesting and valuable stuff.

Next up on my reading list is The Prince and The Art Of War by Niccolò Machiavelli.

Now you might be wondering why i’m reading these kinds of books. Basically, because they really teach you a lot about how plenty of people think and react to things. That doesn’t mean that you have to follow the advice or the guidelines in those books, but it does certainly help you put certain things in perspective and understand certain situations better. And after all, if we are about self-improvement on a technical level, then we certainly should be open-minded enough to read books that could help us improve our understanding of other things in life as well. And i can guarantee you that the stuff you read in those books can help you in your professional life as well.

I’d definitely be interested in any other kind of non-technical, non-fictional book that you can recommend for whatever reasons

I’m not the best debugger out there, but i usually manage to get to the bottom of things and sometimes i even enjoy chasing down a weird bug.  And while i actively try to avoid bugs as much as possible, i’m also always looking to learn more techniques or practices to efficiently find and fix bugs when they do occur.  So when i first heard about Paul Butcher’s Debug It, i immediately preordered it.  And now that i’ve read it, i’m very glad i did.

The book is divided in 3 parts.  The chapters of the first part explain in depth what kind of debugging strategy you’ll need.  Discussed topics include:

• figuring out what you’re really looking for
• tips and tricks to come up with a reliable reproduction of the bug and the value of having that reproduction
• diagnosing the actual problem
• coming up with a true fix
• reflecting on why the bug ever got into the software
• making sure that the bug can’t come back and that we learn from the mistake

For some of you, most of this stuff will just be common sense.  For a lot of developers though, this part alone should be considered required reading.  It’s a complete process of how to deal with bugs efficiently in less than 80 pages!  Think about that for a second: 80 pages that will improve your efficiency at your job and will reduce the amount of time you spend doing something you probably don’t like doing.  How could you resist?

The second part is pretty short (only 2 chapters) but pretty interesting as well.  It mostly deals with organizational patterns and practices that a development shop should take into account.  It covers things such as:

• the importance of bug tracking
• what makes a good bug report
• effective communication with users and support staff
• giving priority to bugs as soon as they’re discovered
• the importance of pragmatic zero-tolerance for bugs
• ways to get out of a Quality Hole

Not all developers will like the second part, but it definitely contains some valuable information for technical managers, or for developers who need to convince their technical managers

The third part of the book deals with a lot of various strategies for a variety of specific situations.  While not everyone will get something out of every topic discussed in this part, odds are that quite a few of them will indeed be interesting for you.  You’ll find specific advice for quite a few special cases (performance, concurrency, backwards compatibility, third-party bugs, etc…).  You’ll also find the obligatory chapter on creating an ideal debugging environment with automated tests, a build system and continuous integration.  If you’re reading this blog, you’re hopefully already convinced of the values of such things so you might want to skip this chapter.  The final 2 chapters are again very interesting… They’ll show you how you can write software that will debug itself.  While not everyone will actually go out and do this, some ideas of that chapter should definitely be kept in mind by most of us.  The final chapter deals with some common (mostly organizational) anti-patterns for dealing with bugs.

All in all, there is just a lot of tremendously valuable information in this book.  And it’s only about 190 pages so it definitely won’t take you a long time to read it.  I’ve frequently been amazed at the inability of developers to efficiently debug issues when they occur.  And i’m not just talking about bad developers.  I’ve seen plenty of good or even great developers having trouble with debugging efficiently.  This book would definitely get them on the right track, with just a little bit effort.

As i mentioned in my (short) review of ’97 Things Every Software Architect Should Know’, i love the format of these “97 Things” books. I already pre-ordered the upcoming ’97 Things Every Programmer Should Know’ and was curious about the other book in the series: 97 Things Every Project Manager Should Know.

Now, i’m not a project manager and have no intentions of becoming one in the future. But as a software developer, i do think it’s important to have an understanding of what good (and bad) project management entails so i’d recommend this book to project managers as well as developers. As usual with books in this series, it’s full of useful, real-world advice and common sense contributed by experienced and established project managers. Each piece of advice is again only 2 small pages, and no topic is ever discussed too in-depth. While not everyone will get something out of every bit of advice, there surely will be quite a few that’ll make you think about improvements that can be made in your company.

While there is no structure in the order of the tips, the book does list each tip by topic in the beginning. Topics that are covered are agile methods, general software development, managing people and teams, dealing with distributed teams, improving communication, managing stakeholders, project processes, dealing with requirements, dealing with end-users and self-management. The book claims to be useful to project managers in general and not just for software projects, though i think non-software project managers will probably not get a lot of valuable information out of this book since the large majority of the tips are rather specific to software development.

Definitely worth reading.

I’ve developed this bad habit of reading about a book (usually in blog posts), thinking “hmm, that should be interesting”, going to Amazon, ordering it and then forgetting all about it. The whole process takes less than 2 minutes. I have recently bought the following books, all of which i still have to finish:

• 97 Things Every Project Manager Should Know: i love the 97 Things series, and i think it’s important to figure out how project managers think (just as it’s important for men to figure out how women think) so i had to pick this one up. I am about halfway through at the moment.
• Debug It!: Too many developers have trouble figuring out where to look when something goes wrong. I’m proud not to be a part of that group (on most days), though i keep my eyes and ears open for any kind of debugging tips so i just had to pick this one up.
• Growing Object-Oriented Sofware, Guided By Tests: i never knew about this book, but i happened to glance over it in a list of recommended books based on another book that i was buying at the time. Once i spotted the “Kent Beck Signature Book”-series logo i clicked the “Add to shopping cart” button. That’s right, i’m that big of a Kent Beck fanboy.
• Advanced .NET Debugging: This is the book i got suckered into buying today… why? because Tess Ferrandez recommended it. Yup, i’m that easy. Seriously though, how could it be bad?
• Writing Secure Code: 2nd Edition: I started reading this about 2 months ago. I’m currently at page 154. It’s that boring.
• Enterprise Integration Patterns: As cool as i suspect this book to be, i still haven’t made it past the first chapter. Which i started about 3 months ago. It’s not that it’s boring, i actually think that messaging is very cool… but for some reason i can’t get myself to read this thoroughly when there are other things to do that are more relevant to what i need at work.

The subtitle of Ship It is “A Practical Guide To Successful Software Projects”, which it most certainly is. While it doesn’t cover nearly as much ground as The Art Of Agile Development, it does contain enough valuable information that will improve the way you attempt to deliver working software.

That is, unless you’re already doing things like Continuous Integration, automated testing and code reviews. While these topics certainly aren’t the only practices that are discussed in the book, they are pretty much the practices ‘building blocks’ that this book depends on. If you’re already using these practices in your projects, then odds are that you won’t really learn anything new from this book. However, if you’re not doing this, or your projects are just a mess and you really have problems delivering software, then this book will definitely help you to improve your situation.

The book first covers a couple of tools and the necessary infrastructure that you’ll need to successfully develop software. Things that some of us will take for granted (source control, CI server, change notification, issue tracker, etc…) but that not everyone is using (apparently). After that, some solid practices are covered, such as the importance of having a technical lead and the responsibilities that come with this job, communication and coordination between all team members, and extensive code review practices (this part was especially good IMO).

The book then also covers ‘Tracer Bullet Development’ which is an approach that the authors recommend for all projects. It basically comes down to using a layered architecture that is loosely coupled and nicely encapsulated along with some good advice in general on how to get working functionality into your system quickly, yet sustainable. Finally, the book closes with (usually) solid advice for a list of typical problems that many teams are suffering from.

Again, if you’re already using the practices that i mentioned in this review then you most likely will not really benefit from this book, and you’d be better off reading the Art Of Agile Development instead to improve what you’re already doing. But if you’re not using any of these practices yet, this book should help you improve your working environment very quickly and rather easily.

As far as Object Relational Mapping (ORM) in the .NET world goes, NHibernate is one of the more mature, powerful and popular options available. But learning how to use it properly can take some time. NHibernate In Action aims to lower that learning curve significantly.

The first 2 chapters offer a general introduction to ORM, some reasons why NHibernate is the authors’ preferred ORM, and a step-by-step guide to creating your first NHibernate application. Topics such as NHibernate’s (high-level) architecture and configuration are also covered here.

The book then proceeds to cover some important NHibernate concepts in depth. First up, writing and mapping classes. This particular chapter doesn’t cover really advanced mapping scenarios (a later chapter takes care of that), but it does cover most of your options very thoroughly. This isn’t just basic mapping though. You’ll already learn about various types of associations you can have and the three available strategies for inheritance mapping.

Once you’ve learned how you can map your objects, you can start working with them, which is what chapter 4 covers. You’ll learn about the persistence lifecycle, working with transient/persistent/detached objects, dealing with object identity depending on the current state of your objects, transitive persistence (cascading options), and you are introduced to some of the possibilities for object retrieval.

Chapter 5 teaches you how to deal with transactions, the various options to deal with concurrency and it also covers NHibernate’s caching features very thoroughly. All 3 of those topics should be very clear to you after this chapter

After that, the authors revisit the subject of object mapping again in Chapter 6, this time covering some more advanced options. The stuff you’ll learn about in this chapter is very interesting, but in most cases you won’t need these features. But it’s good to know that they are there in case you need to handle more exotic mapping situations

Chapter 7 is probably one of the most important chapters of the book, as it deals with various ways and methods to retrieve objects efficiently. You’ll get great coverage of HQL in this chapter, and you’d be surprised how powerful it is. In most cases, you’ll see the equivalent of the HQL statements using the Criteria API of NHibernate, but (and this is one the few gripes i have with this book) for some of the advanced concepts (namely projections and grouping) they completely ignore the Criteria API and focus solely on HQL. I’m a pretty big fan of the Criteria API so i obviously find that a little bit disappointing. It does cover pretty much everything else you want to know about querying with NHibernate though.

The final 3 chapters deal with using NHibernate in the real world. These chapters might be of use to people with little experience in (proper) software development, but i don’t really think most people will really get a lot of value out of these last 3 chapters. Topics covered here: layered architecture, common design goals you should aim to achieve, some options with regard to generating code/mappings/database, dealing with legacy database structures and more. Again, this might be interesting to some, but definitely not to all.

Overall, i would say that everyone working with NHibernate would benefit greatly from reading this book. If you’re just getting started with NHibernate, it will indeed lower your learning curve significantly. If you already have experience with NHibernate, you will most likely learn some tricks that you didn’t know about yet. It’s a good book to read cover to cover, but at the same time it will be of great service to you as a reference book. Chapter 3 through 7 especially are chapters you’ll probably revisit frequently while you are working with NHibernate.

There is one thing to keep in mind though… this book targets version 1.2 of NHibernate, which is a bit of an old release. This is rather unfortunate since NHibernate 2.0 and 2.1 introduced a lot of great new features. Obviously, these great new features aren’t covered here, but the most important things of working with NHibernate are all covered thoroughly so don’t let the 1.2 version number make you think that this book isn’t relevant to the current versions. This book is by far the best source of information on how to get the most out of NHibernate.

97 Things Every Software Architect Should Know isn’t really a book… it’s pretty much a collection of bits of wisdom and advice from a bunch of leading software architects. There are no chapters, there is no unifying theme, there is no structure whatsoever. There is just a lot of great content. Around 50 software architects contributed 97 pieces to the book, each one filling up about 2 (small) pages. In a way, reading these pieces feels like reading great blog posts, though without the usual blogodrama. It’s great stuff for when you want to spend an hour reading, or for when you have a couple of minutes to spare. There’s even a website which contains all of the original, unedited contributions so the cheapskates among you can read it all as well

As i mentioned recently, i’m taking advantage of the low value of the British Pound by ordering quite a few books through amazon.co.uk. I’ve recently ordered even more books, so i now have the following books lying around, waiting to be read:

1. 97 Things Every Software Architect Should Know: this is one is pretty cool so far… lot’s of great, short tips which makes it ideal to read while you’re taking a dump (Borrower Beware!)
2. NHibernate In Action: This looks like it will be the definitive resource for using NHibernate properly.
3. Data-Driven Services With Silverlight 2: gotta increase that Silverlight knowledge.
4. Framework Design Guidelines, Second Edition: this one was also on the previous list
5. Ship It: this one was also on the previous list
6. Enterprise Integration Patterns: this one was also on the previous list
7. Writing Secure Code: this one was also on the previous list

I plan to read them in that order (unless you can convince to me change the order)

I also have a copy of Refactoring To Patterns lying around, which i borrowed from work… no idea when i’ll actually get to it though.

I recently started working on a Silverlight project, and since i had no Silverlight experience at all, i ordered a copy of Chad Campbell and John Stockton’s Silverlight 2 In Action so i could quickly brush up on the subject. This book is a great resource for those who are new to Silverlight, as the authors gradually build up your understanding of Silverlight’s features and capabilities.

While it probably doesn’t cover everything there is to know about Silverlight, it definitely covers most of the things you’ll be dealing with when developing with Silverlight. However, it doesn’t really teach you how to build real-world applications with it. There is very little focus on application architecture, so if you’re already familiar with Silverlight and want to learn how to properly build your applications with it, then this book is probably not for you. But if you are new to Silveright or have little experience with it, then i would definitely recommend it to get to know what Silverlight can do for you, and for what you can do with Silverlight.