Digg

Discover the best of the web!
Learn more about Digg by taking the tour.

Starting Ruby on Rails: What I Wish I Knew

betterexplained.com — Ruby on Rails is an elegant, compact and fun way to build web applications. Unfortunately, many gotchas await the new programmer. Now that I have a few rails projects under my belt, here ’s my shot at sparing you the suffering I experienced when first getting started.

Bury

ronin691 1 year 38 days ago, made popular 1 year 38 days ago

1179 diggs
digg it

ronin691, on 10/11/2007, -1/+10I forgot to post the URLs for the videos, they're funny:

http://www.youtube.com/watch?v=H868NSM2yAg
http://www.youtube.com/watch?v=p5EIrSM8dCA
- rebotfc, on 10/11/2007, -14/+3guh replied at wrong point, bury:/
- brundlefly76, on 10/11/2007, -11/+8Biggest gotcha is that Rails scales poorly
- Chandon, on 10/11/2007, -6/+11brundlefly76 -
  So... you have no idea what's going on, but you heard a rumor that another language - maybe Java - was better than everything else because of "scalability". You're not sure what it means, but it sounds like it would be important in an "enterprise environment", right?
  
  The programming tools you use to build a web application are not the bottleneck for scaling. Any of these MVC toolkits will scale fine, as would any of the non-MVC toolkits. In web application development, the scaling bottleneck tends to be the database.
  
  It's possible that some intensely compute-bound web app that Rails might be *slower* than Java or PHP, but in an application where "scaling" is the issue that just means that you need more servers in your cluster. Rails takes less programming time though, and a web server in a cluster costs less than what you'd pay a developer for 2 weeks of work.
- resplence, on 10/11/2007, -5/+5@Chandon:
  Your comment would be alright if it wasn't for the ad hominem assumptions and the gratuitous pejorative tone. No need to be a dick to make a point.
- daftman, on 10/11/2007, -3/+4@Chandon
  Scalability is the one of the largest requirement for enterprise. It is what differs the toy products from the real heavy weight. When you are talking about business with millions to spend what do you think matters more? development cost or lost of productivity due to low performance and bad scaling?
  Furthermore, language like java has much more documentation than ruby. Java framework such as EJB has been proven to work in the enterprise level where as RoR is currently still under development, ad hoc documentation.
  
  And no, I am not a Java fan. I'm a professional developer who uses ruby, java, python and c++. However, I am realistic on what RoR can deliver. From what I've seen a lot of RoR solutions are hacks and most of Rails are poorly documented. Until this changes RoR won't be a first class enterprise solution in comparison to J2EE or .NET
- brundlefly76, on 10/11/2007, -4/+4@Chandon
  
  Uh, no, I've been a Linux web developer for 12 years and always give new technology a try - its habitual.
  Rails doesn't scale well, period.
  
  Although alot of people who like Rails are willing to upgrade hardware, discard Apache for lighttpd, implement caching techniques, and stand on their head to *make* their Rails apps scale as well as other platforms which scale just as well if not better out of the box with Apache - and thats fine, if you like working with it then give it a go.
  
  However, putting sneakers on a bison doesnt make it a cheetah.
- jaydonnell, on 10/11/2007, -1/+2Chandon is right. The database is the bottleneck in the vast majority of web applications. Ruby is slower than it's competitors but it makes no difference since the database is the bottleneck. I run a rails site that gets a fair amount of traffic (30+k pageviews per day) and here is a line from my rails log. Notice that 72% of the time was spent by the database!
  Completed in 0.12397 (8 reqs/sec) | Rendering: 0.02406 (19%) | DB: 0.08931 (72%) |
  
  We do use caching which someone else mentioned. The above page was not cached; here is the log for a page where the heavy query was cached. We like to keep the site highly dynamic so we don't cache the entire page.
  Completed in 0.03163 (31 reqs/sec) | Rendering: 0.01979 (62%) | DB: 0.00760 (24%) |
  
  However, being slow and scaling are two different things. Rails scales fine. If the db isn't the bottleneck you can add a new webserver to improve performance. This is both cheap and easy relatively speaking.
- brundlefly76, on 10/11/2007, -0/+2@jaydonnell
  
  Last time I checked, if an application platform ran so much slower then another that it required a substantially larger investment to scale to to the same level of user experience, then it doesn't scale well.
  
  This benchmark was done as a 'hello, world' with no database access:
  
  http://www.usenetbinaries.com/doc/Web_Platform_Benchmarks.html
