Christopher Swasey endash

## index.html
<!DOCTYPE html>
<html>
  <head>
    <title>mask-image bug demo</title>

    <style>
      div {
        width: 24px;
        height: 24px;
      }

## testing.markdown

      
              1 file
            
          
              0 forks
            
          
              0 comments
            
          
              0 stars
            
          
                endash
                / testing.markdown
            
            
              Last active
              February 26, 2019 18:46
            
          
    Your Momma So Fat All Her Tests Are Integration Tests

No two engineers can agree what is or is not a unit test, an integration test, or an acceptance test, or the difference between them. This is one of the immutable laws of the universe. So, in the grand tradition of my craft, I'm going to stir the pot further by throwing my own take into the ring.
The key to grokking unit and integration tests, in my opinion, is not to think of them individually, as distinct things with their own definitions that can be known on their own terms. Instead, I think of them as being related by a recursive definition, holisitcally. On their face, integration tests are, intrinsically, more complex and fragile than unit tests. They combine multiple moving pieces into one. Oftentimes, they need fixtures or some encompassing test harness, or are otherwise awkwardly contorted to fit environmental constraints. It stands to reason that anything that lets us reduce the need for integration tests without sacrificing coverage is a g

  
## Parable.md

      
              1 file
            
          
              0 forks
            
          
              0 comments
            
          
              0 stars
            
          
                endash
                / Parable.md
            
            
              Created
              June 16, 2017 12:27
            
              
                The parable of the engineer and the tree house
              
          
    A man asked a novice software engineer to build him a shed. He came back the next day and saw that the engineer had poured the concrete foundation, and it looked pretty good. He came back each day, and each day the shed was looking better and better, and when it was done at the end of the week the man was quite pleased.
The next week, the man asked the engineer to build a treehouse for his kids. He came back the next day, and saw that a mass of scaffolding had been erected, some idle workers were standing around, and large plywood frames were being hoisted up into the canopy.
"What's going on here?" the man asked the engineer, in bewilderment.
"We're getting ready to pour the foundation," the engineer replied.

  
## Code Design For Managers.markdown

      
              1 file
            
          
              0 forks
            
          
              0 comments
            
          
              0 stars
            
          
                endash
                / Code Design For Managers.markdown
            
            
              Last active
              June 16, 2017 12:52
            
          
    Code Design for Managers

There is, in software development, a tension between external pressures to turn out new features and products, and the internal need to maintain high professional standards and minimize technical debt. It can be hard, from the outside, to see the business value in things like refactoring, architectural planning, high standards for code design, and the like, if they seem to extend the development timeline for some new, important piece of software. Some, like code design, might seem purely a matter of aesthetics, if it all leads to the same place, in the end. This perspective is short-sighted, and is quite often fatal or at least highly detrimental to whatever business interests were supposedly being served by undervaluing engineering professionalism.
You might be thinking: “Well, maybe code design is ultimately a subjective thing, like those godless heathens who use tabs to indent their code, or maybe only perfectionists who are impossible to please should, or do, care about it.” W

  
## gist:ad9237a3a8eae1258983
let opt: ((NSColor) -> Bool)? = nil
let nonOpt = {(aColor: NSColor) in return true }
let coalesced = opt ?? nonOpt

## gist:cbe4ae2dedafb214f6b1
let opt: ((NSColor) -> Bool)? = nil
let coalesced = opt ?? {(aColor: NSColor) in return true }

## index.html
<!DOCTYPE html>
<html>

<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
    <title>Normal Plot</title>
    <meta name="description" content="">
    <script src="http://d3js.org/d3.v3.min.js" charset="utf-8"></script>
    <style type="text/css">

## async-observables.md

      
              1 file
            
          
              0 forks
            
          
              0 comments
            
          
              1 star
            
          
                endash
                / async-observables.md
            
            
              Last active
              July 14, 2016 02:26
            
              
                Asynchronous observables in Angular 2 and their issues
              
          
    The problem

In some situations it is beneficial to force an observable to resolve subscriptions asynchronously, via use of the observeOn operator. Failing that, it is at least possible to force an observable to resolve asynchronously. The issue from an Angular perspective is that we usually want our subscribe callback to run in the Angular zone, otherwise change detection won't automatically kick off. Additionally, inside an asynchronous observer callback setTimeout does not run in the app zone, eliminating a potentially obvious solution. To code defensively, one might use NgZone.run wherever there's a possibility that an observable is async. Unfortunately, this has the knock-on effect of causing errors if the observable is not async. To prevent those errors observables can be uniformly forced async, with NgZone used in the subscribe callback, resulting in uniform, proper behaviour. These measures have a not insubstantial technical cost.
I am not presently aware of a way to ensure that cal

  
## _subscribe_decorators.md

      
              3 files
            
          
              0 forks
            
          
              0 comments
            
          
              3 stars
            
          
                endash
                / _subscribe_decorators.md
            
            
              Last active
              January 25, 2016 01:36
            
              
                Angular 2 component observable subscription decorators ***THIS IS AN EXPERIMENT/PROOF OF CONCEPT*** Feedback welcome. Note that some code may appear superfluous but is there for defensive purposes.
              
          
    Note: This implementation is based on RxJS 4.0
⚠️ potentially buggy do not use in production ⚠️
Use case

Heavy use of observables can result in many components with duplicate boilerplate code for subscribing
to an @Input observable and assigning the value(s) to another property for use in the template. This
might also involve juggling property names if you want to use the same semantic naming in both the
component's API and template. Additionally, some defensive boilerplate is necessary to guard against

  
## gist:0aefb287c6901c86ac6a
/**
 * Creates a pipe suitable for a RxJS observable:
 *
 *         @View({
 *           template: '{{ someObservable | rx}}'
 *           pipes: [RxPipe]
 *         })
 *
 * Originally written by @gdi2290 but updated for 2.0.0.alpha-35 and use AsyncPipe
 * (Soon the Angular team will be using RxJS natively and this pipe will be
	<!DOCTYPE html>
	<html>
	<head>
	<title>mask-image bug demo</title>

	<style>
	div {
	width: 24px;
	height: 24px;
	}
	let opt: ((NSColor) -> Bool)? = nil
	let nonOpt = {(aColor: NSColor) in return true }
	let coalesced = opt ?? nonOpt
	let opt: ((NSColor) -> Bool)? = nil
	let coalesced = opt ?? {(aColor: NSColor) in return true }
	/**
	* Creates a pipe suitable for a RxJS observable:
	*
	* @View({
	* template: '{{ someObservable \| rx}}'
	* pipes: [RxPipe]
	* })
	*
	* Originally written by @gdi2290 but updated for 2.0.0.alpha-35 and use AsyncPipe
	* (Soon the Angular team will be using RxJS natively and this pipe will be