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:
We bring in a person/company to do onsite training for a week.
We find a local training class.
Self Study (books and online documentation).
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.
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!
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?
On Mar 30, 2007, at 4:59 PM, Tyler MacDonald wrote:
Small Applications. We come up with some small non mission
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
I’d suggest you do 3, 4, and 5 all at the same time. There’s
probably someone on the team that is
a “read the docs and try it once” person (#3, maybe #5)
a “just point me in the right direction” person (#4)
a person who fits the blank in: “well, just ask ___, s/he will
know” (#5)
#1 and #2 won’t be too effective to start – you need to know how
much you don’t know!
And make sure you focus on the Ruby part of RoR. You’ll save a lot
of time if you avoid the pitfalls of thinking in some non-Ruby
language while you’re doing Rails.
(Presumably the team already has a handle on (X)HTML, CSS,
JavaScript, etc.
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.
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.
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
We bring in a person/company to do onsite training for a week.
We find a local training class.
Self Study (books and online documentation).
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.
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.
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.
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 D."
given by Dave T. and Mike C… 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.
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…
