I'm looking for suggestions or people's experiences with training their development teams on RoR. I have a great team of 5 primarily Java/C++ programmers at my startup that have messed around a little with RoR, but need solid training before we start our next enterprise project using Rails. I'm considering the following options: 1. We bring in a person/company to do onsite training for a week. 2. We find a local training class. 3. Self Study (books and online documentation). 4. Small Applications. We come up with some small non mission critical apps to build that we could use at our office. For example, our .com home page or a time tracking application. 5. One of us studies the heck out of Ruby on Rails and maybe even goes to a class, then comes back and teaches the rest of us. The 'ol train the trainer. Any advice is way appreciated. Thanks! Keith
on 2007-03-30 22:55
on 2007-03-30 23:00
keith <email@example.com> wrote: > Any advice is way appreciated. Thanks! I like #4 or #5... but I learn by doing. Maybe get one of your more competent senior developers to do #3 and #4 in conjunction for awhile and then start bringing individuals in on #5 as the small applications get bigger? - Tyler
on 2007-03-30 23:42
on 2007-03-30 23:52
I am a (hands-on-coder) manager of a dev team of 6 & we just converted to rails from struts/spring/hibernate (Java). I had my team take a week off of active development and complete the agile development with rails book (2nd ed). Then we started working on a project together where every day, twice a day, someone would take 15 minutes to give a demo or explain something new they learned about ruby or rails to the group. It worked. 3 months later we are 100% ruby/rails and fairly efficient at things.
on 2007-03-31 00:34
I'd say number 4. Coming from java and c++ backgrounds it's important to learn what NOT to do. The easiest way to do that is to make your screw ups in an unimportant project and get rid of your bad habits.
on 2007-03-31 02:24
On Mar 30, 3:54 pm, "keith" <k...@riderway.com> wrote: > critical apps to build that we could use at our office. For example, > our .com home page or a time tracking application. > 5. One of us studies the heck out of Ruby on Rails and maybe even goes > to a class, then comes back and teaches the rest of us. The 'ol train > the trainer. > > Any advice is way appreciated. Thanks! > > Keith Working through the Agile 2nd Ed. book is probably as good a place to start as any. The hard part is getting out of the Java mindset and into the Ruby mindset. Otherwise some of the Rails stuff seems really strange, and can potentially become a real obstacle for people. That's why we've found that one of the most important elements of getting up to speed with Rails is getting a solid introduction to Ruby as well. We've done training for C#/C++ developers, a kind of Ruby 101/Rails 101, and most of the concepts translate easily for Java people as well. If you're in the Chicago area, send me an email if you're interested. (We don't rely on training income, so we're cheap :-) Jeff softiesonrails.com firstname.lastname@example.org
on 2007-03-31 05:29
I really like the Pragmatic Agile Rails book, and it seems like everyone here does too. I went through building the sample app and I thought it was very easy to follow. I think this is the book I would have my team study. Everyone who has posted to this has consistently selected option 3, self study. Very interesting. I think most people agree that 1 week is an acceptable amount of time to let people study the book. I was talking it over some more with my Architect Derrek Long. Derrek and I are thinking about going with option 3 and 4. Then maybe attending a more advanced Rails class later on. I kinda figure that any intro Rails class will focus on the stuff covered in the Prag Agile Rails book, so the intro class won't be terribly useful.
on 2007-03-31 07:00
> 1. We bring in a person/company to do onsite training for a week. > 2. We find a local training class. > 3. Self Study (books and online documentation). > 4. Small Applications. We come up with some small non mission > critical apps to build that we could use at our office. For example, > our .com home page or a time tracking application. > 5. One of us studies the heck out of Ruby on Rails and maybe even > goes > to a class, then comes back and teaches the rest of us. The 'ol train > the trainer. Promiscuous pair programming. There is just no substitute. At work we set up 3 monitors, 3 keyboards, and 2 computers across one super-cheap folding table. Not an elaborate desk and _not_ one of those brainless cubicle corner desks where only one person can sit. Then we have "owned" chairs which we have each customized. We pair program by alternating on the keyboards, without swapping them back and forth. And we use the third computer to run the test trigger system, and so each pair can Google independently. -- Phlip http://flea.sourceforge.net/PiglegToo_1.html
on 2007-03-31 21:30
On Mar 30, 9:59 pm, "Phlip" <phlip2...@gmail.com> wrote: > Promiscuous pair programming. There is just no substitute. This is how our team got up to speed on Rails and I have to agree that it's the best way. Pair up a more experienced RoR developer with someone new to it and have them solve problems. It combines the learn- by-doing, train-the-trainer, self-study, small application development methods, and it is fast. We did run into some problems when good developers, new to Rails but quite proficient in it, were paired up with brand new Rails developers, as it is hard to explain some of the agile/rails concepts when they are pretty new to you. Yeah, I was one of those people who found it difficult to explain:) However - learning to explain the reasons behind the big concepts of agile development and rails results in one having a firmer grasp of them for oneself, so I suppose it all works out well in the end. I also recommend the Agile Web Dev book from PragProg. However, the Depot example is pretty basic, and once your developers have done it I think it would be worth it to check out some of the screencasts from PeepCode (http://www.peepcode.com), especially the ones on Test Driven Development and RESTful Rails. All the best, Jacqui
on 2007-03-31 22:06
jacqui wrote: >> Promiscuous pair programming. There is just no substitute. > > This is how our team got up to speed on Rails and I have to agree that > it's the best way. Pair up a more experienced RoR developer with > someone new to it and have them solve problems. It combines the learn- > by-doing, train-the-trainer, self-study, small application development > methods, and it is fast. Our boss has run out of Rails resumes in our area, so this is why I advised them to get PhP and Tomcat resumes... ;-) -- Phlip http://flea.sourceforge.net/PiglegToo_1.html
on 2007-03-31 23:37
Hey Philip, I like #2, #3, and #5. Why? #3) Initially, I went the self study route because I was very curious about the technology and I wanted to apply it to future development projects. It wasn't structured training. Thus, I found myself all over the place until I started reading the AWDwRv1 and learning by doing. Thus, I like the idea of giving your team a week to cover the AWDwRv2 as well as do the sharing as (dysinger) has stated earlier in this thread. #2 and #5) Then I took the 'Ruby on Rails: Express Train to Web Development" given by Dave Thomas and Mike Clark. Thus, I must say that 24 hours of training by some of the people that helped to write the book was well spent and erected a very solid foundation from which to build. Also, it allowed me to ask questions from my self study, the material in class, and general agile development practices using RoR. Now, it would be very easy for a more senior person in RoR to take acquired knowledge and teach the junior people around them. Lastly, you might want to also consider resume(s) that have Python and Smalltalk because the Ruby language was partly derived from Smalltalk conceptually and it's very similar to both Python and Smalltalk syntactically. BTW, Ruby also was derived from PERL, Lisp, and Ada. Just some additional information to think about. Well, I hope that my comments are helpful and I wish you the best of luck. -Conrad