Put your build output in an edit window.

Most programmer’s editors or IDE’s relegate the output from a build to some sort of tool window that is typically in a tab group docked a the bottom.  This is how SlickEdit works by default, because it is what is expected today.  Sometimes you have to jump off the bridge because all of your competitors did.  But that doesn’t mean that is the most powerful way to work.

Try right clicking in the Build tab and selecting “Send Compile Output to Editor Window”.  This means the build window (what we call the the “concurrent process buffer” or simply ”process buffer”) is in the ring of open files when you cycle through them using the next-buffer/prev-buffer commands, or pick one from the Files tool window.  This is actually very powerful.  At first it may seem that you can’t move freely, but you can.  The cursor-up key will cycle through the command history by default, but clicking the mouse or using a non-cursor key to move (page-up for example) will allow you to move freely through the output, or delete it by hand.  I find this much more useful than trying to view my output through a porthole.  Try it out and let me know what you think.  You can always turn this off by right clicking in the Build tab (or the process buffer) and turning off “Send Compile Output to Editor Window”.

1. I would like Time Machine to not start up right away as soon as I log on. Please, please allow me to fire up Outlook, start a Terminal session, and fetch the latest from subversion before you start monopolizing the disk I/O.
2. Non-silent ‘everything’s OK’ compile output. Some compilers and linkers do a decent job of this. Some report useful things like “All files up to date”. It’d be great if all command line tools did this.
3. Some helpful hints when it’s time to create a new password. Every couple months I am forced to dream up a new password, something sufficiently secure but easy and fast to type. Perhaps an interface similar to Captcha prompts? Give me a couple suggestions that already meet the password complexity criteria.
4. Rechargeable batteries for my Magic Mouse that actually hold a charge for more than 1 week.
5. A release of Java that is free of Zero Day security flaws.
6. Ditto for Flash…
7. …and Internet Explorer
8. An e-mail client feature that automatically truncates replies. All we really need are the most recent 3 or 4 responses of a long-running back-and-forth e-mail thread when composing yet another reply. I can’t remember if it was web-based gmail or the Mail app on my iPad that did this for me recently. I sure wish this was everywhere.
9. Selective Bookmark Syncing. There are some links I’d like to have everywhere, and there are some links I have at the office that I’d like to show up on my home devices (and vice-versa). But it seems that most current implementations are an “all or nothing” affair.
10. A Seat Belt detector for my phone. I can’t count the number of times I’ve gotten to the first traffic light on my way home and remembered that I’ve left my mobile phone in my front pants pocket. Perhaps a clever trick could be done with the accelerometer to detect the motion of getting into the driver’s seat.
11. A big red reset button. When you’ve got a runaway process that’s hogging all your system resources, how do you stop it? Right, by invoking the Task Manager or Force Quit dialog, which itself requires resources. It’s a huge chicken/egg problem. In my grade school days there was this awesome red button on the TRS-80 (complete with ergonomic recessed finger tip dimple) that would reset the system. How about something similar that would would kill everything except kernel and OS processes?
12. Stretchy Cables. Ok, so this one’s a little bit strange. But it sure would be convenient to be able to stretch a cable to exactly the length you need. Right now on my desk I have a headphone cable that is much longer than needed to reach from my speakers to my head and a power cable on my MacMini that is just a teensy bit too short for where I’d prefer to position it relative to my UPS. The only perfectly sized cable is the USB cord that reaches from my keyboard to the back of the computer.

Did I miss anything?

• 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.

Recently what started as a lovely afternoon at Guitar Center ended with me changing a car battery in a parking lot after dark.  On New Year’s Eve.  I’m not really complaining.  I’m not that handy, so when I can fix a car and look manly in front of my family, I’m pretty happy to do so.

Fortunate as I am to have a good job, I can drive cars that are just new enough I don’t carry tools in the trunk anymore.  Just emergency reflectors and jumper cables.  This is fine because:

1. As acknowledged above, I’m not that handy.
2. You can’t do anything to cars yourself anymore. Changing spark plugs on one of my cars requires removing the intake manifold.

Despite my best efforts with jumper cables, I could not get the car to start.  So, I found myself at Walmart buying a battery and asking if I might borrow a wrench, because even though I went home and picked up tools, I couldn’t fit a ratchet and socket into the space I needed.  The gentleman went to the back and got me a side-post battery terminal wrench:

• January, 2012 – I solemnly vow not to lose a single ounce during 2012, or at least that’s how I remember it now.  This was a runaway success.
• January 20th, 2012 – We release our first “real” version of SlickEdit for Mac. Our Mac beta testers rejoice that the near-weekly beta builds are now at an end.
• February 3, 2012 – Van Halen releases it’s first album with David Lee Roth singing in 28 years.  Mostly comprised of completed songs that have been floating around on their demo bootleg for years, it is actually good.  The tour got derailed halfway through for a myriad of reasons.  Long time Van Halen fans still see this as “better than average”.
• March 13, 2012 – (directly from Wikipedia) “After 244 years since its first publication, the Encyclopædia Britannica discontinues its print edition.”  This was bound to happen as nobody has bought an “old school” encyclopedia since sometime around 2004.
• April 4th, 2012 – Public beta testing for SlickEdit 2012 begins. Two weeks after the Spring Equinox each year we are required by law to release the first beta of our upcoming version. Check your almanac.
• April 8, 2012 – Jack Tramiel, founder of Commodore Portable Typewriter, which became Commodore Business Machines, dies at the age of 83.  Rest in peace, sir.  As noted in last week’s post, your VIC-20 led me to a career.  Mr. Tramiel was also a holocaust survivor, having been liberated from Auschwitz in 1945.
• April 13, 2012 – North Korea launches an “ Earth observation satellite“.  It goes about as well as my weight loss efforts.  I hope they did it at night, it was probably much cooler than any fireworks display.
• Spring-Summer-Fall, 2012 – After losing 100 games in 2011, The Chicago Cubs have a new General Manager, Manager, and the fans have renewed hope.  The Cubs lose 101 games in 2012.  Ron Santo, veteran Cubs player and broadcaster is inducted into the baseball hall of fame.  I think he would have liked to be inducted on the previous ballot, when he was alive to see it.
• May 2, 2012 – (directly from Wikipedia) “A pastel version of The Scream, by Norwegian painter Edvard Munch, sells for US$120 million in a New York City auction, setting a new world record for an auctioned work of art.”  While we continue to hear about a sluggish economy here in the U.S., and in fact, around the world, apparently some of us still have lots of disposable income.  I could have taken the original, run it through some Instagram filters, and sent it to a place that prints pictures on canvas for a US$1 million, and netted a profit of around US$999,900.
  • Instagram was in the news this year.  I’ve never used it so I’ll mention it vaguely.  I rarely take a picture worth sharing, and if I do I don’t usually want to convert it to sepia-tone first.
• June 24, 2012 – Lonesome George, the last known Pinta Island tortoise, dies at an unknown age believed to be over 100.   I don’t know about you, but a world without the Pinta Island tortoise, is a world I can live in just fine… because it looks exactly like every other larger tortoise I’ve seen at a zoo or Disney’s Animal Kingdom.  George was quoted as having said “The meaning of life is…”.  I’m joking.  He was a tortoise folks.  If he could have spoken he would have asked “Is there any more of that lettuce?  I would like some lettuce”.
• July 27 – August 12, 2012 – The Summer Olympics are held in London.  This event gives swimmers a chance to be sports icons … until there is a professional league for them to compete in.  It also serves as a reminder that by and large, Americans do not “get”, or care very much about, soccer.  Also, we aren’t very good at it.
• October 14, 2102 – (directly from Wikipedia) “ Austrian skydiver Felix Baumgartner becomes the first person to break the sound barrier without any machine assistance during a record space dive out of the Red Bull Stratos helium-filled balloon from 24 miles (39 kilometers) over Roswell, New Mexico in the United States.”  I’m curious if he’s scared of heights.
• October 23rd, 2012 – Apple formally announces the iPad Mini, confirming and ending a years worth of speculation. Still to be determined is if this was the first Apple product released against Steve Job’s wishes, or simply the culmination of the late founder’s final act of misdirection and subterfuge.
• October 26th, 2012 – Microsoft releases the Surface. For the first time in a long time the Microsoft faithful can stick out their tongues at the Apple and Android tablet disciples and chant “nya-nya-na-boo-boo”.
• October 29th, 2012 – I was going to write something about Scott Forstall being forced out at Apple. But the man’s name will forever be associated with the first iteration of Apple Maps for iOS, so I feel no need to pile on further.
• All of November, 2012 – A whole lot of nothing continues to happen in the NHL labor talks. This could have serious consequences for SlickEdit in 2013. In addition to our observance of the Spring Equinox, we also usually rely on waiting until the Carolina Hurricanes are mathematically eliminated from the Stanley Cup playoffs before readying the beta builds.
• November 23, 2012 – Actor  Larry Hagman dies.  I remember as a child when JR was shot.  I still don’t know who shot him, and it wouldn’t matter very much since I’ve never seen another episode of Dallas – I just happened to be up that night.  But whether you loved Dallas or not, I think we can agree that in the last few years Mr. Hagman’s eyebrows had become kinda creepy.
• December 20, 2012 – I write a Christmas themed post about receiving a VIC-20 for Christmas in 1983.  Along with the Commodore ad that features William Shatner, I try to fit a video of William Shatner singing (or perhaps it’s a dramatic reading of) “Rocket Man” at a Sci-Fi award show in the late 1970s.  We decide it doesn’t fit and it is omitted.  If you haven’t seen this, look it up on YouTube.  It is much funnier than anything I will write here.
• December 21, 2012 – The world failed to end, highlighting the fact that if the Mayans were so terrific at predicting things, we would have more… Mayans.  My favorite Facebook post regarding this had Marvin the Martian staring into a telescope saying “Where was the Kaboom?  There was supposed to be an Earth-shattering kaboom”.
• December 30th, 2012 – The Carolina Panthers eke out a come from behind victory over the New Orleans Saints, capping off yet another almost-but-not-quite season at 7-9, stringing us North Carolinians along for yet another year. Perhaps the Earth-shattering kaboom would have been preferable.  Can we get Cam Newton to stop doing that “Clark Kent ripping open his shirt- Superman thing” until they have a winning record after the fourth week of the season?
• December 31, 2012 – Our first year in review post is completed.  Unless we did one before, I didn’t check.  The NHL and the player’s union are supposed to meet today.    We would love to add one more entry…

