Tag: cleanup

DRYing up tasks makes life easier

When writing scripts that perform the same task over and over again with different parameters, it is tempting to just cut and paste. Here’s an example of a bash script:


#!/usr/bin/env bash
grunt make_magic --dir=/foo
grunt make_magic --dir=/bar
grunt make_magic --dir=/lorem
grunt make_magic --dir=/ipsum
grunt make_magic --dir=/magnum
...

Imagine that goes on for hundreds of directories!

This isn’t very DRY. If we wanted to add an extra parameter to the grunt command, we’d have a lot of editing to do.

If we needed to do another command on those very same directories, we would have to enter the directory names again. As you can see, it would be very easy to forget to add all of them.

DRY

DRY stands for “Don’t Repeat Yourself”. If some code or commands are duplicated elsewhere, that’s a sign that there are inefficiencies in the code.

The idea behind this is to pull out common code into functions/methods. When a change to that code is required, it only needs to be made once. If a bug is identified in the code, once it is fixed, it is fixed “everywhere”.

DRYing

Let’s take the example above and dry it up. We have to run the same command with different parameters (directories), so we will create an array of directories:

DIRS=( foo bar lorem ipsum magnum )

Now we write a “for…each” loop to do something for each element in the array:


for thedir in "${DIRS[@]}"; do
grunt make_magic --dir=/$thedir
done

This works on each element of the DIRS array and assigns it to thedir variable, which is now available inside the block.

Using this technique, it is very easy to add additional commands and/or directories.

Adding defensive sanity checks

I recently needed to make a set of several favicons, so I went to the web to see if anyone had a script I could borrow steal.

Sure enough, I found one written by Joshua McGee: “Create a favicon with ImageMagick” (not reproduced here for copyright reasons).

It was a simple enough script, just a series of escaped commands. I noticed, however, that it assumed a few things:

  • An image file was specified on the command line,
  • The image existed, and
  • Imagemagik was installed.

In other words, the script was not developed defensively. This makes sense: it was just a bang-out.

The script had no inline documentation, and if a favicon file that already existed in the current directory would be silently overwritten—not good.

I’m clumsy: I delete and overwrite files all the time, so I could use a little help. Maybe I can tidy up the script?

Ensure command-line parameter

Whenever your script requires a command-line parameter, display a help if it is not provided or is the wrong type. Why? Because in 6 months you will forget how to use it.

if [[ -z "$1" ]]; then
		echo -e "\nUsage:\n\t$0 image.png\n\n\tWhere 'image.png' is ..."
		exit 0
fi

Easy! The -z means “if empty”. And $1 contains the first parameter. When we display the error message, we use $0, which contains the script’s filename and path. So if I run my script like this “/foo/bar/somescript”, that is what $0 will display.

Ensure Source Image Exists

# Check to is if source file exists
if [[ ! -e $1 ]]; then
		echo -e "\nFile '$1' not found."
		exit 0
fi

I added the comment because I can never remember what “-e” means. When scanning the source, I can quickly tell what this section does without reading much further into the code.

Ask the user before overwriting

# Warn if favicon.ico already exists in current directory
if [[ -e favicon.ico ]]; then
		echo -e "Warning:\n\tfavicon.ico exists in current directory."
		choice "Overwrite? [y/N]: "
		if [ "$CHOICE" = "y" ]; then
				echo "Overwriting favicon.ico"
				rm favicon.ico
		else
				echo "Exiting"
				exit 0
		fi
fi

Another defensive-coding best-practice. Before doing anything destructive that isn’t the primary purpose of the script, let the user decide if they want to proceed. By “primary purpose” I mean that the only reason someone would run the script was to destroy something.

What’s worse is destroying something silently, which is why I let the user know when we overwrite favicon. Keeping the user informed needs to be balanced with flooding the user with too many messages.

Note that the “choice” statement above isn’t a build-in command, but a very handy one I got from O’Reilly’s “bash Cookbook”.

