H3RALD: Articles

Book Review: Design Patterns in Ruby

h3rald — Fri, 11 Apr 2008 05:41:00 -0600

I finally got my hands on a shiny new copy of Design Patterns in Ruby¹. The book itself is not brand new and it was already widely praised by many different people online, so I wanted to take a look for myself.

To my surprise, the book is a hardcover edition, which makes it look more professional and more durable than the average programming book². It’s also smaller and shorter than the average programming book² (340 pages), which makes it much easier to carry around and less intimidating to read. It’s also not meant to be a reference book, so it is actually pleasant an easy to read all in one go, as you’ll soon find out.

What is it about? — well, design patters in the Ruby language of course. But it’s not the usual brainwash of programming theory you would expect by a typical book on patters, it has plenty of examples of real code. When I say real code I don’t mean the usual Dog/Cat/Horse/<insert animal here> classes or juke-box simulations which don’t work at all etc. etc., I mean actual snippets from well known Ruby applications, like RubyGems, FXRuby and, of course, Rails. OK well, there’s an exception perhaps: Russ did include a few wild life simulations (ponds with frogs and similar), but it’s only for your own good, and for the sake of tradition.

Anyhow, let’s start from the beginning…

Part I: Patters and Ruby

The first part of the book serves as a general introduction to the other two parts. If you know the basics of both design patterns and Ruby, you can safely skip this as you won’t find anything of overwhelming interest here.

Personally I really liked Chapter 1 though, “Building better Programs with Patterns”, in which Russ does a great job in summarizing the original GoF book³ into four points::

Separate our the things that change from those that stay the same.
Program to an interface, not an implementation.
Prefer composition over inheritance.
Delegate, delegate, delegate.

Also, although it does not come from the Design Patterns book but from building real systems, the author adds the YAGNI (You Ain’t Gonna Need It) principle⁴ as a reminder to resist the temptation of implementing things which may be needed later on, even if they are not needed right now. The chapter ends with an outline of the patterns which will be presented throughout the book: 14 out of the original 23 patterns by the Gand of Four will be discussed in Part II and 3 bonus “Ruby-only” patterns will be examined in Part III, as a special treat.

Chapter 2 (Getting started with Ruby) feels perhaps a bit out of place. As others pointed out⁵, why does a book on advanced Ruby programming techniques include a 35-page-long introduction on the Ruby language? The answer was given by Russ himself in an interview⁶:

“The reason that I included the introductory chapter about Ruby in there was to make the book accessible to folks with little or no Ruby background. Now honestly, I don’t think that you could come to my book with no background in Ruby and walk away from it an expert Ruby programmer — it’s not really that kind of introductory book. But I do think that someone with experience in other languages could read my book and come away knowing about Ruby, understanding what all the shouting is about.”

I admit, I skipped this chapter during my first reading because I was eager to move on to the main part of the book, but I did read it afterwards (I had to write this review after all!). It’s quite a nice introduction aimed at the average .NET/Java developer: Russ provides a step-by-step presentation of the main features of the language while holding the reader by hand when something weird or scary comes about:

The slightly strange-looking syntax in this code is actually a tip-off something deep and important: In Ruby, everythng — and I mean everything — is an object.

Of course Chapter 2 won’t turn you into a Ruby guru, but it definitely fulfills one of the author’s goals: bringing developers of other languages closer to Ruby, and give them a tiny taste of how Ruby can be wickedly powerful.

Part II: Patterns in Ruby

Part II constitutes the bulk of the book, describing 14 GoF patterns in 220 pages. The patterns covered are the following:

Template Method
Strategy
Observer
Composite
Iterator
Command
Adapter
Proxy
Decorator
Singleton
Factory Method
Abstract Factory Method
Builder
Interpreter

Why not covering all 23? Well, because to be honest, they are rarely used in Ruby. Furthermore, in some cases some of the ones examined in the book may feel a bit unnatural to the average Rubyist: how many times did you ever think about using an External Iterator when each is normally available as default internal iterator for any Array-like class?

Each chapter in this part is devoted to a particular pattern and it is organized in more or less the same way, as outlined in the following sections.

Introduction and Personal Anecdotes

Most chapters start with a personal anecdote involving the author: it may be a memory related to his first job at the local grocery store (Chapter 8), or about the day he decided to buy his son a bike (Chapter 14):

“I remember the day we bought my son his first bike.” […] I spent hours trying to pull together a minor junkiard of parts according to instructions that would have baffled the entire National Security Agency. As it turned out, picking the bike was the easy part: putting it together was the real challenge.

This was used to introduce the Builder pattern, and how to use it to configure objects which include different logical parts. Personally I find this technique particularly useful to introduce a particular problem from a different, more mundane prospective instead of starting off with an abstract theorethical description of the pattern itself. The anecdote is then followed by the description of the actual programming problem for which the specific pattern will be used.

Description of the Pattern and Initial Implementation

An initial implementation of the pattern in Ruby will be provided more or less immediately after the introduction of each chapter, often accompanied by a simple UML diagram. This implementation normally has quite a few conceptual flaws, which are then examined and corrected step-by-step the chapter to obtain a more “Ruby-friendly” solution.

A More Rubyfied Version of the Pattern

The final implementation of each pattern is often very different from the initial attempt, and it may contain quite a lot of Ruby-specific code. The author does an excellent job in suggesting pattern implementations which often use blocks, Proc objects or method redefinitions when needed, to make the code more succint and more readable at the same time, as all Ruby code should be.

By doing so, even people who are still learning Ruby will understand how to use some very useful Ruby idioms which can be a bit difficult to grasp otherwise.

Using and Abusing <Pattern>

Patterns are often overused and misused, and some people normally end up wondering if they should be used at all, after all. This section (present as a matter of fact in every chapter of part II an III) examines the pitfalls of the pattern and the most common mistakes developer make when applying it. It is by far the most useful section of each chapter, and that’s what I’ll be reading and re-reading every time I’m thinking about using a particular pattern in my code. As a matter of fact, these sections make you realize that every pattern has its own inherent flaws and dangers, and that it is far from being a Silver Bullet. Even when you’re supposed to use a pattern to accomplish something, be aware that something nasty can happen unless you’re extra careful: this, perhaps, is the true Golden Rule conveyed throughout the whole book.

<Pattern>s in the Wild

This is another very interesting section which is included in every chapter of part II and III. After describing what a pattern does, how it can be used and how it should be used, you’ll finally find some interesting examples taken from real world applications. By “real world application” I mean something like ActiveRecord⁷ (Observer, Command, Adapter, …), DRb⁸ (Proxy) or FXRuby⁹ (Composite), for example, i.e. important programs and libraries which are used in production environments. Personally, I was really glad to find such examples in this book: it definitely helps you feeling design patterns as something more practical and useful than pure software architecture theories.

Wrapping it Up

“Wrapping it Up” is the title of the last section of each chapter of Part II and III. It’s basically a summary of the whole chapter and thus a useful way to recap the most important concepts. I found this section particularly useful when using the book as a design pattern reference, after reading it for the first time: this section provides a quick and essential overview of each pattern—and the most important DOs and DON’Ts, too.

Part III: Patterns for Ruby

By the time you get to Part III you’ll definitely feel that Ruby can do more. Some of the Ruby implementation of certain patterns described in the book make extensive use of blocks and Proc objects, and the method_missing method (although potentially dangerous unless extra care is taken) gives us a more immediate way to obtain delegation, for example when creating Proxies. Also the fact that objects can be modified at runtime by adding and removing methods “as needed” seems quite an underused feature in traditional patterns, simply because those patterns were first conceived for languages which are very different from Ruby and are perhaps less liberal than Ruby when it comes to dynamic features¹⁰.