Let me setup the fall of 1983 for you.  The cold war was raging.  The base I moved to in (state2) was full of B-52s that were made could carry air launched cruise missiles. In September, a Korean Air Lines flight from New York City to Seoul (via Anchorage), with 269 people aboard, was shot down by the Soviet Union.  Later that same month, Stanislav Petrov, a lieutenant colonel in the Soviet Air Defense Forces, may have saved the world.  WarGames was in theaters, and probably only because my parents had not seen it, they relented and got me a Commodore Vic-20 for Christmas.

I have received a number of truly great Christmas presents over the years.  Among them are:

• A remote control R2-D2 in 1978
• My first electric guitar
• My first son coming home from the hospital on Christmas Eve (after a rough entrance to the world 3-week hospital stay)

However, the Vic-20 holds a special place, because it probably kept me from saying “Would you like fries with that?” any longer than necessary.  When you’re a military kid, if you move when school is out it is difficult to meet people, so I learned to program in BASIC pretty quickly.

I would give some stats on the Commodore Vic-20, but it cannot be compared to any modern device.  I imagine any graphing calculator from 1993 was actually more powerful and had more memory.  I suspect there are kitchen appliances that have more RAM than the Vic-20 did.   I received a Commodore 64 the following Christmas, which was a far more usable device, but the Vic-20 set the hook.  And certainly you can see why here:

When coupled with the Commodore 1530 Datasette – which allowed you to save your BASIC programs on a cassette, you really had something.

So, thank you Mom and Dad.  This wise decision probably played a large role in me not still living at your house.

Merry Christmas!

Note: this video is best viewed in the  highest quality setting available for your browser. You can set the quality via the video’s bottom menu bar after selecting to play the video.

See part 1 here.

See part 2 here.

See part 3 here.

• The metric system is better than the English system we currently use (although I kind of like liquid measurements because it’s like they’re in powers of two).
• We should drive on the right side of the road, from the left side of the car.
• We can’t agree whether or not to have am and pm.  Here in the U.S. we tend to refer to 24-hour time as “military time”, but I believe this is the standard in much of Europe.
• We can’t agree whether or not the day of the month, or the month itself comes first when listing the date.  Again, in the United States the military behaves differently than the civilian world, but other countries do it differently as well.
• How to keep the music that was on a TV show in the actual TV show when it goes to DVD.  I have over dated myself here a bit, I was thinking more of Miami Vice, but it appears it was eventually released to DVD.  I never bought it, but those occasional Saturday afternoons when there’s a marathon of it on some basic cable channel, I enjoy several episodes while I procrastinate.

The things the world doesn’t agree on that annoy me, therefore making them by far the most annoying things the world does not agree on.

• New line characters.  With the Mac’s “Unixification”, I believe we’ve moved from 3 formats to two, but WHY!?!?  I believe one standard is quite enough, and since it uses fewer characters, we shall use the Unix standard.  I’m fixing this, right now.  From here on, lines end with 0xA.  If you have old text files that wind up with extra characters, there are several things you can do.  I suggest that you CHANGE them.  Buy a copy of SlickEdit, and if you can’t figure out how to change them, one of the people in our support department will be proud to help you.
• File system case sensitivity.  Case sensitive on UNIX, case insensitive/case preserving on Windows.  AND Mac.  And you could possibly have different file systems on UNIX that are case preserving, so that’s always a possibility.  I’ll make this decision too: case insensitive/case preserving.  OS and file system vendors, take note.  If you’re on UNIX and have separate files, one named “LS” and one as “ls”, I suggest that you CHANGE them first,  then comment on this post explaining why you would ever have done such a thing on purpose.
• Indent levels.  Some people say 3.  Some people say 4.  Occasionally it’s 2.  I’ll make this very simple: it’s 3.  Make a note of it.  If you’re using a 2, 4, 5,  or some number other than 3, stop explaining why you prefer that number, and CHANGE it.
  • If the language you are using enforces a certain indent, I’m not talking to you.
    • If you are in your basement wearing a tinfoil hat developing another language that you think will solve the issues with all the ones available, and your language will enforce a certain indent level, make it 3.  That is now the standard.
      • Stop it.  There are 4,397,531 computer languages.  Yours will not solve all the other problems.  It will have it’s own share.
• Tabs.  Some people like to use tabs to indent, and have them match the indent amount.  Some people like to set indent to one value (it had better be 3), and then set tabs to a larger number (maybe 8), so that it compresses the file somewhat.  So on a line that is indented four times, you get one tab and 4 spaces, thus saving 7 bytes.  So, when should you use tabs?  NEVER. Tabs have NO place in source code. You don’t need to save the space. Attempting to save space cost us a lot of time and money with the whole Y2K 2-digit year fiasco. Here is a 1TB hard drive for $60. Buy two and use all the spaces you need. If you need to compress the leading whitespace in your code, you’re doing it wrong.  SlickEdit it has a nifty feature to help you convert your tabs to spaces (Edit>Other>Tabs to Spaces).  Get to work.

If you’d like to wait until after the holidays to implement these changes, I understand.  If you’re waiting until after December 21st to see if you should waste your time in case the world ends because the Mayan calendar stopped there: they probably just stopped there.  They probably just took it out a couple thousand years and said “that’ll do”.

In the third installment of our series we cover using DiffZilla with version control systems, including:

• Specifying a version control system
• Accessing commands to display version history
• Comparing the local working copy with a previous revision
• Comparing two historical versions

Note: this video is best viewed in the  highest quality setting available for your browser. You can set the quality via the video’s bottom menu bar after selecting to play the video.

See part 1 here.

See part 2 here.

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:

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.

PacMan for Atari 2600: My childhood recollection is that people awaited the arrival of this game with the same enthusiasm most 4 year olds reserve for December 25th. I don’t recall if the subsequent let-down resulted in any rioting in the streets, but I do remember learning some new vocabulary words from my older cousins the first time they played it.

E.T. for Atari 2600: See above. Downright heartbreaking that one of the best movies of all time should be sullied by this release. 1983 was a dark time indeed for the console faithful. This did at least leave us with a cool urban legend.

Apple iOS Maps: The much ballyhooed replacement for Google Maps on the iPhone most likely lead to the ouster of a long-time Apple executive, supposedly when he wouldn’t agree to sign a company apology. It’s still the subject of late-night talk show jokes.

The HD-DVD Format: Not quite a flop. More of the bloodied loser in the boxing match against BluRay. But Sony had lost the battle between BetaMax and VHS, and was determined not to suffer a repeat.

Ada: Despite having the best intentions, it did not make a dent outside the arena where it was required by law to be used.

SuperMan 64 for Nintendo 64: Our resident player/tester commented that “The only bright spot about that game was that I could turn it off at any point.”

Borland OWL (Object Windows Library): Intended to fulfill the role of the MFC libraries for those who chose to not use Microsoft developer tools. Whenever you see software where the Cancel or Exit button features a cartoon figure bolting for an exit door, blame OWL.

Lisp:  Proving that theoretically good ideas are seldom popular, and also that semicolons are easier to type than parens.

Virtual Boy: The best thing to come from the release of the Virtual Boy was not the headaches or nausea, but that if you actually bought one you now have a valuable collector’s item.

Clippy: Remember the days of playing Whack-a-Mole with your word processor, clicking away every few minutes just to get that animated thing to disappear already? The sad part is that the user reaction to Clippy made software developers gun-shy in developing in-application assistants. I hesitate to categorize it as a Turkey. More akin to a Plague.

Note: this video is best viewed in the  highest quality setting available for your browser. You can set the quality via the video’s bottom menu bar after selecting to play the video.

See part 1 here.

Or perhaps the classic Ronald Reagan and Jimmy Carter exchange…

So as you can seen, politics and software technologies don’t really mix all that well. In fact, the results can be disastrous. We experimented with running a sophisticated source code indexing algorithm against internet-hosted code repositories. The indexing daemon was inadvertently pointed at site hosting political quotes. Behold the train wreck that ensued.

iCostume

The potential of using iPads (or any other tablet computer equipped with decent cameras) is exciting. However, the hardware costs may be a little more than you normally budget for costuming.

The Invisible Man : Strap one iPad to your front, and another to your back. Initiate a FaceTime session between the two tablets. The iPad in front will display what the rear one is displaying and vice-versa. The net effect on the adult wearer will appear to be a large hole through the chest, but small children can be rendered nearly invisible using this technique.

Indigestion : Requires only one tablet, mounted just above your belly button. Take several videos from antacid commercials and run them in a slideshow loop.

Infinity : Uses the same chest-mounted tablet. Attach a webcam to a long stick protruding from your shoulders and arrange it so the webcam points to the tablet. Display the webcam image fullscreen on the tablet.

Coding T-Shirts for Groups

A group of three could go as public, protected, and private. If you pick up a 4th wheel, they get the friend shirt.

Also for threes, make up shirts with <, =, and >. See how many relational operators you can construct. Extra candy for implementing (or having anyone recognize) the Perl spaceship operator.

