Although I had never been aware of the term “indie web” (which seems to have been around for almost 15 years, judging by this article from uzine.net), I’ve been building my own independent web presence for more than four years. In the words of the IndieWebCamp home page:

Rather than posting content on many third-party silos of content, we should all begin owning the content we’re creating. Publish short status updates on your own domain, and syndicate to Twitter. Publish photos on your own domain, syndicate to Flickr, etc, etc.

For some good summaries of the ideas and goals of the IndieWebCamp, this article from GigaOm and this post from Mark Hendrickson are a great place to start, while each of the camp’s guests also have their own websites, each with a wealth of information.

While I’ve been using this domain for quite a while, it’s been in use alongside Facebook, Delicious (and Flickr, to a smaller degree) as a part of my web presence. However, since I ditched Facebook five or six months ago, I’ve been relying on this domain for more, and overall I’ve been pleased. However, as the IndieWebCamp is readily willing to admit, there is room for a lot of room for technical innovation in expanding the functionality of the indie web. Towards that end, I see three threads of work that I’m interested in pursuing:

• Using my site for Flickr-like photo sharing. While this might include syndication to Flickr at some point, I mostly want a light-weight DIY solution to photo sharing.
• Similarly, using my site for bookmarking. I really like the service that delicious offers, but I want to own the data and let delicious simply keep a copy of it (see http://adactio.com/journal/4197/ for some ideas).
• Finally, I’m hugely enamored of the work on delivery-agnostic messaging that took place at IndieWebCamp, which you can find details of here. Not only is it a ridiculously simple protocol, but it starts to address some real issues of a distributed social web, in that it allows two-party communication based solely on domain names as unique identifiers, therefore eliminating the middleman in social-web-type communications.

Luckily, I quickly found out that GDAL ships with Python bindings. I installed GDAL from source using the instructions from their wiki. To make sure it built with Python modules I ran ./configure –with-python. After that make and sudo make install ran without a hitch.

I then set about re-implementing gdal_slice.sh in Python. Once I got a handle on how to use the Python bindings it was fairly easy to write. You can find the script here.

Using gdal_slice.py is very similar to using gdal_slice.sh:

$ ./gdal_slice.py -h
Usage: gdal_slice.py [options] FILENAME

Options:
  -h, --help            show this help message and exit
  -o OVERLAP, --overlap=OVERLAP
                        percentage tiles will overlap. should be at least 20%
  -a, --add             write map info to map_koord.txt in current working
                        directory
  -m, --map             use *_map folders for output; use if input image is
                        UTM. Default behavior
  -t, --topo            use *_top folders for output; use if input image is
                        not UTM
  -v, --verbose         enable debugging output

The biggest difference is that gdal_slice.py does not perform any format conversion; it will write maps to TIFF files. Although the file size is decidedly larger than that of PNGs, my version of GDAL is unable to create PNGs, and disk space is (fairly) cheap. If I’m motivated I’ll get around to adding a format option, at least to allow conversion to PNG.

Running gdal_slice.py filename.ext will create a folder named filename_map (or _top, if you use the -t flag) that contains a set of 1280×1024 TIFF files, as well as a map_koord_draft.txt file. Moving this folder into GPSDrive’s map directory, and merging filename_[map|top]/map_koord_draft.txt with map_koord.txt will make the new maps available to GPSDrive. Note that filename.ext must be in the current working directory, as the script handles filenames/paths somewhat naivëly.

So far I’ve only tested this with GeoTIFFs from LibreMaps, but it seems to work great, with the caveat that LibreMaps’ files include the borders of map, and my script doesn’t do any cropping, so you see borders if you’re near the edges of quads. This doesn’t bother me terribly much, but you may need to turn mapsets on and off in the Map Control dialog to see the appropriate images.

Update 7-14-11: I’ve modified the script with an additional flag (-a) that will automatically merge the generated map_koords file with map_koord.txt in the current working directory. This means that if you run the script from inside .gpsdrive/maps with the -a flag the generated tiles will be automatically added to GPSDrive’s database. The script avoids creating duplicate entries in map_koord.txt, as well as alphabetizing all entries.

I’ve modified the documentation here, as well as the links, to reference the latest version.

To get GPSDrive running I had to do a little bit of fiddling, but it’s fairly easy. First off, I needed to downgrade GPSd from 2.96 to 2.95 — apparently the newest version introduced slight changes to the library that GPSDrive hasn’t yet picked up. However, building the two versions is exactly the same — see my post on building 2.96 for instructions that apply to 2.95. You can get the source package for either version here.

Next I used homebrew to install the dependencies that GPSDrive needs by running brew install gtk+ cairo gtkglext postgresql gettext. Note that these are just the packages I didn’t have going into the build — you may need more, depending on your setup.

With preliminaries out of the way, I downloaded gpsdrive-2.11 from here. As per their build instructions I created a build directory (mkdir build), moved into it (cd build), and then ran cmake. After some serious wrestling with dependency locations and linker flags I figured out the following two steps to get GPSDrive to compile and build.

First, because GPSDrive seems to want to automatically link against libcrypt, which OS X bundles in it’s libc, you need to tell cmake not to use it. I couldn’t figure out how to do with with a cmake configuration option, so I edited gpsrive-2.11/src/CMakeLists.txt and commented out (put a # in front) of the two lines containing the word “crypt”. You could also delete these lines — it has the same effect. This is along the lines of the patch here (see the attachment), that was posted to the GPSDrive mailing list last year, when I pointed out this bug. Sadly, the patch has not been applied to the source tree yet, but I can attest it works, if you care to apply it yourself.

With that out of the way, we can now run the following command from inside the build directory.

cmake -DCMAKE_BUILD_TYPE=Debug\
 -DWITH_FRIENDSD=OFF\
 -DWITH_KISMET=OFF\
 -DWITH_MAPNIK=OFF\
 -DWITH_POSTGIS=OFF\
 -DWITH_SPEECH=OFF\
 -DLIBGPS_OLD=OFF\
 -DGTK2_ATK_INCLUDE_PATH=/usr/local/Cellar/atk/2.0.0/include/atk-1.0\
 -DGTK2_GLIBCONFIG_INCLUDE_PATH=/usr/local/lib/glib-2.0/include\
 -DGTK2_GLIB_INCLUDE_PATH=/usr/local/include/glib-2.0\
 -DGTK2_PANGO_INCLUDE_PATH=/usr/local/Cellar/pango/1.28.4/include/pango-1.0\
 -DGTK2_CAIRO_INCLUDE_PATH=/usr/local/Cellar/cairo/1.10.2/include/cairo\
 -DGTK2_GDKCONFIG_INCLUDE_PATH=/usr/local/Cellar/gtk+/2.24.4/lib/gtk-2.0/include\
 -DGTK2_GTK_LIBRARY=/usr/local/lib/libgtk-x11-2.0.0.dylib\
 -DCMAKE_C_FLAGS="-I/usr/local/Cellar/gdk-pixbuf/2.22.1/include/gdk-pixbuf-2.0"\
 -DCMAKE_EXE_LINKER_FLAGS="-lgdk_pixbuf-2.0.0 -lpango-1.0.0 -lgobject-2.0.0 -L/usr/local/Cellar/gettext/0.18.1.1/lib -lintl"\
 -DMSGFMT_EXECUTABLE=/usr/local/Cellar/gettext/0.18.1.1/bin/msgfmt\
 ..

After cmake generates all the necessary files, you can run make, and assuming it doesn’t give you errors, ./src/gpsdrive will allow you to test your newly built executable, and sudo make install will install it.

Once GPSDrive is up and running you should be able to see your current location (assuming you have a GPS connected to GPSd). If you want to get maps, you can download them from within GPSDrive, which has support for OpenStreeMap tiles, as well as NASA Landsat images (although I haven’t been able to get Landsat to download correctly).

Cryptonomicon

Randall Lawrence Waterhouse

Current meatspace coordinates, hot from the GPS receiver card in my laptop:

8 degrees, 52.33 minutes N latitude 117 degrees, 42.75 minutes E longitude

Nearest geographical feature: Palawan, the Philippines

(from http://www.euskalnet.net/larraorma/crypto/slide51.html)

Using GPSd’s python bindings, and the free, CC-licenced RESTful API from GeoNames.org, I wrote a short python script that will produce a similar output:

Seth Just

Current meatspace coordinates, hot from the GPS receiver card in my laptop:

41.751 N latitude, 111.807 W longitude

Nearest geographical feature: Logan Canyon, Utah, United States

The core of the script is two functions — one that gets GPS coordinates from GPSd, and a second that does a lookup for geographical features (mountains, canyons, islands, etc) on GeoNames.org. For more details, see the final section of this post.

Using gpssig.py

To use gpssig.py, first download it from here, and change the extension to .py.

In order to be useful as an email signature, I had to produce output in HTML format, which allows almost any mail client to use the output as a signature. I’ve gone through the effort of setting it up with the two clients I use the most: Mozilla Thunderbird and Apple’s Mail.app. Of these two, Thunderbird has documented support for HTML signatures (see here for details), and should be the most like other email clients. This script has been tested on Mac OS X Snow Leopard, and should run on Linux without problems (although I haven’t tried it on versions of python higher than 2.6.1).

Using gpssig.py takes two steps: first configure your Mail client to take a signature from a file, and then configure gpssig.py to run automatically to update that file.

Thunderbird is relatively easy to set up with an HTML signature. Because it only supports one signature per account, you simply need to tell it to draw that signature from a file. Under each account’s settings there’s an option to “Attach the signature from a file” (see here for a detailed howto). I chose to use ~/.signature.html, but you can use any file you’d like to, just remember the location you choose.

Mail.app is a more finicky beast — although the script supports it, I recommend using Thunderbird, mainly because Mail only refreshes its signatures from files on every launch, whereas Thunderbird will read the file each time you compose a message. However, if that limitation is acceptable (if you don’t move very much, perhaps), it will work just fine. The main issue with Mail.app is that it doesn’t store signatures in an HTML file, but instead in the proprietary .webarchive format. These files can be found in ~/Library/Mail/Signatures. To use gpssig.py with Mail, you need to follow steps 4&5 from http://bytes.com/topic/macosx/insights/825900-setup-html-signatures-apple-mail-mail-app. First create a new signature (under Preferences->Signatures). This will create a new file in the signature folder — take note of the file name. You will use this file name to configure gpssig.py.

gpssig.py is configured with command line options:

Usage: gpssig.py [options] NAME FILENAME
Note: NAME should be enclosed in quotes, unless it contains no spaces.

Options:
  -h, --help   show this help message and exit
  --no-gps     don't attempt to get coordinates from GPS
  -a, --amail  generate files for Apple's Mail.app (.webarchive)
  --lat=LAT    default latitude, if GPS is unavailable
  --lon=LON    default longitude, if GPS is unavailable

The simplest way to use it is manually — simply running it whenever you want to update your signature. For example, I use ./gpssig.py –lat=41.752 –lon=-111.793 ‘Seth Just’ ~/.signature.html to generate a signature for Thunderbird.

If you want to make this automatic, you’ll need to have the script run automatically. On OS X you’ll need to use launchd, while on linux you need cron. Both of these make setting up repeating actions very easy — see here for information on launchd and here for information on cron.

Sadly I haven’t yet figured out a way to run the script whenever you write an email — if I figure it out, I’ll be sure to post something.

The Script

gpssig.py is built around three major functions — one gets coordinates from GPSd, one gets geographical feature information from

The function I use to get GPS information is a bit hacky — there doesn’t seem to be terribly much documentation on GPSd’s python bindings, so I made do with what I could figure out:

class NoGPSError (Exception): pass
 
def get_lat_lon():
  # GPSd Python bindings
  import gps
 
  # Create GPS object
  session = gps.gps()
 
  # Set GPS object as an iterator over reports from GPSd
  session.stream(gps.WATCH_ENABLE|gps.WATCH_NEWSTYLE)
 
  # Loop until we get a report with lat and lon. The limit of 5 loops should be more than enough -- my gps never takes more than three when it has a lock
  i = 0
  while (1):
    try:
      session.next()
      lat, lon = session.data['lat'], session.data['lon']
      break
    except:
      if (i > 5): raise NoGPSError 
      i += 1
 
  return lat, lon

The other function is more straightforward — it makes two http requests to GeoNames.org to get the nearest geographical feature and locality. It then combines those responses in a way that should provide a good response almost anywhere in the world (provided that GeoNames has good, local data). I’ve tested it with a variety of coordinates (provided by http://www.getlatlon.com/), and the responses seem to be pretty good.

def get_geo_string(lat, lon):
  # Modules for REST/XML request from GeoNames
  import urllib
  from xml.etree import ElementTree as ET
 
  # Request the name of the nearest geographical feature
  placename = ET.parse(
      urllib.urlopen("http://api.geonames.org/findNearby?lat=" + str(lat) + "&lng=" + str(lon) + "&featureClass=T&username=sethjust")
      )
  subdiv = ET.parse(
      urllib.urlopen("http://api.geonames.org/countrySubdivision?lat=" + str(lat) + "&lng=" + str(lon) + "&username=sethjust")
      )
 
  # Format and return place, region, country
  try:
    country = subdiv.getiterator("countryName")[0].text
  except:
    try:
      country = placename.getiterator("countryName")[0].text
    except:
      country = ''
  try:
    region = subdiv.getiterator("adminName1")[0].text
  except:
    region = ''
  try:
    name = placename.getiterator("name")[0].text
  except:
    name = ''
 
  if country:
    if region:
      if name:
        result = "%s, %s, %s" % (name, region, country)
      else:
        result = "%s, %s" % (region, country)
    else:
      if name:
        result = "%s, %s" % (name, country)
      else:
        result = country
  else:
    result = "unknown"
 
  return result

Finally, the main method of the program parses arguments, determines what coordinates to use, gets the geographical feature string, and then generates the proper HTML and copies it into the correct place.

if (__name__ == "__main__"):
  # Parse command line options
  from optparse import OptionParser
  parser = OptionParser("Usage: %prog [options] NAME FILENAME\nNote: NAME should be enclosed in quotes, unless it contains no spaces.")
  parser.add_option("--no-gps", action="store_true", dest="nogps", default=False, help="don't attempt to get coordinates from GPS")
  parser.add_option("-a", "--amail", action="store_true", dest="amail", default=False, help="generate files for Apple's Mail.app (.webarchive)")
  parser.add_option("--lat", action="store", type="float", dest="lat", help="default latitude, if GPS is unavailable")
  parser.add_option("--lon", action="store", type="float", dest="lon", help="default longitude, if GPS is unavailable")
 
  options, args = parser.parse_args()
 
  try: assert(len(args) == 2)
  except AssertionError:
    print "You must provide NAME FILENAME\n"
    parser.print_help()
    exit()
 
  try: assert(((options.lat!=None) & (options.lon!=None)) | ((options.lat==None) & (options.lon==None)))
  except AssertionError:
    print "You must provide both lat and lon arguments\n"
    parser.print_help()
    exit()
 
  # Modules for creating signature file
  import tempfile, os
 
  try:
    if (options.nogps): raise NoGPSError
    lat, lon = get_lat_lon()
    print "Got %f, %f from gps" % (lat, lon)
  except NoGPSError:
    if (not options.nogps): print "Failed to get coordinates from GPS"
    try:
      assert((options.lat!=None) & (options.lon!=None))
    except AssertionError:
      print "No default coordinates provided; exiting"
      exit()
    lat, lon = options.lat, options.lon
    print "Using %f, %f as coordinates" % (lat, lon)
 
  geostring = get_geo_string(lat, lon)
 
  lac, loc = 'N', 'E'
  if lat < 0:
    lat *= -1
    lac = 'S'
  if lon < 0:
    lon *= -1
    loc = 'W'
 
  file = tempfile.NamedTemporaryFile()
 
  file.write("<html><body>\n<p>")
  file.write(args[0])
  file.write("</p>\n<p>")
  file.write("Current meatspace coordinates, hot from the GPS receiver card in my laptop:")
  file.write("</p>\n<p>")
  file.write("%.3f %s latitude, %.3f %s longitude" % (lat, lac, lon, loc))
  file.write("</p>\n<p>")
  file.write("Nearest geographical feature: " + geostring)
  file.write("</p>\n")
  file.write("</html></body>\n")
 
  file.flush()
 
  if (options.amail):
    os.system("textutil -convert webarchive -output " + args[1] + " " + file.name)
  else:
    os.system("cp " + file.name + " " + args[1])

Two and a half years ago, GPSd had just released version 2.38. The latest version, which I just downloaded, is 2.96. Most significantly, GPSd has updated their communication protocol from a simple character-command format to one based on JSON-packed data. Further, they’ve built a significant portion of the project around python, and consequently built better python interfaces into the project.

OS X has also been updated, from whatever 10.5.x was current three Januaries ago, to 10.6.8. Luckily, the under-the-hood changes that Snow Leopard brought to the table should only make compiling software easier.

Building GPSd is a whole lot easier than it was the last time I went through all of this. I downloaded the latest source package (from http://prdownload.berlios.de/gpsd/gpsd-2.96bis.tar.gz). The bundled INSTALL file lists only python and py-gtk2 as dependencies, which makes compilation easy, given that python comes bundled with OS X. Although py-gtk2 is available through MacPorts (using sudo port install py-gtk2) I chose to avoid install the ridiculously long list of dependencies that it requires, as it is only required for the graphical test client (xgps), and GPSd also ships the perfectly functional command-line tool cgps, which provides the same information, albeit in a more sparse manner.

The actual build process is surprisingly easy: I ran ./configure –x-includes=/usr/X11R6/include, as suggested by the INSTALL file. As this indicated no issues, I ran make and sudo make install, which ran without a hitch, and gave me a working set of gps tools.

At this point it is possible for me to attach my GPS (see my old post for information about getting devices up and running), run gpsd -n /dev/cu.usbserial, and then use cgpsto get coordinates, date, and satellite information. However, this isn’t everything — all of the python based GPSd tools, such as gpsprof, still don’t work. This is because of Apple’s slightly special python distribution — while GPSd’s sudo make install puts python modules into /usr/local/lib/python2.6/site-packages/, they need to be in /Library/Python/2.6/site-packages/. Instead of having to install these manually, you can use the bundled python install script to put the modules in the correct path by running sudo python setup.py install (thanks to http://docs.python.org/install/index.html).

Now that I have the most recent GPSd up and running I’m hoping to do some fun things with it. If I do, you’ll see it here!

I noticed that I was able to load the website just fine in Safari, and that’s when I had an insight — I noticed that Safari was loading http://grooveshark.com, while Chrome was taking me to https://grooveshark.com. It turns out that the issue was with a plugin I use — the KB SSL Enforcer. While it’s a great piece of software, it was forcing Chrome to connect to the SSL site, which for some odd reason was causing the blank page to be displayed.

The fix for this issue was easy. I just opened up the SSL Enforcer options and added grooveshark.com to the blacklist; telling the plugin to never force SSL for Grooveshark.

Now I’m happily listening to tunes online without having a second browser open!

In September 2010, Hans Viksler posted an article about the insecurity of the stored-value smart card system used by Web Laundry (now Wash Laundry). I’ll let that article stand on its own — it gives a good overview of the bone-headed system that the engineers there had in place. In short, they used a secure memory card made by Atmel (specifically, from the CryptoMemory line), the AT88SC0404C (datasheet here), but neglected to change the default master password. This means that all you need to read or write the stored data is a ISO-7816-3 compliant smart card reader.

This is where my story starts — this summer I’m living in a dorm that uses a Web Laundry stored value system. That was enough of a push for me to buy a smart card reader, seeing as I’d always wanted to play with them, and this looked like a good opportunity. I picked up a smart card reader from Amazon.com, an SCM Microsystems SCR3310. It was both cheap and, according to the manufacturer’s product page, offers full ISO 7816, CCID and PC/SC compatibility (i.e. all of the relevant standards), as well as drivers for OS X, which is my primary operating system for the time being.

Doing some research, it turns out that Apple ships a (modified) version of the open-source PCSC Lite framework for smart card integration. This means that all I would need to get up and running was a driver for my device and a way to interface it. Once the reader arrived I installed the drivers, and ran pcsctest (from PCSC Lite) on the command line. Sadly, all I got was an error message:

Testing SCardEstablishContext    : Service not available.

Googling told me that the appropriate services are supposed to start whenever a smart card reader with appropriate drivers is plugged in, which made this error all the more confusing. Luckily, I found this thread on SCM’s forums — it seems that the driver they have posted doesn’t include the USB identifiers for the version of the reader I had, but a helpful poster left instructions to modify a plist file in the driver (mirrored here for archival purposes). With that, I was up and running!

pcsctest spat out useful output this time around:

$ pcsctest

MUSCLE PC/SC Lite Test Program

Testing SCardEstablishContext    : Command successful.
Testing SCardGetStatusChange
Please insert a working reader   : Command successful.
Testing SCardListReaders         : Command successful.
Reader 01: SCM SCR 3310 00 00
Enter the reader number          : 1
Waiting for card insertion
                                 : Command successful.
Testing SCardConnect             : Command successful.
Testing SCardStatus              : Command successful.
Current Reader Name              : SCM SCR 3310 00 00
Current Reader State             : 0x34
Current Reader Protocol          : 0x0
Current Reader ATR Size          : 8 (0x8)
Current Reader ATR Value         : 3B B2 11 00 10 80 00 04
Testing SCardDisconnect          : Command successful.
Testing SCardReleaseContext      : Command successful.

That left me with the issue of interacting with the smart card somehow. In case you hadn’t guessed from the post title, that solution was Python. Specifically, the pyscard bindings for PCSC Lite, from pyscard.sourceforge.net. There’s a nice array of examples, and so I wrote up a python script for interacting with this particular CryptoMemory card, based on the command set from the datasheet and the examples. It’s not as polished or feature-rich as the software Hans posted, but if you’re running OS X or Linux, it should be helpful. At the moment this script is extremely rough — it gets the job done, but in an ugly and unsafe way. I’m posting it here, but you SHOULD NOT USE IT IF YOU DON’T KNOW WHAT YOU’RE DOING. If you aren’t careful, it will mess up your card. Hopefully I’ll have time to wrap it all in a library that will abstract away the messiness and provide nice features like exception handling; if I do, you’ll see it here.

Using my script I was able to verify Hans’ findings — although the card is configured to require cryptographic authentication to access the user zones (where the goodies can be found), the password is left at the default value, which makes overwriting the access registers and conducting a replay attack (as demonstrated by the video in his post) a walk in the park. Following his example, I won’t post any information on how the cards store their values, but it’s surprising that this security hole still isn’t fixed, seeing as it would cost nothing to overwrite the master password when they first configure the cards.

Hopefully this post will give some of you who’ve wanted to work with smart cards a push in that direction — although there are a few hurdles along the way, it’s an interesting area to work on. I’m hoping to move on from poking at other people’s cards and start using my new hardware for authentication and encryption.

Happy hacking!

Get the code here.

$ time python mandel.py > \dev\null
real	0m0.051s
user	0m0.036s
sys	0m0.010s
$ time perl mandel.pl > \dev\null
real	0m3.518s
user	0m3.463s
sys	0m0.029s

You can find the code here.

This script works well for zooms, as long as you stay below a few thousand iterations. The following picture was generated with x=-1.1887204, y=-0.3032472, width=0.01 and 150 iterations.

After the jump, I’ll give you the code and explain how it all works.

How it Works:

The code from ~/.conkyrc that makes this calendar is simple:

Edit: I’ve updated the code as Zacco suggested in the comments to fix a minor bug on certain dates.

${color orange}CALENDAR ${hr 2}$color
${execpi 60 DJS=`date +%_d`; cal | sed s/"\(^\|[^0-9]\)$DJS"'\b'/'\1${color orange}'"$DJS"'$color'/}}

This is a somewhat complicated expression, but what it does is fairly simple. The first line simply draws the title for the section, and it’s the second line that does the magic. Let me break it down and explain it.

${execpi 60

This command tells Conky to execute the next argument every 60 seconds, and, importantly, parse the output of that argument. This way, when we put in commands that change the text color, Conky will obey them instead of printing them.

DJS=`date +%_d`;

DJS (which stands for “date” followed by my initials) is a temporary variable that holds the current day of the month, padded with a leading space, if necessary (so that we’ll catch the first of the month, not every 1 in the calendar, for example).

cal |

cal simply prints out a simple calendar, and the pipe feeds that output through to the next commmand:

sed s/"\([^0-9]\)$DJS"'\b'/'${color orange}'"$DJS"'$color'/

This is one big mess of a command, but the main body is a regex that sed takes as an argument. The regex searches for the string “\([^0-9]\)$DJS”‘\b’, which means the contents of the variable DJS (which we set earlier) preceded by anything other than a digit, and followed by a word boundary – a change from printable characters to white space. This means that it will find the current date (one or two digits) but won’t find the 3 of the 30th on the third of the month. It also means that it will work correctly if the current date is on the far left or right column of the calendar.

The second half of the regex simply wraps what it found the first time around in a couple of Conky commands that change to color to orange, and then back to what it was before.

Lastly, the closing bracket (}) at the end of the line closes out the opening one that is required for all Conky commands with arguments.

Now go forth and cover your desktop in beautiful calendars.

Update: Erik in the comments has a modification to center the entire calendar, if left-aligning isn’t for you.

So I recently picked up a cheap GPS module on Amazon. It was about $30 with shipping, and I got a neat little dongle which connects over USB to my computer and communicates with software. It didn’t come with support for OS X (although interestingly enough it shipped with Mac OS 8 and 9 drivers), but it promised to send generic NMEA-0183, so I wasn’t too worried.

When it showed up, some quick software probing revealed that it houses a usb to serial adaptor (a Prolific PL-2303, which I’ll get to in a bit) and a gps module that’s configured to send NMEA strings through the virtual serial port. This sort of information is compatible with a host of software, but most of it is commericial, and only available at a considerable price.

Luckily, there’s a wonderful open source project called gpsd which provides support for a wide raft of devices and protocols, and talks to an even wider assortment of software. Primarily, I wanted to be able to get my gps to talk to the network scanner Kismac, and Randall Munroe’s cyborg.py script. Both of these were built to take information from gpsd, so I was in business. However, gpsd, which is designed to play nicely with Linux, takes some coaxing under OS X. This is meant to describe how I got it all running.

I. Hardware driver

Because the gps relies on a usb-to-serial chip to talk to the computer, it needs a driver that will emulate a serial port. The chip in my gps revealed itself as a Prolific PL-2303, a common chip that I’d had previous dealings with, and so had a driver for. This enabled me to see a serial device on my system and read raw data from it:

sethjust$ ls /dev/cu.*
/dev/cu.Bluetooth-Modem		/dev/cu.Bluetooth-PDA-Sync	/dev/cu.PL2303-0000101D
sethjust$ stty -f /dev/cu.usbserial ispeed 4800 && cat </dev/cu.usbserial
,,,3.6,2.2,2.8*3E
$GPRMC,060645.994,A,4537.5498,N,12259.8000,W,000.0,327.4,120109,,,A*70
$GPVTG,327.4,T,,M,000.0,N,000.0,K,A*0F
$GPGGA,060646.994,4537.5498,N,12259.8000,W,1,06,2.2,137.3,M,-21.5,M,,0000*63
$GPGSA,A,3,23,25,13,04,32,20,,,,,,,3.^C

This driver also played nicely with some of the commericial software demos I’d downloaded, but oddly enough it didn’t work with gpsd. Eventually, after some debugging and consulting with one of gpsd’s developers via IRC, I replaced the driver I had (an open source replacement for proprietary driver) with the driver from Prolific’s website. Supposedly the open-source PL-2303 driver doesn’t play nicely with gpsd, and so they recommend using Prolific’s.

II. gpsd and gpsdrive

The gpsd package comes with several useful support utilities, but one that it doesn’t include is gpsdrive, a wonderful program that supports mapping and live data from gps. Getting both running under OS X is a little difficult, but I found a great document here that explains the process. A little has changed, so here’s how I got it working (though I never did get xgps or xgpsspeed to compile…):
1) Install fink if you haven’t already.
2) Install gpsdrive through fink:

$ fink install gpsdrive

3) Rename /sw/bin/gpsd to gpsd-1.06b:

$ sudo mv /sw/bin/gpsd /sw/bin/gpsd-1.06b

4) Download the latest source for gpsd. I used the latest RC for their upcoming 2.38 release and have had no problems.
5) In the gpsd source directory, run ./configure with whatever options you’d like. The earlier document had some suggestions on getting it to see X11 libraries, but I haven’t been able to make them work. I ended up using

