DreamHost Blog » Rails Is as Rails Does

Rails Is as Rails Does

January 10, 2008 on 12:17 pm | In Insider View, Rants by Dallas Kashuba |

Ruby on Rails

I recently wrote a self-described ‘rant’ describing some of the experiences DreamHost has had working with Ruby on Rails on our platform, and with some recommendations on how the Rails community might be able to improve the situation. That post has received some excellent comments, including some by DHH, the creator of Ruby of Rails, and I’d now like to follow-up with some clarifications and further comments of my own.

My original post was intended primarily as commentary for the Rails developer community as a whole and they are, of course, free to take it as simply that. 37 Signals and DHH obviously have their own agendas, business and personal, and those agendas are largely not in line with any agendas DreamHost is working to further. I hope my comments may be taken as ‘food for thought’ by the larger Rails developer community. The project will survive just fine with or without taking my advice, and the zealous user community will likely remain zealous.

DIY

Some of the response to my post was essentially ‘do it yourself’. DHH also went so far as to recommend we not treat the Rails community as a ‘paid vendor’ and to ‘wipe the wah-wah tears’ from my chin. While that is a very valid request, I don’t believe it applies in this situation.

Ruby on Rails is a pretty small part of our overall service. We have already put in a not insignificant amount of work to support Ruby on Rails, including a pretty good amount of user training to assist people new to Rails, and have in general worked to further the cause for it in the shared hosting environment. Aside from hardware, we don’t really have very many paid vendors of any kind now. We have ourselves developed all of the custom perl-based software our business relies on (warts and all). We very much believe in the DIY mentality and it’s been a major part of our business history. Additionally, our business will not be significantly affected one way or the other by the future actions of the Rails community. It simply does not have the critical mass necessary for that.

That said, I would like to see Ruby on Rails reach toward that critical mass of users, and thereby become a larger portion of our business. For that to become a reality I believe it needs to be simpler to use on the server side of things. A larger user community is a good thing for any open-source project.

Bride of PHP?

I mentioned PHP several times in original post, but I very much do not want Rails to become ‘another PHP’. That would be silly, as one PHP is plenty! Ruby on Rails seems to have a conflicted identity at the moment. It is simultaneously compared to enterprise technologies like Java Servlets as well as more average joe programmer technologies like PHP. There are more traditional web programmers experimenting with Ruby on Rails and exploring it, and there are professional enterprise programmers investigating it. The amount of attention Ruby on Rails has achieved in such a short time is awe-inspiring.

Programmers are Lazy

The fact remains that both of those groups of web application developers, and I’d go so far as to say all web applications developers, want development environments that more or less ‘just work’. They want to focus on programming and leave the server administration alone. Rails does a great job at saving programmers on programming time (which is exactly why programmers like it), but many reports I’ve heard indicate that in many cases it trades that programming time for back-end server administration time instead. The average joe programmers out there are typically using completely managed hosting environments that they do not have much control over, and the enterprise programmers are typically using a somewhat complex and large-scale established environment that they also do not have much personal control over. Even those VPS users who do have more control over their server environment do not want to be spending their time managing that VPS. They want to be spending time writing those great applications.

If Ruby on Rails were made to be simpler to use with a wider range of hosting environments, big and small, that would ultimately benefit Rails itself far more than it would benefit DreamHost or me personally.

I would be happy to provide a free hosting account to anyone who would like to help work on these issues with us. Just contact me through our contact form and we can talk about it.

UPDATE! : DreamHost makes using Mongrel much easier! This is one way we’re working to make Ruby on Rails easier to use.

47 Comments »

RSS feed for comments on this post.

1

Having built a number of projects with both PHP and Rails, I found your post right on the money. It’s very disappointing to read DHH’s (which I generally think of as a decent guy) response.

Rails is a very nice framework, but have been amazingly hyped since a very early stage - and it’s truly starting to show. Unfortunately, RoR is far more present in Hype-based publications like Wired or O’Reilly than in actual servers running Web apps.

Comment by NY — January 10, 2008 #
2

Dallas

You hit the nail on the head in this post.

The “Just Work” mindset is EXACTLY why I love your DreamHost PS offering.

Comment by Micheal — January 10, 2008 #
3

Hi Dallas,

As a Dreamhost customer and RoR developer, I’d LOVE for DH to find a solution to this problem. It may have been suggested already (I haven’t read all of the comments on the other post), but have you guys looked into mod_scgi? It may be a viable alternative, and benefit Python and Perl users as well.

