jQuery Progress Wheel indicator

This progress wheel indicator only takes a few lines of code to get up and running and provides a great way to communicate completion to your users! Works in modern browsers supporting the canvas element, and defaults back to a clear text counter in older browsers.this control supports the following features: Easy to initiate and control values; Configurable scrolling speed; Callback function for when the control reaches 100% can be specified; Easy to control appearance, including: Solid colours, radial gradients, and images, and transparency (why not make the indicator an irregular shape, lik…

jQuery Progress Wheel indicator

CANVAS vs. SVG vs. Flash

These are three tools you can use to add animation and interactivity to your websites. There are benefits and drawbacks to all of them. Find out the differences between these three technologies and why you might choose one over another.

Read the full article: How is the CANVAS Element Different from SVG and Flash

Using CANVAS, SVG, and Flash

Image © 2012 J Kyrnin – licensed to about.com

CANVAS vs. SVG vs. Flash

Poll: Have you ever used Flash, SVG, or CANVAS for animation or interactive graphics?

One of the things I like about HTML5 is all the new options we are getting for our websites. Some of them (SVG) are not really all that new, but they are finally coming into their own as Internet Explorer joins other modern browsers in supporting them.

SVG, as we learned from Darla last year, is an XML language that allows you to put vector graphics right in your web page. And HTML5 supports using the element right inside your HTML, without any extra tags or hoops to jump through. this makes SVG as easy as CANVAS to implement.

The CANVAS element is an HTML5 element that allows you to put scriptable graphics on your web pages, again without any extra hoops or tags. CANVAS is written with JavaScript, and while there are not many commercial programs that output to CANVAS yet, that is coming quickly, and I expect that we’ll see more of them in the coming years.

And of course, Flash, is still available to create your interactive graphics and animations. It doesn’t run or isnn’t supported on most modern smartphones or tablets, but if you don’t need to support those devices, then it’s still a good choice with lots of help and programs out there.

In fact, Flash is so common, that I’m betting that many more people will have used Flash than the other two choices in the above poll, so this week, I’m adding a second, follow up poll to the mix. if you have used Flash in the past (or even if you haven’t) are you considering changing to SVG or CANVAS? please post your reasons why (or why not) in the comments.

Poll: Have you ever used Flash, SVG, or CANVAS for animation or interactive graphics?

Creating A Web Page Calculator Using The HTML5 Output Element

HTML5 includes a host of new input elements, such as the output tag. Using the output tag in conjunction with the “oninput” event listener, you can create simple or complex Web page calculators, giving the user instant results. The output tag allows you to build forms using semantic markup, since the element is specifically designed for displaying calculation results.

dzone.com: latest front page

TeeChart for Javascrip

TeeChart for Javascript is written in 100% Javascript and is designed for use across multiple different browser types supporting the HTML5 Canvas. It uses the HTML5 Canvas element to render chart contents. TeeChart for Javascript is available as a standalone product and as an export format across the TeeChart product range. both formats enable HTML5 live in-browser charts as a visualisation format for a selected range of TeeChart data series types. Other series types, not supported in the dynamic model, may be output to browsers as static HTML5 charts. TeeChart for Javascript Live charts suppo…

TeeChart for Javascrip

10 Things ASP.NET Developers Should Know About Web.config Inheritance and Overrides

The ASP.NET configuration system is build around the idea of inheritance:

Each Web.config file applies configuration settings to the directory that it is in and to all of the child directories below it. Settings in child directories can optionally override or modify settings that are specified in parent directories. Configuration settings in a Web.config file can optionally be applied to individual files or subdirectories by specifying a path in a location element.

The root of the ASP.NET configuration hierarchy is the systemrootMicrosoft.NETFrameworkversionNumberCONFIGWeb.config file, which includes settings that apply to all ASP.NET applications that run a specific version of the .NET Framework. Because each ASP.NET application inherits default configuration settings from the root Web.config file, you need to create Web.config files only for settings that override the default settings.

For a lot of sites, you don’t really need to know about that – you can get by with one Web.config file for the site. but, knowing how the inheritance works – and how to control it – can really help out.

I’ve noticed that a lot of the questions I answer questions on forums, StackOverflow, and internal e-mail lists can be solved by better understanding how ASP.NET configuration inheritance and overrides work. and so, a bunch of tips about how ASP.NET configuration inheritance and overrides work! I’ll start with some basics, but there are some towards the end I’ll bet most ASP.NET developers don’t know.

Tip 1: Using Web.config files in site subfolders

And ASP.NET website’s Web.config is part of an inheritance chain. Your website’s subfolders can have Web.config – an example is the Web.config file in an ASP.NET MVC application’s View folder which does things like preventing directly viewing the View templates:

This allows for setting general settings at the site level and overriding them when necessary. any settings in the base Web.config that aren’t overridden in the subfolder stay in effect, so the "child" Web.config can be pretty small. You can continue to nest them, so sub-sub-subfolders can get their own Web.config if needed. Some of the most common uses of subfolders are to restrict permission (e.g. requiring authentication or restricting access to resources), but you can also use them to do things like include default namespaces in Views, toggle handlers, etc.

Tip 2: Understand how your site Web.config inherits its settings

But there’s an inheritance chain above the site, too. Here’s a simplified version from the MSDN docs:

The Machine.config file contains the ASP.NET schema for all of the Web applications on the server. this file is at the top of the configuration merge hierarchy.


ApplicationHost.config is the root file of the IIS 7.0 configuration system. it includes definitions of all sites, applications, virtual directories, and application pools, as well as global defaults for the Web server settings. it is in the following location:


The Web.config file for the server is stored in the same directory as the Machine.config file and contains default values for most of the system.web configuration sections. at run time, this file is merged second from the top in the configuration hierarchy.

The Web.config file for a specific Web site contains settings that apply to the Web site and inherit downward through all of the ASP.NET applications and subdirectories of the site.

ASP.NET application root directory

The Web.config file for a specific ASP.NET application is located in the root directory of the application and contains settings that apply to the Web application and inherit downward through all of the subdirectories in its branch.

ASP.NET application subdirectory

The Web.config file for an application subdirectory contains settings that apply to this subdirectory and inherit downward through all of the subdirectories in its branch.

So your website’s configuration’s actually inherited a bunch of settings that were set at the server level. That’s nice for a few reasons:

  1. It allows the ASP.NET / IIS teams to migrate settings that aren’t commonly modified from the project template Web.config files to server defaults, keeping your Web.config files smaller and more readable. for example, ASP.NET 4 migrated a bunch of handler registrations to Machine.config, so the Empty ASP.NET Application Web.config is slimmed down to about 8 lines.
  2. You can override things at the server level as needed, and they’ll take effect for all applications. for example, you can set <deployment retail="true"> on production servers to disable trace output and debug capabilities.
  3. You can find a lot of useful information in the Machine.config default settings since they’re stored in plain text. for example, the ASP.NET Membership Provider has some defaults set for password requirements and the membership database, and you can look them up by looking in the appropriate .NET framework version’s Machine.config. for a default installation of ASP.NET 4, that’s found in C:WindowsMicrosoft.NETFramework64v4.0.30319Configmachine.config with a quick search for <membership>.

Tip 3: Understand how your Web.config inherits IIS configuration settings

This overlaps a bit of Tip 2, but it bears repeating. Long-time ASP.NET developers (myself included) are prone to thinking of ASP.NET and IIS configuration separately, but that all changed with IIS 7. this is all pretty old news, as IIS 7 has been out for a while, but it hasn’t been completely absorbed by ASP.NET developers.

CarlosAg summed this up well in a post from 2006(!) which explained The new Configuration System in IIS 7.  I’m not going to rehash his post here – go read it. Some important takeaways are that both the ApplicationHost.config and Machine.config feed into the configuration settings in your site’s Web.config, as shown in Carlos’ diagram:

In addition to the understanding how things work part of it, this is also good to know because – based on the info in Tip 2 – you can see what the base settings are, and how you can override them in your application’s Web.config. this is why you can do pretty advanced things like configure rules on for the URL Rewrite Module in your application’s web.config.

Of course, server administrators don’t necessarily want to allow any application on the server to modify settings via Web.config, so there are configurable policies in the ApplicationHost.config which state whether individual applications can override settings. There’s also an Administration.config file which controls things like Module registration.

There’s one kind of new update to this list – using aspnet.config for Application Pool tuning. It’s found in the same directory as Machine.config, and it’s been around since .NET 2.0. However, as of ASP.NET 4 it’s been expanded to handle things like concurrency and threading, as explained in Scott Forsyth’s post, Setting an aspnet.config File per Application Pool. While not something most ASP.NET developers will need to use, it’s good to know that you can control things like maxConcurrentRequestsPerCPU, maxConcurrentThreadsPerCPU and requestQueueLimit at the application pool level.

Tip 4: Location, location

While it’s nice to be able to override settings in a subfolder using nested Web.config files, that can become hard to manage. In a large application, it can be difficult to manage settings because you can’t see the effective permissions in one place. another option is to use the <location> element to target settings to a specific location. for example, I previously showed how to use this to allow large file uploads to a specific directory in an ASP.NET application using the location element:

<location path="Upload"> <system.web> <httpRuntime executionTimeout="110" maxRequestLength="20000" /> </system.web></location>Tip 5: Clearing parent settings when adding to a collection

Sometimes you want to remove all inherited settings and start fresh. a common place you’ll see this is in handler, module, connection string and provider registration – places where configuration is used to populate a collection. Scott Guthrie blogged about an example in which just adding a new Membership Provider causes problems, because you end up with two providers – the default, and the one you just added. It’s important to clear the collection before adding your new provider using the <clear/> element, like this:

<membership> <providers> <clear/> <add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="MyDatabase" enablePasswordRetrieval="false" (additional elements removed for brevity) /> </providers></membership>

As Scott explains, failure to <clear/> the collection first results in both providers attempting to handle membership, which probably isn’t what you intended.

Tip 6: Locking settings with with allowOverride and inheritInChildApplications

You may need to prevent sub-applications from overriding or extending settings. You can do that with the allowOverride attribute, which does exactly what the name suggests – the same way a sealed class prevents changes via a derived class. The MSDN documentation summarizes this well:

You can lock configuration settings in ASP.NET configuration files (Web.config files) by adding an allowOverride attribute to a location element and setting the allowOverride attribute to false. Then within the location element, you can define the configuration section that you want to lock. ASP.NET will throw an exception if another configuration file attempts to override any configuration section that is defined within this locked location element.

Using a location element with an allowOverride=false attribute locks the entire configuration section. You can also lock individual configuration elements and attributes using lockItem, lockElements, lockAttributes, lockAllAttributesExcept, and lockAllElementsExcept.

That last part there – using attributes on sections – works because those lock attributes are among the general attributes inherited by section elements.

Tip 7: Disinheriting your child applications with inheritInChildApplications="false"

If you’ve got settings that should only apply to the parent application and shouldn’t be inherited, you can use the inheritInChildApplications attribute on any section or location element. That makes the settings at the current level, but inheriting applications and subfolders don’t have to bother with clearing and rebuilding configuration just to remove those settings.

This came up in a recent question on StackOverflow:  Unloading parts of a web.config file from a child application

Since Web.config is so heavily built on the concept of inheritance, it’s not surprising that turning it off for a section can have some side effects. The aptly self-named "run Things Proper Harry," a.k.a. rtpHarry, has written up two good posts covering usage and important things to be aware of.

Tip 8: use configSource to separate configuration into separate files

While I’ve been discussing modification of Web.config settngs through inheritance, it only makes sense to mentions some useful ways to handle overriding Web.config settings.

Any Web.config section can be moved to a separate file by setting the configSource attribute to a file reference. I’ve mostly used this for handling connection strings, since it allows you a lot more flexibility over versioning and and deployment. instead of having different Web.config files for each environment ("Oops! Just deployed the staging Web.config to production!!!"). it looks like this:

<configuration> <connectionStrings configSource="connectionStrings.config" /> …

Then your connectionStrings.config file only needs to change between environments, and can contain specific settings. it holds the contents of the element you’re referring to, so it looks like this:

<connectionStrings> <add name="subtextData" connectionString="Server=.;Database=staging;Trusted_Connection=True;" /></connectionStrings>

Another way I’ve seen this done is to have differently named connection strings config files for each environment (e.g. dev.config, staging.config, production.config). That allows you to check them all in to source control and not worry about getting files with the same name but different contents mixed up, but the tradeoff is that your Web.config in each environment needs to be updated to point to the right config source.

So, this is a handy trick, but isn’t quite perfect. a better option is to use Web.config File Transformations.

Tip 9: use Web.config Transforms to handle environmental differences

I don’t hear as much about Web.config Transforms as I’d expect. Maybe they just work and everyone just quietly uses them and doesn’t talk about it. but from the questions I see coming up over and over again, I’m not sure that’s the case.

I love Web.config Transforms. at my first ASP.NET MVP summit, I was part of a feedback group discussing frustrations with deploying ASP.NET applications. Two themes that came up over and over were difficulties with packaging and managing configuration. That team later produced Web Deployment Packages (a nice format that packages files and settings for a site in a way that can be inspected and modified during installation) and Web.config Transforms.

All the new ASP.NET projects have Web.config transforms already set up – if you expand the Web.config node, you’ll see that it’s configured to create different settings for Debug and Release mode.

It’s really easy to use – your main Web.config has the base settings for your site, and whenever you build, the transforms for the appropriate build configuration (e.g. Debug or Release) are automatically applied. If you had a Test database that you wanted to use by default, but wanted your Release builds to run against the Production database, you could set it up so that your base Web.config connection string points to the Test Database connection string, like this:

<connectionStrings> <add name="ApplicationServices" connectionString="[TestDatabase]" /></connectionStrings>

Then your Web.Release.config overwrites that to point at the Production database, like this:

<?xml version="1.0"?><configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> <connectionStrings> <add name="ApplicationServices" connectionString="[ProductionDatabase]" xdt:Transform="Replace" xdt:Locator="Match(name)"/> </connectionStrings></configuration>

The syntax is pretty straightforward, but you don’t need to worry about that because the comments in the Web.Release.config file already show how to do that.

To be clear: unlike the other examples, this is something that happens at build time, not runtime.

I recently ran into an issue where I wanted to deploy something to AppHarbor and wanted to switch between a local SQL Compact database and the hosted database server, and Web.config Transforms worked just great there.

There’s a lot more to talk about with Web.config Transforms that’s beyond the scope here, such as:

  • You can create as many build configurations as you want, with different transforms for each configuration. this makes it simple to switch between different settings in your development environment – say, switching between several development databases or other application settings.
  • You can use the configuration transformation system with any XML file using the SlowCheetah Visual Studio extension. Scott Hanselman’s written a post with more information on that here: SlowCheetah – Web.config Transformation Syntax now generalized for any XML configuration file
  • Sayed (the Microsoft developer who’s worked on both Web.config Transforms and the SlowCheetah extension) has also built a Package Once Publish Anywhere NuGet package which allows you to defer running the transforms until later, using a PowerShell command. That means you can build one Web Deployment Package with all the transforms included, and run them when you’re going to deploy to a specific environment.

There’s some good information on MSDN about Web.config Transforms:

Tip 10: Managing Application Restarts on Configuration Changes

There are a lot of moving parts in figuring out the configuration for a website, as illustrated above. for that reason, ASP.NET computes the effective settings for the site and caches them. it only recomputes them (and restarts the application) when a file in the sites configuration hierarchy is modified. You can control that on a section by section level using the restartOnExternalChanges property.

One place where configuration changes don’t automatically get recomputed is for external config files set using configSource (as shown in Tip 8). You can control that by setting restartOExternalChanges="true" for that section. There’s an example on MSDN that shows this in more detail by creating an external configuration file which is loaded via the configuration API (not referenced via configSource), then toggling the restartOnExternalChanges property and showing the differences in operation.


The ASP.NET Configuration system does quite a bit – I didn’t even mention big topics like using the API for reading and writing values to both local and external config files or creating custom configuration sections. this post focuses on one aspect: getting things done by understanding and leveraging inheritance and overrides. hopefully this gives you both some new tools for effectively handling configuration and some background that helps in troubleshooting when configuration is working as you’d like.

Are there any essential tips that I missed?

10 Things ASP.NET Developers Should Know About Web.config Inheritance and Overrides

Get Started with HTML5

HTML5 is no more difficult to write than HTML 4. This article explains how to create an HTML5 document using sectioning elements and tools to help older versions of IE display them correctly.

Read the full article: Build your First HTML5 Document

HTML5 Tutorials and Tag Information

Get Started with HTML5

Working around a Powershell Call Depth Disaster With Trampolines

I just posted about an update to my NuGet package downloader script which included a few fixes, including a fix to handle paging. that sounds boring, but wait until you hear about the trampolines.

Recursion: Seemed like a good idea at the time

The whole idea of this script is to download package files referenced in the public NuGet package feed. The NuGet package is in OData format, and it’s paged. That’s a good thing – requesting the feed shouldn’t make you wait while up to 16,000 (and growing) package descriptions are downloaded, and it shouldn’t tie up the server with that either. each page currently returns 100 items, but that’s a service implementation detail that could change at any time.

Paging in OData is done using a <link rel="next" href="http://url.com?$skiptoken=sometoken> element at the end of each page, like this:

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?><feed xml:base="http://packages.nuget.org/v1/FeedService.svc/" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns="http://www.w3.org/2005/Atom"> <title type="text">Packages</title> <id>http://packages.nuget.org/v1/FeedService.svc/Packages</id> <updated>2011-12-08T23:46:46Z</updated> <link rel="self" title="Packages" href="Packages" /> <entry> <id>http://packages.nuget.org/v1/FeedService.svc/Packages(Id=’adjunct-Some.Package’,Version=’′)</id> <title type="text">some.Package</title> <summary type="text">First!!!! w00t!!!</summary> < more stuff here /> </entry> <entry> < … entry stuff for another package … /> </entry> < etc – 98 more entry elements /> <entry> <id>http://packages.nuget.org/v1/FeedService.svc/Packages(Id=’adjunct-Last.On.The.Page’,Version=’′)</id> <title type="text">last.On.The.Page</title> <summary type="text">last package on the first page</summary> < more stuff here /> </entry> <link rel="next" href="http://packages.nuget.org/v1/FeedService.svc/Packages?$skiptoken=’adjunct-Last.On.The.Page’,’’" /></feed>

The important bit is that the link element tells you how to request the next page of information. Here it’s a link to the same feed with a skip token indicating the last item we’ve seen. I’m simplifying this a bit – the feed also handles searching, ordering, etc., but I’m just focusing on the paging bit. if you make a big request, the server returns you a chunk of the results with a link to get the next chunk.

My original implementation was to do something like this:

function DownloadEntries { param ([string]$feedUrl) // Download all items on the page $nextUrl = href from last link on the page DownloadEntries $nextUrl}DownloadEntries $firstPage

Note: if you’re new to PowerShell, that’s the syntax for writing a function called DownloadEntries which takes a string parameter called feedUrl.

So DownloadEntries gets passed a URL, downloads all entries on that page, and calls itself with the URL to the next page in the list. This works just fine for a while, but the problem is that every page is adding another level to the recursive depth of the call graph, meaning we’ll run into trouble soon.

Recursion, Call Stacks, and Stack Overflows

Note: I know I’m going to get #wellactually‘d to death. I’m bracing for it. I’m not a Recursion Expert of Recursions, and if you are I’m sure I’ll hear about it in the comments. also, you’re a big, mean jerk. actually, I’m happy to learn more, so fire away. now with that out of the way…

The most common example of recursion in computer science is when a function calls itself. I first stumbled across it as a junior programmer, when I "re-invented" it to solve a tricky problem. I needed to generate a massive Word document report based on a complex object model, and eventually came up with a function that took a node object, wrote out that node’s report information, and called itself for each child node. It worked, and when my boss said, "Hey, nice use of recursion!" I hurried off to read what he was talking about.

Recursion can be really useful, but things can get out of hand. in stack-based languages, recursion requires maintaining the state for everything in the call stack. that means that the memory used by a function grows with the recursion call depth. Since memory is limited, it’s easy to write code that will exhaust your available memory, and you’ll get a dreaded stack overflow error. Wikipedia lists infinite recursion as the most common cause of stack overflows, but you don’t actually have to get all the way to infinity to run out of memory – a lot of recursion is enough.

PowerShell’s Call Depth Limit

Rather than wait for a stack overflow to happen – or even for a script to use up an obscene amount of memory – PowerShell caps the call depth at 100. that means that, even if there were no memory overhead to each call, the above function would fail at 100 pages. Doug Finke shows a very easy way to demonstrate this:

function simpleTest ($n){ if($n -ne 0) { $n; simpleTest ($n-1) }}PS C:> simpleTest 1010987654321PS C:> simpletest 999998979695The script failed due to call depth overflow. The call depth reached 101 and the maximum is 100.Side Note: PowerShell has the same call depth limit (100) on x64 and x86

Also from Doug’s post:

Recursion depth limit is fixed in version 1. Deep recursion was causing problems in 64bit mode because of the way exceptions were being processed. It was causing cascading out-of-memory errors. The net result was that we hard-limited the recursion depth on all platforms to help ensure that scripts would be portable to all platforms.
- Bruce Payette, co-designer of PowerShell

Tail-Recursive Calls and Trampolines

There are ways to work around this problem, but to me they all seem to boil down to replacing deep call stacks with loops – either automatically at the language level or via fancy pants programming. in my case, I needed to convert from recursion to trampoline style – albeit a very simple conversion. With the disclaimer that I’m not an expert here, I thought I’d overview what I read about trampolines, then simplify it down to the basic trampoline solution I ended up with.

Tail Call Optimization

In some cases, languages can optimize their way around this problem. One example is tail call optimization. a tail call is a call which is happening immediately prior to returning from the function, meaning that there’s no remaining logic in the calling function and thus no need to retain the stack. in a tail-recursive call, it’s returning that value to itself.

Languages can effectively unroll this, since in a tail call situation they don’t need to maintain the nested call stack as the calling function has completed all its logical operation. if you’re using one of those languages and make sure that your recursive calls are tail-recursive (so no additional logic is performed after the recursive call), the language will handle this for you and you’ll end up with the benefits of recursion without the baggage of building a big call stack.

Matthew Podwysocki runs through this in more detail with a comparison of how this works in F# and C# (with an interesting difference between 32 and 64 bit operation). He shows an example of a case where a single line of code after the recursive call breaks the tail call optimization, resulting in a stack overflow.

It’s interesting to note that the common language runtime supports tail calls, so it comes down to whether the language and compiler make use of it. PowerShell doesn’t support tail call optimization, so I needed to alter my code. That’s where I learned about trampolines.


The common pattern I read about for dealing with this is to manage state yourself using a trampoline: a piece of code that repeatedly calls functions. And, depending on the language and recursive requirements, that little "a piece of code that repeatedly calls functions" can get really pretty complex.

If my implementation was really making deep use of recursion in such a way that I really needed to emulate nested calls, that trampoline implementation would need to be pretty sophisticated. While that’s implemented differently in different languages, in modern .NET programming I’m reading that’s usually done using a function factory trampoline class which calls functions for you. Here are some posts showing how to do that:

In my simple case, though, I could just to convert the recursive call so that it’s called from a looping construct, returning state from each call. I’d call this option a strategic retreat, since this is now in no way recursive anymore. but, by calling it a refactoring to implement trampoline-style programming, I’ll still keep my pride.

So since the reason I was using recursion was just to continue calling the next page after completing the work on the current one, my trampoline can be implemented as a simple for loop into a function that returns the URL of the next page. Remembering that we started with something like this:

function DownloadEntries { param ([string]$feedUrl) // Download all items on the page $nextUrl = href from last link on the page DownloadEntries $nextUrl}DownloadEntries $firstPage

We can rewrite that as this:

function DownloadEntries { param ([string]$feedUrl) // Download all items on the page $nextUrl = href from last link on the page return $nextUrl}while($feedUrl -ne $null) { $feedUrl = DownloadEntries $feedUrl}

This can now handle unlimited pages, since it’s just a simple loop. The only downside is that I can no longer feel quite as sophisticated, since while I call that a trampoline, you’d probably call it a boring loop that calls into a function.

Here’s the full script so you can see it in context:

Working around a Powershell Call Depth Disaster With Trampolines