about this book
Many technical books I’ve bought are like Disneyland: They seem promising, but they’re expensive, the examples are Mickey Mouse, they take forever, and I end up disappointed.

This is not one of those books.

In Flexible Rails, we’ll build a real application—well, as close to a real application as you can get in a book. As we go, I’ll explain the concepts introduced by the code, as well as explain the code itself. The code is all MIT-licensed, so you can take whatever you want from it and use it as the basis of whatever Web 2.0 startup you’re dreaming of, without owing me (or Manning) a penny. (If you do make millions, I won’t say no to unsolicited gifts, of course!)

Roadmap

Like many applications developed iteratively, this book contains four parts:

  1. Getting started
  2. Building the application
  3. Refactoring
  4. Finishing up

In part 1, “Getting started,” we’ll do the necessary setup work that will let us get to the fun stuff in the rest of the book. We’ll install everything, do a Flex and Rails version of “Hello World,” and then get user creation and login working in Rails and hook up the Flex UI to it. This part contains three iterations:

  • Iteration 1 “Why are we here? Where are we going?”—This iteration provides the motivation for the book, an understanding of the history of Flex and Rails and how they fit together, and an overview of the book.
  • Iteration 2 “Hello World”—This iteration contains three separate sets of instructions (Windows or Mac OS X + Flex Builder 3, Windows + Flex SDK, and Mac OS X + Flex SDK) for installing everything we need and getting “Hello World” running.
  • Iteration 3 “Getting started”—In this iteration, we’ll set up MySQL and then add account-creation and login functionality to our Rails application, using the restful_authentication plugin. We then hook up the Flex UI to use the Rails account creation and login functionality.
  • In part 2, “Building the application,” we’ll do a deep dive using Flex with Rails. By the end of it, we’ll have mastered the basics of using Flex with Rails. This part contains four iterations:

  • Iteration 4 “Creating the main Flex UI”—In this iteration, we’ll build a stubbed-out UI for the main part of the Flex application.
  • Iteration 5 “Expanding the Rails code, RESTfully”—Next, we’ll add new Rails models and controllers for the tasks, projects, and locations—as well as the migrations needed to create their database tables. We also introduce REST in this iteration. Finally, we’ll address some basic security concerns that need to be considered at the outset.
  • Iteration 6 “Flex on Rails”—In this iteration, we’ll hook up most of the main Flex UI we’ll build in iteration 4 to the Rails controllers we’ll build in iteration 5.
  • Iteration 7 “Validation”—We’ll add full validation support on the Rails side and the Flex side to the account-creation process.
  • At this point, we’ll be ready to think about higher-level topics, which we’ll do in part 3, “Refactoring.” This part includes two iterations:

  • Iteration 8 “Refactoring to Cairngorm”—We’ll refactor the code we wrote in part 2 to use Cairngorm, an application framework for Flex.
  • Iteration 9 “Holding state on the client properly”—We’ll refactor the code again, this time to add a proper object model instead of just using XML on the client.
  • At the end of this part, we’ll have a much better understanding of design in Flex and of the options available to us for data exchange between Flex and Rails. Doing the refactoring to decouple the object model from its method of transport (currently XML) will enable us to consider using an alternate method of transport.

    In the final part, “Finishing up,” we’ll finish the application, refactor it to use RubyAMF, and extend it to run on the Adobe Integrated Runtime (AIR).

    This part contains three iterations:

  • Iteration 10 “Finishing the application”—In this iteration, we’ll build the remaining features in pomodo.
  • Iteration 11 “Refactoring to RubyAMF”—We’ll refactor pomodo to use RubyAMF instead of XML for sending data between Flex and Rails. Because AMF is a binary protocol and XML is text (and verbose text at that), this has the potential to lead to substantial performance improvements.
  • Iteration 12 “Rails on AIR (Adobe Integrated Runtime)”—In this last iteration of the book, we’ll convert the code to run on AIR and modify the Notely feature that we’ll build in this iteration to take advantage of AIR-specific features. This won’t be a complete tutorial introduction to AIR; instead, it will give you a taste of one of the exciting ways to take your Flex + Rails applications beyond the traditional web application model.
  • The overall approach of this book is “Flex and Rails Immersion”—instead of getting bogged down in theory and boring you with contrived examples, we’ll build a real application together and learn everything as we go. Also, I don’t pretend that the book exists in isolation: I reference many excellent resources, including not only the relevant books but also numerous blog posts. One of the hallmarks of the Rails community in particular is the number of prolific bloggers—most people in the Rails community learn from these blogs, so the honest thing to do is to provide a brief explanation in the book and reference them for the full explanation, instead of paraphrasing them.

    What the book doesn’t compete with

    This book is intended to be an informative, interesting, useful, and occasionally mildly entertaining tutorial for software developers, regardless of how much Flex, Ruby, or Rails experience they have. This book is not attempting to provide a full Ruby, Rails, Flex, or ActionScript 3 tutorial—each of those topics needs an entire book. Luckily, they already have excellent books:

  • Ruby—Programming Ruby, 2nd ed.; The Ruby Way, 2nd ed.
  • Rails—Agile Web Development with Rails, 2nd ed.
  • Ruby and Rails—Ruby for Rails, 1st ed.
  • Flex 3—Flex 3 Developer’s Guide (a free 1,435-page PDF from Adobe)
  • ActionScript 3—Programming ActionScript 3.0 (a free 576-page PDF from Adobe)
  • This book does not compete with any of these books—it assumes that you either have them (or the knowledge contained in them) or are willing to buy them. (The Flex and ActionScript 3 PDFs are free.) If you’re going to do any serious work with Rails, you should buy the second edition of Programming Ruby (the first edition is free but outdated), the second edition of Agile Web Development with Rails (AWDwR), and/or the first edition of Ruby for Rails.

    What this book will try to do is provide enough information and external references that someone with no Flex, Ruby, or Rails experience can follow along and find help when necessary, but not so much that it would become annoying to someone who already understands all the basics of either Rails or Flex. My assumption is that most readers are coming from one camp (a Rails developer wanting to learn Flex as an alternative to AJAX or a Flex developer looking for a server-side technology other than Java). That said, if you have no Flex or Rails experience, but you have web or desktop UI software-development experience, you should be able to follow along with this book: Many readers have done exactly this.

    A note about the iterations

    All the code in the book is available for download from http://www. flexiblerails.com/code-samples as well as from the publisher’s website at http://www.manning.com/armstrong or http://www.manning.com/FlexibleRails. The download is one big zip file that contains a separate folder for each completed iteration in the book, except iteration 1, for which there is no code. This way, you can start at any iteration and follow along by using the directory from the previous iteration. Or, if you don’t like typing, you can load each completed iteration as you read.

    Because I’m lazy (in the good programmer way), they aren’t all separate projects—they’re copies of the same project at various stages. I recommend creating a staging-area folder called current and having Flex Builder point at it. This way, if you want to start at the end of any given iteration, you can delete your current folder and copy that iteration in place of the current one. When you relaunch Flex Builder, all it sees is that a bunch of files have changed—the project is the same. If you’re using the Flex Framework SDK, this doesn’t apply to you.

    Finally, note that this procedure has no correspondence to anything you would do when actually coding. For real development, use Subversion (or Git) and have it ignore the public\bin directory you’ll be creating for the Flex output. See appendix A for details on using Subversion with Flex and Rails. If you’re using Git, you don’t need a tutorial.

    Which Flex?

    The short answer is: Flex 3.

    The longer answer is that much of the book was originally written using Flex 2, and that the code was updated to Flex 3 Beta 2 before the most recent rewrite. So, the code in the book was all produced using Flex 3 Beta 2. During the typesetting process, the Flex code was tested with Flex 3 Beta 3. This had no effect except in iteration 12 (“Rails on AIR”): Flex 3 Beta 3 renamed Shell. shell to NativeApplication.nativeApplication, so the iteration 12 code was updated accordingly. All the Flex code—except for iteration 12, which uses AIR—will work in Flex 2 and Flex 3.

    Which Rails?

    The short answer is: Rails 2.

    The slightly longer answer is that the most recent rewrite of this book was done using the first release candidate of Rails 2, whose gem version is 1.99.0. Rails 2 final, whose gem version is 2.0.1, was released when the book was already in typesetting. So, during typesetting, I updated my Rails to 2.0.1 and did another full pass through the book, following along using Rails 2.0.1. So, while the text of the book refers to Rails 1.99.0, rest assured that it has been tested with both Rails 1.99.0 and Rails 2.0.1. The code that is available for download from http://www.flexiblerails.com/code-samples, as well as from the publisher’s website, uses Rails 1.99.0. (Because I followed along with Rails 2.0.1, I could have released this code as well. However, its format wouldn’t have matched—copying and pasting from a PDF removes the formatting—so I didn’t do this.)

    The really long answer is that I have rewritten this book more than twice: I started writing the early iterations when Rails was at version 1.1. The iterations were originally shorter, and there were more than 20 of them. (It turns out that this is an unmaintainable nightmare for this style of book, since bugfixes must be ported forward.) So, in May 2007 I completely rewrote the book, dramatically reducing the number of iterations and updating the code to Rails 1.2. In summer 2007, I made an agreement to publish the book with Manning. However, Rails 2 went to preview release shortly afterward, so the book would have been outdated before it was off the press. So, in October 2007 I completely rewrote the book again, updating the version of Rails to the preview release of Rails 2 (gem version 1.2.3.7707). Then, in November and December 2007 during the Author Review phase of the book I updated the book to be based on the first release candidate of Rails (gem ver- sion 1.99.0), by following along from the beginning. Finally, during typesetting I ensured that the code worked with Rails 2 final (gem version 2.0.1), by following along again from the beginning.

    Writing is indeed rewriting, especially when the topic is as fast-moving as the combination of Flex and Rails.

    Understanding the code examples

    For readability, I’ll show the source code of a file with new or modified lines of code in bold italics and lines of code that should be deleted shown in strikethrough. I’ll often omit unchanged portions of a file, using an ellipsis (...) to take the place of the unchanged code. If a large section of code is being deleted, I’ll often use an ellipsis inside the code being deleted (because showing tons of strikethrough code is a waste of paper). If you’re pasting code from the code samples into your code, make sure you omit or delete any lines shown in strikethrough. Furthermore, note that the book uses 64-column code. This results in some purely format-related modifications to generated Rails code in order to make it fit nicely within 64 columns. These changes may not be shown as modified or explained, because that would be tedious. Finally, note that sometimes it isn’t possible to get code to fit nicely in 64 columns—Rails code is often written in a way that favors long lines, and inline event-handling in MXML code lends itself to longer lines too. In these cases, the code will just auto-wrap, and a continuation symbol will be shown.

    A complete code zip file is available for download from http://www. flexiblerails.com/code-samples, as well as from the publisher’s website.

    Author Online

    Purchase of Flexible Rails includes free access to a private web forum run by Manning Publications where you can make comments about the book, ask technical questions, and receive help from the authors and from other users. To access the forum and subscribe to it, point your web browser to http://www.manning.com/FlexibleRails or http://www.manning.com/armstrong. This page provides information on how to get on the forum once you are registered, what kind of help is available, and the rules of conduct on the forum.

    Manning’s commitment to our readers is to provide a venue where a meaningful dialogue between individual readers and between readers and the author can take place. It is not a commitment to any specific amount of participation on the part of the authors, whose contribution to the book’s forum remains voluntary (and unpaid). We suggest you try asking the author some challenging questions, lest his interest stray!

    The Author Online forum and the archives of previous discussions will be accessible from the publisher’s website as long as the book is in print.

    About the author

    Peter Armstrong has been a Flex developer since July 2004 (since Flex 1.0) and he has been tracking Ruby on Rails since mid-2005 (since before Rails 1.0). Before switching to Flex, he spent five years as a Java Swing developer, with a brief stint as a PHP developer during the dotcom bubble in 2000. As someone with a heavy Swing background, Peter initially found Flex appealing because it felt very familiar—more like Swing development than web development. After more than five years of working with Java, Ruby and Ruby on Rails felt like a breath of fresh air.

    Peter is the organizer of The Vancouver Ruby/Rails Meetup Group (http://ruby.meetup.com/112/). He has spoken about using Flex with Rails at the Vancouver Flash/Flex Meetup Group, at a RailsConf 2007 BOF, at the Vancouver RIA Developer Camp, at Rails to Italy 2007 and at VanDev.

    The author’s website for this book is at http://www.flexiblerails.com. The blog for this book is at http://www.flexiblerails.com/blog. Peter’s personal blog is at http://www.peterarmstrong.com. Peter’s consulting company, focused on Flex and Rails development, training, and workshops, is http://www.ruboss.com.

    Peter lives with his wife Caroline and his son Evan in the Vancouver, British Columbia area. When he’s not coding, writing, reading, or being a husband and dad, Peter likes to snowboard and play computer games. If it wasn’t for Desktop Tower Defense, Slashdot, and reddit, this book would have been done a month earlier—if not more!