Pablo Graviel Seo pablogravielseo

This post is also on my blog, since Gist doesn't support @ notifications.

Components are taking center stage in Ember 2.0. Here are some things you can do today to make the transition as smooth as possible:

Use Ember CLI
In general, replace views + controllers with components
Only use controllers at the top-level for receiving data from the route, and use Ember.Controller instead of Ember.ArrayController or Ember.ObjectController
Fetch data in your route, and set it as normal properties on your top-level controller. Export an Ember.Controller, otherwise a proxy will be generated. You can use Ember.RSVP.hash to simulate setting normal props on your controller.

Service Worker - offline support for the web

Progressive apps - high-res icon, splash screen, no URL bar, etc.

Progressive Web Apps: Escaping Tabs Without Losing Our Soul

Ember Addon Essentials

This document is meant to be a brief "checklist" of things to setup for your Ember addon when beginning development in order to have the best possible architecture and workflow out of the gate. For more comprehensive material, the following are bookshelf-caliber:

Ember CLI's Official Addon Guide
Ember Addon Secrets - Written around the Ember 2.6 era, this article takes a much deeper dive into several of the topics mentioned here.

Filling out `package.json`

By the way, I'm available for tutoring and code review :)

What Promises library should I use?
How do I create a Promise myself?
How do I use new Promise?
How do I resolve a Promise?
But what if I want to resolve a synchronous result or error?
[But what if it's at the start of a chain, and I'm not in a .then callback yet?](https://gist.github.com/joepie91/4c3a10629a4263a522e3bc4839a28c83#6-but

Not all random values are created equal - for security-related code, you need a specific kind of random value.

A summary of this article, if you don't want to read the entire thing:

Don't use Math.random(). There are extremely few cases where Math.random() is the right answer. Don't use it, unless you've read this entire article, and determined that it's necessary for your case.
Don't use crypto.getRandomBytes directly. While it's a CSPRNG, it's easy to bias the result when 'transforming' it, such that the output becomes more predictable.
If you want to generate random tokens or API keys: Use uuid, specifically the uuid.v4() method. Avoid node-uuid - it's not the same package, and doesn't produce reliably secure random values.
If you want to generate random numbers in a range: Use random-number-csprng.

You should seriously consider reading the entire article, though - it's

If you want a run-down of the 1.3 changes and the design decisions behidn those changes, check out the LonestarElixir Phoenix 1.3 keynote: https://www.youtube.com/watch?v=tMO28ar0lW8

To use the new phx.new project generator, you can install the archive with the following command:

$ mix archive.install https://github.com/phoenixframework/archives/raw/master/phx_new.ez

Bump your phoenix dep

Phoenix v1.3.0 is a backwards compatible release with v1.2.x. To upgrade your existing 1.2.x project, simply bump your phoenix dependency in mix.exs:

Prelude

I. Preface and Motivation

This guide was written because I don't particularly enjoy deploying Phoenix (or Elixir for that matter) applications. It's not easy. Primarily, I don't have a lot of money to spend on a nice, fancy VPS so compiling my Phoenix apps on my VPS often isn't an option. For that, we have Distillery releases. However, that requires me to either have a separate server for staging to use as a build server, or to keep a particular version of Erlang installed on my VPS, neither of which sound like great options to me and they all have the possibilities of version mismatches with ERTS. In addition to all this, theres a whole lot of configuration which needs to be done to setup a Phoenix app for deployment, and it's hard to remember.

For that reason, I wanted to use Docker so that all of my deployments would be automated and reproducable. In addition, Docker would allow me to have reproducable builds for my releases. I could build my releases on any machine that I wanted in a contai

	import Ember from 'ember';

	// Ember 1.10

	export default Ember.Route.extend({

	//---fire in order on route enter---

	beforeModel(transition) {
	//empty by default

	sass/
	\|
	\|– base/
	\| \|– _reset.scss # Reset/normalize
	\| \|– _typography.scss # Typography rules
	\| ... # Etc…
	\|
	\|– components/
	\| \|– _buttons.scss # Buttons
	\| \|– _carousel.scss # Carousel

	const functions = require('firebase-functions');
	const gcs = require('@google-cloud/storage')();
	const sharp = require('sharp')
	const _ = require('lodash');
	const path = require('path');
	const os = require('os');

	exports.generateThumbnail = functions.storage.object('uploads/{imageId}').onChange(event => {

	const object = event.data; // The Storage object.