Some bugs compile cleanly, pass all tests, and slip through code reviews. I shipped one of those at work: a database transaction that silently leaked operations outside its boundary. I don’t like being stressed with a broken prod, so I built a custom linter to catch them at compile time. Here’s how.
At work, mock generation was slow: 5 minutes locally, and 15 in CI. That’s long enough that I’d start something else while waiting and forget to come back. Refusing to accept the harsh realities of life, I wondered if we could do better.
Shell scripts are awesome, as we know . Now, we have nice shell scripts that self document. But if you’re anything like me, you have lots of them in your ~/bin or wherever you put them. One reason is that each script can do one thing and one thing only. Wouldn’t it be nice if we could group different functionalities in the same file?
Shell scripts are awesome. They are so useful to automate repetitive and boring work. The hardest thing about them, though, is documentation. How often have you written one, put it in the bin directory and forgotten all about it? How cool would it be to have a help message for them?
“Hello, friend?” That’s lame. Maybe I should give you a name… But that’s a slippery slope. You’re only in my head. We have to remember that… Shit. It’s actually happened. I’m talking to an imaginary person. – Mr. Robot S01E01