Sunday, 13 January 2008

Knowing what's on your page

So in work the other day I was asked to help a colleague with an interesting error he was experiencing. In IE he would find on usually the second page load of the site IE would bomb out with an exception: "Internet Explorer cannot open the Internet site", "Operation aborted".


Now I had seen this error before and usually it was down to people forgetting or even not knowing that they had to wait for the DOM to finish loading before trying to fire off JavaScript that manipulates or uses the DOM.


Of course most of us know we can solve this by using event listeners to attach functions to load on the window.load event or my personal favourite by using some sort of .onDOMReady method. Just like the one in jQuery or YUI.


Now in this case it looked like my colleague had set up his JavaScript properly, it was using the YUI onDomReady so this wasn't the issue, so where was the problem. We ended up turning to his JavaScript JSLint'n it to see if there was something I had missed but still the code eventually validated and we still had the IE error.


So we scratched our heads and then by chance I noticed that the page with the error had a flash movie embedded into it. Now I'm very much in the camp of not liking how many developers embed flash into a page and I always use UFO (Unobtrusive Flash Object. It was at this point my colleague mentioned that he was also using UFO after seeing me use it in a few projects, as it allowed him to put alt content in place for non Flash peeps. It was at this point I realised what had happened.


In case your not fully knowledgeable on UFO, "UFO is a DOM script that detects the Flash plug-in and embeds Flash objects (files with the .swf extension)." What you can then do is replace the contents of one Div Container, say one which contains alternative content for non flash users, with a Flash object. It does this using JavaScript and I find it to be the only way of allowing flash on any sites that I work on.


Now as this JavaScript manipulates the DOM, i.e remove the contents of our Flash Div and then put our Flash object into it, it must run once the DOM is ready otherwise we run the risk of trying to manipulate the DOM before it's even ready. This is what our page was trying to do.


Now I mentioned earlier that my colleague had wrapped his JavaScript functionality into a onDomReady, now what he didn't check and I initially missed was what else was in the page and what other JavaScript was loading. In this case his new functionality was causing the page to load a little slower which meant that the UFO code, which wasn't wrapped in a nice onDomReady, was firing before the DOM had finished loading. Such that the Flash DIV wasn't actually available at the point that the UFO code was trying to run.


So we simple moved the UFO method call into our onDomReady function and we were sorted. This example clearly shows that especially when writing JavaScript you need to be aware of what else is on your page and in particular what else is interacting with it. Before writing some JavaScript that does X Y and Z take alook at the page or even site and see what else is running / loading. Not only will this allow you to ensure your code doesn't break or break anything else but you will also find if there is some code you may want to reuse.


For example I often find myself writing JavaScript that uses the YUI library as this is what i have used most however recently I was writing some new functionality for a site and started to use YUI as its what I use most, got the functionality working on my example page, then went to put it into the site and found that it was already using JQuery. I then had to go back and quickly change my code so that it used JQuery instead of YUI as using more than one JavaScript library in my opinion is stupid and means that the end user has to download far more and it will end up with page load times being sacrificed.


So when writing JavaScript ensure you know whats going on in your page before writing your code, otherwise you may end up with a situation like my colleague did or you may end up re writing you code like I did. And you may find that your work load is actually reduced as you may be able to reuse code that's already in the page.

Tuesday, 27 November 2007

for when you network shares are slow... lmhosts

LMHosts has existed in Windows for ever. Well I know it has since Windows ME anyhow. It's a file thats actually very rarely used by Windows. Infact most people don't even have one. So why am I talking about a mythical file that no one uses... Well that's because sometimes it is needed and useful. Here at home I have a nice Linksys NSLU-2 or SLUG as its known. This is running the very nice UnSlung firmware and as well as providing Samba shares it has an FTP server, twonkymedia and some other bits and pieces on it. Overall it's very good and keeps me very happy. However one thing really frustrates me about it. Accessing the Samba file shares are really slow in XP and Vista. Especially slow in XP. I thought that my poor slug may have been being over worked and even that the HDD attached to it could be experiencing some issues. Luckily I decided to do some research before doing anything drastic and I stumbled on a really interesting find. I cant find the forum thread I was reading, it was on the Linksys ones, but a user had suggested that Window Networking can struggle with the device and a way to speed it up is to create / append to the lmhosts file an entry for your device. This means that your box needs to be on a static IP address, but let's be honest this isn't a bad thing. So I went to C:\WINDOWS\system32\drivers\etc and created myself a new lmhosts file. Then by consulting our good friend wikipedia added the following line...

192.168.2.3    mjjamesSlug           #PRE             #SLUG
So i have my ip adress for my slug, the network alias, #pre so it caches it as i use this drive alot and then a nice comment at the end saying what this is for. I wasnt sure if I expected this to improve the speed of my shares but it did amazingly. Straight away everything loaded faster, explorer wouldnt have a good long think everytime i changed folders, my slug was usable again. So now I am going to add this change to all the comps on our home network and reap the benefits. Now the question is will normal windows file shares behave better if each comp has an entry in each other comps lmhosts file, I'm unsure of this but I may give it a go, it wont be that hard to set up 3 comps on static ip's .... Anyhow if you are experiencing slow network shares, especially on a nas or similar device then why not try lmhosts. You may even love it ;)

Monday, 19 November 2007

@Media Ajax London

So Today kicked off @Media's first Ajax conference here in London. I came down yesterday with a few guys from New Mind Derek and I took the train from Liverpool and after a speedy 5.5 hr journey we got into London Euston around 9pm. Today kicked off with Dion and Ben giving us an overview on the "state of ajax". This for me at least really covered the current state of play with Ajax, touched on all the main JS libraries and gave us an insight on what is around the corner. Before lunch Derek Featherstone gave us a great session on "Real World Accessibility for Ajax-enhanced Web Apps". I must say I really enjoyed this session and found Derek to be very witty. Its also good to hear that your not the only one who thinks in terms of semantic HTML. After lunch I also thought that Christian Heilmann's "Planning JavaScript and Ajax for larger teams". This for me opened my eyes to alot of things that at present we don't do in my place of work. I'm not commenting on whether or not this is a bad thing but I am hoping that some of the things Christian highlighted is at least given a go in our work place. In particular I like the idea of having Code Reviews where your code is moderated. This isn't to keep tabs but to help you as a developer to improve your coding ability but also to ensure that good parts of your code are shared and that knowledge shared! I also took note of the YUI team's Build Process, this process consists of validating code, minifying, consolidating and then tagging as Live. If we can streamline our build process code that is put into production should be cleaner and in theory more reliable. I also personally took to heart Christian's comments on our "inner hacker". I know that I often have a habbit of letting my "inner hacker" take over during certain projects and can let this happen during development time. What Christian suggesed is to contain this for more appropiate times. I.e coding in my own time and when I have some downtime in work, which may be rare ;) By doing this I will be able to deliver projects in theory within time better but also have better code. This did strike me hard and I know it's because truth hurts, hopefully I can devote more of my inner hacker to my main site and various side projects, who knows i may even get to blog about them :D That's it for tonight, just to say after Day 1 we all ended up for a few drinks on @Media at the abbey which was cool and after that Derek, Sunny and I headed over to the Hard Rock Cafe London. Well busy but well worth the trek :D --- I will be posting all my pictures from today on my Flickr