I have been building my first site using the Python-based development framework Django and it is really fantastic! I am picking up some of it very fast (the concept of templates and template tags, for example) because of my experience with the PHP-based CMS ExpressionEngine, and some of it is totally foreign to me... but as I muddle through it, I can tell that I've begun to learn some very powerful tools, especially once I got Django working with the jQuery javascript library.

When working with images such as profile avatars, you need to have the Python Imaging Library installed, which also means installing the libjpeg library to compile PIL. I found a couple articles here and here but it seemed that only part of each worked for me. Last night I installed everything again on my PowerBook running Mac OS X Leopard 10.5.4, so I recorded the combination that worked for me:

1. If you haven't already, you must install the Apple Development Tools (XCode).
2. Download and install the Unix software installer Fink. The binary installers for the Mac worked great, both on my Intel and PowerPC machines.
3. Open a Terminal window and type:

fink install libjpeg
curl -O http://effbot.org/media/downloads/Imaging-1.1.6.tar.gz
tar -xzf Imaging-1.1.6.tar.gz
cd Imaging-1.1.6
sudo python setup.py install

And that's it!

The Surfin' Safari blog announced SquirrelFish today, a new javascript interpreter for WebKit that is 1.6 times faster than the current interpreter. This is incredible, as Safari is already a super-fast browser, but as John Gruber points out in Daring Fireball, it may mean improved JavaScript support for the iPhone.

If you've read much of this blog, you already know my opinion about the whole "JavaScript on the iPhone really sucks" thing. I was recently reminded of this when translating some jQuery/JSON scripting from the Web to the iPhone. What ran as a fairly simple and speedy app on the Web became unusable on the iPhone, and I had to strip out tons of code to get even basic functions up to speed.

Keep your fingers crossed that SquirrelFish makes it to the iPhone, and soon!  I'm not sure if its release so close to the WWDC conference means it won't be making it to the upgraded "iPhone 2" that everyone is expecting to be announced, or if an iPhone software update will be released after the new iPhones hit the market.  The sooner the better!

The creators of SquirrelFish say this is just the beginning of new breakthroughs in compile times, and it sounds like they've done some very intensive and boring research to create their mutant aquatic rodent.  Thank goodness for the brilliant and patient minds (read: obsessives) who sort these complicated things out so the rest of us can have a better Web experience.

Oh, and yes... as everyone seems to notice, the SquirrelFish logo is way badass. It looks like it may evolve into a StimpyFish in a later release.

Leave comments on this blog, or let's talk on Twitter or Facebook.

Tags: squirrelfish, iphone, javascript, webkit, safari

Twitter has decided to remove a certain call from their API that the iTweet 2 private beta relied on to create the "ticker" effect that kept it updating at nearly real-time speeds.  The rate limit for API calls also remains handicapped, cut to 30 per hour from the usual 70.  This makes using Twitter API tools extremely inconvenient, and developing them is also quite frustrating.

For now I have removed the "ticker" feature and the friends timeline will refresh every 140 seconds, though this number may be adjusted slightly as I attempt to keep the page open and in use today.  (Big thanks to all my helpful beta testers for your excellent feedback on the last iTweet 2 development cycle!)  Further development on the beta will continue when the API rate limit returns to normal.  Until then, Twitter API development is a waste of time as most people seem to be ditching API apps for the non-limited Web site.

This is actually a good thing for me, as I am working hard on developing some other tools for The Illusion Factory that I will be posting more about soon.  Apologies for the lack of updates recently, I've been in "workshop mode" for quite some time but I will be posting details about the new ideas, tools and projects I've been working with in the coming weeks.  (I call this "pimp" mode as I will be hawking the bejeezus out of my work.)  I'm building some really neat ways of connecting with people, and I am very excited to share them as soon as possible!

Twitter has been very cool about keeping the community updated on its current status, present challenges and plans for future improvement, despite some really nasty attacks and and the lively scrutiny of about a million people speculating on who is to blame, or how a business model could be developed, or how they can fix Twitter's problems in a single blog post/comment/tweet.  They were also kind enough to post a poll in the dev group about removing the friends_timeline/username API call.  This is not something they HAVE to do, so I thought it was nice of them to bother. And — even though I was getting great use out of this feature — I voted that if removing it meant a tangible improvement to Twitter's stability, I would take it out back and shoot it myself.

Here's why I would vote to remove a feature that made iTweet's beta the most bitchin' Twitter interface for the Web: The problems Twitter is suffering from are going to take a while to solve, and more downgrades may happen. The Twitter team is working on it, and I am willing to be patient during the downtimes and downgrades while they get their app sorted out. I enjoy using Twitter and making fun stuff with their API.  But I have lots of other things that I like, and plenty of projects in the works.  I know they are doing their best to improve and/or rebuild their service, so when they've gotten through the current setbacks, I'll be back for more.  Rather than getting cranky about it, obsessing over it, or otherwise wasting my mental energy on it, I'll just go play with some other toys until this one gets glued back together again.

And of course, in the meantime a shinier toy may come along and Twitter may end up collecting dust.  That is the risk they are running every day that their service is downgraded... and I am sure no one is more aware of this than the Twitter team themselves.

Leave comments on this blog, or let's talk on Twitter or Facebook.

Tags: twitter, downtime, api, web development, itweet

I recently had a client ask me to adjust her site to be iPhone-compatible.  The navigation of this site uses Flash to apply a cosmetic animation on the text, so her site wasn't navigable via iPhone or any other non-Flash equipped device.

At first I thought I would advise her to forget about the slight effect that the Flash provided and change to a non-animated, but fully accessible navigation system.  But I knew she really liked this small detail of the site, so I thought I would try another way.

...are you using swfObject to embed your Flash content, anyway? Because you probably should be.  swfObject is an  XHTML-valid javascript  method of displaying Flash content without using unwieldy <embed> tags.  The script will fill any old <div> with your Flash, and changing the layout is as simple as adjusting the <div> with your style sheet.  It detects Flash player versions and will help a user upgrade or install the Flash player "in-window" if necessary.  It is a fantastic workaround for the annoying IE "Eolas patent dispute" requirement to "activate" Flash content by clicking it once before any buttons are active.

And -- thanks to the way that it degrades gracefully -- swfObject lets you "hide" accessible content behind your Flash.  I often use text describing the Flash content to boost a page's search engine indexability. Though this text is visually replaced by swfobject.js, it remains in the source code when the page renders.

In the case of the iPhone, the Flash is simply not displayed, and whatever originally was in the swfObject-specified <div> shows through. This is where you put a static but more-accessible version of the Flash image. You can include any kind of xhtml, links, images, or even embedded swfs.

In this case I simply made an html-friendly version of the client's site navigation, placed it in the navigation <div> and specified that swfObject would replace that content with the Flash nav where possible.  Voila!  The client sees her subtle Flash nav effect on her home computer, and can use her site from her iPhone as well (with minimal visible difference, as the Flash effect was a rollover effect anyway).

I have also used this trick to "hide" a jpg of a site's logo or header behind a Flash version... this way when viewing on the iPhone, that most important piece of your site (your identity) isn't lost!

swfObject was created by Geoff Stearns.
Click here to download the project from Google Code.

Tags: iphone, swfObject, flash, accessibility, javascript, iphonedev