Re: Many Thanks

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

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)