Plurrrr

a tumblelog
home

Swift’s closure capturing mechanics

Closures are an increasingly important part of Swift, both in terms of the overall direction of the language itself, and when it comes to the ways that both Apple and third party developers design libraries and APIs using it. However, closures also come with a certain set of complexities and behaviors that at first can be quite difficult to fully grasp — especially when it comes to how they capture values and objects from their surrounding context in order to perform their work.

Source: Swift’s closure capturing mechanics, an article by John Sundell.

Mallard couple

On the way back to home I took a photo of a mallard couple, Anas platyrhynchos.

Mallard couple
Mallard couple, Anas platyrhynchos. Female left, male right. In the back an Eurasian coot, Fulica atra.

The Shapes of Code

Every piece of code we write is unique, or pretty much. However, there are things that are common in a lot of code, even across various codebases, and even across various languages: the physical shape that code has.

Beyond the mere visual aspect of code, the shape of a piece of code can carry information by itself. Being able to decipher this information allows to glean indications about the code at a glance, even before starting to read it. This information is valuable in itself, and afterwards during the reading of the code itself.

Source: The Shapes of Code, an article by Jonathan Boccara.

Why I went back working on 24-inch screen from a 32-inch screen

This is a guide that I wish I have had when I was buying a 4k 32-inch screen “to be more productive”. If you are using macOS and think about buying a 4k monitor for office or programming work, this article might be useful to you.

For me, it turned out that the new, expensive monitor made me less productive even after a month of using it.

Source: Why I went back working on 24-inch 1080p screen from a 32-inch 4k screen, an article by Iwan.

Beyond TDD: breaking the rules

Rules are made to be broken, right? TDD is a strict set of rules that define a process for building software. But experienced practitioners have moved beyond the rules and work towards something else entirely.

Source: Beyond TDD: breaking the rules, an article by Daniel Irvine.

Correct sRGB Dithering

This is a brain-dump inspired by a thread on twitter about correct™ dither in sRGB, meaning, to choose the dither pattern in such a way as to preserve the physical brightness of the original pixels. This is in principle a solved problem, but the devil is in the details that are easily overlooked, especially when dithering to only a few quantization levels.

Source: Correct sRGB Dithering, an article by Christian Schüler.

A visit to Rotterdam

In the morning we left for Rotterdam. We took the bus to the train station in Schiedam and took the train to Rotterdam Blaak.

Cube houses, Rotterdam Blaak
Cube houses, Rotterdam Blaak.

We took several photos of the well-known buildings near the station, which looks like a wilted sunflower. After a visit to the market and the Markthal; a covered market, we paid a visit to the second book store "De Slegte", from which I took the photo below.

An overview of Rotterdam Blaak
An overview of Rotterdam Blaak.

In the above photo you can see from left to right: the library, the Blaak tower ("the pencil"), the cube houses, the train station ("the sunflower"), and Markthal. In front of those you can see the market.

Haskell Problems For a New Decade

At the turn of the century, the mathematician David Hilbert laid out 23 problems for mathematicians to solve in the 19th century. These were the Big Hairy Audacious Goals (BHAG) for the program of mathematics at the time, problems that drove forward progress and were exciting, adventurous areas to work in. Haskell has always been at the frontier of what is possible in computer science, and it also sustains a devoted community that regularly drags the future into the present. This can’t be done without the people who dare to dream big and build toward ambitious projects.

Here I am proposing a set of ambitious problems for the next decade:

Read the list of problems in Stephen Diehl's article Haskell Problems For a New Decade.

Emacs - Productivity Tricks/Hacks

In the past, I have written about using Emacs as a C++ IDE, and some other stuff. However, I did not realize that I have been using Emacs for many other things. To be brutally honest, I would not have enjoyed using Emacs anywhere nearly as much if it wasn’t for the features listed here. So, I decided to cover some of them. I will provide the configs that I have used to get them to work out of the box on my setup (as in, by literally copying from .emacs)

Source: Emacs - Productivity Tricks/Hacks, an article by Manoj Rao.

Hypermodern Python: Typing

In this fourth installment of the Hypermodern Python series, I’m going to discuss how to add type annotations and type checking to your project.

Source: Hypermodern Python Chapter 4: Typing, an article by Claudio Jolowicz's.