Mike

Comment by Mike Hodgson — January 10, 2008 #
4

Dallas,

Garrett Murray wrote a response as well at http://log.maniacalrage.net/

As he says, if companies like Segment Publishing can run Rails apps with no trouble, then why can’t you? I think it comes down to flexibility. Some hosts are willing to run Mongrel, but I guess Dreamhost isn’t. If other hosts can do it, you can to. We may not know anything about running a hosting business, but Segpub certainly does and they can run Rails apps no problem. So don’t blame your lack of flexibility on Rails, just admit you’re not willing to put the work in. If it’s not worth it to you, then that’s fine, but own up to it.

Comment by James — January 10, 2008 #
5

One of the great things about Rails and the Ruby development community is that our interests lie outside of just writing code in dreamweaver and ftping it to the server. I’d venture to say that most Rails developers want the kind of control of a server that shared hosting doesn’t offer. Sure, I could pay $5 to Dreamhost to get one site up in running, or I could pay $20 and get a VPS from someone like linode or slicehost and do whatever I want with it, all the while learning valuable unix skills. The whole ‘hosting is a black box mentality’ will just keep developers continually relying on hosting vendors for a crucial aspect of their business. d

Comment by Nathan — January 10, 2008 #
6

There’s a bit of irony to be noted here. RoR’s “convention over configuration, saves time by using smart defaults instead of asking every possible question” only goes as far as Dallas points out. Saves programmers time, not System Administrators.
(And much of the time, especially on Amature levels, Programmers ARE System Administrators.)
True for the framework (i.e. related to the code itself), not for the installation (i.e. the integration to the server itself).

Comment by Jason — January 10, 2008 #
7

James,

Dallas already addressed the Mongrel issue in his previous post… “Recommending technologies that are not widely used or supported by any major web hosting company is putting too much of a burden on your users…”

The issue isn’t flexibility (though I think Dreamhost is probably one of the most forward-thinking and flexible webhosts out there.) The issue is Rails has failed to provide the bigger community out there with a solution that is easy to use with the standard tools available. Saying, “well why can’t you use Mongrel” is kind of like telling a carpenter that he can’t use a table saw anymore in your new workshop. You just don’t convince very many carpenters to come use your workshop that way.

Comment by Mike — January 10, 2008 #
8

I run a RoR site (click my name) here at DreamHost. I admit, I had some difficulties using the normal shared hosting account (the site would get aggro’d by some random process monitor that would kill it, sometimes the mysql ran slow as dog molasses), but once I upgraded to DreamHost PS all my problems went away.

I’m not running a big site — only 500 uniques a month, maybe 1.5k page-views a month, but I consider that to be pretty, uh, “hobbyist.”

The biggest problem I encountered was finding Capistrano examples so I could use it to deploy my site whenever I updated it.

Comment by Arron — January 10, 2008 #
9

lol… I read that post by Garrett Murray, and in my opinion he actually proves Dallas’ point.

Comment by Mike — January 10, 2008 #
10

“A larger user community is a good thing for any open-source project.”

You’re not thinking that statement through, and I suspect to some degree the flaw in your logic is the underpinning of DHH’s response to your original post.

Core developers on such an open source project split their time between “inside” work (moving the project forward and identifying new potential core developers) and “outside” work (answering community questions and otherwise communicating with the public). There has to be a balance here: too much inside work and the community stagnates, while too much outside work means the project doesn’t advance very quickly because coders have less time to code.

Rails has been growing its core developers and key outside contributors — those people who create the acts_as… extensions and other plugins. Rails has been able to grow these teams by virtue of the fact that the audience self-selects to one that tends to breed those contributors. In other words, *because* Rails is more difficult than PHP to deploy, it’s been attracting developers who, on average, are more likely to want to tinker, create plugins, and contribute back to the core.

If, for example, Rails 3.0 dusts off the apparently-stagnant mod_ruby extension and cooks up a Dreamhost-friendly deployment model, in the loooooooong term, this is probably a good thing. It might even be a good thing in the short term, but I doubt it.

The problem is, by opening up Rails development to a new tier of developer, you change the balance of inside vs. outside work. I suspect that a Dreamhost-friendly version of Rails will draw an increased number of developers from the PHP/ASP.NET world, who I further suspect will be less likely to be contributing back to the core, writing plugins, etc. Moreover, because they’re new, they’ll have lots of questions…many of which will fall back on Rails Core to answer. As a result, Rails Core will be less able to work on Rails 3.1 or Rails 4.0, meaning those releases will take longer to push out or will have less in them.

