Re: Many Thanks

[Michael <michael.bevilacqualinn@gmail.com>]

Just adding my thanks here.  Sorry I missed the talk.  The airlines were not cooperating.  

Hope to see you all soon!

Thanks,
MBL

Sent from my iPhone

On Mar 13, 2012, at 1:50 PM, Paul <paul.degrandis@gmail.com> wrote:

> Wow, thanks SO much Trevor, that's an awesome list!
> 
> On the topic of blogs, mine is focused more on architecture and is at
> http://www.pauldee.org/blog
> 
> My viewpoint on software engineering (and problem solving in general)
> is:
> http://www.pauldee.org/blog/2011/the-heart-of-all-engineering/
> 
> Which I think we discussed a lot last night ("How I solve problems")
> 
> Paul
> 
> On Mar 13, 11:40 am, Dustin Getz <dustin.g...@gmail.com> wrote:
>> bam! thanks for this trevor you just saved me some work.
>> 
>> Joy of Clojure ("the book" to learn idiomatic clojure) is written by Fogus
>> and Houser. Fogus's expertise is in big enterprise systems. David Nolen is
>> the hipster research dude with an awesome 'fro who is the main guy behind
>> clojure/core.logic. Both of their blogs survived The Great Google Reader
>> Culling of 2012, they have consistently good and regular content.
>> 
>> i have detailed notes on Paul's slides, but they need processing and won't
>> be up until late tonight at earliest.
>> 
>> [1] Fogus:http://blog.fogus.me/-
>> [2] Nolen:http://dosync.posterous.com/
>> 
>> On Tue, Mar 13, 2012 at 10:52 AM, Lalish-Menagh, Trevor <t...@trevmex.com>wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> 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/b18f9006c...
>>> )
>>> 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.degran...@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
>>> t...@trevmex.com
>>> 484.868.6150 (mobile)
>>> trevmex (AIM)