Good morning(?)!

There's been some noise recently regarding Google's AMP. Well Microsoft's Bing is also adding support for AMP. *Opens bag of popcorn.

And with that, let's get to our articles!

Articles

(Sep 17) #css

One major issue writing CSS at scale is its difficulty in maintenance. At some point down the road, figuring out what each CSS class does requires backtracking from the page source to the CSS code to the dependant parts of that CSS code. As the page grows, this becomes even more evident. This is where Modular CSS comes in. Modular CSS is a set of guidelines that have been implemented by a few frameworks that we've featured in the past like BEM. In this in-depth article by Scott Vandehey we learn what are the key elements of a modular CSS and how they are fulfilled by a number of frameworks.



(Aug 21) #python #blockchain

Are blockchains still a thing? Assuming they are, Robin Raymond has started a series of articles that go from scratch to state-of-the-art. In this first part we take a look at how to implement a very basic blockchain. The author explains each element of the design and by the end we have a fully functional blockchain.



(Aug 28) #databases

In this final post on the series "How We Made Joins 23 Thousand Times Faster" author Marios Trivyzas of Crate.IO talks about the final touches on CrateDB to take the database to the world of distributed databases. In particular, the article explains in-depth the two main approaches they investigated, namely the locality approach and the modulo distribution approach, and the reasoning behind their decision.



Weekend Reading

Promises

Last Weekend Reading we looked into Closures and how they compare to anonymous functions. Like mentioned, they are used extensively in JavaScript and other languages particularly when dealing with asynchronous code.

One common pattern in asynchronous code is callbacks. They are very simple to implement as seen by the following example:

// define a function that accepts a callback function example(callback) { // do something and call the callback callback(someValue) } // call the function and pass an anonymous function as a callback example(function (someValue) { // do something });

As simple as this is, it comes with many drawbacks. For one, it's incredibly easy to have multiple levels of nesting to the point that you lose track of where you are.

function computeTheAnswerToEverything(callback) { // Very long process that takes 7.5 million years to compute callback(42); } function addTwo(num, callback) { callback(num+2) } function print(value) { console.log(value); } // Ugly part goes here computeTheAnswerToEverything(function (answer) { addTwo(answer, function(value) { print(value) }) })

(example taken from StackOverflow)

This is one of the issues that promises solve. Another one is error handling. Can you imagine being 4 levels deep and getting an error in one of those levels? It's almost like you HAVE to write spaghetti code!

Here is the above code using promises with error handling:

function computeTheAnswerToEverything() { return new Promise(function(resolve, reject) { // Very long process that takes 7.5 million years to compute resolve(42); }); } function addTwo(num) { return new Promise(function(resolve, reject) { resolve(num+2); }) } function print(value) { console.log(value); throw "Example error to show Error Handling"; } // Beautiful code goes here computeTheAnswerToEverything() .then(addTwo) .then(print) .catch(function (e) { console.error(e); })

As you can clearly see, using Promises is a lot more readable and removes a lot of the boilerplate of callbacks.

Side note: While researching Promises, I noticed that different languages use different terminology and it can get a little confusing. I'll focus on the most obvious one: Futures and Promises.

The distinction was first defined in the 70s and later popularized by Java. Its purpose is to decouple the value (which will be set at some point in the future) and its computation (which promises to return a value). While this distinction is very sublte, we'll see later where this matters. But as far as we are concerned, many modern languages are now ditching the Future term in favor of a unified Promise term that encompasses both concepts. Of course there's always C# to mess with us and name them Task s. Let's stick with JavaScript for now.

With that out of the way, let's define what a Promise is.

A Promise is an object that will eventually return either a value or an error.

Crucially, a Promise stores the value when its computed and any consecutive calls will not result in any further computations. Instead, the value is returned immediately. A promise that has not been executed yet is in its Pending state. Conversely, when it has been executed, it can either be in its Fufilled state, when a value was computed with no issues, or Rejected state otherwise.

The fact that Promises have state solves one particularly annoyance with callbacks: what if the value has been computed before we had the chance to set our listeners? Without promises we need to check for that case prior to listeners while with promises there is no special handling.

So we can chain promises, handle errors elegantly and remember the value, what else is there? There are many more to them, like using Promise.all to wait on multiple computations, but I'll stop here. You can read more in-depth articles in the list below.

Next week we'll take a look at async await which, in JavaScript, use Promises under the hood.

Sources/Further Reading

Programming language of the day: Panda."Panda is a lightweight and powerful programming language written in Java. PERFORMANCE Panda is fast and lightweight. Write without loss of performance. CUSTOMIZABLE Customize Panda to your needs. The flexible system will allow you to do everything. POSSIBILITIES Build your own language on top of the Panda framework and using multiple tools!"