Last weekend I was perplexed to find that Google Maps had apparently broken, but only when running my site locally – the production site seemed unaffected. The map would load and then after a couple of seconds it would be replaced by a ‘Sorry! Something went wrong.’ message. The JavaScript console showed a ‘Google Maps API warning: NoApiKeys’ warning, even though I was using my existing key.

I was able to fix the problem by following the instructions here to generate a new API key.

When I got to the ‘Create browser API key’ section, it was displaying a warning ‘You don’t have permission to create an API key’. The solution is explained here – I needed to create credentials (via the Credentials link in the sidebar).

Preparing your application for deploymentUse the configured port
Reference: Gotchas for Node JS apps on Heroku
Make sure it listens on the port defined in process.env.PORT. If it’s set to listen on some other port, when you try to access it via a browser you’ll see a message about an error occurring in your application and the logs will show something like:
...
2015-04-06T14:30:19.163763+00:00 heroku[router]: at=error code=H20 desc="App boot timeout" method=GET path="/" ...
2015-04-06T14:30:34.754286+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Webprocess failed to bind to $PORT within 60 seconds of launch
2015-04-06T14:30:34.754371+00:00 heroku[web.1]: Stopping process with SIGKILL
2015-04-06T14:30:35.842405+00:00 heroku[web.1]: State changed from starting to crashed
2015-04-06T14:30:35.832461+00:00 heroku[web.1]: Process exited with status 137

Use the configured MongoDB connection string
Reference: Deploying a MEAN stack app to Heroku
When you add the MongoLab add-on Heroku will put the connection string in process.env.MONGOLAB_URI, so you need to make sure you are using this value when making the connection.

$ heroku create – this creates the application on Heroku, and also adds a remote called heroku.

If you have not verified your Heroku account by adding credit card details, you will need to do so to be able to add MongoLab.

$ heroku addons:add mongolab

Deploying
Reference: How can I deploy from a Git subdirectory?
I had my AngularJS front-end and the Express back-end in the same repository. Heroku expects the app directory to be in the root of the repository (Deploying with Git), so I needed to be able to push a subdirectory to my heroku remote. This is possible using git-subtree:$ git subtree push --prefix my-subfolder heroku master
Note: I got an error message when I tried to run this from the normal Windows command line on my machine, but it worked in Git Bash.

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.

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”.

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

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.

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.

Users don’t think in terms of getting collections. So filtering by certain user group (adult, child) -> different possibilities from the API.
In The Little Prince, Saint-Exupéry makes three attempts at drawing a sheep for the Prince, Prince isn’t happy until he draws a picture of a box that he says has a sheep inside. -> don’t “recreate the wheel” – use standards [= the box] and provide info e.g. the grass for your sheep is over there.
Give real-world examples in your documentation, not list of operations. Swagger’s good.

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

Why have an APIMobile/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 APIDrive usage – e.g. TwitterDefensive strategy – get there firstTechnical case – making the hard easy e.g. APIs for sending SMSsPartner connectivity – once a partner has integrated your system it will put them off switching to another provider

Building your APIUse 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 ExperienceCommunication – explain how to use the APITrust – consumer needs to believe company values the APIAsking Questions – a bad expectation on the user’s part is still a bug; need to manage their expectationsGetting started – if people can’t work out what it does and how to use it they’ll walk awayExample codeResources – don’t make assumptions about what developers know, provide resourcesTools – e.g. so that they can look at an objectSupport – 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)