A recent phenomenon I have noticed in the digg comment section is the use of “/sarcasm” at the end of a user submitted comment. This suffix is added by the author to indicate what should be obvious for any truly sarcastic statement.  Like a terrible joke that require an explanation, a sarcastic comment that requires /sarcasm at the end is never funny. Has anyone on the planet ever said or thought the following: “Oh my, that comment was very rude… oh… wait.. he put /sarcasm on the end… he was being sarcastic! Dear lord, I get it now! That is HILARIOUS!” ? I ask you.

For a little bit of history, a forward slash is used to indicate the end of a tag in markup languages such as HTML. /sarcasm might be literally translated as “end of sarcastic statement.” A fully formed markup would also include an opening tag and could look like this: <sarcasm>I hate sarcastic comments</sarcasm>. Though I have no definitive proof of such, I believe the phenomenon was first used to indicate a frustrating “rant” for example: <rant>I hate the /sarcasm tag</rant>. In the early days of web based forums, this full (formal, if you will) syntax would was used. In these days of OMG and ROTFL, time is of the essence. The opening tag has fallen to the wayside in the name of progress.

Sarcasm, as with most forms of humor, is a subtle art. There are really only two exceptions to this rule: 1. Home videos of fathers and/or uncles getting kicked in the nuts and 2. Baboons with the bald, red asses. Those are rarely subtle, but always funny. The /sarcasm tag, I feel, has empowered a group of amateurs to attempt feats of sarcasm best left to professionals. The point of sarcasm is that it is funny - without further explanation needed. Like a great joke, it doesn’t need to be explained. Sarcasm is an inside joke for those who have transcended language as merely a means of crude communication. People who understand it are part of an elite club you might say - the We  Understand Simple Sarcasm Yes! club (WUSSY).

The point of this opinion piece… if you are writing a comment and notice that you are typing /sarcasm on the end, stop! Do you really *need* to tell us that? Is your post even funny in a sarcastic way? Drop the suffix. Put it out there on the line. No more safety net. Have a nice day.

/sarcasm /sarcasm

(the second /sarcasm is to indicate that the first /sarcasm is sarcastic. I am in fact *not* being sarcastic)

Share This

Though many teams are using Subversion (SVN) to work together and share code, version control software provides a huge number of features that are not often used.  Just about any developer these days knows how to checkout a project and commit or revert changes.  But a lot of teams don’t really use or need anything beyond that.

The great thing about version control systems like SVN is that you gain a bunch of really useful functionality - even if you have only been using it for sharing code.  One of those features is the ability to create an export of all modified files since the previous release.  A common scenario for this is when you are working on a web application and it’s time to deploy all the recent changes to the production server.  You might think that you need to delve into tagging and branching to do this, but that is not necessary.

Lets say that you last deployed your application from repository version #500.  After a few weeks of development, the repository is now up to revision #575.  The team has decided that the code is stable and you are ready to package up all new/changed files to transfer to the host server, client, etc.

1. Using TortoiseSVN, right-click on your working folder and select “Show Log” from the TortoiseSVN menu.
2. Click the revision that was last published (#500 in this example)
3. Ctrl+Click the HEAD revision (or whatever revision you want to release ie #575) so that both the old and the new revisions are highlighted.
4. Right-click on either of the highlighted revisions and select “Compare revisions.”  This will open a dialog window that lists all new/modified files.
5. Select all files from this list (Ctrl+a) then right-click on the highlighted files and select “Export selection to…”

You’ll be prompted for a location to save your updated files and SVN will export them all with the directory structure preserved.  You can then zip this up for your client, transfer it to your host or whatever you normally do to deploy the application.

Some teams prefer to actually do an update right on the production server and simply checkout the files that way.  If your hosting setup permits and you don’t mind the “.svn” files in on your server, that is another easy option for deploying code.

For even more automation, this could all be done using batch, shell or ant build scripts.  If you have such a script, please feel free to post it in the comments.

Share This