Eventually, a new equilibrium will probably set in, once there’s enough books, blogs, and other bases of knowledge for the influx of new folk to lean on, lessening the pressure on Rails Core.

However, that “dip” will annoy the heck out of Rails Core, as they feel stretched further and feel they won’t get as much back in return (in the form of contributions, plugins, etc.) for the increased work.

Revising an open source project explicitly to attract a new breed of developer is a strategic decision, no different than deciding to support a new OS or totally revamp an API. Not all projects will want to push through that dip. That’s part of the reason for the “DIY” attitude — you’re asking them to both do a lot of development *and* take on short term support pain for long term gain they may not value as much. At least if you built it yourself, you’d save them the development time investment.

This is not to say that your technical goals are wrong. But bigger is not always better for open source projects, particularly in the eyes of those who bear the greatest burden for those projects.

(posted with apologies to Seth Godin for reworking his “dip” concept…)

Comment by Mark Murphy — January 10, 2008 #
11

What people could do instead of bitching at DreamHost and proclaiming the glory of Rails is to do what Zed Shaw suggested in his rant …

Use MERB instead of Rails. It’s a superfast, thread safe, Ruby for the web framework.

Comment by Tim — January 10, 2008 #
12

Mike,

What I think you failed to realized is that Mongrel to Rails is more or less mod_php to PHP. The issue is not that Mongrel isn’t standard to major web hosts, but that Rails isn’t as widely used as PHP. For Rails developers, Mongrel is now the standard way to serve Rails apps.

Also, if hosts aren’t willing to implement new technologies until they’re well supported, then how are new technologies supposed to become well supported in the first place? By your logic, any new technology should just be abandoned.

So if a major web host like DH wants to support Rails, then they need to keep up with the “standards” in that community (in this case, Mongrel). If DH isn’t willing to put in the work, then don’t support Rails. It’s as simple as that. A host that is not willing to put in the work (even if does not account for a huge amount of their business) to support something as fast growing as Rails pretty much defines inflexibility.

Comment by James — January 10, 2008 #
13

@Mike (#8)

You think I proved Dallas’ point why? Because I agreed it’s difficult to host? I think you may have missed the real point–that DH and some other shared hosts don’t want to do the work to host Rails properly. But there are plenty of places (including non-VPS hosts) who have made it work (and work quite well!).

My argument is that Rails isn’t as hard to host as DH is making it sound. That is, unless you’re unwilling to make any changes. Sure, then it’s really hard. But that shouldn’t be held against Rails. If DH doesn’t want to make changes to support Rails then it will never work, regardless of what the Rails community does.

Comment by Garrett Murray — January 10, 2008 #
14

@ Murphy

So, by that logic rails should be hard to use, since if it is too easy it will attract inexperienced developers? Yet, the whole point of ruby on rails is making things easier.

I can understand not having the time or motivation for making certain improvements, but saying rails isn’t trying to be something big and attract new users is a little disingenuous.

see http://www.rubyonrails.org/

“Everyone from startups to non-profits to enterprise organizations are using Rails. Rails is all about infrastructure, so it’s a great fit for practically any type of web application Be it software for collaboration, community, e-commerce, content management, statistics, management, you name it.”

Comment by michael — January 10, 2008 #
15

As someone who tried deploying a simple Rails app on shared DH hosting a while back and utterly failed, this is a really fascinating discussion. I don’t understand Mongrel/Capistrano/etc. well enough to hold a position on what the Right Technical Answer is, but the messages I’m hearing from the RoR crowd are disheartening. As a small-time developer who is a Rails novice and whose work will be on shared hosting for the foreseeable future, what I’m hearing is that RoR is a) not really designed for me and b) that’s my own problem.

It’s a shame because I like a lot about the design of Rails. What I’ve been doing since that initial bad experience has to been to try to use as many of its concepts as I can with languages I have more experience with (including the much-maligned PHP).

Comment by Chris — January 10, 2008 #
16

@Chris, 14: What problems have you had deploying your application?

Comment by Arron — January 10, 2008 #
17

Who cares if Rails doesn’t gain popularity? Monkeys can (and do) write PHP scripts. (and by write I mean steal scirpts and use Wordpress). Look what happened to that language. It’s a terrible mess.

