Capistrano: Host key verification failed

If you ever encounter the error message below when deploying using Capistrano, here's a solution for you.

 ** [12.12.12.12 :: err] Host key verification failed.
 ** [12.12.12.12 :: err] fatal: The remote end hung up unexpectedly
 ** [12.12.12.12 :: err] fetch-pack from 'git@github.com:abc/xyz.git' failed.

This seems to mean that the RSA key fingerprint needs to be verified (I'm not 100% sure on this). My solution is to do git clone on the server and confirm the fingerprint prompt, but there is a better approach. You can also do ssh git@github.com and confirm the prompt.

Creating Rails project from a local checkout of Rails repository

For my forgetful brain:

ruby /rails_repo/bin/rails new projectname --dev

Superstitious programming

Some programmers tend to think that something causes a problem without examining it further and confirming it. Then they just "fix" it or work around it, blaming it on the suspected cause.

For example, you're using an external library and you found that things went haywire. There are possible causes to this. First, the library causes it. How likely is it? You can look at the number of users (in other word, popularity) of the library. The more users, the less likely that it is the library's problem. Of course there's a remote possibility of you discovering a rare bug. But more likely, perhaps you're just not using the library right.

Here's a way of thinking that is also applicable in real life. Always check your assumption. Ensure that when you think something is causing the other, that it really is the case. Remove or change the cause and see if the effect changes or disappears. Only when you have that correlation that you can confidently say, "Yes, that's really the cause."

Having a knowledge of the scientific method will help greatly when doing this, and as a bonus, also when navigating life generally.

"Assumptions that aren't based on well-established facts are the bane of all projects." (from The Pragmatic Programmer by Andrew Hunt and David Thomas)

"One of the biggest differences between hobbyists and professional programmers is the difference that grows out of superstition into understanding." (from Code Complete, Second Edition by Steve McConnell)

The promise of chef, fulfilled

After using chef (a system configuration management) for more than a year, it is finally a working solution for me. The first time it ran from scratch without a hitch, it was quite a strange experience. Wait a second, everything works? It's magic!

It probably came about because it was run on Ubuntu Lucid, which is an LTS release and probably better supported by the cookbooks. Turned out the old cookbooks I was using were not up to task to deal with Lucid. So I might as well update it to the latest version and deal with many broken things, which required a lot of head scratching and whatever else needed scratching.

I still don't get the hang of the whole thing about the similar but different variables usage like node, params, and others (nor do I really care, it's not that important), but it works beautifully and that's good enough.

It's critical but please get it done as cheap as IMpossible

A nice quote to shove show to people that want softwares to be cheaply done:

What always amazes me is the companies who consider such a piece of software to be "critical" to their company -- but then try to get it done as cheaply as possible. (Chances are that more money was spent on the bathroom facilities in your office than you want to spend developing this program... yet your business success/failure hinges on whether this program is done correctly. Does that sound insane or what? I mean you have 5 employees, and EACH of those employees will cost you MULTIPLE TIMES MORE in a single year than you want/expect to spend developing this critical application -- an application that once completed, could easily make your employees much more efficient & your firm more productive, OR which alternately could cause needless frustration and even reduce their efficiency and productivity.)

The answer is it doesn't work. Those who offer low price are just bidding for any jobs, even the impossible (a very hard and so far unsolved problem quoted for $300-$1000) or ridiculous ones (a clone of eBay for under $500). The old adage still stands, price is a good indicator of goods.

Now, how do you find the excellent companies or programmers? That's a different ball game. Maybe on the next article, maybe.

How people use Google Maps

Watching people press the arrow buttons on Google Maps is painful, but that's the state of most Internet users. Watch around 15:30.



The funny thing is that the usability advices given in this video are not applied on the site itself.

Tomorrow would be better

A quote from Sergey Brin taken from Seth Godin's The Dip:

We knew that Google was going to get better every single day as we worked on it, and we knew that sooner or later, everyone was going to try it. So our feeling was that the later you tried it, the better it was for us because we'd make a better impression with better technology. So we were never in a big hurry to get you to use it today. Tomorrow would be better.

Doesn't mean that you'll never ship it!