search

ga-wdi-boston / rails-api-single-resource

code in demo/code-along/lab in rails-api series
Other
0 stars 93 forks source link

ga-wdi-boston/rails-api-single-resource #1

Open RealWeeks opened 8 years ago

RealWeeks commented 8 years ago

Actual 8. Monday full day after lunch, Tuesday all day plus 10 minutes into 1-1 time.

RealWeeks commented 8 years ago

This could be better split into an overview/MVC/this-is-rails and the actual demo/code-along/lab.

payne-chris-r commented 8 years ago

Actual wow. Such 8. I took wayyy too long during the demo and checked for understanding a lot along the way. I think the meat of this lesson should really be the code-along and lab, and we should try to be a little more speedy during the demo.

jrhorn424 commented 7 years ago

360 minutes, 7.2 units. This went slower than anticipated, even though we removed much of the introductory material that was repeated between this talk and the previous rails-api. In my estimation, I lost about two units by narrating both demos and code-alongs. This may be a problem for our highly-interactive lessons. It might also be a good thing. I did not renegotiate lab time, which I could have cut to keep this on target.

I think this can probably be done in a comfortable 6 units. My strategy next time would be to do demo, code-along, lab sequence for the first two actions index, get, and then go to demo, lab for the remaining actions. In those labs, squads would complete the same action twice, once for the code-along API (even though it's a lab) and again for the lab API.

MicFin commented 7 years ago

300 minutes 6 actual day 1: 1130-1pm, lunch, 2-3pm day 2: 9:30-12pm

This is a great lesson to deliver because it is so feature based and interactive. I wrote the name of the 3 APIs that they would be using on the board. Then I explained how the sequence would go (demo, code along, lab with an API for each). I then have them set up each API one at a time. I change the color of the terminal for each API window. Then, I draw the terminal windows on the whiteboard under the API name, I write the color, and then I write the name of the resource. I highly encourage all developers to follow the same color pattern. We had almost no confusion bouncing between the 3 terminals using this strategy.

As suggested, I did the first 3 actions (index, show, destroy) as demo, code along, lab. The 4th action (update) as a code along and lab, skipped demo. And then the 5th action (create) I had them do as a lab, skipped demo and code along. I gave them hints for the if statements in update and create as well as for the http status symbols.

The repositories for the 3 labs do not have all of the required training branch commits, solution branch commit, or curl scripts so I used their lab time to create the curl script on the fly. We have noted to update those repositories with those files.