SXSW was awesome and I can’t imagine it being any better, which exceptions noted below…
I didn’t bother with day-to-day updates. There are plenty of those to go around. While I do have some pics, you’ll find a whole lot of those on Flickr.
For
me, it was about getting the chance to meet and hang out with a lot of
people I’ve followed for a while online and have a great deal of
admiration for. If you are in web design or web development at all, you
should attempt to make it next year.
The key to having the best
time at SXSW is to be social. While there are a few great panels, most
could be better. It’s at the parties and social events and bars where
you’ll get the most out of the entire experience.
Later
today, I’ll be headed down for SXSW Interactive. From what I hear I
expect it to be a blast. I hope to see a lot of people, learn a lot of
things, drink a lot of beer and mostly have fun.
I’m just beginning to dive into this,
but it’s got me excited. They’ve got two versions of each source file,
a build one with all the comments and a src which is already compressed
for you.
Having worked for a while with Prototype and Script.aculo.us
I’m curious to see how they compare. Seems like Script.aculo.us
provides a lot of whiz bang effects the Yahoo library doesn’t have, but
you do have all of these:
animation
calendar (not sure if there’s a dropdown version)
connection (ajax stuff)
dom
dragdrop
event
slider
treeview (particularly cool)
My biggest issue about it so far is that you’d have to type the namespace of YAHOO about a zillion times. Typing
[UPDATE:
My example for the issue of Rails generating too much database traffic
was actually incorrect for Rails v1.0. Luckily, v1.1 introduced
bottomless eager loading, which addresses it. I’ve revised the example
below.]
If you have been following anything related to web development at all, you have at least heard of Ruby On Rails.
If you’re like me, it makes you want to take a flying leap into
developing with it. For personal projects there’s nothing to hold you
back. However, if you decide to recommend using Rails with a team that
doesn’t know much about it, you may run into some questions. If you
don’t have some ready answers, the idea will most likely be shot down
quickly and left in the dust.
I don’t like using ‘id’ as my primary key name.
Rails is written to expect the field ‘id’ as the primary key to any typical table. Therefore, ‘id’ in a users table would refer to a user id just as ‘id’ in a product table would refer to a product id.
The
important thing to know in order to combat this issue is to that while
‘id’ is highly recommended as a primary key, it’s definitely not
required. Here’s an example of creating a User model in rails, but
telling it that the primary id is UserID instead of ‘id’.
class User < ActiveRecord::Base
set_primary_key "UserID"
...
end
In addition, by naming your own primary key, you need to
assign it a unique value prior to saving anything new to the database.
Rails can’t assume your new field is auto-generating or not, so it
leaves it up to you to set.
My legacy data doesn’t use that naming scheme.
While
you are free to use any naming scheme you want, Rails is definitely
built to work with its preferred naming scheme. The main thing to keep
in mind, in addition to dealing with how Rails works with your primary
keys, is you may have to add code to inform your objects how they are
related to each other via the database. You could also lose out on
automated functionality like Rails ability to automatically take care
of fields like created_at.
Rails generates too much database server traffic.
Some
people are quick to say Rails makes way too many database calls when
you have a number of objects related to each other in one-to-many or
many-to-many relationships. This is because Rails does not load data
into objects until they are referenced.
For example, if you
have an Order and LineItem object where an Order can have many
LineItems which in turn are linked to Products you could have something
similar to the following code.
for order in Order.find(:all)
puts "Item ordered: #{order.line_item.product_id}
puts "Description: #{order.line_item.product.description}
end
In this example, there would be one database call for the
main order, then two calls to retrieve the line item information then
the product description. Here’s a much better approach.
for order in Order.find(:all, :include => {:line_items => {:product}})
puts "Item ordered: #{order.line_item.product_id}
puts "Description: #{order.line_item.product.description}
end
Very similar code, but in the latter version the :include
attribute tells Rails to preload the line items and products, so it
loads up everything in one database call rather than multiple ones. You
also have the option of using the find_by_sql function to specify your own custom call.
It’s difficult to find hosting
Finding
a host isn’t much of an issue if you have your own server, but if
you’re looking for a shared host, not every host offers it. The number
grows steadily, though. TextDrive is a leader in Ruby on Rails hosting, but you can find a growing number of hosts on the Ruby on Rails website.
What about performance
Another
frequest concern about Rails is about it’s performance and ability to
scale. While some think it may be good for small and possibly mid-sized
projects, it doesn’t have what it takes for large scale applications. A
lot of this is just knee-jerk reaction. The great thing about the Rails
community is that there is constant work on making things better.
RailsExpress
is one website that is focused on Rails performance. In addition to a
lot of benchmarks, it also includes a lot of tips for making Rails apps
perform better.
TextDrive also has a weblog which has some of their experiences being a host for Rails apps. Optimizing Rails Resource Usage is one and I’m sure they’ll post more.
Just as you’d expect with any framework and language, the better the code you write, the more efficient it will run.
Have other questions?
There’s a number of great places to find more information on how Rails works. A number can be found on the Rails webpage for documentation. The Ruby on Rails API documentation
is the most up-to-date resource since it is actually generated from the
code itself although it’s more like looking up things in a dictionary.
For a more hands-on, descriptive resource you should really have the book Agile Web Development with Rails.
I have to warn you that the first part of the book will get you ready
to tear into your first application, but the juiciest information is in
the latter part which goes into more details about the underlying Rails
framework.
Rails is written to expect the field ‘id’ as the primary key to any typical table. Therefore, ‘id’ in a users table would refer to a user id just as ‘id’ in a product table would refer to a product id.
While
you are free to use any naming scheme you want, Rails is definitely
built to work with its preferred naming scheme. The main thing to keep
in mind, in addition to dealing with how Rails works with your primary
keys, is you may have to add code to inform your objects how they are
related to each other via the database. You could also lose out on
automated functionality like Rails ability to automatically take care
of fields like created_at.
Some
people are quick to say Rails makes way too many database calls when
you have a number of objects related to each other in one-to-many or
many-to-many relationships. This is because Rails does not load data
into objects until they are referenced.
Finding
a host isn’t much of an issue if you have your own server, but if
you’re looking for a shared host, not every host offers it. The number
grows steadily, though. 
Another
frequest concern about Rails is about it’s performance and ability to
scale. While some think it may be good for small and possibly mid-sized
projects, it doesn’t have what it takes for large scale applications. A
lot of this is just knee-jerk reaction. The great thing about the Rails
community is that there is constant work on making things better.