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.

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?)