Apps or Sites?


Part of me chuckled at the so called hack that affected Twitter today, not that something like this couldn’t affect any site (although given the simple and well known nature of the attack, it really shouldn’t have hit a site like Twitter) but it did remind me of the days in the early 00’s when this sort of thing was common place and the sort of problems we all had to face when coding sites in that era.

What did strike me was whilst I did notice it (whilst random JavaScript tweets are always fun doing the same one over and over again is sort of labouring any joke) I wasn’t affected by it. Why because I wasn’t accessing the Twitter website only consuming the feed from within an app, in my case TweetDeck.

Saved by TweetDeck

I was sort of surprised this week when I heard that 70% of people still use the Twitter website to send and read Tweets. I mean, Wired this month had a whole article bemoaning the death of the web, hasn’t Twitter read that and immediately shut down the home page. Hmm, no, in fact they just released a whole bunch of new functionality (which I can’t yet use, damn them) that can only be accessed via the website, just in time for the hack to emerge.image

Wired do have a point though, more and more people are buying applications for their phones, as smart phones become cheaper and cheaper more and more people will buy apps, just as more and more people will get access to the internet for web browsing. Applications will use the old ‘internet’ for services for the applications on their phone and the ‘web’ will go back to being one of the protocols used on it, that being HTML over HTTP. 

The thing about apps is that they don’t suffer the same attack profile as a web site, when information is mainly entered using an HTML form then that’s where people will look to attack. It’s harder to attack a series of apps that use a data feed, unless you can corrupt the feed in some way, as they usually will display the data in its own way, usually not using direct HTML or even in a browser.

Of course you could be using a compromised application, either downloaded onto a PC from an untrustworthy source or side loaded onto an Android or jail-broken iPhone in that case don’t say I haven’t imagewarned you. In fact the careful cultivation of the App Store under iTunes and to a slightly lesser degree the Android Market place adds that little bit more protection to users than the wilful installation abandon people have on their home (and sometimes work) PC’s (and Mac’s and Ubuntu boxes, but as I said who’s bothering to write a virus for those relatively paltry level of users /jk!).

Patched Apps

image The fact that Twitter patched the XSS issue in relatively short order is one of the main areas where the web works well. The ability to roll out a patch to millions of users at once be it a patch or new features, after thorough testing of course, is only really possible with application that leave no trace on the local machine. Cloud based applications not only protect your data from hardware failures but they can also be patched or upgraded without you having to do anything. Now I know some people will not like this, the same sort of people who still use OS/2 because they don’t understand these new fangled operating systems.

Desktop and mobile applications require an upgrade cycle because they rely on you installing something on a machine. On a mobile application this can be more arduous as they rely first on the developer getting the new application checked by the store it’s being delivered by, and then you have to be notified by the store that a new version is available, finally you have to actually install it.

On the web once it’s passed the requisite tests, it’s just there. Updated lazily in the background or when you next log into the website.

Apps or Sites, your call as long as it’s the cloud.

I read a comment the other day, every time I open an on premise application or use an on premise server to create data, I take a risk with my data. Every time I use cloud services for all sorts of tasks I know it’s not quite as whizzy as on premise applications or servers, but I know if my machine or server dies it’s still there. All I need is another browser and I’m up and running again. No need to install an app, no need to worry about the operating system either mostly these days.

image It works for me, I for one am happily replacing my offline apps for online ones when I can. Sure I still use some installed applications, I still love Live Writer for blogging for instance, Picasa for managing my photos and Google Earth for well just looking at my house from space, but those are my last few on premise applications I use at home (that aren’t games) and Google Earth and Live Writer are conduits for an online services.

I could do the same with my photos if I ever got the time, and there is the crux, as it becomes easier and easier to move data and information to the cloud, or if it has only ever resided there for many digital natives, then more people will and hopefully will be better off because of it.

Why Fiddler is like a Sonic Screwdriver

The post was going to be initially titled, why Visual Studio 2008 is like a VW Bora, in reference to the clip_image001current fun I’ve been having with my current Silverlight adventures. Unfortunately that particular episode will have to wait although I might give it as my Ignite presentation at our companies away day, watch this space as I’ll only give it if we don’t get enough other presenters. Anyway I digress, or should that be ramble, the current post has been sparked by two things, watching Doctor Who episodes with my daughter and fixing a simple connectivity problem in Silverlight.

