My co-worker and I spent the better part of yesterday afternoon going through a former employee’s shell scripts to try to determine what they were and what he was trying to do. The script worked, for a while, but there were several mistakes. The mistakes were not in strict syntax, they were in style. Here are a few simple rules to follow to write great scripts:

1. Always, always, always start off each and every script with a shbang line: #!/bin/sh. Starting off your script with this line tells your shell where to find the interpreter for the commands in the script. Without this line, the script is using your user’s existing shell, the one you are typing in at the moment. This is bad because you are sharing environmental variables, and maybe changing environmental variables outside of your script, and not keeping it self contained and portable.

2. Keep your script self contained: If at all possible, try to avoid writing files in different directories. Or, even better, try to avoid writing files at all. Use variables when you can, write files when you have to.

3. Avoid sourcing other scripts or files containing functions: I read about this method in Wicked Cool Shell Scripts, but I disagree that it is as useful as they say. Writing a custom function to send an email is a great idea. separating it out of the script you are working on at the time is not. Again, keep the script self contained. There are obvious exceptions to this rule. If your function is over 50 lines of code, and reused in multiple other scripts, then by all means, source it. If your function is 10 lines, create a vi shortcut for it and add it to the top of the script.

4. Comment tasks: Each block of code in your shell script is meant for a specific task. Add a comment for this block. Make it easy to read, and simple to understand. Assume that you will not work there forever, and someone else will need to read your code and make sense out of it. Also assume that in a year, you will forget everything you did and why you did it and need a reminder.

5. Keep it simple: Scripts should flow logically from top to bottom. If you are creating functions, make it obvious using a comment. Reading a script should be as easy as reading a book, if it’s not, then you are intentionally making things overly complicated and difficult to read.

6. End each script with #EOF: This is purely a matter of taste, but I find it adds a nice closure to the script.

The easiest thing to do is to create another script who’s purpose in life is to create new scripts. Couple this script with a vi shortcut (mine is ,t) to create the skeleton of the script and you can quickly create powerful, well formatted, easy to read scripts. Here’s an example of mine:

#!/bin/sh
# 
# scripty.sh: This script creates other scripts
# Created: 25 Feb. 2009 -- inbound@jonathanbuys.com 
#
##############################################################

# A place for variables
VAR1="Set any variables at the top"
DATE=`date`
ANDTHEN="Whatever"

# A place for functions
some_func(){
    echo `date`
    echo "Whatever's Clever!"
}

# Get down to writing the script

echo $VAR1
echo $DATE
echo $ANDTHEN
some_func
# etc...

##############################################################
#EOF

This article doesn’t talk about syntax, only style. There’s plenty of help with syntax available on the Intertubes. Also, this is my style, as you progress as a sysadmin or scripter of some sort or another, you are bound to come up with your own style that suits you. My style is based on the documentation at grox.net. My style has evolved over time, as will yours, but this is a good place to start.

From time to time I’m asked by members of my family or friends of mine outside the tech industry what it is that I do for a living. When I respond that I’m a sysadmin, or systems administrator for Linux and UNIX servers, more times than not I get the “deer in the headlights” look that says I may as well be speaking Greek. So, for a while, I’ve taken to saying “I work in IT”, or “I work with computers, really big computers” or even “I’m a computer programmer”, which isn’t exactly accurate. Although I do write scripts, or even some moderate perl, I’m still not officially a programmer. I’m a systems administrator, so, let me try to explain, my dear friends and family, what it is I do in my little box all day.

First, some basics, let’s start at square one. Computers are comprised of two parts, hardware and software. Sort of like the body and soul of a person. Without hardware, software is useless, and vice-versa. The most basic parts of the hardware are the CPU, which is the brain, the RAM, which is the memory, the disk, which is a place to put things, and the network card, which lets you talk to other computers. For each of these pieces of hardware there needs to be some way to tell them how to do what they are intended to do. Software tells the hardware what to do. I forgot two important pieces of hardware: the screen and the keyboard/mouse. They let us interact with the computer, at least until I can just tell it what to do Star Trek style.

Getting all of these pieces of hardware doing the right thing at the right time is complicated, and requires a structured system, along with rules that govern how people can interact with the computer. This system is the Operating System (OS). There are many popular operating systems: Windows, OS X, and Linux are the big three right now. The OS tells the hardware what to do, and allows the user to add other applications (programs) to the computer.

