I’m glad to announce that I’ll be conducting the morning tutorial session at the upcoming Windy City Rails Conference.

It’s a 3-hour tutorial called REST 101: Best Practices for Rails Developers.

If you’re relatively new to Rails, especially if you’re currently a .NET or Java developer who’s trying to figure out how to really get started with Rails, this tutorial is for you. If you’re a more seasoned developer, then you should still attend the conference. There’s a great lineup of speakers, all-day coding sessions, and more.

The conference will be held on September 12, 2009 in downtown Chicago. If you register now, you can get the early bird rate of $99 for conference admission or just $199 for the conference with one tutorial session. For those who might not have heard of the annual Windy City Rails conference before, the conference donates all profits to local charities, like the Greater Chicago Food Depository.

So register now for the conference and/or tutorial. We’ll learn a lot, have fun, and support a good cause all in one day.

Questions? Leave a comment below and I’ll try to respond quickly.

Thanks! See you there!

It seems I’m in a super-minority among Rails developers.

First of all, I write tests. My unscientific guess is that less than half of people who call themselves Rails developers actually write tests.

Second, I write tests first. Of those that write tests, I would guess that less than half write them before writing the implementation code.

So already I’m in the group of “those crazy TDD developers”. But you know what’s even worse?

In that very group of “crazy TDD developers”, I bet more than half use RSpec.

But I don’t. Instead, I use a combination of shoulda, webrat, and mocha.

Honestly I don’t know why I’ve never liked RSpec. Lots of smart people use it, and maybe I just don’t understand it. But I don’t think business users will write tests with the story runner. The most they’ll ever do is read them, which is still valuable. But they can read my webrat tests well enough.

Also, RSpec just feels… heavy. There are spaces between words when I expect ruby-like underscores instead:

Model.should have(1).record

This just looks weird to me.

Unfortunately learning Mocha hasn’t been like falling off a log, either. There’s an excellent Google Group, but I don’t really know of a simple “Getting Started with Mocha” guide anywhere, so it’s taken me a while to get up to speed. Maybe I should take the time to write one? If enough people are interested I’d be willing to give it a shot.

So, there it is. I don’t use RSpec. So flame away and tell me know if I’m a genius or a moron.

I’m glad to help announce RailsBridge, a great idea put forth by Mike Gunderloy. Mike invited me (and many others) last week to join his concept for a positive approach inside the Rails community, and so far things look promising.

I hope to help out by donating time and energy toward any public workshops the group may choose to host, as well do any writing and mentoring that may be needed. The group will do many other things, but for now those are the two that I feel most qualified to do (see here and here if you’re a new reader and don’t know what I’m talking about).

I wasn’t able to make it to RailsConf, but some other RailsBridge members are there, so find them, learn more about it, and join us if you’re so inclined.

A couple weeks ago I was pretty depressed about the state of the Rails community. But now, I’m more optimistic that ever.

Thanks, Mike.

Those of you following me on twitter already know that I’m learning Cucumber.

Traditionally I don’t test my views or controllers all that much. I know, I know, it’s heresy. But I’ve just never gotten much value from writing Rails functional tests nor integration tests.

Yet those of you who have been reading my articles or new book know that I’ve been immersed in TDD for a long time and can’t imagine writing any application without a decent test suite to go with it.

So what do I test? I test the models like no one’s business. I use test/unit or shoulda to drive the design of all the models I write, and I write a lot of tests covering every possible edge case I can think of.

But the controllers and views? Up until now it’s seemed like a waste of time, for several reasons.

First, most of my controllers are stupid-simple RESTful controllers. They’re as skinny as possible, because I move almost all of the real logic into the models. That way I can test my models with unit tests without trying to simulate a browser, and I find it easier to use script/console to play with models than with controllers.

Secondly, once the application gets to its first stabilization point, I find that HTML and CSS change way more often than 80% of the core application logic ever will. Writing tests for the views just means they’ll break after inconsequential layout changes. After all, views are just supposed to be a representation of your models (generally speaking), and other stuff (navigation, ajax effects, etc.) just aren’t worth my time writing a regression suite for.

As much as I’m digging Cucumber’s syntax, I’m desparately close to just going back to test/unit and forgetting about the controllers again.

Convince me otherwise. Do you test your controllers and views? If so, with what – Rails functional tests in test/unit? RSpec? Cucumber? What are you trying to verify in your tests, and why?

