I’ll be working on getting a screen cast of the demo up in the next week or so. Too many other things distracting me at this moment.

I’m going to be doing a presentation in the coming days for the local linux user group (CIALUG) on Puppet from Puppet Labs.

Free pizza and some swag will be thrown around.

The event is 100% free and should hopefully get you acquainted with all the cool stuff you can automate. Signup for your free ticket!

But how do you track something like getting more sleep?

Here is where Mercury App comes in. I’ve been using this product for over a year now and have mainly been tracking things like my weight and job satisfaction. Adding to it Sleep time, not only how I feel about the sleep I got but actually tracking the number of hours should give me a good overall graph at the end of the year of how well I did in getting that 7+ average that I’m looking for.

So if you have a goal that you are working on the for the new year, start tracking your progress. You’ll be amazed at what you can accomplish when you put your mind to it. Because the only one stopping you is YOU!

Puppetlabs has stepped up to offer sponsorship of the event so besides my insightful talk, there will be pizza and t-shirts that will be handed out while supplies last or whatever game we come up with to give them away. I have a whole box of them so hopefully many of you are sporting the latest in puppet wear before the night is through.

So put it in your calendar now to join me for Pizza and Puppet on January 18th at 7PM in the LightEdge corporate headquarters.

Another issue that we ran into after we set the urls was that when we went to an org URL of say vcloud.us.com/org/orgVDC, we got a Org Not Found message. A huge thanks to Dave Hill for this FAQ that solved the issue for us. Here’s the part in particular that saved us some time.

vCloud Director: Org URL Not Found
Q. In vCD, I created an org and the org URL comes up as https://cloudURL/org/tenantOrg. However, attempting to access this Org URL results in an HTTP ERROR: 404 NOT_FOUND error. How do I resolve this problem?
A. Append “/cloud” to the vCD public URL in the VCD public URL setting under the System/Administration/System Settings/Public Addresses.

Typically, Safari renders these meetings the best so it is my go to browser for meetings. Unfortunately, I would get the prompt for trusting the java app and a window would load with nothing happening. Same with Chrome. Firefox actually rendered the window with a Java loading icon spinning for all its worth, but never actually loading the meeting.

So, bail and go to my VDI. Now, I use my VDI for 2 things, powerCLI and VMware access. Its pretty bare bones. I found out that it didn’t even have java to join the web meeting that way. Live Meeting actually told me my version of Internet Explorer was not compatible even after installing java. Seriously Microsoft? I ended up installing the live meeting client and was into the meeting 15 minutes after the start. Yeah for productivity.

So surely I wasn’t the first one to trek down this path of Live Meeting plus OS X right? Correct! This post outlines the issue fully AND the solution. Here it is if you want to avoid a click:

All I did was go to Java Preferences (under Utilities) and on the Advanced Tab, ensure that the last option on the list “Verify mixed security code (sandbox vs. trusted)” is set to “Enable – run with protections, no warnings”. This is probably what was causing Java to hang before opening the session.

So there it is. I figured I ran into it, others surely would as well.

Now, we have several clusters here in our company and often times we move a host from one cluster to the next. Several of the clusters were originally setup to work within the various active directory domains. This has been rather annoying when moving a host from one domain to another and having to do all the DNS update foo. Its much easier to have one private domain to rule them all so most of our hosts have been updated and moved to this new private domain that can be resolved by all domains.

This is where the fun actually comes in. The cluster that I’m moving a new host into is a hold out in the old naming space. Adding a new node shouldn’t be a big deal as the new name resolves in the virtual center.

Now, here comes the rub.

When upgrading a particular host, for some reason I could not enable the HA configuration. It just wouldn’t work. No particular reason other than it just failed to find the primary node. Now, you would think that this was failing on the new host that was added to the cluster. Nope, that added just fine, no worries there what so ever. The node that was failing was actually the 3rd host in the group to be upgraded.

Apparently what was happening actually had nothing to do with the primary node. It happened to deal with the new node with the name in the private domain. The issue, somewhere deep in the bowels of vSphere, it attempts to look up by the “short name” meaning esx123456 instead of esx123456.domain.com. While I was able to resolve esx123456.private.domain.com, I was unable to resolve esx123456 as the rest of the cluster was still looking for esx123456.domain.com which didn’t exist.

So my advice to you is, when changing the domains of hosts in a cluster, make sure you have all entries in both the new and old domains so you can avoid this short name lookup failure.

But seeing as I’ve had a chance to move up in companies and produce multiple products, I have a different appreciation for product lifespan and code rot.

Product lifespan? Code Rot? What the hell is this loon talking about?

Software is much like owning a house, you have to maintain it. Issues (bugs) are found, new technology comes out that will make your product more stable and possibly cheaper to run. New advances in design and layout require a fresh coat of paint from time to time.

Eventually the software is a bit too much of a mess. Sometimes you have to gut a room or two. Sometimes, you just have to tear the whole damn thing down.

How do you know when its time?

