[rails-oceania] Re: Right tool for the job
awesome link - i lol'd more than once. On Wed, Apr 8, 2009 at 3:41 PM, David Turnbull wrote: > > Agreed, http://teddziuba.com/2008/04/im-going-to-scale-my-foot-up-y.html > > On 08/04/2009, at 3:39 PM, Cameron Barrie wrote: > > > I agree with that last point. > > I do loathe the twitter examples in regards to scaling(no disrespect > > meant to anyone BTW). > > I can't think of any framework/architecture out of the box that > > would have, Got that built for them quickly as it did, and not had a > > scaling issue. > > Twitter get's slammed by millions and millions of requests, nothing > > would've handled that load, nor should they have anticipated/ > > architected for that sort of load from the beginning. > > Granted they took to long to come up with a solution, but that's not > > he fault of the language/framework. It's a pretty freakin' good > > solution IMHO. > > > > I had a .Net dev telling me the other day he'd never use Rails since > > it doesn't scale, and pointed out twitter as his example, I asked > > him the last time he wrote a site/service designed to handle that > > sort of load, answer... Never has and probably never will. Like most > > of us. Then of course he also pointed out, that a .NET app straight > > out of the box would've died in the arse as well under that sort of > > load. > > > > Twitter is the scaling corner case or all corner cases. > > > > My opinion of twitter is more along the lines of you want to scale > > Rails, look at twitter that thing is freakin' crazy if they can > > scale that you can scale anything. With some hard thinking and good > > coders you can even make that shit work in Ruby. It's a developers > > best friend after all. :D > > > > C > > > > On 08/04/2009, at 3:26 PM, Daniel Sabados wrote: > > > >> IMHO, if one were building a site that would cater for millions of > >> hits per day before > >> they've even launched it, they've either hit the holy grail of > >> ideas or they're building > >> a site that will host good quality porn. > >> > >> I wouldn't be making any assumptions about high traffic loads early > >> in the game. > >> Therefore, performance or scalability shouldn't be all that relevant. > >> > >> I'm in the "build first, optimise later" camp. One of the things > >> I've learnt is that getting > >> to market first is what counts most. Afterwards, when most killer > >> ideas have been chewed > >> up and spat out, the remaining few are faced with other issues like > >> scalability. > >> > >> As for Twitter, a corner case I'd say. > >> > >> > >> Cheers, > >> > >> > >> Dan. > >> > >> > >> > >> On Wed, Apr 8, 2009 at 3:05 PM, Torm3nt wrote: > >> > >> Hey Dave, > >> > >> Cheers for the input man, greatly appreciated! > >> > >> My point about development time, depends on what the project is. If > >> it's a small, lightweight project then the quicker you can get it > >> out, > >> more than likely the better. If you're going to be creating a project > >> that is going to attract millions of hits a day, it would be worth > >> factoring that into the technology and framework choice, rather than > >> simply going with whatever is most comfortable. I know I myself have > >> fallen into that trap, and it cost me a lot later down the track. > >> > >> Software projects are very much a build first, optimize later - but > >> if > >> it means redeveloping your project (read: twitter), then it would > >> seem > >> that not enough planning and forethought was provided in order to > >> maximise on the platform of choice. (btw, I don't think twitter is > >> necessarily making the best decision =P) > >> > >> That said, not all software projects are web projects and this is > >> what > >> I was trying to stress (on multiple fronts - obviously I didn't > >> communicate it too well =( ). I mean, using rails to create a > >> reporting tool that outputs to console probably isn't the most sound > >> choice for the job, and on the other hand - embedding HTML within a > >> PHP script wouldn't be the best solution to an enterprise-scale > >> project, either. I've even seen on some forums people wanting to use > >> Rails just so that they have access to ActiveRecord, when there are > >> quite a few solutions out there for such a task, which isn't tied > >> to a > >> full-stack framework. > >> > >> "Seems like a bit of a dead issue to me anyway -- accepted practice > >> is > >> to develop then optimise." > >> > >> Very much like my DRY CSS post - it's more of a thought-provoking > >> exercise, and it helps me map my own current thoughts to paper, as > >> well as hope to do the same for others, as is done via this very > >> discussion =) > >> > >> > >> Cheers, > >> > >> Kirk > >> > >> On Wed, Apr 8, 2009 at 2:48 PM, Dave Bolton > >> wrote: > >> > I wasn't able to read your blog post before, but I understand > >> more what you > >> > are getting at now that your server is back up. > >> > > >> > So, you're talking about heavyweight in terms of performance. It's > >> > difficult t
[rails-oceania] Re: Right tool for the job
Without being trite, I'd like to say that I can't now see any reason to use another framework. "Best tool for the job" is a exactly the reason why. (As long as the job is "web application development", I guess.) Compare Rails feature for feature with any other framework. Rails 2.3 now provides all the mechanisms (and did with a bit of hacking previously) that you could ever need for web development. And it's in Ruby a great language by itself. Let's just go over the new and old "greatness" Ruby 1.9 (Low, low, low memory usage and very fast) Metal (Low, low, low latency) Active etc (Support and Record... too many to list) Passenger/Apache deploy Capistrano Git integration/support Plugins/Gems ... IMHO Scaling is s stupid a consideration anyway... I think for any good coder it is really is a joke. Any web app can handle several million hits per day on the right hardware - php, java, coldfusion, anything. Who cares? Processor time is cheap. Would you run a million(s) of hits a day app on a el-cheapo 256Mb linux VPS? No, you would start out small and build as needed. Although you almost can now with Rails. I benchmarked a non-trivial Rails shopping cart application on 1Gb Linux VPS at able to handle without serious slowdown approx 5-6 million requests per day. (~60 requests per second) If your app is getting anywhere close to those numbers you would have time to make some architecture changes to increase support (and perhaps pay for a real server or two). And I hadn't even done any caching. Every request was handled dynamically. Most apps I know of don't get more than 1-2 requests a minute (2-4000 requests per day). And as for twitter I never understood what exactly was running on Rails... The front-end? Should be a pretty easy Rails app and might need some architecture fixes but not huge. The back-end message passing/handling system? Running on Rails? You've got to be kidding me. Why? Write it in C, or even Ruby, (or Scala - boo!) but it doesn't involve Rails as far as I can see. -Adam On 08/04/2009, at 5:49 PM, David Lee wrote: > I recently began a reasonably small project where I expected > performance to be fairly important, and wanted a very small, simple > codebase. > > I started by setting up a sinatra app. Then i began including only > the parts of activesupport I felt i couldn't do without - a few > things from core_ext. > > Fast forward a few days, and I'd learnt a great deal about the > internals of activesupport by trying to include only the parts I > missed without loading the whole library - the dependencies don't > really like being . Ditto, a lot of stuff about rake and Rails' rake > tasks. I'd gotten a bastardised form of migrations going. The list > goes on ... > > I realized I was up against a variation of Greenspun's 10th rule > (http://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule > ) - I was spending more time on the stuff I normally take for > granted when writing Rails apps than I was on my problem domain. > > About that time rails 2.3 came out, and i thought to myself, if i > really need to worry about performance there's now Metal and various > freedoms afforded by Rack. I turned it into a Rails app and didn't > look back. > > " In one instance I witnessed a Rails application for getting > reports on a database." > > If I had to write a simple application to get reports out of a > database, and it was going to take more than a paragraph or two of > code, I'd use Rails without even mild hesitation. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~--~~~~--~~--~--~---
[rails-oceania] Re: Right tool for the job
That does depend a bit on just how "lightweight" the project is, and how day-to-day familiar you are with Rails. For example, I wanted to write a quick UI for a script that controls our build light - I can't really see a good reason to write something like that in Rails (unless perhaps my team were using rails day-to-day for everything; sadly, we aren't). - Korny On Wed, Apr 8, 2009 at 11:24 AM, Dr Nic Williams wrote: > People talk about "rails doesn't scale" and mean performance. What I love > about Rails is that scales for the size of the project. You can start a > micro project today, and it easily evolves into a bigger project. > The single-file-contains-my-app frameworks aren't wrong or broken; rather > they take away one of the oft-forgotten but awesome aspects of Rails: you > and I both know where our next model or controller is going to go. The > generators know it. The IDEs/editors know it. > > The heavy-weightedness of Rails will probably become optional as we move to > 3.0 and beyond. > > On Wed, Apr 8, 2009 at 11:19 AM, Torm3nt wrote: > >> >> Hey all! >> >> I've recently been musing over the use of heavy frameworks (such as >> RoR) and how I'm beginning to see (in some cases) them being overused, >> mostly for the wrong purposes. In one instance I witnessed a Rails >> application for getting reports on a database. >> >> I've written my thoughts on this and would love to hear from some of >> the more intelligent people in this community, either of their own >> experiences or even a counter-argument =) >> >> http://www.kirkbushell.com/articles/using-the-right-tool-for-the-job >> >> >> Cheers, >> >> Kirk Bushell >> >> >> > > > -- > Dr Nic Williams > Mocra - Premier iPhone and Ruby on Rails Consultants > w - http://mocra.com > twitter - @drnic > skype - nicwilliams > e - dr...@mocra.com > p - +61 412 002 126 or +61 7 3102 3237 > > > > > -- Kornelis Sietsma korny at my surname dot com "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of" --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~--~~~~--~~--~--~---
[rails-oceania] Re: Right tool for the job
That is the best blog post about scaling eva! LMAO On 08/04/2009, at 3:41 PM, David Turnbull wrote: > > Agreed, http://teddziuba.com/2008/04/im-going-to-scale-my-foot-up-y.html > > On 08/04/2009, at 3:39 PM, Cameron Barrie wrote: > >> I agree with that last point. >> I do loathe the twitter examples in regards to scaling(no disrespect >> meant to anyone BTW). >> I can't think of any framework/architecture out of the box that >> would have, Got that built for them quickly as it did, and not had a >> scaling issue. >> Twitter get's slammed by millions and millions of requests, nothing >> would've handled that load, nor should they have anticipated/ >> architected for that sort of load from the beginning. >> Granted they took to long to come up with a solution, but that's not >> he fault of the language/framework. It's a pretty freakin' good >> solution IMHO. >> >> I had a .Net dev telling me the other day he'd never use Rails since >> it doesn't scale, and pointed out twitter as his example, I asked >> him the last time he wrote a site/service designed to handle that >> sort of load, answer... Never has and probably never will. Like most >> of us. Then of course he also pointed out, that a .NET app straight >> out of the box would've died in the arse as well under that sort of >> load. >> >> Twitter is the scaling corner case or all corner cases. >> >> My opinion of twitter is more along the lines of you want to scale >> Rails, look at twitter that thing is freakin' crazy if they can >> scale that you can scale anything. With some hard thinking and good >> coders you can even make that shit work in Ruby. It's a developers >> best friend after all. :D >> >> C >> >> On 08/04/2009, at 3:26 PM, Daniel Sabados wrote: >> >>> IMHO, if one were building a site that would cater for millions of >>> hits per day before >>> they've even launched it, they've either hit the holy grail of >>> ideas or they're building >>> a site that will host good quality porn. >>> >>> I wouldn't be making any assumptions about high traffic loads early >>> in the game. >>> Therefore, performance or scalability shouldn't be all that >>> relevant. >>> >>> I'm in the "build first, optimise later" camp. One of the things >>> I've learnt is that getting >>> to market first is what counts most. Afterwards, when most killer >>> ideas have been chewed >>> up and spat out, the remaining few are faced with other issues like >>> scalability. >>> >>> As for Twitter, a corner case I'd say. >>> >>> >>> Cheers, >>> >>> >>> Dan. >>> >>> >>> >>> On Wed, Apr 8, 2009 at 3:05 PM, Torm3nt wrote: >>> >>> Hey Dave, >>> >>> Cheers for the input man, greatly appreciated! >>> >>> My point about development time, depends on what the project is. If >>> it's a small, lightweight project then the quicker you can get it >>> out, >>> more than likely the better. If you're going to be creating a >>> project >>> that is going to attract millions of hits a day, it would be worth >>> factoring that into the technology and framework choice, rather than >>> simply going with whatever is most comfortable. I know I myself have >>> fallen into that trap, and it cost me a lot later down the track. >>> >>> Software projects are very much a build first, optimize later - but >>> if >>> it means redeveloping your project (read: twitter), then it would >>> seem >>> that not enough planning and forethought was provided in order to >>> maximise on the platform of choice. (btw, I don't think twitter is >>> necessarily making the best decision =P) >>> >>> That said, not all software projects are web projects and this is >>> what >>> I was trying to stress (on multiple fronts - obviously I didn't >>> communicate it too well =( ). I mean, using rails to create a >>> reporting tool that outputs to console probably isn't the most sound >>> choice for the job, and on the other hand - embedding HTML within a >>> PHP script wouldn't be the best solution to an enterprise-scale >>> project, either. I've even seen on some forums people wanting to use >>> Rails just so that they have access to ActiveRecord, when there are >>> quite a few solutions out there for such a task, which isn't tied >>> to a >>> full-stack framework. >>> >>> "Seems like a bit of a dead issue to me anyway -- accepted practice >>> is >>> to develop then optimise." >>> >>> Very much like my DRY CSS post - it's more of a thought-provoking >>> exercise, and it helps me map my own current thoughts to paper, as >>> well as hope to do the same for others, as is done via this very >>> discussion =) >>> >>> >>> Cheers, >>> >>> Kirk >>> >>> On Wed, Apr 8, 2009 at 2:48 PM, Dave Bolton >>> wrote: I wasn't able to read your blog post before, but I understand >>> more what you are getting at now that your server is back up. So, you're talking about heavyweight in terms of performance. It's difficult to address your ideas without getting specific about >>> frameworks -- defensiveness be damned, if
[rails-oceania] Re: Right tool for the job
I think we're using "lightweight" to mean different things here. Lightweight as in "Hello world" apps versus Lightweight as in "A bare minimum stack only serving a selected subset of functions at high speed". I happily use Rails for tiny "hello world" and "getting reports on a database", because they fall into the first category. - Andrew --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~--~~~~--~~--~--~---
[rails-oceania] Re: Right tool for the job
Agreed, http://teddziuba.com/2008/04/im-going-to-scale-my-foot-up-y.html On 08/04/2009, at 3:39 PM, Cameron Barrie wrote: > I agree with that last point. > I do loathe the twitter examples in regards to scaling(no disrespect > meant to anyone BTW). > I can't think of any framework/architecture out of the box that > would have, Got that built for them quickly as it did, and not had a > scaling issue. > Twitter get's slammed by millions and millions of requests, nothing > would've handled that load, nor should they have anticipated/ > architected for that sort of load from the beginning. > Granted they took to long to come up with a solution, but that's not > he fault of the language/framework. It's a pretty freakin' good > solution IMHO. > > I had a .Net dev telling me the other day he'd never use Rails since > it doesn't scale, and pointed out twitter as his example, I asked > him the last time he wrote a site/service designed to handle that > sort of load, answer... Never has and probably never will. Like most > of us. Then of course he also pointed out, that a .NET app straight > out of the box would've died in the arse as well under that sort of > load. > > Twitter is the scaling corner case or all corner cases. > > My opinion of twitter is more along the lines of you want to scale > Rails, look at twitter that thing is freakin' crazy if they can > scale that you can scale anything. With some hard thinking and good > coders you can even make that shit work in Ruby. It's a developers > best friend after all. :D > > C > > On 08/04/2009, at 3:26 PM, Daniel Sabados wrote: > >> IMHO, if one were building a site that would cater for millions of >> hits per day before >> they've even launched it, they've either hit the holy grail of >> ideas or they're building >> a site that will host good quality porn. >> >> I wouldn't be making any assumptions about high traffic loads early >> in the game. >> Therefore, performance or scalability shouldn't be all that relevant. >> >> I'm in the "build first, optimise later" camp. One of the things >> I've learnt is that getting >> to market first is what counts most. Afterwards, when most killer >> ideas have been chewed >> up and spat out, the remaining few are faced with other issues like >> scalability. >> >> As for Twitter, a corner case I'd say. >> >> >> Cheers, >> >> >> Dan. >> >> >> >> On Wed, Apr 8, 2009 at 3:05 PM, Torm3nt wrote: >> >> Hey Dave, >> >> Cheers for the input man, greatly appreciated! >> >> My point about development time, depends on what the project is. If >> it's a small, lightweight project then the quicker you can get it >> out, >> more than likely the better. If you're going to be creating a project >> that is going to attract millions of hits a day, it would be worth >> factoring that into the technology and framework choice, rather than >> simply going with whatever is most comfortable. I know I myself have >> fallen into that trap, and it cost me a lot later down the track. >> >> Software projects are very much a build first, optimize later - but >> if >> it means redeveloping your project (read: twitter), then it would >> seem >> that not enough planning and forethought was provided in order to >> maximise on the platform of choice. (btw, I don't think twitter is >> necessarily making the best decision =P) >> >> That said, not all software projects are web projects and this is >> what >> I was trying to stress (on multiple fronts - obviously I didn't >> communicate it too well =( ). I mean, using rails to create a >> reporting tool that outputs to console probably isn't the most sound >> choice for the job, and on the other hand - embedding HTML within a >> PHP script wouldn't be the best solution to an enterprise-scale >> project, either. I've even seen on some forums people wanting to use >> Rails just so that they have access to ActiveRecord, when there are >> quite a few solutions out there for such a task, which isn't tied >> to a >> full-stack framework. >> >> "Seems like a bit of a dead issue to me anyway -- accepted practice >> is >> to develop then optimise." >> >> Very much like my DRY CSS post - it's more of a thought-provoking >> exercise, and it helps me map my own current thoughts to paper, as >> well as hope to do the same for others, as is done via this very >> discussion =) >> >> >> Cheers, >> >> Kirk >> >> On Wed, Apr 8, 2009 at 2:48 PM, Dave Bolton >> wrote: >> > I wasn't able to read your blog post before, but I understand >> more what you >> > are getting at now that your server is back up. >> > >> > So, you're talking about heavyweight in terms of performance. It's >> > difficult to address your ideas without getting specific about >> frameworks -- >> > defensiveness be damned, if you're going to call out heavyweight >> frameworks >> > you *need* to get specific so we can discuss. >> > >> > The example in your email of a Rails app for database report
[rails-oceania] Re: Right tool for the job
I recently began a reasonably small project where I expected performance to be fairly important, and wanted a very small, simple codebase. I started by setting up a sinatra app. Then i began including only the parts of activesupport I felt i couldn't do without - a few things from core_ext. Fast forward a few days, and I'd learnt a great deal about the internals of activesupport by trying to include only the parts I missed without loading the whole library - the dependencies don't really like being . Ditto, a lot of stuff about rake and Rails' rake tasks. I'd gotten a bastardised form of migrations going. The list goes on ... I realized I was up against a variation of Greenspun's 10th rule ( http://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule) - I was spending more time on the stuff I normally take for granted when writing Rails apps than I was on my problem domain. About that time rails 2.3 came out, and i thought to myself, if i really need to worry about performance there's now Metal and various freedoms afforded by Rack. I turned it into a Rails app and didn't look back. " In one instance I witnessed a Rails application for getting reports on a database." If I had to write a simple application to get reports out of a database, and it was going to take more than a paragraph or two of code, I'd use Rails without even mild hesitation. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~--~~~~--~~--~--~---
[rails-oceania] Re: Right tool for the job
I agree with that last point. I do loathe the twitter examples in regards to scaling(no disrespect meant to anyone BTW). I can't think of any framework/architecture out of the box that would have, Got that built for them quickly as it did, and not had a scaling issue. Twitter get's slammed by millions and millions of requests, nothing would've handled that load, nor should they have anticipated/ architected for that sort of load from the beginning. Granted they took to long to come up with a solution, but that's not he fault of the language/framework. It's a pretty freakin' good solution IMHO. I had a .Net dev telling me the other day he'd never use Rails since it doesn't scale, and pointed out twitter as his example, I asked him the last time he wrote a site/service designed to handle that sort of load, answer... Never has and probably never will. Like most of us. Then of course he also pointed out, that a .NET app straight out of the box would've died in the arse as well under that sort of load. Twitter is the scaling corner case or all corner cases. My opinion of twitter is more along the lines of you want to scale Rails, look at twitter that thing is freakin' crazy if they can scale that you can scale anything. With some hard thinking and good coders you can even make that shit work in Ruby. It's a developers best friend after all. :D C On 08/04/2009, at 3:26 PM, Daniel Sabados wrote: > IMHO, if one were building a site that would cater for millions of > hits per day before > they've even launched it, they've either hit the holy grail of ideas > or they're building > a site that will host good quality porn. > > I wouldn't be making any assumptions about high traffic loads early > in the game. > Therefore, performance or scalability shouldn't be all that relevant. > > I'm in the "build first, optimise later" camp. One of the things > I've learnt is that getting > to market first is what counts most. Afterwards, when most killer > ideas have been chewed > up and spat out, the remaining few are faced with other issues like > scalability. > > As for Twitter, a corner case I'd say. > > > Cheers, > > > Dan. > > > > On Wed, Apr 8, 2009 at 3:05 PM, Torm3nt wrote: > > Hey Dave, > > Cheers for the input man, greatly appreciated! > > My point about development time, depends on what the project is. If > it's a small, lightweight project then the quicker you can get it out, > more than likely the better. If you're going to be creating a project > that is going to attract millions of hits a day, it would be worth > factoring that into the technology and framework choice, rather than > simply going with whatever is most comfortable. I know I myself have > fallen into that trap, and it cost me a lot later down the track. > > Software projects are very much a build first, optimize later - but if > it means redeveloping your project (read: twitter), then it would seem > that not enough planning and forethought was provided in order to > maximise on the platform of choice. (btw, I don't think twitter is > necessarily making the best decision =P) > > That said, not all software projects are web projects and this is what > I was trying to stress (on multiple fronts - obviously I didn't > communicate it too well =( ). I mean, using rails to create a > reporting tool that outputs to console probably isn't the most sound > choice for the job, and on the other hand - embedding HTML within a > PHP script wouldn't be the best solution to an enterprise-scale > project, either. I've even seen on some forums people wanting to use > Rails just so that they have access to ActiveRecord, when there are > quite a few solutions out there for such a task, which isn't tied to a > full-stack framework. > > "Seems like a bit of a dead issue to me anyway -- accepted practice is > to develop then optimise." > > Very much like my DRY CSS post - it's more of a thought-provoking > exercise, and it helps me map my own current thoughts to paper, as > well as hope to do the same for others, as is done via this very > discussion =) > > > Cheers, > > Kirk > > On Wed, Apr 8, 2009 at 2:48 PM, Dave Bolton > wrote: > > I wasn't able to read your blog post before, but I understand more > what you > > are getting at now that your server is back up. > > > > So, you're talking about heavyweight in terms of performance. It's > > difficult to address your ideas without getting specific about > frameworks -- > > defensiveness be damned, if you're going to call out heavyweight > frameworks > > you *need* to get specific so we can discuss. > > > > The example in your email of a Rails app for database reports > seems at odds > > with the blog post. Is a reporting app ever going to need to > serve so many > > pages that the framework is the issue? I think not. > > > >> [from blog post]: "Development time is generally much more > expensive than > >> hardware (unless you're serving millions of page
[rails-oceania] Re: Right tool for the job
Okay, I see. It sounded like you were purely talking about web frameworks. For clarity it could be worth rewording part of your blog post, I think that point may be lost in the mix. Definitely agree that using a web framework for a non-web project is non-sensical. Similarly, using Ruby for a high performance concurrent message queuing system (ala Twitter) would make life difficult at some level of success. But it didn't kill them despite the astronomical success, and in twelve months that portion of the system will be in a better place than it is now, so it's probably somewhat of a validation of build first, optimise later approach. Cheers, Dave On Wed, Apr 8, 2009 at 3:05 PM, Torm3nt wrote: > > Hey Dave, > > Cheers for the input man, greatly appreciated! > > My point about development time, depends on what the project is. If > it's a small, lightweight project then the quicker you can get it out, > more than likely the better. If you're going to be creating a project > that is going to attract millions of hits a day, it would be worth > factoring that into the technology and framework choice, rather than > simply going with whatever is most comfortable. I know I myself have > fallen into that trap, and it cost me a lot later down the track. > > Software projects are very much a build first, optimize later - but if > it means redeveloping your project (read: twitter), then it would seem > that not enough planning and forethought was provided in order to > maximise on the platform of choice. (btw, I don't think twitter is > necessarily making the best decision =P) > > That said, not all software projects are web projects and this is what > I was trying to stress (on multiple fronts - obviously I didn't > communicate it too well =( ). I mean, using rails to create a > reporting tool that outputs to console probably isn't the most sound > choice for the job, and on the other hand - embedding HTML within a > PHP script wouldn't be the best solution to an enterprise-scale > project, either. I've even seen on some forums people wanting to use > Rails just so that they have access to ActiveRecord, when there are > quite a few solutions out there for such a task, which isn't tied to a > full-stack framework. > > "Seems like a bit of a dead issue to me anyway -- accepted practice is > to develop then optimise." > > Very much like my DRY CSS post - it's more of a thought-provoking > exercise, and it helps me map my own current thoughts to paper, as > well as hope to do the same for others, as is done via this very > discussion =) > > > Cheers, > > Kirk > > On Wed, Apr 8, 2009 at 2:48 PM, Dave Bolton wrote: > > I wasn't able to read your blog post before, but I understand more what > you > > are getting at now that your server is back up. > > > > So, you're talking about heavyweight in terms of performance. It's > > difficult to address your ideas without getting specific about frameworks > -- > > defensiveness be damned, if you're going to call out heavyweight > frameworks > > you *need* to get specific so we can discuss. > > > > The example in your email of a Rails app for database reports seems at > odds > > with the blog post. Is a reporting app ever going to need to serve so > many > > pages that the framework is the issue? I think not. > > > >> [from blog post]: "Development time is generally much more expensive > than > >> hardware (unless you're serving millions of page view per day), and so > >> therefore (depending on the project) a sound and educated decision > should be > >> made, rather than simply jumping into your favourite development > framework." > > > > Given that development time is more expensive than hardware, then that is > > EXACTLY the reason you should use your favourite framework first. I take > > your point that when you have a hammer, every problem seems to be a nail, > > but also, if you're developing for the web, many problems *are* nails, > and > > most frameworks *are* hammers. Just use the one you are most comfortable > > with. > > > > Seems like a bit of a dead issue to me anyway -- accepted practice is to > > develop then optimise. Are there any frameworks that are really that bad > > that performance is going to kill you before your site is massive anyway? > > (if caching is used) > > > > Cheers, > > Dave > > > > > > On Wed, Apr 8, 2009 at 12:05 PM, Torm3nt wrote: > >> > >> Well there were a couple of frameworks, but I was trying to be > >> framework-agnostic for a reason - there are a few that are quite heavy > >> and load up a lot of files and libraries, even if they're not used - > >> so as to make the job easier for the developer. Plus I didn't want to > >> be labelled as a "oh he doesn't like framework x so he mustn't be > >> good with it".etc. If I targeted any specific framework, people are > >> bound to get defensive of their framework of choice, which detracts > >> from what I wanted to convey. > >> > >> > >> Kirk > >> > >> > >> > >> On Wed, Apr 8, 2009
[rails-oceania] Re: Right tool for the job
IMHO, if one were building a site that would cater for millions of hits per day before they've even launched it, they've either hit the holy grail of ideas or they're building a site that will host good quality porn. I wouldn't be making any assumptions about high traffic loads early in the game. Therefore, performance or scalability shouldn't be all that relevant. I'm in the "build first, optimise later" camp. One of the things I've learnt is that getting to market first is what counts most. Afterwards, when most killer ideas have been chewed up and spat out, the remaining few are faced with other issues like scalability. As for Twitter, a corner case I'd say. Cheers, Dan. On Wed, Apr 8, 2009 at 3:05 PM, Torm3nt wrote: > > Hey Dave, > > Cheers for the input man, greatly appreciated! > > My point about development time, depends on what the project is. If > it's a small, lightweight project then the quicker you can get it out, > more than likely the better. If you're going to be creating a project > that is going to attract millions of hits a day, it would be worth > factoring that into the technology and framework choice, rather than > simply going with whatever is most comfortable. I know I myself have > fallen into that trap, and it cost me a lot later down the track. > > Software projects are very much a build first, optimize later - but if > it means redeveloping your project (read: twitter), then it would seem > that not enough planning and forethought was provided in order to > maximise on the platform of choice. (btw, I don't think twitter is > necessarily making the best decision =P) > > That said, not all software projects are web projects and this is what > I was trying to stress (on multiple fronts - obviously I didn't > communicate it too well =( ). I mean, using rails to create a > reporting tool that outputs to console probably isn't the most sound > choice for the job, and on the other hand - embedding HTML within a > PHP script wouldn't be the best solution to an enterprise-scale > project, either. I've even seen on some forums people wanting to use > Rails just so that they have access to ActiveRecord, when there are > quite a few solutions out there for such a task, which isn't tied to a > full-stack framework. > > "Seems like a bit of a dead issue to me anyway -- accepted practice is > to develop then optimise." > > Very much like my DRY CSS post - it's more of a thought-provoking > exercise, and it helps me map my own current thoughts to paper, as > well as hope to do the same for others, as is done via this very > discussion =) > > > Cheers, > > Kirk > > On Wed, Apr 8, 2009 at 2:48 PM, Dave Bolton wrote: > > I wasn't able to read your blog post before, but I understand more what > you > > are getting at now that your server is back up. > > > > So, you're talking about heavyweight in terms of performance. It's > > difficult to address your ideas without getting specific about frameworks > -- > > defensiveness be damned, if you're going to call out heavyweight > frameworks > > you *need* to get specific so we can discuss. > > > > The example in your email of a Rails app for database reports seems at > odds > > with the blog post. Is a reporting app ever going to need to serve so > many > > pages that the framework is the issue? I think not. > > > >> [from blog post]: "Development time is generally much more expensive > than > >> hardware (unless you're serving millions of page view per day), and so > >> therefore (depending on the project) a sound and educated decision > should be > >> made, rather than simply jumping into your favourite development > framework." > > > > Given that development time is more expensive than hardware, then that is > > EXACTLY the reason you should use your favourite framework first. I take > > your point that when you have a hammer, every problem seems to be a nail, > > but also, if you're developing for the web, many problems *are* nails, > and > > most frameworks *are* hammers. Just use the one you are most comfortable > > with. > > > > Seems like a bit of a dead issue to me anyway -- accepted practice is to > > develop then optimise. Are there any frameworks that are really that bad > > that performance is going to kill you before your site is massive anyway? > > (if caching is used) > > > > Cheers, > > Dave > > > > > > On Wed, Apr 8, 2009 at 12:05 PM, Torm3nt wrote: > >> > >> Well there were a couple of frameworks, but I was trying to be > >> framework-agnostic for a reason - there are a few that are quite heavy > >> and load up a lot of files and libraries, even if they're not used - > >> so as to make the job easier for the developer. Plus I didn't want to > >> be labelled as a "oh he doesn't like framework x so he mustn't be > >> good with it".etc. If I targeted any specific framework, people are > >> bound to get defensive of their framework of choice, which detracts > >> from what I wanted to convey. > >> > >> > >> Kirk > >> >
[rails-oceania] Re: Right tool for the job
Hey Dave, Cheers for the input man, greatly appreciated! My point about development time, depends on what the project is. If it's a small, lightweight project then the quicker you can get it out, more than likely the better. If you're going to be creating a project that is going to attract millions of hits a day, it would be worth factoring that into the technology and framework choice, rather than simply going with whatever is most comfortable. I know I myself have fallen into that trap, and it cost me a lot later down the track. Software projects are very much a build first, optimize later - but if it means redeveloping your project (read: twitter), then it would seem that not enough planning and forethought was provided in order to maximise on the platform of choice. (btw, I don't think twitter is necessarily making the best decision =P) That said, not all software projects are web projects and this is what I was trying to stress (on multiple fronts - obviously I didn't communicate it too well =( ). I mean, using rails to create a reporting tool that outputs to console probably isn't the most sound choice for the job, and on the other hand - embedding HTML within a PHP script wouldn't be the best solution to an enterprise-scale project, either. I've even seen on some forums people wanting to use Rails just so that they have access to ActiveRecord, when there are quite a few solutions out there for such a task, which isn't tied to a full-stack framework. "Seems like a bit of a dead issue to me anyway -- accepted practice is to develop then optimise." Very much like my DRY CSS post - it's more of a thought-provoking exercise, and it helps me map my own current thoughts to paper, as well as hope to do the same for others, as is done via this very discussion =) Cheers, Kirk On Wed, Apr 8, 2009 at 2:48 PM, Dave Bolton wrote: > I wasn't able to read your blog post before, but I understand more what you > are getting at now that your server is back up. > > So, you're talking about heavyweight in terms of performance. It's > difficult to address your ideas without getting specific about frameworks -- > defensiveness be damned, if you're going to call out heavyweight frameworks > you *need* to get specific so we can discuss. > > The example in your email of a Rails app for database reports seems at odds > with the blog post. Is a reporting app ever going to need to serve so many > pages that the framework is the issue? I think not. > >> [from blog post]: "Development time is generally much more expensive than >> hardware (unless you're serving millions of page view per day), and so >> therefore (depending on the project) a sound and educated decision should be >> made, rather than simply jumping into your favourite development framework." > > Given that development time is more expensive than hardware, then that is > EXACTLY the reason you should use your favourite framework first. I take > your point that when you have a hammer, every problem seems to be a nail, > but also, if you're developing for the web, many problems *are* nails, and > most frameworks *are* hammers. Just use the one you are most comfortable > with. > > Seems like a bit of a dead issue to me anyway -- accepted practice is to > develop then optimise. Are there any frameworks that are really that bad > that performance is going to kill you before your site is massive anyway? > (if caching is used) > > Cheers, > Dave > > > On Wed, Apr 8, 2009 at 12:05 PM, Torm3nt wrote: >> >> Well there were a couple of frameworks, but I was trying to be >> framework-agnostic for a reason - there are a few that are quite heavy >> and load up a lot of files and libraries, even if they're not used - >> so as to make the job easier for the developer. Plus I didn't want to >> be labelled as a "oh he doesn't like framework x so he mustn't be >> good with it".etc. If I targeted any specific framework, people are >> bound to get defensive of their framework of choice, which detracts >> from what I wanted to convey. >> >> >> Kirk >> >> >> >> On Wed, Apr 8, 2009 at 12:01 PM, Dave Bolton wrote: >> > - Which frameworks are you targeting? >> > - Heavyweight in what sense? Resources? Concepts? Performance? >> > >> > With respect to Rails, I don't have a problem throwing it at small ideas >> > -- >> > the concepts are easy and standard, and resource requirements are not so >> > onerous to make it unfeasible (in all senses of resources). >> > >> > I guess you could mean heavyweight in the sense of all the things Rails >> > lets >> > you do out-of-the-box, but there's no compulsion to use them all, and >> > I'd be >> > suprised if they changed the resource and performance equations so much >> > to >> > make Rails no longer an option. >> > >> > So, put me in Dr Nic's "scales for the size of the project" bucket. >> > >> > Cheers, >> > Dave >> > >> > >> > On Wed, Apr 8, 2009 at 11:35 AM, Torm3nt wrote: >> >> >> >> Cheers for your input Dr Nic, >> >> >> >> I
[rails-oceania] Re: Right tool for the job
I wasn't able to read your blog post before, but I understand more what you are getting at now that your server is back up. So, you're talking about heavyweight in terms of performance. It's difficult to address your ideas without getting specific about frameworks -- defensiveness be damned, if you're going to call out heavyweight frameworks you *need* to get specific so we can discuss. The example in your email of a Rails app for database reports seems at odds with the blog post. Is a reporting app ever going to need to serve so many pages that the framework is the issue? I think not. > [from blog post]: "Development time is generally much more expensive than hardware (unless you're serving millions of page view per day), and so therefore (depending on the project) a sound and educated decision should be made, rather than simply jumping into your favourite development framework." Given that development time is more expensive than hardware, then that is EXACTLY the reason you should use your favourite framework first. I take your point that when you have a hammer, every problem seems to be a nail, but also, if you're developing for the web, many problems *are* nails, and most frameworks *are* hammers. Just use the one you are most comfortable with. Seems like a bit of a dead issue to me anyway -- accepted practice is to develop then optimise. Are there any frameworks that are really that bad that performance is going to kill you before your site is massive anyway? (if caching is used) Cheers, Dave On Wed, Apr 8, 2009 at 12:05 PM, Torm3nt wrote: > > Well there were a couple of frameworks, but I was trying to be > framework-agnostic for a reason - there are a few that are quite heavy > and load up a lot of files and libraries, even if they're not used - > so as to make the job easier for the developer. Plus I didn't want to > be labelled as a "oh he doesn't like framework x so he mustn't be > good with it".etc. If I targeted any specific framework, people are > bound to get defensive of their framework of choice, which detracts > from what I wanted to convey. > > > Kirk > > > > On Wed, Apr 8, 2009 at 12:01 PM, Dave Bolton wrote: > > - Which frameworks are you targeting? > > - Heavyweight in what sense? Resources? Concepts? Performance? > > > > With respect to Rails, I don't have a problem throwing it at small ideas > -- > > the concepts are easy and standard, and resource requirements are not so > > onerous to make it unfeasible (in all senses of resources). > > > > I guess you could mean heavyweight in the sense of all the things Rails > lets > > you do out-of-the-box, but there's no compulsion to use them all, and I'd > be > > suprised if they changed the resource and performance equations so much > to > > make Rails no longer an option. > > > > So, put me in Dr Nic's "scales for the size of the project" bucket. > > > > Cheers, > > Dave > > > > > > On Wed, Apr 8, 2009 at 11:35 AM, Torm3nt wrote: > >> > >> Cheers for your input Dr Nic, > >> > >> I wasn't actually specifically targeting rails - rails 3.0 certainly > >> looks to be much more enticing as far as frameworks goes as you'll be > >> able to plug and play various libraries together, but not many > >> frameworks do this =P > >> > >> > >> Kirk > >> > >> On Wed, Apr 8, 2009 at 11:24 AM, Dr Nic Williams > wrote: > >> > People talk about "rails doesn't scale" and mean performance. What I > >> > love > >> > about Rails is that scales for the size of the project. You can start > a > >> > micro project today, and it easily evolves into a bigger project. > >> > The single-file-contains-my-app frameworks aren't wrong or broken; > >> > rather > >> > they take away one of the oft-forgotten but awesome aspects of Rails: > >> > you > >> > and I both know where our next model or controller is going to go. The > >> > generators know it. The IDEs/editors know it. > >> > The heavy-weightedness of Rails will probably become optional as we > move > >> > to > >> > 3.0 and beyond. > >> > > >> > On Wed, Apr 8, 2009 at 11:19 AM, Torm3nt wrote: > >> >> > >> >> Hey all! > >> >> > >> >> I've recently been musing over the use of heavy frameworks (such as > >> >> RoR) and how I'm beginning to see (in some cases) them being > overused, > >> >> mostly for the wrong purposes. In one instance I witnessed a Rails > >> >> application for getting reports on a database. > >> >> > >> >> I've written my thoughts on this and would love to hear from some of > >> >> the more intelligent people in this community, either of their own > >> >> experiences or even a counter-argument =) > >> >> > >> >> http://www.kirkbushell.com/articles/using-the-right-tool-for-the-job > >> >> > >> >> > >> >> Cheers, > >> >> > >> >> Kirk Bushell > >> >> > >> >> > >> > > >> > > >> > > >> > -- > >> > Dr Nic Williams > >> > Mocra - Premier iPhone and Ruby on Rails Consultants > >> > w - http://mocra.com > >> > twitter - @drnic > >> > skype - nicwilliams > >> > e - dr...@mocra.com > >> > p - +6
[rails-oceania] Re: Right tool for the job
At a personal level, I can only be proficient with a certain number of tools (with that number approaching 0 over time). While there might be a more appropriate tool for a project in a global sense, the time-to- learn might eliminate it. It's good to distinguish between the two situations and acknowledge which factor is driving the decision. Steve Hayes On 08/04/2009, at 12:05 PM, Torm3nt wrote: > > Well there were a couple of frameworks, but I was trying to be > framework-agnostic for a reason - there are a few that are quite heavy > and load up a lot of files and libraries, even if they're not used - > so as to make the job easier for the developer. Plus I didn't want to > be labelled as a "oh he doesn't like framework x so he mustn't be > good with it".etc. If I targeted any specific framework, people are > bound to get defensive of their framework of choice, which detracts > from what I wanted to convey. > > > Kirk > > > > On Wed, Apr 8, 2009 at 12:01 PM, Dave Bolton > wrote: >> - Which frameworks are you targeting? >> - Heavyweight in what sense? Resources? Concepts? Performance? >> >> With respect to Rails, I don't have a problem throwing it at small >> ideas -- >> the concepts are easy and standard, and resource requirements are >> not so >> onerous to make it unfeasible (in all senses of resources). >> >> I guess you could mean heavyweight in the sense of all the things >> Rails lets >> you do out-of-the-box, but there's no compulsion to use them all, >> and I'd be >> suprised if they changed the resource and performance equations so >> much to >> make Rails no longer an option. >> >> So, put me in Dr Nic's "scales for the size of the project" bucket. >> >> Cheers, >> Dave >> >> >> On Wed, Apr 8, 2009 at 11:35 AM, Torm3nt wrote: >>> >>> Cheers for your input Dr Nic, >>> >>> I wasn't actually specifically targeting rails - rails 3.0 certainly >>> looks to be much more enticing as far as frameworks goes as you'll >>> be >>> able to plug and play various libraries together, but not many >>> frameworks do this =P >>> >>> >>> Kirk >>> >>> On Wed, Apr 8, 2009 at 11:24 AM, Dr Nic Williams >>> wrote: People talk about "rails doesn't scale" and mean performance. What I love about Rails is that scales for the size of the project. You can start a micro project today, and it easily evolves into a bigger project. The single-file-contains-my-app frameworks aren't wrong or broken; rather they take away one of the oft-forgotten but awesome aspects of Rails: you and I both know where our next model or controller is going to go. The generators know it. The IDEs/editors know it. The heavy-weightedness of Rails will probably become optional as we move to 3.0 and beyond. On Wed, Apr 8, 2009 at 11:19 AM, Torm3nt wrote: > > Hey all! > > I've recently been musing over the use of heavy frameworks (such > as > RoR) and how I'm beginning to see (in some cases) them being > overused, > mostly for the wrong purposes. In one instance I witnessed a Rails > application for getting reports on a database. > > I've written my thoughts on this and would love to hear from > some of > the more intelligent people in this community, either of their own > experiences or even a counter-argument =) > > http://www.kirkbushell.com/articles/using-the-right-tool-for-the-job > > > Cheers, > > Kirk Bushell > > -- Dr Nic Williams Mocra - Premier iPhone and Ruby on Rails Consultants w - http://mocra.com twitter - @drnic skype - nicwilliams e - dr...@mocra.com p - +61 412 002 126 or +61 7 3102 3237 > >>> >>> >> >> >>> >> > > > Steve --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~--~~~~--~~--~--~---
[rails-oceania] Re: Right tool for the job
Well there were a couple of frameworks, but I was trying to be framework-agnostic for a reason - there are a few that are quite heavy and load up a lot of files and libraries, even if they're not used - so as to make the job easier for the developer. Plus I didn't want to be labelled as a "oh he doesn't like framework x so he mustn't be good with it".etc. If I targeted any specific framework, people are bound to get defensive of their framework of choice, which detracts from what I wanted to convey. Kirk On Wed, Apr 8, 2009 at 12:01 PM, Dave Bolton wrote: > - Which frameworks are you targeting? > - Heavyweight in what sense? Resources? Concepts? Performance? > > With respect to Rails, I don't have a problem throwing it at small ideas -- > the concepts are easy and standard, and resource requirements are not so > onerous to make it unfeasible (in all senses of resources). > > I guess you could mean heavyweight in the sense of all the things Rails lets > you do out-of-the-box, but there's no compulsion to use them all, and I'd be > suprised if they changed the resource and performance equations so much to > make Rails no longer an option. > > So, put me in Dr Nic's "scales for the size of the project" bucket. > > Cheers, > Dave > > > On Wed, Apr 8, 2009 at 11:35 AM, Torm3nt wrote: >> >> Cheers for your input Dr Nic, >> >> I wasn't actually specifically targeting rails - rails 3.0 certainly >> looks to be much more enticing as far as frameworks goes as you'll be >> able to plug and play various libraries together, but not many >> frameworks do this =P >> >> >> Kirk >> >> On Wed, Apr 8, 2009 at 11:24 AM, Dr Nic Williams wrote: >> > People talk about "rails doesn't scale" and mean performance. What I >> > love >> > about Rails is that scales for the size of the project. You can start a >> > micro project today, and it easily evolves into a bigger project. >> > The single-file-contains-my-app frameworks aren't wrong or broken; >> > rather >> > they take away one of the oft-forgotten but awesome aspects of Rails: >> > you >> > and I both know where our next model or controller is going to go. The >> > generators know it. The IDEs/editors know it. >> > The heavy-weightedness of Rails will probably become optional as we move >> > to >> > 3.0 and beyond. >> > >> > On Wed, Apr 8, 2009 at 11:19 AM, Torm3nt wrote: >> >> >> >> Hey all! >> >> >> >> I've recently been musing over the use of heavy frameworks (such as >> >> RoR) and how I'm beginning to see (in some cases) them being overused, >> >> mostly for the wrong purposes. In one instance I witnessed a Rails >> >> application for getting reports on a database. >> >> >> >> I've written my thoughts on this and would love to hear from some of >> >> the more intelligent people in this community, either of their own >> >> experiences or even a counter-argument =) >> >> >> >> http://www.kirkbushell.com/articles/using-the-right-tool-for-the-job >> >> >> >> >> >> Cheers, >> >> >> >> Kirk Bushell >> >> >> >> >> > >> > >> > >> > -- >> > Dr Nic Williams >> > Mocra - Premier iPhone and Ruby on Rails Consultants >> > w - http://mocra.com >> > twitter - @drnic >> > skype - nicwilliams >> > e - dr...@mocra.com >> > p - +61 412 002 126 or +61 7 3102 3237 >> > >> > >> > > >> > >> >> > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~--~~~~--~~--~--~---
[rails-oceania] Re: Right tool for the job
- Which frameworks are you targeting? - Heavyweight in what sense? Resources? Concepts? Performance? With respect to Rails, I don't have a problem throwing it at small ideas -- the concepts are easy and standard, and resource requirements are not so onerous to make it unfeasible (in all senses of resources). I guess you could mean heavyweight in the sense of all the things Rails lets you do out-of-the-box, but there's no compulsion to use them all, and I'd be suprised if they changed the resource and performance equations so much to make Rails no longer an option. So, put me in Dr Nic's "scales for the size of the project" bucket. Cheers, Dave On Wed, Apr 8, 2009 at 11:35 AM, Torm3nt wrote: > > Cheers for your input Dr Nic, > > I wasn't actually specifically targeting rails - rails 3.0 certainly > looks to be much more enticing as far as frameworks goes as you'll be > able to plug and play various libraries together, but not many > frameworks do this =P > > > Kirk > > On Wed, Apr 8, 2009 at 11:24 AM, Dr Nic Williams wrote: > > People talk about "rails doesn't scale" and mean performance. What I love > > about Rails is that scales for the size of the project. You can start a > > micro project today, and it easily evolves into a bigger project. > > The single-file-contains-my-app frameworks aren't wrong or broken; rather > > they take away one of the oft-forgotten but awesome aspects of Rails: you > > and I both know where our next model or controller is going to go. The > > generators know it. The IDEs/editors know it. > > The heavy-weightedness of Rails will probably become optional as we move > to > > 3.0 and beyond. > > > > On Wed, Apr 8, 2009 at 11:19 AM, Torm3nt wrote: > >> > >> Hey all! > >> > >> I've recently been musing over the use of heavy frameworks (such as > >> RoR) and how I'm beginning to see (in some cases) them being overused, > >> mostly for the wrong purposes. In one instance I witnessed a Rails > >> application for getting reports on a database. > >> > >> I've written my thoughts on this and would love to hear from some of > >> the more intelligent people in this community, either of their own > >> experiences or even a counter-argument =) > >> > >> http://www.kirkbushell.com/articles/using-the-right-tool-for-the-job > >> > >> > >> Cheers, > >> > >> Kirk Bushell > >> > >> > > > > > > > > -- > > Dr Nic Williams > > Mocra - Premier iPhone and Ruby on Rails Consultants > > w - http://mocra.com > > twitter - @drnic > > skype - nicwilliams > > e - dr...@mocra.com > > p - +61 412 002 126 or +61 7 3102 3237 > > > > > > > > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~--~~~~--~~--~--~---
[rails-oceania] Re: Right tool for the job
Server should be a bit more responsive now - reduced the Poolsize of the spawn servers to 2 (default 6). Only have 256mb ram on that slice, so it got chewed up pretty quickly - should be better now =) @ Mike: I use wordpress for torm3nt.com, mephisto for kirkbushell.com - both of which I find easy to use, but I actually prefer mephisto - it's simpler, for one - and I got to look at how someone else uses their Rails framework, plus it was also used as a test case to setup my own server.etc, and learn from it (as was just demonstrated. heh) Cheers, Kirk On Wed, Apr 8, 2009 at 11:56 AM, Mike Bailey wrote: > > In the spirit of 'right tools for the job' I would suggest using > Wordpress for your blog. > > It has an awesome CMS and I've found it to be very reliable over the years. > > Writing a blog engine is a fun weekend project, but I wouldn't run my > blog on someones weekend project. > > - Mike > > On Wed, Apr 8, 2009 at 11:42 AM, Torm3nt wrote: >> >> hahaha >> >> Yeah there seems to be an issue with passenger, with all passenger >> processes sitting at around 22% =\ >> >> Trying to figure out what's going on there, as that's definitely not cool. >> hehe >> >> Have reset the processes and restarted apache numerous times, doesn't >> seem to be resolving the issue. >> >> >> Cheers, >> >> Kirk >> >> On Wed, Apr 8, 2009 at 11:37 AM, Julio Cesar Ody wrote: >>> >>> By the way, Kirk, it seems your blog doesn't scale. Requests are >>> timing out both from where I am and my VM in the Soviet States of >>> America. >>> >>> Must be Rails. Rewrite it in Scala. >>> >>> *ducks* >>> >>> >>> On Wed, Apr 8, 2009 at 11:35 AM, Torm3nt wrote: Cheers for your input Dr Nic, I wasn't actually specifically targeting rails - rails 3.0 certainly looks to be much more enticing as far as frameworks goes as you'll be able to plug and play various libraries together, but not many frameworks do this =P Kirk On Wed, Apr 8, 2009 at 11:24 AM, Dr Nic Williams wrote: > People talk about "rails doesn't scale" and mean performance. What I love > about Rails is that scales for the size of the project. You can start a > micro project today, and it easily evolves into a bigger project. > The single-file-contains-my-app frameworks aren't wrong or broken; rather > they take away one of the oft-forgotten but awesome aspects of Rails: you > and I both know where our next model or controller is going to go. The > generators know it. The IDEs/editors know it. > The heavy-weightedness of Rails will probably become optional as we move > to > 3.0 and beyond. > > On Wed, Apr 8, 2009 at 11:19 AM, Torm3nt wrote: >> >> Hey all! >> >> I've recently been musing over the use of heavy frameworks (such as >> RoR) and how I'm beginning to see (in some cases) them being overused, >> mostly for the wrong purposes. In one instance I witnessed a Rails >> application for getting reports on a database. >> >> I've written my thoughts on this and would love to hear from some of >> the more intelligent people in this community, either of their own >> experiences or even a counter-argument =) >> >> http://www.kirkbushell.com/articles/using-the-right-tool-for-the-job >> >> >> Cheers, >> >> Kirk Bushell >> >> > > > > -- > Dr Nic Williams > Mocra - Premier iPhone and Ruby on Rails Consultants > w - http://mocra.com > twitter - @drnic > skype - nicwilliams > e - dr...@mocra.com > p - +61 412 002 126 or +61 7 3102 3237 > > > > > > >>> >>> > >>> >> >> > >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~--~~~~--~~--~--~---
[rails-oceania] Re: Right tool for the job
In the spirit of 'right tools for the job' I would suggest using Wordpress for your blog. It has an awesome CMS and I've found it to be very reliable over the years. Writing a blog engine is a fun weekend project, but I wouldn't run my blog on someones weekend project. - Mike On Wed, Apr 8, 2009 at 11:42 AM, Torm3nt wrote: > > hahaha > > Yeah there seems to be an issue with passenger, with all passenger > processes sitting at around 22% =\ > > Trying to figure out what's going on there, as that's definitely not cool. > hehe > > Have reset the processes and restarted apache numerous times, doesn't > seem to be resolving the issue. > > > Cheers, > > Kirk > > On Wed, Apr 8, 2009 at 11:37 AM, Julio Cesar Ody wrote: >> >> By the way, Kirk, it seems your blog doesn't scale. Requests are >> timing out both from where I am and my VM in the Soviet States of >> America. >> >> Must be Rails. Rewrite it in Scala. >> >> *ducks* >> >> >> On Wed, Apr 8, 2009 at 11:35 AM, Torm3nt wrote: >>> >>> Cheers for your input Dr Nic, >>> >>> I wasn't actually specifically targeting rails - rails 3.0 certainly >>> looks to be much more enticing as far as frameworks goes as you'll be >>> able to plug and play various libraries together, but not many >>> frameworks do this =P >>> >>> >>> Kirk >>> >>> On Wed, Apr 8, 2009 at 11:24 AM, Dr Nic Williams wrote: People talk about "rails doesn't scale" and mean performance. What I love about Rails is that scales for the size of the project. You can start a micro project today, and it easily evolves into a bigger project. The single-file-contains-my-app frameworks aren't wrong or broken; rather they take away one of the oft-forgotten but awesome aspects of Rails: you and I both know where our next model or controller is going to go. The generators know it. The IDEs/editors know it. The heavy-weightedness of Rails will probably become optional as we move to 3.0 and beyond. On Wed, Apr 8, 2009 at 11:19 AM, Torm3nt wrote: > > Hey all! > > I've recently been musing over the use of heavy frameworks (such as > RoR) and how I'm beginning to see (in some cases) them being overused, > mostly for the wrong purposes. In one instance I witnessed a Rails > application for getting reports on a database. > > I've written my thoughts on this and would love to hear from some of > the more intelligent people in this community, either of their own > experiences or even a counter-argument =) > > http://www.kirkbushell.com/articles/using-the-right-tool-for-the-job > > > Cheers, > > Kirk Bushell > > -- Dr Nic Williams Mocra - Premier iPhone and Ruby on Rails Consultants w - http://mocra.com twitter - @drnic skype - nicwilliams e - dr...@mocra.com p - +61 412 002 126 or +61 7 3102 3237 > >>> >>> > >>> >> >> > >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~--~~~~--~~--~--~---
[rails-oceania] Re: Right tool for the job
hahaha Yeah there seems to be an issue with passenger, with all passenger processes sitting at around 22% =\ Trying to figure out what's going on there, as that's definitely not cool. hehe Have reset the processes and restarted apache numerous times, doesn't seem to be resolving the issue. Cheers, Kirk On Wed, Apr 8, 2009 at 11:37 AM, Julio Cesar Ody wrote: > > By the way, Kirk, it seems your blog doesn't scale. Requests are > timing out both from where I am and my VM in the Soviet States of > America. > > Must be Rails. Rewrite it in Scala. > > *ducks* > > > On Wed, Apr 8, 2009 at 11:35 AM, Torm3nt wrote: >> >> Cheers for your input Dr Nic, >> >> I wasn't actually specifically targeting rails - rails 3.0 certainly >> looks to be much more enticing as far as frameworks goes as you'll be >> able to plug and play various libraries together, but not many >> frameworks do this =P >> >> >> Kirk >> >> On Wed, Apr 8, 2009 at 11:24 AM, Dr Nic Williams wrote: >>> People talk about "rails doesn't scale" and mean performance. What I love >>> about Rails is that scales for the size of the project. You can start a >>> micro project today, and it easily evolves into a bigger project. >>> The single-file-contains-my-app frameworks aren't wrong or broken; rather >>> they take away one of the oft-forgotten but awesome aspects of Rails: you >>> and I both know where our next model or controller is going to go. The >>> generators know it. The IDEs/editors know it. >>> The heavy-weightedness of Rails will probably become optional as we move to >>> 3.0 and beyond. >>> >>> On Wed, Apr 8, 2009 at 11:19 AM, Torm3nt wrote: Hey all! I've recently been musing over the use of heavy frameworks (such as RoR) and how I'm beginning to see (in some cases) them being overused, mostly for the wrong purposes. In one instance I witnessed a Rails application for getting reports on a database. I've written my thoughts on this and would love to hear from some of the more intelligent people in this community, either of their own experiences or even a counter-argument =) http://www.kirkbushell.com/articles/using-the-right-tool-for-the-job Cheers, Kirk Bushell >>> >>> >>> >>> -- >>> Dr Nic Williams >>> Mocra - Premier iPhone and Ruby on Rails Consultants >>> w - http://mocra.com >>> twitter - @drnic >>> skype - nicwilliams >>> e - dr...@mocra.com >>> p - +61 412 002 126 or +61 7 3102 3237 >>> >>> >>> > >>> >> >> > >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~--~~~~--~~--~--~---
[rails-oceania] Re: Right tool for the job
By the way, Kirk, it seems your blog doesn't scale. Requests are timing out both from where I am and my VM in the Soviet States of America. Must be Rails. Rewrite it in Scala. *ducks* On Wed, Apr 8, 2009 at 11:35 AM, Torm3nt wrote: > > Cheers for your input Dr Nic, > > I wasn't actually specifically targeting rails - rails 3.0 certainly > looks to be much more enticing as far as frameworks goes as you'll be > able to plug and play various libraries together, but not many > frameworks do this =P > > > Kirk > > On Wed, Apr 8, 2009 at 11:24 AM, Dr Nic Williams wrote: >> People talk about "rails doesn't scale" and mean performance. What I love >> about Rails is that scales for the size of the project. You can start a >> micro project today, and it easily evolves into a bigger project. >> The single-file-contains-my-app frameworks aren't wrong or broken; rather >> they take away one of the oft-forgotten but awesome aspects of Rails: you >> and I both know where our next model or controller is going to go. The >> generators know it. The IDEs/editors know it. >> The heavy-weightedness of Rails will probably become optional as we move to >> 3.0 and beyond. >> >> On Wed, Apr 8, 2009 at 11:19 AM, Torm3nt wrote: >>> >>> Hey all! >>> >>> I've recently been musing over the use of heavy frameworks (such as >>> RoR) and how I'm beginning to see (in some cases) them being overused, >>> mostly for the wrong purposes. In one instance I witnessed a Rails >>> application for getting reports on a database. >>> >>> I've written my thoughts on this and would love to hear from some of >>> the more intelligent people in this community, either of their own >>> experiences or even a counter-argument =) >>> >>> http://www.kirkbushell.com/articles/using-the-right-tool-for-the-job >>> >>> >>> Cheers, >>> >>> Kirk Bushell >>> >>> >> >> >> >> -- >> Dr Nic Williams >> Mocra - Premier iPhone and Ruby on Rails Consultants >> w - http://mocra.com >> twitter - @drnic >> skype - nicwilliams >> e - dr...@mocra.com >> p - +61 412 002 126 or +61 7 3102 3237 >> >> >> > >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~--~~~~--~~--~--~---
[rails-oceania] Re: Right tool for the job
Cheers for your input Dr Nic, I wasn't actually specifically targeting rails - rails 3.0 certainly looks to be much more enticing as far as frameworks goes as you'll be able to plug and play various libraries together, but not many frameworks do this =P Kirk On Wed, Apr 8, 2009 at 11:24 AM, Dr Nic Williams wrote: > People talk about "rails doesn't scale" and mean performance. What I love > about Rails is that scales for the size of the project. You can start a > micro project today, and it easily evolves into a bigger project. > The single-file-contains-my-app frameworks aren't wrong or broken; rather > they take away one of the oft-forgotten but awesome aspects of Rails: you > and I both know where our next model or controller is going to go. The > generators know it. The IDEs/editors know it. > The heavy-weightedness of Rails will probably become optional as we move to > 3.0 and beyond. > > On Wed, Apr 8, 2009 at 11:19 AM, Torm3nt wrote: >> >> Hey all! >> >> I've recently been musing over the use of heavy frameworks (such as >> RoR) and how I'm beginning to see (in some cases) them being overused, >> mostly for the wrong purposes. In one instance I witnessed a Rails >> application for getting reports on a database. >> >> I've written my thoughts on this and would love to hear from some of >> the more intelligent people in this community, either of their own >> experiences or even a counter-argument =) >> >> http://www.kirkbushell.com/articles/using-the-right-tool-for-the-job >> >> >> Cheers, >> >> Kirk Bushell >> >> > > > > -- > Dr Nic Williams > Mocra - Premier iPhone and Ruby on Rails Consultants > w - http://mocra.com > twitter - @drnic > skype - nicwilliams > e - dr...@mocra.com > p - +61 412 002 126 or +61 7 3102 3237 > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~--~~~~--~~--~--~---
[rails-oceania] Re: Right tool for the job
People talk about "rails doesn't scale" and mean performance. What I love about Rails is that scales for the size of the project. You can start a micro project today, and it easily evolves into a bigger project. The single-file-contains-my-app frameworks aren't wrong or broken; rather they take away one of the oft-forgotten but awesome aspects of Rails: you and I both know where our next model or controller is going to go. The generators know it. The IDEs/editors know it. The heavy-weightedness of Rails will probably become optional as we move to 3.0 and beyond. On Wed, Apr 8, 2009 at 11:19 AM, Torm3nt wrote: > > Hey all! > > I've recently been musing over the use of heavy frameworks (such as > RoR) and how I'm beginning to see (in some cases) them being overused, > mostly for the wrong purposes. In one instance I witnessed a Rails > application for getting reports on a database. > > I've written my thoughts on this and would love to hear from some of > the more intelligent people in this community, either of their own > experiences or even a counter-argument =) > > http://www.kirkbushell.com/articles/using-the-right-tool-for-the-job > > > Cheers, > > Kirk Bushell > > > > -- Dr Nic Williams Mocra - Premier iPhone and Ruby on Rails Consultants w - http://mocra.com twitter - @drnic skype - nicwilliams e - dr...@mocra.com p - +61 412 002 126 or +61 7 3102 3237 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~--~~~~--~~--~--~---
