Unlike leapwm, dbsnap is designed to work for anyone using git and postgres. It's my latest and greatest attempt to solve the problem of keeping a database synced up to a git repository. I designed it to be completely trivial to use, and easy to find the correct backup for any particular point on the git commit tree. To set it up, just run

git clone https://github.com/AlexWillisson/dbsnap
cd dbsnap
sudo ./install.sh

Once installed, dbsnap will live in your $HOME/bin directory. It optionally takes one argument for the database name, and must be run inside a git repository. If you call dbsnap without an argument, it will use the current directory's name as the database name. dbsnap requires sudo to manage the permissions in /opt/dbsnap, but that's simple to remove if necessary.

dbsnap fetches the current commit ID and builds a backup of the postgres database named after the commit, builds a compressed tarball, and stores it in /opt/dbsnap/DBNAME/$DBNAME-$COMMIT.tar.gz. Eventually I'll probably write a dbrestore $COMMIT function which will look for the most recent database backup to that commit.

The net result is a /opt/dbsnap that looks something like this:

atw@lorien:~$ ls -R /opt/dbsnap
atw oom

atw-6e85f75.tar.gz atw-af77ef4.tar.gz atw-9c05b52.tar.gz atw-cc5afce.tar.gz

oom-03c4810.tar.gz oom-600f920.tar.gz oom-87327b9.tar.gz oom-d60f33a.tar.gz
oom-501845e.tar.gz oom-7a967db.tar.gz oom-b82939f.tar.gz oom-f7edce9.tar.gz

If you know that the checked out commit in a git repository had a database backup to go with it, you can restore it with this command (remember to back up your current database with pg_dump!)

pg_dump $DBNAME > $DBNAME-`date +%F`.sql
dropdb $DBNAME
createdb $DBNAME
tar -Oxf /opt/dbsnap/$DBNAME/$DBNAME-`git rev-parse --short HEAD`.tar.gz | psql $DBNAME

If the git repository's directory name exactly matches the postgres database, those commands can be simplified to:

pg_dump $DBNAME > $DBNAME-`date +%F`.sql
dropdb $DBNAME
createdb $DBNAME
tar -Oxf /opt/dbsnap/$(basename `pwd`)/$(basename `pwd`)-`git rev-parse --short HEAD`.tar.gz | psql $(basename `pwd`)

Happy coding!

Be the first to comment

Sooner or later, I generally push git repos of my side projects to GitHub, once they've reached an interesting point. I don't expect them to work on anyone else's machines out of the box, but hopefully they're good examples or fun toys. This project requires nc, xwininfo, xdotool, a Leap Motion, and the leapd daemon running. If you're using a linux-based machine, chances are you have nc and xwininfo already installed.



This was mostly an experiment to learn about the Leap, but if I push it far enough I might start actively using it on my desktop. The idea is to be able to move windows on the screen without having to click and drag. It's a spiritual successor to my Metacity window manager hack that added physics to the windows. You can see a demo of that here:


leapwm doesn't have the bouncing affect yet and only handles horizontal motion, but instead of clicks it uses swipes as detected by the Leap's Python API. Right now, the window's ID must be hardcoded into the script. If I ever get back to the project, I'll add automatic detection of the active window. In the meantime, you can find a window's ID by running

xwininfo | grep -i "window id"

and clicking on the target window.

If xwininfo didn't come installed, it's probably in your package manager.

Under the hood, leapwm is broken up into two main parts, swipe.py and mpu.py. The two processes communicate over a TCP socket with mpu.py as the server. Whenever the Leap's API reports a swipe gesture, swipe.py translates it into a force to be applied to the window, then outsources all the work of the TCP socket by running nc as a command line program. Using nc also means that the whole system is much more resilient to bugs, since there's no persistent connection that needs to be maintained.

mpu.py handles the actual window motion. It collects force information from its TCP socket, keeps a queue of those forces and for how long they should be applied, and does a bit of math to figure out how the window should be moved. mpu.py is entirely independent of the Leap and can be used with any programs that send it force information in the proper format.

Ideally, all the window manager-specific pieces of leapwm would be in mpu.py, and all the Leap-specific parts would be in swipe.py. Because they use a TCP socket, it'd be a simple matter to put the two scripts on different computers. mpu.py absolutely needs a layer of authentication that I didn't bother with for this prototype. swipe.py uses xdotool in a few places to help scale the coordinates.

