[Proposal] Deep dive modular classes

[chancancode]

TL;DR Version:

I'd like to propose a "deep dive" track for students who have completed the suggestotron app in previous workshops but would like to gain some in-depth knowledge/understanding of Rails. A deep dive class would focus on a single topic that we don't normally have time to cover in details (e.g. Rails Models).

Background:

Learning Rails is hard, because to really understand how things work, you need to know about...

• Shell / Command line
• Programming
• OOP
• Ruby
• HTTP, REST
• Browsers
  
• HTML, CSS
• JavaScript
• MVC
• Gems, Bundler
• Git
• Rails
• Networking, Servers, Cloud
• ...

The Railsbridge curriculum, as it stans today, is an attempt to "teach" (or more accurately, "show") them Rails and everything else on this list in merely 4 hours. That's obviously not enough time to cover everything, and so this leaves the teachers two options:

1. Fly through everything and complete the curriculum anyways.

    - Pros: Students get a working web app they can show people by the end of this. Hopefully this would spark interest and motivate them to learn more by themselves afterwards.

    - Cons: Lots of hand waving. (This thing you see here is called X, and it does Y. Unfortunately we don't really have time to go into details today... / Don't worry too much about how this works...) Not a lot of understanding. To some students (esp beginners) it might make the whole Rails/programming thing seems even less approachable.

2. Explain certain topics in details, make sure everyone gets it before moving on to the next topic.

    - Pros: Students actually get a good understanding of something by the end of this.

    - Cons: That "something" is probably not Rails. If you really try, you probably won't even get pass Ruby for a beginner class. Some students might feel disappointed because that's not what they signed up for.

From what I've seen, most of the time we would end up leaning towards #1. Either way, most students would probably come out of the workshop with way more questions than they started with. (Not that it is a bad thing.) We do encourage them to come back for a more advanced class next time, but there are only so much you can learn by doing suggestotron over and over again (and skipping over the "hard" topics over and over again). (The "lack of continuity" problem.)

Mary suggested that perhaps we have more structured definitions for the different class levels and use them consistently across the workshops. However, this would only help if we also restructure the curriculum and spread the topics across different levels (Lv 1 = intro ruby, Lv 2 = html/css, etc), otherwise there would still be the same "lack of continuity" problem. Personally, I would like to see this happen, but I suppose this is going to be quite controversial (cons: students must come to multiple workshops to complete the whole curriculum) and requires a massive overhaul that would take quite a while to implement.

[ By the way, if we decided that the point of Railsbridge is not to "teach" them Rails (in the sense of getting them to understand things), but rather just to show them the "big picture" and motivate them to learn, that's cool too. However, if that's the case, why not give up the explanations altogether (you can only explain so much in 4 hours) and instead focus on upping the "wow" factor - as in showing off the actually "cool" parts of Rails? Like, add more filed types to the scaffolds, add validations, more associations, somehow squeeze in the cool helper methods like 5.minutes.ago, distance_of_time_in_words, etc. This seems like an easier sell if the goal is to convince them it's worth their time to learn Rails - compared to showing them all the scary up-front setup cost & learning curve, and end up with something that they could have built easier with PHP in less time (well, perhaps not really, but you see what I'm getting at). ]

The Proposal

I'm proposing a (partial) solution to the continuity problem that involves less drastic changes to the curriculum and complements our current workshop structure. In addition to what we already offer, I'd like to propose an additional "track" for returning students who already completed the suggestotron app in previous workshops, which I call the "deep dive" track. Each offering of this "deep dive" track would focus on a single topic and would run alongside the regular classes. These classes would build on top of the suggestotron app they have already built. For example:

