Google Maps API Key Issue

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.


  1. Went to and clicked the ‘Get a Key’ button.
  2. 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).
  3. To limit the accepted HTTP referrers to localhost, I needed to use the pattern localhost/* (
Posted in JavaScript | Leave a comment

Notes on deploying a MongoDB-backed Express app to Heroku

Reference: Getting Started with Node.js on Heroku

Preparing your application for deployment
Use 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.

Setting up the Heroku application and database
Reference: Deploying with Git, MongoLab

  1. Navigate to the directory containing your repository.
  2. $ heroku create – this creates the application on Heroku, and also adds a remote called heroku.
  3. 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.
  4. $ heroku addons:add mongolab

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.

Posted in Node.js, Version Control | Leave a comment

Syntax Highlighting For Code Examples in Web Pages

The google-code-prettify project makes it possible to apply syntax highlighting to code examples in web pages. These notes are based on the Getting Started guide and README.

  1. Include the run_prettify.js script in your page.
  2. Put your code example inside one of the supported elements and give the element the class prettyprint. The script supports the code, pre, and xmp elements.
Posted in Uncategorized | Leave a comment

Windows Command Line Reminders

dir /s/b *.mp3 – recursively list files with the specified extension
> foo.txt – redirect output to specified file
chdir – get full path to current directory
%~nxf – gives filename.extension (How to get filename only without path in windows command line?)

Posted in Uncategorized | Leave a comment

A Couple of Useful CSS Transforms

Using Rotation to Create Vertical Headers
You can use rotate(-90deg) (or DXImageTransform.Microsoft.BasicImage(rotation=3) for IE) to rotate a element to make it vertical.
Sideways Headers
Text Rotation
Note: for browser support for transforms please see CSS3 Transforms. For information on applying transforms to inline elements see the Stack Overflow question CSS transform doesn’t work on inline elements.

Using Transitions and Translations to Create an Off-Canvas Menu
CSS transforms and transitions (transform: translateX(350px); transition: transform 500ms ease;) give a much smoother experience than jQuery animations for a flyout menu.
Implementing Off-Canvas Navigation For A Responsive Website
Off Canvas Menus with CSS3 Transitions and Transforms
Note: for browser support for transitions see CSS3 transitions. Remember to use the appropriate vendor prefixes in the transitions (CSS3 transforms and transitions (Webkit)).

Posted in Web Design | Leave a comment

FoWA London 2014 Notes: Zach Holman on Move Fast and Break Nothing

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

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.

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

(= retrospectives)

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

Posted in Future of Web Apps | Leave a comment

FoWA London 2014 Notes: Rob Dudley on Front-End Automation Tools

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

Pre-requisites: node.js and npm

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

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

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.

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.

Posted in Future of Web Apps | Leave a comment

FoWA London 2014 Notes: James Turner on How to Build Front-End Web Apps that Scale

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

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

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.

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

Posted in Future of Web Apps | Leave a comment

FoWA London 2014 Notes: Camille Baldock on Telling Stories with APIs

Notes from Camille Baldock, Telling Stories with APIs, 1 October 2014
Speaker Slides

Kindle API is based on book – book, chapters, pages (nested resources)
“What is the user need?”

User need 1: child reading cares about events and characters
This isn’t linear – it’s linked data rather than a list of resources.
Could use JSON API or HAL (latter has JSON and XML versions)
“HAL embeds child documents recursively”
“JSON API flattens the entire graph of objects at the top level”
HAL uses links to identify things, JSON API uses IDs so caching easier because can identify if already have it.

User need 2: adult reading wants to understand context
e.g. information about the author’s life
DBPedia – linked data version of Wikipedia
JSON-LD [<- LD stands for linked data] = W3C recommended format
– Adds ID and context allowing you to link data
– Means can keep RESTful API and still have semantic web i.e. “Augment existing APIs without introducing breaking changes”

User need 3: deeper understanding of life
“What not to do”:
– Trust Rails to generate JSON
– Think “has many of” is sufficient info about context
“Adding operations to JSON-LD with HYDRA” (can add control e.g. read-only for certain users)

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.

Posted in Uncategorized | Leave a comment

FoWA London 2014 Notes: Kirsten Hunter on Irresistible APIs

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

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

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)

Posted in Future of Web Apps | Leave a comment