Deploying a Merb app on Glassfish with Capistrano

A lot shorter than the last post with a lot less weirdness.

I have traditionally (can you say that for something you’ve used barely a year?) used Capistrano to deploy my Rails applications. Most of the time to a pack of Mongrel but lately all Phusion Passenger. So the natural thing to do when looking to deploy a Merb app into production was dusting of Capistrano.

Long story short, my deploy.rb file( (without all the usual stuff):

set :warfile_name, "calculator"

role :app, "85.17.94.1"
role :web, "85.17.94.1"
role :db, "85.17.94.1", :primary => true

namespace :deploy do
desc "Create WAR file after deploy and deploy that WAR file"
task :after_update_code do
run "cd #{release_path}/ && MERB_ENV=production warble"
end

task :stop do
run "/usr/local/glassfishv3-prelude/bin/asadmin undeploy #{warfile_name}"
end

task :start do
run "/usr/local/glassfishv3-prelude/bin/asadmin deploy --contextroot / #{release_path}/#{warfile_name}.war"
end

task :restart do
run "/usr/local/glassfishv3-prelude/bin/asadmin redeploy --name #{warfile_name} #{release_path}/#{warfile_name}.war"
end
end

Many thanks to the BrightLight blog for providing the initial inspiration.

Note the explicit MERB_ENV environment variable, this makes sure that, well you guessed it, build the WAR file with the production config file. The remainder is stupidly easy once you have figured it out.

There was one thing which threw a spanner in the works. When I was testing with (re)deploying etc I ran into a nasty ‘Permgen space’ Java error. I still hardly know what it does but apparently if you start your Glassfish server with the switch ‘-XX:MaxPermSize=256m’ everything should work fine again. No guarantees.

Posted in development | 1 Comment

Glassfish v3 with Merb and Warbler

It’s been a looong time but this I want to share with you.
For a project I’m currently working on we needed something really really fast. Rails with Ruby MRI was out of the question so we went for JRuby and Merb. This particular piece of the project is ideally suited for Merb as we are using it as a backend system (webservice) only.

So you want JRuby because it is blazingly fast (at least compared to MRI)? Fine. But how to deploy the bugger? We quickly decided on Glassfish an open source application server made and maintained by Sun. Moreover this lovely server had a gem which you can use to fire up a Glassfish server. Easy as pie and within no time at all we were developing our Merb app on Glassfish.

I was charged with the task to deploy the app to the server and that’s when the trouble began. First off I installed JRuby 1.1.5 (in /usr/local/jruby) and installed the Glassfish gem (v0.9.0). I had no idea how to monitor and fire up the gem but that was for later. Installed the glassfish and merb-core (!) gem ($ jruby -S gem install glassfish merb-core). Don’t install Merb! This won’t work as it depends on a gem which tries to build native extensions.

Still manually copying over the source of our app I ran the glassfish command only to be greeted with an Activator error. Took me a while to figure out but this appears to be a proper bug. The maintainer is aware of the issue and will fix it in the 0.9.1 release of the gem. No good for me so onward.

If the gem doesn’t work than the true Glassfish server might do the trick. I come from a Java background but have been developing Rails/Ruby now for over a year and I quite forgot how incredibly verbose the Java world is. After reading for an odd couple of hours or so. I went for the installer of the Glassfish v3 prelude. The v3 release does not require you to package up your app in a WAR file which sounded very good. Unfortunately the installer died with some unclear error messages and I just downloaded the zip and unpacked it in /usr/local/glassfish.

More dark clouds ahead! I have no idea how this stuff works and although there are a couple of Rails examples non worked for our Merb app. :S Starting the server with jruby was already a challenge, in the end

java -J-server -Xmx256m -Djruby.home=/usr/local/jruby-1.1.5/ -jar /usr/local/glassfishv3-prelude/glassfish/modules/glassfish.jar

did the trick. But how to get Glassfish to accept my ‘exploded’ (eg non WAR/EAR) Merb app? I still have no idea. Enter Warbler.

This charming little gem turns a Rails, Merb or Rack app into a WAR file ready to be deployed. I’ll leave out all the errors and just to it. First off edit the config.rb file of the warbler gem (found in /usr/local/jruby-1.1.5/lib/ruby/gems/1.8/gems/warbler-0.9.11/lib/warbler/), got to the auto_detect_merb method and change the line:

@gems["merb"] = Merb::VERSION

to:

@gems["merb-core"] = Merb::VERSION

This will enable warbler to find the correct gem. Installing the gem ‘merb’ was not an option for JRuby!

Second edit the merb-core gemspec (found in /usr/local/jruby-1.1.5/lib/ruby/gems/1.8/specifications) and find all references to webrat and remove them. Webrat depends on Nokogiri which in turn has native dependencies… etc etc.

Third replace the jruby and jruby-rack version in /usr/local/jruby-1.1.5/lib/ruby/gems/1.8/gems/warbler-0.9.11/lib with the hottest flavours (JRuby-Rack: http://kenai.com/downloads/jruby-rack/, JRuby: http://dist.codehaus.org/jruby/)

We are now ready for WAR.

Config the war file!

$ jruby -S warble config

Edit the config/warble.rb file. Remove the ‘vendor’ and ‘tmp’ directory from the config.dirs directive. LEAVE all references to config.gem alone. This does not work as expected config.gem -= “rails” does not remove the rails dependency. On the contrary. The config.webxml.booter needs to say :merb. Save-close-etc.

Create the war file!

$ jruby -S warble war

Tell the now running Glassfish server to deploy it with

$ /urs/local/glassfish/bin/asadmin deploy your_app.war

The server is running on port localhost:8080/your_app
May this help.

Posted in development | 8 Comments

Configuring Cruisecontrol, Git and RSpec

The realization we needed a continuous integration server sank in good last week when work on our internal project really got started. The project has seen quite some development in the past, mainly when my skills in (RSpec) testing where, uhm, less than optimal. This on top of some high pressure hacking left the project in a pretty shabby shape. We are now working on it with three people and we’d like to introduce a bit more rigour in our development process.

One of the first steps was to use a continuous integration server. I was actually surprised so few existed and the choice for CruiseControl(CC) was a quick one. This pretty piece of software did not support Git out of the box but there exists a GitHub branch incorporating this functionality. What is even better is this post which explains how to use it! So I won’t go into the nitty gritty details, what I will do is point out some pit falls and how to make CruiseControl play nice with RSpec. Which it also does not support out of the box but which is really easy.

Install CC as per previously mentioned post. What threw me off where the site_config.rb and the cruise_config.rb I got the (wrong) impression that these files lived in the root directory of the CC install. This is not the case. When installing CC it, by default, creates a directory ~/.cruise which holds your projects. It is here where the site_config.rb file lives. And this is the file to configure ActionMailer! And in the directory ~/.cruise/projects/MyProject the other file can be found in which to configure the people who need to receive emails when the build breaks.

When CC builds a project it just runs some Rake tasks, one of which is cruise. Getting CC to use RSpec is as simple a overwriting this task! This is what I gleaned from other posts:

[sourcecode language="ruby"]

desc “Task to do some preparations for CruiseControl”
task :prepare do
RAILS_ENV = ‘test’
end

desc “Task for CruiseControl.rb, automatically picked up”
task :cruise => [:prepare, "db:migrate", "spec"] do

end

[/sourcecode]

The first task is to make sure the test environment is used which is really what you want in a situation like this.

The next step would be to produce something more readable than the dump of the log file with the results of the ran RSpecs.

Posted in development | Tagged , , | 3 Comments

Using migrations to transform data

Usually I use migrations to just add and remove columns. But today I needed to modify the database schema of a live app and should thus preserve the data already present. Although not hard implementing it revealed some pitfalls.

The task at hand was to augment the users in the system with roles. We had a column in the Members table which made a member a manager or not(boolean). This information is now extracted to a roles table (we are using RoleRequirement). It is now possible to assign many different roles to each member.

The migration I wrote at first looked something like this:

[sourcecode language="ruby"]
def self.up
r = Role.new(:name => “manager”
r.save
remove_column :members, :manager
managers = Member.find_all_by_manager(true)
managers.each do |manager|
manager.roles << r
manager.save
end
end
[/sourcecode]

However this migration failed on the manager.save, complaining that the column manager on the table members no longer existed. And it didn't of course. The column had just been removed! I figured that the attributes in the manager objects still contained the :manager => true key-value pair. So I deleted that but the error persisted. Which makes sense when I thought about it. The migration loaded the Rails framework with all inferred classes. One of these classes was the Member class which contained at the time of loading still a manager field. Trying to save the member without one of the attributes causes an error. Reloading framework seemed a bit overkill as well.

In the end the solution was, as most of the time, deceptively simple. Remove the column at the end of the migration!

[sourcecode language="ruby"]

def self.up
r = Role.new(:name => “manager”)
r.save
managers = Member.find_all_by_manager(true)
managers.each do |manager|
manager.roles << r
manager.save
end
remove_column :members, :manager
end
[/sourcecode]

But how do you test your migration? I took a stab at this in the form of an RSpec test:

[sourcecode language="ruby"]

describe Member, "should migrate properly" do
it "should migrate correctly from a column manager to a role manager" do

`rake db:drop`
`rake db:create`
`rake db:migrate VERSION=59`
m1 = Member.new(:manager => true)
m1.save_with_validation(false)
m2 = Member.new(:manager => true)
m2.save_with_validation(false)
m3 = Member.new(:manager => true)
m3.save_with_validation(false)
`rake db:migrate VERSION=60`
Member.find(m1.id).has_role ?(“manager”).should be_true
Member.find(m2.id).has_role?(“manager”).should be_true
Member.find(m3.id).has_role?(“manager”).should be_true
end
end

[/sourcecode]

But this does not work yielding a MySQL timeout. This has to do with the fact that all tests are run in transaction mode preventing other database changes during the tests. This particular test waits for the lock to be released which never happens and thus times out.

I have yet to figure out how to do this, but I think this is really important! I would love to be able to test my migrations as these migrations manipulate live data which can not be lost. Any suggestions are welcome.

Posted in rails | Tagged , | Leave a comment

BackgroundRB versus Beanstalkd

This seems to be a recurring problem. Sending a lot of emails from Rails is still a bit murky. You can’t really use ActiveMailer for this because when you are trying to send 12.000 emails the request does not return a respond until all the 12.000 emails are sent. This leads to confused users who click the button again, timeouts etc etc. A general mess. You could use a cron job but that does not make that much sense as you would expect the emails being send as you press a button and not when a cron job comes along. Again confused users.

What you really want is to be able to background tasks and be done with it! For this there are many options. Unfortunately. But I believe the two candidates worth looking at are:

Beanstalkd is being used on Facebook(need I say more?). BackgroundRB enjoys more attention and has recently been rewritten and thus presumably increased in quality. The first is not as tightly coupled with Rails as the latter but that can be amended with a plugin.

Then there is the matter of compiling beanstalkd… That was no fun at all. Well maybe I made it too hard for my self and I did not exactly knew how to manipulate ‘make’. But I wanted the latest version(0.11) of beanstalkd and MacPorts only had 0.9 in stock. So I downloaded the source, followed the readme and hit make. Of course that didn’t fly. I needed to point the makefile to the correct lib directory. Long story short, I did install beanstalkd through port and took the makefile from that install and patched the makefile in the source download. Here is the patched makefile. This worked like a charm! However this made me a bit concerned how up to date the packages on our Debian staging server were. It turned out that I needed to install both the dependencies and the actual beanstalkd from source. I’d prefer gems then.

For more information on beanstalkd I gladly refer to this blog post as I decided after this ordeal that I would go forward with backgroundrb. This decision was mainly based on the better logging abilities of backgroundrb and the from source install as opposed to some gems.

A parting thought; look at the footer of backgroundrb’s website. Notice the link called Ginger Ninja? Click it. I think it’s at least weird and perhaps doggy.

Posted in rails | Tagged , | Leave a comment

Small Rspec revelations, RJS

The closing scene of this series. Specing RJS templates. Again a topic which is not on the forefront of the RSpec community.  And again a blog post saved the day. It took me a little bit of time for figure out what kind of RJS type the response object should expect. To illustrate an example RSpec:

[sourcecode language="ruby"]

response.should have_rjs(:chained_replace_html, “some_id”) do
response.should have_text(/some random text/)
end

[/sourcecode]

The response object should have an RJS object but what type? According to the assert_select_rjs method, which the have_rjs method wraps, there are only a hand full of these types but apparently not all of them are listed. As I found out when my inline RJS:

[sourcecode language="ruby"]

render :update do |page|
page[update_div].update(text)
end

[/sourcecode]

None of the mentioned types responded correctly. But I noticed that the blog post mentioned earlier used an other type. Browsing through the source code of assert_select_rjs I found my missing type: chained_replace_html. Hooray! Everything worked fine and dandy from there on.

One last hiccup was that code in the block passed to the have_rjs method does not scope by default the response.should directive, so this is wrong:

[sourcecode language="ruby"]

response.should have_rjs(:chained_replace_html, “some_id”) do
have_text(/some random text/)
end

[/sourcecode]

Obviously.

Posted in Uncategorized | Tagged , | Leave a comment

Small Rspec revelations, Modules

It looks like this is going to be a three parter. For our current project we wanted to abstract some of the functionality which appeared in our models to a module. As we are taking TDD more seriously nowadays I set out to write a spec for the module first. Right. For a normal spec you need an instance of the object you are specing. But by their very nature models can not be instantiated! So how to write a spec then? Here you go:

[sourcecode language="ruby"]

before(:each) do
klass = Class.new { include FicklePricing }
@foo = klass.new
@foo.stub!(:id).and_return(1)
end

[/sourcecode]

In this case we have created a class with does nothing but to include our module. And this almost empty class can by instantiated and used in this specs. Trivial example:

[sourcecode language="ruby"]

it “should respond_to price method” do
@item.should respond_to(:get_price)
end

[/sourcecode]

Posted in Uncategorized | Tagged , | Leave a comment

Small Rspec revelations, ActionMailer

At the office we are getting more and more serious about RSpec . Today we ran into two things we had not done so far. Specing an ActionMailer and a module. The Rails Way only covered Test::Unit and that looked dreadful. Way to much code. I still think I should be coding applications not tests. A quick google turned up not so much, nor did the RSpec site help. Fortunately someone on the RSpec mailinglist brought the subject up. With that I knew enough to get the tests working.
[sourcecode language="ruby"]
before(:each) do
ActionMailer::Base.delivery_method = :test
ActionMailer::Base.perform_deliveries = true
ActionMailer::Base.deliveries = []
end
[/sourcecode]
This before block set the method for delivery method to :test. Normally it default to :smtp and an other possibility is :sendmail. The second directive tells ActionMailer to actually send the emails(who would have guessed?). The deliveries array keeps track of every email seen.

Now you can just send your email as you usually would:
[sourcecode language="ruby"]
mail = Notifications.deliver_some_random_email(“name”)
ActionMailer::Base.deliveries.size.should == 1
mail.body.should =~ /name/
[/sourcecode]
Rock on RSpec.

Posted in Uncategorized | Tagged , | 8 Comments

Building a RESTful CMS

Today is the day we at Innovationfactory finish the development of a site maintained by a CMS. As this was the first CMS we build in RESTful Rails initially we where unsure how to proceed. There is some discussion(and here and here) on whether or not the admin functionality should be seperated from the non admin functionality. On one hand this makes sense. As an admin you are doing something vastly different than a normal user visiting the site. On the other hand it doesn’t. Both the admin and visitor interact with the same resources. Only the view and options presented are differtent. In the end we choose to seperate the admin functionality from the visitors functionality, thus creating two controllers for one resource. We deemed this better as the underlying resource is still the same but the interaction is different. And interaction is taken care of in a controller. Hence two controllers for two distinct way of interacting with our resources.

Posted in Uncategorized | Leave a comment

The usage of self in Ruby

This confused me for some time and I figured I write it down for others to enjoy. When should one use the keyword self in AR:B? For this it is important to realise that Ruby is an interpreted language. Whenever Ruby sees an assignment like bla = 'boe' it first looks for a local varialbe by that name(bla in this case) and if that does not exists it then looks for a method bla=
[sourcecode language="ruby"]
class Foo
def bar
text = ‘fake’ #assigns a variable ‘text’
text.gsub!() #changes the variable ‘text’
end

def bla
text.gsub!() #does not find a variable ‘text’, then searches for a method ‘text’(and fails in this case)
end
end
[/sourcecode]

So if you want to change a field in an ActiveRecord model you need to tell Ruby not to create a local variable but to use the generated setter method.
[sourcecode language="ruby"]
class Foo < AR:B
def bar
self.text = ‘fake’ #assigns the field ‘text’
text.gsub!() #changes the variable ‘text’
end
end
[/sourcecode]

Posted in Uncategorized | 1 Comment