Category Archives: Tools

The Freedom of Software Development

Published / by Andrew

One of the worst things of using a computer is having to work with tools that you don’t like. Sometimes it’s just because you don’t think the same way that the original devs did, or because the devs are stubbornly holding to a feature that’s widely-acknowledged to be broken.

The most freeing part of software development is the ability to make your own tools. That’s not to say that you’ll never be dependent on other people’s work, of course, but, if you don’t like the tool that you’re using, you have the freedom to make a new one if you’re willing to spend the time to do it. A good example of this would be NeoVim.

Case in point, the image above. The autocorrect in Google has been driving me absolutely insane for years. I’ve been using DuckDuckGo for a long time because the autocorrect is less aggressive, but it’s still pretty bad.

Then I noticed that the only thing that Google does in the get query (though I don’t know if it’s really a “get” query, since it starts with a ‘#’ instead of a ‘?’) to disable autocorrect is a simple flag: “nfpr=1”. That’s it. Adding that programatically is a very simple task.

So, I set out to create that very simple webpage. Apart from the Rage comic that I added for kicks, it’s just a single HTML file. I didn’t even separate the CSS and JS files. It was really that easy to do, but I wouldn’t have known that if I didn’t already know how to use JS. When I set Firefox to use this as my default search, it uses Google without autocorrect.

And that webpage is public. There are a couple of reasons for this. The first is that, I may as well share it, because I know I’m not the only one aggravated by this. The second reason is that I can now use it anywhere. From my phone to my office (if I can convince IT to let me through to it).

I relish the freedom that I have as someone with knowledge of software development, and I hope to learn more on a wide area of topics so that I can continue to create and tweak tools to my own purposes.

Shell languages are the gifts that keep on giving

Published / by Andrew

I am currently downloading every episode of The British History Podcast. I wrote a small BASH script to do this:

function downloadFullPodcast(){
    xhtml=$(wget -qO- $1)
    regex='.*?\.mp3'
    readarray links < <(grep -oP "$regex" <<<"$xhtml")
    arrLen=${#links[@]}

    i=0
    tempStr=${links[i]}
    #dmz1
    while [ "$tempStr" != "" ]; do
        regex='>.*<'
        tempStr=$(grep -oP "$regex" <<<"$tempStr")
        len=${#tempStr}
        mp3url=${tempStr:1:len-2}
        numDum=$(($arrLen-$i))
        number=$(printf "%0*d" 4 $numDum)
        wget -qO $number\.mp3 $mp3url
        ((i++))
        tempStr=${links[i]}
    done
}

downloadFullPodcast "https://feeds.feedburner.com/TheBritishHistoryPodcast"

This isn't exactly a novel idea, but I'm surprised at how few devs I come across that have any interest at all in using the command line languages or other scripting languages.

Even before I became a developer, I recognized how powerful and useful the command line could be. When I was an undergrad (with no coding experience whatsoever at the time), someone on a Linux forum helped me to write a BASH script that played a random episode of Scrubs in the Totem player, and I ran this with KAlarm in lieu of an alarm clock. (In fact, I might want to set that up again with a Raspberry Pi or something.)

These days, I live in the command line, whether BASH at home or PowerShell at work. I couldn't go without it. My primary tools at work, apart from Firefox to test the code, of course, are PowerShell, Vim, and MySQL Monitor. All three of these are CLI tools. (Also, notably, all three of these are scriptable.) At home, it's the same, except for BASH instead of PowerShell (and having the PERL engine for the grep command is really nice).

My office's database is separated into almost 50 separate ports, so it's not uncommon for an inconsistency to appear. For example, one dev may add a column to one database and none of the others, then update the code in SVN to match. This causes mysqli to freak out when it can't find a column. It's not uncommon to see emails to the entire dev team saying "Could whoever is in charge of column XYZ add it to all levels?"

I guess the people sending out these emails must refuse to use the command line. I wrote a simple PowerShell function to run a command on all databases. With that function, it's a two-command process to run "SELECT table_name,column_type FROM information_schema.columns where column_name='XYZ'" across all databases to find what table to add the column to and what type to use, and then add the column to that particular table across all of the databases. This takes about 60 seconds, so I've never felt the need to send out a mass email to every dev to add a column. I just find what needs to be added and add it myself.

I won't go so far as to say something obnoxious like "You're an idiot if you're not using CLI tools," of course, but I do think that these tools offer advantages that a lot of people seem to miss. The most useful tools that I've built for myself have been PowerShell, BASH, and VimScript functions.

What I find is that having a strong grasp (or even a mediocre grasp) of scripting languages like command line languages can really help you to complete a lot of tasks that GUI tools just aren't designed to handle. This is because these tasks are too nuanced for the designers of the GUI tools to have anticipated. The example that I have above with the British History Podcast is a decent one. I did that because my podcatcher program on my phone is great for listening to the most recent podcast, but not so great for binge-listening archived podcasts. I decided to get all of the mp3s so that I could put them in my audiobook reader instead. This could be done in a better scripting language like Python or Ruby, of course, but that's just using different scripting language-- The process remains the same.

Tip 21 from The Pragmatic Programmer by Hunt and Thomas is "Use the Power of Command Shells." "Gain familiarity with the shell, and you'll find your productivity soaring," they say. I would extend that to other scripting languages, and I think Hunt and Thomas would, too, because, in the same chapter, they recommend using a text editor that's programmable. I say, if you're interested, give it a shot. You don't really need to buy a book to learn them (the one PowerShell book that I bought turned out to be a complete waste). Just read a few brief tutorials online, and then you can Google everything else you need to learn as you go. It's been really beneficial to me.