Apr 25, 2017
I’ve been dipping my toes in Rust lately and I’m finding it a competent programming language. It’s a
nice middle ground between C/C++ and a programming language that requires you to know Category
Theory in order to start using it (cough… Haskell cough…).
When you start using Rust you quickly find out that it’s a good idea to something called
Clippy. It is a fantastic tool that helps you write
better and more idiomatic Rust code. I’m sure its name is a reference to this guy on the right, just
a little less obnoxious.
Having Clippy on your side is like having an experienced Rust developer telling you that the code
you are writing is of questionable quality, even though it compiles just fine.
There’s one catch though, you can’t use it on stable Rust releases.
Clippy, in fact, is implemented as a compiler plugin and, as such, it depends on unstable
APIs that are available only on nightly releases of the Rust toolchain.
I don’t like to run nightly or beta releases as my daily driver for a couple of reasons:
- I don’t want to risk depending on features that will ever be available only on nightly Rust or
that will change wildly between snapshots.
- Being a beginner, I want to judge Rust on the merit of what’s available in stable releases right
now, not on the prospect of what will be available later, if at all. In a project I decided to
use serde’s codegen before “macros 1.1” were stabilized in Rust
Sometimes Clippy fails to build even with the latest nightly compiler, so the first thing I usually
do is to browse its CHANGELOG
file and find out which release has been compiled with which compiler and use that.
For example, given this excerpt:
0.0.124 — 2017-04-16
- Update to rustc 1.18.0-nightly (d5cf1cb64 2017-04-15)
0.0.123 — 2017-04-07
- Fix various false positives
I would pick Clippy version 0.0.124 and build it with the 2017-04-23 nightly compiler.
Starting with a working
rustup I would then run:
rustup toolchain add nightly-2017-04-15
rustup run nightly-2017-04-15 cargo install --force --vers 0.0.124
If the selected version still fails to compile, I just pick the previous one until I find one that
Since I always keep the stable toolchain as default, running
cargo clippy as-is will result in an error:
0 19:40:53 lvillani@oculus ~/D/borg-hive (master=)
$ cargo clippy
dyld: Library not loaded: @rpath/librustc_driver-8dacd42830809d58.dylib
Referenced from: /Users/lvillani/.cargo/bin/cargo-clippy
Reason: image not found
error: An unknown error occurred
To learn more, run the command again with --verbose.
Since we have
rustup, running Clippy with the nightly toolchain we installed before is easy:
rustup run nightly-2017-04-15 cargo clippy
If, for some reason, running
cargo build with the stable toolchain after Clippy ends up
recompiling all dependencies, just tell Cargo to put its output files in a separate directory like
env CARGO_TARGET_DIR=./target/clippy rustup run nightly-2017-04-15 cargo clippy
This is especially useful if you then want to remove only the output files generated by a Clippy
Feb 19, 2017
Today I learned that, under certain circumstances, Docker and an IPsec VPN can conspire to make your
life as a developer miserable, by eating outgoing HTTPS connections started from inside a container.
The first symptom that something is amiss is usually being unable to go past the “TLS Client Hello”
message during the handshake process, or having the connection stall shortly after that. For
curl from inside a container would just hang, even though it would work just fine
on the host machine itself.
The scenario is the following: I have a standard Ubuntu 16.04 machine with Docker and other tools
coming straight from the official repository, quite boring. An L2TP over IPsec VPN connects me to
the remote site with a split-tunneling configuration.
Said VPN is configured client-side with StrongSwan and
xl2tpd, two of the most evil pieces of
software. Especially the latter, which will often crash unless planets are aligned correctly as the
author wanted. At the other end of the VPN is a Meraki box that shuts itself down if you just so
happen to sneeze around it.
All network interfaces have an MTU of 1500, except for the L2TP tunnel that sits around 1400 since
x2ltpd/pppd duo configures the
ppp0 interface like that, for whatever reason.
Here’s what an imaginary packet would encounter if it had to travel from inside a container to a
machine at the other end of the VPN tunnel (in reality it’s more complicated than that so, please,
bear with me):
It seems that there are
issues with the way Docker does its networking on
Linux and the way Linux itself handles bridge interfaces.
It appears that the issue stems from Docker’s use a bridge interface and the fact that Linux won’t
generate the “Fragmentation Needed” ICMP message that would allow for Path MTU Discovery (PMTUD) to
work when IP packets have the “Don’t Fragment” bit set (which should be typical for TCP streams).
Now, I’m no network engineer so take my layman’s explanation with a grain of salt.
In my case the fix was simple: start the Docker daemon passing the
--mtu=1400 parameter. On Ubuntu
I only had to edit the value of the
DOCKER_OPTS variable present in
systemctl restart docker.
Dec 15, 2016
This time, I’d like to start with a comic, courtesy CommitStrip:
As part of my job I had the honour to work with many Web technologies and tools such as jQuery,
Angular, Backbone, and React with Redux/Reflux, Babel, and TypeScript. Every time I ran away
screaming, feeling the urge to bang my head on a wall, promising myself that I would never endure
such pain ever again.
The problem with the “Web Applications” movement is that they are trying to force design and
development paradigms typical of desktop applications onto a platform that was designed to render
HTML and CSS are, essentially, elements of a glorified typesetting system. The fact that you can
hacks strung together with duct tape. Mostly written by clueless developers.
Whenever I see a desktop application built on top of Electron and HTML5 I cringe. I cringe because I
see a thing that burns through my laptop’s battery and eats hundreds upon hundreds of megabytes of
RAM and I know that the same thing could have been built with Qt and the result would have been more
respectful of my system’s resources and would also have been better integrated with it.
I also cringe at the incredible churn rate with the development toolchain: libraries and tools seem
fast and rewriting stuff just to use the new best-of-breed library du jour.
Watching all this fuss come true lead me to the conclusion that “the Web” attracts a very specific
kind of developer: the masochist.
They know that they are working with a bad platform. They spend their days trying to figure out why
the Rube Goldberg machine built with Babel, Webpack, SASS and whatnot broke. They work sleepless
nights to try to overcome very basic performance problems with their application.
They live a hellish life but, when they do manage to get everything working, they feel incredibly
accomplished. The endorphin rush is so powerful that, just like a drug addict, they want more.
And the cycle repeats.