Rails Development and Deployment
I've been reading up on Rails incrementally, and it looks like FastCGI is the preferred deployment method. I'm not sure how I feel about this. My past experiences with FastCGI is that it's, well, not the most lean bit of code out there. I'm curious if anyone knows this to be different now, particularly on FreeBSD.At the moment, I'm using my own PHP-based framework for web development, so I'm trying to decide if I should look at using Rails, or continue to develop/refine the system I have and eventually release it to the public. I've found PHP itself to be just an unbelievably fast performer, so I still need to see how Ruby can match up in that department.
It also seems that perhaps there's some sort of fundamental issue with Apache and FastCGI that can make it unreliable. Some people seem to suggest using lighttpd. Apache has been so good to me that I'd need a really good reason to use something else.
As for the Ruby syntax itself, it's been a mixed bag. Some bits are quite elegant, others are just far too obfuscated for my taste. I also think the language itself might have too much syntax. My experience with Cocoa has made me a real believer in the value of reducing ambiguity and syntax complexity.
One of the reasons I don't use Perl is that there's just too much special-purpose syntax. I don't object to that because it's hard to learn, but because it's not great when you're looking at someone else's code. I think one of the reasons Objective-C is so effective is that there's very little syntax. If you understand the syntax for one Cocoa app, you understand almost all of them.
I also prefer Cocoa/Objective-C's explicit naming conventions. I've seen a lot of Ruby code like this:
def bfs(e)
q = []
e.mark
yield e
q.push e
while not q.empty?
u = q.shift
u.edge_iterator do |v|
if not v.marked?
v.mark
yield v
q.push v
end
end
end
bfs(e) {|v| puts v}
As well as this:
class Person
def initialize(name, age)
@name, @age = name, age
end
def <=>(person)
@age <=> person.age
end
def to_s
"#{@name} (#{@age})"
end
attr_reader :name, :age
end
group = [ Person.new("John", 20),
Person.new("Markus", 63),
Person.new("Ash", 16)
]
puts group.sort.reverse
(both from Wikipedia's Ruby page)
Most Cocoa programmers I know would probably wince at this. It just feels too terse. Less characters doesn't necessarily mean the code is easier to read. Don't get me wrong, I find Ruby to be a lot of fun, but clarity is absolutely vital.
Back to Rails, I'm still trying to figure out what the "it" factor is. Maybe I'm spoiled by Core Data and WebObjects, and maybe I have a different perspective from writing persistence engines myself, but I haven't yet indentified a "top 5" kind of list for Rails beyond data peristence and integration with the Prototype library.
This is still very much an in-progress evaluation of Ruby and Rails, and there's plenty I don't know. The dependence on FastCGI for deployment is a stumbling block. I was really hoping for mod_ruby to fit the bill. I'm also trying nail down what the deal is as far as templating. I'm really happy with Smarty, but I haven't found its counterpart in the Rails world yet.
Rails Development and Deployment
Posted Jun 29, 2005 — 23 comments below
Posted Jun 29, 2005 — 23 comments below
Daniel Lyons — Jun 30, 05 286
The "big idea" behind Rails is that you're not going to repeat yourself anywhere. I've played around with it and found it to be a really neat, fun development environment. You make the database, and then you just make a class with the name of the table, and it basically figures out the rest by talking to the database. The API is full of this kind of trick.
A couple weeks ago, I set up Typo, the Rails blog software, on one of my servers. I set up four deployments with FastCGi on Apache. Everything seemed to be working just fine, I gave out three of the logins to two other guys, and between the three of us, we managed to get the load average of the server up to 72 with four Rails apps loading up. I find this kind of astonishing.
So I would call it a pretty bulky framework, and I have zero confidence in FastCGI.
Since then I've been messing around with Drupal instead, which is more like a PHP web application framework. I strongly dislike PHP's syntax, but it's damn fast, and Rails (at least on Apache w/ FastCGI) is definitely not ready.
Rob — Jun 30, 05 287
On deployment: I think everyone just gravitates to FastCGI and lighttpd eventually because the combination does work pretty well for the Rails applications that are out there so far. The main sticking point for mod_ruby seems to be that it reuses one Ruby interpreter instance for all hits handled by a particular child process, so running multiple Rails apps on it at once is potentially unsafe. While that limitation makes it unsuitable for shared hosting, it should work just fine on a dedicated server, if that is the environment in which your app is going to end up.
Greg — Jun 30, 05 288
Scott Stevenson — Jun 30, 05 289
I'm a believer in the idea of the database being slave to the model, not the other way around. I think a dedicated model can be more expressive about the design than a SQL database schema.
Rob: Smarty is not your typical templating engine, which is why I was curious if Ruby/Rails had anything similar. It's an exceptionally useful too.
Neil — Jul 01, 05 290
Will Parker — Jul 03, 05 291
"I also think the language itself might have too much syntax."
The same might be said of English, Latin, French and Russian, but those languages seem to have survived the test of time. The question is whether accepting the burden of a complex syntactical structure offers some significant advantage in dealing with certain types of problems.
I'm exploring Ruby now because I got a taste of building an interactive web site with PHP, MySQL and Javascript in the past year. Taken as a bundle, I didn't much care for the taste.
I'm still new enough in Ruby that I don't have a good overall mental model, but Ruby, in combination with Rails and now {url=http://script.aculo.us/]the Scriptaculous Javascript library[/url] is looking more and more like a useful toolbox to me.
Aside from FastCGI, what other tools in the Ruby/Rails toolbox need to be replaced to produce a dependable, scalable Web platform? What is the likely cost of adopting the replacement? Who's working on that part of the solution?
Greg — Jul 03, 05 292
Scott Stevenson — Jul 03, 05 293
From what I've seen, the only two supported deployment options are FastCGI and mod_ruby. The problem with the latter is that all applications share a single interpreter. So when Ruby loads a class, the class initialization affects all active applications.
same might be said of English, Latin, French and Russian, but those languages seem to have survived
It's not like people chose a language to speak when they're born. :) There's built-in inertia. In any case, I think software is much more sensitive to syntactical mistakes.
the question is whether accepting the burden of a complex syntactical structure offers some significant advantage in dealing with certain types of problems
A think you could make the case that just about anything can help you with certain kinds of problems. :)
I'm exploring Ruby now because I got a taste of building an interactive web site with PHP, MySQL and Javascript in the past year.
If you're taking about using PHP's procedural API, and JavaScript written from scratch, I agree. I use PHP as a low-level foundation for my framework because it's very easy to deploy and is ridiculously fast. I also think Smarty adds a lot of value.
the Scriptaculous Javascript library is looking more and more like a useful toolbox to me.
I hadn't heard of this -- thanks for pointing this out. It looks like it's based on Prototype, which is indeed a good library. Neither have to be used with Ruby, of course.
Aside from FastCGI, what other tools in the Ruby/Rails toolbox need to be replaced to produce a dependable, scalable Web platform? What is the likely cost of adopting the replacement? Who's working on that part of the solution?
The two issues I've seen so far are deployment and the (apparent) lack of a Smarty-like templating engine. I'm not sure what you're asking with the other questions.
Phil Ackerton — Jul 04, 05 294
Peter Archer — Jul 04, 05 295
Tim — Jul 04, 05 296
Scott Stevenson — Jul 04, 05 297
Tim — Jul 04, 05 298
Jo — Jul 07, 05 301
Scott Stevenson — Jul 07, 05 302
Nick Fleming — Jul 08, 05 303
Greg — Jul 09, 05 304
Jon Raphaelson — Jul 14, 05 306
And make sure not to get caught up in the confusion many web minded developers seem to get caught in: rails != ruby. This is an extremely important point. Seriously, hanging out in #ruby-lang listening to people whine about ActiveRecord is annoying ;D
Jeff — Jul 26, 05 311
NC — Dec 07, 05 599
SCGI plays nicely with Apache, is far easier to set up, and is still being maintained, unlike FCGI.
See http://www.zedshaw.com/projects/scgi_rails/ for more info.
TheBlatherskite — Nov 20, 06 2459
The state of the application server world has changed greatly for rails since this article was written. If FastCGI is still holding you back, I'd recommend taking another look around. Lighttpd + Mongrel + Pound (on FreeBSD, in my case) in particular has emerged as a favorite among rubists, and there are a number of other viable options as well.
bnxhwka — Jul 23, 07 4540
http://betonsoldierbloodsporttrainer.kura.ewohseka.com/ http://betterbananasorapples.kura.ewohseka.com/ http://bettertogether.kura.ewohseka.com/ http://bettascreensaver.kura.ewohseka.com/ http://betrayalsings.kura.ewohseka.com/ http://betterthansexchocolatecakesundaynewyorktim.kura.ewohseka.com/ http://betterbodzcom.kura.ewohseka.com/ http://bethyacantdoitlikeme.kura.ewohseka.com/ http://betterbureaubusiness.kura.ewohseka.com/ http://betnovatecream.kura.ewohseka.com/ http://bettafishcolorsspotsonfins.kura.ewohseka.com/ http://bethparetta.kura.ewohseka.com/
roger pack — Jan 18, 08 5351