Smaller computers, like your home desktop or laptop have network cards to get on the Internet. The network card will be either wired or wireless, that doesn’t really matter. When you get on the Internet, you can send and receive information to and from other computers. This information could be an email, a web page, music, or lots of other media. Most of the time, you are getting this information from a large computer, or large group of computers that give out information to lots of home computers just like yours. Since these computers “serve” information, they are referred to as Servers.

Large servers are much like your home computer. They have CPU, RAM, disk, etc… They just have more of it. The basics still apply though. Servers have their own operating system, normally either Windows, Linux or UNIX. Some web sites or web services (like email) can live on lots of different servers, each server having its own job to do to make sure that you can load a web page in your browser. To manage, or “administer” these servers is my job. I administer the system that ensures the servers are doing what they are supposed to do. I am a systems administrator. It is my responsibility to make sure that the servers are physically where they are supposed to be (a data center, in a rack), that they have power and networking, that the OS is installed and up to date, and that the OS is properly configured to do its job, whatever that job may be.

I am specifically a UNIX sysadmin, which means that I’ve spent time learning the UNIX interface, which is mostly text typed into a terminal, and it looks a lot like code. This differs from Windows sysadmins, who spend most of their time in an interface that looks similar to a Windows desktop computer. UNIX has evolved into Linux, which is more user friendly and flexible, and also where I spend most of my time.

Being a sysadmin is a good job in a tech driven economy. I’ve got my reservations about its future, but I may be wrong. Even if I’m not, the IT field changes so rapidly that I’m sure what I’m doing now is not what I’ll be doing 5-10 years from now. One of these days, maybe I’ll open a coffee shop or a restaurant, or I’ll finally write a book.

A few days ago I decided that I was not going to use anyone else’s theme on my site. It happened after I stumbled across another site using the exact same theme as mine. Unavoidable really, as long as you are using someone else’s theme. So, the decision was to either stop using Wordpress, or to design my own theme. I love Wordpress, so I decided to go with the latter.

Designing a web site is a strange mix of code and graphic design. In my case, I’ve had to go back to php, a language I left a long time ago, and start learning CSS. Since I’ve been fooling around in Cocoa for quite a while, going back to php is just painful. Objective-C is a beautiful programming language. Mixing php and html… well, that’s just plain ugly. However, that being said, it’s familiar territory, so I almost feel like I’m coming home. One concept that I’ve learned with Cocoa is the Modal-View-Controller method, basically separating out the presentation code from the application code (yes, I know there is a lot, lot, lot more to it than that… no I’m not going to get into it here), using CSS kind of reminds me of the MVC method, in your php/xhtml code you define what objects are going to be displayed, and in CSS you define where and how to display them. I like the separation… keeps it clean.

At any rate, I’ve been busy coming up with the overall look and feel of the site. One thing I believe about software is that simplicity always wins. At least where I’m concerned it does, that’s why I use a lot of the apps that I use, because they are simple to use. Think about the Google home page. Simple, and it wins.

I’d appreciate any comments on the design, and please keep in mind this is only a very early mockup. Also, I’m going to be using this as my avatar for everywhere that I’ve got an account online: A friend of mine, who actually is a designer, laughed when I told him about the tools I’ve been using to do the design so far. First, the initial concept was created in OmniGraffle. From OmniGraffle, I’d export it as a Photoshop file and open it in Pixelmator to add the leaves and other touch ups. Right now, that’s as far as I’ve got. I’ll finish the design in the next couple of days, and then move into chopping the file up and getting deep into some code. Hopefully, I’ll have this finished in two or three weeks.

For better or worse, we are starting to put Ubuntu JeOS images into production in our network. Starting off, we will only put these systems in for our non-IBM services, no WebSphere or DB2, as IBM doesn’t officially support this configuration yet, but for everything else, JeOS looks like a perfect fit.

Most of our production systems currently use SuSE Linux Enterprise Server (SLES), which is an excellent OS, but requires you to purchase a license in order to download patches and updates. This is fine for the majority of our production systems, but as the number of our virtual systems grows, so does the complexity of management overhead that goes along with it. We can quickly put a new SLES box into production if needed, but, will it be licensed? Will it be able to download the latest patches? SLES 8 and 9 were fairly lenient about it, SLES 10 is not. With Ubuntu, we never have to worry about if we are going to be able to download the latest security patches, they are always freely available, which brings me to my next point:

