Stephan Wehner | 1 Feb 01:05 2007
Picon

Re: Dynamic selects won't fire events in some cases


Stephen Gerstacker wrote:
> I'm ripping my hair out this one.
> 
> I have two select boxes.  Both have an 'observe_field' on it.  The first
> select box, when changed, will clear the second select box and, if it 
> needs
> to, adds new options to the second select box.  The second select box, 
> when
> changed, will grab a number from the database and put it in a text box.
> 
> This all works great, except for the following circumstance.
> 
> 1. The second select box is changed to the second option in the list, 
> The
> text box is updated.
> 2. The first select box is changed to another option, clearing the 
> second
> select box.
> 3. The first select box is changed to the first option it was on, 
> filling
> the second select box with options, with the first option in the list
> showing.
> 4. The second select box is changed to the second option in the list.
> 
> Nothing happens.
> The 'observe_field' never fires.
> 
> After that, if I pick different selections in the list, it works fine. 
> So
(Continue reading)

Robert Head | 1 Feb 01:10 2007
Picon

Re: Storing ActiveRecords in the Session


Ezra Zygmuntowicz wrote:
> 
>    def current_user
>       <at> current_user ||= session[:user_id] ? User.find_by_id(session
> [:user_id]) : nil
>    end
> 
> This will cache the the user in  <at> current_user so you can call
> current_user multiple times during a request and it will only hit the
> db once.
> 
> -- Ezra Zygmuntowicz

I'll try that again, but, IIRC, the last time I tried it, I was getting 
marshaling problems when saving the object for some reason.

Thanks.

--

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

(Continue reading)

Robert Head | 1 Feb 01:13 2007
Picon

Re: loading ActiveRecords only once per page


Ezra Zygmuntowicz wrote:
> 
>   If you just stroe the id in the sessions then you can write a method
> that will let you call that object multiple times per request with
> only one call to the database. The typical example is current_user:
> 
>    def current_user
>       <at> current_user ||= session[:user_id] ? User.find_by_id(session
> [:user_id]) : nil
>    end
> 
> HTH
> 
> -- Ezra Zygmuntowicz

Thanks!  I should have put that in the list of things I've already tried 
(got marshaling problems when saving the object), but I'm definitely 
going to give it another go.

Cheers,
rob

--

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@...
(Continue reading)

John | 1 Feb 01:16 2007
Picon

Re: What should I ask for an hourly rate ?


The rule of thumb for working out an hourly rate is to take your current 
yearly salary, or the salary you would like to have, and divide it by 
1000. Thus a annual salary of $93000 per year becomes an hourly rate of 
93 dollars. This is supposed to take into account considerations of sick 
leave, and time off between contracts, as well as some of the costs 
involved in being a private contractor.

If you are running a business with staff costs and other overheads, then 
you'll need to factor those in to the equation.

--

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Ezra Zygmuntowicz | 1 Feb 01:29 2007
Picon

Re: Storing ActiveRecords in the Session


On Jan 31, 2007, at 4:10 PM, Robert Head wrote:

>
> Ezra Zygmuntowicz wrote:
>>
>>    def current_user
>>       <at> current_user ||= session[:user_id] ? User.find_by_id(session
>> [:user_id]) : nil
>>    end
>>
>> This will cache the the user in  <at> current_user so you can call
>> current_user multiple times during a request and it will only hit the
>> db once.
>>
>> -- Ezra Zygmuntowicz
>
> I'll try that again, but, IIRC, the last time I tried it, I was  
> getting
> marshaling problems when saving the object for some reason.
>
> Thanks.
>

	Don't save the whole object thats the entire point. Just save the  
objects id in the session. That method will use the id to do a db  
lookup and then cache the results.

-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
(Continue reading)

Stephan Wehner | 1 Feb 01:46 2007
Picon

Re: The speed of Rails


> 
> What I am really looking for is a host to use once I have the
> application finished, I can run and test the application on my computer,
> so that's not a problem. I need a reliable host that I don't need to
> worry about switching from whenever I do start getting bigger traffic.

You could try dreamhost.com - with a coupon you might just spend $10 for 
the first  year. Search google from dreamhost coupon. There is a 
dreamhost wiki with Rails deployment tips.

Stephan

