Archive for the 'Technology' Category

19
Nov

building a quiet / silent PC

Well, as everyone around the office knows, I don't get on the upgrade wagon that often.  I see software upgrades as being a neverending cycle meant to pull customers in and take their money, when oftentimes, an upgrade isn't necessary, because the software already works. From a hardware standpoint, this is not as true though. Over time, users' computing needs change, and software and OS take up more and more system resources, so hardware upgrades are a necessity at some point.

I last built a quiet PC in or around 2001/2002, and this box is finally starting to show its age. My first thought was, "I'll just update a few key components to boost the speed and then I won't have to build a whole new machine." WRONG. Everything has changed:

OUT

IDE

VGA

SDRAM

Socket A / Socket 478

IN

SATA

PCI express (PCI x16 / x8)

DDR2 / DDR3

Socket AM2 / LGA775

My main focus wasn't necessarily complete silence, because often that comes at the cost of performance. I tried to get a maximum of performance with a minimum of sound, and without breaking the bank. I ranked silence and cost slightly above performance however, but if I could have all three, I did. I also wanted to be able to overclock this machine to get the most performance possible.

I started with the case. There are few good manufacturers that make quiet cases, like Antec, Lian Li and Zalmann, and I am sure there are others. I settled on an Antec case. Then, I chose a chipset and processor (Intel's LGA775 and their dual core e8500 3.16 GHz chip) and motherboard (Gigabyte EP45 UD3P). The next step was the video card and the power supply. There are still manufacturers who make silent video cards (heatsink only), and granted, you have to give up a little bit of performance, and your case cooling needs to be a little better with a heatsink-only card, but it's not that bad and I don't do heavy-duty graphics anyway. I chose a fanless ASUS ATI 3650 PCI-Express card. Next was the PSU; it needed to have enough power but also be fairly quiet. I chose a Seasonic S12 550W model; there are others to choose from, this one seemed to fit my needs well and seems to be well-received on the internet. Finally, I chose a quiet hard drive (Western Digital's Caviar line is very quiet and are also long-lasting ) and some quiet case fans and a heatsink/fan unit for the processor (the supplied Intel HSF for the processor is far too loud). Nexus makes quiet case fans as does Scythe, and I chose the Xigmatek SDT-HD964 as the HSF, replacing the supplied stock fan with a quieter Nexus 92mm fan.

I'll tell you what, this thing is QUIET! I compared it to my old "quiet" machine, and it surpasses it easily. You have to turn everything off and listen very closely to even hear the fan noise (which is just a very soft "whooshing" sound). And even as quiet as it is, my CPU temps haven't gone above 34C with the processor overclocked to 4.08GHz! Right now, the loudest thing is the PSU fan and the 120mm case fan, whose decibel levels can actually be lowered even more by replacing with quieter fans and using some "undervolting" tricks.

There are a couple of sites I used extensively for the quiet pc component reviews: silentpcreview.com and to a lesser extent, endpcnoise.com. They are both valuable resources in your quest to build the ultimate quiet PC.

03
Oct

A common oversight in CSS fluid layouts

A couple of weeks ago, while working on an elastic CSS layout using floated divs, I noticed an annoying problem: when using a fixed width left floated div as well as a 100% width “elastic” div, if the browser is resized and the content is scrolled horizontally, the elastic div’s background stops at the edge of the floated div. Since a large number of web users still use monitors with resolution under 1280px, I knew that the problem would cause usability issues.

After a bit of debugging the code and the lengthy CSS file, I realized that the issue was not with the code, but with the browser itself. During my testing, I found that the issue occurs in Firefox 2, IE7 and Safari (windows) but oddly enough, not in IE6.

FireFox Before Min-Width tag

FireFox 2 - Without min-width

FireFox After Min-Width tag

FireFox 2 - With min-width

The first solution that came to mind was the min-width tag, and after not seeing the issue in IE6 (which does not support min-width or min-height CSS tags), I knew that this was the solution. Because this bug is somewhat difficult to find, I was curious how many other sites using similar design techniques had this issue.
The CSS

#container {
width:100%;
min-width:960px;
height:200px;
background:#444;
}
#content {
float:left;
width:960px;
background:green;
height:65px;
}

The HTML


<div id="container">
<div id="content">
        im inside text</div>
</div>

text below