$ ./configure --bindir=/usr/local/bin -without-x

6) Compile the software by typing “make”. You can then either install it with “sudo make install” or test it before installing:

$ ./gpsd -n /dev/cu.usbserial
$ ./cgps

In my case /dev/cu.usbserial is the device representing the PL-2303. You should replace this with your own.

Running cgps should show a live summary of the information that gpsd is getting, along with a running log of the raw data coming from the gps. You can also test gpsd by telnetting to localhost:2947, typing w and hitting enter. You should see NMEA strings from the gps.

III. Kismac and cyborg.py

The original reason that I embarked on this gps adventure was to use two programs: Kismac and Randall Munroe’s cyborg.py. Kismac is easy to get running with gpsd – once you have gpsd running (e.g. gpsd -n /dev/cu.usbserial), open Kismac and set it to use gpsd for map coordinates. It should display your location on the map screen, and associate coordinates with APs.

cyborg.py is a little harder to get running. It’s dirty (though entirely functional) code that isn’t fully mac compatible. Notably, it uses two programs (flite and figlet) that are iffy under OS X. I patched that up, replacing flite with OS X’s built-in “say” command, and commenting out the figlet bits (which display large text) in favor of the terminal output the script gives. The modified script works beautifully, although I didn’t clean up the code at all. You can get it here.

