Interesting new product (Beta) from the Puppet folks:
Project Nebula automates continuous deployment of applications to multiple cloud-native targets. Our objective is to dramatically simplify continuous deployment of cloud native applications and infrastructure by composing the tools and workflows your developers already use into simple, repeatable deployment workflows.
Brad Westfall from React Training on why the React hook useEffect(fn, ) is not the same as componentDidMount():
When developers start learning hooks having come from classes, they tend to think “I need to run some code once when we mount, like how componentDidMount() works. Ah, I see that useEffect with an empty dependency array does just that. Okay I know how all this works…”
This way of thinking gets us into trouble in a few ways:
They’re actually mechanically different, so you might not get what you expect if consider them the same (which we talk about below).
Thinking in terms of time, like “call my side effect once on mount” can hinder your learning of hooks.
Refactoring from classes to hooks will not mean you simply replace your componentDidMount’s with useEffect(fn, ).
99 second hand smartphones are transported in a handcart to generate virtual traffic jam in Google Maps. Through this activity, it is possible to turn a green street red which has an impact in the physical world by navigating cars on another route to avoid being stuck in traffic.
Until now, the standard for all mobile development at Shopify was native mobile development. We built mobile tooling and foundations teams focused on iOS and Android helping accelerate our development efforts. While these teams and the resulting applications were all successful, there was a suspicion that we could be more effective as a team if we could:
adopt a reactive programming model across all client-side applications
consolidate our iOS and Android development onto a single stack.
As a React (Native) Developer (although I’ve been dabbing more PHP lately; ahem!) I can only applaud this move. Good to see Shopify move to React Native, with the explicit intention of making core contributions along the way.
There are plenty of opportunities for friction in the user experience when logging in, particularly while entering a two factor authentication code. As developers we should be building applications that support the need for account security but don’t detract from the user experience. Sometimes it can feel as though these requirements are in a battle against each other.
In this post we will look at the humble <input> element and the HTML attributes that will help speed up our users’ two factor authentication experience.
The final markup to trigger the correct keyboard and have the browser autocomplete the received SMS code is this:
Coming to the next version of ArcGIS is the “Spilhaus projection”:
In September and October of 2018, three maps went viral on social media and the web. All of them had the same perspective, featured oceans as the main focus, and presented the oceans as one body of water. The maps were based on the so-called “Spilhaus projection” and centered on Antarctica. Though it has recently gained some popularity online, this projection is not new. Many articles recognize Athelstan F. Spilhaus, a South African-American geophysicist and oceanographer, as the author of this projection back in 1942.
Over at the ArcGIS blog they outline the history and how they’ve implemented it in their next version (ArcGIS Pro 2.5 / ArcGIS 10.8).
When watching a diff that contains a lockfile (say: a yarn.lock for example) on GitHub, GitHub doesn’t always show the differences (see screenshot above) as the changes in such files tend to be quite big. And even if it were to show the changes, does one really take a close look into it? With this in mind, Liran Tal started playing around to create a vector of attack using those lock files.
Take this diff for example:
What becomes clear when you look closer, is that I replaced the original ms npm package to resolve it with my own version, which is stored in my GitHub repository. I should have gotten it from the official npm registry, just as was originally set in the lockfile of the project.
When this pull request gets merged, I inject my malicious version of [email protected] into the code in order to control its behavior during runtime.
In this way, I could introduce a backdoor, alter the logic of the ms module or I could run some postinstall scripts.
To prevent such commits from being merged, you can resort to lockfile-lint which will warn you for such issues.
As an end-user it’s wise to run npm install with --ignore-scripts.