JMESPath is a query language for JSON

The JMESPath language is described in an ABNF grammar with a complete specification. This ensures that the language syntax is precisely defined.

JMESPath has a full suite of data driven testcases. This ensures parity for multiple libraries, and makes it easy for developers to implement JMESPath in their language of choice.

Each JMESPath library passes a complete suite of compliance tests to ensure they work as intended. There are libraries in multiple languages including python, php, javascript and lua.


Promises are not neutral enough

Promises in JavaScript create problems which affect the entire ecosystem. In this blog post I’ll explain some of those problems.

The way this article starts might make you imagine that it was written by someone in a grumpy state of mind who, after several hours swearing at the computer, decided to rant about it on the internet. That’s not at all the case. I was just making my morning coffee in no hurry, when someone asked me on Twitter what is my opinion on Promises. I thought about it while sipping my coffee, then wrote a couple of tweets. Some people thought it would better presented as a blog post, so here we go!

The basic purpose of Promises is to represent a value that will be eventually available. It could become available in the next event loop or in the next minutes. There are many primitives that could accomplish this same purpose, e.g. callbacks, C# Tasks, Scala Futures, RxJS Observable, etc. JavaScript Promises are one type of primitive that solve the problem of programming with eventual values.

Even though they fulfill their purpose, JavaScript Promises are an opinionated primitive that introduce a lot of weirdness. This weirdness ends up spreading to other corners of the JavaScript language and ecosystem. Basically Promises are not neutral enough because they introduce 4 opinions:

  • Eager, not lazy
  • No cancellation
  • Never synchronous
  • then() is a mix of map() and flatMap()

Chiccocoin: Learn what is a Blockchain by creating one in NodeJS

Every day on our feeds we find news about new cryptocurrency or someone who says that they are a big bubble that will soon explode and of which only the blockchain will remain. But, what is the blockchain?

By definition:

Is a continuously growing list of records, called blocks, which are linked and secured using cryptography.

So, the blockchain is an immutable, sequential chain of records called Blocks. Each block can contain transactions, files or any data you like. The important thing is that they’re chained together using hashes.

Blockchains are secure by design and are an example of a distributed computing system with high Byzantine fault tolerance. This makes blockchains potentially suitable for the recording of events, medical records, and other records management activities, such as identity management, transaction processing or voting.

Asynchronous JavaScript: From Callback Hell to Async and Await

One of the keys to writing a successful web application is being able to make dozens of AJAX calls per page.

This is a typical asynchronous programming challenge, and how you choose to deal with asynchronous calls will, in large part, make or break your app, and by extension potentially your entire startup.

Synchronizing asynchronous tasks in JavaScript was a serious issue for a very long time.

This challenge is affecting back-end developers using Node.js as much as front-end developers using any JavaScript framework. Asynchronous programming is a part of our everyday work, but the challenge is often taken lightly and not considered at the right time.

What I learned in 2017 Writing Go

A little over a year ago, I joined Cloud Foundry to work on Loggregator, Cloud Foundry’s application logging component. Its core concern is best-effort log delivery without pushing back on upstream writers. Loggregator is written entirely in Go.

After spending more than a thousand hours working with Go in a non-trivial code base, I still admire the language and enjoy using it. Nonetheless, our team struggled with a number of problems, many of which seem unique to Go. What follows is a list of the most salient problems.

A Zero-Math Introduction to Markov Chain Monte Carlo Methods

For many of us, Bayesian statistics is voodoo magic at best, or completely subjective nonsense at worst. Among the trademarks of the Bayesian approach, Markov chain Monte Carlo methods are especially mysterious. They’re math-heavy and computationally expensive procedures for sure, but the basic reasoning behind them, like so much else in data science, can be made intuitive. That is my goal here.

So, what are Markov chain Monte Carlo (MCMC) methods? The short answer is:

MCMC methods are used to approximate the posterior distribution of a parameter of interest by random sampling in a probabilistic space.

In this article, I will explain that short answer, without any math.

The Case for Learned Index Structures

Indexes are models: a B-Tree-Index can be seen as a model to map a key to the position of a record within a sorted array, a Hash-Index as a model to map a key to a position of a record within an unsorted array, and a BitMap-Index as a model to indicate if a data record exists or not. In this exploratory research paper, we start from this premise and posit that all existing index structures can be replaced with other types of models, including deep-learning models, which we term learned indexes. The key idea is that a model can learn the sort order or structure of lookup keys and use this signal to effectively predict the position or existence of records. We theoretically analyze under which conditions learned indexes outperform traditional index structures and describe the main challenges in designing learned index structures. Our initial results show, that by using neural nets we are able to outperform cache-optimized B-Trees by up to 70% in speed while saving an order-of-magnitude in memory over several real-world data sets. More importantly though, we believe that the idea of replacing core components of a data management system through learned models has far reaching implications for future systems designs and that this work just provides a glimpse of what might be possible.