Build Right: Frontend Tooling @ CSS Dev Conf New Orleans

Slides for the Frontend Tooling workshop at CSS Dev Conf in New Orleans.

Transcript

1. WELCOME
2. bit.ly/sparkbox-apprentice
4. Who we are
5. Who are you?
6. bit.ly/css-dev-frontend- tooling
7. BUILD RIGHT: FRONTEND TOOLING PATH OF PAIN
8. BUILD RIGHT: FRONTEND TOOLING TRADITIONAL PAIN
9. PATH OF PAIN Traditional Painful Flow DESIGNER FRONTEND BUILDING LAUNCH! DEV A ! DEV C “DONE!” THIS PART SUCKS LAST SEC CHANGES
11. PAIN POINTS
12. ENLIGHTENMENT
13. PAIN POINTS
14. ENLIGHTENMENT
15. The traditional web development workflow is fraught with variance, isolation, and errors. Modern frontend tooling provides solutions for most of these issues.
16. COMPUTERS SOFTWARE DEV FRONT END DEV
17. CS FRONT END DEV SOURCE CONTROL DRY PRINCIPLES JAVASCRIPT
18. “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/
19. BUILD RIGHT: FRONTEND TOOLING WHERE ARE WE HEADED?
20. Source Control
21. Static Design Tools
22. Local Servers
23. Deployment
24. Preprocessing
25. Editors
26. Development Tools
27. Device Testing
28. Productivity
29. github.com/sparkbox/ br-frontend-demo
30. PRODUCTIVITY BUILD RIGHT: FRONTEND TOOLING
31. LAYING THE GROUNDWORK A Case For Laziness
32. Laziness: the programmer’s mantra
33. DRY Don’t Repeat Yourself
34. Productivity is about net gain.
35. LAYING THE GROUNDWORK Getting Into The Command Line
36. Should a frontend dev learn to use the CLI?
37. Image: nasa.gov Launch a rocket without a control center?
38. Image: flickr.com/photos/library_of_congress/ Fight a fire without an oxygen tank?
39. Do it. It’s the “way in” to your computer
40. If you're only comfortable with GUI interfaces, you're always going to be stuck relying on a translator.
41. bit.ly/br-tooling-links
42. You'll take a few steps backward in productivity when you begin. There's a net gain here, though.
43. PRODUCTIVITY PAIN POINTS And Their Solutions
44. MOUSE CLICKS Using the pointer is usually cumbersome.
45. alfredapp.com Type everything.
46. Alfred Workflows
47. kapeli.com/dash Quick access to docs.
49. vimium.github.io Internet with your keyboard.
51. Touch typing. Practice typing without looking. Looking at your keyboard is a crutch. bullettrain.com
52. DOCUMENT SAVING, RETRIEVING & ORGANIZING
53. daringfireball.net/projects/markdown/ Markdown and the plain text workflow
54. Markdown
55. Markdown
56. Github
    ’s Markdown!
57. Github
    ’s Markdown!
58. brettterpstra.com/projects/nvalt nvAlt: Quick access to text entry
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
73. Achieving focus: The desktop of evil
74. Achieving focus: Hide your dock
75. Achieving focus: Do not disturb
76. THE INTERNET IS A DEEP BLACK HOLE
 The thing we build can also keep us from doing notable work
