ask the manowar fan
Showing posts with label Rails. Show all posts
Showing posts with label Rails. Show all posts

I'll let Yehuda explain the whole deal to you, how Rails 3 and Merb 2 will be the same. Why? Well, he's also doing it and I'm a nice guy dude, give credit where it is due.

What does that mean though?

I'll quote qwantz here, "like ants combining to form the shape of a giant ant"



I hope everyone feels as positively as I do about this.

 

Rails 2.2 thread safe.

Oh man, this should be awesome.

Of course it only helps in certain situations, this will not guarantee your app running on steroids.

Shit like MERB might though.

 

In Rails you ought to look at before_save as your slightly bad ass friend, who you won't give control of your assets to.

You might think that's a bad analogy. When in fact it's not. Bear with me.

Truth/Sane part of analogy:

Don't modify your objects in an before_save hook. In any way, small string manipulation, prepend a dollar sign. Any of that, in any way. Of course, this argument is only valid if you're going to add validations on that object on those fields.

Example:


class Thing
before_save :underscore_most_special

private

def underscore_most_special
name.gsub!(/[-_/]/, '_')
end

end


This is all cool right, well let's say now you throw in a validation.


class Thing

before_save :underscore_most_special
validates_uniqueness_of :name

private

def underscore_most_special
name.gsub!(/[-_/]/, '_')
end

end



class ThingTest

def test_name_should_be_unique
Thing.create!(:name=>"rambo")
assert_equal false, Thing.new(:name=>"rambo").valid?
end

end



Of course this test will pass, what test won't pass on the other hand which I didn't write on the first go is.


def test_name_should_be_unique
Thing.create!(:name=>"rambo-the-dude")
assert_equal false, Thing.new(:name=>"rambo-the-dude").valid?
end


Any guesses why?

The thing that's saved is saved with underscores, and the thing that's wants to get saved is being compared with hyphens. Later on get's saved with underscores. And you end up with duplicates.

So what's the solution. Don't use those AR hooks? Hell no, hooks are awesome! Use before_validates.

 

Rails fields_for is the cheese

Posted In: , , . By Sid

The reason I really really dig the Rails fields_for helper is this reason:


<%= fields_for "parent[child_object_name][]", child_object_instance do |f| %>
<%= f.text_field :attribute%>
<%end%>


Generates ...


<input id="parent_child_object_name_#{child_object_instance.id}"
name="parent[child_object_name[#{child_object_instance.id}]]" />


In fact you could even try ...


<%= fields_for "parent[child_object_name][]", child_object_instance do |f| %>
<%= f.text_field :attribute, :index=>child_object_instance.name%>
<%end%>

<input id="parent_child_object_name_#{child_object_instance.name}"
name="parent[child_object_name[#{child_object_instance.name}]]" />


This really helps when you're trying to pump in or edit a complicated object graph through a form that was originally designed for a single model. I love this approach because it saves me the trouble of having to initialize my objects in my controller actions in accordance to the way the form was designed just so Rails can populate the fields with the right values.

There's also a cool RailsCast about using fields_for in comlex forms.

 

Dr. Nic talks about TDD'ing JavaScript and using autotest for JavaScript on Rails

We all know I have a JavaScript fetish :D And one for TDD.

"Black-hearted devil honey,
With a touch of high class"
Eagles Of Death Metal - Eagles Goth

 

Rails 2.0 is here

Posted In: , , . By Sid

No really, Rails 2.0 is here

*Jumps up, screams, runs around for a while with arms flailing in the air whilst sweating like a sprinkler. Assaults a two headed-lion, wins the battle, overthrows Ceaser (that little shit), ruins the Kingdom in general, runs into the wall of A-201, breaks the door of the Bossini showroom at Commercial Street in Bangalore. Barks for a day, sits down and installs Rails 2.0 ... because it's supposed to be that damn awesome (seriously read the new features they've pumped in, they even made fixtures better)*

 

You have a textarea and you're rendering the text you get from it on a page.

Textarea Input:

This is on the first line.

This is on the second line.

This is on the third.

Browser Output:

This is on the first line.This is on the second line.This is on the third.

Now that sucks.


@string = $F(TextAreaId).value
@string = CGI.unescape(@string).gsub(/\n/,"<br />")


And you're done!

PS: $() is prototype.js for getElementById()

"They make you drink your blood,
and tear yourself to pieces!"
Accept - Balls To The Wall

 

