January 10th, 2010, by fitzy
JRuby is a 100% Pure-Java implementation of the Ruby programming language. From the folks over at the JRuby project:
The JRuby project has been growing impressively quickly, with frequent releases and a constantly expanding community. There’s a hefty list of impressive users and companies, and the team has been touring the world, trying their best to make it out to everyone who wants to hear and learn about the project.
As with any growing code base though, there’s a need to keep things tidy; frequent releases and speedy development also mean bugs, and things that need fixing—and that’s where we turn to you!
The first ever official JRuby BugMash will take place this Saturday, January 9th through Tuesday, January 12th. The core team will spend the days prior to the BugMash highlighting the specific bugs that are most important—you’ll want to keep an eye out for the JRuby Introsection, which will one of the focuses of the BugMash. Also look in spec/tags for failing RubySpecs for JRuby’s 1.8 and 1.9 compatibility modes. There’s a lot of low-hanging fruit (especially in 1.9) for both new and experienced developers. Then, Saturday morning, it’s off to the races! As a small token of our appreciation, in addition to the wonderful satisfaction of having made a difference to the project, we’ll be sending each of the first 100 participants a limited edition JRubyConf Poster.
The JRuby Core Team will be around on IRC channel #jruby throughout the BugMash to help folks get started and to answer questions. Be sure to stop in and say hello!
There’s also a great post on the good and bad of JRuby over at the Engine Yard blog.
We are a web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. You can read more about our Ruby on Rails development or contact us.
Posted in Industry Trends, Ruby on Rails | 1 Comment »
December 2nd, 2009, by aaron
We recently had to embed images into our emails that were being sent with Actionmailer, and as such we turned to the inline_attachment plugin to achieve this. It very easily parses your mail output and overrides the ActionView path_to_image helper to attach the file and create an appropriate path to the attached image inside the email while splitting your mail into appropriate parts as necessary.
What we needed to do though was embed a dynamically generated image into the email. The image didn’t exist on the file system previously so we couldn’t use the standard image_tag helper that inline_attachment was patching.
So we extended ActionView to include a new tag helper attach_image_file that uses the existing inline_attachment part management and just a properly referenced image. The methods from inline_attachment take care of attaching the file to the email and splitting the mail content into the appropriate parts.
Here’s my code. I just added it into my initializers directory :
module ActionView
module Helpers
module AssetTagHelper
def attach_image_file(file)
@part_container ||= @controller
if @part_container.is_a?(ActionMailer::Base) or @part_container.is_a?(ActionMailer::Part)
basename = "barcode.gif"
ext = basename.split('.').last
cid = Time.now.to_f.to_s + "#{basename}@inline_attachment"
@part_container.inline_attachment(:content_type => "image/#{ext}",
:body => file,
:filename => basename,
:cid => "<#{cid}>",
:disposition => "inline")
return "
"
end
end
end
end
end
It did what we need, and allows us to properly inline a dynamic image. You could use similar code to inline pretty much anything that your target mail reader supports. Apple Mail for instance may provide PDF previews.
We are a web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. You can read more about our Ruby on Rails development or contact us.
Posted in Code, Ruby on Rails, Tips and Tricks | No Comments »
October 8th, 2009, by aaron
We’ve been using Selenium, Webrat, Cucumber and any number of other gems together for quite a while with very few problems. Just recently our Selenium tests just stopped working on the login step, and given our application requires users to login to do anything, it meant out test suite was basically broken from step one.
Given that we thought very little of any consequence had changed it was annoying trying to troubleshoot the problem. Typically you start off thinking it’s something you did, then maybe it’s something someone you know did, then you start to branch out and think that maybe, just maybe, it was a bug elsewhere!
I initially started to check the logs and they seemed perfect, but it wasn’t finding the user record in the database. So I loaded the database in sqlite and lo-and-behold there were no user records to be found. I started a debug session and it reported that the user had in fact been created. I thought it had to be something to do with transactions being used. Trying to insert a record into the database and being told the database was locked confirmed this.
I turned out that the Cucumber gem writer determined that there should be no more global setting for turning on or off transaction support when running tests. Previously transactions were turned off by default in Cucumber, and you’d generally turn them back on if you needed them. This change is annoying because a good chunk of our suite uses Selnium for testing and it requires transactions to be turned off. It’s also a bit odd to reverse a default option and have no way to enable it at all.
Apparently the work around is to tag all the features and scenarios that rely on non-transactional database operations with this new tag of @no-txn. After implementing this, we’ve found it does work and so our tests are back to usual condition.
So if you’re running into problems with your Selenium tests using Cucumber with Rails and your database isn’t updating within a test then check out the ‘@no-txn’ tag and see what happens after you use that.
We are a web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. You can read more about our Ruby on Rails development or contact us.
Tags: Cucumber, Rails, ruby, Ruby on Rails, selenium
Posted in Inside TFG, Ruby on Rails | 1 Comment »
August 4th, 2009, by aaron
I just finished watching this informal talk by J.B. Rainsberger with Corey Haines on an evolutionary design pattern that Rainsberger uses. He says that it’s about removing duplication and bad names, to me it’s a simple way to go about enforcing modular design and implementing your design in a way that very strongly matches the MVC pattern.
The talk is about 10 minutes long but worth a listen. He gives a basic example that has common analogues in most areas of application programming.
We are a web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. You can read more about our Ruby on Rails development or contact us.
Tags: Corey Haines, JB Rainsberger, Patterns, TDD
Posted in Ruby on Rails, Tips and Tricks | 2 Comments »
June 10th, 2009, by aaron
I wanted to integrate some branding functionality into an application we’re developing and so I needed test file upload functionality. We’re using Webrat for integration tests, though this will likely change as we increase the amount of Javascript in the app. I added Paperclip to handle the file attachments for logos, and everything was working.
When I added validation to the model, making sure that the file being attached was an image, this broke the tests. It didn’t seem to matter what type the file was, it would fail no matter what on the file type validation.
I used ruby-debug to debug my test and it seems by default Webrat sends file uploads as plain text. It does have the option to specify the file type when attaching the file, so the easiest way around this is just to specify the MIME type for the file. Now my Cucumber step looks something like this :
When /^I attach "([^\"]*)" image to the "([^\"]*)" file field$/ do |filename, field|
type = filename.split(".")[1]
if type == "jpg"
type = "image/jpeg"
end
attach_file field, File.join(RAILS_ROOT, test_asset_path, filename), type
end
Obviously this will need some work as I progress, but it works. At this stage I have an assets folder in my features folder to store any files that I need for my tests.
On the confirmation end of the test I just have a simple tag test to check that the image tag is displaying, and it contains the correct src attribute :
Then /^I should see tag "(.+)"$/ do |selector|
(Hpricot(response.body)/selector).should_not be_empty
end
So in my feature test I have :
Then I should see tag "img[@src*='']"
This just confirms that there is an image tag that contains the file name of the file that I uploaded in the test.
We are a web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. You can read more about our Ruby on Rails development or contact us.
Tags: Code, Cucumber, Paperclip, Testing, Webrat
Posted in Code, Ruby on Rails, Tips and Tricks | 2 Comments »
Follow Us