Apparently one commenter found my April Fools article “ham-handed.”
ham-hand⋅ed
clumsy, inept, or heavy-handed: a ham-handed approach to dealing with people that hurts a lot of feelings.
I’m sorry that some people didn’t realize that an article was meant to show off someone else’s April Fool’s prank. I guess the snippets of code showing the joke, putting it in the “humor” category, and adding the words “april phails phools” to the URL just wasn’t enough for some people 🙁
Next time, in order to prevent hurt feelings, I’ll be sure splay across the top the words: “Look, Phails is an April Fools Joke, Please don’t take it seriously (pretty please?)” in 42-point Charcoal typeface.
…
On second thought, why bother? 37Signals has me beat in the tact and sensitivity department. Notice how they introduce Ruby on Rails as…
(And when I replied that this was madness, he kicked me into some CAT-5 ethernet cabling with the words, “THIS IS SPARTA!!!”)
(I heard that Web development is so hard that Rasmus had John Yoo write up a torture memo lest any Guantamano detainees put up a website between waterboarding sessions.)
Thank God, that I learned Ruby on Rails so I no longer have to deal with the pain of writing a SQL select.
I originally titled this article, “Apparently, Rails developers hate our freedoms” but I opted for this title so as not to appear “ham-handed.”
Er, I’m a PHP developer and I was noting that the joke was lame. Way to overreact.
Each to their own, I guess. I found it pretty funny.
Funny…!
Thought it was funny as well.
Why does everyone freak out about writing SQL themselves, anyway? Isn’t it a good thing to understand the intricacies of the software you write on?
*sigh*
This only re-inforces the stupidity found in the PHP community. All of your attempts at humor are one-sided. You have never been able to make a case as to *why* – you are just really passionate about your spaghetti code.
In your continual attempt to be the funny guy at the grade school lunch table, you even blast out another PHP developer. Your arguments are so blind. Maybe, at some point, you could actually make a case as to why you believe what you believe (but I supposed it’s easier just to poke other people and get your posse behind you to laugh at your super-funny screenshots). So, it’s obvious you won’t stop being *that guy* – but could you at least back it up with something else besides your crazy photoshop skills?
This is coming from someone who has to help clients on a daily basis get out of really crappy PHP code that someone wrote and over-charged them for in the beginning. It’s a low barrier to entry (I guess it explains why you have a job, though).
I know your response will be another poke, jab, and attempt at humor – I’m just curious if you could ever bring an educated response to the table.
@Wilfried
Who was freaking out about writing SQL? I don’t even know how that was injected into this conversation. If you *think* that’s the purpose of a framework, you may want to research a little more. I’m interested in finding Terry’s better solution. Is it to re-do the same thing every time? Is it to create one big massive library? Is it to break things up into re-usable chunks of code? Er…um…nope, that can’t be it – because then it would appear to be the beginnings of a Framework.
Knowledge and efficiency. Work smarter not harder.
@Wilfried
I missed his last line about SQL – so I apologize for that. However, after re-reading it, it’s still a ridiculous assertion. Really? Frameworks are about abstracting SQL? Is that really what gets you so upset?
Ignorance is bliss.
@Nate Clearly you are the final arbiter of humor so we shall all bow and nobody has to read the rest of this comment.
It seems that humor is a nice way of defusing egotistical assholes who imply that web development “hurts”—and so you need to use their framework like some magic fairy dust which will solve all your problems.
The reality is, Rails is a framework. There is no magic other than convention over configuration. Frameworks have advantages but the same advantages it gives you are weaknesses (as is often the case with every choice). The advantage is that a lot of code has been written for you, the disadvatage is that they’ve written code for you.
There is nothing magic about “convention over configuration” and there is nothing magic about the Active Record pattern. There is certainly A LOT of bad things about that pattern when the website scales. Why do you think Twitter crashes or 37Signals solution to “database scaling” is to buy a bigger machine and wait for Moore’s Law. I’m sorry, it’s not just me who sees the absurdity of this! I’m not the one lecturing people who actually have had to deal with scalable web problems about scalability. I’m not the one lecturing people who’ve written books on MySQL performance about performance.
If anyone is flinging food at adults from a grade school lunch table, it isn’t me.
I may have an ego but I’m not an asshole. A very important distinction I’ve made many times. My diatribes hurt no-one and are rife with interesting points which you overlook. I don’t advocate really bad ideas for Web 2.0 companies nor calling out pitchforks and endangering entire companies simply because I dislike their business model.
In the real world, these are serious transgressions because you’re annihilating entire businesses to salve a “grade school” ego here.
In many ways, even though I’ve teased 37signals, I am honest about their modest success. I am a big advocate of frameworks like Rails in enterprise web development and academic sites—the former representing a spending market share much larger than the consumer facing web that PHP dominates. But apparently that’s not nice enough and I have to kiss the ass of an asshole who says, “Fuck you” to me at the end of every talk he gives?
Ask yourself, what if the tables were reversed and they were the website that served 250 million pages per day, the 75th most traffic’d website on the internet, and having the busiest social network in the world using my language, and I’m the piddly little site ranked in the 60,000th busiest with sites that have scaled using my framework finally giving up and adopting Java?
Do you honestly believe a guy whose finishes his conference talks, “If you don’t agree with me, I only have two words for you…” and then shows his last slide with the words “FUCK YOU.” would be better than me?
I’m sorry, personally I’d rather have the self-effacing humor of imagining a world where web development as 300, than a world where someone’s answer to honest criticism is “FUCK YOU” as he high-fives people like you who go onto other people’s blogs and make snide comments on why I don’t honor him as the web world’s Lord and Savior.
The sad fact is if they actually had a website they could point to, they’d be crowing about it. In fact, I’ve suffered worse and nastier ad hominem attacks (and continual string of anonymous nasty comments on this blog that get moderated) even though none of these people put out their numbers. I post my numbers freely as well as point out honest mistakes. I also point out that Google is not using PHP and neither is MySpace (mostly Java and dotNet respectively). I’ve emphasized that their existence and the existence of a host of others show that PHP isn’t the only solution, let alone a panacea.
I’m sorry your clients write really crappy PHP code. I really am. But people write Really Crappy Ruby code and Really Crappy Rails code also. Really Crappyness isn’t language-dependent—just ask Twitter. I admitted, long before you, the ugliness and weaknesses of PHP. In fact I coined the phrase “PHP is a ball of nails.” I postulated the concept of PHP design attracts poor security development. Almost everything I wrote in defense of PHP shows that PHP gathers its strength from working WITH software that solves the “hard stuff” while PHP only solves the relatively simple “web problem.”
Would that others admit their limits as easily as I have.
Maybe then they’d be the architect of a top 3 social network.
I may have “super funny screenshots,” but reread your comments and reread my post. Who has resorted to ad hominem? Because I haven’t seen much content in yours. No, frameworks aren’t about abstracting SQL, but one framework makes a certain abstraction of SQL it’s centerpiece. If the abstraction wasn’t a bad solution for the problem in the area it’s being advocated, nobody would have issue. Change the area (enterprise instead of consumer facing web), change the problem (the need for scalability) change the solution (Database Access instead of Data Abstraction), change it at the centerpiece (allow configuration)—change any one thing in the claim, nobody would take issue.
I’d hate to make an appeal to authority, but please find any one of the top 1000 engineers in this field (consumer facing scalable web) at Yahoo, Google, Facebook, MySpace, Twitter, Tagged, etc. (and no, DHH isn’t one of them) who will defend all of the following claims:
1) Rails is a framework
2) The Rails Framework uses the Active Record model for persistence
3) Rails stresses Convention over Configuration
4) Active Record cannot horizonally scale the database without some sort reconfiguration
5) Horizontally scaling the database is absolutely NOT a premature optimization in the consumer-facing, viral-growth-based web world.
6) Rails is heavily marketed as the solution to your problems in the this consumer-facing, viral-growth-based web world.
7) That the combination of 1-6 doesn’t make it impossible to scale using Rails but it does make it unnecessarily challenging. (You are free to disagree with this conclusion).
Two years ago, when I made this argument, the defense was the framework was new and PHP is a language and much more mature.
It’s been two years. In that time, Tagged has gotten nearly all of it’s growth (to 90 million users and almost 7 billion pages/month). Twitter has jumped to even bigger than Tagged. I’d say there is ample opportunity for the six point things to adequately be defended by some hot shot programmer—a Ruby on Rails Cal Henderson (Flickr) if you will.
Two years ago, I was only postulating.
Today it isn’t a postulate anymore, it’s a theory.
Now the burden is on you to prove me wrong.
Good luck! I really honestly am supportive of it. I learn the most when I’m wrong, not when I’m proven uncannily prescient.
I guess that if you want to make an argument about Twitter you should at least check your facts before, or as usual you will end up beating the wrong guy. Oh you just did it, and I’m not surprised at all 🙂
The problem with Twitter is not Active Record at all (and honestly I don’t know where you read this, nobody ever said something like this), the problem was:
1) They implemented a message queue service in Ruby
2) Performance of this message queue sucked
3) They reimplemented everything using Scala
4) Twitter had again some downtimes. Unfortunately we’re not mean enough to start pointing our fingers at Scala.
As usual, everyone who comes up with the good old joke of a technology that scales or doesn’t, doesn’t seem to figure out even the basics. In the past, I can remember some technologies that didn’t “scale”: python, Linux, MySQL, Java.
You can also check out the fact that Twitter admittedly tried to implement something like a static typing system in Ruby, and think about what would you say to a developer that does the same in PHP (other than asking “why the hell you didn’t use a language with a static typing system” of course).
Oh, FYI, you can scale the DB horizontally with Rails, but I live in the hope that you will once check your facts before writing crap on your blog, I will leave you with the suggestion to search google before. It kind of works, even if it’s implemented in Python for a good part.
Another suggestion, after I will go to use my time in a more productive way.
The “FUCK YOU” thing doesn’t work anymore, you probably don’t know about that (you pretend to talk about Rails, but of course you don’t know a flying fuck about that), but DHH agreed with the Merb people to merge the 2 frameworks.
What does this mean ? That actually his opinions are going to be “patched” in good part by the Merb team. We will be able to switch between ORMs (FUCK YOU ActiveRecord), a stable API for plugin developers, something similar to the old components we had with Rails 1.0 (without the part where they are slow as hell). In a few words, they learned by their mistakes. I’m no DHH fan, granted, I kind of like to use his shit, but a thing must be said: after the initial hype part, he calmed down a lot.
For next rants you can address real problems in Rails instead of stuff you make up. Some suggestions:
1) Thread safety
2) Plugins that overwrite the core classes – this one is ridiculous IMHO
3) 4 years for a cheap deployment on Apache – your mod_php
4) 1.8.6 incompatible with 1.8.7 and 1.9
Maybe you will have answers from someone in Ruby community – I come here because I find your posts funny, and not always in a way you would like.
Please, no “you don’t know who Terry Chay is” like last time, I don’t fucking care, and it’s a lame argument.
Oh, and just to put some facts straight before you start with your usual Alexa dance, not everyone live in the hope of registering to yet another ego based social network like Facebook or Tagged.
Most of my traffic, for example, comes from white label sites we have around on our clients sites (json/xml API). This is particularly fun, because I’m in the hands of ‘developers’ (guess what language they normally use) that query the application for every single thing, and being customers I can’t set a limit like Twitter does. I don’t like PHP, but for sure I’m not going to point my fingers to the language when it’s obvious that the problem is the developers using it, but this is another story.
Happens, expecially when your business model is not about flash banners or xxx (put Twitter business model here).
And before you ask, for some things I will kill Rails without any problem (but I would say Ruby here) for more specific and performing technologies. Erlang probably. Or Haskell.
@ngw: First of all:
1) All languages scale (even Ruby).
2) Scalability is a property of the program/framework.
3) Since frameworks are built on top of a language, all frameworks can be made to scale.
4) There are different types of scalability
5) There is also the issue of performance which isn’t the same as scalability.
6) There are a lot of problems (in fact the majority out there) where scalability isn’t an issue.
As for your specific example about using Merb to solve the partitioning problem. When I installed Ruby on Rails in my notebook three years ago, I benchmarked it at handle 3 transactions/second. On the same hardware, even CakePHP handles about 15 tps, an average PHP framework around 100tps, a dummy PHP script around 200tps, and a static HTML call 300 or more (it’s Apache, so you could do way more with IIS or thttpd or lighty). Now if I work at it and install something like Mongrel, patch this and that, I could get Rails to go on par with an average PHP framework.
So what? Of course it can! It’s built on a language and all languages scale.
Also note that my example was mostly a performance issue, not a scalability one. While languages limit performance, PHP in Apache isn’t exactly the highest performance bar to set.
Alexa Dance??? You mean where I use Alexa to point out that Twitter is a bigger site than Tagged? I use Alexa specifically because the data is public and easily accessible. You can looked up the traffic according to HitWise, Nielsen NetRatings, and Compete. I also give the actual numbers directly so that people don’t think I’m hiding behind Alexa—they are 80 million registered users, 240 million pages (top banner add impressions)/day, and I can look up the number of API transactions we do, but let’s say It’s a lot. I also give a valid e-mail and link my homepage when commenting on other people’s website. I don’t like hiding behind anything because that sort of dishonesty comes back to haunt you.
Besides when I’m wrong (and I’m wrong often), I want to learn about the mistake quickly, that’s when I learn the most.
The use of that statistic is not not an “in your face” thing. I think that web frameworks can do a great job in areas where scalability isn’t a priority—such as Enterprise. I’ve brought this up a number of times and emphasize that “Enterprise” as a whole is a much larger than “Web 2.0” in market size—it also pays better.
Instead, I bring up traffic and scalability specifically because that area is “my house” (my area of expertise), and I’m demanding a certain level of experience when shit talking me in that house. Doing otherwise is going a bit too far. I don’t go telling an enterprise that they shouldn’t be using an ORM because migration is a pain. I don’t go telling a shrink wrap web-software vendor that they shouldn’t use a data abstraction or database abstraction because database portability should not mean database independence if it costs you database performance.
In the consumer-facing web scalability world, both ORMs and database independence are potential deal killers. In the enterprise world or the shrink wrap vendor, an ORM or database independence is a potential deal starter.
…
I don’t say Twitter’s only problem was with Active Record. I do say the first issue I have with Ruby on Rails as a framework for a Web 2.0 startup built on virality is that the ActiveRecord pattern abstracts you from the traditional performance bottleneck on the consumer facing web (the database).
Please note all those qualifiers.
Twitter had a number of issues: a serial message queue that fails was one, and Active Record was another, I’m sure there are many issues. In the end nobody cares until they notice it. Maybe it means they don’t get an update that they should have, or maybe it means they still get updates from people they’ve unfriended, or maybe it means they have to stare at a Fail Whale. They’re a lot better now with a Scala message queue (and their recent growth reflects that), but I still got a Fail Whale just before the last time I twittered yesterday.
Instead, I ask myself, how would I implement a message queue in PHP? The answer is, I wouldn’t. PHP isn’t even thread-safe and building one in that language would be a pain. Of course, forking, multiple apache children, or just handling the queue serially are all solutions that possible in PHP, but I wouldn’t attempt it when there are other languages out there that would solve the queuing problem far more readily: Erlang, Python, or even Java. (I’ll add here that Facebook decided to roll their own chat system, and what did this PHP company decide to use to solve their message queue problem? Hint: it wasn’t PHP.)
The same could be said with Active Record. You can (and many have) made it shard, but why bother baking the ActiveRecord pattern into a framework if your site is viral? Especially when there exist a whole range of sharding strategies?
As for advantages of PHP over Ruby. I’ve already previously mentioned: the existence of leveraging Apache vs. rolling your own (like Mongrel), the ubiquity of PHP installations on hosted environments, and the fact that the LAMP solution is also easier to maintain on a shared hosting environment. (I haven’t noted yet the last advantage is starting to diminish because of cloud computing.)
As for “You don’t know who Terry Chay is” When have I ever made that argument? That sort of argument is a horrible reverse ad-hominem. The only time I mention my name is in a self-effacing manner. I don’t expect anyone to know me (why would I?), even in the PHP world. I would rather people consider and deal with what I say than who is saying it.
Take care,
terry
That argument wasn’t made by you, but by one of your readers, on the dog/dogfood post.
ActiveRecord is a pattern, implemented by ActiveRecord the ORM. If you say that the ORM can’t scale you are wrong, it can scale horizontally. The problem here is that the implementation IMVHO has always been suboptimal, because the way of doing of AR deveopers is to (of course in my opinion) implement the coolest and most useful feature first, refactor in a scalable way last. Examples ? I have a truckload. I can’t use :select => fields when I use :include => tables. I can’t select specific fields when I join 2 tables. Why ? Too difficult to implement ? This would already be terrible at the DB side, just think at our wonderful 70s mark and sweep GC, if you loop through a large dataset you are screwed, say hello to your RAM. But hey, we have named routes …
This is the problem, not using or not an ORM. Zope uses an OODB written 90% in Python and I wrote huge things without having a single scalability/performance problem (stuff for banks), it can’t be that a damn layer is so hard to scale.
Just take DataMapper, it uses the DB as much as it can, it has lazy loading and identity maps. Not even mentioning that you at least should cache as much as you can – Facebook for example cache 90% of it’s content.
In any case, for the kind of scaling are we talking about, is the ORM or direct access to the DB the issue ? Are we sure that we want an RDBMS at all ? Why Twitter used an RDBMS ? (hopefully the answer here is not “vodka”) What’s the point of using a DB when the first thing you will do when scaling the whole thing is denormalize it ?
I see for example Amazon’s architecture, they use an RDBMS just for storage, but for querying they are actually using distributed hashes and hundreds of web services.
You really think they query the DB directly ? That having a common access to writing and reading data is not a huge improvement in productivity, and feasable at the app layer ? Maybe I can just take an ActiveRecord::Base subclass (if AR was made for this, DM for example permits this stuff) and implement a REST service to be queried exactly as I query tables, and for example takes care of caching at the superclass level. I can use both MySQL and CouchDB that way, for example.
Using an ORM is not just a matter of database independency. If you have just MySQL everything will do, you can optimize every single query, if you have more than one backend you are going to need an abstraction, because it’s true that the application need to perform and scale well, but it’s also true that you will need to use the right tool for the job, and this normally means using a lot of tools together and also try to not make new hires kill themselves because the data access layer is completely inconsistent.