The first question you should ask is what platform you want to send push notifications on: native, or web. Either way, you will need a dedicated back-end infrastructure to handle the traffic like the other answer says, but depending on the platform there are great third-party resources. For native push, I recommend using UrbanAirship. For web push, Roost provides a great service that covers Firefox, Chrome, and Safari. Building out the actual infrastructure required to send push notifications to all platforms is way more complex than it may seem, and using a third-party provider is definitely the way to go.

I had a similar situation migrating to a new version of a dashboard -- it was highly unstable for a little while, but the UI was so improved that most users still preferred to use it, although both versions needed to be available. From a data standpoint, @JanVladimirMostert is absolutely correct about versioning your API (starting with a /v1/ route right from the get-go is a great practice), but sometimes you need to maintain, or at least serve, two radically different front-ends after a redesign, which is what I think you may be talking about. I used two Git repos, one for the legacy version and one for the new version. I use Codeship, but with most CLI tools you can have it pull from these repos during build automatically, so it really doesn't add any overhead to the deploy. Then in the new version, I had a banner up at the top for a few weeks that let the user switch back to the legacy version. Two repos might seem heavy-handed, but there's really no drawback, and if you're talking about radically different codebases (in my case it was a simple bootstrap-ajax front-end versus a whole EmberJS SPA) it really makes sense.

Similar to the cousin comment here, if you do need to use third-party services (it's often highly preferable to avoid re-inventing the wheel), try to find one that is open source / supported by an open source community. For example, when planning for a new dashboard last year I was choosing between Angular, Ember, and React. Without starting a flame war (they all have their benefits), Angular and React were disqualified in my mind largely on the basis of their propreitary nature. This ended up being a pretty lucky / safe call with regard to Angular, as migrating to 2.0 would have required a large rewrite. In the case of Parse, it's good to remember that there are often less flashy, less cool, but much more stable alternatives to these kinds of services. I mentioned on another thread that CouchDB is a pretty awesome choice in this regard. Apache services are never the cool choice, but if they're anything it's stable.

Wow, that example "flyfile" is... beautiful. May have to give this a closer look!

Firebase is pretty cool and really easy to get up and running with, but I'd still be hesitant to use it in any serious production application (they were acquired by Google not too long ago, and it's not crazy to think a similar situation may arise there). Apache CouchDB would be my bet.

I don't use NPM as a build tool (I use grunt for the product I work on and gulp for a few private projects), but it does seem interesting. If I were to use something other than the standard gulp/grunt build, though, I think I would opt for using Make. The reasons, and a brief intro, are outlined pretty well in an article by the folks at segment.io.

Ubuntu is fantastic and very easy to get up and running, but if you want a crash course in how Linux really works, I recommend using Arch. I had used Ubuntu and Fedora before, but never really had a handle on Linux until I set up Arch. It can be difficult to get going, but their instructions and tutorials are really fantastic -- just read it all the way through before you start.

scotch.io is a great source for tutorials (https://scotch.io/tag/node-js). I also recommend the Manning book on NodeJS, NodeJS in Action (https://www.manning.com/books/node-js-in-action). As the other comment said, NodeSchool is also a fantastic resource.

It'll be interesting to see the effect that ES6 syntax has on the learning curve for new JS programmers. It's always been a pretty accessibly language, given that you don't really need a deep understanding of OO principles or computer science to get started writing simple scripts, or even a Node server. I think ES6 changes that a bit, since you really do need to understand the underlying concepts of JS to take full advantage of things like fat arrow syntax (requires a good understanding of functional context), generators (closures), and even let (hoisting). Maybe we'll see a general increase in the quality of new JS programmers, but I hope there isn't a steep decline in general quantity.

As a self-taught developer who has also been recently interviewing devs from both self-taught and academic backgrounds, there are a couple major pros and cons that I see repeatedly. Pros - Motivated to learn new things - Confidence to know that unknown tech can be approached and tamed - First-hand knowledge of what makes a system/language/framework accessible (or not) to beginners - Passion Cons - Lack of theoretical background can start to catch up as you move into more senior roles (although this can be abated with continued hard work and independent study). - Lack of understanding of underlying principles can lead to unscalable and inappropriately hacky code. - Lack of understanding of algorithms can be lead to same problems as above. These are very general of course, and definitely don't apply to everybody. I think the best quality that self-taught devs have is a real passion for programming and desire to improve on personal time (although plenty of academic programmers have that as well). The cons can also be overcome with hard work and determination.