Whether you’re preparing for an interview or you want to design a distributed/microservice oriented application, this list will definitely help you achieve that.

Jonas Lundberg:

Hands on tips for learning a new codebase within a short time frame enough to be able to say: “Steve’s legacy ends here. I’ll figure it out.”

This is a great piece filled with actionable details and particulars.

These iconic, low-resolution designs are the perfect tool to learn the basics of physical interface design. Armed with 52 different bricks, let’s see what they can teach us about the design, layout and organisation of complex interfaces.

Stephanie Morillo:

Developers encounter technical writing everywhere: product & API docs, manpages, tutorials & more. We know it matters but what is technical writing exactly? And how does it differ from other writing?

In this brief post, I define what technical writing is, provide examples of technical writing in software and beyond, and explore other skills technical writers must develop to create successful and effective documentation.

Lane Wagner:

I built a new go Playground that uses Web Assembly to run Go code right in the browser. One of the cool things about this is is that it made it way easier to build a secure server execution environment because the server doesn’t execute anything, it just compiles.

If you’re using and loving Zeno Rocha’s dark mode theme, you might be interested in pairing it with a dark mode wallpaper. These were created by Dracula user kajwski and collected by Zeno for easier sharing.

Peter Ohler:

I had a dream. I’d write a fast JSON parser, generic data, and a JSONPath implementation and it would be beautiful, well organized, and something to be admired. Well, reality kicked in and laughed at those dreams.

This post lays out Peter’s plan, his journey, and his lessons learned in great details. Seems like it’d pair nicely with the recent Go Time all about JSON.

In a post aptly titled “Tripping over the potholes in too many libraries,” Carl Johnson explains his philosophy on using dependencies.

In short, I think it’s become entirely too easy for people using certain programming languages to use libraries from the wide world of clowns that is the Internet. Their ecosystems make it very very easy to become reliant on this stuff. Trouble is, those libraries are frequently 💩. If something about it is broken, you might not be able to code around it, and may have to actually deal with them to get it fixed. Repeat 100 times, and now you have a real problem brewing.

I have a simple rule: never use a dependency that you could replace with an afternoon of programming.

Bevy has the following design goals:

• Capable: Offer a complete 2D and 3D feature set
• Simple: Easy for newbies to pick up, but infinitely flexible for power users
• Data Focused: Data-oriented architecture using the Entity Component System paradigm
• Modular: Use only what you need. Replace what you don’t like
• Fast: App logic should run quickly, and when possible, in parallel
• Productive: Changes should compile quickly … waiting isn’t fun

Before you get too excited, a word of warning 🚨

Bevy is still in the very early stages of development. APIs can and will change (now is the time to make suggestions!). Important features are missing. Documentation is sparse. Please don’t build any serious projects in Bevy unless you are prepared to be broken by api changes constantly.

Greetings, Go devs!

I often find myself thinking that I often encounter a situation when I need to do some small prototyping (playing with goroutines, etc.) and Go’s playground often is a faster solution than a dedicated IDE window. Unfortunately play.golang.org is very primitive (goplay.space is better but not much), so I’ve decided to try to create something a bit better.

A few months ago I decided to try to create a better version of Go playground that will have a small valuable set of features that make prototyping comfortable enough, such as basic code autocomplete (stdlib only supported), syntax check, snippets and examples. Also as Go in WebAssembly trend starts to grow, WebAssembly support was added.

In addition, users can customize the editor by enabling font ligatures, selecting editor font, and some other small subset of options.

I would like to know your opinion and get some feedback. Source code here. Contribution is appreciated!

A solid interview with Steve Klabnik from the Rust core team:

We sat down with Steve to hear from him first-hand about his professional activities at the moment, the design success of Rust, a little about the “full-stack” development hype, and overcoming burnouts.

ppk muses after digesting Mozilla’s big lay off:

To my mind, Mozilla’s core problem is the cult of the free. To my mind, we should eradicate the cult of the free from web development, and Mozilla should take a small step in that direction by requesting donations from inside Firefox — on an entirely voluntary basis.

This conversation hits close to home for a few reasons here at Changelog.

First, we have plenty of friends and acquaintances who were directly affected. Second, we share concern for the future of these bastions of the web (MDN) and open source (Servo). Finally, we’re a small internet-based business that gives away almost everything we create for free and shares a business model with Mozilla.