Don’t give me that “Digg runs on PHP and so does Facebook” line. Those developers are smarter than most. They also know how to deploy an enterprise app. THey’re not using DH and sharing rsources with a bunch of script kiddies.

End users don’t care what language a web app uses, just as long as it works. They will pay what the contractor tells them it costs.

If you think Rails is hard, too hard to learn, or too hard to deploy, then you keep right on using PHP or something else. I’ll use Rails. I’ll get my projects done faster than you and I’ll charge less because of that fact. I invested in myself. I learned how to deploy with Capistrano. I don’t have to FTP my files. I type a command on my local machine and the new version is rolled out to all of my servers. That process even takes care of my database too, changing tables, migrating data, whatever i need it to. Took me about an hour to figure most of it out too, thanks to the great Rails community.

If you don’t want to take the time to learn Ruby, Rails, and how it all works, then you’re missing out on a great opportunity. Technology changes, and you have to change with it.

Comment by small time dev — January 10, 2008 #
18

I hear a lot of people out there saying that Rails people are a bunch of arrogent jerks. A few might be, but you should know that anyone who needs help deploying applications, or writing code can get help any time they want from hundreds of volunteers.

IRC chat
#rubyonrails on irc.freenode.net

Or Rubyonrails on Google Groups
http://groups.google.com/group/rubyonrails-talk

Comment by small time dev — January 10, 2008 #
19

Mongrel, Apache, whatnot are all just web servers. Apache is the most used web server in the world. Why would you think it’s an obvious thing to not properly support it?

When we started the development on Grails in the summer of 2005 we’ve chosen to re-use everything we could that was available on the Java platform. Now that’s a strategic decision.

Today Grails applications are deployed as just a WAR - for people who know what that is - and it just works on just any Java web server, from Tomcat over WebSphere and OC4j to Weblogic.

Actually, it’s up to users to figure out which server fits them best. But which ever of the existing servers they choose to deploy Grails applications they’re never going to get in trouble.

Still Grails does everyting Rails does and more.

People have said that Rails saves time in development and that is very true. It does not seem to save time in deployment and that’s a shame.

If however you add everything up than you have to conclude that Rails is a gigantic ego trip of a few people led by Generalissimo DHH (see his reply to the original post). That’s according to me is the true nature of Rails and all the rest is second to that.

Rails has inspired a lot of people and has really un-stuck a lot of things. Half of the leading web frameworks in Java for example didn’t exist 3 years ago. PHP now has a lot of Rails-like frameworks as well.

So if Rails has been the experiment that changed everything then the real benefits can be found in the established communities: PHP and Java.

Comment by Steven Devijver — January 11, 2008 #
20

@Steven #18:

Comparing Grails to Rails is a little unfair. You started out writing something on top of the JVN. Rails started out using Ruby which wasn’t used anywhere on the web really. Smart move on your part, but as you implied, someone had to blaze the trail.

Rails supported Apache from the very beginning. The problem is that FastCGI worked, but it didn’t work well. Nobody was maintaining the fastCGI project. They still really aren’t. Since you don’t have the keys to FastCGI, you go invent something different so you can move forward.

You’re implying that Rails, like Grails, should just “use what’s out there.” So why doesn’t Grails run on Apache with FastCGI? Why do I need a Java web server? Heck, why can’t all Java apps run on Apache with mod_java or something? Simple, the same reason I need a Rails app server. It’s specialized technology and it’s different than how people are used to doing it.

JRuby will make deploying Rails accessible to anyone using Java. I personally don’t like Java (the platform) but I do think that’s where Rails needs to go.

Even so, deployment of Rails apps is not hard. It’s just not what people are used to. The “Deploying Rails” book has many different deployment strategies, from using Apache to deploying on shared hosting, to deploying on Windows. Once you get how it works, you can code up a general recipe and automate the whole thing, from configuring Apache to rolling out database changes, just like you can with ANT.

I could say that ANT is hard to use, and that I can’t get a project deployed to Tomcat with that. That’s because I never took the time to learn it. It’s all about priorities and where you think the value is.

Comment by Brian Hogan — January 11, 2008 #
21

@Arron #16:

