You searched for entries containing the words "application", "rss" or "xml".

Matching entries are ordered according to their relevance and not the date they were posted.

<!--
var plugin = (navigator.mimeTypes && navigator.mimeTypes["application/x-shockwave-flash"] ? navigator.mimeTypes["application/x-shockwave-flash"].enabledPlugin : 0);
if (plugin && parseInt(plugin.description.substring(plugin.description.indexOf(".")-1)) >= 4) {
document.write('<EMBED src="detec.swf" quality=high bgcolor=#ffffff ');
document.write(' swLiveConnect=FALSE WIDTH=80 HEIGHT=72');
document.write(' TYPE="application/x-shockwave-flash" PLUGINSPAGE="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash">');
} else {
document.write('<IMG SRC="images/animation.gif" WIDTH=80 HEIGHT=72 BORDER=0>');
}
//-->

My client has designed a screenshot showing how they would like their application to look. The guy who made it is fairly good with Photoshop and it has rollovers and tabs with 3D effect and everything. However, whilst he is a fairly capable amateur designer, he doesn't have a lot of knowledge of usability and has resulted to the standard muddling through approach. The design uses frames; employs a fair amount of javascript; will require frames to be kept in sync with each other and uses a JS tree view control.

Typically with the muddling through approach, a lot of it is fine. Syncing frames all the time will make the application more complicated as each page has to work out where what goes. The tree view is a worry as well. What if somebody hits it with a browser that can't handle it? I will build it using DOM methods and CSS so it's future proof, but I bet there are going to be people that use Netscape 4 to browse this application. Because it's a functional application I believe it's much more important that people can access it reliably. It's OK when you can't hit the latest Kylie website, but if you work in say, a hospital or a garage, you don't want to be upgrading your browser just to get your job done.

Somehow I need to bring these issues into discussion without making the designer think I'm having a go at his design. I also admit that there is a side motive, some of the stuff he has asked me to do will be time-consuming to implement, so I'd rather not do it. My reason for this is not just laziness, they could use my time better to create a more functional application.

The dilemma is working out how much I'm hired to talk and how much to do. Often I'm hired to build and advise but that isn't always the case. It's not black and white, of course, some things are open for debate, others are resolutely not. I get the feeling that the design of this site is not up for debate and there's only one way to find out. It's not my favourite part of the job and I think that it might be worth looking at a course in client management or something. The reason it's so hard is that when I'm in a meeting my primary goal is to please the client. When I'm coding, it's to build an application quickly and without bugs. That means that I think of something and when I come to discuss it my view has been changed subtly by the desire to please my client.

It occurred to me last night, as I was debugging some particularly tangly Javascript and Java running in several frames, that programming a complex web application that uses frames is essentially developing a multi-threaded application. You have the synchronisation issues that you get with multiple threads, albeit on a lesser scale as you usually have many more threads than frames.

On top of that, because the round-trip time to the server is so much higher than access times for threads running locally, you just can't use a lot of the typical techniques for solving sync problems. Also, as the frames are meant to act as a coherent whole, you have to ensure that they dance together properly. They can communicate with each other and they can communicate with the server, but only in the most basic ways.

Sometimes, this makes things hard.

Very bad customisation. I wanted the page to look like part of my application, WorldPay wanted me to use their design service! I'm pretty good at HTML, but they gave me no tools to perform the required alterations. The result is ugly. Plus their documentation is out of date, so it didn't tell me that their advanced Java product wasn't supported on Tomcat. Grrr. Their support is pretty good though, but it's nothing to write home about.

When I create an application, consistency is vital. In future I will recommend to my clients that they go the full nine yards and get SSL hosting or a cert for their server and collect CC details themselves. I know some consider this a mugs game, but I wouldn't store those details. I would transmit them (via SSL again, of course) to the payment provider from my backend rather than with the client's frontend. I wrote something similar once, there was no payment provider however, and sending the details on involved GPG them and emailing them. I was careful to make sure nothing leaked out on to the server. As long as nothing unencrypted goes to disk or stays in RAM too long, I'm happy.

I've never been one for debuggers, I'm too lazy really and because I've been a web application developer all these years, debuggers aren't really very often found. I'm much happier just slapping a print statement or two into the code. But I may have found a way to use a debugger that suits my (primitive) working style.

First of all, it's worth showing just how easy it is to get started with my debugger, pdb. Add these lines to any stretch of Python.

import pdb
pdb.set_trace()

When the interpreter runs into pdb.set_trace(), it'll drop into the pdb prompt and you can start inspecting the innards of your code. See the pdb command documentation for everything you can do.

Use test cases to debug web apps

A simple trick for making use of the debugger in a web application is to use a test case as the container instead of the web server. In Django's testing framework for example, tests are run inside the standard Python unittest module which works happily with pdb.

You can also set IPython to invoke pdb whenever an exception is raised and not caught. Allowing you to debug as you play with your code in a interactive Python session.

next page →

Choose another page: 2, 3, 4, 5, 6, 7.

Last updated at 0:35, Monday December 1st, 2008. All times are shown in 24-hour clock format and are GMT.

Rate my journal on bloghop.com: