jed

How to set up stress-free SSL on an OS X development machine

One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.

Most workflows make the following compromises:

• Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.

• Use production SSL certificates locally. This is annoying

rwjblue

From a terminal run the following commands:

git clone [email protected]:emberjs/ember.js
cd ember.js
npm install
npm start

While that is running open another terminal and run the following (starting from the ember.js folder you cloned a moment ago):

Genkilabs

// app/initializers/simple-auth-config.js
export default {
  name: 'simple-auth-config',
  before: 'simple-auth',
  initialize: function() {

    var tokenEndpoint = '/users/sign_in';
    MyAppnameENV['simple-auth'] = {
      authorizer: 'simple-auth-authorizer:devise',
      crossOriginWhitelist:[

sebmarkbage

import { Component } from "React";

export var Enhance = ComposedComponent => class extends Component {
  constructor() {
    this.state = { data: null };
  }
  componentDidMount() {
    this.setState({ data: 'Hello' });
  }
  render() {

nolanlawson

// Promise.all is good for executing many promises at once
Promise.all([
  promise1,
  promise2
]);

// Promise.resolve is good for wrapping synchronous code
Promise.resolve().then(function () {
  if (somethingIsNotRight()) {
    throw new Error("I will be rejected asynchronously!");

fivetanley

(Originally taken from the Skylight "almost daily" emails, written by Tom Dale)

It was a very busy week. We spent the first three days of the week digging deep into Glimmer performance. As we've been scrambling to bring the benefits of this brand new approach to rendering to the many existing Ember apps, we inadvertently added some performance regressions while adding backwards compatibility features.

We spent many hours staring at the profiler in Chrome, trying to figure out how to optimize Glimmer's rendering performance at both the micro and macro level.

One of the biggest improvements was minimizing the number of DOM manipulations for certain cases of re-rendering an each helper in Ember. You can see more of the specific details in the commit here: https://github.com/tildeio/htmlbars/commit/64be35ef03953d80cfe4434446a01dd483bba7b0

This definitely involved busting out some rusty Computer Science skills, but it's always fun to explore algorithms and

paulirish

What forces layout / reflow

All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.

Element APIs

Getting box metrics

• elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent

tomazzaman

import fs from 'fs';
import path, { resolve } from 'path';
import assert from 'assert';
import Module from 'module';
import jsdom from 'jsdom';
import Mocha from 'mocha';
import chokidar from 'chokidar';

// Let's import and globalize testing tools so
// there's no need to require them in each test

paulirish

A few conversations have circled around user-side structural profiling. For context, see React PR #7549: Show React events in the timeline when ReactPerf is active

One particular concern is the measurement overhead. This gist has a benchmarking script (measure.js) for evaluating overhead and initial results.

Results: performance.mark()

Runs about 0.65µs per mark() call. Naturally, that's ~= an overhead of 1ms for 1500 mark()s.

CodeMyUI

<div class="page page-laser-to-text">
	<input id="input" type="text" maxlength="24" placeholder="I love you!">
	<canvas id="canvas"></canvas>
</div>