• Models deep dive
• What is a database, and why do we need that?
• Poking around with Rails console
• Validations (e.g. topic name is required)
• AR quires (e.g. sort the topics list by # of votes)
• Migrations explained (e.g. add a new field to topics)
  
• Associations explained (e.g. a topic belongs_to a category)
  
• ...

Other possible topics are :

• HTML + CSS + Rails Views -> Prettify the suggestotron app (I think a front end class is already in the works...?)
• JavaScript / CoffeeScript + AJAX + Asset Pipeline -> ????
• REST / HTTP + Controllers + Routing -> Authentication (from scratch)?
• Git(hub) + bundler + finding/using gems -> integrate with twitter or something
• ...

I think alumni from the intermediate classes are going to benefit the most from this, but I think it's possible to structure these classes in a way that the only requirement is that they have completed suggestotron.

If people liked the idea, I can spend some time working on a draft curriculum (I think the model class is most approachable so I'll likely start with that). If you are interested in helping out, you're more than welcomed to!

Timeline

I won't be able to make it to the July class, so if we decided to do this my goal is to have a draft ready for pilot at the August class (with the help of an experienced teacher/TA and a few brave returning students). From there we can evaluate how helpful this is and move forward from there.

WDYT?

[Carina C. Zona]

I like the idea of giving instructional opportunities that focus on
going deeper with selected topic(s). If you're game to develop
curriculum, I hope you do go for it.

I agree it has potential to be a workshop track. Though it'd probably
have to be limited to venues that are particularly big, to accommodate
at least one more classroom and the students/volunteers for that.

I think it has better potential as either its own workshops, a la
Emily & Rachel's successful experiment in developing the frontend
version <http://installfest.railsbridge.org/frontend/>, or else in
evening course(s). The graduates frequently want to know "What's
next?" and are eager for follow-up education resources. Judy Tuan's
Women Who Code Rails Study Group, Gabe Kopley's Rails class at
Noisebridge, the Railsbridge Alumni Study Group, etc are each filling
different niches. I can picture this doing well to fill another of
them. Offering it separately would allow you to retain maximum
flexibility to experiment, rather than have to immediately tailor it
exclusively to the goals and constraints of the existing workshops.

That said, it need not be only one or the other.

I'm the organizer for August 24-25 at Rackspace. Let's talk off-list
to explore what, if anything, might be realistic to attempt there.

> --
> You received this message because you are subscribed to the Google Groups
> "RailsBridge Workshops" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/railsbridge-workshops/-/oPC0yvxot_cJ.
> To post to this group, send email to railsbridg...@googlegroups.com.
> To unsubscribe from this group, send email to
> railsbridge-work...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/railsbridge-workshops?hl=en.

[Sarah Allen]

Great topic.  Appreciate all of your thoughts.  Some notes:

#1  In every teacher training I've ever given or attended, we emphasize that finishing the app is not the goal.  The goal is to make a connection with the students and teach what they are interested in.  Getting to deployment *is* important, since we want to have everyone go through the "story arc" of building a deploying a Rails app, so they experience all parts of the cycle.

#2 I don't think we currently have a good curriculum for people learning Ruby (at least last time I looked 2 months ago).  We used to have additional deep curriculum, but it was never unified into a track.  I think that would be good. 

#2 Are you aware of the Front-end workshop?  I think this is a really exciting development that Rachel (and others) started in Feb. It provides a different entry point.

When Sarah and I first came up with suggestotron as the app we would build in the workshop.  We had this idea that there would be a series of smaller, follow-up workshops.  We thought that alums would finish the suggestotron app and then use it for people to sign up for mini-workshops where we could do a deep dive.  It seems we still have waiting lists... if we pulled out the alums to separate "deep dive" workshops, where people would have to attend one of the other workshops first, then I think we could do a better job with the intro workshops and (i hope) get more alums to TA.

Don't forget that the majority of people who come to the workshops have prior programming experience. Many people already come with deep experience in several topics listed under "background."  I always think about how frustrating it was for me to learn Rails -- I knew command-line, OOP, HTML, CSS, JS, MVC, HTTP, REST, but not Ruby, Rails, git.  Sometimes when I help out with workshops today, I don't know where someone like me would fit in -- advanced programmer, novice in many of the tech we teach.  I didn't need encouragement to become a programmer.  I needed to figure out whether I was interested in adding Ruby or Rails to my core set of tools.  The small groups seem to work really well for this profile.  Deep dive into some things, fly over others.

Another idea that a few of us have talked about and no one has moved forward with is providing different entry points for people with different backgrounds:  for Java programmers, for PHP developers, etc.  Alternately, I'd like to see one that was purely "Learn to Program in Ruby" that does a deep dive into programming concepts.

Interested in what other people think.

Sarah

[Mary Jenn]

Yep! Good stuff! 

Hmm….this reminds me: I think I need to change the slide in the presentation deck that says, "By the end of today, you will have a real app live on the web." For me, knowing that it is not about the destination, but the journey,  the slide served as a reminder for me to tell the students that  but it may be misleading and confusing.  I also covered this emphatically in the training and Godfrey mentioned it too. 

I think that, still, they like being able to have a finished app to deploy to heroku. 

It seems to me that the front end workshop people should definitely be involved in this discussion about follow up curriculum. 

We had a few really experienced programmers this time (one was 15 yrs!) She loved it and I think she will be a key person in the RailsBridge community in the So. Bay/Peninsula. Her instructor was a guy with 6 years RoR experience and a former teacher, so we were blessed with some really strong volunteers. 

[Sarah Allen]

I still think everyone at the Rails workshop should deploy an app -- even if they don't "finish" the curriculum.  

Deploying an app is just:

rails new suggestotron

cd suggestotron

git init

git add .

git commit -m "new app"

heroku create

git push heroku master

Even if people spend most of the day learning Ruby, spending the last class session deploying a Rails app is fun and completes the picture.  If we're not going to have them build a Rails app, then I think it should be a separate "Learn Ruby" workshop like the front-end workshop is different.

My $.02

Sarah

[Carina C. Zona]

+1 to wrapping the day with a deployment, regardless of whether
they've finished suggestotron. Even for those who won't fully
understand deployment, it's just plain satisfying to walk away from an
intensive with something live to show for it. Also, many do ask how
to show their achievement to family/friends/etc.

[Mary Jenn]

I'm totally on board with that! Generating and deploying the app feels like the "magic" part of it, but it's really fundamental and getting even more into ruby would actually be a nice "deep dive" modular class.

[Godfrey Chan]

Thanks for all the feedback! :)

My 2 cents… (more like my $200… sorry for making it so long :P)

> Offering it separately would allow you to retain maximum
> flexibility to experiment, rather than have to immediately tailor it

> exclusively to the goals and constraints of the existing workshops.

There are two parts to this. I'm neutral about offering this seperately in terms of time/location - although I probably won't be the one organizing this so it's probably only going to happen if someone else is interested in picking up the organizer role :P

Content-wise, I do want to tailor this exclusively for the alumni of the workshop. I don't think the problem is the lack of resource for learning Rails in depth. If nothing else, the Rails tutorial is an excellent resource. Instead, I'm trying to fill the "what's next" void among the Railsbridge alumni.

I think the current curriculum and suggestotron has the right structure and potential.  I feel like if the students actually understand all the steps they went through, they would be in a pretty good position. I just keep wishing that I have more time during the workshop to explain the steps in more details instead of just pointing out "this is a big topic and we don't have time for today". I'd like to be able to add "…but, if you are interested in this..."

> That said, it need not be only one or the other.

How about a hybrid approach? What if I flesh it out enough in words so that it is closer to a tutorial that the students can read/follow on their own? When we can afford to offer this alongside the regular workshop, we can do that; otherwise we can just point students to these modules that they could read online.

> #2 I don't think we currently have a good curriculum for people learning Ruby (at 

> least last time I looked 2 months ago).  We used to have additional deep 

