Yay! Rasmus Andersson recently added Thin and Light weights to Inter UI.

"Inter is a typeface specially designed for user interfaces with focus on high legibility of small-to-medium sized text on computer screens." It's the most similar typeface I've found to Apple's San Francisco. The best part? It's open source and free. You can find it on GitHub.

Take a look at the samples.

Last month, I had a conversation with Antonio García Guerra, who recently finished his PhD at the University of Oxford on nanotechnology applied to medicine. It was inspiring to hear about the physical, emotional, and informational activities that balance his life.

I'm surprised all of the faces and license plates are there. No blurring. I found this to be a great source of procrastination. Consider yourself warned.

Browse the image here.

Listen to Craig Long on how life is in the moments you didn't expect, quieting your inner intensity, helping others achieve complex goals when they don't know where to start, remote working, and disconnecting from technology.

If you're enjoying the show and want to share it with your friends, take a look at How you can spread the word.

Here are my highlights of Deep dive into Electron’s main and renderer processes by Cameron Nokes.

[Each of these processes is] an operative system level process, or as Wikipedia puts it "an instance of a computer program that is being execute."

[…] Each of these processes run concurrently to each other. […] [M]emory and resources are isolated from each other. […] The two processes don't share memory or state.

Why multiple processes?

Chromium runs each tab in a separate process so that if one tab runs into a fatal error, it doesn't bring down the entire application. […] "Chromium is built like an operative system, using multiple OS processes to isolate web sites from each other and from the browser itself."

Main process

[I]s responsible for creating and managing BrowserWindow instances and various application events. It can also register global shortcuts, creative native menus and dialogs, respond to auto-update events, and more. Your app's entry point will point to a JavaScript file that will be executed in the main process. A subset of Electron APIs are available in the main process, as well as all Node.js modules. The docs state: “The basic rule is: if a module is GUI or low-level system related, then it should be only available in the main process.” (Note that GUI here means native GUI, not HTML based UI rendered by Chromium). This is to avoid potential memory leak problems.

Renderer process

The render process is responsible for running the user-interface of your app, or in other words, a web page which is an instance of webContents. All DOM APIs, Node.js APIs, and a subset of Electron APIs are available in the renderer. […] [O]ne or more webContents can live in a single window […] because a single window can host multiple webviews and each webview is its own webContents instance and renderer process.

See this Venn diagram of Electron (provided by the source).

How do I communicate between processes?

Electron uses interprocess communication (IPC) to communicate between processes—same as Chromium. IPC is sort of like using postMessage between a web page and an iframe or webWorker […] you send a message with a channel name and some arbitrary information. IPC can work between renderers and the main process in both directions. IPC is asynchronous by default but also has synchronous APIs (like fs in Node.js).

Electron also gives you the remote module, which allows you to, for example, use a main process module like Menu as if it were available in the renderer. No manual IPC calls [are] necessary, but what's really going on behind the scenes is that you are issuing commands to the main process via synchronous IPC calls. (These can be debugged with devtron.)

Can I make something work in both the main and renderer?

Yes, because main process APIs can be accessed through remote, you can do something like this:

const electron = require('electron');
const Menu = electron.Menu || electron.remote.Menu;

//now you can use it seamlessly in either main or renderer

console.log(Menu);

(See the full thing.)

Afternoons can be dangerous time to be a patient.

Something happens in the TROUGH that makes it FAR MORE PERILOUS than any other time of the day!

• You are 3x more likely to receive a potentially fatal dose of anesthesia.
• You are more likely to die within 48 hours of surgery.
• More cancerous growths go undetected.
• Internists are 26% more likely to prescribe unnecessary antibiotics for viral infections.
• Staff are 10% less likely to wash their hands before treating patients.

Sourced from Hospital of Doom, When: The scientific secrets of perfect timing

I learned about Renée because of her illustration for the New York Times microservice golang library, gizmo.

Apple seems highly committed for all of its users to opt in with their automatic updates model. I can see the benefits and the reasons but the amount of offerings to "Turn Automatic Updates On" seems a bit excessive.

To automatically install macOS updates in the future, including apps downloaded from the App Store, select ”Automatically keep my Mac up to date.” Your Mac will notify you when updates require it to restart, so you can always choose to install those later.

"Every decision you make taxes your brain."

"Imagine watching a 3D hologram of a live soccer game on your living room table; you can walk around with an Augmented Reality device, watch the players from different viewpoints, and lean in to see the action up close¹." Well, now this might be a way to "get rid" of television as we know it.

We present a system that transforms a monocular video of a soccer game into a moving 3D reconstruction, in which the players and field can be rendered interactively with a 3D viewer or through an Augmented Reality device. At the heart of our paper is an approach to estimate the depth map of each player, using a CNN that is trained on 3D player data extracted from soccer video games. We compare with state of the art body pose and depth estimation techniques, and show results on both synthetic ground truth benchmarks, and real YouTube soccer footage.

This is a paper from Konstantinos Rematas², Ira Kemelmacher-Shlizerman²³, Brian Curless², and Steve Seitz²⁴.

Open the PDF.

A while ago, I added a list of books I've read (and highly recommend) to my Library. Today I'm starting a list of books I'd like to read next.

• Farsighted by Steven Johnson
• Thinking, Fast and Slow by Daniel Kahneman
• The Coddling of the American Mind¹ by Greg Lukianoff and Jonathan Haidt
• The Laws of Simplicity by John Maeda

Let me know of any other good reads you know.

Here's a note on how to display dialogs, alerts, and notifications on macOS with AppleScript, useful to automate day-to-day tasks you do with your machine, or even create complex programs.

