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.

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

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?

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.

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, and shutdown -h +45 schedules a shutdown in 45min.

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

Solution

1. Launch Cloud9 Environment on AWS
2. Install VS Code + SSH Remote Extension
3. 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.

📓 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:

1. 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)

2. 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.

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.

See the Quickstart for complete instructions

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.

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>