Christian Heilmann

Posts Tagged ‘architecture’

Giving technology to the world – a talk about writing good code examples

Friday, February 5th, 2010

One of the things I love about my company is that you are perfectly allowed in Yahoo to give “Fire and Brimstone” talks to rally your colleagues. It is a very open company and if you can back up criticism with proof and offer solutions people are happy to listen to you.

Last Thursday I took the opportunity of being in the Silicon Valley to give a talk about giving technology to the world, pointing out mistakes we made in explaining our services and APIs, what works well and how some competitors do a great job at explaining complex technology in an easy to understand fashion.

It was a great opportunity to explain the concepts of developer evangelism to an internal audience who hadn’t yet read anything about the matter of seeing developers as an audience.

Check the slides on SlideShare and the audio on archive.org:

Listen to the Audio of the talk on archive.org:

Do you know any great API sandboxes and documentation? I’d be happy to have more positive examples!

Let’s make 2008 the year of embracing the server side with Ajax

Sunday, December 30th, 2007

I am always fascinated by the amount of Ajax tutorials and examples out there that totally ignore the backend part of an Ajax app. A lot of times you’ll find page-long ravings about the 6-7 lines of JavaScript that allow the client to make an HTTP request but when it comes to talking about the proxy script needed to allow for cross-domain requests a lot is glossed over as “you don’t need to know this, just use this script”.

That would not really be an issue if the scripts offered weren’t that bad. Unsanitized URLs are the main attacking point for cross-server-scripting attacks. If you use a PHP_SELF as the action of your forms you shouldn’t be too confused about a lot of mail traffic from your server or text links on your site you didn’t sign off and get money for.

The other thing about Ajax information on the web that amazes me is that people keep complaining about the slowness and problems with converting data from one format to another on the client side. Let us not kid ourselves: even after all the articles, books and podcasts about Ajax we still have no clue whatsoever what a visitor uses to look at our products. We cannot tell for sure what browser is used, if there is assistive technology involved or anything about the specs of the computer the browser runs on. This to me makes the client side the least preferable place to do heavy calculation and conversion.

The server side, on the other hand, is in your control and you know what it can do. Complex regular expressions, XSLT conversion, all of this is much easier to do on the backend – and you know that the text encoding will work to boot. A lot of complexity of Ajax apps is based on bad architecture and design decisions and on relying on the client side to provide necessary functionality.

So if you ask me what the ratio of client-to-server code of a good Ajax app is I’d say 30% client and 70% server. The 70% on the server should be used to provide security, non-JavaScript fallback functionality (yay accessibility) and conversion of data to small, easy-to-digest chunks for the client (think HTML and JSON). The 30% client side code should mainly be used up to enhance the usability of the product and make it easier for your visitors to reach their goals.

So here’s my plan for 2008: whenever I talk Ajax I will try to cover as much backend as frontend. I’ll do this by partnering with other experts as I myself created some terrible PHP in the past. I hope that others will follow that example as Ajax is a wonderful opportunity to bridge the gap between frontend and backend engineering – and we have to talk to each other to create a good app.