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.
On the way back to home I took a photo of a mallard couple, Anas
platyrhynchos.
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.
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.
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.
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.
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.
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.
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:
In the past, I have written about using Emacs as a C++
IDE,
andsomeotherstuff. 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)
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.
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.
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?
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).
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.
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.
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.
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.
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?
