Omar is on fire. Just a few days after publishing his Guide to creating a Google App Engine / Remix API / Facebook app, he’s released Remix.NET, a C# wrapper for the Best Buy Remix API.

Code sample:

Using Remix;

Product p = null;
try
{
    Server remix = new Server("username", "password");
    String filter = "iphone";
    String postalcode = "94102";
    String radius = "25";
    bool tersemode = true;
    int pagenum = 0;

    // Get all Hardgoods that match "iphone" in the name attribute and
    // are in stores in the 94102 area code in a 25 mile radius.
    // When "tersemode" is true, only return a handful of information.
    // (See method signature for details.)
    Products list = remix.GetHardGoods(filter, tersemode, pagenum, postalcode, radius);

    if (list.Count > 0) p = list[0];
}
catch (Exception e)
{
}
return p;

Check out Omar Abdelwahed’s* guide to using Google App Engine with Best Buy’s Remix API to build a Facebook app.

Omar is also the author and maintainer of the bbyremix Twitter app.

Sign up for an api key at the Remix API website.

* friend of Pivotal

1. A great little Ruby tutorial using HTTParty with the Remix API.

2. Slashdot mention.

3. Finance and Commerce: Best Buy API Aims To Expand Store’s Reach Online.

For more on Remix, check out the Remix API website (where you can sign up for a developer key).

There’s a reason you don’t stick your hand into fires, walk into traffic, or use Windows Vista. Humans, along with pretty much every other organism with a central nervous system, have evolved fear as a defense mechanism that protects us from doing things that cause us pain. We can override this to a certain extent, but fear is instinctual and basic.

Now, a lot of the ideas and practices that fall under the umbrella of “Agile,” exist largely to remove fear and pain from the software development process. Detailed and extensive tests remove the fear of breaking things when we make changes; pair programming and collaborative work remove the fear of getting stuck on a problem, or learning a new domain or technology, or having someone leave the team. Rapid iterations and rich feedback remove the customer’s fear of not knowing the true progress of the project, or having not having the really important stuff done when the deadline comes.

On top of this, we build more tools every day to make our lives easier and less painful. Rails itself is a great example: it removes the painful and tedious bits of creating a website, removing the fear a web developer might have of becoming mired in details and configuration. But, are all of these tools that reduce fear good things? After all, we’re much more likely to jump headlong into something we don’t fear.

Bug management systems are an example of this. They exist for one reason: to make dealing with a lot of bugs less painful. If a system has three bugs then there’s no real reason to prioritize or filter them. If that system has three thousand bugs, then the situation is quite different. Just looking through the bugs without some form of sorting or filtering would be quite painful. But, isn’t an out of control bug count something we should be afraid of? Do bug management systems make it too easy to manage a situation that we should be doing anything to avoid?

Exception notification systems for Rails are another excellent example. Personally, I like ExceptionNotifier. It sends an annoying email to, ideally, your entire team. That’s it, no frills. Now there are systems like HopToad and GetExceptional that manage these exception in a friendly way. Again, do these tools remove the wrong kind of pain? Shouldn’t we be afraid of runaway exceptions?

Personally, I like the idea of leveraging basic animal instincts to keep us on the straight and narrow. Programmers will tell you that they know the right thing to do, that these tools don’t create any disincentive to do the right thing. But, I suspect that someone with an anesthetized hand would be a lot less careful about sticking it into a fire.

ActiveRecord’s update_attribute() method is useful for setting a single attribute value while bypassing validation.

You may not know, however, that when invoked on a new record, update_attribute() saves the record, including all the fields, and bypassing validation for all fields.

This can lead to some unwelcome surprises. For example, acts_as_list uses update_attribute(), so if you’re using acts_as_list, watch out for unexpected, unvalidated saves when using new records within the list.

Thanks to Adam Milligan for the heads-up.