jamestalmage

1. Smoker

   • Old Country BBQ Pits Insulated Gravity Fed

2. Control Unit

   • My Choice - Fireboard 2 Drive.
     • Base unit comes with everything you need, including two food probes.
     • Internal battery that will power the unit and fan for most day-of cooks.
     • Wifi / Cloud Connectivity - See/control what's going on from anywhere.
     • Predictive cooks, provides a guess as to when the food will be done. Can't speak to the accuracy.

• Programmable cooks, option to automate the entire cook.

jamestalmage

	babel.transform(`foo()`, {
		plugins: [
			function () {
				return {
					visitor: {
						CallExpression() {
							console.log('plugin 1');
						}
					}

jamestalmage

Full Disclosure: I'm a member of the AVA team

Q: How much faster is AVA than Mocha (tap, tape, ...).

A: It depends.

First things first:

I should start by saying there are lots of reasons to choose AVA, and I don't think speed is (necessarily) the most import one. Other good reasons include:

jamestalmage

Full Disclaimer: I am a member of the AVA team

Between babel-plugin-espower#12 and ava#466 we are starting to see some pretty good performance compared to mocha:

I used emoji-aware for the benchmarks, it's a real life test suite with 4,300+ tests. It's a good candidate for benchmarking the efficiency of AVA's test Runner because:

1. All the tests are synchronous. AVA is at an incredible advantage when it comes to async tests. If your tests need to interact with the disk or network, then AVA is almost guaranteed to be faster - simply because it allows concurrent execution of tests.
2. 1 or 2 simple assertions per test. (The goal of this exercise was to measure test runner performance, not assertion libraries).
3. Multiple test files. This allows AVA to flex it's process forking muscle.
4. Lots of tests per file. Even with the multi-proces

jamestalmage

// code
require('time-require')
require('bluebird')

// output 
Start time: (2016-01-02 00:25:23 UTC) [treshold=1%]
 #  module                                          time  %
 1  pretty-ms (node_modules/pretty-ms/index.js)      1ms  ▇ 2%
 2  ansi-styles (node_modu...tyles/ansi-styles.js)   1ms  ▇ 2%
 3  strip-ansi (node_modul.../strip-ansi/index.js)   1ms  ▇ 2%

jamestalmage

TAP version 13
    # Subtest: (unnamed test)
    1..1
    ok 1 - should be equal
ok 1 - (unnamed test) # time=10.216ms

1..1
# time=36.141ms

jamestalmage

@bcoe @novemberborn The self-coverage stuff is actually a pretty interesting profiling tool when used in conjunction with npm link. Since we automatically use index.covered.js if it exists, we can get a better idea how our code behaves IRL. All these screenshots were generated running the AVA test suite:

Comparing runs with an empty cache, vs ones with a complete cache

First run, no cache hits:

We can see that out of 50 forked processes, it only becomes necessary to create an instrumenter in 3 of those processes (meaning that 47 forked processes simply pulled from the cache - even on the first run). This makes sense with the speedups I am seeing. You still get the majority of the benefit from caching even on your first run. The second run may be faster, but imperceptibly so.

jamestalmage

Why

Doing require extensions correctly is essential, because:

1. Users should be able to install multiple extensions in succession, and have them work together.
2. Coverage tools like nyc need it to reliably supply coverage information that takes into account sourcemaps from upstream transforms.
3. Because non-standard, un-predictable behavior causes hard to solve bugs, and major headaches for project maintainers.

What is a require extension anyways?

jamestalmage

Keybase proof

I hereby claim:

• I am jamestalmage on github.
• I am jamestalmage (https://keybase.io/jamestalmage) on keybase.
• I have a public key whose fingerprint is 4C25 E7D2 DFC7 25E1 D148 BB6E FE57 771B 3E74 787A

To claim this, I am signing this object:

jamestalmage

https://www.firebase.com/blog/2015-10-07-how-to-keep-your-data-consistent.html

function fanoutPost({ uid, followersSnaphot, post, postId }) {
  // Turn the hash of followers to an array of each id as the string
  var followers = Object.keys(followersSnaphot.val());
  var fanoutObj = {};
  // write to each follower's timeline
  // Correction: I think it needs something like this:
 followers.forEach((key) => fanoutObj['/timeline/' + key + '/' + postId] = post);