Friday, January 22, 2010

Bad experience with Oceanair International

In 2009 I finally moved back to California from a multi-year assignment in London. My move was managed by ACE Relocations who sub-contracted with Oceanair International to do my packing and shipping from my flat in London back to my home in California.

After several months of wrangling with both companies, we've finally received payments for some of our possessions that went missing during the packing / shipping that Oceanair was responsible for. I believe that the packers at Oceanair deliberately manipulated my packing manifest and shipping inventories to allow them to steal thousands of dollars worth of electronics from me during this move.

Essentially anything we shipped by sea that was an electronic item, never made it back to California. This included:

  • 2 macbook pros
  • 1 sony vaio
  • 1 asus eeepc
  • 1 nabaztag
  • 2 sony psps
  • lots of various minor electronics (digital picture frames, ipods, etc...)
If you look at the paperwork we signed, there were boxes labeled "electronics", but in the end several boxes that got packed, seemed to be left off the manifest completely. With two guys working in our flat at a breakneck pace it would have been easy for them to skip labeling a couple of the boxes on their way down to the truck, and that is exactly what I believe happened.

If you are moving in the UK, I would recommend that you find someone else to do your packing and shipping. I know that I'll never use Oceanair International again, and I'll be encouraging my employer to never use this sub-contrator again either.

From this experience, I've got some tips on moving:
  1. Do your own inventory. Don't let the packers seal a single box, until you have seen what is in it.
  2. Count each box that goes out the door and compare that count to your own inventory. If your inventory doesn't match the number of boxes going out the door, tell the packers to empty their truck and find the missing boxes.
  3. Make sure there is someone in the room with every packer at all times. Don't trust them.
  4. Make a photo inventory and capture serial numbers on all of your valuables, and submit it to the moving company before they pack.
  5. Add a call-home application to any computer that is going to be shipped, and make sure it has an encrypted drive and requires authentication to boot up. Even better, erase the hard drive on any computer that will be out of your control.

Thursday, September 24, 2009

Back in the USA

from Shasta Hanchette Park, San Jose, CA, USA
I've been back in California for 25 days now. I'm living in my new house, with a new puppy, and all of my old furniture that has been in storage for the last four years. I'm still having a hard time getting used to the fact that I'm back for good. It feels like a strange working holiday so far.

The house is great, Jenna and I are working like mad to get settled. Every night I try to do three tasks to get us closer to that end, and Jenna does several more during the day. We've been hanging pictures, setting up AV systems, organizing, and putting away.


The puppy is fun. Here she is right now sleeping in her favorite spot on the stairs. She likes to sleep either on that step or the one above it. I think she prefers the carpet there over the tile in the rest of the house.

