Hi guys, After a few days of webrick seeming to use up a ton of ram (the longer it was running, the more ram); izayoi on #rubyonrails kindly suggested changing Dependencies.mechanism in development.rb to :require which appears to have fixed the prob - at the expense of having to restart webrick after making changes to .rb files. Is this a known issue, or is there an alternative solution? Secondly, I''ve cobbled together an ''image passthru'' action in a controller that essentially streams jpegs from disk - seems to work ok except that i''ve found that if i refresh a page with links to the action, the images come through corrupted. Browsing to another action/controller and back again doesn''t seem to suffer the same probs.. any ideas? Apologies for poor readability, but it''s nearly 5am ;-) Thanks in advance, Paul _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
The problem, it seems, is almost universal. But this tradeoff is not one i''d want to make when using webrick. Editing .rb files is something that happens alot during active development, so I would let it leak. Maybe we need a better bundled server. Maybe this is also a good nudge towards test driven development. On 4/16/05, Paul <nroc-XKoCOsdg+WzR7s880joybQ@public.gmane.org> wrote:> > Hi guys, > After a few days of webrick seeming to use up a ton of ram (the longer it > was running, the more ram); izayoi on #rubyonrails kindly suggested changing > Dependencies.mechanism in development.rb to :require which appears to have > fixed the prob - at the expense of having to restart webrick after making > changes to .rb files. Is this a known issue, or is there an alternative > solution? > Secondly, I''ve cobbled together an ''image passthru'' action in a > controller that essentially streams jpegs from disk - seems to work ok > except that i''ve found that if i refresh a page with links to the action, > the images come through corrupted. Browsing to another action/controller and > back again doesn''t seem to suffer the same probs.. any ideas? > Apologies for poor readability, but it''s nearly 5am ;-) > Thanks in advance, > Paul > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 4/16/05, Paul <nroc-XKoCOsdg+WzR7s880joybQ@public.gmane.org> wrote:> After a few days of webrick seeming to use up a ton of ram (the longer it > was running, the more ram);Yup, webrick is pretty leaky like that. Sometimes it''ll even crash and go into an infinite loop of RAM gobbling. When this happens, pages won''t load and it has to be killed... but usually this is only caused by buggy rails code (the only specific thing I can remember is that if you call the check_box helper like this: check_box "foo", "bar", nil instead of like this: check_box "foo", "bar", {} then it will spiral out of control like that. My solution to webrick''s memory problems is basically to run my production server on lighttpd, and then only use webrick for development, and make sure it''s not running when I''m not actually doing active development. In small doses, webrick isn''t a problem, and it''s really convenient ;) -- Urban Artography http://artography.ath.cx
Paul wrote:> After a few days of webrick seeming to use up a ton of ram (the longer > it was running, the more ram); izayoi on #rubyonrails kindly suggested > changing Dependencies.mechanism in development.rb to :requireSolution is simple. Don''t run WebRick for prolonged periods of time in production environment. Webrick is not JBoss or WebLogic, you know... :) Even for a real application like RForum restarting Webrick takes merely a couple of seconds. Besides, use automated tests. Myself, I''m doing some Rails development for half a year (for Rails today 6 months is like ages ago :) and it is the first time I even hear about this memory leak. It was quite obviously always there, but I never noticed :) -- Best regards, Alexey Verkhovsky Ruby Forum: http://ruby-forum.org (moderator) RForum: http://rforum.andreas-s.net (co-author) Instiki: http://instiki.org (maintainer)
Alexey Verkhovsky wrote:> Solution is simple. Don''t run WebRick for prolonged periods of time in > production environment.I meant to say "in development environment". -- Best regards, Alexey Verkhovsky Ruby Forum: http://ruby-forum.org (moderator) RForum: http://rforum.andreas-s.net (co-author) Instiki: http://instiki.org (maintainer)
On Sunday, April 17, 2005, 1:51:49 PM, Casey wrote:> The problem, it seems, is almost universal. But this tradeoff is not > one i''d want to make when using webrick. Editing .rb files is something > that happens alot during active development, so I would let it leak. > Maybe we need a better bundled server. Maybe this is also a good nudge > towards test driven development.Just interested, how does TDD work in Rails? I know the mechanisms, more or less, but not the process. Especially, how does it square with "interface-driven devlopment" which some people (notably DHH) advocate? I tend to beat the HTML & CSS interface into shape and add bits and pieces of functionality without knowing exactly what''s coming up next. Not sure how TDD fits in here. Gavin
Alexey / Rob / Casey, Thanks for your replies :-) I hope the impression was not that I was out to bash webrick, not at all! I realise that everything has its place, and I''ve found webrick extremely useful from the get go with RoR. I''m glad to hear that alternative daemons don''t appear to have these issues, my biggest fear was that it was a RoR thing and that when I got to production it wouldn''t hold up ;-) Thanks again, Paul
Personally i''ve used a combination of screen / test driven development. We started out with a bunch of basic screen shots. Then we elaborated the pages we had a general idea of what we wanted. Then the next step was to create a controller, then a general model. Then i started by writing functional tests for each action with in a controller. Then expanding out and writing some unit tests. In general i bounced back and forth between expanding out the model code and the controller code. I didn''t always keep to writing the tests first, but most of the time i was able to do it. The real problem came up when we''ve started to have a large code base. It''s started to take 5 to 10 minutes to run the full suite of tests. -rabble On 4/17/05, Gavin Sinclair <gsinclair-81uBx+iSpXA0n/F98K4Iww@public.gmane.org> wrote:> On Sunday, April 17, 2005, 1:51:49 PM, Casey wrote: > > > The problem, it seems, is almost universal. But this tradeoff is not > > one i''d want to make when using webrick. Editing .rb files is something > > that happens alot during active development, so I would let it leak. > > Maybe we need a better bundled server. Maybe this is also a good nudge > > towards test driven development. > > Just interested, how does TDD work in Rails? I know the mechanisms, > more or less, but not the process. Especially, how does it square > with "interface-driven devlopment" which some people (notably DHH) > advocate? > > I tend to beat the HTML & CSS interface into shape and add bits and > pieces of functionality without knowing exactly what''s coming up next. > Not sure how TDD fits in here. > > Gavin > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Apr 17, 2005, at 11:39 PM, evan wrote:> Personally i''ve used a combination of screen / test driven development. > > We started out with a bunch of basic screen shots. Then we elaborated > the pages we had a general idea of what we wanted. Then the next step > was to create a controller, then a general model. Then i started by > writing functional tests for each action with in a controller. Then > expanding out and writing some unit tests. > > In general i bounced back and forth between expanding out the model > code and the controller code. I didn''t always keep to writing the > tests first, but most of the time i was able to do it. > > The real problem came up when we''ve started to have a large code base. > It''s started to take 5 to 10 minutes to run the full suite of tests.I hear rumor that this is being worked on such that the test suites will run orders of magnitude faster. I can''t wait for that goodness. -Scott _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Gavin Sinclair <gsinclair-81uBx+iSpXA0n/F98K4Iww@public.gmane.org> writes:> Just interested, how does TDD work in Rails? I know the mechanisms, > more or less, but not the process. Especially, how does it square > with "interface-driven devlopment" which some people (notably DHH) > advocate?Even though I''m still Rails newbie, I''ll throw up my take on TDD. My "team" is broken fairly cleanly between design/html/css and programming. I really like that as the developer I can work out the whole app and spend almost no time on the views. I do all my work writing functional tests and then making them pass. Only at the end of my development session do I even fire up the web browser and check out what the views are doing. I am a little frustrated that running my functional tests are so slow. I''m given to running just the tests for the controller and/or model I''m working on at the moment to save time. Using rake to run them all borders on too painful. So, I''ll just run an individual test file until it passes and then run the whole batch of tests after I''m done with that one controller/model. As far as writing the actual tests themselves go, I love the test framework for functional/controller tests! I don''t write a bunch of tests up front. I typically just work on one feature at a time. I think, "What needs to be done next and how would I test that?" Typically I only end up with just a very few or a couple new tests before I start coding. Frankly, I''m not really sure what "interface driven development" is. My current plan is to keep with the TDD and working strictly on the controllers/models until I have a good portion of the code written. At that point I''ll switch hats and start working on the views a lot more. It''s not that I don''t have views now, it''s just they are bare minimum. Really they are just a tad more than scaffolding. Once we''re mostly confident of the flow of the app we''ll start wrangling the views into something nice and applying the design. Note that our customer and our designer are already working through multiple iterations using Photoshop. By the time I''m ready the design will be done and ready for CSS. -- doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org
On Apr 18, 2005, at 2:08 PM, Doug Alcorn wrote:> Gavin Sinclair <gsinclair-81uBx+iSpXA0n/F98K4Iww@public.gmane.org> writes: > >> Just interested, how does TDD work in Rails? I know the mechanisms, >> more or less, but not the process. Especially, how does it square >> with "interface-driven devlopment" which some people (notably DHH) >> advocate? > > Even though I''m still Rails newbie, I''ll throw up my take on TDD. My > "team" is broken fairly cleanly between design/html/css and > programming. I really like that as the developer I can work out the > whole app and spend almost no time on the views. I do all my work > writing functional tests and then making them pass. Only at the end > of my development session do I even fire up the web browser and check > out what the views are doing. > > I am a little frustrated that running my functional tests are so > slow. I''m given to running just the tests for the controller and/or > model I''m working on at the moment to save time. Using rake to run > them all borders on too painful. So, I''ll just run an individual test > file until it passes and then run the whole batch of tests after I''m > done with that one controller/model.This is exactly how I operate. The -n option to the tests makes this a breeze. For those unaware, you can do the following: % ruby test/units/test_foo.rb -n test_blah # Runs just test_blah method % ruby test/unites/test_foo.rb -n /blah/ # Runs any test method matching the regex /blah/, this one''s awesome. There have also recently been rake targets made to run only test files that have changed (in the last 10 minutes I think).> As far as writing the actual tests themselves go, I love the test > framework for functional/controller tests! I don''t write a bunch of > tests up front. I typically just work on one feature at a time. I > think, "What needs to be done next and how would I test that?" > Typically I only end up with just a very few or a couple new tests > before I start coding. > > Frankly, I''m not really sure what "interface driven development" is. > My current plan is to keep with the TDD and working strictly on the > controllers/models until I have a good portion of the code written. > At that point I''ll switch hats and start working on the views a lot > more. It''s not that I don''t have views now, it''s just they are bare > minimum. Really they are just a tad more than scaffolding. Once > we''re mostly confident of the flow of the app we''ll start wrangling > the views into something nice and applying the design. Note that our > customer and our designer are already working through multiple > iterations using Photoshop. By the time I''m ready the design will be > done and ready for CSS.The key to designing the interface first is that only the *important* part of the interface is designed first. You wouldn''t start with a completely polished and style mock up of everything before writing any model or controller code, that''s going to far. But defining the important inputs and data displays often gives you insights for better structuring your models and their relationships as well as control flow. David also just added some nice asserts that make checking for things in the rendered output dead simple (eg you can check if a container is present which matches a heirarchy, or has specific attributes like class="foo" or id="errorBox", etc). This makes TDD for the interface even easier. TDD and interface-first are a good fit and work well together in my experience. I can remember a time when I would design my models first (it wasn''t too long ago). I''m a programmer, and that''s the "fun stuff". I took a month and forced myself to do the important parts of the interface first, as well as writing tests before code. It''s been several months and I haven''t looked back, it''s been great. I feel like I''ve improved as a programmer, anyway. Of course, everyone has their preferred techniques and what works for me may not work for anyone else (and vice versa). But, it doesn''t hurt to try. You just might like it! -Scott _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
With regards to how TDD in Rails squares with interface-driven development I think it all depends on how you like to build an application as a whole. If I can take a guess at what interface-driven development is then I would guess: 1) It''s designing an application from the UI instead of from use cases and functional specs. 2) It''s driven from the view to the controller to the model rather than from the other way around 3) It''s about designing an /application/ If I contrast this with what I know about Test Driven Development: 1) It''s about writing tests that get you to think about what it is you intend your code to do 2) It''s driven from very small discrete constructions of code that can be combined to provide an entire feature set and in my experience tends to go from model to controller to view 3) It''s a very specific approach to designing and developing/ code/ IDD = Designing an application for it''s form and function particularly in the usability aspects of the View TDD = Designing and developing the code part of that application particularly from the logic and functionality aspects of the model and controller After reading Jamis Buck''s blog (http://jamis.jamisbuck.org/blog.cgi/programming/Taking%2037signals''%20Process%20for%20a%20Spi_20050130220429.tx) on the 37Signals approach to application building I tried the following: IDD 1) Brainstormed ideas for an application and wrote them down on paper. Made a list of possible features. Broke the features out into iterations. 2) Sketched on paper, mock-ups of the UI. 3) Rendered in CSS + XHTML the paper mock-ups 4) Adjusted my design every step of the way with the new info each step gave me TDD 1) Looked at my XHTML mockups and selected a set that had the same "theme" 2) Decided what entity I wanted my model to be and what attributes it would have and created the database table for it 3) Wrote unit tests for the domain logic that would be captured by the model object 4) Wrote the code for the model object to pass the tests 5) Wrote functional tests for the different ways a user might want to access the model object through the controller based on looking at the mock-ups 6) Wrote the code for the controller object to pass the tests 7) Wrote functional tests for aspects of my view that I felt were worth examining (i.e. whether a certain link was rendered under a certain condition) 8) Wrote controller and view code to pass the tests The thing I like most about this approach is that by the time I''m ready to code I''ve already put a lot of thought and consideration into the design so that I can then put on my developer hat and just think about building code. It eases the burden of thought. Now this isn''t to say I don''t change the design when the coding starts, i do, but by separating the two activities I find it helps me to just focus on code to support the design, and design to support the application. My two cents, Tim Case Scott Barron wrote:> > On Apr 18, 2005, at 2:08 PM, Doug Alcorn wrote: > >> Gavin Sinclair <gsinclair-81uBx+iSpXA0n/F98K4Iww@public.gmane.org> writes: >> >>> Just interested, how does TDD work in Rails? I know the mechanisms, >>> more or less, but not the process. Especially, how does it square >>> with "interface-driven devlopment" which some people (notably DHH) >>> advocate? >> >> >> Even though I''m still Rails newbie, I''ll throw up my take on TDD. My >> "team" is broken fairly cleanly between design/html/css and >> programming. I really like that as the developer I can work out the >> whole app and spend almost no time on the views. I do all my work >> writing functional tests and then making them pass. Only at the end >> of my development session do I even fire up the web browser and check >> out what the views are doing. >> >> I am a little frustrated that running my functional tests are so >> slow. I''m given to running just the tests for the controller and/or >> model I''m working on at the moment to save time. Using rake to run >> them all borders on too painful. So, I''ll just run an individual test >> file until it passes and then run the whole batch of tests after I''m >> done with that one controller/model. > > > This is exactly how I operate. The -n option to the tests makes this > a breeze. For those unaware, you can do the following: > > % ruby test/units/test_foo.rb -n test_blah # Runs just test_blah method > > % ruby test/unites/test_foo.rb -n /blah/ # Runs any test method > matching the regex /blah/, this one''s awesome. > > There have also recently been rake targets made to run only test files > that have changed (in the last 10 minutes I think). > >> As far as writing the actual tests themselves go, I love the test >> framework for functional/controller tests! I don''t write a bunch of >> tests up front. I typically just work on one feature at a time. I >> think, "What needs to be done next and how would I test that?" >> Typically I only end up with just a very few or a couple new tests >> before I start coding. >> >> Frankly, I''m not really sure what "interface driven development" is. >> My current plan is to keep with the TDD and working strictly on the >> controllers/models until I have a good portion of the code written. >> At that point I''ll switch hats and start working on the views a lot >> more. It''s not that I don''t have views now, it''s just they are bare >> minimum. Really they are just a tad more than scaffolding. Once >> we''re mostly confident of the flow of the app we''ll start wrangling >> the views into something nice and applying the design. Note that our >> customer and our designer are already working through multiple >> iterations using Photoshop. By the time I''m ready the design will be >> done and ready for CSS. > > > The key to designing the interface first is that only the *important* > part of the interface is designed first. You wouldn''t start with a > completely polished and style mock up of everything before writing any > model or controller code, that''s going to far. But defining the > important inputs and data displays often gives you insights for better > structuring your models and their relationships as well as control flow. > > David also just added some nice asserts that make checking for things > in the rendered output dead simple (eg you can check if a container is > present which matches a heirarchy, or has specific attributes like > class="foo" or id="errorBox", etc). This makes TDD for the interface > even easier. TDD and interface-first are a good fit and work well > together in my experience. > > I can remember a time when I would design my models first (it wasn''t > too long ago). I''m a programmer, and that''s the "fun stuff". I took > a month and forced myself to do the important parts of the interface > first, as well as writing tests before code. It''s been several months > and I haven''t looked back, it''s been great. I feel like I''ve improved > as a programmer, anyway. > > Of course, everyone has their preferred techniques and what works for > me may not work for anyone else (and vice versa). But, it doesn''t > hurt to try. You just might like it! > > -Scott > >------------------------------------------------------------------------ > >_______________________________________________ >Rails mailing list >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >http://lists.rubyonrails.org/mailman/listinfo/rails > >
> > I am a little frustrated that running my functional tests are so > slow. I''m given to running just the tests for the controller and/or > model I''m working on at the moment to save time. Using rake to run > them all borders on too painful. So, I''ll just run an individual test > file until it passes and then run the whole batch of tests after I''m > done with that one controller/model.I''m currently working on something to speed tests up a bit. Basically it''s a little server that requires all the rails code (thats what takes a couple of seconds before the tests are actually run) and then just waits for requests from a client. Right now for me it works like this: - Open a testcase with textmate - Put the cursor inside of some test method - Press alt + apple + t in textmate - Textmate uses the testclient to tell the testserver to run the specific test. With that you don''t have to wait for requiring Rails on every test run and can easily define which specific test you wanna run. A lot faster! A lot nicer for doing TDD
oakland cutlery wrote:>>I am a little frustrated that running my functional tests are so >>slow. I''m given to running just the tests for the controller and/or >>model I''m working on at the moment to save time. Using rake to run >>them all borders on too painful. So, I''ll just run an individual test >>file until it passes and then run the whole batch of tests after I''m >>done with that one controller/model. > > I''m currently working on something to speed tests up a bit. Basically it''s > a little server that requires all the rails code (thats what takes a couple > of seconds before the tests are actually run) and then just waits for > requests from a client. > > Right now for me it works like this: > > - Open a testcase with textmate > - Put the cursor inside of some test method > - Press alt + apple + t in textmate > - Textmate uses the testclient to tell the testserver to run the specific test. > > With that you don''t have to wait for requiring Rails on every test run and can > easily define which specific test you wanna run. A lot faster! A lot > nicer for doing TDDAwesome. Please get this to the masses, polish or no. jeremy
oakland cutlery <csshsh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:> I''m currently working on something to speed tests up a > bit. Basically it''s a little server that requires all the rails code > (thats what takes a couple of seconds before the tests are actually > run) and then just waits for requests from a client. > > Right now for me it works like this: > > - Open a testcase with textmate > - Put the cursor inside of some test method > - Press alt + apple + t in textmate > - Textmate uses the testclient to tell the testserver to run the > specific test.For those of us trapped in the ''80s and can''t give up emacs, how would this work? Is it possible to get rake to use the test client? Sounds great though. Not being familiar with the test process with rake, does it have to require all the rails code for each individual test or once for all the tests? Could rake be optimized to instantiate one testserver at the beginning of the tests, run all the tests with testclient, then kill off the testserver? BTW, how does the testserver handle changes to the modules? Is Ruby smart enough to notice when modules change and "re-require" them? -- doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org