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)

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)

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.

If you have a WordPress.org blog and want to try a new plugin or a new look, you have two options: You could just install it on your running production site and risk crashing it. Or you could first experiment with it on a different test installation. Ideally this test system would resemble the real site as closely as possible. I think you can guess which one is the right way and which is the one most people go for. This article show how to copy your existing blog to a local computer and run it there, so you don’t have to fear trying out something new.

This tutorial requires some technical knowledge. How to set up a LAMP/WAMP stack, FTP files and use phpmyadmin. Nothing very complicated, but if you don’t feel comfortable doing it, I’d gladly help you out and create a fully working VirtualBox image of your blog for $50 (I’ll also support you in setting up VirtualBox).

(why buy from Streamhead?)

Step 0. Prerequisites

This tutorial won’t work for WordPress.com hosted blogs, only for self-hosted WordPress.org blogs. You will need to have an FTP account that can access your WordPress installation files. Every host offers this, so check your hosting details and keep the FTP url, login and password ready.

You will also need to export your database. The easiest way is via phpMyAdmin. I haven’t seen a host that doesn’t offer this super-useful application. A link to it is usually located in the control panel of your hosting account.

Step 1. Operating environment

Depending on your preferences, there are a wide range of operating systems and environments you can work with.

• If you’re used to Windows and you like to keep it simple. You can install everything on Windows.
• If you want to create something portable, I suggest running some kind of virtualization software. I’m a fan of VirtualBox.

Basically, pretty much any operating system will do, but I like to create a virtual Ubuntu system in VirtualBox. It’s a great way to keep the server software that you’ll install in step 2 away from your “normal” operating environment. Shut down the virtual machine and you don’t need to worry about system processes that keep using memory and CPU that you forgot to shut down.

Step 2. LAMP

While there are other ways to run WordPress, the easiest way is to install the Apache web server, MySQL database and PHP language. It’s the same environment that your blog host uses, so this is the best way to reproduce identical conditions.

• If you’re on Windows, you can go for one of the many WAMP distributions.
• For Ubuntu there is an in depth guide to setting up a server. Keep in mind that you don’t need to go through the whole guide. You only need to install Apache2, MySQL and PHP5. I also suggest to add phpMyAdmin while you’re installing. It isn’t strictly necessary but will make copying the database easier.
• If you’re on Mac, there’s MAMP.

Step 3. Copy WWW directory

Now it’s time to do the actual work. First you need to copy all the blog files locally:

• Figure out where the local Apache server stores its files. On Ubuntu this will be in /var/www. Many WAMP distributions offer shortcuts to this directory.
• Next open an FTP client. I like FileZilla, but feel free to pick the one you like.
• Connect to your blog’s FTP site and navigate to the WWW directory. Usually it’s called “www”, sometimes “public_html” or something similar. There should be 3 directories in there that start with wp (wp-admin, wp-content and wp-includes) plus a bunch of .php files that also start with wp and then a number of miscellaneous files.
• Download this entire directory into your local www directory. This might take some time, especially if you have been blogging for a while, have many plugins/themes and/or have uploaded a lot of files.

You can already perform steps 4 to 7 while the download continues.

Step 4. The Database Connection

In the WWW directory, open the file “wp-config.php”. You will see a number of lines that start with “define”. There’s one that defines the name of your database, it’s “DB_NAME”. Write down the name after that. By default it’s going to be “wrdp”, but this can vary. Also write down the values for DB_USER and DB_PASSWORD. You may have entered those at some point but might have forgotten them. Or they could be autogenerated when WordPress was installed.

Step 5. Export the database

Fire up phpMyAdmin on your remote host.

• In the right part of the screen, you’ll see a number of tabs.
• One of those is “Export”. Click that one.
• You’ll see a screen divided into two sections: “Export” and “Options”.
• In the “Export” section select the database name that you wrote down in step 4.
• You don’t need to change anything in the “Options” section.
• If you have a large database, select “gzipped” compression at the bottom of the screen. This can reduced the file size by a lot (mine was only 30% of the original, uncompressed file)
• If you like, you can pick a nice name for the download.
• Click “go” and remember where you save the file.

Step 6. Import the Database

Now we are going to import this file into your local database.

• Fire up phpMyAdmin locally. Again, your AMP distributions will come with a shortcut to it. On Ubuntu you’ll find it at http://localhost/phpmyadmin/ by default.
• This time pick the “Import” tab. It’s right next to the “Export” one.
• Browse and select the file you just saved.
• Press “go”.

Step 7. Set Up the Database User

Now we need to configure the WordPress database user. Remember you wrote down the name and password in step 4.

• In the left section of phpMyAdmin, where it shows the databases, you should now see your imported WordPress database.
• Click on it and it will show the tables in that database.
• Now click on the “Privileges” tab.
• Enter the username and password.
• As host enter * or localhost.
• Check all privileges (this will give global privileges, you could also give the user only access to the WordPress database. Since this is a local test system I’m not too worried about strict security, but keep this in mind)
• Click “go” to create the user.

Step 8. First Test

Surf to http://localhost

You should see the blog appear, but you might notice it downloads all images from your original blog site. All links will also still point to the Internet, not to the local site. You won’t be able to log into the administration.

Step 9. Converting to Localhost

You didn’t leave phpMyAdmin, did you?

• In the left column, click on your blog database (if it isn’t already showing)
• Browse the “wp_options” table (it’s the first tiny actions icon)
• Find the two options with option_name “siteurl” and “home”. There are many ways to do this, phpMyAdmin has a search function or you could change the SQL query if you know what you’re doing.
• Change both options (with the little pen icon) so that their “option_value” reads “http://localhost”

Step 10. You’re Done

That’s it. You now have a fully functioning local copy of your WordPress.org blog.

Common Issues

When importing the database you receive an error that the file is too large.

In many cases, it might be beneficial to first clean up your database. Also make sure you enable gzip compression. If none of those help, you will need to change the default PHP file upload limit.

Categories or article links don’t work

Depending on your permalink structure, you need to have the “mod_rewrite” Apache module enabled. I’m not sure why, but this isn’t always on by default. There are numerous articles about it if you Google. For instance here’s a howto for Ubuntu.

Can’t add/configure plugins and themes and other permission issues.

Again, depending on how your installation is configured, the Apache/PHP process may not have permissions to change or add files in your WWW directory. If you don’t care about security, I suggest a “chmod -R 777 *” in your WWW directory. If you do care, find the group that the Apache process runs in and give that group write access to the entire WWW directory.

Something else

I haven’t run into this issue, but I can imagine there are plugins that won’t like to be moved to a different server. If you see strange issues, try to disable your plugins and enable them one by one. If you find the culprit, maybe you need to change its options in the wp_options database table.

Conclusion

Having a full copy of your blog on your own computer is a great resource to experiment with new themes or plugins. Although it might look daunting, once you’ve done this procedure, you won’t know why you didn’t try this earlier.

If you’re not very technical, or don’t feel like going through all the steps, I offer a $50 service for creating a VirtualBox Ubuntu image. Feel free to contact me for more information, or you can go straight to PayPal (VirtualBox setup is included).

(why buy from Streamhead?)

I have created a standalone example project that demonstrates the explanation in this article. The example shows how to upload an image to the App Engine Blobstore and associate it with the current user (which is stored in the Datastore). You can use it with Maven, or load the provided Eclipse project files:

Vaadin / Google AppEngine integration example project

Once the file is extracted, change into the folder and simply run:

> mvn gae:run

If Maven is correctly installed this will launch the Google AppEngine development server and when launched, you can point your browser to http://localhost:8888/. Enter a username which is persisted in the DataStore and in the next step you can upload an image that will get associated with that user.

To use the Google AppEngine Blobstore with Vaadin, you’ll need the following 5 components:

1. Vaadin user management

This example doesn’t really go into how to deal with users. But to demonstrate the concepts, there’s a basic user object. It contains a name and an id. The example uses Objectify for easy persistence to the datastore.

The user object also has 2 more field:

• a blobkey that points to the uploaded image (if any)
• an uploadkey that is only used during the upload. This is explained later on.

The user object is stored in the Vaadin application’s user field.

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

public class User implements Serializable {
  @Id Long id;
  String name;
  String uploadKey;
  String blobKey;
 
  // skipping getters, setters, constructors, equals and hashcode
 
  public String generateUploadKey() {
    this.uploadKey = String.valueOf(Math.round(Math.random() * 100000f));
    // you probably want something more robust here
    return uploadKey;
  }
}

2. Blobstore upload form

The example reuses the upload form that is used in the Blobstore documentation.

There is one difference: we add a hidden field that contains a randomly generated upload key. This key is also stored with the user object in the datastore. This key will be used by the servlet below.

1
2
3
4
5
6
7

final String uploadKey = user.generateUploadKey();
final String uploadUrl = BlobstoreServiceFactory.getBlobstoreService().createUploadUrl("/uploadImage");
final Label label = new Label("<form action=\"" + uploadUrl + "\" enctype=\"multipart/form-data\" method=\"post\">" +
  "<input type=\"file\" name=\"myImage\" />" +
  "<input type=\"hidden\" name=\"uploadKey\" value=\"" + uploadKey + "\" />" +
  "<input type=\"submit\" value=\"Upload\" />" +
  "</form>", Label.CONTENT_XHTML);

3. Upload servlet

The Blobstore itself is responsible to handle the upload. So we can’t use the traditional way of uploading multipart formdata. There is no direct access to the bytes. Instead the Blobstore will save the uploaded file and call a servlet. This servlet can access the uploaded blob via a number of parameters in the request.

Because Vaadin hides this request it is difficult to add the handling of the upload to your Vaadin application. I’m sure it’s not impossible, but I decided to create a separate servlet.

The servlet does not have access to the Vaadin application and its associated user object. That is why the servlet gets the upload key from the form. It searches the associated user and can then add put the blobkey into the user object.

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

protected void doPost(HttpServletRequest req, HttpServletResponse resp)
      throws ServletException, IOException {
  final Map blobs = blobstoreService.getUploadedBlobs(req);
  final BlobKey blobKey = blobs.get("myImage");
  final String uploadKey = req.getParameter("uploadKey");
 
  final Objectify ofy = ObjectifyService.begin();
  final User user = ofy.query(User.class).filter("uploadKey", uploadKey).get();
  user.setBlobKey(blobKey.getKeyString());
  ofy.put(user);
 
  resp.sendRedirect("/?refresh");
}

4. Vaadin refresh parameter handler

After the upload servlet has done its work, it redirects the user to the Vaadin application. To make sure the application updates it’s content, an additional parameter is added to the request URL.

This parameter is intercepted by a parameter handler that’s responsible for refreshing the Vaadin layout.

1
2
3
4
5
6

@Override
public void handleParameters(Map<String, String[]> parameters) {
  if(parameters.containsKey("refresh")) {
    // refresh the layout ...
  }
}

5. A Vaadin resource for the blobstore

This is a fairly straightforward implementation of the Vaadin ApplicationResource. It makes it easy to integrate blobs into your application.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

public class BlobstoreResource implements ApplicationResource {
  // variables skipped
  public BlobstoreResource(String keyStr, Application application) {
    this.application = application;
    this.blobKey = new BlobKey(keyStr);
    this.blobInfo = new BlobInfoFactory().loadBlobInfo(blobKey);
    if (blobInfo == null)
      ; // handle missing blob here
    application.addResource(this);
  }
 
  @Override
  public String getMIMEType() {
    return blobInfo.getContentType();
  }
 
  @Override
  public DownloadStream getStream() {
    InputStream inputStream;
    try {
      inputStream = new BlobstoreInputStream(blobKey);
    } catch (IOException e) {
      return null;
    }
 
    final DownloadStream ds = new DownloadStream(inputStream,
        getMIMEType(), getFilename());
    ds.setBufferSize(getBufferSize());
    ds.setCacheTime(cacheTime);
    return ds;
  }
 
  // other methods skipped ...
}

Conclusion

The example demonstrated the basics for integrating the Google AppEngine Blobstore with a Vaadin application. It was a fully functional example, but beware, before you go to production, you’re going to want to add a whole lot of error handling.

Vaadin / Google AppEngine integration example project

In this tutorial you’ll learn how to create your very first Vaadin web application, how to run it on a local AppEngine development server and how to deploy it to the Google App Engine infrastructure. And all of that in about 5 to 10 minutes. Yes, if you have the necessary prerequisites installed, you’ll be up and running straight away. Thanks to the power of Maven.

This tutorial is in the form of a nicely formatted, 4-page, quick reference card. You can download it straight away, no sign-ups required.

The card will guide you through the process of:

• Setting up your environment.
• How to run a Vaadin application on the Google App Engine development server.
• How to deploy that application.
• How to start customizing the Powered by Reindeer templates.

Please leave your feedback. I plan to do follow ups and would love your input.

Get started with Vaadin and Google AppEngine right now.