Keep in mind that I tried Rails on Dreamhost more than a year ago. I rsync’d my code onto my server and performance tanked as expected without FastCGI. I followed some directions posted over on the Dreamhost Wiki on how to configure FastCGI, which got things more or less in good shape at first. However, every couple days, requests would start timing out and/or throwing generic server errors. Killing all the fastcgi processes got things back up and running, but then a couple days later the same thing happened again.

Comment by Chris — January 11, 2008 #
22

One of the current nits that makes deploying Rails applications more troublesome than it should be is that the FastCGI configuration doesn’t seem to set RAILS_ENV=production reliably despite http://wiki.dreamhost.com/FastCGI saying that it should be. I’ve tried getting support on this, but didn’t get anywhere. Other than that problem I have a pretty reliable Capistrano set-up which will deploy to DreamHost with no problems.

The broader performance problem with Rails (and Java application servers for that matter, so Grails is no better) in a shared hosting environment is that it is designed to do a large amount of initialization at start-up time in exchange for making each individual request more efficient. As such the intention is that each server process is a long-running process and will stay in memory. This seems to conflict with the shared hosting economic model where (I guess) the hope is that sites that are idle don’t consume resources.

Comment by Mark Wilkinson — January 11, 2008 #
23

@James,

Usually, I think the way of open source projects from hobby to mainstream goes something like this:

1. Someone starts a project.
2. People like that project, start contributing.
3. Those people _know_ what they do, they are deeply involved. If the project turns out as a good idea, they will use it more often.
4. Since they’re using it more frequently now, the changes they make also improve the usability. This again widens the community.
4a. Deployment etc. is a part of usability. If developers start deploying things more often, they will improve the ease of the deployment.
5. Once these things get into a stable state, it is more attractive to a even wider community, and third party “supporters” (e.g. hosters).
6. Profit! (Sorry, couldn’t restrain myself :)

So, as I understand it, the DreamHost guys are doing you a _favor_. They are telling you that from they’re POV, you’re now somewhere between 3 and 5, and that 4a seems to be demanded by their customers (at least by some). Take it or leave it, but would it be better if they didn’t tell you at all? You might think it would be best if they’d contribute it, but why should they? They’ve already contributed by giving you feedback.

Rails isn’t perfect. It will never be. Nothing will. And I can’t quite understand the hostility of some parts of the rails community (people that get work done aren’t usually very loud, unless they’re also very funny or have another talent that makes their writings enjoyable. At least that’s my impression) when people tell them what they think could be wrong. In open source, information _is_ a contribution.

Of course, there are people who just say bad things because it’s “in” (the same with people who say $framework is the best, just because it’s “in”). But very often, people who take the time to give feedback _do care_. Not every critique is a demand or an insult.

So, that’s enough for now, I think. Excuse the somewhat longer sentences, but I’m native austrian and can’t quite shake that habit :)

I’m not a Ruby developer btw. I personally use Perl (especially the Catalyst framework these days). Catalyst’s community and popularity is (at the moment) behind Rails, but the DreamHost guys have always been very helpful, open and communicative. AT least that was my impression.

Comment by phaylon — January 11, 2008 #
24

Oh don’t worry guys, just throw more hardware/money at the problem, DHH is paying for it! Oh wait…

Comment by to_be_defined — January 11, 2008 #
25

@phaylon,

I totally agree with you, but the way in which DH went about it is pretty disgusting. First of all, Dallas didn’t mention a single thing in his post that hasn’t been said a million times already (information is only useful is it’s new). Secondly, his post is _filled_ with passive aggressive insults directed mainly at Rails, and also at the community. If he wanted to rant that Rails is hard to deploy (which it isn’t), fine! But don’t it on the blog of a professional hosting company unless it’s actually useful to the community (which this wasn’t).

But again, the main problem I have with his argument, is that other shared hosts seem to be able to run Rails apps just fine. So why can’t DH do it as well? That question has yet to be answered by anyone.

Comment by James — January 11, 2008 #
26

In my opinion, Dreamhost is providing a service to the Rails community by stating the inherit difficulties in deploying RoR on a shared hosting environment.

It’s a service b/c they have the knowledge, expertise, and critical mass to give merit to their statements.

The community should listen, and help provide solutions … not bitch/moan/complain that Dreamhost doesn’t know what they are doing.

Comment by Tim — January 11, 2008 #
27

