User talk:Chris Tyler/OPS235 Updates

msaul:

  In the future, I will just add content into this discussion area, but perhaps create a section in "user page" to preview my editing suggestions
  for feedback and confirmation to proceed by fellow OPS235 instructors. I want to start on this asap...

• I like lab #1! Learning these manual override concepts are essential! Don't throw out the baby with the bathwater! My previous students loved the ability to use these tools to help "get them out of a situation". I wanted to make a YouTube video on practical use of skills used in lab #1...
  
  
• I'm OK with ditching written test #2 (but then how does this affect mark weighting?)
  
  
• I think it could work if we just took one assignment and split it into 2 sections. I got idea from Chris Jankul when he was teaching OPS435. He had two stages (the second built upon the other). In this way, marking doesn't have to be "massive". I believe that students gain the most experience from performing the labs any-ways...
  
  
• Which official version of Fedora are we using? (Fedora 16 live CD, and Fedora 16 DVD)? Need confirmation, so I can test-out the labs.
  
  

• I also want to create some YouTube videos placed prior to the "Review Questions" section for "Connecting the Dots" so to speak. These would be short videos to provide reasons why they are using these tools. Especially LAB1!! Hint, Hint, (i.e. I don't want students to lose lab1!!!!)
  
  
• Which lab (i.e. in relation to "fall lab line-up") would be affected by SysVInit -> Systemd ?
  
  
• I am in STRONG AGREEMENT with "re-factoring" wiki labs and course notes content. I strongly believe in "forward" and "backward" linkages as well. Let's take a journey down a river (hopefully no waterfalls). In addition to preamble about what student will be performing, it would be nice to "tie-in" the previous lab to allow a "flow" ("end-to-end"). This would relate to a "forward linkage" of what students can expect in the next lab. I strongly believe that well designed courses provide a "flow". This is NOT to indicate "spoon-feeding", but a nice "fit" in a practical container (yet not too constrained). I like the steps listed in the "re-alignment".
  
  

As a "follow-up" to this "flow":

• For debugging, I would stress common problems that students have made in the past, and a general suggestion that the student take to remedy the situation. Careful "check-points" should be indicated (perhaps with a "check-point icon" (a good "gaming" connection) to have students CAREFULLY confirm their contents with the suggested output, and then direct them to debugging. I would NOT recommend YouTube videos for fixing the problem (that should still be "hands-on" and text-based), but videos for confirmation checks... and call over instructor for major difficulties...
  
  

The concept of a "check-point" works well with the "graphics" discussion at the bottom of the "user page". Many students are "gamers" and "visually stimulated". I agree to revamp the wiki and reduce the "text overload". Don't get me wrong - students need to research to learn, but learning now comes in different flavours.

I really like this course! I totally get the importance of "learning how to learn". On the other hand, just posting up links to content may "turn-off" students. I recalled, that I created some "slide-shows" for students to know where to focus on the important things. I would think this is the challenge to engage the students to "learn how to learn", but not get "overloaded" in too many details... On the other hand, alternative media can be used to foster this. I recall Chris that you once pushed for students to use graphical editor to break that "older concept of traditional cli editor. I think the same applies for learning contents. In the future, more emphasis on demonstrations. For example, we could demonstrate using gtk-recordmydekstop, upload and link desktop recording to a YouTube of what the output from commands should be. Perhaps, this can reduce the "text-overflow". I did find that using YouTube greatly reduced the size of the "Sample Run" specifications of the OPS435 course immensely!

• I'm a big believer that if students are left to complete those "review questions" at the end of the lab, they won't. Why not change the perspective a little? We seem to be very good at programming the practical test results, can't we program mark the labs? I'm assuming that you guys may have thought of this already, but probably a BIG TASK (I understand and respect this). But if can be done, then I would think this would reduce a lot of checking from the instructor to "sign-off" at the end of the lab. Have it done by having instructor verify from automated lab submission. Perhaps shift of focus on "instructor checking" could be done at the check-points. I'm getting the impression that if we are going to go in for "adjustments", let's make a few more, and really make a great product! I'm willing to completely test, write (i.e. total rewrite labs - YIKES FOR ME!!, but I'm geared up for it!!!), as long as someone wants to automate the lab submission, and perhaps as a bow on top, build a quiz blank with questions asking random questions with immediate feedback.
  
  The only problem would be that students don't get their lab sheets checked manually by instructor, but they these marks would be updated at the end of the week my instructor, and should know where they stand...
  
  

Automation (via shell scripting) helped a great deal in OPS435 to manage tracking online tutorials and labs, perhaps OPS235 would benefit from that as well. Sure, steady end of week commitment for a couple of hours, but most likely well worth it, and relates to the "automation" of administrative tasks (i.e. "lead by example")...

Tell me, and I forget, show me and I will watch, involve me and I will learn...

No pain, No gain. So let's have No fear. Time to "rock and roll"...

My passionate $0.02...