Many Thanks

[Paul <paul.degrandis@gmail.com>]

Many thanks to all that came out last night.  Thank you so much for
the attention, the feedback, and the great discussion.  You all
provided me with some insight on how to really hone in the focus of my
talk.

If anyone has questions specific to the slides, the discussion, or the
Tutorspree technology pieces, follow up in this thread.

I'm digging up the paper on user perceived system errors based on
response time.


I also wanted to fill in some details about baking that might help
better fill-out the business case:

One of my greatest risks is managing lots of physical computing
resources with a limited number of engineers.  Our time is better
spent serving our internal engineering needs, or the needs of
customers, not the inherent complexities of scaling and maintaining
web machines.

We have a risk that the pipeline from design concept to production
push is just too long.  We'd really like to use the objective data
from A/B tests in a tight loop, to push UI and Interaction changes a
lot faster.

Another risk is that our mobile traffic is growing faster than any
other segment.  The old architecture choice was mobile-dispatching,
but it means that we have to double up on some of the control logic
and also the designs.  Given the second risk, this becomes a small
hangup.

Our best source of traffic comes from organic search (a lot of long
tail stuff that we scoop up).  So we optimize a lot for that sort of
thing.
=====

The idea is simple:
A designer builds us static HTML.  They use a chopped up version of
Bootstrap2 and HTML5boilerplate that has all the responsive/fluid
stuff turned on (we've removed the mobile rendering concern to some
degree.  We also got semantic markup via microdata for free - great
for SEO).  We then put the page through a baking process where we're
doing div transforms with real data from our DB.
The pages that come out are RICH for SEO.  Our static content that we
place on the CDN is the bare-minimum for humans, and the best case
scenario for machines.

We additionally push snippets of JavaScript (some actual JS, but
mostly compiled ClojureScript) to the CDN.

This JS fulfills all the dynamic needs of Tutorspree, by doing simple
div transformations and swapping out the HTML when needed.

90% of all traffic and interaction is now being handled between the
CDN and the client.  So the scaling and system maintenance/
administration risks are greatly reduced.

What we gained is now engineers don't have to worry about taking a
design and turning it into a template, UI/UX changes can happen in a
tight loop, engineers get the benefit of interactive development at
all points of the application, we don't need to worry as much about
scaling our DB for connections, just for data and processing.

Hope this helps clear some confusion for some people,
Paul