- jaydonnell, on 10/11/2007, -2/+1@brund
  hello world with no db access is the farthest thing from a typical web application. Have fun if you want to base your decisions around that ;)
- brundlefly76, on 10/11/2007, -0/+1@jaydonell
  
  Exactly - presenting "Hello, World" is the least taxing web application I can think of.
  
  How is it that a more complex real work application would show better performance?
  
  Are you saying that as soon as a web application becomes more complex that Rails suddenly becomes faster?
  Thats nonsensical.
- jaydonnell, on 10/11/2007, -0/+1@brund
  I get the impression that you didn't read my comments. The database is the bottleneck for the vast majority of web applications. Drawing conclusions about scalability without considering the database is pointless. Did you see the logs I posted above? On non cached pages the db is 70-80% of the execution.
  
  The database is the issue for scaling most websites, not the language.
- brundlefly76, on 10/11/2007, -0/+1@jaydonnell
  
  In 12 years I have never worked on a site when an RDBMS was accessed on every page (never a good idea), nor have I ever used PHP or mod_perl with MySQL where the requests per second were affected to the degree of the numbers on that page - except perhaps during a special complex query here and there, like a search application.
- jaydonnell, on 10/11/2007, -0/+1i have no idea what kind of sites you are working on. If the db isn't accessed what is the code doing for the page? Let's use digg as an example. I'll wager that numerous db queries are made for 90% of the pages viewed. This page we are reading right now has the db as it's bottleneck.
  
  Can you give me an example of a site where the code would be a bottleneck and that doesn't hit the db often? I think you are arguing just to argue. But feel free to use whatever you want. Btw, it's trivially easy to scale a site that doesn't have the db as a bottleneck. Speed and scalability are two different things.
  - brundlefly76, on 10/11/2007, -0/+1"i have no idea what kind of sites you are working on."
    
    Well, one was Yahoo!, where I was lead developer on 5 different Yahoo! properties, none of which used an RDBMS.
    
    Digg *does* access MySQL a great deal - guess what? - its also a very slow site (Alexa: 80% of sites are faster).
    Also - Digg has more MySQL servers in their server room then they do webservers.
  - jaydonnell, on 10/11/2007, -1/+1you were a lead developer at yahoo and don't understand why a 'hello world' isn't a meaningful metric of scalability!?!? Time to sell my yahoo stock!
    
    But please give me a real example. Show me a page does a lot of computation and doesn't use a database. I can think of a few types of pages. Ones that manipulate images or some such. however that does not represent the majority of websites. But please show me an example. We'll see if hello world would be a meaningful metric for it.
    - Chandon, on 10/11/2007, -0/+2When you get into larger web applications, you build your own application optimized storage stuff rather than using a RDBMS. A good example would be something like Yahoo Mail or a major search engine. Once you get to that point in application development - where you have 20+ programmers on the project and you're going to be building your own storage stuff - there actually does get to be an argument for trading some extra development time for more execution speed. But... you have to be bigger than sites like Digg and Slashdot for it to matter, so for 99.9% of web developers the advice to not worry too much about language speed because the database is the bottleneck is correct.
    - brundlefly76, on 10/11/2007, -0/+1Chandon hit it right on the head, except that I disagree that 99.9% of sites it doesnt matter - kinda true, but.... Once you are familiar with the techniques of avoiding RDBMS use (hashed filesystem indicies, bulk pre-generated HTML layouts , flat file direct-access webserver shared memory usage, inverted index search tools (e.g. Lucene, etc), you may actually prefer them to an RDBMS regardless of the size of your next project.
      
      Why? Because its easier (tough learning curve, but once you know it..), faster, more reliable, and can be implemented on day 1 and you never have to worry about changing your core infrastructure to accommodate massive success ( for 2 of my websites, there were completely unexpected digg-type events which took the site from thousands to millions of page views a day permanently - with its original 3 webservers one would have fallen down during the digg event with an RDBMS solution)
    - jaydonnell, on 10/11/2007, -0/+1@chandon
      
      Exactly. hello world is not a valid benchmark for such large sites, AND it's not a valid benchmark for 99% of sites. I know you didn't mention 'hello world' but that is what started me on this rant. The idea that a hello world test has any bearing on scalability is nonsense.
      
      @brund
      I've used Lucene (ferret actually), but none of the other things you mentioned. Why don't we see more usage of these techniques over rdbms systems for the ones that aren't apples to orages? What is the trade off? Why can't the learning curve be abstracted away a bit more?
      
      As for Lucene, I'm going to guess that inserts take longer than they do in an RDBMS. Either way this still begs the question, will your programming language be the bottleneck? I'm highly skeptical and why spend more money using a trickier setup if you can scale well enough for 99% of cases AND with a faster time to market?
    - brundlefly76, on 10/11/2007, -0/+1jay, I could go on and on about how the reason this stuff isnt more popular is because of the popularity of SQL as a cuisinart for all data, and how we all see the world through SQL-colored glasses while ignoring its significant drawbacks, but this thread has gone way off topic. Keep checkign back to this thread and I will post a URL to a blog post on the subject, which I have been meaning to write anyway.
    - jaydonnell, on 10/11/2007, -0/+1I'll check back!
      
      You mentioned alexa saying that digg is slow so I did some digging (no pun intended). My company watched alexa like a hawk, but we've grown very skeptical of their stats. One thing you may not have realized is that their Avg load time appears to include the loading of all scripts (including ads). Safari's new webkit will show you the time it takes to load a page and break it down for all files/scripts loaded. Loading the page itself (this page) takes 800ms (fast) but loading all the scripts for ads pushes the total load time to about 4s per page. This is also true of one of the sites I work on. A page without ads will appear to be much faster according to alexa, but that may not be the case.
cruzlee, on 10/11/2007, -7/+4Warning, article contains humor:

"When you create your first rails app, the directories are laid out for you. The structure is well-organized: Models are in app/models, controllers in app/controllers, and views in app/my_local_views (just kidding)"
Squidly, on 10/11/2007, -0/+26"I wished I knew how to scale my website for a digg onslaught."
willistg, on 10/11/2007, -5/+1"elegant, compact and fun" and "many gotchas" WHA?

TURBOGEARS FTW!!!!!!!!!
sd123, on 10/11/2007, -12/+571 diggs, 2 comments, and already excruciatingly slow. Is this one of the RoR "gotchas" he wishes he had known?
- oracleofmist, on 10/11/2007, -3/+5honestly? are you seriously retarded? Diggs have no direct/indirect representation of the number of site views a page has seen. Even moreso, Digg is not the only site that links to stories. My favorite part about you being retarded is that you somehow think that comments hurt a website. Whether they are digg comments or the site's comments (i can't tell cuz the site is still trying to load) They hardly have any overhead unless the person who coded that page is a complete moron. If they were, you two would get along just great. Have a nice day being stupid.
dandiemer, on 10/11/2007, -1/+5google cache has it. http://72.14.253.104/search?q=cache:nJY5PuNeohQJ:betterexplained.com/articles/starting-ruby-on-rails-what-i-wish-i-knew/+betterexplained.com+ruby&hl=en&ct=clnk&cd=1&gl=us
kurious, on 10/11/2007, -2/+11Hey guys, thanks for the cached link. It's a Wordpress blog, I had WP-Cache disabled while doing some tweaks and then the Digg storm hit. As soon as I can log into my own machine I'll enable it.

