[Advert: Support Joe Clark's Micropatronage Project - support accessible media research]

Syndicated feed for Web Development

Weblogs: Web Development

All the things that have no direct relation to web standards or web accessibility

Web Development links

Atom Feed for this links blog Link blog feed

Tuesday, June 19, 2007

London Hackday: BBAuth and Yahoo Mail

BBAuth Authentication system

Dan Theurer covers Yahoo's BBAuth, authentication system. The main reason behind making this API available on the web is so that we can provide programmatic access to all data in Yahoo!. Using web services it makes it easy for third parties to integrate Yahoo data into their own services. It opens up Yahoo! data to mobile as well as desktop devices, and allows users to us data how they want.

September 2006 saw the first Open Hackday, and when the Mail API went live. At that point Yahoo! web services gets interesting, since we are no longer just reading or consuming data. BBAuth can be used to log into third party apps with a Yahoo API, making Single-Sign-On easy.

When using BBAuth on third party applications the process is as follows. When you click on the sign in link on a third party application you are redirected to a Yahoo! login page. The next page is one where you are asked to confirm that you are allowing a third party permission to use your login data. When you agree you are sent back to the original third party application.

The third party application then receives a unique token which is valid for two weeks. If requested, BBAuth can return a user hash. All method calls to the BBAuth API are signed with a secret value issued by Yahoo!.

The third party application then submits a signed appid and token, and BBAuth responds with a cookie and WSSID in the response body. Then the third party application can talk to the relevant Yahoo! endpoints (e.g. Mail API). The cookie is valid for one hour, and would need to be refreshed after that.

Mail API

Ryan Kennedy covers the Yahoo! Mail API. This was launched as a web service at the first Open Hackday in September 2006. March 2007 saw the release of version 1.1, which is the official release. The idea behind the Mail APIs is to treat mail as a platform, not just an application. Yahoo Mail has over a quarter of a billion users, and is the largest property in Yahoo!.

Treating mail as a platform is not a new concept. POP and IMAP interfaces have been available for years, and offer features like folders. Offering mail as a web service allows us to offer things IMAP and POP can't do well, for example the ability to strip javascript from HTML emails (as well as stripping out nasty stuff). Web services offer much richer services than IMAP.

The Mail Services is a Tiered service split into two groups, one that's available to all users, and a set of features that's only offered on premium mail accounts. The reason for the separation is cost - Mail is an ad-supported system; we want free users to come into the web system to read and compose mail.

With all mail accounts the following features are available:

Premium mail accounts offer the following extras:

What sort of applications can you build? Social applications - email is still the largest, and oldest, online social network). Separate user interfaces, like a more accessible or customised interface, or an interface from mobile phones. Desktop applications are possible, the login, using BBAuth is web based, so it needs a twist to integrate that into a desktop application.

Building headless applications isn't going to be possible because of the authentication system being web-based. It needs at a minimum for the user to login every 14 days.

The documentation is available on the Yahoo! Developer Network in the Mail API section. Sample code is available for .Net, Java, PHP, Perl, Python. Actionscript samples are coming soon.

Ryan also points out that there is a gallery of applications using the Mail API, so offers a good place to seek inspiration on using the MailAPI.

On the Sunday I was listening to a conversation Aral Balkan and Ryan Kennedy on the Actionscript sample code, its using the SOAP interface to call the Mail API. Aral is seriously considering adding the Mail API to his fantastic SWX framework, thus making the Mail API elegantly available on all Flash platforms, from Apollo, to browser plugin and mobile phones running Flash. This can make Yahoo Mail available on mobile phones, which to me is a spectacular feature.

Tuesday, February 06, 2007

The role of a web developer

I've been a web developer for close on 7 years now. I started with building microsites and content updates for the first few months, and gradually got into building Java based backends. That progression kept pace and in the last two years at Legal & General I was co-developing of entire e-commerce applications, seeing every little piece that makes up a Java-based web application. Now with Yahoo! I'm in a position where my skills as a web developer are being used, but not the skills as a server-side developer.

I admit, through the course of the interview process, I debated with myself if I could manage just being the front-end guy. Would I miss not being knee-deep in server-side stuff, not being actively involved in the entire scope of the project?

