index.html | searchcode

/www/index.html

https://github.com/corleroux/frontend-dev-baseline
HTML | 938 lines | 678 code | 241 blank | 19 comment | 0 complexity | e54ede932e67012ed067a60611953dc0 MD5 | raw file

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">

    <title>The New Baseline for Front-End Developers</title>

    <meta name="description" content="">
    <meta name="author" content="Rebecca Murphey">

    <meta name="apple-mobile-web-app-capable" content="yes" />
    <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />

    <link href='http://fonts.googleapis.com/css?family=Signika:400,600,700,300' rel='stylesheet' type='text/css'>

    <link rel="stylesheet" href="css/reset.css">
    <link rel="stylesheet" href="lib/reveal/reveal.css">
    <link rel="stylesheet" href="css/print.css" type="text/css" media="print">

    <link rel="stylesheet" href="lib/highlight/styles/solarized_light.css">
    <link rel="stylesheet" href="css/rm.css">

    <!-- fwiw: i'm not in love with client-side prefix fixing,
    but i'm doing it here for the sake of worrying about other things.
    thanks to lea verou for making this available. -->
    <script src="js/prefixfree.js"></script>
  </head>

  <body>

    <div id="reveal" class="reveal">

      <!-- Used to fade in a background when a specific slide state is reached -->
      <div class="state-background"></div>

      <!-- Any section element inside of this container is displayed as a slide -->
      <div class="slides">
        <!-- intro -->
        <section>
          <section data-markdown class="title-slide">
            <img src="img/line-in-the-sand.jpg" alt="" width="500">

            # A New Baseline <br/>for Front-End Developers

            Rebecca Murphey&nbsp;&nbsp;☆&nbsp;&nbsp;TXJS&nbsp;&nbsp;☆&nbsp;&nbsp;June 2012
          </section>

          <section class="centered oneliner" data-markdown>
            <p><img src="img/bocoup.png" class="clean" alt="Bocoup" height="300"></p>

            [@rmurphey](http://twitter.com/rmurphey)&nbsp;&nbsp;☆&nbsp;&nbsp;[rmurphey.com](http://rmurphey.com)&nbsp;&nbsp;☆&nbsp;&nbsp;[bocoup.com](http://bocoup.com)
          </section>

          <section class="centered" data-markdown>
            <iframe src="http://rmurphey.com/blog/2012/04/12/a-baseline-for-front-end-developers/" width="960" height="700"></iframe>

            <aside class="notes">
              want to talk about a post i wrote a while back about a “new baseline for front-end devs”

              about how the demands on front-end devs have changed over the years.

              this post inspired an odd amount of controversy

              but i think in a year or two, people who don’t know these things won’t be able to keep calling themselves FEDs
            </aside>
          </section>

          <section class="centered" data-markdown>
            <img src="img/lynx.png" class="clean" alt="Lynx" width="800">

            <aside class="notes">
              my career doing web development -- before it was interrupted for a few years so i could work at newspapers -- began when the web looked like this ...

              we used simple tools then -- basically, a text editor
            </aside>
          </section>

          <section class="centered" data-markdown>
            <img src="img/yahoo.png" class="clean" alt="Yahoo!" width="600">
            <aside class="notes">
              soon, the web had advanced to look like this ...
            </aside>
          </section>

          <section data-markdown>
            <iframe style="background-color: white" src="http://www.andybudd.com/archives/2004/05/an_objective_look_at_table_based_vs_css_based_design/" width="960" height="600"></iframe>

            [An Objective Look at Table-Based vs CSS-Based Design](http://www.andybudd.com/archives/2004/05/an_objective_look_at_table_based_vs_css_based_design/)

            <aside class="notes">
              and within a few years, we were fighting over exciting things like tables for layout.

              these disagreements were a sign that front-end dev was going to be a serious pursuit ...
            </aside>
          </section>

          <section class="centered" data-markdown>
            <img src="img/gmail.png" class="clean" alt="Google Gmail" width="600" style="display: block; position: absolute; top: 0; left: 0; z-index: 1">
            <img src="img/gmaps.png" class="clean" alt="Google Maps" width="500" style="display: block; position: absolute; top: 150px; left: 400px; z-index: 1">

            <aside class="notes">
              around the same time, 2004, tools like gmail and google maps started to make clear that JavaScript was going to be a serious thing, too
            </aside>
          </section>

          <section class="centered">
            <iframe src="http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications" width="960" height="600"></iframe>

            <aside class="notes">
              In 2005, we got a name for these technologies that were letting us move more and more of our development energy to the browser.
            </aside>
          </section>

          <section class="centered" data-markdown>
            <img src="img/jquery.jpg" class="clean" alt="jQuery Logo" width="500" style="margin-top: 150px">

            <aside class="notes">
              in 2006, jquery came along

              it made the scary world of JS a whole lot less scary

              also a whole lot more accessible to people w/o traditional dev backgrounds
            </aside>
          </section>

          <section class="centered" data-markdown>
            <img src="img/etherpad.jpg" class="clean" alt="Etherpad" width="800">

            <aside class="notes">
              meanwhile, apps got even more complex, and less website-y
            </aside>
          </section>

          <section class="centered" data-markdown>
            <img src="img/facebook.png" class="clean" alt="Facebook" width="800">

            <aside class="notes">
              today, immersive web-based experiences exist in the browser, powered largely by “front-end” technologies
            </aside>
          </section>

          <section class="centered" data-markdown>
            <img src="img/yahoo.png" class="clean" alt="Yahoo!" width="600">

            <aside class="notes">
              if we think of the skills that we used to build stuff like this ...
            </aside>
          </section>

          <section class="centered oneliner" data-markdown>
            <img src="img/birdhouse.jpg" class="clean" alt="Birdhouse">

            <aside class="notes">
              as similar to the skills we’d use to build something like this ...
            </aside>
          </section>

          <section class="centered" data-markdown>
            <img src="img/facebook.png" class="clean" alt="Facebook" width="800">

            <aside class="notes">
              then the skills we’d use to build something like this ...
            </aside>
          </section>

          <section class="centered" data-markdown>
            <img src="img/skyscraper.jpg" class="clean" alt="Skyscraper" height="700">

            <aside class="notes">
              are akin to the skills we’d use to build this.
            </aside>
          </section>

          <section class="centered oneliner" data-markdown>
            Our emphasis shifts from <em>trivia</em> to <em>tools</em>
            as we are required to automate, streamline,
            and bullet-proof our processes.

            <aside class="notes">
              it’s (past) time for front end devs to become better versed in the practices of software dev.

              we’re building skyscrapers.

              this talk is less about teaching new things, and more about teaching you what to learn.

              if you already know all this, you should probably be getting paid more.

              if you don’t know all this, learn it, and you will get paid more.

            </aside>
          </section>

          <section class="centered" data-markdown>
            ![angry mob](img/angry_mob.png)

            <aside class="notes">
              disclaimer: these are the specific tools *i* like. you don’t need to use them.
            </aside>
          </section>

        </section>

        <!-- javascript -->
        <section>
          <section data-markdown>
            # javascript

            ## you already know

            jQuery, underscore, basic JavaScript

            ## you should know

            jQuery-less JavaScript, prototypal inheritance,
            closures & function scope, MV* basics
          </section>

          <section data-markdown>
            <p class="centered"><img src="img/js-assessment.png" width="800" class="clean"></p>
          </section>

          <section data-markdown>
            <pre>
              <code class="javascript">
it("you should be able to determine the location of an item in an array", function() {
  expect(answers.indexOf(a, 3)).to.be(2);
});

it("you should be able to add the values of an array", function() {
  expect(answers.sum(a)).to.be(10);
});

it("you should be able to remove an item from an array", function() {
  var result = answers.remove(a, 2);

  expect(result).to.have.length(3);
  expect(result.join(' ')).to.be('1 3 4');
});

it("you should be able to add an item to the end of an array", function() {
  var result = answers.append(a, 10);

  expect(result).to.have.length(5);
  expect(result[result.length - 1]).to.be(10);
});
              </code>
            </pre>
          </section>

          <section class="centered">
            <a href="http://eloquentjavascript.net"><img src="img/ejs.png" width="200" class="book book-1 clean"></a>
            <a href="http://shop.oreilly.com/product/9780596517748.do?sortby=bestSellers"><img src="img/javascript-the-good-parts.jpg" width="200" class="book book-2 clean"></a>
            <a href="http://shop.oreilly.com/product/9780596806767.do?sortby=publicationDate"><img src="img/javascript-patterns.jpg" width="200" class="book book-3 clean"></a>
            <a href="http://shop.oreilly.com/product/0636920025245.do?sortby=publicationDate"><img src="img/maintainable-javascript.jpg" width="200" class="book book-4 clean"></a>

            <aside class="notes" data-markdown>
              Left to right, these are short books very much worth reading. JS Patterns
              especially was transformative for me and helped me "level up" my JavaScript
              (and gave me names for patterns I didn't know had names).
            </aside>
          </section>
        </section>

        <!-- git & github -->
        <section>
          <section data-markdown>
            # git & github

            ## you already know

            creating a new repo, cloning a repo, branching and merging locally

            ## you should know

            collaboration workflow, pull requests, code reviews

            <aside class="notes">
              Most open-source projects of interest to front-end devs make their home
              on Github. 

              If you want to participate, if you want to understand how something came
              to be the way it is, if you want to contribute or just see the sausage
              being made, you need to know your way around.

              Of course, more internal projects are using Github too -- it turns out it's
              a great way to collaborate on software.
            </aside>
          </section>

          <section class="centered" data-markdown>
            <img src="img/git-workflow.png" height="600" alt="git workflow" class="clean">
            <aside class="notes">
              Understand the git branching model and understand how a particular project
              approaches branching.

              I remember the first time I saw this diagram and I was pretty puzzled, but
              learning to use development or "feature" branches is pretty key to getting the 
              most out of git -- and to contributing to open-source projects.
            </aside>
          </section>

          <section>
            <img src="img/tower.png" height="600" alt="Tower" class="clean">

            <aside class="notes">
              If you need training wheels, apps like Tower or Github for Mac are great, but
            </aside>
          </section>
        </section>

        <!-- modularity & builds -->
        <section>
          <section data-markdown>
            # modularity & builds

            ## you already know

            to keep scripts out of your `head`
            to limit the number of http requests
            to reduce http overhead via minification

            ## you should know

            AMD, RequireJS/Almond, UglifyJS, Closure Compiler
          </section>

          <section>
            <iframe src="http://requirejs.org" width="960" height="700"></iframe>

            <aside class="notes">
              RequireJS lets you write modular code and then build it for production.

              Module loading in dev happens async, so it doesn't slow you down.

              In prod, use built files, but continue to load pieces async
              if you'd like.
            </aside>
          </section>

          <section data-markdown>
            <pre>
              <code class="javascript">
define([ 'jquery', 'underscore' ], function($, _) {
  return {
    placeAt : function(data, templateString, node) {
      $(node).html(_.template(templateString, data));
    }
  };
});
              </code>
            </pre>

            A module using AMD; specify dependencies, return an object

            <aside class="notes">
              Dependency management is taken care of for you, too
            </aside>
          </section>

          <section data-markdown>
            <pre>
              <code class="javascript">
require.config({
  deps: ["main"],

  paths: {
    // JavaScript folders
    libs: "../assets/js/libs",
    plugins: "../assets/js/plugins",

    // Libraries
    jquery: "../assets/js/libs/jquery",
    lodash: "../assets/js/libs/lodash",
    backbone: "../assets/js/libs/backbone"
  },

  shim: {
    backbone: {
      deps: [ "lodash", "jquery" ],
      exports: "Backbone"
    }
  }
});
              </code>
            </pre>

            The RequireJS config from [Backbone Boilerplate](https://github.com/tbranyen/backbone-boilerplate)

            <aside class="notes">
              Tell Require where to find dependencies, and "shim" libraries like
              Backbone and Underscore that don't support AMD out of the box.
            </aside>
          </section>

          <section class="oneliner centered" data-markdown>
            `r.js -o your.build.js`

            <aside class="notes">
              For production, run r.js and pass it your instructions.
            </aside>
          </section>

          <section data-markdown>
            ## before requirejs

            <p class="centered">
              <img src="img/unbuilt.png" width="800" class="clean">
            </p>

            <aside class="notes">
              You can keep your dev environment sane and modular with lots
              of small files that don't pollute the global namespace ...
            </aside>
          </section>

          <section data-markdown>
            ## after requirejs

            <p class="centered">
              <img src="img/built.png" width="800" class="clean">
            </p>

            <aside class="notes">
              ... and consolidate it all into a handful of requests for production
            </aside>
          </section>
        </section>

        <!-- dev tools -->
        <section>
          <section data-markdown>
            # dev tools

            ## you already know

            `console.log`, `console.dir`, editing CSS, the Network tab,
            Firebug or Chrome dev tools

            ## you should know

            breakpoints & step debugging, `$0`, timelines & profiles,
            other browsers
          </section>

          <section data-markdown>
            <div class="centered">
              <iframe width="960" height="480" src="http://www.youtube.com/embed/nOEw9iiopwI" frameborder="0" allowfullscreen></iframe>
            </div>

            [Chrome Developer Tools: 12 Tricks](http://www.youtube.com/embed/nOEw9iiopwI)

            <aside class="notes">
              Paul Irish has some *great* YouTube videos about getting the most 
              out of Chrome dev tools.
            </aside>
          </section>

          <section data-markdown>
            <iframe width="960" height="600" src="https://developers.google.com/chrome-developer-tools/docs/scripts-breakpoints"></iframe>

            [Chrome Developer Tools Docs: Breakpoints](https://developers.google.com/chrome-developer-tools/docs/scripts-breakpoints)

            [Fixing These jQuery](http://fixingthesejquery.com)

            <aside class="notes">
              There are also great docs about using breakpoints.

              BTW, Fixing these jQuery from Adam Sontag -- if you haven't seen this, it is an amazing
              resource for improving your debugging skills (or helping someone
              improve theirs).
            </aside>
          </section>

          <section data-markdown>
            <iframe width="960" height="600" src="http://my.opera.com/dragonfly/blog/" frameborder="0" allowfullscreen></iframe>

            [Opera Dragonfly](http://my.opera.com/dragonfly/blog/)

            <aside class="notes">
              Chrome is the browser most devs are using for debugging these days,
              but Opera and other browsers still have great things to offer for
              specific needs -- Opera, for example, has some great color palette 
              management stuff if you're designing in the browser. 

              Which of course you are, right? 
            </aside>
          </section>
        </section>

        <!-- command line -->
        <section>
          <section data-markdown>
            # command line

            ## you already know

            either the command line is amazing,
            or the command line is terrifying

            ## you should know

            ack, ssh, find, curl, git, npm;
            creating aliases for commonly used commands

            <aside class="notes">
              This is probably the rant-iest section of this talk. If we're to
              call ourselves developers, we can't be afraid of the command line, 
              and yet ...
            </aside>
          </section>

          <section>
            <blockquote>Is it <em>unreasonable to ask for a GUI</em>
              so that whatever I’m doing works like all
              the other programs I use all day?</blockquote>
            <cite>Dark_Prism on Reddit</cite>
          </section>

          <section class="oneliner">
            <h2>YES.</h2>
          </section>

          <section>
            <blockquote>Now you can berate me for not understanding
              the Terminal if you like, but I’ll trade your rubygems
              for my under-colour removal and dot gain, any day
              of the week. <em>How hard should this be?</em></blockquote>
            <cite>Andy Clarke, author of “Hardboiled Web Design”</cite>
          </section>

          <section class="oneliner">
            <h2>IT’S NOT HARD IF YOU TRY.</h2>
          </section>

          <section data-markdown class="centered">
            <a href="https://github.com/gf3/dotfiles/"><img src="img/dotfiles.png" width="960" class="clean"></a>

            <aside class="notes">
              Our friend Gianni Chiappetta -- gf3 -- has meticulously curated "dotfiles".
              Take a look and be tantalized by what you could be doing with the command line.
            </aside>
          </section>

          <section data-markdown>
            ## tools you can use

            - `ack`: Smarter-than-`grep` search for text within files in a directory
            - `find`: Locate files whose names match a pattern. Bonus points:
              use the files as the arguments to a `sed` command
            - `curl`: test the behavior of a data API
            - `npm` and `gem`: a universe of usefulness

          </section>
        </section>

        <!-- templates -->
        <section>
          <section data-markdown>
            # templates

            ## you already know

            to send data, not HTML, from the server;
            to build HTML as a string & insert it into the DOM all at once*

            ## you should know

            various templating libraries & tradeoffs,  
            the RequireJS `text!` plugin

            <small>* This is less true in modern browsers!</small>
          </section>

          <section data-markdown>
            <iframe src="http://garann.github.com/template-chooser/" width="960" height="600"></iframe>

            [Garann Means’ Template Engine Chooser](http://garann.github.com/template-chooser/)
          </section>

          <section>
            <pre class="thin">
              <code class="javascript">
define([
  'views/base',
  <span class="code-highlight">'text!views/templates/searchForm.html'</span>
], function(View, tpl) {
  return View.extend({
    template : tpl,

    // ...
  });
});
              </code>
            </pre>

            - [More about RequireJS and templates]()

            <aside class="notes">
              BTW, you can use Require to manage text dependencies, too
            </aside>
          </section>
        </section>

        <!-- css -->
        <section>
          <section data-markdown>
            # css

            ## you already know

            CSS doesn't have variables but it should; 
            OOCSS helps a little; optimize everything else
            before you optimize CSS selector perf

            ## you should know

            SASS, Stylus, and/or LESS
          </section>

          <section data-markdown>
            <pre class="thin large">
              <code class="css">
border-radius()
  -webkit-border-radius arguments
  -moz-border-radius arguments
  border-radius arguments

body
  font 12px Helvetica, Arial, sans-serif

a.button
  border-radius(5px)
              </code>
            </pre>

            [Stylus](http://learnboost.github.com/stylus/)
          </section>

          <section data-markdown>
            <pre class="thin large">
              <code class="css">
$blue: #3bbfce;
$margin: 16px;

.content-navigation {
  border-color: $blue;
  color:
    darken($blue, 9%);
}

.border {
  padding: $margin / 2;
  margin: $margin / 2;
  border-color: $blue;
}
              </code>
            </pre>

            [SASS](http://sass-lang.com/)
          </section>

          <section data-markdown>
            <iframe src="http://lesscss.org/" width="960" height="600"></iframe>
            <div class="oval-marker fragment">This is a lie</div>

            [LESS](http://lesscss.org/)
          </section>
        </section>

        <!-- testing -->
        <section>
          <section data-markdown>
            # testing

            ## you already know

            you should be testing your code,
            but it’s  hard to know where to start

            ## you should know

            modularizing code makes testing easier;  
            baby steps are better than no steps at all
          </section>

          <section data-markdown>
            <iframe src="http://visionmedia.github.com/mocha/" width="960" height="600" style="background-color:white"></iframe>

            [Mocha](http://visionmedia.github.com/mocha/)

            <aside class="notes">
              Mocha works well in a Node stack because it can be used for testing 
              client and server code; browser runner is trivial to set up.

              In a Ruby stack, you might prefer Jasmine.

              Or you might prefer QUnit. I really don't care. TEST.
            </aside>
          </section>

          <section data-markdown>
            <iframe src="http://szafranek.net/works/articles/javascript-unit-testing/" width="960" height="600"></iframe>

            [Getting Started with JS Unit Testing](http://szafranek.net/works/articles/javascript-unit-testing/)
          </section>

          <section data-markdown class="oneliner">
            We *desperately* need more resources
            to teach people how to get started with testing.
          </section>
        </section>

        <!-- code quality -->
        <section>
          <section data-markdown>
            # code quality

            ## you already know

            subtle flaws in code can ruin your day

            ## you should know

            JSHint, pre-commit hooks, editor plugins
          </section>

          <section data-markdown>
            <iframe src="http://www.jshint.com/options/" width="960" height="600"></iframe>
            [JSHint](http://www.jshint.com/options/)
          </section>
        </section>

        <!-- automation -->
        <section>
          <section data-markdown>
            # automation

            ## you already know

            there are an awful lot of things that you do all the time

            ## you should know

            tools like grunt, rake, ant can simplify your life
          </section>

          <section data-markdown>
            <p class="centered">
              <img src="img/grunt.png" height="600" alt="Grunt" class="clean">
            </p>

            [Grunt](https://github.com/cowboy/grunt)

            <aside class="notes">
              Grunt comes with built-in tools for common tasks like minification, testing,
              RequireJS builds, and more. 
            </aside>
          </section>

          <section data-markdown>
          </section>
        </section>

        <!-- docs -->
        <section>
          <section data-markdown>
            # docs

            ## you already know

            [w3schools.com](http://dai.ly/MB95Ww) is abhorrent

            ## you should know

            [MDN](https://developer.mozilla.org/en-US/), [dochub.io](http://dochub.io/); prefix all your JS searches  with “mdn” (or&nbsp;!js on duckduckgo)
          </section>
        </section>

        <section>
          <section data-markdown class="centered">
            <blockquote>A good programmer is a lazy programmer; <br>
              only lazy programmers will want to write <br>
              the kind of tools that might replace them <br>
              in the end. But for a lazy programmer to be <br>
              a good programmer, he or she must be <br>
              <em>incredibly unlazy when it comes <br>
                to learning how to stay lazy.</em></blockquote>
            <cite>Paraphrased from Philipp Lenssen,  “[Why Good Programmers are Lazy and Dumb](http://blogoscoped.com/archive/2005-08-24-n14.html)”</cite>
          </section>
        </section>

        <section class="centered oneliner" data-markdown>
          <p><img src="img/bocoup.png" class="clean" alt="Bocoup" height="300"></p>

          [@rmurphey](http://twitter.com/rmurphey)&nbsp;&nbsp;☆&nbsp;&nbsp;[rmurphey.com](http://rmurphey.com)&nbsp;&nbsp;☆&nbsp;&nbsp;[bocoup.com](http://bocoup.com)

          [bit.ly/front-end-dev-baseline](http://bit.ly/front-end-dev-baseline)

        </section>


      </div>

      <!-- The navigational controls UI -->
      <aside class="controls">
        <a class="left" href="#">&#x25C4;</a>
        <a class="right" href="#">&#x25BA;</a>
        <a class="up" href="#">&#x25B2;</a>
        <a class="down" href="#">&#x25BC;</a>
      </aside>

      <!-- Displays presentation progress, max value changes via JS to reflect # of slides -->
      <div class="progress"><span></span></div>

    </div>

    <script src="lib/reveal/reveal.js"></script>
    <script src="lib/highlight/highlight.pack.js"></script>
    <script src="lib/classList.js"></script>
    <script src="socket.io/socket.io.js"></script>

    <script>
    var query = {};
    var socket = io.connect(window.location.origin);

    socket.on('navigate', function(data) {
      var dir = data.direction;
      if (!dir) { return; }
      var fn = 'navigate' + dir.charAt(0).toUpperCase() + dir.slice(1);

      if (Reveal[fn]) {
        Reveal[fn]();
        return;
      }

      switch (dir) {
        case 'home':
          Reveal.navigateTo(0);
          break;
        case 'end':
          Reveal.navigateTo(Number.MAX_VALUE);
          break;
      }
    });

    var handleCurrentSlide = function(slideElement, event) {
      if (query.socketless) { return; }

      var nextindexh;
      var nextindexv;

      if (slideElement.nextElementSibling && slideElement.parentNode.nodeName == 'SECTION') {
        nextindexh = event.indexh;
        nextindexv = event.indexv + 1;
      } else {
        nextindexh = event.indexh + 1;
        nextindexv = 0;
      }

      var notes = slideElement.querySelector('aside.notes');
      var slideData = {
        notes : notes ? notes.innerHTML : '',
        indexh : event.indexh,
        indexv : event.indexv,
        nextindexh : nextindexh,
        nextindexv : nextindexv
      };

      socket.emit('slidechanged', slideData);
    };

    location.search.replace( /[A-Z0-9]+?=(\w*)/gi, function(a) {
        query[ a.split( '=' ).shift() ] = a.split( '=' ).pop();
        } );

    // Fires each time a new slide is activated
    Reveal.addEventListener( 'slidechanged', function( event ) {
      handleCurrentSlide(event.currentSlide, event);
    } );

    Reveal.initialize({
        // Display controls in the bottom right corner
    controls: true,

    // Display a presentation progress bar
    progress: true,

    // If true; each slide will be pushed to the browser history
    history: true,

    // Loops the presentation, defaults to false
    loop: false,

    // Flags if mouse wheel navigation should be enabled
    mouseWheel: false,

    // Apply a 3D roll to links on hover
    rollingLinks: true,

    // UI style
    theme: query.theme || 'default', // default/neon

    // Transition style
    transition: query.transition || 'default' // default/cube/page/concave/linear(2d)
    });

    hljs.initHighlightingOnLoad();

    (function boom(){

     if (!window.Showdown){
       var scr = document.createElement('script');
       scr.onload = boom;
       scr.src = 'lib/showdown.js';
       document.body.appendChild(scr);
       return;
     }

     [].forEach.call( document.querySelectorAll('[data-markdown]'), function  fn(elem){

       // strip leading whitespace so it isn't evaluated as code
       var text      = elem.innerHTML.replace(/\n\s*\n/g,'\n'),
       // set indentation level so your markdown can be indented within your HTML
       leadingws = text.match(/^\n?(\s*)/)[1].length,
       regex     = new RegExp('\\n?\\s{' + leadingws + '}','g'),
       md        = text.replace(regex,'\n'),
       html      = (new Showdown.converter()).makeHtml(md);

       // here, have sum HTML
       elem.innerHTML = html;

       });

     }());
 </script>

  </body>
</html>