VictorTaelin

async/await is just the do-notation of the Promise monad

CertSimple just wrote a blog post arguing ES2017's async/await was the best thing to happen with JavaScript. I wholeheartedly agree.

In short, one of the (few?) good things about JavaScript used to be how well it handled asynchronous requests. This was mostly thanks to its Scheme-inherited implementation of functions and closures. That, though, was also one of its worst faults, because it led to the "callback hell", an seemingly unavoidable pattern that made highly asynchronous JS code almost unreadable. Many solutions attempted to solve that, but most failed. Promises almost did it, but failed too. Finally, async/await is here and, combined with Promises, it solves the problem for good. On this post, I'll explain why that is the case and trace a link between promises, async/await, the do-notation and monads.

First, let's illustrate the 3 styles by implementing

oxyflour

// a typescript implement of hindley-milner type inference
// reference http://smallshire.org.uk/sufficientlysmall/2010/04/11/a-hindley-milner-type-inference-implementation-in-python/

/// <reference path="./lib.es6.d.ts" />

// ...
interface AstNode {
}

class Id implements AstNode {

OlegIlyenko

In this gist I would like to describe an idea for GraphQL subscriptions. It was inspired by conversations about subscriptions in the GraphQL slack channel and different GH issues, like #89 and #411.

Conceptual Model

At the moment GraphQL allows 2 types of queries:

• query
• mutation

Reference implementation also adds the third type: subscription. It does not have any semantics yet, so here I would like to propose one possible semantics interpretation and the reasoning behind it.

KonTrax

#### ALL CLASSES
# Unsorted at the moment
|===========================|======|==================|====================|=================|========|==================|
|           CLASS           | TYPE |    ATTRIBUTES    |     PROPERTIES     | FONT.PROPERTIES | LAYERS | LAYER.PROPERTIES |
|===========================|======|==================|====================|=================|========|==================|
| auto_complete             |      |                  | row_padding        |                 | layer0 | tint             |
|                           |      |                  | dark_content       |                 |        | opacity          |
|---------------------------|------|------------------|--------------------|-----------------|--------|------------------|
| auto_complete_label       |      |                  | fg                 |                 |        |                  |
|                           |      |                  | match_fg           |                 |        |                  

KonTrax

Sublime Text Cheat Sheet

Jeff Miller, 23 January 2013

Useful URLs

• Latest developer builds
• Official documentation
• Unofficial documentation
• Code Folding tutorial
• Package Control packages

gregoryyoung

Greg's Stop Loss Kata

Testing is very hard when time is involved ...

A trailing stop loss is a term used in financial trading. For a very in depth explanation you can read here http://www.investopedia.com/articles/trading/03/080603.asp and http://en.wikipedia.org/wiki/Order_(exchange)#Stop_orders

However we do not need a huge amount of background in order to do the kata as we are going to limit the problem a bit.

The general idea is that when you buy into a stock at a price say $10. You want it to automatically get sold if the stock goes below $9 (-$1). If we use the term "trailing" that means that id the price goes up to $11 then the sell point becomes $10.

gregoryyoung

Value objects are an important concept in DDD. This kata is made both to learn value objects and to learn better ways of testing.

Write a probability value object. It should contain the following methods:
   Probability CombinedWith(Probability)
   Probability InverseOf()
   Probability Either(Probability)

if you forget your probability math:
   Either:P(A) + P(B) - P(A)P(B)
   CombinedWith: P(A)P(B)

gregoryyoung

OK so now you have implemented the kata. Your tests should look something like this:

We can say that the tests define the object "in a calculus of itself". They are not state based tests, they define how the behaviours of the object interact with each other.

To see the real value of this let's introduce some change ... I hear real system's do this occasionally. Because this is a high performance system decimal math is too slow. You now need to use floats instead. 

Need help on floating point math? Check out: http://www-users.math.umd.edu/~jkolesar/mait613/floating_point_math.pdf

You will need to use a non-exact equality... How will this change your code?