Gold Plated Blog Posts

Whatev.

• Topics:
• Picasa
• India
• Bumper Stickers
• Travel

Don't Drink the Kool-Aid

I've never posted about politics before but I feel like there is a reason to now. Ever since the primary campaigns started up I've been troubled by this wholehearted devotion to Barrack Obama that a good portion of the country seems to have taken to. It's not that I'm appalled that people agree with the things that he says, but what troubles me is that I think a lot of his supporters don't really know what he stands for and yet they're so dedicated to him and his campaign. So I whipped up a graphic in my spare time that gets to the point:

For those of you unfamiliar with the reference, read this. For those of you who do get it, I think you'll agree that the message is more fitting here than it ever has been when used in pop culture. Again, this is not aimed at those who have listened to the little bit of actual content that he's said and agree with him (because there may be no hope for you). This is for those of you with moderate to conservative political views who have fallen under Barack's sweet, sweet spell. This is meant to be a wake up call and a grassroots effort to try and make it okay to stop listening to the way he says things and instead listen to what he actually says. If people start doing that, I think there is hope this November yet. As it stands, I've only ever heard his supporters talk about how inspiring and charismatic he is, which is no good reason to elect a President.

Spread the word!
This message isn't going to do much good if the word doesn't get out there. To do this, I've got three ways. The first is to do as I've done and put this little poster I've created on your website, or your blog, or your Facebook page, or wherever it is that people go to hear your voice. If you want to put it on your website, here is the HTML code:

<a href="http://cameronhinkle.com/blog/id/1719814690632762619">
 <img width="150" height="225" 
   src="http://www.cameronhinkle.com/images/dontdrinkthekoolaidsmall.jpg" />
</a>

You can link it to whatever site you want by changing the value inside "href". Link it to your party's website or the official website of your favorite candidate or leave it as it is and it will link to this post. You could also not link to anything, the important thing is getting the message out. If you want to add it to your Facebook or MySpace or Bebo page, right click on the image and select "Save Image As...", save it to your hard drive and then upload it to your account. If people want different sizes I'd be happy to make them, just email me what size you want.

The second way to spread the word is by wearing it- on your head, chest or car. I set up a Cafe Press account today and created a hat, t-shirt, and bumper sticker. Wouldn't you look awesome walking into work wearing this hat? Forget about all the crap you'll take from your coworkers, you'll be doing them a favor. Anyway, the store is set up at http://www.cafepress.com/badkoolaid. Bumper stickers are $3.49, T-Shirts are $11.99, and hats are $12.99. If you really want an item that I haven't setup there, let me know and I can add it.

Lastly, Digg this! And Stumble it, and Reddit it! I'm not exactly the Blogomaniac; I'm not going to have thousands of people reading this as soon as it hits the web. If you think it's a worthwhile message, click the little buttons at the bottom of the post to send it to the news aggregation sites. You'll be doing your part to help keep America America.

To be clear, this is not an endorsement for Hilary or McCain. This is just an effort to wake up those who need it before it's too late.

Building Your Own Picasa Gallery

Since the release of version 3 of my Picasa API I've received some feedback from users that it would be helpful to have some sample code for those who want to do the basics: host their own gallery. I can relate with this, since it's the reason I built the API in the first place. Sure, you can do a lot of other cool stuff with the API, like uploading and managing photos, but certainly the typical adopter is just going to want their own Picasa pictures viewable from their personal homepage. So here is a quick rundown of how to do a basic gallery using the Lightweight PHP Picasa API, version 3.0.

As you might already know, my gallery consists of three types of pages, which I will refer to as an account page (seen here), an album page (for instance, here), and an image page (for instance, over here). It's pretty self explanatory, the account page lists all the albums, the album page lists all the photos in an album, the image page shows a larger version of the selected image. For each page type, you'll need some kind of information that you can store in a constant or get from GET/POST data. I'll go over each page type and list source code along with what information is required.

Account Page
For the account page, the only thing you'll need is the username. I recommend storing the username in a constant variable somewhere where all your code can access. This is so that if your username changes, or you want to give your code to someone else, you only have to change the username in one place. I store mine in a variable called "Cam_Util_PictureUtil::$USERNAME". However, for the sake of readability, I'll just refer to it in the following code as "$username". Here's the code for the account page, which just outputs each album's icon with a link to the album page. I use a URL structure similar to what my site uses, but modified to be closer to the typical setup. And obviously you can change the HTML to suit your needs:

