Can someone point me to some good ideas about managing Rails development - like what would be a good way to document all the models and controllers and methods that might result if several people are prototyping on different parts of a system, and what might be a good structure for pushing back code into SVN as scaffolds are turned into real projects - that sort of thing. I''m just starting to learn the nuts and bolts of how the environment works, so I haven''t quite gotten my brain around what the process would be like for building a system that''s bigger than what would fit in one person''s head while they''re railing away. Maybe that''s so specific that there isn''t much useful universal advice, but just a blog about someone''s specific experiences would be helpful. e.g. would you try to document or diagram models, controllers, and methods as they''re built, or is there a good way to reverse-engineer that out of the system periodically? Thanks, Steve
Hi Steve, A lot of people interested in running rails projects are also into agile development methodologies. The best known rails book, for example is "Agile Development with Ruby on Rails", which although it doesn''t talk about agile project management practices, does tend to espouse the view that rails development is fast enough that many of the traditional bells and whistles of "big up front design" style project management (with much diagramming and so forth) are not necessary. 37signals has a little book out called "Getting Real", which talks about there experiences, and also pushes a very agile line. Their book is from an entrepreneurial or business management point of view, and may be of interest to you if you are managing a rails project. Also, I think that most people could do a lot worse than reading up on Extreme Programming, which is one of the most widely known agile methodologies available. The bible for that is probably Kent Beck''s "Extreme Programming Explained (2nd Edition)". My experience developing rails apps is certainly along these lines. Don''t follow conventional wisdom from the 80''s and 90''s that says you need strict documentation for your development. Instead, just follow a constant cycle of iteratively making things better. To respond specifically to your comments; Subversion Yes, use SVN all the time. Right from the start. Yes, check those scaffolds into subversion. When should you commit to SVN? Constantly! I do so ever time I add a new feature, about every 20 minutes. Documenting models, controllers and methods Don''t do it! Why bother? Ruby code is clean and readable, if your code isn''t readable, don''t spend time documenting it, spend time cleaning it up so that it''s readable again. If you really want documentation that you can rely on, consider writing tests instead. They explain in no uncertain terms what the system does, and they will never get out of sync with the code (because you''ll run them constantly). Disclaimer: Documentation is still needed if you are releasing a web framework, rather than a web application. Fitting your system into several people''s heads This will work fine. Yes, I know it didn''t always work fine with big messy PHP or Perl apps. However, rails organises things into a tidy stack, and neat vertical slices. Anyone who knows how rails works can dive in and understand, providing the code is clean. I''ve tried multiple developers in a rails app, and it works fine. Have a look at the "no code ownership" ideas and practices which are part of the extreme programming methodology for more ideas about how this can be done well. hope that helps, Craig Steven Rogers wrote:> > Can someone point me to some good ideas about managing Rails > development - like what would be a good way to document all the models > and controllers and methods that might result if several people are > prototyping on different parts of a system, and what might be a good > structure for pushing back code into SVN as scaffolds are turned into > real projects - that sort of thing. I''m just starting to learn the > nuts and bolts of how the environment works, so I haven''t quite gotten > my brain around what the process would be like for building a system > that''s bigger than what would fit in one person''s head while they''re > railing away. Maybe that''s so specific that there isn''t much useful > universal advice, but just a blog about someone''s specific experiences > would be helpful. e.g. would you try to document or diagram models, > controllers, and methods as they''re built, or is there a good way to > reverse-engineer that out of the system periodically? > > Thanks, > Steve > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
Hi Steve, In addition to Craig''s suggestions, you might also want to consider joining the Agile Project Management group at http://finance.groups.yahoo.com/group/agileprojectmanagement/ Good group of folks. Best regards, Bill ----- Original Message ----- From: "Steven Rogers" <srogers1@austin.rr.com> To: <rails@lists.rubyonrails.org> Sent: 2006-04-05 12:39 AM Subject: [Rails] Managing a Rails project> > Can someone point me to some good ideas about managing Rails > development - like what would be a good way to document all the > models and controllers and methods that might result if several > people are prototyping on different parts of a system, and what might > be a good structure for pushing back code into SVN as scaffolds are > turned into real projects - that sort of thing. I''m just starting to > learn the nuts and bolts of how the environment works, so I haven''t > quite gotten my brain around what the process would be like for > building a system that''s bigger than what would fit in one person''s > head while they''re railing away. Maybe that''s so specific that there > isn''t much useful universal advice, but just a blog about someone''s > specific experiences would be helpful. e.g. would you try to document > or diagram models, controllers, and methods as they''re built, or is > there a good way to reverse-engineer that out of the system > periodically? > > Thanks, > Steve > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
I think that UML collaboration diagramms (or something close to them) are great as modeling tools for developing web applications with RoR. I''m trying them now in a project, and will let you know the results. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Hi Federico, I''ll be interested in your report. It would be neat to be able to use UML as a front end for a kind of "super scaffolding" generator. Starr --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Hi Again :) Well... the project is almost done. We didn''t use Rails, because I didn''t have Rails programmers (instead, we had to use PHP+Smarty), but we used sequence diagramms that imitates Rails MVC model. The result was awesome: once that the diagramms were ready, the programmers understood the application completely. Before starting the implementation phase, one programmer told me: "wow I can see the whole application, I know exactly what I have to do". I made a plan of 5 releases, and they were executed without any problems. Tomorrow the 5th release will be done, 3 weeks before the death line. Now I''m starting a new project, and I will use this technique again in the design phase, but adding TDD for the implementation phase, and Rails. If this project goes as well as the first one, I would like to develop a graphical IDE for Rails... I think it would rock. Anyone interested in such a tool, please leave the message. I think I would start working on this in January. Cheers, Federico F. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Federico F. wrote:> Now I''m starting a new project, and I will use this technique again in > the design phase, but adding TDD for the implementation phase, and > Rails. If this project goes as well as the first one, I would like to > develop a graphical IDE for Rails... I think it would rock.Google "Waterfall". Your PHP project went well because Waterfall is indeed a step up from Code-and-Fix. However, if your project was larger, then a "design phase" would conflate any mistakes in design. Your "implementation phase" would suffer. Use TDD essentially the same way Rails has used it on itself. Design a little, code a little, deliver a little, and repeat in small cycles. Write tests for everything, to make frequent releases safe. I met with a team using Rails the other day, and unless I misunderstood them, they seem to be releasing each integration. They seem to have no "staging server", where most commercial web applications deploy their source into a simulated production environment, for smoke-tests before the main deployment. Unless I misunderstood them, they could apparently change their code on their own desktop, pass their tests, hit a button, and deploy this new feature directly to their live server. That is "agility". -- Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Philip, Yes, I didn''t use an "Agile" approach for this project, because even though I like some ideas from XP and Scrum, I also like some from CMMi. So , I''m currently working on a process that mixes what I think is the best of both worlds. I do belive that you need to design what you are going to code, before coding it, and it may be a good practice to do TDD after you have these design documents. I also think that you need much more less design documents than those available in RUP. But, of course, I also don''t think that there is THE best way to develop software. I think it depends on the people you have in your team. Cheers, Federico --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Federico F. wrote:> Yes, I didn''t use an "Agile" approach for this project, because even > though I like some ideas from XP and Scrum, I also like some from CMMi. > So , I''m currently working on a process that mixes what I think is the > best of both worlds. > > I do belive that you need to design what you are going to code, before > coding it, and it may be a good practice to do TDD after you have these > design documents. I also think that you need much more less design > documents than those available in RUP.RUP is an "agile" process too, and it does _not_ specify that you create lots of design documents before coding.> But, of course, I also don''t think that there is THE best way to > develop software. I think it depends on the people you have in your > team.There are, however, worst ways. One of the biggest impediments to adopting TDD is the amount of effort you must spend learning to retrofit tests into existing frameworks. (This, in turn, is a good way to vet the quality of those frameworks. Attrocities like ASP.NET should be shunned _specifically_ because they are hard to test.) Rails, however, provides a testing framework matching most of its features. So all you need to do is just start extending the tests, in parallel to how you extend the application. So the ultimate goal of TDD, Emergent Design, is within reach of anyone as soon as they generate their first Rails application. -- Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Ok, googling a bit I found that RUP can be used for agile development... some artifacts, some rules... but it is not an agile process from its beggining. Anyway, perhaps you have a broader definition of "Agile" in your head, than I have in mine. It''s not the point. The real point is CMM/CMMi and it''s relation with Agile methodologies. If you like CMM it is hard to accept pure XP, Scrum... So my intention is to find a way to adopt an Agile process that fits CMM aswell. Googling a bit again... I found a paper of some person talking about "stretching" Agile to make it CMM level 3 compliant. I will read it as I read more about agile and TDD. Specifically, my doubt now is if you can design your software with at least one or two UML diagramms before doing TDD. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Federico, Federico Fernandez wrote:> So my intention is to find a way to adopt > an Agile process that fits CMM aswell.You might want to check out www.niwotridge.com. Glen Alleman is one of the most experienced folks around wrt utilizing agile development methods within a CMMI-compliant overall PM infrastructure. hth, Bill --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Federico Fernandez wrote:> The real point is CMM/CMMi and it''s relation with Agile methodologies. > If you like CMM it is hard to accept pure XP, Scrum... So my intention > is to find a way to adopt an Agile process that fits CMM aswell.XP satisfies all the CMM KPAs for one team. All the "manage your process" stuff. This requires you to actually _do_ XP (just as CMM actually requires you to do it, not just speak it!). A CMM certifier should rate an XP team at Level 3 and part of 4, at least. The remaining KPAs are the inter-team stuff, which XP naturally does not cover. For example, pure XP requires an Onsite Customer (a "business analyst" role) to author acceptance tests. These tests are analysis, and documentation, and requirements gathering, and - uh - tests. All in one. So the KPAs that require those things are satisfied. Projects without acceptance tests are not XP, so they also should fail CMM certifiation.> Googling a bit again... I found a paper of some person talking about > "stretching" Agile to make it CMM level 3 compliant. I will read it as I > read more about agile and TDD. Specifically, my doubt now is if you can > design your software with at least one or two UML diagramms before doing > TDD.CMM does _not_ require you to draw diagrams before you write code. XP does _not_ forbid them, either. People practicing XP learn that they need such diagrams less often. This, in turn, increases the value and meaning of such diagrams when they are used. So people practicing XP often write about their experiences, leading to a myth that things like UML and debuggers are forbidden. A company at CMM Level 5 should lose their certification if they don''t try XP in a pilot project, per the KPA "experiment with new processes and learn from them". -- Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---