Tagged with Ruby …

Oct 18 2014
Leave a comment
Ruby

Rails Composer – Easily setup a new rails project

I can’t even count the number of rails projects I’ve created over the last five years. For a while I’ve been using the site RailsWizard to take away some of the drudgery of setting up the typical gems I like to work with. Recently someone introduced me to an alternative called Rails Composer.

If you end up on their website it can be difficult to figure out that the functionality they offer is actually free. You can find it, however, if you go to the projects repo page on GitHub. The money line is this:

$ rails new myapp -m https://raw.github.com/RailsApps/rails-composer/master/composer.rb

I suggest you give it a shot. So far it looks really promising to me.

Tagged , , , ,
May 25 2014
Leave a comment
Ruby

Create RVM gemset along with .ruby-version and .ruby-gemset

Usually when I start a new project I want to create a new gemset along with the .ruby-version and .ruby-gemset files in the project directory. Inevitably I’ve since forgotten the syntax and spend 5 or 10 minutes trying to track it down. To save me that time I’m going to record the command here so I know where to find it next time I need it:

➜ rvm --ruby-version use [ruby version]@[gemset name] --create
Tagged , , , ,
Sep 06 2010
Leave a comment
Uncategorized

Rails Host Review – (the good) SliceHost

As I explained in my earlier post berating HostingRails, I built a project for the City of Edmonton’s Apps4Edmonton contest in Ruby on Rails called Alertzy.  In order to make our project live, we needed to find a host for it.  Our initial host fell incredibly flat, so in our second iteration we made sure to perform more research into our available options.  We were initially looking for what I would call a “Rails Host”, as in a hosting provider who gives you an out of the box solution ready for rails hosting.  Under this criteria we found a few potential options, but then we stumbled upon SliceHost.

SliceHost Review

I’ll summarize my impressions of slicehost here:

Pros: Very fast setup, very good performance, very professional

Cons: Start from a blank image on a VPS

Our intention was not to use a VPS provider who didn’t provide an out of the box rails compatible solution.  The reviews for SliceHost, however, were just too good to ignore.  All the reviews which we were able to find for this hosting provider were positive, so we decided we had to give them a shot.

It is important to understand that SliceHost is not so much a Rails hosting provider, as a generic VPS hosting provider.  They simply provide you with a “slice” which has certain performance metrics and a blank OS install on it, and then it is up to you to configure the server to do what you would like it to do.  This has the advantage of complete freedom (SliceHost would prove as effective a PHP host as they are a Rails host), but comes at the cost of configuration.

With our decision to give SliceHost a try, we proceeded to go through SliceHost’s registration and payment process.  Their cheapest slice starts at $20, but we opted to go for their $25 plan which got us 384 MB of RAM, 15GB of storage, and 225GB of bandwidth.  For some reason we flagged something in their system and had to go through an additional verification step.  This process was completed promptly by SliceHost, and our account was online and operational within 45 minutes of the start of the process.  

With our account in place we now had access to their control panel, where you are able to configure your DNS as well as choose an operating system for your Slice and launch it.  The speed with which a new slice comes online impressed me greatly.  From the time of choosing the operating system and launching it, it takes only ~20 seconds before you are ready to start connect to and start configuring your slice.

Unfortunately the next step of this process involving configuring our Slice to run Rails proved to be very difficult.  This was in no way SliceHost’s fault as this process is exactly the same as configuring Rails to run on any system, but the convenience of having a ready made image to use would be an advantage of using another Rails specific host.  The tutorials that I was able to find for configuring Rails to run on a SliceHost VPS were out of date and didn’t work with the more recent versions of Ruby and Rails.  (I will try and put a tutorial outlining my own experiences online in the near future).  I opted to use Capistrano and Deprec to deploy Rails on the new server, and due to the same shifts in versions this proved to be quite a headache to deploy on the Ubuntu 10.04 server we had opted to run.  It took me approximately 10 hours to resolve all the bugs in the deprec scripts to where the deployment could fully run.

Once I had Capistrano and Deprec functioning I was able to deploy our site to SliceHost.  Finally being able to access our site on a good host with great performance was more than sufficient reward for the past day of struggle deploying Rails!  The difference between HostingRails and SliceHost was truly night and day, and we’ve received very good feedback on the responsiveness of our site. 

In conclusion, I had a hard time deploying Rails, but in no way was this the fault of SliceHost.  In everything that is their responsibility, SliceHost has so far delivered either up to, or more often exceeding my expectations.  I intend to use them as my default host for similar projects going forward.  If you would like to check the responsiveness of our site, go check out www.alertzy.com which is running off our slice.

Tagged , , , , , , , , , , , , ,
Aug 20 2010
7 Comments
Uncategorized

Ruby on Rails – Disabling a select tag using the select helper