$pic = new Picasa();
$account = $pic->getAlbumsByUsername($username);
$albums = $account->getAlbums();
foreach ($albums as $album) {
  print('<a   href="http://www.your_web_site.com/album.php?
  albumid='.$album->getIdnum().'">
  <img src="'.$album->getIcon().'" />');
  print('<div>'.$album->getTitle().'</div>');
}

Album Page
For the album page, you'll not only need the username, but you'll also need the album id. If you use the URL structure used in the previous example, you should be able to get the album id from the $_GET superglobal. I'll include how to do that in the code sample. So the album page just prints each image in the album with a link to the Image Page and the album title displayed below:

$albumid = $_GET["albumid"];
$pic = new Picasa();
$album = $pic->getAlbumById($username, $albumid);
$images = $album->getImages();
foreach ($images as $image) {
 print('<a href="http://www.your_web_site.com/image.php?
     albumid='.$albumid.'&imageid='.$image->getIdnum().'">
     <img src="'.$image->getMediumThumb().'"/>');
 print('<div>'.$image->getTitle().'</div>');
}

Image Page
Lastly for the image page, as you might have guessed, you'll need the username, album id, and image id. Again, using the above example, you get the image id from the $_GET superglobal. The image page prints the image, the image title, and the description of the image:

$albumid = $_GET["albumid"];
$imageid = $_GET["imageid"];
$pic = new Picasa();
$image = $pic->getImageById($username,$albumid, $imageid);
print ('<img src="$image->getLargeThumb().'" />');
print('<div>'.$image->getTitle());
print('<div>'.$image->getDescription().'</div></div>');

Unfortunately the current implementation of Picasa::getImageById() doesn't support any image sizes other than the defaults (which are pretty small). This was an oversight on my part because there was a workaround that made it not necessary. Unfortunately, due to a change in Google's API, the workaround no longer actually works. I've emailed the Picasa development mailing list to find out if there is another workaround that will work now, but I've also entered an enhancement request in my project's Google Code page. As soon as I fulfill that request, I'll post a quick tutorial on how to get larger sized images. It should be less than a week for that to happen.

Hopefully this tutorial has been helpful. Thanks to everyone who has given me feedback on the API, so far I've only heard good things. If something's not quite working right or it seems there's something wrong with the tutorial here, please let me know. And check back in the next week, I should have the fix for getting larger image sizes available for download, and I'll include a bit of code on displaying and posting comments for your images.

Lightweight PHP Picasa API Version 3.0

After weeks and weeks of toiling away at my desk in my free time, I've finally put the finishing touches on Version 3.0 of my Lightweight PHP Picasa API. I think the extra time has not been wasted, as this version is about a thousand times more robust and feature-rich than versions 1 and 2, as well as being a lot easier to use. For easy access, here are the important links:

Download the API source code

View the Documentation

View the bug and feature request list

Here I'll list the major features, and then go into greater detail on each one. Features include:

• Automatic query building through the Picasa class
• Pass in the parameters for your request and the member functions will build and send the query for you.
  
• Robust error handling through the Picasa_Exception class
• 8 different Exception classes that can be caught individually, all of which extend Picasa_Exception to allow any level of granularity your situation requires.
  
• Easy-to-use implementation of authorizations through the Picasa class
  
• Supports Client Login or AuthSub
• Supports persistent authorizations using browser cookies
• Added previously unsupported operations
• Suports not only fetching feeds, but also posting and deleting images, albums, comments, and tags, as well as updating images and albums.
  
• Include access to public and private albums.
• Added several fields to existing classes
• Added support for Exif data, GML coordinates, among others
  
• Comprehensive documentation using PHPDoc
• View the Javadoc style manual here.
  
• 100% backwards compatible with versions 1 and 2
• It's still "lightweight"
• No special requirements, just PHP 5
  
• Less than a third the size of the Zend framework

Automatic query building through the Picasa class
The Picasa class is certainly the biggest addition to the new version. It's really the only object that your client code will ever have to instantiate. It handles both authorization as well as data requests and manipulations (posting and updating images, etc). The nice part about how it handles data requests is that you'll literally never have to formulate a query string again. Pretty much any type of feed that can be requested from Picasa is supported through just a few different methods in this class. Just instantiate a Picasa object and then call the method you're looking for. For instance, to get all albums for user "goldplateddiapers" (that's me), use the following code:

$pic = new Picasa();
$albums = $pic->getAlbumsByUsername("goldplateddiapers");

Now $albums will hold a Picasa_Account object that has an array of all my albums. To see exactly what is in a Picasa_Album, you can look at the manual, or you can just print the object. I've added very handy __toString() methods for all the objects. So add this line and see what you get:

print $albums;

If you're viewing this in Firefox (which you should be!), view the page source to get a prettier display. The output should be a nicely formatted printout of every field in the object. Each one of those fields has a getter method so that you can access the data you see.

Of course, oftentimes your request will not be as simple as getting all images from one user. So each of the "get" functions in the Picasa class take a plethora of parameters to suit your needs. For instance, take a look at the definition for Picasa::getImages():

public function getImages($username=null, $maxResults=null,
      $startIndex=null, $keywords=null, $tags=null, 
      $visibility="public", $thumbsize=null, $imgmax=null);

As you can see, none of these parameters are required. Which ones you should supply depend on what you're looking for. To find the first 250 images in Picasa tagged "lolcats", do the following:

$pic = new Picasa();
$images = $pic->getImages(null, 250, null, null, "lolcats");

Now $images will be a Picasa_ImageCollection object with an array of up to 250 of your favorite lols. The same format follows for any methods in the API starting with "get". And of course, all of the parameters for each method are fully described in the documentation.

One thing to be careful of is that all combinations are not supported by Picasa. For instance, calling just Picasa::getImages() with no parameters, Picasa itself will probably yield an error, which will be thrown as a Picasa_Exception with the error message retrieveable through Picasa_Exception::getMessage(). See the next section for more information on exception handling. I've left it up to the client code to send acceptable requests; the API will only throw an exception if Picasa itself responds with an error, the API doesn't catch invalid combinations of parameters and thus they're not documented here. You'll have to play around with different parameter combinations or check Picasa's Developer Guide.

Robust error handling through the Picasa_Exception class
The previous versions of the API didn't do much in the way of error handling, and this aspect is probably the second biggest improvement since then. There is one main exception class, called Picasa_Exception, that all exceptions thrown from the API will be at least subclassed from. It's not an abstract class, so oftentimes an instance of Picasa_Exception itself will be thrown, but a more specific subclass will be thrown when appropriate. Take a look at the subclasses in the documentation or the source code, they're all listed in the Picasa_Exception class.

The Picasa_Exception class extends PHP's Exception class and adds a few nice fields to have. The first is Picasa_Exception::$url, which will contain the offending URL if the exception resulted in a bad request to Picasa. If the exception wasn't thrown as a result of a bad request, this field will be null. The other field that can be useful is Picasa_Exception::$response, which holds the complete response that the exception was thrown as a result of, again only if the exception is thrown because of a bad request.

To give you some background on how the API knows it should throw an exception when it's given a bad request (skip this paragraph if you don't care), basically the method that is used for executing requests (Picasa::do_request()) checks for a response of 200 or 201. If that's not found, it passes the response header to a method (Picasa::getExceptionFromInvalidPost()) that determines which kind of exception to throw. It saves the error message given by Picasa as the result of Exception->getMessage(). However, sometimes the body of the response, even if it was not a 200 or 201 response code, can be useful. For example, if a client is trying to authenticate using Client Login and Picasa requests a CAPTCHA challenge, the response code is 403, but fields are set in the body identifying the URL to the CAPTCHA challenge and the CAPTCHA's token value. The API uses the Picasa_Exception::getResponse() method to get the returned response, determine that it is a CAPTCHA challenge, and parse out the required fields.

The only other exception class in the API that adds any fields to the base Exception class is Picasa_Exception_CaptchaRequiredException. This (as you might have guessed) is thrown when a CAPTCHA challenge is requested by Picasa upon attempting to gain authorization. If you're unfamiliar with this operation, Picasa will ocassionally require a user attempting to login using Client Login to type in letters that appear in a supplied image in order to guarantee that the user is a real person. To login after a CAPTCHA is requested, you do exactly what you did to log in the first time, this time passing in the user's CAPTCHA answer and a token supplied by Picasa (see the next section for how the API deals with logins and CAPTCHAs). The Picasa_Exception_CaptchaRequiredException contains the method Picasa_Exception_CaptchaRequiredException::getCaptchaUrl() for getting the URL to the image to display, the method Picasa_Exception_CaptchaRequiredException::getCaptchaToken() for getting the token to pass along with the re-attempt at authorization, and the methods Picasa_Exception_CaptchaRequiredException::getUsername() and Picasa_Exception_CaptchaRequiredException::getPassword() for getting the user's username and password that they originally used when attempting to sign in.

As an example of how to use the Picasa_Exception classes effectively, here is an example of client code attempting to log in (see the next section for details about how to use the authorization functionality, but I think you can infer what the code is generally doing). Let's assume I've just requested the user's username and password in a form, using the POST method:

// Get the username and password from the POST superglobal
$user = $_POST['username'];
$password = $_POST['password'];

$pic = new Picasa();
try{
    $pic->authorizeWithClientLogin($user, $password);
} catch (Picasa_Exception_CaptchaRequiredException $ce) {
    print "Please enter the letters you see in the image: ";
    print '<img src="'.$ce->getCaptchaUrl().'" />';

   /* Put code for generating a form with an input field, setting $ce->getCaptchaToken(),
    * $ce->getUsername(), and $cd->getPassword() as hidden fields here
    */
} catch (Picasa_Exception_InvalidUsernameOrPasswordException $ie) {
    print "The username or password you have entered is invalid.";

    /* Put code for handling re-logins here
    */
} catch (Picasa_Exception $e) {
    print "Your attempt to login has failed: ".$e->getMessage();

    /* Put code for handling relogins here
    */
}

Easy-to-use implementation of authorizations through the Picasa class
Previous implementations of the Lightweight PHP Picasa API did not support authorizations in any way. This suited my needs personally, but left a lot of people out of luck or on their own to throw something together. With the addition of the Picasa class, though, comes a suite of methods and fields for gaining and keeping authorizations. The first thing you need to know about is the difference between Client Login and AuthSub. Client Login allows you to enter a user's username and password, while AuthSub requires your client to redirect the user to a Google-hosted secure page to enter their username and password. The Picasa class supports both.

To authorize a user using Client Login:

1. Get their username and password
2. Call Picasa::authorizeWithClientLogin(), passing in their username and password.

At this point, if the authorization was successful, you have an "authenticated" Picasa object. Now, using this Picasa object, you can do operations that the current user is authorized to do, such as accessing their private albums, posting photos and albums to their account, etc. If the authorization was unsuccessful, a Picasa_Exception is thrown. See the previous section for instructions on how to handle such exceptions.

To authorize a user using AuthSub:

1. Redirect the user to the Google login page using Picasa::redirectToLoginPage()
2. On the page supplied in the $next parameter or Picasa::redirectToLoginPage(), call Picasa::authorizeWithAuthSub().

These steps automate a few things that you could also do manually, depending on what your intentions are and what your server configuration gives the API access to. First, if you want to redirect the user manually, you can call Picasa::getUrlToLoginPage() just to get the URL that you should send the user to, and then redirect them using your client code however you want. Second, if the API doesn't have access to the $_GET superglobal (which the token required for Picasa::authorizeWithAuthSub() is in), you can get the "token" parameter out of the URL however you normally would and manually pass it as the first parameter in Picasa::authorizeWithAuthSub(). If it's not passed in, or null is passed instead, the method will look in the $_GET array for the token and if it's not there, throw a Picasa_Exception_FailedAuthorizationException.

A neat feature that is built into the API is persistent login through the use of cookies. Cookies are used because there's no server-side caching mechanism supplied with the API. So by default, if you authorize a Picasa object, it will store the authorization token and the type of authorization used (AuthSub or Client Login) in the users browser cookies. Tokens don't expire for quite a while, so this allows the user to login once and remain logged in as long as you like. You can use the method Picasa::authorizeFromCookie() and it will automatically look in the user's cookies for an authorization token and authorize the object if it finds one. If it doesn't, false is returned and your client code can prompt the user to login again. So here is a snippet for logging in using AuthSub:

$pic = new Picasa();
if ($pic->authorizeFromCookie() === false) {
    Picasa::redirectToLoginPage("http://yourdomain.com/samplePage.php");
}
//Perform authorized requests here

On the other hand, if you don't want the API to automatically save the token to the user's cookie and you want to save it yourself in a more secure way, you can pass false as the $saveAuthorizationToCookie parameter of either Picasa::authorizeWithAuthSub() or Picasa::authorizeWithClientLogin(). The token is returned from both methods when a successful authorization is established. To then authenticate a Picasa instance, you can either pass the token along with the type of authorization (represented by the public static members Picasa::$AUTH_TYPE_AUTH_SUB and Picasa::$AUTH_TYPE_CLIENT_LOGIN) into Picasa's constructor when you instantiate it, or call Picasa::setAuthorizationInfo(), also passing in the token and type.

It should also be noted here that Picasa actually returns a "single use token", which is only good for one request, when a user attempts to login through AuthSub. However, the API automatically converts the single use token into a session token and saves that value. There is no parameter to turn that feature off because there is no downside to doing it and a single use token is too worthless to warrant another parameter.

Added previously unsupported operations
Now that authorizations are possible, so are authorized operations. I've done my best to provide pretty much any operation available through Picasa's core Data API in this PHP version. So you can post, update, or delete albums and images from an account that you have permission to do so in once you have have an authorized Picasa instance. You can also post or delete comments and tags, and retrieve private feeds.

The methods for posting, updating, and deleting are extremely similar to the methods for retrieving feeds. There are several "posting" methods, just like there are several "getter" methods described in the first section. So let's say you want to post an album titled "Dwight Schrute's One Night Stand" to the account "goldplateddiapers":

$pic = new Picasa($token, Picasa::$AUTH_TYPE_AUTH_SUB);

if ($pic->isAuthenticated()) {
  try {
      $album = $pic->postAlbum("goldplateddiapers",      //Username
             "Dwight Schrute's One Night Stand",         //Title
             "Dwight and Angela exchange cat pictures.", //Summary
             "private",                                  //Access rights
             "false"                                     //Commenting enabled
                               );
  } catch (Picasa_Exception_UnauthorizedException $ue) {
      print ("You are not authorized to add this album.");
  } catch (Picasa_Exception $e) {
      print ("An error occured while posting the album: ".$e->getMessage());
  }
} else {
  Picasa::redirectToLoginPage("http://yourdomain.com/samplePage.php");
}

Yeah, I know, the parameter list gets a little ridiculous. However, I've tried to order them in such a way that they will be as short as possible. For instance, had I wanted that album to be public and allow commenting, I could have left off the last two parameters.

Now that you know how to post an album, posting images, comments, and tags are all done the exact same way, though the parameter list varies. You can also update albums and images, although Picasa doesn't allow comments or tags to be updated. Deleting is allowed for all four types of objects. Read the documentation to see exactly which parameters are accepted for each type.

Added several fields to existing classes
The most noticeable difference here is going to be in the Picasa_Image class. The amount of information that is available for each image has just about doubled. You can see that Exif data and GML information are two things that were not supported in previous versions. One thing you will have to look out for, though, is that some of the fields will be null at times. It just depends on what the Atom feed from Picasa applies. To see what fields are null while testing your client code, just print the result of Picasa::getImages() and play around with the parameter values. The __toString() method will be automatically invoked and you can get a nice view of exactly what the instantiation looks like.

There is a cool new feature for some of the getter fields, too, that alleviates some of the problem associated with the null fields. You'll notice in the past that if you request all albums for a single username, the result would have come in the form of a Picasa_Account, which would have an array of Picasa_Album objects. However, those albums would not contain any images, presumably because it would take a lot of extra time to fetch and transfer the information about each image. Now, however, the method Picasa_Album::getImages() will check to see if the $images array is null and fetch a new instance of the current image, pull out the $images array from that instance, and return it. This way, if you want the value, it will always be there. The same logic follows for Picasa_Image::getComments() and Picasa_Image::getTags().

Comprehensive documentation using PHPDoc
I've gone to great lengths to document the entire API, and I finally went through the trouble of generating the docs and hosting them. I think the documentation will be really helpful in using this API, I have literally spent hours preparing it. One thing to note is that it's split up into two packages: Picasa and Picasa_Exception; the latter can be difficult to spot from the documentation's front page, there's a link to it at the very top. You can find all the documentation here.

I did not generate documentation for the Cam folder because it is not really part of the API and shouldn't be used. I attempted to change the code inside those files to utilize the new Picasa class, but the method names and intentions didn't really make sense in the context of the new version. They're still there, for backwards compatibility sake, and they work. However, if you're a newcomer, I would certainly ignore them.

100% backwards compatible with versions 1 and 2
As with the previous versions, drop the code in where your previous code was and you should have no problem. The one caveat is that you have to have had the classes inside the Picasa folder that was provided with the old versions. That folder is no longer the topmost level, the php folder is, so be careful when doing this. And as I stated earlier, the Cam folder is included for backwards compatibility.

It's still "lightweight"
It really depends on what you call "lightweight", but I think I've held true. The main thing is that there are no special packages needed with PHP in order for it to work. It was tempting to use the cUrl library or the Http classes, but I just implemented all the HTTP responses and requests myself.

Also, it's still a very easy install. You should be able to drop the files into your include path and pretty much be ready to go right away. A lengthier explanation is given in the README, but there's not a whole lot to it other than that.

The future
Obviously I've spent a lot of time trying to make this a product that people can actually use. I didn't expect to, but it remains to be by far the most popular topic on my blog, so I decided to expand on it. To that extent, I've also opened up a Google Code page for it, which I'll mainly use for tracking issues. You can visit that here. While I can't currently see a reason to make a version 4 of the API, I will certainly have future releases. With the added functionality, there will positively come added bugs, and there are enhancements that I have thought up that I did not get time to implement. So if you find a bug, let me know or add it to the bug list, and I'll probably release an update every month or two. It also really depends on the response, whether or not people seem to like the product. Whatever happens, I'll keep all the download links pointing to the latest release, so you can be sure you're getting the most up to date code.

I made this with the intent of making it easy for PHP developers to harness the Picasa service and create really cool new products, so please do so. As always, if you have any commentary, please leave a comment here or send me an email to tell me what you think. I would love to hear that someone really likes or really dislikes anything about the API. If you have features you'd like to see, feel free to let me know or add it to the issue list. And just in case you missed it at the top:

Click here to download the API

Thanks to everyone who has helped with this and everyone who is using it. Now while the bug list is still at zero and my eyes are still open, I'm going to play my Wii...

Lightweight PHP Picasa API

As I've mentioned before, the Pictures section of this site is run through Picasa, Google's picture service. So I upload all my pictures to Picasa through a local application that they provide, I group them into albums, name them, give them a location, etc, and then they appear on CameronHinkle.com. This works out really well because their interface is nice for uploading photos and I don't have to pay for storage (I'm only using 13% of my total space and I can buy more if I need it). I also like that it's hosted in a central place with a lot of other photos because that means it's not sectioned off in its own little corner of the world. I don't usually get hung up on privacy concerns so the fact that I don't have control over the physical location of the photos does not bother me in the least.

