Serverless architectures are becoming increasingly popular, and with good

Serverless architectures are becoming increasingly popular, but, when using

Clustering is the general study

One of the great perks of living in the San Francisco Bay Area is proximity to some amazing wine regions. Over the last couple years, I've visited vineyards in regions like Napa Valley, Sonoma Valley, Paso Robles, and even Malibu. I recently ran into a machine learning data set that has data on 6000 Portuguese wines that includes a 1-10 quality rating, which seems like a great excuse to build a neural network that can predict the 1-10 quality rating based on factors like residual sugar and alcohol content. Effectively, this neural network attempts to match the wine palate of whoever put this data set together.

Much to many people's chagrin, the practice of asking algorithms questions in tech interviews doesn't seem like it is going anywhere. From what I've heard though, more and more companies are allowing people to answer algorithms questions in JavaScript. In this week's article, I'll walk through a common interview question, glob matching, and implement the solution in JavaScript.

Promise.prototype.finally() recently reached stage 4 of the TC39 proposal process. This means the Promise.prototype.finally() proposal was accepted and is now part of the latest draft of the ECMAScript spec, and it is only a matter of time before it lands in Node.js. This article will show you how to use Promise.prototype.finally() and how to write your own simplified polyfill.

MongoDB 3.2 introduced the $lookup aggregation framework pipeline stage, which let you pull documents from a separate collection into your aggregation framework pipeline. Before MongoDB 3.6, $lookup could only do left outer joins with equality matching. In other words, suppose you had a collection of users, a collection of stocks, and a collection that mapped users to the stocks they hold. The $lookup stage can give you an array of stocks a user holds. But in MongoDB 3.2 and 3.4, $lookup could not give you just the stocks that had gone up in price since the customer bought them.

Before MongoDB 3.6, tailing the MongoDB oplog was the only way to listen for changes to your MongoDB database. The oplog is a special collection that logs all inserts and updates that come in to your MongoDB server so other members of the replica set can copy them. Tools like Meteor and MoSQL were built on tailing the oplog. Unfortunately, the oplog was built primarily to support replication internally as opposed to being a user-facing feature. Change streams are a usability layer on top of the MongoDB oplog that make change detection in MongoDB much easier than tailing the oplog directly.