Originally publish at: Jobsity Blog
Yes! I'm a lazy dev and I like it.
Don't misunderstand me I haven't said I'm not productive, it is the opposite, let me explain myself.
I hate doing that kind of repetitive task on a daily basis, I'm always looking for challenges, something that really puts my brain to work and then gets the best of it by figuring out creative solutions.
That's why I pushed myself through the way of automating repetitive tasks with scripts 😜
Scripts have helped me a lot to perform repetitive tasks and even to increase my productivity since I don't have to worry on spending a lot of time doing the same and focus on what's worth.
It might be tough to start but if you want to become a lazy dev too just let me give you some advices on tips you should keep in mind whenever you're writing a new script
Tips
- Use a common scripting language known by the team
- Keep it short, clean and understandable
- Follow the same pattern in your scripts
- Document your scripts
Once you identify a task where you could create a script for, please don't hesitate to automate it, your team and even you're going to love it.
What language should I use?
Well I prefer writing my scripts using bash, it's simpler, easy to learn and it comes with all the Unix based systems 😄
Javascript could be an option as well if your team is used to javascript.
Personally I've written most of my scripts in bash and some others with python.
One script to rule them all!
Please don't try to write a script to make everything, it's better to have several short and maintainable scripts well documented than a big bunch of code trying to control the world.
If that's what you want you might consider to write a complete CLI program instead. Though I wouldn't recommend
Patterns would make it easy
As a rule of thumb try to keep patterns on your scripts, that'd make it easy not only for you to start creating a new script but also for your teammates to understand how the script works.
The pattern I like to follow is flag's parameters where you pass them to the script as flags, for instance if you want to pass an external file path you add a flag like -f or --file if you prefer the full flag.
Document your scripts
Best way to document your scripts is a self explained code but we usually just need a quick documentation of how to use it without need to checkout the code, that's why I'd recommend you to always add a help -h|--help command.
Templates!
For those who reach the end I'll give you some templates you could use to start creating your scripts, and believe me this has helped me so much, improving my performance and accelerating several tasks in the projects I've worked on.
And on top of that, it makes my clients happy when I build tools to increase the development pace -- and it makes me happy to reduce the need to create and re-create those stressful repetitive tasks we've all grown tired of creating!
For those who reach the end I'll give you some templates you could use to start creating your scripts, and believe me this has helped me so much, improving my performance and accelerating several tasks in the projects I've worked on.
And for sure it makes my clients happier when I build tools to increase the development pace of those stressful repetitive tasks we've gone through.
Bash Template
#!/usr/bin/env bash -e
PARAMS=""
COMMANDS_FLAGS="
Help:
In order to pass arguments use '--' after the command like: npm run script-name -- -f
-f|--file: Pass file path
-o|--output-file: Sets the output file’s name
-h|--help: Lists help options
"
# VARS
FILE=""
while (( "$#" )); do
case "$1" in
-f|--file)
FILE=$2
shift
;;
-h|--help)
echo "$COMMANDS_FLAGS"
exit 0
;;
-*|--*=) # unsupported flags
echo "Error: Unsupported flag $1" >&2
exit 1
;;
*) # preserve positional arguments
PARAMS="$PARAMS $1"
shift
;;
esac
done
# set positional arguments in their proper place
eval set -- "$PARAMS"
# execute your script
echo "Running script..."
if [ "$FILE" = "" ]; then
echo "File not found."
else
cat $FILE
fi
Alright let's split the code, first we will need a variable to store the positional parameters $PARAMS, those are the ones its order is important
COMMANDS_FLAGS is basically our documentation we're going to display when the --help flag is passed or if the passed params does not supply the minimum requirement.
Always supply short and full flags to your scripts, believe me users are going to love it.
Then you'd want to define all the default values for the vars you're using, because next is where most of the magic happens...
Here we're parsing our flags and storing the right values in our variables depending on what needs to be done, you can add as many flags as you wish.
Just add a new case like:
-f|--flag)
FILE=$2
shift
;;
Remember the flag's value for non-boolean flags is going to be stored in $2 var.
And don't forget the last two conditions:
-
-*|--*=)is meant to throw an error when a flag is not valid -
*)is meant to concat the positional params
while (( "$#" )); do
case "$1" in
-f|--file)
FILE=$2
shift
;;
-h|--help)
echo "$COMMANDS_FLAGS"
exit 0
;;
-*|--*=) # unsupported flags
echo "Error: Unsupported flag $1" >&2
exit 1
;;
*) # preserve positional arguments
PARAMS="$PARAMS $1"
shift
;;
esac
done
Also after parsing the your flags remember to put back the positional params on its place with:
eval set -- "$PARAMS"
And that's it! Now you can start running your script based on the conditions set by the flags the user passes or throw an error if the user passes each other exclusive flags, it depends on how you define your script after that.
Bonus! (For the Laziest Devs Only)
If you'd like to add more life to your scripts -- like showing an error message in red or a piece of advice in yellow -- I suggest you to define your colors like this:
red=$'\e[1;31m'
green=$'\e[1;32m'
yellow=$'\e[1;33m'
blue=$'\e[1;34m'
magenta=$'\e[1;35m'
cyan=$'\e[1;36m'
purple=$'\e[1;34m%-6s\e[m'
end=$'\e[0m'
The end var is to define where to stop painting your text, and it's used like:
printf '%s\n' "${red}Error! There's nothing to be updated!.${end}"
Well and if that's not enough for you, you can also create helper functions to help you better build your script or even better to add some enhancements to your script like the power of logging the batch of commands to be run in case your script performs a sequence of commands.
That way the user will be able to see before running the script what is about to be executed, I've made that abstraction for you, so don't worry just use it.
run_command() {
if [ "$TEST_OUTPUT" = true ]; then
echo "|$ $@"
else
printf "%s\n" "${blue}running -> $ $@${end}"
eval "$@"
fi
}
This function as you can read the code requires a variable called TEST_OUTPUT, you can define the flag whatever you wish I've done it with capital letter T -T|--test
And what it does basically is if true then echo the command about to be run otherwise print the command and also execute it.
A simple use example would be if your script wants to run git status to check out if there's any change then you'd run it with the helper function:
run_command "git status"
Note
With python you could use argparse to actually parse your flags in a fancy way than bash does it if you're more a python enthusiast
Get Lazy!
Well, that’s it, friends! Hope this could help you improve your productivity and find your way to being a truly lazy developer. If you follow these tips, my advice, and play with my templates, once you identify a task that can be automated by a script, you’ll be able to without much effort. And when you do, don't hesitate to get it written. Your team, your clients, and your lazy nature will thank you later! 🤗
Top comments (2)
I'd say you're more of a resourceful developer rather than a lazy one. I wholeheartedly agree especially with your point about documenting the script. It always makes a great deal of a difference to have proper fleshed out documenation for a tool or library.
This isn't laziness. Laziness would be holding on to the boring busy work so when you don't feel like doing crap you just fall back to the busy work. Even lazier would be to hoard the scripts to yourself and tell everyone you're doing the busy work, run it automatically and sit back pretending to work.
You're not lazy. You love working. You just hate "working for the sake of working."