March 25th, 2008 at 10:31 pm
(Rails)
Remember all that joy coding with Rails when you were a wee lad? Things seemed so blissful then, metaprogramming voodoo and that complex object relational mapping stuff were all taken care of behind the scenes.
Alas, whence it doth time to unleash your brilliant social networking app onto the unsuspecting public, your Ruby/Rails world came crashing down faster than FSJ can order a chai latte.
FastCGI, SCGI, Mongrel, Rack, Thin, Pound, Nginx, Apache.
Doing a virgin Rails application deployment would have been a trial by fire where you’ll trawl the Ruby and Rails forums looking for advice on which webserver is best suited to serve your future web application superstar or pray to the One and just deploy on faith.
You’ll settle for Mongrel or Rack if you were lucky enough to come across people who have been there before. Otherwise, be prepared to be regaled with war stories about how some web hosts *COUGH* Dreamhost *COUGH* arbitrarily shutdown your Rails processes for consuming a tad too much resources.
Wouldn’t it be nice if I could just do like what I did for PHP applications? Just upload the files onto the webserver and it just works(tm)?
Now you can! Well, technically only the people at Phusion can at this moment. Lai Hongli breaks the news about modrails, complete with requisite cool screencast.
I think this is a really cool development that makes life a whole lot simpler for people who just want to focus their energies on actual development rather than have to worry about how to configure the deployment environment properly. Even if this is Apache2 only now, it should be possible to port it over to other servers like Nginx, licence restrictions notwithholding.
1 Comment
August 11th, 2007 at 12:54 pm
(Behaviour Driven Development, Rails, Ruby)
Chris Wanstrath has written about making Rails fixtures less painful than they need to be with the FixtureScenarios plugin. Personally, I prefer the Factory approach, nicely explained by Daniel Manges.
I've been using factory methods to create in-database ActiveRecord objects for a project that I've been working on in Bezurk. Reading Daniel's article gave me a few ideas on improving the way I create fixtures and mocks. Since I've been using RSpec extensively in this project, I'll present the examples in RSpec.
As the models evolve with the design and its behaviour change accordingly, there is a need to go through all the specifications that create this model and make sure that its created in a valid state. This is more pronounced with the use of test doubles, the test doubles also need to have its method stubs changed to reflect the latest state of the model that its is representing. I happen to make much use of test doubles for test isolation, so trying to manage all these objects became an exercise in patience. As it was getting painful, It's time to change the way I create these models and test doubles.
As always, a layer of indirection will always go some way to solving a software problem. We introduce a Factory that encapsulates the creation of ActiveRecord objects by providing creation methods.
RUBY:
-
module FixtureFactory
-
def create_user(attributes = {})
-
User.create!(ModelAttributes.user(attributes))
-
end
-
end
We'll have a Factory for test doubles too.
RUBY:
-
module MockFactory
-
def mock_user(method_stubs = {})
-
mock_model(User, ModelAttributes.user(method_stubs))
-
end
-
end
And the attributes for this model will be declared in a module that's used by both Factories
RUBY:
-
module ModelAttributes
-
def self.user(attributes)
-
attributes.reverse_merge({:name => 'doug'})
-
end
-
end
The Factory modules are then included in Spec::Runnner
RUBY:
-
Spec::Runner.configure do |config|
-
include FixtureFactory
-
include MockFactory
-
end
The objects can now be created using the factory methods available to all specifications.
RUBY:
-
doug = create_user
-
doppelganger = mock_user
Update
Added links to Chris Wanstrath and Daniel Manges' articles on managing Rails fixtures.
Comments
April 5th, 2007 at 11:34 pm
(Rails, Ruby)
The next singapore.rb meeting will be held on the 19th of April 2007 in the Central Lending Library. The National Library Board of Singapore has kindly provided the use of one of their meeting rooms (complete with WIFI). The (tentative) agenda for the meeting is as follows:
7:00pm Rails Plugins Showcase: Dead simple AJAX and Form testing in Rails - Choon Keat
7:30pm FxRuby and ScreenSvr - Sausheong
8:00pm Q&A, discussions
8:30pm End of meeting
My thanks goes out to the NLB's Ivan Chew for facilitating the use of NLB facilities for a trial session, as well as to Choon Keat and Sausheong for making the presentations.
Comments
January 11th, 2007 at 10:26 am
(Rails, Ruby, Software Development)
The Rails Podcast has an excellent interview with Josh Shairbaum and Dan Manges from JP Morgan on using Rails in the enterprise. Do check it out if you're at all interested in introducting Ruby/Rails to your particular company.
Listening to Josh and Dan made me realise that I'm quite fortunate to be working in a company where there are no corporate traditions to follow when it comes to technology. I've developed 2 applications for use by staff and clients alike so far and they're both powered by Rails. Being the sole developer in my company, Rails is a perfect fit and this combination has shown its worth.
Josh mentioned that his development team of 3 got Rails in the door by using it to develop a reporting application, an app where the implementing technology was not a big issue with corporate managers. By having the reporting application running AND available to end users within 1.5 months demonstrated the productivity gains that can be achieved by Rails. A lot of evangelizing and demonstrations were done to help their cause too. I think that they benefited a fair bit from having key people in other functional units willing to give Rails a try, even though it required them to risk doing something that's new and by corporate definition, risky.
It's encouraging to listen to them and their passion for Rails was apparent in the way they talked about and how they dealt with people who did not understand what it was.
Comments