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


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 <trev@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/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)