A guest post on Engine Yard’s blog by Darcy:
“Whilst prototyping the early stages of a new app with Filter Squad, we found ourselves prototyping a lot of API clients for new versions of APIs that were lacking up to date clients or in the case of other APIs, were missing functionality we required.”
Read the full post over at Engine Yard: Building Structured API Clients with API Smith
It’s been a busy few months at The Frontier Group.
Firstly, a congratulations to our very own Darcy Laycock for winning a Ruby Hero award. The Ruby Hero awards are put in place to recognise people that have gone above and beyond in the Ruby community.
We’ve rolled out our new Frontier Group blog design, and would love to hear what you think of it in the comments below. We’ve also added a Featured Posts section in the sidebar, so you can see what other visitors (and hopefully you) are interested in too.
We’ve been heavily featured in a range of Podcasts recently, such as Ruby5 and The Ruby Show. Also we’ve been featured in prominent Ruby and Rails websites such as Ruby Weekly and Ruby Rogues.
We’d love you to keep visiting. Sign up to receive our newsletter using the form to the right, or stop back here from time to time. Don’t forget to check out the rest of our site and see what we’ve been working on.
I had some conditional logic I needed to test that was based on the current Rails environment. Basically something like:
if Rails.env.production?
# Do something
Elsif Rails.env.staging?
# Do something else
End
I needed to stub out the Rails.env call. I had a quick Google around but I couldn’t really find a way of doing this I was happy with.
I whipped up this function that allows you to set the Rails environment to whatever you want:
Can’t see this Gist? View it on Github!
Put the above function in your spec file or your spec_helper.rb. The function can be called as such:
Can’t see this Gist? View it on Github!
The Rails.env function looks like this:
Can’t see this Gist? View it on Github!
So all you’re doing is setting the cached instance variable to the environment you want.
So two distinct issue have come up as a result of the above content.
Firstly, there was no ensure meaning that if an exception was raised in the middle of the stub then the environment would be changed for the remaining tests. This was a stupid mistake but, it happens, so I’ve updated the gist and my code.
Secondly, the issue of checking environment in code. The solution for this would be to have a constant in each env file that defines whatever it is you are using the env check for. So in the example I was working with each env file would have a EMAIL_TARGET constant.
You still need to test this, so the stub provided is still useful in this regard.
There is a gem called ydd that offers really simple import and export of smallish databases. It exports to YAML and then imports to whatever database Rails can connect to. After using YDD a few times I’ve found it easier to pinpoint the cause of problems that occur using taps.
It doesn’t handle character encodings though so I went about adding that. With the handy rchardet gem and IConv, detecting the character encoding of the incoming string and converting it to UTF-8 was pretty simple. I’ve created a pull request for the gem that will hopefully be accepted.
The essential code is below, and revolves mainly around the detection and conversion. Using //TRANSLIT causes IConv to try and convert the incoming character code to something that exists in the UTF8 character set, and then //IGNORE will ignore any characters that don’t exist in the UTF8 character set. Chaining //TRANSLIT and then //IGNORE will make IConv try a conversion first and then ignore anything it cannot convert.
I used this gem after the above changes to convert about 400,000 records of text data with ASCII, windows-1252, IBM866 and other character encodings from an old SQLite installation to a new postgres database without any issues.
Just upgraded to the newest RSpec (2.6.0) and found that RCov has stopped working completely? That’s what happened to me after running a bundle update. RCov refused to run, no error messages, just blank output.
After looking around for a little while I found this: https://github.com/rspec/rspec-core/issues/370
In short: the new RSpec has been broken up into modules a tad more, the one that we require for rspec to run correctly ‘autorun’ is not included by default, so to solve this simply add require ‘rspec/autorun’ to the top of your spec_helper.
Can’t see this Gist? View it on Github!
The latest @rubyfive podcast is up, our own @sj26 receiving a mention for Ruby 1.9.3 performance improvements. http://t.co/hfx3EPMz
@frontiergroup about 4 days ago #