In my previous blog I explained how to get the httpContext to survive an asynchronous callback by using the aspnet:UseTaskFriendlySynchronizationContext application setting and I questioned why this wasn’t set by default. Well I’ve since discovered why that’s the case and it has some pretty significant consequences for Umbraco’s backend CMS.
Captcha was always a good idea on paper, but in practice it means annoying legitimate users.
Following on from my previous blog about thread exhaustion, I recently had to deal with a site experiencing thread exhaustion that happened to be an Umbraco site. This issue was nothing to do with Umbraco itself, it was synchronously calling a fairly slow webservice that was responsible. My solution? Async controllers
All applications require logging to some degree, whether that is simply logging to the standard output stream or asynchronously logging a fixed size rolling log file to disk using enterprise logging tools.
In the immortal words of Homer Simpson “People are afraid of new things. You should have taken an existing product and put a clock in it or something.” So this is my new blog post, with a clock in it.
Adaptive and responsive design have emerged from the desire to serve all the content of a single site from a single domain.
The problem I encountered recently was that I had a field wrapped in 15 pieces of design flare and really needed to add the error class to an element several levels up the DOM hierarchy.
When I am developing web sites, I like my development environment to match, as closely as possible, the actual live environment on the server that will host the finished site. For this reason I prefer to use IIS for development and testing, over the inbuilt development server included with Visual Studio.