Tech, Ramblings, and Intellectual Detritus

My old friend Orkut sent me an email yesterday, the first in a long time . . .

Loading mentions Retweet

I actually googled this and found a workable but ugly solution:

 
 ## view code
<%= date_select('range', 'start_date', :order => [:month, :day, :year])%>


## controller code
@start_date = Date.civil(params[:range][:"start_date(1i)"].to_i,params[:range][:"start_date(2i)"].to_i,params[:range][:"start_date(3i)"].to_i) 

I needed to include the hour and minute as well, and didn't want to cram more arguments into the Date.civil call (actually Time.zone.local), so I cleaned up the code a bit.

Hoping to leave the internet a little better for the next guy, I thought I'd post the code.

 
 ## view code
<%= datetime_select('range_start', 'date', :order => [:month, :day, :year, :hour,:minute]) %>


# controller code
@start_date = Time.zone.local(*params[:range_start].sort.map(&:last).map(&:to_i)) 

Loading mentions Retweet

credit:  http://bigeyedeer.wordpress.com/2008/07/15/this-cartoon-wrote-a-sweary-word-o...

Loading mentions Retweet

I thought Happy Town had a decent chance of being entertaining: 

So with my expectations possibly set too high, Happy Town was fully disappointing - formulaic writing, overly produced, and all-around cheesy.  I want to know who to blame if it's too much like CSI.  It's unlikely I'll be back for a second episode, 20 minutes was more than enough.

 

Loading mentions Retweet

Flash? Really? Funny given that Pandora was featured in the f8 keynote.

Loading mentions Retweet

Facebook has decided to do away with notifications - the little messages notifying you of things friends did on platform applications, or giving you updates on applications you have installed:

The Dashboard

Getting Alpha and Beta Confused

XML isn't Supposed to be Pretty, but WTF?

Loading mentions Retweet

learning again that you get what you pay for

Groupon

For those that are unfamiliar, Groupon is a collective buying site, similar to Woot and BuyWithMe.  Borrowing from the Wikipedia entry:

The Groupon works as an assurance contract using ThePoint's platform: if a certain number of people sign up for the offer, then the deal becomes available to all;  if the predetermined minimum is not met, no one gets the deal that day. This reduces risk for retailers, who can treat the coupons as quantity discounts as well as sales tools. Groupon makes money by getting a cut of the deal from the retailers

Sounds great, right?  Retailers build sales by offering a one-time discount, contingent on quanitty, and consumers get a good deal on some product or service, with Groupon taking a little cut.

Well, as with anything with even trivial complexity, the devil is in the details. 

My Experience

I was overdue for a dental exam, and my insurance doesn't exactly have stellar dental coverage, and i happened to be checking out Groupon when the deal of the day was for $60 exam/cleaning/xrays at a San Francisco dental office.   

Great! Right?

I bought into the deal, and actually waited about a month before booking my appointment.  Well, before trying to book my appointment.  When I called the office, I was greated not by the receptionist, but by this pre-recorded message:

The following information applies only to our Groupon.com patients that have not yet scheduled with us but who have already called or emailed our office.  We are currently repsonding to Groupon.com user calls and emails in the order in which they were received.  If you have already called or emailed to schedule your Groupon.com appointment, we ask that you be patient and please not call or email us again.

That's when I decided to run the numbers, something I probably should have done beforehand:

• 585 Groupons issued 
• 10 new patients/week (estimate)
• 58 weeks before I get an appointment

Now I feel like an idiot, and simultaneously realize the brilliance of the Groupon model - they can make interest on the float of non-cashed groupons, which is huge for services that can't be consumed instantaneously.

I have to mention that a simple email to groupon and my money was quickly refunded, so I have no beef with Groupon.  The experience made me wonder though: how many vendors would be prepared for the massive Groupon demand spike?

A Quick Look at Some Recent Deals

Here are some of the recent vendors/deals and quantities issued for Groupon:

• Indian Restaurant Discount - 2549
• Admission to a Party - 1650
• Food Festival Entrance - 216
• Spa Session - 1734
• Asian Restaurant Discount - 2111
• Salon Haircut - 833
• Massage - 998

Here are some of the discussions centered around the deals:

I’ve been trying to book an appointment online and it just says “No available times were found” for every date in January and February… Is that just because they are overwhelmed by the number of Groupons purchased?

They made me feel like it was my fault that they had too many people buy this (1700 people) so they just can’t handle the capacity, so they haven’t been able to get back to everyone.

I just called and found their phone number was disconnected, too.

Not all the comments were negative -- for goods/services that are typically provided in high volume, people seemed extremely happy with their Groupon experience.  For the time-intensive services, the user response was a bit more spotty. 

Concluding Notes

Again, my experience wasn't great, but getting a refund was no problem whatsoever.  It may take a little time for consumers and vendors to flesh out the best way to manage their respective Groupon experiences, but there seems to be a real benefit from getting consumers excited about buying together on the day's deal.  So I expect Groupon to be around for a while, continuing to incite mania-induced group purchasing of local goods and services. 

As a side note, am I the only person who wonders why a "Collective Action Engine" is necessary to drive the Groupon site?  It sounds a lot like business-speak for one line of code saying "don't issue deal until N customers have bought.  Maybe I'm missing something.

Loading mentions Retweet

Rails, does it scale? 

That horse has been beaten to death, and there is ample evidence that it does scale with a little elbow grease where necessary.  

It's also commonly known that many of the rails convenience methods aren't terribly good at making complex queries.

What I've just realized, is that some of the seemingly simple operations are implemented with horrible efficiency (the current tech-lingo would be "non-performant" which makes me puke a little into my mouth when I write it). 

Today I found two big performance problems:

HABTM relation creation

Take the following:

You would expect that code to do a single insert for all the join entries.  In reality you get something like this, repeated for each bar:

bars_foos Columns (1.1ms) SHOW FIELDS FROM bars_foos SQL (0.6ms) INSERT INTO bars_foos (bar_id, foo_id) VALUES (100, 117200)

I hand coded sql to do the same thing, and found a 7x speedup:

HABTM relation deletion

This one should be a layup:

@foo.bars = []

but I was shocked to see this in my sql log:

I hand coded the trivial sql and got a 10x speedup:

In Conclusion

These aren't difficult or complex operations, and they're extremely common.

I looked into ar-extensions, but there doesn't seem to be any support for HABTM relation creation.

I guess for now these queries should be hand-coded once tables get to a certain size, but I'm still in minor disbelief.  Anyone with a better "Rails Way" to do this, please clue me in.

Loading mentions Retweet