There is a bit of a subtlety to this, and it took me a while to figure this out. If I used the select_tag helper I was able to disable the select menu, but using comparable code with the select helper it wouldn’t be disabled.

<% options= ['one', 'two', 'three', 'four'] %>

<%= select_tag :content, options_for_select(options), :disabled => true %>

<%= f.select :content, options, :disabled => true %>

Here my select_tag would be disabled like I wanted, but the f.select would not be. This made me quite perplexed, and with more research I discovered it’s because the “disabled” option for the select helper has been mapped to allow the developer to disable specific elements. For example, this code similarly yields differing behavior:

<% options= ['one', 'two', 'three', 'four'] %>
<% disabled_options= ['two', 'four'] %>

<%= select_tag :content, options_for_select(options), :disabled => disabled_options %>

<%= f.select :content, options, :disabled => disabled_options %>

In the case of the select_tag helper, the menu is still disabled as the disabled_options array will evaluate to true. For the select helper, however, the disabled_options array will tell the helper to set the options that match elements of the array to disabled. This is where I remained stuck for a while, not being able to figure out a way to use the select helper to disable the menu. Then looking more closely at the API documentation, I noticed a difference between the two helpers.

select_tag(name, option_tags = nil, options = {})

select(object, method, choices, options = {}, html_options = {})

The select helper has an additional set of parameters called “html_options” after the options. The select_tag helper conversely simply uses any parameters in its options array that don’t match expected options as html attributes. Based on this I wondered if I passed a hash array for the options parameter, if I could explicitly pass disabled as an html option, as follows:

<% options= ['one', 'two', 'three', 'four'] %>

<%= select_tag :content, options_for_select(options), :disabled =>true %>

<%= f.select :content, options, {}, :disabled => true %>

Sure enough this worked, and gave me the same behavior for both helpers! I was quite surprised to find such inconsistent behavior for these two helpers. It was reminiscent of my experiences with PHP and I’m disappointed to see it here in the Rails API. I would be curious to hear an explanation for why these two helpers are so different.

Happy Coding!

Tagged , , , , , , , , ,
Aug 20 2010
Leave a comment
Uncategorized

Ruby on Rails – Nested Object Forms using a :belongs_to association

In a project I am currently working on, I have a one-way relationship using a belongs_to association.  I wanted to use the newer Nested Object Forms functionality added in Rails 2.3 to allow me to modify the properties of the related object in one form.

For the purposes of this post I’m going to use the following simplified code:

#address.rb
class Address < ActiveRecord::Base
  attr_accesible :address_string
end

#user.rb
class User < ActiveRecord::Base
  attr_accessible :name

  belongs_to :address
  accepts_nested_attributes_for :address
end

I ran into an issue when I was testing out this functionality in script/console and trying to assign attributes to the address through the user. I would encounter the error “WARNING: Can’t mass-assign these protected attributes: address_attributes” in my development.log. I proceeded to try and google a solution to this problem, and found many posts from users which encountered this issue, but none of them provided a solution. It appeared many people simply abandoned attempting to use nested attributes with a :belongs_to association. The solution to this problem is actually quite simple (once you know it!). Here’s the console log and the database log from my initial attempt:

#script/console
>> user = User.first=> #<User id: 1, name: "Bill", address_id: 1, created_at: "2010-08-20 21:49:52", updated_at: "2010-08-20 22:06:37">
>> params = {:address_attributes => {:address_string => "Up the tree", :id => 1}}
=> {:address_attributes=>{:address_string=>"Up the tree", :id=>1}}
>> user.update_attributes(params)=> true
>> user.address=> #<Address id: 1, address_string: "down the street", created_at: "2010-08-20 21:49:53", updated_at: "2010-08-20 21:49:53">


#development.log     
WARNING: Can't mass-assign these protected attributes: address_attributes

Note that the console even returns true from the operation, but the update address attributes aren’t assigned and the string is still “down the street” instead of “Up the tree” that we were trying to assign. The solution to this problem is to make sure that address attributes are added to the attr_accesible in the user model:

#user.rb
class User < ActiveRecord::Base
  attr_accessible :name, :address_attributes
  belongs_to :address
  accepts_nested_attributes_for :address
end

Now the error will no longer occur, and the address will be succesfully updated, as in the following console log.

#script/console
>> user = User.first=> #<User id: 1, name: "Bill", address_id: 1, created_at: "2010-08-20 21:49:52", updated_at: "2010-08-20 22:06:37">
>> params = {:address_attributes => {:address_string => "Up the tree", :id => 1}}
=> {:address_attributes=>{:address_string=>"Up the tree", :id=>1}}
>> user.update_attributes(params)                                               => true
>> user.address=> #<Address id: 1, address_string: "Up the tree", created_at: "2010-08-20 21:49:53", updated_at: "2010-08-20 22:41:46">

I hope this post can help save some time for others who run across this same issue.

Happy Coding!

Tagged , , , , , , ,