And yeah, I'll have to do a "What I wish I knew before I got on Digg" article too... it's my first front page article.
- TenebrousX, on 10/11/2007, -1/+2Great, there aren't enough of those.
  
  "Digg gives drives lots of traffic to your site.
  Most users don't click on ads.
  Look at these charts: "
- kurious, on 10/11/2007, -1/+3Don't worry, was just joking about that :-). I saw there were a few articles on Digg just today on the same topic...
  
  No ads on my site btw, just want people to avoid some of the headaches I hit.
adidax, on 10/11/2007, -1/+12He says controllers have business logic. They shouldn't. All controllers should do it move information from models to views and views to models. All business logic *should* be contained in the model.
- locnguyen, on 10/11/2007, -0/+4Your code is strong adidax. There should be no, or very, very minimal logic in controllers.
- kurious, on 10/11/2007, -0/+1Yeah, I agree, it's best to have "fat models, thin controllers" and put the business logic in the model. I forgot to mention this but will add it in as soon as I can edit the page again.
  
  Most beginning rails examples do a lot of work in the controller, but it's good to continually refactor and trim down the controllers.
- daftman, on 10/11/2007, -1/+2Why do controllers have to have minimum business logic? Is there a proper reason to this?
  As far as I see, controllers are the glue between models. Each models should be modular and has minimum coupling between each other.
  If the point of the controller is to simply draw a view then you not using much of what a view can offer.
