Archive for June, 2008

Yahoo! GeoPlanet API makes backwards-incompatible change, keeps it secret?

Published on June 28, 2008 in APIs and Development. 2 Comments

I just noticed that the Yahoo! GeoPlanet API made an API change to its JSON API that breaks existing apps. (I noticed because it broke the sign-up process for the new Singularity teaser site.)

Googling around, I couldn't find any announcements from Yahoo! about this. I don't know if there's a notification feed somewhere that I'm missing -- if so, I'd appreciate it if someone could point me in the right direction. Otherwise, in case any other developres are using the Yahoo! GeoPlanet JSON API and are affected by this, here's a summary of the change from the post I just made on the yws-geo forum:

I just realized that you removed the 'place' array from the JSON object returned from places.q() calls (e.g., of form http://where.yahooapis.com/v1/places.q('city
name');count=0?format=json) and that the returned places object now has the
place indices as strings.

This requires code to be changed from, for example, result['places']['place'] to result['places'] and also requires that numeric indexed loops be changed to use string indices.

It's quite baffling that a change like this (which, really, isn't even necessary) was made and not communicated. Even more so considering that the API is versioned properly (you access it from /v1/), so a change like this should really have gone into (/v2/).

I would love to hear from someone on the Yahoo! GeoPlanet team about the rationale behind this change and where we can find out about similar changes in the future.

I love the Yahoo! GeoPlanet API -- it is awesome and very simple to work with -- but please, guys, pay a bit more attention to backwards compatibility, communicate better, and don't break existing apps! :)

On online security and password policies

Published on June 27, 2008 in Security. 14 Comments

Writing the post on del.icio.us's password policy got me thinking about passwords and online security again.

Having a strong password policy such as "passwords must be longer than six characters and must contain a number or a symbol and a mix of uppercase and lowercase characters" is great in theory but let's take a moment to follow Joe User as he encounters such a policy and chooses his password:

Joe User: Ah, it won't let me use my normal password, I need to create a new one... ok, done!

Joe User: Hmm, I'm never going to remember this, let me just write it down on this Post-it note.

Joe User: Better not lose this, let's stick it on my monitor.

Joe User: Cool, now that's done, I can leave for lunch.

See the problem?

