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

Transcript

1. @robtarr @neilrenicker
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
46. kapeli.com/dash Quick access to docs.
48. vimium.github.io Internet with your keyboard.
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
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
72. manytricks.com/moom Moom: quick screen resizing
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
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?
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
121. A few essential Sublime packages: Many more: sublime.wbond.net/ ‣ SideBarEnhancements ‣ AdvancedNewFile ‣ Emmet
122. Why Sublime? ‣killer features Go to Anything: ⌘+P
124. Why Sublime? ‣killer features Command Palette: ⌘+Shift+P
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!
146. Manually look for changes
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)
171. bit.ly/br-tooling-links
172. +
173. thehubapp.com Hub: better Github notifications
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?
183. THE STATIC
 COMBATANTS
184. PAIN POINTS
185. POWER vs. COMPLEXITY
186. SKETCH Just enough power. No needless complexity.
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
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
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/
278. LET’S PULL IT ALL TOGETHER
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?
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?
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
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