Sonic What?

imageJust in case you’re not a Doctor Who fan, and I know it’s hard to believe that there are a number of them out there, or maybe you’re not British and been brought up with good time lord for the last 40 years (give or take a few gaps) then a little explanation is in order about imagethe sonic screwdriver. The sonic screwdriver is a plot device which allows the good Doctor to fix or interrogate any system or machine to find out information about it, fix it or damage it. Usually it’s just a flick of the wrist, a press of button and a flash of light and its job done, procedure complete, information acquired. Now unfortunately in the real world we don’t have a sonic screwdriver that can do this, but we do have fiddler.

So what has this got to do with Fiddler?

imageFiddler is a free tool that allows you to view the requests made from a browser (usually IE). It can be used to interrogate the requests and responses and to visually give you an indication about what might be wrong with a particular application. Like a sonic screwdriver it can gather information just running in the background without any interaction and can tell you how web applications work at the browser level. This can be useful to see why something might be failing in an application even though you might not have access to the code or to see what a system is requesting even though the code is not you own.

This can allow you to see exactly the information a website is sending and receiving from the browser very useful in an era where the logic is maintained within the browser as JavaScript applications or Silverlight/Flash programs. Here it is often useful to see the responses back from the server or more importantly why a request is failing and often this is to do with security issues or cross site access rights.

It’s screwdriver time!

Often the time you break fiddler out to diagnose the problem is the same time that Doctor Who breaks out the screwdriver. System calls failing, applications not working properly once installed on a remote site or map services not responding. Panic starts to set in hours go by as you try and vainly debug the application then someone (usually me) pipes up ‘have you seen what you get in fiddler’?


Now looking into fiddler is like staring into the matrix, when you have done it enough you start being able to see the woman in the red dress even though the screen just shows the weird green dots. You can start to pick out anomalies in the calls, fiddler helps you, it highlights file not found and errors in bright red and it shows you cached items in grey, both of which can give an indication of possible problems.

Authentication issues or caching problems can both cause errors that can be hard to track down, can manifest themselves in esoteric ways and can end up burning a lot of time to diagnose. Fiddler can be your sonic screwdriver in those moments.

Divining a problem.image

Now this post could equally be titled, how many times does a man need to forget to place a crossdomain.xml file on a web server before it stops being funny, but it does serve as a good example of  where fiddler could have shown a problem well before the final issues were resolved. Crossdomain.xml and its Microsoft equivalent of clientaccesspolicy.xml are used by Flash and Silverlight (which can use both) to tell their particular run time environments that they can access services and data on a particular server. This is particularly important when a rich internet application needs to access services or files from a server that it is not served (downloaded) from initially. Without these files present at the root of the server then the request will fail often with unforeseen consequences.

I must admit after going through the story the reason why there were problems becomes obvious, but the feature layer was coming from another server which I had not used before and I had no idea that there might be an issue with it. But it serves as a reasonable simple example nonetheless.

In my particular case I was using the ESRI Silverlight API in conjunction with the most excellent (and free!) Blacklight control library. Now my application was working without issue when I decided to add another layer into my map using a feature layer. I merrily put the lines of XAML into my page to add the feature class (notice server names have been changed to spare the innocent, any maps generated are done by actors).

image Having set up the right renderers and such like I proceeded to run the application. Nothing came back; I checked the code, double checked, triple checked, but nothing. The base maps came up but no features on the top. I then proceeded to add the new map service as a normal dynamic layer as such to check there wasn’t something wrong with the FeatureLayer class. The XAML looked as such:

image Now this gave me an error in Visual Studio:

imageDoh! I think. I had made the classic schoolboy error of not adding the cross domain file onto the new server. I can see this in fiddler as such, so just waving fiddler at the requests has allowed me to divine the problem, much like (in my head anyway) the sonic screwdriver.

image Now this is a good example of being able to see the problem in fiddler even though the application wasn’t reporting any issues. Being able to diagnose problems in this way should often be the first port of call with any issue that doesn’t get picked up by Visual Studio, especially when calling remote services.

Adding the following cross domain file to the server (it’s internal so it doesn’t require too much security, but don’t use this in the wild verbatim) allowed the application to work fine with both the dynamic layer and the feature layer, problem solved, Daleks defeated (again in my head).


