Attn: Engineers – Stop Misusing ‘Utilize’
Posted by HokieTux on May 27, 2010 in General
Perhaps one of the most common mistakes I see in technical writing is the misuse of the word ‘utilize‘. It is sadly common for authors writing conference and journal papers to substitute the word ‘utilize’ for ‘use’, often because it simply sounds fancier. There seems to be a perception that if you describe your idea with convoluted, big words, then it will sound more intelligent.
False.
If your idea, design, or invention is truly innovative, then your writing should be just as impressive with simple and easy-to-read syntax and diction. Attempting to glorify your work with impossible-to-understand diction only alienates your audience and makes what is likely an already complicated subject even harder to understand. On top of that, ‘utilize’ does not have the same definition as ‘use’.
Here is a real example from an actual published paper where the author goes totally overboard while trying to sound intelligent. The result is that the author just sounds like an idiot. This example is a little worse than what most people would write, but it does illustrate how far some authors take this practice. Here it is:
“The tests illustrate that the waveform utilized the correct interfaces and properly utilized them.”
Impressive, right?
There is a Wiki Answers article which perfectly summarizes the proper use of ‘utilize’. Here is what it says:
“Use” and “utilize” are often used interchangably, as synonyms, usually to turn a boring one-syllable word into a fancy-sounding three-syllable word. Unfortunately this practice has diluted the original meaning of “utilize.”The real difference is “use” means what you think it means, to employ for some purpose, whereas “utilize” means to use something for other than its intended purpose, or to give something a purpose that it is not normally thought to have. …
Example:
“We used the bus to transport all the tour members.”
“We utilized the bus for shelter in the fierce, unexpected blizzard.”
In the first you are using the bus as… a bus, so “use” is appropriate and sufficient. In the second you are using the bus as a shelter, so you are giving it a utility, or purpose, that it does not normally serve.
Try not to use “utilize” when you really just mean “use.” You may think it makes you sound sophisticated to simple people, and it probably does, but it also makes you sound simple to sophisticated people.
I think the closing line is perfect. You may think you sound intelligent by using ‘utilize’, but you sound pretty stupid to people that are intelligent.
A Great Article About Use vs. Utilize
A 12-Year Old Piece About Use vs. Utilize
OS X ‘delete’ key not working in Terminal Fix
Posted by HokieTux on February 3, 2010 in Hacks
By default, the OS X terminal will not send the proper ‘^H’ character when you press the ‘delete’ key. This isn’t a problem if you are working locally, because the terminal knows how to interpret local keystrokes without issue.
However, if you are SSH’d to a remote machine and/or are using GNU screen, there is a chance that you will no longer be able to backspace properly.
Luckily, the fix is simple. Head into the Terminal preferences, click the ‘Advanced’ tab, and check the box about ‘delete’ sending the ‘^H’ character. It should look something like this on Snow Leopard:
And that’s it! You should be all set =)
Using <complex> vs <complex.h> with g++
Posted by HokieTux on February 1, 2010 in Code, Hacks
Long story short: Including <complex.h> in your C++ source file does not include the C language complex.h header!
After fighting with g++ to get the proper complex numbers implementation working in a recent project of mine, I thought I would post what I discovered in case anyone else finds it useful.
It is fairly common knowledge that use of C-style standard headers in C++ is considered deprecated. By this I mean that if you want to include <stdio.h>, a C library, in a C++ source file, then you should actually include <cstdio>. The same exists for other libraries, e.g. <math.h> is <cmath>, <signal.h> is <csignal>, etc. This has been phased into recent versions of compilers with varying levels of enforcement.
However, not all standard C libraries have been moved over to the new standard. For a long while, <stdint.h>, which includes bit-specific datatype declarations like int32_t and uint64_t, did not have an equivalent <cstdint>. In these circumstances, including the originial <stdint.h> worked just fine, and included the C language header as expected.
This is not the case with <complex.h>.
The C++ standard implementation of complex numbers is a templated type. To declare it, you do something like:
complex<float> mynum(2.0, 3.0);
The C version of complex numbers is an IEEE standard (1003.1), and is declared like so:
complex double mynum = {2.0 + 3.0*I}
If you want to use the C version, you might think all you need to do is #include <complex.h> in a C++ file… turns out that doesn’t work. For whatever reason, g++ will include the C++ templated type rather than the standard C language type.
If you want to use the C version, the easiest way I’ve found is to simply give the absolute path to the include header, like so:
#include “/usr/include/complex.h”
I ended up using the C++ version anyways, but while I was attempting to use the C implementation, this one certainly had me confused for a bit.
Back Up & Running
Posted by HokieTux on November 15, 2009 in News
So everything seems to be back up and running again.
I use Slicehost to host the server for this site as well as a few other things. Slicehost, as far as I’m concerned, is fantastic and I would recommend them to anyone (note: not affiliated – just a satisfied customer).
For the past few months, I have been unable to do any serious upgrades on my slice – everytime I attempted a system upgrade, my slice would not come back up after a reboot. In addition, every few weeks, my slice would crash altogether – weird filesystem stuff going on.
Anyways, I’ve been simply restoring from backups of my slice every couple of weeks for the last few months to keep the site alive until I could find time to fix the problem, whatever it was. Turns out the problem was that I simply wasn’t using the Slicehost Manager properly. I had completely missed a little tab where you specify a kernel for your slice:
Simply setting this to the appropriate kernel, allowing the reboot, and then doing a system upgrade fixed everything, hah. So it goes.
Well, that said, I still need to post some new content. I have some good ideas for a few posts… I just need to find the time =)
A Guide to Setting Up Git, Gitosis, and Gitweb
Posted by HokieTux on March 3, 2009 in Guides
I have recently migrated to using Git for my (D)SCM-of-choice, and so far, I am extremely happy with it. I am hosting public and private Git trees on this server, and using it as the ‘central node’ for most of my coding and configs. I am using Gitweb for the web interface and Gitosis to manage secure commits from multiple users and machines. While getting Git set up was a piece of cake, getting everything else up and running wasn’t quite so smooth. This is a guide for getting the whole system up and running quickly and easily so you can get back to hacking =)
The meat of this post is about Gitweb, for which there seems to be far fewer useful guides and docs out there (relative to the number for Git and Gitosis). This is also the part that I found the most difficult and time-consuming. Hopefully, with this guide, it’ll be a much smoother ride for you.
Why I Use Git
There are a metric tonne of sites about why you should use Git, so I won’t try to convince you. I will, briefly, however, go over my reasons for choosing it:
- People and projects I am working with are using it – This is extremely important, especially if you plan on making any sort of contributions to these projects. As a computer engineer, I have a significant amount of interaction with Linux kernel trees (like the one over at Xilinx, for example), and nearly all such projects are using Git as their SCM.
- It works with projects that aren’t using it – The only projects I work with that aren’t using Git use Subversion. Thankfully, the ‘git svn’ tools work beautifully, and allow me to use Git to interact with svn repos. This is very significant, as it allows me to further simplify my workflow into one common thread.
- Git is quickly becoming a valuable skill – Knowing SCMs has been, and always will be, valuable skills to employers. The situation used to be that knowing CVS was a major selling point. Then it moved to Subversion. People are starting to realize the benefits of distributed SCMs, and focus is transitioning to DSCMs. Of these, Git is at the fore-front in terms of user base and company adoption.
- It is small & fast- I don’t have infinite bandwidth, and I have a lot of interaction with code repositories. Being able to clone Git trees and commit new
…
