Saturday, February 9, 2013

Retail Tip: PC Decrapifier


The PC Decrapifier

Over the years I have worked on a wide range of technical installations ranging from backend data-driven systems to frontend kiosk-like applications. One of the most tedious and time consuming tasks is to prepare the machines responsible for hosting such applications.

As we all know, installing and uninstalling software in Windows is not trivial. You need to follow workflows, reboot the machine countless times and make sure that in the process, the core Windows features and software needed by your applications still works.

Recently, I was part of a large retail installation we did in New York. The installation required setting up dozens of machines, making sure all of them were striped out of third party software and tools, and at the same time, having the required software components for the system on all machines.

There are a few alternatives for such situations:

  1. Software Image: prepare one of the machines and generate an image of it that you can use to setup all other machines. The problem is that this often doesn’t work because the hardware and configuration is not always the same among the machines. This becomes impossible when you have machines that differ in hardware configuration.
  2. Virtual Machine: you could generate an image of the machine and then set it up as a virtual machine on all the other machines. I honestly don’t think this is a viable solution for retail environments where you need your app to have full access to the machine resources. It might be a proven solution for backend systems and cloud hosting, but not for retail installations. I have had bad experiences even on local servers where even the easiest configuration tasks can become really difficult when using virtual machines. And at the end of the day, the native OS running the VMs can always get in the way.
  3. Setup all Machines: this is the most basic and traditional solution. It requires you to setup all machines, one by one. This is actually the most reliable solution. It guaranties that all machines are clean from useless third party software. It also allows you to configure the OS to prevent updates, unexpected reboots, annoying notifications and the like. The problem with this is that it takes a lot of time and effort, and is always prone to human error.

On the installation I mentioned before we came across with a magic little utility that will make your life a lot easier for such situations. Meet PC Decrapifier. The tool allows you to remove all unwanted applications, third party tools, and any useless software from the machine and leave you with a vanilla installation. It effectively removes the crap from any PC. It is really easy to use, safe and self explanatory. And the best of all is that reduces the time and effort required to clean PCs.

The tool is available for any users, and I’d imagine it is intended for IT and Home users to keep PCs clean. But it is actually incredibly useful for retail installations and frontend native applications. Thanks to this tool, my life on digital retail is easier!

R/GA London Make Day 2 Video

R/GA has published the final cut of the second annual Make Day event. The idea is simple: Make Something.

R/GA London Make Day 2013

At the end of last year I published a case study of the project I worked on with with a few of my colleagues at R/GA. Despite being busy with client work, I managed to take the whole day to work on it.

During that day, I was able to explore the Windows Azure Mobile Services stack and implement a Windows 8 application to act as a second screen for displaying supporting content to non-linear presentations. The whole concept was an exploration on how to change the way we present ideas and pitches to clients.

Check out the original post for details on the architecture and the different components.

Portfolio Project: Ray-Ban Ambermatic


Thanks to the new Ray-Ban Ambermatic App, Ray-Ban users and fans can take an analogue shot through a real pair of Ray-Ban Ambermatic shades.

The campaign and installation is focused on raising awareness among people about the re-launch of the Ray-Ban Ambermatic aviators, sunglasses that shift in color depending on weather.


We created an iPhone mobile app that gives them a chance to virtually see the world through the Ambermatic lens.


The app lets users snap a picture with their phone, then instantly sends it to the Ambermatic installation in the Ray-Ban flagship store in Covent Garden, London, where the photo is projected and re-taken through a pair of the iconic sunglasses, analog-style.



And just like the weather, the yellow hue changes with each image, allowing users to experience the world through the Ambermatic shades.


Users get their retro-style image back on their mobile app, and the best photos get to be showcased in the Ambermatic Online Gallery.


I worked with the Stockholm and London teams to create the experience. I was responsible for architecting, implementing and maintaining the Ambermatic Installation, which processes and re-captures all submitted images. The installation controls the camera, the image processing and the timing, ensuring that each image is captured and resubmitted correctly, using online services to connect the mobile app, the online experience and gallery and the camera installation itself. Effectively, this is kind of a high resolution, real time analog Instagram-like system!