Anyway, all of this magic is brought to you by Picasa's API. When I started this project, I was under the impression that Picasa, like Blogger, had a really slick API written in PHP that I could easily integrate with my site. It was going to be a piece of cake. Well, that turned out to not be the case. There was no existing PHP API, only one in XML, which meant I had to start the task of parsing lots of XML (which fortunately is really easy in PHP). To make things easier, I made my own PHP API that can really be used by anyone. So if you have a Picasa account and you know PHP, this makes it relatively simple to display your Picasa pictures on your website. And now for the first time, I'm publishing it on the web.

Click here to download my lightweight Picasa API in PHP.

The API is not great, it does exactly what I need it to do and not a whole lot more. However, it's extraordinarily easy to add on to. Basically it is set up with 4 types of objects that are simple to understand: Accounts, Albums, Images, and ImageCollections. Accounts have Albums, Albums have Images, and ImageCollections also have Images. Everything is pretty self explanatory except possibly ImageCollection, which is just a way to contain several images that are not from the same Album because there are different rules (like ImageCollections aren't given a title). The easiest way to understand how each class works is to look at it's constructor because that will tell you what to pass in to make a given object. Be aware that if you only need one photo, creating an entire Account object will take forever, so there's an easy way to create just a single Image object.

If you want to publish your uploaded photos on the web, this is perfect! If you want to upload your own photos, it's not so good, but it may be a good start. Hopefully someone needs to do more than I did and runs with the idea. However, I assume that there will be a Zend package available for Picasa within the next 6 or 12 months, at which point my API will be completely obsolete. Until then, enjoy!

