jb… a weblog by Jonathan Buys

Adamo - Apple Pushes the Industry Forward

March 18, 2009

I almost feel sorry for the other hardware manufacturers. No matter what they do, no matter what they come out with, they seem to be forever following in Apple’s footsteps. Such is the case with Adamo from Dell, a clear shot at the MacBook Air.

Adamo uses the same machined aluminum manufacturing process introduced by Apple with the Air, which has since spread very successfully to the rest of the Mac laptop line. Adamo markets itself as very thin, and very light, and has an artistic feel to their advertising that seems out of place with “cookie cutter” Dell. In fact, the marketing is almost too artistic, almost like they are trying too hard to shed their old image.

The specifications between the two lines are very similar.

AdamoMacBook Air
CPU1.2Ghz Core 2 Duo1.6Ghz Core 2 Duo
RAM2GB2GB
Display13.4”13.3”
GPUIntel GMX 4500NVIDIA GeForce 9400M
Storage128GB SSD128GB SSD
Weight4 Pounds3 Pounds
Price$1999$2299

As you can tell, this is not truly an apples to apples (pardon the pun) comparison. At this price point, the major difference between the Air and the Adamo is the $500 optional SSD. Configured with the 120GB SATA drive, the Air comes in at $1799. The Air is faster and lighter than the Adamo, and includes a dedicated NVIDIA graphics card.

A more accurate comparison may be with the MacBook, also configured with a 128GB SSD.

AdamoMacBook
CPU1.2Ghz Core 2 Duo2.0Ghz Core 2 Duo
RAM2GB2GB
Display13.4”13.3”
GPUIntel GMX 4500NVIDIA GeForce 9400M
Storage128GB SSD128GB SSD
Weight4 Pounds4.5 Pounds
Price$1999$1749

The MacBook case is larger and heavier. With the MacBook there is a half a pound difference in weight, but there is a big difference in the 2.0Ghz speed boost in the CPU. Fortunately for Dell, the Adamo is not about hardware internal hardware specs. It’s about trying to catch up with Apple in industrial design.

The screen looks gorgeous, I love the edge to edge glass design. The Adamo screen has a slightly different resolution from the standard 1280x800, coming in at 1366x768. Dell has done a great job with the Adamo. Unfortunately, its still not a MacBook killer, simply because its still not a Mac. Great industrial design is only one part of the puzzle of what makes a Mac a Mac. The other vital piece is OS X. With OS X and the Mac Apple has created a machine that drifts into the background, gets out of your way, and lets you do what you set out to do. Adamo ships with Windows Vista Home Premium 64bit. No matter how great the hardware is, if the software is not intimately tied to it the way only a company that creates both the hardware and the software can do, it’s still just another PC.

People may initially buy their first Mac because of the design, or the halo effect of the iPod. They buy their second Mac because of the experience.


Communications

March 5, 2009

Ask any mechanic, machinist, or carpenter what the single most important thing that contributes to their success is, and what they are bound to tell you is “having the right tool for the job”. Humans excel in creating physical tools to accomplish a certain task. From hammers to drive a nail to the Jaws of Life to pry open a car, the right tool will save time, money, and frustration. It’s interesting to note the contrast that people have such a hard time with conceptual tools. Software designed to accomplish a specific task, or several tasks, is often forced into a role that it may not fit into, making the experience kludgy, like walking through knee deep mud.

I’ve found this problem to be especially prevalent in business environments, where the drive to “collaborate” brings many varied and sundry applications into the mix. While hurrying to the next great collaboration tool they forget to ask the absolute most important question: What do we need this software to do?

To communicate effectively in a business environment, it is imperative to use the right tool for the job. To determine what the right tool for the job is, you first have to ask yourself exactly what the job is. Do you need ask a quick, immediate question from a co-worker? Is there a more detailed project question that you need to ask, and maybe get the opinions of a few others too? Do you have something that you need to let a large group of people know, maybe even the entire company? Each of these tasks is best suited to a different tool. Unfortunately, I’ve most often seen each of these tasks shoe-horned into email.

