DIY 19-inch Rolling Rack

By · Published · diy

Tags: diy, 19" rack, 1u

After my debacle with the 1U servers I bought (see my previous post), I went by a local technology recycling center and picked up a couple of off-lease Dell Poweredge 1750s. It's what I should have done in the first place.

Anyways, I decided a few weeks ago that I wanted to mount these servers in a rack. I wanted it to be mobile and easy to move as moving is something I have been very familiar with over the last few years. After not finding what I wanted anywhere, I was able to find rack rail at  zZounds (a music store that I've ordered guitar stuff from before). So I decided to do it myself.

The first step was to understand the measurements of a 19" rack. Originally designed to hold railroad signal switching relays, 19" rack measurements are specified by EIA-310-D. The strips from RaXXess are standard rack rail at 0.625" in with. They are mounted at 19" apart from the outside of the rails, giving a distance between the inside edges of the rails of 17.75". The depth isn't specified, so I decided to make mine 30" deep.

After that, it's just cutting! It took 4 2x4's at 10ft and a sheet of plywood. The pictures below will explain better than I can in words the process of building this thing.

Parts

The first step was measuring and cutting. This was actually the most tedious part of doing this whole thing was getting the measurements right - as Dad always said, measure twice, cut once! I cut four 24.5" pieces, four 22" pieces, and four 36" pieces.

Frame 1

Here's the completed frame 1, with a Dell Poweredge 1750 in to test and be sure that I had the measurements right. The rails had been mounted on the inside towards the back of the frame to give the server face some protection.

Server Closeupt

Closeup of the server in the frame.

Almost complete!

Adding the top and bottom pieces now.

(Mostly) Finished Product

Mostly complete. By now you can see what I'm aiming for.

Done!

And here's the finished product! I added plywood sides and casters to roll it around.

Looking Down

The total cost was about $100. The most expensive items were the rails (which came in at about $50 shipped) and the casters (which were $20 for four locally from Harbor Freight). After that, it took me about four hours cut and put everything together. It's not quite finished yet - I want to add doors to the front and back to ease transport a little bit as well as handles on the sides to make it easier to lift in and out of a truck.

I haven't put the servers in it yet - I'm waiting for rails to come in for the servers since they didn't have any where I bought them from. I'm also thinking about slaping a coat of paint on it to make it look a bit better. Otherwise, it's pretty sweet!

( Comments )

Angry Rob is Angry

By · Published ·

Tags: geeks, geekcom, hardware failure

... or, beware of deals that look too good to be true.

In my professional career, I have now found only two things that have a 100% failure rate. The first was a batch of Digium TDM-400P FXO/FXS card. Every single one we deployed from that batch at my previous employer failed. I hear they don't have those problems anymore - using a different fab shop now, I guess. But I still don't like that card for that specific reason.

The second 100% failure rate came just this evening. The culprit is this little POS: Dual Xeon 2.4GHz 2GB ECC 120GB 1U Rack Mount Server being sold by Geeks.com.

Look, it's a 1U for $375. I'm not expecting the universe out of these things. With that in mind, let me document the last two days of my life. I ordered two of these little guys about a week ago, and they arrived on Tuesday. I intended to turn one into a general purpose test and development box, and one was going to go to Atlanta to replace the 1U Celeron in my friends' data center.

So I get the machines home, unpack them and try to boot. The first one won't POST. No beep, no video, just a bright orange surrender HD light. Research tells me that the motherboard is fried. The other one booted up fine. I figured I was just unlucky, so I RMA'd the first one today and was going to put the OS on this one.

Well, the OS install went fine but when it came time to reboot ... presto. The exact same thing as the first. No video, no beep, orange HD light. Of two machines ordered, both of them failed within 48 hours and both in the exact same way. So now I'm out at least $60 in RMA shipping charges - and I have no servers - just because this company apparently has no Q.A.

So take my experience as an example of what not to do when ordering a server. A good deal can turn into a major headache incredibly fast. Me? I'm ordering Dells from now on.

( Comments )

Something In The Air

By · Published · apple, mac

Tags: apple, macbook, macbook air, macworld

... or maybe the water.

Unless you were living under an Internet rock, you likely know that today was Keynote Tuesday. That is, the day Apple CEO Steve Jobs tells us loyal apple fanbois what we will be spending our money on this year.

The star of this year's show was the Macbook Air, a thin, light laptop designed to fit somewhere inbetween the Macbook and the Macbook Pro. At first I was wow'd by the Air. Jobs, as always, is the consummate showman and I will admit that I bought into the reality distortion field for a little bit. Then the "air" cleared and I began to think about what the Macbook Air really is. So let's take a look at the Macbook Air and where it fits.

  • Maximum thickness of 0.76". The Macbook is a quarter inch or so higher at 1.08".

  • Weight of 3 lbs. The Macbook, a slightly heavier 5 lbs.

  • Battery life is slightly longer at 5 hours. The Macbooks average between 3-4 in my experience. However, the battery is not removable, whereas I could carry several Macbook batteries with me.

  • For $1200 more, you can get a solid state drive.

  • 2GB of memory, and only 2GB of memory. The Macbook comes in at 1GB standard, but can be upgraded to 4GB.

In my opinion, these are the areas where the Air wins. Now, let's look at where it loses.

  • 1.6ghz / 1.8ghz Core 2 Duo. The Macbook slides in at betwen 2.0 and 2.2 ghz.

  • Storage is an 80GB 4200rpm PATA drive, whereas the Macbook boasts an 80GB 5400rpm SATA drive. Granted you can get a 64gb SSD drive with the Air, but for $1200 I can't believe that anyone other than the biggest fanboi will be buying those for that price.

  • The Macbook can be upgraded to as much as 4GB of memory. The Air is stuck at 2GB, and since it's sodered onto the board, it's stuck there forever.

  • 1 USB plug? No onboard Ethernet or FireWire? No mic plug?

  • No optical drive. Granted, you can buy an external drive, and you can use that boot from another computer thing, but that doesn't help you if you have no other computer.

Now, Brian Moon often tells me that I don't think from the point of view of an average user because I'm not an average user. While it's true that I'm not your average user (as a computing professional, I have needs generally beyond most consumer computing gear), I like to think that I can look at all choices and choose the best one. In this case I just can't understand where this product is being targeted.

I just don't understand how anyone could want to trade off all the features you get with the regular ol' Macbook for what is essentially a small gain in dimensions and weight, and the "wow!" factor, especially when all those added features on the Macbook come in at $300 less for the top-end Macbook model. At that price, you could upgrade the memory and buy an extra battery and still come in less than the base price of the Macbook Air, with the only tradeoff being that it's 0.32" thicker and 2lbs heavier.

I can't believe that any informed consumer is going to choose a feature poor Macbook Air when the standard Macbook, at between $300 and $750 less, is just so obviously a better deal. Brian Tiemann said it best: "a ridiculously overpriced, feature-poor, and generally useless pig of an idea."

Also, I wonder if Steve Jobs knew Randy Newman was going to go all Michael Moore on everyone. Someone please be sure he never sees a microphone again!

( Comments )

Four Free Mac Apps I Can't Live Without

By · Published · apple, mac, osx

Tags: apple, mac

I know top X lists are almost passe at this point, but that's not going to stop me from giving a shout-out to some of the applications that daily make my life easier:

MarcoPolo

MarcoPolo is a neat little application that is capable of executing actions based on a set of rules. That is, if something on the system changes (such as an IP address, power status, USB or even the light level), it can execute a series of commands (such as mounting network drives, setting the screensaver, changing the default printer, etc). It can even run arbitrary shell scripts!

Why this is useful to me: At dealnews, we (the dev team) all use MacBook Pros for our development work and constantly alternate between home and office. Whenever I arrive at work in the morning, the minute I plug my MacBook into the network, MarcoPolo senses that the IP address has changed from my home and changes the default printer, mounts some network shares, adjusts the screensaver settings, and runs a few other custom shell scripts I have to set up my environment. All without having to do a single thing. When I get home, it executes still more commands to change to a remote development environment. Completely effortless.

XMeeting

XMeeting is a SIP softphone (and videoconferencing application, but I've never used the video features) that allows you to connect to a SIP server and place calls using your laptop.

Why this is useful to me: At dealnews, we run Asterisk as our phone system (see my earlier posts on Asterisk). One of the many nice features of Asterisk is its standards compatibility - that is, you can use anything that can talk SIP with Asterisk. Since CounterPath has apparently decided that Leopard compatibility for their free softphone (X-Lite) is not a priority, XMeeting comes to the rescue. As a bonus, it actually acts like a Mac application and doesn't do the stupid things that X-Lite did (like messing with the system volume).

Quicksilver

Quicksilver is the single application I cannot live without. On a Mac without it I am almost lost. More than just a launcher, it is a tool to help you work more efficiently. You can press Ctrl+Space and type what you want and Quicksilver will launch what you need. That's a horrible description for how cool this app is.

*Why this is useful to me: *Without Quicksilver, I am lost. It makes it literally so fast to move around your Mac without taking you hands off the keyboard. A quick hit of Ctrl+Space gives you the ability to launch programs, open files, navigate contacts and send emails, and make quick notes among many othe things that this program can do. It is essential to my everyday life as a Mac user.

DejaMenu

DejaMenu is a neat little program that will display the current application's main menu as a popup menu where the mouse is whenever a key combination is pressed.

*Why this is useful to me: *I use my MacBook Pro with a second monitor when I'm at the office. One of the things that has infuriated me for awhile as a Mac user with multiple monitors is the inability to have the top menu bar either on each monitor respresenting the application on that monitor, or the ability to have it move with whatever monitor the mouse is on. It's irritating to have to go back to the main monitor when the application is running on a different one. DejaMenu allows you to pop the application menu wherever your mouse is, which makes things a little easier. Additionally, I mapped the key combination to a button on my Logitech MX-1000 to make things even easier.

( Comments )

Announcement

By · Published · news

While in general I only use this blog for discussing programming, computers and my life as an engineer in dot-com, it's only natural that, every now and then, a personal post will slip in. And this is as good a reason as any.

On December 26th, I asked my girlfriend of almost three years to marry me.

She said yes!

 

 

( Comments )

Benchmarking Vista and XP: Apples and Oranges?

By · Published · microsoft, pc, windows, mac, osx

Tags: vista, windows, xp

This article posted to C|Net got me to thinking. In the article, they talk about vaguely defined "benchmarks" showing that Windows XP with the beta of Service Pack 3 outperformed Windows Vista with Service Pack 1.

I can only say one thing: duh. Quite frankly, I would have been more surprised if Vista had outperformed XP.

This really is an apples and oranges comparison because Vista is a newer and more complex operating system. And I'm not exactly a Microsoft fanboy, either - I'm typing this on a Mac, using a Java journal client. Of course it is going to run slower on the same equipment than an operating system that was released six years ago. I'm sure Windows 98SE will beat the pants off of XP on the same equipment, too. Leopard, released a few months ago, won't even run on hardware circa when OS X first came out and will almost certainly run slower on machines that were top of the line when Tiger was released. Hey, while we're at it, we could compare Doom to UT3 to see which runs faster!

If they wanted to do a more fair comparison, they would have compared them on different machines - top of the line machines when their respective operating systems were released, using adjusted benchmarks. Being that machines are much faster now than they were in 2001, I wager that the difference between them would be a lot less.

 

( Comments )

Set Leopard's Menu Bar Back To White

By · Published · apple, mac, osx

There's been a good bit of debate about Leopard's new translucent menu bar. For me, it doesn't cause many issues. However, some of my coworkers despise it and, to be fair, I can see the arguments that many of the people who dislike it have: it doesn't add anything to the OS and actually makes it more difficult to read the text.

Well, here's a litle tweak that will set the menu bar back to a white background. In the terminal, you can use the following command to change the default appearance of the bar:

sudo defaults write /System/Library/LaunchDaemons/com.appledowServer 'EnvironmentVariables' -dict 'CI_NO_BACKGROUND_IMAGE' 1

Restart your Mac, and voila! White menu bar! Changed your mind? Set it back:

sudo defaults delete /System/Library/LaunchDaemons/com.apple.WindowServer 'EnvironmentVariables' -dict 'CI_NO_BACKGROUND_IMAGE'

Restart your Mac and your menu bar is back to being translucent.

( Comments )


Controlling iTunes with Python ... Cross Platform

By · Published · python, mac, apple

So it's been awhile since I've written. In that time, my girlfriend has moved in here with me in Huntsville and, as always, dealnews has kept me very busy. However, it has not prevented me from occasionally trying my hand at something new.

A week or so ago I decided that I was going to learn Python. However, as part of my nature, I simply can't "learn" a language without having a purpose. For instance, I have never been able to simply read a book on programming - I needed a reason. So I've been giving myself reasons to do little tasks here and there in Python. One of them came to me just today.

I have recently moved all of my development at dealnews from the PC to a Macbook. I've never been an OS-bigot - always use the right tool for the job, and the Mac - which in many ways is just Unix with pretty make-up - is the perfect platform. However, I still use many of the peripherals I purchased for my PC, including my Microsoft Natural Egronomic Keyboard that I adore. At home, I still use a PC (until I can afford a new Mac Pro), albeit with the same keyboard.

One of the things I really love about the keyboard is that it has various buttons that are just ... buttons. They can be mapped to do anything you want them to. There are five multi-function buttons at the top that can be mapped to run programs. So I'm sitting here thinking, "self" (because that is what I call myself), "why not write a little program to run on the click of that button and go to the next or previous track in iTunes, so that changing the music doesn't involve any more effort out of my busy programming day than hitting an additional keystroke". But, it must work both at home and at work, meaning that it must run in Windows and Mac.

Enter Python

I knew from previous experimenting in .NET that iTunes exposes a COM object on Windows. With that in mind, I quickly found this page that described almost exactly what I wanted to do in Windows. So that left the Macintosh. After an hour or so of digging on Apple's website, I found this page that described how to access the COM on the Mac - and wouldn't you know, the functions are slightly different.

After that, it was pretty easy:

import sys from optparse import OptionParser

platform = sys.platform
if platform == "win32":
    import win32com.client
    iTunes = win32com.client.gencache.EnsureDispatch("iTunes.Application")

if platform == "darwin":
    from Foundation import *
    from ScriptingBridge import *
    iTunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")

def previousTrack():
    if platform == "win32":
        iTunes.PreviousTrack()
    if platform == "darwin":
        iTunes.previousTrack()

def nextTrack():
    if platform == "win32":
        iTunes.NextTrack()
    if platform == "darwin":
        iTunes.nextTrack()

def main():
    parser = OptionParser()
    parser.add_option("-n", "--next-track", action="store_true", dest="next")
    parser.add_option("-p", "--prev-track", action="store_true", dest="prev")
    (options, args) = parser.parse_args()
    if options.next == True:
        nextTrack()
    if options.prev == True:
        previousTrack()

if __name__ == "__main__":
    main()

So yeah. It's kind of code monkeyed together, but not bad for someone who's only been doing Python for a week in the evenings. Passing either a -n or -p to the script causes it to command iTunes to go forward or back. Of note, to work on Windows, it does need the COM components from the Python for Windows extensions.

I'm gonna expand this script some more in the future, but for now it does what I need.

( Comments )

PHP Templating Celebrity Deathmatch!

By · Published · php

Tags: php, smarty, blitz, includes, benchmarks

Ladies and Gentleman! Welcome to the PHP Templating Celebrity Deathmatch!

I actually do like the idea behind templating. I know there are varying arguments about whether or not templating is appropriate for PHP, though those are not the focus of this entry.

The big idea behind templating is separation of concerns, that is, breaking a program into parts that are easily manageable and don't overlap in functionality. In an ideal world, templating would provide the added advantage of allowing a programmer to be a programmer and not a web designer - and allowing a web designer to be a web designer and not a programmer - by keeping the logic underlying the presentation layer to a minimum. However, I have never found this to be true in any project I've worked on in my professional career.

One of the big benefits, as far as I see, is that it makes code much easier to read. This may not be true for everyone, but I would much rather be confronted with smooth, separated templated code rather than a jumbled PHP mess. It's easier to read and far, far easier to adapt and change.

While I was attending OSCON a few weeks ago, I heard mention of a new PHP templating engine that was written in C and native compiled into a PHP extension. This would make it much, much faster than anything written in PHP itself - in theory. This project, called Blitz, was making some pretty grand claims on their website, so I wanted to put them to the test - at least a small timing test.

In this test, I am going to be comparing Smarty (the most widely used PHP templating engine and an official PHP project), Blitz (a new templating engine currently under very active development that is native compiled as a PHP extension), and standard PHP includes.

For the purposes of this test, I wrote a quick timing function that uses microtime() to record how much time has elapsed between each call of mark_time(). The code is available in the accompanying project.

A Note About The Tests

These are not meant to be exhastive tests by any means. These tests are just designed to give you 5,000 foot overview of the current state of PHP templating. They only evaluate page generation time and not other metrics such as CPU load, IO load, or memory usage. Furthermore, I selected three scenarios that I have commonly used in templating; there may be some scenarios that I haven't tested where one method may outperform others. And, as with any benchmarking, they are dependent on my system - YMMV.

Test 1: Instantiation

This is a simple test that determines how much time it takes to power up the templating engine and get it loaded into memory for PHP to use. For the purposes of this test, we will just be comparing Smarty and Blitz, as there is no need for instantiation with a standard PHP include. We'll start with Smarty first.

smarty_instantiation.php

<?php
echo mark_time()."<br>";  
include "Smarty.class.php";  
$smarty = new Smarty;  
echo mark_time()."<br>";
?>

Smarty's instantiation time was 0.0058109760284424 or 0.005 seconds in human terms.

blitz_instantiation.php:

<?php
echo mark_time()."<br>";  
$blitz = new Blitz;  
echo mark_time()."<br>";
?>

Blitz's instantiation time was 3.0994415283203E-5, or 0.00003 seconds in human terms.

It may not seem like a big difference, but this is one area where having Blitz as a PHP extension makes a huge difference over Smarty being written in PHP and included. Because PHP must traverse the include_path to find Smarty.class before including it, it causes PHP to be slowed down before it can even instantate the Smarty object. To be fair, I decided to run a second test again with the include out of the timing mark.

smarty_instantiation2.php

<?php
echo mark_time()."<br>";  
$smarty = new Smarty;  
echo mark_time()."<br>";
?>

Even without having to search the include_path for Smarty, it still took 6.5088272094727E-5, or 0.00007 seconds to instantate the Smarty object - almost twice as long as it took to instantate the Blitz object. However, this is not a realistic scenario in any way - there is no way that PHP can have saved any time and still have access to the Smarty object!

Winner: Blitz

Test 2: Simple Template Rendering

In this test, we will be comparing simple template rendering in Blitz, Smarty and PHP includes. In this test we will create a simple HTML template with two variables that need to be replaced, then render and display them to the user using each engine or, in the case of PHP, straight PHP. So, let's get started! We'll run Blitz first, since it won the previous test.

blitzsimplerender.php

<?php
echo mark_time()."<br>";  
$blitz = new Blitz('blitz_simple_render.tpl');  
echo $blitz->parse(array(  
'title' => "Blitz Test!",  
'body' => "Blah foo! I'm a body!"  
));  
echo mark_time()."<br>";
?>

Blitz took an impressive 0.00011801719665527, or 0.0001 to render a simple HTML document with two replaces. Smarty's next:

smartysimplerender.php

<?php
echo mark_time()."<br>";  
include "Smarty.class.php";  
$smarty = new Smarty;  
$smarty->assign('title',"Smarty Test!");  
$smarty->assign('body',"Blah foo! I'm a body!");  
$smarty->display('smarty_simple_render.tpl');  
echo mark_time()."<br>";
?>

Because Smarty is a compiling engine (it compiles the templates to PHP and caches them), the first run is always the most costly - in this case, an atrocious 0.058284997940063 or 0.06. Even on subsequent runs, 0.0065691471099854 or 0.007, again much slower than Blitz. Finally, standard PHP includes:

phpsimplerender.php

<?php
echo mark_time()."<br>";  
$title="PHP Test!";  
$body="Blah foo! I'm a body!";  
include "php_simple_render.tpl.php";  
echo mark_time()."<br>";
?>

Surprisingly, standard PHP includes took 0.00030016899108887, or 0.0003 seconds - much faster than Smarty, but three times as slow as Blitz. Once again, this likely has to do with PHP having to traverse the include_path before finding the appropriate file. If you specify the _absolute path on the filesystem _to the file above, the time took becomes 0.00010490417480469, or 0.0001, roughly equal to Blitz on any given run. However, because Blitz is able to parse the template with a minimum of fuss whereas I have to explicitly specify the filesystem path for PHP to get equal performance, this round also goes to Blitz.

Winner: Blitz

Test 3: Complex Templating

In this case, we are going to be doing complex templating. This test includes three template-based includes, one foreach loop over an array, and a large array of generated data. Just for the curious, the generation of the data is not going to be counted towards the timing. In this case, we have generated a 10,000 item array and are going to have each engine iterate over it.

blitzcomplexrender.php

<?php
echo mark_time()."<br>";  
$blitz = new Blitz('blitz_complex_render.tpl');  
foreach($arr as $array) {  
$blitz->block('master_loop',array(  
'id' => $array['id'],  
'id1' => $array['id+1']  
));  
}  
echo $blitz->parse(array(  
'title' => "Blitz Complex Render text"  
));  
echo mark_time()."<br>";
?>

Blitz ran the test in 0.072134971618652, or 0.07 seconds, not too shabby considering it had to iterate over a 10,000 item multidimensional array.

smartycomplexrender.php

<?php
echo mark_time()."<br>";  
include "Smarty.class.php";  
$smarty=new Smarty();  
$smarty->assign('title',"Smarty Complex Render test");  
$smarty->assign('arr',$arr);  
$smarty->display('smarty_complex_render.tpl');  
echo mark_time()."<br>";
?>

Again, because Smarty is a compiling engine, the first run is always the most expensive - in this case, a whopping 0.31642484664917, or 0.3 seconds. Subsequent runs fell in the range of 0.099456838607788, or 0.1 seconds, three times as fast as the first run but still slower than Blitz. Finally, standard PHP includes:

phpcomplexrender.php

<?php
echo mark_time()."<br>";  
include "php_complex_render.tpl.php";  
echo mark_time()."<br>";
?>

In this test, raw PHP includes came in at 0.055343866348267, or 0.06, the fastest of all and yet just a small bit faster than Blitz.

Winner: PHP

Conclusion

Blitz won two of the three tests and came in a close second in the last. Of course, one could argue that PHP "won" the first test since there was no need to be tested on instantiation.

Considering the short amount of time Blitz has been under active development, its sheer speed is rather amazing. From a templating standpoint, Blitz is the fastest unless you are willing to jump through lots of little hoops to make standard PHP includes work for you, and even at that point, the performance as far as total page generation time goes is roughly equal, though native PHP may have a slight advantage.

However, unfortunately, the very strength of Blitz (it being written in C and compiled into a PHP extension) is its greatest weakness. Because so many websites are served off shared hosts without the ability of users to use external extensions, most of the community will never have the ability to take advantage of Blitz. Only those with access to the machine, or more specifically the php.ini file, will have the ability to use Blitz unless it were to be merged into the PHP tree. Even in the best case, considering how many shared hosts are still running PHP4, I wouldn't expect to see anything like this soon, if ever.

Perversely, the very weakness of Smarty (that it is written in PHP and included) is its strength, for the reasons above. Smarty is the slowest templating engine tested, however because it is just PHP, it can be included and run like any other PHP script - meaning all the people on shared hosting can make use of it with a minimum of fuss. And in Smarty's defense, there are many features (such as template variable modifiers) Smarty has that are simply not available in Blitz. These features come with the tradeoff of a massive loss in speed. It was honestly surprising to me how slow it was.

Ultimately, it is the decision of the programmer as to what is the right method to use. If you want the advantages of templating as far as seperation of concerns and ease of maintenance and you have the ability, Blitz is probably a good choice for you. If you still want the ease of maintenance and separation of concerns provided by templating and are willing to make the tradeoff for a massive loss of speed, Smarty is a possibility also. If sheer pure speed is your primary concern and you're not willing to make any kind of tradeoffs, going with raw PHP is probably your best option provided you fine tune it a bit to get the absolute best performance out of it.

( Comments )