Posted in Software on 19th August 2010, 10:44 pm by Stuart
When on holiday recently I made extensive use of the Google Navigation app with my HTC Desire to provide satnav for our journey across France.
Before we travelled I’d been using Navigation in the UK and was really quite impressed with it. The directions were accurate and I’d found it worked really well. Out of the box it found the places we wanted to drive to easily and if we went the wrong way, re-routing was quickly calculated. The detail provided for junctions and roundabouts are clear and timely as you get several prompts before and during the manoeuvre.
Google Navigation fetches the route upfront when you tell it the location you want to head to, it doesn’t currently provide maps to download in advance. The route is cached so it doesn’t need any data as long as you stay on the route. In the UK as my contract includes unlimited data, it’s not a problem to request a new destination on the fly or have Navigation re-calculate a new route if you miss a turn.
The interesting thing about trying to use this abroad was I didn’t want to end up with a massive data bill when roaming. So this required a bit of planning. When setting out on a route, where I had Wi-fi available, I’d use that to pre-fetch the route so I didn’t need to use mobile data to get the route. I bought a weeks worth of data for roaming via Text message (It was £5 for 50mb for a week). Then I only used the mobile internet when I absolutely needed to. Turning mobile internet on and off can be achieved by pressing and holding down the power button and then selecting it from the menu that appears.
In France the instructions were as accurate as the instructions in the UK and for the odd occasion where we’d got lost it was very handy to be able to get our location and find our way back to the place we were staying at. It would be nice to have a French accent to the audible instructions when in France, but the english voice was was good enough to know what was happening.
What could be better
The main downsides were it would be great to be able to download maps in advance to avoid the faffing with turning data on an off. This would also avoid the reliance on a signal to get directions. If there’s no data connection available you have to drive until you have one.
Another issue is that currently there’s no way to route a journey with a specific via point. This would have been useful in the case where we knew there were roadworks making a particular route unusable. The way to get around this was to drive off the chosen route and then have the app re-route us when we knew it would have to choose the route we wanted to take.
Lastly and probably the most frustrating issue with Navigation was that I found that the app seemed to crash if the phone got hot from being charged up. If the phone wasn’t being charged or the weather was colder it seemed a lot more stable. Time will tell if this issue will be resolved with Froyo update.
Verdict
As Navigation is free, it really is quite stunning how well it works. If you’ve not yet tried it out and you have an android phone, I’d highly recommend it.
Post Tools
Posted in Software on 19th August 2010, 10:10 pm by Stuart
Whilst on holiday recently I was using Shotwell (the rather excellent photo manager for Ubuntu) to import some photos. After importing the photos Shotwell asks if you want to delete the imported photos from the card. Without thinking, I absently-mindedly said yes. What I’d missed was I’d not separately imported the videos that were on that SD card, (Shotwell doesn’t currently cater for video imports though this feature is destined to be added soon.) usually this isn’t an issue but in this case I’d inadvertently removed the videos I wanted to keep.
The good news is by realising I’d removed the files, I could just make sure I didn’t write anything to that card, because deletion just means that the space those files occupies on the memory card is marked as free. So as long as you don’t fill that freed space with new writes the files should be recoverable.
So I looked for a suitable utility to recover my files and I came across PhotoRec. It’s available for a whole slew of operating systems including Windows, Linux and OSX.
On Ubuntu PhotoRec is available via the package “testdisk”:
sudo apt-get install testdisk
Mass Storage Devices vs Photo Transfer Protocol
As I was on holiday I wanted to use photorec on the SD card using the camera as a card reader. Depending on which camera you’re using this may or may not work. In my case I was using an IXUS, it doesn’t support mounting of the memory card as a mass storage device. On my wife’s Lumix it’s configurable. So to be able to recover the files I had to wait till we got home so I could use the card reader in my Lenovo dock.
File Recovery
Recovering the files is done on the command line. On Linux you have to use sudo e.g:
sudo photorec
It then displays a list of the available drives you can recover data from. In my case it was /dev/sdc:
Next you just have to select the partition table type, in my case it was Intel/PC – PhotoRec highlights the detected partition table type by default.
After that you have to choose the partition, here I chose “Whole disk”:
After that choose the filesystem type. Once again the default is the auto-detected value. In this case Other because our card is FAT.
Next you decide where to save the files. PhotRec creates directories inside this location itself so Desktop will suffice:
Next the recovery begins.
Once complete you should find all your files in a directory named: “recup_dir.1″.
This took about 10 mins for a 2GB card on my machine and lo and behold my videos were restored.
Post Tools
Posted in Code, Work on 28th July 2010, 2:10 am by Stuart
Photo CC licensed by oedipusphinx
I’ve been working for canonical for about four and a half months now. One of the things that I’ve been really impressed with is the workflow for development and the process for how new features end up in trunk.
The workflow is as follows:
Feature Development
Our primary development focus is trunk as this is what’s deployed on a weekly basis. So the first step is to pull the local copy of trunk to ensure it’s up to date. Next, the developer makes a branch of trunk for the feature/bugfix.
cd trunk
bzr pull
cd ../
bzr branch trunk branches/my-awesome-feature
The feature is developed with TDD (tests first, followed by code to make the tests pass). Once the feature or bugfix is finished the branch is pushed up to launchpad under the project.
# hack hack hack
# Ensure tests pass
bzr push lp:~<USER>/<PROJECT>/<BRANCHNAME>
A nice feature of bzr that I’d not used prior to working at canonical is the way you can automatically set push targets for branches based on the directory that contains them. So for example we have a config in ~/.bazaar/locations.conf that looks something like this (obviously substituting the variables in angled brackets for your username and project etc):
[/path/to/branches/]
push_location = bzr+ssh://<USERNAME>@bazaar.launchpad.net/~<USERNAME>/<PROJECT>
push_location:policy = appendpath
So if I have a new branch at /path/to/branches/foo-bar-baz
This will automatically set the push location to:
bzr+ssh://<USERNAME>@bazaar.launchpad.net/~<USERNAME>/<PROJECT>/foo-bar-baz
Meaning all I have to do is use bzr push to send my branch into launchpad.
Note: At any time you can check the push location with bzr info
Code Review
The next stage is for the developer to make a “merge proposal” via the launchpad interface. This puts the merge request in a “to be reviewed queue” which provided a merge proposal page with a diff of the changes from trunk (the target branch is customisable). The rule is that every branch has to be approved by a minimum of two devs. Reviewers can make recommendations or assert that something needs to be fixed and the developer can then push subsequent changes to the same branch and those changes are made visible.
The focus of reviews are on coding style, standards e.g. adherence to PEP 8, and reviewers will run the test suite and run pylint to check for any glaring violations. Merging with trunk is also carried out to check that no conflicts occur.
Landing branches
Once the code has been successfully reviewed code is submitted via PQM (Patch Queue Manager) which then runs the test suite and only merges the code with trunk if the tests pass. We’re still using PQM but most projects have already begun the process to move to tarmac which is tightly integrated to launchpad.
I like the rigorous review process. By having code reviews a mandatory part of the process it becomes just part of a routine, everyone is used to it and so are happy to receive and give criticism. Reviews are definitely seen as a route to better code rather than making people feel small which is exactly how it should be.
The process might sound quite lengthy but because of the ease of branching in bzr (like any other DVCS) the process is very quick and easy and branches are continually landed in trunk every day. It’s actively encouraged that branches are kept around 500 lines of diff where possible, to make it easier for code to get reviewed. Branches aren’t worked on for weeks on end, they are developed, reviewed and merged within what’s usually at most a couple of days.
Future changes
One of the things we’re currently looking at is using hudson to automate the running of the test-suite for merge-proposals. This would mean that hudson could run the tests as soon as a merge proposal is made and provide an “approval” or “needs fixing” status based on the results of running the test suite. The net effect would be that we’d then require 3 approvals rather than 2.
Summary
Obviously our workflow revolves around the use of launchpad, but there’s plenty of ways to adopt a similar workflow without requiring the use of launchpad. For example on personal projects I’ve adopted pretty much the same process except branches are pushed to remote server instead of launchpad and rietveld has been used for reviews in place of the merge proposal feature. Rietveld is fairly vcs-agnostic however, if you’re using git as your vcs then something like gerrit might be worth looking at. (gerrit was originally a fork of rietveld but has more recently been completely re-written using java instead of python). Also review-board is another code review tool that works for all popular VCSs – review-board is django-based and is therefore relatively easy to set-up.
In summary:
- Use a DVCS (e.g: git, mecurial, bzr) so branching is easy. I remember at Yahoo when CVS was the VCS everyone had to use, branching was explicitly avoided as much as possible because merging was seen as such a pain. Worst case, if you’re stuck with something like svn be comfortable with merging so branching is not a hurdle.
- Branch as often as necessary.
- Review everything and make it a part of the code routine.
- Merge as early as possible.
- Keep Trunk pristine.
Post Tools
