Open Cage Software

I really like FogBugz.  It just works.  And the fine folks at Fog Creek make it so easy to get an account (for free!) if you are a one or two person startup.

I work on a few projects outside of my day job (which also uses FogBugz) and one of the things I’d like to add to the products for my day job and side projects is the ability to send Windows minidump files to FogBugz automatically.  One way to do that is through email.  Unfortunately that did not work so well for us.  Using the C++ bugzscout wrapper does not allow file attachments.  The good news is that one can use the FogBugz XML API to access a FogBugz account – including file attachments.  The not so good new is that while the API has some neat wrappers for .NET, there is nothing like that for unmanaged C++ code.

The solution?  A codeplex open source project.  Then I found the StackOverflow open source ads! I threw up a really bad logo and entered the “contest”.  The FogCreek and SO staff pitched in to help me out and came up with not one, but two great logos to use.

Come join us, or just wait for the functionality to be released.

And thanks again Michael, Aviral and Yi for the help.

We use hudson CI (Continuous Integration) server at Open Cage.  We really like it.  It has great support, is cross-platform, works with a lot of other development tools we use, and is pretty easy to learn, configure and maintain.

I recently found yet one more reason to love it.  I can trigger builds remotely via instant messaging.  This is not really necessary for normal projects since commits to our version control system trigger builds.  I wanted the IM trigger functionality so that I (or any other developer) could ‘promote’ a development/candidate build to ‘stable’ or public status.

All our builds are FTPed to a server, however the directory they are in is not public.  We also have a public-facing directory for builds we have tested and are confident in.  Prior to using hudson for this process I had to manually log in to the server and copy the file(s).  This usually had to take place after working hours since I have a day-job, thus the copy was not immediate.  Also, my partner has no interest in figuring out how to log in and copy the files on the ftp server, but he interacts with customers and does a lot of the testing that determines if/when builds are approved for release.  It makes sense that he should be able to trigger the process.

So, after some poking around and not being able to get an email trigger to work, I tried the Jabber plugin for hudson.  It was pretty easy to configure and after a few simple tests I found that it fit the bill perfectly.

So now when my partner or I need to publish a build to the world, instead of logging in to an ftp site, finding the right file, copying files, waiting for them to transfer and then logging out, all I have to do is go to my google chat window, start an IM with the build machine account I created, and type:

!build Promote 1234

and it is done.  In the example above, ‘Promote’ is the name of the parameterized build/project that does the copy/promotion and ’1234′ is the svn revision number of the build I want to publish.

So, once again, to the folks at hudson and to the plugin developers: Thank you for a wonderful tool.

After about a year of redirecting Open Cage Software’s website we’re back in action.  Our main product, SyringePumpPro, was sold to another company who have done a great job making improvements and supporting the product better than we could.

While we were quite happy with the product, partners and customers, we felt that we were too busy on other projects to support the software and make the upgrades that the customers and hardware manufacturer deserved.

I remember most of the first days I had at many of my companies. Some were glorious. Others were like the first moments of a prison sentence. There is a saying about first impressions. I forget what it is, but hopefully by the end of this article it will come to me. Impressions are so important that apparently some French artists invented a whole new kind of art in honor of them. But let’s get back to my story…

When my new hires were scheduled to start I did all that I could to make sure they felt welcomed. I had limited powers of course, but small gestures like finding an unstained chair for them to use and a computer that had more than 128MB of RAM were appreciated.

My views were not shared by all my peers. Apparently some took the terms “working manager” and “hands-on-manager” to heart. They liked to spend lots of time looking at code and they dreaded talking to their reports except to “call them into their office” to tell them what to do and how to do it. Of course, I never worked as a manager. Work is for suckers. I avoided work. So I had to make sure the people who reported to me made up for my laziness. And boy, did they ever!

Chris was a new hire. He showed up on time. I discovered him wandering around the reception area on his first day. I welcomed him and showed him to his new home/cube and left him there then went to inform his manager that his fresh young hire right out of college had arrived. Peter (we’ll call him Peter for now) hardly looked up from his buggy code and mumbled something about being too busy – lots of (bad) code to write that day apparently. I thought he was kidding. Nope, he wasn’t. Apparently this golden boy was too important to waste time greeting, introducing and getting his new report started. Of course, I was not that special or important, so I had plenty of time to waste on a new employee. I introduced Chris around to everyone (including his very busy manager), got him a company t-shirt, and showed him where the bathroom was – all very, very important things. (At least to me and my bladder and I think to Chris’s)

I never could figure out why we didn’t do more to knock the socks off new hires on their first day. I am sure that during their first personal calls of the day (either while at work or when they got home) they were asked how the new job was or how they liked the new company. Here’s where we stop the film and pause it and the narrator steps in front to pose a dilemma and present a choice to the viewers. What do you want that new hire to say?

“Man, this place is fantastic – they had free Snapple and bagels for me and dancing girls popped out of the cake and there was a valet in the bathroom to dry my hands for me…” (well, maybe no cake or girls)

or

“My boss was too busy to greet me and introduce me to the team, but that’s ok, he scheduled a time for us to meet next week when he has time. I found the bathroom myself and I should have a phone at my desk by the end of the week, but I don’t really need it yet because they haven’t found me a permanent office. The temporary computer they gave me to use doesn’t have a development environment on it, but at least it has the internets so I can check monster.com again for other jobs.”

Chances are that this new hire knows other competent people and those people might be looking for good companies to work for. One scenario above makes it easy to get candidates lined up at your interview room – the other one predisposes new hires to line up at the HR office for exit interviews or just never show up to work again. Some people are too busy fighting fires and fixing all the bad code they wrote to consider the consequences.

You never get a second chance at a first impression. (I hate clichés like that, but it happens to agree with my sentiments, so there it is.)

No, I didn’t work for Nike. I did work for many people who seemed not to understand logic and were not impressed with doing things the right way. After getting lucky on my first real task at a software company, I was told we absolutely had to have a this great new feature put into the code. The required assembly language part was all done. My job was to make the call to the assembly language and put it into the product. Somewhere. Anywhere. Now.

This “must have feature” was the greatly hyped Intel® Pentium® Processor serial number. After getting the secret orders I ran back to my office to plan my whiz-bang implementation. But. There. Was. One. Minor. Problem. There was no context for this information. It was meaningless. It helped no one. So I made an ass of myself and raised the question, “Why are we doing this? It isn’t used anywhere in the product.” (I didn’t even get to the part where I asked what we should do for multi-processor machines)

I needn’t have worried. A careful, well-thought-out argument came back my way: “Just do it.” Apparently having the Intel® logo on our box in the stores would make the product boxes fly off the shelves even faster. At least that is what the marketing and product geniuses claimed. So I “just did it.” It was as useful as an ice cube in Antarctica. And I had a hand in it. What a proud day that was for me.

But wait. It gets even better. The objections started slowly and imperceptibly, but as momentum gained the apparently super-duper-useless feature became a liability. People were afraid of the serial number. It could identify them. Products that touted being able to take advantage of the serial number were seen as Big Brotherly, and not in a Philadelphia loving kind of way.

I don’t recall what became of the code I put into the product, but hopefully it was removed or quietly optimized out of the product by a compiler that was smarter than my managers and knew the code wasn’t getting called.

Just Do It. But first, make sure it is useful.