The first few months I worked in a state of accepting that I've lost what I used to have. It was raised as a question in my interview whether I understood I wouldn't be a lead developer, just a web developer. I understood the role, but perhaps not the implications of it.

Today, I think I understand those implications. I understand why making what on the surface looks like a step backward was the right move. Its because it moved me closer to where I'm happiest - a job that challenges me over a broad range of areas. It isn't a step back, but a leap forward - I'm unleashed from fitting into a job description that fails to describe the value I offer. I'm allowed to do the job I was really doing at Legal & General, and not to be ashamed of it.

Machinations of Legal & General

When I first started working for Legal & General, e-commerce developers wrote web applications in Java. HTML was just beneath them, and it was a task well suited for the most junior member of the team. When senior developers had no other choice, bizarre conceptions like generating markup on the fly within an EJB came to the fore, as well as the notion of storing entire HTML templates, JavaScript and images in a user session! As a result, no matter the approach, the web front-end of the application was shoddy. It was generally considered lucky the web application actually worked in one particular browser (the corporate desktop browser of choice), and you were just plain mad if you even considered trying it out on something that wasn't a corporate standard browser.

With the emphasis on the logical view of the application, there was very little focus in the front-end itself. You could nuke the United Kingdom, and still get your pension valuation. And yet, the one public facing interface to these services was utterly diabolical.

After a prolonged fight, particularly with a strong emphasis on accessibility, the web interface to these services started to improve. Hopefully, they were in a much better state when I left than when I joined. What was immediately obvious was I was doing the expected role of a senior 'ecommerce' developer as well as ensuring the web front-end was of sufficient quality - and so was everyone working in what was the Legal & General web team. Although we were seen as mere web developers, we were doing the same job as the java developers, and more.

Moving to Yahoo!

Switching to Yahoo!, in some sense could be considered a step backwards for me - losing out on the actual code-jockeying. But this is compensated by being able to focus on the most important part of a web application - what gets sent to the browser, for if that doesn't work - no amount of application design will correct that.

And the key implication is this: the specialisation on the web front-end means the quality of the front-end increases, because of the increased expertise. We have the same skill set as the engineers that develop the code that is the guts of our environment, but this isn't utilised because there's more value to be gained by using the web skills.

A couple of times in the last few months I've managed to diagnose problems with various applications that have had engineers befuddled for (apparently) months. That's not to say I'm anyway better than the engineers, we have some top-notch developers working with us in Europe. Its more to do with a wider scope.

Web development as a mindset

Web development isn't one skill, its an aggregation of many skills and knowledge - almost anything used in the context of the web counts as a web development skill. There are the basic skills like HTML, CSS and a server side language - that's enough to build a web application - this is the staple diet of a web developer.

No two web developers are the same, apart from sharing the same foundation of skills. Some web developers specialise in JavaScript - and they produce amazing work that I can't begin to comprehend. Anyone involved in building maps-related web applications has my respect - its something I don't understand yet - too many events going on in the browser to get my head around sufficiently.

Other developers specialise in internationalisation, or accessibility, or usability, or information architecture, or design, or search engine optimisation, or flash, or caching, or specialising in certain frameworks, templating systems, microformats, shell scripting, Unix (and its relations of Linux and BSD), system administration, Applescript, XML (even Atom and RSS), Web services (particularly REST and POX), Semantic Web technologies, and the often overlooked customer-facing skills. Its a melting pot of skills that no one web developer can completely grasp.

All those skills, spread across a team of highly skilled, passionate individuals comfortable in their own skills to willingly and freely share their knowledge and expertise. No one is an expert in everything, but everyone's an expert in a handful (or more) areas. And that is the modern web developer.

Web development and satisfying curiousity

But its not all about what expertise they bring to the table right now. Web development is also a mindset - its the passion for working on the web, allied with a thirst to learn new things - be it a new technique or a new technology. Quenching that thirst, that's the challenge of a web developer. Satisfying that curiosity to understand what's out there, and sharing ideas.

Older Posts:

[ Weblog Frontpage | Blog categories and feeds | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]