---

Is your team switching to Rails? Sign up for a fun-filled, one-day class in your own office: SwitchingToRails.com

Photo credit

A little while back, Brian and I were glad to be asked to appear along with James Avery on the ALT.NET Podcast.

We mostly focus on issues that are of interest to those who are straddling that line between day-job .NET and night-time Rails, but we also touch on other topics as well.

So give a kick and a listen to our episode about Rails and let us know what you think of it.

Sorry for the late notice – I was having too much fun at RubyConf last week – but I’ll be speaking at the upcoming ChicagoRuby meeting this Saturday. If you’re in the neighborhood, come join us!

ChicagoRuby is headed up by Ray Hightower, the same guy who made Windy City Rails a reality. You can let us know you’re coming by using this Meetup.com link.

See you there!

Thanks to all who attended REST with Rails. I had a great time, and it seems that everyone else did, too.

Starting from the very beginning, we explored how Rails makes it easy to do RESTful development, making it easy to build web applications.

It was especially cool to have a nice mix of developers, some who are currently using the Microsoft ASP/ASP.NET stacks, some who just quit their jobs to start their own businesses, and others who are just want to know what REST is really all about.

I’ve very grateful to the warmth and hospitality at FiveRuns, for opening up their great office space for us. I also want to thank Damon Clinkscales who helped spread the word at Austin On Rails.

I’m already starting to plan for the next Purple workshop. Once again, I’m open to suggestions on location and topic (planning on doing the intro to REST again, but would be up for the 2-day Essential Rails again, too).

Let me know!

Photo credit

I once knew someone who lived in a pretty cool apartment. The building had nice architecture on the outside as well as on the inside. There was a neat archway that joined the living and dining rooms. And the floorplan was somehow laid out to help a small space feel bigger than it was.

But, you’d hardly know it if you hadn’t been there at least 10 times. The person living there had stuff strewn all over. Things were cluttering up the space, making it far less usable and enjoyable.

Think of your Rails app like the interior of home. There are many rooms. Some of them have specific uses. The interior architecture influences how you live there.

Your objects live in your Rails app. Your models, views, and controllers need to communicate with each other and work together.

Rails dictates an MVC architecture. If you don’t follow that architecture, you’re going to make things harder on your objects to work together. If you put spatulas in the bathroom and the fridge in the bedroom, making dinner will be a lot harder than it ought to be.

So don’t be trying to have models generate HTML. Don’t have controllers go poking around the internals of all your models. Don’t have views trying to do a ton of queries.

If something feels hard to do in Rails, 95% of the time it’s because you’re cluttering up your app with objects in the wrong places, that you can’t leverage the wonderful architecture that surrounds them.

Photo credit

Suppose you’re trying to be a good Rails developer and use RESTful routing wherever possible in your application. Using the ever-present blog example¹, you might implement your PostController’s index action like this:

def index
  @posts = Post.all unless request.format.rss?

  respond_to do |format|
    format.html  # render posts.html.erb
    format.xml   { render :xml => @posts }
    format.rss   { @posts = Post.all(:limit => 10, :order => 'created_at desc') }
  end
end

In other words, for HTML and XML clients, we return all the posts, formatted accordingly. For RSS readers, we only give out the 10 most recent posts².

Without doing anything special, this url:

/posts.rss

will automatically use /app/views/posts/index.rss.rxml (which we have to write) to generate our RSS data feed.

But I Knew That Already

Ok, but suppose you’re converting an existing site, and your readers already grab your feed at this url:

/posts/feed

Now, our code won’t work. Rails will try to call the show action, using feed as an :id parameter. Not good.

At this point, the easiest thing to do is to add a custom action to your controller:

def feed
  @posts = Post.all(:limit => 10, :order => 'created_at desc')
  # render default template
end

Rails will automatically find a template named, say, app/views/posts/feed.rxml and use it generate the feed.

But those who know me, know that I despise custom actions. Yes, once in a blue moon I have to use them. But in this situation, I prefer to use a more elegant solution: routes.

Ok, But Did You Know How To Do This?

We need to support /posts/feed as our url for RSS feeds. Remember that Rails routing allows us to route any url we want into any controller action we want. So somewhere above the map.resources :posts line in our routes.rb file, we do this³:

  map.feed 'posts/feed', :controller => 'posts', :format => 'rss'

