Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Build Right: Frontend Tooling @ Sparkbox HQ

Build Right
February 25, 2014

Build Right: Frontend Tooling @ Sparkbox HQ

The deck from the full day Build Right: Frontend Tooling workshop in Dayton, Ohio on February 25, 2014. For a list of links shared throughout the day, visit bit.ly/br-tooling-links

Build Right

February 25, 2014
Tweet

More Decks by Build Right

Other Decks in Technology

Transcript

  1. PATH OF PAIN Traditional Painful Flow DESIGNER FRONTEND BUILDING LAUNCH!

    DEV A DEV C “DONE!” THIS PART SUCKS LAST SEC CHANGES
  2. The traditional web development workflow is fraught with variance, isolation,

    and errors. Modern frontend tooling provides solutions for most of these issues.
  3. You'll take a few steps backward in productivity when you

    begin. There's a net gain here, though.
  4. THE INTERNET IS A DEEP BLACK HOLE
 The thing we

    build can also keep us from doing notable work
  5. Productivity Strain ‣ The best time to create a shortcut

    for an obtuse task is the moment you imagine that it could be faster. ‣ It’s probably billable time.
  6. Do Editors Matter? ‣ 90% of editor arguments are lighthearted

    ‣ Your editor preference barely effects the rest of your team ‣ Fighting over editors is almost useless. There are better battles to fight.
  7. TEXT EDITORS A few signs you need a better editor:

    1. Your editor is writing code for you
  8. TEXT EDITORS A few signs you need a better editor:

    2. You’re doing lots of clicking
  9. TEXT EDITORS A few signs you need a better editor:

    3. You’re repeating yourself—a lot!
  10. TEXT EDITORS A few signs you need a better editor:

    4. You’ve hit a ceiling, and you can’t go higher.
  11. Writing all your code in TextEdit.app would be pretty painful,

    though! ‣ Lots of typing! ‣ No project tree ‣ No syntax highlighting ‣ Sad and depressed
  12. “Dreamweaver was attempting to be helpful, but the moment it

    reformatted my code, I threw a fit. YOU TOUCHED MY CODE. Dreamweaver never recovered from that horrendous first impression.” http://randsinrepose.com/
  13. Here’s what to look for: ‣ are you comfortable in

    it? ‣ can it do what you need? ‣ is it writing code for you?
  14. Editors on the market: ‣ Sublime Text ‣ Vim ‣

    TextMate ‣ Coda ‣ Emacs ‣ Espresso
  15. Why Sublime? ‣ recent rise in popularity ‣ compared to

    Coda or Espresso, it’s fast & close to the code ‣ Vintage mode for Vim key bindings ‣ hint: you should use Sublime
  16. Why Vim? ‣ fast ‣ mouseless! ‣ dot command, macros,

    commands by line ‣ configurable (vimrc, vundle) ‣ super old
  17. Why Vim? ‣ high skill ceiling ‣ popular (vimbits.com) ‣

    Runs in a terminal ‣ everywhere (any platform, ssh, other people’s machines) ‣ fun, in a weird way
  18. Editor Cults ‣ Get cultic about your editor ‣ As

    you're making your case, you'll have to nerd out on your editor. ‣ This is where real learning happens!
  19. $ $

  20. Git supports rapid branching and merging [...] A core assumption

    in Git is that a change will be merged more often than it is written, as it is passed around various reviewers. Branches in git are very lightweight. http://marc.info/?l=linux- kernel&m=111288700902396
  21. DEFINING SOURCE CONTROL Source Control gives you: ‣ The ability

    to collaborate with others on a single codebase ‣ Manage any conflicts that collaboration brings ‣ The ability to move code around in time.
  22. Version control is a system that records changes to a

    file or set of files over time so that you can recall specific versions later http://git-scm.com/book/en/Getting-Started-About- Version-Control
  23. “[In making Git] Take CVS as an example of what

    not to do; if in doubt, make the exact opposite decision." Torvalds http://en.wikipedia.org/wiki/Git_(software)
  24. Photoshop is the most widely used, and most well known.

    http://bradfrostweb.com/blog/post/the-post-psd-era/
  25. We don’t know how good we have it ‣ Alerts

    to debug JavaScript alert("JavaScript is loaded!");
  26. We don’t know how good we have it ‣ Blindly

    switching between editor and browser
  27. Humble beginnings ‣ 2006: Firebug ‣ 2007: IE Developer toolbar

    (IE6 and IE7) ‣ 2009: IE8 Developer tools
  28. “When you hit the ‘Inspect’ button, mousing around the page

    will reveal the source of the element under your cursor ‘in real time’. Having the source instantly expand to reveal what what you touch is quite fun - it gives one the sensation of panning for gold.” ! —Joe Hewitt, creator of Firebug http://joehewitt.com/2006/03/15/firebug-a-love-story
  29. styletil.es “Style Tiles are similar to the paint chips and

    fabric swatches an interior designer gets approval on before designing a room”
  30. sparkbox.github.io/style-prototype/ “…allow[s] a client to get a visual summary of

    a site’s design direction without creating multiple Photoshop comps or fully developing HTML pages.
  31. demo.pattern-lab.info/ Atoms can also include more abstract elements like color

    palettes, fonts and even more invisible aspects of an interface like animations.
  32. We should shift the bulk of our time toward the

    environment where our final deliverable will live.
  33. 3rd Party Dev Tool Plugins ‣ Grunt devtools ‣ Ember

    Inspector ‣ RailsPanel ‣ You name it!
  34. SEMANTIC SHIFT “the evolution of word usage — usually to

    the point that the modern meaning is radically different from the original usage” —http://en.wikipedia.org/wiki/Semantic_change
  35. MOUSE small gray rodent with a long tail or a

    plastic device used to navigate on a computer screen
  36. Why should we expect anything less from computer languages? ‣

    Incredible complexity ‣ Rapid change in hardware ‣ Rapid change in software
  37. THE PATH OF PAIN Our languages are flawed ‣ HTML

    is redundant. ‣ CSS is “flat”. ‣ JavaScript is verbose.
  38. What, exactly? ‣ Preprocessors are a way to write code

    in a friendly language. ‣ The code then gets processed into something that browsers can understand.
  39. Less CSS .unstyled-link {! text-decoration: none;! }! ! .toollist-item {!

    .border-radius(5px);! background-color: #7b81d1;! ! a {! &:extend(.unstyled-link);! color: #000;! }! }! .toollist-item {! -webkit-border-radius: 5px;! -moz-border-radius: 5px;! border-radius: 5px;! background-color: #7b81d1;! }! ! .toollist-item a {! text-decoration: none; ! color: #000;! }!
  40. .toollist-item {! -webkit-border-radius: 5px;! -moz-border-radius: 5px;! border-radius: 5px;! background-color: #7b81d1;!

    }! ! .toollist-item a {! text-decoration: none; ! color: #000;! }! Stylus CSS .unstyled-link! text-decoration none! ! .toollist-item! border-radius 5px! background-color #7b81d1! ! a! @extend .unstyled-link! color #000!
  41. .unstyled-link {! text-decoration: none;! }! ! .toollist-item {! @include border-radius(5px);!

    background-color: #7b81d1;! ! a {! @extend %unstyled-link;! color: #000;! }! }! Sass CSS .toollist-item {! -webkit-border-radius: 5px;! -moz-border-radius: 5px;! border-radius: 5px;! background-color: #7b81d1;! }! ! .toollist-item a {! text-decoration: none; ! color: #000;! }!
  42. PREPROCESSING: CSS Which one? ‣ nesting ‣ variables ‣ mixins

    / functions ‣ extends ‣ math ‣ including
  43. PREPROCESSING: CSS We use Sass ‣ Widely used ‣ Personal

    preference ‣ Shipped with Rails ‣ Not much else
  44. @mixin sb-media($query) {! @if $no-mq-support{! @if $query < $serve-to-nomq-max-width{! @content;!

    }! } @else {! @media ( 'min-width:' + $query ) {! @content;! }! }! }
  45. var number, summaryMarkup;! ! number = 3 + 2;! !

    summaryMarkup = "<div class=\"content\">\n <p> \n Foo: " + number + "\n </p>\n</div>";! JS
  46. number = 3+2! ! summaryMarkup = """! <div class="content">! <p>!

    Foo: #{number}! </p>! </div>! """! Coffee
  47. Grunt does all the things! ‣ Process CSS ‣ Process

    CoffeeScript ‣ Process HTML ‣ Reload a page when code changes ‣ Minify code ‣ So much more
  48. module.exports = function(grunt) {! ! // Project configuration.! grunt.initConfig({! pkg:

    grunt.file.readJSON('package.json'),! uglify: {! options: {! banner: '/*! <%= pkg.name %> <%=grunt.template.today("yyyy- ! ! ! mm-dd") %> */\n'! },! build: {! src: 'src/<%= pkg.name %>.js',! dest: 'build/<%= pkg.name %>.min.js'! }! }! });! ! // Load the plugin that provides the "uglify" task.! grunt.loadNpmTasks('grunt-contrib-uglify');! ! // Default task(s).! grunt.registerTask('default', ['uglify']);! }; Everything lives in Gruntfile.js
  49. What is Bower? ‣ Pull down almost any JS library

    via the command line ‣ Not checking dependancies into the repp ‣ Use Grunt to manipulate the libraries once Bower pulls them down
  50. {! "name": "br-demo",! "version": "0.1.0",! "dependencies": {! "jquery": "1.9.1",! "js-md5":

    "~1.1.0",! "d3": "3.4.2",! "bootstrap": "2.3.2"! }! } Everything lives in bower.json
  51. Handlebars ‣ Basic templating without a CMS ‣ Brings automation

    power to markup (100’s of helpers) ‣ Reduce repetition
  52. Assemble ‣ Light static site generator ‣ Organize your layouts

    into manageable chunks ‣ Separate data from markup
  53. _tool-list-item.hbs <div class="tool-list-item" style="background-color: {{color}}">! <div class="tool-list-item--container">! <div class="tool-list-item--title">{{title}}</div>! <div

    class="tool-list-item--entry"><a href="{{entry-anchor}}" title="{{entry}}">{{entry}}</a></div>! {{#if notes}}! <div class="tool-list-item--expander js-trigger-tool-list">! <span class="icon-plus tool-list-item--expander-icon">! <a href="#" title="Read more">Read more</a>! </span>! </div>! {{/if}}! </div>! ! {{#if notes}}! <div class="tool-list-item--dropdown js-list-dropdown">! <div class="tool-list-item--dropdown-content wysiwyg">! {{#markdown}}{{notes}}{{/markdown}}! </div>! </div>! {{/if}}! </div>! Let’s write that once.
  54. […] what matters is if you can test any changes

    to your code fast enough. http://programmers.stackexchange.com/questions/ 139187/web-development-no-local-server-workflow
  55. Working via Remote Server ‣ Slows development time ‣ Opens

    up production vulnerabilities ‣ Increases downtime
  56. Working Locally ‣ Websites/apps load instantly ‣ Work offline ‣

    Allows existing live sites to be up and functioning normally. ‣ Catch errors before they get to staging or production.
  57. Vagrant ‣ Creates a VM to exactly replicate a production

    environment. ‣ Vagrant’s config can be checked into source control to replicate the environment across a team.
  58. Try a number of solutions to find one that fits

    your project, your team, and your workflow
  59. Getting Started ‣ Android mobile device ‣ iOS mobile device

    (iPod Touch works great) ‣ A tablet: iPad Mini, Kindle Fire, or Google Nexus
  60. VIRTUALIZATION Mobile Device Emulation ‣ iOS simulation with Xcode’s iOS

    Simulator ‣ Android simulation with Google’s Android Emulator
  61. We default to using physical devices if possible, VM’s for

    IE, and Browserstack for everything else.
  62. require 'mina/git'! ! set :repository, 'git://...'! set :env_config, YAML.load_file('./config/env.yml')! set

    :environment, ENV['on'] || env_config.fetch('default')! ! desc 'Sets up Mina to deploy to the requested environment'! task :environment do! env_config.fetch(environment).each do |key, value|! set key.to_sym, value.to_s! end! end! ! task :setup => :environment do! end! ! desc "Deploys the current version to the server."! task :deploy => :environment do! deploy do! invoke :'git:clone'! invoke :'deploy:link_shared_paths'! ! to :launch do! end! end! end desc "Deploys the current version to the server."! task :deploy => :environment do! deploy do! invoke :'git:clone'! invoke :'deploy:link_shared_paths'! ! to :launch do! end! end! end deploy.rb
  63. staging:! domain: staging.example.com! deploy_to: /var/www/staging_site! branch: master! ssh_options: "-A"! !

    production:! domain: example.com! deploy_to: /var/www/site! branch: production! ssh_options: "-A"! ! default: staging environments.yml