Blog Action Day: Conserving Energy

A while back I decided that I would take part in the Blog Action Day and write about an environmental issue that meant something to me. Well, I've been busy moving to Texas and starting a new job so I haven't had much time to think about it until now. As I've always been very interested in computers and technology I've noticed a growing trend thats just now being dealt with as a problem. That problem is inefficient design in computers and electronics causing them to consume much more power than they should be. I've never understood why you wouldn't want to design devices with efficiency in mind, but it has often been the case where efficiency is thrown by the wayside. So, for my Blog Action Day pledge, I'm going to spend some time looking at ways you can improve your computer's energy efficiency.

Get an 80+ Power supply

One of the biggest wastes of electricity on the desktop comes from the power supply. Many PC power supplies run at around 60% - 72% efficiency with the rest being dissipated as heat. Since energy costs are very high in many places, running your computer 24/7 can have a noticeable impact on your power bill. By switching to an 80+ approved power supply, your guaranteed to have at least 80% efficiency at 20%, 50%, and 100% power supply usage. This is great news for anyone running their computer as a home server, router, etc... as you can have significant energy usage reductions and lighten up that power bill a little bit.

On a side note...

While reading Jeff Atwood's Coding Horror blog I noticed a very interesting point he made. He makes the point in choosing the right wattage for your power supply. All too often people put in the equivalent of a 500 horsepower engine just because they 'might' need it some day. The problem with that lies in the design of a power supply. They are notoriously inefficient at low power consumption, so while your computer is idling, the power supply is eating the most power it can. So when you are buying your 80+ power supply, please consider how much your rig will need and buy accordingly!

Get an LCD monitor
Many people stare all day at the largest energy monger on their computers. Thats right, your monitor can be voracious consumer of electricity. If you own a CRT monitor, its time to ditch that heavy thing and move to the LCD age. LCD monitors consume roughly one third of the energy a CRT consumes [1]. There are also many other environmental issues you are escaping when switching over to LCD. For instance, CRT monitors have a high amount of lead[2] in them making them difficult to dispose of as well as exposing many people to the effects of lead if disposed of improperly. LCD's have many advantages over CRT's (they weigh so much less!) that its time you consider getting rid of that old CRT (properly, of course) and investing in a shiny new LCD monitor.

Finally....

Turn on your computers power saving features!
This is a a very simple, very free way to help conserve energy. Simply open up your power settings and pick a few reasonable settings. Have it turn your monitor off after so much inactive time, spin down those disks, put it into hibernate or suspend, just turn the power saving features on!

I missed the search train?

I just noticed that Google Reader has the long overdue search feature. When did this happen? I must have missed it while I was travelling to Austin I suppose. Either way, I am extremely happy to see this feature finally implemented. Let us all rejoice in the Googly searching goodness that has now been set free on Google Reader. Yay!

Compiz Fusion Time

I got bored a couple of days ago and I installed Compiz Fusion for the first time. I must say that is really great software and even in its early alpha phases it is very impressive. It looks like much of Beryl and its settings manager were used for Compiz Fusion's settings manager as well as many if the effects. A couple of changes though, the cube now can have a reflection as well as a new way to move through the desktops using ctr+alt+down. There are many other changes they have made to Compiz Fusion but I'm too lazy to write about them right now so enjoy my little video I made of my desktop.

Ubuntu Fun

I just recently installed Ubuntu Feisty Fawn on my T60 again and I have to say I'm loving it. Most everything is running smoothly and I have most things I need installed. It makes me happy to see that the Sun JDK 6 is in the main repository along with Netbeans, Java DB, and Glassfish. Well, Netbeans and Java DB are sort of in the repository, you still have to download Netbeans and Java DB before you can actually install them.

Other than that my experience with Feisty has been going quite well. I have managed to set most everything set up easily and without any major problems. I even have managed to install IBM Rational without messing up my laptop. The only thing I haven't set up yet is XGL. There are a couple reasons for my delay there. First, Compiz Fusion, the merge of Beryl and Compiz is still in an alpha phase and second, I have always had problems getting the ATI driver working properly and getting all the features I need working well with Compiz. I probably will get to installing it later though, because of this video I saw.

Bus Factor = 1

I haven't been as prolific on this blog as I had hoped a few months ago, but thats how life goes. You get busy with school and you don't have time to write. Since I have a few minutes I thought I would write quickly about something I learned at the end of this quarter at Neumont.

Always bus-proof your projects.

Many of you developers know what I'm talking about, but I'll explain what I mean by "bus-proof." Think about a development project that you have been on for a moment. If someone on your team was hit by a bus, would the project be able to continue? How many people would have to be hit by a bus until the project couldn't continue? Thats basically the entire concept of the bus factor of a project.

I learned the hard way this quarter that you should always bus-proof your projects. The project I was working on this quarter had a bus factor of 1. Can you guess what happened? *dramatic pause* He got hit by a bus. OK, so he didn't really get hit by a bus but he wasn't able to work on the project anymore or even help us out with any questions we had.

