Author Archive for jjordan

19
Nov

building a quiet / silent PC

By jjordan 0 Comments
Categories: Technology

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.

29
May

Managing Legacy Code While Remaining Somewhat Sane

By jjordan 0 Comments
Categories: PHP, Technology and Web Strategy

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.