And now if you go to /posts/feed, your glorious index action will be called and will respond as if an RSS client has made the request.

Cool, no?

¹ At our workshop, we will build something more interesting than a blog.

² We’ll also learn how to use named scopes to simplify this kind of code.

³ Even in development mode, you might have to restart your local server (mongrel or webrick or thin or whatever) to get Rails to pickup your routing changes.

---

Ready to learn more about RESTful development? Register now for REST for Rails before the seats are all gone.

Suppose someone told you that they are an Olympic athlete. What would you know about them? You could safely assume that they’re in great physical shape. But you’d have to ask more questions: what kind of athlete are you? Are you a swimmer? A runner? Maybe you do archery?

Even knowing the sport might not reveal all of their talents. For example, many Olympic events have a variety of events associated with them. To qualify for the swim team, you have to swim in multiple ways: freestyle, butterfly, backstroke, and breast stroke. Gymnasts also have to be good at a lot of things to be considered Olympic material: not only the floor exercise, but also the pommel horse, vault, and rings, and I don’t know what else.

Swimmers who only excel at freestyle swimming might be great at freestyle swimming, but they’ll never really be able to be good enough to make the Olympic team. Gymnasts who are great at the pommel horse, but never bother to learn the other disciplines, won’t make the team either.

Umm… Isn’t This Blog About Rails?

Ok, I’m getting to the point… Perhaps you currently consider yourself to be a real cool Rails developer. But do you really take the time to learn all of different skills that entails?

If there was a Rails event at the Olympics, would you qualify?

Here are the main “events” that I think Rails developers need to be good at to be considered “Olympic” quality.

Ruby

First and foremost, how is your Ruby? When was the last time you learned something new about Ruby? I don’t mean Rails. I mean Ruby. If you haven’t been able to refactor your code into something simpler and clearer, then you probably need to spend more time with the Ruby language.

ActiveRecord

ActiveRecord has actually gotten pretty big. Some features may exist that you don’t know about, or don’t know how to use (has_many :through and named_scope come to mind). Learn them. Use them. They can simplify your code. Not sure about the difference between association proxies and arrays? Wondering what SQL calls ActiveRecord is really making on your behalf? Then it’s time to do some strength conditioning and learn more about it.

Views

Maybe you’re feeling pretty good with your HTML views. How about your Javascript skills? Are you using the best possible form_for syntax in your views? Have you learned how to use view helpers to DRY up your view code?

SQL

Just because ActiveRecord writes SQL for you doesn’t mean you don’t have to learn SQL. It’s a muscle that we Rails developers can avoid using, but that probably mean that it’s atrophied. I know for myself, SQL is probably my weakest link when it comes to Rails development. I need to spend more time in the SQL gym, so I can better understand and improve upon the database performance in my apps.

REST

If you’re not doing RESTful development, but you’re using Rails 1.2 or higher, then you really need to get on the ball. Or maybe you think you’ve got the RESTful thing down pat, but you still end up adding a bunch of custom actions to your controllers. If so, then it’s time to see your friendly neighborhood trainer and get your REST skills in shape. Your apps (and your boss) will thank you.

Anything Else

You probably feel a twinge of guilt about some area of Rails that you know you should get better at, but you just never seem to have the time. Do you know how to write a plugin? Do you know how to contribute a patch to Rails? Do you need to get better with subversion or git? How about deployment? The list could go on and on.

If you want to say you’re a professional Rails developer, you can’t just be good at script/generate model Product. Identify what you want to learn next, and learn it.

Have you learned something recently that really helped you get to the next level in your Rails coding? Or, is there a weak area that you know you want to get better at? Drop us a comment and let us know.

---

Ready to learn all about REST with Rails? Our next workshop is coming up fast (Oct 4, 2008), so register now before all the seats are taken.

Frederick Cheung has done a great job eliminating the spam problem that had been plaguing the Ruby on Rails Google Group. I had more or less abandoned the group months ago, because the value of the group had plummeted.

But lately I’ve enjoyed posting questions and answers there again. If you have never tried the Google Group (also mirrored here if you prefer a different UI than Google’s), I recommend it.

Thanks to Frederick for volunteering his time and energy to serve the Rails community this way.

---

New to REST in Rails? Join us at REST with Rails Oct 4, 2008, in Austin, TX

