1. mount --bind : 10:51
2. CS education weblog : 13:41
By the way, the blog has some nice diagrams. I wonder how...
3. Blogging as an educator : 13:47
I haven't ever blogged as an educator, I must admit. This is, I think, a failing in my blogging practice. In particular, I really like the idea of weblogging about my practice in a place where my students can see what I'm thinking. This is because I (Matt) personally think there are too many guessing games between me as an instructor and my students. If they can see where I think the educational process is breaking down, and why, they can actually take part in the solution. Or, what might be even cooler, would be...
I find that I blog a lot as an educator. I write for myself because I need to reflect on each day - to note what worked and what I can improve on. I write for other teachers so that they can check out resources I've come across, avoid whatever mistakes I made, learn from whatever insights I had, and maybe even share their own thoughts. I write for my students so that they know I value their feedback and that I'm looking for ways to make learning more fun, interesting and effective. They can see my thoughts on what worked and what didn't.
I've received a lot of positive feedback. Some people have suggested websites to visit. Other people have asked questions that spawned new blog entries. Yet others have shared what they learned. I have learned so much from the people who've written in with their comments, and I look forward to learning from you.
4. CS education dissertations : 14:17
Attrition rates in the computer science major are quite high. Many students who struggle through the first few courses ultimately drop out of the major when the coursework becomes too complex, mostly because of the increased amount of logic and abstraction that the coursework requires.
This study compared content comprehension, logical reasoning ability, and attendance in two groups of second-semester university computer science students. In a quasi-experimental, pretest/posttest, control-group design, the control group (n=25) received instruction in a traditional lecture/discussion learning environment three days a week for nine weeks. The treatment group (n=24) met in a cooperative learning environment for the same number of hours as the control group. Each group was given the pretest and posttest for the Burton Comprehension Instrument (BCI) and a pretest and posttest for the Propositional Logic Test (PLT) to measure levels of content comprehension and logical reasoning ability. A head-count was taken daily to determine if the cooperative learning environment might promote better attendance.
The null hypotheses investigated in this study were. (1) There will be no difference between the cooperative learning and control groups in concept comprehension. (2) There will be no difference between the cooperative learning and control groups in the improvement of logical thinking skills. (3) There will be no difference between the cooperative learning and control groups in attendance. The collected data were analyzed by the use of Analysis of Covariance (ANCOVA), Multivariate Analysis of Variance (MANOVA) with Repeated Measures, and one-way ANOVA.
The results of the analysis revealed no difference between the cooperative learning and lecture groups in the areas of content comprehension or logical reasoning ability. However, the cooperative learning group did have significantly better attendance (p<.03).
Further research is recommended in the use of cooperative learning in university-level computer science courses. Of special interest is the use of cooperative learning tactics in large lecture-based courses and the effect of cooperative learning on gender equity in computer science.
Copyright (c) 1997 by Roger Louis Priebe. Presentation of this material by the Department of Computer Sciences at the University of Texas at Austin was made possible under a limited license grant from the author, who has retained all copyrights in the works.
I should look into doing research like this even now.
5. Naive tools for studying compilation history : 14:31
We are interested in assessing the impact of pedagogic programming environments in the teaching of programming to novices. As part of this work, we are interested in studying student compilation histories--a sequence of snapshots of a student's program taken each time they compile. Much like a sequence of moving pictures imply motion, we believe there is merit in studying the evolution of a student's program. A compilation history represents one aspect of a solution trajectory, a sequence of observable (external) and mental (internal) states that define a student's path from problem start to completion.
The 14-page paper raises the question about the delta between compiles - what students change in between compilations. They use source substitution to ignore minor changes in variable naming, and they try to look at structural and type changes. They hope to be able to use this to analyze how students rewrite programs.
- How can one measure the growing complexity of a program solution?
- How can one record the kind of bugs students encounter?
- Maybe it would be nice to record not only compilation bugs but also
I'd love to hear about any questions, comments, suggestions or links that you might have. Your comments will not be posted on this website immediately, but will be e-mailed to me first. You can use this form to get in touch with me, or e-mail me at firstname.lastname@example.org .