There is very little installed with the default JeOS image, there truly is “just enough” to get up and running. Reminds me of the bare-bones OpenBSD installs I used to do 7 or 8 (9?) years ago. Follow up with “sudo apt-get install ufw clamav” and you’ve got a very secure, firewalled, anti-virus scanned system. Yes, clam and ufw both need more configuration, but even that is dead easy. Also, I really like the concept of not having a root user, and having to use sudo to accomplish anything.

The final thing I enjoy about Ubuntu is that it’s just easy to use. Today, I set up Request Tracker (better known as RT) from Best Practical. It was so easy, the 3.6 version is in the repositories, so installing it was a quick apt-get away. Comparatively, using SLES, I had to run their “make testdeps” and “make testdeps” scripts to try and download and compile all of the perl prerequisites, not to mention Apache, MySQL, and mod_perl.

RT is the first app that I’m moving over to an Ubuntu JeOS. It will be quickly followed by Nagios, Webmin, and then Postfix and an Apache web server hosting our company web site. The idea is to make each of these services a virtual appliance, so we could move them around easily, and work on one without affecting the others.

It was June of 1996 when I arrived in Rota. The Spanish sun was bright as I stepped off the creaky military aircraft, and I realized that this day would hold a lot of firsts for me. Today, I was going to meet my ship.

This was the day for which I had been preparing for the last year; U.S. Navy boot camp in Chicago, followed by engineering common core, (a school designed to teach us young recruits about the basics of engineering, like, how to turn a valve), then a class A school in San Diego where the curriculum taught how to create machinery parts out of metal stock using a lathe and mill, and where I learned how to stick a twenty in my sock in Tijuana to pay off the crooked cops. That whirlwind of confused order was designed to prepare me for this experience, this day, when I begin to earn the title that the United States government has given me. Today when I set foot on the ship, I will earn the name Sailor.

After twelve hours of being cramped up in the suffocating small cabin of the plane, suffering through the tiny, dry in-flight meals, and two movies that I could neither see clearly through the array of heads in my line of sight, or hear through the headphones that did not fit properly on my head, I was relieved to be out in the fresh air again. But my reprise was short lived, as the airport staff soon herded us into the airport to collect our baggage. Only one bag for me, the Navy seabag, packed tight with everything that I owned in the world, except what was boxed up at my parents house in Montana. I reached down and grabbed my seabag, and hefted it up to my shoulders. As I turned around, a stocky Hispanic man with thick glasses and tight black hair wearing Navy dungarees asked me, “You fireman Buys?” he asked. “Yes”, I replied, “Fireman Recruit Buys.” A broad grin stretched out across his face as he laughed and said, “Ok, Fireman Recruit Buys, I’m Petty Officer Garcia. Welcome aboard, and follow me.”

Why was he welcoming me aboard, I wondered, I’m not on the ship yet. I brushed my trivial concerns behind me and followed him to his plain white government issue van. We had only a short drive until we stopped in a gravel parking lot in front of a long concrete pier. I hauled out my seabag and followed Petty Officer Garcia up the pier. It smelled of salt water and fuel, the breeze light on my skin. It was then that I got my first good look at the ship I would be calling home for the next few years. Haze gray paint covered the hull of the oiler named USS Platte. The ship was smaller, and less impressive than I thought it would be. Still, it was a good sized ship, approximately two football fields long. The first two thirds of the ship were dominated by seven kingposts, metal towers bearing large black hoses. The last third was split; half was the house, at the top of which was the bridge. At the aft end of the ship was a small flight deck, large enough for one helicopter.

As Petty Officer Garcia led me up the metal brow, I pulled out my military ID. At the top of the brow I reached the quarter deck. Before stepping foot on the metal deck, I faced the American Flag, stood at attention for a moment to pay respect. Then I turned to the officer of the deck, stood at attention and presented my ID. “Permission to come aboard.” I requested. “Very well.” Came the reply. I then set foot on the deck of the ship, a sailor at last. Yes, it was very well indeed.

In December 1995 I was halfway through boot camp, a time called service week. Service week was when the recruits went to work in the galley. Some served food, other mopped the floor, and still others handed out miniature boxes of cereal.

