Fubaredness Is Contagious

What we in IT call a “bad state” (as in “application ended up in a bad state and needed to be restared”) in economics is called “bad equilibrium.” Here is more on General Equilibrium theory.

Check this out - someone else is thinking along the same lines - http://elasticvapor.com/2008/05/virtual-private-cloud-vpc.html

Starting today, Elastic Server On Demand allows you to select Phusion Passenger (mod_rails for Apache) as a web container for your Rails 2 application. This  allows you to deploy a Rails app on Apache, the world’s most popular web server. Check it out at http://es.cohesiveft.com/site/rails2.

I just spent roughly 2 days trying to figure out why I could not start a rabbitmq broker on a Debian machine. To make a long story short, it was caused by snoopy. Snoopy fubars erlang. Solution is to remove snoopy (dpkg –purge snoopy, if you are on Debian).

Here are some symptoms that you might see:

• net_adm:names() returns {error,timeout} when you do it inside “erl -sname foo”
• if you run epmd -d -d -d -d -d in your terminal and launch erl -sname foo, you will get the registration (ALIVE2_REQ, ALIVE2_RESP) but there will be no more communication between epmd and foo no matter what you do, until you Ctrl+C from foo. Ideally, you should be able to see PORT2_REQ and PORT2_RESP when doing net_adm:ping.
• “erl -sname foo” and “erl -sname bar” on the same machine will not be able to ping each other with “net_adm:ping(’foo@host’).” or communicate with each other.
• inet:gethostbyname(”any.domain.name”) will return {error,timeout} for all domains, even for names in your /etc/hosts, when you do “erl -sname foo” but might work when you do just “erl” (not starting a distributed node).

RabbitMQ related symptoms:

• broker will not start using /etc/init.d/rabbitmq-server start
• rabbitmqctl status will always fail with badrpc error

Yesterday was 1 year since I started at CohesiveFT. New things this year (in no particular order):

• Mac. I got a Macbook Pro as my work laptop. Feels great every time I sit down to work, even though I am not a very demanding desktop user - browser, email, IM, rss reader for non-public feeds, terminal, occasional Office document work, occasional PDF to read. And most importantly - VMware Fusion to run my Linux development box.
• Debian. Our paths surprisingly have not crossed until this year. Probably because I lost interest in low level OS maintenance a long time ago and was not actively looking for a new distro to try (my home server is running Red Hat Linux 7.0 with everything important upgraded to later versions - I don’t use RPMs and prefer GNU Stow for package management). Overall, I can’t say I dislike it. apt-get is nice. And deb packaging format imho is superior to rpm (writing standalone rules files using GNU make is easier than writing shell within spec files). Like rpm however, apt-get does not handle edge cases, when I don’t want computer to think it’s smarter than me.
• Ruby. The second attempt to learn ruby was successful. Ruby now joined Python on the list of my favorite languages. They are both equally great for doing all kinds of development, provided your project doesn’t use both at the same time - each has its own patterns and I personally find it somewhat hard to adjust when I try to write in both in parallel. I am also happy that Ruby joined Python on my list, not displaced it (several years back, Python did displace Perl on my list) - so I am kind of bi-lingual now, which mimics my real life situation with real languages.
• Rails. Yes, Ruby on Rails and Django on Python are my favorites now.
• RabbitMQ. This is a big one. For quite some time I have been searching for a highly available messaging bus as a holy grail of building and operating a scalable system. I think I found what I was looking for in RabbitMQ and its implementation of AMQP standard.

Elastic Server On Demand is built with each of these somehow tied to it behind the scenes. Shaping up very good so far…

Google released their App Engine yesterday. Very cool python goodness, supposedly with access to their BigTable and GFS and supposedly free for use up to a certain limit.

In the meantime, Google engineers (or was it designers?) came up with a new type of aircraft. You probably have heard about flying wings, but it looks to me like the concept of “a flying engine” has been introduced for the first time. And it’s a very simple design too - you take a jet engine, and attach wings and a tail to it. I am not a specialist, but I don’t see a reason why it won’t fly.

Seriously though, Google definitely has my respect for doing things like this.

What is the most important phase of a software development project? Some people might say planning, others might think it’s QA. Probably nobody will say actually doing it (aka development), as that would be too boring.

I think all these answers are wrong. In my opinion, the most important phase of a software development project is… coming up with a name for the project. My experience indicates that a good name can increase developers’ fun (and consequently productivity) by 30-70%. A great name can lead to up to 100% increase in fun and productivity. These numbers are not very scientific, but they are very real.

Consider difference in motivation when one works on a project named RLASI (which might stand for Reduced Latency Algorithm for Sending Information) and another works on project Milton (in honor of Milton Waddams, a guy with red stapler, from Office Space). Milton is actually one of my most beloved project names and it was an actual project, which I worked on in the past.

If you are starting something new, consider spending some time to find a great name for it - remember that it is 50% of the project’s success!

http://damienkatz.net/2008/04/couchdb_language_change.html

Or is it not a joke?…

Virtualization can also serve as software delivery medium. You know, like floppies, CDs and DVDs. You do sacrifice space and some CPU power, but get a controlled installation environment in exchange. This comes handy if a product you are trying to distribute takes some effort and knowledge to install correctly.

To illustrate this concept, I am going to give an example. Let’s say you are considering a Getting Things Done technique and you are looking at tracks. Tracks is a Ruby on Rails web-based application, and if you are not familiar with this technology, it might take you some time to get all bits and pieces together so that you can see tracks login prompt in your browser. Instead, consider using this elastic server. It’s an image of a VMware virtual machine, which you can simply download and run in VMware Player. And there is your tracks application inside - it is already configured with a database and comes with all necessary web containers to run it.

I won’t be very surprised if more applications in the future will be offered for download in this format.

Almost everybody is familiar with better resource utilization as one of the benefits of virtualization. You can reduce the physical footprint (have fewer physical pieces of hardware) and still run the same number of “standalone” servers as before virtualization.

I think however that there is another huge benefit that doesn’t get as much attention - virtualization allows you to eliminate physical human labor component from the process of provisioning, moving or decommissioning your servers (once the original hardware, where VMs will be running, is set up). What does it take to provision a new virtual server? Several commands - and you are done. What does it take to move a virtual server? Again, several commands - no need to hire a moving company. What does it take to decommission a virtual server? You guessed it - several commands. And all these commands can be put together into a script or a GUI, and the entire process of ordering hardware, receiving it, unpacking it, racking it, taking power to it (you also need to check if that power is available, by the way), setting up cooling for it, connecting it (cables are so old fashioned!) and then finally turning it on can be encapsulated in a relatively small piece of software.