jamestalmage

describe('myModule', function(){
  beforeEach(module('myModule'));
  
  /* @ngInject */
  var a, b;
  
  it('does things', function() {
     // .... 
  });
});

jamestalmage

#!/usr/bin/env bash
GEN_PASS=$(dd if=/dev/urandom bs=1 count=9 2>/dev/null | base64 | rev | cut -b 2- | rev)
echo $GEN_PASS
echo $GEN_PASS | pbcopy
GEN_PASS=0

jamestalmage

root@42474955d2f4:~/temp# npm ls -g          
/usr/local/lib
├─┬ generator-nm@1.4.0
│ ├─┬ humanize-url@1.0.1
│ │ └── strip-url-auth@1.0.1
│ ├─┬ normalize-url@1.3.0
│ │ ├── object-assign@3.0.0
│ │ ├── prepend-http@1.0.1
│ │ ├── query-string@2.3.0
│ │ └─┬ sort-keys@1.1.0

jamestalmage

npm search james.talmage | awk '{system("npm owner add jamestalmage "$1)}'

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);

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

/pattern/flags
new Regexp(pattern[, flags])

flags: g global, i ignore case, m multiline

regex.test(string) or string.search(regex) - returns true or false

regex.exec(string) - null or an array. 0 index is matched string, 1+ is captures. Maintains state for continuation searches /g flag is set.

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

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

// 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%