Category: Brain Dumps

Kill-a-Watt Alternative For Measuring Energy Consumption

Kill-A-Watt Hardware enthusiasts know that Kill-A-Watt is the device to use for checking power consumption. A lot of people/sites use this device, from blogger Jeff Atwood to hardware site HardOCP.

Unfortunately for us here living in the Philippines, Kill-A-Watt is out of the question. Not only is it difficult to import electronic devices without paying hefty customs fees, one should also take note that there are no Kill-A-Watt models which support 220V yet. (No, don’t tell me the obvious solution with a 220 to 110 transformer and a 110 to 220 transformer. Just… don’t.)

Just when I thought there was no other way to determine the power consumption of my computer aside from buying a bulky submeter, I stumbled upon a thread in TipidPC.com where a guy suggested an alternative to Kill-A-Watt.

Continue reading “Kill-a-Watt Alternative For Measuring Energy Consumption”

Fitness and Personal Finance

I find it odd that I failed to mention the relationship between Finance and Fitness in last night’s update of About This Site. It’s odd in the sense that these two seemingly unrelated categories share the same basic principles.

The most important thing! Spend less than you earn! The most basic principle for personal finance is Spend Less, Earn More. For physical fitness, it’s Eat Less, Exercise More.

The similarities don’t stop there. Both basic principles are simple yet difficult to apply in real life. This often results in people getting into get-rich-quick scams (for finance) or trying out fad diets (for fitness) in the hopes of skipping the hard parts. However, time and time again, these two principles are often the only reliable means for people to reach their goals in personal finance and physical fitness.

Speaking about goals, both categories also require you to define realistic goals. Not only does this prevent you from the inevitable disappointment you fail to reach your goal, this also forces you to assess your situation and your target. Maybe your situation is more dire than you expected, or maybe you really don’t need to worry about your situation; either way, finding your starting point and your goal in both personal finance and physical fitness will allow you to determine the correct steps needed to get you where you need to go.

Even on the micro-level, there are still similarities between the two categories. Logging of all expenses and calorie counting are both very tedious tasks and yet they are among the most reliable ways for you to determine where you can trim off excess expenses/calories. Heck, these two tasks are so similar that you could probably log your calorie intake in a personal expenses logging software and vice-versa!

Another similarity is the importance of changing the way you think. You should change your perception about yourself by taking reality into account e.g. ignore how the media portrays “fitness”, you really don’t need to buy that gadget no matter how shiny it looks, etc. You should also understand that being both fit and financially stable requires a long term change in your lifestyle and not just a temporary one.

Of course, there are differences between fitness and finance, but my goal for this post is just to relate the two. You can’t blame me for not pointing the differences out. :P

(picture source: The Simple Dollar)

NIH

“Not Invented Here” (NIH) is another fundamental concept in that one must understand when entering software development.

There are a lot of issues and concepts related to NIH (as seen in the WikiWikiWeb page) so for this post, I will only cover the basic concepts in this post.

Whenever possible, steal code.
– Tom Duff, Bell Labs, quoted in Programming Pearls

 

“Not Invented Here” (NIH) is another fundamental concept in that one must understand when entering software development. NIH describes the tendency of an individual or organization to refuse using an available solution (say, open source software) just because it was not invented by them (hence, not invented here).

There are a lot of issues and concepts related to NIH (as seen in the WikiWikiWeb page) so I’ll only cover the basic concepts in this post.

—

The first time I read about NIH is in Alistair Cockburn’s Agile Software Development: The Cooperative Game. There is something about Cockburn’s (pronounced Co-burn -___-) approach to NIH that separates it from the other perceptions of NIH. Unlike those who add “syndrome” at the end of NIH, he treats NIH not as a disease but as a cultural imperative. That is, people and organizations practice NIH because their culture trained them to do so from an early age.

From earliest school days, students are instructed not to copy other people’s work, to not help each other, and to be as original as possible in all but rote memory acts. They are given positive marks for originality and punished for using other people’s solutions. (Recently, a fourth grade teacher told her students not to call each other to discuss homework problems—not even to ask for which problems to do!).

Through the university level, assignments are designed to produce grades for individual work, not for teamwork. This reaches a culmination in the Ph.D. dissertation, where originality is a core requirement.

Somewhere in these years of schooling, some people join the profession of “programmer,” a person whose job is to program and who advances in the profession by writing harder and more uniquely original programs.

Under these circumstances, it is hardly surprising that the people internalize the Invent-Here-Now Imperative.

If you’re unfamiliar with software development, you might ask:

So what’s the problem with striving for originality?

For software engineers, the answer is simple:

It’s usually a waste of time and resources.