These particular Ruby features can be used (and abused, of course) to implement more Ruby-esque patterns, such as the ones included in this part of the book:

Internal Domain-Specific Languages
Meta-Programming
Convention Over Configuration

These are just examples, of course some may complain because the Active Record or ORM pattern are missing, but this is understandable as it may be considered too specific compared to the others. Each pattern is examined in detail, and I particularly like way the DSL pattern was described: Chapter 16 explains how to develop a simple but effective Ruby DSL from scratch for creating file backups. This can be particularly useful for people who never tried creating DSLs before, but also for developers who tried, but want to improve their skills.

Chapter 18 (Convention Over Configuration) is sufficiently clear and detailed, perhaps even too much if you already know how Rails was developed (and all the hype which follwed).

On the other hand, I was a bit disappointed by Chapter 17 (Meta-Programming). Maybe it’s because I built up extremely high expectations about it while reading the rest of the book, but it just felt too short and not detailed enough for my liking. If I had to write such a chapter (which would have been actually very hard), I would have started from an excellent post by Ola Bini¹¹ which introduces eleven meta-programming techniques, and built up content and examples from there. The only reason why ~~- I think -~~ Russ didn’t do it in his book was length/balance constraint: a properly detailed chapter about meta-programming in Ruby could easily take up over forty pages!

The Verdict

As I said in the beginning: this is not meant to be a complete, in-depth, reference book on everything you may want to know about design patterns in Ruby. That’s why, as a matter of fact, you can actually read this book all the way through without getting utterly bored. Russ uses an informal, yet appropriate style to turn potentially complex, theorethical computer science principles into easy-to-understand, useful tools which can truly improve the way you code.

The whole book flows very very nicely. I actually recommend reading this book in sequence, without skipping chapters, because each pattern is described in a way that is somehow linked to the following ones, so that you can understand and learn about the pros and cons of each one in a more natural and useful way.

OK, I would have loved to see Part III as long as Part II, probably, but overall I’m very, very satisfied of what the book taught me. The only problem is that it also made me suddenly realize all the naive design mistakes I’ve been making when coding in Ruby, so I’ll now feel compelled to fix at least some of them…

Definitely a worthwhile read, I just hope to see more books like this, or even a second edition of this one soon!

Notes

¹ Design Patterns in Ruby by Russ Olsen, Addison Wesley Professional, 2007.

² Think of Programming Ruby: The Pragmatic Programmer’s Guide, 2nd Ed. by Dave Thomas with Chad Fowler and Andy Hunt, Pragmatic Programmers, 2004.

³ Design Patterns: Elements of Reusable Object-Oriented Software, by By Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides (a.k.a. the Gang of Four), Addison Wesley Professional, 1994.

⁴ For more information on the YAGNI principle, visit You’re NOT gonna need it, Ronald E Jeffries.

⁵ See Design Patterns in Ruby, a review, _On Ruby_blog.

⁶ See Russ Olsen Interview, _On Ruby_blog.

⁷ ActiveRecord is an implementation of the Object-Relational Mapping (ORM) pattern used by the Ruby on Rails framework.

⁸ Distributed Ruby, see Intro to DRb by Chad Fowler.

⁹ FXRuby, a graphical toolkit written in Ruby.

¹⁰ This can be a good or bad thing depending on the way you look at it, and what you want to use the language for. The fact that Ruby is dynamically typed makes it easier to do things which are totally impossible in C++ or Java, but it also introduces a whole new set of potential dangers.

¹¹ Ruby Metaprogramming Techniques, Ola Bini: Programming Language Synchronicity.

Book Review: Writing Efficient Ruby Code

h3rald — Mon, 21 Jan 2008 05:47:00 -0700

The second shortcut from Addison-Wesley Professional series I’m going to review is called Writing Efficient Ruby Code. A very promising title, especially considering that this book is only 50 pages long.

As usual, this shortcut can be intended as a sort of programmer-friendly detailed cheatsheet: like the other ones in this series it sports a monitor-friendly landscape layout and does not go to deep into the details unless strictly necessary to understand a particular concept.

The Author

Dr. Stefan Kaes, the author, contributed a lot to improve Ruby on Rails’ performance by refactoring portions of its core and try to “get maximum speed out of performance-critical sections of code”. This short but interesting shortcut groups together a lot of performance tweaks, tips and tricks but also some “anti-patterns” Kaes was able to identify through his career as programming teacher Ruby software consultant and key Rails contributor.

The Contents

Like with the previously-covered Mongrel shortcut, Writing Efficient Ruby Code always goes straight to the point when it comes to identify problems. The first one mentioned is of course that the Ruby Interpreter is Slow, most people are aware of that, due to their direct experience or because this argument is normally used by non-Rubyists to argue the language’s usability in commercial projects. What you may not know is why that is so, and that’s where the first part of this book comes into play.

“Ruby is a highly dynamic language: Almost all language entities are first-class citizens in that they can be created, changed, and destroyed at runtime. This comprises classes, modules, methods, constants, and class and instance variables. Only local variables are second-class citizens in Ruby: Whether a name refers to a local variable is determined at parse time.

This makes Ruby extremely flexible, but also more complex. Whever you use a name to refer to an object, Ruby has to search for the object it refers to, and this costs in terms of processing time.

As a matter of fact, one of the most recurring tips in the book to improve code performance is the following:

Method calls are expensive, use variables directly when possible.

Keep this in mind: self.something is not the same as @something. The end result is the same, but the first way costs more in terms of performance because Ruby has to look up the method name. Similarly, local variables should be introduced as a way to “cache” the result of method calls. Often you may feel “guilty” to introduce a new variable and keep calling the same method over and over: this should definitely be avoided.

Other useful tips include, for example:

Use syntax constructs (e.g. assignments) as expressinons. Use evaluation precedences.
Use interpolated strings "... #{string_variable}" (there’s also no performance difference if constant strings are used between " or ')
Use operators which update the data structure without copying it (when possible). Use update or merge to update hashes.
Iterating using for a in A is slightly faster than performing the same iteration using each, (it is the opposite in Ruby 1.9 though)
do not use return unless you have to
test in order of expected case frequency
Use parallel assignment (a, b = 5, 6) where applicable
If a module gets included in only one other class (or module), it’s preferable to open the class instead.

I deliberately chose not to elaborate any further on the tips listed above because otherwise I’ll give a big chunk of the contents of the book itself. If you know Ruby enough, you may already know why such reccommendations make sense, but if you don’t, Writing Efficient Ruby Code can be a short but very interesting read.

The Good

For each of the 30 “coding patterns” (and consequent anti-patterns) described in the book, the author does a great job explaining the reasons of doing something in a particular way, also through examples and benchmarks, where possible.

Furthermore, this shortcut can really be useful to grasp a few difference between Ruby 1.8.5, 1.8.6 and 1.9 in terms of performance: not all the patters apply to all Ruby implementations, and when that’s the case it is clearly stated.

The Bad

My only complaint about the book is probably the lack of details and more “specialized” patterns. Everything (except for a few Rails-specific tips) normally apply to Ruby as a whole, without going deeply to analyze specific libraries or third-party gems. As a result, once you get the general idea, some of the patters may seem pretty obvious or a logic consequence of others.

It is also true that this is meant to be a shortcut, not a comprehensive analysis on code optimization techniques which can be applied to specific cases: something like this would require much more than 50 pages!

The Bottom Line

Read it, re-read a few bits of it to make sure you grasp the most important concepts, and keep its table of contents in front of you as a reminder when refactoring your code!

A Firefox Lover's Guide to Opera

h3rald — Fri, 28 Dec 2007 14:19:00 -0700

Note: This article can be considered a sequel for An IE Lover’s Guide to Firefox, which described Firefox through the eyes of an Internet Explorer fan. Similarly, this article describes Opera’s features from the point of view of a user – myself – who has been using Firefox for years and is now considering another browser switch.

I am a Firefox fan. I’ve been using Firefox since it was named “Firebird” and calling it “stable” was a big overstatement. Firefox dragged me out of Internet Explorer, and that was definitely one of its biggest achievements.

Because I’m addicted to trying out new tools, however, I always kept testing new browsers I discovered here and there. K-Meleon, Flock, Sleipnir… When Safari came out for Windows I immediately installed it and used it for about 2 hours, only to realize that it wasn’t – and it still isn’t – usable at all, mainly due to sporadic crashes.

Similarly, I’ve been trying out Opera periodically, as new releases came out, but again it didn’t seem to work for me. The biggest complaint I had was its inability to render heavily-ajaxified web sites properly. However, now it seems that the Opera Development Team made a big effort to improve the browser, and I was pleased to notice that Opera 9.5b (“Kestrel”) doesn’t seem to have this sort of problems at all.

Planning the Switch

Firefox has extensions. Plenty of them actually. Some are useful, like the newish Del.icio.us one made by Yahoo, and also crappy ones you’ll never use unless you want to have a fancy button on one of your over-cluttered toolbars which enables you to interface more easily with X or Y web services you hardly ever use.

By contrast, Opera never attempted to add full-blown extension support to its venerable and yet very powerful browser. Instead, they kept building more and more features right into its core, being careful not to undermine the browser’s two proverbial qualities: speed and stability. What seemed a doomed philosophy at first turned out to be a good thingin the long run. More and more people are getting more and more worried about Firefox’s memory issues and begin to wander off to explore new things, exactly like I did.

The first step to switch from Firefox to Opera is to reduce the number of Firefox extensions to the bare minimum you need:

Colorzilla
Web Developer
MeasureIt
Search Status
Gmail Manager
Secure Login
Del.icio.us
How many extensions do you actually use? Here’s a short analysis for the ones above:

The first three are related to Web Development only, which means that I don’t need them unless I’m doing some web-development tests during which I’m always going to have more than one browser open anyway. UPDATE: there are a few Ruler widget which can be used instead of MeasureIt (thanks Ameer).
SearchStatus gives me Alexa Rank and Google Pagerank: I think I can survive without those for a while. UPDATE: if not, there’s always SEObar (thanks Ameer).
I use Gmail Manager because my girlfriend uses Gmail on the same computer. I’m switching to Opera and she’ll stick with Firefox, so no problem there…
Secure Login? It’s called Wand and it has been built-in into Opera for the last decade or so.
Del.icio.us – OK, I won’t be able to access my favorite tags as quickly, but someone already came out with a few handy buttons for a better integration with the popular social bookmarking service.

UPDATE: For a list of the features provided by Firefox extensions which are included in Opera, see Rijk’s Top 150 Popular Firefox Extensions and Opera

Because I’m addicted to betas, I immediately downloaded Opera Kestrel, i.e. Opera 9.50 beta 1. I never actually liked Opera’s default theme, so I started looking around for new skins (yes, eye-candy matters sometimes) and came across the Ximple series by serafins. In particular, 2nd thought – Jimple quickly became my favorite.

Tabs

“Opera is the Web pioneer that delivered tabbed browsing in 2000 […]”

Opera tabs feel stable and mature. Why? Probably because tabs are used more consistently to open not only web pages but also:

Downloads (“Transfers”)
RSS feeds
Notes
Emails
Bookmarks
Widget Management
Contacts
History
Page Links

I think this is a great feature and Firefox should definitely consider it: v3.0 comes with new download and bookmark managers, but they’re still dialogs. Yes, I know, there’s probably some extension which allows you to display them in the sidebar, but that’s not the point: Opera brings more consistency to the overall browsing experience by using tabs wherever they should be used.

Additionally, Opera tabs…

Can be rearranged, exactly like Firefox tabs
Can be restored, if closed accidently, by re-opening them from the Trash can
Can be locked, meaning that they can’t be closed accidently
Can be duplicated
Can be saved in groups (sessions) and re-opened later on
Can be restored if Opera crashes

Speed Dial

When you open Opera for the first time, and whenever you open a new empty tab the Speed Dial is displayed. What I originally thought it was one of the most annoying things introduced by Opera 9 turned out to be actually useful and very addictive.

The idea behind it is simple:

Show a default page with 9 slots
Allow users to drag links to those slots
Display preview of each slot (which is cached and can be updated by refreshing the page)
Allow users to quickly access pages saved in the Speed Dial via CTRL+1 .. CTRL+9 or simply by clicking them.
Simple and effective. Once you get going with it, you’ll overcome the initial feeling of imposition and you’ll use it more and more: I literally can’t live without it now!

Right-click goodies

While I was testing Opera, my girlfriend came along and asked me to look something up on IMDB. I normally had IMDB as custom search engine in Firefox, but unfortunately Opera didn’t seem to allow users to customize their search engines…

Totally wrong. Not only Opera lets you add any search engine to the search bar, it also does it with style and in the easiest way possible:

Go to your search engine or any website with a search form
Right click the search field
Click Create Search…
Specify a name and a keyword for your search engine

Done. You’ll now be able to search that particular site directly from the search bar. As you can see, I added Wikipedia, IMDB and even the Unofficial Elder Scrolls Pages in this way.

Besides creating searches, Opera lets you do a lot by right-clicking anywhere on a page:

Block Content: Right-click an empty area of any webpage and select Block Content to select which ads, scripts and images will be blocked from now on.
Validate: Validate the HTML source code of the current page.
Translate: Translate the current page into a foreign language with just two clicks.
Open With: Open the current page in another browser installed on your system.
Edit Site Preferences…: Choose to block/allow cookies and popups, identify Opera as another browser, set a different encoding, enable/disable scripts, images, flash, etc. These setting apply to the current web site only.
View source, reload page every X seconds/minutes, send by email, etc.

Widgets

Opera Widgets must not be considered as Opera’s counterpart to Firefox extensions. Instead, Opera Widgets can be used as poor man’s Vista Gadgets on Windows XP, and they do their job most remarkably.

I’m personally very fond of these ones:

They all have a common trait: they all behave as standalone programs, as they should be. The Wikipedia one, for example, can display Wikipedia entries directly inside the widget, unlike some others which just take you to Wikipedia, which is rather pointless.

Although widgets live within Opera, they can be displayed “always behind”, which means they’ll be glued to your desktop and therefore will be visible whenever Opera and other applications are minimized.

Needless to say that anyone brave enough can make widgets for Opera by following a simple Widget Specification.

Everything you can do on the Internet

The term browser applied to Opera is somehow misleading. Personally I would have called it something like “Internet Suite”, because that would be a better choice due to the features it offers and the things it can do.

Traditionally speaking, a web browser can be used to browse web pages, read feeds (sometimes) and navigate through FTP directories. Here’s what Opera can handle:

Web Pages – No need of explanations here.
FTP – FTP directories are listed very clearly, overriding server’s settings with a more user-friendly layout.
Local Files – This was a surprise for me. Typing file:// will automatically load a list of the drives currently available on your machine. Similarly, auto-completion for directory and file names is supported! I almost started using Opera as my everyday’s file manager (almost).
Feeds – An embedded feed reader can be used to subscribe to RSS/Atom feeds and view them… in a tab, of course.
E-mails – Opera is also a pretty decent email client. As of version 9.5 full IMAP support has been added, which definitely makes the difference.
IRC – Opera can be used as an client, which works pretty well. Who needs ChatZilla anymore?
News – Opera can be used to signup and retrieve news from newsgroups.
Gopher/WAIS – Although not used everyday, Opera can handle these old protocols as well.
BitTorrent Files – By default, Opera can act as a BitTorrent client as well, so you can just open .torrent files through the program and then monitor the download progress in the Transfers window, like with any other normal download. While this feature is indeed useful, it is also possible to disable it and still use your favorite BitTorrent client.

Portability and Synchronization

Let’s spend some words about portability. Sure, there are two “Portable Opera” apps out there, and they work well enough, but one thing I’d like about a web browser is the ability to synchronize my preferences, customizations, themes, passwords etc. etc. across multiple computers. Firefox is getting there, although the technology is still at a very early stage. Opera is doing something similar through Opera Link, which allows you to synchronize automatically your Bookmarks, your Personal Bar and your Speed Dial. All you need is to get a (free) Opera account, login to Opera Link and enable the synchronization feature from the File menu. From now on every time you’ll modify your Speed Dial or Bookmarks, the changes will be sent to your Opera Link page. Similarly, whenever you start using opera somewhere else, if you login to your Opera Account you should be able to synchronize your Bookmarks and Speed Dial.

Here are some thoughts on this type of technology:

It’s not totally private yet. While it’s great to be able to sync bookmarks and speed dial, the problems arise when you finish using your friend’s computer for example… what happens to the bookmarks you just sync’ed? The only way to delete them would be to have your friend to log in to his Opera account and re-sync them. Not enough privacy for my liking.
Your passwords, notes, widgets, etc. etc. cannot be synchronized yet, but that will hopefully be possible in near future.
Sync’ing bookmarks is pointless for me. Although Opera still hopes to compete with Del.icio.us & Co., that will be very hard to achieve. I stopped using in-browser bookmarks long ago.
Link seems and interesting feature considering that Opera is available on virtually any operating system and a lot of different devices (mobile phones, Nintendo DS & Wii, …).

At any rate, it is still possible to “carry around” your personal opera settings by following the instructions provided on this page which explains pretty much everything you need to know aboud Opera files and local storage.

Advanced Features

Opera looks more “polished up” than Firefox in most cases. The superb usage of tabs for nearly everything is one example, and another one is the possibility to apply skins (themes) on-the-fly, without having to restart the browser. Firefox can do this via the Personas extension, but Opera had this built-in for a long time.

To apply a new skin:

Go to the Skins Directory
Download a skin you like
Opera will download and apply the skin immediately, and it will ask you whether you want to keep it or not. If you choose not to, it won’t save it in your profile (very useful for quick previews). Neat.

Another quality opera always excelled to is accessibility. Besides using the interface in the traditional way, it is also possible to:

Use mouse gestures – I wasn’t a big fan of this until I bothered reading the excellent documentation Opera provided for them (which is significantly better than the Firefox’s equivalent). It can be quite useful at times.
Use keyboard shortcuts – Believe it or not, you can literally use Opera without a mouse.
Speak to it – Opera’s voice integration is getting better and better. Not only you can effectively tell your browser what to do, you can also use the built-in text-to-speech function (Windows only) to have it read entire pages for you. It actually works quite well and it can parse punctuation well enough to apply the right intonation. Just for fun, I had it read it an Italian page… and it actually worked as expected: it was like listening to an American reading an Italian text using US pronuntiation!

Finally, power users will be delighted of the way opera lets you hack the program settings, as you can:

Use Tools > Quick Preferences to block/unblock popups, cookies, Java applets, images, etc.
Use Tools > Advanced to access detailed information concerning cookies, cache (it lists every image/object cached!), plug-ins, Wand passwords, etc.
Use Tools > Appearence… to access and manage appearance-related settings, like skins, toolbars, buttons and panels
Use Tools > Preferences… to access general preferences (all the rest)
Type in opera:config to view and tweak Opera’s internal settings, somehow like Firefox’s about:config, but much cleaner and easier to use.
Download the Developer Console to have a simpler alternative to Firefox’s Web Developer Toolbar extension, to view DOM elements, CSS and Javascript information.

Annoyances

After using as main browser for a few weeks now, I can say that it’s great but not perfect yet. It’s very advanced, faster and more mature than any other browser, of course,but there are a few things which should be fixed or improved.

In particular:

It’s not open source – This may not matter to someone, but some people consider this an essential requirement for their browser, and that’s why Firefox is their most obvious choice. Although Opera is free, it is proprietary software after all, which means is definitely not as open as you may want it to be. Personally I’m not too bothered, as I’m starting to think that too much openness may lead to too many unuseful and bloated extensions and make the program somehow “unpredictable” and heavy.
No address bar search – Amazingly, only Firefox seems to have this feature built-in. I’m referring to the ability to type whatever in the address bar to be redirected to the site returned by a Google’s I’m feeling lucky search. It is possible to emulate this feature in Opera by creating a custom search for I’m Feeling Lucky and assign it a short keyword like “l”. In this way, for example, typing in l h3rald should lead you to this website. Not quite as immediate as in Firefox though.
No find as you type – Another big disappointment for who comes from Firefox or Safari: Opera still uses a dialog box to perform page searches.
No spell clecking – Again, both Firefox and Safari now offer text fields spell checking. Opera doesn’t yet.
No HTML mail composer – Opera’s built-in mail client can display HTML emails but doesn’t yet allow users to create them.
Auto-start widgets? – This is a feature enhancement Opera Dev Team should consider: allow users to configure certain widgets to start automatically when Opera starts.
Google Reader + Flash problems – Sometimes I experiences some scrolling problems when reading news which contain embedded flash movies on Google Reader.
Corporate Sites – Unfortunately some corporate web site do not support Opera or are not displayed correctly in Opera. Unfortunately there’s nothing much we can do about it but trying to “mask” Opera as another browser (via right-click > Edit Site Preferences…)
Default Browser Problems – Setting Opera as default browser on Windows doesn’t seem to set the file icons accordingly (or worse, it resets them to the default file icon).

ERRATA:

It is possible to have Opera to redirect you to the right after typing a few words in thr address bar by setting Google’s “I’m feeling lucky” as default search engine (thanks EJ902).
Spell Checking is supported via GNU Aspell Ospell for inline spell checking _(thanks Dava).
Find as you type can be triggered by pressing . and typing (thanks cvm).
It is possible to auto-start widgets by saving a session with all your widget open and reloading it at every startup [CTRL+F12 > General > Startup > Continue saved sessions] (thanks Tamil & Ameer).
As of the latest snapshot, setting Opera as default browser and handler for HTML files doesn’t cause any problems thanks Ayush).