Responding to James and Tim (and probably others) is that it doesn’t matter if Dallas is right or wrong technically or socially. He’s expressing a perception that RoR is painful. The core of the complaint is that RoR is difficult to deal with. Whether it’s a technical issue, or a documentation issue, or even a publicity issue has to be dealt with. The RoR community can’t just dismiss the opinion of the head of a major webhosting company and say it’s his problem. Clearly it’s a *lot* of people’s problem and needs to be addressed; not criticized.

Comment by sdayman — January 12, 2008 #
28

Interesting article and great comments. thanks for sharing.
http://www.golfnorwich.com/

Comment by http://www.golfnorwich.com/ — January 12, 2008 #
29

@DreamHost: Sounds like you’re just trying to give advice to the RoR community about how to get more mainstream. Why not say it like that without slamming on their work and accusing them of being elitists?

Your tone sounds rather selfish and whiny. Paraphrased, here’s what you sound like:

“Dear RoR community: In order for us to profit more from your hard work, you’ll need to do a bunch of more work. And don’t ask us to pitch in, because that would be elitist and not real world. KKTHXBAI”

Comment by Chad Myers — January 12, 2008 #
30

I totally agree with the Dreamhost guys. Rails is great but not for the sys admins.
I’ve recently build small site for my client in UK. He wanted a cheap hosting solution in UK. All the shared hosting plans for Rails in UK are generally more expensive than VPS or even dedicated servers. Web development with Rails is faster and easier but most of the saved time I devoted on deployment.
In terms of hosting, PHP is light years away.

Comment by tyler — January 13, 2008 #
31

For all the people saying how great Rails is, think about this.

According to 37signals, it takes 30 servers to run Basecamp, Campfire and Highrise. Yes, 30 dedicated servers.

As such, they have to pay someone to be a fulltime system admin. See their post about it here.

My logic is such that if simply using a framework is causing you to have to hire a fulltime system admin, then considerable time needs to be spent optimizing the framework to elevate this need.

Comment by Tim — January 13, 2008 #
32

I’m running my e-store on DH account, written in RoR from ground-up (click my name). I don’t have a DH PS (when they’re going to be available to the public, huh?), just a basic account for 9$/month.
After some initial few-hours-long hassle with deploying and running it for the first time on my DH account, it works like charm. It runs so good I’m actually trusting my business on it and not planning to move to any VPS.

Good work, DH guys!

Comment by Tomash — January 13, 2008 #
33

This post illustrates why I moved my sites away from Dreamhost’s managed hosting to a VPS. It was quite clear that they have no intention of ‘managing’ anything other with exception to PHP and MYSQL. Why? Because they take no work to manage.

However, I would suggest that Dreamhost stop advertising that they support Rails when in actuality there is only limited support for a very simplistic vanilla setup.

Comment by Matt — January 13, 2008 #
34

Interesting info, I never knew about it until now. Thanks for sharing this valuable information.

Comment by Aurelius Tjin — January 13, 2008 #
35

@Tim,

37 Signals may need 30 servers, but I would guess that Facebook needs hundreds of servers, and they use PHP. Facebook most likely employs __many__ full time sys admins to keep their site running.

So does that mean PHP needs to be improved?

Your logic is severely flawed. Obviously high traffic sites are going to need to scale out to multiple servers. To run a simple J2EE app you would need at a bare minimum a VPS with 1 gig of RAM, so does that mean J2EE needs to be optimized? If you want the benefits of using a framework like Rails or J2EE, then you have to pay the price. My question is…so what? If DH doesn’t want to put the work in to fully support Rails, then they should stop saying they do, and not blame Rails for their lack of effort.

Comment by James — January 14, 2008 #
36

@James

Are you seriously trying to compare the traffic of Facebook to BaseCamp.?

You’re kidding, right!

Facebook is something like the 7th most visited website in the WORLD.

Basecamp/etc.. probably isn’t even in the top 10,000 of visited sites. I can think of news/blog sites that get a ton more traffic than Basecamp that run on a single dedicated web server (e.g. TechCrunch, Gizmodo, Engadget etc).

Comment by Doug — January 14, 2008 #
37

James

Wow. I really don’t know what to say other than - WOW.

You just made a comparison the traffic patterns of a $10 billion valued company, Facebook, to 37signals.

Wow!

Comment by Tim — January 14, 2008 #
38

I really wish you looked at how WebFaction hosts Rails sites. From what I’ve read on various forums they manage to keep Rails sites stable for the same price as DreamHost (not sure how they do it though).

Comment by Pete — January 14, 2008 #
39

