Re: [stlruby] Excellent meeting tonight

[Mark Volkmann]

I moved my reply to the steering committee mailing list.

On Jul 10, 2007, at 12:22 AM, Randall wrote:

Thanks to Mike Sullivan and Jeff Barczewski for leading the meeting

tonight with the start of the new Rails project.

I'd also like to add my thanks! I think the new format is going to be great!

Tonight was a great start, too!

I thought the meeting started great, but I'm concerned about the way it ended. My concern is that there were many people in attendance that had very little exposure to Ruby and Rails. Things got moving pretty quickly once coding began. Lots of terminology was quickly thrown out and many things were only briefly explained. I imagine the people that already knew Rails pretty well really enjoyed it and those that didn't were more than a bit confused.

Here are some of the questions I think newcomers might have had.

How do you install Rails?

How does Rails compare to other web app. frameworks? What's the basic architecture?

What is a gem?

What is a block?

What is a controller?

Why are there three databases?

What is Rake?

I think we need to decide whether we are going to cater to newcomers by moving more slowly and explaining things more thoroughly.

I have a suggestion for the next meeting. I think we should immediately set up the RubyForge project so that attendees can grab the latest code after each meeting. We should document on the web site what they can do with the code such as running tests and exercising whatever functionality is currently implemented. This will allow people that miss a meeting to catch up before the next one.

I hope this email doesn't come across as overly negative. I just want to make sure we maintain the great attendance we had last night.

---

Mark Volkmann

ma...@ociweb.com

[Mike Sullivan]

Great point Mark.  I noticed the same thing, as did Randall H.  He made the suggestion to go over those issues in a 30 minute beginner / refresher presentation next meeting.

I expect that the variety of attendee experience may continue to diverge as we grow (at least initially).  How does everyone think we should reconcile that and bring the newcomers up to speed without overly diminishing the value to experienced Rails users?

On our group site, we could suggest a list of tutorials (e.g. Curt's OnLamp articles) as homework for newbies, or we could post our own group tutorial with the material Mark suggested and include the gems and techniques that we use in our development, or we could regularly (quarterly) do a presentation to bring newcomers up to speed.  Any other ideas?

  - Mike

[Jeff Barczewski]

On 7/10/07, Mark Volkmann <ma...@ociweb.com > wrote:

I thought the meeting started great, but I'm concerned about the way it ended. My concern is that there were many people in attendance that had very little exposure to Ruby and Rails. Things got moving pretty quickly once coding began. Lots of terminology was quickly thrown out and many things were only briefly explained. I imagine the people that already knew Rails pretty well really enjoyed it and those that didn't were more than a bit confused.

Thanks for the feedback. We'll be trying to adjust to our audience through out this process.

I didn't keep a tally but it seemed to me that there were only a few complete newbies in the group, that many others had some exposure to Rails.

If the majority were complete newbies then we'd need to take a step back and bring them up to speed or at least point them to some good things to read to get the basics. We can also address questions that are above people's heads as they are raised in the meetings, though it may take a little while for people to get aquainted with the group and feel comfortable asking questions.

However there is an equal danger to spending too much time going back over the basics if most people have what they need to get going. You will lose the group that already is using Rails, they are coming to learn new material. They will tolerate some brief questions but won't want to be stuck in the basics for the majority of the meeting.
 

Here are some of the questions I think newcomers might have had.

How do you install Rails?

How does Rails compare to other web app. frameworks? What's the basic architecture?

What is a gem?

What is a block?

What is a controller?

Why are there three databases?

What is Rake?

It is a balancing act in what to go into detail on and what to skip over as to not bore those already have some familiarity.

Randall mentioned that we might take 20 minutes to go over Rails before the next sessions. So that might be prudent, however I expected some of the other things to be explained as we got into them. We only looked at models yesterday, so when we get into controllers we would discuss those concepts there. I did expect to have more time to discuss what we did cover though (models and migrations), so we'll have to be sure to get that in if even at a high level.

I don't know that spending time on how to install rails is the best use of our time since this is covered many places on the net and in books. We can however point people to the details about where to find this information. In retrospect I don't believe we ever had any presentations in the past on how to install Ruby either.  Those details can be very dry and specific to the environment they are using. I believe that if someone came to a meeting to see what Rails is all about, they come to see what some of the buzz is about and if they like it, then they turn to find out how to install and to read more. In some ways we might be better in evangelizing key concepts and not getting caught down in the details unless asked. We should have resources prepared for those to find out the details if they want to.

We purposely didn't go into explaining Ruby (gem, block, rake) to save time, however I was going to respond to any questions that would arise from new people not knowing concepts, and if not in this meeting then in future meetings as well. We've had questions like that come up in Ruby meetings and we address them as needed.

But sometimes you don't really need to understand all the details to use things for instance if you are told to do 'gem install zentest' to install something, you can do so without knowing in detail what it will do. (It is nice to know all the detail but not required for most). Same with Rake, you use this command to do this, so you can use it without knowing intimately how it works. Blocks are great to understand but often new people can use them simply by following an example since they are pretty intuitive in the syntax.

It comes back to the differences in various rails users, some want to know the details of how everything works and there are those that just want to know the high level stuff to get by. I believe we will have both in our meetings, so it will be a balancing act to accomodate both types.

If this were indeed a full training course with adequate time then one needs to go into details to make sure everyone understands the full details, but for these short presentations, we could easily spend all our time on any one of these topics if we went into details.

So depending on the mix of people who regularly attend I think we'll need to adjust accordingly. We'll need to adjust meeting descriptions to match what level of detail we will be going into. We can do a better job of that.

If we are having a meeting that is Rails 101 then we state that clearly about what is and isn't required prerequisites and then experienced developers will have fair warning about the content. If we do more advanced topics then we do the same so the newbies can know that things may be over their head to some degree.

I think making sure that our announcements discuss the level of detail, prerequisites, and goals of the meeting will be extremely helpful in informing the public in advance and setting expectations.

I think we need to decide whether we are going to cater to newcomers by moving more slowly and explaining things more thoroughly.

Yes, and we need to indicate the prerequisites and level of content in the announcements to be clear. We may want to walk the middle ground here rather than going completely one way or another. Another answer might be to start a meeting with beginner level stuff at 6, then move into heavier stuff at 6:20 (so experienced developers could chose to come a little late if not interested in the review, and/or newbies could leave after the intro).

It really depends on who our regular attendees are. It would be nice if we had our polling feature to ask these types of questions.

Mary Jo mentioned that it might be good to ask for feedback at the end of the meeting so we can know how we did (too advanced, too easy, too slow, too fast, areas for improvement). I think that would be a good idea as well. I can bring some survey forms to help us get that information next time and we'll have to do less speculating.
 

I have a suggestion for the next meeting. I think we should immediately set up the RubyForge project so that attendees can grab the latest code after each meeting. We should document on the web site what they can do with the code such as running tests and exercising whatever functionality is currently implemented. This will allow people that miss a meeting to catch up before the next one.

Yes, that is what I had envisioned as well.

I hope that the other steering committee members can share their feelings on all this as well to make sure we have a collaborative perspective since I only got to talk to a portion of the people.

Jeff

[Gordon Thiesfeld]

> I have a suggestion for the next meeting. I think we should immediately set
>
> > up the RubyForge project so that attendees can grab the latest code after
> > each meeting. We should document on the web site what they can do with the
> > code such as running tests and exercising whatever functionality is
> > currently implemented. This will allow people that miss a meeting to catch
> > up before the next one.

Other Ruby user groups/brigades have a single RubyForge project for
all the code/libraries they're working on (NYC.rb, Seattle.rb,
Missoula.rb). Is that what you have planned? I think it would be a
good idea to have a central location for everything done in the
meetings.

