Last weekend I was lucky enough to attend RailsConf in Portland OR. For the unfortunate who weren’t able to attend, it was a 1600 nerds attending dozens of seminars on the latest and greatest technologies and techniques for working with Rails. Some of the stuff was really niche and I didn’t really feel like it applied.

I hope amazon paid an ton for the 3+ sessions that where devoted to S3 and EC2. I know this is new exciting technology, but it seems like it only applies to the thoroughly scaled application and not so much for the lowly startup.

I learned a lot about different testing methodologies and got a good dose of REST, these are two things I will soon be focusing my development on, so I was excited to learn more about them from the proverbial horses mouth.

I have the best of intentions of writing an article about each of the sessions I attended, but it might take me a while to get it all written and posted, so don’t hold your breath.

In the mean time:

Conference Slides
Official Conference Website

The wiki is probably most pertinent for those who want to know what actually happened, not just what was expected.

To make short 45 minutes of frustration… Yes it is possible to fragment cache your rjs data. The only difficulty is that you can’t do it within RJS.

If you can’t bring a horse to water you bring water to the horse.

So at this point I toyed with the idea of renderng rjs templates *within* rhtml templates. The first barrier to entry is the return type, but you can fix that by changing the header in your controller, before you render:

@headers["Content-Type"] = 'text/javascript'
render :action=>"index_render_rjs", :layout=>false

By rendering an rhtml template this gives you the ability to cache inline. I tried a couple theories on how to render rjs in my rhtml template and the following worked for me:

<% cache("token") do -%>
<% prepare_data() %>
<%= render :update do |page|
page.call("Something")
page.visual_effect :appear, 'a_field'
end%>
<%end%>


This put together works pretty well.

The only reason to do this is if you push your sql calls into the cached section of the page so that they aren’t executed when the page is cached. This is breaking with MVC and a memcache solution is probably semantically superior, but this works too and makes the whole process a lot faster.

I’m sitting here twiddling my thumbs right now while my application deploys itself.

Rails has completely changed the way I work on the internet. Before I used to manually push individual files up via ftp. I made manual backups of my files using my own proprietary naming schema’s. If there where problems I had to run through a checklist of things I could have done wrong. Sometimes I’d have to go thorough the entire process again to get the darn thing working right.

Up until this last project I even did this with my Rails work. I will never go back!

I’m using a set of tools now including Radrails (my IDE of choice), Subversion (versioning and repository/backup) and Capistrano (Deployment). To deploy I select my updated files in Radrails and commit them to Subversion by right clicking and selecting commit. Once the files have been I go to a console navigate to my project and type “cap deploy”. This kicks of Capistrano and all I have to do now is wait.

Configuring all these tools can be a pain the first couple times, but I only have to go through that process once per project. After that they pretty much deploy themselves. You can even write variable deployment recipe’s for deploying to different test environments.

If this goes over your head, don’t worry. If you need to know it give it some time and exposure. If you don’t have a practical use nod and move on with life. There is a world of magic and mystery here that most lay people should probably remain distanced from.

I Google this info about every 48hours, so I figure it’s time I made it closer to my fingertips. This post is not original. I am blatantly coping from here.

In the order I use them:

Basic migration functions

• create_table(name, options)
• drop_table(name)
• rename_table(old_name, new_name)
• add_column(table_name, column_name, type, options)
• rename_column(table_name, column_name, new_column_name)
• change_column(table_name, column_name, type, options)
• remove_column(table_name, column_name)
• add_index(table_name, column_name, index_type)
• remove_index(table_name, column_name)

Commands I commonly use:

• rake migrate RAILS_ENV=”production”: run on production server after deploying project
• rake db_schema_dump: run after you create a model to capture the schema.rb
• rake db_schema_import: import the schema file into the current database (on error, check if your schema.rb has ”:force => true” on the create table statements
• ./script/generate migration MigrationName: generate a new migration with a new ‘highest’ version (run ’./script/generate migration’ for this info at your fingertips)
• rake migrate: migrate your current database to the most recent version
• rake migrate VERSION=5: migrate your current database to a specific version (in this case, version 5)

I’ve been looking at REST for a couple weeks now and I’ve determined that the next new project I start will be under REST.

What is REST?
REST is a standardized way of building complexed web interfaces for CRUD objects. CRUD is great conceptually, but its lack of strict standards makes it common to build separate interfaces for different formats (xml, javascript, html, rss, atom, etc…) and also creates the need for complex transfer protocol for handling interactions between servers (SOAP, CORBA, and other RPC standards). REST represents broad ranging standardization as well as making room for Active Resources which is the future of the RPC world.

For the most part, Rails already has a pretty standardized CRUD interface, so the first question I asked myself is:

So what changed?
As I perceive it, the majority of the changes take place in the routing. There are a lot of functions that are automatically generated and become handlers, connecting the html links and forms with the generated routes. REST also enables you to setup cascading objects while keeping pretty URLs.

Routes
Rails developers are pretty accustomed to URL’s that look like :controller/:action/:id followed by a query string with anything else. Under REST the most standard actions do not appear as part of the URL (new and edit are exceptions to this). The are now implied by the way in which the URL is called. Methods, formerly just POST and GET (think forms) are now POST, GET, PUT, and DELETE mapping directly to Create, Read, Update, and Delete. PUT and DELETE are indicated with hidden fields in browsers where they are not available as methods.

Functions
With all these default routes, it can be cumbersome a pain to assemble all the paramaters needed to create a URL or worse attempting to define URL’s explicitly. So to link everything together REST automatically generates functions that will take in paramaters and spit out either URL’s or hashes of paramaters needed to generate URLs. A plural function name implies that you are working with multiple objects or creating a new object while singular indicates that you are viewing or operating upon that object. When these functions generate URL’s they don’t continue to reflect the plural/singular…

Path Examples:

Each example has three functional counterparts, one for generating hashes, another generates complete URLs, the last one adds formatting information.
object_path(:id) becomes hashed_object(:id) or object_url(:id) or formatted_object_path(:id) respectively.

Cascading Models
So most Rails programmers have run into the situation where your passing 2 or more foreign keys along with your objects information.
Ex. User has_many Books has_many Chapters etc…
And when you go to make a modification to a chapter you want to make darn sure this user is editing his own books and not someone else’s. So you pass foreign keys, into the chapters controller every time anything happens so that you can track scope. The RESTful approach allows all of this to become implicite. Rather than passing foreign keys along as auxiliary paramaters they are now passed as part of the route. So you end up with URLs like
http://www.example.com/users/:user_id/books/:book_id/chapters/:id
which is way more intuitive than
http://www.example.com/chapters/:id?user_id=:user_id&book_id=:book_id
as it occurs so often in my own applications.

Advantages
More security: with every route explicitly specified it’s more difficult to allow access to critical system features without doing so intentionally
More Standardized: If you need to work with someone else’s code it’s convenient if they are using the smae standards driven conventions that are ingrained in your head.
More concise URLs: As many actions are removed from the URL
More descriptive URLs: As cascaded objects are represented in a more intuitive way the URLs become more human friendly
Active Resource: Ultimately REST paves the way for Active Resource. There is a lot of minor prettying up for which REST can kind of justify itself, but as Active Resource comes into its own I predict that a lot of people will begin to operate within REST just because it gets them to Active Resource.

Disadvantages
Learning Curve: So Rails itself requires a pretty avid fan to survive the initial learning curve. You have to have some sense of object oriented programming, database design, software testing, etc… just to make it to your first production launch. REST is another learning curve, with conventions to memorize and a little bit more magic to come to terms with.

Conclusion:
REST is worth it. If you’re reading this then you’re doing the right thing by keeping your eye on the horizon. When this arrives, bringing Active Resource with it, I look forward to seeing how the industry reacts. This is the kind of stuff that bumps Rails up into the niche occupied by SOA and so many other infinitely more complicated frameworks. Standards make corporate america go round, and this is bound to turn some heads.

Learn more:
PeepCode Screencast & Cheatsheet
Detailed Wiki Article
How this stuff works, and more on Edge Rails

General Hype:
Article covering “Why is REST important?” in dialog form
More of the same
Both of these came from LoudThinking which you should be reading if you’re not already

So I’ve been wrestling through another technical problem the last couple hours. I have databased email formats that are structured as rhtml so that they are both dynamic and easy to modify. Nothing new here. I want to be able to pre-render them using render_to_string(:inline=>code) so that I can capture the output and store that to database as a log of which messages are sent to whom.

The problem lies in my desire to do this at both the model and controller level. The function render_to_string is available strictly within the scope of the controller. There is probably a simple reference or something that can be used to drop the functionality to the model level, but after scraping around the internet for half an hour the best I could come up with is some obscure reference to using blocks…

I’ve spent almost a full year avoiding learning more about blocks. I’ve written thousands of lines of ruby code and have failed to really come to understand one of the most fundamental advantages this language has to offer. In this case using blocks allows me to yield from the model to the controller, execute render_to_string in the controller scope and pass the result back into the model. On a pragmatic level this is really cool because while it is very common to have a parent object have access to all aspects of its member objects it is not common to be able to allow those members access to their parent, but the magic of blocks goes much deeper.

I need to spend a little more time looking at ruby from an academic perspective so I can work more effectively.

code sample:
Controller level

def refer_to_provider
    @order = Order.find(params[:id])
    @shipment = @order.order_shipments.find(params[:shipment_id]) if @order
    if @shipment

      @shipment.refer{|opts| render_to_string(opts)}

      flash[:notice]="Shipment has been referred"
      redirect_to :action=>:show,:id=>@order.id
    end
  end

Model level

  def refer
    mark_referred
    variables = {:order=>self.order, :shipment=>self}
    format = CommunicationFormat.find_by_token("submit_to_provider")
    subject = yield(:inline=>format.subject, :locals => variables)
    body = yield(:inline=>format.subject, :locals => variables)
    Sender.deliver_send("orders@yourdomain.com", self.provider.fullfillment_center_email.address, format.token, subject, body, self.order)
  end

Inspiration
Info on blocks