Goal One: Save Money

Many people seem to have a belief that just because the site/s are on a VPS, even with memory set as low as possible (300MB of RAM assigned to a machine in the case of a DreamHost VPS), they will have perfect or near perfect uptime. Sadly, this is not the case and often times this misunderstanding/confusion can lead to serious downtime and frustration. Ideally, for people who are trying to have the lowest amount of memory usage possible, a memory management application would realize that there is a need for more memory, calculate an estimated amount of memory needed to handle the increased usage, resize the VPS as closely as possible to that need, then downsize as soon as the memory is no longer needed.

There is one major issue with this scenario:

Creating estimates regarding the amount of memory needed in an environment where usage is constantly changing, is a massive challenge. To be more specific; since the ability to resize a VPS tends to take some time (anywhere from 1-5 minutes), it is possible for memory requirements to have increased during the time that the need was detected and the memory estimate was created. This could create a resize on a VPS with too little memory, causing problems for the website/s on the VPS, as the machine is given too little memory to handle the increased need.

Goal Two: Keep Services Running

If you are on a VPS, chances are you’ve outgrown shared hosting or are looking for more stability and control over the environment your applications run on. If you’ve got a decent understanding of servers, applications, and websites, you may also understand that you need to have enough memory to run all the processes and handle the requests to your sites. Often times simply setting your service to the lowest amount of memory possible is going to be asking for failed script executions and the dreaded 500 error being displayed on your site.

So with this understanding, some people go to the extreme and max out their VPS resources. At DreamHost that means $200 a month for services (4GB worth of RAM) which may not be fully utilized (and most likely are not). So the question here becomes how to balance cost and the need for memory, in order to keep services running without paying the maximum amount at all times.

A Hybrid Memory Manager Focused on Uptime

With these two potential goals in mind, I had decided to mainly focus my attentions on goal two. While I do understand the need to keep price as low as possible, it is my personal belief, gleaned from experience, that a downed website is more damaging to the bottom line than a slightly larger payment for hosting services. So with this in mind, the memory manager was created to focus on uptime, while still saving time and money for those who manually resize throughout the day, and potentially over-allocate memory for their site/s.

All this being said, I am quite excited to be releasing this software soon. The status of this release is currently closed beta. However, if you are interested in testing this on your DreamHost VPS, please contact me. I am looking to increase the pool of Beta testers before the official release.

You can download the PasswordWithSalt.class.php file here. Also I setup a VERY simple demo of how this works. I’m still working on developing this but comments and advice will definately be useful here.

 The following is the rough text and instructions I’ve written for my “readme.txt” file.

I know many people don’t add some salt before storing the password and MD5.rednoize.com really is the perfect example as to why you should be salting all passwords! Even if you have a single sitewide salt - prepending it to a user’s password before creating the hash is a powerful way to prevent the use of a database like the one which runs MD5.rednoize.com matching against your database. So basically in PHP:

$salt = “ThisSuperLongStringWillProtectMyUsersAgainstInsecurePasswords”;
$userpass = $_POST['pass'];
$md5pass = md5($salt . $userpass);

When your user then attempts to login you’ll duplicate the same process. I personally would keep the $salt in a file outside the normal webroot.

Now the chances of a site having the matching hash to your users password – even if the pass is ”word” is MUCH less likely. I hope this explains what it means to salt your passwords.

You can read Marcel’s post and learn how to call his webservice here:
http://blog.fl3x.de/2005/11/10/checking-password-strength-using-md5rednoizecom-and-ajax/

Resize JPG images using the GD library and PHP.

function get_image_information($key) {
global $thumbnail_dest, $image_dest, $thumb_max_height, $thumb_max_width, $image_max_height, $image_max_width;
$filename = $_FILES[$key]["name"];
$file_type = $_FILES[$key]["type"];
$file_tmpname = $_FILES[$key]["tmp_name"];
$file_error = $_FILES[$key]["error"];
$file_size = $_FILES[$key]["size"];

if($file_error == 0 && $file_size > 0) {
if($file_type == “image/pjpeg” $file_type == “image/jpeg” $file_type == “image/jpg”) {
$image_name = md5(time() . rand(1001,10000)) . “.jpg”;
$thumb_dest = $thumbnail_dest . $image_name;
$image_dest = $image_dest . $image_name;
create_image($file_tmpname, $thumb_max_height, $thumb_max_width, $thumb_dest);
create_image($file_tmpname, $image_max_height, $image_max_width, $image_dest);
return “thumbs/” . $image_name;
} else {
$success .= file_upload_success_1 . $filename . file_upload_success_2 . “
“;
$success .= “We can only accept jpg uploads. Upload Failed.”;
return $success;
}
} else {
if($file_error == 1) {
echo $file_upload_fail_1;
} elseif($file_error == 2) {
echo $file_upload_fail_2;
} elseif($file_error == 3) {
echo $file_upload_fail_3;
} elseif($file_error == 4) {
echo $file_upload_fail_4;
} elseif($file_error == 6) {
echo $file_upload_fail_6;
}
return false;
}
}
function create_image($image, $max_width, $max_height, $dest) {
$image = imagecreatefromjpeg($image);
if ($image === false) {
die (‘Unable to open image’);
}

$width = imagesx($image);
$height = imagesy($image);

if($width < $max_width && $height < $max_height) {
$new_width = $width;
$new_height = $height;
} else {
$scale = min($max_width/$width, $max_height/$height);
$new_width = floor($scale * $width);
$new_height = floor($scale * $height);
}

$image_resized = imagecreatetruecolor($new_width, $new_height);
imagecopyresampled($image_resized, $image, 0, 0, 0, 0, $new_width, $new_height, $width, $height);
imagejpeg($image_resized, $dest, 90);
}

For all those developers interested in making some seriously interesting or possibly revenue generating programs the google, amazon, and ebay api’s may be a good place to start. I’ve used them in the past always to make something small for a client.

Now it’s my turn, and although the programs I would like to make may be small they’ll be a great learning experience and my own! It’s just that special little feeling of accomplishment when that first XML transaction goes through and you recieve something other than an error code! Ah, yes that’s a good feeling indeed!

So yeah I went a little overboard today and signed up for every major API at the three.
If you’re interested take a look!
Google Maps API (This one is just fun.)
Google Ajax Search API (Might be interesting.)
Google Adwords API (Maybe make some money off this.)
Google Checkout API (Sign up for sandbox if developing. Looks great in my opinion.)
Amazon Web Services (You can make some interesting things out of this!)
Ebay API (Hmmm webservices with ebay… definately could build something interesting!)

Enjoy!