Most people in IT, especially security, have worked with some form of code. Whether it's for automating system tasks, performing network monitoring or developing full-fledged applications, understanding certain scripts is necessary to keeping support running every day.
Time is short, though, so finding ways to optimize your scripting tasks (without compromising the quality of your work) is important.
System Automation Scripts
If you work with systems, the shell environment quickly becomes your natural habitat. Keep in mind you can make that beloved text console more powerful, helping you perform system automation processes and giving you extra time for the core tasks with just a few simple tricks.
Instead of repeatedly typing different series of complex commands and retyping them a couple of times because you made an error, you can make these complex commands accessible through a simple alias.
An alias is basically a shorter alternative for a command that you place in a config file, ~/.bashrc, in your home directory. To get the used space per folder, for example, one level deep can be done with an alias:
alias du_1='du -h --max-depth=1'
A useful shortcut is showing the hidden files in a directory:
alias ls.="ls -d -l .*"
Another clutch shortcut for making the console more useful is running your scripts in different virtual screens. This doesn't mean different terminals, but rather multiplexing one console between several processes. A practical use is having the output of one script running in one screen and then switching to another screen for additional debugging. Screen is available as a package in your favorite Linux distribution, and you can start it with the — you guessed it — screen command.
When that screen has started, you just have to launch your script. Once launched, you can keep the script running and detach from its visual output with CTRL-A d. Having an overview of the running scripts is done via:
Of course, having the script running without being able to see what it's actually doing is pretty useless. You can pick up its status by reattaching to the screen with:
Improving How You Deploy Scripts
If you develop software in teams, the process of accepting code changes, reviewing them, making a new build, testing the build, publishing the code and then informing the contributors that their change request has been accepted is a tedious and time-consuming process. Devops doesn't want to lose time on tasks that can be automated, either. They'd prefer to push a button (in this case, click a button) and have the new build deployed.
Automation requires the right toolset. And there's a tool for (almost) everything. For example, with Travis CI you can:
- Review a pull request (someone proposes a change to the code).
- Verify if it can be included in the code tree.
- Check if the build works.
- Confirm the pull request.
- Inform the contributors.
It might sound obvious, but reinventing the wheel is a waste of time. So why would you not use that same principle when doing code development? A lot of the things you want to resolve might have already been done by someone else. Don't give yourself more work; use their expertise.
Reusing open-source code is a great move for this purpose, and GitHub has a very large set of open-source projects waiting for you to be included in your projects.
However, sometimes you need a scripting solution for one specific problem. This is where "code snippets" come into play. You can build up your own repository from scratch, but what would keep you from making use of a community-driven effort?
One of the most popular efforts is Snipplr. This site provides code snippets for different code languages (HTML, Ruby, PHP) that you can immediately include in your projects.
As a coder by any right, you don't have to stay on the beaten path. Integrate the tools and tricks that are out there and make more room for your core task — developing (and supporting) the stuff that already works.