--

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Josh Gilman | 1 Feb 01:46 2007
Picon

Re: The speed of Rails


David Harkness wrote:
> Josh Gilman wrote:
>> I am still kind of "playing" around with Rails, although I have plans of 
>> deploying the current website I am creating once I finish it. I don't 
>> expect too much trafic, but I mean there are going to be a lot of people 
>> searching through hundreds of articles and I don't want it taking 10-15 
>> seconds every search. It's not really traffic I am worried about, just 
>> the speed of the things the site is doing. This will me my first rails 
>> application deployed.
> 
> I'm sure you've thought of it, but the only time I've had a slow system 
> (without  heavy traffic), is improper use of the joins, or not using 
> eager loading.
> 
> 
> For Example,
> 
> Myobject.find(:all,:include=>'childtable')
> 
> One of the big things, is that rails makes it easy to do something this
> 
> <%=Myobject.childtable.full_name-%>
> Doing that 500 times in a view, will make 500 database calls unles you 
> use eager loading.

What does:

Myobject.childtable.each {}

(Continue reading)

Philip Hallstrom | 1 Feb 02:06 2007

Re: The speed of Rails


>> I'm sure you've thought of it, but the only time I've had a slow system
>> (without  heavy traffic), is improper use of the joins, or not using
>> eager loading.
>>
>>
>> For Example,
>>
>> Myobject.find(:all,:include=>'childtable')
>>
>> One of the big things, is that rails makes it easy to do something this
>>
>> <%=Myobject.childtable.full_name-%>
>> Doing that 500 times in a view, will make 500 database calls unles you
>> use eager loading.
>
> What does:
>
> Myobject.childtable.each {}
>
> Do? I thought it would just query the database once, grab all the
> results, and loop through them.

Right, but that's not exactly what the parent meant. Consider...

model... Person has_one Address

controller....  <at> people = Person.find(:all)

view....
(Continue reading)

R Mason | 1 Feb 02:41 2007
Picon

Question I don't know how to summarize for the subject field


Let's say I have a model Poll which would have multiple Options.  For
each Option a User can vote.

Let's say in my particular case, certain Options are recurring.  To save
database space, recurring Options such as "Yes" or "No" or "Maybe" are
stored once and then joined accordingly to relevant Polls..  This makes
a HABTM setup better than a has_many setup (or at least I think it does)
so:

Poll < ActiveRecord::Base
  has_and_belongs_to_many :options
end

Option < ActiveRecord::Base
  has_and_belongs_to_many :polls
  has_many :votes
end

Vote < ActiveRecord::Base
  belongs_to :option
  belongs_to :user
end

The problem with this setup is that a Vote belongs to an Option, but in
respect to a specific Poll.  If I just were to count the total number of
Votes for an Option normally - like  <at> option.votes, then the total would
be for all Polls combined.  But I need it to be specific to the one Poll
and can't quite figure out the design pattern I should be using.

(Continue reading)

askegg | 1 Feb 02:57 2007
Picon

Re: What should I ask for an hourly rate ?


On Feb 1, 11:16 am, John <rails-mailing-l...@...> wrote:
> The rule of thumb for working out an hourly rate is to take your current
> yearly salary, or the salary you would like to have, and divide it by
> 1000. Thus a annual salary of $93000 per year becomes an hourly rate of
> 93 dollars. This is supposed to take into account considerations of sick
> leave, and time off between contracts, as well as some of the costs
> involved in being a private contractor.
>
> If you are running a business with staff costs and other overheads, then
> you'll need to factor those in to the equation.
>
> --
> Posted viahttp://www.ruby-forum.com/.

While this is a valid method for most people, I found it to be a great
way to limit the amount you can earn - in this case to $93K.

If you are going to ask for an hourly rate make sure you ask enough,
otherwise you will be a slave for hire.  Keep in mind, there is a
judgment of your abilities according to the rate you charge - the more
you charge the more experienced and professional you are.  Low rates
attract people who want work done cheaply, but not professionally.

Another way is to try and gauge how much the work is *worth* to the
client and charge them accordingly.  Sure this is sometimes a harder
sell, but every client has an idea of how much they want to spend on
this problem - the time taken to accept delivery is an evil they would
rather avoid.

(Continue reading)


Gmane