Seth Yates

An article on MSDN published a quick roundup of ten tips for achieving high-performance in your ASP.NET web application:

1. Return multiple resultsets from your data access layer
2. Use paged data access to only return the data you need
3. Use Connection Pooling
4. Use the ASP.NET Cache API to cache frequently used, rarely changing information
5. Cache frequently used request-specific information for the duration of the request
6. Process as much in the background (offline, out of the request) as possible
7. Use Page Output Caching and Proxy Servers (mmmm…depends)
8. Run IIS 6.0
9. Use Gzip Compression
10. Reduce Server Control View State

This is a great list. We’re running 9/10 on this (we don’t cache page output because everything is dynamic), and the web servers are pretty much idling most of the time.

Related posts

• No related posts.

CNET reports that Microsoft is “developing a free online service that will allow people to list items for sale, events and other classifieds type of information that can be shared either with select groups of friends or anyone over the Internet”.

Okay, so now everybody wants to play. Google recently launched Google Base, which is its version of classifieds advertising system. Craigslist has been running all over the US drying up the local newspaper’s “rivers of gold” from classifieds advertising, although their foray into Australia has been very weak. Fairfax’s cracker.com.au has seemed to be more successful, with over a half million unique visitors per month and hundreds of thousands of postings in the main metro areas.

The classifieds market (jobs, cars, houses) is finally tipping (in Australia). With such a transformational shift happening, plenty of players are rushing in to try and cut out a bit of the market for themselves.

The next 5-10 years are going to be interesting indeed.

Related posts

• No related posts.

As reported in Business Week, Amazon are testing several new features in beta form now:
1. tagging
2. wikis
3. community discussions

Really interested to see how they fare with this, as these are some really cool features that I would like to see in use in more sites. Amazon have always been sort of a quiet innovator in many ways, with their recommendation engine (other people who bought this book/dvd/cd/garden hoe also boought this book/dvd/cd/shovel), RESTful web services, and their huge collection of reviews (now that is a truly powerful barrier to entry).

Although I am often a skeptic of the latest technology being used in search of a problem, I think tagging, wikis and community discussions can be really powerful tools in the right applications (and I think Amazon clearly is the right application for many of these). Hopefully Amazon will be able to make the wikis last longer than The Los Angeles Times were able to.

Related posts

• No related posts.

This is important:

“Developers of four of the most widely used Internet browsers (ed. Microsoft Internet Explorer, Firefox, Opera and Konqueror) have agreed to make a number of changes to their products to make Web browsing a more secure and trustworthy experience.”

“The basic plan would be for all browsers to tint the address bar green when users visit major-brand sites with a “highly-assured” digital certificate. Suspicious sites that might be sources of phishing scams would be indicated by a red address bar. A padlock icon would be also be set in the address bar, where it’s more visible, when users are at an SSL-secured page.”

“Additionally, the plan would put an address bar in every browser window, even those popped up or under as forms, to defeat fraudsters’ camouflaging tricks.”

“Some browsers already include elements of the plan. Firefox and the open-source Konqueror, for example, put the padlock icon in the address bar, while the under-development Internet Explorer 7 uses the green/red combination in its integrated anti-phishing filter.”

Covered here on Yahoo! and here on InfoWorld.

I hope these guys can pull this off, but it is highly dependent on the parties being able to push forward these ideas consistently and on the certificate signing authorities coming up with a yet-unspecified rigorously checked “high assurance certificate”. It will also mean we’re given yet more power to the big CA’s like VeriSign.

Related posts

• No related posts.

Roedy Green has a great page on how to write unmaintainable code.

Related posts

• No related posts.

We released Restful.NET 1.0 library today. This library is a light-weight, open-source (GNU LPGL-licensed) framework for building and consuming REST web services from .NET.

The Restful.NET REST Web Service framewok can be downloaded from here..

Related posts

• No related posts.

So you have a (near-) 24×7 website running on multiple servers in a web farm and you need to upgrade the database. How do you upgrade the database without taking the site down or breaking things? Anybody who has run a 24×7 web-based business will know the challenges of upgrading the production system to support new features, all while keeping the site running smoothly and seamlessly. You can’t ensure that everything accessing the database is upgraded at the same instant.

Read more on this discussion and discover a simple solution.

SQL Server, web development, database

Related posts

• No related posts.

You have a (near-) 24×7 website running on multiple servers in a web farm and you need to upgrade the website. How do you upgrade the website without taking the site down or breaking things? How do you quickly and easily rollback if the upgrade doesn’t go so smoothly?

