Nifty Assignments from SIGCSE

Posted on March 24, 2015 by Dave Reed

I got back last week from another great SIGCSE Conference. If you don’t know about it, SIGCSE is the annual conference for the ACM Special Interest Group on Computer Science Education. While the conference has traditionally focused on higher-ed CS, it has been putting greater emphasis on K-12 topics in recent years, including a special two-day registration rate for K-12 teachers.

For many attendees, myself included, the highlight of the conference is the Nifty Assignments panel, which is run each year by Nick Parlante and Julie Zelenski. This panel presents creative, classroom-tested assignments, along with resources to help teachers adapt the assignments to their courses. These assignments can range from the simple and creative, to the complex and mind-boggling. Personally, I have been inspired by a number of the nifty assignments over the years, and have integrated variants of nifty assignments in my courses. This year, two of the nifty assignments particularly appealled to me, due to their “niftiness” and relative simplicity. Peter-Michael Osera presented the Speed Reader assignment, which had students write a program (in Python) for displaying words in succession and measuring a person’s reading rate. Stuart Reges presented the GeoLocator assignment, which had students write a program (in Java) that utilized the Google Map API to locate and calculate the distances between landmarks. Both assignments were farily simple to understand, could be easily ported to different languages, and would be motivational to many students.

All of the Nifty Assignments from past years can be found online at http://nifty.stanford.edu. Check them out if you are looking for inspiration on creating or adapting your own “nifty” assignments.

Dave Reed
College Faculty Representative, Chair-elect

Doing computing means embracing failure

Posted on March 20, 2015 by Fred Martin

We always tell ourselves and our students to take risks. But taking risks means that we will fail at things. And generally, none of us like to fail.

Think about what it’s like to write code. Most of the time, the code is broken, and you’re failing.

This semester, I’m watching my students struggle with assignments in our sophomore-level object-orientation in C++ programming class.

We’re working through a series of two-week projects. The projects are pretty fun:

using recursion to draw Sierpinksi’s triangle (and creating a derived object that’s “drawable” using a gaming graphics library)

building a pseudo-random number generator using a linear feedback shift register, and then using this to encode (and decode) an image

simulating the movements of planets in the solar system (using Newton’s fundamental laws of gravity and acceleration)

(There are more—this material is from Princeton’s COS 126 course.)

From the students’ point of view, there are a lot of steps to get to a working system:

First, to understand the basic problem. What data structures will we use? How does the algorithm we’ll use work? How will it all be organized into objects?

Next, starting to write code. What goes in the header file? What goes in the source file? Why is there this separation anyway?

OK, I have some code. Let’s try compiling it. Oh great, tons of compile errors. Of course.

OK now it compiles. Does it work? Not a chance.

Well, time to debug… where do I start? Probably printing some stuff out… how about seeing that I can read the command line arguments properly?

And so on.

Probably the most challenging part is at the very beginning—making sense of the task itself, and how it’s to be accomplished.

I encourage my students to do their work in baby steps. Just write a few lines of code, compile it, and make sure it works.

Only add more code after you have a little bit of code working.

Compile and test before moving on. Make sure you are going from a working thing to the next working thing.

But even with this strategy, as soon as a bit of code is working, the next step is to add more code, which means breaking it again!

Most of the time, things are broken.

It takes a high tolerance for failure like this.

I do believe that we learn best when we encounter challenges.

And the beauty of our practice is that we’re so readily able to get feedback on the quality of our ideas. Since our ideas are expressed in machine-executable form, we can debug them.

But it is hard, emotionally demanding work, and it’s important that we recognize how much effort our students put in to accomplish their successes.

Terry Dash, a CS educator in Massachusetts, just described to me a teaching experience she had teaching Scratch to middle school students. Midway through the school year, her student Erica cried out during class, “Now I get it! The more it breaks, the more fun it is!”

That’s the spirit!

yours respectfully,
Fred Martin
CSTA University Representative

CSTA Funding Committee

Posted on March 18, 2015 by Fred Martin

Another of CSTA’s standing committees is the Funding Committee. Our charter is to support the initiatives of the CSTA, and help ensure the sustainability of our organization.

We keep an eye out for federal and other grant opportunities, and then we bring together groups of CSTA people and others to hash out the ideas and ultimately submit proposals.

A lot of the practical fund-raising work is also carried out in a continuous process by Lissa Clayborn, our acting executive director.

The Funding Committee is led by Fred Martin (chair) and Dave Reed (co-chair).

If you know of a grant opportunity that’s a fit for the CSTA, please let us know!

Yours,
Fred Martin
University Representative

Governance Committee

Posted on March 12, 2015 by Myra Deister

Governance Committee

The Governance Committee reviews how the board is functioning and when necessary recommends to the board revisions to the Policy and Procedure Manual as well as the By-Laws. Both documents are posted on the CSTA website. These changes could include revisions of the roles and responsibilities of the board members, board committees, conflict of interest procedures, and procedures for nomination, selection and removal of board members. The Governance Committee is charged with ensuring the board is governing the organization effectively and efficiently.

