Build Right: Frontend Tooling @ Front-End Conf

Build Right: Frontend Tooling @ Front-End Conf

The deck from the full day Build Right: Frontend Tooling workshop in St. Petersburg, FL on July 10, 2014. For a list of links shared throughout the day, visit bit.ly/frontend-conf-workshop-notes

475203b37527b26e4fb2cc58e6e8493e?s=128

Build Right

July 10, 2014
Tweet

Transcript

  1. @robtarr @neilrenicker

  2. None
  3. Who we are

  4. Who are you?

  5. bit.ly/frontend-conf- workshop-notes

  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. PAIN POINTS

  10. ENLIGHTENMENT

  11. PAIN POINTS

  12. ENLIGHTENMENT

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

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

  15. CS FRONT END DEV SOURCE CONTROL DRY PRINCIPLES JAVASCRIPT

  16. “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/
  17. BUILD RIGHT: FRONTEND TOOLING WHERE ARE WE HEADED?

  18. Source Control

  19. Static Design Tools

  20. Local Servers

  21. Deployment

  22. Preprocessing

  23. Editors

  24. Development Tools

  25. Device Testing

  26. Productivity

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

  28. PRODUCTIVITY BUILD RIGHT: FRONTEND TOOLING

  29. LAYING THE GROUNDWORK A Case For Laziness

  30. Laziness: the programmer’s mantra

  31. DRY Don’t Repeat Yourself

  32. Productivity is about net gain.

  33. LAYING THE GROUNDWORK Getting Into The Command Line

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

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

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

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

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

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

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

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

  42. MOUSE CLICKS Using the pointer is usually cumbersome.

  43. alfredapp.com Type everything.

  44. Alfred Workflows

  45. None
  46. kapeli.com/dash Quick access to docs.

  47. None
  48. vimium.github.io Internet with your keyboard.

  49. None
  50. Touch typing. Practice typing without looking. Looking at your keyboard

    is a crutch. bullettrain.com
  51. DOCUMENT SAVING, RETRIEVING & ORGANIZING

  52. daringfireball.net/projects/markdown/ Markdown and the plain text workflow

  53. Markdown

  54. Markdown

  55. Github ♥’s Markdown!

  56. Github ♥’s Markdown!

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

  58. None
  59. metaclassy.com Byword: Beautiful Markdown

  60. EXCESSIVE TYPING

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

  62. Shortcuts within the terminal: aliases and bash scripts

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

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

  65. Your /dotfiles repo

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

  67. DISTRACTION

  68. Syntax highlighting

  69. Achieving focus: Obsessive singularity

  70. None
  71. None
  72. manytricks.com/moom Moom: quick screen resizing

  73. None
  74. Achieving focus: The desktop of evil

  75. Achieving focus: Hide your dock

  76. Achieving focus: Do not disturb

  77. theletterapp.com Let.ter: send-only email

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

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

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

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

    over time
  82. Productivity Strain COMFY OUCH! RADICAL IMPROVEMENT

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

  85. None
  86. Your productivity hacks?

  87. DEMO

  88. TEXT EDITORS BUILD RIGHT: FRONTEND TOOLING

  89. Which editor do you use?

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

  91. None
  92. 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.
  93. HOWEVER

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

  95. Your editor preference changes the way you think.

  96. THE PATH OF PAIN

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

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

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

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

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

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

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

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

  105. This is the part you actually need

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

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

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

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

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

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

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

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

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

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

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

  118. Why Sublime? ‣highly extensible

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

  120. None
  121. A few essential Sublime packages: Many more: sublime.wbond.net/ ‣ SideBarEnhancements

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

  123. None
  124. Why Sublime? ‣killer features Command Palette: ⌘+Shift+P

  125. None
  126. 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
  127. Why Vim?

  128. Why Vim? ‣ fast ‣ mouseless! ‣ dot command, macros,

    commands by line ‣ configurable (vimrc, vundle) ‣ super old
  129. …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/
  130. 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
  131. Runners-up panic.com/coda/ macrabbit.com/espresso/

  132. THE RABID CASH MACHINE

  133. TEXT EDITORS MATTER. GET FOAMY.

  134. 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!
  135. Seething, rabid coding machine

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

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

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

  139. $ $

  140. BUILD RIGHT: FRONTEND TOOLING SOURCE CONTROL

  141. THE PATH OF PAIN Life without Source Control

  142. Let’s build something!

  143. None
  144. None
  145. None
  146. Manually look for changes

  147. None
  148. Collaboration + Data Integrity

  149. main.css neil.css rob.css old.css

  150. What about you?

  151. UH… WHAT’S SOURCE CONTROL?

  152. TERMS

  153. Push Server Computer

  154. Pull Server Computer

  155. Commit ⌘ S +

  156. Branch Master New Branch

  157. Master New Branch Merge

  158. Conflict !@#$

  159. Branching is a huge feature.

  160. 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://en.wikipedia.org/wiki/Git_(software)
  161. Go Branch Crazy

  162. 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.
  163. 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
  164. Local v. Centralized

  165. Both of these solutions suffer from having the change data

    stored in a single place.
  166. Distributed: A third option arises!

  167. Git is a DVCS

  168. We use Git because it allows effortless branching, it's blazing

    fast, and it's extremely reliable
  169. “[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)
  170. None
  171. bit.ly/br-tooling-links

  172. +

  173. thehubapp.com Hub: better Github notifications

  174. None
  175. INTRO TO USING GIT

  176. Grab the GitHub App ! http://mac.github.com http://windows.github.com

  177. DEMO

  178. BUILD RIGHT: FRONTEND TOOLING DESIGN TOOLS

  179. VERSION CONTROL FOR DESIGNERS!

  180. ‣ Keynote: apple.com/mac/keynote/ ‣ Moqups: moqups.com/ ‣ Foundation: foundation.zurb.com/ ‣

    Bootstrap: getbootstrap.com/ Wireframing
  181. Static or Hybrid?

  182. None
  183. THE STATIC
 COMBATANTS

  184. PAIN POINTS

  185. POWER vs. COMPLEXITY

  186. SKETCH Just enough power. No needless complexity.

  187. None
  188. It ain’t perfect.

  189. NO WINNERS

  190. Design should be happening in all phases of a project.

  191. Know your tools, use the right one for the task

    at hand.
  192. Thoughts? Your Experience?

  193. DEMO

  194. BROWSER DEVELOPER TOOLS BUILD RIGHT: FRONTEND TOOLING

  195. THE PATH OF PAIN Dev Tools Edition

  196. We don’t know how good we have it ‣ Alerts

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

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

    (IE6 and IE7) ‣ 2009: IE8 Developer tools
  199. Firebug: a tool is born

  200. “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
  201. None
  202. Now, dev tools are a key part of our workflow,

    and more powerful than ever.
  203. YOUR BROWSER IS A DESIGN TOOL

  204. Our designs have started far away from code…

  205. …but we’re slowly moving closer to the code.

  206. styletil.es “Style Tiles are similar to the paint chips and

    fabric swatches an interior designer gets approval on before designing a room”
  207. …until we’re almost right on top of the code.

  208. 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.
  209. 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.
  210. Our deliverable? Websites. The sooner we get to the code,

    the closer we are to shipping.
  211. Image: “You best solve problems using tools you are fluent

    with.” 
 —@bencallahan fluency
  212. Modern browser developer tools are incredibly sophisticated. ! Fluency is

    possible.
  213. We should shift the bulk of our time toward the

    environment where our final deliverable will live.
  214. Is this… really less complex?

  215. A FRIENDLY BEGINNER’S GUIDE What can the dev tools do

    for me?
  216. ⌘ + OPT + I! or right-click, “Inspect Element” How

    do I view source?
  217. The ideal inspector layout for RWD work

  218. The ideal inspector layout for RWD work

  219. The ideal inspector layout for RWD work

  220. Elements Tab

  221. Network Tab

  222. Sources Tab

  223. DEV TOOLS MASTERY It can do that?!

  224. Know this one thing!

  225. The Settings Pane

  226. Resources: loaded documents

  227. Resources: local storage

  228. Resources: cookies

  229. Audit panel

  230. Audit panel

  231. Dev tools plugins

  232. 3rd Party Dev Tool Plugins ‣ Grunt devtools ‣ Ember

    Inspector ‣ RailsPanel ‣ You name it!
  233. bit.ly/br-tooling-links

  234. DEMO

  235. PREPROCESSING BUILD RIGHT: FRONTEND TOOLING

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

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

  239. AWFUL inspiring wonder or truly terrible?

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

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

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

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

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

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

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

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

  248. User friendly language PREPROCESSOR Compiled language

  249. Language optimized for humans PREPROCESSOR Language optimized for browsers

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

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

  252. None
  253. Preprocessing: CSS ‣ Less: lesscss.org/ ‣ Stylus: learnboost.github.io/stylus/ ‣ Sass:

    sass-lang.com/
  254. 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;! }!
  255. .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!
  256. .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;! }!
  257. PREPROCESSING: CSS Which one? ‣ nesting ‣ variables ‣ mixins

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

    preference ‣ Shipped with Rails ‣ Not much else
  259. Let’s take a look at some Sass.

  260. $primary-color: #cb592c;! $no-mq-support: false;!

  261. @mixin sb-media($query) {! @if $no-mq-support{! @if $query < $serve-to-nomq-max-width{! @content;!

    }! } @else {! @media ( 'min-width:' + $query ) {! @content;! }! }! }
  262. gem install sass! ! sass-lang.com

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

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

  265. DEMO

  266. JAVASCRIPT PREPROCESSORS

  267. Preprocessing: JavaScript

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

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

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

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

  272. HTML PREPROCESSORS

  273. jade-lang.com

  274. haml.info

  275. We don’t use HTML preprocessing at Sparkbox

  276. Emmet emmet.io/

  277. None
  278. LET’S PULL IT ALL TOGETHER

  279. None
  280. How do we compile preprocessed code?

  281. bit.ly/br-tooling-links

  282. incident57.com/codekit/

  283. http://alphapixels.com/prepros/

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

  285. Is there a better way?

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

  287. Grunt: a taskrunner gruntjs.com/

  288. npm install -g grunt-cli

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

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

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

  292. Grunt: Open source. Just files.

  293. 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
  294. Other Task Runners: gulpjs.com

  295. Other Task Runners: brunch.io

  296. Other Task Runners: github.com/broccolijs/broccoli

  297. Bower: a frontend package manager bower.io/

  298. npm install -g bower

  299. What is Bower? ‣ Pull down almost any JS library

    via the command line ‣ Not checking dependancies into the repo ‣ Use Grunt to manipulate the libraries once Bower pulls them down
  300. bower install jquery

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

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

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

  305. This is a simple page, right?

  306. None
  307. Many repeating elements

  308. This is our final preprocessor pain point

  309. Handlebars + Assemble: powerful, modular markup

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

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

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

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

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

    position: relative;! }! Now our Sass can mirror this partial
  316. DEMO

  317. Questions?

  318. BUILD RIGHT: FRONTEND TOOLING LOCAL SERVERS

  319. […] 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
  320. Working via Remote Server ‣ Slows development time ‣ Opens

    up production vulnerabilities ‣ Increases downtime
  321. 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.
  322. Remember DVCS?

  323. OPTIONS

  324. bit.ly/br-tooling-links

  325. Packages

  326. Roll Your Own

  327. 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. http://vagrantup.com
  328. Docker ‣ The Docker Engine container comprises just the application

    and its dependencies. ‣ …it enjoys the resource isolation and allocation benefits of VMs but is much more portable and efficient. http://docker.com
  329. Try a number of solutions to find one that fits

    your project, your team, and your workflow
  330. Your Local server of choice? Questions?

  331. DEVICE TESTING BUILD RIGHT: FRONTEND TOOLING

  332. GET YOUR HANDS DIRTY

  333. Community Device Lab Start one?

  334. Company Device Lab Start one?

  335. None
  336. Getting Started ‣ Android mobile device ‣ iOS mobile device

    (iPod Touch works great) ‣ A tablet: iPad Mini, Kindle Fire, or Google Nexus
  337. Poor man’s device lab! —Image source: http://www.flickr.com/photos/21241102@N00/3908708670/

  338. VIRTUALIZATION

  339. Desktop OS virtualization allows developers to run alternate operating systems

    for testing purposes.
  340. parallels.com virtualbox.org

  341. bit.ly/br-tooling-links

  342. But what about licensing?

  343. LICENSING.

  344. modern.ie

  345. Every major IE and it’s needed OS

  346. One-command install: ! github.com/xdissent/ievms

  347. browserstack.com Simulated VMs in your browser

  348. VIRTUALIZATION Mobile Device Emulation ‣ iOS simulation with Xcode’s iOS

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

    IE, and Browserstack for everything else.
  350. SYNCHRONIZED TESTING SOFTWARE

  351. 3RD PARTY SOFTWARE 3rd party synchronized testing software ‣ Adobe

    Edge Inspect ‣ Ghostlab
  352. Adobe Edge Inspect iOS & Android app Chrome Browser Extension

    3RD PARTY SOFTWARE
  353. Adobe Edge Inspect 3RD PARTY SOFTWARE

  354. Adobe Edge inspect works great, but limited in devices. Included

    in CC membership. 3RD PARTY SOFTWARE
  355. Ghostlab 3RD PARTY SOFTWARE

  356. Ghostlab Mac & Windows application 3RD PARTY SOFTWARE

  357. Ghostlab Hosts your site on a local server 3RD PARTY

    SOFTWARE
  358. Ghostlab Point any device on your network to that server

    3RD PARTY SOFTWARE
  359. Ghostlab Inspector on host device 3RD PARTY SOFTWARE

  360. Ghostlab is fast, almost unlimited in devices. $49.99 for license.

    3RD PARTY SOFTWARE
  361. ACCESSIBILITY TESTING

  362. Don’t overlook accessibility testing. Consider it a part of your

    job.
  363. VoiceOver on OS X System Preferences > Accessibility

  364. VoiceOver on iOS ! Preferences > General > Accessibility

  365. Sim Daltonism Mac App Store

  366. iconfactory.com/software/xscope XScope

  367. BUILD RIGHT: FRONTEND TOOLING AUTOMATED DEPLOYMENT

  368. A Major Point of Vulnerability

  369. STOP FTPing ALL THE FILES

  370. “Own your deployments from beginning to end.” !

  371. Services

  372. bit.ly/br-tooling-links

  373. None
  374. Roll Your Own

  375. Mina

  376. Features ‣ Fast! ‣ Uses Rake ‣ Boils down to

    a single Bash script
  377. Downsides ‣ A little harder to support more complex configurations

  378. require 'mina/bundler'! require 'mina/git'! ! set :domain, 'buildright.io'! set :deploy_to,

    '/var/www/buildright.io'! set :repository, 'git://...'! set :branch, 'master'! ! set :shared_paths, ['log']! ! task :setup => :environment do! queue! %[mkdir -p "#{deploy_to}/shared/log"]! queue! %[chmod g+rx,u+rwx "#{deploy_to}/shared/log"]! end! ! desc "Deploys the current version to the server."! task :deploy => :environment do! deploy do! invoke :'git:clone'! invoke :'deploy:link_shared_paths'! invoke :'bundle:install'! ! to :launch do! queue "touch #{deploy_to}/tmp/restart.txt"! 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
  379. 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
  380. Capistrano

  381. Features ‣ Deploys to multiple environments out of the box.

    ‣ Ruby syntax
  382. Downsides ‣ Slower than Mina ‣ More complex ‣ Developer

    commitment seemed to waiver a but for awhile recently
  383. Questions?

  384. THANK-YOU! @neilrenicker @robtarr