Registration is officially now open for REST with Rails, coming to Austin, Texas on Saturday, October 4, 2008.

---

REST with Rails

When: Saturday, October 4, 2008, 8:30am – 5:00pm

Where: FiveRuns Offices: 209 West 9th Street, Suite 100, Austin, Texas 78701

Cost: $295.00

---

If you’re new to REST and want to learn what all the fuss is about, join us for a fun, one-day workshop! We’ll cover all the basics of RESTful development with Rails. This class is geared for those new to REST, regardless of how long you’ve been using Rails. (We assume you can at least create a simple Rails app, but not much more than that.)

All of our workshops have a friendly atmosphere. There really are no dumb questions. We use an informative combination of slides and live coding demos instead of long, boring powerpoint presentations.

And, thanks to FiveRuns, this public workshop will be held at their brand new offices in downtown Austin, Texas!

Seating is quite limited, so read all about it and then sign up!

(Those who signed up for early notification should have received your discount code. If for some reason you didn’t get it, please let us know.)

Thanks, and we hope to see you there!

Most people who start learning Rails today quickly learn about generators. They’re easy to use and very handy.

Still, like any other code-generation device, it’s important to understand what they’re doing when you use them. I thought that would go without saying, but I should know better. I remember back in the day of ATL COM programming on Windows, adoption of ATL really took off when Visual Studio added a few wizards to help you create COM components easily. The number of people who didn’t realize what it was doing was surprising. When the smallest bug or issue would come up, they were at a loss to know what their program was doing. To be fair, I also didn’t know what the wizards were doing when I started learning, either. I finally learned how to create COM components by hand (IDL….yuck), and once I did a couple, I knew everything I needed to know. Using the wizards after that was fun and helpful, since I knew how to change (or fix) anything I needed to after the wizard had generated its code.

Ok, back to the present… once in a while I notice that people don’t really understand Rails generators. I don’t really think it’s worth a blog post to explain all of them, but I did want to mention a quick tip that you might not already be aware of if you’ve just recently started with Rails: if you do this,

c:\myapp> ruby script\generate

(and then wait a minute) you’ll get a page showing all the options and generators available.

You can get specific help on a generator (say, the scaffold generator) like this:

c:\myapp> ruby script\generate scaffold

The help that’s emitted to the console is dense but usually quite complete.

Just do me one favor: after using a generator, learn what it did for you. There’s nothing a generator can do that you can’t do yourself. They just take the tedium out of some common Rails tasks that you’d otherwise have to do by hand.

Now, if you’d like to see an article on a specific generator, or have other questions about Rails generators, just drop us a comment here.

---

New to REST in Rails? Come to REST with Rails Oct 4, 2008, in Austin, TX

Announcing the next Softies on Rails class!

Here’s the scoop:

---

REST with Rails

When: Saturday, October 4, 2008, 8:30am – 5:00pm

Where: Downtown Austin, Texas

Cost: $295.00

---

Wait… Austin?

We usually hold our classes in Chicago, but we know that not everyone can make it to Chicago. So earlier this year we asked you to vote on where we should hold our next class, and what the topic should be.

Here’s the results of the location poll. Austin won by a slim margin over Southern California, 22% to 20%:

And here’s the result of the topic poll. A one-day “REST and Web Services” class was the clear winner:

Thanks for everyone’s patience – we know it’s taken a little while to pull this together (and we’ve been a little busy this year).

We’ll be able to run this class as a Purple Workshop, Jeff’s side venture for putting on short, fun classes for beginning Rails developers.

What To Expect

If you’ve never attended a Softies class before, here’s the 10-second summary: we aim for a “no question is too dumb” atmosphere; geared for those new to Rails (or at least to the topic of REST); and value live coding demonstrations over boring powerpoint presentations.

For complete details, head on over to the official workshop page . Sign up to be notified when registratation opens (which should be in about a week or so). We’re limiting the class size to only 15 this time, so we recommend you join the notification list.

Questions? Reactions? Let us know by leaving a comment.

Thanks, and we hope to see you in Austin!

Came across an interesting thread on the Ruby-Talk google group. Eric Hegwer started it by asking the question, “What was YOUR first Ruby project?”

It’s fun seeing the wide spectrum of answers. People were using Ruby for things I would never have dreamed of.

I’d like to ask our readers a similar question: what was the first Rails app you wrote? Maybe you never made it public, but what was your first Rails project?