“modern lint checkers are often used
to find code that doesn't correspond
to certain style guidelines.”
http://en.wikipedia.org/wiki/Lint_(software)
JSLint: http://www.jslint.com/
ESLint: https://github.com/nzakas/eslint
JSHint: http://www.jshint.com/
Slide 30
Slide 30 text
If there’s a reason to break those
rules, do it. But always explain why
Tip: JS linters respect scope within which you set local changes
Slide 31
Slide 31 text
Do we really have to do all
those things by ourselves?
Slide 32
Slide 32 text
Automation
Slide 33
Slide 33 text
But wait. Isn’t automation hard?
ANT? XML? RAKE? anyone?
Slide 34
Slide 34 text
GRUNT TO THE RESCUE
Slide 35
Slide 35 text
GRUNT TO THE RESCUE
Easy to configure
Slide 36
Slide 36 text
GRUNT TO THE RESCUE
Easy to configure
Plenty of plugins
Slide 37
Slide 37 text
GRUNT TO THE RESCUE
Easy to configure
Plenty of plugins
Writing your own task with no hassle
Slide 38
Slide 38 text
GRUNT TO THE RESCUE
Easy to configure
Plenty of plugins
Writing your own task with no hassle
It’s still just JavaScript and Node
Slide 39
Slide 39 text
Why should i use it?
Slide 40
Slide 40 text
Why should i use it?
Real-time feedback
Slide 41
Slide 41 text
Why should i use it?
Real-time feedback
Build process
Slide 42
Slide 42 text
Why should i use it?
Real-time feedback
Build process
Easy deployment
Slide 43
Slide 43 text
Why should i use it?
Real-time feedback
Build process
Easy deployment
Saves you time
Slide 44
Slide 44 text
Real-time feedback
Slide 45
Slide 45 text
Real-time feedback
Slide 46
Slide 46 text
Build process/Deployment
Slide 47
Slide 47 text
how to?
http://www.integralist.co.uk/posts/grunt-boilerplate/
https://speakerdeck.com/shaundunne/
grunt-your-way-to-glory-sideview-2013
http://merrickchristensen.com/articles/gruntjs-workflow.html
http://gruntjs.com/getting-started
Slide 48
Slide 48 text
Think about your build process before
starting a project and verify it before
merging anything to repository
Slide 49
Slide 49 text
pre-commit
!
pre-push
!
post-update
GitHooks
Slide 50
Slide 50 text
`your-repo/.git/hooks/hook-type`
HOW TO?
Keep in mind to set executable permissions for hook files:
`$ chmod +x your-repo/.git/hooks/hook-type`
Slide 51
Slide 51 text
Ah, and never tell your
friends that there’s
--no-verify flag!
Slide 52
Slide 52 text
If you decide to use pre-push hook
only, learn how to clean up
after your work
Slide 53
Slide 53 text
git commit --amend
git rebase --interactive
git cherry-pick
ARE YOUR FRIENDS
Slide 54
Slide 54 text
▼
Slide 55
Slide 55 text
Ok, but what if one of developers
didn’t set hooks?
!
Ask Travis for help
Slide 56
Slide 56 text
Travis CI
Lets you monitor status of your repository
and run specific tasks for every commit
!
It’s fully integrated with GitHub Status API
Slide 57
Slide 57 text
Setting up
Enable travis service hook on GitHub repository:
https://github.com/your-user/your-repo/settings/hooks
Create `.travis.yml`
in project root
And just add test script
to package.json
Slide 58
Slide 58 text
Yup, that’s it
3 steps
Slide 59
Slide 59 text
And now everyone can see
instant feedback
Slide 60
Slide 60 text
As well as verify whole pull-request
Slide 61
Slide 61 text
Keep in mind that still, no matter what,
people will be still making mistakes
!
Minimise the risk by allowing machine
to do the hard work
Slide 62
Slide 62 text
Those are only tools
They suppose to help you do your
work, not make it more difficult
Slide 63
Slide 63 text
Once written stack can be
a great codebase for all future
projects within your company
if everyone will respect
settled rules