Tim: James is absolutely correct. The point you’re missing is that professional, commercial web services need professional-grade resources. TechCrunch, Engadget, etc, are blogs, not applications in the way that Basecamp or Facebook are (hell, TC is running Wordpress). When it comes to system resource usage, database reads on even high-trafficked sites like those are nothing compared to interactive use, whether you’re using PHP, Rails, Java, or whatever.

Also don’t forget staging environments, load balancing, and everything else that comes along with serious web application development and deployment. 30 servers sounds about right for what 37s is doing. I recently worked for a much smaller (in terms of traffic/user base) company who ran about a dozen machines, including web app, mail, database, and file servers.

Incidentally, how are you privy to how Techcrunch, et al, are running their sites?

Comment by Kenn Wilson — January 15, 2008 #
40

@Doug,

As Kenn said, those sites you listed are blogs. VERY easily cached and MUCH more reads than writes. If you understood anything about databases and web applications, you would know that the more writes (interactivity), the harder it is to scale. So that basically makes your argument null and void.

@Tim,

Your ignorance shows through yet again. Here is what I said:

“37 Signals may need 30 servers, but I would guess that Facebook needs hundreds of servers, and they use PHP.”

That means that I am NOT comparing 37signals to Facebook. That means that Facebook is MUCH larger (e.g. HUNDREDS of servers). But that fact remains that you are trying to fault 37signals for having a full time sys admin and 30 servers. For an application suite such as that run by 37signals, 30 servers isn’t that bad. A comparable PHP app would need just as much.

Oh and how did you come to the conclusion that Facebook was worth $10 billion, because pretty much every economist on earth would disagree with you. Let me guess, it’s because MS bought a 1.6% stake for $240 million right? But did you also know they were able to extend their advertising partnership as a result? All that means is that they valued 1.6% AND an advertising deal at $240 million.

Moral of the story, do some research before trying to sound smart.

Comment by James — January 15, 2008 #
41

@James

I have nothing constructive to add to the conversation.

Given that, comments like “your ignorance shows through yet again”, and “do some research before trying to sound smart” make you sound like a self-absorbed dick. Just FYI. Not going to win any arguments that way.

Comment by Curtis — January 15, 2008 #
42

@James:

Concerning what Curtis said: Yes. Especially since that’s the behaviour you’re complaining about. The difference is that the DH guys didn’t insult you. In my impression they didn’t say anything other than stating their problems. The interpretation of it is yours.

Quite frankly, if a bunch of HQ rails guys would show up here and would’ve just said “Yea, we know, but thanks for the comment. If you’d want to discuss it in detail, you can contact me/us at $mail_here,” it would probably be a bright sunrise for rails’ community PR. Honestly, if you accuse everyone who makes a comment you don’t like of insulting you, you just won’t get feedback from them anymore. This is as I can see one of Rails’ biggest problems and the Ruby guys are probably also taking a few hits because of it. I personally (and at least a handful of other people I talked to, which where even really interested in Rails and Ruby at first) keep clear from the Rails/Ruby communities because of this behaviour.

As most of you, I earn my living with software development. And I simply refuse to include myself and my job into a community that reacts to critics that way. Even if you’d have been impolite, but answering honestly, and not saying “It ain’t so,” it would’ve been 10 times better for everyone.

Some of you might feel attacked from the article, but theirs no attack in there. It was probably written by someone who _wants_ DreamHost to support Rails in all possible ways. Do you think you’re reaction, your insults and denials are going to change anything higher up in the management?

Sure, other’s can do it, so why can’t DH? There’s surely a simple answer if we’d know DH’s management, facilities, staff, business plan or information about all other projects going on there. To me (and just me) the ranting in the comments sounds like you guys want DH to drop everything and fix it, just because you guys are so valuable. There is a lot of self-illusion in the Rails community about their size, I think, but I have no numbers. But I do know that when someone would ask me (as a non-Ruby dev) where to host his Rails site, I’d tell them to try DH. And I’m not even a customer yet.

These guys are maybe some of your biggest supporters, don’t blow it. Rails wouldn’t be the only one to take a hit. Every open source project after you will probably receive a small splinter of that bullet too.

Comment by phaylon — January 16, 2008 #
43

@Curtis

You’re right. You don’t have anything constructive to add. At least when I attack someone for their ignorance, I attack their arguments along with it. Nice try though.

@phaylon