Why Learn AWK?

Because of the arcane syntax? Because other languages can’t do the job?

No.

I resisted AWK for a long time. Couldn’t I already do everything I needed with sed and grep? I felt that anything more complex should be done with a “real” language. AWK seemed like yet-another-thing to learn, with marginal benefits.

Read on in Jonathan Palardy's Why Learn AWK?.

The CSS Cascade

The CSS Cascade is one of the most powerful parts of CSS. But it can also be very frustrating, if not well understood. Anyone who’s worked on a large enough website has complained "Why won’t this CSS property work?!" And we’ve all been tempted to throw an !important to strong-arm things into place.

To save ourselves from future angst, let’s take a step back and learn this thing for real.

Source: The CSS Cascade, an article by Amelia Wattenberger.

Why do we fall into the rewrite trap?

One of my favorite reads is Joel Spolsky's Things You Should Never Do. He wrote this post almost twenty years ago, outlining the downfall of Netscape and others because they spent years rewriting working code. His solution is, unsurprisingly, to refactor. About a year before Joel wrote Things You Should Never Do, Martin Fowler published his popular book, Refactoring: Improving the Design of Existing Code.

So, my question is, if we as a community figured out — twenty years ago — that we should stop rewriting programs, why is it still commonly done today?

Source: Why do we fall into the rewrite trap?, an article by Justin Fuller.

curl cheat sheet refresh

Several years ago I made a first version of a “curl HTTP cheat sheet” to facilitate the most common curl command line options when working with HTTP.

This has now been refreshed after I took lots of feedback from friends on twitter, and then worked on rearranging the lines and columns so that it got as compact as possible without sacrificing readability (too much).

See curl cheat sheet refresh for Daniel Stenberg's cheat sheet.

Go: Reduce function parameters

Typically you don’t want functions that take a lot of parameters, and though there’s no magic number for how many is “too many”as it depends a bit on what the function is doing. But when you have a function that takes many parameters, there’s a good chance that the function is not exactly “Single Responsibility” and is doing too much.

Source: Go: Reduce function parameters, an article by Dylan Meeus.

A Sober Look at Bayesian Neural Networks

Proponents of Bayesian neural networks often claim that trained BNNs output distributions which capture epistemic uncertainty. Epistemic uncertainty is incredibly valuable for a wide variety of applications, and we agree with the Bayesian approach in general. However, we argue that BNNs require highly informative priors to handle uncertainty. We show that if the prior does not distinguish between functions that generalize and functions that don’t, Bayesian inference cannot provide useful uncertainties. This puts into question the standard argument that “uninformative priors” are appropriate when the true prior distribution is unknown.

Source: A Sober Look at Bayesian Neural Networks, an article by Jacob Buckman.

Iron Gold

In a fearsome new world where Obsidian pirates roam the Belt, famine and genocide ravage Mars, and crime lords terrorise Luna, it's time for Darrow and a cast of new characters from across the solar system to face down the chaos that revolution has unleashed.

In the evening I started in Iron Gold, the fourth book in the Red Rising series by Pierce Brown. I read the first 3 books some time ago so it took me some effort to get into this book. From the previous three I liked the first book, Red Rising, the most.

Stone Chairs and Egyptian Geese

Ever since she spotted the stone chairs from the bus in Delft, Alice wanted to sit in one. And today, when she left school she had the opportunity.

Alice sitting in a stone chair
Alice sitting in a stone chair.

I saw two Egyptian geese standing near the edge of a small canal. I used my iPhone 5 to take a few photos.

Egyptian geese, Alopochen aegyptiaca
Egyptian geese, Alopochen aegyptiaca.

How to decide what to work on next

Many people manage their tasks using a to-do list. Everything they need need to work on at some point ends up on that list, and they measure their productivity by looking at the number of tasks completed in a certain amount of time. While I’m a big fan of checklists—which have a clear objective—I don’t think to-do lists should be managed the same way a shopping list would. It’s great to have a place to dump all your tasks in, but how do you decide what to work on next?

Source: How to decide what to work on next, an article by Anne-Laure Le Cunff.

Sunset near Delft

On our way home from Delft, Alice and I admired a beautiful sunset from the bus.

Sunset near Delft
Sunset near Delft.