My name was chosen alphabetically for assignment to the GI Hole. There were six of us; our job was to wash the big pots and pans that the food was cooked in and to get rid of leftovers. Approaching the hole from the glistening clean galley, the walls would grow continually darker, the air thicker and warmer, and the odor more pungent. The hole itself was a very large room; with pots and pans stacked six feet high along three of the four walls.

We would work at a feverish pitch, trying desperately to finish at a decent hour. I was nearly deafened by the sound of the metal pans flying down the metal trough. One person would scrub a little, and then pass, scrub then pass. In the morning, the butcher would come with his gigantic cauldron the size of a wheelbarrow and dump the blood on the floor so it would run down the drain in the middle of the floor.

The problem was, the blood didn’t drain.

The screen covering the drain would clog up, and the water we used to spray the pans with would begin to collect on the ground. By noon, we were standing in two inches of warm water, rotten food, and blood. Over the course of the day, scraps of food build up, and we would dump them in a large metal bin three feet long and a foot deep. When the bin was full of leftover scraps of food, it was time to feed Igor.

Igor was the industrial strength garbage disposal in the center of our shallow gutter that we used to wash the pans in. We would scoop the food out with our hands, spread it out on the counter and look for peas. Igor didn’t like peas because they would cause him to choke. Then we would push the food into Igor’s mouth. Igor would churn and spit, and swallow, and tiny bits of food would spray out of his mouth.

The food would get everywhere, in my hair, in my eyebrows, in my nose, and in my mouth. Tiny bits of bloody rotting food were getting everywhere, and I couldn’t get it off! Some of my co-workers developed rashes in their arms from the big black rubber gloves that they wore. These gloves were never washed, and they came up over the elbow. Little bits of Igor’s snacks would get inside the gloves and fester for months.

Sometimes I ask if anyone remembers the GI Hole, but it seems very few do.

The hole was shut down soon after I left, for sanitary reasons.

In 2007 I spent two months working as a network engineer for a small tech consulting company. The work there was amazing. They had built a long range, city-wide wireless network, and were providing broadband to rural areas. They were also providing a “one stop shop” for everything IT for small businesses in town. The people who built this business were energetic and bright, and I was lucky to have worked there. I could have stayed there longer, made a career out of it, or perhaps launched my own solo career from there. That’s not what happened, I left after two months. The reason: I was scared to death.

I was in the Navy for 11 years. Being in the Military for that long, it starts to feel like a nice, warm cocoon. In the Navy, I never had to worry about what we were going to eat that day, or where my family was going to live. Basic needs were taken care of. After my first four years were almost up, I was planning on getting out and going to college. My wife and I were newly married, and we had our first child, so we decided that now was probably not the best time. I reenlisted again, and luckily, went to England for four years. While in England, the Senior Chief who was in charge of my area moonlighted in the UK as a security consultant. He taught us everything he knew, and pointed us down the right track. He’s the reason I learned UNIX to begin with. After that tour was over, I was going to get out and start my own consulting business. However, my wife and I had two kids now, and we were overseas, and we weren’t sure how long our savings would last, etc, etc, etc… So, I reenlisted a third time, for three years, and went to New Mexico. In New Mexico, I did a lot of networking, and network cabling, and felt like my skills were good enough to get out and give it a go in the real world. But, my wife and I had three kids now, and I had been in for a long time, so we thought about staying in and making a career out of the Navy, and retiring after 20 years. Then the Navy told me that I was going back out to sea, which meant months, and months, and months away from the family that I had grown to love being with. I believe that kids need their father around, so despite the tough times that we knew might lay ahead, I left the Navy.

The original plan was to stay in New Mexico. We had a house, and had started to put some money away in savings. We had connections in the local area, and I had a clearance that may have landed a nice government job. Talking with my wife, it became increasingly clear that Iowa was calling. Her father was ill, the schools were better, and New Mexico was becoming increasingly violent. When the convenience store down the street was the focus of some gang related activity, we decided it was time to go. So, against all odds, we left everything that we knew, and went to Iowa, where we knew almost no one, had no connections, had no home, and no job… and we were expecting our fourth child.