She has been a surprisingly good dog over the last week. She hasn't destroyed much, and hasn't had any accidents in the house (given that the shelter warned us that she wasn't house trained is a little amazing from my perspective).

She did destroy a bathroom yesterday by ripping apart every roll of toilet paper and tissue box in the room, but it really wasn't her fault. We normally keep her in a crate while we are out, but she doesn't like it. Yesterday we used the bathroom out of desperation because she refused to go in the crate. BTW, if any of you have good tips on getting a puppy to like the crate, I'm all ears.



Life is hectic right now, but in a good way. We are bringing order to chaos, and looking forward to a visit from my Mom and Dad next month.

Monday, June 1, 2009

Buying a house with Google Spreadsheets and data

from Kensington, London W8 5SJ, UK
Over the last several weeks Jenna and I have been shopping for a house in California. We've been living in London for the last three years, and are now preparing to move home to the San Francisco Bay.

By all accounts, this is a great time to buy a house. When we contacted our old friend and real estate agent, Roger Knapp, we were surprised that he sent us so many properties that met our requirements.

Roger sent us 140 possible properties for us to look at. Of those we choose 19 to visit on this trip, and we're hoping to buy one of those 19 this week.

The last time we bought a house, we approached the task in a very loose way. We visited the properties, took some pictures, and discussed them afterward, but we mostly relied on our feelings to tell us which house to buy. We don't have that luxury on this trip, so we've been more rigorous about collecting and collating data on each property we want to consider.

Google Spreadsheets has been a huge help in this. First we created a spreadsheet with MLS number, address, and price. Then we added a gadget to the spreadsheet to create a map with all the properties on it. This spreadsheet had the added advantage that we could share it with Roger, and our families to get their opinions on the properties we are looking at.

We realized pretty quickly that there were many more properties than we could possibly look at, so we introduced a simple subjective rating system. For each property on the list, Jenna and I looked at the MLS page for it, and gave it a rating of 1-5. We decided that we would only look at houses with a 4 or 5 rating.

Next we decided that we should derive some metrics from the data we had in the spreadsheet. So we created a sheet to calculate the monthly mortgage payment for each property with a fixed down payment, and added a price per square foot column to help us understand the underlying cost of each property.

After that we added some formulas to color the cells for our metrics. In each case we sorted the sheet by the metric in question, and divided the different between the lowest number and the highest number by 3. We assigned green, yellow, and red to the cells based on which third of the spread their contents fell in. This allowed us to get a really great overview of the properties, and showed us how some of our favorites were great values and some weren't.

Finally we created a form in the spreadsheet, that we could access from our iPhones while we are visiting the properties. It's got about 20 questions on it, where we ask ourselves to enter a rating of 1-5, and it is keyed off of MLS number. This means that as we are touring a property, Jenna and I can each answer the questions individually, and then send the data back to our spreadsheet.

We'll combine the survey data for each property and the metrics we calculated before to develop a ranking for our potential houses. That data should help us to understand which house is really our favorite across several considerations.

Once this is all done, I'll post the spreadsheet for others to see, but until then, wish us luck.

Sunday, March 22, 2009

Division Binned


Division Binned, originally uploaded by Allen Hutchison.

Looking out our window this morning we saw the heads from Pink Floyd's Division Bell album cover in the skip behind EMI's offices in London. The album came out in 1994, so I wonder where these have been all those years.

Wednesday, March 4, 2009

Really like Shell Sink

I stumbled across Shell Sink the other day. It's an appengine app that allows you to capture and tag all of the commands you run from a command prompt. That means that you can synchronize your bash history for several machines, and tag and annotate commands in the web interface.

This is such a great idea. I often find myself looking for some huge complex command that I ran on one machine, to run again sometime later. Of course I could manually search through all of my bash_history files, but then I would have to remember which machine I ran the command on.

Shell Sink allows you to save all of those commands in one place and search for them, so I don't have to worry about where I ran that complex command the next time I need it.

There are a couple of things I wish Shell Sink supported:

  1. Should allow people to delete old commands. If I run a command with some sensitive data on the command line (even though I know I shouldn't) I'd like to be able to delete that command from the Shell Sink history. Shell Sink does give me the option to disable command collection for a time, but I'm afraid that I'll forget to do that.
  2. It should aggregate commands. Right now it just lists your history as it would in a plain text file. It would be great if it actually aggregated your commands so that there is only one entry for 'ls' in my history.
  3. If it aggregates, it would also be great to have a counter for each command. So if I only have one 'ls' entry I can know that I ran it 500 times.

If you are a command line addict, then check out Shell Sink, and let the author know you like it.


Appengine remote_api example on OS X

The appengine team recently published an article on using remote_api, a new feature for accessing your appengine data store from a remote process. In the example they start off with a script that will allow you to get a console into your data store. The code on the site doesn't work as in for Mac OS X.

Below you'll find an updated example that does work for Mac. Basically you have to add the yaml lib directory to the sys.path.

#!/usr/bin/python
import code
import getpass
import os
import sys

DIR_PATH = "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine"

EXTRA_PATHS = [
  DIR_PATH,
  os.path.join(DIR_PATH, 'lib', 'yaml', 'lib'),
]

sys.path = EXTRA_PATHS + sys.path

from google.appengine.ext.remote_api import remote_api_stub
from google.appengine.ext import db

def auth_func():
  return raw_input('Username:'), getpass.getpass('Password:')

if len(sys.argv) < 2:
  print "Usage: %s app_id [host]" % (sys.argv[0],)
app_id = sys.argv[1]
if len(sys.argv) > 2:
  host = sys.argv[2]
else:
  host = '%s.appspot.com' % app_id

remote_api_stub.ConfigureRemoteDatastore(app_id, '/remote_api', auth_func, host)

code.interact('App Engine interactive console for %s' % (app_id,), None, locals())

That's all it takes. Hope you find it helpful. I'll also drop a line to the appengine team to let them know about these changes.

Friday, February 27, 2009

Egomania and work life balance

from Kensington, Greater London, UK
I had an interesting chat at lunch today about work / life balance. Those of you who follow my twitter stream will find this ironic, but I actually feel like I have a pretty good work / life balance.

I don't log in after I've come home for the day, and I don't work on the weekends, and I don't carry a blackberry. There are, of course, rare times when I do all of those things (except for the blackberry), but its not very often. I'm also happy to say that the same statements apply to my teams at work.

Yes, some people stay later than me, some come in earlier, but generally we are all pretty balanced with work, and I actively throw people out of the office in the evenings because I don't want them to work crazy hours.

There are people, however, who put in long hours, check email every few minutes, and log on all weekends. I'm willing to bet that this isn't really required, and in my mind is a symptom of one of two possible team problems:

Its either a lack of distributed knowledge, or a lack of trust.

In the first case, the obsessive emailer has become a locked source of knowledge in the team. Everyone comes to her with their questions, and she feels compelled to respond so that others aren't held up. On the surface she feels like she is helping the team, but in the long run she is hurting the team. She is training people to rely on her when they don't immediately know the answer to their own questions. In effect, she has become the safety net. This leads to her working longer hours because she has to handle disruptions during the day and her own job at night.

In the second case its a lack of trust or empowerment in the team. In this case the obsessive emailer has become a locked source of decision making for the team. He has to weigh in on every decision no matter how small, and will become offended if others take action without consultation. He ends up working long hours because sometimes its just easier to do it yourself.

In both of these cases the obsessive emailer is really suffering from the idea that they are more important to the project than they actually are or they have made themselves critical where they don't need to be.

In my teams, I encourage everyone to use mailing lists, wikis, and documentation to overcome the first problem. If you are going to answer someone's question, make sure at least one other person learns from your answer, that helps to distribute knowledge throughout the team and makes it much easier for individuals to rotate in or out.

I also avoid weighing in on every decision in my teams. I encourage people to make their own decisions. Yes, sometimes they'll screw up, and that is ok. The best people you can have in your teams are the ones who screw up in a new way every time. That means that they are taking risks, and learning from their mistakes.

Don't let yourself become a team bottleneck, and don't loose your own work / life balance. Take a step back and see what people do without you. I'll bet you find that they get on ok.

Saturday, February 21, 2009

New lines added to severedelays.org

from Kensington, Greater London, UK
Last night I upgraded the service running at status.severedelays.org (html, xml, json) to include current status for the London Overground and Docklands Light Rail (DLR). This rounds out the service nicely for London.

The last couple of weeks have also included a lot of behind-the-scenes work to make the service scale. I'm pretty happy about where it's at, and am now ready to include new transit networks and new developers.

If you would like to work on a current status API for your local transit network, get in touch with me. Severedelays.org would like to host your data. It's trivially easy to add new transit networks to the service. For example, take a look at the work required to add the London Overground.

This process makes it easy to add new lines, stations, or anything else with data available on the web. My next task for the service is automated service aggregation. I'll be providing aggregates of service levels for each line in the system. So you'll know how often it runs without disruption, and what the likelihood is of it running without disruption tomorrow.

There are hundreds of great applications to be written with this data. Drop me a line if you are interested.

The Crisis of Credit Visualized

from Kensington, Greater London, UK

The Crisis of Credit Visualized from Jonathan Jarvis on Vimeo.

The Short and Simple Story of the Credit Crisis.



Crisisofcredit.com



The goal of giving form to a complex situation like the credit crisis is to quickly supply the essence of the situation to those unfamiliar and uninitiated. This project was completed as part of my thesis work in the Media Design Program, a graduate studio at the Art Center College of Design in Pasadena, California.



For more on my broader thesis work exploring the use of new media to make sense of a increasingly complex world, visit jdjarvis.com.