Debugging AJAX with Fiddler

By default, IE & Fiddler won't track HTTP traffic through localhost - a pain when developing locally.

A few work arounds - if using localhost, the easest is to acces it as below:
http://localhost.:3233/Default.aspx
with a "." after localhost. You can also use your machine name.

Taking a look at the differences between web service calls & update panels prompted this - interesting to see the differences in data being passed back. Nothing comes for free, and although UpdatePanels are really easy to implement they do have performance concerns (above and beyond the page going through its entire life cycle).

I then watched the below video, where they point out the Fiddler issue which would have been nice to have known before I hunted for it myself.

http://asp.net/learn/ajax-videos/video-160.aspx

If you haven't checked out the videos above, you owe it to yourself to do so. Excellent stuff.

Dealing with Success

Great article below on the evolution of the architecture at MySpace.

http://www.baselinemag.com/print_article2/0,1217,a=198614,00.asp

I especially like the comments about caching - as I stated previously, I've been using caching a lot to improve performance. It works pretty well with frequently accessed/infrequently changed data.

That level of hardware is pretty impressive, to say the least.

Cross browser postback

Meant to publish this a while ago - cross page postbacks are interesting if only for that fact that they're a lot like the "old" way of doing things. I haven't investigated the new ASP.Net MVC framework, but seeing that using it means you can't use ViewState or PostBack's definitely makes me think that it involves Cross browser post backs.

http://msdn2.microsoft.com/en-us/library/ms178141.aspx


http://msdn2.microsoft.com/en-us/library/ms178473(vs.80).aspx


http://weblogs.asp.net/scottgu/

AJAX and UI Concerns

I had a request come across my desk that, as a business requirement, required AJAX. Really? Asking for a specific technology? Definitely interesting that AJAX is to the point that people are requesting it. Obviously AJAX is a means to an end - people really want more sophisticated user interfaces without have server refreshes, and sure, AJAX is probably the way to do that, but interesting that its one of those buzzwords that is starting to take hold (see Wiki, Blog, etc).

Regardless of how you feel about Microsoft technologies, they're certainly putting a lot of effort into teaching people how to use their products. The amount of videos and tutorials out there is really quite amazing.

For a starting point, see below:
http://asp.net/ajax/default.aspx

So in between the time I wrote the first part and the below, I ran across:
http://script.aculo.us/
Didn't sound TOO promising, but whatever - Javascript libraries are great as I don't have to write them myself.

And then I saw the below:
http://wiki.script.aculo.us/scriptaculous/page/print/SortableListsDemo

How cool is that?

Which brings up a really interesting point - who's going to tell me to implement that kind of control? A business analyst? Are they really going to be on the script.aculo.us site and take a look at the demo's? Or download the Ajax Toolkit and tell me which controls they find useful? Should developers implement new UI controls on their own?

I think the answer is somewhere in the middle - UI designers and developers need to communicate more and more efficiently. I attended a user interaction conference in the spring, and the issues that people had with their software engineers was startling. Are we really that difficult to deal with? I think the answer is probably yes, a lot of software engineer's are that difficult, but you're never going to get good products without having a good open dialogue with UI designers, QC analysts - its a team approach that needs to be preached and followed. I think that's one of the reasons people are all over Agile development - it forces people to communicate. This doesn't mean we can't take ideas from Agile and put it into practice with day to day work, though.

More on the ASP.Net Ajax toolkit when I have time to really blog about it.

Links:

Main script.aculo.us site: http://script.aculo.us/
All demos : http://wiki.script.aculo.us/scriptaculous/show/Demos
Sortable Lists: http://wiki.script.aculo.us/scriptaculous/page/print/SortableListsDemo
ASP Ajax: http://asp.net/ajax/default.aspx

Developer Tools

For people who live, eat and breathe technology, it seems like we don't often vary the tools that we use. For instance, we find a text editor that we like (I still don't have one I'm wild about - I must have used MultiEdit for 5 years, Notepad++ is the current editor-de-jour) and stick with it until someone else shows us . How long has Fiddler been out? How long did it take me to learn how it worked? Likewise with the IE Developer tool bar, like with
with Nant, NUnit... take your pick.

I think part of the issue is that SO many of the tools are really bad, have poor/no documentation and it takes a while to learn them... only to realize the tool itself is flawed. A lot comes down to plain ole usability - complicated tools are hard to use, and won't get used much (a theme in "Don't Make me Think" by Krug)

Not a bad starting list - what are you guys using?

http://msdn.microsoft.com/msdnmag/issues/04/07/MustHaveTools/

Current tools I'm using daily/weekly/would die without:
Notepad ++
NAnt
NUnit
ClearContext (Outlook add-in, still under investigation)
Fiddler
IE Developer Toolbar
Reflector
Regulator
Google Bookmarks
FeedReader

Output Caching

Over the last couple years, I've really done a lot more "web-programming" than I've been used to. Dealing with web caching, http headers, stylesheets, javascript - much more web oriented than I used to. Which bring me to output caching.

Output caching seems like an idea that would be really useful, but I haven't deal with it all that much. I'm currently working on some performance optimizations for a client, and I'm looking at using both output caching on a user control and setting the cache control headers.

Pretty good article below on the ins and outs of output caching from a .Net 1.1 point of view.
http://aspnet.4guysfromrolla.com/articles/022802-1.aspx

.net 2.0 really ups the ante though. The substitution bit below is pretty cool.
http://aspnet.4guysfromrolla.com/articles/121306-1.aspx

VaryByControl is also pretty neat, and gets cool pretty quickly (see the last example).
http://quickstarts.asp.net/QuickStartv20/aspnet/doc/caching/fragment.aspx

I think one of the more important ideas that I've seen is that you can do caching at so many levels (expires headers, output caching, data caching, etc) and you really need to keep those things in mind, especially if your system/framework supports those ideas. The CMS I work with right now does a lot of web-based caching, and knows how the HTTP headers work is a pretty crucial part of writing an application for it.