Python Apple Notification Server

http://github.com/samuraisam/pyapns

Don’t have any immediate plans to build a product that uses notifications on the iPhone, but if I did, I’d look here first for sample code to deal with it all.

January 5, 2010, 9:20 p.m.
0 comments

Django learnings

I’ve been building cloudwich using Django, which is both my first experience with Python and my first experience with Django as a framework.  So far it has been pretty painless, but today I did run into a funny gotcha.  Django 1.0.2 which is what runs on the pottier.com server, didn’t support filter arguments being surrounded by single ( ’ ) quotes, only double quotes ( ” ).  As I’m developing primarily on my mac on 1.1.1, it took me a bit of experimentation to figure this out, as the error message was far from helpful.

One thing I do find both funny and frustrating with Django is that the arguments to the ‘date’ filter don’t match the default Python datetime ones.  While Python’s datetime, supports ‘%B’ to represent the full month name does, Django does not, instead using the C standard’s ‘F’.  It is a bit crazy to be inconsistent within a language, and crazier still that both of these aren’t the same as either unix’s ‘date’ format nor java’s SimpleDateFormat.  It makes one wonder who comes up with this stuff, neither ‘F’ or ‘B’ evoke full month name to me, though PHP uses ‘F’ as well, so maybe Python is the culprit.

The even more galling part is that the Django’s date filter doesn’t use a % to escape the date tokens.  So when specifying a date, you do so via “F j, Y, P”, instead of the far more natural Python, Java, C and unix date standard of “%F %j, %Y, %P”.  So if you are doing any type of fancy formatting for your date, with strings embedded, you need to know all the built in codes in order to escape them properly.  That is terribly silly.

Things like this are undoubtedly the cause of a few bad early decisions.  For whatever reason, at some point someone thought it was more natural to use ‘B’ without ‘%’ for the full month, and by the time the authors realized it was a mistake, it was too late, too many sites were using the Django to roll it backwards.  This is the curse of becoming too popular, too soon.  Once you have a large installed user base, it is hard to go back and fix things properly.  You will alienate too many users.

But I think it is a necessary evil.  The projects that bravely go forward willing to break backwards compatibility remain cleaner, and in a project like Django, a framework, it is doubly important to be willing to do this.  After all, everybody is installing their own version anyhow, so let them pick the version that works for them.

PHP in my opinion, is the mess it is because it has always adopted the strategy of tacking on new method names and features as it went along, hardly ever deprecating or removing anything.  It makes for a ridiculous number of available functions, all in the global state that always make me feel slightly uneasy.  Just go look at the number of date related functions and you’ll see what I mean.  Does PHP really need this many?  Of course not, but the popularity of PHP means they will probably always be there.

In any case, how much time has been wasted looking up the proper escape code for date formatting?  God knows I’ve probably spent a day in my career looking these up across different languages and libraries, and it sure seems like a waste.

December 19, 2009, 7:32 p.m.
0 comments

Betting it all on the cloud..

I recently had our main family website server completely crash.  I use a cheap host and when things went south, they didn’t try terribly hard to fix things, the drive was dead and I had lost everything.  Of course, I am supposed to have backups.  I am supposed to know better.  And I did, of the photos on the site, but I hadn’t done a SQL backup of our photo metadata in a long time, and therefore was pretty much out of luck.

So I’ve decided that I really suck at being a sysop, at least for my personal data, and that I’d bet it all on the cloud instead.

The content on pottier.com was almost all photo galleries that Marc and I posted.  I’ve decided to move our photo hosting and metadata backups wholesale to Picasa.  Picasa not only has a great desktop client on both Windows and Mac, which does fantastic syncing onto their web, but they also have ridiculously cheap pricing.  My pictures and my email are really the only two things I care about every losing, so I want to have the full resolution photos backed up.  Not a problem with Picasa, and at 200Gigs of storage for $50/year, it’s a bargain.  The real key is that it isn’t just dumb storage for my photos, like any normal backup would, but instead also includes all the metadata for the photos, from exif tags, to location, to comments, descriptions and tags.  Good stuff.

The rest of the content on pottier.com was just my ramblings about one thing or another, and here I’ve decided to move to tumblr.  Even though I usually try to avoid sites with missing letters, I like their simple interface and very open API’s, and the way they classify content (links, posts, photos, etc) just kind of grocks with the way I want to ‘blog’.  Oh and it’s free, so even better.

Now Picasa and Tumblr are all well and good, but I miss having a homepage for our family, with what we’re up to and our own style and look and feel.  So part of the picking those two services was making sure they had nice and open APIs.  And they do, so I’ll be rebuilding the pottier.com website as very thin veneer over those two services.  No pictures will be saved on my server, instead I’ll be grabbing them from Picasa and styling them on the fly.  In a similar vain, I’ll wrap and post my tumblr posts, and maybe even some Facebook statuses.

The idea is not to own any of the data, because that’s a pain.  I’ve written interfaces for managing photos before, and I’m done with it.  It is far easier to use Picasa on my mac, or even the web UI to edit and post.  Same with tumblr.  Most of the work of creating a custom website is those admin tasks, managing your content, letting you edit and post what you want.  I’m choosing to trust the cloud, and to use their interfaces for content creation, but package their product into my own site.

We’ll see how it goes, but so far I am loving the simplicity.  Oh, and I’ll be doing it all in Django, as I’m starting to appreciate Python more and more for this kind of work.  So far Django seems fantastically organized, and the pre-built Python libs for accessing Picasa and Tumblr sure don’t hurt either.

December 13, 2009, 5:37 p.m.
0 comments