Christian Heilmann

Posts Tagged ‘sunnyvale’

Want to work for Yahoo? We’re looking for web developers in the UK and the US.

Sunday, November 29th, 2009

A new year is coming which always means new opportunities. If you think Yahoo is a place to work and help us build the biggest web sites on the internet here’s your chance. Requirements are:

  • Hand-coded (X)HTML, CSS, and JavaScript
  • Solid knowledge of standards-based, accessible, cross-browser web development
  • Basic PHP or other front-end language (e.g. Python, Perl, Ruby) programming skills
  • Experience in developing web applications with rich client interfaces using AJAX, drag and drop, and other DOM Scripting techniques.
  • Experience with JavaScript libraries such as jQuery, Prototype, and especially the YUI
  • Experience developing functionality/applications by assembling existing code modules
  • User-level experience with *IX-style command line (BSD/Linux)
  • Experience using version control systems such as CVS & Subversion, including branching and merging
  • Experience with bug tracking software

The full job specification for the UK is here= and the US openings are also available.

The US jobs are located in Sunnyvale, California and the UK ones in Covent Garden, London, bang in the centre of theatreland and a stone-throw from Soho.

You can also send me your CV or contact me on Twitter: @codepo8

Training new developers in the valley – Day 1

Thursday, July 24th, 2008

I am currently in Sunnyvale, California to teach a bunch of bright young people the ways of the DOM and YUI. I am one of the trainers in the Juku project of Yahoo! (alongside Ross Harmes and Douglas Crockford) and give a 12 day intensive course. Naturally, this keeps me busy and I don’t get to blog as much – or so I thought. Actually I don’t see much harm in doing a day-by-day report on what we covered here, as a reminder for myself and maybe an inspiration for your own training courses.

Day one is traditionally for me the day to test the waters and see how my style of training suits the group. I hate sitting in lecture-style training with a massive binder and interspersed with coding exercises that are more hello world than anything useful. Instead I do more of a hands-on style where I try to get the attendees to form and run most of the course with me aiding by steering and helping out. There is an overall master plan for the course (you have to cover x amount of content in y amount of time, after all) but the individual days might differ a lot according to the subject matter. I normally tend not to use the computer as much as possible (as it leads people to surf around and get distracted with work mail) but in this case this’d be tough to do.

I got to know the attendees and asked them who they are, what they do, why they are here and what they want to get out of the course. I was very happy to hear that whilst the subject knowledge level of the group differs greatly from member to member, they all wanted to “learn how to apply things in the real world” and “get in-depth knowledge of how browsers deal with the DOM and DOM scripting”.

I started by explaining that DOM scripting is more than just manipulating the DOM but that we coined the term (in the now defunct WaSP working group) as a quality mark of DHTML development. I re-iterated the need for separation of development layers and the ideas behind progressive enhancement.

  • We set up a valid HTML document, explaining what is needed for any document to become one – doctype, a title, encoding, language, reading direction and all the necessary elements.
  • We talked about where to put styles and scripts and the impact of their location on performance
  • We then went to learn about the DOM, setting up and using Firebug to play with it and took a look at getElementById() and getElementsByTagName().
  • We talked about optimizing for loops and iterating over resulting HTMLCollections with as few code as possible whilst not sacrificing maintainability or performance.
  • We went into reading HTML attributes and discovered the pains of reserved words like class and for
  • Last but not least we created our own getElementsByClassName function.

The last aspect was especially interesting, as I deliberately kept the specifications of the function loose and asked the group to plan it on a whiteboard before plunging into it. The discussion around the planning showed that there are millions of ways to approach this problem and that if you mix developers that come from a UI-centric background with hard-core C++ developers you get interesting approaches to the same problem

You can see the results of the different teams in this document. The different examples are commented out with the quick commenting trick so to try them out, just add another slash in front of the /* preceeding the functions.

Day two is about to start…