> curriculum, but it was never unified into a track.  I think that would be good. 

I'd love to see this too. Last time I talked to Stephen, I think he said he has been thinking (working?) on something.

> When Sarah and I first came up with suggestotron as the app we would build in 

> the workshop.  We had this idea that there would be a series of smaller, follow-up 

> workshops.

That sounds almost exactly what I have in mind :) The delivery method (whether or not we do it along side the main workshop, or whether it needs to be an in-person workshop at all) is secondary, but I think something like this would really complete the picture for the students.

> #1  In every teacher training I've ever given or attended, we emphasize that

> finishing the app is not the goal.  The goal is to make a connection with the

> students and teach what they are interested in.

> I think that, still, they like being able to have a finished app to deploy to heroku. 

This is a tough one. I was teaching a beginning-intermediate class yesterday. We ended up spending the two morning sessions teaching Ruby. We moved in baby steps, making sure everything actually make sense to everyone before moving on. By the end of the second session, we had a little coding challenge. The students were able to complete that and shared many different valid solutions. I actually feel like I taught something :P

At the beginning third session, although I still don't feel like we have covered enough about Ruby, I feel that some of the students are really eager to move on, and I think that's probably the right thing to do - they signed up for Rails bridge after all.

So we did. However, compared to the baby steps we have been taking in the morning, where we introduced one small concept after another (variable, objects, methods, arrays, etc), the jump into the Rails world feels like leaping across oceans (the fact that it's right after lunch probably didn't help). We have to explain the shell (cd, pwd/cwd), the rails (new) command, git, heroku, rails server, etc in an hour just to get started. Then there is database, rake db:migrate, rails generate scaffold, MVC, HTML, etc in another hour just to get something that I'd feel comfortable calling a web app. Compared to the morning, I'm really not unsure how much (if at all) the students actually understand any of these, and I was feeling a bit uneasy about that.

> I still think everyone at the Rails workshop should deploy an app -- even if they 

> don't "finish" the curriculum.  

