From ws3reg at gmail.com Fri May 11 15:52:15 2007 From: ws3reg at gmail.com (W S) Date: Fri, 11 May 2007 13:52:15 -0600 Subject: [Boulder-Denver Ruby Group] vimrc setup for Ruby? Message-ID: <1837c60e0705111252s3807d97bra1a6861053261c1d@mail.gmail.com> Just curious if anyone uses VIM as their main editor. If so, could you please post your ~/.vimrc? Regards, Will From pjones at pmade.org Fri May 11 15:56:00 2007 From: pjones at pmade.org (Peter Jones) Date: Fri, 11 May 2007 12:56:00 -0700 Subject: [Boulder-Denver Ruby Group] vimrc setup for Ruby? In-Reply-To: <1837c60e0705111252s3807d97bra1a6861053261c1d@mail.gmail.com> References: <1837c60e0705111252s3807d97bra1a6861053261c1d@mail.gmail.com> Message-ID: <20070511195600.GM31550@slim.pmade.com> W S wrote the following on Fri, May 11, 2007 at 01:52:15PM -0600: > Just curious if anyone uses VIM as their main editor. If so, could > you please post your ~/.vimrc? http://pmade.com/svn/oss/rc/trunk/vim/main/vimrc -- Peter Jones http://pmade.com From mghaught at gmail.com Mon May 14 19:00:21 2007 From: mghaught at gmail.com (Marty Haught) Date: Mon, 14 May 2007 17:00:21 -0600 Subject: [Boulder-Denver Ruby Group] BDRG - May Meeting - May 15th Reminder Message-ID: <57f29e620705141600i727e06lcc09262d4634b499@mail.gmail.com> Hi Everyone, Here's a final reminder on our May 15th meeting. We're having it one day early on Tuesday due to RailsConf starting Thursday morning. We'll be starting at our usual time of 6:30pm at Collective Intellect (directions below.) Jay Phillips presenting on Adhearsion which is a cool Ruby framework for integrating VoIP via Asterisk. You can check it out at http://adhearsion.com. Bruce Williams will also be doing a mystery presentation for his last meeting as a Colorado resident. He'll be moving to Austin, TX in June. So come and wish Bruce the best of luck at our May meeting. It is traditional that after the meeting we head over to the Lucky Dog pub down the block. I hope to see you all on Tuesday. Cheers, Marty Directions: Collective Intellect 1414 Pearl St., Suite 200 Boulder, CO 80302 It is located on the East end of the walking mall above a store called "Baby Doll" on the South side. The Collective Intellect name is on the door of a stairway leading up to the office. URL to google maps: http://rubyurl.com/QO7 From jameson.watts at gmail.com Tue May 15 16:55:12 2007 From: jameson.watts at gmail.com (Jameson Watts) Date: Tue, 15 May 2007 14:55:12 -0600 Subject: [Boulder-Denver Ruby Group] Rails send_file... Message-ID: ...anyone have experience waiting for the last bit in a rails send_file call? i.e. Need to verify that a file was downloaded before performing an action. Regards, Jameson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/bdrg-members/attachments/20070515/2f8b55d9/attachment.html From tony at clickcaster.com Tue May 15 17:51:16 2007 From: tony at clickcaster.com (Tony Arcieri) Date: Tue, 15 May 2007 15:51:16 -0600 Subject: [Boulder-Denver Ruby Group] Rails send_file... In-Reply-To: References: Message-ID: I'd say your best bet in this respect is a Mongrel plugin. send_file doesn't block until the transfer completes, but rather instructs the renderer to send a file as the content body. send_file (at least with Mongrel) will read the entire file into memory as it's being sent, so if you're using it for large files you should seriously consider X-Sendfile instead -- Tony Arcieri ClickCaster, Inc. tony at clickcaster.com On 5/15/07, Jameson Watts wrote: > > ...anyone have experience waiting for the last bit in a rails send_file > call? i.e. Need to verify that a file was downloaded before performing > an action. > > Regards, > Jameson > > _______________________________________________ > Bdrg-members mailing list > Bdrg-members at rubyforge.org > http://rubyforge.org/mailman/listinfo/bdrg-members > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/bdrg-members/attachments/20070515/a59250cd/attachment.html From ara.t.howard at gmail.com Fri May 18 16:16:54 2007 From: ara.t.howard at gmail.com (ara.t.howard) Date: Fri, 18 May 2007 14:16:54 -0600 Subject: [Boulder-Denver Ruby Group] re-inventing components Message-ID: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> i'd love feedback from the community http://drawohara.tumblr.com/post/2070878 cheers -a -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama From tony at clickcaster.com Fri May 18 17:19:53 2007 From: tony at clickcaster.com (Tony Arcieri) Date: Fri, 18 May 2007 15:19:53 -0600 Subject: [Boulder-Denver Ruby Group] re-inventing components In-Reply-To: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> References: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> Message-ID: That was my impression of Stencils as well... that it was moving Rails more towards a component-oriented approach, although for whatever reason (DHH?) components have been frowned upon by the Rails community, despite their success in frameworks like WebObjects (which, correct me if I'm wrong, was the first MVC web framework to use an ORM for abstracting the data model). Seems like Rails learned a lot of great lessons from WebObjects, but component-orientation was not one of them. "There is only one controller in effect at a time in Rails and that controller's data is, effectively, global for all rendering actions" This has been a big problem for me, particularly when I'm trying to make reusable, interactive (AJAX) "widgets" that allow you to have the same functionality on multiple parts of the site. A messaging system is one example. Until now the solutions have been "use helpers" or render_component, which seems to be shunned and isn't implemented very well. I'll certainly check out componentry when you release it. There's a few places I could see it being very useful. -- Tony Arcieri ClickCaster, Inc. tony at clickcaster.com 720-227-0129 ext. 202 On 5/18/07, ara.t.howard < ara.t.howard at gmail.com> wrote: > > i'd love feedback from the community > > http://drawohara.tumblr.com/post/2070878 > > cheers > > -a > -- > we can deny everything, except that we have the possibility of being > better. simply reflect on that. > h.h. the 14th dalai lama > > > > _______________________________________________ > Bdrg-members mailing list > Bdrg-members at rubyforge.org > http://rubyforge.org/mailman/listinfo/bdrg-members > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/bdrg-members/attachments/20070518/2dadb80f/attachment-0001.html From pjones at pmade.org Fri May 18 18:41:21 2007 From: pjones at pmade.org (Peter Jones) Date: Fri, 18 May 2007 15:41:21 -0700 Subject: [Boulder-Denver Ruby Group] re-inventing components In-Reply-To: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> References: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> Message-ID: <20070518224121.GB31550@slim.pmade.com> ara.t.howard wrote the following on Fri, May 18, 2007 at 02:16:54PM -0600: > i'd love feedback from the community Ara, this stuff looks pretty good. Like you, I tend to gravitate towards OOP, and it's disappointing that with Rails, MVC is only 1/3 OO. I'm wondering if it's time to rethink ActionController and ActionView a bit. -- Peter Jones - 303-669-2637 pmade inc. - http://pmade.com From david at collectiveintellect.com Fri May 18 21:24:08 2007 From: david at collectiveintellect.com (David Clements) Date: Fri, 18 May 2007 19:24:08 -0600 Subject: [Boulder-Denver Ruby Group] re-inventing components In-Reply-To: <20070518224121.GB31550@slim.pmade.com> References: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> <20070518224121.GB31550@slim.pmade.com> Message-ID: Not sure if I am totally following the issue here. I totally agree with the premise that the support for widgetizing our apps is really ugly. And I use components regularly to widgetize various portions of our apps. Are we talking about syntax or functionality? We could re-write your example today using render_component_as_string: class FooController < ApplicationController def bar # get a handle on, and parameterize, a bar controller bar_controller = component_for(:controller => 'bar') do @foo = 42 @bar = 'forty-two' end # call two actions on the bar controller, potentially reusing the entire model+view+controller stack foo = bar_controller.content_for :action => 'foo' bar = bar_controller.content_for :action => 'bar' render :text => [foo, bar].inspect #=> [42, "forty-two"] end end With this: class FooController < ApplicationController def bar params_hash = {:foo => 42, :bar => 'forty_two'} # call two actions on the bar controller, potentially reusing the entire model+view+controller stack foo = render_component_as_string( params_hash.merge(:controller => "bar", :action => "foo" ) bar = render_component_as_string( params_hash.merge(:controller => "bar", :action => "bar" ) render :text => [foo, bar].inspect #=> [42, "forty-two"] end end Not sure if I am missing something, as I didn't here Bruce's talk last week, Dave On May 18, 2007, at 4:41 PM, Peter Jones wrote: ara.t.howard wrote the following on Fri, May 18, 2007 at 02:16:54PM -0600: > i'd love feedback from the community Ara, this stuff looks pretty good. Like you, I tend to gravitate towards OOP, and it's disappointing that with Rails, MVC is only 1/3 OO. I'm wondering if it's time to rethink ActionController and ActionView a bit. -- Peter Jones - 303-669-2637 pmade inc. - http://pmade.com _______________________________________________ Bdrg-members mailing list Bdrg-members at rubyforge.org http://rubyforge.org/mailman/listinfo/bdrg-members From tony at clickcaster.com Sun May 20 00:51:13 2007 From: tony at clickcaster.com (Tony Arcieri) Date: Sat, 19 May 2007 22:51:13 -0600 Subject: [Boulder-Denver Ruby Group] re-inventing components In-Reply-To: References: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> <20070518224121.GB31550@slim.pmade.com> Message-ID: The issue here really lies in reusable subcomponents of functionality, of any granularity of your choosing (i.e. objects) Presently helpers are your best bet in this respect, but what happens when you have something so complex it needs to retain state? In that case, the procedural approach exposed by the helper API grows increasingly insufficient. - Tony On 5/18/07, David Clements wrote: > > Not sure if I am totally following the issue here. I totally agree > with the premise that the support for widgetizing our apps is really > ugly. And I use components regularly to widgetize various portions of > our apps. > > Are we talking about syntax or functionality? > > We could re-write your example today using render_component_as_string: > > class FooController < ApplicationController > def bar > # get a handle on, and parameterize, a bar controller > bar_controller = component_for(:controller => 'bar') do > @foo = 42 > @bar = 'forty-two' > end > > # call two actions on the bar controller, potentially reusing > the entire model+view+controller stack > foo = bar_controller.content_for :action => 'foo' > bar = bar_controller.content_for :action => 'bar' > > render :text => [foo, bar].inspect #=> [42, "forty-two"] > end > end > > > With this: > > class FooController < ApplicationController > def bar > params_hash = {:foo => 42, :bar => 'forty_two'} > > # call two actions on the bar controller, potentially reusing > the entire model+view+controller stack > foo = render_component_as_string( params_hash.merge(:controller > => "bar", :action => "foo" ) > > bar = render_component_as_string( params_hash.merge(:controller > => "bar", :action => "bar" ) > > render :text => [foo, bar].inspect #=> [42, "forty-two"] > end > end > > > Not sure if I am missing something, as I didn't here Bruce's talk > last week, > > Dave > > > > > On May 18, 2007, at 4:41 PM, Peter Jones wrote: > > ara.t.howard wrote the following on Fri, May 18, 2007 at 02:16:54PM > -0600: > > i'd love feedback from the community > > > Ara, this stuff looks pretty good. Like you, I tend to gravitate > towards OOP, > and it's disappointing that with Rails, MVC is only 1/3 OO. I'm > wondering if > it's time to rethink ActionController and ActionView a bit. > > > > > > > -- > Peter Jones - 303-669-2637 > pmade inc. - http://pmade.com > _______________________________________________ > Bdrg-members mailing list > Bdrg-members at rubyforge.org > http://rubyforge.org/mailman/listinfo/bdrg-members > > _______________________________________________ > Bdrg-members mailing list > Bdrg-members at rubyforge.org > http://rubyforge.org/mailman/listinfo/bdrg-members > -- Tony Arcieri ClickCaster, Inc. tony at clickcaster.com 720-227-0129 ext. 202 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/bdrg-members/attachments/20070519/daa0c777/attachment.html From tony at clickcaster.com Sun May 20 00:53:18 2007 From: tony at clickcaster.com (Tony Arcieri) Date: Sat, 19 May 2007 22:53:18 -0600 Subject: [Boulder-Denver Ruby Group] re-inventing components In-Reply-To: References: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> <20070518224121.GB31550@slim.pmade.com> Message-ID: In specific regard to render_component, Rails components are painfully slow and unofficially deprecated to the point where Rails core is silently threatening to remove them (although they probably won't, due to their utility) Nevertheless, the general vibe is: don't use components, and expect them to go away I think something lighter than an entire instance of ActionController is definitely in order, and specifically something where its creators aren't telling you "Don't use it" - Tony On 5/19/07, Tony Arcieri wrote: > > The issue here really lies in reusable subcomponents of functionality, of > any granularity of your choosing (i.e. objects) > > Presently helpers are your best bet in this respect, but what happens when > you have something so complex it needs to retain state? In that case, the > procedural approach exposed by the helper API grows increasingly > insufficient. > > - Tony > > On 5/18/07, David Clements wrote: > > > > Not sure if I am totally following the issue here. I totally agree > > with the premise that the support for widgetizing our apps is really > > ugly. And I use components regularly to widgetize various portions of > > our apps. > > > > Are we talking about syntax or functionality? > > > > We could re-write your example today using render_component_as_string: > > > > class FooController < ApplicationController > > def bar > > # get a handle on, and parameterize, a bar controller > > bar_controller = component_for(:controller => 'bar') do > > @foo = 42 > > @bar = 'forty-two' > > end > > > > # call two actions on the bar controller, potentially reusing > > the entire model+view+controller stack > > foo = bar_controller.content_for :action => 'foo' > > bar = bar_controller.content_for :action => 'bar' > > > > render :text => [foo, bar].inspect #=> [42, "forty-two"] > > end > > end > > > > > > With this: > > > > class FooController < ApplicationController > > def bar > > params_hash = {:foo => 42, :bar => 'forty_two'} > > > > # call two actions on the bar controller, potentially reusing > > the entire model+view+controller stack > > foo = render_component_as_string( params_hash.merge(:controller > > => "bar", :action => "foo" ) > > > > bar = render_component_as_string( params_hash.merge(:controller > > => "bar", :action => "bar" ) > > > > render :text => [foo, bar].inspect #=> [42, "forty-two"] > > end > > end > > > > > > Not sure if I am missing something, as I didn't here Bruce's talk > > last week, > > > > Dave > > > > > > > > > > On May 18, 2007, at 4:41 PM, Peter Jones wrote: > > > > ara.t.howard wrote the following on Fri, May 18, 2007 at 02:16:54PM > > -0600: > > > i'd love feedback from the community > > > > > > Ara, this stuff looks pretty good. Like you, I tend to gravitate > > towards OOP, > > and it's disappointing that with Rails, MVC is only 1/3 OO. I'm > > wondering if > > it's time to rethink ActionController and ActionView a bit. > > > > > > > > > > > > > > -- > > Peter Jones - 303-669-2637 > > pmade inc. - http://pmade.com > > _______________________________________________ > > Bdrg-members mailing list > > Bdrg-members at rubyforge.org > > http://rubyforge.org/mailman/listinfo/bdrg-members > > > > _______________________________________________ > > Bdrg-members mailing list > > Bdrg-members at rubyforge.org > > http://rubyforge.org/mailman/listinfo/bdrg-members > > > > > > -- > Tony Arcieri > ClickCaster, Inc. > tony at clickcaster.com > 720-227-0129 ext. 202 > -- Tony Arcieri ClickCaster, Inc. tony at clickcaster.com 720-227-0129 ext. 202 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/bdrg-members/attachments/20070519/f863148c/attachment.html From ara.t.howard at gmail.com Sun May 20 09:19:21 2007 From: ara.t.howard at gmail.com (ara.t.howard) Date: Sun, 20 May 2007 07:19:21 -0600 Subject: [Boulder-Denver Ruby Group] re-inventing components In-Reply-To: References: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> <20070518224121.GB31550@slim.pmade.com> Message-ID: <5692C2EB-6FFA-48CC-BEB9-FAF7996425BB@gmail.com> On May 18, 2007, at 7:24 PM, David Clements wrote: > Not sure if I am totally following the issue here. I totally agree > with the premise that the support for widgetizing our apps is really > ugly. And I use components regularly to widgetize various portions of > our apps. > > Are we talking about syntax or functionality? both. > > We could re-write your example today using render_component_as_string: > > class FooController < ApplicationController > def bar > # get a handle on, and parameterize, a bar controller > bar_controller = component_for(:controller => 'bar') do > @foo = 42 > @bar = 'forty-two' > end > > # call two actions on the bar controller, potentially reusing > the entire model+view+controller stack > foo = bar_controller.content_for :action => 'foo' > bar = bar_controller.content_for :action => 'bar' > > render :text => [foo, bar].inspect #=> [42, "forty-two"] > end > end > > > With this: > > class FooController < ApplicationController > def bar > params_hash = {:foo => 42, :bar => 'forty_two'} > > # call two actions on the bar controller, potentially reusing > the entire model+view+controller stack > foo = render_component_as_string( params_hash.merge(:controller > => "bar", :action => "foo" ) > > bar = render_component_as_string( params_hash.merge(:controller > => "bar", :action => "bar" ) > > render :text => [foo, bar].inspect #=> [42, "forty-two"] > end > end > the main difference in the above is that, using 'component_for' is constructing an object *once*. using 'render_component_as_string' is making two objects. in the case of components these can be very expensive objects to create class SpreadSheetController < ApplicationController def initialize @rows = select_100_100_rows end def foo something_with_100_000_rows end def bar something_with_100_000_rows end end of course there's nothing on 'component_for' which adds some measure of turning completeness to ruby/rails - nothing truely new is gained - it's simply the difference between creating objects which can be manipulated and combined vs. setting up a bunch of parameters and calling a bunch of methods. i personally just happen to map most problems to objects in my mind and find it a useful abstraction to be able to do this with rails' views - it's certainly not a panacea though! ;-) anyhow, i'm happy to hear you are using components - people claim that they are much slower, but my tests haven't managed to show this. can you comment on that? hope you are having fun at the jupiter! cheers. -a -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama From ara.t.howard at gmail.com Sun May 20 09:39:58 2007 From: ara.t.howard at gmail.com (ara.t.howard) Date: Sun, 20 May 2007 07:39:58 -0600 Subject: [Boulder-Denver Ruby Group] re-inventing components In-Reply-To: References: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> <20070518224121.GB31550@slim.pmade.com> Message-ID: <5B2A8CC3-BF99-4B3C-AF0E-83D9553185C0@gmail.com> On May 19, 2007, at 10:53 PM, Tony Arcieri wrote: > In specific regard to render_component, Rails components are > painfully slow and unofficially deprecated to the point where Rails > core is silently threatening to remove them (although they probably > won't, due to their utility) > > Nevertheless, the general vibe is: don't use components, and expect > them to go away > > I think something lighter than an entire instance of > ActionController is definitely in order, and specifically something > where its creators aren't telling you "Don't use it" > > - Tony > > hi tony- i've been unable to show that components are, in fact, slower: ### a simple controller cfp:~/src/ruby/componentry/componentry-0.0.0/sample/rails > cat app/ controllers/bar_controller.rb class BarController < ApplicationController def initialize @foo = 42 @bar = 'forty-two' end def foo render :text => @foo end def bar render :text => @bar end def foobar render :text => [@foo, @bar].inspect #=> [42, "forty-two"] end end ### benchmarking cfp:~/src/ruby/componentry/componentry-0.0.0/sample/rails > ab -n 25 - c 4 http://localhost:3000/bar/foobar|grep 'Requests' Requests per second: 7.05 [#/sec] (mean) ### another controller which uses the simple controller above via component_for (see attached code) cfp:~/src/ruby/componentry/componentry-0.0.0/sample/rails > cat app/ controllers/foo_controller.rb class FooController < ApplicationController def foobar # get a handle on, and parameterize, a bar controller bar_controller = component_for(:controller => 'bar') do @foo = 42 @bar = 'forty-two' end # call two actions on the bar controller, reusing the entire model+view+controller foo = bar_controller.content_for :action => 'foo' bar = bar_controller.content_for :action => 'bar' render :text => [foo, bar].inspect #=> [42, "forty-two"] end end ### benchmarking cfp:~/src/ruby/componentry/componentry-0.0.0/sample/rails > ab -n 25 - c 4 http://localhost:3000/foo/foobar|grep 'Requests' Requests per second: 6.79 [#/sec] (mean) so this seems to indicate that the above two routes, with and without components, are essentially the same. do you have code showing that they are significantly slower? my reading of the rails source doesn't show any significant work being done when components are used, many objects are dup'd when possible, so this makes sense to me. nonetheless the net is awash with people claiming this is not true. ps. above is using lighttpd, perhaps mongrel would have issues with concurrency? cheers. -a -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/bdrg-members/attachments/20070520/211f27ad/attachment.html From david at collectiveintellect.com Sun May 20 13:50:25 2007 From: david at collectiveintellect.com (David Clements) Date: Sun, 20 May 2007 11:50:25 -0600 Subject: [Boulder-Denver Ruby Group] re-inventing components In-Reply-To: <5692C2EB-6FFA-48CC-BEB9-FAF7996425BB@gmail.com> References: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> <20070518224121.GB31550@slim.pmade.com> <5692C2EB-6FFA-48CC-BEB9-FAF7996425BB@gmail.com> Message-ID: On May 20, 2007, at 7:19 AM, ara.t.howard wrote: > > On May 18, 2007, at 7:24 PM, David Clements wrote: > >> Not sure if I am totally following the issue here. I totally agree >> with the premise that the support for widgetizing our apps is really >> ugly. And I use components regularly to widgetize various portions of >> our apps. >> >> Are we talking about syntax or functionality? > > both. > >> >> We could re-write your example today using >> render_component_as_string: >> >> class FooController < ApplicationController >> def bar >> # get a handle on, and parameterize, a bar controller >> bar_controller = component_for(:controller => 'bar') do >> @foo = 42 >> @bar = 'forty-two' >> end >> >> # call two actions on the bar controller, potentially reusing >> the entire model+view+controller stack >> foo = bar_controller.content_for :action => 'foo' >> bar = bar_controller.content_for :action => 'bar' >> >> render :text => [foo, bar].inspect #=> [42, "forty-two"] >> end >> end >> >> >> With this: >> >> class FooController < ApplicationController >> def bar >> params_hash = {:foo => 42, :bar => 'forty_two'} >> >> # call two actions on the bar controller, potentially reusing >> the entire model+view+controller stack >> foo = render_component_as_string( params_hash.merge(:controller >> => "bar", :action => "foo" ) >> >> bar = render_component_as_string( params_hash.merge(:controller >> => "bar", :action => "bar" ) >> >> render :text => [foo, bar].inspect #=> [42, "forty-two"] >> end >> end >> > > > the main difference in the above is that, using 'component_for' is > constructing an object *once*. using 'render_component_as_string' > is making two objects. in the case of components these can be very > expensive objects to create > > class SpreadSheetController < ApplicationController > def initialize > @rows = select_100_100_rows > end > > def foo > something_with_100_000_rows > end > > def bar > something_with_100_000_rows > end > end > > of course there's nothing on 'component_for' which adds some > measure of turning completeness to ruby/rails - nothing truely new > is gained - it's simply the difference between creating objects > which can be manipulated and combined vs. setting up a bunch of > parameters and calling a bunch of methods. i personally just > happen to map most problems to objects in my mind and find it a > useful abstraction to be able to do this with rails' views - it's > certainly not a panacea though! ;-) > > anyhow, i'm happy to hear you are using components - people claim > that they are much slower, but my tests haven't managed to show > this. can you comment on that? I think that the perf issue people speak about comes from assumption that the Bar controller could more efficiently setup the data needed for the Foo controller rather that running through the whole stack again. I have setup up my component partials in a way that I can use them without calling into the component when I need to make separate calls. So I guess my question here is that if components are going to be deprecated then how do you separate the concerns of the Foo and Bar controllers? Even in your example, Ara, I don't like the fact that Foo controller has to know anything at all about Bar. I want the view to make the decision that , in this context ,we are going to draw the Bar widget somewhere on the page. I have situations where I don't want Foo to know anything about Bar. And currently , in rails, I do need to do this for performance reasons when I can't afford to render the same component more than once. Dave > > hope you are having fun at the jupiter! > > cheers. > > > -a > -- > we can deny everything, except that we have the possibility of > being better. simply reflect on that. > h.h. the 14th dalai lama > > > From ara.t.howard at gmail.com Sun May 20 15:54:56 2007 From: ara.t.howard at gmail.com (ara.t.howard) Date: Sun, 20 May 2007 13:54:56 -0600 Subject: [Boulder-Denver Ruby Group] re-inventing components In-Reply-To: References: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> <20070518224121.GB31550@slim.pmade.com> <5692C2EB-6FFA-48CC-BEB9-FAF7996425BB@gmail.com> Message-ID: On May 20, 2007, at 11:50 AM, David Clements wrote: > > I think that the perf issue people speak about comes from assumption > that the Bar controller could more efficiently setup the data needed > for the Foo controller rather that running through the whole stack > again. I have setup up my component partials in a way that I can use > them without calling into the component when I need to make separate > calls. > ok. that makes sense - but reading the component code it doesn't actually look like much work - mostly dups.... my real concern is if anyone has ever seen *measurable* differences. have you had any issues with speed? iff so, can you quantify to give me an idea of what i'm up against? > So I guess my question here is that if components are going to be > deprecated are they? i've heard that, but then http://groups.google.com/group/rubyonrails-core/browse_thread/ thread/6f923c6483914c27/3ff503c1f4b0dcc0?lnk=gst&q=components +deprecated&rnum=1#3ff503c1f4b0dcc0 so, since you are there - what's the current thinking? are they or are aren't they? > then how do you separate the concerns of the Foo and Bar > controllers? i'm not following you - they are completely different objects - any other controller could construct and parameterize a bar object too - it seems like the separation is the same as this code a = [] h = { :key => a } > Even in your example, Ara, I don't like the fact that > Foo controller has to know anything at all about Bar. I want the > view to make the decision that , hmmm. don't you normally consider the controller as responsible for contructing all data for the view? in any case you certainly could construct that bar widget in the view or a helper method.... > in this context ,we are going to > draw the Bar widget somewhere on the page. I have situations where I > don't want Foo to know anything about Bar. And currently , in > rails, I do need to do this for performance reasons when I can't > afford to render the same component more than once. just to clarify - are you saying that you do not want to go through the whole 'render' stack (request, response...) and that you are not using render_component_to_string in that context because of performance reasons? if so that certainly makes sense. it's obvious that some imagined widget would not always need to go through the whole rendering stack but, be things how the are, the tight coupling of the request, controller, and the virtual mating of the view and controller in rails make this hard to accomplish any other way... did anyone have novel ideas on this at the conf? kind regards. -a -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama From bothari at gmail.com Mon May 21 11:55:07 2007 From: bothari at gmail.com (Bothari) Date: Mon, 21 May 2007 10:55:07 -0500 Subject: [Boulder-Denver Ruby Group] Ruby spots on the Front Range? Message-ID: Greetings, Group! My name is Joe Fair, and I am a former resident of the Front Range. I've developed lots of Java, but I'm trying to move to Ruby full-time. I was wondering how the market is in Denver? Are there any full-time people hiring, or contracting spots that require a local person? Are there any places to persue or avoid? I'm in the middle of Oklahoma now, so the only option is full telecommute gigs. I'm open to that, but I'm looking for a good reason to move back to Colorado. :-) I can develop in Java, too, but I want to start doing more Ruby this year. I attended the Rails Studio in Denver last year, and there seemed to be several companies open to the idea. Does anybody know if those seeds took root? Email me offline and I'll keep your name out of it. :-) Thanks, Joe -- "For a new software system, the requirements will not be completely known until after the users have used it." Humphrey's Requirements Uncertainty Principle. From david at collectiveintellect.com Mon May 21 12:51:51 2007 From: david at collectiveintellect.com (David Clements) Date: Mon, 21 May 2007 10:51:51 -0600 Subject: [Boulder-Denver Ruby Group] re-inventing components In-Reply-To: References: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> <20070518224121.GB31550@slim.pmade.com> <5692C2EB-6FFA-48CC-BEB9-FAF7996425BB@gmail.com> Message-ID: <0BE2551D-38C1-4D05-AEC5-8F0899C9AEAC@collectiveintellect.com> On May 20, 2007, at 1:54 PM, ara.t.howard wrote: > > On May 20, 2007, at 11:50 AM, David Clements wrote: > >> >> I think that the perf issue people speak about comes from assumption >> that the Bar controller could more efficiently setup the data needed >> for the Foo controller rather that running through the whole stack >> again. I have setup up my component partials in a way that I can use >> them without calling into the component when I need to make separate >> calls. >> > > ok. that makes sense - but reading the component code it doesn't > actually look like much work - mostly dups.... my real concern is > if anyone has ever seen *measurable* differences. have you had any > issues with speed? iff so, can you quantify to give me an idea of > what i'm up against? The only thing I have heard is that the duping is expensive, that never made sense to me. I don't have anything measurable and concur that I don't se anything in the code that dive me concern. The only response I ever see is that you should be able to chuck your component and use helpers and partials. > > >> So I guess my question here is that if components are going to be >> deprecated > > are they? i've heard that, but then > > http://groups.google.com/group/rubyonrails-core/browse_thread/ > thread/6f923c6483914c27/3ff503c1f4b0dcc0?lnk=gst&q=components > +deprecated&rnum=1#3ff503c1f4b0dcc0 > > so, since you are there - what's the current thinking? are they or > are aren't they? Didn't talk to anyone about it. > > >> then how do you separate the concerns of the Foo and Bar >> controllers? > > i'm not following you - they are completely different objects - any > other controller could construct and parameterize a bar object too > - it seems like the separation is the same as this code > > a = [] > h = { :key => a } > > >> Even in your example, Ara, I don't like the fact that >> Foo controller has to know anything at all about Bar. I want the >> view to make the decision that , > > hmmm. don't you normally consider the controller as responsible > for contructing all data for the view? in any case you certainly > could construct that bar widget in the view or a helper method.... Maybe I am off the deep end but I can see any trivial examples where the main content of a page does not have anything to do with sidebar content. One example that i have is a logout header at the top of many my layouts. There is information in the logout header that I don't want my main pages to care/know about at all. I guess I could code around this in someway right and have a LogoutHelper.init_instances and then render :partial => 'logout_header'. That just seems ugly and heavy to me. So I like the direction you are going and have other examples I can show you to help flesh out your use cases. > >> in this context ,we are going to >> draw the Bar widget somewhere on the page. I have situations where I >> don't want Foo to know anything about Bar. And currently , in >> rails, I do need to do this for performance reasons when I can't >> afford to render the same component more than once. > > just to clarify - are you saying that you do not want to go through > the whole 'render' stack (request, response...) and that you are > not using render_component_to_string in that context because of > performance reasons? if so that certainly makes sense. Yes, but your approach might make more sense in these cases. If you could grab ahold of a Bar instance and initialize it with the data for all the calls of render_component, then that would make my life easier and I think it would be much cleaner. Which makes me think........ Why wouldn't you handle the main target controller in the same way? Every thing is a widget! Coffee and a whiteboard? Dave > > it's obvious that some imagined widget would not always need to go > through the whole rendering stack but, be things how the are, the > tight coupling of the request, controller, and the virtual mating > of the view and controller in rails make this hard to accomplish > any other way... > > did anyone have novel ideas on this at the conf? > > kind regards. > > -a > -- > we can deny everything, except that we have the possibility of > being better. simply reflect on that. > h.h. the 14th dalai lama > > > From bothari at gmail.com Mon May 21 13:07:22 2007 From: bothari at gmail.com (Bothari) Date: Mon, 21 May 2007 12:07:22 -0500 Subject: [Boulder-Denver Ruby Group] Ruby spots on the Front Range? In-Reply-To: References: Message-ID: Let's make a deal. I've gotten a couple responses already, and one request for a summary of what I find. Just to make it interesting, I'll be glad to summarize the responses and post them (names redacted) to anyone that sends me info on Thursday. If you don't have anything to contribute, just send me a note saying you don't know the answer to my question, but you work at and do java/ruby/whatever and it rock/sucks because . That way you're on the list and I have more info, but I won't post those messages without your permission. I still won't post your name, because it could be your cow-worker trying to get you fired. ;-) Unless I win the Powerball I'll send it out Thursday. I'm asking a similar question in Houston, and if I get anything worth having there I'll include it, too. Thanks, Joe On 5/21/07, Bothari wrote: > Greetings, Group! > > My name is Joe Fair, and I am a former resident of the Front Range. > I've developed lots of Java, but I'm trying to move to Ruby full-time. > I was wondering how the market is in Denver? Are there any full-time > people hiring, or contracting spots that require a local person? Are > there any places to persue or avoid? > > I'm in the middle of Oklahoma now, so the only option is full > telecommute gigs. I'm open to that, but I'm looking for a good reason > to move back to Colorado. :-) I can develop in Java, too, but I want > to start doing more Ruby this year. > > I attended the Rails Studio in Denver last year, and there seemed to > be several companies open to the idea. Does anybody know if those > seeds took root? > > Email me offline and I'll keep your name out of it. :-) > > Thanks, > Joe > > -- > "For a new software system, the requirements will not be completely > known until after the users have used it." Humphrey's Requirements > Uncertainty Principle. > -- "For a new software system, the requirements will not be completely known until after the users have used it." Humphrey's Requirements Uncertainty Principle. From ara.t.howard at gmail.com Mon May 21 13:25:17 2007 From: ara.t.howard at gmail.com (ara.t.howard) Date: Mon, 21 May 2007 11:25:17 -0600 Subject: [Boulder-Denver Ruby Group] re-inventing components In-Reply-To: <0BE2551D-38C1-4D05-AEC5-8F0899C9AEAC@collectiveintellect.com> References: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> <20070518224121.GB31550@slim.pmade.com> <5692C2EB-6FFA-48CC-BEB9-FAF7996425BB@gmail.com> <0BE2551D-38C1-4D05-AEC5-8F0899C9AEAC@collectiveintellect.com> Message-ID: On May 21, 2007, at 10:51 AM, David Clements wrote: > > The only thing I have heard is that the duping is expensive, that > never made sense to me. I don't have anything measurable and > concur that I don't se anything in the code that dive me concern. > The only response I ever see is that you should be able to chuck > your component and use helpers and partials. ok good. that really supports this http://drawohara.tumblr.com/post/2184032 > > Didn't talk to anyone about it. > ok. did any other ideas about where view patterns where heading emerge? actually - those of us who didn't go would really appreciate a run down of the proceedings from you and others who went - maybe next ruby group? marty? > > Maybe I am off the deep end but I can see any trivial examples > where the main content of a page does not have anything to do with > sidebar content. One example that i have is a logout header at > the top of many my layouts. There is information in the logout > header that I don't want my main pages to care/know about at all. > I guess I could code around this in someway right and have a > LogoutHelper.init_instances and then render :partial => > 'logout_header'. That just seems ugly and heavy to me. So I like > the direction you are going and have other examples I can show you > to help flesh out your use cases. > > ok - i understand that. it makes sense. i'd love to see more examples. > > Yes, but your approach might make more sense in these cases. If > you could grab ahold of a Bar instance and initialize it with the > data for all the calls of render_component, then that would make my > life easier and I think it would be much cleaner. Which makes me > think........ Why wouldn't you handle the main target controller > in the same way? Every thing is a widget! > > Coffee and a whiteboard? > yes! wednesday @ the cup - 8 am? anyone else care to join? > > -a > -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama From mghaught at gmail.com Mon May 21 14:27:44 2007 From: mghaught at gmail.com (Marty Haught) Date: Mon, 21 May 2007 12:27:44 -0600 Subject: [Boulder-Denver Ruby Group] re-inventing components In-Reply-To: References: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> <20070518224121.GB31550@slim.pmade.com> <5692C2EB-6FFA-48CC-BEB9-FAF7996425BB@gmail.com> <0BE2551D-38C1-4D05-AEC5-8F0899C9AEAC@collectiveintellect.com> Message-ID: <57f29e620705211127h65a72f87v9e869cad7a63b0b5@mail.gmail.com> > actually - those of us who didn't go would really appreciate a run > down of the proceedings from you and others who went - maybe next > ruby group? marty? Sounds like a good idea. I'd be happy to do a review of RailsConf along with the others that went. Let's see how many of those on the list that did attend can make the June meeting (June 20th). Cheers, Marty From jeremy at hinegardner.org Mon May 21 17:56:21 2007 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Mon, 21 May 2007 15:56:21 -0600 Subject: [Boulder-Denver Ruby Group] re-inventing components In-Reply-To: References: <04556DB1-7A2B-471F-9CE8-B164573C7626@gmail.com> <20070518224121.GB31550@slim.pmade.com> <5692C2EB-6FFA-48CC-BEB9-FAF7996425BB@gmail.com> <0BE2551D-38C1-4D05-AEC5-8F0899C9AEAC@collectiveintellect.com> Message-ID: <20070521215621.GI9854@hinegardner.org> On Mon, May 21, 2007 at 11:25:17AM -0600, ara.t.howard wrote: > > > > Yes, but your approach might make more sense in these cases. If > > you could grab ahold of a Bar instance and initialize it with the > > data for all the calls of render_component, then that would make my > > life easier and I think it would be much cleaner. Which makes me > > think........ Why wouldn't you handle the main target controller > > in the same way? Every thing is a widget! > > > > Coffee and a whiteboard? > > > > yes! wednesday @ the cup - 8 am? anyone else care to join? Ping... I'm in. Hmm... I have this large chunk of whiteboard at my house... enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From pjones at pmade.org Thu May 24 11:30:05 2007 From: pjones at pmade.org (Peter Jones) Date: Thu, 24 May 2007 08:30:05 -0700 Subject: [Boulder-Denver Ruby Group] Looking for a Local Ruby Developer for LgDb.com Message-ID: <20070524153005.GT31550@slim.pmade.com> LgDb.com is an awesome company with a bright future and a hard-to-pronounce name. We are building a site to make governmental information much easier to find, and professional tools that make the jobs of lobbyists and others dramatically easier. We are looking for a Ruby developer who produces code that is beautiful to look at, and a dream to run. That's what our small team has produced already, and you will be part of this rock star team. This is a full-time position, which can be structured as a traditional FTE, or independent contractor depending on what works best for everyone. Either way, you're free to work at home, or in one of our offices in Denver. Requirements: Practitioner of agile development Ruby experience (or a strong background in other OO languages) Experience in HTML parsing (Hpricot) is a strong plus Unix proficiency Please email your resume, and a note to work at LgDb.com. If you have any open source projects or code available online, please include a link to that as well. -- Peter Jones pmade inc. - http://pmade.com From tony at clickcaster.com Fri May 25 23:53:15 2007 From: tony at clickcaster.com (Tony Arcieri) Date: Fri, 25 May 2007 21:53:15 -0600 Subject: [Boulder-Denver Ruby Group] send_file "memory leak" Message-ID: When I gave my talk on Rublique (which has now been rendered quite obsolete by Evan Weaver's Bleak House, which uses C instrumentation much faster than ObjectSpace) I mentioned at the end that the memory leak I was experiencing was due to send_file. A lot of people were confused because of that, specifically what the nature of the memory leak was, and I didn't exactly do a good job of describing what the problem was. It's not really a memory leak. The problem is Rails returns a StringIO to Mongrel which represents the entire content body. That's fine for most documents, but what happens when you're trying to send a 1GB+ file? send_file returns a Proc object as the :text option to render. This proc contains a simple routine to print out the file. The problem with the Rails/Mongrel combination is that this Proc simply writes to a StringIO, which when the entire content body has been emitted (i.e. the entire contents of the file) returns it all to Mongrel, which then sends it to the network: 70: len = options[:buffer_size] || 4096 71: File.open(path, 'rb') do |file| 72: while buf = file.read(len) 73: output.write(buf) 74: end 75: end When Mongrel is serving multiple, large files to the network, this is obviously going to eat up a lot of RAM. The intermediate StringIO is what causes the massive memory consumption. If you could instance_eval the Proc returned by send_file and expose a method which writes directly to the network, the intermediate StringIO could be avoided. The advantages to this would be pure-Ruby instrumentation which can act upon exactly how much data is sent, for example a statistics tracking system which monitors how much of a given file was sent after it was requested. You can do this now, but the cost is every file presently being sent will remain in memory until the transfer ends. -- Tony Arcieri ClickCaster, Inc. tony at clickcaster.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/bdrg-members/attachments/20070525/d785b1fd/attachment.html From ara.t.howard at gmail.com Tue May 29 19:37:43 2007 From: ara.t.howard at gmail.com (ara.t.howard) Date: Tue, 29 May 2007 17:37:43 -0600 Subject: [Boulder-Denver Ruby Group] activerecord iteration Message-ID: <1038B9AB-2F98-4D0D-876E-34EA40E1EC65@gmail.com> anyone skinned this cat http://drawohara.tumblr.com/post/2629204 ?? -a -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama From inboulder at gmail.com Tue May 29 21:57:30 2007 From: inboulder at gmail.com (Kyle) Date: Tue, 29 May 2007 19:57:30 -0600 Subject: [Boulder-Denver Ruby Group] activerecord iteration In-Reply-To: <1038B9AB-2F98-4D0D-876E-34EA40E1EC65@gmail.com> References: <1038B9AB-2F98-4D0D-876E-34EA40E1EC65@gmail.com> Message-ID: <170321190705291857h4916897el7d50baf98887cccb@mail.gmail.com> Howdy, I'm looking for a Rubyist for a project starting mid June in Boulder; RoR experience necessary, kick ass web design skills a bonus. If you're interested please shoot me a cv, $ reqs etc. Cheers, Kyle From inboulder at gmail.com Tue May 29 22:28:14 2007 From: inboulder at gmail.com (Kyle) Date: Tue, 29 May 2007 20:28:14 -0600 Subject: [Boulder-Denver Ruby Group] Ninja Contractor Wanted - not:activerecord iteration Message-ID: <170321190705291928y11aa8f34rad056ce6fdf17620@mail.gmail.com> Oops, I just noticed I forgot to change the subject line. On 5/29/07, Kyle wrote: > Howdy, > > I'm looking for a Rubyist for a project starting mid June in Boulder; > RoR experience necessary, kick ass web design skills a bonus. If > you're interested please shoot me a cv, $ reqs etc. > > Cheers, > Kyle > From pjones at pmade.org Wed May 30 00:31:34 2007 From: pjones at pmade.org (Peter Jones) Date: Tue, 29 May 2007 21:31:34 -0700 Subject: [Boulder-Denver Ruby Group] activerecord iteration In-Reply-To: <1038B9AB-2F98-4D0D-876E-34EA40E1EC65@gmail.com> References: <1038B9AB-2F98-4D0D-876E-34EA40E1EC65@gmail.com> Message-ID: <20070530043134.GD55044@slim.pmade.com> ara.t.howard wrote the following on Tue, May 29, 2007 at 05:37:43PM -0600: > anyone skinned this cat http://drawohara.tumblr.com/post/2629204 Sounds like a good game of golf ;) http://pastie.caboo.se/65955 This version works very well with irb: ./script/console >> require 'crawl' >> Employee.find(:first) >> Employee.find(:all).each(&:inspect) -- Peter Jones pmade inc. - http://pmade.com From ara.t.howard at gmail.com Wed May 30 11:53:46 2007 From: ara.t.howard at gmail.com (ara.t.howard) Date: Wed, 30 May 2007 09:53:46 -0600 Subject: [Boulder-Denver Ruby Group] activerecord iteration In-Reply-To: <20070530043134.GD55044@slim.pmade.com> References: <1038B9AB-2F98-4D0D-876E-34EA40E1EC65@gmail.com> <20070530043134.GD55044@slim.pmade.com> Message-ID: On May 29, 2007, at 10:31 PM, Peter Jones wrote: > ara.t.howard wrote the following on Tue, May 29, 2007 at 05:37:43PM > -0600: >> anyone skinned this cat http://drawohara.tumblr.com/post/2629204 > > > Sounds like a good game of golf ;) > http://pastie.caboo.se/65955 NICE! > > This version works very well with irb: > ./script/console >>> require 'crawl' >>> Employee.find(:first) >>> Employee.find(:all).each(&:inspect) > > -- > Peter Jones > pmade inc. - http://pmade.com > _______________________________________________ > Bdrg-members mailing list > Bdrg-members at rubyforge.org > http://rubyforge.org/mailman/listinfo/bdrg-members -a -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama