Wayne Molina
2009-May-17 11:45 UTC
Overwhelmed with choices concerning Rails "best practices"
As someone who has repeatedly tried to sit down and really pick up Ruby on Rails, the one deterrent I continually find is that the best way of doing things seem to change on a daily basis, and half the time nobody can agree with it. Since my programming background is largely self-taught and without any formal CS education, I like to make a list of the "right" way to develop applications in a particular language/ framework so I know that I''m going to be starting off on the right foot; this is in direct opposition to something like picking up a book on PHP, say, and cranking out junk sites and learning bad practices. In effect my problem is that whenever I sit down to really learn Rails (and I have almost a dozen books on it I''ve gathered over the past year, although a lot are from the prior edition - I have: AWDWR 3rd Edition, Programming Ruby 2nd edition, The Ruby Way, The Rails Way, O''Reilly''s Learning Rails, Ajax on Rails, Enterprise Rails, Apress Social Networking Sites with Rails, and RailsSpace) the community seems to have charged forward and changed its best practices, so it''s just added a whole bunch of things I need to learn as well. For instance, the new thing seems to be BDD and RSpec, so I have to learn RSpec in addition to Rails and Ruby. Git is used for version control, so that''s something else. RJS is out and unobtrusive stuff is in, so that means jQuery. Hosting is now typically done with Phusion Passenger, so I have to learn Apache and that. Finally with the Rails+Merb merger things are going to get shaken up even more so. I really want to learn Rails but the community seems to just keep jumping from one bandwagon to another without staying put long enough for somebody who didn''t come aboard in 2005-2006 to ever get to speed. Like I said I like to follow best practices because I come from .NET and I''ve seen what just slapping together code can do, and it''s not pretty, so I feel like if I''m going to learn Rails, I need to learn it right from the start, not learn the "obsolete" way of writing it and then upgrade. Can somebody knock some sense into me in this regard? I''ve been trying to learn Rails for over a year now and this is the main reason why I can never get more than basic tutorial-style stuff going on.
Rimantas Liubertas
2009-May-17 12:15 UTC
Re: Overwhelmed with choices concerning Rails "best practices"
<…>> the community > seems to have charged forward and changed its best practices, so it''s > just added a whole bunch of things I need to learn as well.Welcome to the web development :) You list a bunch of technologies which have some alternative tools for the work to be done. Learn the principles common to those tools and you won''t be scared anymore.> For instance, the new thing seems to be BDD and RSpec, so I have to > learn RSpec in addition to Rails and Ruby.Actually this is the only thing more or less directly related to RoR.> Git is used for version > control, so that''s something else.It is about time to move on from Subversion to some DCVS. Git is very good choice, but maybe with the steeper learning curve than others. I have no doubt that in some point of your developer''s live you will meet bazaar, mercurial too.> RJS is out and unobtrusive stuff > is in, so that means jQuery.jQuery is just one of the available Javascript frameworks for DOM manipulation and AJAXing. Once you know a bit about that be it Prototype, jQuery, YUI, mootools, dojokit, etc. won''t scare you.> Hosting is now typically done with > Phusion Passenger, so I have to learn Apache and that.That''s another layer, but learning a bit of apache won''t hurt for sure.> Finally with > the Rails+Merb merger things are going to get shaken up even more so. > I really want to learn Rails but the community seems to just keep > jumping from one bandwagon to another without staying put long enough > for somebody who didn''t come aboard in 2005-2006 to ever get to > speed. Like I said I like to follow best practices because I come > from .NET and I''ve seen what just slapping together code can do, and > it''s not pretty, so I feel like if I''m going to learn Rails, I need to > learn it right from the start, not learn the "obsolete" way of writing > it and then upgrade.Rails if only part of the whole picture. Learn the parts what make that picture, learn common principles behind those parts and you may begin to see the light. Yes, there is a lot to learn—server side, client side, developer''s tools, deployment''s tools, etc. but it is fun too! Regards, Rimantas -- http://rimantas.com/
Michael Schuerig
2009-May-17 14:36 UTC
Re: Overwhelmed with choices concerning Rails "best practices"
On Sunday 17 May 2009, Wayne Molina wrote:> As someone who has repeatedly tried to sit down and really pick up > Ruby on Rails, the one deterrent I continually find is that the best > way of doing things seem to change on a daily basis, and half the > time nobody can agree with it. Since my programming background is > largely self-taught and without any formal CS education, I like to > make a list of the "right" way to develop applications in a > particular language/ framework so I know that I''m going to be > starting off on the right foot; this is in direct opposition to > something like picking up a book on PHP, say, and cranking out junk > sites and learning bad practices.[...]> Can somebody knock some sense into me in this regard? I''ve been > trying to learn Rails for over a year now and this is the main reason > why I can never get more than basic tutorial-style stuff going on.You''re serious about learning to develop software and expect to do it some time? Then it is really worthwhile to learn the fundamentals instead of the technology of the day. As you''ve discovered, the later tends to change quickly, if not literally daily. Here are just three suggestions Matthias Felleisen et al. How to Design Programs: An Introduction to Programming and Computing MIT Press 2001 http://www.htdp.org Robert C. Martin Agile Software Development, Principles, Patterns, and Practices Prentice-Hall 2002 http://www.objectmentor.com/resources/books.html Graeme Simsion; Graham Witt Data Modeling Essentials Morgan Kaufman 2004 Michael -- Michael Schuerig mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org http://www.schuerig.de/michael/
Phlip
2009-May-17 14:36 UTC
Re: Overwhelmed with choices concerning Rails "best practices"
Wayne Molina wrote:> ...the community > seems to have charged forward and changed its best practices, so it''s > just added a whole bunch of things I need to learn as well.The more things change, the more they stay the same.> For instance, the new thing seems to be BDD and RSpec, so I have to > learn RSpec in addition to Rails and Ruby.What''s 10-years-old about that is "test-first". Write a test that fails before writing _any_ line of code. Don''t just use those things as toys, and don''t just write tests on the sitting duck targets that are easy to test. If a given feature requires 20 minutes of coding, but requires 2 hours of writing the test first, write the test first anyway. This is how a project sustains itself at scaling time. Further tests will _not_ require those 2 hours again! Also, while RSpec is in a growth phase, I suspect most Rails tests are in Test::Unit. Learn it. > Git is used for version> control, so that''s something else.Ideally, put either git or svn into your lib/tasks/project.rake, and then run short rake commands. > RJS is out and unobtrusive stuff> is in, so that means jQuery.Hardly; JavaScript is still JavaScript. The good news there is the libraries are more pluggable, and as Rails converges with Merb they will only get more-so. > Hosting is now typically done with> Phusion Passenger, so I have to learn Apache and that.The story there is, for whatever reason, Ruby for the longest time had no module that plugged into the great A-Patchy server. When it arrived, the committee renamed it to Passenger.> Finally with > the Rails+Merb merger things are going to get shaken up even more so.Merb has a better core.> I really want to learn Rails but the community seems to just keep > jumping from one bandwagon to another without staying put long enough > for somebody who didn''t come aboard in 2005-2006 to ever get to > speed.Doing Rails requires good skills with El Goog, including codesearch, including remembering to always check the date on some blog entry offering some critical tidbit of information. Any Rails book, plus that skill, will keep you in the loop. And the other good news is as Rails matures, gains converts, and becomes stable, the committee won''t be able to make all these changes so often. That is the intent of the Rails-Merb merger. > Like I said I like to follow best practices because I come> from .NET and I''ve seen what just slapping together code can do, and > it''s not pretty, so I feel like if I''m going to learn Rails, I need to > learn it right from the start, not learn the "obsolete" way of writing > it and then upgrade.Why does .NET impede "just slapping code together"? BTW that is _not_ what we do here - refer back to the "test-first" verbiage above! Oh, I remember! .NET is closed source over all of its stack, meaning it''s software that attempts to control its programmers, and keep them locked in to one vendor. We don''t do that. Anyone who invents a better Rails wins, so the competition keeps us honest, even as we invent conflicting libraries and systems.> Can somebody knock some sense into me in this regard? I''ve been > trying to learn Rails for over a year now and this is the main reason > why I can never get more than basic tutorial-style stuff going on.Do you have a client with feature requests? That helps. Also, you might then notice that most of our code _is_ tutorial level. That is the point of Lean and Agile development with such a light framework... -- Phlip http://flea.sourceforge.net/resume.html
Marnen Laibow-Koser
2009-May-17 15:11 UTC
Re: Overwhelmed with choices concerning Rails "best practices"
Phlip wrote:> Wayne Molina wrote: > >> ...the community >> seems to have charged forward and changed its best practices, so it''s >> just added a whole bunch of things I need to learn as well. > > The more things change, the more they stay the same.As usual, Phlip has some excellent advice here. I thought I''d just amplify a few points.> >> For instance, the new thing seems to be BDD and RSpec, so I have to >> learn RSpec in addition to Rails and Ruby. > > What''s 10-years-old about that is "test-first". Write a test that fails > before > writing _any_ line of code.Yup. And that''s not a Rails-specific thing either. [...]> Also, while RSpec is in a growth phase, I suspect most Rails tests are > in > Test::Unit.I suspect you''re wrong. I know that you don''t like RSpec (for reasons I cannot fathom), but it seems to me that most Rails code I look at these days uses it.> Learn it.Er...why, other than for completeness'' sake? Last time I looked at Test::Unit, it just seemed so *clunky* compared to RSpec, although your assert2 module seems to help.> > > Git is used for version >> control, so that''s something else. > > Ideally, put either git or svn into your lib/tasks/project.rake, and > then run > short rake commands.Maybe. I liked that approach with Rubinius, when I was a newbie to Git, but these days, I think I use Git in so many different ways that writing Rake tasks wouldn''t really reduce any complexity. I *can* think of one or two exceptions, though. YMMV.> > > RJS is out and unobtrusive stuff >> is in, so that means jQuery. > > Hardly; JavaScript is still JavaScript.Indeed. You can be unobtrusive with any JS library, or with none. jQuery is hardly implied by unobtrusive JS.> > The good news there is the libraries are more pluggable, and as Rails > converges > with Merb they will only get more-so.I have a suspicion that Rails will jump the shark when it merges with Merb, but I would be extremely happy to be wrong about that.> > > Hosting is now typically done with >> Phusion Passenger, so I have to learn Apache and that. > > The story there is, for whatever reason, Ruby for the longest time had > no module > that plugged into the great A-Patchy server.Actually, mod_ruby has been around for a long time, but its single-threaded nature made it unsuitable for Rails.> When it arrived, the > committee > renamed it to Passenger.I don''t think that name came from the Apache committee...did they even have anything to do with Passenger?> >> Finally with >> the Rails+Merb merger things are going to get shaken up even more so. > > Merb has a better core.Good to know.> >> I really want to learn Rails but the community seems to just keep >> jumping from one bandwagon to anotherYes, parts of the Rails community are very faddish. It''s up to you to decide which fads are worthwhile. :)> without staying put long enough >> for somebody who didn''t come aboard in 2005-2006 to ever get to >> speed. > > Doing Rails requires good skills with El Goog, including codesearch, > including > remembering to always check the date on some blog entry offering some > critical > tidbit of information.Yup. Rails core development moves quite fast.> > Any Rails book, plus that skill, will keep you in the loop.Seems to me that Rails books are generally out of date as soon as they''re printed.> > And the other good news is as Rails matures, gains converts, and becomes > stable, > the committee won''t be able to make all these changes so often. That is > the > intent of the Rails-Merb merger.Do you really think that DHH will be able to resist the lure of further opportunities for intellectual masturbation by tinkering with the Rails core? I sure don''t. [...]> Anyone who invents a better Rails wins, so the > competition > keeps us honest, even as we invent conflicting libraries and systems.We''ll see. 3.0 may be a better Rails, or it may not.> > -- > Phlip > http://flea.sourceforge.net/resume.htmlBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
Jeffrey L. Taylor
2009-May-17 17:27 UTC
Re: Overwhelmed with choices concerning Rails "best practices"
Quoting Wayne Molina <wayne.molina-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: [snip] As someone who has been programming for over 35 years, my advice is learn how to learn. Actually, learn how YOU learn. Because you are going to need it. Programming is like science. Good observation finds things that aren''t like it "should" be. So a hypothesis is proposed, tested, debated, and if there is no conflicting data, slowly transformed into "law", received truth. There are many hypotheses about how it should be, what might improve things. Some will show their value, others won''t. Some will be useful for years, some for only a short bit of space and time. Practices that make sense for large stable problem spaces may not make any sense in small problems in rapidly changing areas. And many "best practices" are overkill and oversold. The core idea is good, but it has hardened into dogma, accumulated too much overhead and isn''t worth the amount of time required. It is a very good idea to spend some time up front thinking about the design, both user interaction and implementation strategies. Few projects will see a decent Return On Investment (ROI) of a 50 pound design document. My suggestion is to learn incrementally. You can do most of your development with Webrick or Mongrel. Learn Apache and Phusion Passenger when you are ready to deploy the production system. Automated testing is extremely helpful. TDD, BDD, or whatever. There are good reasons for testing as early as possible, but start with just the low hanging fruit. If you aren''t sure what the system is supposed to do, don''t invest a lot of time testing for what is likely to change. Expectations change, socially acceptable costs change, technology costs change. For example, I remember when if you wanted seatbelts in your car, you went to a small airport to buy them and installed them yourself. These were the 2 point, metal to fabric, lap belts. Same as on commerical aircraft of the day. Then came metal to metal lap belts available as an option. Nowdays, three point, lap and shoulder belts are standard and most jurisdictions in the US legally require that you use them. Airbags are following the same route. However, 5 point belts are required in racing cars. Safer than 3 point belts, but the hassle/cost is considered too high for the benefits. I like Alistair Cockburn''s work on programming process. One he focuses on what has a track record of working in practice, not on what "should" work according to some guru sitting in an ivory tower somewhere far from the front lines of actual programming (not all ivory towers are in academia). Also he makes a point of differing levels of process depending on how many people and how critical the system is. The level of rigor, paperwork, documentation, etc. appropriate for a 2 person project making an entertaining widget is different from a 50 person project making a life-critical application (e.g. X-ray machines, heart-lung pumps). Advice from a human potential trainer many years ago I still find helpful. If you decide today to be a vegetarian, do not expect to be 100% vegetarian tomorrow. You don''t have the recipes, the ingredients in your kitchen, the nutritional information, or habits necessary. Start with one or two improvements, when they are second nature, and another. And know that better is a moving target, not a destination. HTH, Jeffrey
Sazima
2009-May-18 15:00 UTC
Re: Overwhelmed with choices concerning Rails "best practices"
Hi Wayne, I think you''re too anxious. Software development best practices are not so specific to RoR, you can follow well established patterns independent of the language/platform of choice. Regarding new technologies and Rails-specific techniques, I just tend to ignore them if they are not particularly useful/necessary to the project at any given moment. Cheers, Sazima On May 17, 8:45 am, Wayne Molina <wayne.mol...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> As someone who has repeatedly tried to sit down and really pick up > Ruby on Rails, the one deterrent I continually find is that the best > way of doing things seem to change on a daily basis, and half the time > nobody can agree with it. Since my programming background is largely > self-taught and without any formal CS education, I like to make a list > of the "right" way to develop applications in a particular language/ > framework so I know that I''m going to be starting off on the right > foot; this is in direct opposition to something like picking up a book > on PHP, say, and cranking out junk sites and learning bad practices. > > In effect my problem is that whenever I sit down to really learn Rails > (and I have almost a dozen books on it I''ve gathered over the past > year, although a lot are from the prior edition - I have: AWDWR 3rd > Edition, Programming Ruby 2nd edition, The Ruby Way, The Rails Way, > O''Reilly''s Learning Rails, Ajax on Rails, Enterprise Rails, Apress > Social Networking Sites with Rails, and RailsSpace) the community > seems to have charged forward and changed its best practices, so it''s > just added a whole bunch of things I need to learn as well. > > For instance, the new thing seems to be BDD and RSpec, so I have to > learn RSpec in addition to Rails and Ruby. Git is used for version > control, so that''s something else. RJS is out and unobtrusive stuff > is in, so that means jQuery. Hosting is now typically done with > Phusion Passenger, so I have to learn Apache and that. Finally with > the Rails+Merb merger things are going to get shaken up even more so. > I really want to learn Rails but the community seems to just keep > jumping from one bandwagon to another without staying put long enough > for somebody who didn''t come aboard in 2005-2006 to ever get to > speed. Like I said I like to follow best practices because I come > from .NET and I''ve seen what just slapping together code can do, and > it''s not pretty, so I feel like if I''m going to learn Rails, I need to > learn it right from the start, not learn the "obsolete" way of writing > it and then upgrade. > > Can somebody knock some sense into me in this regard? I''ve been > trying to learn Rails for over a year now and this is the main reason > why I can never get more than basic tutorial-style stuff going on.
Pardee, Roy
2009-May-20 15:12 UTC
Re: Overwhelmed with choices concerning Rails "best practices"
Sazima''s exactly right. When you''re getting your "sea legs", ignore what the cool kids are doing and just learn the basics of the platform. Get yourself a book, install the version of rails it covers, dig in & write an application or two. Once you''ve got some experience under your belt you''ll know what seems like unnecessary pain to you, and can start to explore the different tweaks and add-ons. That''s my plan anyway. ;-) -----Original Message----- From: rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org [mailto:rubyonrails-talk@googlegroups.com] On Behalf Of Sazima Sent: Monday, May 18, 2009 8:01 AM To: Ruby on Rails: Talk Subject: [Rails] Re: Overwhelmed with choices concerning Rails "best practices" Hi Wayne, I think you''re too anxious. Software development best practices are not so specific to RoR, you can follow well established patterns independent of the language/platform of choice. Regarding new technologies and Rails-specific techniques, I just tend to ignore them if they are not particularly useful/necessary to the project at any given moment. Cheers, Sazima On May 17, 8:45 am, Wayne Molina <wayne.mol...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> As someone who has repeatedly tried to sit down and really pick up > Ruby on Rails, the one deterrent I continually find is that the best > way of doing things seem to change on a daily basis, and half the time > nobody can agree with it. Since my programming background is largely > self-taught and without any formal CS education, I like to make a list > of the "right" way to develop applications in a particular language/ > framework so I know that I''m going to be starting off on the right > foot; this is in direct opposition to something like picking up a book > on PHP, say, and cranking out junk sites and learning bad practices. > > In effect my problem is that whenever I sit down to really learn Rails > (and I have almost a dozen books on it I''ve gathered over the past > year, although a lot are from the prior edition - I have: AWDWR 3rd > Edition, Programming Ruby 2nd edition, The Ruby Way, The Rails Way, > O''Reilly''s Learning Rails, Ajax on Rails, Enterprise Rails, Apress > Social Networking Sites with Rails, and RailsSpace) the community > seems to have charged forward and changed its best practices, so it''s > just added a whole bunch of things I need to learn as well. > > For instance, the new thing seems to be BDD and RSpec, so I have to > learn RSpec in addition to Rails and Ruby. Git is used for version > control, so that''s something else. RJS is out and unobtrusive stuff > is in, so that means jQuery. Hosting is now typically done with > Phusion Passenger, so I have to learn Apache and that. Finally with > the Rails+Merb merger things are going to get shaken up even more so. > I really want to learn Rails but the community seems to just keep > jumping from one bandwagon to another without staying put long enough > for somebody who didn''t come aboard in 2005-2006 to ever get to speed. > Like I said I like to follow best practices because I come from .NET > and I''ve seen what just slapping together code can do, and it''s not > pretty, so I feel like if I''m going to learn Rails, I need to learn it > right from the start, not learn the "obsolete" way of writing it and > then upgrade. > > Can somebody knock some sense into me in this regard? I''ve been > trying to learn Rails for over a year now and this is the main reason > why I can never get more than basic tutorial-style stuff going on.GHC Confidentiality Statement This message and any attached files might contain confidential information protected by federal and state law. The information is intended only for the use of the individual(s) or entities originally named as addressees. The improper disclosure of such information may be subject to civil or criminal penalties. If this message reached you in error, please contact the sender and destroy this message. Disclosing, copying, forwarding, or distributing the information by unauthorized individuals or entities is strictly prohibited by law.
Marnen Laibow-Koser
2009-May-20 15:35 UTC
Re: Overwhelmed with choices concerning Rails "best practices"
Roy Pardee wrote:> Sazima''s exactly right. When you''re getting your "sea legs", ignore > what the cool kids are doing and just learn the basics of the platform.Sure. OTOH, don''t take this as license to not learn the usual idioms in the field.> Get yourself a book, install the version of rails it covers, dig in & > write an application or two.I *really* am not sure that Rails books are worth it, since the framework changes so fast. (But there''s always the guides.)> > Once you''ve got some experience under your belt you''ll know what seems > like unnecessary pain to you, and can start to explore the different > tweaks and add-ons.Yes. Rails generally makes it very clear when you shouldn''t be doing something.> > That''s my plan anyway. ;-)Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.