Or is it already dead? The once-promising blockchain and beloved smart contract project seemed to be at the top of the world. From a high of $1431 in January 2018 to its current low of $126, it seems whatever hopes people have for Ethereum have faded quite a bit.
Despite the fact that Ethereum still holds the number two spot on Coin Market Cap Ethereum has fallen out of the limelight somewhat with developers. On State of The DApps, Ethereum accounts for only three of the top ten applications. Klaytn accounts for four of them, Steem accounts for two and NEO just one. In the top five, Ethereum only has one DApp.
Here is a nice bug-not-bug to close out in 2019. One of my Trello cards detailed what sounded like an error:
When toggling between two options (yes and no) in a dropdown, entering “y” changes to yes and quickly entering “n” does not switch to no. However, waiting a second you can change between them.
Some initial debugging suggested this was not actually a bug in our application. But, I knew if I was going to get the ticket closed off as not a bug, I had to have an explanation.
When working with mocks and spies in Jest, it is quite easy to fall into a trap where they become stale (especially in cases where pure functions are not being used). Heading to the documentation for Jest yields a lot of similar-looking methods for restoring mocks, clearing mocks and resetting mocks.
This is where confusion sets in. What is the best practice? Which ones should I call to ensure my tests don’t have stale mocks or spies? Even I struggled with this aspect.
People once thought the banking industry was too big to fail, some seriously big financial institutions ultimately proved that wrong during the Global Financial Crisis of 2008/2009 which saw many seemingly unsinkable companies go out of businesses.
Early 2019, after two deadly crashes of the allegedly bigger and better 737 MAX, the plane was grounded by countries around the world as people scrambled to find answers for what happened. After numerous investigations, the culprit turned out to be MCAS also known by its non-abbreviated mouthful of a name Maneuvering Characteristics Augmentation System.
Well, this is a pretty frustrating bug. The other day I and a few other people in my team noticed something peculiar while debugging some Javascript. The ability to hover over variables and function arguments in Chrome Developer Tools had stopped working.
At first, we thought this might have been a Webpack configuration issue or an update to one or more of our packages breaking the way in which Chrome parses our Javascript. The issue turned out to be Chrome itself. There is an issue recently created where many voice their frustration (myself included) over this bug.
In Aurelia 2, a new element called bindable has been introduced which is leveraged in HTML only custom elements. If you want a HTML only custom element which has one or more bindable properties, then you use the bindable element to specify them.
The ability to create bindables for HTML only custom elements existed in Aurelia 1, but was limited. The constraint being the bindable keyword had to be specified on the template element.
If you are already familiar with Aurelia and have worked with Aurelia 1, then HTML custom elements are not a new concept to you. If you’re starting out with Aurelia 2, they might be a new concept to you.
How HTML Only Custom Elements Looked In Aurelia 1 We have a custom element called user-info.html which accepts a user object through a bindable property called user and we display their name and email.
While Aurelia 2 is still not quite ready for release, you can use it right now as the basic core pieces are functional. I thought it would be fun to build a weather application using Aurelia 2.
If you don’t want to run through a tutorial and just want the final result, all of the code for the weather application can be found on GitHub here.
What Are We Building? In this tutorial, we are going to be building an Aurelia 2 application that displays weather information. Original, right? You will learn how to create new Aurelia 2 applications, as well as work with the OpenWeatherMap API where we will consume JSON for the information.
The front-end space over the last six years or so has really heated up, you could say superheated. As browsers become more powerful, devices continually improved and innovation a constant thing, no language is more popular and widely used than Javascript.
And yet, as learning resources have become more easily accessible and coding boot camps have become a thing, newcomers are being taught to lean on frameworks and libraries straight out of the gate.
Staunch functional proponents will fire up at the mere mention of classes or any form of object-oriented programming. These arguments go way back to before Javascript was even a thing or as popular as it is now.
Let’s clear the air and point out that classes in Javascript are not real classes. They’re often compared to the likes of Java and other languages that promote OOP-style programming, but classes in JS are unlike those implementations. Javascript has prototypes and prototypes are not classes.