Posted by kev
Wed, 23 Apr 2008 16:19:00 GMT
With apologies to Gruber.
Original text from TechCrunch.
It doesn’t really matter if Twitter’s Chief Architect Blaine Cook was fired
or resigned. The important thing is that he’s gone now, and this gives
Twitter the opportunity to hire someone (or a team) who may actually be able
to scale the nearly two year old service and keep it live.
I haven’t done any research or spoken to anyone about it, so don’t ask, but I have found a scapegoat.
Cook was directly responsible for scaling Twitter, and he very much failed
in his job.
Twitter is down sometimes, and I’m angry about it.
A year ago he spoke at the Silicon Valley Ruby Conference about scaling
Rails applications. His presentation suggested Twitter’s problems were
behind them, but in fact some of their biggest stumbles hadn’t occurred yet.
Note in particular slide 9 of that presentation, where Cook says about
scaling Rails apps like Twitter: “It’s Easy. Really.”
I found a posted slide from a public conference during my “investigative reporting phase. Oh, and Twitter is on Rails, and I can blame Rails. It’s Easy. Really.
Whether Twitter’s woes were all on Cook’s shoulders or not, he should not
have been boasting about solving the problem last year.
I’m high as a kite.
Meanwhile, Twitter has made at least three key hires this year on the
technical side. Lee Mighdoll joined as VP Engineering and Operations in
January. And this week they hired two scaling experts - John Kalucki and
Steve Jenson (”known for his work scaling Blogger and Blogspot”).
And they hired someone, yada yada yada, sprinkle random facts in so nobody notices my complete incompetence. Perfect!
Posted in Op-Ed | 4 comments
Posted by kev
Sun, 15 Apr 2007 20:13:00 GMT
An interview by a twitter developer has gotten a good deal of press lately. For many, it has reawakened the giant that is the “does Rails scale” debate, and others feel compelled to defend the framework.
The problem with Rails isn’t that Ruby is slow. It’s also not that Rails is slow, or big, or bloated, or doesn’t scale. The problem isn’t that Rails doesn’t support multiple databases or composite keys out of the box. The problem is that this is how the vocal minority in the community tends to respond to criticism.
So let’s all slow down and take a look at how we got here and what we can do to avoid it. That’s of course assuming we want to. Inflammatory posts certainly get lots of traffic, but I think Rails is in the spotlight enough we can actually talk like reasonable people and still get things done.
More after the jump.
Read more...
Posted in Rails, Op-Ed, Musings | 29 comments
Posted by kev
Wed, 06 Sep 2006 10:04:00 GMT
Recently Tim Bray posted a list of things he has found that Ruby needs. One of these things is an IDE and he provides a list of useful things one would do for us. I’m not sure if Tim has tried TextMate, but if you’re aware of the right features it turns out to almost be exactly what he’s looking for. The remaining features might be implemented by the right group out in the Lazy Web (do these things and we’ll all be grateful). Anyway, here’s interesting things you may have missed about TextMate in the context of Tim’s wish for an IDE.
Read more...
Posted in Op-Ed, Ruby, sightings | 14 comments
Posted by kev
Thu, 31 Aug 2006 01:25:00 GMT
So, I seem to have inadvertently caused a significant amount of controversy with this morning’s article on what I don’t think you should be doing in Rails. Some rather harsh words have been exchanged. It’s time for us all to take a breath, count to ten, and remember we’re all just coders working together to make Rails (and Ruby) better.
Matz is nice, so we should be nice.
With that as a preface I’d like to explain some of the things I said which caused a stir. Hopefully this will clarify and you can stop thinking of me as some pre-pubescent FUDdy jerk if indeed that’s where you stand.
I thought I was giving you a list of things that you should avoid in modern versions of Rails. I didn’t get anything back differently from my reviewers. You should know that for bigger articles like this I always have a group of people take a look see first and give me feedback. These are people that I respect and may be better at writing and programming than I am (and often are). I wait to get OKs from that group before I post.
I think this group of lines may have been my downfall.
See? A halt! Sufficiently frightened? You should be.
Now, stop using these things. It’s for your own good.
I rather regret this. In my head it was tongue-in-cheek. My reviewers didn’t even mention it though I imagine they knew I was joking since they know me personally. Others apparently didn’t. What I meant to say was that I hope the list would coerce you into improving your code. That message got lost somewhere along the line and I feel like we’ve played a rather large game of telephone. I’m sorry for that.
Pagination seems to be the issue we pulled apart today so let’s talk about that for a few minutes. I said some things about pagination that, after returning to them, seem a bit cryptic. Sorry about that. Let me clarify: the built in pagination helpers are a hackish pain. They’re hard to work with and have some efficiency issues. As a result, working with very large data sets can cause it problems. Don’t be afraid, just be aware. With large data sets you’ll want to roll your own. The Paginator object itself isn’t so bad (though we really should clean it up) and I prefer to use custom pagination with it over the helpers.
That being said, we’ve talked about pulling out the Rails pagination helpers into a plugin for a while. I imagine they were brought up when I passed the article around was for that reason. It isn’t deprecated yet, but it probably will be.
Now, if you have other concerns please bring them up here.
Update: A friend has noted that one of the problems may be that some look at me as a voice of the core. Let me be clear: I’m not in core. I don’t speak for core. I speak for myself based on my knowledge and opinions. When I say, “we’ve talked about it” I mean “I’ve talked with developers working with the core in and outside the core team and the consensus seems to be that pagination will come out”. BUT, I’m still not David and not the core.
Posted in Rails, Op-Ed, Musings | 29 comments
Posted by kev
Mon, 07 Aug 2006 18:24:00 GMT
I hate fixtures in Rails. Sometimes I hate them because they slow down my tests. Most often I hate Rails fixtures because they make my tests brittle. Everyone that uses fixtures has had that moment where they add another bit to their fixture file for that new test and suddenly things are breaking all over the place. It’s ugly and arguably a broken system.
I think we can fix it. I’ve had several long discussions about this and most of what I’m going to preach here isn’t original. That being said, I think this might work so pay attention and tell me what you think.
Fixtures suck because it’s all or nothing. You can either grab all of your user data or not have any of it. It does cut down on duplication because you’re not redefining data for every set of tests. However, having all the extra stuff in the scope of your test is unnecessary and leads to brittle tests.
One option is to compromise. We could modify the current fixtures method to accept syntax like fixtures :users => [:alice, :bob], :articles => :ruby. This would allow you to get only the data you need. At the same time, the old syntax could be backwards compatible and you could grab all of the data if you wanted to. I generally find that when I’m writing tests it’s only with one or two pieces of data. With Rails, everything else in the database is just hanging out.
The downside to this new syntax is that the current way of structuring test cases would make this ugly. You don’t want to define fixtures for every individual test. It’s much easier defining fixtures by test case. Here’s where the BDD folks got it right. Test cases should really be broken up by what context they’re being run in. We shouldn’t have one test case for the model. We should have several test cases with tests divided by what data we’re working with. We get smaller and more granular sets of tests this way. It’s the testing version of DHH’s “everything is REST”. Every test is about context.
Do remember that more test files don’t mean more work. We’re already generating empty integration tests. What’s one or two more generators? Really, it’ll be easy. You’ll like it.
The other option is to throw off fixtures completely. I know of people who have already taken this step and they solve the fixture problem by writing helpers to create the data in code and then run them in setup. This seems like a viable option as well and would require no changes to Rails core.
It’s time to admit that fixtures, as implemented in Rails, are broken and ugly. We’ve been taught to demand beauty and elegance. Let’s make something better.
Posted in Rails, Op-Ed, testing | 11 comments
Posted by kev
Mon, 05 Jun 2006 06:43:00 GMT
This week’s guide is going to be a little different.
On the rails-core mailing list, in what started as a discussion the issue of the growing number of Scriptaculous/Prototype tickets and especially enhancement requests, we’ve begun talking about the removal of the “enhancement” category on trac tickets.
The problem is that generally half or more of the tickets that come through the Rails bug tracking system are enhancement requests. With 13 people able to commit and a handful of others actively dealing with tickets being reported, enhancement requests will in general never be acted on. This means there are new tickets every day ruining that delicate signal vs noise ratio.
For a while the standard line for enhancements has been “make it a plugin and see where it goes”. This may not always be the proper response but when dealing with the deluge it is at the very least the easiest and a plugin is usually the simplest way to see feature X in Rails.
So here’s the guide part: we could use an alternate viewpoint. The rails-core list is significantly biased: people who care to speak up there are comfortable writing patches and plugins. I expect a good portion of you watching my feed and visiting my blog haven’t written patches for Rails and haven’t written your own plugin. Do you think keeping the enhancement category is worthwhile?
The real question here isn’t whether Rails should accept new features. Patches for new enhancements would be considered but enhancement tickets sans a patch would not.
I’d like to make this an open dialog. Please, speak your mind. And careful with that submit button. Apparently my comments are a bit wonky and it tends to result in double posting. I’ll try to fix it as soon as I can.
Next week we’ll return to our regularly scheduled practical guides.
Posted in Rails, Op-Ed, guides | 15 comments
Posted by kev
Wed, 24 May 2006 01:30:00 GMT
I’ve been in the Measure Map alpha since November and I’m a big fan of the application, but one of the things that really helped me get enthusiastic about the operation was the small shop feel.
I first really encountered the personality that I began to associate with the Measure Map team when I asked about blogging my experiences. I recieved a quick and personal reply:
Hi Kevin,
We’re glad you’re enjoying Measure Map so far.
Absolutely, feel free to write about it, post
screenshots, etc. – but we do just ask you to
keep in mind that the product is in early alpha
and that we’ll be adding a ton of
improvements/features soon.
Would you send us a link to your review?
We’d love to read it. And thanks for helping
us out by trying Measure Map during this alpha
stage!
Greg
Contrast that with the reply I got yesterday about some problems with page loads:
Hello Kevin,
Thank you for your email and the heads-up
concerning the pages failing to
load. This is a known bug we are working on
getting resolved. We hope to
roll-out fixes for a few known problems in the
near future. Thank you
again for helping us continue to test our alpha
product. Please do
continue to send feedback.
Sincerely,
Measure Map Support
To share your knowledge or learn from other
Measure Map users, please
visit the Measure Map Forum at:
http://groups.google.com/group/measuremap-forums?lnk=li
Notice the change in tone? No name, only “Measure Map Support”.
I understand that when projects are part of a big company, the company face is the one that is shown to the world, but when a small project is aquired should its personality be sacrificed?
If you have any, I’d like to hear stories about companies or projects that survived being aquired or post mortems if you have them.
Comments are open.
Update
It’s important to note that I did receive an instant message from Nick Seckar of the team about my email. This post, however, is really about the “official” face of Measure Map and how it is shown through support.
Posted in Op-Ed | no comments
