One question many small business owners struggle with is how much to spend on software. Should you get existing software off the shelf? Open Source or proprietary? Or should you invest in custom development? But how much does that cost and is it worth it?

Many of the smaller companies I’ve worked with over the last year have similar problems. At some point they decided they needed a website and just went with whatever their cousin recommended. This wasn’t a bad choice, because the site has brought them new clients and kept them in touch with existing clients.

In short: the site has made them money.

Programmer’s and lean startup aficionados would say that their minimum viable product has validated their assumptions.

The other side of the coin, is that a site like this usually requires a lot of manual maintenance. So now the business is at a point where they want to invest in the improvement and the expansion of the website.

But what to do?

Lets study a fictional example: Huey Bobbie’s company “Server Certified Studios” has a website containing a few modules:

• A content management system that was created by his nephew as a homework assignment. It works, but for every update to the site, Huey needs to figure out what file to change and if he makes even the smallest error, the entire site goes offline.
• An open source application that manages his mailing list.

Calculating expenses

Huey’s expenses for the site are:

• A shared hosting account and a domain name. For about $150/year you can get a decent package deal.
• Initial programming and template for the site. Those are sunk costs, so they won’t play into any calculation here.
• Every month Huey needs to add a few products to the site, add a bunch of news items and update one or more page. Writing all of those things takes about 1 hour weekly. But because he has to search through the files and be very careful with the syntax, this takes him another 1 hour weekly. Lets assume Huey, as a business owner, values his time at about $100/hour (which is conservative, he could be doing other stuff to make more money).

Everything combined, the website costs Huey on a yearly basis:

$150 + 50 (working weeks) * $200 = $10150 / year

I think this is a fairly realistic number of the cost of a typical small business website that is maintained regularly.

Profit

For the sake of argument, lets say Huey has calculated that the site is generating a revenue that is exactly double of what it cost him: $20300 / year.

Or the site is making a profit of $10150 / year, or a 50% profit margin.

Just to make this more concrete: $20300 means 203 customers buy $100 worth of product over a year. Or about 17 customers find Server Certified Studios through his website. Not at all impossible.

Room for Improvement

That’s not a bad extra profit to add to the bottom line. But lets see how we can do better.

For instance, lets believe in magic and assume there is no additional work required to get a news item that is written on the website. So Huey only need to write 1 hour / week and whatever he has written magically appears on the site.

In that case, the website cost is:

$150 + 50 * $100 = $5150/year

The profit is $15150 or a margin of 75%. That’s huge improvement!

But lets try something more realistic. We automate the website a little and improve it’s administrative interface. Now Huey only needs an hour each month to update the site.

The cost: $150 + 50 * $100 + 12 * $100 = $6350 / year

That’s $13950 profit or a margin of 69%. A nice increase.

Getting There: Investing

If Huey wants to recoup this improvement in a year. The investment may not be over $3800 (this is the additional profit over a year: $13950 – $10150)

Given the size of this website, $3800 can buy a lot. A few example investment opportunities are:

• Find a WordPress theme expert and let them convert the existing site layout to a WordPress theme: Site maintenance will be drastically easier and finding cheap developers afterwards easier (the WordPress dev community is probably one of the most saturated)
• Go on Elance and find a PHP developer that can create a script that automatically converts the input text to the XML format of the site: Not as future proof, but could be even cheaper if you find a good Asian developer.
• Hire a Virtual Assistant to put everything online at about 1/10 the cost of you: Easy to set up, but requires continuous payment.

If Huey would ask me what to do, I would most certainly recommend the WordPress solution. It’s a one time investment that will create a site that is ready for further expansion. And the numbers support it.

Huey will find a WordPress theme company that can create this for $1000. Which will repay itself in 4 months. Furthermore, the WordPress powered site will probably have better SEO than whatever was there previously. Thus delivering even more clients to Server Certified Studios.

Conclusion

If you are a small business owner and feel your website is sucking up way to much of your energy, it’s time to evaluate your options. Write down the numbers and see what kind of time and money you are spending and how much it is making you.

Even small investments can tremendously improve your profit margin and reduce your frustration.

(image credit)

2011 has been a transformative year for Streamhead. Due to some major work and planning behind the scenes, I haven’t been able to post as much as I would have liked. But all this hard work is about to pay off and you, my dear reader, will enjoy the fruits of it. In 2012, I plan to double down on in-depth articles, tutorials and case studies. All practical hands-on information. Read on for a review of 2011 and my goals for 2012.

Before I start making plans, it’s good to look back at the goals I had a year ago. In 2011, I finally managed to focus on just a few projects and not be so random, which is why I don’t score too good on the goals I set for myself:

1. HTML5, CSS3, etc.: I wanted to learn new enabling technologies for the web. And, in a way, I did, but not like I imagined. I learned PHP and got into the WordPress plugin business (a post on that is forthcoming). I also used Node.js to launch my latest personal project and I’m glad I did.
2. Mobile: Sadly, I wasn’t able to create anything worth showing on the mobile front. Apart from some very small experiments, I got nowhere.
3. Online Marketing: For the last few months I’ve had an Adwords campaign running. It’s been slow learning, but I am getting better at finding keywords and convincing Google my ads are relevant. And I managed to get a site to position 7 in Google for my target keywords in about a month. Nothing major, but I’m pretty happy with this evolution. I haven’t written about any of this, because I feel I got very little to add to the discussion at the moment. That might change, though.
4. Game Modding: A big zero on this one. I launched two small experiments early in the year. There was little interest and I wasn’t convinced myself, so I didn’t promote anything. I did manage to pull of a half-assed ticket to ride clone, which convinced me I shouldn’t invest further in ActionScript. Adobe killing of Flash has only strengthened that opinion.

What you haven’t seen is my search for a sustainable business model for Streamhead and my other projects. Making money with a blog is, for all intents and purposes, impossible. Unless you want to churn out a few long-form articles a day, like Tuts+ (A great resource BTW), you can’t live of of advertising or ebook sales. Furthermore, I realized a full-time writing gig is not my thing. I want to be in the trenches, developing, not writing about developing.

Plans for 2012

Most developers tend to stay away from sites like elance. I did discover that there is good work out there, with good clients that want to pay for quality. And the further my reputation improves, the easier it is to find that work. It’s very easy to phase in and out small projects as time permits.

There is a lot of work out there in the widest possible range of technologies, but it is most profitable to stay focused on just a few. Which is a major pain point for me, so in 2012 I intend to focus on a few core technologies.

Currently, I’m trying to limit my programming languages to Java, JavaScript and PHP. I might try out something related (Groovy, Clojure, Coffeescript), but I’m going to try to not stray too far from the path.

Java

Although there are now other cheap options, I still like the AppEngine platform for Java web application deployment. Libraries, such as Vaadin, are what keep the platform young. However, I do feel that there’s going to be a turning point soon when one of the other JVM languages really goes mainstream. It’s probably not going to be Clojure, maybe Scala?

I also still have that Android in Action book I want to go through.

PHP

PHP is a great source of small project work. It’s an interesting language I will continue to use. However, I am going to narrow it down to WordPress development and possibly a few other applications.

JavaScript

Like it or not, JavaScript is the language of the future. It’s everywhere and there’s no reason why it would go away. And now it has also invaded the server side. I was pleasantly surprised with Node.JS. It’s a very robust programming module that is going to stay in my tool-belt. On the client side, I do hope to get some game programming in and maybe some cross-platform mobile programming.

Non-technical

Of course, 2012 isn’t going to be just programming. I will continue with my Internet marketing efforts and if I feel it’s worth sharing, you’ll be the first to know.

Conclusion

I value input. Do you have a great topic you want me to write about? A question you can’t find the answer to? Get in touch with me and I’ll make it happen in 2012.

(photo credit)

Over the last month or two, I’ve been very busy with a few projects. And it was about time to present some. I have many more ideas on how to extend ExpensesSpreadsheet, but I thought it wise to first gauge the reaction of people.

It uses the following technology:

• Node.js, the JavaScript event machine that is all the rage now.
• RailwayJS, a Rails-like web framework.
• connect-auth for Facebook integration (and a lot more)
• MongoDB for data storage. Mostly because it was so easy to get started with compared to traditional related databases. But in hindsight, I think it’s an ok choice. I really don’t safe any relations anyway.
• EJS JavaScript templates. Although in hindsight, I think I like Jade better.
• Heroku, cloud hosting done right.

This was my first experiment with Node.js and Heroku and it was extremely enlightening. JavaScript is not my favorite programming language, but it certainly has a way of reducing boiler plate code (stuff I’m really starting to hate in Java). Combined with deployment to Heroku, the time between idea and deployed application is so short, it will make any developer smile.

If your day-to-day life involves lots of Java, you owe it to yourself to try out this stack. It’s not your average hacked together client side JavaScript. It takes a little time to wrap your head around the Node model, but it’s all worth it.

Since you probably only want to do this in a production environment, I suggest you place this in that configure block.

Before you add any middleware add the following route:

1
2
3
4
5
6
7

app.get('*', function(req, res, next) {
  if (req.headers.host.slice(0, 3) != 'www') {
    res.redirect('http://www.' + req.headers.host + req.url, 301);
  } else {
    next();
  }
});

That’s really all there is to it. Since most frameworks have similar routing options, you should be able to adapt this to other frameworks, such as Geddy.

BTW I’m planning to launch a Node.JS app in November as part of Hacker News’ Launch an App Month.

Since I launched the PayPal servlet, I’ve had many inquiries and I know of at least 2 production deployments of the code. It was about time that I started handling the project a little more professionally.

The first step in this process was completed last weekend: the project is now a Maven project and the Eclipse specific configuration has been removed. I have decided to make this part of my Powered by Reindeer initiative. Although it can be used completely independent and will remain so, I believe that there are going to be some nice synergies in the future that I’ll want to exploit.

My next step will be cleaning up the actual code. I’m not sure when I’ll get around to it, but this will involve changing the package names a little to be more in line with the Powered by Reindeer structure. If you think there’s a good reason to keep the old names, please let me know. Also let me know if you’d like to get a personal e-mail when the changes will take place.

See the GitHub page for all details.

If you’ve ever created anything using jMonkeyEngine’s SimpleApplication and you use something other than the American standard QWERTY keyboard, you might have had the same frustration as me: Why isn’t there quick way to switch the keyboard layout? The SimpleApplication base class is supposed to make your life easier, yet there you are, completely stuck with that unnatural keyboard layout. Read on for a quick copy-and-paste solution.

The keyboard mapping that SimpleApplication uses for its camera movement is defined in the FlyByCamera. The mapping is hardcoded and the mapping names don’t even use constant strings. Clearly, no one ever thought about international users. jMonkeyEngine does so many things right, yet on this one, it really misses the ball.

Luckily, with a little searching, it’s fairly easy to redefine the correct mappings. It’s something I now do in all my experiments.

I just copy and paste the following at the start of every simpleInitApp:

1
2
3
4
5
6
7
8
9
10

inputManager.deleteMapping("FLYCAM_Forward");
inputManager.deleteMapping("FLYCAM_Lower");
inputManager.deleteMapping("FLYCAM_StrafeLeft");
inputManager.deleteMapping("FLYCAM_Rise");
inputManager.addMapping("FLYCAM_Forward", new KeyTrigger(KeyInput.KEY_Z));
inputManager.addMapping("FLYCAM_Lower", new KeyTrigger(KeyInput.KEY_W));
inputManager.addMapping("FLYCAM_StrafeLeft", new KeyTrigger(KeyInput.KEY_Q));
inputManager.addMapping("FLYCAM_Rise", new KeyTrigger(KeyInput.KEY_A));
inputManager.addListener(flyCam, new String[] {"FLYCAM_Forward", "FLYCAM_Lower", "FLYCAM_StrafeLeft", "FLYCAM_Rise"});
flyCam.setMoveSpeed(10f);

(Note that I’ve also sped up the movement to more easily move around)