We first lived with my wife’s family for a couple of months. That nearly drove me nuts. We finally found a place to rent, a tiny little shack with a decent yard in Coralville, between Iowa City and Cedar Rapids. On top of this, we had taken a loss selling our home in New Mexico, and due to some paperwork snafu, we had lost thousands in the move to Iowa. The Navy will move you, but we decided to move ourselves and try to make a little money through reimbursement. The government calls it a DITY move. That idea went horribly wrong. It was against this backdrop that I met the owner of the consulting company that I would work for briefly.

I went knocking on doors. Asking everyone I knew if they knew a business looking for the skills that I had. I boasted a combination of UNIX, Windows, networking, and security. I also had no idea how I was going to put food on the table. I met the owner of the business wearing a suit and tie. We went into the back and talked for a while, and he explained that he might have an opening in a few months for someone with my skills that he would hire as a network engineer. I was excited. The atmosphere of the place reminded me of my aspirations to own a small business of my own. We agreed to stay in touch, and he would let me know when the position opened up.

That didn’t help for paying the rent at the time though. I was still technically on leave from the Navy, and was getting the last couple of months worth of my paycheck, but that was rapidly running out, and I didn’t have time to wait for that position to open up. However, a position did open up at Yellowbook in Coralville, where I worked as a UNIX systems administrator for four months as a contractor. Towards the end of the four month contract, the owner of the consulting company and myself agreed that I would come and work for him after the contract expired.

That’s a lot of back story to lead up to the main idea. My family and I were still living in the shack in Coralville, my wife was getting close to delivering, and I realized that I was not going to be able to afford everything. The work there was very, very interesting, and also very stressful. I was coming into a network that had grown organically over time, and had some very unique constraints. Working with wireless adds an entirely new level of complexity to the system. The owner sat right behind me, and set about to training me. The first day, I was so overwhelmed by the amount that I didn’t know that I nearly cried when I went home. This was a small business, with all of the network complexity of an enterprise business. The owner had a goal of organizing the IP allocation of the network to make better sense and be easily managed, and also to eventually set up BGP between their two upstream connections. We had lots of routers, all over town and out in the countryside.

As time went on, the owner began to feel like I was making good progress and was becoming ready to take over without his needing to be involved as deeply as he was. I on the other hand, began to feel more and more sure that I was in over my head. I was not making enough money to pay all of my bills and buy groceries without dipping into credit at the end of the month, I was paying for COBRA because the small business did not have a health insurance plan, and on top of that, I felt like I was not earning the salary I was getting at work. So, while I may have been able to ask for a raise, I really didn’t feel like I deserved one. In the last couple of weeks of my wife’s pregnancy, right or wrong, I sent my resume off to a couple of places in Des Moines.

Another thing that I noticed about the consulting business, I learned after I started working there that all of the employees and the owner went to the same church. That’s not a bad thing, I go to church too, but since I didn’t go to the same church, I began to feel more and more like an outsider. I made mistakes, I tried to correct them, and I just couldn’t get my brain in gear. There was too much going on.

I was actually fairly certain that the owner regretted hiring me. So I was surprised at his shock when I gave him my two weeks notice. I joined the business to try to live out some fantasy of mine about working for a small business, and not in a gigantic enterprise. I wanted to make a difference. It turns out that it was just not the right time, and neither I nor my family were ready.

I’ve aged ten years in the three that I’ve been out of the Navy. My hair is turning gray and the lines in my face seem deeper, but mostly the age is in my eyes. The Navy can be a warm cocoon, but real life is hard and demanding. My family has been blessed by God. I have a steady job that’s poised to do well through the recession, and that I’m quite good at, we were able to buy a modest home that’s a perfect size for the family, and is in a perfect place, and I’m once again putting money away for a rainy day. There were a lot of ideas I had about life when I left the Navy that turned out to be fantasy, and it took a long time to get to a point where I understood that.

My phone went through the wash today.  Turns out it happened first thing this morning.  I really should be more careful about cleaning out my pockets before throwing something in the washing machine, but to be honest, I never liked that phone to begin with.  It had a faulty battery, and a faulty USB charger, so it would almost never fully charge and when it did, it would drain quickly.  The Bluetooth on it didn’t work either.  So, it wasn’t that great of a phone, and now its gone, and good riddance to it.  Now, I’m faced with the prospect of finding a replacement phone, but this comes with complications.