Currently, the Governance Committee is recommending to the board members a Conflict of Interest Policy for the CSTA Board members, one for CSALT members and another for Chapter Leadership. It will be put to a vote at the next board meeting. Recently, the Governance Committee has recommended a Code of Conduct for attendees at CSTA Conferences to assure our members a safe and welcoming conference experience.

This committee is comprised of two members: Myra Deister, chair and one member, Alfred Thompson.

Myra Deister, Governance Committee Chair and At-Large Representative

How Do You Help Struggling CS Students?

Posted on March 10, 2015 by Myra Deister

This question has plagued me for the last few years, but more so this school year. In order to offer computer science courses and to make the course open access, some students enroll in the courses that don’t fully understand what computer science is and may not have the prerequisite problem solving skills. They do know that they want an AP course.

There is no prerequisite computer science course for AP Computer Science at my campus. The students would not enroll in a prerequisite unless it was an honors or AP, and we don’t offer one that is. To ease the students into computer science, I use Alice3 at the beginning of the school year then move into programming turtles and then Media Comp Lessons that are in Exploring Wonderland by Dann, Cooper and Ericson. I have been successful with this approach the last few years until this year.

This year I have tried several new strategies. I began using paired programming so each student would have someone to turn to for help. I would be free to help the students that are really struggling. Additionally, I have assigned fewer labs to give the students more time to work out solutions together. I have also assigned scenarios similar to the labs for the students to construct pseudocode prior to writing the program. I select random student papers, project them and we discuss the student written pseudocode. I also have assigned videos to do some flipping of lessons and the students take Cornell Notes while viewing the videos. I am available at lunch and after school for additional help. The students are writing reflections at the end of each unit discussing a lab that they have completed.

Even with all of that, I have students that are so lost they are not completing labs and are scoring low on tests. This semester the counselling department has resurrected a course title, “Fundamental of Programming” and has transferred a few of the students into that class. I have altered the assignments and tests to better meet their needs.

As I work to make my computer science course more diverse, I know that I will need to include additional teaching strategies to help all students. On Wednesday, March 11, I will be participating in the CSTA K-8 Task Force Twitter Chat #CSK8 from 5-6 pm PDT about Pedagogy: How to teach CS to 5 – 14 year olds. I am looking forward to hearing what K – 8 teachers are doing and tweaking their ideas to use with the high school students. I am also attending the CSTA Conference in July. One session that interests me is “Teaching CS to Students with Learning Differences”.

I will be piloting a Computer Science Principles course next school year and offer it as an AP course the following school year. Adding CS Principles may encourage some students to enroll in that course rather than AP Computer Science to help build their confidence.

I am continuing to look for additional resources and strategies. If you have any suggestions, resources or strategies please post them.

Myra Deister
CSTA Board At-Large Representative

Out of Your Seat Comp Sci: Coding Using the Kinect

Posted on March 9, 2015 by admin

By: Doug Bergman, CSTA 2015 Annual Conference Presenter

One of our most successful and popular high school Computer Science classes is also one of our most challenging: Coding for the Kinect camera, where the students spend all semester working on a single project using the Microsoft Kinect. The Kinect API, using the C# language, allows students to collect and interpret 3D skeletal streaming data. Because of the nature of the technology, classes tend to be extremely collaborative and active. But what kinds of projects can the students do, after all they are only in high school, right? You’d be surprised– simulations, games, interactive activities, tutorials, analysis programs, and learning tools. The thought processes involved in moving from the standard keyboard/mouse 2D input forces students to think in 3D space and also to use gestures, motions, and positioning. Check out this presentation to find out more, but don’t expect to just sit back and watch—I am looking for volunteers in the audience to try out real student projects, and we’ll walk through the code together to see what this code looks like. We’ll even build a small program together to show how students can work through their logic of developing functioning code. Yes, your students not only CAN do this, they will LOVE it.

You can attend Doug’s session on Tuesday, July 14, 2015, plus more by registering on our conference page.

Teaching and PBL

Posted on March 5, 2015 by admin

By: Moslem Cherif, CSTA Member

As we know, learning is becoming something of a bore for students in our days. This problem gets bigger day after day, without intervention or mediation of anyone. The solution here, is to use a type of learning that can create motivation for students, and here we have the idea of PBL.

PBL (Problem Based Learning) is a method to motivate the students based on self- learning, knowing that our current methods can become a little lazy.

Giving a problem to solve, or a project to finish can motivate any student and give him/her the energy to search and to use their imaginations. This method fosters active learning, improved understanding and retention, and development of lifelong learning skills.

As with any method, PBL has limits and drawbacks. It can cause disruption when working on a team, and it may also complicate the evaluation.

Advocating the “Coolness” of CS

Posted on March 3, 2015 by Stephanie Hoeppner

Quick – what is one “cool thing” about computer science? Hopefully several thought flooded your brain and you probably had trouble deciding what one thing you would reply with. I would assume that would be the case with most CS Educators and supporters; however, what would your students say?