Whenever you’re proposing a web site or application to a client, showing him what it’s going to look like can work wonders. It avoids confusion and can fix doubts. But how do you show off a website when you haven’t written one line of code and HTML? Wireframe tools and website mocks are the answer. This article compares a few of the many tools available.

In this article I compare:

• Balsamiq. The de-facto standard for creating mocks.
• WireframeSkechter. A new kid on the block, based on Eclipse. The author generously donated a free license for this review.
• Mockingbird. A completely web-based tool.

All three of the tools offer a similar feature set and are all very capable. So if you don’t feel like reading on, just pick one, and I’m sure you’ll be happy.

Of course, if you look closely, there are many small differences that might suite you and your workflow better.

Mockingbird‘s visual style is cleaner and different than most other tools. And the way you can arrange components by snapping them to guidelines and other components is equaled by no other tool. It’s easy to quickly create a well-aligned and well-spaced layout.

Balsamiq  is the most widely known mocking tool. It is popular for a reason. With a solid standard set of components and many ways to extend its functionality through custom components and third party tools, you’ll certainly find what you need. I tested the desktop version, but since this is a Flex application, the online version is exactly the same.

WireframeSketcher has a similar sketchy look as Balsamiq. Which is great way to communicate to your client that these are just temporary mockups. WireframeSketcher’s main selling point is the wiki-like syntax that allows you to deeply customize the standard components, such as the table. My main gripe is the small up and down arrows to navigate through the component library. I know this is a very minor annoyance, but the idea of mockups is to quickly sketch a layout and this held me back somewhat.

None of the three tools have an intuitive way of adding arrows. I like to attach yellow sticky notes to certain areas to explain different parts and have arrows point out the details. None of the tools made this easy.

The following spreadsheet gives an overview of some of the features of the different tools. You’ll notice that they are very close, so in the end it’s probably going to come down to personal preference.

PHP in Action is all about using PHP. It is not about learning PHP. In the book, you’ll study practical ways of applying software patterns to real life situations. It is not a book for beginning PHP programmers, but it is a treasure trove for those looking for good ways to solve common problems in web application development.

PHP

You may or may not like to hear this, but PHP is the language of the web. Where JavaScript is the de facto choice for client side programming, PHP is ubiquitous on the servers of small businesses everywhere, but it is also used for many large web applications. Many other programming languages only come into play once a website is established and management decides something more “enterprisy” is needed.

The trouble with PHP is, that it makes it incredibly easy to shoot yourself in the foot. Global variables are frowned upon pretty much anywhere, PHP has a special keyword for them. Many popular PHP applications actually rely on them.

However, in the hands of a skilled PHP developer, the language is an incredible tool for rapid development. Dynamic programming and duck typing allow a freedom that any Java developer can only dream of. Add to this the availability of very cheap hosting and you’ve got a bootstrapper’s dream.

PHP in Action

This is where “PHP in Action” comes into the picture. It shows you how to apply modern software development and design techniques in PHP. In 4 parts you’ll learn:

• How you can create object oriented programs in PHP
• How to properly and automatically test your application
• How to create secure, extendible and bug-free web interfaces
• And finally, how to get everything into and out of the database

You’ll notice that there is no chapter on how to program PHP. You either need to know the PHP basics, or you’re going to need to fill the gaps by lots of Google. Nothing I would recommend to a starting programmer.

Lead by Example

Most of the chapters use small pieces of code from larger projects. Those examples work very well, because it clearly shows you why the presented patterns are useful and what pain points they solve. Starting from a badly designed program, the author gradually introduces the concepts and immediately applies them so you can see how the architecture of the application improves.

Depending on your knowledge of PHP and software patterns in general, you will need more or less time to truly get the advantage. In most cases you will want to experiment with them.

So take your time and work on some small hobby application during the read.

Frameworks and Libraries

Quite frequently, PHP libraries are used in the code examples. Most of them are only mentioned incidental, except for SimpleTest which is used throughout the chapters on testing. In most chapters, enough information is given to get started with the libraries immediately. However the database chapters were a bit too short in this regard. A few libraries are used (eg. Creole) and code fragments are shown, but the libraries’ homepages and documentation are essential to really get started using them.