For couples, go dressed as && and || and, in conversation, && disagrees with everyone as soon as he disagrees with one thing, and || agrees with everything anyone says once he’s heard on thing he agrees with. See if anyone catches on, or if everyone just eventually decides that && is a jerk.

Another idea for couples is to go as NULL and -> (alternative being * and 0). Stand close together and fall down (or freeze) whenever anyone addresses you.

Mathematically, it stands to reason that you are going to overlook something.  We have already established that there are 783,711 version control systems available, yet there you are with the same Pink Floyd album side playing over and over writing #783,712.  Because all of them didn’t do it right.  So the odds are you won’t get it exactly right either.  Maybe you’re not quite as clever as you think, or maybe your foil isn’t quite thick enough.  Or maybe you just overlooked something I find very important.  So here we go (in no particular order):

• Under NO circumstances should the default check-in behavior be to delete the local file.  I’m going way back on this one… but this one bugs me.  When I have to write support for a version control system, I try to use it’s default options as much as possible.  And in this case I did too.  However, I found it such a terrible default it bears mentioning here.  Perhaps it made sense to somebody at a point in time when hard drive space was measured in megabytes.   But not to me.
• Let us suppose your version control system supports separate repositories at a pre-specified location.  For example you set an environment variable:

SERVER_LOCATION=TINFOIL1,port:80

If you allow multiple repositories (or modules, herds, gaggles or whatever you choose to call them) to be stored at TINFOIL1,port:80, I should be able to list them all.  There should be a command I can run to see all of them.  If your version control system uses a URL where only one thing can exist:

http://tinfoil1/NewVCS

then this does not apply to you.  I do not have an opinion about which one is better, although the URL method seems to be more modern.  But if there is more than one thing, let me see it - do not make a colleague of mine and I sit and try things until we notice that there is a command that you can run that gives an error message for each module, and we can get it that way. I shouldn’t have to do something wrong in order to stumble across a correct answer.

• Let me view all versions of a file  across branches.  I won’t go into detail here because I covered this in Manifesto – Part 1 – Branching.  But it is important enough it bears mentioning again.
• Let me get a file, and put it where I want it.  Do not make me get the whole directory.  Do not make me get the whole directory structure, with just one file in it.  Let me get any version of any file, from any branch, and put it anywhere I please.
• Let me run any command and specify the output in XML, or some other regular format.  I am adding support for this version control system to SlickEdit after all.  I don’t want to use your API.  I want regular output written to a file I specify, or that I can redirect to a file.
• When running a version control command, a history or log command for example, let me refer to the file any way available to me.
  • If I am on Windows, let me refer to the local file, using a relative or absolute path, OR using the URL (or whatever the remote specifier is).
  • Do not make me use forward slashes in relative paths while I am working on Windows.
  • Do not make me change to a directory that was checked out and use a relative path.
    • I should be able to sit in “c:\temp” and run “tinfoilvcs history c:\src\project1\file1.cpp”.
• Let me checkout multiple copies of the same branch/module/whatever.  Most recent version control systems do not have issues with this.  But I often find myself in a situation where I need to fix a bug, but my copy of the branch I am working on is “too dirty”.  So I checkout a new copy, fix the bug, check it in, delete the new copy, and update the other copy.

For extra credit:

• Let a user plug in a 3rd party GUI diff on their own – so if they would like to run vsdiff.exe to view differences even if they run your version control’s diff command from the command line, they may do so.
• In the above paragraph, replace “diff” with “3-way merge”.

Now go flip the record over.

I recently had the unfortunate experience of revisiting this bug (hadn’t seen the thread in a while) because of the newly released Eclipse 4.2 (Juno). At SlickEdit, we are currently working on our next version of the SlickEdit Core for Eclipse plugin, which will be built on Eclipse 4.2. In Eclipse 4.2, the split editor window problem has again become a major hurdle. I’ll refrain from voicing any dissenting opinion about the new UI released in Juno, though all the criticism seems to be warranted, and focus on the issue at hand. Several plugins, ours included, have implemented their own ways of providing split editor window capabilities within Eclipse. These implementations may have relied on internal APIs (bad practice), but there was no publicly available way to go about providing this feature. So we did what we had to do to provide what our customers wanted. Eclipse sure didn’t seem interested in actually providing a way to split an editor window in their IDE (remember, 10 years). And please don’t say, “Click and drag the window.”

Enter Juno, the new Eclipse workbench UI, and API changes which have broken these implementations. Of course there is no guarantee that internal Eclipse APIs will not change or break between releases, so this to no fault of Eclipse. Although maybe if the bug was addressed sometime in the last 10 years this wouldn’t be such a problem in the first place.

For now we are left searching for another workaround, and checking the status of this epic bug. The comment history has gone through a civil phase, a nasty phase, and then what seems to be phases of disbelief, and now acceptance. I really just wanted to share this thread to some who might not have seen it before. Maybe now you feel a little bit better about some of the long-standing bugs in your code. I hope we don’t ever have to toast them.

In future videos we’ll cover more advanced usages of DiffZilla, including Backup History and version control history comparisons.

Note: this video is best viewed in the  highest quality setting available for your browser. You can set the quality via the video’s bottom menu bar after selecting to play the video.

“I think I’m entitled.”

“You want answers?!”

“I want the truth!”

“You can’t handle the truth! Son, we live in a world that has walls, and those walls have to be guarded by men with guns…”

The above comes from a very famous movie allegedly based on the life of a lawyer that runs those ads on TV now.  I don’t mean to imply that makes him better or worse than any other lawyer – people have to know you’re out there, and we don’t have yellow pages anymore.  It’s a great scene… I’m not going to mention the name of the movie… not because of any copyright or anything.  My premise started with the fact that the movie, and that scene in particular, are so famous that everybody will recognize it.  I’m sticking to that.

But right now,  I want the truth – about the current directory of the tool I am in.  My responsibilities here at SlickEdit sometimes require me to use development tools that are not SlickEdit.  And whenever this happens, I find it difficult to figure out what directory I am in.   And this is not an indictment of a sole tool, although the one that prompted me to leave it and start this rant seems to be the worst offender.

Is the directory that my project is in a secret? Is there a dark piece of history surrounding the location of these files that have caused their family shame, and they don’t want me to know?  Do they think that I “can’t handle the truth”?  Am I the only user of these products in history to have to switch between two copies of the same project and try to figure out why one works and one does not?

I’m a big boy. I can handle it.  Just tell me.  And floating over a tab to show me where an open file came from is not good enough, because I don’t know if it is the one in that project or not.

For those of you who feel the same way, in SlickEdit you can go File>Change Directory to view (or change) the current directory.  You can also go to the SlickEdit command line (click on the status bar to the left of the Line indicator) and type “cd”.  Or if you speak UNIX you can type “pwd” if that makes you more comfortable… but typing “cd” by itself will not make the current directory of the editor your home directory.

Upon further review, I must admit the whole analogy falls apart somewhere around the part about “those walls have to be guarded by men with guns…”   But I love the line “You can’t handle the truth!”.  But in this case, I can.  I just want to know what directory things are in.

After using an iPhone for about 3 years I decided to switch to the Samsung Galaxy S3. I loved my iPhone but the new iPhone 5 screen size simply is not wide enough for me. I couldn’t believe Apple wouldn’t make the screen wider. Choosing the right smart phone depends on what features are most important to you. For me, I was in desperate need of a bigger screen so I could read more on my phone and the S3 seemed like it would be worth the effort of switching.

The tasks I use my smart phone for

Most important:
email, phone calls, calendar, browsing

Some must haves:
camera, notes, weather, movie show times/reviews, stock quotes, stock trading, YouTube, Engadget (yep, I like to read about gadgets!)

Some nice to haves:
sports scores, live sports videos, TV Guide, calculator, poker with computer, black jack with computer

As you might have guessed, my smart phone is primarily used for work. I removed the Facebook app I had because there were too many notifications. I don’t have much time for games, something I suspect the iPhone is better at. While I listen to some music on YouTube, I haven’t purchased much music from iTunes. I did buy a ring tone as well as create one from a song I purchased. As far as apps go, I purchased two apps, one of which is now free. Hah, I’m not locked into Apple (“you will not assimilate me”).

Configuring the Samsung S3
I spent at least 12 hours configuring my phone. That should give you an idea of how bad I wanted to benefit from my new 4.8 inch screen. My time was spent finding and configuring apps, and learning how to be productive on my new S3. I wasted a lot of time getting my email to work well. Thankfully someone else took care of rooting my phone and installing CyanogenMod. I didn’t have to root my phone but I decided I wanted to be on the bleeding edge so I could have the latest greatest android features and fixes. I love the new default keyboard and the ability to configure my home screen icon grid to 5×5 instead of 4×4.

I highly recommend changing your font size and choosing something smaller if you have good eyes. I set the font size to “small” and this allows me to view more text in the apps that matter to me. If you don’t do this, you might as well be using an iPhone because the default fonts on the S3 are pretty large.

Email is not so great on android
The iPhone has one email app which works well with Yahoo email, Gmail, and Microsoft exchange (ActiveSync). The S3 and most android devices as of this article ship with two email apps. The Gmail app only supports Gmail. The Email app supports all the other typical providers including Gmail. Sounds good right? Here’s the catch, the Email app doesn’t support push notifications with Yahoo email (it does for Gmail if set up using Google Sync). For me, having push email for Yahoo was a requirement. That way I get my emails very shortly after they are sent and conserve battery life. After trying some other email apps, I liked MailDroid the best for providing push notifications for Yahoo mail and Gmail. Unfortunately, it doesn’t support ActiveSync yet due to Microsoft licensing issues so I have to run two email apps. The Email app looks ugly to me especially when writing an email (I won’t go into details here). It’s not a perfect solution but it gets the job done. I needed to tweak more settings than I expected for the Email and MailDroid apps to behave the way I wanted. In addition, I had to download Adobe reader for reading PDFs. The iPhone email app just works. For me, the iPhone email app is better than any combination of email apps on Android but I do like Androids ability to operate on multiple emails at once (say to delete several emails).

