While perusing through my favorite web comics, I saw this xkcd comic about automation. While I have agree with Randall Munroe's comments on how attempting to automate can go comically wrong, I also believe that it can be used for good. Also, I understand that the comic in question is attempting to be funny, and it is showing the worst sides of programming for a laugh. However I feel that it is an excellent opportunity to explain my thoughts on why being able to write simple automation style programs is good.
What I am getting at is that simple scripts or programs can be written by almost anybody, and even the simple ones can automate tasks, which can, in the long run save time. And yes, sometimes the research required to learn how to write these scripts can take a lot more time than it takes to complete the tasks, however I believe that the skills learned in taking these steps can be useful elsewhere in life. Lets say for example, that I like to take photographs, and each time that I get back from shooting, I have to download and rename the photos from their camera name (for example, DSC_001) to something that makes a lot more sense (hawaii_vacation_jan2014).
Normally I would do this through the Finder (I'm using a Mac, the Finder is the equivalent of Windows Explorer) by selecting each file, then pressing the return key, entering the new name, and then pressing the return key again. While that doesn't seem like a lot of work to do for each file, it does add up after hundreds of files. To the point where I might decide to delete files that I would otherwise keep because I want to get done sooner. There is another problem of doing this repeating task manually. Errors can creep in because I am writing the name by hand for each file. Every file is a chance that I will misspell a word, forget to put in the number correctly, or even forget a dash. The results of that wouldn't be horrible, but they would make things inconsistent, which is what the naming scheme is trying to do. The solution then, is to write a program to do the renaming for me. As long as I write the program correctly, then the result will be consistent.
In order to write this program I would need to research what programming languages can see the number of files in a folder, read their names, keep track of the number of photos processed, change the file names, and copy them into another folder of my choice. It would also be nice if the program would ask me what the new naming scheme is. I would choose to do this with a Terminal scripting language called Bash (Bourne again Shell).
Obviously the next step is to learn how to program with Bash. I can do this by reading a book from the local library, or by reading tutorials on the internet. There really isn't a correct way to go about this, however it is a good idea to have a project like this one in mind when attempting to learn a new programming language. That way, as you learn how to do things, you can implement them into the program you are writing.
The next step is to plan out the program. This is a step that a lot of people skip; many people prefer to get right into programming and "code as they go". However this can be problematic, especially if you are new to programming as it can lead to feature creep. Feature creep is what happens to programmers who decide to add new features in the middle of programming. While it can work out ok, I have seen projects abandoned because the code got too messy due to all of the new expansions that the programmer realized would be nice to have without planning these new features out. While making my program, I'll write out a list of everything that I need the program to accomplish, and then I'll start writing pseudo-code (Using english sentences instead of the actual code). This way, if I realize halfway through I could add a really cool feature, then I would be able to incorporate that into the planning and not break any of the logic of what I have already done.
Another step that a lot of people skip is testing the logic of the planned code before writing the code. What I mean by logic, is what the code is going to do, as opposed to the code itself. A program that runs without error, but doesn't have the right output is said to have a logic error. The opposite would be syntax, but we aren't on that step right now. Now, we are focusing on the logic. We need to run through a few (or a lot for complex projects) examples in our heads to make sure that what we are planning on doing works. I do this by talking myself through the pseudo-code and pretending to be the computer running it. I would also make sure to try things that should fail, like running the program with no files in the folder. If I was concerned that my program could delete files, then I might have a friend look at my code to make sure that it was safe.
Finally, I can start programming. And now that I've done all of the hard work, all that is left is the syntax. Making sure that the program is understood by the computer. Since I trust the logic, I don't need to worry about that. If I get any ideas that could be added in, I will refrain from changing my plan, but instead I will write them down for the next version (or I will go back to the beginning and start over again with the new ideas added in). When I program in this way, then I often find myself writing the program without errors on the first try.
The best part of writing these programs is using them, it can be very rewarding to see all of your hard work pay off. Another benefit is that if I need to write anything like this in the future I'm set; I can pull out this code and modify it for another project quickly for the new project. Finally, I now have a new skill to use, be it at work or at home. These skills can save time and money for a company, and can make me more employable.
No comments:
Post a Comment