Build Right: Frontend Tooling @ BDConf Nashville

Build Right: Frontend Tooling @ BDConf Nashville

Slides for the Frontend Tooling workshop at BDConf in Nashville.

475203b37527b26e4fb2cc58e6e8493e?s=128

Build Right

July 28, 2014
Tweet

Transcript

  1. WELCOME

  2. None
  3. Who we are

  4. Who are you?

  5. http://bit.ly/bd-conf- nashville-frontend-tooling

  6. BUILD RIGHT: FRONTEND TOOLING PATH OF PAIN

  7. BUILD RIGHT: FRONTEND TOOLING TRADITIONAL PAIN

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

    DEV A DEV C “DONE!” THIS PART SUCKS LAST SEC CHANGES
  9. None
  10. PAIN POINTS

  11. ENLIGHTENMENT

  12. The traditional web development workflow is fraught with variance, isolation,

    and errors. Modern frontend tooling provides solutions for most of these issues.
  13. COMPUTERS SOFTWARE DEV FRONT END DEV

  14. CS FRONT END DEV SOURCE CONTROL DRY PRINCIPLES JAVASCRIPT

  15. “There’s a new set of baseline skills required in order

    to be successful as a front-end developer, and developers who don’t meet this baseline are going to start feeling more and more left behind…” ! —rmurphey.com/blog/2012/04/12/a-baseline- for-front-end-developers/
  16. BUILD RIGHT: FRONTEND TOOLING WHERE ARE WE HEADED?

  17. Productivity

  18. Editors

  19. Preprocessing

  20. github.com/sparkbox/ br-frontend-demo

  21. PRODUCTIVITY BUILD RIGHT: FRONTEND TOOLING

  22. LAYING THE GROUNDWORK A Case For Laziness

  23. Laziness: the programmer’s mantra

  24. DRY Don’t Repeat Yourself

  25. Productivity is about net gain.

  26. LAYING THE GROUNDWORK Getting Into The Command Line

  27. Should a frontend dev learn to use the CLI?

  28. Image: nasa.gov Launch a rocket without a control center?

  29. Image: flickr.com/photos/library_of_congress/ Fight a fire without an oxygen tank?

  30. Do it. It’s the “way in” to your computer

  31. If you're only comfortable with GUI interfaces, you're always going

    to be stuck relying on a translator.
  32. bit.ly/br-tooling-links

  33. You'll take a few steps backward in productivity when you

    begin. There's a net gain here, though.
  34. PRODUCTIVITY PAIN POINTS And Their Solutions

  35. MOUSE CLICKS Using the pointer is usually cumbersome.

  36. alfredapp.com Type everything.

  37. Alfred Workflows

  38. kapeli.com/dash Quick access to docs.

  39. vimium.github.io Internet with your keyboard.

  40. brettterpstra.com/projects/nvalt nvAlt: Quick access to text entry

  41. EXCESSIVE TYPING

  42. smilesoftware.com/ TextExpander TextExpander: speedy text snippets

  43. Shortcuts within the terminal: aliases and bash scripts

  44. alias c="clear" ~/.bashrc or ~/.zshrc

  45. alias go="cd ~/Documents/Projects ; ls" ~/.bashrc or ~/.zshrc

  46. Your /dotfiles repo

  47. Other People's Dotfiles (OPD) dotfiles.github.io github.com/asimpson/dotfiles

  48. DISTRACTION

  49. Achieving focus: Obsessive singularity

  50. None
  51. None
  52. manytricks.com/moom Moom: quick screen resizing

  53. Achieving focus: The desktop of evil

  54. Achieving focus: Hide your dock

  55. Achieving focus: Do not disturb

  56. THE INTERNET IS A DEEP BLACK HOLE
 The thing we

    build can also keep us from doing notable work
  57. THE PRODUCTIVITY MINDSET

  58. Drip, drip, drip ‣ Productivity boosts happen in tiny increments

    ‣ Could I automate this?
  59. Productivity Strain: ! Embrace small strains for huge productivity gains

    over time
  60. Productivity Strain COMFY OUCH! RADICAL IMPROVEMENT

  61. 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.
  62. Simple example: ! TYPE ALL OF YOUR CODE

  63. Your productivity hacks?

  64. TEXT EDITORS BUILD RIGHT: FRONTEND TOOLING

  65. Which editor do you use?

  66. WHY CAN’T WE ALL JUST GET ALONG?

  67. 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.
  68. HOWEVER

  69. You spend almost all of your time in your editor.

  70. Your editor preference changes the way you think.

  71. THE PATH OF PAIN

  72. TEXT EDITORS A few signs you need a better editor:

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

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

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

    4. You’ve hit a ceiling, and you can’t go higher.
  76. THE CASE FOR THE PLAIN TEXT EDITOR

  77. Technically, all you need to code is an app that

    will accept text:
  78. Writing all your code in TextEdit.app would be pretty painful,

    though! ‣ Lots of typing! ‣ No project tree ‣ No syntax highlighting ‣ Sad and depressed
  79. IDE? Integrated Development Environment

  80. This is the part you actually need

  81. Choosing a great text editor removes abstraction between your brain

    and your code.
  82. IDE’s ‣Slow development time ‣Messy code ‣Unskillful developers

  83. “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/
  84. Enter the simple, powerful text editor

  85. Here’s what to look for: ‣ are you comfortable in

    it? ‣ can it do what you need? ‣ is it writing code for you?
  86. THE CURRENT STATE OF EDITORS

  87. Editors on the market: ‣ Sublime Text ‣ Vim ‣

    TextMate ‣ BBedit ‣ Coda ‣ Emacs ‣ Espresso
  88. Editors you should actually consider: ‣ Sublime Text ‣ Vim

  89. Seriously, you guys. Vim Sublime Text sublimetext.com vim.org

  90. “I don’t think of BBedit as a commitment. It simply

    continues to be the best choice.” —bit.ly/editor-rage
  91. bit.ly/br-tooling-links

  92. Why Sublime? ‣low barrier of entry sublimetext.com/

  93. Why Sublime? ‣highly extensible

  94. Why Sublime? ‣highly extensible sublime.wbond.net/installation

  95. A few essential Sublime packages: Many more: sublime.wbond.net/ ‣ SideBarEnhancements

    ‣ AdvancedNewFile ‣ Emmet
  96. Why Sublime? ‣killer features Go to Anything: ⌘+P

  97. Why Sublime? ‣killer features Command Palette: ⌘+Shift+P

  98. 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
  99. Why Vim?

  100. Why Vim? ‣ fast ‣ mouseless! ‣ text objects and

    motions ‣ dot command ‣ configurable (vimrc, vundle) ‣ super old
  101. …the fact that, yes, people still use an editor that

    is over 20 years old […], and those people number in the hundreds of thousands, perhaps they might be
 onto something. csswizardry.com/2014/06/vim-for-people-who-think- things-like-vim-are-weird-and-hard/
  102. 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
  103. Runners-up panic.com/coda/ macrabbit.com/espresso/

  104. THE RABID CASH MACHINE

  105. TEXT EDITORS MATTER. GET FOAMY.

  106. 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!
  107. Seething, rabid coding machine

  108. There’s only one thing more important than your editor. The

    code it helps you write.
  109. While you're nerding out on your editor, your coworkers are

    raking in cash for the boss.
  110. THE RABID CASH MACHINE He’s using Sublime

  111. $ $

  112. PREPROCESSING BUILD RIGHT: FRONTEND TOOLING

  113. “I’m doing just fine, thank-you.”

  114. 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
  115. Usage of words, 1850 to 2014 —books.google.com/ngrams/

  116. AWFUL inspiring wonder or truly terrible?

  117. FANTASTIC existing only in the imagination or marvelous, wonderful?

  118. MOUSE small gray rodent with a long tail or a

    plastic device used to navigate on a computer screen
  119. Languages have always evolved.

  120. Why should we expect anything less from computer languages? ‣

    Incredible complexity ‣ Rapid change in hardware ‣ Rapid change in software
  121. Embrace “semantic shift” in your workflow if it tends toward

    efficiency.
  122. THE PATH OF PAIN Our languages are flawed ‣ HTML

    is redundant. ‣ CSS is “flat”. ‣ JavaScript is verbose.
  123. Preprocessors let us live in a fantasy world where we

    create the languages we want.
  124. What is a preprocessor, exactly?

  125. User friendly language PREPROCESSOR Compiled language

  126. Language optimized for humans PREPROCESSOR Language optimized for browsers

  127. What, exactly? ‣ Preprocessors are a way to write code

    in a friendly language. ‣ The code then gets processed into something that browsers can understand.
  128. CSS PREPROCESSORS

  129. Preprocessing: CSS ‣ Less: lesscss.org/ ‣ Stylus: learnboost.github.io/stylus/ ‣ Sass:

    sass-lang.com/
  130. 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;! }!
  131. .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!
  132. .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;! }!
  133. PREPROCESSING: CSS Which one? ‣ nesting ‣ variables ‣ mixins

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

    preference ‣ Shipped with Rails ‣ Not much else
  135. gem install sass! ! sass-lang.com

  136. PREPROCESSING: CSS Sass: The Ecosystem ‣ Compass ‣ Bourbon ‣

    Scut
  137. gem install compass! ! compass-style.org

  138. JAVASCRIPT PREPROCESSORS

  139. Preprocessing: JavaScript

  140. var number, summaryMarkup;! ! number = 3 + 2;! !

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

    Foo: #{number}! </p>! </div>! """! Coffee
  142. Preprocessors let us live in a fantasy world where we

    create the languages we want.
  143. sudo npm install -g coffee-script! ! coffeescript.org

  144. HTML PREPROCESSORS

  145. jade-lang.com

  146. haml.info

  147. We don’t use HTML preprocessing at Sparkbox

  148. Emmet emmet.io/

  149. LET’S PULL IT ALL TOGETHER

  150. How do we compile preprocessed code?

  151. bit.ly/br-tooling-links

  152. incident57.com/codekit/

  153. http://alphapixels.com/prepros/

  154. Honorable mentions: ‣ Less.app ‣ Scout app ‣ Compass.app

  155. Is there a better way?

  156. Ruby Node SASS, Compass Grunt packages Bundler NPM Grunt

  157. Grunt: a taskrunner gruntjs.com/

  158. npm install -g grunt-cli

  159. Grunt does all the things! ‣ Process CSS ‣ Process

    CoffeeScript ‣ Process HTML ‣ Reload a page when code changes ‣ Minify code ‣ So much more
  160. Grunt is a JavaScript task runner that can automate dozens

    of repetitive tasks.
  161. It's just JavaScript. (actually Node)

  162. Grunt: Open source. Just files.

  163. 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
  164. Bower: a frontend package manager bower.io/

  165. npm install -g bower

  166. 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
  167. bower install jquery

  168. “Bower runs over Git, and is package-agnostic.” —http://bower.io

  169. bower install git@github.com:sparkbox/Custom-Selectbox.git

  170. {! "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
  171. The holy grail: modular markup

  172. This is a simple page, right?

  173. None
  174. Many repeating elements

  175. This is our final preprocessor pain point

  176. Handlebars + Assemble: powerful, modular markup

  177. Handlebars ‣ Basic templating without a CMS ‣ Brings automation

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

    into manageable chunks ‣ Separate data from markup
  179. Notice the repetition?

  180. _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.
  181. _tool-list.hbs {{#each tool-list }}! {{> _tool-list-item }}! {{/each}}! Then use

    handlebars to automate it
  182. _tool-list-item.scss .tool-list-item {! @extend %clearfix;! overflow: hidden;! padding: 3em 1em;!

    position: relative;! }! Now our Sass can mirror this partial
  183. Questions?

  184. THANK-YOU!