Advantages of S3 over the iPhone:
(keep in mind, this is based on my needs and not necessarily yours)

• Big screen so you can read more. By far, this is the biggest benefit.
• Pictures and Videos look better due to the larger screen.
• More icons per home screen.
• Back button at the bottom of the phone. The iPhone really needs this for better one handed phone use.
• Widgets (like contacts and weather) can be placed on the home screen just like apps!
• Menu button at the bottom. The iPhone needs this too but since many apps have buttons at the bottom, it’s not that big a deal.
• Better keyboard enhancements. With CyanogenMod or the Swiftkey app, hold the period to get a menu of common punctuation characters.
• Good support for multiple browsers or email apps.
• Easier to configure home screens. I especially don’t like how iOS auto arranges icons!
• Many more configuration options. I’m starting to really like this.
• Easier to root phone. This provided me with a better keyboard and more icons on the home screen.

Advantages of iPhone over S3

• Easier to use and configure. More things just worked for me with less or no configuring (visual voice mail, email, iCloud).
• Security. Arguably better because apps go through an Apple review.
• UI experience. More of the apps I’ve seen have a consistent look and feel with good looking graphics.
• Apps. This will be very different for everyone. For me, the following apps are slightly better on iPhone: email, ScoreMobile, calendar, TV Guide, and WeatherBug. Although, Mobi Calculator Free is better than any iPhone calculator app I tried.
• Touch screen. I find the iPhone screen slightly more accurate/responsive.
• More pixels per inch so you can read smaller fonts. This is valuable when the browser displays something very small.  The whole Retina display thing has value but I’d rather have a larger screen so I can read more.
• Cut/paste is slightly easier on iPhone because the popup is closer to your finger. There is also a problem on Android if you want to select and copy text from the first line of the screen (Yes, I ran into this problem).
• Bluetooth for car just works. Like many, the S3′s Bluetooth for my car has problems.

Conclusion
This was my experience switching from the iPhone to the Samsung Galaxy S3; while it may not completely match your’s, there will probably be some overlap. If you’ve been using your iPhone for a long time, it will take you a while to make the switch. In general, the S3 is better suited for users interested in fine-tuning their environment and who do not mind spending the time to do it. Android has come a long way and I can definitely say that I’m enjoying my S3. Android needs to continue to improve the apps ease of use and automation (reducing setup time). For me, I would like the features for some of my favorite apps improved. Apple had better come out with a larger phone than the iPhone 5 soon because Android has a significant edge with so many form factors. Its a bit like TVs where a lot of the value comes from the size and quality of the screen. Like I said, one size doesn’t fit all.

Branching is a fantastic concept that allows you to split your code base when you need to create a complicated feature, or fix a complicated bug, but still have the benefit of version control.  When you are done, you can merge it back into the main branch (referred to as the “trunk” – I think it must be a pine tree, I’m not sure it works otherwise… it might be OK for oak, but it can’t be one of those trees that splits into branches and the trunk stops going in a straight line through the middle).

Different version control systems have handled this concept different ways.  Some (cough-sourcesafe-cough) just sort of didn’t do it.  This is how a lot of rock bands reacted to disco – they pretended it never happened and just kept doing what they always did.  Not all of them though.

If you’re not used to using branches, don’t be scared of it.  Branch the whole thing (don’t try just doing a few files, even if it is all you need).  But you do need to know how your version control system handles branching.  I will not be teaching you.  But I will mention what a couple of them did wrong, maybe yours (provided you are using CVS or Subversion).

CVS let you create branches with names – but unfortunately it created them with really confusing long numbers – the same way it did everything else.  Also the syntax to do this was bit of a pain – I honestly don’t remember it exactly – but you had to use the “tag” command with the “-b” option for branch, but not “-B” which meant something different (obviously) .  It was easy to look at a number and tell that it was a branch, but it was rather difficult to pair that number to the actual human readable name for the branch.  Sometimes you have to do this, particularly if you are writing support for CVS at a company that produces a programmer’s text editor.  But what it did right was make it easy to see all the versions of a given file, across branches.  So if you are looking for a fix that was in some version of /path2/path2/file17.cpp, but you then realize that fix might have been in a different branch, it was easy enough to look for.

If you knew enough command line options, you could merge two branches together.  I don’t remember how to do it, I’m not going to look it up.  I never completely trusted it.  I would check out both branches, use our multi-file diff to compare/merge them, and then commit.  It might have worked fine, but I found the options very confusing.  Also, learning to trust tools to perform complex operations for you is a process.

Subversion lets you create named branches that stay named (as far as we can tell).  Creating them is very intuitive, it has a “cp” command that we’re all used to (that’s the same as “copy” for the Unix impaired (for those of you who may be very young, it’s the same as right clicking on a folder and selecting “copy”, then “paste”, and then changing the name)).  So to create a branch all you have to do is type “svn cp http://svnRepos1/trunk http://svnRepos1/branches/branch13″.  Terrific, right?  No.  Actually not so much.  There are a few problems with this:

1. Tags and branches are the same thing, which is nice because the one “cp” command covers everything.  The problem is that there is no difference between a branch and tag.
2. The “Subversion people” (I forget the exact name of the consortium that runs this thing) suggest that you use the following layout for your repository so that you can tell the difference:
   1. http://svnRepos1/trunk/
   2. http://svnRepos1/branches/
   3. http://svnRepos1/tags/
3. This layout works very well, we use it here.  It makes it easy to tell branches from tags.  Of course, it isn’t enforced at all.  Again the headache this causes is largely to a person – namely me – writing support for a system in a different product.  Also, because there’s no difference, and no enforcement of these directories, if you make a mistake putting one of these in the wrong place, nothing will detect it.  You’re thinking, “But Dan, you can just move it, no wonder you’re writing a manifesto you’re one of those idiots in your basement with a tin foil hat”.  But you’re wrong:
   1. I don’t have a basement.
   2. The real problem here is that unless you notice by accident nothing will tell you that you put the tag for your release version in the tags/ directory, and you will freak out when you try to check it out later and cannot find it.
   3. I’m not wearing a tin foil hat, I’m wearing a Cubs hat, and right now I’m pretty sure it makes more sense to wear a tin foil hat to block out signals from HAARP than it does to pull for the Cubs (motto:”Breaking hearts since before the triple bypass was invented”).
      1. This is a lie, I threw it in to try to be funny.  My son lost my Cubs hat while we were on vacation this summer.  I need to pick up a new one, along with another copy of Catcher in the Rye.
4. It is very difficult to search for different versions of the same file across branches.  As newer versions of Subversion have been released, it has become possible, but still not easy.  SlickEdit’s Subversion History dialog does this.

Subversion’s merge command will merge another branch int0 your branch really well.  It provides a –dry-run command (CVS could do a dry run for anything with the global -n option, which Subversion does not have).  It works very well, except in a couple of mystery cases, where it does not work well at all.  The key is to merge often.  Here for example, development generally continues on the trunk.  If you are “out on a branch” working on a large feature that touches a lot of files, you will be much happier if you merge with the trunk often.  Eventually that feature branch will need to merge to the trunk, and that will be far easier if you continually merge the trunk into the feature branch.

Neither one of these provides a method to “cap” a branch.  To make a branch read-only so that it can be checked out – but no longer checked into.  This would be a good thing.

Finally, git and Mercurial provide an entirely different paradigm for version control – which means their branching works differently.  Their fans will tell you it’s better… I won’t draw a conclusion yet.

I will leave you with a final thought: If there are plugins available to augment the functionality I’ve complained about – I don’t care.  This is my manifesto, write your own.  Just kidding – I’d love to hear about them, but the truth is that I have to write support for these products, so I have to handle the way they behave out of the box.  So I can’t write support for history that shows branches across a file provided that a given plugin is installed.

I glanced at the preview – this is long, rambling, all text, no pictures, and spotty punctuation.  I think it qualifies as a manifesto.  Part 1 is a wrap.

P.S.: A colleague notes that I should mention that Clear Case did a fine job of branching over a decade ago.

There’s not a lot of literature on parsing C++ with incomplete information.

Which in hindsight, isn’t too surprising. It’s a messy problem that doesn’t have a clean “apply methodology X to problem Y, repeat” solution that you see in most publications. And unlike a compiler, the beautifier can’t afford to do a 100% accurate parse – that would require the beautifier’s parser to accept every grammar and dialect of every compiler product/version used by any of our customers, a tremendous effort on it’s own.

Since we don’t have the fully stocked symbol tables that most methods of resolving C++ grammar ambiguities require, we deal with them in other ways:

• Some ambiguities don’t matter because resolving them wouldn’t effect any of the beautifier rules,so we ignore them.
• More complicated resolution is handled by some parsing state that is refined as we parse through the source, that describes how sure we are of our parse. (i.e.: “in expression or declaration”, “definitely in a type decl”,”I do not recognize this place”).
• When things get truly bad, we’ll rewind the token stream for a statement and restart the parse, using the information we gathered in the failed parse to guide the parse down another path. It’s a little bit expensive, and makes it hard to debug the parser, so this is a method of last resort.

Preprocessing makes everything more complicated.

As helpful as it may be for coding, preprocessing complicates the state handling in the beautifier substantially. Preprocessor conditionals can be tricky if different branches have wildly different pieces of code in them where braces don’t match up locally, or in cases where a single statement is spread across several branches of different conditionals. Unlike a compiler, we don’t just see the one path through the conditionals that the compiler gets from the preprocessing stage. We have to examine all of the branches, and we’d like to do something sane with all of them.

