posts by tag

So, why call it Hoptoad? From their blog...

For the academically curious, the word “hoptoad” is railroad industry slang for a derailed train. At least, it used to be when the railroad industry had slang.

Yeah, that’s not what I thought it meant either. But it turns out that Hoptoad is a particularly clever name, considering that it metaphorically signifies a Ruby on Rails application getting derailed. Maybe that will make more sense to you in a minute.

No matter how hard us web developers try and build solid applications, things go wrong. And get this, sometimes we don’t even know! Aha! The perfect solution: Exception Notifier. Now, I can get an email when any un-handled exception occurs. Perfect!

Eh, not really. Exception Notifier is a little obtrusive in the sense that it sends every single error to your email. And yes, you could setup a special account just for that, and blah-biddy-blah, but at the end of the day you’re still parsing text in an inbox. Good? Yes. Great? Maybe. Perfect? Hardly.

Enter Hoptoad. I don’t know how many of these things exist (except for this other one), but man, what a brilliant idea. Instead of sending the exceptions to your inbox (which is hardly the ideal place to read through them), it uses a web-service. And it posts to a real deal web application where its sole purpose is to merely provide an interface (and a very clean one at that) around your exceptions. It allows you to setup several projects, mark exceptions as resolved, look at a frog (er, toad), and there’s word of a few more bells and whistles on the way.

It was officially released yesterday, so go on and ride the toad (as they say). I’ve already incorporated it into Golf Trac and a few other projects of mine, so I can vouch for it’s slickness.

This definitely scratches my itch with exception notification, so thanks, Thoughtbot.

I know, I know, REST is cool and SOAP sucks. Rails is awesome and .NET blows. But the reality is I have to do a little bit of both.

Things at work are moving more and more toward Rails, but there’s still a large investment in a few .NET systems that must be maintained (until the decision is made to rewrite them in Rails). With that means there are a few SOAP services that I still need to work with. It turns out, this isn’t so bad.

Originally I thought I’d bring back AWS and deal with it that way. But from my experience, AWS has more support for generating services rather than consuming services. While AWS isn’t a terrible approach, there’s an easier way this can be handled: SOAP::WSDLDriverFactory. This is a straight-up Ruby solution that comes shipped with the standard library. It’s straight-forward to use and requires no XML parsing (which sort of surprised me).

As an example, one of the Rails applications I’m currently working on needed to have the ability perform certain actions under that users’ .NET account. Mainly, since the applications are completely separate (read: separate DB, separate users table), I needed to get the user id from the .NET system via their credentials in the Rails system. While this isn’t the actual implementation, you can see how easy this is to do.

require 'soap/wsdlDriver'

class SomeDotNetWrapper
  attr_accesssor :endpoint, :service

  def initialize(endpoint=nil, service=nil)
    @endpoint = endpoint
    @service  = service
  end

  def get_user_id_from_credentials(username, password)
    soap = wsdl.create_rpc_driver
    response = soap.GetUserID(:username => username, :password => password)
    soap.reset_stream
    response.getUserIDResult
  end

  private
    def wsdl
      SOAP::WSDLDriverFactory.new("http://#{@endpoint}/services/#{@service}.asmx?WSDL"
    end
end

By creating a “factory” with the services’ WSDL, you can easily set things up for remote procedure calls (i.e. GetUserID(username, password)). What’s even nicer is that you can parse the response by chaining methods together. In this case, it put me right inside the response, where I only needed to call one level of nested XML (response.getUserIDResult). But if this were nested deeper, I’d just keep calling the methods that map to the XML nodes until I got to what I wanted. And of course, I could then write any Ruby code to do what I needed to do, but the point is it’s automatically method-like access, which is nice (think of Builder).

So, once you write your “wrapper” class, you’re ready to go.

class SomeDotNetWrapperController < ApplicationController

  def store_other_id
    raise InvalidCredentials if params[:username].blank? || params[:password].blank?
    service = SomeDotNetWrapper.new('http://example.com', 'authentication')
    other_id = service.get_user_id_from_credentials(params[:username], params[:password])
    current_user.update_attribute(:other_id, other_id) unless other_id.to_i == 0
  rescue InvalidCredentials
    # ...
  end
end

I’m sure there are a lot of different approaches, but this seemed the easiest to me. I had somewhat of a difficult time finding a solid solution online for easily consuming .NET SOAP services, so I decided to resort back to the standard library, as generally every language has support for this sort of thing. Anyway, maybe someone else with the same needs will find this useful.