Just over 5 years ago we started CodeSherpas with a vision - the nature of software development is changing, and we wanted to be on the forefront of that change. Our jobs are many and varied - sometimes training and mentoring, sometimes augmenting existing staff, sometimes the project is ours and ours alone. Sometimes we work at home, sometimes on client-site. We bring the deep experience we have developed to bear on our client's projects, and have a strong reputation doing so.

The time has come for us to broaden ourselves; we are looking for a couple of passionate, self-motivated software engineers who want the opportunity to take their expertise to the next level. Are you interested in working for a company where your skillset is the product, and the company invests in it? Are you interested in working someplace where even the owners write code, and there are no 'pointy-haired bosses'? Are you interested in solving a variety of interesting technical problems? Have you been dabbling in recently emerged technologies and want the opportunity to use them full-time in mission-critical production applications?

We currently spend most of our time in a web-centric development stack. To us that means: Ruby, Java, Javascript, CSS, HTML5, JQuery, NodeJS, Backbone, MySQL, Redis, Linux, OSX, and so on. We also occasionally dabble in Objective C and Clojure, and see those technologies as crucial to the future. When we run a project we prefer 2 week iterations, constant feature delivery, and reflection on the work to improve ourselves. We know and love git. We like to publish, speak at conferences, record screencasts, and promote the local user group communities. If you think you can contribute to a team doing these things, we want to talk to you.

As consultants, our jobs tend to take us around the Northern Virginia and Washington DC area. Sometimes we work at home, sometimes in the Reston area, and sometimes in DC. We know commuting in the DC metro area is tough, we do it ourselves. Despite this, we strive to maintain a healthy work-life balance.

We're not looking for rock stars... we're looking for orchestra members. We're not looking for ninjas... we're looking for Sherpas. We do the technical heavy-lifting.

Does that sound interesting? Lets talk.

"Its never any one feature that causes problems; it is the interaction of otherwise reasonable-seeming features."

In a recent conversation with a number of NFJS speakers, David Sletten (via his brother Brian) brought up a tricky Java puzzler - a piece of code that is seemingly simple, but doesn't do quite what you'd expect. Consider:

Arrays.asList(new Integer[] {1, 2, 3}).size();
Arrays.asList(1, 2, 3).size();
Arrays.asList(new int[] {1, 2, 3}).size();

To make a long story short, any reasonable first-reading of this code would expect all three examples to return '3', yet the bottom one returns '1'. Why?

Brian Goetz, who has the esteemed title of "Architect for the Java Language and Libraries" gave a clue that leads to the answer when he said "Hint: asList is a generic method. What type is being inferred for T?"

This led to a conversation that only the nerdiest of nerds lubricated with the finest of scotches would dare sit through. Brian eventually concludes with the statement, "The bipartite nature of the type system is the root cause here; int is not an Object, but int[] is. Mix that with varargs' attempt to conflate T... with T[], and...bam, astonishment. Its never any one feature that causes problems; it is the interaction of otherwise reasonable-seeming features."

That last sentence was quickly seized upon as a profound truth in software development and dubbed "Goetz's first law".

The code example above isn't nearly as important as the sentiment that inspired the law. Since he said that, I've seen virtually every problem I'm encountering as a variation of this.

I'm doing a lot of work lately using ActiveResource.  I wanted to get 'down to the wire' and see the traffic flowing over http... so a quick google search, and I found an entry I had written in 2008.  I love it when that happens!  So I'm reblogging it with a slight change to make it work in Ruby 1.9.

If you're using rails, create an initializer name active_resource_spy.rb and drop in this content:

class ActiveResource::Connection
  # Creates new Net::HTTP instance for communication with
  # remote service and resources.
  def http
    http = Net::HTTP.new(@site.host, @site.port)
    http.use_ssl = @site.is_a?(URI::HTTPS)
    http.verify_mode = OpenSSL::SSL::VERIFY_NONE if http.use_ssl?
    http.read_timeout = @timeout if @timeout

    #Here's the addition that allows you to see the output
    http.set_debug_output $stderr
    return http
  end
end

All the data that flows over the http connection will be dumped to $stderr (the terminal you started the app in, unless you redirected it).

I have been a customer of Tivo for a long time; I first saw one at a friend's house in the fall of 1999, and bought one for myself that Christmas.  Over the years I have owned somewhere around 6 tivos... Upgrading when the series2, series3, and most recently the Tivo Premiere came out.

Of course at its heart, the Tivo is a computer with a hard drive, and in the past 12 years I've had a few technical issues.  This story starts last month when my Tivo Premiere died a horrible hard drive death and needed to be replaced, and ends with a lesson on the importance of having a relationship with your customers.

I wasn't looking forward to replacing the Tivo - besides the call to Comcast (which is an entirely separate blog post), I know from experience that every Tivo is a blank slate...  I have to 'teach' it everything about me again... the shows I record, the stuff it should suggest for me, and so on.