While simple macro expansions are less heinous, they can still be tricky for us when you consider we probably don’t know what the macro expands to.

You can always come up with a preprocessing trick that will trip up a parser, so the emphasis is more on minimizing the effects of the hiccups rather than assuming we can parse our way around all of them.

How you handle errors has a huge effect on your parsing strategy.

This is probably true for parsing in general, but differences in our strategy reemphasized the point for me.

For a compiler, you need errors to be informative, and you want to be conservative in how you pick restart points so you don’t flood the user with bogus cascading errors from an earlier syntax error.

For the beautifier, error handling is almost entirely dedicated to finding a good place further in the stream to restart the parse, while leaving bread crumbs for the output  pass of the beautifier so it doesn’t become completely lost. The remainder of the handling is for either:

• Cases where we’ve obviously parsed ourselves into a corner, and need to rewind and reparse with a different assumption. (the assumption usually being either “declaration vs. expression” or ”expression with a ‘<’” vs “declaration with a template type in it”, etc…).
• Cases where we’ve hit an EOF during the parse. This can be common when beautifying selections, and beautifying while editing. You have to take care not to lose partial parse information when this happens, even if you technically don’t have enough information to form a valid node in the parse tree.

In our favor, we are much less constrained than a compiler when it comes to picking restart points. If we trip up in the declaration of a function, and scan forwards to the first statement in the function, we’re certainly losing information, but not anything that’s going to be relevant for the configuration rules we need to apply.

And finally, related to error handling….

Don’t underestimate the value of good defaults.

It is guaranteed that there will be parse problems in the field. Vendor extensions, perverse use of macros, oddball syntax accepted by ancient compilers, etc… So when the inevitable occurs, what we don’t want to do is announce this to the user by switching to brace style 3 with double spacing in the section of code that was parsed incorrectly. And yes, early development versions did do things like this. It was horrifying to behold.

90% of the problem was fixed by just changing both the configuration and behavior defaults to have a sane behavior in the absence of parse information. The remaining issues we handle by doing a little bit of special handling in the output stage when we’re dealing with unparsed source, so we leave unparsed code with as few changes as possible.

Designed by developers for developers, SlickEdit’s award-winning source code and text editor is respected for its rich set of coding tools and powerful time-saving programming features. A true cross-platform, multi-language editor, SlickEdit 2012 gives programmers the ability to code in over 40 languages on 9 platforms.

The SlickEdit Academic Multi-Platform license, which is valued at $649.00, is regularly available for $59.00, but can be purchased by students through October 31st for just $49.00.

To take advantage of this offer call 1-800-934-EDIT (3348) or email academic@slickedit.com and mention this offer. Proof of your current student status will need to be provided for eligibility.

The first video in the series can be found here.

This installment covers:

• Auto-Completion
• List Symbols
• Parameter Info
• The Preview tool window
• The Defs tool window and the Current Context window

• Go to Definition
  Bound to Ctrl+. to go to the definition of a symbol
• Pop Bookmark
  Bound to Ctrl+, to return to the previous location
• Find All References
  Bound to Ctrl+/ to display all references to a symbol

The middle portion of the video details how compiler, SDK, and Framework directories are tagged using the Auto Tag dialog.

The last minute shows quick demonstration of symbol searching.

Future videos in this series will examine other tagging-driven features like auto-completion.

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.

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.

I wanted to take the time to tell you about the new “Beautify while typing” feature for C++ and Objective-C that we added to SlickEdit 2012 (v17.0.2). This feature is off by default, which means many users won’t ever know this valuable feature exists. If you are editing C++ or Objective-C, I highly recommend you turn it on. I have this turned on by default and love it. Previously, my code was indented properly thanks to SlickEdit but I avoided putting in any extra spacing simply because it was too much manual work. This made my code less readable. Now I let SlickEdit beautify my code when I type a semicolon, open brace, or close brace.

Here is a quick sample clip of this feature:

To turn on this feature:

• Edit a C++ or Objective-C file
• Turn on Document>(C++/Objective-C) Options>General>Beautify while typing
• Press OK
• You can also turn on Document>(C++/Objective-C) Options>General>Beautify on paste or drag drop

It’s a good idea to create a beautifier profile customized in the style your company/project desires. Edit a C++ or Objective-C file and go to (Tools>Beautify>Options) to create and customize your own profile. The “Edit…” button allows you to modify the profile settings.

I hope you enjoy this feature as much as I do.

I welcome your thoughts on this exciting new feature in the SlickEdit Community Forums at http://community.slickedit.com

Thanks!

Clark

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 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.

If you prefer to watch the videos directly on our YouTube channel, click here.

Video One

• Creating a new compiler configuration
• Specifying a compiler configuration header file
• Tagging the compiler header directories

Video Two

• Creating a starter project
• Configuring the project to use a different compiler
• Modifying build/compile commands
• Adding new source files to the project

Video Three

• Customizing SlickEdit’s error parsing to detect error messages in the build output
• Using the Regex Evaluator to create and test a regular expression

I recently came across a great local story about software making a huge difference in the lives of many children in our area. Just up the road in Wake Forest, NC, Melissa Matthews recently won the “Ikea Life Improvement Sabbatical Contest”. The award was a $100,000 grant to continue work on a project which will improve the lives of others in their community. Melissa is the mother of a child with down syndrome, and is well aware of the incredible work of software developers who are creating apps for special needs children. She is working with the Frankie Lemmon School right here in Raleigh, NC, to enhance their use of technology in furthering the education and development of their students.

If you check out the website born from this project/grant at http://frankielemmonschool.org/technologies, you can read all about the efforts of Melissa and the Frankie Lemmon school. One iPad app currently in use (DAF Assistant) helps students who have speech impediments by relaying delayed auditory feedback to them as they speak. It’s been well studied that this technique can make a big difference in their development. In true SlickEdit fashion, the app is very customizable and has received great ratings in the iTunes store . There is a list of all apps for the iPhone and iPad being researched and used at http://www.kcdsg.org/files/content/24470331-iPhone-and-iPod-touch-Apps-for-Special-Education.pdf.

Of course, short of contacting any of these developers directly, I have no way of knowing that our editor was a part of the development of these pieces of software…but it sure is possible. At any rate, it’s always nice to hear about fellow coders who are working on special projects and making a difference. Maybe they are hardcore Vim users who just wish they had a nice graphical interface to organize their projects, while still being able to use their familiar Vim key bindings…

This has many benefits, chiefly limiting a system’s exposure to accidental changes or malware attacks. For software developers it has the added benefit of ensuring your software will install and function properly in such an environment. But developers frequently need those elevated rights for installing utilities, configuring the system for use-case testing, and using 3rd party tools that aren’t access rights savvy. So while many developers are aware of this practice, they aren’t inclined to work that way themselves.

I imagine that some least-privilege-resistant developers react to their more secure peers in a way very similar to how some people react to a person that is or claims to be a vegetarian.

Reaction #1: Quiet Admiration
Sure sounds like a good idea, and is probably good for you, but I don’t think I’ve go the discipline to do it myself.

Reaction #2: Suspicion of Dedication to the Ideal
We’ve all encountered folks who claim to be “mostly” vegetarian, but do allow themselves some animal sources. Is she really running that MacBook Pro under a Standard User account? I’m pretty sure I saw a “sudo” command in that Terminal window…

Reaction #3: A Cry for Attention
Are those who are claiming to run under least privilege just trying to score “I’m better than you” points? They’re just doing it so they can blog about it and feel superior.

Reaction #4: “I’ll Convince You that You’re Wrong“
Some folks like to argue just to hear themselves talk. You know that guy gnawing on his 15th buffalo wing proclaiming that a vegetarian diet is incomplete and unhealthy? He’s the same one who’s certain that his un-patched Windows XP is just as safe as your system. And it runs faster, too.

Reaction #5: “It’s a Phase“
The shine will wear off this fad pretty soon. You’ll be eating barbecue ribs and running Admin accounts with weak passwords by year’s end.

Do you run under least privilege, or have you tried it and given up?

We did a quick poll around the office to gather up some of the features that we use all the time. And yes, everyone’s list was quite different. So in no particular order, here are a few of our favorite things in SlickEdit.

Italic bold below denotes a Slick-C command, like complete-next, which can be executed from the SlickEdit command line or bound to a keyboard shortcut.

complete-next and complete-prev
Bound to Ctrl+Shift+> and Ctrl+Shift+< in most emulations. This searches for prefix matches in your current document. Very handy for completing words when you’re working in plain text or in a file format where Context Tagging is not able to provide symbol matches, or when you want to pick up non-symbol matches, like words found inside comments.

where-is, what-is, and bind-to-key
For those of you who like to keep your hands on the keyboard as much as possible, you need this. Sure this information is available on the menus and in the Options dialog, but why mouse around? Entering where-is on the SlickEdit command line will allow you to enter a Slick-C command to see if there’s a keyboard shortcut defined for it, while what-is lets you see the command name for a shortcut, or check if it’s free. Use bind-to-key to define a shortcut for something that’s currently not bound to one.

Aliases with %\n
If we had to list which features of SlickEdit we feel are underutilized outside our office walls, Aliases would be at the top of every list. Aliases simply allow you to type a short sequence which will be expanded, which is great for frequently used boilerplate text. They can be defined globally or on a per-language basis. We do provide some aliases out-of-the-box, but the real power is in creating your own. Go to the Tools > Options dialog, and search for “Aliases” to see where you can define them.
A common usage is generating “Caveman Debugging” statements. Here’s a sample alias for C.

printf(" %\n: %\c \n");

The SlickEdit alias facility has several escape sequences, and %\n is the sequence for “current function name”, and %\c positions the cursor for editing after the text expansion is made.

