Posts Tagged: review


29
Dec 09

book review: design patterns in ruby

design patterns in ruby

Go buy this now

I am back from the holiday break and a perfect storm has come together, I’m currently working on a rails project, and I have a wonderful girlfriend who embraces my geekiness and buys me Design Patterns in Ruby. I have been reading this thing for the past few days and can’t put it down, I wanted to read a chapter last night before bed, I sleepily set it down 5 chapters later.

Just so you understand something, although I love to read, I am a slow reader, books are hard for me to get through, I also have a ton of things to read and play around with, so you better keep my attention. I have also read the classic GoF book, so I’m coming into this book well versed in design patterns. I’ve played with ruby a few times before, but nothing too serious (if you look back in the archives you will see that my first post was on ruby koans).

Let’s talk about this great book by Russ Olsen. The book does not require you to know anything about ruby, the first chapter is, in fact, a great primer to the language. Olsen comes from a background of 25 years of software development experience, as he puts it

I have been building software for more than 25 years. I’ve done assembly language, FORTRAN, Pascal, C, C++, Python, Java and now Ruby.
  -Russ Olsen

The introduction to ruby feels like it was written for someone with programming experience in a Java-like language. Throughout the book Olsen makes reference to the Java way to do things (which will be easy to grasp for the .Net crowd too). The primer to the language is interesting in that it skips some of the core things that makes ruby what it is (the whole meta-programming, monkey patching, message passing thing). This would seem like an oversight at first, but was helpful for me as a new ruby user. I wasn’t bogged down in the different of ruby, so I could focus on the same. This let me feel comfortable with the language and focus on the patterns, as we will see, these parts missing in the primer will be fully explored later in the book.

The book is structured very much like the GoF book, with each chapter focusing on a particular pattern. Olsen opens up the chapter with some example situation, then he moves into how you could solve it with inheritance or ugly code. Then the problem is re-examined, a pattern starts to emerge, and then is described. The pattern is explained in the classic GoF style with example code (in ruby) and UML diagrams, the best part though is the clear, concise, approachable explanation provided by Olsen. The pattern now being firmly understood, the book digs into the pattern and looks at ways that we can ruby-ize it. At this point we are normally treated to some new interesting ruby language paradigm that let’s us quickly and easily rewrite the pattern, making it more concise and elegant. There is then a discussion of the uses, and probably more importantly, the abuses of the pattern. Every chapter ends with a nice summary of what was learned and (as I found out last night) an enticement to keep reading as the next pattern is introduced.

rocket sauce

Pure unadulterated rocket sauce!

The writing is incredibly approachable, Olsen does not get bogged down in technical jargon, he explains everything that’s going on in a concise and understandable way. There are copious code examples that are excellent at providing a concrete example to the abstract pattern Olsen is discussing. The author mixes in some humor here and there and will show how other programming languages implement the patterns and historical reasoning for why things are the way they are in ruby.

The overall impression I got from this book is that it is win, condensed down into ink on paper. I have learned a ton about ruby, relearned some great patterns, and gotten a great insight on the ruby way to solve problems. If you find yourself thinking, “Well I don’t need to learn design patterns, I’m so smart!” Well you are not, I’m going to use one of my favorite quotes here with a bit of a twist.

Those who don’t understand design pattern are condemned to reinvent them, poorly.
  -Matt Nowack (original attribution to Henry Spencer)

Design Patterns are all around you, learning these will help you solve future problems, understand how rails works (in fact there are several occasions in the book where Olsen shows how rails uses this pattern or that one). This book is a pleasure to read, and I suspect will serve as a nice reference for implementing patterns correctly in ruby. I’m glad to have it in my toolbox, and I would suggest you get it for yourself.


1
Dec 09

riding the wave

wave

wave

Yesterday’s post seemed to strike a nerve within the programming community, it was encouraging to see that I was not alone. I want to thank everyone that provided great commentary both here and in the Hacker News entry. I will probably touch upon the topic again, unlike a sitcom the issue of professional burnout isn’t solved in a half-hour, but not today. Today I want to talk about Google Wave!

I previously wrote about Google Wave in you can’t understand google wave which had such gems as

The problem with people waxing inanely about what Google Wave will be is that they have their heads up their asses. They don’t know, because they can’t know.

I wrote that post a long time ago during the hype and the hyperbole about Wave being the savior of the world or the misstep that will sink Google. I also wrote that post from the outside looking in, not being lucky enough to have a wave invite, I could just read the whitepapers and wonder. Yesterday though the worm turned and my dear friend Jeremiah Peschka sent me a coveted invite. After the Google gears churned away I got the email later that night, the velvet rope had swung open, I would be able to ride the wave! I fired up firefox and clicked the link, my hands trembling with the joy of new technology. I was whisked off to the interface I had come to expect in screencasts and diagrams.

I then had A Universally Confusing Initial User Experience, and tried furiously to remember Mark Essel’s Aha Moment. Once I typed “with:public” and then variations on that theme “with:public haskell” or “with:public erlang” I was off and running in the world of wave. I’d like to jot down my first impressions

  1. There is a lot of stuff out there – so many you often see listings like “51 – 76 of lots” which is the cute way Google Wave tells you there is a ton of stuff.
  2. There are other languages – I’m looking at Korean, Cyrillic, Chinese, and Spanish, all in one little window. Very rarely in my day to day surfing on the old internet do I see anything but English, on wave you see everything.
  3. Gadgets == slow – Maybe it was just a bad first experience, but Gadgets seem to bog down the wave a ton. This coupled with the fact that the few I saw seem absolutely pointless made me despise that little puzzle piece
  4. Wave == slow? – I have a fairly beefy home computer with the top tier internet connection Time Warner Cable provides, but wave felt sluggish. Things worked, but the wait times were on the high end. I thought at one point I should try it in Chrome, but that didn’t seem to make anything better.
  5. I don’t know what I’m doing – This is the big sticking point so far, I have no idea how to use this thing
  6. It pushes the boundaries – Often as a web developer we get too used to the standard paradigms, we also get stuck in a mental model that is concerned (rightly or overly) about bounce rates and conversions. Wave pushes these boundaries, Google has enough muscle to say, this is important, it doesn’t matter if people don’t “get it” right away, they will. It’s big enough and important enough that people can bounce, they will end up back at Wave before long. This is what Apple does, and it’s why people love (and loathe) Apple products.
  7. Scrollbars – I read an article about the Google Wave scrollbars a week or two ago and couldn’t make up my mind. After using them I will say you get used to it quite quickly, but I’m still not sure why they felt it necessary to re-engineer this feature. I’m thinking the biggest reason is the on-demand nature of Wave makes it so that even Wave doesn’t know how many more items are in a list, making traditional scrollbars difficult

At this point I still need to play around with Wave quite a bit before I get the hang of it. I’m going to attempt to avoid making any statements predicting into the future, because I can’t. I’m glad Google is pushing the boundaries, wave could surge or crash, either way I think its impact will be positive. Google is saying in a very public way that it is ok to think outside the box, reinvent scrollbars, change the way we view a web application, and that will have results.

People are going to debate the merits of all the parts of Wave, and that debate has definite value. The ideas that will come forth from that debate will have impact on usability, communication protocols, general design, and so much more. Pushing the community forward is never a bad thing, and so in that respect Google Wave is already a success.