background image
Home

Carl Sorenson

Resume

My current resume can be found here.

A bit about my work

In most of the jobs I have held, I have been known for quickly making a mark and being surprisingly productive. Here is one fun example:
Years ago I had a few months before I would begin college, so I got a job through a temp agency and was sent to Air BP (the jet fuel division of BP Amoco) to do some very mundane billing processing. On the morning of my first day, they trained me to perform bill cancellation and re-entry, a manual process I was to perform over and over all day long. Once I understood the process, I hesitantly told them I knew of a way to speed it up with some computer code to automate the process. They were receptive to my idea, and by the end of the day I was programming. I soon had four different computers running my scripts at once, processing orders five to ten times faster than I ever could manually, making my management and the temp agency quite happy. With my help, they were able to make a big dent in their accounts receivable backlog to the tune of tens of millions of dollars! When I finally left for college, the office threw me a party and gave me a replica airplane - making for quite a fond memory.
At Feld Entertainment, I was promoted to Web Architect. At my performance review several months later, I was told, "We had high expectations for you as Web Architect, and you have exceeded them." My managers have said in my reviews things such as:
  • Carl is clearly the most technically competent member of the Event Systems group. He is the visionary for the technical direction of the Feld web team and its projects. His expertise and his ideas have been invaluable during the planning and execution of the data center move and public web site mitigation.
  • Carl is a consummate professional. He can [be] counted [on] to get things done - properly and on time.
  • Carl takes great pride in his position, his accomplishments, and the accomplishments of the web team – as well he should. I rely on his decisions and his judgment and he has not let me down. Rarely do I have to adjust his course.
Most recently, I have been at PowerChord, where I have been working with React/Redux, Node, and to an extent Go. I have enjoyed the opportunity to branch out, get familiar with Macs and shell scripts, and do some JavaScript. I am interested in doing more with Angular and .NET.

My role at Feld Entertainment

Until 2014, I was the Web Architect at Feld Entertainment, leading a small team in building, maintaining, and hosting the company's web sites, such as our Feld International sites, ringling.com, monsterjam.com, and many others. We also built line-of-business applications, windows services, etc. We hosted all of these on our own servers (as described below), but we were actively working to move web sites and services into the Azure cloud or other hosted solutions.

My team did HTML and client scripting, but focused a bit more on CMS integration and server-side code.

Some of what I did at Feld

In eight years of building tools and refining our environment, I set up quite a system for hosting and maintaining our web sites. I designed and built most of our setup and tools. Even before I became the Web Architect, I generally took the lead in this.

The main factor driving many of these investments on the Web Team was the sheer number of sites to manage. When I began at Feld, we had about five web sites (Feld Entertainment, Ringling, Intranet, Circus Fit, and Elephant Center) and four developers. But for several years while we added web sites and expanded our responsibilities, we had only three developers. Depending on how you count them, we had one to three dozen web sites by the time I left. These varied among:
  • Content-heavy sites (Monster Jam)
  • Line-of-business applications (Feld Intranet, with many different data forms and unrelated sections)
  • A Silverlight-based distributed application with components in several offices (Media Files)
  • Simple HTML sites, sometimes even single pages
We also had many media guides and other web applications that were sub-applications in IIS, and which were independent projects in Visual Studio. By my count, we had:
  • 36 web sites set up in IIS
  • 12 production Ektron CMS sites (excluding test / demo sites)
  • 20 sub-applications
  • 5 mobile sites and 10 country-specific sites (mobile.ringling.com, www.feldentertainment.co.uk, etc.)
  • 5 significant console or class library projects (including our main library, Feld Enterprise Library, with dozens of classes)
  • 7 custom windows services
  • 800 domain names to manage, most of which redirected to canonical domain names via our tools
  • Several PowerShell scripts to perform file synchronization and backups
We could control the load balancing and Ektron syncs using web-based tools that I developed:
Load balancing tools screenshot
(The sync was an Ektron database sync with the file system portion replaced with our own solution based on Microsoft Web Deploy. A custom windows service monitored and managed all of this.)

Having things organized like this was the only way to manage so many web sites with such a small team.

Management and Visibility

All web sites automatically loaded a number of custom HTTP Modules from our enterprise library. Among the most important of these were modules that provide management tools and error logging to give us control of our sites and visibility into what was happening.

All web sites automatically had a virtual or hybrid virtual/physical admin page:
Admin page screenshot

All sites also logged exceptions to a database through a queue-based, fault-tolerant system: Error log viewer screenshot

Development and Deployment

We set up a wildcard DNS entry on our network so that, without using the hosts file, we could develop and debug our web sites locally using a custom TLD (for example, www.ringling.localhost). We did not precompile the web sites—deployment was simply a matter of copying the files to the servers using a custom Visual Studio package that I wrote, either via keyboard shortcut or context menu:
Deployment tool screenshot

All deployments were logged to an auditing database.

Among the many features of our enterprise library were mechanisms for caching (persistence):
Persistence screenshot

We also built a Common Data Store repository with an API, so that we could avoid making simple one-off databases:
Common data store screenshot

Each web site or application could have a walled-off space within the data store to keep track of its own data.

Content Delivery Network and Image Resizing

One of our HTTP modules provided on-the-fly image resizing via query string:
http://www.monsterjam.com/images/logos/PathofDestruction.png?maxw=150

This saved client bandwidth and ensure that images fit in the appropriate spaces. Rather than implement a caching mechanism for this ourselves, we referenced the images (or any assets) via Amazon CloudFront CDN:
http://monsterjam.feldcdn.com/images/logos/PathofDestruction.png?maxw=150

Once the CDN was set up for a site and image references were set to use the CDN, it was essentially zero-maintenance. The site can be set to switch between CDN and direct mode via a config setting.
CDN screenshot 1

CDN screenshot 2

The CDN enabled us to offload a large majority of our network traffic and free up server resources at a minor expense.