Conclusion

Despite the few annoyances listed in the previous section, Opera 9.5 beta 1 truly impressed me. I was waiting for Opera to get better before switching and now I’ve not been using Firefox for a few weeks. Although Opera offers a lot of features, there’s still room for improvements, especially for what concerns integration with third party services: I would really like to see some sort of integration with del.icio.us, and that could be possible via widgets at least. Regarding the new Opera Link feature, it looks very promising and a potential competitor for Mozilla Weave even though it will be used mainly to get more and more users to register to the Opera community (I did, at least), which is indeed very active any way.

To conclude this article, which still barely scratches the surface of this very powerful application, I’d like to praise two more things about Opera:

Their website network, and in particular their truly excellent documentation knowledge base, which is very comprehensive of references, tutorials and interesting articles. I am a full time technical writer myself, and I’ve hardly ever come across better documentation.
Their extensive support and compliance to web standards, which makes Opera the most advanced browser ever made.

If you’ve not tried Opera before, or if you’ve always dismissed it because “X browser is better”, you may want to give it another shot: for me it was definitely worthwhile!

Book Review: Mongrel Digital Shortcut

h3rald — Sat, 15 Dec 2007 03:42:00 -0700

If you ever considered about developing an deploying a Rails application in the last year or so, you must have heard of Mongrel before. If you didn’t, I’d recommend you learn more about it because up to now it proved to be one of the few essential ingredients for deploying scalable Rails applications.

