Inside NASA’s facility where they keep the Moon Rocks

In honour of the upcoming 50th anniversary of the first lunar landing – which launched on July 16th, 1969 – Destin from SmarterEveryDay went to the NASA facility where they keep about 70% of the Moon Rocks that were ever collected (Apollo Missions 11, 12, 14, 15, 16, and 17). The video offers us a truly amazing inside view on how the rocks are stored, manipulated, documented, etc.

Extra kudos to his guide Andrea Mosie, who speaks in such a passionate, open, and honest way about it all. It must be a joy and privilege to work with her.

💩 Did you know: In order to take all those rocks back, the astronauts left a lot of their stuff on the moon … including wastebags filled with their own poop.

In the end of the video Dustin refers to It’s Okay To Be Smart‘s video on The Genesis Rock, which is also worth your time:

The Wikipedia article on Moon Rocks is also worth a read 🙂

🚀 If you really want to go back in time you can – just like with the Apollo 17 Mission before – relive the entire Apollo 11 Mission in real-time. Included real-time elements are:

  • All mission control film footage
  • All TV transmissions and onboard film footage
  • 2,000 photographs
  • 11,000 hours of Mission Control audio
  • 240 hours of space-to-ground audio
  • All onboard recorder audio

And to say some people still think this was all a scam 😅

Apollo 11 in real-time →

Deploying multi-source sites to Netlify

Deploying one site (from a single source repo) to Netlify ain’t that hard – see my instructions here – but what if your sources are spread out across multiple repos? How do you combine the data without duplicating it into a monorepo?

That’s exactly the problem Spatie was having for their docs.spatie.be: the website holds the documentation for all of their (bigger) open source packages, but the documentation itself is not part of said repo but is stored within each project’s repository.

To solve this they first created an inventory file repositories.json. The file keeps track of each part of the documentation and its location. Using a script named fetch-content.js they aggregate all those documentation parts:

const util = require("util");
const exec = util.promisify(require("child_process").exec);
console.log('Fetching repositories...');
console.time('Fetched repositories');

const repositories = require("./repositories.json");

function transformBranchToFolderName(branch) {
    return branch.startsWith('v') ? branch.substring(1) : branch;
}

(async function () {
    let promises = [];

    for (const repository of repositories) {
        for (const [branch, alias] of Object.entries(repository.branches)) {
            const folder = `content/${repository.name}/${alias}`;
            const url = `https://codeload.github.com/${repository.repository}/tar.gz/${branch}`;

            promises.push(exec(`mkdir -p ${folder} && curl ${url} \
             | tar -xz -C ${folder} --strip=2 ${repository.repository.split('/')[1]}-${transformBranchToFolderName(branch)}/docs \
             && echo "---\ntitle: ${repository.name}\ncategory: ${repository.category}\n---" > content/${repository.name}/_index.md`));
      
        }
    }

    await Promise.all(promises);
    console.timeEnd('Fetched repositories');
})();

To build the site they first launch fetch-content.js and successively run hugo.

[build]
  command = "node fetch-content.js && hugo -b https://docs.spatie.be"
  publish = "public"

By adding webhooks which point to the same endpoint on all of the listed repos, the docs website is built whenever a commit to any of those repos is pushed.

Going serverless with Hugo and Netlify →
docs.spatie.be Source (GitHub) →

Hermes, a JavaScript engine optimized for running React Native on Android

Interesting announcement from Facebook:

Hermes is an open-source JavaScript engine optimized for running React Native apps on Android. For many apps, simply enabling Hermes will result in improved start-up time, decreased memory usage and smaller app size. At this time Hermes is an opt-in React Native feature, and this guide explains how to enable it.

Here’s a side-by-side comparison recording by @nparashuram of one and the same app . The one of the left is with Hermes, the one on the right without:

To enable Hermes, simply edit your android/app/build.gradle file and set enableHermes to true (requires React Native 0.60.2 or newer):

project.ext.react = [
    entryFile: "index.js",
    enableHermes: true  // clean and rebuild if changing
]

One cd android && ./gradlew clean later and you’re good to go 🙂

Hermes Source (GitHub) →
React Native: Enabling Hermes →

Clock Experiments by Vasilis

Vasilis had some fun and created these experimental clock interfaces.

First up is the “Decimal Clock”:

If we had ten hours in a day, instead of 24, and if each of these hours had 100 minutes instead of 60, and if every minute had 100 seconds, our clocks would look like this, and the time would be …

Decimal Clock →

~

And there’s also the “WowClock”:

All numbers are built with 24 round digits. Each digit looks like a small clock, with two hands that can turn. Every time a number changes, for instance when 13:36 turns into 13:37, the hands of all little clocks start moving until the reach such a position that their combined pattern forms the new number.

WowClock →

React: Forget about component lifecycles and start thinking in effects

Yesterday, while at a workshop, React Hooks (intro here) became the subject of discussion between participants. Someone in the audience asked how to easily map the classes+lifecycle way of thinking onto hooks, as she had trouble doing so.

In short, my recommendation was to no longer think in lifecycles but to think in effects, as useEffect was created for exactly this type of thing: when one (state) value changes something else should happen. It also provides you with cleanup methods, to perform stuff one would typically do in componentWillUnmount.

When coming home later that day I was really glad to see that Sebastian had just published a blogpost, along with a practical example, on that very same subject:

React recently introduced a new way to deal with side effects: the useEffect hook. Translating lifecycle methods to useEffect calls can be confusing at first. It’s confusing because we shouldn’t be translating imperative lifecycle methods to declarative useEffect calls in the first place.

Thanks for writing this post Seb, saved me some time from writing it myself 😉

Forget about component lifecycles and start thinking in effects →

The State of CSS 2019

Despite being over 20 years old, there’s signs that CSS might be going through the same tumultuous teenage years that JavaScript just went through. Flexbox! Grid! CSS-in-JS! In 2019, CSS is finally dyeing its hair pink and getting a tattoo just like it’s always secretly wanted.

Parenting books won’t help much with this one, but that’s where we come in: we’ve surveyed over 10,000 developers in this first ever State of CSS survey. So join us to find out which CSS features are used the most, which tools are gaining adoption, and much more.

Using the “Awareness – Interest – Satisfaction” ratio rankings, you can verify (or adapt) your choices.

The State of CSS 2019 →

Typed Properties in PHP

As mentioned before I’m really looking forward to Typed Properties that will land in PHP 7.4 (now in alpha!). Brent has done a full writeup on ‘m:

In this post we’ll look at the feature in-depth, but first let’s start by summarising the most important points:

  • They are available as of PHP 7.4, which is scheduled to be released in November of 2019
  • They are only available in classes and require an access modifier: public, protected or private; or var
  • All types are allowed, except void and callable

Typed properties in PHP →

💭 As also mentioned before, I’m missing one specific typehint: Foo[].

This typehint would tell PHP that you require a variable to be “an array of Foo‘s”. With the current typehint system that not possible: when requiring the type array, you cannot specify its contents.

And no, the variadic function syntax is not a closing solution workaround for this.

NASA: We Are Going

We are going to the Moon, to stay, by 2024. And this is how.

Must admit I got some goosebumps while watching this …