Draconis Software Blog

I’ve just put the finishing touches on a new “logo” for RSP. I decided to put it together after noticing that small, rectangular logos are the rage for a lot of tech companies (something that’s easy to recognize, easy to add to a blog, etc). Be sure to let me know what you think.

Thought I’d post a quick teaser about the new version of RSP (version 2.2, if you’re keeping track). First, there’s going to be a big focus on hardware management. We’ve been especially interested in tying performance data to the underlying system resources of a computer system. This should prove especially useful for capacity planning and figuring out what needs to be upgraded (i.e. a web server with 2 gigs of RAM that’s heavily used might better benefit with another 2 gigs of RAM, rather than upgrading a backend database that’s still chugging along on an older CPU).

Second, we’ve done a number of cosmetic improvements to the interface. We’re big fans of the new Web 2.0 visualization technologies (such as tying AJAX with slick UI effects), and we’ve spent a lot of time trying to make the interface as easy to understand and use as possible.

We’re looking to release the new version of RSP early next week, so be sure to keep your eyes peeled. More details be out then (and in the meantime, you can let me know what you think about the logo).

If you haven’t come across it yet, check out Squidoo. It’s a new, very Web 2.0, site that allows users to create their own “lens” on a subject of their choice. A lens can be anything you like and is intended to be a guide to other users (for instance, I created one called My Top 5 Business Books). Creating a lens is very easy, and there’s already a strong community building of “lensmasters”.

There’s a hook though: what sets Squidoo apart from other community-created sites (like Wikipedia or MySpace) is the ability to generate affiliate sales. Squidoo is aimed at creating income: either for the lensmaster or a charity (and always for Squidoo). A lensmaster adds links to purchase products (such as books, as I did, from Amazon) and upon referring a customer who makes a purchase, the online merchant has agreed to pay an affiliate fee to Squidoo. Upon receipt, Squidoo then allocates a part of that fee to the lensmaster to do with as s/he wants (for instance, claim it for themselves or donate it to charity).

I love Squidoo for two reasons: it embraces the read/write web using slick Web 2.0 visual technologies, and has a workable business model. In fact, following the cash flow through Squidoo is simple: viewers can turn to customers when visiting a lens, and sales are sent back to Squidoo and its lensmasters. The company wins because it inherently creates a community that wants to drive as much traffic to Squidoo as possible (thus further growing its community – and making critical mass relatively easy to achieve).

As a final note, I’d like to point out the uncluttered interface of Squidoo. There are targeted text ads on the pages, but nothing that distracts the eye from the content. And lensmasters are the ones with control over the content section of the pages – no annoying “inline” ads that many media organizations love to place in the middle of an article.

So, if you haven’t seen Squidoo yet, check it out. And create a lens for yourself – it’s surprisingly addictive.

In the past few years there’s been a trend to expedite and simpify the process of creating a web application. The latest step in this trend (or perhaps the culmination of it) is Ruby on Rails. Rails a web application framework built upon the Model-view-controller architecture, and it uses Ruby, an easy to use object-oriented programming language along the lines of Perl.

I’ve been interested in Ruby on Rails for a while now, and what first got me excited about it is a video that uses Ruby on Rails to create a functional blog in 15 minutes:

http://media.rubyonrails.org/video/rails_take2_with_sound.mov

There are some other Ruby on Rails “screencasts” available on the site as well.

I think the ability to create a working application so quickly is great, and really takes a number of MVC concepts to their logical conclusions. You could even use Ruby on Rails to create working mockups of web apps and then port them to other frameworks.

However I also think it Ruby on Rails shouldn’t be used for every scenario. It’s great for apps that have simple model objects and need quick interface code to modify those objects, but as you stray outside this environment a more robust framework like Struts or Spring may be preferable.

There’s an article up on SecurityFocus called “Basic journey of a packet”. It gets into some of the details of TCP/IP and routing, and should prove a useful introduction to those not fully on what’s happening behind the scenes. From the article:

Once an Internet application is invoked, a whole series of events takes place. This article will be a simple introduction to how a packet is created and the various devices it will travel through on the way to its destination. Having an understanding of just what happens between point A and point Z can be quite helpful in furthering your understanding of networking.

I think the article gives a good sense of how incredibly complex networking really is. At each layer from the physical to application there’s an incredible amount of work going on, just to simply view a webpage. Networking is a good example of how powerful layers of abstraction can be. Each stage builds upon the last, while still creating an simpler interface for the next. It creates a sort of stack, with each stage being simpler and easier to use. At the bottom you have the physical layer, which would require a good deal of knowledge of physics and electronics to begin to comprehend. Yet once you get to the top you’re dealing with something as simple as typing “www.google.com” into your browser and hitting go. Much of the technology we take for granted today works because of these kinds of abstractions.

The article also mentions the differences between networking and programming. I think for both network administrators and programmers it’s very useful to have at least a passing understanding of what’s happening at each stage, each layer of abstraction. Whether you’re fixing a network problem or debugging a web application, you never know if you might be working with an application error or a broken ethernet link.

While still focusing on developing and selling RSP, Draconis has also been offering consulting services for some time now. It might still be more common for consulting companies to branch into the software market, but it’s becoming increasingly common for things to happen the other way around, as it did for us.

A lot of the time doing contract work on the side can be very easy for startups. Many may already have relationships with companies who need work, which simplifies what can be the most difficult part of consulting: finding jobs. Even without an network to work from, the software startup already has personnel, a set of marketable skills, and an LLC or similar corporate entity.

Let’s look at some of the benefits consulting provides:

1. Consulting brings in money when you need it most.

Startups can always use more money. This can be particularly true during initial development, when it’s likely there’s no money coming in at all. Having a steady stream of income can literally save new companies from going under. Consulting can often be pretty lucrative on its own, and while you can’t necessarily count on a job whenever you need one, it can be a lot more consistent than those early sales. Even when there is a temporary lull in work, there’s always plenty to be done in the startup itself.

2. Consulting gives you new customers.

While you certainly don’t want to start right in with a sales pitch as soon as you get a new job, you might be surprised how often clients end up becoming customers. A big reason companies avoid buying from a startups is the lack of a strong reputation. Once you’ve proven your trust by doing good work on a job, that reputation is already there. Forming a good relationship is a great way towards getting that next client.

3. Consulting helps you learn what your customers needs are.

During the trials and tribulations of forming a company, it can be easy to loose focus on what your target market wants. A brand new feature is no good if it’s not going to do something to help your customer. Consulting will give you a chance to see firsthand what a potential customer is going through, and will probably give you tons of ideas of how your software tool can help them.

4. Consulting teaches you new skills to help your business.

You can almost always learn something from seeing another company in action. This could be anything from how they pay their sales staff, to how they run their finances, to which kind of furniture they have in their lobby. Keep in mind that you might see just as many things not to do — but this can be just as helpful. There’s no better way to learn about the world of business than by seeing what makes real world companies work (or not work).

5. Consulting gives you a break from the routine of building a business.

Let’s face it; starting a business can be tedious. Don’t get me wrong, there’s often tons of excitement, but when you’re in the middle of writing a business plan, or working on that 10th white paper or piece of marketing material, you might feel like you need a breather. Rather than loosing focus on your company, consulting gives you a chance to do something different while still helping your company. You get to work on a variety of projects, meet new people, and of course the extra money doesn’t hurt either.

I love the Fourth of July. One of my favorite things is BBQ, and nothing beats a hot grill on a warm Fourth. If I couldn’t be in IT, I think I’d be a professional BBQ griller (maybe for a restaurant). One of the cookbooks kicking around here, called Weber’s Big Book of Grilling, has a fantastic article in it, and a great lesson for all you entrepreneurs and salespeople out there. Here’s an excerpt from “A Firehouse Turkey Tale” (p. 274):

Firefighters typically worked long shifts for 10 straight days, then had several days off. In this downtime, many picked up odd jobs to supplement their income. So I would drive up to a firehouse, remove a shiny, fire-engine red Weber charcoal kettle grill from my car, wheel it up to the firehouse, and go find whoever was in charge (if they hadn’t already appeared to chase me off the property). After finding the usually suspicious watch commander, I would volunteer to cook a turkey for the crew and leave the grill behind for their use. I was generally regarded as insane, but the prospect of a tasty meal usually earned me the green light. After all, if there were any unintended pyrotechnics, they could handle it.

As I lit the charcoal, I’d tell the firefighters stories about folks who didn’t follow lighting instructions and some of the crazy things that could happen. I’d invariable hear about someone in their district who had used gasoline or another forbidden fire starter and unintentionally torched a lawn or deck.

While the turkey was cooking, someone would ask why Weber had sent me out to cook a turkey and give away a grill. I’d explain that we needed demonstrators who could set up a Weber charcoal grill for Indirect cooking, safely light a fire, prepare a turkey for roasting, and then talk about the grill while the turkey was cooking. Since they had just witnessed a guy show up from nowhere and do all of this, they know it was pretty much a no-brainer. When I explained that they could earn a daily fee doing it, three or four firefighters usually applied for the job right on the spot.

The only thing that ever sidelined my recruiting efforts was a fire alarm. One such time I was in Des Moines, Iowa, chatting up a firefighter who was a natural for the job. He could tell a story, he was the firehouse cook, and he needed some culinary help with his job. His name was Stewart Leathers, but his nickname was Shoe-Leather, obviously a jab at his firehouse steaks, which he cooked in a cast-iron skillet on the stove. I was just at the point of recruiting Stu when the bells went off and the men – Stu included – scrambled into their gear, jumped onto fire trucks, and roared off.

About two hours later, they returned, grinning and … mischievous. Evidently they had just answered a call at a burning horse barn. Fortunately, no one was injured, but one of the firefighters had picked up a horribly scorched saddle as a trophy. Now, after washing off the smoke, they assembled near my grill to present it to Shoe-Leather. There was a raucous speech about the saddle being more edible than Stu’s firehouse cuisine and everyone laughed. Bit it lit a fire under poor Stu.

The turkey was ready just as the “ceremony” ended. Everyone raved about how juicy and flavorful it was, and quickly reduced the bird to bones. No one asked more questions about how to grill a turkey than Stu. Before my firehouse visit ended, Stu and two other firefighters had signed up to demonstrate our grills.

One of the best parts about being an entrepreneur is the opportunity to be creative in your job. “Cooking” up new ideas to reach folks who can solve problems using your products is the whole point of going into business, and one of the things I’m always on the watch for. Have a great Fourth!

There’s an interesting article in the NY Times about Google’s infrastructure strategies.  As it’s been the talk of many folks for a while now, Google has spent a lot of time and brainpower creating their own infrastructure more or less from scratch: they build their own computers, they have their own file system, etc.  From the article:

In many ways, it still has the head of an graduate-school project grafted onto the body of an multinational corporation. The central tenet of its strategy is that its growing cadre of world-class computer scientists can design a network of machines that can store and process more information more efficiently than anyone else.

Mr. Reynolds estimated that Google’s computing costs are half those of other large Internet companies and a tenth those of traditional corporate technology users.

Interesting, but before you start thinking of building your own servers and file systems, remember that Google can benefit greatly from economies of scale: the extra time spent building those thousands of servers translates into greater savings; for most organizations, you might save a few hundred or thousand bucks going the DIY route, but you’ll be spending even more money in researching/building the five or so systems yourself to not make it worthwhile.

Anyway, a good read if nothing else for the WOW factor.