SEO: Redirecting users from your www subdomain to the non-www domain

One of the major things people don’t understand about Search Engine Optimization (SEO) is that google assigns a PageRank per URL. So if you have a friend who links to and another friend that links to, google doesn’t combine them and acts as if one person is linking to each page.

However, if, when crawling your page, the googlebot is redirected via a 301 Moved Permanently, the googlebot learns that the two pages are the same. This is incredibly easy to do if mod_rewrite is enable on your Apache installation.

To do this, open up the .htaccess for your site and add these lines:

# To redirect all users to access the site WITHOUT the 'www.' prefix,
# ( will be redirected to
# adapt and uncomment the following:
RewriteCond %{HTTP_HOST} ^www\.yourpage\.com$ [NC]
RewriteRule ^(.*)$$1 [L,R=301]

Remember to replace “” with your actual URL. This redirect/rewrite will preserve the query so will still get translated to

Setting max width and height on images for Corona SDK

As some of you may know, I am currently experimenting with Corona SDK to develop with one code base, an application that can be deployed to both iOS and Android devices.

Corona SDK’s UI tools are very primitive, and this is the first of several entries on how to improve upon the standard UI API Corona gives you.

One of the first problems I ran into was image sizes. In Corona, I can give an image a size via the display.newImageRect() function, and Corona will scale my image for me. However, it does not maintain the aspect ratio of the original image.

I pulled out my ui module and added a function to figure out the width of an object, given the height:

-- get the width of an image given the height of the image. Maintain aspect ratio
function ui.imageGetWidth(image, height)
	local tempImage = display.newImage(image)
	local multiplier = height / tempImage.height
	return tempImage.width * multiplier

With this function, all I cared about was setting a maximum height, and not caring about the restraining width. However, I soon found this was too limited and needed to find a real height and width given a maximum for each direction. So I expanded that function a bit into this:

-- get the size of an image given the maximum width and height. Maintain aspect ratio. Prefers larger image
function ui.getImageSize(image, maxwidth, maxheight)
	-- print(image .. ":" .. maxwidth .. "x" .. maxheight)
	local tempImage = display.newImage(image)
	local multiplier_height = maxheight / tempImage.height
	local multiplier_width = maxwidth / tempImage.width
	local width = nil
	local height = nil
	if multiplier_height > multiplier_width then
		width = tempImage.width * multiplier_height
		height = tempImage.height * multiplier_height
		width = tempImage.width * multiplier_width
		height = tempImage.height * multiplier_width	
	-- do we need to shrink?
	if width > maxwidth then
		--resize width
		multiplier_width = maxwidth / width
		width = maxwidth
		height = height * multiplier_width
	if height > maxheight then 
		--resize height
		multiplier_height = maxheight / height
		height = maxheight
		width = width * multiplier_height
		-- because this can only shrink, we do not need to check width again
	--make whole
	width = math.floor(width)
	height = math.floor(height)
	return {
		width = width,
		height = height

Which worked perfectly, except now I needed to call it, then create an image and then set that image to the values returned from it. This created a lot of extra overhead and a lot of complicated code. So to tie it all together, I rewrote the display.newImageRect into this:

function ui.newImageRect(image, maxwidth, maxheight)
	local size = ui.getImageSize(image, maxwidth, maxheight)
	return display.newImageRect(image, size.width, size.height)

The new ui.newImageRect ties everything together and I can create aspect ratio restrained scaled images with one line of code.

Distributed stress tester with Erlang Part 1

One day, not too long ago, I was asked by a client, “What would happen if we send the server five times the volume of traffic currently being sent?” They were asking this question because they had just acquired another company and was planning on integrating that companies services with theirs. The answer, quite frankly, was no. Our servers’ CPUs were hovering near 50% utilization at all times, and we didn’t want to risk maxing out.

However, as luck might have it, we were getting new hardware in two weeks. That gave me two weeks to figure out just how much load our new hardware could handle.

Examining the Problem

We needed to figure out how much load the new servers could handle, so we needed a way of flooding the network with requests. We had a regression tool, but it just wasn’t cut out for this type of work. It sent one message at a time, and did pre and post processing. No, we needed something better, something faster.

We could use perl, make it concurrently send messages to the server via curl. That would work. But it wasn’t distributed, so unless we coordinated our testing, it would be limited by that one user’s bandwidth. Not enough to reach current production traffic. And a hassle to coordinate, so that won’t work.

Then I remembered the conference I went to a while back, CodepaLOUsa, there was a session I attended by Bryan Hunter about Erlang.

Erlang: Enter Stage Right

Erlang has this neat ability to make distributed, cross-network computing extremely simple. It was designed for this type of job. To connect to a cluster (or “cloud”) of computers is only one line of code:


Not only does that connect you to the remote node, it also connects you to every node connected with the remote node. And when your pool of nodes is a wandering army of co-worker laptops, it’s a good thing Erlang gossips. To manage our constantly changing network of nodes, we setup one, immobile, always on node at a development server. Whenever a laptop was booted, an Erlang node was launched, which connected to the coordinating node at the development server. Because everyone knew where that was, everyone knew where everyone else was too.

Let’s Work Together

Now that we have a cluster of nodes, let’s do something with them! To send a command to all the nodes is also incredibly simple in Erlang. It’s also just one line of code:

rpc:multicall(ModuleName, FunctionName, [Array of Parameters]).

It’s as simple as that. That line of code will call

ModuleName:FunctionName(Array of Parameters).

on all nodes connected to you, including yourself.

But Sir, How Will We Know What To Do?

Now that we have all the nodes connected, and know how to tell them to do something, how do we deploy our module that actually does the stress testing across all the nodes? In a normal situation, you’d have to email everyone a copy of your binary, or have them update it using some sort of tool. Or if you’re savvy, you could have a cron job check for new versions and update every so often. But that’s all too complicated. All the hassle to send that out and get everyone to update, or all the red tape for management to approve a new deploy. Too much work, let’s solve it with Erlang. In Erlang, deploying your module to all the nodes connected to you is, you guessed it, one line:


Once we compile our stress tester, we can deploy it using that single line of code, and then we can make all the nodes execute it using rpc:multicall.

What Next?

Now we have our network of laptops connected, and everyone has the code and can run it, what is actually in our code for stress testing? Join me next time for that!

To Be Continued…