what makes me “Grunt”?
developer happiness courtesy of automation

Fabien Doiron / @fabien_doiron
no automation
make me go something something
I work on Crated
software developer, front-end

@fabien_doiron
when I got into development

front-end development was pretty simple
typical tools

HTML / CSS / JS / FTP / browser
then something happened

front-end development became complex
current typical tools

linting / preprocessors / concatenation /
minification / versioning / testing /
coverage / dependen...
tools mentioned
from our stack
environment:

back-end:

front-end:
4 reasons
we use build tools & automation
build tools
in 10 seconds or less
what?
automation
why?
automate what you have but don't want to do
how?
configure a task once, run as often as you want

~ ▸ build task:target
who?
Grunt, Gulp, Phing, Make, Rake, Jake, Brunch, Ant…
1.

project setup
project setup: goal
coding ready in minutes
project setup: tools
environment:

build
 tools:
project setup
in 3 easy steps
i.
~ ▸ git clone …
# get code from repository
~ ▸ git pull
# get latest code from repository
ii.
~ ▸ vagrant up
# puts together a complete environment
# provision environment with chef
iii.
~ ▸ phing proj:build
# get deps with composer, npm & bower
# database migration with phinx
# front-end build with gru...
2.

project output
project output: goal
reproducible results regardless of developer setup/workflow
reduce the risk of
“works on my machine”
by abstracting the output settings from the
user to the build tool
project output: tools
compiling CSS: user settings
~ ▸ sass in.scss:out.css
~ ▸ lessc in.scss > out.css