(To the uninitiated, you would run this code by opening the AppleScript Editor (on macOS), pasting the code there, and hitting run.)

Dialog and Alert¹

display alert "This is an alert" buttons {"No", "Yes"}
if button returned of result = "No" then
    display alert "No was clicked"
else
    if button returned of result = "Yes" then
        display alert "Yes was clicked"
    end if
end if

System notification

display notification "Have a simple day!"

A short-form piece on the pros and cons of engaging with tasks as they come. What's your take on doing things as they happen versus processing later, in batches?

This summer, right before leaving Cambridge, I was extremely lucky to interview Ben Fry for the podcast at Fathom Information Design, in Boston, Massachusetts. Ben, together with Casey Reas, co-created the "Processing" programming environment back in 2001 (that's seventeen years ago), an open-source tool still in active development and used daily by thousands of designers, artists, researchers, engineers, students, and professionals from a wide variety of disciplines. Processing was a side-project Ben was working on while writing his thesis on Computational Information Design at the MIT Media Lab, which led him to found Fathom Information Design later on, a studio in Boston focused on understanding complicated data problems.

Listen to this episode.

After cloning a repository, you can have git not track changes you make to one (or multiple) files.

Tell Git to assume a file is unchanged

git update-index --assume-unchanged file

Tell Git not to assume a file is unchanged anymore

After this command is run, the repository continues tracking the file. It might have changes that git will want to commit.

git update-index --no-assume-unchanged file

Roll back the changes you made while the file was --assume-unchanged

In case you made changes while --assume-unchanged was on and don't want to keep the changes on the file: Roll-back to where the repository is when you want to pull or push changes.

git checkout -- file

for...of¹

const numbers = [1, 3, 100, 24];
for (const item of numbers) {
  console.log(item); // 1, 3, 100, 24
}

Sorting a list of numbers¹

let numbers = [-34, 100, 20, 2, 3, 5, 6];
numbers.sort( (a, b) => a - b ); // Ascending sort
// [ -34, 2, 3, 5, 6, 20, 100 ]
numbers.sort( (a, b) => b - a ); // Descending sort
// [ 100, 20, 6, 5, 3, 2, -34 ]

GitHub just released GitHub Actions, to "automate your workflow from idea to production." Their slogan:

Focus on what matters: code

Here are some comments by Sarah Drasner on CSS-Tricks:

Previously, there were only few options here that could help with that. You could piece together other services, set them up, and integrate them with GitHub. You could also write post-commit hooks, which also help.

[...]

Actions are small bits of code that can be run off of various GitHub events, the most common of which is pushing to master. But it's not necessarily limited to that. They’re all directly integrated with GitHub, meaning you no longer need a middleware service or have to write a solution yourself. And they already have many options for you to choose from. For example, you can publish straight to npm and deploy to a variety of cloud services, (Azure, AWS, Google Cloud, Zeit... you name it) just to name a couple.

But actions are more than deploy and publish. That’s what’s so cool about them. They’re containers all the way down, so you could quite literally do pretty much anything — the possibilities are endless! You could use them to minify and concatenate CSS and JavaScript, send you information when people create issues in your repo, and more... the sky's the limit.

You also don’t need to configure/create the containers yourself, either. Actions let you point to someone else’s repo, an existing Dockerfile, or a path, and the action will behave accordingly. This is a whole new can of worms for open source possibilities, and ecosystems.

Curious about how this all works? Take a look at CSS-Tricks tutorials:

• Setting up your first action
• Writing an action in code
• Creating a custom action

Visit GitHub Actions.

Here are some notes I took while reading GitHub's An Introduction to innersource white paper.

Organizations worldwide are incorporating open source methodologies into the way they build and ship their own software. […]

Many companies use the word “innersource” to describe how their engineering teams work together on code. Innersource is a development methodology where engineers build proprietary software using best practices.

[…]

[I]nnersource code helps your team discover, customize, and reuse existing internal projects. They can also establish and build on a shared set of documented processes to optimize the way your company deploys and uses software. This can lead to lower cost, greater flexibility, and an end to vendor lock-in.

[…]

Within an enterprise, individual developers can pursue their interests, share ideas on a level playing field, and more easily learn from their peers. However, innersource also requires a cultural shift. Your team’s culture will need to encourage knowledge sharing and welcome contributions from across your organization. […] For innersource projects, distributing control across a smaller group of participants frequently makes approvals and reviews more effective. Creating a small, cross-functional team of decision makers can also help teams stick to quality standards and gain executive support.
Adopting innersource practices is like starting an open source community within your organization. As with open source, transparent collaboration mobilizes a community’s collective knowledge and skills to create better software. An innersource community, in contrast, contains the knowledge, skills, and abilities of people and tools within a single enterprise.

Why do companies adopt it?

As businesses evolve and differentiate their products and services with software and data—or recognize software and data is their product or service—they quickly realize that traditional development methods and tooling don’t quite work. The slow, systematic practice of gathering requirements, holding meetings, and developing in silos is not in step with the pace of technology today—or even the pace of customer demands.
Innersource helps teams build software faster and work better together—resulting in higher-quality development and better documentation. It also can help companies become more efficient by:

• Making it easy to find and reuse code on a broad scale, avoiding wasted resources and duplication
• Driving rapid development, regardless of company size
• Reducing silos and simplifying collaboration throughout the entire organization—inside and between teams and functions, as well as across teams and business lines
• Increasing clarity between engineers and management, as well as anyone else who’s interested
• Creating a culture of openness, a precursor to open source participation
• Reinforcing the pride, growth, and job satisfaction felt by team members who help wherever there is a need

React Google Charts is "A thin, typed, React wrapper over Google Charts Visualization and Charts API." View the source on GitHub.