Christian Heilmann

Posts Tagged ‘yahoo’

Useful tweets widget using Yahoo Pipes and some JavaScript

Sunday, September 28th, 2008

If you look on the right side of this blog (and you can see) and you have JavaScript enabled you’ll spy a little “Useful tweets” widget (list). This is done with Yahoo Pipes and some JavaScript. As people asked me how it is done, here goes:

The idea

I use twitter a lot. Some of what I write is very relevant to the blog here, some is not fit for publication and some is just personal. So publishing all the tweets here would have been disruptive, hence I tried to find a way to filter things down.

What I do is that I end every tweet that I want to show up here with a § symbol, thus giving me a handle to filter out the good ones.

Playing nice with twitter and not summoning the fail whale

As twitter is probably the most hit API out there I didn’t want to go through the API and all the authentication malarkey. Instead I am using the ATOM feed and pipes to get the information and to filter it down.

Yahoo pipes is still full of win when it comes to filtering, mashing and converting data, and the pipe in question that I am using is available here: Useful tweets pipe

It takes the atom feed of a twitter user of a certain ID, removes all tweets but the ones ending in a § and removes the user name of the output.

Using the pipe and displaying the content

In order to display the pipe all you need is a small JavaScript and the right HTML in your page (or in my case WordPress template):




The link means the thing still makes sense when JavaScript is not available and the script does the rest. One thing you need to do to show your useful tweets instead of mine is to change the class on the DIV! You get the number from your twitter page:

  • Go to your twitter page, f.e.: http://twitter.com/codepo8
  • Click the RSS link at the bottom
  • Check the URL of the feed, your ID is the number in between the slash and ‘.rss’, f.e.: http://twitter.com/statuses/user_timeline/13567.rss

The JavaScript for display of the badge is no rocket science whatsoever:


var tweets = function(){
var x = document.getElementById(‘mytweet’);
if(x){
var twitterUserId = x.className.replace(‘user-’,’‘);
var s = document.createElement(‘script’);
s.type = ‘text/javascript’;
s.src = ‘http://pipes.yahoo.com/pipes/pipe.run?’ +
‘_id=f7229d01b79e508d543fb84e8a0abb0d&_render=json’ +
‘&id=’ + twitterUserId + ‘&_callback=tweets.tweet’;
document.getElementsByTagName(‘head’)[0].appendChild(s);
};
function tweet(data){
if(data && data.value && data.value.items){
if(typeof data.value.items.length !== ‘undefined’){
var ul = document.createElement(‘ul’);
var all = data.value.items.length;
var end = all > 5 ? 5 : all;
for(var i=0;i < end;i++){
var now = data.value.items[i];
var li = document.createElement(‘li’);
var a = document.createElement(‘a’);
a.href = now.link;
a.appendChild(document.createTextNode(now.title));
li.appendChild(a);
ul.appendChild(li);
}

x.appendChild(ul);
}

}
};
return{
tweet:tweet
}

}();

  • We check if the element with the ID mytweet exists
  • We then extract the user ID from the class name and create a new JavaScript pointing to the JSON output of the pipe. This, once loaded, will call tweets.tweet() and send the data as JSON
  • The tweet() method checks if data was retrieved, creates a list of links and appends it to the DIV.

Hope this is useful to someone else, too.

UK government browser guidance in dire need of upgrading

Monday, September 8th, 2008

One thing web developers who do not work in large corporations or with the public sector or education often forget is that there’s a lot of red-tape and checkbox ticking to be done before you even start a line of code. This get worse once there has been a decision made or a guideline in place, as replacing or upgrading those slips far down the list of need-to-do’s.

The web is a large and confusing place and the fact that you just cannot control or demand the setup your visitors use to come to your site and consume what is there can be frustrating. To me, it is what the web is about and I love the challenge of the unknown. Official sites, however, do not revel in unknowns and challenges and try to help webmasters to release quickly by cutting down on things to support.

Last friday, the UK government’s Central Office of Information (COI) published a public consultation on browser standards for public sector websites which misses the mark of good advice by quite a bit.

Bruce Lawson checked the guidelines in detail and responded to them on the WaSP blog

I agree with all that is said there, and humbly point the COI to the graded browser support my employer applies to steer the wild web into easier supportable channels.

There’s a comment form on the bottom of the page on the guidance site that gives you a chance to react to this. It might not mean much, but let’s not forget that if we can have an impact on the public service, it’ll mean a lot more web sites out there that do the right thing. These are the areas we should concentrate on – if your blog doesn’t render properly that is much less of an issue than you not being able to pay a parking ticket or sign up your kids for school.

Yahoo Music API tutorial

Friday, August 29th, 2008

Over at the Yahoo Developer Blog, I just posted a quick tutorial how you can use the Yahoo Music API to show videos of your favourite band in a few dozen lines of JavaScript.

musicvideoplayer.jpg

This is a bit of a rough’n’ready way of doing it and I’ll get some more sophisticated examples out there once I gave some feedback to the Music API team :)

Training new developers in the valley – Day 3

Sunday, July 27th, 2008

On the third day we went deeper into the oddities of the DOM and how to access and create content in the current document. One thing I realized very fast is that teaching DOM before the days of FireBug was much easier – you can lead the group from property to property and method to method. With FireBug they are much faster in finding out what can be done and also get a lot of goodies that FireFox provides but aren’t the standard.

We went through the basics – setAttribute and the differences when using it in comparison to the shorter property notation (MSIE sees expando properties as attributes and in order to remove them you’d have to null both the attribute and the object property).

We then moved on quickly to createElement and createTextNode and detected the need to apply them to the document somehow to make them appear.
This lead to insertBefore and appendChild and we discovered that there is no insertAfter, which is a logical fault in the DOM.
As a remedy I asked the group to write their own insertAfter, which is a good exercise to re-iterate looping through child nodes as well as using the creation methods. There are of course several methods of writing an insertAfter, but I was pretty much stunned to see one of the attendees to come up with one I hadn’t thought of:


function insertAfter(newElm,elm){
var clone = elm.cloneNode(true);
elm.parentNode.insertBefore(clone,elm);
elm.parentNode.replaceChild(newElm,elm);
}

I am not too sure about its performance, but I really like the logic of it: this way you can be sure the new node will be after the old one regardless of where the old node is (last node, first or somewhere in the middle). This also means you don’t need to fork and use insertBefore or appendChild respectively.

Other examples we went through were removing nodes with a certain class (to show the problem of the changing length when iterating over a nodeList and removing elements) and writing a simple form validation script that changes the labels of mandatory fields when they are empty.

I wrapped up the day using the JSON output of the del.icio.us API to write out a list of bookmarks and tags:


In an extra step I then asked the team that instead of calling the API in an own script tag to progressively enhance a link and create the script tag dynamically:

My Delicious Links


We then ranted a bit about the non-logic of DOM methods and their parameter order (“why is document.insertBefore(oldNode,newNode) not possible but instead we need oldNode.parentNode.insertBefore(newNode,oldNode)??”) and came up with a wishlist of DOM methods that should be native:

  • createLink(url,text)
  • insertAfter(newNode,oldNode) – consistent with the native DOM inconsistency
  • removeNode(node)
  • textElement(elementName,text)
  • addScript(url)
  • normalizeNode(node) – removing whitespace
  • getText(node)
  • setText(node,text)

This list is also the courses homework, and we’ll take a look at the results on Monday.

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…