Modern software development is different from school. When an English teacher asks you to write a short story and you copy one off the net, you’re a plagiarist. Depending on your educational institution, you could be expelled for that act.

On the other hand, if a client wants you to set up a CMS for his company and you use Joomla, Drupal, or whatever open source CMS for it, you’re a pragmatist: you just saved thousands of hours of development and testing when compared to writing one from scratch.

—

That said, I’d like to point out two things related to NIH:

First off, it does not mean that “code reuse is always good” and “NIH is always bad”. In fact, Cockburn’s reason why he mentioned NIH in the book is not to condemn it outright, but to show us the importance of researching over inventing.

This means that, when faced with a programming task, a software developer must first research for the simplest solution available. It may be in the form of a built in function or class in her framework, or it may even be someone else’s code. A developer would only code everything from scratch is if the task is trivial and disposable, or if the effort of researching (or modifying, if a third party module is used) in both the short and long term is larger than coding from scratch.

—

The other implication of NIH is that it exposes the fact that traditional teaching methods (i.e. those used in computer science courses in college) is not conducive to producing quality software developers needed by the industry.

I would agree that computer science should program their own MPs instead of copying from their classmates (speaking as the-guy-who-never-copied-code-from-anyone, I personally found this behavior insulting back in college). But the problem here is that throughout a computer science student’s life in college, the student is taught to value originality as they are valued in other courses.

By adopting an NIH culture, computer classes continually promote values that are considered detrimental in software teams: independence instead of teamwork, pride over one’s own work instead of open mindedness towards other solutions, writing throwaway code instead of writing maintainable code, etc.

Now you have an idea of what I have to deal with when I was a trainer for my previous company. :P

Usability and The Reservoir of Goodwill

As much as I’d like to go back to talking about management and software engineering (to scare away the people who stumbled upon my site because of the incoming links), DDB “damage control” people decided to submit their entire freaking FAQ as comments to two of my posts.

Now that gives me a good reason to continue talking about their site while bridging the gap between this issue and software engineering. :D

—

Practically the main reason why people are skeptical about the Ako Mismo website is its lack of usability.

Don't Make Me Think Now, when we talk about usability, the first reference book that would come into mind for many web developers is Steve Krug’s Don’t Make Me Think. The book covers the main issues on usability faced by websites and does this by being clear and non-technical and by using pretty pictures. In other words, the book’s a perfect for people interested in improving their site’s usability but would be intimidated by Jakob Nielsen’s useit.com or Edward Tufte’s books.

As with most decent software engineering or web design books, you probably won’t find this book in local stores. A former colleague told me that Fully Booked carries this book sometimes though I haven’t verified it myself. You could try making a special order from local bookstores for it but that would lead us back to the book blockade thingy. =/

Fortunately, there are free chapters of the book available on the net. One of those chapters is available in the Adobe Design Center: Usability as common courtesy.

Usability is about building clarity into Web sites: making sure that users can understand what it is they’re looking at — and how to use it — without undue effort. Is it clear to people? Do they “get it”?

But there’s another important component to web usability: doing the right thing — being considerate of the user. Besides “Is my site clear?” you also need to be asking, “Does my site behave like a mensch?”

Steve Krug starts the chapter with a story about how, after being concerned that a union strike will affect his flight, he visited an airline’s web site to find more information about the strike. Long story short, the web site did not contain any relevant information about the issue on hand and this frustrated him.

He then introduces the concept of a “reservoir of goodwill” to explain how it turned out that way. In the concept, he tells us that everyone has a reservoir of goodwill when we visit websites. When we find what we are looking for or anything similarly interesting, that reservoir fills up. Similarly, when we don’t find what we are looking for or if we see something that disgusts us, the goodwill level goes down. If for some reason that reservoir becomes empty in the course of our visit, we leave that site in disgust/frustration.

—

Back to Ako Mismo, the reservoir of goodwill easily explains why people reacted that way to the Ako Mismo site.

A lot of people entered the site with a high amount of goodwill in their reservoirs. A good number of them left when they couldn’t find any information about the dog tags.

Others’ reservoirs didn’t last that long. A part of the article actually gives the exact same reason why:

Sometimes a single mistake can empty it. For instance, just opening up a registration form with tons of fields may be enough to cause some people’s reserve to plunge instantly to zero.
I'm out of here

—

As we can see from these examples, usability may be an often overlooked aspect of a website, but it can spell the difference between a successful sale and a lynch mob.

Unfortunately, usability is not my area of expertise so I couldn’t provide you with a comprehensive list of usability links. All I have is a link to another chapter of Don’t Make Me Think and the aforementioned useit.com site.