jlong

var parser = document.createElement('a');
parser.href = "http://example.com:3000/pathname/?search=test#hash";

parser.protocol; // => "http:"
parser.hostname; // => "example.com"
parser.port;     // => "3000"
parser.pathname; // => "/pathname/"
parser.search;   // => "?search=test"
parser.hash;     // => "#hash"
parser.host;     // => "example.com:3000"

arobson

Abstraction Suggestions

Summary: use good/established messaging patterns like Enterprise Integration Patterns. Don't make up your own. Don't expose transport implementation details to your application.

Broker

As much as possible, I prefer to hide Rabbit's implementation details from my application. In .Net we have a Broker abstraction that can communicate through a lot of different transports (rabbit just happens to be our preferred one). The broker allows us to expose a very simple API which is basically:

• publish
• request
• start/stop subscription

ericelliott

Essential JavaScript Links

I no longer mantain this list. There are lots of other very comprehensive JavaScript link lists out there. Please see those, instead (Google "awesome JavaScript" for a start).

almost

In the default React Native app scaffolding you have to edit AppDelegate.m to change where it loads the code if you want to test on your device. I use the following snippet to detect if it's being compiled for Debug or Production and for the Simulator or a device. For Production it uses a copy of the code included in the bundle, for Debug on the simualtor it loads from a server on localhost and for Debug on a device it loads from a server on a given IP address.

NOTE: You need to edit YOUR-IP-HERE and change it to the IP to load the code from when in Debug mode on a device. You could use a service like ngrok to make this work from anywhere.

  NSURL *jsCodeLocation;

  // Loading JavaScript code
  #if DEBUG
    // For Debug build load from development server. Start the server from the repository root:

bethesque

When you declare a request and response using the traditional Pact DSL, ("uponReceiving" and "willRespondWith") you're building a structure that has three purposes -

1. it provides the concrete example request and response used in the tests
2. it specifies the contents of the contract which...
3. defines how to validate the the actual request/response against the expected request/response

The three different uses of this structure are hidden from you when using HTTP Pact because the mock service handles numbers 1 & 2 in the consumer tests, and the verification task handles number 3 for you in the provider tests. When using Pact in a non-HTTP scenario, there is no nice neat protocol layer to inject the code to do this for you, so you have to explicitly do each step.

The file expected_data_from_collector.rb declares an object graph using the Pact DSL. This is going to be used to create the concrete example and the contract. This could be declared inline, but for easier maintenance, and to allow the contr

tlrobinson

// give it a name so it reuses the same window
var win = window.open(null, "redux-devtools", "menubar=no,location=no,resizable=yes,scrollbars=no,status=no");

// reload in case it's reusing the same window with the old content
win.location.reload();

// wait a little bit for it to reload, then render
setTimeout(function() {
    React.render(
        <DebugPanel top right bottom left >

davidlivingrooms

Essential JavaScript Links

I use the Essential JavaScript Links list almost daily. I add to it when I find more links that I think every JS developer should know about. I want to make it easier to scan, and easier for users to suggest new links. We're going to turn it into a proper website, so...

The List has a New Home:

The Essential JavaScript Links List

Please visit there and open an issue if you have any suggestions.

wesbos

// paste in your console
    speechSynthesis.onvoiceschanged = function() {
      var msg = new SpeechSynthesisUtterance();
      msg.voice = this.getVoices().filter(v => v.name == 'Cellos')[0];
      msg.text = Object.keys(window).join(' ');
      this.speak(msg);
    };

jdforsythe

#!/bin/bash

# "master" is the name of your main branch you'll be comparing to, or you can pass the "parent" branch as an argument
# it compares against the current branch by default, but you can pass a second argument to specify a child branch

# this creates a permanent alias so you can use `git oldest-ancestor` to get the oldest ancestor of the current branch at any time

git config --global alias.oldest-ancestor '!zsh -c '\''diff --old-line-format='' --new-line-format='' <(git rev-list --first-parent "${1:-master}") <(git rev-list --first-parent "${2:-HEAD}") | head -1'\'' -'

nolanlawson

Why we dropped Lerna from PouchDB

We dropped Lerna from our monorepo architecture in PouchDB 6.0.0. I got a question about this from @reconbot, so I thought I'd explain our reasoning.

First off, I don't want this post to be read as "Lerna sucks, don't use Lerna." We started out using Lerna, but eventually outgrew it because we wrote our own custom thing. Lerna is still a great idea if you're getting started with monorepos (monorepi?).

Backstory:

• https://pouchdb.com/2016/01/13/pouchdb-5.2.0-a-better-build-system-with-rollup.html