Every time I use fiddler it saves me time, the key is remembering to use it earlier in the problem solve! That way you can save time being burnt on things that have simple solutions and concentrate on the other time killers like getting agreement on the UI design, as we know everyone’s a critic!

So where do I get my screwdriver?

Whilst fiddler is written by a Microsoft employee (Eric Lawrence) it’s not actually a Microsoft product ‘per imagesey’, but it does have some good information about how to use it here (msdn) and here (msdn).

If fiddler isn’t your thing, or you just think that pointing a glowing blue light at a computer might be able to fix any communication problem even in the real world, then you can get your own from Amazon here, in fact if I could get a Wi-Fi one maybe I could hook them both up <goes off to tinker in the shed>.

IE 6, 7 and 8 and other browsers. Support them all.

As you can see I’m not one for short posts, but sometimes a great article needs to be pimped. Smashing imageMagazine has lots of those and whilst I’m mostly a Web Developer and not a Web Designer (I do have an iPhone so there may be hope for me) it’s good to keep an eye on the current design trends for web applications.

Smashing, super, great, well not so great with IE6.

Their current article “CSS Differences in Internet Explorer 6, 7 and 8” is a change from the normal rant at Microsoft fare, but aims at understanding all the differences that occur in the Microsoft browser segment of the market around, in this case, their different handling of CSS. The main fact of importance is the imagecontinuing need to support all of the browser due to their market share, each browser holds almost an equal share of the 65%+ of the market (as seen on Market Share).

In fact if you break it down even more we see that IE8 compatibility mode beats Chrome and that really for public sites you should be testing for Safari as well.

Browser Market Share
Microsoft Internet Explorer 6.0 24.42%
Microsoft Internet Explorer 7.0 19.39%
Microsoft Internet Explorer 8.0 16.84%
Firefox 3.5 12.65%
Firefox 3.0 9.62%
Safari 4 2.92%
Microsoft Internet Explorer 8.0 (Compatibility) 2.30%
Chrome 2.0 1.74%

Like any large company, Microsoft has a great deal of legacy to support, people who have brought their products, people unlike myself who don’t want to upgrade at the first opportunity, who are happy with the way something works (even if it is IE6). Especially where a browser still holds such a large part of the market within the enterprise space, the cost to upgrade all of the browsers (which work for all the applications they currently use by the way!) could be prohibitive in the current economic climate.

Testing Painimage

All this leaves is a massive amount of legacy testing pain for development teams, especially when developing applications for use within an enterprise environment. It’s all very well for people on the social side of web development to trumpet the call to the new, but when part of your market is stuck in 2001, so to a certain extent are you.

At this point it’s interesting to look at the support level of browser for ArcGIS Server here. The supported browsers are Firefox 2,3 and IE 6,7,8. That’s not to say stuff won’t work in Chrome (it’s does, I’ve tested it) or Opera (I don’t know, sorry), but the official line is what is shown on the site, so when developing applications for use with ArcGIS Server it’s always good to remember what’s official supported and choose that as a baseline.

In fact many people are tempted to throw the browser out completely and fall back into the loving arms of the plug-in. Flash and Silverlight take much of the worry about browser support of the nuances of CSS imageand JavaScript but providing a nice sandbox for the application to play in. Unfortunately they are no true panacea. Often the enterprises that are still on IE6 are probably on Flash 5, if they have Flash at all and might never have considered Silverlight (although Microsoft’s positioning gives Silverlight a more enterprise-y feel allowing it to make inroads sooner within the firewall). This leaves you back at the beginning needing to support your browser based application in IE6, there is no escape, accept it and test accordingly.

And finally.

One great quote from the comments is this “You could power every house on Earth for a few hours– just from the sheer RAGE MSIE elicits from Web Designers.”. It’s not just IE, the lack of standards amongst browser has always been a frustration, Microsoft might be the current football to be kicked around, but in its day Netscape was the villain. image

Whilst most people, probably even Microsoft, want IE6 to go away, it wont soon, people image like have a funny campaign, but the only thing that will change that is when all the big companies have gone through a technology refresh and the
re are only a few copies of IE6 lingering left. In the non-corporate world, well as Amy Barzdukas (Microsoft IE general manager) says "Friends do not let friends use IE6”.