The most troublesome is the namespace that might be included. To make everything independent from 3rd party different namespaces nokogiri allows to remove the namespaces before the parsing begins.

doc = Nokogiri::XML(open(file))
doc.remove_namespaces!

Split testing is a marketing research tool, where you test your assumption with your users by presenting them different approach. What you might want to measure would be user reaction to it. For example you might want to Test how your signup page is perceived by your users. You can test how many saw it, and how many of them did sign up. You can try different content, style, backgrounds. There are many possibilities to do that. It is up to you to decide what assumption you would like to test and what would be the measure.

With Ruby on Rails application we have variety of tools that allow us do an A/B testing. One of it is a gem with obvious name ‘split’ which can be found on github. It does let you create simple campaigns where you are able to test different behaviors with your user base. It has been recently featured on railscasts.com which is one of primary sources for Ruby on Rails developers to stay on the edge.

Contact your development team to start split testing as soon as possible. You might want to know if you are building products people want, or you might need to adjust your selling strategy.

It is more often met to build a prototype with ruby on rails just over two days to talk about it with potential investors, share ideas with friends and prepare for some real work to be done. I dare to say it become a springboard for a project. Of course you need to find devoted and skilled developers to share your idea, walk in your shoes and think of your business while eating…
It is not that seldom anymore as more and more development shops switch to more personalized approach to the client. The excitement with building an application together with a client is  put higher that just charging a lot of money and stay out of a trouble and learning from mistakes. It is bringing businesses together. Is there anything better?

Recently on the project I have run into a requirement of delivering the results to the client browser in an instant that some delayed job has been completed.
The architecture itself was pretty complex and the job sometimes took more than 3 seconds.
Polling was taking too much of the resources and the delay was still high.

The decision was to switch to the html5 websockets.

To send the message to the listening service there is a nice implementation of ruby websocket client

https://github.com/gimite/web-socket-ruby

Then in the resque worker I was able to use following

WebSocket.new("ws://example.com:9090/").send("expected message")

Now it does not matter it is the Controller, model or resque worker.

The websocket broadcaster:

require 'em-websocket'

EventMachine.run {
  @channel = EM::Channel.new
  EventMachine::WebSocket.start(:host => "0.0.0.0", :port => 9090) do |ws|
    ws.onopen {
      sid = @channel.subscribe { |msg| ws.send msg }

      ws.onmessage { |msg|
        @channel.push msg
      }

      ws.onclose {
        @channel.unsubscribe(sid)
      }
    }
  end
}

It works like a hub so it repeats message to everyone connected listener.

Tricky part

The most tricky here was how to run the websocket service on production machine.

I gave a ‘daemons‘ gem a try.

#!/usr/bin/env ruby

APP_ROOT = File.expand_path(File.join(File.dirname(__FILE__) + '/..'))
APP_ENV =  ENV["APP_ENV"] || "development"
$LOAD_PATH.unshift(APP_ROOT + '/lib') unless $LOAD_PATH.include?(APP_ROOT + '/lib')

require 'rubygems'
require 'daemons'

def stop_and_exit
  # Do something useful here....
  exit 0
end

Signal.trap('INT') { stop_and_exit }
Signal.trap('TERM'){ stop_and_exit }

options = {
  :app_name => 'Websocket',
  :multiple => false,
  :log_output => true,
  :dir_mode => :normal,
  :dir => File.join(APP_ROOT, 'log')
}
Daemons.run(File.join(APP_ROOT, 'websocket.rb'), options)

Receiving the message (in Javascript):

var socket = new MozWebSocket("ws://example.com:9090);
socket.onopen = function(){
  // something can be done here
};
socket.onmessage = function(event){
  if(event.data.indexOf("expected message") != -1){
    // do the call since job has finished and results are ready to be displayed

    // close if connection is not needed anymore
    socket.close();
  }
};

Receiving the message is the easiest task. This js code just wait for “expected message” to be received, then some work can be done.

Conclusion

Eventmachine and HTML5 Websockets create nice glue to scattered architecture when latency is the key.

I was recently given a very complicated task:  installing a highly dependent project in a complex environment ( one of 30 different configurable environments) without VMs or root privledges.   Now, to complicate things, image that you don’t have any guidance, not one thing written.   All you have is a poorly documented configuration file known in Maven as the POM, 10 sets of property files, and a git directory.   To make matters even worse if possible, you have never touched this code and you can’t write any of it.  You can only compile, build, configure, install, and troubleshoot.   Oh, the developers who wrote the code are in remote offices  and you are installing this complex software in a remote network, without access to the internet.  Number of external services requires for integration = 10+ rest based with encrypted services.

The challenge is daunting.

These are the steps that I took to overcome:

1. Procrastinate.  That’s right, I said it.   I solved a few other issues knowing that this task was looming   Is this healthy?  I am not sure, but this posting is part of that procrastination.  Who knows, maybe someone will cancel the task and I wouldn’t have to do it , right?  Wrong.

2.  Control It  -  Create a teaching aid to teach someone else.  When you teach something, you must learn the material better.  It it only through teaching that you really learn.  I turn to documentation as not only a helper for those that follow, but more as a motivator.    Face it, compiling and configuring someone else’s work is  just about the worst job out there.  When you think of the benefits and value you have by building training material, just about any task is bearable.   If you have control, you are going to be much happier.

3.  Acknowldge your Pain – When doing something very difficult, remind yourself… it is going to suck at first, bad.  Then,  it will get easier.   It always does, provided you have the prerequisite knowledge to complete the task.  If you find yourself without the basic fundamentals in place,  you will always struggle until your foundation is correct.  You are human and this cycle is natural.  I acknowledge the pain by swearing at my computer some times, if you choose this option, make sure you do it quietly. :- )

4. Don’t give up – work through the pain and don’t give up.   Grab a coworker and talk through a problem you are having.  Even if  they don’t know how to solve it, it can feel better or help you work through something.

5. Celebrate – By now, maybe is it 1 day or 5 days later, you will have solved the problem and become that much sharper for it.  Realize that when you can do hard jobs, other people around you will value that skill, even if they don’t say it.

6. Do it again.  As soon as possible, volunteer for the same job.   Taking the hard jobs means that you are typically going to grow your skill set.   Even if this boss doesn’t realize how valuable these skills are, remember, that one day, you will find someone who does appreciate them.

7.  Expand Your Influence – If you can influence the work so that it is easier to do, then that is even better.

• Train a coworker – grab someone and help them through the steps that you just completed.
• Take the time to work with the remote developers building your code to make the task easier to complete.   Your customer will thank you for it!