87 Responses to “How Ruby on Rails Could Be Much Better”

1. Brent Says:
   January 7th, 2008 at 7:51 pm

   Well stated. I’m a Ruby on Rails developer myself, and tried deploying on Dreamhost in the early days. It worked, but I can’t say that it was a pleasant experience, and eventually I decided that it’s just not worth it to mess with Rails unless you have root. VPS services are gaining ground here.

   Rails deployment has been a sore spot for a long time, so maybe after all the ruckus that Zed Shaw has stirred up, someone will seize the opportunity to replace his fame and ask, “Why do we need to proxy to this Mongrel thing again?” and either a) improve fcgi support in Rails, or b) made mod_ruby into something formidable for Pete’s sake.

2. Thomas Aylott Says:
   January 7th, 2008 at 8:27 pm

   How true it is. We recently moved a project from rails to .net mostly for deployment issues and the lead developer happens to be a better .net coder. And the next version of a certain high profile extremely high performance rails app has been written with almost all custom c code and php.

3. Terri@DreamHost Says:
   January 7th, 2008 at 10:15 pm

   As the one who maintains the Rails packages here, I have to agree with Dallas. It’s a PITA. Adjusting the Rails gems to Debian packaging often feelings like pounding square pegs through round holes.

   Plus there is the recent frustration with the framework files that had to be altered just so people could freeze their rails. If we had just one server to maintain it wouldn’t be that big of a deal, but on a larger scale it’s a pain. It also seemed like a very dumb bug introduced into something that should just work.

4. Mikael Jansson Says:
   January 7th, 2008 at 10:36 pm

   PHP and the likes are CGI-style application “frameworks”, and as such they of course do not require much resources.

   However, on the other side of the fence, with actual *application servers* (such as RoR, TurboGears (which I use), TomCat, …), by definition you cannot be lightweight — there has to be an application server running in the background.

   The best way is to use a proxy setup, which you now have, *except* for the fact that you cannot proxy it at the root of your domain…

   +- 0 to DreamHost. :/

5. Albright Says:
   January 8th, 2008 at 7:08 am

   But most of the time, I don’t want to run an “application server” or framework or anything like that. I want to type some code into a file and run it. I sometimes get frustrated with PHP and start investigating alternatives, but when I see all the nonsense I have to go through to get a Django or Rails app running, I give up.

   I personally hope ECMAScript 4 catches on on the server side… I love its syntax. However, whatever language that wants to make it big is going to need PHP’s stability and it-just-works-ness if it’s going to catch on at anywhere near the same level.

6. Alex Says:
   January 8th, 2008 at 9:13 am

   Too true, Dallas. I’m glad to hear that Dreamhost is aware, and grateful to hear that communicated.

   I have two Rails sites running on Dreamhost and each has been an incredible pain to deploy. All supposed time-saving that comes with using a framework like Rails was very quickly nullified when deployment and maintenance was factored in.

7. Robin Hoode Says:
   January 8th, 2008 at 11:26 am

   My $0.02 on this issue:

   1) I used to be pretty animate about my Dreamhost citizenship. But now I’m mostly done with Dreamhost exactly because of the Rails deployment issues I ran into. While Dreamhost is great for hobbyists, career programmers should probably subscribe to a VPS.

   2) That said, let’s not expect Rails to fill the same role that PHP does. Rails is providing a place in the marketplace for alpha-geeks who are constantly pursuing the bleeding edge. This is why API constantly breaks backwards incompatibility. Compare that to PHP 4 still running on the majority of the web servers these days, despite the maintainers warning of deprecation for some time.

8. Christoph Says:
   January 8th, 2008 at 12:25 pm

   I would like to mention that there’s a clear difference between a programming language (which PHP is) and a framework (which is Rails). Of course you can do all type of web applications just with Ruby, without a framework, and it’s gonna be fast (well, sort of). But your development process will be slower because you don’t have ActiveRecord and all the other cool things Rails offers.

   I’m happy that Dreamhost supports Rails but I have to second Robin’s statement, if your really wanna run a Rails application in production, use a VPS.

9. Albright Says:
   January 8th, 2008 at 2:52 pm

   Christoph, let’s be real here; how many people out there are really building Ruby web apps without Rails? (Or Ruby apps at all, for that matter?) Is such a thing even possible on DreamHost? And I’m not saying that as a Ruby hater; I actually think it’s quite a pleasant, if occasionally overly-cute (”string” * 3 = “stringstringstring”), scripting language. I’m just tired of the glassy-eyed Rails fanboys trying to complicate my life with “The Rails Way” — these people make even the most religious of us Mac freaks look normal in comparison.

   Yes, I’m well aware of PHP’s weaknesses, but until something else comes along that has the same level of it-just-works-ability, I’ll stick with it, both for work and pleasure.

10. Nathan Says:
    January 8th, 2008 at 3:00 pm

    I think that most people do not care about the difference between application servers and cgi style frameworks, but it is a very important difference that they have to deal with anyway. I mean how many people request tomcat or custom java servers from dreamhost shared hosting?

    I also think many people are forgetting eruby, which is exactly what most people probably want. It lets you use ruby code just like php code. The only problem is that everything is instantiated every request, so just like with php, you gotta lazy load everything (which is very possible).

    I don’t think rails needs to change it’s deployment model too much (it is meant for vps’s with monit running and stuff like that and I love it), but other frameworks in different styles will fill those other gaps.

    I would love a eruby framework that lazy loads database stuff and lets me use haml. I suppose I should get started on coding that up.

11. Christoph Says:
    January 8th, 2008 at 3:10 pm

    Albrigt, how many people are building apps with PHP without any framework? I did it and I don’t use a full fledged framework for simple websites (eRuby does a pretty good job here). I’m aware that Rails is complicated to deploy (at least for the first time) and it’s slower than other solutions.

12. Jimminy Cricket Esq. Says:
    January 8th, 2008 at 4:28 pm

    I like PHP it makes me smile and feel like oooo free as a birdddddddddddddddd.

13. Albright Says:
    January 8th, 2008 at 5:35 pm

    Christoph, I’m not sure if your question is rhetorical, but if so, then people are building sites without a framework all the time — or, at least, nothing as rigid or feature-packed as Rails. I recently started doing a lot of coding in Drupal, but even that isn’t something I’d call a framework — it doesn’t have database structures. Rails-like frameworks exist in PHP, but few people use them.

    I’d never heard of this “eRuby” before. I’ll look into it.