- jaydonnell, on 10/11/2007, -0/+1@daftman
  There are a few reasons to have fat models. It's much easier to test models. Controllers assume a web environment. Putting your logic in your models decouples it from the web assumptions. However, the idea that there shouldn't be much logic in controllers is wrong. Logic in controllers is fine, business logic in controllers is not. For example, logic that tests things related to the web environment (i.e. sessions, url's, etc) should go in the controller and not in the model. The view is something that should be easy for your designers to work on (i.e. minimal code).
rodgy, on 10/11/2007, -5/+3High-level applications such as those that use popular frameworks (RoR, Django, CakePHP...) use much more CPU. I prefer low-level programming. It's more machine friendly and it performs faster under heavy load.
- nater, on 10/11/2007, -0/+3There is a traditional trade-off between productivity and performance. Often hardware is cheaper than labor and bringing a product to market sooner is more economical than writing it for absolute performance. This may change in the future and high-productivity languages may become as fast as lower-level languages. The point is that these languages/frameworks are fast enough to work for the vast majority of web application purposes and increase the speed of the development of the application.
- FlaG8r, on 10/11/2007, -0/+3Did you think that anyone that takes the time to read this doesn't know that higher level languages use more CPU time?
- nater, on 10/11/2007, -0/+2I think that's actually a distinct possibility. Ruby and Rails have low barriers to entry, so more often than in lower level languages you see people with no programming experience attempting to learn them. His comment may actually educate someone, but if you just wanted to flame, then flame on.
- Chandon, on 10/11/2007, -0/+3Low level languages take significantly more programing time, and the performance gains are usually much less significant than one might expect. Frequently the performance bottleneck isn't CPU time at all - it's something like database IO. Even when the bottleneck *is* CPU time, it's frequently cheaper to write the program in a high level language and buy more servers for your cluster than it is to pay programmers to write in a lower level language.
spankr, on 10/11/2007, -7/+1I love it - "...server is taking too long to respond" RoR doesn't scale well...
- nater, on 10/11/2007, -1/+2You should read the previous comments, it's a wordpress blog. RoR scales horizontally, instead of vertically, so it can scale as large as you want. The major players on the web have proven forever that horizontal scaling it far the superior of vertical scaling.
- kurious, on 10/11/2007, -1/+4It's actually just a Wordpress blog running on PHP :-). Unfortunately I didn't have the caching plugin enabled when it got popular... just need to log in and enable it (fingers crossed).
s1mph0ny, on 10/11/2007, -6/+1Am I the only one who read this as Rudy on rails? How many Canadian mounties would save him though?
rebotfc, on 10/11/2007, -1/+3Rails is great, but there are some areas that can be improved to make it even better for newbies.

1) Deployment - a pain at the moment as Rails support in hosting environments is not as common as php. One of the major problems is to deploy properly you really need a ssh / svn / and capistrano stack something that is always a premium. Compared to php where applications like wordpress are a drop in and off you go deployment rails is tough for the newbie.

2) High quality blog / forum software - one of the reasons php is so popular is that there are some great applications (phpbb & wordpress) that newbies can install and use even though they dont fully understand how it all works. They then learn thru hacking plugins and such and still enjoy a useful application. Sure rails makes it easy as possible to code these from scratch but if you want something v useful it is always a daunting task...
- thewump, on 10/11/2007, -1/+1I agree with you on both counts, and would go further to say that I don't even like SVN as a single coder so it all seems like unnecessary work.
  
  The work around that my host uses ( hostingrails.com ) is to login and create a rails application on the server account then copy all of the app and public stuff etc from your own application but not copy up the environment stuff.. instead modify the generated files for the appropriate setup. Works OK and much easier than trying to start from scratch
  - Jellybob, on 10/11/2007, -0/+0On what basis do you not like SVN - you may be a single coder, but I'd imagine like everyone else you do occasionally make mistakes. If you're using version control then you can just revert back to the last check in, and get on with things. Without it you've just lost n hours of work, and need to write it again.
    
    The same with your deployment - it might "work", but it's error prone. What happens if someone uploads the wrong file, and how do you recover from that? Capistrano automates the process, making sure it happens the same every time, and if something does go horribly wrong you can roll it back again.
- bbqplate, on 10/11/2007, -0/+2launching a rails app is easy without capistrano. what ive been doing is i have a skeleton app with all the necessary files modified(.fcgi, .htaccess, environement.rb). that way, when i start a new web application, all i do is copy paste that folder and all my folders of the plugins i plan on using. when im done coding up the app, upload my local folder to my host, change the accounts in the database.yml, and cut and paste the scema file into a new migration, run rake migrate, and my app is online.
spankr, on 10/11/2007, -2/+1I didn't say "doesn't scale" and I also didn't say that the blog ran on RoR - I just found it rather apropos...
FlaG8r, on 10/11/2007, -0/+3"Getting Started With Rails. Yes, it’s a book. And a cohesive book is worth 100 hobbled-together online tutorials."