toggle-comment
This feature originated as a macro written by one of our customers, which he shared on our community forums. It was so popular that we made it part of the product. It’s a great complement to comment-lines and comment-block.

Quick replacements from the command line
Doing a quick search and replace inside the current file is a snap using the c/old/new/ syntax on the command line. Even more power comes from using command modifiers after the trailing slash. For example, the ‘m’ modifier means ‘mark’ (our term for current selection), and ‘*’ means globally without confirmation prompting. So to change all instances of char to wchar_t in your current selection without a prompt, you would enter c/char/wchar_t/m* on the command line, and you’re done.

svc-diff-with-tip
This is a super-quick way to compare your current file with the most recent version in version control, bypassing the version control history dialog. This currently supports CVS, Subversion, and Git. And if you’re using Subversion, and not currently able to connect to the repository, svn-diff-with-base performs a comparison with the ‘clean’ copy from your most recent update.

svn-get-annotated-buffer and cvs-get-annotated-buffer
A wrapper around the “blame” command for CVS and Subversion. Warning: May be habit-forming.

list-buffers and project-load
These bring up the Files tool window. Stop right there! You’re about to skip past this one because the word “Files” is pretty plain, and “bring up the Files tool window” sounds pretty dull. Do yourself a favor and try them out, and perhaps set up keyboard bindings for them. list-buffers will show you a searchable list of all the files you currently have open, allowing you to quickly switch to one without having to search through file tabs. Handy if you tend to leave a lot of files open in the editor. If you have a project open, the Project and Workspace tabs of the Files window allow you to find any file and open it from there. Very helpful for large projects.

Vim cursor keys
I hesitated to include this one initially. It’s not specific to SlickEdit, of course, and is only one of the 15 keyboard emulations we define. But if you’re a vi/vim adherent, having a high fidelity vim emulation built into your IDE is a big deal. It allows you to get all the benefits of the tools and features built into the environment without having to rewire you brain when you actually need to edit code. If you’ve ever accidently typed a stray ‘j’, ‘h’, or ‘dd’ or into an instant messaging client, you know exactly what I mean.

What feature(s) is/are highest on your list?

Set up an empty workspace

Go to Project – New… and click on the Workspace tab. Select Blank Workspace, set a good workspace name (such as libreoffice-master), then set the path to the workspace to be the root of the libreoffice source tree + /slickedit. For instance, if your source tree is located in /home/foo/libo/master, then set the path to the workspace to be /home/foo/libo/master/slickedit. When the editor asks you to create a new directory because it doesn’t exist yet, select yes to create the directory. This will create a new workspace file (.vpw) under that directory.

Add projects to the workspace

Once you have an empty workspace set up, it’s time to add projects to this workspace. It’s best to use a single project to manage a single module i.e. have a project for sc, another project for svx, and another for sal, and so on.

To add a new project, have that empty workspace you’ve just created open, and go to Project – New…, check Add to current workspace check box on, type in the name of the module (sc, sal, sw etc) into the Project name box. In the Project Type window , select Other C/C++ as the project type. Make sure that you leave the “Create project directory from project name” check box unchecked, and that the location points to the same directory as your workspace. Then click OK to proceed.

It now asks you to add files to the project. To do it, click Add Tree to launch the “Add Tree” dialog. Set the path to the base project directory (for sc, it should be <root dir>/sc, and so on), specify the file types to include all used file extensions (*.c;*.cc;*.cpp;*.cp;*.cxx;*.h;*.hh;*.hpp;*.hxx;*.inl;*.xpm;*.hrc;*.src;*.xcu;*.xcs;*.hdl is a good one to use), make sure the Recursive check box is checked, then click OK. You will have to manually add several extensions that this project uses, such as *.hrc, *.src, *.hdl and so on which the default option doesn’t include.

Repeat the above process for all the modules you want to manage.

What projects to add to workspace

First off, you shouldn’t add all modules in the libreoffice source tree to the workspace, since that would overwhelm SlickEdit’s tag database, and will slow down the editor. Instead, we recommend that you only add modules that are relevant to the work you are doing.

For instance, if you are working on the Calc part of the code base, it’s sufficient to only add sc, formula, and sal. The sal module includes definitions to the rtl::OUString and rtl::OUStringBuffer classes as well as rtl::math functions, so it’s good to add that project to the workspace no matter which area you work in.

If you use UNO API’s a lot, then it’s a good idea to add solver as a project, but only add files that are under solver/<inpath>/inc/offapi and solver/<inpath>/inc/udkapi to enable auto completions of UNO structs, enums, constants and so on. Make sure you add *.hdl files as well as *.hpp files under these directories.

If you work on a wide range of areas, then it’s recommended that you set up multiple workspaces for different areas of focus. Switching between workspaces is very fast in SlickEdit, so this set up should not cause any loss of workflow efficiency.

How to update the workspace tag database

SlickEdit uses one tag database per workspace to allow context-sensitive source code navigation. The tag database file is named after the workspace name, located in the same directory where the worksapce file is, and it has a .vtg extension. It so happens that, when you update your git tree, the source code is updated, but your tag database isn’t. To update your tag database,

1. Close the editor
2. Remove the .vtg file under the workspace directory
3. Re-open the editor

Once the editor sees the the tag file is missing for the workspace, it will re-tag the entire workspace.

This post was written by Kohei Yoshida and was reposted here with his permission. The original may be updated and/or extended and can be found here.

He shared it with our community here. Check it out and share any comments you have to help him expand it for both beginners and experts!

But if all we accomplished was in-person advertising, we probably wouldn’t invest the time, money, and effort required to set up a 10′x10′ booth for three days on the other side of the country. What really makes exhibiting worthwhile is the ability to keep our fingers on the pulse of the industry. We find out firsthand what languages, tools, and platforms are trending. And we can gauge what types of features and functionality prospective customers are looking for, and what they like (and don’t like) about the current tools they’re using.

Some observations from this year’s show…

Unity buzz

Mobile gaming platforms have exploded in the past few years, and the tools to support creating games for those devices are riding a wave of popularity. Unity had a very large presence this year, and they generated a considerable amount of excitement at the show. Fortunately for us, the built-in source code editing tools for Unity, while free, leave quite a bit to be desired. (I will not name said editor out of respect to the feature-challenged.) It’s no exaggeration to say that 1/4 of the folks that wanted to demo SlickEdit were looking for a decent code editor for their Unity projects.

Teach your children well

Many of the attendees at the show are university students, taking courses in software development and in some cases game development specific curricula. Note that these are not your typical four-year college Comp-Sci majors, taking courses in compilers and data structures. Rather, these students are mostly in two-year degree or career oriented certificate programs. A few years ago it seemed that the vast majority of these two-year students were learning Java, and primarily using free tools like Eclipse. This year I was pleasantly surprised to find that students are not being fed a diet of 100% Java, but are also being exposed to C/C++, delving into scripting and utility languages like Python, Perl, and Bash, and are being introduced to version control systems as part of their coursework. I’m hoping some of these real-work-world skills are finding their way back into the four-year programs.

Why aren’t you people using version control?

One of our features that really resonates with SlickEdit first-timers is our Backup History, which keeps an incremental versioning history of your source files each time you save. We like to think of this facility as a safety net between version control check-ins. When demoing this feature I usually ask what version control system folks are using, and I am met with far too many blanks stares. For every chin-high steady-of-voice declaration of “I use Subversion”, or “We use Perforce at the office, and I use Git at home”, there are an equal number of sheepish shoulder shrugs, admitting that nothing is in place. Well, good luck to you…

Flash is alive and well

Despite Apple’s decision to banish Flash from iPhones and iPads, plenty of Flash-based games are being written. And that means plenty of developers need to edit and navigate ActionScript source. When we first added proper ActionScript support to SlickEdit a few years ago (again, due to demand we witnessed at GDC), we assumed that demand and usage would taper off and die in a couple years. That assumption was wrong.

The art of trade show swag is suffering

The past few years we’ve been bringing USB flash drives to the show, with all the installers for our products pre-loaded. But our “fun” giveaway hasn’t changed for the past 5 years. It’s what I refer to as the “bouncy spider”, or “octopus yo-yo”. It looks like a multi-colored sea anemone suspended from a bungee cord, and you bounce it up and down. It has no useful function (besides attracting folks to our booth), but it’s always the hit of the show amongst the giveaway goodie cognoscenti. Usually someone else at the show has an equally cool giveaway. But not this year. The monotony of an endless sea of t-shirts, notebooks, knit caps, logo-ed plastic bags, and ballpoint pens was disheartening.

Overall we had a great, successful trip and will definitely be venturing back to San Francisco at the end of March 2013 for the next GDC! What was your experience at GDC this year? Leave a comment below to share!

We’re headed to the Game Developers Conference again this year! We’ll be in San Francisco from March 7 – 9 showing off our latest SlickEdit for Mac native Aqua interface version of SlickEdit as well as our newest features and improvements.

GDC is the world’s largest professionals-only game industry event. We’ll be there with hands-on demos of easy project set up, detailed back up history, context tagging, other productivity enhancing features, and of course our new Native Mac UI.

If you’re at the conference, stop by booth 815 to meet our team, learn about what we have in store for our customers in the near future, see our demos, and, of course, pick up some cool SlickEdit swag!

You can see what our booth looks like and also get an idea of what it’s like to be at the conference from this video that one of our developers made from GDC 2009.

The documentation provided with the SDK does a good job explaining how a “Server” application (an application that needs some editing done) can send and receive the appropriate AppleEvents to an editor like BBEdit. Many third party applications now support the client side, but the “how to” is not documented very well. For those not intimately familiar with AppleEvents, getting started can be a bit daunting. This article, and the provided sample applications, aim to fill in that knowledge gap.

