Bogeymin

I'm proud to announce the commencement of a new project called "Bogeymin" -- a command suite tool for managing Web servers and related services such as DNS and email.

Features include:

• Linux-based.
• Total control from the command line and complex automation for consistent maintenance and administration.
• Utilizes existing security technologies to safely permit access to level 1 support, level 2 technicians, and full administrators.
• Unique website organization system.

The project is scheduled for completion in October. Visit the official site to for the latest info and sign up to be notified when it's released.

The Shoe is On the Other Foot

I am a pretty good guesser and empathizer. I also have a good imagination. This helps me build Web sites and applications that are useful, thoughtful, and helpful to clients. Most of the time, anyway. It also helps me understand the client's perspective and win more jobs.

But after deciding to outsource the Objective-C portion of our iPhone application, I am now "the client". And the experience has been helpful in understanding even more of the client's perspective.

Timing and Silence

My chief complaint -- if it can be called that -- is getting the job done on time (which we have not) and hearing from the developer on progress (which was good at first but lately has been sporadic). Most of us (developers) are well aware that communication can be an issue, but this experience has really driven home to me the necessity of prompt communication.

• Say something, anything. Never let a message go unanswered, eve if it's just to say "message received". We often feel pressured to have news or progress before responding, but this takes time. Instead, let the customer know you're still there.
• Be up-front about delays. Let the customer know as soon as possible if there's going to be a delay.
• Be open about the current schedule for incoming change requests.

Silence leads to frustration -- don't frustrate your clients.

As a result, I have a new goal for communication with my own clients.

My First Experience with "Offshore" Outsourcing

I have scads of experience both building and managing software projects. I've also worked with a lot of people; full-time employees as well as contractors. My first experience with outsourcing a project went to India where I could leverage the exchange rates to purchase more hours for my dollars. I put together a fairly extensive project plan from which everyone could work.

After having review the source code and tested the application, I know the developer is competent. However, there are several things I will do differently next time.

1. My application needed a Web service. I was providing this service, but I wanted to let the developer have some leeway here -- the developer would know best as to what would be needed, right? This was bad. I should have defined the Web service before hand -- method names, parameter names, design by contract, etc.

2. Design. I am no designer. The developer did the design work. The graphic design didn't turn out bad but it wasn't what I wanted. The problem is, I didn't come up with a design concept until the work was well underway. I couldn't criticize a design that was otherwise okay because I was too unimaginative to come up with something on my own in the first place.

3. Layout, labels, and process flow were all left to the developer. Again, this didn't turn out that bad, but it could have been much better in terms of UI. I should have had my own screenshots in advance with flow-charts indicating how the user experience should be implemented.

There were of course times when the language barrier was a problem, but it was never a significant problem, especially via email. Planning -- even more than I had done -- would have saved a lot of time and produced a better product.

It's a Dirty Hack, But Someone Has to Do It

I had finished a fairly complicated application -- to the client's specification -- that featured a complex system for selecting advertisers for various types of announcements. Although the money was paid, the project lay dormant for many months until the client started selling the ad spots.

Unfortunately, the person selling the spots had been left in the dark on how the system was built and sold the ads in a way that was completely contrary to the current tools -- control panel, automation, and front-end were now incompatible.

I looked at every way possible to make it work within the capabilities of the application but there was no reconciling the way the product was sold and the way the product was built.

To make matters worse, the deadline for the "new" way of doing things was two weeks and I had already had a full plate. I sensed stupid hours in my future, but promised the client I would come up with something.

The more I got in to the code, the more I realized that it was worse than I anticipated. I tried several approaches, but everything was backward in terms of implementation and data that was previously needed in one place was now needed somewhere else -- some where the scope was completely wrong.

I really only had a weekend to work out a solution and the "real" way of doing it would probably take a week's worth of work.

Sometimes you just have to hack something in place. In this case, I bypassed all of the dynamic stuff and just hacked in the raw data for the specific advertiser. Yes, lots of really complicated and fascinating code was essentially discarded for a plain text band-aide that will have to be fixed some day. It wasn't pretty but it was simpler, and more importantly it got the job done quicker.