US Cellular has me for another 10 months.  My contract doesn’t end with them till November.  I can cancel my contract for $70, and I may wind up doing just that, but then I’ll also have to replace my wife’s phone as well.  US Cellular is a good phone company, but when I think about spending money on a phone, its hard to justify purchasing anything other than an iPhone, which takes US Cellular out of the equation.  I’m eligible for an “upgrade” in May, when I can get a new phone for a reduced cost from US Cellular, but if I want a phone between now and then, I’m paying full price.  That’s $159.95 for a Samsung SCH-u340, which boasts an internal antenna and a VGA camera.  When I look at that price, and think that I could get a refurbished iPhone for $9.95 <it>less</it>, it makes my wallet hurt.  

So, if I buy an iPhone, won’t I be chaining myself to massive monthly service charges from AT&T?  Well, maybe, maybe not.  We pay right around $100/mo. for our service now.  This is for 1000 minutes shared between our two phones.  Looking at our phone bills, I find that we do not come anywhere close to using 1000 minutes.  We would be perfectly suited to the At&T 450 minute family plan, which is right around $60/mo.  Couple this with the iPhone’s required $30/mo data plan, and we are at $90/mo.  Of course, I’d have to have two data plans… because there’s no way my wife would let me have an iPhone and not get her one as well, so that’d bring the grand total up to $120/mo.  So, $20 more per month than what we are paying now.  Since I’d have to cancel both of our accounts at US Cellular to get this to work, that would cost $140.  The iPhones, even refurbished, would cost $300.  So, for the first month, to get going, we are looking at $560.  We are not poor, but we are not rich either, and that amount of money needs to be well thought out, which brings me to the basement.

We’ve got an unfinished basement that I’m working on as time and money allows.  I’ve built a couple of walls, made lots of plans, taken lots of measurements, and bought some tools.  I’m a long, long way from being able to have a couple of my kids move their rooms down there.  The basement is also where I have my desk, which holds my monitor and Time Machine drive, and where I do most of my programming at.  Programming takes a lot of concentration, a lot of studying, and most of all… lots and lots of time.  Recently, I’ve been thinking that the unfinished basement would be much, much easier to concentrate in, if it were a little closer to being finished.  

The phone going in the wash today has actually been a conduit for me re-aligning my priorities.  I’m still very intent on finishing my application, but I think I would be more comfortable, and therefore be able to concentrate on development better, resulting in a better product, if I finish the basement first.  Since I’m going to have to adjust the budget for the new phone, and since I’m going to need money to finish the basement, I’m thinking that the new phone is going to have to wait.  Work gives me a cell phone every other week so I can be “on-call”.  Normally I simply forward the phone over to my personal phone so I don’t have to look like some kind of geek Batman carrying around a utility belt full of gadgets.  Now, since I don’t have a personal phone, I’ll just carry the one they give me.  I suppose I’ll also have to start carrying the pager again.  Yes, a pager, and party like it’s 1989.  

So, I’ll live without a cell phone for a while, and I’m also going to put development on hold for a while.  Not entirely, I’ll still have a little time in the morning, but I’ll probably put that time to use blogging either here or over at The Apple Blog.  The rest of my time, and the rest of my money, is going to go towards finishing the basement.  After that’s done, I’ll be in a much better position to move to an iPhone, and finish developing Go in peace and comfort.

Last summer I decided to dive into programming and give it everything I’ve got. For months, I would get up at 5 and pour through the Hillgass book, every page, every challenge. I’d revisit it at night, after the kids were in bed, and code till I couldn’t stay awake any more. I finished the book, and started coding my first real application. It was then that I found out how very little reading one book gave you. Hillegass says he gives you 80%, I’m thinking it’s more like 50%, tops. I reached out to the Cocoa Dev mailing list for help, and eventually even went to a CocoaHeads meeting with the local chapter. Meeting some “real” developers, I despaired. There was far, far too much that I didn’t know, I felt that it would take me an entire lifetime to learn what I needed to know. I gave up, wrote Goodbye Cocoa, and focused on something else.

Months passed by, and I began to rethink my initial approach to development. It became clear to me that I was trying to accomplish too much, and that I needed to start with something very small. At work, I wrote a small shell script that I use to ssh to the servers. The script was very small, and very, very handy. I called the script “go”. To use it, I just type go servername and I’m there. I decided turning that script into a gui cocoa app would be a great practice, a great learning exercise. So, I downloaded Xcode again, and fired it up.

