Suppose you have access to an S3 bucket in some AWS account. You need to get the files to another bucket (same or different AWS account I think makes no difference to my eventual point) You do your due diligence and count the objects in the origin bucket aws s3 ls s3://originBucket --recursive --summarize | grep "Total Objects:" You get the total count and start your sync aws s3 sync s3://originBucket s3://destinationBucket --delete --exact-timestamps Great. It completed successfully. Now let’s count the objects in the destination bucket ...

It’s generally a good practice to differentiate between application endpoints than need to be accessible via Internet and endpoints that need to be accessible only internally via your private VPC. But what if I need one app’s endpoint temporarily accessible to my CICD runner that’s not in the VPC? e.g a /health to know if the deployment succeeded. If you’re on AWS, you may be correctly thinking PrivateLink, VPC Endpoints etc But that may be overkill for a short-lived connection from our CICD. The apps I’m interested in run mostly in kubernetes. To access an internal endpoint from my local, I’d just kubectl port-forward ...

Ran into a nice little bit of nostalgia today. Have any of you heard/remember the bash bomb ? It’s Denial of Service attack in 13 characters! : (){ : |: & };: Here’s how

This a another discussion I have frequently. Why bother changing something, however small, if it works as it is? Well, it’s a best practice. If we can spend a very limited amount of time to make trivial changes that will protect us from mishaps, carelessness and changes beyond our control, is it not worth it? This argument, on its own, is usually not very effective against a stubborn engineer in a hurry. So, whenever possible, I try to give more concrete examples. Here’s one that I was happy to find just in time for such a discussion. ...

I’ve always been fascinated with details. They’re subtle, easy to ignore but every once in a while they turn out to be important. I have gotten in very interesting (and often heated) discussions about this fascination (mainly at work). Taking the time to go over the details, learn, understand and digest takes time. And startups are always on a countdown clock and push to get things faster. People too. If something seems like it can be ignored, we tend to ignore it. I suppose most of our minds are already at capacity, way before someone starts a long-winded argument about things that seem trivial and inconsequential. ...