Update 04/09/2008: This post is for Version 1.0 of my Lightweight PHP Picasa API. Version 3.0 has since been released, which includes a great deal of expanded functionality. Go get it here for more Picasa PHP fun!

UPDATE 12/2/2007: I eventually took the time to post some help with using this download and that article is posted here. I will probably offer additional help later.

Home sweet home!

America. Land of the free. Where every shower has a curtain, every toilet has paper, and you have to go all the way to an Oakland Raiders game to see people peeing in the streets. After 33 days in a foreign country and 60 hours of flying, I'm happy to be home. To get an idea of what I really missed about being home, take a look at the first thing I did when I got to the U.S. and then see the second thing I did when I got to the U.S. Something tells me you probably could have guessed both of those, in that order.

I wish I could say it was easy coming home; in one day of flying, Indian Airport Security, Lufthansa, United Airlines, and the Portland International Airport all managed to make it onto my list of parties I care not to do business with. I recount the last 30 hours of my flight with as much detail as I can remember, given that the better parts of my brain have blocked most of it from memory.

Tuesday, June 24, 2007
12:15 AM IST After saying goodbye to everyone in the office, Alec and I head to the airport a little bit later than desired for our 1:45 AM flight. I get to the check in counter with my two carry on bags and two check in bags, the same collection that I arrived in the country with. I'm informed by the lady at the counter that I can only carry on one bag if it has a laptop in it. "What?!" I ask. "It's not Lufthansa's rules, it's India's rule. Security won't let you past with two bags," she explains. "Will these be okay?" asks Alec behind me. "Is that a camera bag? Yes, that's fine," she assures him. She continues with me, "Well, you'll have to put that smaller bag inside your larger bag. If it doesn't fit, take the laptop out and carry it under your arm." "You have got to be kidding me," I exclaim, hoping that I'm the butt of a short-lived joke. "No, once you get through security, you can unpack both bags and take them onto the plane, you just have to pass security with one bag. Sorry for the inconvenience sir." So there at the front of the line with everyone watching, I unpacked all my belongings with great swiftness, shoved my laptop bag inside my rolling travel bag, tucked my laptop, DVD case, and Bible under my arm, and walked to the immigration line.

