I often setup aliases, and other bash configurations, in my .bash_profile to make life easier. Though, sometimes I’m not so careful; I’ll set something up on one computer, but forget to do it on the other.

Sharing configurations across two computers is easy thanks to Dropbox. Here’s how:

1. Create a file in your Dropbox. I called mine .bash_profile_shared, and stored it in the root Dropbox folder, for consistency’s sake, but you can call whatever you like, and store it anywhere on Dropbox.
2. Edit your local .bash_profile file, and add this as the first line of your script: source ~/Dropbox/.bash_profile_shared, or whatever you named your shared Dropbox file.
3. Reload your Terminal, or source ~/.bash_profile

And, that’s it. Anytime you’d like to share a config, just add it the .bash_profile_shared file in Dropbox (and wait for it to sync).

UnacceptableVersionError: django 1.1 was requested, but 1.2.1.final.0 is already in use


Me too. After mucking around a bit, I’ve figured out an acceptable workaround:

First, download Django 1.1.1 and place it somewhere on your hard drive (I put mine on Dropbox, so that I could use this fix across multiple computers).

Then, modify your main.py from this:

import os, sys,logging
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'

from google.appengine.dist import use_library
use_library('django', '1.1')

To look like this:

import os, sys,logging
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'

if os.environ.get('SERVER_SOFTWARE','').startswith('Devel'):
    sys.path.insert(0, "/your/local/path/to/Django-1.1.1/")

from google.appengine.dist import use_library
use_library('django', '1.1')

Essentially, you’re telling App Engine that, when it’s in the Development environment (running on your local computer), it should prepend Django 1.1.1 to the system path. Then, a few lines down, when the App Engine SDK looks for Django, it will see that version first.

For my first project, I decided to play with Twitter’s direct message feature. The idea was simple: send me a direct message that included a time (number of minutes) and a message, and I would reply with a direct message when the specified time had expired. It was a sort of alarm clock…an egg timer…a timer. In May 2007, @timer was born.

Three years later, @timer is still actively used, with over 16,000 followers (you have to follow in order to direct message). Happy belated birthday, lil’ buddy.

On a related note, I’ve updated @timer to use OAuth (as of August 16th, Twitter will be shutting of basic authentication). I suppose this is a the real reason for the post, but the birthday wishes seemed overdue and appropriate. So, enjoy the new and improved @timer…

A lot.

In 2007, Jeff Skinner and I launched the now-defunct Tappity, a site which helped people discover mobile-friendly websites. The other day, I was perusing the Tappity innards and came across something interesting: a database table filled with unique User Agent strings from devices that had visited our site. For those not familiar with User-Agent Strings, they are a sort of fingerprint which helps identify a browser, so the database table represents a large sample of mobile browsers which have accessed Tappity.

The list doesn’t represent every device, nor are the strings exclusively mobile, but it does give you an idea of the diversity that exists in the mobile universe. For example, here are some top manufacturers alongside the number of browser applications/version. Note: Minor version numbers are counted as unique:

Motorola: 357
SonyEricsson: 351
Samsung: 341
Nokia: 300
LG: 169
BlackBerry: 125
HTC: 45

The full list of User-Agents can be viewed on Google Docs. Note: There are two worksheets: one with the raw strings from the database table, and another containing my attempt to identify unique application/version numbers.

1. Will my product require use of the camera, microphone or other device-specific hardware?
2. Will it access the address book, media library or common user data?
3. Will I charge for my product, using an app store as the payment processor?
4. Will I send push notifications or need background processes?

If the answer to any of the above is ‘yes,’ then an iPhone/Android app may be right for you. If the answer is ‘no,’ you may want to consider building an HTML5 mobile website instead.

Mobile websites:

• Can access geolocation info.
• Provide offline caching and storage.
• Handle touch and gesture events.
• Are easily deployed (new versions and bug fixes)
• Are cross-platform (Android, iPhone, webOS, etc.)

Comments and discussion: #NotAnApp

• Choose slide direction (left or right)
• Custom width slides
• Modal slides
• unobtrusive
• Mutiple slide definitions on the same page
• Fully supported with IE7+, FireFox 2+, Safari 2+
• Minified version included!

Link

Link

The widget that I created–TinyFinder–looks for rev=canonical links in a webpage, and displays them in the statusbar of the browser window. Rev=canonical links are meta tags that are used when a website wants to suggest a preferred tiny url to use. For example, the Flickr page (http://www.flickr.com/photos/srobbin/3533142101/) can also be accessed by Flickr’s own tiny url (http://flic.kr/p/6odh48). Of course, you could always use one of many url shortening services, but Flickr’s custom URL suggests what you’ll see on the other side of the redirect: a photo/movie. Several services are starting to employ their own custom tiny urls:  Dopplr, Threadless, Songza, and many more.

If the web page you are looking at does not provide its own tiny, custom URL, you can always click on the statusbar widget; one will be created for you and automagically copied to your clipboard.

Link

Link

Link