Repent now all ye practitioners of Basic Authentication. Your days are numbered. On June 30th, Twitter will be turning off Basic Authentication in the Twitter API — the OAuthcalypse!
What does this mean? Well, some apps are going to break. And some, like TweetList, won't. Since it launched, TweetList has taken advantage of Twitter's xAuth authentication method. No matter what version you're running, your normal Twitter experience won't be affected.
It's the other guys we're concerned with though — particularly the photo services that various apps use to store the photos you take and post to Twitter. Right now, most require that an app sends your Twitter username and password to them every time a photo is uploaded; that's how Basic Authentication works. Fortunately, Twitter has proposed something called OAuth Echo that avoids sharing your password. @raffi, a member of the Twitter API team, calls it delegation in identify verification. Catchy.
When Twitter turns off Basic Authentication, attempting to upload a photo to a provider who hasn't implemented OAuth will fail. It's definitely in their best interests to make sure this doesn't happen, but as of this writing, not many have. And things are getting a bit too close for comfort given the lead time we need for application approval through Apple. So we will be proactively switching over to TwitPic with the next release of TweetList (version 1.3.0 a.k.a. "Broadway").
Exciting news! We've just discovered that TweetList, our featured-packed and über-fast Twitter client for the iPhone, is currently featured in the iTunes App Store. See it there in "New and Noteworthy"?
As you've undoubtedly heard, Twitter has recently released its own official client, a rebranded version of Tweetie 2. Tweetie was an excellent iPhone Twitter app that set the bar pretty high in terms of usability and speed. But we are striving to be better. And it's great for Apple to recognize the work of independent 3rd-party developers.
...I've been here for years. But I'm just now getting around to dusting off this old blog.
In addition to Ruby programming, I've been dabbling a bit in Objective-C over the last 9 months or so, specifically iPhone development. I'm going to start posting a bit more about that soon. It's a very different game, exciting in its own ways, but I've had to build up a whole new toolbox of code from scratch. There are so many things you take for granted from a server/web programming background (like, say, garbage collection or asynchronous image downloading). But I'm not here to bitch and moan. If it was easy, everyone would do it I suppose (although lately it's starting to seem that way.)
Sitemaps are an easy way for you to inform search engines what pages on your site are available for crawling. Web crawlers typically discover pages by following links from site to site. Sitemaps provide hints so they can do a better job.
The Sitemap protocol defines a simple XML schema for specifying what URLs are on your site, along with some useful optional information: the date of last modification, how frequently the page is likely to change, and the priority of a given URL relative to other URLs on your site. Here's an example:
/sitemap.xml — Sample sitemap
<?xml version="1.0" encoding="UTF-8"?> <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <url> <loc>http://sickpea.com/</loc> <lastmod>2009-07-17T17:17:32-07:00</lastmod> <changefreq>daily</changefreq> <priority>0.8</priority> </url> </urlset>
Unsigned applets can only connect to the server they are served from. This is a bit limiting if you want a web-based SSH session. Self-signing an applet "solves" this problem, but remember that just because an applet is signed doesn't mean you should trust it!