1:15 AM IST After waiting in the immigration line for 45 minutes, I finally made it through. Alec had some trouble with his ticket because his original ticket was scheduled to leave several weeks ago. It took him about 40 minutes to get it straightened out and I was concerned he would miss his flight but somehow he ended up through the line before I did (you sort of get used to these inconsistencies after being in India for long enough). At any rate, we both made it out with what we hoped would be enough time to make it through security and to our flight.

1:25 AM IST Security was no problem. The security guard took one look at me and hesitated, probably thinking that I had too many bags, but then realized that I was in compliance and let me through. Once through security, I immediately unpacked all my gear again, organized it into its original configuration, and head to the line of people boarding the plane.

1:35 AM IST Alec asks, as we're walking to the flight, what seat I'm in. "33K", I reply. "33K? Hmm, I'm also in row 33. ...possibly seat K!" After closer inspection, sure enough, we had been given the same seat. We stop an attendant while in line to point out the mistake. After making a few walkie-talkie calls, they take my ticket, cross out 33K and write in 25G, tell me to get a new ticket at the next counter, and send us on our way.

1:40 AM IST We arrive at the counter where boarding passes are being accepted. Alec continues to the plane while I wait for a new boarding pass. While getting to the counter, we had speculated that 25G might be Business or First Class and I assure him that if he bumps me into Business Class, I will buy him a coffee when we get home. After 5 minutes of confusion, with up to 7 Lufthansa representatives making phone calls back and forth and some of them asking me what's going on, I am finally handed my new boarding pass...with seat 33K printed on it. "But someone else has 33K," I explain. "Oh we've taken care of it. It's a window seat!" she assures. So I race the 100 feet down to the plan and make it on as the final passenger. As I walk to my seat, I see Alec settling down in seat 25G...in Business Class. He has yet to buy me a coffee.