Read more on this discussion and discover a simple solution to deploying 24×7 web applications.

ASP.NET, web development

Related posts

• No related posts.

Quite often when developers are developing ASP.NET applications and they’ve added exception handling, they will have some code like the following:

try
{
...
Response.Redirect("/default.aspx", true);
}
catch (Exception exc)
{
... // proper exception handling.
}


Funny thing is, many developers don’t realise it, but Response.Redirect throws a ThreadAbortException, which gets caught by the catch filter.

What’s the right way to handle this? I can outline three ways, each of which may be applicable in a given scenario:

1. Simple. Move the Response.Redirect outside the try/catch statement. Problem solved. The catch filter will not receive the exception.
2. Follow some exception handling best practices and only catch the exception type you really know how to handle:
   
try
{
...
Response.Redirect("/default.aspx", true);
}
catch (ArgumentOutOfRangeException exc)
{
... // proper exception handling.
}

3. Catch the ThreadAbortException and rethrow it:
   
try
{
...
Response.Redirect("/default.aspx", true);
}
catch (ThreadAbortException)
{
throw;
}
catch (Exception exc)
{
… // proper exception handling.
}


Hope that’s answered “why am I getting a ThreadAbortException?” and given you some ideas of how to work around it.

ASP.NET, web development, exception management

Related posts

• No related posts.

I really love code reviews where I tell developers that they need to better plan for and handle exceptions, and in the followup code review, they present the following:

try
{
// do some dangerous stuff that may throw an exception.
}
catch (Exception e)
{
throw (e);
}


My usual reaction is to grit my teeth, administer an icy stare and ask a calm, measured question: “And what exactly, are you aiming to accomplish here? (besides, of course, losing your stack trace and the real source of the exception)”.

The problems I have with this “pattern” are many:

1. You lose your stack trace when you call throw(e);. The stack trace now points directly to this line, so you no longer know the real culprit.
2. There’s no real “handling” going on here, now is there? What’s the code saying when you read it? “Hey! I can handle ‘Exception’. Oops, no I can’t, gonna have to throw this one on up the chain.”.
3. Almost always, too generic of an exception is being caught. Come on, tell me that you know how to handle an OutOfMemoryException (or any other exception that derives from the Exception class…that’s almost* every exception) in this case. Really?

When I’ve finished with the code review, the above code is usually refactored into one of two forms:

1. // do some dangerous stuff that may throw an exception.

   This is most often my favourite refactoring. It accomplishes the same effect as the above code…passing the buck.
2. try
{
// do some dangerous stuff that may throw an exception.
}
catch (InvalidOperationException e)
{
throw MyFacadeException("There was a problem doing the dangerous thing.", e);
}

   This is the form of the refactor I prefer if there is truly a need to handle the exception and do something with it (in this case throwing a new exception, wrapping the thrown exception).

There are plenty of exception management best practices, but I typically use the following simple rules:

1. Avoid an exception if you can (e.g., check for a zero denominator instead of just dividing by zero; check if a file exists rather than just trying to open it).
2. If you can’t avoid an exception, catch the most specific exception you can (e.g., catch (ArgumentOutOfRangeException) instead of catch (Exception)…) and never, ever catch without a filter.
3. Only catch the exception if you know what to do with it. If you don’t know what to do with an exception, don’t catch it.
4. If you’re going to rethrow an exception, do it properly so the stack trace is maintained: throw; instead of throw(e);.
5. Valid things to do in a catch are:
   • Do nothing. Swallow the exception if you expect it to happen, and rely on the fact that things weren’t done in the try clause to signal the exceptional case.
   • Set some flags, or reset some local variables. Let these be the signal to the exceptional case.
   • Throw a new exception, wrapping it around the thrown exception and providing either a facade exception type or providing better exception information (e.g., the message may be more specific about what was intended rather than the actual nuts-and-bolts error as in “Could not create the lock file required for exclusive write access” would be better than “Access denied”).
   • Rethrow the thrown exception (using throw;, not throw (e);). This is useful if you need to handle some more generic exceptions, but you want to bubble some more specific exceptions.
   • Log a message and return (if you must). Least preferred, as it may be hiding some exceptions from you.

* Some obscure runtime exceptions actually don’t inherit from Exception, and these get caught in the following code:

try
{
...
}
catch
{
...
}


exceptions, code reviews, quality, wtf

Related posts

• No related posts.