Thu, Jul 13, 2006
Honestly, it failed to grab me. It looked like a nice enough language, but its syntax is sort of a hybrid of Perl and Python. Given that I already know both Perl and Python, I couldn't see the point of spending much time on Yet Another Language, especially one that was more of the same.
Still, buzz continued to grow. I picked up a copy of Hal Fulton's book The Ruby Way. This one included Appendices explicitly for Perl and Python programmers, as well as several "real-world" examples, so I gave it another shot.
Actually, I started to give it another shot. But since the Appendices were squarely aimed at me, I started there. Big mistake -- I fell asleep. Several times. I put the book aside and figured I was done.
Three years later, in 2004, along came Ruby on Rails. Wow. Do I really need to tell you how impressive Rails is? But at the time I wasn't working on any web applications, I still wasn't thrilled with Ruby as a language, and I certainly wasn't thrilled at the prospect of learning a whole new language just to write web apps.
More recently I've been looking at the cavalcade of Rails clones. I think I've settled on CakePHP as the best documented, most mature, and easiest to learn. But just as I was getting started, it occured to me....
As I tell students, the best way to learn is by going straight to the source, not by reading the nth re-hash by someone else. I'm still planning to learn Cake, but really, why not start with the best? (Or at least with the original.)
Ok, back to Ruby. In the years since Programming Ruby was published by Addison-Wesley, the Pragmatic Programmers have started their own publishing company, The Pragmatic Bookshelf. Which brings me (finally) to the ostensible subject of this review, Learn to Program by Chris Pine.
The purpose of Learn to Program is, well, to learn to program. The language just happens to be Ruby. Honestly, I don't even remember when I first learned to program -- I must have been 7 or 8 years old. (BASIC, on a Timex-Sinclair 1000, if you must know). I can't really comment on how well the book succeeds in that goal, because I'm clearly not the target audience.
I read through the book fairly quickly, since I already understand the concepts. A couple of things concerned me, though. The explanation of "variables" seemed overly complicated. I think the author was trying to explain references, without actually using the word "reference".
Ditto his explanation of recursion -- I admire the attempt to suggest that recursion is a perfectly natural concept (the title of Chapter 10, on recursion, is "There's Nothing New to Learn in Chapter 10"), especially since most CS1 textbooks for imperative languages make it far too complicated. But c'mon. If it's so easy, why does "nothing new" take 17 pages to explain?
So I can't tell you whether it's a good book for a beginner, but it was a good book for me. The truth is, the only way to learn a new programming language is to write code. You can't just sit and read a book about programming; you need to do it yourself. In this, the author succeeds wonderfully. The exercises he suggests (under the heading "A Few Things to Try") are geared toward putting the concepts you've just read about directly into practice. And they're straightforward enough that, instead of thinking "oh great, another programming exercise," you'll be thinking "hey, that sounds easy enough," and you'll dive right in.
Even better, they're fun. No lame "Hello, world" or farenheit-to-celsius converters here. (Oops, I think I just insulted K & R.) Instead you'll find such gems as
Oh, and my impressions of Ruby now that I've written a few short programs? It's kind of a nice language. You can slurp the contents of a file in a single line. It switches seamlessly between fixed-sized integer types and "big" integers. (As it turns out, so does Python, but I'd never seen it before). YAML is nicer than Perl's Data::Dumper. I like that you can add easily add methods to built-in classes, even if it's probably a bad idea -- being able to type 3.factorial is coool.
Ruby strikes me as being sort of like Python, if Python had been written by someone who liked Perl. I don't think, though, that it goes the other way: Ruby is not sorta like Perl. It just has enough Perl-ish bits to make the transition less painful.
I'm having trouble deciding on my next Ruby book. I'm leaning toward the Pickaxe Book, but Ruby for Rails looks good, too. After all, that's why I was planning to learn Ruby in the first place.
By the way, click here for some bits of Ruby code. Nothing spectacular, but they're sitting here on my hard drive -- no point in not sharing them.Fri, Jul 01, 2005
Blueprints for High Availability
Well, this isn't your average QA job. I work in the deployment group. Our job is to make sure that products work when they're... well, deployed. As in, sure, all of your software tests passed in the lab, but what happens when we try to deploy it in the Real WorldTM?
See now, that's a sysadmin's dream -- getting to play with lots of cool technology (firewalls, load balancers, clusters, SANs, app servers, database servers) in an environment where breaking something not only isn't a disaster, it's actually part of your job.
Of course, if you've never built a cluster before, there's a bit of a learning curve. So I decided to start where I always do when confronted with a new technology: the bookstore.
Since much of our work is focused on High Availability and Disaster Recovery configurations, I thought I'd start there. The first book I picked up was Blueprints for High Availability, Second Edition by Evan Marcus and Hal Stern. The authors ought to know what they're talking about: Marcus is a principal engineer at VERITAS, and Stern is the CTO of Sun.
The book is structured around a list of technologies and practices arranged into an "Availability Index." Think of it as the OSI model for HA. At the bottom are the fairly straightforward things that everyone should be doing to ensure availability such as buying reliable hardware and making regular backups. Each layer works toward increasing levels of availability (and cost) with technologies such as clustering, replication, and failover. And they're right, they really are layers -- there's no point wasting lots of money building a global cluster to fail over between geographically separate sites if you haven't invested in fault-tolerant storage and redundant network connectivity.
Having described the Availability Index, the authors provide a general introduction to the field, including its jargon (e.g., MTBF, MTRR, sigmas, and nines). Especially helpful here is a chapter on "The Politics of Availability," describing how technical personnel can get management buy-in. This is important, considering that (a) sysadmins aren't always particularly good at communication, and (b) HA technology tends to be expensive. If you haven't built the case for availability, expect resistance.
Assuming that you've gotten the green light, we begin working our way up the Availability Index, starting with (my favorite) good system administration practices such as change control and consistent system configuration. The next three chapters cover storage management issues, including backup and restore, volume management, and RAID. The final chapter on storage is a good introduction to SANs, NAS, and storage virtualization (especially helpful to me as a relative newbie to "enterprise storage" -- I didn't know you could do all that.)
Having taken care of local storage, the next chapter takes on networking, discussing the different ways in which networks fail and options for building redundant networks. Redundant network connectivity leads naturally to a discussion of Data Centers and environmental issues such as racks, redundant power, and cooling.
The chapter on environmental issues ends by discussing something completely different: system-naming conventions. This happens to be one of my pet peeves, and I think the authors are dead-on. Too many try to name their systems using some sort of code: if you're working in the Orange County office and you have three machines running AIX, please don't name them oc-aix01, oc-aix02, and oc-aix03. That kind of thing may work well for network equipment such as switches and routers (after all, what's important about a network device if not its location) but it's a horrible idea for systems: it's hard to remember, and it's hard to communicate. So you're on the phone, in the middle of a noisy data center, and you're under pressure to get things back up and running immediately. Now which one were you supposed to reboot -- was it oc-aix02 or oc-aix03? I can't remember. Damn...
On the other hand, if all of your machines have "real" names (cartoon characters, say) are you really going to forget whether it was linus or snoopy that you were supposed to be working on? And if you were planning to tell me that you're encoding important information in the names (e.g., the OS they're running), I simply counter that you lack imagination: name the AIX boxes after cartoon characters, the Linux boxes after characters in Lord of the Rings (good Lord, people are using thse for baby names?), and the Oracle servers after Navy ships .
Whew. Ok, back to the book. The next chapter discusses people and processes for availability, including maintenance plans and vendor management. The discussion reminds me of another of my favorite books, Limoncelli and Hogan's Principles of Network and System Administration. Actually, come to think of it, so did the previous chapter. Do yourself a favor and get both.
The next couple of chapters cover issues with applications, including the special requirements of NFS servers, web servers, and database servers. The authors describe the different kinds of things that can go wrong with applications (memory leaks, network connectivity issues, buffer overflows, hung processes), as well as techniques for sharing state among multiple instances of an application and checkpointing in case of a failure.
Finally we reach the heart of the matter, at least as far as I'm concerned: there are four chapters devoted to clustering, failover, and replication. You won't learn everything you need to know (and in fact, if what you need to know are technical details of particular products, you won't learn anything), but it's a good introduction to the components of an HA system (virtual IP addresses, shared disks, heartbeats), the options for configuring clusters (active-passive, active-active, service groups, N-to-1 vs. N-plus-1), and the issues such as fail-back and split-brain.
Next comes a short chapter on "Virtual Machines and Resource Management," which seems out of place. Perhaps its material should have been relocated to the chapter called "A Brief Look Ahead" on future trends such as iSCSI, InfiniBand, and grid and blade computing. The book was published in 2003, but much of this technology seems to still be in its infancy.
The flow picks back up with the final major chapter, on Disaster Recovery. This chapter is much less about technology than about planning and logistics. It's important, I don't deny it, but personally I was looking for a discussion of global clustering.
Finally, the Second Edition was written after the attacks on September 11, 2001, when businesses really started to think about not just HA, but Disaster Recovery and Business Continuity. This edition includes a chapter called "The Resilient Enterprise," describing how, despite losing their offices and even the trading floor itself the morning of September 11, The New York Board of Trade was able to recover and be ready for business by 8pm that evening. Now that was a Disaster Recovery Plan.
This isn't a terribly technical book, but it's a good introduction. If you're just getting started, start here. If you need to configure a cluster, start elsewhere. The next book on my stack is Shared Data Clusters, by another engineer at VERITAS, and it appears to contain more technical details.