When I poke my head above my monitor at FlickrHQ, I can see a lot of headphones. Ever wonder what inspires us to write code (besides fried chicken sandwiches and cocktails)? Well I did a little snooping in the playlists of a few Flickreenos:

Oh, and I suppose I should share mine too:

•  Blueprint Car Crash – Gun Moll

•  Little Dragon – Come Home

•  Angus & Julia Stone – Black Crow

•  Plants and Animals – Celebration

•  of Montreal – Coquet Coquette

Find even more of what inspires us on our FlickrHQ Last.Fm Group

Photos by waferbaby

During the redesign of our photo page, we created a YUI3 API  module, used for all Flickr API transactions. This module has been designed to load component modules as needed, which makes for a speedy initial load. For example, the YUI3 IO module, which handles XMLHttpRequests in the YUI3 library, is loaded only if writing to the Flickr API. Read requests are all handled by the Get Module, which is included in the core of YUI3. A byproduct of this approach is that read requests can be made cross domain, without a proxy.

Reading from Flickr

Simply include gallery-flickr-api in your requirement definition. Then use the Y.flickrAPI.callMethod function, passing the Flickr API method name and callback as arguments. Have a look at the YUI3 Gallery page for more information about using gallery modules. Read requests can be made cross-domain without a proxy, since the request and response will be loaded as a script resource instead of using XMLHttpRequest.

YUI().use('gallery-flickr-api', function(Y) {

Y.flickrAPI.callMethod('flickr.panda.getPhotos',
{
api_key: 'your_api_key',
panda_name: 'ling ling',
extras: 'license, date_taken, owner_name',
per_page: 50,
page:1
},
{
success : function(response_object) {
//Success Code
},
failure : function(response_object) {
//Failure Code
}
});

});

Writing to Flickr

Okay, writing to Flickr API (i.e. post requests) is a little trickier. You will need to make sure that your API key is enabled to read and write. As soon as you make the first API request to write, the YUI3 IO module will be loaded (if it is not already). It is important to note that write requests can only be done on the same domain, which is the standard security restriction of the XMLHttpRequest for browsers. POST requests to the Flickr API, will require some sort of proxy which will accept the post request on your domain and handle the cross-domain communication with api.flickr.com

YUI().use('gallery-flickr-api', function(Y) {

Y.flickrAPI.callMethod('flickr.favorites.add',
{
api_key: 'your_api_key',
photo_id: a_photo_id
},
{
success : function(response_object) {
//Success Code
},
failure : function(response_object) {
//Failure Code
}
});

});

We hope that you make use of this new module. It is a great way to get quick prototypes and full scale applications made using the Flickr API in a short amount of time. See you in the App Garden!

The Joy of Popup Windows

As you’ve probably noticed, we’ve been working on the login process here at Flickr. In an effort to make this flow as painless as possible we’ve moved to a “contextual” login, which is to say, logging in doesn’t require you to leave the page you are looking at. We accomplished this by using a popup window.

We initially considered using an in-page modal dialog box instead of a popup, but quickly dismissed this approach for two security reasons. Firstly, to prevent phishing and cross site attacks it’s very important that login forms are not posted cross domain (Yahoo!’s Membership Platform authentication happens on yahoo.com, not flickr.com). Secondly the URL of the login page should never be hidden from the user.

An in-page modal fell foul of both of these concerns. A more suitable solution would be the popup browser window, once a favorite of advertisers.

Our initial approach

Revisiting our turn of the millennium Javascript for opening windows with the BOM, things looked simple enough: call window.open, make sure the window opened, then set a timeout to see if the window was closed:

function waitForWindowClose() {
	if (web1999Window && web1999Window.closed) {
		// the pop-up was closed, done with auth etc.
		window.location.reload();
	} else {
		// check again in a moment
		setTimeout(waitForWindowClose, 1000);
	}
}//cute function name by Scott Schiller
function webCirca1999(url) {
	try {
		web1999Window = window.open(url,'newWindow','width=640,height=650');
	} catch(e) {
		//handle blocked popup...
	}
	try {
		//this is to check if it really opened
		if (web1999Window.focus) {
			web1999Window.focus();
		}
	} catch(ee) {
		// also handle failure
	}
	waitForWindowClose();
	return false;
}

Unfortunately Yahoo!’s new user signup process closed our popup and opened a new one of their own. This triggered our waitForWindowClose{} function, web1999Window && web1999Window.closed evaluated to true, and the Flickr page refreshed, even though the user hadn’t logged in yet.

The next thing we tried was watching window focus. When the window blurred after clicking on the login popup, we’d know the popup was open, and when focus came back we’d check the user’s login credentials.

But focus tracking also had its problems. Some browsers didn’t always report the window blur event when a popup was open, resulting in inconsistent behavior. It was also possible for the user to accidentally focus back on the window and kill the flow. We tried several ways to track focus, and although behavior got better, it was never 100% reliable. For a feature like login that was obviously a problem.