Once I got the box set up, I was greeted with a "Welcome to Tivo" message in the Tivo's "messages and settings" that politely told me what I needed to know to use my Tivo, as if I was a first-time user.  I was slightly annoyed at this...  I thought to myself "Tivo *knows* who I am - this Tivo is linked to a lifetime account.  Why not have a welcome message that says 'Here's your replacement Tivo - we hope Rudy at the service center was able to resolve your issue.'?

Of course, Tivo could easily do a lot better than that suggestion.  My Tivo is linked to an account where I can schedule shows on the Tivo website; Why not back up my preferences there, and automatically download them to the new tivo?  Why do I have to set up, yet again, things like "Record episodes of Phineas and Ferb off of DisneyHD"?  I'm not asking Tivo to back up tons of data - not the actual shows, just the 'metadata' about my shows, my thumbs up and down ratings, the premium channels I subscribe to, etc.  This can't be more than a few hundred kilobytes. (I would think they would be interested in that data too - wouldn't TV executives PAY to know how many people gave a TV show a thumbs up vs. a thumbs down rating?).

A week after I set up my replacement Tivo, I received a new message that says "You may have noticed extra recordings that you didn't request - these are Tivo Suggestions".  This reminded me how annoyed I was...  "Yes, I know you suggest shows to me - you've been doing it for ELEVEN YEARS...  DON'T YOU KNOW WHO I AM?!?"  I began to get the feeling that Tivo, as a company, doesn't care that I'm a loyal customer.  They should be sending me a message that says "Its been a week and we see you're recording your preferred shows again.  We're happy everything was set up properly with your cable company".

Another week went by and I got another message "Have you ever missed an episode of your favorite program?  Learn how to set up a Season Pass".  Sigh.  Perhaps you didn't notice, but I've already set up, like, 70 of them?  Remember me?  I was mildly annoyed at having to set everything up - but weeks later, Tivo's naive attempts at customer contact are simply reinforcing the negativity of the whole experience.

Now, I'm not expecting Tivo to greet me by name when I call their service department, or send me cookies at Christmas time, but they can do a lot better than this. As a software engineer, I know the things I'm suggesting are next to trivial to implement.  I'm also quite sure the Tivo engineers have a list of user stories like these sitting in an idea tracker somewhere...  The only reason Tivo, as a company, would not do these things is because they haven't been made a priority.

Thats right, Tivo, as a company, has not made it a priority to have a relationship with their customers.

As much as I love my Tivo, I think they survive because their biggest competition is from cable-proprietary DVRs... and we all know the track record of customer relationship management cable companies typically have.  Tivo should be thankful Apple didn't make the AppleTV a DVR... I don't think they could survive the competition.  If Apple made a DVR, I'm sure it would be sending me tweets: "Hey Dave - Neal DeGrasse Tyson is going to be on Letterman tonight - don't worry, I'll record it for you."

You know what would have been the ultimate experience?  A message on my tivo 2 months ago that said "We've noticed your Tivo is beginning to have issues with its hard drive.  We've backed your schedule data up and scheduled a hardware replacement under warranty.  call 1-800-get-tivo to schedule your return and replacement".  Upon plugging my new Tivo in, a message like "We've downloaded and rescheduled your shows and noticed you've inserted your cable card.  You now need to call 1-800-comcast, and give them this MAC ID and Card Pairing Code to have them reactivate your cable service".  Every piece of hardware and data is available to make that possible; all thats missing is software.


Is there a lesson here?  Yes!  We can trivially use the data we have on our customers to improve their experience, and make it seem like they have a more personal relationship with a big faceless company.  How can you improve your relationship with your customers?

This is a small complaint about Rails 3.1, but its one I'm surprised I'm able to make at all.

If you have been following the evolution of Rails, you know that years ago the framework adopted REST as one of its core principals (well, restful concepts - I'll leave it up to others to debate/defend the true purity of the implementation). One of the core ideas behind REST is the idea that a url represents a unique resource, and that the mimetype/filename extension is used to negotiate the format that gets delivered. for instance:

and

should be the same underlying *thing*; what gets transferred is a representation of the thing in the format requested... in this case, my resume, as either html or pdf.

Enter the new Rails Asset Pipeline, which is a fantastic piece of work in general. In diving in and playing with it for the first time, I was trying to wrap my head around some of the conventions. I generated a new rails project with v3.1rc4, and I hadn't added any of my own content yet. I was looking at how everything under assets directory seems to be served up under the /assets/ url without much respect for the directory structure underneath it. Out of the box, rails gives us several files that have default contents. For instance:

and

Compare that to my first example above. These are the same url, but with different extensions - different "content negotiators"... but they aren't serving up the same thing at all. One could argue that they are two things designed to work together, but I don't think thats enough - the principal is violated - these are not the same thing, just in different formats, these are really much different things - one being code in the Javascript language meant to be used by your web application, and the other being a css file that contains all of the view/layout of your app. the browser isn't saying, "Give me that same information, but in the .js format", the browser really is requesting a different asset.

I like the asset pipeline, and I like the convention of treating all of these things as "first-class citizens" in their own assets directory under /app instead of as "a bunch of stuff" that happens to live under the /public directory - but I don't think this first-class citizenry has gone far enough - why aren't these things further scoped by the /images, /javascripts, and /stylesheets directory when referenced via url?