Sample Source

The sample zip for this article contains:
LilPad – A small text editor application, which implements the client side of the ODB Editor Suite.
ODBServer – A testbed application which can be used to invoke ODB client applications.
ODBSuite – A directory containing a stub for the ODBEditorSuite.h header file. This must be downloaded directly from BareBones Software.

Handling the ‘Open File’ AppleEvent

Most document-based applications are already set up to handle this event. Even if you aren’t explicitly adding a handler for the kCoreEventClass/kAEOpenDocuments AppleEvent, the Cocoa frameworks are set up to handle this via your NSDocument class, or the NSApplicationDelegate application:openFiles: message. The LilPad sample application does this in the override of the readFromURL:ofType:error: message (in MyDocument.m).

The AppleEvent sent by an ODB Server app will contain the extra ‘FSnd’ (keyFileSender) parameter. The client application must save this identifier in order to properly respond to the server app. A server app will also usually send an identifying token (keyFileSenderToken, ‘FTok’) and a “Custom Path” (keyFileCustomPath, ‘Burl’), which is usually used to specify a more friendly display name, rather than the full file path. A client app can safely ignore the keyFileCustomPath parameter, but should retain the reference to the token if one is provided.

If you’re authoring an NSDocument-based application, you can store the associated parameters right in the document object. Otherwise, you’ll need to set up a dictionary to hold the parameter values.

Notifying the Server

The code that demonstrates notifying the server application is found in the LilPad sample, in MyDocument.m. The [MyDocument saveDocument:] and [MyDocument close] messages override the NSDocument base implementation in order to inform the server application that changes were made. [MyDocument setFileURL:] is overridden in order to handle the “Save As” operation.

The client application must do the following.

• Construct an AppleEvent with the class code of kODBEditorSuite.
  The eventID is either kAEModifiedFile, kAEClosedFile, or keyNewLocation.
  keyNewLocation is used when the client application performs a “Save As” operation.
• Identify the target of the AppleEvent by the server application’s package signature. This is the ‘FSnd’ value of the “Open Files” event.
• The keyDirectObject of the event should be set to the “file://path/to/doc.txt”-style URL of the modified/closed/renamed file, with a descriptor type of typeFileURL.
• If the original “Open Files” event specified a token, this should be sent back as the keySenderToken parameter. Simply provide the reference to the NSAppleEventDescriptor that was retained earlier from the keyFileSenderToken param.

Give it a spin

The ODBServer application can be used to test your ODB Client application. Simply replace the hard-coded reference to the LilPad bundle id (com.slickedit.lilpad) with that of your own application.

The prevailing wisdom at the time was that it would be easy for us to do a Mac version, “because it’s just UNIX now, and you guys are UNIX already – it’ll just be another port”.  I remember hearing this over and over at trade shows in between requests for Ruby support, and “Do you guys have any free t-shirts?” (Right now, there’s a guy in his basement inventing a new scripting language, convinced his will be the one that will take over the world, obsoleting all other scripting languages.  I really wish somebody would stop him, because it won’t take over and obsolete all other scripting languages, but it will become just popular enough we will have to support it.  When I say “stop him”, I don’t mean hurt him or anything – just take him out to dinner or introduce him to a woman).

It turns out the “It’s just UNIX now” logic is a bit, what’s the word I’m looking for…. wrong.  There is UNIX under there, and obviously that was a good place to start when they revamped MacOS.  Plus, I can get a console window which was always my complaint about Macs “back in the day” (yes, I know you could install something, I maintain it should just be there).  But what the fact that “It’s just UNIX now” got us was the ability to create an X11 application that would run on the Mac.  So we did that – and customers loved it.  Well, that isn’t exactly true.  They acted more like we gave them a new BMW but first used it for one of those things you see at the county fair where you pay a dollar and get to hit a car with a sledgehammer (granted they usually do this with demolition derby cars, not new BMWs).  It was SlickEdit – it worked, but it just didn’t look or feel like people expected it to. Hardcore SlickEdit fans were happy… ish.  They were happy to have SlickEdit, but they missed all the Mac-isms, and were a little perturbed by SlickEdit’s menu being attached right to the top of the application window.

So, starting sometime in 2010 our CTO began the process of exploring how to get us a native version on the Mac – and the GUI overhaul that ensued stayed largely in his office until sometime this past spring when different team members began to have certain controls assigned to them to port to our new GUI framework (I’m not going into which one here, the evidence is “out there”).  I was able to be part of this process, and it was very interesting work.  It is an exciting time to work here at SlickEdit.

We had a nice long beta test – a little longer than we planned. I would like to take a moment to say that our beta testers were some of the best we’ve ever dealt with.  Even when there were problems, the comments almost always went something like “It crashed, but thanks for doing a native Mac version, great work, looking forward to the next version!”.  The beta testers this time were aces – some of them old SlickEdit fans we’ve known for a while, and I believe we made some new friends too.  Thanks guys.

So, our native Mac version is “out there” now.  We hope everybody likes it.  Typically I haven’t been a big Mac fan, but I’m learning to appreciate the things that it does well.  I only wish I could get a few people to join me in an Indiana Jones like quest to track down the eleven remaining single button mice on the planet and then Ctrl+Click could work properly.

If you bought any of our X11 versions on the Mac you can get the new version for free. Here’s the link,or you can give our sales team a call at (919) 473-0070.

Caffeinated Soap
No, we’re not making this up. http://www.thinkgeek.com/interests/giftsunder10/5a65/ 
Between end-of-year project deadlines, gift shopping, and other holiday preparations, a coder can get really squeezed for time. And you don’t want to back a programmer into a corner where they have to choose between sufficient caffeination and personal hygiene. This should avoid any such unpleasantness.

A Blunt Instrument
http://www.harborfreight.com/4-lb-neon-orange-dead-blow-hammer-41800.html
There are situations in which you simply cannot improve upon a large hammer.  This is the reason that the B-52 has had such a long lifespan. This orange beauty will allow your beloved techie to vent frustration upon keyboards, desks, recalcitrant Solaris machines, etc without the risk of forehead or hand injury.

A “Come home for dinner late” card
It’s surprising how many bugs are found just after the “I’ll be home by 6:15 for dinner” phone call. Your programmer is now torn between a promise to loved ones and a dedication to hunting down that crash before calling it a day. Give them a Monopoly-style “Get out of dinner, free” card so that at least once this year week, they can arrive late without guilt.

A USB-chargeable flashlight
http://www.berettausa.com/products/jolt-usb-flash-light-b2c-only-blue/
A USB flashlight is insidious in its irresistible blend of techie-seducing features. First off, it’s a USB device. *Anything* USB (and to a lesser extent FireWire) is worthy of investigation. Secondly, it’s the size and shape of most trade show trinkets, which programmers are wired at birth to hoard. Thirdly, it has a genuinely useful function, which all but ensures your coder will make every effort to rationalize this gadget’s place in the laptop bag for years to come.

Carpal Tunnel Therapy
http://www.amazon.com/Roleo-Therapeutic-Carpal-Therapy-Massager/dp/B005CP4GDA/
Because sometimes you gotta play hurt.
(Not yet verified, but I think this thing can also make homemade ravioli…)

Yoga Gear
http://www.amazon.com/Office-Yoga-Simple-Stretches-People/dp/0811826856
Not only is this great for relieving the tension of long hours frozen at the keyboard, it appears to also be a crafty way of furthering ones career.

Let’s assume you have some file extension which is not already set up accurately in the default SlickEdit Core configuration. It might be something your company only uses internally. Let’s use .data for this example.

I have a workspace created which includes some .data files, and what I first see in the Navigator view is this:

When I go to open one of these files, Eclipse will use the standard Text Editor because it does not know better:

Not terribly useful…clearly the SlickEdit editor has not been opened, and we have no language support whatsoever. These appear to be COBOL files…so we should set up Eclipse to recognize them as such, and also tell SlickEdit that these files should be treated as COBOL code.

The first step is to go to Window > Preferences > Editors > File Associations and add *.data as a “New File Type”. Then select *.data in the list and click the Add button in the “Associated Editors” pane. Now select “SlickEdit Editor”. Make sure you mark “SlickEdit Editor” as the “Default” editor for this file type. Now we have told Eclipse to open all .data files with the SlickEdit Editor.

We are not quite finished yet. Now we need to tell SlickEdit to treat these files as COBOL. So, go to Window > SlickEdit Preferences > Languages > File Extension Manager and create a new extension for data (just data…not *.data), and assign the language to be Cobol 85. Click “OK”, and then click “OK” on the SlickEdit Preferences dialog. Now when you open up one of these .data files, you will see the correct editor opened with the correct language support.

Since the Eclipse IDE has become so popular for mainframe developers, we have been dedicating more and more resources to our mainframe language support. The SlickEdit editor is even now integrated into the Compuware Workbench:

Supports a vast array of programming languages for source code editing, powered by SlickEdit.

PL/I is one of the mainframe languages that got a major support upgrade in the newly released SlickEdit Core v3.7.1. The SlickEdit editor now has full support for parsing structures, includes, and even statement level tagging for PL/I code.

SlickEdit Core also has great support for COBOL, JCL, REXX, and other languages. If you are a mainframe developer coding in an Eclipse-based environment, try out the latest version of the SlickEdit Core plugin for free.

SlickEdit is an MDI application
While there are some very well known applications that support a multiple document interface on the Mac, there is no real standard for how they should look and feel. Each application has a slightly different interpretation. As such we have chosen to keep our MDI implementation very close to what we have used in recent versions.