After browsing through about 10 popular websites ranging from design blogs to CSS galleries, to online retailers, I was surprised to find that roughly 30% had not corrected this bug. Although the chance that any given user experiences the bug are shrinking as monitor sizes are growing, if only 8% of the users have 800x600 resolution and the site gets 10,000 visitors a week who use a browser other than IE6, that is roughly 41,500+/- visitors a year that are not seeing the site correctly because of the absence of one short CSS tag.

29
May

Managing Legacy Code While Remaining Somewhat Sane

I think every coder and every company that's been around long enough arrives at a situation where for whatever reason, old code needs to be re-used. But not in a 'Hey, I'll grab this function from the site' way but in a 'Hey, we need to redo the frontend for this site without redesigning the code base' way. But seemingly without fail, this code was created three versions of coding language ago using barely logical, much less programmatically sound, methods. As a coder, how do you avoid pulling out all your hair in an instance like this?

There could be a number of reasons for doing this. One, there may not be enough budget to redesign the code. The idea is that by not spending the time necessary to document and and then reprogram the code base, time is saved because the code, in theory, already works. Two, if no one really knows how the code works and a deadline is approaching, it may be hard to justify spending lead time on the process necessary to document code that seems to work. However, I might argue that when making a decision like this, one should consider the support time that might be required to ensure that everything is working properly once the site goes live, the time cost of combining two or more disparate types of code which may not want to 'play nice' with each other, and other similar factors.

Ultimately, whether or not to re-use or reappropriate legacy code depends on the budget, time constraints, and other business factors. If the person who designed the code is available, then this process is made easier; if not, the person who picks up the project has to make some tough decisions. If the decision is made to use legacy code, a developer's best plan is to:

1) Be organized. Keep notes on everything and refer to those notes frequently. The code may be unorganized, but that doesn't mean you have to be.

2) Have a plan and follow it throughout your development. If you have a certain way of formatting code, make sure you do it everywhere. Come up with way to address general problems you will encounter. If a function doesn't work, are you going to rewrite it from scratch? Are you going to attempt to fix the code in-place? Whatever you decide, apply the same thing everywhere.

3) Be patient. Dealing with legacy code can be frustrating and slow. Take it one page / function at a time. Speed is always important, but never at the expense of good code.

4) Keep perspective. Yes, you will encounter crazy, illogical ways of doing things. You will not believe that someone could think this way. However, the point is not to let that distract you from the goal of creating good code. Create a 'Wall of Fail' like we have where we poke fun at these things.

So if you are presented with legacy code that needs to be reappropriated, try to follow these steps. If you do, hopefully at the end of the project you will be able to don a smoking jacket, and not a straitjacket.

24
Apr

Setting up PEAR on a Linux web server (CentOS)

Installing pear lets you take advantages of some really interesting way to extend PHP. This should be a fairly simple install, so we hope this helps.

First shell into your machine. This is a personal preference, but if you don't have an "installs" directory, your home directory can get messy. Let's cd into it.

% cd installs

Now get the pear code:

% wget http://pear.php.net/go-pear

What? No wget? Install wget and come back.

The following is at the top of the file that wget just downloaded, but they don't seem to mention it, so we will. Just run this file as a php script from the command line.

% php -q go-pear

The only thing you need to change is the install path. The default is where you are now. Use /usr/local.

For some reason the default looks like this:

Below is a suggested file layout for your new PEAR installation.  To
change individual locations, type the number in front of the
directory.  Type 'all' to change all of them or simply press Enter to
accept these locations.

1. Installation prefix ($prefix) : /Users/mlavista
2. Temporary files directory     : $prefix/temp
3. Binaries directory            : $prefix/bin
4. PHP code directory ($php_dir) : $prefix/PEAR
5. Documentation base directory  : $php_dir/docs
6. Data base directory           : $php_dir/data
7. Tests base directory          : $php_dir/tests

1-7, 'all' or Enter to continue:

Type "1" to change the path. Go with /usr/local/ and hit enter

The rest is all defaults and let it install.

To test, when you're done check to see if it's in your path:

% which pear

You should be all set. To install something

% pear install NAME_OF_MODULE
24
Apr

Getting authorized_hosts to work | Logging in without a password in Linux

So many of the posts out there about this seem to leave us hanging. This post outlines how to log in to Linux without a password and addresses some of the gotchas that seem to creep up along the way. We manage enough servers that it's nice to be able to get in and around quickly.

I'll try to outline the way to do it and then address some of the gotchas that come up.

