ryan / Tue, 05 Dec 2006 15:33:59 GMT
Tags advertising, buzzwords, enterprise, marketing, revolutionary | 4 comments
In some of our marketing materials, I used to refer to Lovetastic.com as “revolutionary” service. I’d call it the “revolutionary gay social network” and such. Of course, I believe that the term applies. We are trying to change the discourse in this area of online personals—to do something totally different that shifts the paradigm away from hook-ups and towards love and substantive communication. Our community is marked by a gently subversive (and explicit) philosophy that transcends the product itself and is instead about a broader culture and movement, so the revolutionary concept felt right.
But with all the focus these days on Purple Cows and Long Tails, everybody wants to be revolutionary. I started reading and hearing ads all over the place describing things from phone service to game consoles as “revolutionary.” It’s become a marketing cliche to mean that one’s product is incrementally different from its competitors, which of course is neither all that surprising nor interesting—and certainly not revolutionary. I grew to be immediately skeptical whenever I heard it in an ad myself. So I stopped using it.
The usurpation of a perfectly good English word to turn it into hyperbolic marketing-speak is a shame. I’ve got nothing against passion and a bit of well-intentioned hyperbole in marketing where it’s due, but when several huge corporations start having words like “revolutionary” applied to their products in national TV campaigns by ad agencies they’ve hired, the term sort of, well, loses its authenticity and indie subversiveness.
======
As a post script, it’s worth noting that there is an enterprise-speak correlate for “revolutionary.” Large corporations like to use the term “disruptive technologies” to mean “products that don’t suck and might therefore might put us out of business.”
ryan / Mon, 04 Dec 2006 21:21:09 GMT
Tags ajax, chat, comet, lighttpd | 7 comments
There is a lot of bullshit buzz-speak about “COMET” floating about the internet these days. As best as I can tell, Comet is not an acronym for anything, but rather a play on the term “Ajax” (a related browser communication technique that, like Comet, shares its name with an abrasive cleaner.)
Though it seems that everything written on the subject of Comet is impossibly opaque, the concept is pretty damn simple. Comet is a way around the fact that HTTP is a stateless protocol (i.e., browsers request things, servers serve those things, and then the connection between the two immediately dies.) In order to get new information, browsers have to make requests. Heretofore, this has required applications that need to get frequently updated information to force the browser to “poll” the server at regular intervals to see if new information is available. There was no way for the server to let clients (browsers in this case) know that the new information was available as soon as it became available. Instead, the server had to wait for one of these polling requests to come in again.
This kind of problem is specialized, but important. The utility of being able to “push” data to clients as it becomes available is obvious for live chat, stock tickers, and election results, to name a few examples.
Now, thankfully computers are pretty fast these days, so the polling approach can scale quite nicely; to wit, Campfire, a live web-based chat application produced by our illustrious heros over at 37signals. Campfire does a fine business on a profit-per-request basis, thank you very much. But it does require throwing on some good equipment to support heavy user loads, and more seriously, it still suffers from an annoying lag between when a user types something and when it shows up in the chat window.
When we wrote our live chat application at Lovetastic.com, we chose one precarious solution to the problem to make latency a bit lower. We used Adobe Flash, which exists in most browsers but doesn’t suffer from the same need to communicate only via HTTP. That is, Flash can open stateful sockets with a server and keep the communication flowing both ways. Two problems with this: a) Flash is proprietary and stupid, and b) it requires us to home-brew our own buggy chat server in Python—Ruby’s network programming isn’t so hot. We’re web application programmers and we shouldn’t have to be solving these basic network programming challenges, reinventing the wheel just to get our own low-latency chat. Passing text to clients should be a simple problem, and we don’t see why we should be solving it as “end-user application developers” if you’ll pardon a silly turn of phrase.
Comet has been a long-developing alternative to this Flash approach. Comet, like Ajax, uses features built into Javascript, which is a non-proprietary technology available in nearly all browsers. It uses a little trick built into Javascript to persuade the browser to keep the connection alive as long as possible. In a sense, it’s a bit of a conceptual hack, but I’ve seen it work very well in the case of Lingr, for example. It solves the problem. One might say Ajax itself is a hack too, so whatev.
Trouble is, the writing on Comet available on the internet up until very recently has been scarce at best and absurdly obscurantist at its worst. At the time we set out to create our live chat software, we couldn’t plow through the jargon-laden manifestos to get any practical information out of them. Equally, we weren’t keen on the prospect of having to code either Perl or Java in order to use some of the early comet servers being built.
But fortunately, now it looks like COMET is going to become a whole lot easier to do. This time its thanks to Jan Kneschke, the creator of the webserver lighttpd (which made YouTube possible), with whom we discussed this very prospect at this year’s RailsConf.
Jan has a post over on the lighttpd blog about “mod_mailbox,” which is what he envisions lighttpd’s implementation of COMET to be.
The basic idea is that lighttpd will handle the connections required for COMET, completely decoupling the connection handling from the backend server that handles the logic. So, we’ll be able to write COMET applications that pickup and dropoff messages from the user “mailboxes,” without having to write any of the connection handling that is so hard to do with COMET apps. Also, if he uses the COMET protocol Bayeux, we’ll get the javascript end of the connection handling for free as well.
This will be a huge turning point for COMET… the point at which a developer can code a COMET app without building everything from scratch, a task that is not feasible for most (and was a prospect we certainly didn’t relish ourselves.)
As soon as Jan makes a version available, you can look to Lovetastic.com to be its test-bed.
ryan / Fri, 17 Nov 2006 23:05:19 GMT
1 comment
If you’re interested in interning with a Rails-based web start up and are supportive of the socially-progressive philosophy/mission of Lovetastic, find out more here.
ryan / Thu, 09 Nov 2006 20:32:25 GMT
no comments
When the professor asked us to align our chairs in a circle in college, that was always an unambiguous signal that no learning was going to take place for the rest of the class.
Equally, when it is asserted that something is worth doing because it enhances “hand-eye coordination” or “leadership skills,” that is an official admission that one’s time is about to be completely wasted.
Apropos of nothing. Just thought I’d vent.
ryan / Wed, 08 Nov 2006 19:14:59 GMT
2 comments
Here are the latest stats from Lovetastic.
PS: We like our customers. :)
jd / Thu, 02 Nov 2006 18:41:19 GMT
Tags nginx, rails, ssl | 7 comments
This article has moved over to our sister spin-off blog, RubyJudo, which focuses on more arcane technical topics than NotRocketSurgery.
jd / Sat, 28 Oct 2006 06:27:33 GMT
Tags mysql, osx | 8 comments
This article has moved over to our sister spin-off blog, RubyJudo, which focuses on more arcane technical topics than NotRocketSurgery.
ryan / Fri, 06 Oct 2006 20:34:48 GMT
1 comment
Scene404.com. Written in PHP. 20,000+ lines of code.
Lovetastic.com. The Rails re-write. <2,000 lines of code.
ryan / Thu, 05 Oct 2006 20:06:23 GMT
Tags 37signals, gettingreal, launch, lovetastic | 6 comments
It’s been a long road since I attended the Getting Real workshop last winter and decided to completely tear down and redesign the site that would become Lovetastic.com.
I’m proud to announce that this week we launched Lovetastic with:
- Fewer features
- A simpler, cleaner interface
- Fewer requirements on sign up
- Requests for all information from users pushed to the last minute we need them
- A remarkably easy search page, which does the thinking for you
- An elegant, maintainable, and DRY Ruby on Rails back-end
- The judicious use of javascript and xhr to make data-entry more intuitive and less tedious
Many (if not all) of these ideas came directly from examples and ideas in the Getting Real workshop and book—and the great examples set by applications like Basecamp, Campfire, and Backpack.
I look forward to blogging in more specificity, now that the site is launched, on how we built the site.
In the mean time, to enjoy more of my 37signals fanboyism, listen to my interview on Leo Laporte’s Inside the Net podcast, in which I talk about the building of Lovetastic and all the ideas that I love to write about here at NotRocketSurgery.
ryan / Tue, 26 Sep 2006 19:05:53 GMT
Tags davethomas, pragdave, rails, railsconfeurope | 2 comments
Kyle Shank of RadRails fame (or infamy, depending where you stand) quotes Dave Thomas’s keynote at RailsConf Europe.
The question is not: is Rails ready for the Enterprise? The question is: is the Enterprise ready for Rails?
I was critical of Dave’s keynote at RailsConf in Chicago, which seemed (thematically at least) to be articulating the precisely opposite point.
I’ve subsequently learned that Dave was both misunderstood (by me and others) and perhaps mildly miscommunicated his original intention.
I’m so glad to see that Dave’s vision for Rails really does in fact coincide with where the greatest promise of the framework lies: as a proof-of-concept for how truly pragmatic it can be to worry first and foremost about programmer happiness.
A summary of Dave’s whole RailsConf Europe speech, which was rightly met with rousing applause and praise, can be read here.
Dave, as the fellow who effectively brough Ruby to the English-speaking world, is as responsible for Rails as anyone other than DHH. Do like I did: go see him at the pragmatic studio.
Subscribe