Archive for December, 2008

SSL setup for Ruby

December 18th, 2008

I found recently that I wanted to get SSL enabled when making HTTP connections with Ruby. However, if you’re wishing to talk to servers that have certificates signed by commercial certificate authorities then you won’t be able to verify them when you make a connection:

require 'net/http'
require 'net/https'
http = Net::HTTP.new('www.google.com', 443)
http.use_ssl = true
http.get('/mail')
"warning: peer certificate won't be verified in this SSL session"
=<#net::httpfound 302="" found="" readbody="true">

Notice line 6? Not good as its really important to be able to verify SSL certificates on the web to make sure that you’re talking to who you think you’re talking to!

So to verify these certificates, download commercial certificate authorities used by Mozilla (Firefox) that have been kindly pre-packaged for you:

http://curl.haxx.se/docs/caextract.html

Store in a logical location:

/usr/share/ssl/cert.pem

Now, test out that they are working, try this code (IRB works well!):

require 'net/http'
require 'net/https'
http = Net::HTTP.new('www.google.com', 443)
http.ca_file = '/usr/share/ssl/cacert.pem'
http.use_ssl = true
http.get('/mail')
=<#net::httpfound 302="" found="" readbody="true">

Yah! No more warnings, we’re properly verify the server’s SSL certificate!

Tip: If you’re behind a proxy, then you’ll need to change the third step to be:

http = Net::HTTP::Proxy('myproxyserver', 8080).new('www.google.com', 443)

The above code creates a HTTP class with your proxy configuration baked in. Then you can create an instance from it, just like a regulard HTTP class!

No comments »

Posted in Software development

Tags:

Thinking integration

December 16th, 2008

After working on several web projects that have required plenty of integration involving many systems within the enterprise, I’ve come to some realisations about getting integration right:

Services must be exposed at the right level

It’s extremely tempting when performing integration to try and apply good application programming practices of keeping methods simple and stringing them together. This practice makes it easier to test methods in isolation, simplifies their contracts, and ultimately leads to more flexible and understandable code.

The frameworks available for performing integration (i.e. web services with Apache Axis) give you a healthy level of abstraction deliberately so that you can easily forget that you are performing integration at all.

But here in lies the problem. As soon as you forget that you are performing integration, you can start to perform good application practice which in turn can lead to disastrous integration practice. For instance, if the services exposed for integration are too fine grained, then the consumer may have to invoke many services to get a enough data to fulfill its objective. User experience and (distributed) server load are the first things that will suffer.

Services need to be exposed at the right level to ensure that a consumer can make as few a calls as possible (ideally one) to fulfill their objective.

No doubt getting this level of exposure correct is the tricky bit, but as soon as you find that you’re starting to become very chatty with services to get things done, this is the sign that its time to think about exposing a new service at a higher level of abstraction.

Ensure that services are fit for purpose

In a similar vein to the point above, it’s important to ensure that the service you’re invoking is truly designed to meet your purpose. There is a temptation to look at a service catalogue and pick out the services that will help you get what you’re after. However, if these services are not in line with your objectives, then there is a good chance that they’ll be doing more than they should be for your needs. This leads again to unnecessary server load and the likely-hood of an impaired user experience.

A good way to spot if a service is unfit for your purpose is to inspect its response payload. If it contains far more information than you need, then you’ve probably got to think about getting a better suited service exposed.

Thinking SOAP based web services as the protocol for integration, the above problem re-enforces for me why the document style web service is a far better approach than the RPC style web service. The later is tightly coupled and inflexible, just like a method call is. The former is the opposite allowing for a service to cover many situations and purposes. Some that may not have been originally conceived but are now required. Incorporating this support should not be costly and have limited if any impact on existing consumers.

So, if a service is using the document style approach and its not quite fit for purpose, you should be in luck! With a small enhancement, you will have the service that fits exactly to your needs.

Here’s an old article that sings the virtues of document style web services:

Reap the benefits of document style Web services

No comments »

Posted in Software development

Tags:

Ok, ok, I get it, jQuery is cool!

December 4th, 2008

I’d been hearing about jQuery for quite a whiles now but resisted the temptation to dive in. The Rails community in particular is quite abuzz with it and I’d heard the creator of it interviewed on Geoffrey Grosenbach’s Ruby on Rails Podcast.

Still I resisted, surely prototype and scriptaculous were the way to go, after all they’ve been shipping with Rails since forever and Rail’s has many functions that tightly integrate with them, especially its RJS view support.

Then I started to hear people becoming quite critical of RJS, in particular raising concerns over its abstraction of javascript and invasive approach to the DOM.

I continued on my merry way, working on my pet project, pulling out a lot of RJS support that I had previously but still using it where it made sense.

Then I started looking into potentially introduce an Accordion User Interface widget and thats when the wheels started to fall off for the prototype and scriptaculous cart that I was pushing.

I found an accordion extension for p & s and started playing around with it. It seemed to work fine on the demo site, but it looked horrible when I integrated it into mine. I discovered that it was built against prototype 1.5 whereas I was using 1.6.

It was at this point that that I decided that I’ve got myself a problem. jQuery had an accordion widget, I’d seen it demonstrated at a recent workshop at the WebDirections South conference in September and it looked pretty good. Time to bite the bullet.

I checked out Ryan Bate’s Railscast on jQuery to get a quick overview and see how to get it up and running quickly in Rails. Then I spent an hour checking out the jQuery website and getting familiar with the examples and API. All looking very impressive. Pretty quickly the concepts started to come through. It really struck me that the selector approach is incredible powerful and it made striving for unobtrusive Javascript easy, just like CSS is unobtrusive presentation.

Within a couple of hours my Rails app was devoid of all RJS, prototype and scriptaculous. jQuery was introduced and all my obtrusive Javascript removed!

Now it feels like I have a world of options available to spruce up my user interface too! The plugin repository is incredibly large, something which p & s are sorely missing.

The amount of inertia behind jQuery is quite impressive and in my opinion this is what counts. The fact that Rails developers are openly advocating it spells the end for prototype & scriptaculous too. Alas, they were great libraries but its time to move on, the mob has spoken.

No comments »

Posted in Software development

Tags: