Roy's musings

I use a Linux VM for my development. I run my VM using VMWare Player . The VM obtains the IP address using a DHCP client run by NetworkManager (it is a part of vmware-tools suite). Every time the VMWare Player issues a new IP address, my /etc/resolv.conf file gets overwritten and I am left with only "localhost" as the search domain. Some of the machines that I connect to require fully qualified names to resolve. For e.g. I cannot look up host1 , instead I should look up host1.corpdomain.com . Hence I should make sure that the /etc/resolv.conf has the correct search directive after every DHCP lease. The NetworkManager first copies the /etc/dhcp/dhclient.conf file under  /var/run/nm-dhclient-eth0.conf and then adds a few extra directives of its own. So all that I had to do to fix the issue is to add the following two lines at the end of /etc/dhcp/dhclient.conf file: prepend domain-search "corpdomain.com"; prepend dhcp6.domain-search "corpdomain.com"

If you run "rails console" from within Emacs, you might have been annoyed by the output that contains control characters whenever you run a query. Like the one given below: 1.9.3-p125 :001 > BlogPost.all ^[[1m^[[36mBlogPost Load (0.2ms)^[[0m  ^[[1mSELECT "blog_posts".* FROM "blog_posts" ^[[0m I could not find a satisfactory solution for this anywhere. So I came up with the following solution that works fine for me. What this code does is to make use of "term" instead of "shell" to run the rails console. In term-mode you have better support for rendering these control chars. To make navigation and kill/yank easier, it switches to line-mode. The default mode is char-mode. You can switch between line-mode and char-mode using C-c C-j and C-c C-k respectively. Hope that helps.

This posting is a venting of my frustration. Never ever agree to have a table that doesn't have a primary key. There may be forces of nature that might attempt to convince you to have one, like: Your peers might say you don't need to perform an UPDATE in that table, now or ever You just need that table only for audit or reporting purposes We store data in that table just to go back and refer later which may never happen, so don't bother You may be under a gun where the big boss says "you don't need a primary key, because I say so!" For Christ's sake, don't yield to any of these things. I was in a limbo recently where I had to make use of one of the legacy tables that didn't have a primary key. This table was once thought as insignificant, but now has suddenly become an important table. The issue is that, for me to perform the operations that I want to perform, I need a primary key. The issue is that this monster table has more than

WARNING : Micro benchmarks are mostly deceiving, if you aren't careful about how to interpret the results. I leave it up to you to interpret these results. Recently I came across a problem when I had to convert an array of bytes into a long value. The obvious choice was for me to write a bytesToLong method that takes a byte array as an argument and returns a long value. When I dug around a little bit, I found that I could also make use of the ByteBuffer to wrap the bytes and  make use of the getLong () method to get the long value. I was curious to know if there is any performance benefits of going one way or the other. So I wrote a small micro benchmark, and here is the source code and the results: The results are given below: The columns are: number of iterations, time taken by the shift version, time taken by the ByteBuffer version, the ratio between the two times. As you can see, the ByteBuffer version is four times slower than the hand coded version. For my case, t