1:30 PM EST I've gotten over the Business Class incident and have safely landed in Washington, D.C. I know there were a lot of messages over the airplane's PA system about customs but I was listening to my iPod most of the time and didn't hear them. I think I'll be fine. I'm meeting my aunt and uncle from Baltimore here and we plan to have dinner. So when faced with going to the line of people catching connecting flights and going to the line of people staying in Washington, D.C., I go to the latter because I'm not sure I'll be able to leave the airport otherwise. I go through customs with just my carry-on and then meet my family and we have a very good steak dinner. At some point, it occurs to me that the reason there was two lines may have been important for me to pay attention to.

4:30 PM EST My flight leaves in an hour and I'm still a little concerned. I made it through security and to my gate in plenty of time, but I seem to remember something about taking your checked-in baggage through customs playing on the airplane's television. No one staying in D.C. had to take more than their carry-on through customs, though, so I'm not too worried. I ask the woman at the counter about my bags and she assures me, in a tone that made me think she was tired of talking to me before we started, that my bags were checked in to Portland and that they would meet me there. I reiterate the problem just in case, and she reassures me. So I feel pretty good.


8:30 PM PST I'm home! It's a wonderful meeting with the family. Besides the fact that I've been pretty sick ever since my first encounter with red meat in 5 weeks just hours earlier, my homecoming was as good as anticipated. Debbie even met me with a goofy sign to try to embarrass me (it didn't work!). So we head to baggage claim and wait. ...And wait. ...And wait. Finally I get the idea and check with the lady in the baggage claim office. She tells me that, in fact, I was supposed to get my bags in D.C. and take them through customs myself. Also, she tells me that PDX would not deliver them because it was my fault. So I got them the next day (and in horrible condition...I think those Customs guys probably take their aggression from having to clear the leftovers by themselves out on the bags.)