Make yourself a private key on the machine you'll be coming *from*. This is how to do it using a Mac or Linux. Windows people, I wish you luck with something like cygwin or using your SSH program to do this. If you're using Linux servers, maybe you can do this on the main machine you log in to, then go from there as your "home base."

Open up your shell.

% ssh-keygen -t rsa

Just hit enter for the passphrase (that kind of defeats the purpose of what we're doing). The default is to put the file it makes in your $HOME directory. (echo $HOME). For this example, I'm assuming that's what you did.

If it didn't exist already, this will have created a directory called .ssh in your home directory and created 2 files inside it:

-rw-------   1 myuser  myuser   1671 May 24  2007 id_rsa
-rw-r--r--   1 myuser  myuser    400 May 24  2007 id_rsa.pub

You need to copy the contents of the id_rsa.pub to your clipboard.

% cat id_rsa.pub

Copy it. It should looks something like this (not my actual key, of course)

ssh-rsa kjakjhasdhjfjkahsgdfhjkgasdjkhgfajkshdgfhjags834yg
swdhjgfjkashgdfjkhasgdfjkhgasdjkhfgasjkhdgfjkhasgdfjkhgasdjk
fhgasdcvjhasgdfjhkqg34jhkqgwejkhfgaskjhdgfkjhasgdfkjhagsd== myuser@Zap.local

Now ssh to the machine you want to log in to automatically.

% ssh 123.45.67.8

Enter your password as normal. Once logged in, let's check to see if you have an ssh directory.

% ls -la

If you see .ssh, cd into it. Otherwise mkdir .ssh and cd into it. Now we just need to add your key to your authorized_hosts file. This next command will either add to what you have already or create it if it doesn't exist.

% cat &gt;&gt; authorized_hosts

Now paste the key you copied above. Hit enter to get to a new line and then Ctrl-D to stop editing.

To make sure that there aren't any issues with permissions, make sure that only this user can read the file.

% chmod 600 authorized_hosts

Now let's make sure that this directory has similar permissions. Go back up a directory and fix the permissions

% cd ../
% chmod 700 .ssh

That should do it. Try opening up a new shell window and log in.

% ssh 123.45.67.8

That should get you in without having to enter a password.

Extra credit: I think it's helpful to make sure you have hosts mapped in your /etc/hosts file (Mac / Linux) if the IP or host you're using doesn't have a convenient name for you. Windows XP users, this is conveniently located in your c:\Windows\system32\drivers\etc\hosts file. Of course, other systems vary.

In that file, just make an entry like this

123.45.67.8          server5

And save it. On a Linux system you may need to restart the network to have it take effect.

% /etc/rc.d/init.d/network restart

Now you can just ssh to the name

% ssh server5

Need to troubleshoot? See what /var/log/secure says about it.

24
Apr

Using Subversion for Web Development

Hopefully by now you know what Subversion, aka SVN is. It's a version control system that keeps track of changes made to files like source code and documentation. It's similar to CVS, but with some major advantages. We've been using it at work for awhile, and I really like it. Changes don't get lost, we can easily keep track of released versions, and once we get around to implementing it SVN will tie into our bug tracking system.

We usually have two servers for a project, one as the development server, and the other a production server. We all have a working copy checked out on the development server. Using virtual hosts with Apache we all have our own sub domain. So for example on our dev server we'd have:

  • dan.ourproject.com
  • mike.ourproject.com
  • jc.ourproject.com

With each pointing to that developers working copy. We make our changes on the dev server as we're making the site, when we finish a task we check it in, and everyone does an update often to avoid conflicts.

When we are getting ready to push a release out to the production server we have to be careful since a lot of the time there are people using the site. We don't want to have errors pop up on the production server. To make sure it runs on that server as well as it did in our working copies, we have a staging area. It's on the same server as the production copy, but only we have access to it.

So we do an export to the staging area, click through the site and run through a checklist of things to check for and once we're sure it's running ok we copy that to the production area and it's live.

Since we want to keep track of the versions we push out to the production server, we give that release a version number, tag it in our Subversion repo, and update our project wiki.

This workflow has worked well for us and if we have a problem we can always roll back to a previous release. We can also use the Change Report feature of SmartSVN to do a kind of code review when others commit code. If we see something a little strange we can fix it, or if's completely crazy we can roll back quickly.

This is just how we do it, if you do it differently I'd love to hear about it so just leave a comment. In the future I'd also like to look into using Git in a similar way.