Bound version constraints (upper caps) are starting to show up in
the Python ecosystem. This is causing real world
libraries following this recommendation, and is likely to continue
this practice does not scale to large numbers of libraries or large
numbers of users. In this discussion I would like to explain why
always providing an upper limit causes far more harm than good
even for true SemVer libraries, why libraries that pin upper
limits require more frequent updates rather than less, and why it
is not scalable. After reading this, hopefully you will always
consider every cap you add, you will know the (few) places where
pinning an upper limit is reasonable, and will possibly even avoid
using libraries that pin upper limits needlessly until the author
updates them to remove these pins.
Out of the many attacks that threaten web applications today,
XXE remains the one that is talked about the least. Although it
gets far less attention than
it does carry its own risk and should not be taken as a slight.
Lossless compression is the act of making a dataset smaller than its
original form while still being able to transform the compressed
version back into the original source material. This contrasts lossy
compression which produces a derivative dataset that, while being
something humans can appreciate, cannot recreate the original source
This post is about how and why my multiplayer card game GALGA uses a
Free Monad DSL for its game rules. If that’s gobbledygook to you,
read on and hopefully it’ll make at least a little more sense by the
In the process of switching my shell to Haskell, I also got a lot
faster at writing Haskell. Haskell is now the primary interface
through which I use my computers, and it has been very pleasant. I
no longer have to deal with regexes, since I can whip out a full
parser combinator library any time.
Very often, making code easy to unit test tends to go hand-in-hand
with improving that code’s separation of concerns, its state
management, and its overall architecture. In general, the more
well-abstracted and organized our code is, the easier it tends to be
to test it in an automated fashion.
However, in an effort to make code more testable, we can very often
find ourselves introducing a ton of new protocols and other kinds of
abstractions, and end up making our code significantly more
complicated in the process — especially when testing asynchronous
code that relies on some form of networking.
But does it really have to be that way? What if we could actually
make our code fully testable in a way that doesn’t require us to
introduce any new protocols, mocking types, or complicated
abstractions? Let’s explore how we could make use of Swift’s new
async/await capabilities to make that happen.
A common problem in computer animations is rotating an object in
fully 3D space. Think objects, spaceships and heroes tumbling and
turning in complex sequences. This is usually accomplished with an
arcane mathematical object called a quaternion.
It happens a lot, you write a bash script and half way it exits due
an error. You fix the error in your system and run the script
again. But half of the steps in your scripts fail immediately
because they were already applied to your system. To build resilient
systems you need to write software that is idempotent.
Traditionally, Python has been a blocking language when it comes to
I/O and networking, meaning lines of code are executed one at a
time. With network requests, we have to wait for the response before
we can make another request. Meanwhile, our computers sit
idling. Luckily, there are ways to address this, the most exciting
of which is leveraging asynchronous requests with the
aiohttp package. This article
explains how asynchronicity can help solve these issues – and how
you can put it into place within your own code!
A goal of the async foundations working group is for async Rust to
be portable and
want to dig in to what that means in this blog post. For a little
background, see my earlier post on async
You’re using multiprocessing to run some code across multiple
processes, and it just—sits there. It’s stuck.
You check CPU usage—nothing happening, it’s not doing any work.
What’s going on?
In many cases you can fix this with a single line of code—skip to
the end to try it out—but first, it’s time for a deep-dive into
Python brokenness and the pain that is POSIX system programming,
using exciting and not very convincing shark-themed metaphors!
One Git usage pattern that I think is underused is the “branchless”
workflow. The idea here is pretty intuitive if you’ve used
there’s just one “main” branch that everything gets merged into. No
feature branches, no release branches, no hotfix branches.
The “branchless” workflow is, in a nutshell: You work in a stack of
atomic commits which are all eventually intended to be merged into a
single trunk branch. Each commit can become a pull request, and each
pull request consists of a single commit.
This is the second article in a series where I try to understand
systemd by creating small containerized examples. In Part
we created a minimal systemd setup in a container. We are now using
this setup to continue our investigation of systemd, starting with
taking a closer look at dependencies.
We all know that indexing is important, but it can be difficult to
know where to start. In this post, my aim is to collate some of the
best advice I’ve seen for indexing Postgres, and simplify it for
folks just getting started.
When writing asynchronous code using Swift’s new built-in
concurrency system, creating a Task gives us access to a new
asynchronous context, in which we’re free to call async-marked
APIs, and to perform work in the background.
But besides enabling us to encapsulate a piece of asynchronous code,
the Task type also lets us control the way that such code is run,
managed, and potentially cancelled.
The Memory Image Pattern (MIP) is a novel approach to application
development. It rejects the idea of storing state in a database and
gains both developer productivity and run-time performance. If you
can fit your application data in memory, MIP might be for you.
A couple of years ago I wrote a somewhat controversial article on
the topic of Bringing the Unix Philosophy to the 21st
by adding a JSON output option to CLI tools. This allows easier
parsing in scripts by using JSON parsing tools like
jp, etc. without arcane awk,
sed, cut, tr, reverse, etc. incantations.
It was controversial because there seem to be a lot of folks who
don’t think writing bespoke parsers for each task is a big
deal. Others think JSON is evil. There are strong feelings as can be
seen in response to the article in the comments and also on Hacker