'Agile Web Development with Rails' is a very popular choice as well.

Also http://www.noobkit.com/ is a very nice API reference site.
- daftman, on 10/11/2007, -0/+1I've yet to find a book that show the inner working of Rails e.g. the order of loading for all the class, how low level, routing work. A lot of those popular books are terrible for advance rails stuff such as plugins, writting your own db adapter,
- jaydonnell, on 10/11/2007, -0/+1@daftman
  this is true, but I'm not sure a book is the right media for this info. I had the same questions about the inner workings of routes and I found that reading the source was much easier than I expected. I couldn't figure out why one of my routes was/wasn't matching what I expected. I wrote a blog about it here if you're interested. http://www.soulcast.com/post/show/62917/ruby-on-rails-routes
arjung, on 10/11/2007, -0/+1i haven't been able to get in for the past hour or so, and there are no mirrors, but the rss feed acts as a mirror.

http://feeds.feedburner.com/Betterexplained
marsbar, on 10/11/2007, -5/+4Here's a tip: Avoid Ruby on Rails, and while you're at it avoid Ruby as well.

While admittedly it does certain things quickly/easily it is poorly suited for many other tasks. It is far better in the long run for both yourself and your client to use the same tool throughout your application stack. Stick with Java, C, or C# (pick one) for most of your work. Keep scripting languages (perl, javascript, etc) to the absolute minimum.

Ruby is destined for the same pile as ADA, Forth, Smalltalk. Some really good ideas but too specifically focused to be worth wasting your time.

Do everyone a favour and take Ruby out back and put a bullet in her.
robuk24, on 10/11/2007, -1/+2I like Rails but I had more "fun" using Django. Good read though. Dugg.
- Jellybob, on 10/11/2007, -0/+0I'm a big fan of Django as well, having dabbled with both. I havn't really had the chance to do any real applications, but I need to choose a framework to be adopted at work soon, and I'm very tempted to go with Django, since it seems to be a lot more "complete".
  
  The automatic admin is beautiful, and surprisingly full featured, and I like the idea of generic views.
subramanyam86, on 10/11/2007, -3/+0@marsbar
ignorance
If U dont want to use rails,dont.
Dont preach nonsense..
- daftman, on 10/11/2007, -1/+2No actually he has a point. Ruby is a nice language. However, its core maintainers are a small group of esoteric Japanese who only document when they feel like it. Until Ruby can implement proper multi-threading like other language such as perl or python, it's not going to go far in terms of performance.
  In your software development career its best to know at least 2 languages: 1 scripting and 1 enterprise. For the scripting, choose between python, perl, ruby and for enterprise there are java, c/c++ or c#. Personally I would choose python as it is under much more active development and more companies are supporting python. Ruby on the other hand has much more to go.
  For enterprise I would choose Java and touch on c/c++ for real time financial systems.
- jaydonnell, on 10/11/2007, -0/+1@daftman
  Are you sure that python has proper multi-threading support?
  http://docs.python.org/api/threads.html
  
  I also don't buy your assumption that a scripting language can't be an enterprise language. Define those two for me and tell me why they are mutually exclusive.
JMaelstrom, on 10/11/2007, -1/+4Lol - Ruby doesn't support multi-threading...

'nuff said...

Look, if you wanna put up Mom's family tree website, use rails. If you want to put together an online payment system, use one of the grown-ups like Java, C#, or hell, PHP would be a bteer choice than RAILS...

If you dig coding in Ruby and like rails but want the enterprise features, just use groovy and GRAILS...
- Chandon, on 10/11/2007, -0/+1> Ruby doesn't support multi-threading...
  Why would you want multi-threading in a Unix webapp? If you want to get really technical about 3% benchmark differences there's an argument for multi-threading, but Unix webapps have been using fork() instead of threads for years, and it's worked fine. Threads are really essential only on Windows or a JVM where heavyweight processes are handled poorly or don't exist.
invalidsyntax73, on 10/11/2007, -0/+0Very Clever and Helpful humor is good for the programmer
Login or register to add a comment

Create a new account or login to join in the conversation on Digg. You'll also be able to Digg stories to help promote things you like.

Starting Ruby on Rails: What I Wish I Knew

Login or register to add a comment