It is scheduling time at our high school and students are making decisions about what courses to take and why. When a student looks that the computer science offerings what comes to their minds? What message have you gotten out to the students? Do they think it is cool? Important? Necessary for future? Fun?

We send messages to all students in our classes and I think we need to be purposeful about those messages sometimes. Over the past month I have reiterated how cool computer science is in my programming class by promoting “there is no one right answer – you can solve problems how your brain works and thinks”. My programming class had an ah ha moment when we were working on a program and I showed a couple different ways it had been completed and that both ways worked. For my part I did mention that as you learned more there may be better solutions in term of speed, efficiency, etc. but that right now I just wanted them to solve problems how they saw them.

A couple days ago we were removing an object (a car) that got to the edge of the screen (a frogger simulation game). We discussed a removeObject method and how you would go about using it and they all were happy they could now remove the pile up occurring on the side of their screen. I stopped them though and said….there is another way of doing this – maybe better or maybe not – but it is how I saw the program for the first time. Then I began to explain I wouldn’t remove the cars. I would reset their location on the screen and reuse them as if they spawned on the other side. Because of that I also would not continually create new cars, instead I would create a set number and kept reusing them. I said that is how my brain envisioned the game the first time I saw the program. There were some nods of understanding and then I said “but that is the beauty of programming, I could do it that way and others could remove cars but we would all still have a working frogger style game.”

I think we need to remind students why CS is awesome, why we love CS, and I think it is important we share how we view solutions especially when they may not be the most common way. It makes other students more comfortable to solve something the way they see it. Then maybe they tell their friends “Computer Science is cool. I can solve problems the way my brain thinks.”

Teaching Writing is just like Teaching Computer Science

Posted on March 2, 2015 by Pat Phillips

We all know that writing is an important skill to develop in every classroom—including the computer science (CS) classroom. If our students can’t communicate their ideas, they don’t have a chance succeeding in or out of our classrooms.

And while as CS teachers we know the importance of teaching writing, we sometimes freeze with that deer-in-the-headlights look when thinking about actually TEACHING communication skills. Well, I’m here to tell you that you’re a natural! If you can teach computer programming, you can kids to write.

Thank you, Terry Freedman, for the elaboration of these ideas in the Tech & Learning article “How learning to code might improve writing skills” (http://www.techlearning.com/blogentry/8736).

Compare the strategies you use to teach CS to those required in writing.

Making a plan for writing is similar to creating a flow chart or storyboard.
Writing a clear precise sentence is like an explicit computer instruction.
Good grammar is just syntax in another language.
Well-ordered text is not much different than code that follows the algorithm.
Too many words can confuse the reader just like too many statements create spaghetti code.
Creative writing and programs require a mastery of vocabulary and commands.

See? I told you that you were a natural. Teach writing the way you teach programming and you’ll be fine.

Barriers to Pair Programming (and solutions!)

Posted on February 27, 2015 by Irene Lee

A hot topic at the New Mexico Computer Science for All (NM-CSforAll) wrap-up meeting held on January 3^rd, 2015 at the Santa Fe Institute was barriers to pair programming. NM-CSforAll has been actively promoting and preparing teachers to use of pair programming and peer instruction with our diverse student population that includes a high percentage of Hispanic and Native American students. Over the past two years we have repeatedly heard from participating teachers that these methods are not easy to implement so we set aside time to discuss the barriers teachers encountered and solutions suggested by fellow CS teachers. Here is what we learned:

In general, new CS teachers experienced difficulty supporting the wide range of skill levels among students in their CS class(es). Some students had prior experience in computing while others were totally new to computing. When using the pair programming methodology, sometimes the more experienced student did not want to switch out of the “driver” role. Suggestions to deal with this situation included:
1. Carefully constructing pairs taking into account the needs and dispositions of each student.
2. Avoid tracking students based on ability.
3. Monitoring to make sure students switch roles.
4. Reiterating benefits of pair programming often.
5. Practice occasional individual programming and reflect on the difficulties of working entirely alone.

Communication with fellow students can be difficult for students from different cultures. Suggested interventions included:
1. Providing students with pair programming prompts such as “what do you think we should do next?”
2. Showing videos that demonstrate how to “pair program” such as the one from Code.org. (See http://youtu.be/vgkahOzFH2Q)
3. Practicing and modeling pair programming frequently.

Students who come into the class already knowing other students are often unwilling to work with a student they do not know. Suggested solutions included:
1. Frequently switching the pairings.
2. Reiterating that pairs will be reassigned often, “it’s not forever.”
3. Providing students with opportunities for feedback on the pairing and the work produced by the pair.
4. Using a Gallery walk as an occasion for students to discuss their project with fellow students and find common interests and working styles. Sometimes this leads to new successful partnerships and pairings.

Thanks to the CS teachers who contributed to this discussion: Amanda Dunlap,

Alan Daugherty, Michael Steele, Julie Scott, Rowena Dolino, Melody Hagaman,

Joanna Stitt, Elvira Crockett, Barbara Teterycz, and AnnNet Delaney.

–Irene Lee

CSTA CT Task Force chair