Uncategorized

The only proper way to finish the title sentence is “… I don’t write code”.  The way that it absolutely not be finished is “…I just use vi”.  Here are the reasons people seem to claim for using vi most often:

  • It’s always there.
  • It’s always the same.

But there’s more to it than just that.  Insisting on relying on vi for your editing needs is a pride thing.  The pride of walking into the wilderness with nothing but a knife.

That’s right.  We all want to believe we’re able to rush out into the wilderness with nothing but a knife, able to survive for days like John “Yes, I do have a first name” Rambo.  After all, it’s not just a blade.  It also has a compass, a couple of waterproof matches, and a needle and thread in case we need to stitch a large gash up ourselves.  You picture yourself, looking rugged with a headband and makeshift burlap shirt, running through a rocky ravine and stopping to check the compass built into the end cap of the handle (an image which I looked for for literally hours, impeded by copyright police and the fact that I can’t remember which Rambo movie it was in – so please take a second to paint the mental picture).  The truth is you look more like Michael Scott out in the woods wearing his pants on his head (an image I spent absolutely no time looking for – if you’ve never seen The Office (the U.S. version), Michael Scott is a man who is far too dumb to breathe, and he tries to prove he is clever enough to walk into the woods wearing just what he has on and survive.  He’s not, and somehow he winds up wearing his pants on his head.  It is marginally funnier than it sounds).

So, we’ve established that vi is like a survival knife with a blade and little else except a compass and some waterproof matches and enough needle and thread to stitch up a cut yourself.

A slightly more acceptable answer for why you don’t need SlickEdit is that you use whatever editor is included in your modern IDE.  The IDE editor tends to be sort of like a Leatherman tool.

(Leatherman is a trademark, but I think they were first in this space, I’ve used their products for over 20 years.  Although I am not a paid spokesperson, I am completely willing to be.  Just contact me here by leaving a comment below).  The Leatherman type multi-tool is sort of like a Swiss Army knife that is actually usable.  It has usable screwdrivers (different types and sizes), pliers, wire cutters, scissors, a saw, and of course a knife. They have different models that have different types and numbers of tools, and any knife maker worth their salt has their own version.   And these can be used for more reasonable tasks.  I’ve never had to stitch myself up, but I have found myself needing pliers, a screwdriver, file, saw, etc.  You could actually use one to perform an emergency car repair.  Pliers are not ideal for this sort of thing, but in a pinch, you could probably use this to change a belt, and certainly use it to replace a hose.  But you can’t use it to rebuild an engine.  There are a number of reasons why.  But here’s a big one:

This is a piston ring compressor.  It is a specialized tool used to compress the rings on a piston when you put them back in an engine.  And there is probably a way to get a piston into the cylinder without one.  It probably involves cutting up a beer can and using a strap wrench, getting a really nasty cut, and making it worse trying to stitch yourself up with the thread in your survival knife, then going to the doctor who informs you that you should never, ever try to stitch yourself up again unless you’d like to lose your hand, and finally going to an auto parts store on the way home to buy a piston ring compressor.  You could probably do something like that.   But I wouldn’t try it.  If I were doing serious work on engines day in and day out, I would try to have the right tools on hand.

And that’s the thing.  If you’re reading this, odds are you’re not a guy who is not making emergency code repairs on the side of the road.  Odds are you are a guy who is building and rebuilding engines (race car engines, right?), or at least maintaining them, every day.  You won’t do your job effectively with a survival knife or a multi-tool.  You need a tool box.  A big one.

And this tool box is SlickEdit.  A great deal of it is stocked when you get it.  There are other tools that you have to put in the box, but it leaves a nice drawer there for you.  It’s customizable, so you can cut a piece of foam out to fit your special tools.

Quit trying to build engines with a pocket knife.  Get the tools that will best help you do your job. Some of my best friends are mechanics.  They have to buy their own tools and move them from job to job.   They don’t buy cheap ones.

In my long tenure at SlickEdit, I’ve learned a few tips and tricks about using SlickEdit. You think faster than you type.  Why?  The brain has no moving parts.  There may be other reasons too, I’m not a doctor.

I believe the biggest time saver that SlickEdit offers is reducing the number of keystrokes you have to type.  Because you think faster than you type.  So the less time you spend typing, the less likely you are to lose your train of thought.

So SlickEdit tip #743 is as follows: try binding Ctrl/Alt shortcut keys for cursor movement so you do not have to your hands off of the main part of the keyboard.  I suggest the following:

Keystroke SlickEdit Command
Ctrl+I cursor-up
Ctrl+J cursor-left
Ctrl+Shift+J prev-word
Ctrl+K cursor-down
Ctrl+L cursor-right
Ctrl+Shift+L next-word
Ctrl+N page-down
Ctrl+P page-up

 

Depending on what emulations you’ve tried in SlickEdit, you might recognize a few of these already.  It takes some getting used to, but since have I adapted to using these key bindings, I believe they have saved me a lot of time.  Let me know what you think.

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.

Next Page »