A little Sketchplanation on "point positive".

Point positive is a rafting term for agreeing in advance to point towards the safe way out of danger rather than towards the dangers themselves.

When you're in trouble, don't dwell on the cause, look for a solution. Only when the waters are calm, take a step back, reassess, and learn the necessary lessons to avoid it in the future.

↗ sketchplanations.com

In 2005, Joel Spolsky’s software company, Fog Creek, filmed a documentary about their summer internship program. The film is called Aardvark’d: 12 Weeks with Geeks, and it follows four college interns as they design, implement, and launch a completely new software product.

That’s not the interesting part.

Looking back on this documentary 18 years later, it’s striking how many interviews it captured with people who would go on to greater fame and success:

I lovely read on craft by Cat Hicks.

Grandpa loved craft. […] He fixed things often and silently. Grandpa just cared about things working. He had an instinct for not just broken things but soon to be broken things. He would point out risky work, bad decision making in the form of shoddy materials or shifting angles.

As software developers, we often consider our trade to be unique. But what we (should) have in common with others is the mindset of respecting our craft—of producing solid and lasting work.

I have read a lot of long spiels about craft that frequently end in something like, software work isn’t like other work, and we shouldn’t be judged the same way. We are entirely unique. We are the special ones. I find this both saddening and unconvincing. I think that all labor is skilled labor. I think about the factories and the fields and the ways that demands for speed instead of cadence can hurt people. I think we should seek to understand and value our skills and see effort. But I don’t think we are going to fix anything about how software work is valued by refusing to let it belong to the rest of the world.

↗ www.drcathicks.com

Go’s defer and t.Cleanup have similar semantics, but there’s a good reason to prefer the use of t.Cleanup specifically in the presence of parallel subtests.

I love Laravel Forge's quick deploy scripts. Forge allows you to set up a deploy script in their web interface and run it when you push to a git branch. However, I generally prefer to keep orchestration in the git repository. It's nice to have history, and I don't want to visit Forge whenever I want to make a change to the deploy script.

An elegant solution: move the script to a file. I created a deploy.sh and call it from Forge.

My deploy script isn't too bulky for now. It runs composer install and npm ci for dependencies, builds assets, clears the cache, caches config files, and does a safe restart of the php fpm process.

composer install --no-dev --no-interaction --prefer-dist --optimize-autoloader
 
npm ci
npm run build
 
php artisan cache:clear
php artisan config:cache
 
( flock -w 10 9 || exit 1
    echo 'Restarting FPM...'; sudo -S service php8.2-fpm reload ) 9>/tmp/fpmlock

Which I call from Forge:

cd /home/forge/full-stack-artisan.dev
git pull origin $FORGE_SITE_BRANCH
 
./deploy.sh

Don't forget to make deploy.sh executable before use.

chmod +x deploy.sh

Whenever I need to tweak the deploy script, I can update it from my text editor and git push.