results: can vary
example task (Sass)
module.exports = function ( grunt ) {
var src = '<%= grunt.option( "src" ) %>';
var tmp = '<%= grunt.o...
compiling CSS: tool settings
~ ▸ grunt sass
~ ▸ grunt less

results: are the same
3.

coding environment
coding environment: goal
easily work in a dev and/or production replica environment
coding environment: tools
coding environments setup
in 4 easy steps
i. separate targets
~ ▸ grunt build:dev
# all source files, commented, unminified
~ ▸ grunt build:prod
# concat, minified,...
grunt versioning task
versioning: {
options: {
cwd: 'public',
outputConfigDir: 'public/config'
},
dist: {
files: [{
assets...
iii. generated configuration file
~ ▸ grunt build:dev
<?php
return array( 'static.assets' => array(
'global' => array(
'cs...
iii. generated configuration file
~ ▸ grunt build:prod
<?php
return array( 'static.assets' => array(
'global' => array(
'c...
ii. generated output
~ ▸ grunt build:dev
▾ public
▾ static
▾ css
main.css
▾ js
plugin1.js
plugin2.js
common1.js
common2.js...
iv. use generated configuration file
// inside our layouts
<?php $this->versionedAsset()->render( 'global' ); ?>

~ ▸ grun...
why did we go down this road?
cloudfront invalidation ~15 minutes
no longer applicable*

*appending a hash creates a “new” file
cleaner includes in our layouts
messy
if( APPLICATION_ENV == "production") {
// include concat/min files
} else {
// inclu...
demo
4.

debugging
debugging: goal
effectively debug errors
debugging [ compiled, ] concatenated,
minified code is hard
our approach
when a bug is found/reported
i. build dev environment
reproduce the error
rule out minification error
use devtools on source files
update/add unit, int...
ii. build prod environment
reproduce the error
use devtools with source maps
still have access to source files
easier to d...
“trying to fix a bug in minified code is like
using a new API with no documentation”
recap
being a front-end developer is hard
build tools make you awesome
automate the repetitive tasks
frictionless project setup
...
resources
chef
vagrant
phing
composer
grunt
bower
npm
grunt static versioning
CONFOO2014

40% off
coupon code because you were awesome

*valid until March 30, 2014
thank you

questions

Fabien Doiron / @fabien_doiron
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
What makes me "Grunt"?
Upcoming SlideShare
Loading in...5
×

What makes me "Grunt"?

3,067

Published on

Slides from my talk at Confoo 2014. Notes to come...

As a front end developer, I want to write code. Dealing with the mundane tasks that come with static assets such as concatenation, minification and versioning, I don't care much for. In this session, I'll explain how to setup Grunt tasks to handle CSS and JavaScript assets in both development and production environments. This automated workflow allows you to easily reproduce both environments locally for testing and debugging.

## Resources
* http://www.getchef.com/
* http://www.vagrantup.com/
* http://www.phing.info/
* https://getcomposer.org/
* http://www.gruntjs.com/
* http://www.bower.io/
* http://www.npmjs.com/
* http://github.com/canvaspop/grunt-static-versioning

## Links
* http://fabien-d.github.io/
* http://twitter.com/fabien_doiron
* http://canvaspop.com
* http://dna11.com
* http://crated.com
* http://developers.canvaspop.com
* http://remade.canvaspop.com/

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
3,067
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

What makes me "Grunt"?

  1. 1. what makes me “Grunt”? developer happiness courtesy of automation Fabien Doiron / @fabien_doiron
  2. 2. no automation make me go something something
  3. 3. I work on Crated software developer, front-end @fabien_doiron
  4. 4. when I got into development front-end development was pretty simple
  5. 5. typical tools HTML / CSS / JS / FTP / browser
  6. 6. then something happened front-end development became complex
  7. 7. current typical tools linting / preprocessors / concatenation / minification / versioning / testing / coverage / dependency management / continuous deployment / version control / frameworks / libraries…
  8. 8. tools mentioned from our stack
  9. 9. environment: back-end: front-end:
  10. 10. 4 reasons we use build tools & automation
  11. 11. build tools in 10 seconds or less
  12. 12. what? automation
  13. 13. why? automate what you have but don't want to do
  14. 14. how? configure a task once, run as often as you want ~ ▸ build task:target
  15. 15. who? Grunt, Gulp, Phing, Make, Rake, Jake, Brunch, Ant…
  16. 16. 1. project setup
  17. 17. project setup: goal coding ready in minutes
  18. 18. project setup: tools environment: build tools:
  19. 19. project setup in 3 easy steps
  20. 20. i. ~ ▸ git clone … # get code from repository ~ ▸ git pull # get latest code from repository
  21. 21. ii. ~ ▸ vagrant up # puts together a complete environment # provision environment with chef
  22. 22. iii. ~ ▸ phing proj:build # get deps with composer, npm & bower # database migration with phinx # front-end build with grunt ~ ▸ grunt build # lint, preprocess, concat, min, version # my personal favourite: ascii
  23. 23. 2. project output
  24. 24. project output: goal reproducible results regardless of developer setup/workflow
  25. 25. reduce the risk of “works on my machine” by abstracting the output settings from the user to the build tool
  26. 26. project output: tools
  27. 27. compiling CSS: user settings ~ ▸ sass in.scss:out.css ~ ▸ lessc in.scss > out.css results: can vary
  28. 28. example task (Sass) module.exports = function ( grunt ) { var src = '<%= grunt.option( "src" ) %>'; var tmp = '<%= grunt.option( "tmp" ) %>'; grunt.config( 'sass', { dist: { files: [ { expand: true, cwd: src + '/sass', src: [ '*.scss' ], dest: tmp + '/sass', ext: '.css' } ] } } ); grunt.loadNpmTasks( 'grunt-contrib-sass' ); };
  29. 29. compiling CSS: tool settings ~ ▸ grunt sass ~ ▸ grunt less results: are the same
  30. 30. 3. coding environment
  31. 31. coding environment: goal easily work in a dev and/or production replica environment
  32. 32. coding environment: tools
  33. 33. coding environments setup in 4 easy steps
  34. 34. i. separate targets ~ ▸ grunt build:dev # all source files, commented, unminified ~ ▸ grunt build:prod # concat, minified, versioned files
  35. 35. grunt versioning task versioning: { options: { cwd: 'public', outputConfigDir: 'public/config' }, dist: { files: [{ assets: '<%= uglify.main.files %>', key: 'global', dest: 'js', type: 'js', ext: '.min.js' }, { … } ] } }
  36. 36. iii. generated configuration file ~ ▸ grunt build:dev <?php return array( 'static.assets' => array( 'global' => array( 'css' => array( '/static/css/main.css' ), 'js' => array( '/static/js/file1.js', '/static/js/file2.js', … ) ), 'home' => array( 'css' => array(), 'js' => array( 'static/js/home1.js', '/static/js/home2.js' ) ), 'anotherKey' => array( … ) ) );
  37. 37. iii. generated configuration file ~ ▸ grunt build:prod <?php return array( 'static.assets' => array( 'global' => array( 'css' => array( '/static/css/main.7f41197e.min.css' ), 'js' => array( '/static/js/plugins.7409b19a.min.js', '/static/js/common.4923a32c.min.js', … ) ), 'home' => array( 'css' => array(), 'js' => array( 'static/js/home.47b0990d.min.js' ) ), 'anotherKey' => array( … ) ) );
  38. 38. ii. generated output ~ ▸ grunt build:dev ▾ public ▾ static ▾ css main.css ▾ js plugin1.js plugin2.js common1.js common2.js home1.js home2.js … ~ ▸ grunt build:prod ▾ public ▾ static ▾ css main.7f41197e.min.css ▾ js plugins.7409b19a.min.js common.4923a32c.min.js home.47b0990d.min.js …
  39. 39. iv. use generated configuration file // inside our layouts <?php $this->versionedAsset()->render( 'global' ); ?> ~ ▸ grunt build:dev <link rel="stylesheet" href="/static/css/main.css"> … <script src="/static/js/file1.js"></script> <script src="/static/js/file2.js"></script> … ~ ▸ grunt build:prod <link rel="stylesheet" href="/static/css/main.7f41197e.min.css"> … <script src="/static/js/plugins.7409b19a.min.js"></script> <script src="/static/js/common.4923a32c.min.js"></script>
  40. 40. why did we go down this road?
  41. 41. cloudfront invalidation ~15 minutes no longer applicable* *appending a hash creates a “new” file
  42. 42. cleaner includes in our layouts messy if( APPLICATION_ENV == "production") { // include concat/min files } else { // include all dev files } clean <?php $this->versionedAsset()->render( 'global' ); ?>
  43. 43. demo
  44. 44. 4. debugging
  45. 45. debugging: goal effectively debug errors
  46. 46. debugging [ compiled, ] concatenated, minified code is hard
  47. 47. our approach when a bug is found/reported
  48. 48. i. build dev environment reproduce the error rule out minification error use devtools on source files update/add unit, integration, regression tests generally all we need
  49. 49. ii. build prod environment reproduce the error use devtools with source maps still have access to source files easier to debug than on the live site update/add unit, integration, regression tests
  50. 50. “trying to fix a bug in minified code is like using a new API with no documentation”
  51. 51. recap
  52. 52. being a front-end developer is hard build tools make you awesome automate the repetitive tasks frictionless project setup reproduce output every time access to dev and production environments locally take the stress out of debugging
  53. 53. resources chef vagrant phing composer grunt bower npm grunt static versioning
  54. 54. CONFOO2014 40% off coupon code because you were awesome *valid until March 30, 2014
  55. 55. thank you questions Fabien Doiron / @fabien_doiron
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×