PragDave
3 news.
Capistrano-Standing Room Only 
It was standing-room only at Mike Clark's Capistrano talk: one of the first talks at this year's RailsConf. Latecomers stole chairs from other rooms and fought their way to some free floor space to hear Mike talk about the way we deploy Rails applications. I'd just finished giving the first keynote. One of my topics was making deployment in Rails easier and more amenable to corporate use. I suspect from the interest in my talk, followed by the overwhelming interest in Mike's talk, that deployment will be one of the hot Rails topics of the coming year. [more]PragDave, 2006-12-04 04:17:15
It was standing-room only at Mike Clark's Capistrano talk: one of the first talks at this year's RailsConf. Latecomers stole chairs from other rooms and fought their way to some free floor space to hear Mike talk about the way we deploy Rails applications. I'd just finished giving the first keynote. One of my topics was making deployment in Rails easier and more amenable to corporate use. I suspect from the interest in my talk, followed by the overwhelming interest in Mike's talk, that deployment will be one of the hot Rails topics of the coming year. [more]PragDave, 2006-12-04 04:17:15
Glue That Doesn't Set
Back in the old days of computing—those days where I could still see my knees when standing up—folks used to talk about languages such as Perl as glue languages. What did they mean? Well, Perl is a great general purpose programming language. But it is exceptional at doing something that no previous language could do well: Perl made it easy to glue together other stuff. Data, programs, external systems—all these things could be integrated using Perl. Thanks to its integration with the underlying operating system, and its amazing support for text processing, Perl made a name for itself as an integrator par excellence. Want to take the last 20 lines of an error log, convert them to HTML, and upload the result to your web server? Perl could do that in a handful of lines of code. Need to screen-scrape a book's sales rank from Amazon and writing it into a local MySQL database. Perl to the rescue. Perl let us glue stuff together. It was magic. But there was a problem. Perl is a great language. It was my scripting language of choice before I discovered Ruby. But even on my most charitable days I could never really claim that these Perl programs were exemplars of readability. And, in turn, this lack of readability made it hard for me to pick one of them up six months after I'd written it and make some change—even small alterations could involve long periods of head-scratching as I tried to work out exactly what the entries in my hash of arrays of hash references9 actually contained. As a result, I found that the longer it was since I last looked at a program, the harder it was to maintain and extend it. The programs effectively became less malleable and more viscous. It became stickier; I got mired in a gooey mess of details. Leave a program long enough, and I'd often decide to rewrite it rather than attempt some piece of surgery: the program had become totally inflexible. The glue had set. Now Ruby is also a glue language. Just like Perl, Ruby works and plays incredibly well with external data, resources, and programs. I can do everything with Ruby that I used to do with Perl—I can use it to integrate all kinds of stuff just as easily as I used to be able to with Perl. But, there's a major difference. I've discovered that, over time, my Ruby programs stay malleable and easy to change. Ruby is the glue that doesn't set. Glue and the Web That's all very well, but what does writing little utility scripts have to do with real-world web programming? A whole lot, as it turns out. As we move into a world where the network is the computer, applications change in character. Rather than writing free-standing islands of code, developers are increasingly writing programs that knit together other, existing web resources. Want to annotate a map with pictures of famous landmarks? Maybe you'll want to use the Google Maps and Flikr APIs to carry most of the load for you. Want to let your readers know when their product has shipped? Why not generate the information as RSS and let their aggregator client do all the gruntwork of displaying the result? As we move forward, more and more of our applications will be less and less like one-man bands and more like orchestra conductors. Our applications are increasingly becoming glue code. And, if that's the case, I'd rather write them using a glue that doesn't set over time. [more]PragDave, 2006-12-04 04:17:15
Back in the old days of computing—those days where I could still see my knees when standing up—folks used to talk about languages such as Perl as glue languages. What did they mean? Well, Perl is a great general purpose programming language. But it is exceptional at doing something that no previous language could do well: Perl made it easy to glue together other stuff. Data, programs, external systems—all these things could be integrated using Perl. Thanks to its integration with the underlying operating system, and its amazing support for text processing, Perl made a name for itself as an integrator par excellence. Want to take the last 20 lines of an error log, convert them to HTML, and upload the result to your web server? Perl could do that in a handful of lines of code. Need to screen-scrape a book's sales rank from Amazon and writing it into a local MySQL database. Perl to the rescue. Perl let us glue stuff together. It was magic. But there was a problem. Perl is a great language. It was my scripting language of choice before I discovered Ruby. But even on my most charitable days I could never really claim that these Perl programs were exemplars of readability. And, in turn, this lack of readability made it hard for me to pick one of them up six months after I'd written it and make some change—even small alterations could involve long periods of head-scratching as I tried to work out exactly what the entries in my hash of arrays of hash references9 actually contained. As a result, I found that the longer it was since I last looked at a program, the harder it was to maintain and extend it. The programs effectively became less malleable and more viscous. It became stickier; I got mired in a gooey mess of details. Leave a program long enough, and I'd often decide to rewrite it rather than attempt some piece of surgery: the program had become totally inflexible. The glue had set. Now Ruby is also a glue language. Just like Perl, Ruby works and plays incredibly well with external data, resources, and programs. I can do everything with Ruby that I used to do with Perl—I can use it to integrate all kinds of stuff just as easily as I used to be able to with Perl. But, there's a major difference. I've discovered that, over time, my Ruby programs stay malleable and easy to change. Ruby is the glue that doesn't set. Glue and the Web That's all very well, but what does writing little utility scripts have to do with real-world web programming? A whole lot, as it turns out. As we move into a world where the network is the computer, applications change in character. Rather than writing free-standing islands of code, developers are increasingly writing programs that knit together other, existing web resources. Want to annotate a map with pictures of famous landmarks? Maybe you'll want to use the Google Maps and Flikr APIs to carry most of the load for you. Want to let your readers know when their product has shipped? Why not generate the information as RSS and let their aggregator client do all the gruntwork of displaying the result? As we move forward, more and more of our applications will be less and less like one-man bands and more like orchestra conductors. Our applications are increasingly becoming glue code. And, if that's the case, I'd rather write them using a glue that doesn't set over time. [more]PragDave, 2006-12-04 04:17:15
The Rails Edge
Mike Clark has announced The Rails Edge, a set of small, regional Rails conferences. The first will be November 16-18 in Denver. I'm really pleased with the way he's put these together. He's selected a stellar group of speakers, all with deep, practical Ruby and Rail experience. Then he's organized it as a single track event. I know this was a hard decision. But having one track means that everyone shares the experience, and everyone can build on each session during the breaks and in the evenings. It means we have a critical mass of folks, and all the more experience to share. And what I like most of all is the instructions he's given the speakers. Unlike events where one person speaks and the other speakers head off to pick up e-mail and work on projects, Mike is encouraging the Edge speakers to participate in all the talks. If Mike's talking, you might find yourself sitting next to Chad Fowler or core-team member Marcel Molina, Jr. If someone asks an Ajax question that Mike doesn't feel comfortable handling, Stu Halloway or Justin Gehtland might field it from the floor. As a speaker, I love this format--it means we're all part of the same team. Having other people around to help out lets me go both deeper and broader into stuff. I'm really looking forward to these events. [more]PragDave, 2006-12-04 04:17:15
Mike Clark has announced The Rails Edge, a set of small, regional Rails conferences. The first will be November 16-18 in Denver. I'm really pleased with the way he's put these together. He's selected a stellar group of speakers, all with deep, practical Ruby and Rail experience. Then he's organized it as a single track event. I know this was a hard decision. But having one track means that everyone shares the experience, and everyone can build on each session during the breaks and in the evenings. It means we have a critical mass of folks, and all the more experience to share. And what I like most of all is the instructions he's given the speakers. Unlike events where one person speaks and the other speakers head off to pick up e-mail and work on projects, Mike is encouraging the Edge speakers to participate in all the talks. If Mike's talking, you might find yourself sitting next to Chad Fowler or core-team member Marcel Molina, Jr. If someone asks an Ajax question that Mike doesn't feel comfortable handling, Stu Halloway or Justin Gehtland might field it from the floor. As a speaker, I love this format--it means we're all part of the same team. Having other people around to help out lets me go both deeper and broader into stuff. I'm really looking forward to these events. [more]PragDave, 2006-12-04 04:17:15