Mongrel is a creation of Zed Shaw who started writing a replacement for FastCGI to use with Rails, and ended up creating a brand new, HTTP web server who turned out to be one of the best things the Rails community ever saw happening.

It was created to be simple to use and configure, nevertheless it does require some skill to set it up and tune it. Documentation is there, along with plenty of blog posts, but there’s also an interesting book from Addison Wesley Professional which is definetely worth a read.

“Mongrel: Serving, Deploying, and Extending Your Ruby Applications” – that’s the title of the book. A Digital Shortcut, 100-odd pages long, in landscape format to make it easier to read on a computer, straight to the point with no added sugar for just 15$ (PDF only). I must say Addison Wesley got it right: the book’s format is, as a matter of fact, optimized for web developers, especially those who can’t afford to read a 500-pages book covering everything about a subject just to find that one thing they don’t know about. This shortcut can be seen, essentially, as an expanded cheatsheet which will teach you the basics about Mongrel and also give you plenty of advice on how to learn more about it.

Let’s have a closer look at it.

Overview, Introduction & Getting Started

The first three ~~chapters~~ sections (there are no chapters, just sections) of the book are meant to be a gentle introduction to Mongrel and its world. The main author is Matt Pelletier, but Zed Show’s contributions are definitely one of the book’s best selling points. Zed’s thoughts are scattered here and there in many sidebars throughout the book (there’s at least one in each section): you’ll see an odd-looking face (Zed’s self-caricature) with some text next to it; when you read it, you’ll notice that they are actually Zed’s own thoughts, straight from his mind, with no editorial filter whatsoever in-between. Be warned: the text included within the Zed Sez sidebars is highly opinionated, that’s precisely what Zed feels to say about something, and he’ll just say it: just the plain, simple thoughts of an experienced programmer. As the author explains in Section 1: “[…] You may not agree with everything he says, but you probably should.”

Section 2 is a general introduction about Mongrel. It explains what it is, when and why it was made, and how it works. There’s nothing new to learn if you already used Mongrel before, probably, but it’s definitely the first thing to show to someone who’s new to Mongrel and its world, and possibly a bit skeptical about it. The last subsection “What can Mongrel do for me” is an attempt to ~~brainwash~~ persuade you to fully embrace Mongrel and its philosophy, whether you are a developer, a sysadmin or even a manager: assertions like “Mongrel is pretty damned secure.” and “Mongrel’s license is capitalist-friendly.” will definitaly make some of you (managers) happy.

Section 3 is slightly more juicy than the previous one, as it explains how to install and use Mongrel. Basically that’s what everyone who ever used it already knows, but it’s still necessary for the book’s consistency, after all. After reading this section, you’ll probably have your first Mongrel up and running and serving your little Rails application’s pages, and you’ll begin to wonder why the hell you need to keep reading this book now that everything seems to work already…

Section 4: Configurations

…aka “a truly useful Mongrel cheatsheet”. This section dives deep(er) into Mongrel’s configuration by explaining what each start parameter does in detail. The parameters are presented in tabular form in a very well-organized way. As you would expect from an high-quality cheatsheet.

Then the author will explore a few commonly used deployment scenarios, in particular:

Standalone – The simplest configuration possible, with just one Mongrel instance serving both static and dynamic pages.
mongrel_cluster – How to use “a pack of mongrels” together to handle more traffic.
Behind a static web server – The most common (and most scalable) option, used to serve static content faster using a front-end server and use Mongrel only to handle Ruby pages.

Towards the end of the section, for the developer’s delight, the author will discuss two common, useful scenarios where Mongrel can be used:

Apache 2 + mod_proxy_balancer + mongrel_cluster
Nginx + mongrel_cluster

The difference here is that detailed instructions are provided on how to setup and configure each server, including example file sources. This can be particularly useful for the Nginx example, as most of the documentation for this fantastic, lightweight Mongrel fron-end is scattered around the web (or written in Russian in a well known place).

Section 5: Production Deployment

This section introduces one of the most important part of the life cycle of a Rails application: the deployment on a production server. The author is pretty honest about the whole subject:

“You will not do this in a day. If you are expecting to code until 1 minute before your deadline and then simply point and click and have an instant server then you need to take some kind of medication because you are violently hallucinating. You will need at least a week of 8 hours days to make sure your first deployment works and to have the time to do it right.”

Sounds terribly true. Especially for larger projects demanding good performance under heavy traffic. Scared? Probably, if you never deployed a Rails application “properly” before, but at least the book comes to the rescue by providing an overview of what you need to perform a deployment and why it is such a complex and delicate process.

Not only this, but also a “Best Practices Rubric” is also provided for the developer’s own private enjoyement. It’s written as a list of questions like:

11. Do you have a shared location where you can document the deployment, such as a Wiki or CMS? 12. Do you know how to use httperf or ab and know what the statistics mean?

After these 13 questions, the author provides the key to give a meaning to your answers:

“For each question you answer with “NO”, add 10 hours to your time estimate for completion. This may seem unrealistic, since saying “NO” to everything means it’ll take 190 hours (about one month), but this estimate is actually low according to most first deployment experiences.”

If you answered “NO” too many times to these questions, you may want to read on through the next subsection which states 17 “worst practices”: an invaluable read for beginners!

But after all this section is not only about stating the obvious (…right?): a full example scenario is describedand examined throughly to give you an idea of how a deployment should be made, using three different machines:

One for Apache (as a front-end to Mongrel)
One for the Mongrel cluster and the Rails application
One for the database

Maybe something you’ll never do if you just want to run your grandma’s site on Rails, but certainly something you may want to start looking at if your grandma becomes really popular and your small server gets grounded by several thousands of visitors per day.

The last part of the section will give you a brief introduction on monitoring your applications and on which tools you should be using, although it does not discuss the subject in detail at all, it’s just meant to point you to the right direction.

Section 6: Extending Mongrel

This section digs deeper into the software code internals and describes how to teach new tricks to your Mongrel, i.e. how to extend its functionality.

Before you begin, though, don’t forget what Zed himself has to say about Mongrel’s simplicity:

“I’ve always had a different aesthetic sense when I write my software. I value simplicity and directness and try to write software that follows this approach. I jokingly call it the Shibumi School of Software Structure. All I do is apply this rule: When given two possible designs with equal end results, pick the simpler one. I then ruthlessly strip the solution down to its finest elements, but no more.”

Mongrel’s architecture is not that complex, and this section is sufficient to get you started by providing an overview of the main classes involved (HttpServer, HttpRequest, HttpResponse, HttpHandler, URIClassifier), and how they work together. Note that the book won’t describe anything about the APIs of these classes. but after all, the project’s RDoc documentation should cover all the details you need.

The rest of the section focuses on how to extend Mongrel, by:

Writing custom handlers in Ruby
Creating custom filters to perform security checks, clean up requests and preliminary file processing
Creating plugins and distributing them as rubygems

Two working examples are also provided:

An example handler to deflate content (if the browser supports deflate)
An example “duck” plugin, to make Mongrel quack like a duck when it’s started (not the most useful thing in the world, but serves the purpose)

Debugging, Performance & Security

The last three sections deals with other important aspects concerning the deployment of your application, how to debug, how to improve performance and how to secure your application.

Section 7 introduces two debugging modes:

Dash-Bee logging (-B)
USR1 logging (lighter)

And also gives you an idea on what to look for when debugging an application. Nothing too detailed, granted, but enough to make sure you are pointed in the right direction.

Again, Zed’s wisdom and wit are remarkable:

“These people’s problem is they suffer from Potpourri Turd Syndrome—a belief that their you-know-what don’t stink and smells like fine dew on freshly cut grass. Whenever there’s a bug, they go running like kids in a candy store to other people’s code trying to find fault and just assume that it’s nothing they wrote. […] When you run into a problem with your application, always assume it’s your fault first. Mongrel’s not perfect, but its code is minuscule compared to the size of Rails and most likely even your own appli-cation code. Mongrel also powers many large and medium deployments without any problems. If there’s an error, the evidence already says it’s in your code, so bite the bullet and start investigating it as if it’s your problem.”

Similarly, Section 8 is a short but useful overview on performance tips and tricks and deployment tuning. The most useful thing is probably the checklist of the “tuning process”, which illustrates the simple steps to take to tune your application.

Finally, Section 9 addresses some common security concerns and clarifies how Mongrel deals with them. The answer is normally “Mongrel strictly does this” or “Mongrel doesn’t support this feature”. After all, you should have understood by now that Mongrel is an example of simplicity and that it deliberately does not aim to offer all the feature you’d expect by a server like Apache:

“As you probably see, Mongrel say, “No” in many places where most Web servers say, “Yes, OK.” Sometimes this is because no one using Mongrel has needed it yet, sometimes it’s because there’s a better, simpler way to accomplish the same goal. Mongrel is a different kind of Web server, and frequently you can solve your problem with a different solution.”

Conclusion

If Mongrel is opinionated software, this is definitely an opinionated book which fully embraces the project’s philosopy of simplicity above everything else. It’s an interesting read and it won’t bore you to death by deliberately skipping long and potentially tedious subjects and adding interesting insights instead (like the Zed Sez sidebars). Perhaps it is a bit too direct towards certain people, who may get even get offended (as planned) by some of the author’s assertions.

Despite being a 100-pages book, this shortcut covers pretty much everything you need to know about Mongrel. It will not teach you everything about deployment, security, performance tweaks and debugging though: as the authors often state throughout the book, a lot of (big) books are available on those subject, and it wouldn’t make sense to even attempt to discuss them in this shortcut.

Similarly, you won’t find complex examples either, but that’s acceptable because simple examples are often the only thing you need to grasp the basics of a concept or feature, and then use them as a “scaffold” for your own code.

Globally, the book is well balanced and optimized for its size: lightweight introductory sections at first, then the “real juice” in the middle, and a few overview sections on advanced topics towards the end. You can read it easily in a few hours, perhaps less, and whenever you need to look something up in a hurry it will be fairly easy to locate.

A good read, and a must for everyone who wants to learn more about Mongrel or Rails deployment.

A closer look at Komodo Edit

h3rald — Sun, 25 Nov 2007 07:23:00 -0700

What’s your favorite code editor?

This is a common question which still keeps popping up on community boards, mailing lists, comments, etc. Every programmer who writes code in some programming language normally has an editor of choice. Being realistic, most of the times it’s not only one program but several, depending on the language and on the features needed at the time. Yes, great, but how do you choose your favorite editor? By trying a lot of them of course: that’s what I’ve been doing since I started programming. Lately I’ve become fond of Vim (or better, gVim), although I have a few other editors I may recommend, e.g.:

Recently, however, I came across my n^th “what’s your favorite editor” thread and someone mentioned Komodo Edit. I knew of it already, actually, but I never had a chance to give it a proper try. ActiveState is well known mainly for two things:

Their effort in offering a lot of commercial, windows-based Perl libraries
Their commercial IDE, Komodo IDE, which I personally tried quite a long time ago

The problems of Komodo IDE are foundamentally two:

It costs money – this is not great in a world where Eclipse and Netbeans are free
It is an IDE – which normally means ‘heavy as hell’.

It’s a matter of taste and needs: some people feel more confortable with using an editor for certain tasks, while sometimes an IDE may be the best solution, despite its potential slowness and bulk.

Komodo Edit solves the above-mentioned problems because:

It’s free
It’s an editor

Actually I wouldn’t call it an editor, because it offers quite a lot of features which are normally absent in editors—it’s something in-between, which definitely deserves a try.

User interface

Komodo Edit’s interface is one of the most clear I’ve ever come across. It is organized in four main areas plus the top menu and toolbar (which only has the buttons you REALLY need, unlike Notepad++’s 31-button-bar).

The central area is for editing, the left pane is for the Project browser, the right one is for the Toolbox and the bottom pane is for command output. Luckily enough, a set of handy little buttons is provided in the toolbar to show and hide each pane. I normally only use the Project Browser and the main editing area, leaving the Toolbox and Command Output panes hidden, but that’s up to you really.

Komodo Edit allows symultaneous editing of multiple documents, which means that it has tabs like most of the best editors out there. Furthermore, it is possible to have Komodo re-open the files edited in the last editing session, saving you a lot of time. Granted, a lot of IDE do, but this is NOT an IDE, remember? It’s an editor, or at least it is advertised as such.

In reality it has most of the power of a full-blown IDE though normally remaining under the 60K memory usage (out of 2GB of total RAM)—which is not that bad, considering what Eclipse and NetBeans need. Out of all the extra features offered by Komodo IDE, the only one I truly miss is the Code Browser. Other than that, it quickly became my editor/IDE of choice (when gVim isn’t looking, of course…)

Lets find out why…

Editing features

Komodo Edit comes with all the editing features of ever average editor, so “[…] Code commenting, auto-indent and outdent, block selection, incremental search, reflow paragraph, join lines, enter next character as raw literal, repeat next keystroke and clean line endings on “save”.”, it uses Scintilla as main editing component, which makes it a close relative of Notepad++, Notepad2 and of course SciTE when it comes to understanding languages and syntax highlighting.

This is good, of course, as Scintilla is an excellent editing component, but – I have to say this – not as good as Vim when it comes to syntax highlighting (nothing is as good as Vim though, so I can’t really complain!). As you can see from the screenshot I included earlier on, it is possible to change the default black-on-white color scheme to something more stimulating and energy-saving. This doesn’t mean I have to manually re-set the color of each element, it actually comes with a black-background scheme, which is handy.

Supported Languages & Syntax Highlighting

Komodo Edit supports quite a few programming languages, which means it can recognize the most common ones (C, C++, Java, PHP, Python, Ruby, Perl) but it also smart enough to notice framework-specific syntaxes like Smarty, Django or RHTML. Like every scintilla-based editors, it sports a nice HTML multi-highlighter which allows you to keep putting all the Javascript, CSS and server-side scripting into the same file, GREAT! No, you probably wouldn’t want to do that, but it’s a good thing to have.

Auto-completion

What makes this editor a really handy tool is its auto-completion capabilities. Why? well, because it supports:

Ruby: require, class modules (on . and ::), class variables and methods, method calltips.
Python
Perl
PHP
XSLT
XML
Tcl

Why is this so special? Well, because if you want this you normally need an IDE, and if you want it for Ruby AND Python AND Perl your choices are very limited. I played with the Ruby auto-completion features quite a bit, and I’m actually really impressed.