It may have been an unpleasant trip back but I made it and that's all that counts! Things would have been significantly worse had I missed a plane or actually lost one of my bags for good. The flight mishaps were far overshadowed by the fact that I got to be home, visiting my family, sleeping in my own bed, and eating with a knife and fork. So long India, we'll talk again when my toothbrush stops tasting like lake water...

Who cares about elevators?

It's been two weeks since I arrived in India and things are becoming pretty normal. The traffic rarely frightens me now and I'm not surprised to see rows of parked cars with people sleeping in them. However, while things have become normal, they haven't necessarily become reasonable. So expounding on what a said a few days ago about the little difference, I thought I would spend some time outlining these oddities. None of them are things to get outraged about, they're just different and curious.

Elevators

Take a look at the picture to the right, which is the elevator in my office building. Notice anything strange? Well, keep in mind we're on the 5th- but not final- floor. Look closely and you should see that there's no Up button. Now I rarely have a reason to go any higher than the 5th floor but I often times find myself on the 2nd floor, where the situation is the same, getting a frosty beverage. How do I get up? I watch the numbers on the floor indicator as they go 0-1-2-3-4-3-2, and then stop...and then start going down again because, of course, I hit the down arrow. This started my realization that everything takes longer in India, which I will undoubtedly get to on a later date.