I thoroughly enjoyed the meeting, and I'd be glad to help out with
anything that needs done.

Gordon

[Craig Buchek]

A few thoughts on the new meeting location and ideas:

The room is great, except for lack of Internet access. I did find an
RJ45 port in the back that was live. If someone brings a wireless
router, we'd be good.

We had a lot of new people. We need to figure out why they came and
how they find out about us, so we can keep it up. We also need to see
what we can do to keep them coming back.

The dinner after the meeting was well-attended. Awesome -- I often get
more from the after-meeting get-togethers than actual user group
meetings.

As far as catering to newbies, my general suggestion is to have a
presentation start with the basics, and end with some really advanced
stuff. That way nobody is bored with the whole thing. With a couple
presentations per meeting, we could have more introductory topics at
the beginning, and more advanced topics later in the evening.

I'd like to see a (perhaps 15-minute) presentation on setting up a
RubyForge project. So maybe hold off and create our new project on RF
live at the next meeting.

Feedback would be helpful, but it'd have to be written hand-outs. If
you just ask, everyone will say it was OK. Even if you have a written
survey, people will likely be too polite to respond critically to a
free presentation.

One idea for newbies that I've considered for the LUG is to give new
folks a "newbie packet". It would describe some of the basics about
Ruby, Rails, Gems, etc. as well as some info about our group. Maybe
include the articles on how to install Ruby and Rails, how to get
started with a Rails app, and recommended books, web sites, and
articles.

Craig

[Mark Volkmann]

All excellent suggestions!

--~--~---------~--~----~------------~-------~--~----~

You received this message because you are subscribed to the Google Groups "Saint Louis Ruby Users Group - Steering" group.

To post to this group, send email to stlruby-...@googlegroups.com

To unsubscribe from this group, send email to stlruby-steeri...@googlegroups.com

For more options, visit this group at http://groups.google.com/group/stlruby-steering?hl=en

-~----------~----~----~----~------~----~------~--~---

---

Mark Volkmann

ma...@ociweb.com