SlickEdit does a lot
This mostly affects how we present our application configuration options. Most Mac applications have a relatively small Preferences pane, perhaps with half a dozen categories, and a half-page screen of options for each category. But SlickEdit has 20+ years worth of features and configuration settings. Developers come to SlickEdit from a wide variety of editing environments, and our users want to be able to mold the application to their tastes.

SlickEdit is not just for the Mac
Like all multi-platform software, we have to make trade-offs between what might look best for a particular operating system, and what makes the most sense for a feature that needs to work on all of the supported platforms. There is also quite a bit of bias toward keeping functionality and appearance consistent with what long-time customers want and expect. SlickEdit has always placed a premium on letting you work with multiple languages on disparate platforms without having to retrain your brain and fingers. When implementing and tweaking features, we are constantly evaluating what a Mac user would expect, and what a SlickEdit user (regardless of platform) would expect.

SlickEdit will continue to evolve
While we do want to keep our product familiar across platforms, we aren’t going to be sitting stock still. While our immediate focus for the Mac is improvements to Objective-C language support, and better interoperability with Xcode project formats, we are looking forward to changes we can make in the user interface to improve effectiveness and efficiency. Getting this first non-X11 release ready was a big effort. And now that it’s almost done, we’re looking forward to making it the best it can be. We’re excited, and we hope that you will be too.

If you haven’t yet taken a look at SlickEdit 2011 for Mac, we invite you download our most recent beta version.

I didn’t buy your book. There are several reasons I walked out the door without shelling out for your title.

First off, fifty bucks on the sticker price subjects a book to a lot of extra scrutiny. When I think of all I can do with that sum, the bar gets set pretty high. This used to be somewhat ameliorated when Borders was still a going concern. Their frequent 30% and 40% discount coupons made me a little more cavalier in my purchasing decisions. I am now limited to shopping Barnes and Noble. They have a good selection of titles, but they are a bit more stingy with the coupons, and a 10% discount barely covers our state sales tax. I’m still willing to part with two Jacksons or more, but you’ve gotta wow me.

Why does your book have 10 authors, including 9 I’ve never heard of? Unless I’m reading a short story anthology, I’d prefer to see just one or two subject matter experts. I get a little suspicious when the author count goes above 3.

Annotated code samples and snippets are wonderful. And bonus points can be earned for legibility-enhancing color coding. But I really don’t care to pay for the trees you chopped down to provide over 200 pages of mostly boilerplate code. I work with computers for a living, so I’m not afraid to download a zip file with source code. Look into it.

Your book won’t stay open. I know a nice binding, especially a hardback binding is going to cost more. But I don’t have two sets of arms. Most of the time I’m reading a computer book while trying to work on the computer. I’d prefer not to have to pin down a page with empty coffee mugs and my left elbow while trying to type in a code sample.

Your index isn’t helping me find what I need. If I’m in the market for a programming title, it’s often because I am unfamiliar with the language or technology. And since I’m not plugged into the lingo yet, I need all the help I can get finding the relevant passages. An index that is 90% class and function names does me little good.

Before you decry how internet retailers are pushing down your margins, let me assure you that I still buy most of my software titles in a brick and mortar store. I’ve been disappointed too many times buying books online, sight unseen. I need to hold a book in my hands and flip few a couple chapters. I’ll buy that book in the store, but you’re going to have to work a little harder for my money.

Sincerely,

TechBookShopper

The winner will receive an iPad 2 valued at $499 (he/she may opt to receive a visa gift card of equal value instead).

So, what are we looking for? In an attempt to not limit your creativity and critical thinking, we are keeping this as open-ended as possible. The winning submission will stand out from the rest. Maybe it does something really neat and creative, or it solves a widespread problem with just one line of code. Your submission doesn’t have to be long or short, but it has to wow us in order to win the iPad!

You can enter now through October 31, 2011, so there is plenty of time to put your best macro together and submit it for your chance to win! Click here for contest rules and how to enter.

Look at this. It’s worthless – ten dollars from a vendor in the street. But I take it, I bury it in the sand for a thousand years, it becomes priceless. Men will kill for it. Men like you and me.
- René Belloq, Raiders of the Lost Ark

Whether it be changing jobs, moving to a new house or office, or simply cleaning out clutter, every so often I find myself sorting through the bits of technology-related junk I’ve accumulated over the years. There’s a fair amount of trade show goodies, some of them entirely too cool or valuable to part with. The bulk of it is reluctantly thrown away, including stress-relief squeezy things, can coolers, light up pens that no longer light, and the like. But there are items that always survive the cut, ones that have some sentimentality attached to them.

Professional Developers Conference 2000 pen

I cannot believe this thing still writes after 11 years. It has lived in the glove box of the three different cars I’ve owned since 2000. This was the PDC where Microsoft formally introduced the .NET platform to the masses. I vividly recall the stunned looks on thousands of keynote attendees as they realized all their Win32 mastery was just rendered obsolete. The pen has actually outlasted several .NET technologies introduced at the conference. I’ve got one from the 2003 PDC ready to go once this one runs out of ink.

Cyrix x86 processor

A leftover from my system building days. It was the first real ultra-cheap x86 alternative, and prompted Intel to develop the Celeron line. I placed this in a slapped-together spare parts budget computer (running Windows 95) that I assembled for my wife’s grandparents. Cyrix as a company didn’t last long, but this chip powered that system for over a decade. Now that the grandparents are gone, I can’t bear to toss this hunk of silicon junk.

NeXT Step poster

I got this gem in a trade with my wife’s uncle, a sysadmin, for a Windows Server 2000 license. It’s a panorama of the first generation NeXT system, replete with all black computer, keyboard, monitor, and printer. I’ve been meaning to put it up on my office wall, but I can’t bring myself to stick pins through it, and I can’t justify the cash it would take to frame it.

Do you have anything like this that you can’t seem to part with? Please share by leaving a reply!

In order to become a better golfer I decided to start from scratch, beginning with lessons from a PGA pro and purchasing a set of clubs suited to my ‘experienced beginner’ game. And in the process I have found some interesting parallels between learning to golf (again) and learning to use a code editor.

You need solid fundamentals as your foundation
Having been a badly-self-taught golfer for the majority of my life, I now see them all the time at the driving range. And it always starts with the hands. If you have a lousy grip, you’re going to have a lousy swing. The corollary in software development in my mind is basic typing and keyboard navigation skills. You can have a talented mind for software development, but if you’re not touch typing your way through source code, you’re making it way too hard on yourself.

Know and use the tools available to you
I recall a time when my high school golf coach, in a effort to make a point about club selection (or perhaps just to show off), played a few holes with just a 3 wood, a 7 iron, and a putter. This is eleven clubs fewer than you’re allowed to carry. We got the point he was trying to make, but you don’t see good players with fewer than 14 clubs in the bag. And they aren’t using the cheapest off-the-shelf sticks, either.

I also recall a PDC conference session several years ago where the presenter was banging out ASP.NET examples and frequently used Notepad to tweak some of his prepared code snippets. The audience started tuning out about the 5th time he had to repeat the edit-save-compile cycle on a particularly troublesome sample, when the use of any decent code editor would have shown the syntax error at the top of the file right away.

Master the basics so you can focus on the harder tasks
Once you have a solid, reliably repeatable golf swing, your mind is free to focus on all the other details of the game. A software developer that is in command of his or her IDEs, editors, debuggers, etc is likewise free to focus on the real work of designing and coding.

Everybody’s “key move” is different
One night at the driving range I was having a terrible time making clean contact with the ball, even with the deliberate practice of what my golf coach and I had just gone over in the previous lesson. But somewhere in the recesses of my memory I pulled out a tip I had read in Ben Hogan’s Five Lessons where he recommends a wrist waggle as part of the pre-shot routine. So I gave it a try. Lo and behold the waggle made it quite evident that my stance was too close to the ball. After making the adjustment, everything else fell into place. Now I don’t swing a club without this waggle routine.

Most software developers have their favorite features and shortcuts in their editor of choice. These features become an essential part of how they navigate a source base or edit code. My key move in SlickEdit is using the SlickEdit command line. It’s the first place I go when I want to do a quick search, compare the current file with Subversion, look up a keyboard shortcut, and dozens of other operations. Other folks swear by aliases or custom macros. Some will create custom key bindings for every conceivable editor operation.

Demo clubs are awesome
I tried out half a dozen models of clubs before finding the set that I liked the best and felt right for my work-in-progress swing. If you’re not yet carrying SlickEdit in your tour bag, we invite you to download a trial and take it out on the range.

The primary oddity I see is the scheduling of the release. Hot fixes are easy. A problem comes up, you investigate and fix it, then send out the small update. And for us at SlickEdit, major releases are dictated by our annual release cycle. We *will* have a beta in the early spring and we *will* have the major release out late spring/early summer. Lawns go un-mowed, playoff hockey goes unwatched, and “I’ll be home for dinner” promises are broken in order to meet the schedule. For hot fixes and major releases all of the time pressure is one-way: the sooner the better.

A point release is just harder to time as there are forces pulling at both ends of the schedule. An earlier release means customers don’t have to wait as long for the features we had to let slip initially. There is a shorter wait for resolutions to the small bugs that didn’t warrant a hot fix. An earlier release means that the quality of the trial version is better sooner. And the quicker it goes out the door, the sooner we can focus all attention on feature development for the next major release.

But there are also forces that want to delay the service pack. More time means more polish, fewer bugs, and more special requests that can be accommodated.

This release is a little more poignant for me personally. I primarily work on the Mac version of SlickEdit. And we are committed to providing a native version for 2012, meaning that we’re finally getting rid of our X11-based UI. It’s a welcome (admittedly overdue) change, and I’m enjoying the early progress we’re making. But this release of 16.0.1 represents the last chance we have to make the X11 version work as well as it can.

But now the release notes have been finalized, customers have received the update e-mails, and it’s time to call 16.0.1 done.