77. THE PRODUCTIVITY MINDSET
78. Drip, drip, drip ‣Productivity boosts happen in tiny increments ‣Could I automate this?
79. Productivity Strain: Embrace small strains for huge productivity gains over time
80. Productivity Strain COMFY OUCH! RADICAL IMPROVEMENT
81. 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.
82. Simple example: TYPE ALL OF YOUR CODE
83. Your productivity hacks?
84. TEXT EDITORS BUILD RIGHT: FRONTEND TOOLING
85. Which editor do you use?
86. NOBODY CARES
87. NOBODY CARES (since it doesn’t really affect them)
88. LET’S STOP FIGHTING. KUMBAYA.
89. HOWEVER
90. You spend almost all of your time in your editor.
91. You should feel comfortable in your editor.
92. THE PATH OF PAIN
93. TEXT EDITORS A few signs you need a better editor: 1. Your editor is writing code for you
94. TEXT EDITORS A few signs you need a better editor: 2. You’re repeating yourself
95. TEXT EDITORS A few signs you need a better editor: 3. You’ve hit a skill ceiling
96. TEXT EDITORS A few signs you need a better editor: 4. Your editor is in your way
97. This is the part you actually need
98. <blink>very simplicity</blink> <marquee>much essential</marquee> <div style=“text-align:right”>wow</div>
99. TextEdit.app Crazy IDE
100. TextEdit.app Crazy IDE SWEET SPOT
101. Choosing a great text editor removes abstraction between your brain and your code.
102. Let’s hit the sweet spot.
103. THE CURRENT STATE OF EDITORS
104. Editors on the market: ‣Sublime Text ‣Vim ‣TextMate ‣BBedit ‣Coda ‣Emacs ‣Espresso
105. Editors we’ll focus on: ‣Sublime Text ‣Vim
106. Vim Sublime Text sublimetext.com vim.org
108. Why Sublime? ‣low barrier of entry
109. Why Sublime? ‣killer features Go to Anything: ⌘+P
110. Why Sublime? ‣killer features Command Palette: ⌘+Shift+P
111. Why Sublime? ‣highly extensible
112. Why Sublime? ‣highly extensible sublime.wbond.net/installation
113. A few essential Sublime packages: Many more: sublime.wbond.net/ ‣SideBarEnhancements ‣AdvancedNewFile ‣Emmet
114. Why Sublime? ‣Power user features ‣Keeps out of your way ‣Strong community ‣Sorta free ‣Gateway drug to Vim
116. Vim is uncomfortable.
118. Vim is uncomfortable. Mostly because it’s modal.
119. When you’re painting a picture, most of your time is spent with your paintbrush off the canvas.* * Drew Neil’s analogy
120. Writing code works the same way.
121. Normal mode & Insert mode
122. .
123. Solid Community ‣Vimcasts ‣Vimbits ‣VimAwesome
124. My .vimrc bit.ly/ethansdotvim
125. There are a ton more cool things about Vim
126. Other editors are good, too panic.com/coda/ macrabbit.com/espresso/
127. TEXT EDITORS MATTER. GET DORKY.
128. SEETHING RABID CODING MACHINE
129. There’s only one thing more important than your editor. The code it helps you write.
130. While you're nerding out on your editor, your coworkers are raking in cash for the boss.
131. $ $
132. BUILD RIGHT: FRONTEND TOOLING SOURCE CONTROL
133. THE PATH OF PAIN Life without Source Control
134. Let’s build something!
138. Manually look for changes
139. Collaboration + Data Integrity
140. What about you?
141. UH… WHAT’S SOURCE CONTROL?
142. TERMS
143. Push Server Computer
144. Pull Server Computer
145. Commit ⌘ S +
146. Branch Master New Branch
147. Master New Branch Merge
148. Conflict !@#$
149. Branching is a huge feature.
150. 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
151. Go Branch Crazy
152. 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.
153. 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
154. Local v. Centralized
155. Both of these solutions suffer from having the change data stored in a single place.
156. Distributed: A third option arises!
157. Git is a DVCS
158. We use Git because it allows effortless branching, it's blazing fast, and it's extremely reliable
159. “[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)
160. bit.ly/br-tooling-links
161. QUITE THE COUPLE
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?
169. bit.ly/br-tooling-links
170. THE STATIC COMBATANTS
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/
176. Multiple Files v. Layer Comps
177. Layer Comps
178. Photoshop Drawbacks
179. ILLUSTRATOR
181. Illustrator Drawbacks
182. SKETCH
184. Sketch Cons
185. Reality is that design should be happening in all phases of a project.
186. Know your tools, use the right one for the task at hand.
187. Thoughts? Your Experience?
188. BROWSER DEVELOPER TOOLS BUILD RIGHT: FRONTEND TOOLING
189. THE PATH OF PAIN Dev Tools Edition
190. We don’t know how good we have it ‣Alerts to debug JavaScript alert("JavaScript is loaded!");
191. We don’t know how good we have it ‣Blindly switching between editor and browser
192. Humble beginnings ‣2006: Firebug ‣2007: IE Developer toolbar (IE6 and IE7) ‣2009: IE8 Developer tools
193. Firebug: a tool is born
194. “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
195. Now, dev tools are a key part of our workflow, and more powerful than ever.
196. YOUR BROWSER IS A DESIGN TOOL
197. Our designs have started far away from code…
198. …but we’re slowly moving closer to the code.
199. styletil.es “Style Tiles are similar to the paint chips and fabric swatches an interior designer gets approval on before designing a room”
200. …until we’re almost right on top of the code.
201. 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.
202. 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.
203. Our deliverable? Websites. The sooner we get to the code, the closer we are to shipping.
204. Image: “You best solve problems using tools you are fluent with.” 
 —@bencallahan fluency
205. Modern browser developer tools are incredibly sophisticated. Fluency is possible.
206. We should shift the bulk of our time toward the environment where our final deliverable will live.
207. Is this… really less complex?
208. A FRIENDLY BEGINNER’S GUIDE What can the dev tools do for me?
209. ⌘ + OPT + I or right-click, “Inspect Element” How do I view source?
210. The ideal inspector layout for RWD work
211. The ideal inspector layout for RWD work
212. Elements Tab
213. Network Tab
214. Sources Tab
215. DEV TOOLS MASTERY It can do that?!
216. Know this one thing!
217. The Settings Pane
218. Resources: loaded documents
219. Resources: local storage
220. Resources: cookies
221. Audit panel
222. Audit panel
223. Dev tools plugins
224. 3rd Party Dev Tool Plugins ‣Grunt devtools ‣Ember Inspector ‣RailsPanel ‣You name it!
225. bit.ly/br-tooling-links
226. PREPROCESSING BUILD RIGHT: FRONTEND TOOLING
227. “I’m doing just fine, thank-you.”
228. 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
229. Usage of words, 1850 to 2014 —books.google.com/ngrams/
230. AWFUL inspiring wonder or truly terrible?
231. FANTASTIC existing only in the imagination or marvelous, wonderful?
232. MOUSE small gray rodent with a long tail or a plastic device used to navigate on a computer screen
233. Languages have always evolved.
234. Why should we expect anything less from computer languages? ‣Incredible complexity ‣Rapid change in hardware ‣Rapid change in software
235. Embrace “semantic shift” in your workflow if it tends toward efficiency.
236. THE PATH OF PAIN Our languages are flawed ‣HTML is redundant. ‣CSS is “flat”. ‣JavaScript is verbose.
237. Preprocessors let us live in a fantasy world where we create the languages we want.
238. What is a preprocessor, exactly?
239. User friendly language PREPROCESSOR Compiled language
240. Language optimized for humans PREPROCESSOR Language optimized for browsers
241. What, exactly? ‣Preprocessors are a way to write code in a friendly language. ‣The code then gets processed into something that browsers can understand.
242. CSS PREPROCESSORS
243. Preprocessing: CSS ‣Less: lesscss.org/ ‣Stylus: learnboost.github.io/stylus/ ‣Sass: sass-lang.com/
244. 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; }
245. .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
246. .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; }
247. PREPROCESSING: CSS Which one? ‣nesting ‣variables ‣mixins / functions ‣extends ‣math ‣including
248. PREPROCESSING: CSS We use Sass ‣Widely used ‣Personal preference ‣Shipped with Rails ‣Not much else
249. Let’s take a look at some Sass.
250. $primary-color: #cb592c; $no-mq-support: false;
251. @mixin sb-media($query) { @if $no-mq-support{ @if $query < $serve-to-nomq-max-width{ @content; } } @else { @media ( 'min-width:' + $query ) { @content; } } }
252. gem install sass sass-lang.com
253. PREPROCESSING: CSS Sass: The Ecosystem ‣Compass ‣Bourbon ‣Scut
254. gem install compass compass-style.org
255. JAVASCRIPT PREPROCESSORS
256. Preprocessing: JavaScript
257. var number, summaryMarkup; number = 3 + 2; summaryMarkup = "<div class=\"content\">\n <p> \n Foo: " + number + "\n </p>\n</div>"; JS
258. number = 3+2 summaryMarkup = """ <div class="content"> <p> Foo: #{number} </p> </div> """ Coffee
259. Preprocessors let us live in a fantasy world where we create the languages we want.
260. sudo npm install -g coffee-script coffeescript.org
261. HTML PREPROCESSORS
262. jade-lang.com
263. haml.info
264. We don’t use HTML preprocessing at Sparkbox
265. Emmet emmet.io/
266. LET’S PULL IT ALL TOGETHER
267. How do we compile preprocessed code?
268. bit.ly/br-tooling-links
269. incident57.com/codekit/
270. http://alphapixels.com/prepros/
271. Honorable mentions: ‣Less.app ‣Scout app ‣Compass.app
272. Is there a better way?
273. Ruby Node SASS, Compass Grunt packages Bundler NPM Grunt
274. Grunt: a taskrunner gruntjs.com/
275. npm install -g grunt-cli
276. Grunt does all the things! ‣Process CSS ‣Process CoffeeScript ‣Process HTML ‣Reload a page when code changes ‣Minify code ‣So much more
277. Grunt is a JavaScript task runner that can automate dozens of repetitive tasks.
278. It's just JavaScript. (actually Node)
279. Grunt: Open source. Just files.
280. 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
281. Bower: a frontend package manager bower.io/
282. npm install -g bower
283. 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
284. bower install jquery
285. “Bower runs over Git, and is package-agnostic.” —http://bower.io
286. bower install git@github.com:sparkbox/Custom-Selectbox.git
287. { "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
288. The holy grail: modular markup
289. This is a simple page, right?
291. Many repeating elements
292. This is our final preprocessor pain point
293. Handlebars + Assemble: powerful, modular markup
294. Handlebars ‣Basic templating without a CMS ‣Brings automation power to markup (100’s of helpers) ‣Reduce repetition
295. Assemble ‣Light static site generator ‣Organize your layouts into manageable chunks ‣Separate data from markup
296. Notice the repetition?
297. _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.
298. _tool-list.hbs {{#each tool-list }} {{> _tool-list-item }} {{/each}} Then use handlebars to automate it
299. _tool-list-item.scss .tool-list-item { @extend %clearfix; overflow: hidden; padding: 3em 1em; position: relative; } Now our Sass can mirror this partial
300. Questions?
301. BUILD RIGHT: FRONTEND TOOLING LOCAL SERVERS
302. […] 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
303. Working via Remote Server ‣Slows development time ‣Opens up production vulnerabilities ‣Increases downtime
304. 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.
305. Remember DVCS?
306. OPTIONS
307. bit.ly/br-tooling-links
308. Packages
309. Roll Your Own
310. 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.
311. Try a number of solutions to find one that fits your project, your team, and your workflow
312. Your Local server of choice? Questions?
313. DEVICE TESTING BUILD RIGHT: FRONTEND TOOLING
314. GET YOUR HANDS DIRTY
315. Community Device Lab Start one?
316. Company Device Lab Start one?
318. Getting Started ‣Android mobile device ‣iOS mobile device (iPod Touch works great) ‣A tablet: iPad Mini, Kindle Fire, or Google Nexus
319. Poor man’s device lab! —Image source: http://www.flickr.com/photos/21241102@N00/3908708670/
320. VIRTUALIZATION
321. Desktop OS virtualization allows developers to run alternate operating systems for testing purposes.
322. parallels.com virtualbox.org
323. bit.ly/br-tooling-links
324. But what about 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. “Own your deployments from beginning to end.”
351. Services
352. bit.ly/br-tooling-links
354. https://divshot.com
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!