My development has been on fluxbox with the default theme, so there will probably be a few hiccups on other systems. If you want to make this system work for yourself, you'll probably need to change the x and y offsets at swipe.py:110 and mpu.py:106, since they match my window decorations. Unfortunately the geometry I can extract from xdotool gives me the corner of the X window, but not the corner of the decorations that the window manager applies around the X window. If your window is mysteriously moving especially jerkily and downward as well as whatever direction it's supposed to be moving in, chances are it's because your offset doesn't match the height of the bar at the top of the window.

Be the first to comment

ThinkPad W540 and Ubuntu

I recently got a new laptop to replace my old ThinkPad W520, I wound up just getting the current version of the same line. Unfortunately because of UEFI and SecureBoot the installation was a bit of an adventure, but I got it working surprisingly easily. Essentially I wound up turning off everything related to the new UEFI and SecureBoot verification things along with FastBoot, and dualbooting Ubuntu with Windows 7. The copy of Windows 8 that came with the laptop didn't work with Legacy Boot, and I couldn't get a bootloader (either the EFI one or grub) to notice Ubuntu when in the not-Legacy Boot mode.

On a fresh install of Ubuntu, most of the hardware works pretty nicely. There's a few things that are a little annoying, and I'm looking to fix. Some is on a hardware/firmware level so I can't do much about it, but a lot is fixable in software.

Be the first to comment Read more

I'm cleaning up my site, and I rediscovered a post I was working on a while ago but never published. I've abandoned this project, but I figured someone might be interested in my documentation I wrote while I was trying to get it working.

For a long time there has been a spaceball in my house. Basically, a spaceball is a joystick with six degrees of freedom and a bunch of buttons. Six degrees of freedom means it can take input along six degrees. Forwards and backwards, like a normal mouse or joystick (x and y), up and down (z axis), rotation around the z axis (clockwise/counterclockwise when looking down), pitching forwards and backwards (rotation around the x axis, or clockwise/counterclockwise when looking at it from the side), and finally, tilting from side to side (rotating around y axis, or clockwise/counterclockwise when looking at it from the front)


I don't really have a clue what I'll be able to use the spaceball for, but it's a really cool input device. It'd be perfect for flying around in Google Earth, or any sort of game that involves moving around in a 3d world. It could probably be used for a really cool sculpting program, or controlling a quadcopter.

I got the spaceball working after not much effort, although I would have saved some time if I'd tried using root to start with. The command is: # inputattach -sbl /dev/ttyUSB0 Where /dev/ttyUSB0 is where the spaceball is attached to. If you have an actual serial port, it'll probably be one of the /dev/ttyS* files.

If you're trying to get a spaceball to work, try that command before continuing. If that works, you don't need to keep reading (but feel free to!). A few things which I tried before running that command follow the break. If you don't have inputattach, it's currently on apt-get for Ubuntu 11.10. If you're from the future when 11.10 is ancient, you can probably find it in archives somewhere, if it hasn't been updated. There's a small chance I'll have mirrored it somewhere to make sure my devices keep working, so you can also check whatever I'm using at the time to host my projects.

Be the first to comment Read more


Over the past couple of years, I've been experimenting with interesting ways to control my computer. I've played with the Kinect and the Xtion depth cameras to adjust my computer's volume and scroll web pages, I've fiddled with the Leap Motion in the hope of controlling my window manager, and I've started collecting other unique input devices such as a bluetooth EEG headset. Recently, I came up with an idea that is much more portable and requires little extra hardware. While I was chatting with one of my artistic friends, I started thinking more about how computer interfaces are becoming more physical and are trying to simulate real objects. Ubuntu and OS X's default scrolling behavior mimics pushing the page around instead of moving the scroll bar. Many types of scrolling have momentum, so if you swipe and release, it keeps going for a little while. The OS X trackpad gestures feel very much like you're trying to grasp what's on the screen. The newest version of iOS makes it easy to have interface elements bounce around relative to each other whenever the app is scrolled.

So, I came up with something from the other direction. Instead of trying to use a trackpad or a scroll wheel to manipulate objects on the screen that are acting physical, I'm working on a way to manipulate physical objects to control a computer. I decided get a deck of cards with QR codes and hook them up to some software I wrote that reacts when it sees a string from a QR code it recognizes.

Be the first to comment Read more
more recent articles