Is Imagemagick installed?

Actually, I don’t care because I use it so much that I always install it on whatever system I’m using. An approach I might take would be

type mogrify

And compare the result.
A good discussion of self-documenting code vs. inline documentation may be found in chapter 11 of: McConnell, Steve (2004). Code Complete (2nd ed.). Pearson Education. ISBN 9780735636972.

Bulk process RAW image files

Recently I had to convert about 250 RAW image files to PNGs. For neatness, I wanted to convert the upper-case filenames the camera assigned with a lower-case name.

A little bash script-fu is all it took:

clean_pics.sh

#!/bin/bash
# Extract from SD Card
for i in /Volumes/SDCARD/DCIM/100ND40X/DSC_0*; do
 filename=$(basename "$i")
 lower_file="$(echo $filename | tr '[A-Z]' '[a-z]')"
 # verify it doesn't already exist
 newfile="${lower_file%.*}.png"
 echo -e "Processingnt$i tont$newfile"
 if [[ -e $newfile ]]; then
  echo "****SKIPPING"
 else
  convert "$i" "$newfile"
 fi
done

echo -e "Detoxing..."
find . -iname "*.png" -exec detox "{}" ;

echo "Procedure complete."

(“SDCARD”, etc is the path to the source files)

Once the script was up and running, it took about 1/2 hour to process all the files. Meanwhile, I was off doing something else!

Do it correctly: decoupling presentation from content

Box model in CSS

Box model in CSS (credit: Wikipedia)

I recently ran across the anti-pattern of what I see as a common problem amongst designers and developers: coupled presentation and content. I’ve found that decoupling the presentation from the content makes things much easier to write, maintain and expand.

Here’s a simple example:

HTML

<section>
    <div class="margin-top-10">Lorem Ipsum</div>
</section>

CSS

.margin-top-10 { margin-top: 10px };
.margin-top-20 { margin-top: 20px };
(etc)

Take a look at what is going on here: we’re adding a 10px margin to the top of the div. DON’T DO THIS. You want your class names to be contextual, not descriptive of the style.


Rule of thumb

To change the layout, you should only have to edit the CSS, not the HTML.

Here’s where our anti-pattern falls down and will cause grief.

  1. You decide to adjust the positioning of the section. You can:
    • Edit the CSS, changing the class’s margin value and breaking every other element that uses that class.
    • Edit the HTML create a new class, then edit its CSS class definition. If you have to experiment with different margin values, you’ll need a LOT of classes. “Will 14px work or 15px? What about .25em? Argh!”
  2. You can’t have too many attributes in each class, because they will have unintended consequences for the other elements that are using them. Add a red border to one class because you need a border for a specific element, now you have red borders on ALL the elements that share that class. So, you’ll have to have many single- (or few-) attribute values, and include all of the necessary ones on the required HTML elements.
  3. The violent psychopath maintenance programmer (who knows where you live) will kill you in your sleep. You have made her job insanely hard by turning this:
<div class="margin5 blueborder mediumwidth floatingleft" ...

into this

<div style="margin:5px;border:3px blue outset;float:left;width:75%" ...

for no good reason.

The Cure

Think about the element in terms of content or a functional space. What is it and what does it do? In our example above, let’s assume it is the lede section of an article. Then we would do:

HTML

<section>
    <div class="lede">Lorem Ipsum</div>
</section>

CSS

.lede { 
  margin-top: 10px;
  border-bottom: 2px #9fe2f9 outset;
  float: right;
  position: relative;
  width: ...
};

By decoupling the content (div) from the presentation (style-dependent class), we are free  to adjust the style of that element by making whatever changes to the CSS and leaving the HTML alone.

“But,” you shriek, “I have common elements for everything! Rounded corners! Gradients! (except IE…) Et cetera!”

 

For this, we will turn to our trusty companions Less and/or Sass in a future post.

SASS: Style w/ Attitude

SASS: Style w/ Attitude

Enhanced by Zemanta