The weakest link in online security is not password strength but the human being who owns the password. Having a complicated password policy that enforces strong passwords may actually become a security issue if it results in the user writing her password down to remember it as that becomes the weakest link in the chain. (By the way, this isn't fiction, I’ve actually seen passwords on Post-it notes stuck to monitors — good, honest, strong passwords — completely compromised.)

It's a balance, for sure, but not always between security and usability as it is often portrayed. It's a balance between security and security. Specifically, beyond a certain point, increasing the complexity of password policies may actually start compromising the overall security of the whole system where the user, not the password, is the weakest link.

It's also a matter of psychology. Different applications handle data of varying sensitivity and users have varying expectations of what comprises adequate security. You expect a bank to have a strong password policy. Twitter? Not really.

Usability, of course, is also a very important consideration. There are some applications where you spare nary a thought for the authentication system, it just works and stays out of your way. Yet there are others were it seems you are always filling out the forgotten password form. Guess which ones users like more.

Two ways to change your business’s name on PayPal…

Published on June 27, 2008 in Payment systems. 0 Comments

First way:

Call their premium 0870 support number and pay £??? to be told that they will send you an email with instructions on the procedure which involves sending them a fax then proceed to wait several days for said email without success.

Second way:

Sign in to your PayPal account, go to the Contact Us - My Account Profile - Name Change page in their help system, select Business Name Change, and enter your business's new name in the form, click submit, and Bob's your uncle.

Hope this saves someone else a little bit of time.

I found out about this thanks to this very helpful page -- thank you for sharing.

SVN commit failed error

Published on June 25, 2008 in Source Control and Project Management. 5 Comments

After running through a lot of merges last night (I was incrementally going through several changesets to see where I'd introduced an interesting regression) and updating to the HEAD revision and fixing the bug, I got the following error message while trying to commit:

svn: Commit failed (details follow):
svn: Your file or directory 'paypal.py' is probably out-of-date
svn: The version resource does not correspond to the resource within the transaction.  Either the requested version resource is out of date (needs to be updated), or the requested version resource is newer than the transaction root (restart the commit).

A svn up didn't fix the issue and neither did running svn clean.

The file in question is in a folder called /lib so in the end, I fixed it by deleting that folder (rm -rf lib) and then running svn up to restore the folder from the HEAD revision.

The only other advice I found about this on the net suggests that you delete the all-wcprops file in your .svn folder but I personally think that that's a Bad Idea (tm) as you don't want to go messing inside your .svn folders and corrupt your working copy.

electricrain Swift3D on Pistach.io

Published on June 25, 2008 in Pistach.io. 1 Comment

Swift 3D

electricrain, makers of Swift3D, the popular 3D software for Flash, have just started advertising on the Pistach.io Flash Pack.

Swift3D Version 5 runs on both Mac and Windows and has native support for Papervision3D so you can export your 3D models as Papervision3D objects and start manipulating them in realtime in Flash.

Register your interest if you would like to advertise on the Pistach.io Flash Pack.

Buying an ad on the Pistach.io Flash Pack puts your ad on all of the following web sites: Andre Michelle, Aral Balkan, Chad Udell, Flash Magazine, Grant Skinner, Keith Peters, Marco Casario, Mario Klingemann, OSFlash, Peter Elst, and Seb Lee-Delisle.

Find out more on the Pistach.io web site.

Use promo code ABALW5 to get 5% off the price of your Pistach.io ad.

stu.pid.us password usability is.su.es

Published on June 25, 2008 in Security and Usability Design. 14 Comments

Hmm, I need to log in again to del.icio.us after clearing out my passwords. I wonder why my regular passwords don't work... oh well, time to start the forgotten password process.

Cool, got the email and now I'm on the site -- this should be simple:

Delicious password stupidity - screen 1

I enter a weak password -- this isn't too important an account after all. Submit.

Delicious password stupidity - screen 2

What's this? It's too short? Well why didn't you tell me on the first screen? Mumble, grumble... I type a longer password. Submit.

Delicious password stupidity - screen 3

Aaaaaaaaargh!!! You fool!

  1. Why does a simple social bookmarking service need such strong passwords?
  2. If you do need them, give people the criteria on the first screen!

This is how the form should look:
Delicious password screen alternative

I love you, del.icio.us -- please fix this!

How to revert (roll back) to a previous revision with Subversion

Published on June 22, 2008 in Development. 14 Comments

You would think that reverting to a previous version of your application would be one of the key use cases for a version control system like Subversion and that it would be trivial to do, but it's actually not intuitive at all.

When I was first starting out with Subversion, I thought there would be a revert command that took a revision as an argument and basically rolled back your application to revision X. Alas, there is a revert command in SVN, but instead of reverting to a previous revision, it works to undo any local changes you've made to your working copy.

Here, then, is a very simple, plain English explanation of how to revert to a previous version of your application in Subversion, to help anyone who may be starting out with it and is lost.

To revert to a previous version of your application (roll back changes) in Subversion, you merge the changes from your current revision back to the revision you want to revert to. So, for example, if you want to revert the trunk of your application from revision 73 to 68, you would do the following:

  1. svn merge --dry-run -r:73:68 http://my.repository.com/my/project/trunk
  2. svn merge -r:73:68 http://my.repository.com/my/project/trunk
  3. svn commit -m "Reverted to revision 68."

Step 1 will perform a dry run and show you what the merge will produce. If you want to see exactly what changes will be applied, do a diff:

svn diff -r:73:68 http://my.repository.com/my/project/trunk

Step 2 actually performs the merge (you'd do this after you're happy with the dry run). At this point, realize what is happening: Subversion is calculating the changes between revision 73 and revision 68 of the trunk and applying them to your working copy. For the majority of the time, you will thus want your working copy to be a fully updated copy of the revision you are reverting from (in this example, revision 73).

Finally, since the merge happens on your local working copy, you need to commit it to the repository in Step 3.

Winning at the shell game: iPython on Google App Engine

Published on June 22, 2008 in Development, Tools and Utilities, django, google app engine and python. 1 Comment

iPython is an awesome extended Python shell that gives you goodies like tab completion for instances, history tracing (so you can easily copy interactive sessions as doctests), etc. And, if you install it, your Django project on Google App Engine will automatically start using it instead of the regular python shell when you use ./manage.py shell.

To install iPython on OS X Tiger (yes, my Leopard discs are still safely in their box since I downgraded and I don't see any reason to bring them back out yet), I followed the following steps:

  1. Download the latest iPython from the iPython distributions page (ipython-0.8.4.tar.gz)
  2. Untar it, cd into the folder
  3. As per the instructions on the iPython download page: 
    python setup.py build
sudo python setup.py install
  4. To test it out on my Google App Engine/Django project, from my project folder: ./manage.py shell

(Note: The docs mention that you need to have readline installed on Mac OS X in order to use some of the features like tab completion and syntax highlighting. It just worked out of the box for me on OS X Tiger 10.4.11 -- I'm not sure if I had installed readline at some point or whether it was just there. Check out these instructions if you're having trouble.)

Once you have it installed, try out the cool code completion:

from my_app import models
models.

Press ⇥, and you'll see a list of all your models. models.my_model. ⇥ will show you the properties for that model and so on.

To create doctests, simply enter your test instructions in the shell and then type hist -n to get a dump of your history without line numbers that you can copy and paste into your doctest.

You can press ⌃ P and ⌃ ⇧ P to interactively bring up the previous and next commands in the history. If you've typed a bit of the command before doing this, it will filter to show you only those commands from your history that match the text you've entered.

You can also access the system shell without leaving iPython by preceding system calls with an exclamation mark. !ls, for example, will show you a listing of the current working directory.

And there's much more you can do that you can read about on the iPython documentation (or just type ? in the iPython shell itself and browse the docs interactively).

Check out iPython, it's yummy!

I found out about iPython from an excellent blog post by AkH on useful tips and good practices for Django projects. Thanks, dude!

Building Conference 2.0 on O’Reilly InsideRIA

Published on June 20, 2008 in Development and Singularity. 0 Comments

OReilly InsideRIA

I just started my development diary for the Singularity web conference on O'Reilly InsideRIA. Check out my inaugural post: Building Conference 2.0.

Conditionally displaying sIFR text for different languages using content negotiation with Django

Published on June 20, 2008 in Development, django and python. 0 Comments

I'm using sIFR on the new Singularity teaser site (not least because Mark Wubben is speaking at the conference, mind you) and ran into an issue today with extended characters (such as extended Western characters, Chinese, Japanese, etc.) not displaying properly as they weren't embedded into the Flash text field.

Getting extended Western characters working is not too difficult as you can embed most of them in the sIFR SWF without increasing the size of the SWF too much. The current size of my GillSans SWF currently on the site is 32KB and includes the following character sets from Flash (note that some of these contain overlaps):

  • Uppercase
  • Lowercase
  • Numerals
  • Punctuation
  • Basic Latin
  • Latin I
  • Latin Extended A
  • Latin Extended B
  • Greek
  • Cyrillic
  • Armenian

Embedding fonts for other sets such as Hebrew, however, balloons the size of the SWF to unacceptable sizes.

The workaround I implemented was to use content negotiation to switch sIFR off for various languages. The code (which you can put inside your request handler or in a decorator or middleware method):

use_sifr = True
if 'HTTP_ACCEPT_LANGUAGE' in request.META:
	language = request.META['HTTP_ACCEPT_LANGUAGE']
	remove_sifr_for = ('ar', 'zh', 'he', 'ja', 'el', 'ko', 'pa', 'th')
	for lang_test in remove_sifr_for:
		if lang_test in language:
			use_sifr = False
context['use_sifr'] = use_sifr
 

Then, based on the setting of the use_sifr template variable, I conditionally include the JS for sIFR: 

{% if use_sifr %}
	<script type="text/javascript" src="/js/sifr.js"></script>
	<script type="text/javascript" src="/js/sifr-config.js"></script>
{% endif %}

You can easily test this out in Firefox through the Preferences panel (⌘ ,) → General → Languages → Choose... and adding one of the languages for which sIFR is switched off (such as Chinese).

« Older Entries

Bad Behavior has blocked 0 access attempts in the last 7 days.