Make sure to check the Ambermatic Experience and see the world through the retro-style aviator lenses.

Press Releases

Mercurial: Beheading a Head

This is the short version of my recent article “Mercurial: Commit Timeout Issues and Dirty Heads”.

To close a branch/head you first need to locally update you the head you want. Then tell Mercurial that you want to close that branch, and finally update to the latest one or the branch you want. This will prevent the closed branch to show by default when you list the heads, and when merging, Mercurial will now that it should not try to merge the closed branch.

hg update –r 145
hg commit –close-branch –m “reason to close dirty branch”
hg update –C default

Notice that ‘145’ is the revision number you want, representing the head or branch you want to close.

Hope it helps.

Mercurial: Commit Timeout Issues and Dirty Heads

image        image

Recently, I have been working with Mercurial and Kiln. Both tools provide an integral distributed version control system for our projects and teams.

On my latest project, my team was having problems committing large changesets to the server, leaving the local branch in inconsistent states, causing a bit of frustration and delays. Having .Net developers working with open source solutions can always generate some heat, and I wanted to try to keep it smooth for them.

It turns out that in some instances, you could end up with dirty branches because of incomplete commits, leaving multiple heads on the server.

Here’s why this can happen and how to manage similar cases.

The Timeout Problem

The first problem we detected, was that sometimes the server would close the connection while doing a commit. I’m still not sure why this happens, since I would expect the server to support large changeset commits. It might be because of slow network connections or large media files. The normal workflow for a commit would be something like this:

hg add .
hg commit –m “commit comment”
hg push

You should always make sure that your local branch is up to date to avoid conflicts before doing a push. So before executing the sequence above, you should update:

hg pull
hg update

Ok. So the problem is that when you are committing the large changeset, the server could timeout, leaving your branch in an inconsistent state. If you try to push again, you might get an error like the following:

hg push

pushing to https://*************
searching for changes
abort: push creates new remote heads on branch ‘default’!
(did you forget to merge? use push –f to force)

So you try to update:

hg pull
hg update

abort: outstanding uncommitted changes

And now it starts to get messy. You can try to pull again and merge, and you will get the same problem. You try pushing again, and is the same. So, you end up trying to force it.

The Dirty Head Consequence

Here’s how you force the push in Mercurial:

hg push –f

Now, this will actually create a new head on the server, which is not what you intended. But even worse, you will get the same timeout error, leaving the new head dirty, and your local branch in an inconsistent state.

Now you need to solve two problems: finish the initial commit problem, and then get rid of the dirty branch.

Solving the Push First

In our case, we noticed that the problem was the server timeout during the commit. This was do to large media files being used in our project. So what we did was to do the commit in parts.

First we rolled back to the previous revision after creating a backup of the latest changes in another folder. To know which revision you need to update two, just list the head lists:

hg heads

That will give you the list of heads:

changeset:   145:c094f56e3012
user:            User
date:            Date
summary:     Dirty Head

changeset:   132:c094f56e3012
user:            User
date:            Date
summary:     Previous clean head

If you compare this to your Kiln commit history you should be able to identify the correct head you need to rollback to. Then you execute the commands to rollback to that revision:

hg update –r 132

Now you can start committing the large changeset in batches, following the same push workflow.

This worked and solved the first problem. We were able to finish the commit with all the required files. Which will move the head forward. Let’s say, 154.

Beheading the Dirty Head

Now, you need to close the dirty branch we pushed before the last successful commit. Basically you need to close the branch, so is no longer listed in the open heads. You need to first update your local branch to the dirty head:

hg update –r 145
hg commit –close-branch –m “reason to close dirty branch”
hg update –C default

Done. You have closed the dirty branch, and updated your local branch to the latest clean changeset. You can now take a break and have a coffee before your next commit!

Hope it helps. Please feel free to share your experiences, or to point out any corrections if you think this should be solved differently.