The Cookie Solution

Ultimately we settled on a solution that forgot about popup tracking and window focus and instead concentrated on checking for the user’s login cookies. The code below polls to see if the login cookie is set, then makes an AJAX request to verify it, then refreshes the Flickr page:

function pollCookie(){

	if(document.cookie.match(sessionRegex)){
		authInProgress = false;
		checkAuth();
	}else{
		Y.later(20, this);
	}

}

This has the benefit of being very responsive, avoids the nightmare of focus tracking, and is low impact (as there’s no need for us to poll the server).

So today we have a reliable contextual login. Our popup system also made it possible to add google and facebook login with less pain than usual.

We’re happy to announce today the launch of our Flickr API Developer Guide. Whether you’re just getting started or you have worked with our API for a long time, check it out for some tips on how to best (and respectfully) use the API. All feedback is welcome via the discussion board for the API Mailing List, and you can also check out the API Changelog for any updates, via @flickrAPI, the Flickr API Twitter feed.

In July 2010 we launched a new photo page that displays photos at up to 640 pixels on the largest side. In the months leading up to this launch we did a lot of work to support generating this new size, along with making our support of the Large image size more consistent.

Medium 640

We started adding support for the new Medium 640 size(_z suffix) on March 31st 2010. We generated a Medium 640 size for all photos uploaded after that date. Over the next couple months after that we found and corrected instances where we were not fully supporting this size. We display the Medium 640 size on the Photo, Photostream and All Sizes pages.

Dynamically Generated Images

If a photo was updated/uploaded before March 31st 2010 then we do not have a Medium 640 size on file and will try to dynamically generate it. We can do this if a large version of the photo exists, or if the original is a jpeg that has not been rotated(when you see an image URL that ends in _z.jpg?zz=1, the zz=1 indicates we can generate from an original). By doing this we make a lot of old photos display at 640 on the new Photo, All Sizes and Photostream pages. And every time we generate a Medium 640 image it gets cached, so we don’t have to generate it again for a while. If we can’t generate the image dynamically, we fall back to displaying the Medium 500.

Generating photos dynamically needs to be happen fast, so we don’t try to generate a Medium 640 from the original if the photo has been rotated or needs to be converted from a non-jpeg format.

Larges For All

We wished we had generated a Large size in the past for all photos uploaded, it would have made it simpler to dynamically generate the Medium 640 size. Before May 25th 2010 we only generated Larges for photos uploaded greater than 1280 in size, now we generate a Large no matter what size is uploaded. This is great for certain types of photos, for example we can now display 800×600 photos(common to some camera phones) as a Large in Lightbox or on the All Sizes page. So, a Large photo will be 1024 pixels in size on the longest side, or the same size as the original if something smaller than 1024 pixels was uploaded(we never scale a photo larger, an original photo of 800×600 will have a Large that is 800×600). You can expect the Large to always exist for newly uploaded photos.

Using the API

The best way to get the URL for a Medium 640 is to include url_z in the extras field when calling the flickr API. When photo data is returned, it will also include the full Medium 640 URL in url_z, along with height_z and width_z. Constructing the URL from the photo data returned will also work, but less reliably for photos before March 31st 2010.
http://farm{farm-id}.static.flickr.com/{server-id}/{id}_{secret}_z.jpg
See: http://www.flickr.com/services/api/misc.urls.html

Who are you, and what do you?

I’m Stephen Woods and I’m a frontend engineer at Flickr. Along with the rest of our team I am responsible for the bits that make the UI work, which mostly means html, css and javascript. So I write code, but I also make sure the design of the site looks and works the way the designers want it to.

What hardware are you using?

In terms of computers I have 15″ MacBook Pro with a 24″ monitor, as well as the standard ipad and iphone. I don’t have a desktop anymore and I do any hacking or side projects on a slicehost image. I used to have a pretty large collection of random computers and desktops, but over the years I have really cut back on hardware, it just doesn’t seem necessary anymore. Like a lot of people here I also enjoy photography. I have a digital rebel xsi and a someone worse for wear 4×5 view camera, neither of which I use as much as I would like.

And what software?

I use TextMate (and sometimes vim) for coding. My development browser is mostly Safari, with Firefox/firebox for some things. I use Charles proxy a lot for HTTP debugging. VMWare fusion is indispensable. I have a portable hard drive with a little collection of VM images to test all the various browsers out there.

I am also completely dependent on Evernote. I use it for everything. Frequently I remember something I need to do or figure out a problem while lying in bed, so I just grab my ipad, write down my notes and they are on my laptop when I need them.

What would be your dream setup?

My dream setup would be the MacBook Pro with the good video so I could actually play games on it. Otherwise I am pretty much living the dream.