IV. Links

• gpsd
• gpsdrive
• Kismac
• Randall Munroe’s cyborg.py
• Post by Hashim on the gpsdrive mailing list
• Prolific PL-2303 and driver
• PL-2303 Alternative Driver
• Getting maps in gpsdrive
• My gps

To start, installing Finance::Quote is a breeze. As long as you have CPAN installed, just type at the command line:

$perl -MCPAN -e shell
>install Finance::Quote

From there it’s easy to get start, it’s just a matter of importing the module and creating and instance. This means the beginning of our script will look like:

#!/usr/bin/perl -w
use strict;
 
# import module
use Finance::Quote;
# create object
my $q = Finance::Quote->new();

The instance that we created has one main method: fetch(). It takes a list of arguments, with the first being a the exchange to look for quotes on, and the remaining being a list or array of ticker symbols. The Finance::Quote documentation provides the following list of valid exchanges:

australia           Australan Stock Exchange
dwsfunds            Deutsche Bank Gruppe funds
fidelity            Fidelity Investments
tiaacref            TIAA-CREF
troweprice          T. Rowe Price
europe              European Markets
canada              Canadian Markets
usa                 USA Markets
nyse                New York Stock Exchange
nasdaq              NASDAQ
uk_unit_trusts      UK Unit Trusts
vanguard            Vanguard Investments
vwd                 Vereinigte Wirtschaftsdienste GmbH