I think you should read the original article Dallas posted, because it’s full of passive aggressive insults. If you can’t see that, then you should get your eyes checked.

The Rails community reacts in proportion to how they are attacked. People don’t attack PHP this way. Why isn’t Dreamhost posting about Java since J2EE apps would be MUCH harder to deploy and run on shared hosting. No, they only go after Rails. But the funny thing is, Rails developers don’t really care, because we all know to just host on a VPS, or pay for a GOOD shared host like Mosso. No one expects $5 a month hosting to be good for anything but serving up static html pages.

“These guys are maybe some of your biggest supporters, don’t blow it. Rails wouldn’t be the only one to take a hit. Every open source project after you will probably receive a small splinter of that bullet too.”

Do you really think anyones cares whether Dreamhost support Rails, or any other framework for that matter? If you need hosting that works, there are quite a few GOOD hosts that provide excellent suppport for Rails and any other framework you might want to use. DH is irrelevant. What matters is that they are blaming the Rails guys for lack of shared hosting support, when in fact it is their own responsibility to make it work just like many other shared hosts have. If that means charging more than $5 a month, then so be it. Dreamhost is pretty much the WalMart of the hosting industy. A ton of customers, and rock bottom prices. But if you’re looking for quality, do you shop at WalMart? Of course not! Quality costs money. That applies just as much to the hosting world as it does to retail. Do you see WalMart complaining that Gucci won’t make discount handbags for them?

Comment by James — January 16, 2008 #
44

As an outsider to the whole Rails thing, I have to say that incidents like this leave the vocal Rails people looking like real arseholes, and the original complainants more sympathetic. It just seems like the Rails culture is incredibly bad at handling criticism, even when constructive.

James: Hush now. This vituperative crap is just hurting your own cause.

Comment by jussive — January 17, 2008 #
45

@jussive

As a self described “outsider to the whole Rails thing”, you’ve obviously failed to see that the criticism wasn’t constructive. It was just a way for Dreamhost to _attempt_ to cover their own asses after taking quite a bit of heat in the blogosphere for horrible Rails support. This attempt included insults at both Rails, as well as the developer community. The very same community who attempted to help them. What did Dreamhost do? Ridiculed their proposed solution. There is no ’cause’ here jussive, just right and wrong. What Dreamhost did was wrong.

What I don’t understand is why people like you are defending them? If you believe that a host who charges $5 a month is a quality host, then you need to re-evaluate your deductive reasoning skills.

Comment by James — January 17, 2008 #
46

James: What you seem to be missing — a problem endemic among computer geeks, in fact — is the awareness that people form a poor opinion of you when you flame and act rude, even when you’re right. I cannot emphasize that last part enough; right or wrong doesn’t matter here. Is Rails too hard to set up and administer, or is Dreamhost just being whiny? I don’t know; it’s not my area of expertise. But I do know that incidents like this (and they don’t seem to be uncommon, sadly) where Rails supporters act like tools have really put me off the whole Rails thing.

You would do much more for the Rails community by learning when not to speak.

Comment by jussive — January 18, 2008 #
47

@jussive

Geeks just don’t have time for ignorance and misinformation. If someone is posting information that is false or misleading, we will call them on it. If that’s rude, then so be it.

You said:

“Is Rails too hard to set up and administer, or is Dreamhost just being whiny? I don’t know; it’s not my area of expertise.”

Well it is “our” area of expertise, and that is why the Rails community gets angry when people who do not know what they’re talking about spread false and purposely misleading information.

If you base your decisions on how rude you think the developers are, then you will be missing out on a lot of great stuff. A lot of people think Richard Stallman is pretty rude, but they still use the GNU tools. Developers are passionate about their tools, and thus are going to have emotional responses when clueless people try and spread false information, or when companies try and pass the buck because they don’t want to put in the time and effort.

As well, I find it funny that you’re accusing me of being rude, when the original post by Dallas was _full_ of unneeded insults at Rails and the developers. Why do you think there was such a backlash against it? The Rails community’s response to Dallas’ original post, is for the same reason you don’t like my posts.

Comment by James — January 18, 2008 #

Rails Is as Rails Does

DIY

Bride of PHP?

Programmers are Lazy

47 Comments »

Leave a comment

Categories:

Archives:

Meta:

Rails Is as Rails Does

DIY

Bride of PHP?

Programmers are Lazy

47 Comments »

Leave a comment

Categories:

Archives:

Other Sites

Meta: