8. ▪ we use a variety of testing tools:
▫ mocha, lab, tap
▪ we’re not dogmatic about TDD
▫ we’re dogmatic about writing tests.
▪ everything runs with Travis CI
Unit Testing
9. ▪ eliminates the question, did you write a test
for that?
▪ we use the coverage tool nyc
▪ we use Coveralls
Test Coverage
10. var express = require('wombat')
var app = wombat()
app.get('/', function (req, res) {
res.send('Hello Log')
})
app.listen(3000) github.com/bcoe/nyc
tools should be so
simple they’re fun to
use
11. ▪ this one is controversial!
▪ ultimately, we decided:
▫ use whatever coding style you like, but
automate its enforcement.
▪ I ❤ github.com/feross/standard
Coding Style
12. ▪ the longer you wait to upgrade, the more
annoying it becomes
▪ use npm outdated
▪ greenkeeper.io rocks
keep dependencies
up-to-date
13. var express = require('wombat')
var app = wombat()
app.get('/', function (req, res) {
res.send('Hello Log')
})
app.listen(3000)
greenkeeper.io
one of my top five, all
time, favorite robots
14. ▪ npm publish --tag=alpha
▪ npm version patch -m “awesome new
feature”
▪ we run several internal npm On-Sites:
▫ private npm packages are a thing.
we’re npm power
users
15. “engineers are far more tolerable of a
pedantic robot than they are pedantic
people.”
— someone probably.
19. ▪ unit-testing is a great example:
▫ developers learned running large OSS
projects, the benefits of unit-testing.
▪ people emulate the projects they respect:
▫ this creates a feedback loop!
how do habits spread?
20. “What works best is studying the projects of
other maintainers already on this list,
interacting with the developers, learning
from them, and emulating their
methodologies.”
— blog.npmjs.org
22. developers converge on the tools that
facilitate these practices
4 Best Practices
Center Around
Great Tools
23. 9/10 Use Travis CI10/10 Use GitHub 3/10 Use Coveralls
top 10 npm packages
24. ▪ a pull request is opened on GitHub
▪ build kicks off on Travis:
▫ installing modules from public and private
registries.
▪ a conversation begins between developers.
the npm workflow
25. ▪ pull-request kept up-to-date by robots:
▫ Coveralls reporting coverage.
▫ Travis CI reporting build status
▪ once merged, module is published to npm
▪ greenkeeper.io notifies other projects o/
the npm workflow
26. ▪ tools work together elegantly.
▪ as many steps are automated as possible:
▫ let humans do what humans are good at.
▪ it feels (a little bit) like you command a robot
army.
what makes this
awesome?
28. ▪ restrictions on infrastructure.
▪ practices lag behind.
▪ process can be overwhelming.
developing enterprise
software is hard
29. OSS methodologies
can work!
▪ OSS practices were designed to help large
asynchronous teams work effectively:
▫ this is applicable in large corporations!
▪ InnerSource: Internal Open Source at PayPal
30. “The results were visible after 6 months. The
Checkout Platform team spends 0% of its
time rewriting code and just 10% reviewing
submissions. The team was able to do a
major refactoring and a 4x increase in
performance without planning for it. The
mindset moved from blocking change to
mentoring and coaching.”
31. ▪ InnerSource is about:
▫ developers taking ownership of repos.
▫ people taking on the role of a lead
maintainer.
▪ developers need tools that empower them.
education is important
32. ▪ good developer tools do more than deliver
an asset to a build server:
▫ there’s a real disconnect between devs
and ops folks here.
what are good
developer tools?
33. ▪ it’s about facilitating communication.
▪ it’s about discovery.
▪ it’s about automation.
▪ it’s about delivering an asset to a build
server.
what do I mean by
this?
36. how are we working
together?
▪ we’re keeping our roadmaps aligned
▪ we’re looking for tighter integration points
▪ we’re preaching a similar message about
OSS in the Enterprise
37. why this is awesome
▪ OSS software and Enterprise software can
learn a lot from each other.
▪ we can make a developer’s life more
awesome.