For the purposes of this script, I’m going to stick to “usa” because it covers both NYSE and NASDAQ, and those are the stocks I’m interested in.
Fetch() returns a two-dimensional hash of results. The first index (or dimension) is the ticker symbol of the stock and the second is the label for the specific piece of information. For now, the labels that we’re interested are the name of the company (‘name’) and the price (‘price’). A full listing of labels is available in the Finance::Quote documentation.
Using this information we can now build a simple script to fetch a stock quote:

#!/usr/bin/perl -w
use strict;
 
# import module
use Finance::Quote;
 
# create object
my $q = Finance::Quote->new();
 
# retrieve stock quote
my %data = $q->fetch('usa', 'GOOG');
 
# print price
print $data{'GOOG', 'price'} . "\n";

This script, although it does what it’s supposed to, isn’t very pretty. By adding a little code to read ticker symbols from the command line we can check on multiple stocks at the same time, as well as remove the need to hard-code the ticker symbols. We can also make it produce much prettier results by adding more information about the company and add some basic error checking, which yields the following script:

#!/usr/bin/perl -w
use strict;
 
# import module
use Finance::Quote;
 
# create object
my $q = Finance::Quote->new();
 
#print usage information
if (length(@ARGV) == 0) {
	print "Usage: $0 ticker1, ticker2, ... , tickerN\n";
	exit;
}
 
