Ask HN: Small scripts, hacks and automations you're proud of?

When I run a command that takes long, I run it (I use fish but any shell has an equivalent) like:

./mycommand && beep

or

./mycomand && play something.wav

It can be useful If I am doing something else on the computer or outside of it. It saves time from checking over and over if the command finished.

I use it not for just persisting commands but leaving comments for future me such as github personal tokens or api keys etc.

[0] https://eli.thegreenplace.net/2013/06/11/keeping-persistent-...

At my first software developer job (small company of about 400 people in a country in Asia), there was a company wide requirement that our working hours should be logged into OpenProject.

Logging the hours turned out to be painful because the UI was clunky. Too many clicks and page loads were needed. You probably see where this is going.

Iteration #1:

After working there for a year, one evening I checked out the API for OpenProject. The web interface itself includes a place to set an access token, and examining the browser network tab gave me additional information that I needed.

In about a couple of hours, I wrote a quick and dirty python script that would read a text file formatted this way:

     
     
   etc

What took 15 minutes every evening now only took 30 seconds!

Having said that, this was a quick and dirty script, and although it worked fine I didn't want to spend time cleaning things up.

Iteration #2:

30 seconds was too long!

This was because for every line in my input text file it would establish a new API connection. So if there was 5 lines of input, it would make essentially the same 5 API calls.

(There's probably a proper way to bundle all input into a single API call, but that's not the approach I took.)

I realised that my workload is embarrassingly parallel. I altered my script to process each line in parallel.

What took 30 seconds on a typical day now only took like 5 seconds! (Depending on input size of course).

(My dirty script became dirtier in terms of code quality.)

Iteration #3:

Even though it took literally just 5 seconds, manually running the script every evening was a chore!

So I setup a cronjob to run at 6:05 pm everyday to run this automatically. 6 pm is when I usually call it a day.

On the occasional day that I stay a little bit longer, I just had to log in manually to OpenProject and do the necessary adjustments. No big deal.

Iteration #4:

Before the aforementioned cronjob ran I'd like to review what it's going to push. I discovered the notify-send utility in Linux that I can use to display a popup.

Wrote a crontab entry to show me the contents of the input file in a popup a few minutes before my other script ran.

Iteration #5:

(By this time I've been relying on this python script for over a year).

OCD finally became unbearable about the crappy code quality (even though I never actually had to look into the code at all for like 9 months by this point).

One weekend I rewrote everything in Go (to take advantage of goroutines, since my program could readily use those — and because parallel programming in other languages I knew felt like an afterthought, though that's a topic for another day). My keys and such things were now in a proper config file.

The Go program also ran without hiccups.

I left the place about 6 months later though.

It was fun!