Recent Posts (all)
My password-manager of choice, 1Password, doesn’t care about the consumer market anymore.
Read their Series C announcement.
You might read of yet another unicorn raising money.
But I read about a company that deeply cared about its (Mac) users and that now sees the future in B2B services.
I don’t fault them.
1Password has been profitable from the start — contrary to many others. It did so by building a delightful product (I have been a user since Christmas 2008).
But even though they had a lucrative life-style business, there is way more money in the B2B market. So they took that route and are not looking back.
A single company — where you could easily have 1000 employees — earns them 8$ per employee a month (8000$/month). That’s equal to 1600 1Password family plans. A feature winning them a family is worth nothing. A feature winning them a company? Easily $100k per year!
And that future is already here.
1Password 8 is subscription only, while v7 had a fixed-price version. Why? This is how enterprise buys software nowadays.
1Password 7 was a native Mac app. 1Password 8 is an Electron app. They can pull it off as business users already have all sorts of crap on their machine. Electron is one of the good ones there.
In the future, more might come and I wish this wasn’t the case. 1Password is the app I couldn’t live without.
If you work with Python on macOS and are trying to let your kids play with things like turtle
you will encounter errors such as
>>> import turtle
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "~/.pyenv/versions/3.7.4/lib/python3.7/turtle.py", line 107, in <module>
import tkinter as TK
File "~/.pyenv/versions/3.7.4/lib/python3.7/tkinter/__init__.py", line 36, in <module>
import _tkinter # If this fails your Python may not be configured for Tk
ModuleNotFoundError: No module named '_tkinter'
If you use pyenv and brew there’s a simple way to fix it:
brew install tcl-tk
brew install pyenv # skip if you already have pyenv installed
export PATH="/usr/local/opt/tcl-tk/bin:$PATH"
export LDFLAGS="-L/usr/local/opt/tcl-tk/lib"
export CPPFLAGS="-I/usr/local/opt/tcl-tk/include"
export PKG_CONFIG_PATH="/usr/local/opt/tcl-tk/lib/pkgconfig"
export PYTHON_CONFIGURE_OPTS="--with-tcltk-includes='-I$(brew --prefix tcl-tk)/include' \
--with-tcltk-libs='-L$(brew --prefix tcl-tk)/lib -ltcl8.6 -ltk8.6'"
pyenv uninstall 3.8.2 # substitute here the version you're using or skip if you were not using pyenv
pyenv install $(pyenv install --list | grep -v - | grep -v b | tail -1)
After you’re done, you can now turtle along:
>>> from turtle import *
>>> color('yellow', 'blue')
>>> begin_fill()
>>> while True:
forward(200)
left(220)
if abs(pos()) < 1:
break
>>> end_fill()
>>> done()
![a turtle](/images/turtle.png)
Since having changed my main business title on LinkedIn away from Shoe Designer, I got my good
share of recruiters contacting me whether I’d be interested in the best data scientists and
engineers I’ve ever encountered.
At GoDataDriven we’re always hiring so my standard answer was — initially — “Yes of course, send
the profile over”.
However what happened next was always more or less the following:
- I get a bunch of profiles in my inbox;
- As everyone
wants
to
be a data scientist or data engineer, the
profiles are chock full of buzzwords and it is really hard to see if someone if the real deal or
not;
- After having lost north of 10 minutes per CV, googling various company names, technologies, and
institutions, I made a list of people I wanted to talk to. Maybe 1 to 2 people every 20;
- Talking to these people took at least 45’, probably 1 hour including planning (I didn’t have
somebody to manage my agenda);
- During this chat, I often found out glaring flaws that the recruiters should have caught, such as
unwillingness to relocate, very different salary expectations, CV not being 100% honest, etc.
This means that every time a single recruiter would send me 20 CVs, I would lose 4-5 hours,
scattered among multiple days. If I include a generous context-switching time lost of 2-3 hours,
that meant that every recruiter interaction meant a whole day would be wasted.
I should add to this the frustration of not winning: I did not hire a single person in months. And
it wasn’t for lack of clarity on my part. I onboarded each recruiter with a 30’ call explaining in
details what kind of colleagues we were looking for.
Certainly something had to change. I introduced a recruiter “policy”. The policy was very simple
and I would send it as soon as someone contacted me:
- You can send a maximum of 4 CVs, all at the same time;
- If we don’t hire anyone from this first batch, we terminate our relationship.
My inspiration was something that I believe Atlassian published. I loved this policy because
it shifted most of the work from my back to the recruiters’ back.
The full day of work was reduced to 2 hours in total — if I didn’t hire anyone: otherwise they
could send me all the CVs they wanted.
Most interestingly, lots of recruiters stopped before sending me a single CV: a strong indicator
that they didn’t want to do their job and rather wanted to continue their volume game with some
other fool.
How many recruiter agency did we end up working with? Just one, comprised of a single person. We
love him, and kept using his service until we hired our first internal recruiter.
So next time you think you’re overwhelmed by the amount of CVs recruiters send your way, try
shifting the work
On Wednesday July the 10th, the Dutch website NOS broke the news that people employed by or
through Google, listen to thousands of conversations Dutch people are holding in the proximity of
Google Home devices (that’s the reason I keep the microphone of my Sonos turned off).
In our company Slack, I reacted stealing John Gruber’s words about a very different topic:
Get me to the fainting couch. What a shocker.
I love the job ad for the new Africa writer for the the Economist.
They don’t care if you’re a journalist, what’s your experience,
background, skin color, etc.
They only care about:
original thinking, good analytical skills and, above all,
good writing.
👌🏼👍🏼👏🏼
Today HBR published an article about some causes of burnout. One struck a cord with me, and,
as a physicist that went more into the managerial path, I’m sure I’m not the only one:
Workload […]: assess how well you’re doing in these key areas: planning your workload,
prioritizing your work, delegating tasks, saying no, and letting go of perfectionism.
I think they’re all tightly coupled: if you’re good at planning, you must have prioritized
properly by knowing what you can and cannot accomplish with your time, and if you have prioritized
you must say no and you must have delegated tasks. If you’re good at planning, you also can’t be a
perfectionist, because perfection is difficult to plan.
I struggle with three of them mostly: delegating tasks, letting go of perfection, and saying no.
Delegating tasks is hard because I can’t let go of perfection, and because I am usually not good at
communicating the end result. And I am not good at communicating the end result because I delegate
too little: if I were to delegate more, I would learn — from all the times it went wrong — what
things are important to communicate.
Since I know that, I also know that the first times I delegate, the end result will not be what I
want: again, I can’t let go of perfection.
Luckily I’m learning the hard way that I need to let go quickly in these key areas:
- Before my last holiday I was real close to losing it, and I felt it and it scared me;
- As the line of business I am running grew, I let potential opportunities slide, as I didn’t have
time.
So, right before the summer, I tricked myself into start delegating. Two things helped
me out:
- My daughter was going to be born (she’s arrived yesterday), so if I wanted to enjoy time with
her, I had to have my hands free from work;
- I said to myself that delegating didn’t mean recognizing that somebody else was better than me at
doing a task, in absolute term and that I couldn’t do the job just as well: I said to myself
that other people had either more time, or more focus, or better tools, or more experience in
doing it. In other words, I could do it myself, but it was not efficient.
So here I am now, with time in my hands to write this post :)
Brent Simmons doesn’t mince words when he talks about algorithms to drive engagement, honed and
“abused” by companies such as Facebook and Twitter:
My hypothesis: these algorithms — driven by the all-consuming need for engagement in order to
sell ads — are part of what’s destroying western liberal democracy, and my app will not
contribute to that.
I forgot to link to this very good article from David. Having almost 6 kids, I am usually not
bothered by noise outside my head, but by noise inside my head.
Noise inside my head comes mostly from not having a long or well defined task. These are the kind
of tasks that tends to come in through Slack.
To fix it I offload most of these tasks — before they reach me — to people who are
better at handling them.
Companies that are business-savvy about the hidden costs of interruptions should know that they
should be penny foolish and pound wise on this one.
A couple of days ago I moved the blog and the website over to Netlify.
The reasons are simple:
- The site was previously hosted on S3 + Cloudfront, but I didn’t have
https
enabled;
- I didn’t know how to enable
https
although I must not be too hard;
- The application I was using to deploy to S3 — called Stout — was unmaintained and growing old.
Every time I’ve read comments on Netlify the message was the same: it’s easy to set up, and once
you’ve set it up, you can forget about it.
I gave myself 5’ to try: if I could do it, good, otherwise I would stay on the current setup.
Well, not only I could do it, but the whole project was undistinguishable from magic. They took
care of everything for blog.lanzani.nl
and lanzani.nl
, including serving the naked domain
(previously it would be forwarded to www.lanzani.nl
, something that always bothered me).
As they integrate with GitHub and hugo, I don’t even need to build the website anymore, they do
it for me every time I push the repo!
So the end result is that you can read this blog without fearing that someone has tampered with the
content!
This is another post that is totally a note for my future self.
I don’t write on this blog often. But what I do, a lot, is read what other people write on their
blog. I do that through the wonderful capabilities of RSS.
Doing so in a sane manner involves a few moving parts:
- One or multiple feeds you want to read. This is the easy part;
- A server that keeps track of them
- The server should provide a good interface to read on the web;
- Bonus points if the server also provides an API so that I can use apps to read the articles.
Up until a couple of weeks ago I was using a simple pair: Stringer, hosted on a spare GCP
machine, and Unread on iOS. Stringer offers a nice reading experience on the web, so I didn’t
need an app for my Mac.
However, as the spare machine wasn’t spare anymore I started looking for something else as
I did not like the fact that Stringer was an unmaintained Ruby app anymore. I have nothing against
Ruby, but the fact that the app was unmaintained meant running a potentially insecure application.
There are many RSS readers as a service since Google Reader shut down:
- Feedbin
- Newsblur
- Bazqux
- The Old Reader
- And many more.
The only “problem” is that these services cost from approximately $2 to $5 a month. Can I do
something for free?
At first I thought about running stringer on one of my Raspberry Pis. They are pretty powerful and
I don’t have that many feeds I need to read.
But if I do that, I possibly want to have everything working in a semi-automatic fashion, so that
there’s little to no manual work if the SD is my Raspberry Pi goes south.
The easiest solution — for single machine scenarios and where seconds of downtime are OK — is to
use Docker with docker-compose.
This is where, however, Ruby and the Ruby version stringer uses (2.3.3) are painful:
- There were no official Ruby 2.3.3 images for ARM (that I could find);
- Updating to the latest 2.3 version (2.3.8 at the time of this writing) would trigger some bug
that I was not able to fix;
- Updating to 2.3.4 would have everything working, but
- The image for stringer using Ruby 2.3.4 is 857MB: not exactly small;
- As I would need to customize the stringer docker image heavily (to make it compatible with 2.3.4,
plus some other small details), that would mean building the images from time to time when new
security updates get pushed (if they ever do);
- Doing the above is doable with one of the many CI/CD services out there (for example Azure
Pipelines) but since the build needs to be for ARM on an X86 server, extra care and
configuration is needed (buildx is not generally available yet).
If you’re a bit like me, the above feels like a chore and change of many headaches (that’s probably
why all those RSS as a service services exist in the first place).
So I turned to Reddit to see what others are doing. While searching here
and there, I came across a thread where they mention miniflux.
When I looked at the website, I couldn’t believe it: it has everything I need and then some more:
- Easy to get started with;
- Provides ARM images out of the box;
- Written in Go and hence very small to host (compared to the 857MB of stringer, miniflux docker
image is 17MB, 50x smaller);
- Written in Go and hence faster than non-optimized Ruby (and it certainly feels a lot faster than stringer);
- Like stringer, it implements the Fever API, meaning I can use it with Unread.
Requirements
Now that I have settled down on the server, what else do I need?
- I already said that I want Docker support;
- Possibly everything should be scriptable, for 99% of the code (I am OK running a couple of
scripts manually);
- I want
https
: if I’m entering a password it should be secure;
- I (ideally) want the latest security patches quickly, without much maintenance;
- It should be easy.
The solution
After a bit of googling, I’ve come up with the following folder structure and files to serve my
needs:
.
├── data
│ └── nginx
│ └── app.conf
├── docker-compose.yml
└── init-letsencrypt.sh
Let’s see the content of each file.
version: '3'
services:
database.postgres:
image: postgres:9.6-alpine
container_name: postgres
ports:
- 5432:5432
environment:
- POSTGRES_PASSWORD=<insert_pg_password>
- POSTGRES_USER=miniflux
- POSTGRES_DB=miniflux
volumes:
- ./data/postgres:/var/lib/postgresql/data
restart: always
service.rss:
image: miniflux/miniflux:latest
container_name: miniflux
ports:
- 8080:8080
depends_on:
- database.postgres
environment:
- DATABASE_URL=postgres://miniflux:<insert_pg_password>@database.postgres:5432/miniflux?sslmode=disable
- RUN_MIGRATIONS=1
- CREATE_ADMIN=1
- ADMIN_USERNAME=admin
- ADMIN_PASSWORD=<insert_miniflux_password>
restart: always
nginx:
image: nginx
restart: unless-stopped
volumes:
- ./data/nginx:/etc/nginx/conf.d
- ./data/certbot/conf:/etc/letsencrypt
- ./data/certbot/www:/var/www/certbot
ports:
- "80:80"
- "443:443"
command: "/bin/sh -c 'while :; do sleep 6h & wait $${!}; nginx -s reload; done & nginx -g \"daemon off;\"'"
certbot:
image: tobi312/rpi-certbot
restart: unless-stopped
volumes:
- ./data/certbot/conf:/etc/letsencrypt
- ./data/certbot/www:/var/www/certbot
entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"
watchtower:
image: v2tec/watchtower:armhf-latest
restart: always
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /root/.docker/config.json:/config.json
command: --interval 604800
The docker-compose.yml
contains quite some images:
- The
postgres
one is simple: we need a database with a user;
- The
miniflux
one is configured as per their docs;
ngix
is also pretty simple: we add a couple of touches: we mount the configuration folder, we
mount the letsencrypt certificates, and the www
folder to put the verification for letsencrypt;
rpi-certbot
is an ARM-ready image with certbot
watchtower
is a docker image that looks (in my case every 604800 seconds, every week) that
all the images I’m using are up to date. If not, the image will be updated. This is especially
relevant for nginx
and miniflux
which are the containers facing the users.
For nginx
the app.conf
file is needed. Its content is
server {
listen 80;
server_name <my_domain>;
server_tokens off;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
return 301 https://$host$request_uri;
}
}
server {
listen 443 ssl;
server_name <my_domain>;
server_tokens off;
resolver 127.0.0.11;
set $upstream service.rss:8080;
ssl_certificate /etc/letsencrypt/live/<my_domain>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/<my_domain>/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
location / {
proxy_pass http://$upstream;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Frame-Options SAMEORIGIN;
client_max_body_size 100m;
client_body_buffer_size 128k;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
}
}
There’s not much to explain here. The last snippet is the init-letsencrypt.sh
. The script
“bootstraps” nginx
for the first time: since we want https
, but we cannot have it without
certificates, but we cannot ask certificates without a running nginx
, this script creates fake
certificates, start nginx
, removes the certificates, and then request real ones through
letsencrypt. The content is quite long, but here you go:
#!/bin/bash
if ! [ -x "$(command -v docker-compose)" ]; then
echo 'Error: docker-compose is not installed.' >&2
exit 1
fi
domains=(<my_domain>)
rsa_key_size=4096
data_path="./data/certbot"
email="" # Adding a valid address is strongly recommended
staging=0 # Set to 1 if you're testing your setup to avoid hitting request limits
if [ -d "$data_path" ]; then
read -p "Existing data found for $domains. Continue and replace existing certificate? (y/N) " decision
if [ "$decision" != "Y" ] && [ "$decision" != "y" ]; then
exit
fi
fi
if [ ! -e "$data_path/conf/options-ssl-nginx.conf" ] || [ ! -e "$data_path/conf/ssl-dhparams.pem" ]; then
echo "### Downloading recommended TLS parameters ..."
mkdir -p "$data_path/conf"
curl -s https://raw.githubusercontent.com/certbot/certbot/master/certbot-nginx/certbot_nginx/options-ssl-nginx.conf > "$data_path/conf/options-ssl-nginx.conf"
curl -s https://raw.githubusercontent.com/certbot/certbot/master/certbot/ssl-dhparams.pem > "$data_path/conf/ssl-dhparams.pem"
echo
fi
echo "### Creating dummy certificate for $domains ..."
path="$data_path/conf/live/$domains"
mkdir -p "$data_path/conf/live/$domains"
openssl req -x509 -nodes -newkey rsa:1024 -days 1 \
-keyout $path/privkey.pem \
-out $path/fullchain.pem \
-subj '/CN=localhost'
echo
echo "### Starting nginx ..."
docker-compose up --force-recreate -d nginx
echo
echo "### Deleting dummy certificate for $domains ..."
docker-compose run --rm --entrypoint "\
rm -Rf /etc/letsencrypt/live/$domains && \
rm -Rf /etc/letsencrypt/archive/$domains && \
rm -Rf /etc/letsencrypt/renewal/$domains.conf" certbot
echo
echo "### Requesting Let's Encrypt certificate for $domains ..."
#Join $domains to -d args
domain_args=""
for domain in "${domains[@]}"; do
domain_args="$domain_args -d $domain"
done
# Select appropriate email arg
case "$email" in
"") email_arg="--register-unsafely-without-email" ;;
*) email_arg="--email $email" ;;
esac
# Enable staging mode if needed
if [ $staging != "0" ]; then staging_arg="--staging"; fi
docker-compose run --rm --entrypoint "\
certbot certonly --webroot -w /var/www/certbot \
$staging_arg \
$email_arg \
$domain_args \
--rsa-key-size $rsa_key_size \
--agree-tos \
--force-renewal" certbot
echo
echo "### Reloading nginx ..."
docker-compose exec nginx nginx -s reload
For this and for app.conf
file I took inspiration from the nginx-certbot repository with some
modification: I’m using rpi-certbot
instead of certbot
and the openssl
utility that comes
with the Raspberry (if it doesn’t, use sudo apt-get install openssl
to get it).
Outside the Raspberry
The outside world need to know where to find your Raspberry and should be able to get there. Doing
so is outside the scope of this post, but in general
- Find your external IP address (and hope it’s static or use a service such as Dyn)
- Update the DNS of your (sub)domain (For example
reader.lanzani.nl
)
- Assign a static DNS to your Raspberry from your router
- Route port
80
and 443
in your router so that the traffic is handled by the Raspberry (port
80
is necessary for the letsencrypt verification).
Start everything
Once all these files are in place, you are in the right folder, and you have updated the various
variables marked with <>
(passwords and domain name) in the files above you can get rolling with
curl -sSL https://get.docker.com | sh
pip install --user docker-compose
bash init-letsencrypt.sh
docker-compose up
Now visit your (sub)domain, use admin
as the user and the password you have chosen to log in.
Enjoy the rest!
←
4/11
→