Dustin Getz on 13 Mar 2012 08:41:45 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: Many Thanks |
Hi all,
Here is a list of links I compiled throughout the talk. There was a
lot I didn't know, and I thought a list of links could help other grok
Paul's talk as well. I how they help:
Here are some links to tools that he talked about:
Clojure and Scala: A mailing list post by the main developer on World
Singles and why they chose Clojure over Scala
(http://groups.google.com/group/clojure/browse_thread/thread/b18f9006c068f0a0?pli=1)
Hiccup: HTML Rendering in Clojure (https://github.com/weavejester/hiccup)
Chris Granger: Inventor of fetch, noir, and jayq. Tools to manipulate
the DOM in Clojure
(http://www.chris-granger.com/2012/02/20/overtone-and-clojurescript/)
Bootstrap: Twitters HTML/CSS/JS templates (http://twitter.github.com/bootstrap/)
David Nolen: Writer of "The Joy of Clojure"
(http://blog.fogus.me/2010/07/19/take-7-david-nolen/)
Uniplate: A Haskell framework for general traversals
(http://community.haskell.org/~ndm/uniplate/)
Scrap your boilerplate: A series of MS Research papers on generic
programming that Uniplate is based off of
(http://research.microsoft.com/en-us/um/people/simonpj/papers/hmap/)
core.logic: A logic programming library for Clojure
(https://github.com/clojure/core.logic)
RabbitMQ: Everyones favorite message queue (http://www.rabbitmq.com/)
(unless you are a 0MQ guy (http://www.zeromq.org/))
Uniti Testing in Clojure: 'nuff said
(http://nakkaya.com/2009/11/18/unit-testing-in-clojure/)
ClojureScript: Clojure for the browser (compiled to _javascript_
https://github.com/clojure/clojurescript)
enlive: CSS templating and transformations in Clojure
(https://github.com/cgrand/enlive)
enfocus: DOM manipulation in ClojureScript (enlive in ClojureScript
https://github.com/ckirkendall/enfocus)
How To Solve It: A great book on systematic problem solving
(http://en.wikipedia.org/wiki/How_to_Solve_It)
Try Haskell: in the browser! (http://tryhaskell.org/)
Scala levels: The levels of a Scala programmer
(http://www.scala-lang.org/node/8610)
The Art of the Metaobject Protocol: A book explaining metaobject
protocols used in lisps
(http://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Protocol)
Software Transitional Memory: What makes Clojure's (and Haskell's)
concurrency model work so well
(http://en.wikipedia.org/wiki/Software_transactional_memory)
Learn Clojure: Tutorails and videos for learning clojure
(http://learn-clojure.com/)
Yours,
Trevor
--
On Tue, Mar 13, 2012 at 8:08 AM, Paul <paul.degrandis@gmail.com> wrote:
> 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
Trevor Lalish-Menagh
trev@trevmex.com
484.868.6150 (mobile)
trevmex (AIM)