This is the cocoa Go. There are sheets for default preferences and individual host details. The idea is to stay as close to the keyboard as possible, so all of the buttons are bound to the standard key combos. CMD-N creates a new host, CMD-, shows the preferences sheet, CMD-i shows the info sheet, Delete removes a host, and return launches Terminal with an ssh session to the currently selected host open. That’s Go in a nutshell. You can add hosts, and set up easy ssh to the hosts. The green light at the left of each host will (eventually) show if you can ping the host or not. I have the ping code down, and I have the code that shows the light down, I just need to tie them together in an if/then loop, and then set that loop inside of a timer to update every so often.

There is a lot of spit and polish left to add to Go. Adding a decent “About Go” panel, adding some nice looking help, and creating a decent status bar menu for it to live in for starters. I’d also love to add some of the really nice Core Animation stuff to the main Go window… just because its there. Getting Go to where it is now has been a lot of fun, and someday it may even be ready for public consumption. One of the first things I did with Go was to put it into an online Subversion repository, which I host here. Another thing I did very early on was to add the Sparkle framework for auto-updating, since I’ve got a friend in Maine who tests Go out for me on a fairly regular basis. After adding Sparkle to it, I followed these instructions to create an automated workflow to compile Go, create a zip file of it, digitally sign the zip archive, upload the archive to my server, and update the appcast xml file. An awesome amount of automation.

Adding the ability to ping was a challenge. A few of the forum posts that I saw said that there was no way to do it, and since you had to open up a raw socket to do it, you’d have to have root privileges. That was obviously not going to fly, but I couldn’t believe that there wasn’t already an existing cocoa class to do it. After much searching, I found SimplePing, buried in the Apple Developer site. I downloaded it, imported the class into Go, and gave it a shot. Calling SimplePing seemed to work! It would ping the host when I called it. Unfortunately, even if it tried to ping and could not reach the host, it still returned a return code of 0. That was not going to do. So, looking through the C code of SimplePing I found this:

if (error == 0) //was able to wait for reply successfully (whether we got a reply or not)
{
    if (gotResponse == 1)
    {
		{numberPacketsReceived = numberPacketsReceived + 1;}
	}
}

which I changed to this:

if (error == 0) //was able to wait for reply successfully (whether we got a reply or not)
{
    if (gotResponse == 1)
	{
		{numberPacketsReceived = numberPacketsReceived + 1;}
	} else {
		error = 1;
	}
}

and all was right with the world again.

Adding the ability to launch Terminal and ssh to the selected host was also an interesting challenge. Apple provides a framework to add the ability to manipulate other applications through AppleScript, called the ScriptingBridge.framework. To actually be able to call the Terminal, I needed Go to know what AppleScript Terminal would accept. So, I ran this command: sdef /Applications/Utilities/Terminal.app | sdp -fh --basename Terminal --bundleid com.apple.Terminal This created a header file “Terminal.h”, which I was able to import into Go. From there, I created a “ScriptController” class, where I have this piece of code:

