Build Right: Frontend Tooling @ Sparkbox HQ

475203b37527b26e4fb2cc58e6e8493e?s=47 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

475203b37527b26e4fb2cc58e6e8493e?s=128

Build Right

February 25, 2014
Tweet

Transcript

  1. @a_simpson @neilrenicker

  2. None
  3. bit.ly/br-tooling-notes-sb

  4. BUILD RIGHT: FRONTEND TOOLING PATH OF PAIN

  5. BUILD RIGHT: FRONTEND TOOLING TRADITIONAL PAIN

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

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

  8. ENLIGHTENMENT

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

    and errors. Modern frontend tooling provides solutions for most of these issues.
  10. BUILD RIGHT: FRONTEND TOOLING WHERE ARE WE HEADED?

  11. Source Control

  12. Static Design Tools

  13. Local Servers

  14. Deployment

  15. Preprocessing

  16. Editors

  17. Development Tools

  18. Device Testing

  19. Productivity

  20. PRODUCTIVITY BUILD RIGHT: FRONTEND TOOLING

  21. LAYING THE GROUNDWORK A Case For Laziness

  22. Laziness: the programmer’s mantra

  23. DRY Don’t Repeat Yourself

  24. Productivity is about net gain.

  25. LAYING THE GROUNDWORK Getting Into The Command Line

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

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

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

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

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

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

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

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

  34. MOUSE CLICKS Using the pointer is usually cumbersome.

  35. alfredapp.com Type everything.

  36. Alfred Workflows

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

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

  40. Touch typing. Practice typing without looking. Looking at your keyboard

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

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

  43. Markdown

  44. Markdown

  45. Github —’s Markdown!

  46. Github —’s Markdown!

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

  48. EXCESSIVE TYPING

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

  50. Shortcuts within the terminal: aliases and bash scripts

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

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

  53. Your /dotfiles repo

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

  55. DISTRACTION

  56. Syntax highlighting

  57. Achieving focus: Obsessive singularity

  58. None
  59. None
  60. manytricks.com/moom Moom: quick screen resizing

  61. Achieving focus: The desktop of evil

  62. Achieving focus: Hide your dock

  63. Achieving focus: Do not disturb

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

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

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

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

    over time
  68. Productivity Strain COMFY OUCH! RADICAL IMPROVEMENT

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

  71. None
  72. Your productivity hacks?

  73. TEXT EDITORS BUILD RIGHT: FRONTEND TOOLING

  74. Which editor do you use?

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

  76. None
  77. 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.
  78. HOWEVER

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

  80. Your editor preference changes the way you think.

  81. THE PATH OF PAIN

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

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

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

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

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

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

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

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

  90. This is the part you actually need

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

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

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

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

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

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

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

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

  100. bit.ly/br-tooling-links

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

  102. Why Sublime? ‣highly extensible

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

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

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

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

  107. 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
  108. Why Vim?

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

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

  112. THE RABID CASH MACHINE

  113. TEXT EDITORS MATTER. GET FOAMY.

  114. 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!
  115. Seething, rabid coding machine

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

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

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

  119. $ $

  120. BUILD RIGHT: FRONTEND TOOLING SOURCE CONTROL

  121. THE PATH OF PAIN Life without Source Control

  122. Let’s build something!

  123. None
  124. None
  125. None
  126. Manually look for changes

  127. None
  128. Collaboration + Data Integrity

  129. What about you?

  130. UH… WHAT’S SOURCE CONTROL?

  131. TERMS

  132. Push Server Computer

  133. Pull Server Computer

  134. Commit ⌘ S +

  135. Branch Master New Branch

  136. Master New Branch Merge

  137. Conflict !@#$

  138. Branching is a huge feature.

  139. 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
  140. Go Branch Crazy

  141. 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.
  142. 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
  143. Local v. Centralized

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

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

  146. Git is a DVCS

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

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

  151. QUITE THE COUPLE

  152. None
  153. INTRO TO USING GIT

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

  155. Main screen

  156. Changes

  157. Unsynced commits

  158. History

  159. BUILD RIGHT: FRONTEND TOOLING DESIGN TOOLS

  160. VERSION CONTROL FOR DESIGNERS!

  161. Static or Hybrid?

  162. None
  163. bit.ly/br-tooling-links

  164. THE STATIC COMBATANTS

  165. None
  166. PAIN POINTS

  167. PHOTOSHOP

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

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

  171. Layer Comps

  172. Photoshop Drawbacks

  173. ILLUSTRATOR

  174. None
  175. Illustrator Drawbacks

  176. SKETCH

  177. None
  178. Sketch Cons

  179. NO WINNERS

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

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

    at hand.
  182. Thoughts? Your Experience?

  183. BROWSER DEVELOPER TOOLS BUILD RIGHT: FRONTEND TOOLING

  184. THE PATH OF PAIN Dev Tools Edition

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

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

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

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

  189. “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
  190. None
  191. Now, dev tools are a key part of our workflow,

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

  193. Our designs have started far away from code…

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

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

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

  197. 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.
  198. 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.
  199. Our deliverable? Websites. The sooner we get to the code,

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

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

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

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

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

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

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

  207. The ideal inspector layout for RWD work

  208. The ideal inspector layout for RWD work

  209. Elements Tab

  210. Network Tab

  211. Sources Tab

  212. DEV TOOLS MASTERY It can do that?!

  213. Know this one thing!

  214. The Settings Pane

  215. Resources: loaded documents

  216. Resources: local storage

  217. Resources: cookies

  218. Audit panel

  219. Audit panel

  220. Dev tools plugins

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

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

  223. PREPROCESSING BUILD RIGHT: FRONTEND TOOLING

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

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

  227. AWFUL inspiring wonder or truly terrible?

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

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

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

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

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

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

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

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

  236. User friendly language PREPROCESSOR Compiled language

  237. Language optimized for humans PREPROCESSOR Language optimized for browsers

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

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

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

    sass-lang.com/
  242. 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;! }!
  243. .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!
  244. .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;! }!
  245. PREPROCESSING: CSS Which one? ‣ nesting ‣ variables ‣ mixins

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

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

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

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

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

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

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

  253. JAVASCRIPT PREPROCESSORS

  254. Preprocessing: JavaScript

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

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

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

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

  259. HTML PREPROCESSORS

  260. jade-lang.com

  261. haml.info

  262. We don’t use HTML preprocessing at Sparkbox

  263. Emmet emmet.io/

  264. LET’S PULL IT ALL TOGETHER

  265. None
  266. How do we compile preprocessed code?

  267. bit.ly/br-tooling-links

  268. incident57.com/codekit/

  269. http://alphapixels.com/prepros/

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

  271. Is there a better way?

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

  273. Grunt: a taskrunner gruntjs.com/

  274. npm install -g grunt-cli

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

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

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

  278. Grunt: Open source. Just files.

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

  281. npm install -g bower

  282. 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
  283. bower install jquery

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

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

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

  288. This is a simple page, right?

  289. None
  290. Many repeating elements

  291. This is our final preprocessor pain point

  292. Handlebars + Assemble: powerful, modular markup

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

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

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

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

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

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

  300. BUILD RIGHT: FRONTEND TOOLING LOCAL SERVERS

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

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

  305. OPTIONS

  306. bit.ly/br-tooling-links

  307. Packages

  308. Roll Your Own

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

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

  312. DEVICE TESTING BUILD RIGHT: FRONTEND TOOLING

  313. GET YOUR HANDS DIRTY

  314. Community Device Lab Start one?

  315. Company Device Lab Start one?

  316. None
  317. Getting Started ‣ Android mobile device ‣ iOS mobile device

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

  319. VIRTUALIZATION

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

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

  322. bit.ly/br-tooling-links

  323. But what about licensing?

  324. LICENSING.

  325. modern.ie

  326. Every major IE and it’s needed OS

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

  328. browserstack.com Simulated VMs in your browser

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

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

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

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

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

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

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

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

  337. Ghostlab Mac & Windows application 3RD PARTY SOFTWARE

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

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

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

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

    3RD PARTY SOFTWARE
  342. ACCESSIBILITY TESTING

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

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

  345. VoiceOver on iOS ! Preferences > General > Accessibility

  346. Sim Daltonism Mac App Store

  347. iconfactory.com/software/xscope XScope

  348. BUILD RIGHT: FRONTEND TOOLING AUTOMATED DEPLOYMENT

  349. A Major Point of Vulnerability

  350. STOP FTPing ALL THE FILES

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

  352. Services

  353. bit.ly/br-tooling-links

  354. None
  355. Roll Your Own

  356. Mina

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

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

  359. 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
  360. 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
  361. Capistrano

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

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

    is buggy
  364. Questions?

  365. THANK-YOU!