Email is a personal communications medium, best suited for projects or questions that you do not need immediate responses to. There have been many times when I’ve gone through my inbox and found something that didn’t grab my attention when it was needed, and by the time I looked at it was past due. Email is asynchronous, ask a question, and wait for a response whenever the receiving party has time.

If you do need immediate response, the best tool would be instant messaging. IM pops up and demands the receiving person’s attention. When requesting something via IM, the person on the other end has to make a decision either to ignore you or to answer your question. Long explanations are not a good fit for IM, but short, two or or three sentence conversations are perfect or it.

When considering sending something out to the entire company, keep in mind that email is a personal communications medium. Company wide email blasts are impersonal, and for the most part require no action on the part of the receiver other than to eventually read it. A better tool for this job is an internal company blog, accompanied by an RSS feed. RSS is built into all major browsers now, and could be built into the base operating system build for PCs. Every single time I get something from our company green team or an announcement from the CEO, I can’t help but think that a blog would be the best place for such formal, impersonal communications. A blog could be archived for searching, new announcements broadcast through RSS, and best of all accessible when the intended receiver has the time and attention to best appreciate the content. To me, company wide email is the same thing as spam, and for the most part, is treated as such.

One other form of internal communications which is far, far too often maligned beyond recognition is shared documentation. Technical documentation especially suffers from document syndrome, which is having a separate (often) Word file for each piece of documentation, spread out through several different directories on Windows shares, or worse on the local hard drive of whoever wrote it. Such documentation should be converted to a wiki as soon as possible. If you are writing a book, I hear Word is a fairly good tool to use. If you are writing a business letter, again, great tool. If you are documenting the configuration of a server, a word processor should not be launched. Word (or OpenOffice) documents have a tendency to drift, and are difficult to access unless you are on the internal network. Trying to access a windows share from my Mac at home through the VPN is something that I’ve never even considered trying. A wiki, is perfectly suited for internal documentation. They are a single central place to organize all documents in a way that makes sense, is accessible from a web browser, easy to keep up to date, and most importantly, searchable. Need to know how to set up Postfix? Search the internal wiki. Need to know why this script creates a certain file? Search the internal wiki. Everything should be instantly searchable. Perhaps search is not the most important feature of a wiki, perhaps the most important is the ability to link to other topics according to context. I can get lost in Wikipedia at times, jumping from one link to another as I explore a topic. The same thing can happen to internal documentation. This script creates this document for this project, which is linked to an explanation of the project, which contains links to other scripts and further explanation. Creating the documentation can seem time consuming, until you are there at 2AM trying to figure out why a script stopped working. Then the hour spent writing the explanation at 2PM doesn’t seem so bad.

One of the first things I did when starting my job was to set up both a personal, internal blog and a shared wiki for documentation. I used Wordpress for the blog, and MediaWiki for the wiki. Both are excellent tools, and very well suited for their purpose. If I were a manager, I’d encourage my team to spend 15 minutes or so at the end of the day posting what they did for the day in their personal blog. Could you imagine the gold mine you’d have at the end of a year or so? Or the resources for justifying raises. Solid documented experience with products and procedures, what works and what doesn’t. The employee’s brain laid out.

Internal moderated forums is something that I haven’t tried yet, but I can see benefits to this as well. They’ve been used on the Internet for years, and I can imagine great possibilities there, especially for problem resolution. How about a forum dedicated to the standard OS build of PCs? Or one for discussing corporate policies?

Blogs, wikis, forums, and IM are tools who’s tasks are far too often wedged into email. If an entire organization begins to leverage using the right tool for the job, the benefits would soon become apparent. Then you’d wonder why you ever did it the other way at all.


Shell Script Style

February 25, 2009

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.


Systems Administrator

February 24, 2009

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 Work in Progress

February 19, 2009

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.


JeOS

February 6, 2009

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.


Rota

February 1, 2009

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.


The GI Hole

January 31, 2009

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.


Consulting in Coralville

January 27, 2009

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.


First Things First

January 26, 2009

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.