Coffee

I have provided an image to scale that depicts two strange things. The first is the thimble full of coffee that is typically provided at most coffee shops. The second is the comparatively massive amount of sugar that is contained in each packet. The coffee is one quarter sugar! Apparently Alec ordered his coffee black one time and then watched as everyone around him dropped their jaws and walked away slowly.

Checkout

I didn't get a great photo of this but something I found very peculiar is the number of people involved in me purchasing cookware. Look in the photo and you'll see that people do not do things alone. The two employees in the foreground are helping each other bag items. The people behind those two are ringing up customers: one to read the price and the other to type it into the register. I would not only argue that this is unnecessary but also more error prone. It doesn't stop there, though. First there was the guy directing me which line to get in. Then there was the guy handing out baskets to put my items in. Then there was the register duo. At this point my purchase mysteriously vanished and I was handed a receipt. After asking a few people, I found out that I had to go to the center counter to pick up my items, which had been bagged by the bagging duo and placed under the counter. So I count a total of 6 people to buy 5 items.

Menus

It's not the actual menus that confuse me here. In fact, the menus are relatively straightforward. The only information they don't include, unfortunately, is what's not available. Take a look at a picture of Brio's menu, which is a very westernized coffee/sandwich shop. I've taken the time to modify the menu to reflect their actual offering, which you can see better by clicking on it. Also, they have a large class cabinet in the front which houses pastries that would be perfect for breakfast. Unfortunately, I've been informed several times that the pastries don't arrive until 1:30 in the afteroon. While Brio is pretty westernized, this is a common characteristic amongst Indian restaurants.

Hand Wash

The actual need for a Hand Wash room is obvious, and I more than appreciate the attempt at sanitation. However it makes sense to me that in a situation where everyone expected to wash their hands before and after a meal, you would provide some method of drying. I've only ever seen one restaurant that had a solution to this problem and it was a big bath towel that I did not dare touch. And thankfully, too, as the exact same bath towel was there a week later when we had lunch there again. You may assume that the towel had been washed since then but judging from the looks of it, that was almost certainly not the case. As a result, I can typically be found with a large hand print on both sides of my shirt.

While these items stood out the most, there are other questions I'd like answered. For instance, why does everyone walk in the street instead of the sidewalk? Why does everyone eat with their fingers? And why are there urinal cakes in all the sinks? I've been here two weeks and I'm no closer to solving these mysteries than when I arrived. Can anyone help me out?