Okay so you've all heard about the miracle of birth right?

Then again you haven't heard about the miracle of refactoring have you?! Yup, I'm going to tell you all about it now.

Or put up some links so you could just experience the niceness of it all.

There's a nice book on Refactoring Ruby that I want to read.

There's a couple of RailsCasts on refactoring I'm downloading as we speak.

Cheers to better, cleaner, more readable, faster way more kickass programming.

"Put an end to their fascist laws"
Six Feet Under - Victim Of The Paranoid

 

Usually on a Ubuntu install you install rails via


sudo gem install rails


But, sometimes this leaves the symlinks in the vendor/plugins folder broken. You fix it as follows


sudo apt-get install rails


Who'd have thought you need to both eh? Well, the new Rails install guide for Ubuntu Fesity fawn tells you to do so, but not why.

Anywho, if you need by any chance to downgrade a version like I did. Apparently rake tasks that use ActiveRecord objects don't work quite well on Rails - 1.2.2 so I had to go down to Rails - 1.6.6


sudo gem install rails -v1.6.6


Go to http://packages.ubuntu.com and get the specific version of Rails from there.

EDIT:

The reason for this is, by default your server will first look for Rails inside your MY_APP/vendor folder, and since those symlinks are broken will complain since an install using gem doesn't put Rails inside the /vendor folder, it only creates symlinks.

A fix is just to delete what's in the MY_APP/vendor folder.

"Deadringers, Warmongers, Hypocrites,
Masquerade in Blood."
Sodom - Masquerade in Blood

 

Here's the shakedown, both essentially do the same thing, they take what's in the ActiveRecord, use the Model and take the information back to the database but there's one very important difference between the two.

Save incorporates all your filters (validates_uniqueness_of etc.) but update does not. So you say, oh pishaw big bloody deal! Well, I'll why this really is a big deal ...

Say you have a Model and a filter


my_models (
id int,
number int,
name varchar(200),
status boolean
)

validates_uniqueness_of :number, :scope=>:status


What this does is, is asserts the uniqueness of the combination of 'number' and 'status'. Yeah, yeah Mr. Fan, Manowar get on with it.

So you have a delete method which goes:


@model=MyModel.find(id)
@model.status=0
@model.save


Now, we assume that there is another entry into the my_models table which has the same 'number' as the entry we're trying to update but a different 'status' say false. And on deletion we're setting this 'status' attribute to false. The point to note is that the save method will fail on the validate_uniqueness_of callback filter, but it will fail silently, and that my men is what introduces a bug.

Use update in scenarios like that, it works out well.

"13, 13, 13,
Steps to nowhere"
Pantera - 13 steps to nowhere

 

Blood and Wine

Posted In: , . By Sid

Interpreting the Rails Logs

You know how they say one man's blood is another man's wine. Well a while ago, I hated logs. Now I drink them dry.

 

Rails and Scaling

Posted In: , , . By Sid

Okay, so I love Rails. But, Rails has an issue with scaling. A fresh install of Rails for instance comes with sessions implemented in the file system. That's all well and good for a development box, the issue arises when you're serving more than a small number of clients.

Serializing data shared by processes in a file is doable. You can use identity stamps and all that jazz, but it slows things down I imagine.

So the alternative is using my favourite ... tables! Or in our case ActiveRecord, the layer of ORDBMS on top of your database.

It's quite simple. All you need to do is find this line in your config/environment.rb and uncomment it.





After this is done, set up the tables by running.


rake db:sessions:create
rake db:migrate

Toggle the code!

Update:

Alrightie then, first rule of entrepreneurship, don't believe in technology (hype). Hmmm, so the ActiveRecord method of storing sessions that Rails ships with is not so good.

Rails is excellent to say the least in the development environment, but production on the other hand involves a lot of fun.

Right now, I'm going to settle for a 60GB hard-drive 1GB memory 15 inch wide screen Xubuntu production box.

Also, for production sake, the alternative's to the ActiveRecord method of storing sessions; you could use SQLSessionStore for sessions, or better still the better performing memcached.

I'm reading this article on how to deploy Rails on a mongrel cluster and Apache.

 

You need to have installed the ActionMailer before doing this. You can do this by running:


gem install actionmailer


How to set up actionmailer to use a GMail account

Setting up ActionMailer for Ruby on Rails

"welcome in the visitors"
Lamb Of God - Terror And Hubris In The House Of Frank Polard