-
Testing Without Excuses
Every app has that last inch (or mile) of code that’s not covered by tests. Usually it’s an interactive cycle of compile-run-inspect on the command line like
You Test
curl -X POST https://reqbin.com/echo/post/json
##👀 You Expect:
{"success":"true"}
Despite having 3-4 testing frameworks for unit tests, e2e, regression etc– there’s always a gap where you find yourself re-playing commands in the terminal to test.
A common case is 🔥firefighting where ad-hoc tests are needed to validate an emergency config change or deployment.
-
Three Pillars
Recently an old friend, with great experience as an IC, PM and EM, called me to ask for some advice. He had been running his business for a while and took up a new role as an engineering manager after some time. “What areas do you focus on as an EM?, particularly when joining a new team”.
I divided the conversation into three pillars: strategy & inventory, technical (aka going deep) and career / personal
-
Signal Vs Noise
One responsibility of engineers & especially leads is managing many channels of signals : emails, blog posts (internal and external), tags , push notifications, group chats, alerts from dashboards and more.
These signals tend to scale exponentially to the number of projects & people that you are responsible for.
Quickly you’ll need to set up a system to make sure that you are receiving high-signal information and filtering out low-signal noise. How do you do that?
-
A Timeless Directory Layout for All of your Projects
Directory layouts are like log cabins that start from a basic shed, gradually adding a room at a time. When you start out on UNIX, everything gets thrown in your home directory. Over time you start to develop a structure for your sources, binaries, projects, data files (like CSV, images, tar files), config, etc
My layout is called TDL – because it allows me to juggle open source projects, partnerships and jobs in a consistent structure across machines and time.
-
Snooze to Save Money
Cloud instances bill by the hour (or the minute) – and right now you’re burning money. Use
snooze
to auto-shutdown your instances in 45 minutes.Add
snooze
to your~/.bashrc
alias snooze='sudo shutdown -c ; sudo shutdown -h +45 &' snooze
When you want to extend your session, run
snooze
Broadcast message from ec2-user@ip-172-31-43-250 (/dev/pts/1) at 2:50 ... The system is going down for halt in 45 minutes!
How does this work?
shutdown -c
cancels the shutdown, andshutdown -h +45
schedules a shutdown in 45min. -
Fully Remote Development with VS Code & Cloud9
I work from about 7 different machines, including 3 laptops, ipad, chromebook and a PC desktop. Usually this means keeping credentials, config, build dependencies and IDEs in sync across all 3–and the iPad & Chromebook just can’t run my dev environment
I considered a few options to enable seamless work across devices
option pros cons Keep a “dev” docker image that contains everything. fully-local dev only works on Desktop OSs. Inconsistency if you forget to push the image Sync script fully-local dev Inconsistency across devices. Script mayhem Code remotely via a VM Secure, consistent Traditionally, text-only Solution
- Launch Cloud9 Environment on AWS
- Install VS Code + SSH Remote Extension
- Install tmux
With this setup, you get the highest-fidelity experience when you can (with VS code), plus an adequate experience on iPad & Chromebook (cloud9 web ide). With tmux you get seamless handoff across all devices.
-
Build 100kB Docker Images from Scratch
📓 The Gist
You may think your 100mB Alpine images are small–but how about 100kB? Smaller images ship more quickly, and contain fewer attack vectors. Moreover, by optimizing images, you discover and isolate exactly what is needed for your app to run.
Let’s Optimize.
There are two key characteristics of scratch-based docker images:
- The Dockerfile has two build stages:
- a builder–which contains all of the build dependencies including source, libraries and tools and..
- a final image, containing the binary and any run-time dependencies (config files, certificates and dynamically linked libraries)
- The final image is
FROM scratch
– the empty docker image
With this approach, your run-time image will contain exactly what is needed for your app to run – no additional config files, daemons or libraries that could be misconfigured or exploited.
-
Publish Free Static Websites With Firebase, Hugo and Google Cloud Builder -- Part 2
In Part 1, we completed our development environment, including setting up Hugo and our repo.
Here we’ll publish our site to Firebase Hosting, and create the CI tools on Google Cloud Build to build and publish upon push.
Open Your Cloud Shell
In Part 1, we enhanced our cloud shell with hugo and set up our repo. In Part two, we’ll use it to create the builder and configure hosting.
-
Benchmarking Pihole : Pi Zero vs Pi 3b+
Here’s a benchmark comparing pi-hole running on a Pi Zero (with USB ethernet) vs a Pi 3b+.
tl;dr There was negligible performance difference for blocked domains, but a measurable difference in mean for forwarded + cacheable domains. Although the Pi 3b+ has a 11ms better mean response time for forwarded queries, the P95 for pi zero is better in both blocked and forwarded queries.
I would recommend using the Pi Zero.
-
PHP Dev Environment One-Liner
Here’s the fastest way to get your PHP app running. No MAMP, WAMP, apache or any of that nonsense.
Moreover, it allows you to run multiple projects independently.
I’m assuming you have docker.
tl;dr
This runs the php docker image, mounts the current directory, and spins up a server on port 8086
$ docker run -v $(pwd):/www -it -p8086:8086 php:5.6-alpine sh -c "cd www; php -S 0.0.0.0:8086"
The Full Version
Create your index.php
$ cat > index.php <html><body><h1><?php print("Hello World!") ?> </h1></body></html> CTRL-D
Run the Server
$ docker run -v $(pwd):/www -it -p8086:8086 php:5.6-alpine sh -c "cd www; php -S 0.0.0.0:8086"
Test Your Server
$ curl localhost:8086 <html><body><h1>Hello World! </h1></body></html>