Productivity

I like to open with a joke.  I won’t this time, I’ll close with one.  And then I will let Bob Newhart make it funny.

I have spent my entire professional career at here at SlickEdit, and almost from the start, I have handled our version control support.  This means a couple of things:

  • I have only used (on a day-to-day basis) the version control systems that we have used here at SlickEdit.  In the early days we used our mutli-file diff feature.  I prefer to think of this as a testament to how good our diff feature is rather than what you are thinking – which is probably “that is pure insanity”.  In later years we used CVS.  Eventually we moved to Subversion.  A little sooner than we wanted because of how it handles branches – this is another story.
  • Because I have to handle supporting them in SlickEdit, I have tested most of the free and commercially available version control systems (and a few that are no longer commercially available) on small source bases.  I have not actually used all of them, I have some experience with them.  The technical term for this in our industry is, “I know enough to be dangerous”.

We have 3 kinds of version control support in SlickEdit:

  1. Basic “command line” support, where we will run your checkin command according to a specified command line where the file name is filled in.
  2. SCC support – For version control systems that have an SCC provider, we will communicate with it and provide the level of support that SCC allows for.  This can be frustrating because if an SCC system crashes, it will cause SlickEdit  to crash.  This happens occasionally because SCC providers tend to do their testing with Visual Studio, and not other systems.
  3. “Specialized Support” – This is what we provide for CVS, Subversion, git, and now Mercurial.  We provide a GUI for viewing what files you have modified, what files are out-of-date (where possible), and a nice history dialog, among other things.  Initially we did this sort of support for CVS because it was a different animal than the systems supported by 1 and 2.  CVS is more directory oriented, rather than file oriented.  This is true of all of the systems that have this kind of support.
Unfortunately, none of our support is a replacement for a basic level of understanding of  how to use your version control system.  This is increasingly true as time goes on.  If you do not understand how Mercurial works, even though we provide some nice GUI interfaces, using Mercurial through SlickEdit will still prove confusing at best.  For Mercurial specifically, I would recommend the Joel Spolsky tutorial, especially if you are an experienced Subversion user, as it is tailored for that.  Joel’s assertion is that Mercurial is better.  As of this writing, I still prefer Subversion, but he makes some interesting points.  Either way, it is an excellent introduction to Mercurial.

So, now SlickEdit supports Mercurial, which a little different from git, which is a little different from Subversion, which was a little different from CVS.  So, if you’re sitting at home in your basement (excuse me, “office”) writing a version control system that is going to solve the issues with Mercurial that weren’t solved in git, that weren’t solved in Subversion, that weren’t solved in CVS, I would like to say (politely):

STOP IT!

Enough already.  The next version control system released needs to offer some real improvements over what is currently available.  Since I have to support it, I’ll be the judge of what is a real improvement.  Just contact me here… I’m easy to find.  I’ve been here my entire adult life, integrating version control systems, comparing files, and working on my manifesto (no, this isn’t it.  This doesn’t even scratch the surface).

P.S. The last couple of paragraphs are supposed to be funny.  I understand the differences/advantages of  these different systems, you don’t need to leave me nasty comments.

P.P.S. If you didn’t find any of what I wrote funny, take a few minutes and allow Bob Newhart to make you laugh.

If you don’t find this funny, I can’t help you.

Arthur C. Clarke’s “The Nine Billion Names of God” is one of my all-time favorite Sci-Fi short stories. (Spoiler Alert) To oversimplify the plot, Tibetan monks hire some computer engineers to put together a system that will print out all the 9 billion names of God, speeding up centuries of effort. Their belief is that after this task is complete, mankind’s purpose on Earth will be fulfilled.

And while my goals are not quite so lofty, I felt it important to demonstrate all the varied ways you can perform searches in SlickEdit. No promises that it’ll save you centuries of effort, but you may learn a few new tricks.

Please note that SlickEdit is a multi-platform, multi-language editor. This recording was done on Mac OS X, which is only one of the 9 platforms options that SlickEdit offers. View all available platform options here

In 1979, when several members of the SlickEdit team were not yet born, I remember when Voyager 1 started sending back pictures of Jupiter.  The big thing I remember is that we learned Jupiter has rings.  I honestly don’t know if astronomers knew Jupiter had rings and we were just unable to see them from Earth, or if this was a complete shock – but it was big news in second grade science class, where the previous week’s lesson involved gluing macaroni to plates.  Or maybe that was vacation Bible school.  I seem to remember life before my tenth birthday involving a lot of pasta getting glued to plates, and then being spray painted gold by a qualified adult.  Either way, the Voyagers (there were two, but for reasons that will become only slightly clearer later, we are focusing on Voyager 1 here).

In 1990 Voyager 1 was leaving our solar system.  To show the Earth relative to the vastness of space, Carl Sagan convinced NASA to have the Voyager take a picture of the Earth from a distance (according to Wikipedia) of about 6 billion kilometers (to convert to kilometers to miles, I normally look at the little dial on my speedometer, but since it doesn’t go up to 6 billion I had to look it up – this is roughly 3,728,227,153 miles).  The photo, where the Earth is barely visible as about one pixel, became known as The Pale Blue Dot:

How does this tie into SlickEdit?  Poorly, to say the least.  Normally I try to open with a joke, but today it was the Pale Blue Dot.

SlickEdit will let you compare two URLs.  This isn’t a well known fact, so I figured it was an appropriate thing to blog about.  For example, if you wanted to compare two versions of a Wikipedia page, you could fill it out like this:

The output looks like this:

I realize, of course, that the Wikipedia has a built in facility for this, but I needed an example.

I hope this comes in handy for you someday, or maybe you’ll just go, “Wow, that’s kinda cool”.

And as you continue coding (with SlickEdit, I hope), try to remember that all the files in the world that ever needed to be compared,  all exist on that Pale Blue Dot.  Work hard – don’t forget to live hard too.

P.S.: I only want to hear comments about files that were compared in space on the ISS, space shuttle, etc, from people who actually wrote the software, or were in space doing the comparing.  If you were actually in space comparing files, you may use a MUCH higher level of sarcasm in your response.

P.P.S.: The ISS was not there when this picture was taken, but either way I imagine:

  • It would not be visible in the picture
  • The space where the ISS and other satellites exist would probably be covered by the same pixel or so.


P.P.P.S:
If you did compare files on the ISS, Space Shutte, Skylab, or any of the Mercury, Gemini, or Apollo missions, please send us an autographed photo.

Next Page »