+ (void)runTerminal:(id)sender withUserName:(NSString *)userName andHostName:(NSString *)hostName;
{
// Create our terminal object
TerminalApplication *terminal = [SBApplication applicationWithBundleIdentifier:@"com.apple.Terminal"];

// Get selected host name and IP address from NSTable
NSString *script = [NSString stringWithFormat:@"ssh %@@%@", userName, hostName]; 

// Run the script
[terminal doScript:script in:nil ];
[terminal activate];

This allows you to pass a user name and host name to this class, which will create a ssh script, and pass that script to Terminal via AppleScript.

Since it was fairly easy to add this ability, I’ve been playing with the idea of also adding VNC capability to Go. Leopard includes a Screen Sharing application, which is based on VNC, so I’m hoping to be able to script it in a similar way. I also looked into Microsoft’s Remote Desktop Client and CoRD, but neither allows AppleScript, so it would be very difficult to tie them into Go.

Go is a “document based” application. That means that you can create different “sets” of hosts, and save those sets as individual files. So, if you are on a team, you can share your set with the rest of your team.

The concept of Go is pretty simple, you have a set of places, and you want quick access to those places. I’m toying with the idea of adding a lot more capability to Go, like storing bookmarks, Finder folders, ftp, sftp, etc… It will be interesting to see how it goes. Right now, I’m just trying to get the basics down. Programming is perhaps the most challenging thing I’ve ever done, but I’m glad I didn’t give up for good.

I’ve been unlucky enough to be working with quite a few pieces of so called “enterprise” software, the worst of which I’ve been working with lately is called the Tivoli Workload Scheduler. TWS is, at its core, a glorified cron. It is a scheduler, you can create jobs, or scripts, and have them executed at given times. You are supposed to be able to cascade jobs, and create dependencies between jobs. This is all well and good, but there are some serious problems with this software.

The first problem is the price. List price for TWS is $33/value unit. IBM bases its pricing scheme on how many CPU cores are in the server that you install their software on, 100 value units per single core CPU, and 50 value units per core for dual or quad core CPUs. So, if you have four servers, and each server has four quad-core cpu’s in them, that comes out to around $26,400. I think we just went ahead and bought 1000 value units up front. That’s a fairly good sized amount, and that does not include the cost of the consultant its going to take to install, configure, and actually use the software.

Why tie the cost of the software to the number of cores in the system? TWS doesn’t use CPU resources to actually do any work, it passes off the work to other applications, TWS simply schedules them to be run. The price would almost be bearable, if the software actually worked. For $26,000 I’d think that it ought to make me coffee and pancakes in the morning. The reality is that after several months of enduring the software, it still doesn’t work properly.

The end user of the system has been trying to add event rules that fire off an email if a job doesn’t end correctly. Wow, that’s like, what… one line of shell script? But, since this is the TWS, we have to put in a call to IBM. IBM will call back, and ask for a ton of information. They’ll ask for directories that don’t exist, ask you to run commands that may or may not work, and generally take up a lot of time. Meanwhile, I’m starting to think that we are actually beta testing this software for IBM, and they just didn’t bother to tell us.

And then there’s the user interface. The UI, like many IBM applications, is quite obviously built on Java, evidenced by the length of time it takes to launch. Once it is launched, there are cascading left to right areas of a single window that allow you to perform separate tasks. At $work, I’ve got a 22” monitor, and this is the only application that I expand to full screen. It needs it. The application, called the “Job Scheduling Console” provides it’s own tabbed MDI interface. It is extremely confusing. Part of the confusion is that evidently the developers decided that there were too many options in the man application window, and chose to add a second interface to TWS through it’s integrated WebSphere application server. The second interface, also Java, is accessed through a web browser. Unfortunately, not just any web browser, it seems to only support Internet Explorer. I tried to access it first through Chrome, which did not work at all, and then through Firefox, which almost worked, but there were pieces of the application missing. IE worked well. The web interface is just as jumbled as the fat client on the desktop. Buttons seemingly randomly placed, some options hidden in drop down menus and others placed either above or below the data.

There is no clear, obvious method to accomplish anything with this user interface.

And that is not all my friends, oh no, that is not all. You must also have access to the command line on the server where TWS is installed. Even on the command line TWS is not a good citizen. There is no man page or online help shipped with the application, you have to load a ton of special environmental variables, and they provide scripts that launch a faux-shell that only accepts certain commands. One such command, conman, offers the ability to view the logs in real time (why, for the love of God, do you not log everything to syslog?), but only if you enter the command “con se” at the conman prompt. Also, you should enter “lev=4” to make sure you get all the logs. Proper logging in an application can be a lifesaver, and it could have been an area where TWS could redeem itself somewhat. That is not what has happened. The “con se” command only works sometimes. Other times it simply says that it submitted that command to be processed and returns you to your prompt. Great, thanks… so where’s my logs?

Having multiple interfaces to the application is fine, if you could accomplish everything needed in any one interface. However, that is also not the case. You need all three, and the end user must switch between the web interface and the fat client, and I as the administrator must switch between the web client, the fat client, and the command line to try to coax this monster into doing what it is supposed to do. Which is… schedule jobs. That’s really all this is supposed to do, schedule jobs to run. I don’t think it should be this hard.

Take these points into consideration in the light of the cost of the application. Now, let your jaw slowly close and realize that IBM can charge this much because it has found a market that no one else is tapping. TWS is only one example of horrible “enterprise” software, there’s a lot more of it out there. Personally, I see an opportunity here. An opportunity for well thought out, beautifully crafted software that works well, is easy to use, and gets the job done.