PragDave
10 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. 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. 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. 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. PragDave, 2006-12-04 04:17:15
Rails Guidebook
RailsConf 2006 is in its final day, and I just realized that I hadn’t blogged on Rails Guidebook. The Guidebook was a preconference event. For a day before the conference proper started, attendees got an introduction to all the stuff that’d be hearing about in the following days. It was a combination of a tutorial and a glossary. We didn’t charge. Instead, the cost of admission was a contribution to charity. The Rails community raised over $8,000 This is wonderful stuff, and Mike and I thank everyone who made it possible: the Ruby Central folks who agreed to add a day to the agenda, Jay Zimmerman for organizing the facilities, the core team members and other experts who turned up to help, Mike and Nicole for doing all the Guidebook logistics, and, more importantly, the folks who turned up and contributed. A Challenge If you’re already organizing a conference, adding a guidebook day ahead of it isn’t a great incremental cost. So, here’s a challenge to conference organizers. Let’s start a tradition of these types of charitable events. Let’s make a point of sharing some of our success with others. Not only does it do some good—it’s fun. PragDave, 2006-12-04 04:17:15
RailsConf 2006 is in its final day, and I just realized that I hadn’t blogged on Rails Guidebook. The Guidebook was a preconference event. For a day before the conference proper started, attendees got an introduction to all the stuff that’d be hearing about in the following days. It was a combination of a tutorial and a glossary. We didn’t charge. Instead, the cost of admission was a contribution to charity. The Rails community raised over $8,000 This is wonderful stuff, and Mike and I thank everyone who made it possible: the Ruby Central folks who agreed to add a day to the agenda, Jay Zimmerman for organizing the facilities, the core team members and other experts who turned up to help, Mike and Nicole for doing all the Guidebook logistics, and, more importantly, the folks who turned up and contributed. A Challenge If you’re already organizing a conference, adding a guidebook day ahead of it isn’t a great incremental cost. So, here’s a challenge to conference organizers. Let’s start a tradition of these types of charitable events. Let’s make a point of sharing some of our success with others. Not only does it do some good—it’s fun. PragDave, 2006-12-04 04:17:15
Prices in Cents
In the second edition of AWDwR, I changed the Depot application to store money in integral cents, rather than floating point dollars and cents. Some folks pushed back on this, saying it overly complicated the application. This morning, while working on some code to migrate some legacy data, I bumped into a problem that boiled down to the following (on my PPC—your results may differ) dave[store/migrate 9:00:57] irb irb(main):001:0> Integer(77.85 * 100.0) => 7784 Obviously it’s possible to do rounding (although even that’s trickier than you might first code if you have to handle negative numbers). I still feel that Rails should convert decimal(x,y) columns into BigDecimal format in Ruby, giving us scaled, exact, representations. Until that day, stick with integers for amounts that you need to be exact. PragDave, 2006-12-04 04:17:15
In the second edition of AWDwR, I changed the Depot application to store money in integral cents, rather than floating point dollars and cents. Some folks pushed back on this, saying it overly complicated the application. This morning, while working on some code to migrate some legacy data, I bumped into a problem that boiled down to the following (on my PPC—your results may differ) dave[store/migrate 9:00:57] irb irb(main):001:0> Integer(77.85 * 100.0) => 7784 Obviously it’s possible to do rounding (although even that’s trickier than you might first code if you have to handle negative numbers). I still feel that Rails should convert decimal(x,y) columns into BigDecimal format in Ruby, giving us scaled, exact, representations. Until that day, stick with integers for amounts that you need to be exact. PragDave, 2006-12-04 04:17:15
Pluvo
LtU has a link to Pluvo, a language which seems like a cross between Python, JavaScript, Ruby, and Lisp. It has some interesting ideas (coordination is a fun one) and the basic system (written in Python) is currently less than 50k to download. PragDave, 2006-12-04 04:17:15
LtU has a link to Pluvo, a language which seems like a cross between Python, JavaScript, Ruby, and Lisp. It has some interesting ideas (coordination is a fun one) and the basic system (written in Python) is currently less than 50k to download. PragDave, 2006-12-04 04:17:15
Decimal Support in Rails
A couple of blog posts ago, I commented on the dangers of converting database decimal columns into Ruby floats. And, five months early, Santa delivers. In the Rails trunk, numeric and decimal database columns with a scale factor are now converted into Ruby BigDecimal objects. If the scale factor is zero, they instead become integers. Migrations now support decimal columns too, with the addition of two new attributes, precision and scale. add_column :orders, :price, :decimal, :precision => 8, :scale => 2 I just spent a day reworking all the Depot chapters to use this, and it seems to work great. (And, no, the updated PDF isn’t released yet. I’m also half-way thought the ActiveRecord chapter rewrite, and need to get that finished before the next release.) I’d be interested to hear[1] from folks currently using BigDecimal for financial calculations. Is there a preferred rounding mode? Any gotchas? In the meantime, thanks core team. dave?pragprog.com PragDave, 2006-12-04 04:17:15
A couple of blog posts ago, I commented on the dangers of converting database decimal columns into Ruby floats. And, five months early, Santa delivers. In the Rails trunk, numeric and decimal database columns with a scale factor are now converted into Ruby BigDecimal objects. If the scale factor is zero, they instead become integers. Migrations now support decimal columns too, with the addition of two new attributes, precision and scale. add_column :orders, :price, :decimal, :precision => 8, :scale => 2 I just spent a day reworking all the Depot chapters to use this, and it seems to work great. (And, no, the updated PDF isn’t released yet. I’m also half-way thought the ActiveRecord chapter rewrite, and need to get that finished before the next release.) I’d be interested to hear[1] from folks currently using BigDecimal for financial calculations. Is there a preferred rounding mode? Any gotchas? In the meantime, thanks core team. dave?pragprog.com PragDave, 2006-12-04 04:17:15
Migrations Outside Rails
I’m about 3 weeks into the rewrite of the Active Record chapters for the new Rails book. In the book, I try to demonstrate Active Record with real, live code. At the same time, I don’t want to run every single piece of code in the context of a Web application. So, I use Active Record stand-alone, without having the rest of Rails loaded. All my demonstration files start: require "rubygems" require_gem "activerecord" and then include a call to establish_connection to connect to the database. At this point, I’m up and running, and I can play with all the Active Record functionality. But… I still wanted to create tables in the underlying database. In the first edition, I used DDL to do this, but in the second I wanted to use migrations. My first hack was to use the fact that the various schema definition methods are defined both for migrations and in every database connection object. That let me use the following in my code: ActiveRecord::Base.connection.instance_eval do create_table children, :force => true do |t| t.column :parent_id, :integer t.column :name, :string t.column :position, :integer end end I was pretty chuffed with this until Jamis Buck (who else) pointed out a more elegant way: ActiveRecord::Schema.define do create_table children, :force => true do |t| t.column :parent_id, :integer t.column :name, :string t.column :position, :integer end end As I see more and more people start to use Ruby (and Active Record) as enterprise glue, being able to bring these kinds of Rails goodies to non-Rails applications is a win all around. PragDave, 2006-12-04 04:17:15
I’m about 3 weeks into the rewrite of the Active Record chapters for the new Rails book. In the book, I try to demonstrate Active Record with real, live code. At the same time, I don’t want to run every single piece of code in the context of a Web application. So, I use Active Record stand-alone, without having the rest of Rails loaded. All my demonstration files start: require "rubygems" require_gem "activerecord" and then include a call to establish_connection to connect to the database. At this point, I’m up and running, and I can play with all the Active Record functionality. But… I still wanted to create tables in the underlying database. In the first edition, I used DDL to do this, but in the second I wanted to use migrations. My first hack was to use the fact that the various schema definition methods are defined both for migrations and in every database connection object. That let me use the following in my code: ActiveRecord::Base.connection.instance_eval do create_table children, :force => true do |t| t.column :parent_id, :integer t.column :name, :string t.column :position, :integer end end I was pretty chuffed with this until Jamis Buck (who else) pointed out a more elegant way: ActiveRecord::Schema.define do create_table children, :force => true do |t| t.column :parent_id, :integer t.column :name, :string t.column :position, :integer end end As I see more and more people start to use Ruby (and Active Record) as enterprise glue, being able to bring these kinds of Rails goodies to non-Rails applications is a win all around. PragDave, 2006-12-04 04:17:15
Rails and the Legacy World
I gave what turned out to be a slightly controversial keynote at RailsConf. In it, I pointed out that people (like me) who can use Rails on green-field projects are incredibly privileged. We get to code using cool technologies in an incredibly agile, reactive environment, producing applications that just work. But, at the same time, there are a whole lot of people who don’t get to enjoy the world of Rails. I see these people regularly: I talk at No Fluff symposia around the country, a great set of shows aimed at Java developers. I’m the outsider, normally giving a full day’s worth of talks on Ruby and Rails. And, in a way, it makes me sad to do it, because I often see folks get really excited about the possibilities present in Rails only then to realize that they’ll be going back to work on Monday with no real hope of using what they’d just seen. These folks come to me during the breaks and talk about how bad their world currently is, and how much better it would be if only they could use Rails. If only… Sometimes, the things that block these people are not technical issues: companies have policies dictating that all work is done in Java (or .NET, or whatever). But many times the road blocks are technical. In their particular environment, with legacy code and legacy databases, they need to be able to do things that Rails just doesn’t support out of the box—more complex schemas, staged deployment, and so on. So, in my keynote, I asked a simple question. Can we, as a community, do anything to make the lives of these developers easier. Can we find a way of bringing them in out of the cold? Clearly, I believe the answer is yes. As I said in Chicago, the answer is not to change Rails. Instead, the answer is to use the fact that Rails is based on Ruby, and Ruby gives developers incredible power to extend existing code in directions not anticipated by the original developers. I asked the community to consider creating extensions to Rails to allow currently disenfranchised developers to join the party. This seems to have touched people’s nerves. Some have reacted violently against the idea, others have welcomed it. It’s an interesting, although ultimately sterile, debate. If people need changes to Rails, Ruby will let them do it. An interesting example is Greg Houston’s recent blog post, Let ActiveRecord support Enterprise Databases. (Uh oh! He used the enterprise word). He describes a problem he faces trying to use Active Record migrations to maintain a legacy schema. The database-neutral migrations didn’t give him the kind of control he needed, so his post describes how he extended Active Record to do what he wants (including a very simple but nicely powerful trick to make migrations spit out SQL, rather than execute it). And, importantly, he did all this as a regular user of Rails: he didn’t need any changes to the framework or any endorsement of his work by the core team. (He does, however, make a good point at the end of his post. If Active Record had an extension API it would make it easier for these kinds of plugins to survive changes to the core code base.) Greg’s post is a basic experience report: he took what he needed from Rails, extended it where necessary, and solved a business problem. By blogging, he’s shown other developers just how to solve this category of problem. A .NET developer needing to manage a legacy SqlServer schema could read his post and realize that something that seemed impossible in Rails is actually fairly easy. One more person can join the party. You could argue that the stuff in Greg’s post is just a simple matter of coding. There’s nothing stopping any .NET developer downloading Rails and making the simple changes he’s suggesting. But the reality is that you have to have a good idea that this kind of thing is possible before you invest time in the exercise. If you’re a Java or .NET developer looking for salvation, and you spend some time looking at Rails, you’ll currently come across a lot of information explicitly telling you that Rails is never going to address the issues you face—Rails is explicitly not "enterprise." And so you’d move on. And you’d be missing an incredible opportunity. And this is one of the challenges I’d like us, the Rails and Ruby communities, to address. While keeping the Rails core focused on new ways of writing web applications, I’d like others of us to find ways of educating corporate software developers, showing them that they can also bring our technologies into their daily lives—using Ruby as an enterprise glue language and Rails as a viable enterprise web development platform. Should Rails be everything to everyone? No. Should Rails be "marketed" as a replacement for J2EE or .NET? God forbid. But there are a whole group of people out there who could be using Rails now but aren’t, simply because they don’t know that it is up to their challenges. And I’d like to try to help these folks. Let’s not be the only people having fun. PragDave, 2006-12-04 04:17:15
I gave what turned out to be a slightly controversial keynote at RailsConf. In it, I pointed out that people (like me) who can use Rails on green-field projects are incredibly privileged. We get to code using cool technologies in an incredibly agile, reactive environment, producing applications that just work. But, at the same time, there are a whole lot of people who don’t get to enjoy the world of Rails. I see these people regularly: I talk at No Fluff symposia around the country, a great set of shows aimed at Java developers. I’m the outsider, normally giving a full day’s worth of talks on Ruby and Rails. And, in a way, it makes me sad to do it, because I often see folks get really excited about the possibilities present in Rails only then to realize that they’ll be going back to work on Monday with no real hope of using what they’d just seen. These folks come to me during the breaks and talk about how bad their world currently is, and how much better it would be if only they could use Rails. If only… Sometimes, the things that block these people are not technical issues: companies have policies dictating that all work is done in Java (or .NET, or whatever). But many times the road blocks are technical. In their particular environment, with legacy code and legacy databases, they need to be able to do things that Rails just doesn’t support out of the box—more complex schemas, staged deployment, and so on. So, in my keynote, I asked a simple question. Can we, as a community, do anything to make the lives of these developers easier. Can we find a way of bringing them in out of the cold? Clearly, I believe the answer is yes. As I said in Chicago, the answer is not to change Rails. Instead, the answer is to use the fact that Rails is based on Ruby, and Ruby gives developers incredible power to extend existing code in directions not anticipated by the original developers. I asked the community to consider creating extensions to Rails to allow currently disenfranchised developers to join the party. This seems to have touched people’s nerves. Some have reacted violently against the idea, others have welcomed it. It’s an interesting, although ultimately sterile, debate. If people need changes to Rails, Ruby will let them do it. An interesting example is Greg Houston’s recent blog post, Let ActiveRecord support Enterprise Databases. (Uh oh! He used the enterprise word). He describes a problem he faces trying to use Active Record migrations to maintain a legacy schema. The database-neutral migrations didn’t give him the kind of control he needed, so his post describes how he extended Active Record to do what he wants (including a very simple but nicely powerful trick to make migrations spit out SQL, rather than execute it). And, importantly, he did all this as a regular user of Rails: he didn’t need any changes to the framework or any endorsement of his work by the core team. (He does, however, make a good point at the end of his post. If Active Record had an extension API it would make it easier for these kinds of plugins to survive changes to the core code base.) Greg’s post is a basic experience report: he took what he needed from Rails, extended it where necessary, and solved a business problem. By blogging, he’s shown other developers just how to solve this category of problem. A .NET developer needing to manage a legacy SqlServer schema could read his post and realize that something that seemed impossible in Rails is actually fairly easy. One more person can join the party. You could argue that the stuff in Greg’s post is just a simple matter of coding. There’s nothing stopping any .NET developer downloading Rails and making the simple changes he’s suggesting. But the reality is that you have to have a good idea that this kind of thing is possible before you invest time in the exercise. If you’re a Java or .NET developer looking for salvation, and you spend some time looking at Rails, you’ll currently come across a lot of information explicitly telling you that Rails is never going to address the issues you face—Rails is explicitly not "enterprise." And so you’d move on. And you’d be missing an incredible opportunity. And this is one of the challenges I’d like us, the Rails and Ruby communities, to address. While keeping the Rails core focused on new ways of writing web applications, I’d like others of us to find ways of educating corporate software developers, showing them that they can also bring our technologies into their daily lives—using Ruby as an enterprise glue language and Rails as a viable enterprise web development platform. Should Rails be everything to everyone? No. Should Rails be "marketed" as a replacement for J2EE or .NET? God forbid. But there are a whole group of people out there who could be using Rails now but aren’t, simply because they don’t know that it is up to their challenges. And I’d like to try to help these folks. Let’s not be the only people having fun. 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. 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. PragDave, 2006-12-04 04:17:15