Changelog++ might be even more integral to our survival than we’ve been thinking it is….

They’ve split the dataset up into two bundles:

1. Lite, which you can download w/ a click, but is limited to 25K image
2. Full, which you have to request access to and is limited to non-commercial use

This is interesting for a couple of reasons. First, it’s a great resource for anyone training models for image classification, etc. Second, it’s a nice business model for Unsplash as a startup.

Can be used as an embeddable Go library or as a language-agnostic service. Here’s their list of use cases:

With this feature set, Olric is suitable to use as a distributed cache. But it also provides distributed topics, data replication, failure detection and simple anti-entropy services. So it can be used as an ordinary key/value data store to scale your cloud application.

1️⃣ Value contributions to documentation just as much as code contributions
2️⃣ Put documentation and code in the same project repo
3️⃣ Make documentation a requirement for a merge or release milestone
4️⃣ Have a consistent contribution process for code and documentation
5️⃣ Have well-documented processes for contributing to documentation

That’s the TL;DR, but each of these is expanded upon in the article.

Musicians and developers go together like peas and carrots, Jenny. So it makes sense that techniques used by musicians to hone their skills might transfer over to software people. One of those techniques is the “masterclass”

A masterclass is a format in which musicians perform a work for an established artist and the artist then gives them feedback rather like a lesson, except that all of this happens in front of an audience.

Click through for a compelling distillation of what software teams can learn from musicians when it comes to giving and receiving feedback.

Built in Go, askgit is an open source CLI and coming soon web interface (linked above). With this tool in your toolbox, you can mine your repo for info like commit count by author on each day of the week:

SELECT
    count(*) AS commits,
    count(CASE WHEN strftime('%w',author_when)='0' THEN 1 END) AS sunday,
    count(CASE WHEN strftime('%w',author_when)='1' THEN 1 END) AS monday,
    count(CASE WHEN strftime('%w',author_when)='2' THEN 1 END) AS tuesday,
    count(CASE WHEN strftime('%w',author_when)='3' THEN 1 END) AS wednesday,
    count(CASE WHEN strftime('%w',author_when)='4' THEN 1 END) AS thursday,
    count(CASE WHEN strftime('%w',author_when)='5' THEN 1 END) AS friday,
    count(CASE WHEN strftime('%w',author_when)='6' THEN 1 END) AS saturday,
    author_email
FROM commits GROUP BY author_email ORDER BY commits

Today Mitchell Baker, CEO of Mozilla Corporation, shared news of big changes taking place at Mozilla in the wake of COVID-19. In addition to the changes noted below, Mozilla is also laying off 250 employees while it makes these changes.

…going forward we will be smaller. We’ll also be organizing ourselves very differently, acting more quickly and nimbly. We’ll experiment more. We’ll adjust more quickly. We’ll join with allies outside of our organization more often and more effectively. We’ll meet people where they are. We’ll become great at expressing and building our core values into products and programs that speak to today’s issues. We’ll join and build with all those who seek openness, decency, empowerment and common good in online life.

This internal document includes the details about the restructuring and other specifics.

I’ve reached out to Mitchell via LinkedIn messages to invite her on The Changelog for deep dive into the future of the internet. If you or anyone you might know has a direct connection to Mitchell, please pass this invitation on to her — we’d love to have her on the show.

Have you heard of the GitHub Arctic Code Vault? If not, the goal of GitHub Arctic Code Vault is to preserve open source software for future generations. Which means we need thorough docs describing how the world makes and uses software. Which I find completely fascinating!

From the GitHub Archive Program readme:

We are now also opening up the initial compilation of Tech Tree resources to community input. Inspired by the Long Now Foundation’s Manual for Civilization, the Tech Tree is a collection of technical works which document and explain the layers of technology on which today’s open-source software relies, along with works included to provide additional cultural context for the Arctic Code Vault.

From the Tech Tree readme:

What follows, which we call the Tech Tree, is a selection of works intended to describe how the world makes and uses software today, as well as an overview of how computers work and the foundational technologies required to make and use computers. The purpose of the GitHub Archive Program is to preserve open source software for future generations. This implies also preserving the knowledge of other technologies on which open-source software runs, along with a depiction of the open-source movement which brought this software into being.

A 6-step guide to pairing fonts in all sorts of sites, covering brand, legibility, common mistakes, and more.