Never rent a bad movie again. I created iMoveMash.com after renting one bad movie too many at the local supermarket's DVD rental kiosk. The free-wifi sign near that kiosk and my long time interest in mobile applications sparked an idea to help movie lovers make better rental decisions.

The resulting mobile web application integrates 7 data sources, including DVDPlay's kiosk content, Blockbuster's latest movies, IMDB movie ratings, Kids-In-Mind movie ratings, YouTube, Yahoo Movies, and Google Maps.

iMovieMash lists the kiosk's or Blockbuster's new movies in descending IMDB movie rating order (best movie first). Each movie I list is also a link to Yahoo Movies and search results from YouTube's API. The YouTube search query is biased in a way that is likely to return trailers or videos related to the movie itself. When clicked, the YouTube results launch the native YouTube application in the iPhone or iTouch.

iMovieMash took 2nd place at Mashup Camp 6, where I demo-ed the application dozens of times in 5 minute "speed geeking" sessions. That was a good bit of fun, and re-enforced the concept that successful products have a simple message, solve a real problem, and look good.

The application was developed with Perl for the backend and the IUI iPhone framework for the front end. It looks best on the iPhone or iTouch, but runs fine on a Blackberry or any web browser. Just goto http://imoviemash.com.

    

Also, researchers at Glasgow University have a proof-of-concept video of a creative new use of the motion sensor: Shake the phone and hear "your messages" rattling around inside it.

[updated 9/3: fixed typo]

Those who have followed this blog will know that I like to like to play with unusual input methods (see my earlier posts on , ambient light sensors, and the SmackBook).

As it turns out, the iPhone has a built-in LIS302DL, a tiny 3-axis accelerometer. While some have attempted to use it from within the Safari browser (the Tilt game detects changes to the width of the browser page; it is basically used as a 1-bit input device), its potential is still somewhat untapped.

After a rather lengthy bout of reverse-engineering (I had barely touched ARM assembly before this), I finally figured out how to access the raw data from the accelerometer itself, as can be seen in the video above. Source code will be posted as soon as possible is posted here. (update: yes, it is possible to access the accelerometer directly through UIKit without this hack -- however, you'll be locked to the default sample rate, which is too slow for some of the fun stuff)

Straw poll: What would you like to see on the iPhone?

Long story short, I made a simple one from a plastic bag, some dye and a camera:

Fast forward a few weeks later: I'm on a plane heading to our headquarters in Menlo Park. Eclipse (and a bunch of other technologies) are serving me our app via localhost--nice! ...that is, until I needed to reference those pesky $.ajax parameters!

With that in mind, and the remainder of the flight, I threw together a jQuery reference widget. It's been of value to us front-end developers at Medallia, and now we're returning some love to the jQuery community with this public release.

The widget provides simple, searchable, offline access to the API. More, we've provided the ability to search older APIs, as well as a few quick-links to online resources.

Per Resig's suggestion (and thanks John for all your help), we're releasing this with an MIT license and have made it available under version control.

We hope you find it of value!

Download the widget, v1.0 (View screenshots)

I've updated the widget to the latest documentation 1.1.3.1.

There were 1249 registrants, which got narrowed down to 500, 200, 50, and finally 8 through four online rounds. In one problem you had to make an AI for a simplified version of poker, and in another you had to write a strategy for a lumberjack running around in a forest. It is however the fourth problem that is my topic, as here the competition gets really tough for those 8 finalist spots.

The problem is about directing an army of up to several thousands robots as they go around in a warehouse delivering products, with the objective of completing all the assigned tasks as quickly as possible. Researchers have studied the general concept of multi-robot collaborative routing before, but it's much more fun to see what 50 good programmers can come up with in two weeks for this particular problem formulation.

Read the full entry to see a full explanation of my algorithms, the source code, and the results.

For our User Experience team, we need a skilled front-end developer looking to push the boundaries of the browser in order to create unparalleled user experiences. To create elegant aesthetics we are looking for a visual designer that can make art scalable and appropriate in the context of web applications.

To join our world class engineering team, we are looking for a senior software developer with architect design skills and an ability to craft elegant code. And to give our engineers a run for their money, we do need someone that enjoys breaking things and finding vulnerabilities as an accomplished QA engineer.

To read more, head over to the jobs section

Greasemonkey has been a great tool for creating efficiencies at work, and for hacking fun on the weekend. I like to support the local libraries so I created this mashup of Google Print's book view and the San Francisco Peninsula Library system's book search. It immediately let's you know if the book you're paging through on Google Print is available in the library. Click on the screenshot for a preview. Get the script

The Greasemonkey Javascript puts a small yellow box in the corner of your Google Print book search. The box includes a book title and a link to the library system's search results. When clicked, a new browser tab is created containing the library's lookup page with the book's location and status.

The script also linkifies the library names on the latter page, to point to the library's street map, hours and phone page.

Many have written their thoughts on this subject, and the comparison to building bridges is frequently made: if only we could build software the way we build bridges it would always be on time, on budget and of high quality.

I would argue, instead, that software development is incredible easy. It is so easy, in fact, that any 14-year-old with some spare time on his* hands can do it. No other profession is so readily available: anyone with a computer and some spare time can do it right from home.

Let me take you along on a small thought experiment: what if building bridges was as easy as developing software or in fact any kind of structure? What if, after writing down some specification on dimensions, material used and other necessary parameters you could press a button and said structure would magically appear out of thin air?

The following is a guide I wrote which we are using internally to get people up to speed on using Mercurial. While there are several other guides out there I have not found one which, in my opinion, explains well how to effectively work with named branches (probably because they were only relatively recently added to Mercurial). I also wanted a single document which explains everything necessary to start working in a clear and concise way. My hope is that this guide provides that.]]> http://blog.medallia.com/2007/02/a_guided_tour_of_mercurial.html http://blog.medallia.com/2007/02/a_guided_tour_of_mercurial.html Code Sat, 24 Feb 2007 20:32:00 -0800 I thought it would be worth noting that Neal Gafter's talk on the closures proposal for Java is now online. Enjoy.

They thought this was a brilliant idea and went ahead, putting it up on numerous big billboards. After a few weeks the sales were still very slow, however, and they could not figure out why, until after asking a few people why they were not interested it dawned on them.

Since we provide a web application to our customers that we host ourselves we are naturally interested in how it is being used. A while ago one of our account managers asked me to compile a report for her on how many times people from a specific client had logged in over the last week, and I quickly realized that this would not be the last such request. As much as I enjoy grepping through logfiles (or even writing a small perl script to do it for me) I would much rather spend my time developing new features, so then I got an idea. Since we already have an advanced reporting application that churns through millions of records in less than a second while making coffee, why not try to use it to do our usage statistics as well? How much work would it take? Not much as it turns out!