It can suggest what to write through calltips after a require directive, after a . and a ::, and hitting CTRL+SPACE (or just tab if you configure the right option) will auto-complete what you’re writing, be it a language keyword, a variable of any kind or a method. Additionally, it comes with “soft characters support”, which means it will try to match ( [ { when possible, allowing you to write over the completed character if you want to.

Syntax Checking, Vi/Emacs key bindings and code folding

The heading is almost self-explanatory here: Komodo Edit supports code folding (you can even chose the folding chracters!) for all its supported languages, syntax checking (it can detect and display errors before running the script, very useful in Ruby, and hard to find in other editors) and Vi/Emacs key bindings. It also offers “vi emulation”, which is constantly improving through every release – so you won’t forget Vim’s keys when I don’t use it: very nice, and again, hard to find in other editors, nevermind IDEs!

Projects and Tools

The Project Browser and Toolbox are two features which are normally presents in IDEs and which are normally not found in editors. Granted, some editors like PSPad do indeed have “projects”, but most of the others don’t. A project in Komodo Edit is normally composed by:

Some Live Folders including all the source files of the application you’re developing
An optional set of tools, commands, snippets and other goodies which may help you coding that particular application.

It is possible to create these tools by clicking the Add Item to current project button in the Projects toolbar or by clicking the Add Item to Toolbox button just over the toolbox. Either way, you can choose among the following:

File/Remote File

Add a file on your local machine or a remote file hosted on a server you configured via Edit > Preferences > Servers. Supported protocols are: FTP,FTPS, SFTP, SCP.

Folder

This will not link to a folder and import local files in Komodo, instead, it will create a container for other tools, not for local files.

Live Folder

On the contrary, a live folder links to an actual folder on your machines, and all files and directories inside it are automatically imported. Note that it is possible to choose to include or exclude certain files or directories from being imported by right-clicking the folder and editing its properties.

Command

This will create a shortcut to a command to execute. It is possible to specify its parameters, the directory where it will be run, whether its output will be displayed in the Command Output or in a newly-spawned console window, etc. etc.

Snippet

TextMate fans will love this. Komodo will let you create a code snippet for later use. Furthermore, it is possible to specify “tabstops” to automatically select certain words when tab is pressed (so you can effectively fill in only particular fields of the snippet).

Template

A simple but effective way to create code templates.

Url

A link which will open a given url.

Open… Shortcut

This will popup an Open File dialog in a direcxtory of your choice.

Macro

For those who require even more customization, it is also possible to record or code macros in Python or javascript, and then configure their key bindings and triggers.

Custom Menu/Custom toolbar

This was really impressive. Sure you can group all your tools in folders in your current project or you can create them in the toolbox to make them available all the time, but it would be cool if the editor itself could make those tools available by default in a toolbar or a menu. Well, that’s possible: all you need to do is create a new custom menu or toolbar and populate it with your tools by drag and drop. Very, very nice!

This mini-framework to create custom tools can be used to create project templates in a blink. To show this concept, Komodo Edit comes with a Rails template with almost all the tools you need when coding a Ruby on Rails application:

Create/delete database
Generators
Migrations
Run server
Example view snippets

Conclusion

Komodo Edit is an interesting editor which offers a lot of features which are normally only available in IDEs at a smaller memory footprint. Granted, when I want to jot something down I still prefer to fire up gVim, but for a serious coding session, Komodo is the right choice. Its close attention to details and its ease of use make developing an even more pleasant experience, although perhaps there’s still room for improvement, if you’re really fussy.

Sometimes when you start getting used of its advanced features, the lack of a code browser seems a real shame, but after all, ActiveState must sell their IDE to someone at some point!

Another thing which I would have liked is the ability to create new syntax highlighting schemes, which Notepad++ and VIM both offer. Whydoes it bothers me so much? Well, because I’d like a Textile syntax highlighting scheme for writing blogs and articles. VIM and Intype seem to be the only ones which offer it out-of-the-box, but there’s no trace of it in Komodo Edit.

Actually it is possible to create new syntax highlighting schemes and extend Komodo Edit via XUL extensions, exactly like Firefox. After a closer look, the Django syntax was added in this way.

Unfortunately there aren’t that many extensions available for Komodo Edit, yet, but the Activestate Community seems very active, so you never know. Additionally, the recently-started OpenKomodo is a new project created by ActiveState to “[…] create an open source platform for building developer environments. ActiveState has open-sourced elements of Komodo Edit, a free multi-language editor for dynamic languages based on Komodo IDE, to create the Open Komodo code base”. A new competitor for Eclipse and Netbeans will be available soon?

Book Review: Humble Little Ruby Book

h3rald — Wed, 03 Oct 2007 05:53:00 -0600

After reading the very first paragraph of Mr. Neighborly’s Humble Little Ruby Book (HLRB for short, from now on) it was very clear to me that it was going to be quite an unconventional read:

“Yes, there is a Chapter 0. There is a little bit of introductory stuff we need to talk about before we set you loose on Ruby. You wouldn’t want to get psyched about a new gadget, get it home, and then figure out you need batteries, a grapefruit, and the ability to speak three languages to even open the box would you?”

That reminded me immediately of Why’s Poignant Guide to Ruby. without a doubt. I don’t know how it is possible that two witty, crazy, and very inventive guys grew fond of the same programming language. Anyhow, to reassure a few of you, you won’t find any foxes or chunky bacon cartoons in HLRB, just some very well made (although still pretty unconventional) diagrams like this one:

Got the picture? Good. Let’s move on…

Chapter 0: What’chu talkin’ ‘bout, mister?

Chapter 0 is like an introduction to the book and a place to put all the boring stuff you have to talk about in a book about a programming language:

What is Ruby?
Installation procedure (on Windows, Mac OS X and Linux)
Hello, World!

Yes, you can skip this one safely without losing too much, unless of course you still need to install Ruby on your machine.

Chapter 1: Welcome to Ruby.

“This section aims to introduce the syntactic sugar and linguistic misfortunes of Ruby in the quickest manner that will still allow for a full education on the subject.”

As the first two lines of this chapter say, it’s time to learn the basics of Ruby. You’ll be quickly guided through strings, numbers, collections and variables. Every section with tons of code examples for your to play with. You won’t find a full list of all the 876 methods of the String class, but you’ll certainly learn the 10 most common ones at least (numbers are random, so no, don’t count them). Sure, yes, right, whatever… if you really want you can skip this chapter too, but if you are already a Ruby Guru there’s probably no need for you to read books about Ruby, right? Beginners need to read this chapter. It’s compulsory, really, and pretty enjoyable, too.

Chapter 2: Break it down now!

Or “learn how to segment your code” using methods, and… blocks & Proc objects! Gosh. Our poor newbies will probably have a heart attack if they never heard about blocks and closures before. I almost got scared myself, because this is normally regarded as a pretty tough topic. Despite, at page 25 of the book you’ll have to face your fears and dive into it. You’ll survive, anyway.

Purist Warning: Please be aware that sometimes the author may decide to use certain terms and construct which may not sound 100% right to your ears. Just move on, beginners will understand more things like “Think of Proc objects as blocks that are pushed into variables.” than anything else, guaranteed.

After this section you’ll finally be introduced to Ruby classes. Now, this can piss someone off, no doubt. Ruby is a fully OO language, so people must learn about classes before anything else. I must admit I was a bit confused by the ordering of the topics at first, but if someone comes from a non-OO background he’ll probably find this particular order more suitable. This section will cover class and object basics in Ruby like defining classes, instantiating objects, access control, methods, attributes, scope, duck typing. Finally, you’ll briefly look into modules as well.

Chapter 3: Hustle and flow (control)

Finally, the author will deal with flow control. So things like if, case, conditional operators, loops and statement modifiers. In my opinion this section is truly excellent: it introduces all the control structures in a very simple and crystal clear way, often using flowcharts. A great chance even for absolute beginners to understand these basic but powerful concepts. Towards the end of the chapter, you’ll also learn how exceptions work: a clever way to tell people “you have to learn how to use exceptions from the very beginning”. Really nicely done.

Chapter 4: The system beneath…

Here comes the juicy stuff. Up to now you learnt the usual boring things you need to know when learning a new programming language, now finally you learn how to do real things. The chapter is full of complete and meaningful code snippets which will answer nearly all the questions you may have (at this time):

How do I read and write to a file?
How do I handle threads and processes?
How do command-line parameters and environment variables work?
How can I perform specific Windows-only operations, like reading and writing to the Registry? What about OLE automation?

Some of the big books out there will not spend too much time talking about Windows-only libraries, but I found HLRB gives quite a comprehensive introduction about them.

Chapter 5: Looking beyond home

More juicy stuff. If you are looking for a tutorial to learn the basics about networking, from from sockets to FTP to POP and web services, look no further: this chapter does a very remarkable job introducing various network-related libraries, with the usual well written code examples. If that’s still not enough, you’ll also have a chance to explore the wonderful world of distributed Ruby and of databases. Granted, this chapter won’t tell you about the 1567 methods available in ActiveRecord (buy a copy of Agile Web Development with Rails for this), but will tell you enough to get started.

Chapter 6: It’s a Library!

The final chapter will go more in depth on some more advanced topics, like:

Strings
Regexp
Date & Time
Hashing and Cryptography
Unit Testing

Everything with more and more useful code snippets.

The Appendices

Last but not least, a HUGE collection of links and resources to learn more about Ruby, and a quick digression on C/C++ extensions… not much, but enough to wet your appetite.

The bottom line

HLRB is not the only book you need to read about Ruby. It’s better to make this clear otherwise I’ll be hunted forever by Dave Thomas, Chad Fowler, DHH and all the other excellent Ruby hackers who also wrote very successful books (which I bought as well). HLRB is LITTLE and HUMBLE, after all: it doesn’t aim at becoming the official Ruby Bible anytime soon (although a bird told me it may get updated someday and include more stuff), but it is still a worthwhile reading.

And of course I came to the very end of this review without mentioning the most important thing: this little wonder is free. All you need is to register to InfoQ (for free) and grab your free copy. If you want you can buy a printed copy for just $9.95, if you feel in a good mood (please do).

The most obvious strengths of this book are the abundance of code examples and very useful working snippets, and the unconventional style which makes it very readable and not boring at all. If I were to name some of its weaknesses (but only if you force me to), I’d say some parts should be expanded and more info on other libraries should be provided… but you never know what the future will bring us!

Well done, Mr. Neighborly!

RedBook - A simple Ruby program for your daily logging needs

h3rald — Sat, 29 Sep 2007 14:05:00 -0600

Logging your daily activities is important. If you don’t believe me you’d better check at least these three posts on LifeHacker, which feature different scripts and applications:

I had a look at each one of them, and I believe they are quite useful, although I didn’t really find what I was looking for. Why? Well, for example:

I don’t believe a GUI is necessary—you’d better off with just a shortcut key or command to run from Launchy or QuickSilver, that’s much faster.
They just log timestamped messages on a file, there’s no real way to search through them and display them except by using a test editor
They are Windows only—not that it matters for me, but others may not be happy about it.

That’s why I thought I’d roll out my own: meet RedBook. Let me say it’s nothing fancy: I’m not a full-time programmer but I do like playing with Ruby during my lunch breaks at work, so that’s why RedBook is just a humble, tiny Ruby script. This automatically makes it cross-platform: you can install Ruby very easily on Linux & alikes, Mac OS X and Windows. Furthermore, if you are on Windows and for some weird reason you don’t want to install Ruby, you can just try out the packed EXE file (made with RubyScript2Exe)—it’s about 2MB, but you won’t need anything else.

How It Works

The program uses two YAML files, one for configuration, which must reside in the same directory as redbook.rb (or redboo.exe) and one for the log itself, which you can place anywhere, provided that you edit the configuration file accordingly. For information on how to install RedBook and how to configure it, you can check the manual.html (powered by TiddlyWiki) file provided with the program or browse it online.

When started, RedBook will load both the configuration file (config.yml) and the whole log file into memory—it’s not a big deal, considering that they are only text files after all. I did a test with a log of quite a few MBs, and it was fine.

You can then start input commands right away, following a few sample rules. RedBook has a (very) rudimentary parser which is able to detect keywords, i.e. alphabetic strings prepended with a colon. RedBook commands look like this:

:log This message will be logger :tags tag1 tag2
:select :last 15 :since January
:save /home/h3rald/backup.yml

If everything goes OK, RedBook will reply with some sort of response, an acknowledgement, a list of messages, etc.

Simple.

Here’s basically what the program can do:

Log any message to the main log file. Messages can be tagged with one or more tags and will be automatically timestamped.
Load/display a list of logged messages on the screen. It is possible to filter messages by specifying a time span, a string to search in the message text, or a list of tags.
Dump loaded messages to a TXT, CSV or YAML file (you can even backup your log saving it to another YAML file in this way).
Calculate the time elapsed between two or more tasks. Time will be displayed in years, months, weeks, days, hours, minutes and/or seconds as necessary.

How? Here’s a short tutorial…

A Quick RedBook Tutorial

Let’s assume you are able to run RedBook on your system by now (if you can’t find some of the gems which are required for it, you can download them packed in a ZIP file from here).

Here’s what happens when you start the program:

Good. Let’s start logging something then. Just use the :log keyword, followed by a message, and then you can also add the :tags keyword followed by space-separated tags, like this:

RedBook >> :log My first message :tags test
>> Logged.
RedBook >> :log This is another message
>> Logged.
RedBook >> :log This is another message :tags test another_test
>> Logged.

Try waiting a few seconds between each message. These three messages will be appended to the log file. You could open it in an editor, but it’s normally easier to display them directly inside RedBook, like this:

RedBook >> :select
1 Sat Sep 29 2007 – 09:09:32 PM My first message [test]
2 Sat Sep 29 2007 – 09:10:51 PM This is another message
3 Sat Sep 29 2007 – 09:11:45 PM This is another message [test][another_test]
>> 3 messages loaded.

Easy. What if you have hundreds of messages? Well, the :select operation can take an optional search string, or you can tell RedBook to load only those messages tagged with one or more specific tags, like this:

RedBook >> :select :tags test
1 Sat Sep 29 2007 – 09:09:32 PM My first message [test]
3 Sat Sep 29 2007 – 09:11:45 PM This is another message [test][another_test]
>> 2 messages loaded.

Or you can use the :from and/or :to keywords to specify a certain time frame, like this:

:select :tags test :from ten minutes ago

:select :from last week :to 2 days ago

RedBook includes a very nice “natural language date/time parser”, Chronic which is able to convert sentences like the following into Ruby Time objects:

6 in the morning
friday 1pm
sat 7 in the evening
today
yesterday at 4:00

It’s not perfect (and it’s in pre-alpha as well), but it does the job, for what I can see, and it makes it very easy and fast to specify timeframes.

After executing a :select command, two other operations can be performed on the loaded messages: :calc and :save.

:calc calculates the exact amount of time elapsed between two or more tasks. Do you remember the numbers on the far left of each message? Think them as temporary IDs for the actual messages, and you can use them to select specific tasks when executing the :calc operation:

RedBook >> :calc 1 3
1 Sat Sep 29 2007 – 09:09:32 PM My first message [test]
- 2 minutes and 13 seconds.
3 Sat Sep 29 2007 – 09:11:45 PM This is another message [test][another_test]

Similarly, if no IDs are specified, :calc calculates the time difference between each message and the previous:

RedBook >> :calc
1 Sat Sep 29 2007 – 09:09:32 PM My first message [test]
- 1 minute and 19 seconds.
2 Sat Sep 29 2007 – 09:10:51 PM This is another message
- 54 seconds.
3 Sat Sep 29 2007 – 09:11:45 PM This is another message [test][another_test]

Finally, you can save loaded messages to a TXT, YAML or CSV file, as follows:

RedBook >> :save log.txt
>> Saving…
>> Saved dataset to “log.txt”
h If you want to backup your log, you can load all messages and then save them to a YAML file. Maybe in this case you want to append the :silent keyword to the :select command, so that messages won’t be displayed on the screen.

Conclusion

RedBook is just a simple program: it suits my needs for now, but of course there’s roo for improvement. If you have some useful suggestions, or you want to contribute in some way, feel free to contact me!

Home Page | Development | Download