# get stock symbols from the command line and
# format them correctly (uppercase)
for (@ARGV){
	$_ = uc();
}
 
# retrieve stock quote
my %data = $q->fetch('usa', @ARGV);
 
# print result for each stock
for (@ARGV){
	if ($data{$_, 'success'}) {		# if getting the quote succeeded
		my $name = $data{$_, 'name'};	# build a report
		my $price = $data{$_, 'price'};
		my $message = '';
		$message .= $name . ' (' . $_ . ')';
		$message .= ' ' x(25 - length($message));
		$message .= "$$price\n";
		print $message;
	}
	else { print "Failed to retrieve quote for $_: $data{$_, 'errormsg'}\n"; }
}

This is very simple, but it does its job well:

$ quote goog msft aapl dell java
GOOGLE (GOOG)            $352.32
MICROSOFT CP (MSFT)      $22.32
APPLE INC (AAPL)         $98.23
DELL INC (DELL)          $11.99
SUN MICROSYSTEMS (JAVA)  $4.54

Download the script here

In the last couple weeks, at least four people have asked me how to get music off of their iPods. The answer I gave all of them was Senuti (iTunes spelled backwards). It’s great! It does exactly what you need: takes songs from your iPod and puts them into iTunes, and it’s super easy to do. Once you have disk use enabled:

To copy songs back to your computer, all you have to do is select the songs and click the transfer button in the upper left hand corner of the application.

The songs will be copied to the your computer. They will be added to iTunes if you enabled the preference to automatically add them to iTunes.

It’s just that easy.

Of course, Senuti isn’t just a one trick pony, it can do other useful things as well, such as copying songs to a folder, or showing you what songs you already have in your iTunes library, and allowing you to hide them, so that you only transfer new songs.

So next time you feel like IM’ing me about how to get songs off of your iPod, remember Senuti, and save my sanity just a little bit.

I’m afraid that Apple’s new products and schedules are clashing with their characteristic way of doing business. In the past they were able to wait until a product was just perfect before releasing it. Now, with their partnerships and such, at least with the iPhone, Apple is forced to announce their products earlier, and so they have much stricter deadlines to meet, which begs the question “Can Apple keep this up and still deliver the same quality product they have in the past?”