Jenny's Jottings

Notes from Zach Holman, Move Fast and Break Nothing, 1 October 2014
Speaker Slides

Not breaking things
Mark Zuckerberg has moved away from ‘move fast and break things’
Moving fast = better product because you see what works and it gives you momentum
But there are things it’s not OK to break e.g. billing, permissions
You avoid breaking them by testing
But production can differ from your expectations and the test’s expectations – find weird edge cases – and it’s production behaviour you mustn’t change
So use parallel development – every time you get a request run the new code as well and compare the results e.g using github/dat-science – you give it control code (which runs every time) and candidate code

CI as code maintenance
e.g. test for removing CSS as well if you remove the element that uses it, or vice versa – “automates grunt work out of code review”
They even test their blog posts e.g. for over-used phrases

Process
annp – apple new product process
GitHub has equivalent, but at end of process – ship lists
All the hard discussion and thinking has been done by the time you get to checklists

Code ownership
Not throwing it “over the wall”. People who write the code know how to fix it.
“Chrome has owner files [that] tie code to writers” – “Makes mentors [people you can ask] visible” to people who are going to start working on code. GitHub writes team name in file so issues get assigned to the appropriate team.

Communication
Better communication is better than more communication
“most things aren’t emergencies” – need to respect our co-workers’ time
“add empathy to your process” – comes from “real pain”, “everyone should do some support”

Institutional teaching
“it’s just logic that someday we won’t be here.” – Ed Catmull. So you need to transfer knowledge.
“chatops: learning by osmosis” – at GitHub they do everything via chat. People can watch you fix things. Real-life debugging – people posting status updates. “debug in the open”.

Feedback
(= retrospectives)

“Slow is death. You don’t want to be in a dead company”

Notes from Rob Dudley, Rocket-Powered Ramp Up with Front-end Automation Tools, 1 October 2014
Speaker Slides

Pre-requisites: node.js and npm

Bower
Front-end package manager (getting contained consistent copies – technically app store is a package manager)
Has search command, also a repo online
jQuery, Bootstrap, Underscore
$bower init creates bower JSON that specifies dependencies. Set private to true if you don’t intend to put the package in the Bower repo. --save or --save-dev on install saves it in the JSON.
$bower home gives you info on a package

Grunt
Superseded twice over
JavaScript task runner, massive number of plugins
Need to install grunt-cli and grunt separately
JSHint, uglify, concat, watch
Gruntfile.js reads package.json
$grunt – runs default task
$grunt <task> – runs particular task

Which plugin to use?
– Only load a plugin that does what you need it to do
– “Contrib” are official – kept up to date and always work
– Live reload and grunt concurrent are useful

Yeoman
Scaffolding tool

Legacy workflow
– Bower first – swap jQuery etc. out and replace with Bower versions.
– Grunt – minification, then SASS
– Yeoman for repeated tasks
– Build incrementally

You don’t commit node_modules, just the JSON. Suggests committing built assets.

Questions
What if you want to put them on CDN? – Bower will put it locally, so you have to get round it by swapping files out in a grunt task.

Notes from James, How to Build Front-end Web Apps that Scale, 1 October 2014

What’s a large-scale JS app?
Quote from Addy Osmani, Patterns for Large-Scale JavaScript Application Architecture

Large amounts of code
Complexity e.g. GMail – Large SPA, complex functionality, complex interactions, open all day
Long-lived – Features evolve, features added and removed, technology changes
Many contributors – Front-end devs, back-end devs, designers, QA, product owners, business analysts, …

What we need
Structure for codebase
Interaction architectures
Contributors work in harmony
Promote quality
Development productive

Structure
Use Libraries. Developers do too much work, when there’s a library to do it – if it’s not unique to your code, use a library.
Make it modular – module solving a small problem.
Divide into features.
“Component: sealed code unit fully configurable via its (documented) API Module: a general blob of functionality”
Their features are called blades because it’s a slice through the whole stack – HTML, CSS, Tests, etc.

API core
Bootstrap, layout manager, services, themes [<– the unique bits]
————————————————-
Tools, frameworks, components

Frameworks intrude above the line and affect how you write your code

Faster loading time because you’re only loading the code you need for that blade.
Easy for new developers to find assets – it’s all in the blade.
Re-use: make blade into assembly, top level becomes config and ‘glue’. But this is expensive, so only do it if you’ve got it three times.
Modules need to be able to use any rendering technology – don’t tie application to rendering framework.
Conway’s law – system will copy organisation’s communication structure
Vertical layers make it much more obvious who’s broken it.
Segmentation means less likely will break other sections.

Services
Services allow access to shared resources.
They’re a contract/protocol/interface – allows fail fast.
Decouples you from project risk from other teams because you can put in fakes.
Can inject implementations for different scenarios.

Tests
Don’t touch the DOM in E2E tests – theirs failed because the HTML changed. You should be poking the ViewModel instead.
Do test by contract.
Test time went from > 8 hours (running 3×, accepting < 5% failure), now < 10 minutes.

They automate builds, scaffolding, define workflow.
They have tooling for dependency analysis and compliance e.g. you are not allowed to reference another blade.

Questions
Sharing translated text?
– Putting things in libraries
– Theme defined at application level
Versioning services?
– They use streams rather than REST

Notes from Kirsten Hunter, Designing Irresistible APIs, 30 September 2014
Speaker Slides

API should be a first-class product; without API you get code duplication. Etsy did API first.

Why have an API
Mobile/market penetration – good reason to have API, so you get consistency with your main product. Netflix made themselves industry standard on video devices by providing API
Drive usage – e.g. Twitter
Defensive strategy – get there first
Technical case – making the hard easy e.g. APIs for sending SMSs
Partner connectivity – once a partner has integrated your system it will put them off switching to another provider

Building your API
Use cases
If it’s easy for you to use the API, it will be easy for others.
Mobile developers care about one call per screen, and small payload because you’ve only got a small pipe

Architectural Considerations – Think usability rather than scalability: if no-one uses it you don’t have to worry about scalability!

Expressive queries
Netflix can extend queries to retrieve other data because the user needs a big pipe to use their product anyway
LinkedIn users want to chain things together

XML
Most developers are using compiled languages and will be happier with XML, but Twitter did switch to JSON
XML is painful in interpreted languages, they prefer JSON
JSON also better for mobile developers because of payload

Authentication and Authorisation – can control access to system

Copy – if there’s a similar API, make yours similar

Schema Modeling – e.g. with Blueprint, Swagger. It’s like the WSDL file was for SOAP

Design Driven Development – test your API against use cases

Developer Experience
Communication – explain how to use the API
Trust – consumer needs to believe company values the API
Asking Questions – a bad expectation on the user’s part is still a bug; need to manage their expectations
Getting started – if people can’t work out what it does and how to use it they’ll walk away
Example code
Resources – don’t make assumptions about what developers know, provide resources
Tools – e.g. so that they can look at an object
Support – how quickly will you respond

Versions
Every time you create a new version of an API you create technical debt
If you put the version in their URL they’ll never move to the new version
Deprecating old APIs is expensive – Twitter alienated a lot of developers and increased their support expense
(Audience member said you can actually make lots of backwards-compatible changes)