Sometimes the greatest difficulty in this situation is getting over the fact that you are hacking otherwise excellent code into pieces.

This brings me to yet another truth in programming:

It's a Dirty Hack, But Someone Has to Do It.

You are the best candidate to hack on your own code and when the rubber hits the road, the reality is you just have to do it.

But what can you do to minimize the damage?

1. Leave comments for yourself (or the next guy) wherever you need to change the code.
2. Use @hack or some similar marker so you can easily find the changes and comments.
3. Go back and fix it on a rainy day.

Lemonade Web Site Hosting

I've been managing servers off and on since 1998 and have been working with Web-related servers (DNS, FTP, HTTP, POP, SMTP) since about 2001. And starting around 2004 for, I took over the management of a small hosting company with about 1500 to 2000 websites.

It has always been frustrating to me when customers balk at a decent price for hosting. Everyone tends to gravitate toward the cheapest of any product, but having used various hosting services as well as operated my own, I understand better than most that real hosting costs real money.

What is "real" hosting? And why does it cost money?

• Hosting occurs on servers that cost money.
• Servers are located in a building that costs money.
• Connecting the servers to the Internet costs money.
• The skilled employee(s) needed to maintain this infrastructure costs money.

In the old days of the Web, that is, 1995, I remember "business class" hosting was sold for $50 to $150 per month. But some companies today are selling hosting for as little $2.95 a month. And what about free hosting? How do they sell it so cheaply or even give it away?

• Hosting may be a secondary business.
• Advertising is inserted into the hosted sites.
• They offer little or no support to hosting customers.

Real hosting companies needs to make a profit. With the exception of a very few, these low-bid hosting companies are like childhood lemonade stands -- here today, gone tomorrow. They are in the business to make a quick profit and it doesn't matter if they aren't around tomorrow -- to them at least. It is easy to find horror stories of cheap hosting gone bad.

Real website hosting comes from people offering friendly and responsive support on a stable and well maintained infrastructure. This is NOT what you pay for when you purchase hosting for $2.95 a month.

Oh, and if you're looking for "real" hosting, check out Connecting Point. And if you're a photographer, I would recommend Marathon Press. They aren't paying me to say good things about them, but I work for and with both of these companies from time to time and you'll find them to be real indeed.

Our First iPhone Application -- Been There -- is Almost Done

Been There, which is something like a geographic discussion board allowing users to share their favorite locations with comments and rankings, is almost done.

The whole process has been a ... learning process. I was managing the project's outsourcing team as well as my own labor on the Web service that drives the app. There are many things I would have done differently, which will probably constitute a separate post, but all in all, I've been happy with the progress.

Now we'll see if anyone will buy the app!

The Log File is Your Friend

So, I was working with the flexigrid plugin for jquery, which is pretty cool but not very well documented, and I encountered this strange problem where the grid was failing to display the output.

Now, with most of the grid tools you

1. Create only the most basic HTML on your page.
2. Write some javascript to make the AJAX call, also included on your page.
3. Create a PHP (or whatever) script to generate the output which is typically JSON or XML.

In this case, I choose to generate XML for use by the flexigrid plugin. But my grid wasn't working. It would just sit there and spin, saying "processing".

• The jquery javascript was working with no errors (confirmed this in the browser's debugger).
• The PHP script was generating the correct XML (confirmed by manually entering the script address in the browser).

But it wasn't working when the PHP script was called from the javascript on the page.

The solution? When the PHP script was being called from the javascript on the page, the flexigrid plugin was sending sortname and sortorder values that were "undefined" in javascript. So the query against the database was something like "SELECT * FROM sometable ORDER BY undefined". This of course was generating SQL errors and the PHP script was failing to output the XML. But only when called from the page. It was fine when called manually (and flexigrid was bypassed). A simple check for undefined values in the PHP script and all is well.

This brings me to one of the great canons of programming for the Web (and perhaps other types of programming). The Log File is Your Friend. I discovered this problem by tailing the PHP error log. Otherwise, the failure is very puzzling because everything appears to be working, just not together. When using AJAX or creating Web services, things going on unseen may only be exposed by consulting the log(s).