In my last article, I showed how to implement authentication with Ruby on Rails. But security is about more than simple login. For many applications, we want to grant permission to manipulate a resource to a set of users. In this article, I will guide you though adding functionality so that users can modify the permissions for who gets to edit an article. Before we start implementing access control, we should get our application ready by encapsulating all access control checks.

In my previous articles, I have showed you how to create a simple blog application with articles, comments, rss feeds and formatting. However, as it is currently written, the application allows for anyone to create or edit an article. This is a serious security issue, and we better fix it. In this tutorial, I will show you how to make sure that only logged in users can create articles, and that nobody else can edit an article that you created.

If you though getting started with Rails seemed easy from my first post, you haven’t tried out Heroku yet. Heroku is a hosted solution for Rails that comes with a browser based IDE. There’s nothing to install. It is so easy that it’s almost ridiculous. To me, this is the future of application hosting. One of the remarkable things about Rails is that it lets you get up and running very quickly.

This is the fourth article in my introduction to Rails. In the previous articles, we created a web application that let us edit articles, added support for comments to our articles, and added some nice AJAX effects. But a real blog needs feeds, a decent front page and some article formatting. In this article we will add all these. The article contains no groundbreaking features, but mostly dots a few i’s and crosses a few t’s both when it comes to the blog we’re building, and details in Rails.

In my previous articles, I showed you how to get started using Rails, and how to create model objects that are associated with each other. In this article, we will clean up the way that information is displayed and add support for dynamic HTML, or as the cool kids are calling it these days, AJAX. A view to die for First, clean up app/views/articles/show.hml.erb. I am assuming you know enough HTML to be able to make it look reasonably blog like.

In my last article, I showed you how to get started with your Rails application. The result of the simple commands, rails blogdemo; cd blogdemo; ruby script/generate scaffold article title:string author:string content:text; rake db:migrate; ruby script/server was that you had your own simple blog up and running. The blog support articles each of which have a title, an author, and text content. This initial model was generated for us with no editing on our part.

I am planning to write a series of articles on how to get started with Ruby on Rails. One of the remarkable things about Rails is that it lets you get up and running very quickly. Here is what you need to do to get your first application up and running. Before you start, you need to install Ruby on Rails: On Macs, Rails is already available and you can type the following commands in a normal terminal window.

The Norwegian word “smidig” means “agile”. So when we wanted to make a Norwegian conference for the Oslo Agile community, “smidig 2007” (November 26th and 27th) was a natural choice for a title. The seed of the conference was idea by Nils Christian Haugen and Aslak Hellesøy to have a whole day devoted to open spaces. Meanwhile, I had been experimenting with “lightning talks” on Oslo XP meetup, a user group that meets in Oslo every month.

Inspired by the “Hi, I’m a Mac” ads of Apple, Gregg Pollack and Jason Seifer has made these cute Ruby-on-Rails ads (featuring Ruby-on-Rails versus Java and Ruby-on-Rails versus PHP): Click here to view on YouTube

I often criticize products from the big vendors like IBM, Microsoft and Oracle for what I call the “New Coke Effect”. As retold by Malcom Gladwell in Blink, Pepsi introduced blind taste tests in the 80s. They beat Coca Cola by a big margin. In order to regain the advantage, Coke developed “New Coke”, a product that was optimized for the blind taste tests. It tanked. Totally. It tanked so bad that coke had to have the words “classic coke” prominently on the label until 2002.

Some time back, I watched a video David Heinemeier Hansson give a talk on ActiveResource on RailsConf. The thing that struck me is how much Rails’ ideas are connected to those of Domain-Driven Design. Watching DHH is like seeing a version of Eric Evans on speed. The video is long, but very entertaining. And it is well worth watching even if you couldn’t care less about Rails. DHH explains in real concrete terms how to think in terms of Domain-Driven Design, even though from the sound of it, I don’t think he’s heard of the term.

David Heinemeier Hansen’¨s talk at OSCon is available at IT Conversations. For those who don’t know, DHH is the man behind the big rising star of 2005: Ruby on Rails. Favorite quote: “Too many technologies are chasing flexibility as thus it was free. It is not. Your exchanging flexibility for velocity in development, for a delay in changing you mind, and it is really a bad notion! … In other terms, constaints are liberating”