Build Right: Frontend Tooling @ ConvergeSE

Build Right: Frontend Tooling @ ConvergeSE

The deck from the full day Build Right: Frontend Tooling workshop in Columbia, SC on May 1, 2014. For a list of links shared throughout the day, visit bit.ly/br-tooling-links

475203b37527b26e4fb2cc58e6e8493e?s=128

Build Right

May 05, 2014
Tweet

Transcript

  1. @a_simpson @neilrenicker

  2. None
  3. Who we are

  4. Who are you?

  5. bit.ly/convergese- 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. 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. kapeli.com/dash Quick access to docs.

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

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

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

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

  52. Markdown

  53. Markdown

  54. Github ♥’s Markdown!

  55. Github ♥’s Markdown!

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

  57. None
  58. EXCESSIVE TYPING

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

  60. Shortcuts within the terminal: aliases and bash scripts

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

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

  63. Your /dotfiles repo

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

  65. DISTRACTION

  66. Syntax highlighting

  67. Achieving focus: Obsessive singularity

  68. None
  69. None
  70. manytricks.com/moom Moom: quick screen resizing

  71. Achieving focus: The desktop of evil

  72. Achieving focus: Hide your dock

  73. Achieving focus: Do not disturb

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

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

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

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

    over time
  78. Productivity Strain COMFY OUCH! RADICAL IMPROVEMENT

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

  81. Your productivity hacks?

  82. TEXT EDITORS BUILD RIGHT: FRONTEND TOOLING

  83. Which editor do you use?

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

  85. None
  86. 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.
  87. HOWEVER

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

  89. Your editor preference changes the way you think.

  90. THE PATH OF PAIN

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

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

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

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

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

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

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

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

  99. This is the part you actually need

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

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

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

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

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

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

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

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

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

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

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

  112. Why Sublime? ‣highly extensible

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

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

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

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

  117. 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
  118. Why Vim?

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

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

  122. THE RABID CASH MACHINE

  123. TEXT EDITORS MATTER. GET FOAMY.

  124. 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!
  125. Seething, rabid coding machine

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

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

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

  129. $ $

  130. BUILD RIGHT: FRONTEND TOOLING SOURCE CONTROL

  131. THE PATH OF PAIN Life without Source Control

  132. Let’s build something!

  133. None
  134. None
  135. None
  136. Manually look for changes

  137. None
  138. Collaboration + Data Integrity

  139. What about you?

  140. UH… WHAT’S SOURCE CONTROL?

  141. TERMS

  142. Push Server Computer

  143. Pull Server Computer

  144. Commit ⌘ S +

  145. Branch Master New Branch

  146. Master New Branch Merge

  147. Conflict !@#$

  148. Branching is a huge feature.

  149. 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
  150. Go Branch Crazy

  151. 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.
  152. 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
  153. Local v. Centralized

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

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

  156. Git is a DVCS

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

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

  161. QUITE THE COUPLE

  162. None
  163. INTRO TO USING GIT

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

  165. BUILD RIGHT: FRONTEND TOOLING DESIGN TOOLS

  166. VERSION CONTROL FOR DESIGNERS!

  167. Static or Hybrid?

  168. None
  169. bit.ly/br-tooling-links

  170. THE STATIC COMBATANTS

  171. None
  172. PAIN POINTS

  173. PHOTOSHOP

  174. Photoshop is the most widely used, and most well known.

    http://bradfrostweb.com/blog/post/the-post-psd-era/
  175. None
  176. Multiple Files v. Layer Comps

  177. Layer Comps

  178. Photoshop Drawbacks

  179. ILLUSTRATOR

  180. None
  181. Illustrator Drawbacks

  182. SKETCH

  183. None
  184. Sketch Cons

  185. NO WINNERS

  186. Reality is that design should be happening in all phases

    of a project.
  187. Know your tools, use the right one for the task

    at hand.
  188. Thoughts? Your Experience?

  189. BROWSER DEVELOPER TOOLS BUILD RIGHT: FRONTEND TOOLING

  190. THE PATH OF PAIN Dev Tools Edition

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

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

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

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

  195. “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
  196. None
  197. Now, dev tools are a key part of our workflow,

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

  199. Our designs have started far away from code…

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

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

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

  203. 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.
  204. 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.
  205. Our deliverable? Websites. The sooner we get to the code,

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

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

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

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

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

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

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

  213. The ideal inspector layout for RWD work

  214. The ideal inspector layout for RWD work

  215. Elements Tab

  216. Network Tab

  217. Sources Tab

  218. DEV TOOLS MASTERY It can do that?!

  219. Know this one thing!

  220. The Settings Pane

  221. Resources: loaded documents

  222. Resources: local storage

  223. Resources: cookies

  224. Audit panel

  225. Audit panel

  226. Dev tools plugins

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

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

  229. PREPROCESSING BUILD RIGHT: FRONTEND TOOLING

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

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

  233. AWFUL inspiring wonder or truly terrible?

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

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

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

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

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

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

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

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

  242. User friendly language PREPROCESSOR Compiled language

  243. Language optimized for humans PREPROCESSOR Language optimized for browsers

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

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

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

    sass-lang.com/
  248. 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;! }!
  249. .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!
  250. .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;! }!
  251. PREPROCESSING: CSS Which one? ‣ nesting ‣ variables ‣ mixins

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

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

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

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

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

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

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

  259. JAVASCRIPT PREPROCESSORS

  260. Preprocessing: JavaScript

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

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

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

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

  265. HTML PREPROCESSORS

  266. jade-lang.com

  267. haml.info

  268. We don’t use HTML preprocessing at Sparkbox

  269. Emmet emmet.io/

  270. LET’S PULL IT ALL TOGETHER

  271. None
  272. How do we compile preprocessed code?

  273. bit.ly/br-tooling-links

  274. incident57.com/codekit/

  275. http://alphapixels.com/prepros/

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

  277. Is there a better way?

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

  279. Grunt: a taskrunner gruntjs.com/

  280. npm install -g grunt-cli

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

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

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

  284. Grunt: Open source. Just files.

  285. 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
  286. DEMO

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

  288. npm install -g bower

  289. 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
  290. bower install jquery

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

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

  293. {! "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
  294. DEMO

  295. The holy grail: modular markup

  296. This is a simple page, right?

  297. Many repeating elements

  298. This is our final preprocessor pain point

  299. Handlebars + Assemble: powerful, modular markup

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

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

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

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

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

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

  307. BUILD RIGHT: FRONTEND TOOLING LOCAL SERVERS

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

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

  312. OPTIONS

  313. bit.ly/br-tooling-links

  314. Packages

  315. Roll Your Own

  316. 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.
  317. Try a number of solutions to find one that fits

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

  319. DEVICE TESTING BUILD RIGHT: FRONTEND TOOLING

  320. GET YOUR HANDS DIRTY

  321. Community Device Lab Start one?

  322. Company Device Lab Start one?

  323. None
  324. Getting Started ‣ Android mobile device ‣ iOS mobile device

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

  326. VIRTUALIZATION

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

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

  329. bit.ly/br-tooling-links

  330. But what about licensing?

  331. LICENSING.

  332. modern.ie

  333. Every major IE and it’s needed OS

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

  335. browserstack.com Simulated VMs in your browser

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

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

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

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

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

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

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

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

  344. Ghostlab Mac & Windows application 3RD PARTY SOFTWARE

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

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

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

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

    3RD PARTY SOFTWARE
  349. ACCESSIBILITY TESTING

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

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

  352. VoiceOver on iOS ! Preferences > General > Accessibility

  353. Sim Daltonism Mac App Store

  354. iconfactory.com/software/xscope XScope

  355. BUILD RIGHT: FRONTEND TOOLING AUTOMATED DEPLOYMENT

  356. A Major Point of Vulnerability

  357. STOP FTPing ALL THE FILES

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

  359. Services

  360. bit.ly/br-tooling-links

  361. None
  362. Roll Your Own

  363. Mina

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

    a single Bash script
  365. Downsides ‣ Doesn’t support more complex configurations

  366. 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
  367. 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
  368. Capistrano

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

    ‣ Ruby syntax
  370. Downsides ‣ Slower than Mina ‣ More complex ‣ 2.x

    is buggy
  371. THANK-YOU!