Sharing Xvnc sessions

We're a pretty diverse group at the RDU erlouge even though we haven't reached the point where we actually need a formal venue for our meetups. We're still bumming it out in cafes with free WiFi. Likewise we don't have a projector or anything for presenting our code. The easiest and most cross platform way to achieve pretty much the same result as a projector was to use VNC.

Here's what I do on Fedora 7:
#'s denotes root shell
$ means your normal unprivileged user

# yum install vnc-server vnc
$ vncserver :1 -depth 24 -geometry 1024x768 -AlwaysShared

Most of those arguments do not need any further explanation so I'll be brief. That command starts a server on display :1 (port 5901) and sets all the connections to shared. That's a nice flag to set (read the Xvnc manpage for more options) since we were having problems with people forgetting to specify a shared connection on the client side and thus disconnecting everything.

VNC is not the most efficient remote desktop protocol but it gets the job done. If a large group of people are connecting and bandwidth is limited you may try a few things to reduce the amount of bits that have to fly around. I like to use a lighter weight window manager. You can edit your ~/.vnc/xstartup and put in something like this:

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
fluxbox &

Obviously the first to lines are boilerplate.

If you are ever in a situation where you don't feel like the wireless network you are on is safe I would recommend tunneling your VNC traffic through SSH. I don't think any VNC servers advertise their security and the traffic definitely isn't encrypted. Just give everyone who you want allow access to your machine an account then have them log in as follows:

$ ssh -N -T -L 5901:[VNC server ip address]:5901 &

That creates the tunnel. Then just tell the users to connect to their local point (which forwards to the host)

$ vncviewer -ViewOnly -Shared localhost:5901

NOTE: The '-Shared' option is only really needed if you are connecting to a server that doesn't enforce sharing.

Using git to cope with crazed svn repositories

If you ever find yourself working with a gnarly svn repo you may want to give git-svn a try. You will be able to do your collaboration with git and then dump your changes back to svn. The truth is many large projects are not yet ready to ditch svn completely and there may exist tooling already for svn that your team needs (and doesn't have time to rewrite). For this reason exists git-svn.

Initialize your svn aware git repository:
mkdir mywork; cd mywork
git svn init http://workserver.com/path/to/the/code/you/care/about
git svn fetch -r [revision you care about]

The reason I'm encouraging you to only grab the code you care about is because if you are working with a truly crazed svn repository things can get unnecessarily complex. When I did a full svn import of the root on the svn repo where I work it took over 3 days to finish on a good connection. The truth is there was only one branch that I really cared about.

If you are working on a more complex project and having to deal with other groups that are using svn you may have to do a slightly more sophisticated initialization:

git svn init https://workserver.com -T path/to/the/repo/you/want/to/commit/to -b dir/that/has/branches/of/other/teams

The main thing to understand is that git-svn provides two-way communication between git and only one branch in svn. The path you specify for '-T' needs to be that one branch. It doesn't actually need to be the real trunk from svn's point on view--it's just the particular path you care about.

Once you have initialized your repo you will need to do some fetching. Again, you don't want to fetch more than you need. One thing that was not intuitive for me was how the fetch works. I immediately tried to check the latest revision and nothing was getting pulled down. The trick is to pull down revision that actually have commits. Use 'svn info' to find out the last revision where a particular path was changed. You will need to do this for your 'trunk' and any other branch you care about.

Erlang Bit Syntax II

Since my previous post on the subject was so lame you should take a look at a better article on the subject.

Erlang bit syntax

I've been hacking around with Erlang off and on the last few weeks because I think it will be immediately useful for a few problems I'd like to solve. When people are first exposed to Erlang they are often impressed by its support for massive concurrency and crazy "assign once" variables. Aside from that I've found Erlang's bit syntax to be a pleasant surprise.

What would someone want to do with a bunch of nasty bits? Well the example in the PragProg book shows how to create a SHOUTcast server for streaming MP3s. Using the bit syntax you can elegantly chop up the binary blobs to read the metadata.

Here's an (unrelated) example taken from erlange.se:

DgramSize = size(Dgram),
case Dgram of
<<?IP_VERSION:4, HLen:4, SrvcType:8, TotLen:16,
ID:16, Flgs:3, FragOff:13,
TTL:8, Proto:8, HdrChkSum:16,
SrcIP:32,
DestIP:32, RestDgram/binary>> when HLen >= 5, 4*HLen =< DgramSize ->
OptsLen = 4*(HLen - ?IP_MIN_HDR_LEN),
<<Opts:OptsLen/binary,Data/binary>> = RestDgram,
...
end.



I appologize for the lack of indentation. The method I have used previously for escaping code didn't like Erlang's use of '<<' instead of blogger's PRE tag. It's that specific syntax, however, that is used for Erlang's bit packing and unpacking. Equivalent code written in most languages would get a little nasty. If you would like to see documentation on the syntax be sure to check out this site.

Ruby closure shootout

Ok, so I too have been bitten by the arity differences between Proc.new and lambda so a few months ago I tried to find the Ruby spec to get a better understand. It was then I came to realize that the only true Ruby spec is defined by the C implementation. While such a spec may allow for rapid improvements to the language it comes at the cost of warts--and Ruby is not without it's fair share. I stumbled across this site today that is possibly the best 'research' compiled on Ruby's closures that I have seen to date. It does a great job of exposing Ruby's warts while at the same time demonstrating the power of closures in Ruby.

The article (it's really just a script you can feed the interpreter!) was encouraging in that it showed me I really should spend a little time in the MRI perusing the source for these sorts of tidbits. I can really appreciate all the work that the groups heading up the various Ruby implementations are doing to formalize a Ruby spec.

Black-boxing Google Translate

It seems like the more I watch the Mountain West sessions the more I stumble across solutions to itches I've had recently. Just yesterday at work I was hacking with a friend on a simple CLI for Google Translate and we were struggling a bit getting 'curb' to do exactly what we wanted. After watching James Britt's session on Black-boxing with Ruby I realized that mechanize would probably be a better choice for what we were trying to do. 10 Minutes later:

require 'rubygems'
require 'mechanize'

agent = WWW::Mechanize.new
agent.user_agent_alias = 'Linux Mozilla'
page = agent.get("http://translate.google.com/translate_t?langpair=en|#{ARGV.shift}")
translate_form = page.forms[0]
translate_form.text = ARGV.join(' ')
translate_form.ie = "UTF8"
translate_form.hl = "en"
results = agent.submit(translate_form)
puts Hpricot(results.body).search("//div[@id='result_box']")[0].to_plain_text


# Examples
ruby translate.rb zh-CN "I love to eat tacos on Tuesdays" => 我爱吃tacos周二
ruby translate.rb es "I love to eat tacos on Tuesdays" => Amo comer el tacos el martes

While these may not be accurate translations, this script definitely works for testing out i18n functionality until the real translations come in. If and whenever Google decides to release an API for their site it will be painless to throw this script away.

Programming Rule #42

"Every problem has already been solved. It is Open Source. And it is the first result on Google"
--Ara T. Howard (I don't know if he's actually the one who said that first, someone correct me if I'm wrong)

I spent some time this weekend watching the Mountain West Ruby Conf's videos and I must say what I've seen so far has been great (now I'm really exited about the Ruby Hoedown). The session on Ruby Queue is going to be immediately useful to me in my effort to distribute selenium tests over a linux cluster. It's actually quite amazing that the solution I had cooked up approached the task of clustering from almost the same way--simply using a queue to feed shell tasks to an array of nodes. It's quite ironic in light of Ara's quote on Rule #42 and his project that basically sent mine to the grave.

Luckily my solution was only the product of a few weeks of work off and on. In < style="font-weight: bold;">it's that simple. So, I'm going to take my project off rubyforge and stick it somewhere else. The one thing that I really need that RQ doesn't handle is clustering with Windows machines. Since I need to run tests with IE I'll have to spend some time to see if this is something that could be worked into RQ. I have absolutely zero experience with Windows and NFS so I don't have any idea how much work would be needed at this point.