The usecase here is to migrate an Heroku Application to Heroku Europe, and minimise downtime.
The heroku documentation on this subject is quite complete.
It is recommanded to read it if you are planning a migration.
https://devcenter.heroku.com/articles/app-migration
In this guide, sourceapp is the original (source) app and targetapp is the migrated (target) app.
| /*- | |
| * Copyright (c) 2017 | |
| * | |
| * This program is free software: you can redistribute it and/or modify | |
| * it under the terms of the GNU General Public License as published by | |
| * the Free Software Foundation, either version 3 of the License, or | |
| * (at your option) any later version. | |
| * This program is distributed in the hope that it will be useful, | |
| * but WITHOUT ANY WARRANTY; without even the implied warranty of |
| // getComponent is a function that returns a promise for a component | |
| // It will not be called until the first mount | |
| function asyncComponent(getComponent) { | |
| return class AsyncComponent extends React.Component { | |
| static Component = null; | |
| state = { Component: AsyncComponent.Component }; | |
| componentWillMount() { | |
| if (!this.state.Component) { | |
| getComponent().then(Component => { |
This guide makes no assumptions on prior knowledge of Github Pages or Travis CI. You'll know which steps to skip (if the project uses Pages already, this will overwrite them). Assumed is you have a public D project on GitHub and you have documented its API with embedded ddoc comments. You should probably be aware of the known issues of ddox, which we use here.
For a project URL like https://github.com/<user>/<project>, the documentation will appear at https://<user>.github.io/<project>/.
The long story: https://docs.travis-ci.com/user/getting-started/, https://docs.travis-ci.com/user/languages/d/
The short story:
| var db = mongoose.connect('mongodb://localhost:27017/DB'); | |
| // In middleware | |
| app.use(function (req, res, next) { | |
| // action after response | |
| var afterResponse = function() { | |
| logger.info({req: req}, "End request"); | |
| // any other clean ups |
sudo npm install -g puppeteer --unsafe-perm=true --allow-root
sudo npm install -g puppeteer --unsafe-perm=true --allow-root
Recently I noticed that Safari 10 for Mac/iOS had achieved 100% support for ES6. With that in mind, I began to look at the browser landscape and see how thorough the support in the other browsers. Also, how does that compare to Babel and its core-js runtime. According to an ES6 compatability table, Chrome, Firefox, and IE Edge have all surpassed what the Babel transpiler can generate in conjunction with runtime polyfills. The Babel/core-js combination achieves 71% support for ES6, which is quite a bit lower than the latest browsers provide.
It made me ask the question, "Do we need to run the babel es2015 preset anymore?", at least if our target audience is using Chrome, Firefox, or Safari.
It's clear that, for now, we can't create a site or application that only serves ES6. That will exclude users of Internet Explorer and various older browsers running on older iOS and Android devices. For example, Safari on iOS 9 has pretty mediocre ES6 support.
Move a background around within a container
A Pen by Denis Sellu on CodePen.