For me, there isn’t one question that clearly lets you know when its time. For example: When was the last time you gave the product any love? When was the last time you added a feature or fixed a bug? When did you give it some marketing dollars? Has it been so long that you can no longer remember? Have you been distracted by other products? When was the last time you had a signup?

Its OK to admit that you have been ignoring a product. But now you have to ask yourself, how much is this costing me a month? How often is support getting calls on it? What are my hosting costs for keeping this around? Am I still making money? Would I have a company if this was my only product?

It quickly becomes clear on what you should do. We have a product at our company that hasn’t done as well as I would have liked. To be honest, it has a lot of issues. Most of which are out of our control. Due to licensing, its priced too high and competes with “free” alternatives even if they are less secure. It has maybe a couple hundred users on it and if it was our only product, we would have shut the doors a while ago. Its time for it to go.

Dealing with the breakup

So the hard stuff now has to happen. You have to either tell your customers to go away, or find an alternative that maybe you’re reselling, maybe not. There is a good chance that they’re not going to like what you are going to tell them. Break it to them easy, give them PLENTY of time to migrate away from your company if they choose. Bend over backwards to any request that they have for getting their data. After all, its THIER data! Helping users move their one service will hopefully keep those customers on the other services that they have with you.

In the end, this is best for the company. Even if you lose a customer or two, its best in the end. Even with the lost revenue, there is hopefully a huge reduction in expenses that can now be pushed to your money making products. And yes, even with repeating this to yourself, it will still suck. Good luck my friends.

If you are a typical employee, there is a good chance that your job revolves not around day to day mundane tasks. There may be some of that, but there is a good chance that it revolves around completing projects. Yes, project oriented work is challenging and rewarding, but often done very poorly.

Not that your work is bad, its the management of the project that we suck at. And more to the point, its the time estimation that we’re the worst at doing.
This is one of the hardest thing a person has to do in their day to day jobs. If you are a contractor, you may have gotten pretty good at it.

Engineers, we suck at it.

I’ve been out of college now for 12 years. I’ve worked on a bunch of projects of all sizes. Even in college we did some time estimation practices and I can say with 100% certainty…we suck at time estimation.

If at first you don’t succeed, flying helicopters isn’t for you

So why do we keep going down the path of guessing what we think a project will take? Surely our ego is no longer getting in the way. We are very well aware that no matter what I tell you, it will probably take longer than that. Even when I’m bullshitting to myself that I think a project will take 1 week, I tell my manager it will take 2 and it ends up taking 3 or 4. Wow…I suck at this.

I don’t really have a good answer of why we keep doing this. The best that I can tell is, we need something on paper. Whether it has anything to do with reality, it helps the business move forward so they know what can get done in a reasonable amount of time, even if we miss it but a few weeks.

But what happens when those few weeks turn into a few months?

Solutions to the problem!

I don’t have all the answers, not by a long shot. But based on my experience, my work environment and knowing what my skills are, I can typically get a pretty good estimation of what my gut is tell me that a project will take. I think take that number and multiply by 3.

Yes, you heard that correctly, multiply by 3.

I have no idea why this works, but for some reason, it always seems to work out in my favor. Now I have a bit more luxury of if something derails what I thought would happen, I have some time to make up ground. If things go smoothly and I finish in the week that I thought it would take, now I look like a stellar employee. And we all want to look good at the office right?

Calling bullshit

I know that many of you are thinking, this is bullshit. It has no basis in reality and your manager knows you are making up numbers so why wouldn’t they just divide by 3 and bust your nuts. Well, they could. But I would say 75% of the time, my multiplication of 3 is actually what is the REAL time to take to get something done.

If someone wanted to bust me on it, I’d simply call out the bullshit of their business plan / sales forecast. After all, no one has a crystal ball.

So that’s my little tip to you on time estimation. Its far from perfect but has served me well over the years. Best of luck to you.

In a previous life, way back when we were first developing our appliances, we shipped on Sun v100 servers. They were cheap boxes that packed quite a bit of power under the hood. Sun had on their site that servers shipped within 3-5 business days.

Well, most of the time.

If a reseller, channel partner or well, anyone remotely associated with Sun wanted a server before you ordering through the web wanted it, well, they got it and you didn’t. We eventually because a partner and were able to order servers at a much faster rate. But for a while, we discovered that business days actually equaled weeks! WEEKS!!!!!

Move on to the present day. Now my job no longer entails ordering mass quantities of servers to be made into appliances. Now I’m dealing with project planning, estimates and general work load balancing. One thing that I have noticed that is not unique to my current employer but to a lot of employers is how fast they move. There are just too many small to medium businesses that are stuck in slow. Its time to put that foot on the gas pedal and start moving again folks.

The speed of business is killing us!

One of the big slow downs that I’m seeing right now is a lot of people are afriad to make a decision. Let’s have another meeting before deciding on where we want to go. Let’s look at the numbers again. Did we make a mistake? Are we predicting the future correctly with this?

How about, let’s try something and see how it works. Risky? Sure. But limit the risk and you never know, it just might be the home run you were looking for. If not, you didn’t lose that much but at least you tried something that hopefully moved your company forward rather than sitting in meeting rot.

Its time to move forward, lets GO!