From the redis manifesto:

"We optimize for joy. We believe writing code is a lot of hard work, and the only way it can be worth is by enjoying it. When there is no longer joy in writing code, the best thing to do is stop. To prevent this, we'll avoid taking paths that will make Redis less of a joy to develop."

Amen.

Permalink | Leave a comment  »

As a developer I've found new appreciation for the adage "a man* is only as good as his word."  In business and in life, you can't depend on people who don't follow through on promises, especially when stakes are high.

Amongst programmers, our code is our word.   If collaborators can't trust that our code is of high quality, we are effectively a time and energy sink for those around us, forcing on others the task of testing and validating our work.  The analogue in the non-tech world would be someone whose promises require second guessing, backup plans, and a non-trivial dose of anxiety.

A developer that pushes high-quality commits, like someone who follows through on his or her word, is a refreshing person to interact with, because the cost of interaction is negligible, making the net value of all contributions significantly higher.

Push good code.

*note:  excuse the gender bias in the quote - fortunately women are better with promises and code commits

Permalink | Leave a comment  »

A case study of the physical world bleeding into the technical . . . and a case study in idiotic StackExchange questions.

Permalink | Leave a comment  »

I always hated "programming problems" when I was interviewing for jobs. I now also hate them as someone who is trying to hire programmers.

As a candidate, I felt like these kinds of problems had little relationship to real work. How often do I really need to find the number of ways that one could walk down a set of stairs (a classic recursion interview question) or what floor an egg breaks on? (nice one, google)  And what am I supposed to do if I already know the answer? (which was often)  There are multiple levels of weirdness at play -- not exactly what I call enjoyable.

As an employer, I hate them for an entirely different reason. My objective during an interview is to find out two things:

a) is this person smart
b) can this person work well with our team

Canned interview problems may given you the answer to (a), but they do so at the cost of having any chance of knowing (b).

By giving them a contrived problem that I know the answer to (and they know I know the answer), I've immediately forced an artificial interrogation-style power dynamic between us and likely amplified their anxiety by a couple orders of magnitude. My goal is to get as far away from that dynamic as possible.

To the best of my ability, I want to simulate an hour or two of work and see whether we can collaborate effectively.  Here's the rough approach I've worked out so far, comments are appreciated as I'm pretty new at this myself:

• Have them share a personal project with you, it doesn't have to be of epic proportion, just something they're working on.
• Talk through some of their code during the interview if possible. This can give you both an idea of what a code review will look like.
• Have them explain any problems they are having, and see if you can help. This informs whether you will be able to collaborate on projects they own. 
• Walk through some of your own code and explain some of the problems you've been having. See if they have any insight and whether you can brainstorm together.

In both cases of reviewing your respective work, you are admitting that you don't know the answer to the problem. In the case of your own problem, you're also admitting that it's something you could use help with.  You have now mitigated the power dynamic somewhat, which means the candidate can feel comfortable in throwing out ideas. You've moved from waiting for the "right" solution to asking for ideas on a real problem.

You come away with a good indication of their ability, as well as a decent indication for how well you would work together. And a possible side benefit may be new insight into the problems that you're struggling with.  It takes a little extra courage to fly without a net, but that's the whole point - leveling the field so you can actually talk.

If this sounds sane to you and you're looking for dev work in San Francisco, please get in touch.

Permalink | Leave a comment  »

I run into a fairly common problem in rails views when I'm pulling data from multiple tables.  To optmize on db access, I use :select to pre-load the data from the joined tables.  For example, let's say I want to list all users with their respective cities:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

#models/user.rb
class User < ActiveRecord::Base
  has_one :address
  named_scope :with_city_info, 
              :joins=>:address, 
              :select="users.*, addresses.city as user_city"
end

#models/address.rb
class Address < ActiveRecord::Base
  belongs_to :user
end

#users controller
def locations
  @users = User.with_city_info
end

Then I don't have to load the Address model to display a user's city:

1
2
3
4
5

#locations.html.erb
<%= render :partial=>"user", :collection=>@users %>

#_user.html.erb
<%=h user.name %> lives in <%=h user.user_city %>

The problem is that my user partial is now coupled with my named scope:  if I render the partial without using the scope, I'll throw an exception.  To avoid the problem, I add an accessor method to the User model that will pull the pre-loaded data if available, and revert to using the Address model:

1
2
3
4

#models/user.rb
def user_city
  read_attribute(:user_city) || address && address.city || ""
end

The partial will be inefficient, but I'd prefer to find the error when profiling view times rather than through exceptions.

Permalink | Leave a comment  »

. . . so much for Javascript fallback.

Permalink | Leave a comment  »

This functionality is included in some ruby gems (Utility Belt seems to be the most popular), but I'm more of a "roll-your-own" kinda guy.  Not to mention that the gem is a little overkill for printing out command history. 

Here's what I came up with:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

def history(num=100)
  h = Readline::HISTORY.to_a
  start = [0,h.size-num-1].max
  h.zip((0..h.size).to_a)[start...h.size].each do |e,i| 
    puts " #{(i).to_s.rjust(4)}  #{e}"
  end;nil
end

>> history(7)
  483  def history(num=100)
  484    h = Readline::HISTORY.to_a
  485    start = [0,h.size-num-1].max
  486    h.zip((0..h.size).to_a)[start...h.size].each do |e,i| 
  487      puts " #{(i).to_s.rjust(4)}  #{e}"
  488    end;nil
  489  end
  490  history(7)

Permalink | Leave a comment  »

When authenticating users via facebook, you have a laundry list of possible permissions to ask for.  If you ask for no permissions, the user gets the following login window:

Below is a screenshot of what it looks like when asking for the full suite of permissions (I used the helpful Rell application to test). From this you can get an idea of what it looks like to the user based on which permissions you're asking for.

Asking for all permissions at once would be a little intimidating for users . . .

Permalink | Leave a comment  »

Confirming the email alert I recently received, Google appears to be strategerizing in social with a renewed push for Orkut: it's listed on page 1 of their new products page (despite launching in 2004).

Permalink | Leave a comment  »

My browsing speed was noticeably & absurdly fast, so I ran a quick check:

Permalink | Leave a comment  »

Permalink | Leave a comment  »

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

Permalink | Leave a comment  »

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))

Permalink | Leave a comment  »

Permalink | Leave a comment  »

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

Permalink | Leave a comment  »

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.

 

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

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?

Permalink | Leave a comment  »

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. [edit - I'm told that Groupon pays out vendors immediately on the deal, which in theory should mean the vendors can sit on the cash until redeemed]

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.

Permalink | Leave a comment  »