Posted in August 2010

Rails Host Review – (the bad) HostingRails

I am currently working on a project for the City of Edmonton’s Apps4Edmonton contest.  When we initially started looking for hosts we made the decision that we would use a cheap host for our initial deployment, and then migrate over to something faster when it was justified.  Our site Alertzy is mostly a web portal for people to configure settings for text messages, so we didn’t expect the load to be high.

After looking through the available options, we initially decided to go with www.hostingrails.com.

HostingRails Review

At the risk that some might not read this entire review, I’ll summarize our experience here:

Pros: Friendly, fast support.  Very Cheap.

Cons: Painfully poor server performance.  False advertising on website.  Bad upgrading support.  Outdated support articles.  Blacklisted IP’s for e-mail.

We initially went with Hosting Rails’ Shared hosting option.  For $8 we got 10 GB of space, 100 GB, and migraines.  The initial sign-up process was unexceptional, but things went downhill from there.  We naturally went to Google and searched for articles on deploying a Rails application onto hostingrails.com, and quickly found an article on hosting rails wiki “How to deploy a Rails application on HostingRails.com”.  Unfortunately this article which was the first hit on google is archaically out of date, and we wasted hours trying to get its procedure to work.  We created a support ticket for help with a step of this procedure, and this was our first experience with the knowledgable, fast, and friendly support.  We were quickly straightened out, and started working through the much easier and up to date process in the more hidden article on their wiki “How to deploy a Rails app with Passenger”.  

With this updated procedure in hand and the occasional promptly answered support ticket we soon had our application online (I should point out that this great support response was happening at 4 in the morning on a Saturday night!).  Unfortunately this accomplishment only led us to experience more issues.  It was quickly apparent that the performance of the server just wasn’t going to cut it.  At times the site was snappy, but at other times a page load could take upwards of 20 seconds.  As this is shared hosting some performance variance is to be expected, but this was well beyond acceptable.  

Continuing our deployment (with our fingers crossed that performance would improve once passenger got up to speed), we then worked on deploying e-mail.  I configured SPF and domain keys to try and ensure our outgoing e-mails wouldn’t end up in junk bins, but unfortunately despite both of these passing, our e-mail was still getting junked on gmail.  Having a bad feeling about this I performed a blacklist search on our IP address, and sure enough it was blacklisted.  We created a support ticket, but unfortunately received a very apathetic response:

We can request a removal from the blacklist, but due to compromised accounts and other customers sending spam, the blacklist is almost always reinstated shortly after having it removed.

Being the resourceful chaps we are, we moved our e-mail over to Google Apps, and kept on moving along.  Finally we had our application fully deployed, but had to come to the conclusion that the performance on the shared server wasn’t going to cut it, and that we’d need to move to a VPS to avoid being embarrassed at our site’s speed.  At this point we could have looked at other hosting options, but we had been very impressed with the support thus far and were convinced that VPS would solve our performance problems and we could move on.  

We were very optimistic about the migration to VPS, as hostingrails.com states on their site they are “experts in scaling Rails applications from shared to VPS and multi-server dedicated environments”.  They also state they provide a “Ruby on Rails Image Ready to Roll”, which had all the software we would need pre-installed.  Unfortunately both of these statements turned out to be false.  

After a painful account upgrade process with broken e-mail confirmation links and confusing billing we finally got a server online, only to find that it was a completely blank CentOS install with none of the functionality we had been told would be present.  At this point our shared hosting was already down, so we were understandably anxious to get our site back online.  We sent in another support ticket (about our 5th of the migration process) asking where the stated functionality was.  We patiently waited about an hour with no response, and found that our support request had been escalated to a level 2 request.  Deciding that no response would likely be forthcoming until morning we decided to call it a night.

In the morning we did in fact get a response, but it was not what we were hoping for.  

I apologize for the inconvenience, but the VPS Rails image that was used previously has become very out of date and is no longer offered the image that is currently on your VPS is the standard image all VPS accounts receive

At this point we had had enough.  We picked up our bags and decided to move elsewhere.  This time we did better research before choosing a host, and ended up at Slicehost.  I will do a follow-up post with a review of our experiences on Slicehost once we have been there longer, but so far the experience has been a dream relative to our nightmare with HostingRails.

 

[update] HostingRails.com has since removed the Ready to Roll image from their list of features; likely do to our experience.

Tagged , , , , , , , , , , ,

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 , , , , , , , , ,

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 , , , , , , ,

Ruby on Rails – Default Text Field Text That Clears On Click

I’m going to try using posterous’s code tags to make my first code post on this blog.  Bear with me if things don’t work out perfectly.

The designer on a project I’m working on (www.alertzy.com) wanted to have the effect where there is default text inside a text field, but it clears once the user clicks in the box.  The effect looks like this, before and after a user clicks on the text field (thanks to www.meshcanada.com for this example):

Beforeclick
Afterclick

As I am building this project in Ruby on Rails, I decided to write a simple helper to accomplish this behavior.  The helper itself is pretty straightforward, and I’ll leave dissecting the code as an exercise for you.  If you have any questions or suggestions for improvement feel free to post them in the comments.  Place this code in your application_helper.rb file in your Rails project.

  def default_text(text)
    onFocusFunction = "field = event.target || event.srcElement; if (field.value=='#{text}') {field.value = '';}else {return false}"
    onBlurFunction = "field = event.target || event.srcElement; if (field.value=='') {field.value = '#{text}';}else {return false}"
    {:value => text, :onfocus => onFocusFunction, :onblur => onBlurFunction}
  end

Then in your views you can simply call this helper function in the parameters of a field to add this behavior.  Here is an example for a text field for the users username which will display the text “Login” in the field.

<%= text_field_tag 'login', @login , default_text("Login")%>

The end effect of this will look like this:

Helperbeforeclick
Helperafterclick
Happy Coding!

Update August 20th/2010: It was brought to my attention that this helper wasn’t working in Internet Explorer.  This is because IE uses event.srcElement instead of event.target.  The code in this post has been updated to reflect this and should now work cross-browser.

Update August 28th/2010: I had forgotten that this functionality has been added to text fields in HTML 5 under the attribute “Placeholder”.  This technique is still useful for getting this functionality in non-HTML 5 compliant browsers.

Tagged , , , , ,

Hulu seems to be working in Canada

Yesterday I was experimenting around with different proxy software, which I use to allow me to watch Hulu in Canada despite their attempts to block it based on IP address.  I was very surprised to discover by accident that even without my proxy running, I was still able to connect to, and watch content from Hulu from my Canadian address.  I have had a few friends try this, with similar results.  I encourage everyone to go and give it a shot, because Hulu has some great content, and it would be great if we could get this content in Canada without having to jump through the hoops.

Update (August 7th 2010):  Unfortunately this window seems to have been closed.  Hulu cut me off about 2/3 through a program, and doesn’t seem to be allowing us to watch shows anymore (without going through hoops anyways).

Tagged , ,