In general, the later chapters seemed to have been kept shorter and less in depth than the earlier ones. I’m not sure if this was intended, but it didn’t bother me, except for the chapter 14 on composite views and templating. In my opinion, this was the only chapter where the examples were too incomplete and the overview was missing. It was very unclear how the different parts fit together to form a templated application.

But that is my only criticism with the book.

Conclusion

If you know a little PHP or you have a good grip of another language and are feeling adventurous, PHP in Action is the book for you. Clear and concise examples show how to apply modern software development techniques and patterns.

Therefore I have created a small flowchart that will try to guide you in the maze.

Feel free to submit additions, corrections, comments. I’ll keep updating the flowchart.

It’s no secret, I am a fan of Google’s App Engine. Once you get used to its peculiarities, it has a number of major advantageous. Since I started incorporating some of the continuous integration/lean startup ideas in my own project I’ve run into the shared datastore issue and the need for a properly isolated staging environment has become apparent.

Here’s how I did it.

Setting up the Staging Application

It’s possible to use namespaces to create an isolated datastore, however I didn’t want to create additional code for testing. So I took another approach, which I believe is a lot easier and less error-prone:

1. In the appengine control panel, create a second application. You have 10 free ones so that shouldn’t be a problem. I added the “-staging” suffix to the name of the application under test, so I won’t mistake one for the other.
2. If you want to start from a copy of the existing datastore, you can export the entire datastore using the Python development kit. Even if you’re using the Java development kit, it’s worth setting this up. It allows you to make backups of your datastore, which might come in handy when something is really messed up.
3. Next, import the database into your staging application using the same tool.
4. And finally, deploy your application to the staging application. If you’re using Eclipse, just change the application id, if not, you can find the property in the appengine-web.xml.

A small note on using production data in your tests: Be very careful about it. You may want to anonymize some of the data and remove anything that could be remotely confidential.

That should be it. There really wasn’t much to it, but you now should have a fully functioning copy of your production application. Surf around a little to make sure everything is working swiftly.

When you’re happy, lets automate it.

Automating Deployments

I was about to throw out Maven, but I’ve now created a setup that I’m pretty happy with. So Maven is here to stay for now. As are the Maven Eclipse plugin and the GAE plugin for Maven.

It’s thanks to the maven-gae-plugin that I could automate the staging and production deployments. Which has given me a very reproducible build and deployment set up.

To seamlessly create a build for both the staging and production server, I’m using Maven profiles and its ability to filter resources while copying them.

In the appengine-web.xml I added a gae.application variable:

1
2
3
4

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
        <application>${gae.application}</application>
...

Next up I enabled filtering of the appengine-web.xml (all of the next few bits go into the pom.xml):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <configuration>
        <webResources>
            <resource>
                <directory>src/main/webapp</directory>
                <filtering>true</filtering>
                <includes>
                    <include>**/appengine-web.xml</include>
                </includes>
            </resource>
        </webResources>
    </configuration>
</plugin>

In the properties section, I added the default application, which is the staging one. This gives me the assurance that I’ll always be deploying to the staging environment, unless I really want to go to production:

1
2
3

<properties>
    <gae.application>myapp-staging</gae.application>
</properties>

And for the production deployment I created a profile:

1
2
3
4
5
6
7
8

<profiles>
    <profile>
            <id>production</id>
            <properties>
                    <gae.application>myapp</gae.application>
            </properties>
    </profile>
</profiles>

With this configuration, I can easily run the local development server:

> mvn gae:run

Deploy to the staging server:

> mvn gae:deploy

And when I’m happy, deploy it to the production server:

> mvn gae:deploy -Pproduction

In addition to the name of the application, you can also configure other properties that differ between a test setup and a production one. For instance, I use the PayPal development servers locally and on the staging server, but the real PayPal site in production.

Conclusion

With a pretty simple Maven configuration, it’s possible to create a very reproducible build and deployment environment. Add a continuous integration server and you’re on your way to the perfect lean setup.