More than I like, I’ve run into situations where I had to post to services from ruby using WSDLs via SOAP requests. While there are some gems out there that help with it, writing your own solution is actually pretty straight forward.

In this post I will describe how you can use HAML to template your SOAP envelope for a WSDL request.

Lets say we are starting of with a WSDL request definition for retrieving snow board endorsers as described here. The WSDL request might look something like this:

Deploying the service

Deploying the service is straight forward, we will do this like any CF app with cf push.
Navigate into the directory where your services lives, makes sure you are logged into CF, then `cf push`.

Respond to the prompts with the name you want for the service, I use random-string-service-service, for the rest we can use defaults.
Once the push was successful, `cf apps` should show something like this:

If you are using the example app, visiting the above url and adding `/health` should tell you that the service app is responding. You should see ‘The random string service is at your service!’ on the page.

Deploying the gateway

This is the part that was the most confusing to me. The gateway will play a broker role down the road and it is important to know that you use the gateway to create a service instance. From the directory where the gateway lives do a cf push.

Deploying the app that binds to the service

All that is needed now is to do a cf push from the directory the sample app lives in. In the push process select the option to bind a service and when prompted for a service, select the ‘random-string-service’, you can choose the defaults for everything else.

In order to use the service in our app, its needs to be getting the service info from the environment. Interesting to note here, the name that is uses in the VCAP_SERVICES environment is based on the service label, not the name you give your service instance.

One of the exciting things in Cloud Foundry is the possibility to connect your app to different services.

The interesting aspect about services is actually not the service itself. That can just be a regular CF app that provides some functionality, e.g., an app that takes photos, resizes and returns them. The key to getting that app used by other apps in CF is the so called ‘service gateway’. The service gateway does the brokering between the cloud controller and the app to make the service available.

A service gateway itself is rather simple. It needs to support 4 basic actions: bind/un-bind and provision/un-provision. Technically speaking it only needs to support binding and provision if unbinding/un-provisioning are not crucial for your service.

This can be a simple sinatra app that responds to “/gateway/v1/configurations” and “/gateway/v1/configurations/:service_id/handles”.

Advertising the service

The developer needs to provide a mechanism that advertises the service offering to the cloud controller. To do this several endpoints on the cloud controller have to be called to make it aware of the new offering. In this example we call it the CloudControllerAdvertiser.

It needs to perform 3 main functions.

1) Query the cloud controller for a list of services.
2) Advertise services and plans
3) Figure out which services are already registered.

This should be pretty much all you need to get started with a service.
Remember to generate your auth token in the cloud controller. This and more details on service creation a documented here: CF service docs

In the second part of this article I describe how to bind the service to an app and make use of it.

The best way for Google and friends to crawl and index a page is by finding static content. With applications that make heavy use of libraries like Backbone, Sproutcore or ember.js a lot of the content can be rendered in the browser. This can constitute a serious problem since the support methods from Google et. al. for alternative crawling coem with no guarantees.

We recently ran into this problem and came up with a neet solution where the client side templates can also be rendered server side.

There are two parts to the implementation. First, a method that can take a jade partial and its local variables, compile and evaluate it. Second, a view that calls out to that method and provides the template and the necessary local variables.

The method is pretty straight forward, it loads the template from the assets/template directory, compiles it and then evals it with the provided locals. The output is raw html that can be included in your view.

Part 2, a view that requests the compiled and eval’d templates from the server

Here the main thing is the call to the method in application helper that will produce the raw html given a template name and the necessary local variables.

That is pretty much it. It may take a little bit to figure out the requirements for the local variables in your template, especially since jade is very strict about them. If it can’t find one it will not compile.

I’ve put an example app on github with the complete source code for this post.

Recently, I’ve been using a nice way to test if the correct arguments have been passed to a method. This uses a neat property of jasmine where you set up the method you want to test as a mock and have an expectation inside the mock.

The only caveat is you have to set an expectation that your mock get’s called, otherwise if it never gets executed the test will also never fail.

Step by Step

1) Set up the spy on the method for which you want to test the params.
2) Set up the expectation to compare a param to an expected value.

if you need to display complicated html in a javascript driven carousel, write your own,

jquery plugins tend to mess with your markup and force it into a specific layout
which can break your behaviour

acceptance vs. non acceptance rspec

When running regular rspec tests and acceptance test combined slow build time were observed,
breaking them out into different builds resulted in a 25% speed up
(combined 21 min, only rspec 5min, acceptance 10min)

possible help: leave transactional_fixtures as true for acceptance
supported by forcing one db connection as described here:

It is actually not that hard and there are resources all over the inter tubes, you just have to find them.
For the sake of saving myself and some fellow programmers some time I will summarize the process we followed.

First, you need to make sure to have the fixture_builder, database_cleaner and while we’re at it headless gems installed.
Then the bulk of the work happens in acceptance_helper.rb, spec_helper.rb and fixture_builder.rb.

Details on what is in them are below. There are some notable things which I mention in context with the code.

spec_helper.rb

If you need you fixtures loaded in a particular order
you can load them in that order by specifying them as argument for the config.global_fixtures variable in spec_helper.

ENV["RAILS_ENV"] ||= 'test'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'
Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| require f}
RSpec.configure do |config|
config.include ObjectCreationHelper
config.include ObjectCreationMethods
config.mock_with :rspec
config.global_fixtures = :all
# Remove this line if you're not using ActiveRecord or ActiveRecord fixtures
config.fixture_path = "#{::Rails.root}/spec/fixtures"
# If you're not using ActiveRecord, or you'd prefer not to run each of your
# examples within a transaction, remove the following line or assign false
# instead of true.
config.use_transactional_fixtures = true
config.before(js: nil) do
config.use_transactional_fixtures = true
end
end

accptance_helper.rb

Here headless (enables running selenium tests on a ci-server without a browser) and data_base cleaner are set up.
Database_cleaner will clean everything in the specified interval (in my case after each test) unless tables are specified in the “except” option for the database_cleaner strategy.
It is important to turn transactional fixtures off before running specs that require js and turn them back on after they have run
to ensure rspec spec still runs, assuming that there are spec files that have both test that require js and some that don’t require js.