After he got hit by the bus we were basically SOL after that.

Although the project ended up being a complete disaster, I did learn something from this experience. I found that there are a couple of different ways that you can help to bus-proof your project

Always comment your code.
If your code isn't commented then the next set of developers behind you will have no clue what you were trying to do. Always comment anything that you had to hack around or make a decision on why you wrote the code the way you did. This way no one has to guess your intentions in the code.

Document your decisions
You are going to make many design decisions in your project that isn't going to end up as a comment in some source code.It makes life much easier if you just document why you decided to use pattern x over pattern y or why you chose to use Guice over Spring. You get the idea.

Have a roadmap
One thing that I have found is very useful to a project that is going to be around for any amount of time is the roadmap. By documenting what you plan on doing with the project and give it direction, it is much easier for new developers to see where you have been and where you are going.

Limit the scope of your work
One of the easiest ways to give your project a bus factor is to allow one person to have their hands in the whole project. It is easy to see why this is a problem because if only one person has a grasp of the whole project Murphy's Law is going to take its toll. There are a couple of solutions I see to this problem though. First you have more than one person with an intimate knowledge of the project and second... DOCUMENT YOUR PROJECT. (See the tips above)

As you can see, these are just a couple of ways you can help bus-proof your project. As a good programmer you should always be looking for different ways to keep the project's bus factor down. I definitely learned the value of keeping the bus-factor down at the end of this quarter.

SCP Fun

Just a little thing I found out. To copy a directory with SCP just use the -r flag. (r for recursive duh!)

Automate This - What to Automate

Automation

Automate This! is a series of posts about my interest in software development, automation. I'm going to start off by talking about what you can automate and what should be automated on software development projects. Since automation can be useful in more than just software development, you can rest assured I'll rant about anything else you can automate in later posts. But, enough of that little side note, lets get back to what I was talking about, automation. I want you to think back about the projects you have been on. I know it can be scary to think about some of the things you have worked on, but just keep thinking.... OK, now that you have a few projects in mind, how many of them had automated some aspect of the project. The build perhaps, and unit tests (if you actually have unit
tests!) probably are the first things that come to mind, but is there anything else your project automated? If you have had the experience I've had so far, then that is probably about all that comes to your mind.

Where to now?

So where do we go from there? What else can be automated? Is automation really that useful? I know when I first started getting into automation, these were some of the first questions that came to my mind. To answer your questions, yes, automation really is that important. Who really wants to have to remember to run the test suite, or start the build before you leave work? I know I don't, doing those by hand is very error prone. Not to mention the fact that if I had to remember to run the tests, they never would be run! As for what else can be automated, that one depends on what your project needs to have done in a consistent, repeatable manner. Making sure documentation is updated and packaged is a great process to automate, deploying your application is another great automation task. Do you have any code that is generated? Automate it!

As you can see, there really are many tasks in a project that can be automated. Since each project is different, you are going to have changing needs for what you automate. To deal with the changes from project to project, I keep a simple guideline as to what should be automated on any project I work on. If it needs to be repeated, generated, and done consistently, it should be automated.

Some Things Should Always Be Automated

Otherwise, it's really up to you on what you can and can't automate on a project. Although you may have varying aspects of your project to automate, I have found there usually is a core set of things that you should always automate
in a project. My list is pretty short, so read it

Code Generation - Anything that needs to be generated (SQL Scripts,
Web Service Skeletons, etc...)
Tests - Any tests you have, Unit, Regression, Integration, etc...
Documentation - BOTH Developer Documentation (such as Javadocs) AND
User Documentation
Builds - I don't care what you use, just automate it!
Packaging and Deployment - Usually an extension of the build, you
should automate putting the project together as you would release it to the public. If its a web application, learn how to automate its deployment to the web server and you will
thank yourself later.

Go Forth and Learn

OK, well now that we have our introduction to project automation, go out and learn more about it! Look through other projects code and learn how they handle automation and definitely learn how to use a build tool such as Ant, the ubiquitous Make, or the trendy Rake. In my next post, I'll introduce you to these three build tools and show how they are used on different projects. Until then, have fun learning your build system!

Sam

The Pragmatic Programmer

I just recently picked up a copy of The Pragmatic Programmer: From Journeyman to Master and I must say that the book is awesome. This book has easily become one of the most important books that I have read since I started attending Neumont. If you haven't read this book and you are in software development, do yourself a favor and go buy this book right now. The book directly addresses the problems many developers face early on in their careers.

OK, so now you are wondering whats the big deal, right?
right.

There are many reasons why I think this book is such a big deal. This book is written to help you grow as a developer and as a team member, not to solve a technical problem. This book isn't a solution to that pesky EJB bug you are having, or how the Proxy pattern can help your project. Instead it focuses on the facets of programming and working on a team, from learning how an editor and version control, to documentation, testing automation, and pragmatic teams. These are just a few of the sections in The Pragmatic Programmer, once I read the book again I plan on writing a more in-depth review. In closing, go out and read the book now. It will change your way of thinking drastically.

Cheers,
Sam