14. Samo Says:
    January 8th, 2008 at 11:17 pm

    Meh, I’d be happy with mongrel at DreamHost. I really like the service and all, but I need to do more and more rails work and I’m afraid I’ll have to switch away to another hosting solution because of that. :o(

15. Bob Sherron Says:
    January 9th, 2008 at 12:16 am

    This blog post just goes to confirm my worst fears. Anyone who works with Rails knows it can be hard to get it running and keep it running. With that in mind, I’d expect a host with the size and resources of a DreamHost to be actively trying to solve the problem though instead of crying about it on their blog. There are plenty of people who are working their asses off to make Rails work better and faster (cough http://rubini.us/ cough), and some other high profile hosts like Engine Yard (disclaimer: I’m also an EY customer) are backing these initiatives.

    Now, I don’t expect DreamHost to have an EngineYard-like level of support, especially when you consider the cost differential and the scope differential of the two companies. What I do expect is for DreamHost to pick a horse already. Either support Rails properly in your basic plans, or jump ship and make it pay to play. If it’s going to be on the “invite only” PS plans, then so be it. At least we’ll know rather than sitting around refreshing my RSS reader to see if DH is supporting Mongrel yet.

16. Frank B. Says:
    January 9th, 2008 at 7:43 am

    >> “we are working on additional support for it to be tied in with our DreamHost PS plans”

    I would absolutely love the idea of offering additionally selected software support for Dreamhost PS.

    Such as: NGINX web server, memcache RAM caching, and PHP APC for PHP bytecode acceleration.

17. Shanti Braford Says:
    January 9th, 2008 at 12:08 pm

    It might come across as elitist, but just about anyone who contributes to rails or releases open source ruby projects, will at least have a VPS in their pocket if not many dedicated servers.

    Getting Rails to work in shared environments like DreamHost is waaaay low on the totempole for the ruby/rails contributors.

    I think it’s up to you guys to fight the good fight on this one.

    IMHO, rails is such a customized beast that it would not work will intermixing with other DreamHost apps (PHP, etc).

    It almost needs its own custom control panel:
    * subversion URL to checkout from
    * # of mongrels to use
    * ngix tweaking
    * etc
    .. with the ability to SSH in and tweak additionally.

18. Peter Says:
    January 9th, 2008 at 3:57 pm

    I was a longtime Dreamhost customer as well, but it was this problem with Rails that finally got me to move on to something else.

    I ended up putting a Mac mini in a data center and it has been great. All the benefits of a dedicated server, but a much lower price. (I ended up going with Macminicolo.net…$35/mo)

    Perhaps someday I’ll look at Dreamhost again.

19. Adrian Madrid Says:
    January 9th, 2008 at 3:58 pm

    Too many things come to mind about this post. For one thing, why? Why does Rails needs to be like PHP? Besides that you are comparing a language with a framework I personally just don’t see a good reason why RoR should be like PHP. At all. I can see how it would make your life easier but I’m not sure what it will really gain for everybody.

    Second, you might want to check your facts. In Zed’s rant he states that DHH’s app _had_ a large problem with restarts. again, had. Your statements say that it _has_.

    “Zed Shaw mentions in his rant that even the Ruby on Rails application run by DHH (the guy who wrote Rails!) _has_ regular issues and needs restarts several times a day.” (emphasis added)

    Third, have you even tried running Litespeed? Even the free version has great, out-of-the-box support for running Rails apps. And if you are willing to pay for the Enterprise version it even has support for hosting companies like yours. Are you willing to spend the money/time and try it?

    I’m sorry but this whole article, although it points sove valid arguments, leaves me with a lemony, whiny taste in my mouth.

20. Watts Says:
    January 9th, 2008 at 4:03 pm

    I think the main sticking point has been touched on by a few commenters but not made explicit. We all hear the “Rails is a framework, PHP is a language” chorus, but the real point is that PHP is a language the way ColdFusion is a language, i.e., very explicitly targeted to web applications. Ruby, Python, Perl, et. al. are not. Sure, you can do shell scripting and console apps in PHP if you’re sufficient masochistic, but the damn thing’s been designed from the start to run in the context of a web server.

    The problem in practice is that the things that would make Rails less of a PITA to deploy for a shared hosting provider aren’t really things about Rails. They’re things about running web applications written in Ruby. Rails doesn’t play nicely with Apache because Rails doesn’t play nicely with mod_ruby because mod_ruby has lousy threading support (or something like that). The logical answer here for a shared hosting provider is “fix mod_ruby so it becomes a viable way for one Apache server to run multiple Rails applications,” but that’s not something that’s actually up to the Rails core team. They don’t have anything to do with mod_ruby (or for that matter, Apache).

    Having said all this, I really haven’t looked into whether this is even feasible, but I think expecting shared host providers to radically change their environment to work with Rails isn’t too rational. (The only Rails app I’m running now is Instiki, which is just stunningly execrable in terms of resource use). I know folks in the Python world have been actively trying to make deployment of systems like Django easier, particularly with mod_wsgi, which IIRC is explicitly designed to be shared-host friendly.

21. Joseph Says:
    January 9th, 2008 at 4:10 pm

    Hey Dallas, here’s an idea: Why don’t YOU guys make it happen? I know that sounds backward, but stick with me here..

    If you invested the engineering time to figure out why exactly Rails is difficult to deploy on your environment, and you can create patches and get them accepted, how much do you stand to gain? There are TONS of people who’d be using Rails if they could affordably deploy to a host like DreamHost, and you could capitalize on it.

    That, or just let us set up a damn proxy to the root of our domains (for private servers). How hard is that?

22. kenrick Says:
    January 9th, 2008 at 4:18 pm

    I guess the question really to ask is, what do you get from rails that is so awesome that you really need to use it? The interesting ideas that it has posed have already been copied successfully in other platforms. ActiveRecord? Really? Hmm I like to write my own SQL, its really not that hard. It seems like all these people making RoR sites all all trying to just make the same kind of site anyways, seems like if RoR was so hot there would be one defacto package everyone uses. But since Rails has performance anxiety (like when I got married, thank goodness for beers) no one can actually create a killer app for it yet.

    There are so many more interesting problems on the web to solve then creating more frameworks.

23. Andrew Dupont Says:
    January 9th, 2008 at 4:29 pm

    One reason why PHP so easily runs on shared hosting is the company behind it: Zend’s business model is directly tied to the popularity and broad install base of PHP.

    37signals, on the other hand, has its own business model that doesn’t depend on the promotion of Rails as a platform. Instead they make apps that use Rails. RoR is free and open-source not so that it will be widely-adopted and make them rich, but so that the framework itself can get better, which in turn contributes to the quality of 37signals’s own apps.

    (Don’t misunderstand: I’m not trying to argue that one approach is better than the other.)

    For this reason, 37signals has little incentive to make their framework more portable. I’m sure they will accept any “drop-in” optimizations submitted as patches, but only someone with an incentive to get Rails working in a shared hosting environment would try to write those patches in the first place. And anyone who’s already sold on Rails is likely working on a VPS, or a dedicated server, or is just messing around on their local machine.

    Plus, as you’ve mentioned, a lot of that work needs to be done on a lower level than Rails itself. Ruby is goddamned slow. (Luckily, smart people are working on this. YARV, Rubinius, JRuby, et cetera.)

    I agree that the answer from you got from the community (”just use lighty + SCGI”) was quite stupid. The “smart” answer, on the other hand, would’ve acknowledged that what you were trying to do was Really Hard, and might’ve even suggested that the effort would not have been worth it.

24. Clay Preheim Says:
    January 9th, 2008 at 4:57 pm

    Ruby/Rails definitely seems to be trickier to implement, but the guys at hostingrails.com seem to have Rails apps in a shared environment pretty nailed down… Performance has been great.

25. Greg Says:
    January 9th, 2008 at 5:10 pm

    That all seems like a bunch of whining to me…”If only someone with a lot of resources and a financial stake in shared hosting would do some work in making this free open source software work better on shared hosting!” (followed by a large stream of Dreamhost customers talking about leaving Dreamhost because of it’s inability to successfully run Rails under its shared hosting plans).

    The whole deal with open source software is that if you need it to do something it doesn’t already do, you put in the work to make it happen. I’d wager that nearly everyone who’s ever contributed to Rails deploys on their own servers / hosted virtual machines. If Dreamhost has a lot to gain from Rails working well under shared hosting, and they know a lot about the real world requirements of their shared hosting customers, they should do the work to make it so, not wait for people with no financial interest and no hands-on knowledge to do the work for them for free.

    And they certainly shouldn’t be spreading FUD about Rails (by taking advantage of the fragile emotional state of one of its most productive contributors) to cover up their own lack of effort.

26. Bryce Says:
    January 9th, 2008 at 5:37 pm

    Well said. I’d love to be able to write a Rails app, but I can’t run it on my shared host. Unlike PHP where I can just upload a few files and go.

27. Jens Alfke Says:
    January 9th, 2008 at 5:45 pm

    As already pointed out in comments, this issue is not specific to Rails, or to Ruby. The same problems apply to any complex web-app (like Django or TurboGears, and probably some of the larger PHP-based frameworks too) that has a large amount of set-up overhead. By running a separate app process you amortize the setup costs across large numbers of requests.

    This is a more complex model than a simple CGI or mod_whatever, but it’s a straighforward engineering problem and there’s no reason it shouldn’t be workable. (I’ve dealt with exactly these sorts of IPC issues in native OS X apps.) Not to impugn anyone, but a lot of web development is done with duct tape extension cords and not engineered very well — to the point where a fairly simple but efficient web server like Mongrel gets idolized a some kind of mysterious alien technology.

    FastCGI is a terrible protocol; it’s far too complicated for what it does. SCGI (developed by some smart people in the Python community) does the same task in a much simpler way, so I’m sure it’s more reliable. Has Dreamhost tried using mod_scgi to bridge Apache to Rails?

    I would also look at whatever daemon Dreamhost is using that kills off processes that run for more than a few seconds. I can’t even run “gem install” anymore without the command getting the axe before it can download anything. This is definitely going to screw up FastCGI processes, which by their very design need to stay running long enough to handle many requests.

    It sounds like both sides here (DH and the Rails devs) are to blame. I’m pissed off at this, as I’ve done my time with PHP, a nasty little pidgin C that lends itself to unmaintainable spaghetti code, and I’d really like to use a real framework like Rails or TurboGears, but I can’t because none of these work on DH. Please just make it work, guys. This is not rocket science.

28. Albright Says:
    January 9th, 2008 at 6:35 pm

    Adrian:
    I’m pretty sure anyone who knows enough to understand the original blog post is well aware of the differences between a language and a framework. The reason why Rails should be more like PHP is because PHP is both easy to implement on web servers and easy to start hacking away in. Rails is neither. That eRuby thing looked promising, but it sort of missed the point of the “Be more like PHP!” cry — the ability to mix code and HTML is *not* why PHP is popular, and it’s actaully quite dumb in my opinion. (I generally try to avoid it when I can, using Smarty.)

    Watts:
    What makes you think writing CLI apps in PHP is painful? Toss in your shebang line, get your arguments out of $argv and go to town — I can’t imagine how it could be easier.

    kenrick:
    What I want from a language like Ruby (not necessarily a framework of any sort like Rails) is to get away from PHP’s inconsistant and sometimes painful syntax. I’m also a fan of the “everything is an object” paradigm. PHP is a lawn mower — incredibly functional and useful but not very pretty and capable of making quite a mess.

29. Hostile Monkey Says:
    January 9th, 2008 at 6:45 pm

    The real issue is that hobbyist developers want to use Rails because “its the cool new thing”, and then want to deploy their website built in Rails on their shared hosting package because it’s just a hobbyist site, and they can’t afford the (now tiny!) cost of dropping it onto a VPS.

    That’s not to dismiss the hobbyist developers! I’m a hobbyist developer when I’m not a professional one, and I know that if what I want can be achieved by “chucking a few PHP files on my host and BOOM”, then that’s what I’ll do. I’m not insane enough to fire up a full application stack just to enable some forms or have some funky AJAX requests.

    Rails (and Symfony, and Django) are APPLICATION FRAMEWORKS. They are the complete opposite of PHP and its ilk, though both can be used to achieve the others target.

    PHP is designed to allow you to take a flat website and add processing power to it. It starts with a site, and then adds fun.

    Rails etc are designed to allow you to build a full-featured application, and deploy it on the web. BaseCamp isn’t a website, it’s an application. Building BaseCamp in PHP is possible, just as creating a website in Rails is possible, but you’re using the wrong tools if you do it that way.

    Should DH support Rails in a shared environment? I can think of no good reason why, and frankly this is all a lot of hot air about nothing. If your customers are clamouring for something, that doesn’t mean they understand what they’re clamouring for.

30. Hostile Monkey Says:
    January 9th, 2008 at 6:50 pm

    Oh, and one final thought – Rails is not “a better PHP”, and neither does it want to be.

    PHP5 is a step towards “a better PHP”, and I hope PHP6 finally brings a mature language. Rails and PHP can happily co-exist in your toolbox, neither one being “better” than the other. A screwdriver and a power-drill kinda look the same, and kinda work the same, but you can’t replace one with the other, and the do different jobs.

    Let’s just move along, learn both, and be happy, eh?

31. Jon Hoyt Says:
    January 9th, 2008 at 7:34 pm

    Surprised no one has mentioned Merb… I really don’t see any reason to use rails any longer, it is bloated and slow… Merb, using datamapper, on the other hand is quite fast and powering all my latest apps…

32. Adrian Madrid Says:
    January 9th, 2008 at 7:38 pm

    Albright:

    You want people to change Rails into something more like PHP: easier to work with more servers and easier to start hacking. But you want other people to do the work for you. Why? What is the benefit for DHH and the core group of developers behind Rails? In every open source project there is an itch to scratch that starts it all. In RoR it was an actual application that started it. Now there are people that don’t quite like how RoR is implemented and have started plenty of Ruby servers (Thin, EVMA, ServerSide) and web frameworks (Merb, Sinatra, Halcyon, etc.) each with it’s own take on how to develop web applications. So if you need an easier way to deploy in multiple web servers go ahead and build it. Fork it if you can’t get it into trunk. Who’s stopping you? I am personally tired of people wanting other people to do their work for them for free. Specially when people only tell you what they want and not even a hint of how or offering time/money.

33. Michael Says:
    January 9th, 2008 at 9:04 pm

    Rails is all marketing. It’s a joke. It doesn’t perform, and the world surrounding it (As Zed’s awesome article pointed out) is totally a crock of immature and inexperienced pretentious developers who think they rule the world.

    Rails = Marketing. Now that it’s so big it can’t keep up with itself.

34. Geoffrey Grosenbach Says:
    January 9th, 2008 at 9:37 pm

    It may interest you to learn that the Ruby on Rails Podcast site is actually run off shared hosting…Dreamhost to be specific.

    Every public-facing page is page cached (written to disk as static HTML pages) and I’ve had very few problems.

    All my mission-critical sites, are hosted on a VPS at RailsMachine, but Dreamhost works fine for simple sites that can be fully page cached.

35. Aaron Says:
    January 9th, 2008 at 10:18 pm

    @Albright: EcmaScript IS catching on on the server! See appjet.com and helma.org, both excellent uses of server-side EcmaScript.

36. she Says:
    January 9th, 2008 at 11:00 pm

    The only proper solution would be to have ruby itself do what RoR is supposed to do – build web apps.

37. Steven Says:
    January 9th, 2008 at 11:28 pm

    Stop using FastCGI. Switch to mongrel and all the stability problems go away like magic. Wooo.

    Can’t believe you guys still haven’t got this right.

38. res Says:
    January 9th, 2008 at 11:46 pm

    i really don’t understan what the problem with rails and shared hosting is all about, i never ever had a problem with it

    i am using a simple and cheap vps-setup (http://www.hosteurope.de/produkte/VPS-Linux) and it took me less time than reading this post here to figure out how to set up some mongrels behind a apache

    i am wondering what could be easier than mongrel… wouldn’t it be easier for you to write own some paragraphs for your users how to setup up and monitor mongrels than writing lengthy rants

39. Pratik Says:
    January 10th, 2008 at 12:37 am

    Rails seems easy at first sight, but trust me, it’s not a framework for idiots. It has a very steep learning curve. And it’s a very new technology ! So for fuck’s sake, stop comparing it with PHP ! Don’t expect your same kind of setups to support Rails properly and make extra monkey. I suggest you better keep your focus on PHP n00b, else you might end up losing many customers.

40. Adam Bair Says:
    January 10th, 2008 at 12:53 am

    I can’t imagine this sort of rant would be useful in gaining new users, helping existing ones, or finding people to solve your issues.

    Wouldn’t time be better spend working on solutions to your problems instead of demanding them from the community?

41. Pratik Says:
    January 10th, 2008 at 1:02 am

    And btw, if you knew a tad about rails, you would understand why everyone should FREEZE the rails version their app is using. And you wouldn’t have ranted about backward compatibility. That point was really stupid :)

42. Dee Zsombor Says:
    January 10th, 2008 at 1:42 am

    Often surprised by the amount of horror stories you hear about rails deployment. In fact is quite simple, safe from the fact that most shared hosting environments have innate limitations making you to go trough a set of non-standard web forms instead of having the full power of shell (root). This is the main problem.

    There are two main ways of deploying: Mongrel & FCGI. The *sole* advantage of Mongrel is that it can be paired with Apache’s proxy module and the former is a stable implementation. While in case of FCGI the Apache pair is weak and buggy (note that not rails rather the Apache module). There is no major speed difference between Mongrel and FCGI, infact if there is a difference at all then it is FCGI being faster due to a more compressed protocol by a slight ignorable edge.

    Most of my setups use FCGI & Lighttpd, a rock solid combination. I can assure you that restarts are not that common as Zed’s misinterpreted and *out of context* DHH quote would lead you to believe.

    If you are in shared host then you can even have FCGI & Lighttpd bellow an Apache proxy. Or just use Mongrel if Apache is a must. The steps to create a working setup are predictable, reproducible => programmable. What is the big deal? There is no reason why the Dreamhost would not have a simple form where you specify:

    * domain to where the rails app should listen
    * upload a DB dump you would want the app to be initialized

    Automated gerbils would do the setup, and deploy a blank “Hello Rails” application. Then you would receive a mail telling you that it is all set up, with an attachment containing the Capistrano deploy.rb file specially crafted for this project.

    Perhaps even better you could have just a dreamhost_deploy gem that you’ll install for yourself then run in your project’s top directory and does this entirely for you. The first shared host that does this will get lot of business. Should not be too difficult to program.

43. mtkd Says:
    January 10th, 2008 at 2:27 am

    The ‘backwards compatibility’ comment is very valid.

    Anyone picking up a book on Rails won’t be able to work through most of the first examples listed if they’ve installed 2.0.2

    These kind of issues raise the cost of entry and put people off.

44. AkitaOnRails Says:
    January 10th, 2008 at 2:39 am

    DHH himself replied to this (http://www.loudthinking.com/posts/21-the-deal-with-shared-hosts)

    He is spot on. He and most of the Rails contributors DON’T need shared hosting. So it means that they need people who need to tackle the problem. It is an OPEN SOURCE project remember? Contributions anyone? It is always easier to rant and rant and do absolutely nothing and feel good about yourself, right?

    Dreamhost, on the other hand, MAKES MONEY out of Rails. So good luck to them if they think this kind of rant will motivate any NON-PROFIT contributor to help them.

    That said, I use Railsplayground WITH FastCGI. It is not perfect, but they are WAY more supportive.

    Neither Ruby nor Rails is a commercial product. If people are using them, that’s because they feel it helps them. So help back now. Or, go for a VPS solutions and DIY. Slicehost might be good.

45. MItchell Gross Says:
    January 10th, 2008 at 2:51 am

    I never tried dreamhost, but I tried running my business on rails, and hoo boy! I spent most of my time wrestling with deployment issues.

    And in those days (don’t go there much anymore) most people just overlooked it. If DHH doesn’t talk about it, then it’s not an issue, regardless of how much it is needed in the real world.

    When DHH says FUCK YOU! he really means it, and so does the rest of the sychophants on the core team. That is not just a joke line.

    Sorry to say. I have moved my business back to PHP, because you know what I realized, when the ruby on rails people wanted their mundane stuff to be served without problems, they used PHP forums or blog software or whatever. Last I checked the main ruby on rails site was running on PHP!

46. rick Says:
    January 10th, 2008 at 3:04 am

    Does this mean Dreamhost has upgrade to Rails 2?

47. T M Says:
    January 10th, 2008 at 3:47 am

    There are many people (and DHH himself) here who say that there is no motivation for the core rails team to get Rails work better on shared hosts. As someone who loved rails until he tried to deploy his first production app I can say this is a very short-sighted view.

    Lets look at some usage scenarios: Rails is intended to take the pain out of building simple data driven sites, the majority of sites built on the internet are low traffic. Most of these sites cannot afford or justify a dedicated server per site – its a ludicrous proposition.

    If DHH truly wishes Rails to be the simple and easy to use language that it proclaims to be and wants it to spread further (it _is_ still small after all) then he needs to spend more time on this matter. Its true that this shouldn’t be all on his head, Shared hosts need to get involved too but posts like this are necessary to raise the profile of this issue to where it should be: The Top of the pile.

48. Rubén Says:
    January 10th, 2008 at 4:57 am

    There is a Ruby on Rails clone in PHP named Akelos (http://akelos.org) for those of you who want to have the best of both worlds right now. Rails functionality with the ease of PHP deployment and scaling.

    It even supports ruby-like syntax on views!.

    The sad thing is that the amount of other Rails-wannabe PHP frameworks is making the a lot of noise that makes Akelos to remain little known.

    Here you have a side to side comparison (http://www-users.mat.uni.torun.pl/~tomahawk/summary.php) where PHP frameworks are compared to Rails.

    Keep it simple for your small projects you host on Dreamhost and avoid Rails when possible on shared environments where PHP excels.

49. Mark Says:
    January 10th, 2008 at 5:51 am

    How does your experience with other major web programming frameworks such as Django or Turbogears compare to that with Rails?

50. Michael Brutsch Says:
    January 10th, 2008 at 7:01 am

    My God, DHH sounds just as arrogant as a KDE developer. DreamHost doesn’t make money from Rails, they make money from hosting. No one cares what the f’in developers use; it’s the average Joe user, trying to implement Rails, who suffers because DHH can’t be bothered to make Rails work on commodity platforms. Thus, widespread acceptance goes in the toilet. I’m beginning to think Zed was right about Rails, despite his lack of tact.

    At least Open Source is always entertaining.

51. Tom Says:
    January 10th, 2008 at 7:04 am

    I’m surprised nobody has mentioned the ASP.NET option. It is super easy to program against (the free version of Visual Studio is amazing), all sorts of inexpensive shared hosting options are available, and deployment is straightforward and just flat out works. Oh, and performance is blazing…

52. Stephane Grenier Says:
    January 10th, 2008 at 8:20 am

    I think you hit the nail on the head. Even if not everyone agrees, the reality is that many web shops don’t want to setup and configure their own servers (shared, VPS, or dedicated), this why there are managed solutions.

    Even for dedicated boxes, for my own company LandlordMax, we don’t want to spend much time configuring the box. It’s not our core competency. It’s not our core business. It’s as simple as that!

53. Eric Says:
    January 10th, 2008 at 8:26 am

    The post purports to address the difficulties of deploying Rails on shared hosting in general, yet it seems that the only source of information is Dreamhost. I use Joyent shared hosting and deploying my rails apps is dead simple, follow-the-steps easy, and I’ve never had a single problem with reliability. As far as performance, who has an app so big it bogs down a cpu with rails, and yet doesn’t have the budget for a dedicated virtual machine?

54. Brian Hogan Says:
    January 10th, 2008 at 8:29 am

    I deploy Rails apps on Dreamhost. The pain comes from the way Dreamhost runs FastCGI, and their aggressive process killer. Rails apps die constantly unless you patch them. DH sends a TERM signal to the fascgi processes.

    A simple patch to the Rails dispatch.fcgi script to ignore the TERM signal and issue a restart has kept my rails applications running for nearly one year without incident.

    The other problem is that sometimes setting up your domain to use fastcgi just doesn’t work. Don’t know why. Support tells me to just delete the domain and add it again.

    Finally, in order to host Rails apps you need to understand the way a Rails app works. A Rails app is memory intensive. You have to have 25 to 100 mb for EACH fastcgi dispatcher that runs. That part of the app needs to stay in memory, which is why FastCGI is a good fit, but other methods (like an app server) are better. Dreamhost doesn’t have those resources available for all of its users, hence the aggressive process killing. You can think of Rails like a Java app. You can’t just drop a java app with servlets into your public_html folder and expect it to work.

    This sounds like a Dreamhost problem. Check the forums and you’ll find lots of posts about this which have gone largely ignored by DH support. The wiki even offers up all sorts of hacks to make it work.

    As for DHH’s rebuttal, I agree with him on this. Rails doesn’t support deployment on the Windows platform via IIS either. It appears that Microsoft is working on that though. Apparently, someone from there even submitted a patch to Rails to help it out. Very few people get paid to work on Rails… it’s voluntary. The things that get fixed are the things that the contributers struggle with. If you feel strongly about making Rails work on Dreamhost, get involved. Post to the Rails list about this. If Dreamhost was really serious about this, I know they’d get people from the Rails community to help. I know I would.

    If you want to know more about deploying Rails apps, see http://www.pragprog.com/titles/fr_deploy.

55. Davey Shafik Says:
    January 10th, 2008 at 8:29 am

    Too funny, I tried to post the url to this article on Twitter, one of the Rails poster-children… and got a temporarily overloaded error. GJ Rails!

    Anyhow, I’m not sure I entirely agree with BC issues in PHP, they have been few and far between, and for the most part, the new solution is worthy of the issues it causes.

    - Davey

56. justin Says:
    January 10th, 2008 at 8:31 am

    I’ve been running several Rails sites in Dreamhost shared environments for several years now, and although it has been stressful at times to deploy, I think I have all the bugs worked out.

    Before I took one of my Rails applications offline a few weeks ago, I was maintaining (either in my account or accounts I setup for other people) 5 different Rails applications in a shared Dreamhost environement, all running fine with a frozen Rails gem, and all reliable.

    ^ To the guy talking about ASP.NET, this is about Rails. Also, deploying a .NET application to a production environment is a royal pain. I lost a lot of hairs in my earlier years with that framework.

57. ed Says:
    January 10th, 2008 at 8:52 am

    Quote:
    ^ To the guy talking about ASP.NET, this is about Rails. Also, deploying a .NET application to a production environment is a royal pain. I lost a lot of hairs in my earlier years with that framework.
    ——–

    No, it isn’t.

    Step One: Upload files via FTP
    Step Two: Done.

58. Scott Says:
    January 10th, 2008 at 8:53 am

    I’ve deploy, develop, and support ASP.net, PHP, and Ruby on Rails applications.

    Rails is by the far the most difficult to deploy, but it is the most fun to code due to ruby’s meta language and Rails focus on convention over configuration.

    I say Why can’t Ruby on Rails be a premium framework? I’ve read most of the comments, and most of you all say, it should work on shared hosting, because PHP does. I ask why? Why should it because PHP does it? Rails works great within a VPS with root access. Yes, it’s still a pain to deploy, but it’s acceptable with the multiple capistrano recipes out there.

    I think some of you don’t really understand the Rails Way, and 37signals.com getting real meme. Basically, Rails is not meant to be all things to all people. From what I have done, Rails does what it does and does it well. It makes writing web applications fun and allows you to focus on the business problem rather than framework.

    Now, does that mean the Rails core team is not arrogant? I don’t know. Does that mean future Rails functionality can not be created to allow simple easy deployment on shared hosting? I don’t know, but I think it’s feasible. It’s just waiting for the right apache developer to build mod_rails or enhance mod_ruby or some other solution.
    Now, I also agree with some Zed’s statements.

    Why Not ASP.net? Well, because the MVC architecture is only becoming available. Although, I’ve always liked ASP.net, and I have yo look more closely.

    PHP is great for what it does. It’s a great language for just throwing down some code and just letting it run.

59. Niko Says:
    January 10th, 2008 at 9:01 am

    I’m running a rails test-site on Dreamhost as well and for testing purpose it work well enough for me.

    For any thing serious get a vps!

    Rails just isn’t made for shared hosting and it never will be. One Rails process uses 30MB RAM and more and the whole framework takes several seconds to boot. That means, you can’t boot it on demand, but have to keep it (and it’s 30MB) around all the time. No shared hoster can dedicate 30MB permanently to each single site of each single user. Last time I looked on ‘my’ Dreamhost machine where about 1000 users. If these 1000 users would run 100 Rails sites that alone would take Dreamhost 3G of RAM just for Rails.

60. Dallas Says:
    January 10th, 2008 at 9:07 am

    Thanks to everyone for their comments!

    The commenter that compared the business models of Zend to 37 Signals makes a very good point. 37 Signals should proceed ahead with their own agenda because they are the most important user of their software.

    The suggestions that DreamHost put in the effort to make this happen are entirely in line with one of the main points of my rant. In all honesty, we do NOT stand to make a significant amount of money from doing this work ourselves. Rails does not have the user base or the critical mass to make it enough of a mainstream platform for that to worth it for us.

    This rant is primarily an attempt to reach out to the Rails COMMUNITY (not Rails core) to improve Ruby on Rails in a way that I strongly believe would be ultimately beneficial for Rails as a platform. In fact, I believe the benefit to Rails itself would be far more significant than any benefit DreamHost would see directly.

61. justin Says:
    January 10th, 2008 at 9:30 am

    re: ed

    Step One: Upload files via FTP
    Step Two: Done.

    That’s the exact same deployment recipe I use for all my rails sites running in a shared environment on Dreamhost!

62. Carlos Júnior Says:
    January 10th, 2008 at 10:26 am

    What I think is (not that it matter): Rails is a Free and Open Source Software, you win much much money with rails, so why don’t stop complain and work on it? Why don’t spend a bit of money hiring a Ruby developer to help on Rails development?

    My 2 cents.

63. Name Withheld Says:
    January 10th, 2008 at 10:38 am

    There are low cost shared hosts that support rails. Dreamhost is not that painful to get a rails app running, if you are cool with fcgi, it’s actually pretty simple.
    If someone wants mongrel, there is hostingrails.com and railsplayground.com, price comparable, but not as much space/bandwidth.

64. Tim Says:
    January 10th, 2008 at 10:42 am

    Some link love from DHH to Dreamhost

    http://www.loudthinking.com/posts/21-the-deal-with-shared-hosts

65. James Urquhart Says:
    January 10th, 2008 at 11:12 am

    Coming from the PHP world, i found the development of rails apps to be quite strange.

    With PHP, one just plonks the files in a directory, perhaps edits a single file, runs the installer, and then they are up and running.

    With Rails, it’s a whole other story. I almost screamed when i read up on mod_proxy, mongrel, fastcgi, and capistrano, and memory usage.

    (Granted it can just be a simple matter of copying files via FTP, but i rarely find it is anything but)

    I guess its just another one of those double-edged swords.

66. James Urquhart Says:
    January 10th, 2008 at 11:12 am

    Coming from the PHP world, i found the development of rails apps to be quite strange.

    With PHP, one just plonks the files in a directory, perhaps edits a single file, runs the installer, and then they are up and running.

    With Rails, it’s a whole other story. I almost screamed when i read up on mod_proxy, mongrel, fastcgi, and capistrano, and memory usage.

    (Granted it can just be a simple matter of copying files via FTP, but i rarely find it is)

    I guess its just another one of those double-edged swords.

67. Peter Cooper Says:
    January 10th, 2008 at 11:57 am

    We are discussing this issue, as a community, over at:

    http://www.rubyinside.com/no-true-mod_ruby-is-damaging-rubys-viability-on-the-web-693.html

    It seems Rails in particular might be too slow to run in a mod_php-esque fashion, but there should be a way to build a Tomcat like application server that can manage multiple apps, rather than have to set up lots of Mongrel clusters manually. This might eventually prove to be a solution for shared hosts, especially if it can terminate dormant apps, and only focus on those in actual usage.

68. Frankie Robertson Says:
    January 10th, 2008 at 2:39 pm

    Perhaps consider replacing mod_fcgid as it seems to have better process management than mod_fastcgi. (I know it’s rails’ fault but still.) Additionally this would benefit Djangonauts like myself and anyone else using fastcgi.

69. RJ Says:
    January 10th, 2008 at 3:47 pm

    Dallas,

    I disagree that you don’t stand to make more money by getting RUBY to work better in a shared hosting environment. I would love to deploy Merb and Sinatra apps at DreamHost. Help make Ruby run right by hiring a couple of devs to work full time on it. Don’t just think about Rails. Fix Ruby in a shared hosting environment, and someone else will fix Rails to meet that environment.

    1. Fix mod_ruby (or replace it with something that works)
    2. Give me an easy option for installing my own gems
    3. Charge me $5 more per month
    4. Profit!

    Take a look at EngineYard. They are investing in Ruby to make it faster via Rubinius.

    There may come a day when I actually stop using DH for my shared hosting projects. A possible replacement will be http://www.heroku.com. They make rails run without dealing with any deployment. You can import a .tar, change the database.yml and run your migrations – and then it’s live.

70. Robert Says:
    January 10th, 2008 at 4:14 pm

    Very good post. I recently chose to build an application in PHP just because of RoR’s deploying problems. Even Java, of which my day job consists of, is easier to deploy on. Yes hosting companies don’t like it, but that is a side issue.

    If the RoR gang weren’t so elitist and actually help people out, RoR would grow much larger. If not, it will be relegated down to startups and enterprise apps, and they will have a hard time competing with Java in the enterprise realm (even with JRuby).

71. Albright Says:
    January 10th, 2008 at 5:37 pm

    Adrian Madrid:
    I do *not* want Rails to be more like PHP. For one, I know that’s like saying I want a carriage to be more like a horse; for two, you seemed to have missed that I don’t like the idea of using these really thick “frameworks” for 90% of web development anyway, especially if it’s just hobbyist stuff. No, I want *Ruby* (or some other language with better syntax and coherency than PHP) to be more like PHP, in terms that I can write code, upload it to a server, and have it just work. I’ll say it again; what Rails (and Ruby itself, as far as I’ve seen so far) lacks as a method of developing web apps is anything approaching PHP’s It Just Works factor.

    Aaron:
    That AppJet thing is interesting, but not quite what I had in mind… I’ll give Helma a further look, though. I hope it can do ES4.

    Pratik:
    In 41, you seem to be making the argument that arbitrary breakings of backward-compatibility is a-okay…

72. Ben Says:
    January 10th, 2008 at 11:11 pm

    This is a passage from this months dreamhost newsletter:

    “Of course, it’s not like the newsletter is late because we’ve been
    working on a lot of features or anything. Nope, just your average
    everyday run of the mill holiday laziness and overall slackitude plus
    slothibility at work.”

    That says alot…

73. Larry Gilbert Says:
    January 13th, 2008 at 10:01 am

    Glad to see DreamHost’s candid comments, especially those from Terri, the one apparently in charge of the Rails side of things. Now I see that if I’m going to continue to get serious about Rails, I’m going to have to start looking outside of DreamHost for committed support.

74. adwin Says:
    January 13th, 2008 at 10:59 pm

    I love how the rails work and still envy for it. I would love to see “nice php version” for rails someday (cakephp, have the same features but it has no good documentation).

    I also wish, i could install rails application as easy as copy and paste into apache server like the php one.

75. Rick New Says:
    January 13th, 2008 at 11:16 pm

    I’m one of those Rails newbies, just about ready to bail because of deployment issues.

    For the last 3 weeks I’ve been trying to learn both Rails and Ruby. Learning Ruby has been pretty straight-forward. I’m taking a free tutorial from Satish Talim. The community is great and the course is nice. The Ruby books are pretty clear and up to date. There are a lot of free resources and pretty much everything makes sense.

    As to learning Rails, it’s been a whole different experience. I attended a local users group, and while the community was nice, not a single person reached out to offer any learning assistance, even when I asked if I could hire someone for personal training.

    I’ve bought 3 books and had to return them all because after a few days I ran into the major differences between 2.0 and the previous version in all the books.

    I signed up with Joyent (the official Rails host) to try and deploy a test application. The KB docs for deployment were difficult and the host stated they “will not support deployment issues.”

    I think I’ll stick with learning Ruby for a while and continue to watch Rails develop. Yes, I think they could reach out a little bit more during the early stages of folks coming into the community.

    I’m currently developing on .NET with Visual Studio 2005. Shared hosting deployment is as simple as choosing a .NET host and uploading to the server.

    Visual Studio has improved a lot since the 2003 version and C# is a joy to write.

    I’m not ranting, if anyone has some suggestions for moving from .NET to Rails, please give me some advice. I want to use Rails, but the hype (at least in the early stages) seems disconnected to the reality.

76. Ryan Says:
    January 14th, 2008 at 7:49 am

    I’ve been a Dreamhost customer for something like 10 years. 11? Not even sure. Obviously I’m relatively content. I’m also a Rails developer and I’m using Dreamhost as a host for a commercial, public-facing Rails app, as well as a B2B system. I’m a very experienced Perl and PHP developer.

    My impression of Rails has been that although the hype FAR outpaces the reality, Rails is really neat stuff. I was aggravated to discover that Capistrano isn’t anywhere near as simple as Rails advocates will have you believe, I spent two full days just trying to find current and accurate documentation for it. That was partly Dreamhost’s fault for hosting out-of-date documentation in their wiki, partly Capistrano’s fault for ignoring backwards compatibility, and partly the Rails community’s fault for religiously pretending that Rails “Just Works” with no problems. Rails people tend to skip the standard ‘troubleshooting’ talk because they have faith that there will be no troubles. That’s not impressing potential new converts to their religion.

    I still spend at least a full day just setting up deployment for every new app even now that I know what I’m doing. Most recently because when Rails can’t open a log file for writing at runtime, it doesn’t even tell you the path of the file in the HTTP stderr log message. That’s just one of many, many, many examples of rough edges on Rails that make it just not ready for prime time. You can’t open a log file for writing, so that’s a catastrophic error, and you make a log entry where you don’t even tell me which file so that I can make some progress? “Just Works”, heh… Zed has it right when he says that the Agile book’s introductory development session is pure fantasy. Rails proponents would like you to believe that Rails is far more solid, stable, and reliable than it really is.

    I’ve come to love Rails and I’m not turning back. I’ve come to learn to make Rails work with Dreamhost and I’m not turning back. But now that I know better, I chuckle when I read some of the propaganda coming out of the Rails community about how it “Just Works”. No, sorry, Perl and PHP “Just Work”, but Rails is a delicate machine that requires a lot of love. It’s cool enough to keep my attention as long as I keep that perspective in mind.

77. Gunnar Wolf Says:
    January 16th, 2008 at 11:42 am

    Being a DreamHost customer, a Rails developer, a Debian developer and member of the Debian pkg-ruby-extras team (co-maintainer of Mongrel in fact ;-) ), I must say it amazed me how hard it was to get my systems running in DreamHost. I agree with Brent (first comment to this post – Shame that this blogging software limits postings with over three links :) Yes, spam sucks big-time), it is not a pleasant experience at all.
    Terri complains about installing Gems in Debian systems (third comment to the post) – And boy, I share your pain. Our group in Debian has long been a strong critic of mixing RubyGems and Debian, as it is a sure way to mayhem and chaos.
    But, DreamHost guys: Please reconsider moving away from FastCGI (which sucks) towards Mongrel. Yes, I agree with Dallas’ comment regarding Lighttpd and SCGI – In its due time, I bit the SCGI bullet and packaged SCGI for Debian. I even used it at one of my servers with libapache2-mod-scgi… And I recognize it is easier and more reliable than FastCGI. But just when I was about to make my experimental package into an official one, the Mongrel hype came up.
    Anyway… Mongrel is reliable, it is quite easy to install – and (shared hosting providers, this is interesting to you!) it easily provides perfectly separated processes for each user. Even more, it is built to be used in clusters, so (putting that combined to Dreamhost’s way, where user directories are shared over NFS) it’s potentially very easy to make it scale, even send it to other machines. I have enjoyed a much easier deployment (and much more reliable ongoing operation) since I moved over to Mongrel.
    Now, regarding how The Rails Way is sometimes a royal PITA… Yes, indeed. It shares very little with the Debian culture (with which I’m much more comfortable) that values long-term stability over changing features with the newest fads. But then again, Rails is a very productive and nice environment to work in!

78. Rob Morris Says:
    January 18th, 2008 at 10:23 am

    I dunno, guys. I use A2Hosting.com for my Rails hosting on a $100/yr shared hosting package with shell access. They have cPanel 11 with Rails support, Mongrel, and I have never, NOT ONCE, had a server error due to deployment. I run 4 sites on two shared hosting accounts. It’s a piece of cake.

    YMMV, but I think DreamHost may be scrimping on per/user RAM or some such, if this is such a big headache for them. I think extrapolating from one host’s experiences to a major problem with the Rails application stack (& core team) is a bit of a stretch.

79. Aaron Blohowiak Says:
    January 21st, 2008 at 11:12 am

    Make your shared hosting force users to use jruby, this way most of your complaints disappear or become readily manageable.

80. Kondo Says:
    January 21st, 2008 at 7:21 pm

    I have to say that dreamhost has good to me in the past years but I pretty close to take my rails app in to public beta and Dreamhost is just not suited to rails apps in its current state. I’m going with another provider where they gives user mongrel support and apache support (its not hard to do). Virtualization is a great thing and this other provider has embraced it very well.

81. remi Says:
    January 24th, 2008 at 11:01 pm

    Christoph, let’s be real here; how many people out there are really building Ruby web apps without Rails? (Or Ruby apps at all, for that matter?) Is such a thing even possible on DreamHost?

    @Albrigh:

    You would be surprised! Especially since Christian Neukirchen’s awesome Rack.

    I love Ruby. I very much like Rails, especially for the part it’s played in helping me to learn Ruby and … cause it’s just plain awesome.

    That said … I don’t write many Rails apps. That’s mostly because of the resources they require, which is pretty ridiculous, and also because I typically just don’t need all of the overhead and the things Rails does. I’m happy working closer to the “real code.”

    Lots of developers are writing apps using either Rack-compatible web frameworks, or using Rack, itself. Support Rack and you can easily run your site using CGI, FastCGI, Mongrel/Thin … or anything that has a Rack handler.

    You would also be surprised about the number of people using Ruby ‘off rails’ or off the web, in general. It’s a good general purpose programming language. All you have to do is watch/browse Rubyforge to see all of the various thing people are doing.

    Also, I like me frameworks that support Rack because it means it’ll run OK on dreamhost :)

    Also, I dunno how people so easily overlook things like … eruby? Dreamhost has information about it in its wiki. It’s basically PHP-style development for Ruby. I’ve build sites that I would’ve used PHP for in Ruby, using eruby (on dreamhost) and I’ve had great experiences with it.

82. phil Says:
    January 25th, 2008 at 4:36 am

    You can’t compare an MVC application framework with a programming language/templating system. You need to either compare Rails and some PHP MVC framework or Ruby/ERB and PHP.

83. andres Says:
    January 29th, 2008 at 6:58 pm

    It’s sort of lame asking the rails developers to thing about the shared environment, specially coming for a company that hosts several hundred of thousands sites.
    The right move is to contribute with one developer, full time, and help rails having the features you are asking for.

84. toadalee Says:
    February 6th, 2008 at 11:37 pm

    So am I wrong to recommend using phpcake as your framework instead of rails if you want to use php? I have been looking at RoR and PHPCake and they seem very similar. Mambo has actually chosen phpcake for their next version (5). That should give it some clout.

85. Buy Phentermine Online Says:
    February 23rd, 2008 at 1:40 pm

    Hi, nice post. I couldn’t understand some parts of the article but it sounds interesting..
    Continue writing…

86. Jourgenz Says:
    April 17th, 2008 at 3:32 pm

    It’s test.
    I could’t post a message…

87. Ankara Sohbet Says:
    October 28th, 2008 at 3:53 pm

    teşekkür ederim.