Of course, there’s nothing funnier in IT than the movie “Office Space.”  I once had a research psychiatrist tell me that she thought it was a funny movie, so I corrected her, dryly explaining that the movie was actually a documentary about life in IT.  Here’s the famous “What Would You Say You Do Here?” scene, parodied by CRC Data Protection.

Here’s another great one.  Incredibly, it is for IBM’s mainframe division!  It parodies the lonely life of the mainframe sales team, done in the style of “The Office.”

Among other big enhancements, Exchange Server 2010 does away with traditional backups and can only be backed up through VSS.  As a result, new versions of backup clients (such as TSM TDP for Mail) are needed.

I’m personally excited about the announcement, as we are currently testing Exchange Server 2010.  I’ve been waiting for support to be added so I can bring Exchange under our TSM umbrella.  Plus it will be nice to get another production service away from BackupExec!

The announcement is here.

I’m just hoping that we don’t have any further reminders for the rest of the week.

There were two problems that I was experiencing. The first was that F1-F4 were mapped differently, for what appears to be historical reasons (VT100 terminals did not have these keys). The other was that the telnet client needed to be in character mode, instead of line mode, and there was no easy way to do this in the Linux telnet client except through the user manually changing the mode.

So I used Expect to translate the F1-F4 keys to what the remote MSCA telnet server wanted, and then used C-Kermit as my telnet client. The scripts I wrote to perform these two steps are as follows:

 #!/usr/local/bin/kermit

 set telnet newline-mode nvt raw
 set telnet echo remote

 telnet /nowait host.company.com 12345

 quit

and

 #!/usr/bin/expect

 eval spawn -noecho "/usr/local/bin/ktelnet.sh"

 interact {
 "\033[[A" { send "\033[P" }
 "\033[[B" { send "\033[Q" }
 "\033[[C" { send "\033[R" }
 "\033[[D" { send "\033[S" }
 }

Unfortunately, Kevin failed to mention a potential downside of having one of these babies. Namely, your developers and consultants will assume (even more than they probably already do) that whatever junk code they throw at the machine will run flawlessly. And if it doesn’t, it must be the DBA or Unix team’s fault.

I don’t have a dog in this fight, but it seems a bit strange that one vendor (EMC) is asking its customers to harangue another vendor (Oracle). This is the bad part about using best-of-breed – there’s always the potential for finger-pointing. Why remind customers of this right when a competitor is going vertical, instead of highlighting how much better value you might be able to provide?

My big takeaway is that Oracle has positioned itself as a soup-to-nuts vendor. That is, they will be able to sell you every part of the system, from the SPARC server running Solaris, to the StorageTek tape backup, to the Oracle database, to the business application, which just happens to be written in Java.

This isn’t too terribly different from what Jonathan Schwartz was saying recently, that Sun provided the technology stack. Except that Sun had no applications to tie into – particularly since so many Oracle customers jumped ship and ran to Linux in the last decade. Obviously, Oracle now has plenty of reason to try to convince everyone to return.

Whether or not the strategy works, I still think Solaris is the best operating system on the block, and would love to see a reinvigorated SPARC platform as a viable option.

I had a nice reminder recently of why it’s good to stick to best practices when putting something shiny and new out for others to see. Something that was supposed to be easy ended up causing some furrowed brows for a bit. Luckily, it ended up being just a bump in the road thanks to some spot-on work by my creative counterpart, and some good, old-fashioned use of vi (still the handiest tool to have around, in my book).

So basically we learned a lot about the surprisingly crazy things that WordPress will do when moved without due care. Like modify your theme’s source code. And also, it was a good reminder to follow best practices when deploying an application, even when it looks like a slam dunk.

I know many of you already practice this, and it’s a bit of preaching to the choir, but hey, everyone in IT loves to talk about how things should be done, so let’s sing it together:

1. Have development, test, and production environments that are separate but identical
2. Keep developers out of test and especially production environments
3. Use the same tools and procedures for moving updates from test to development as from development to test
4. Have someone who wasn’t involved in the development do the testing
5. Have someone who was involved in the development on hand in case something goes wrong
6. Have a good text editor handy
7. Know more than you need to, just in case
8. You do have a backup of production prior to making the change, right? Right?

Now, it is often the case that you or your client may not have the resources for development, test, and production environments. But having separate environments saves you so many headaches, that I advise you to grab an old desktop system and run free virtualization software (such as VMware Server or Sun VirtualBox). If you’ve never had a formal process for doing this, it will seem like a waste of time at first, but trust me, it will save you plenty of heartburn down the road. Besides, a line about “virtualization” looks great on the resume!

Once you have separate environments, and have an app that is looking good, you can deploy it to your test environment. Try to keep the test environment as restricted as possible, since you want any changes that need to be made done in the development environment. If possible, have someone not involved in creating or configuring the app test it. A coworker, an end user, or, if you’re lucky, one of those jaded QA types. Notice that you’ll not only be testing your application, you’ll also be testing how you will be deploying the application to production.

In my experience, it’s best if the developers do not have access into your testing environment. Expect lot of complaining about this one, but you do not want developers saying, “oh, that’s not a big deal, I’ll just fix it in test,” and ruining the point of having separate development and testing environments (and usually the code repository, as well). I can’t count the number of times I have seen this cause problems.

After everything’s passed testing with flying colors (send it back to dev if it doesn’t), you’re ready to push your app out into production. Since you’ve already done the process once successfully, it should be a breeze the second (or thirteenth) time through. Pat yourself on the back and head out early to the local brewpub (after making sure that everything is working fine, of course!).

And we all know that there are times when it certainly doesn’t work fine. Which in a sense is why we’re all paid the big bucks, right? When things do go wrong, it’s best to have good resources on hand, whether it’s debugging tools or debuggers. Far too many times, I’ve seen the people who developed an application, configuration, or whatnot, walk out the door on their way to vacation about 10 minutes prior to go-live. In many situations, simply having another knowledgeable person around will help immensely. If you’re doing something specialized, like anything spelled “Oracle,” keep your DBA’s phone number handy and verify that someone is paying the licensing bills (a former employer did this to themselves six months after I left – they tried to save money by not paying for software and ended up being down for two solid weeks – genius!).

As for tools, it always pays to have a good text editor, that you’re familiar with, handy. Vi, which I mentioned before, is extremely useful. Since it’s available on basically every Unix and Linux system, it’s a good idea to have a basic knowledge. On OS X, I’ve been very happy with TextMate, which recognizes a large number of text file formats (eg, HTML, Perl, PHP, etc.). Even lowly, unloved Notepad is an effective and useful Post-It Note. Other tools that are especially helpful include tcpdump and lsof on Unix, SQLdeveloper or SQL*Plus when working with Oracle, and with Windows, keep the install CDs handy!

Then there’s you. I really encourage everyone to have a basic understanding of how different platforms work, as I have yet to see an IT shop that ran completely on a single platform. Almost everybody has some mix of Windows and Unix servers, Cisco or low-end networking hardware, a database or three, some sort of storage, and probably the phones, too. If you know the basics of how most of those things work – and especially, how they talk to one another – your life is going to be a lot easier. And again, looks great on the resume.

Finally, make sure you have a good backup before you do anything. This goes double for big, important databases that C-level execs notice when it goes down.