> Even if people spend most of the day learning Ruby, spending the last class 

> session deploying a Rails app is fun and completes the picture.  If we're not 

> going to have them build a Rails app, then I think it should be a separate "Learn 

> Ruby" workshop like the front-end workshop is different.

I'm not sure so sure about this. I don't quite see the value here. Didn't they already built and deployed a more functional app (the drinks app) from installfest? If the point of this is to meet their expectation of "getting a web app by the end of a web app workshop", I'm not sure if that would cut it, because I'd hardly call the "Welcome to Rails" page a web app - and even if it does qualify, I'm not sure whether having a "welcome to Rails" app is really that satisfying/magical - especially when they already deployed a more functional version of that the night before.

Come to think about this, this is pretty much what I did with my class. We taught them Ruby in baby steps in the morning, but felt obligated to teach some Rails, so we used to last two hours to get to the scaffold part.

The weird thing is, by the end of these two sessions, the functionality of this app is exactly the same as the drinks app they built during the installfest (with the labels changed)! Any value I am adding here must therefore come from the fact that I'm explaining what all the steps mean instead of just blindly following them. I speculate it would probably take them about an hour just to follow the steps on their own, which means I really only getting around an hour of "explanation time". This is clearly not enough time to really explain all the concepts behind the steps (shell (cd, pwd/cwd), the rails (new) command, git, heroku, rails server, database, rake db:migrate, rails generate scaffold, MVC, HTML), which led me to doubt whether I really added any value at all in the afternoon.

I think the outcome/expectation/goal of the workshop need to be better communicated, not just to the teachers, but also to the students - before they sign up.

There are two parts to "outcome" - what you can bring home from this (the "product") and what you have learned from this (the skills and/or knowledge).

For example, if I go to a pottery workshop, I probably expect to take home with me a DIY clay teapot or something, and have little expectation about the skills I'd learn because it's not like I'm going to get into the business of making and selling my own clay teapots after this.

On the other hand, if I go to a investment workshop, I probably don't care much about the "product" (some sort of filled-out worksheets?), but I'd expect to have learned some skills that I could apply in the future when I invest money.

Because a Rails workshop (or a programming workshops in general) is not something that people come across very often, the expectations are across the board and I think it is important for us to communicate that explicitly up front. 

My intuition and initial impression suggest that Railsbridge probably belongs to the latter (a learning workshop - which is why I feel so strongly about making sure the students actually understand what they were doing), but now that I think more about it it really could be either, or anything in between.

I definitely have heard very different things about this among the teachers and even the organizers/curriculum writers. It would be nice if we could collectively decide (or if it has already been decided in the past, then reiterate) what a Railsbridge workshop is trying to do in terms of outcome, so that everyone (organizers, curriculum writers, teachers and students) are all on the same page.

If we decided that we indeed want to focus on the learning part, then I think we should think about the beginner/intermediate path a bit more. I think the curriculum we currently have is great for more advanced students (I never taught/TA'ed those classes, so I can only guess). I just don't think we have a very smooth path for beginners.

Perhaps it really boils down to the fact that Rails development is difficult, and it's simply unrealistic to expect someone to be able to learn Rails development without first knowing the basics such as basic programming & basic HTML. (Again, I'm using "learn" in the sense that you will be able to apply and adapt the skills you gained to a different problem in the future. Learning what the V in MVC is all about isn't very useful if you don't know how to edit the HTML anyways. Same thing for learning M & C when you don't really understand how methods and if statements work.) In that case, maybe we should either just make those skills a minimum requirement for enrolment (probably undesirable), or we probably should always have those two beginner tracks (one for basic programming and one for basic HTML) alongside the main track, so beginners could first go to those tracks to learn the basic, then come back again for the main track?

On the other hand, we can alternatively focus on the "product" instead or the skills. This is not really that crazy, because frankly there are so many excellent resource out there to learn Rails, all you really need to do is to spark their interest and point them to the right resource at the end.

If this is our focus though, I think we didn't go far enough. With what we currently have barely touches the coolest part of Rails. If we are not attempting to teach a skill they could use in the future, but rather just to spark interest and motivate further learning, we should ideally show off as much benefits of Rails as possible (how little work it takes to do X). Given that even the beginners could follow the steps during the installfest to create a CRUD app within ~ an hour, it should theoretically be possible to add 2-3X more features to the Suggestotron app. Imagine having a working Suggestotron with data validation, commenting and Facebook OAuth integration by the end of the day. Now THAT would be a cool app that I can't wait to share with my friends, and it most definitely would motivate me to dive deeming into Rails/web development. (And hey, even if you decided not to, you still get an app that's actually useful by the end of the day, much like the clay teapot you get out of a pottery workshop).

I feel like if we make up our mind (or communicate that clearly if we already did) decide to focus on one of the two approach, we could provide a much better experience for beginners. (Actually, I think the second approach also fits Sarah's profile really well, as in "I didn't need encouragement to become a programmer.  I needed to figure out whether I was interested in adding Ruby or Rails to my core set of tools.")

> if we pulled out the alums to separate "deep dive" workshops, where people 

> would have to attend one of the other workshops first, then I think we could do a 

> better job with the intro workshops and (i hope) get more alums to TA.

Or that :)

[Alex Chaffee]

Sent from my iPhone

On Jul 1, 2012, at 9:37 PM, Sarah Allen <sa...@ultrasaurus.com> wrote:

> I still think everyone at the Rails workshop should deploy an app -- even if they don't "finish" the curriculum.

+1000

Demystifying web app development is what it's all about, and getting an app up on the Internet so anyone can see it is arguably the most important part.

[David Doolin]

> --

I'll go further: demystifying the command line interface has huge long
term consequences. It's an important side effect of the workshops.

[Mary Jenn]

It was such a whirlwind, but I know i explained to a few of the attendees (and to Godfrey) what the original vision of Suggestotron would be--as a usable tool for RaislBridge--to communicate the relevance. I know that some of the women are getting together to do a study group, and were trying to think of a project. I suggested that they work as a group on building it out to practice. I did let them know about BridgeTroll, and that they may want to get in touch with the people who are working on that to make sure that its not something already included in BridgeTroll, but from what i know it's not.

Godfrey, I think the workshop series building on the barebones app is a great idea and if it all gets the go ahead, I'd be glad to help you with it. :)

[Alex Chaffee]

Godfrey, your $200 email is spot on and could become a FAQ. The points you raise are all valid and it's good to readdress them from time to time.

Which I will be happy to do once I'm at a proper keyboard. :-)

-A

[Mary Jenn]

By the way, since Carina mentioned Gabe's class and he covers some more advanced topics--I wonder if this something to collaborate with him on and get his input. Just a thought. 

[Alex Chaffee]

Fisking Godfrey (no, that doesn't mean what you think it means):

> If we insert "What's this?" or "Learn More" links in the installfest docs, the students *will* read them, and since I don't think you can reasonably explain things like "git" and "heroku" to beginners in a paragraph or two, I have a feeling that this is going to cause more confusion among the beginner students.

Excellent point. Now that the installfest and curriculum apps are
integrated, we can do more in the installfest pages to point students
not at arbitrary external links but to the appropriate curriculum
sections (which may then point at the external links) -- which might
signal to installfesters "we'll cover this tomorrow". Sometimes it is
important to have deeper explanations directly inside the installfest,
though, especially when it will inform an installation decision or
problem. Case by case, I'd say.

> propose a "deep dive" track for students who have completed the suggestotron app in previous workshops but would like to gain some in-depth knowledge/understanding of Rails. A deep dive class would focus on a single topic that we don't normally have time to cover in details (e.g. Rails Models).

This sounds great to me. We could teach it/them either during a
regular workshop (as another track, like we have beginner and advanced
and advanced beginner and so on now) or during a different workshop
altogether.

> Mary suggested that perhaps we have more structured definitions for the different class levels and use them consistently across the workshops.

I'm reluctant to use the term "levels" since it's not a strict linear
progression. I like to emphasize what will be taught rather than
rating the students. "Tracks" or "classes" or "curricula" are all
fine.

> why not give up the explanations altogether (you can only explain so much in 4 hours) and instead focus on upping the "wow" factor - as in showing off the actually "cool" parts of Rails?

Because those are only cool if you have something to compare them to.
Otherwise it's just more crap to learn. To a beginner, the fact that
methods like .ago exist is not really impressive. Nor that Rails
Migrations are the most elegant and beautiful way to do schema
migrations if you don't even know what a schema is.

> end up with something that they could have built easier with PHP in less time

This is why I've always liked Sinatra as a teaching tool. Once a
student knows a little bit of Ruby syntax they can make a Sinatra app
-- without a database or layouts or REST or any of the important Rails
features -- in a few lines of code, with or without a separate
view.html.erb file. That really nails down the concept of CGI (not
that anyone calls it that any more): the user says "/hello" and your
"get '/hello'" code block runs and returns "<b>hello</b>" which shows
up in the browser with "view source". Spooky action at a distance
demystified!

Rails is good too. It's too bad we don't have time to teach intro to
Ruby *and* 20 minutes on Sinatra *and then* Rails/Suggestotron -- and
I agree with Sarah et al. that jumping right to Rails makes the most
of our precious teaching hours.

> These classes would build on top of the suggestotron app they have already built.

That's pretty powerful, but I'd say not an essential requirement. We'd
have to be careful to make them independent, though. Or would you say
you have to do the Style Track (HTML/CSS) before the Model Track (or
vice versa, depending on what depends on what)?


and Sarah:

> Alternately, I'd like to see one that was purely "Learn to Program in Ruby" that does a deep dive into programming concepts.

Big fat +1 on this too.

We do have a few slideshows but they're not really adequate as a curriculum:

http://workshop.railsbridge.org/workshop/foundational_skills
http://workshop.railsbridge.org/workshop/ruby_for_beginners
http://workshop.railsbridge.org/workshop/ruby_for_programmers


and Carina:

> http://installfest.railsbridge.org/frontend/

Please use

http://workshop.railsbridge.org/frontend/

even though the other one works too (for now).



--
Alex Chaffee - al...@stinky.com
http://alexchaffee.com
http://twitter.com/alexch

[Mary Jenn]

I was envisioning that brief definitions could be done not even in an external link, but as a "quick view" or rollover very brief description that they can mouse over without leaving the install directions. 

For example, when a student rolls over "Git",  they get a bubble that says "Git is a version control system". We often get the question "What is git? during installs. It doesn't explain it thoroughly, but it at least gives them a little more understanding of why they're installing what they're installing or why they're typing what they're typing. Is that not helpful? 

I''ll fork the repo and add some just for kicks. 

[Bradford Cottel]

>> end up with something that they could have built easier with PHP in less time

> This is why I've always liked Sinatra as a teaching tool. Once a
student knows a little bit of Ruby syntax they can make a Sinatra app
-- without a database or layouts or REST or any of the important Rails
features -- in a few lines of code, with or without a separate
view.html.erb file. That really nails down the concept of CGI (not
that anyone calls it that any more): the user says "/hello" and your
"get '/hello'" code block runs and returns "<b>hello</b>" which shows
up in the browser with "view source". Spooky action at a distance
demystified!

> Rails is good too. It's too bad we don't have time to teach intro to
Ruby *and* 20 minutes on Sinatra *and then* Rails/Suggestotron -- and
I agree with Sarah et al. that jumping right to Rails makes the most
of our precious teaching hours.

+ 1,001

Great idea Alex.

I actually think that spending that 20 min teaching *exactly* that would _more than save_ 20+ minutes of confused looks later during the MVC discussions, esp. when REST eventually rears its pretty little head (like from the auto comments like # GET /users above the def index)!

Adding a we bit 'o Sinatra as a *fundamental* knowledge piece to a Rails training would be very instructive, helpful, and even time-saving. (Might be able to skip it in an intermediate or advanced class, but essential for beginner or advanced beginner, imo.)

[Judy Tuan]

I'd like to respond to this part:

> The weird thing is, by the end of these two sessions, the functionality of
> this app is exactly the same as the drinks app they built during the
> installfest (with the labels changed)! Any value I am adding here must
> therefore come from the fact that I'm explaining what all the steps mean
> instead of just blindly following them.

Practice is good.

Doing it once at installfest will get people familiar with it. Then
when they do it again the next day with the teacher explaining,
they're already familiar with it and that'll help them absorb and
remember what the steps mean and understand what each step is doing.

Also, if they do the same thing twice, but with certain words changed
out, that actually helps them pick out the patterns. For someone
totally new to rails, the first time you type "rails generate scaffold
Teacup," you don't know that "generate" and "scaffold" are key terms.
You might think "scaffold" is part of what you're naming your model or
something. So actually I think the repetition is good, so that they
can see a few examples right away, and glean the important bits by
analyzing how they differ.

~judy

[Doug May]

Another extremely valuable thread.  I love this community!

There is much to be said here, and I'm not going to pretend to hit even the most important points, but I'll hit some of the ones I feel strongly about.

1.  Railsbridge is an outreach program (as I understand it).  The goal is to get more women into coding, and to further empower those already there, by making some very interesting and fairly modern technology accessible.  This implies a potentially different teaching style than the traditional programming class.  This is why it is so important to make it extremely safe and in fact encouraging every single question they may have.  I am both an unavoidable sexist and an adamant anti-sexist.  Humans cover a huge spectrum, and while there are clear differences in the aggregate between men and women, the huge variability within both means that there is massive overlap, and exceptions to every rule.  Having said all that, I feel very strongly that the overwhelmingly male majority in the programming world is in part a self-reinforcing bias, that makes it unduly difficult for women in general, and for men who lean toward the feminine end of the spectrum, to break in and succeed.  We have decades of practices and habits that make empathy, collaboration, (and lots of other things) relatively unnatural to the typical programmer.  I would suggest that this is why so much software appears to have been generated in near-total ignorance of what the user needs.  In many ways, the existing body of tools and code, especially if you go back further in time, almost exaggerate the gender differences, and embody some of the strongest "male" anti-patterns.  I know that these statements will ruffle feathers, if not trigger a flame war (a "male" anti-pattern?), but my only real "regret" about my first Railsbridge (and the teacher training beforehand) was that almost nothing was said (that I heard) about gender differences, the pre-existing coding culture and tools, and the reason for the outreach (other than the obvious -- the numbers are horribly skewed).  I consider it vital to open up the conversation, so that the things that are not being said can start to come out of the shadows, and so the industry overall can start to recognize and take responsibility for its inherited biases, and start to step out of its own shadow.  Just my opinion, but I feel it so strongly I'm willing to be shot down by the group rather than leave it unsaid for another round.  The questions that women have about programming, and the ways that programming tools expect them to think, are an invaluable set of hints as to where the bias is encoded right into the water in which we swim, and I think Railsbridge is positioned to do amazing work toward carrying the whole industry, if not the whole world, forward, but we have to claim that as our goal (without it becoming yet another barrier to women registering and taking advantage of the program).  It's an extremely fine line to walk, and the program has done marvelously well, so I'm not so much advocating a change in practice as a change in consciousness, and hopefully an overt recruitment of our "students" into being co-researchers into the prevailing gender gap in the industry.

In full disclosure, I should say that I also consider those biases to be endemic to Western science and Western economics, and that I consider that legacy to be a central factor in our current sustainability crisis, and perhaps our biggest obstacle in making the transition to sustainability, so I consider the work we are doing to be vital to human survival, as much as balancing out the geek population, hence my over-the-top passion on the subject.  I'll also add that my one undergrad class in Information Systems was taught by a woman (in fact, the very one who found the primordial bug), my first manager at Bell Labs was a woman, and I have only run IT shops where my executive management was primarily or exclusively women.

With that off my chest, I'll now return to the original thread, and a more genderless discussion.

2.  I think there is in great merit in the observation that the goal of having a deployed web app is accomplished in the Installfest.  That means that we have all day Saturday to embellish, extend, or refine our understanding.  I think that we could relook at the installfest as an opportunity to help each student clarify what aspects of that she most wants to develop next, and inject some commentary and guidelines so that each student can use the installfest to inform their choice of group for Saturday (see my other comment on the "registration process" thread, once it gets approved and posted).

3.  Again, at the risk of adding more neon attractors to the target I've painted on myself, I will oversimplify and say that in the basics, there are 3 distinct bodies of knowledge needed to grok a basic web app.  The first is basic logic and data types and syntax and operations, aka Ruby.  The second is the web in general, and html/css in particular, as a layout framework and presentation platform.  The third is the integration architecture, where you have the logical arrangement of components and folders, and servers that get requests and respond to them at a distance, and provide persistence (i.e., Rails, Git, and Heroku).  No doubt we could recast that as some version of MVC, but perhaps at the risk of hiding as much as we reveal (and collapsing the map toward the male bias in the process, thereby taking a step backward before we begin).

We touch on all 3 in the Installfest, and with a modicum of added content and commentary, we could inject more useful understanding through the installfest process, and have students better identify what area(s) they want to focus on in their immediate learning.  It would also make the big picture much more readily grasped.  Again, this is in part my personal bias, because I am a big-picture person, and a visual thinker, and I can only learn well when I have a decent conceptual framework on which to hang what I am learning.  I also think that the big picture is missing broadly in IT training, and that my need to see and understand connections is one of the key characteristics that locates me toward the feminine end of the male distribution spectrum.

I think the 3 distinctions make it more straightforward for students with some existing technical knowledge to see where they need to extend themselves, and that they could fairly readily self-select groups that will focus on what will best serve their educational and career goals, as well as helping them have a better appreciation of the whole, and at least a rudimentary understanding of what the other players and components in the system are doing, and why they are needed.  We might find it easier to organize Saturday's groups by these verticals, with fewer levels, and still offer the basic suggestotron as an overview to those who want the whirlwind tour of the whole.  It is probably much easier to tolerate a wider range of expertise in the room when the vertical topic is narrowed.  Newbs benefit more directly from the pre-existing understanding around them, and the teacher has more help in providing examples and analogies. The teacher can hit some more advanced material while the newbs are digesting the basics just handed to them, so everyone gets value.

Having just started my first paid RoR gig, and finally having a complete enough install that I believe I can fork and update some of the Railsbridge docs, I'll be able to make some of these points better by example, by updating some of the training materials.  In the meantime, I hope that at least part of this rant provides some useful input to the overall conversation.  I hope that despite the strongly political overtones, you were able to glean something useful here.  Thanks for listening.

To close on a gender-neutral note, here's a zen riddle:  How many times do you have to repeat the DRY principle before it sticks?

Doug

[Alex Chaffee]

On Sat, Jul 7, 2012 at 2:39 PM, Doug May <intu...@gmail.com> wrote:
> How many times do you have to repeat the DRY principle before it sticks?

I'm sorry. Could you please repeat the question?

- A

[Elle]

Is there any interest in a workshop focusing on Agile development techniques (TDD, user stories, pair programming, refactoring,..)?

I recently brought this up to Bosco for SFRuby in general, and then recently realized that perhaps this could have the potential to be a Railsbridge modular workshop?

I'd also be super interested in helping out with the curriculum for a shell/command line workshop.  (I used to be a UNIX sys admin before becoming a web programmer, and actually did a lightning talk at OSCON on basic UNIX tools for the web developer a few years back.)

[Mary Jenn]

Elle, 

Bill DePhillips and I were talking about doing a pairing workshop based on coderetreat.com. This reminds me we need to plan it now that I have more time. :) Wanna help? 

--
You received this message because you are subscribed to the Google Groups "RailsBridge Workshops" group.

To view this discussion on the web visit https://groups.google.com/d/msg/railsbridge-workshops/-/AUBTADbg8QIJ.

[Daniela Wellisz]

I for one really miss having tdd in the curriculum and feel like its an important skill. I'd be interested

Sent from my iPhone

--

[Faun Winter]

I'm so down.

Faun

On Oct 2, 2012, at 1:26 PM, Elle <elle....@gmail.com> wrote:

[Carina C. Zona]

Elle, thanks for suggesting/offering this!

Heck yeah. _Especially to TDD/refactoring._

A workshop on shell/CLI would be valuable. People new to the
commandline find it so scary/overwhelming. Which makes me wonder if
they'd be more eager to sign on for a 2-3 hour evening course than for
a full Saturday. What if RailsBridge offered an Intro to CLI night,
with the secondary agenda being to get them excited about doing a full
day dive in?

A number of students have mentioned that they'd wished their workshop
would've spent on Saturday explaining what the heck she/he was doing
on Friday. It's all a black box to them.

A CLI workshop (of any length) could be opportunity to kill two birds
with one stone by giving that kind of walkthrough (yay, repurposing
existing curricular materials!) for alumni (specifically; so the CLI
workshop doesn't devolve into an Installfest) and expanding into more
commands/concepts.

[Alex Chaffee]

On Wed, Oct 3, 2012 at 12:41 AM, Carina C. Zona <ccz...@gmail.com> wrote:
> Heck yeah. _Especially to TDD/refactoring._

https://github.com/alexch/test-driven/blob/master/test-driven.deck.md
https://raw.github.com/alexch/test-driven/master/make-it-green.png

soon to be on http://codelikethis.com

[Alex Chaffee]

On Wed, Oct 3, 2012 at 12:41 AM, Carina C. Zona <ccz...@gmail.com> wrote:

> A workshop on shell/CLI would be valuable.

https://github.com/railsbridge/docs/blob/master/sites/workshop/foundational_skills.deck.md

[Elle Yoko Suzuki]

A workshop on shell/CLI would be valuable. People new to the
commandline find it so scary/overwhelming. Which makes me wonder if
they'd be more eager to sign on for a 2-3 hour evening course than for
a full Saturday.

+1 !

 

[Doug May]

Yes, to CLI evening event, and a workshop on TDD/refactoring.

I still think we should have a backlog of internal upgrades to our
sites and tools that we use as working examples. I always struggle
with phony or contrived project examples, because there's no real
client to imagine or connect with.

[Mary Jenn]

+ 2! 

There is a lot of time spent in installfest getting some people comfortable with command line. An evening into to it would be perfect! 

--
You received this message because you are subscribed to the Google Groups "RailsBridge Workshops" group.