User:Srebelsky

Links

• Proposal to work on exercises for an Ushahidi-enriched CS2
• Work Log for the Ushahidi-enriched CS2

Samuel A. Rebelsky

Samuel A. Rebelsky, known to most of his students as SamR (alternately pronounced "Sam-Are" and "Sammer"), is one of the POSSE 2013-06 Participants. When he's not in the POSSE, SamR is a Professor in the Department of Computer Science at Grinnell College, which is located in the middle of nowhere Iowa. Like most faculty at small colleges like Grinnell, SamR teaches a wide variety of courses in the undergraduate CS curriculum and beyond, although his favorite courses to teach are those in the introductory sequence, when he has an opportunity to expose students to the wonders of algorithmic problem solving, and the upper-level programming languages course, where he can challenge students to think in new ways. SamR has also been known to teach a seminar for incoming students on Intellectual Property, the College's introductory stats course, and even a course in the Evolution of Technology.

SamR's efforts in open source tend to focus on media applications, particularly GIMP (the GNU Image Manipulation Program), an open-source alternative to Photoshop, and Inkscape, an open-source alternate to Adobe Illustrator. SamR's work emphasizes ways to support interactive scripting in this applications and opportunities to use such scripting to motivate people to learn new modes of problem solving.

In his spare time, SamR likes to do things with this three sons and his wife. Sometimes that means camping. More often, it means playing board or card games.

You can reach SamR at an email address available via reCAPTCHA™ Mailhide - not only will you get to send him mail, you can help OCR books!

You can laugh at how out-of-date SamR's Web site is.

p.s. Although SamR refers to himself in the third person in this rambling section, traditionally he likes to refer to himself in the first person, singular.

Course Planning, Phase 1

I'll admit to some mixed feelings about all of this. I see lots of recommendations for non-coding related contributions. However, in the end, I really do want my students to think about program design and development. Things are complicated by the fact that I'm focusing primarily on introductory-level classes; a colleague is developing a new model for our software design course and will be responsible for it for the next few years. Things are also complicated by my desire to focus on one or two FOSS projects that I can come to know well. So, my initial feeling is that I will get my students used to tools associated with FOSS projects, but have them work on the periphery of FOSS projects, or perhaps on their own FOSS Projects. That said, here are a few possibilites.

CS1, Taught in Scheme/Racket

The GIMP can be scripted in Scheme, most frequently via the built-in "Script-Fu" interface. Students could develop simple script-fu plug-ins and contribute them to a repository. Doing so would get students used to (a) thinking about being part of a community; (b) using a source code management system, such as github; (c) considering intellectual property and licensing for their work (I hope that they will choose appropriate FOSS licenses, but I am likely to leave it up to them). Ideally, this would also add a "continuity of practice" element to the course - students in subsequent semesters could work with the plug-ins written by students in previous semesters.

While GIMP is a leading FOSS project, at first glance it does not seem to be a Humanitarian software. However, I might argue that manipulating images is something that everyone who builds things for the Web has to do, and providing a reasonable alternative to Photoshop is therefore a humanitarian activity.

I will note that my past experiences having students work with the GIMP team have been mixed. Some early questions to the listserv were met with a reaction of "Oh, we don't care about Scheme any more. We've moved on to Python." I also find the GIMP's current Scheme implementation a bit messy and unfriendly. That said, I still think there are ways to approach the project.

CS2 (OOP, Algorithms, ADTs), Taught in Java

This course is already a bit packed, and I really do expect students to focus on the design and analysis of algorithms, abstract data types, and data structures. However, I think that fitting in a two-week "design your own small project" component could be quite useful. I'm exploring the scope of projects possible, particularly if I give the students some infrastructure (or a connection to an open-source project that they can use). I've set up an appointment with our director of community outreach to identify some likely "clients" for the students. As in the CS1 course, I see an opportunity to set up a community of small projects that can be revisited in subsequent semesters.

While building your own HFOSS software doesn't quite fit in the model that we've been looking at, I do see that it is #10 in the Berkshire Linux Group's Guide to Contributing to FOSS.

As I think about this project further, I can see some possibilities of leveraging the Ushahidi or SwiftRiver Java API. That would give students the opportunity to contribute to a FOSS project by finding appropriate applications.

As a side note, I'm already looking at ways to incorporate using git from day one in the class.

Unknown Course

As I've worked with some GIMP code, I've found that it is rarely documented, at least at the procedure level. I can see some benefit to having students read and attempt to document that code.

Choosing a FOSS Project

Note that I still need to do a more formal evaluation.

As the preliminary course planning suggests, I have two open-source projects in mind, one explicitly humanitarian, one implicitly so. The projects are Ushahidi/SwiftRiver and GIMP. I made my assessments based on variants of criteria I chose for part 1 of the Open Source field trip.

Do I find the subject matter interesting?

Ushahidi/SwiftRiver - I've been thinking a lot about data visualization, particularly of big data and what we might call social network data. In fact, as I was looking at a new design for our CS2 course, I was considering ways to incorporate these topics.

GIMP - While I prefer to make physical art, rather than digital art, I do use GIMP a lot. And I really like the results I get when I script GIMP.

Can I envision assignments that will motivate students?

Ushahidi/SwiftRiver - It looks like we can do some mobile apps, which I do expect to motivate students. I also think that data analysis will be somewhat motivational.

GIMP - I've already seen that media computation motivates students. I'm hoping that exploring GIMP in new ways will motivate students.

Does it match the language and ideas I hope to promote in the course?

Ushahidi/SwiftRiver - At first I was concerned that the focus on PHP in these products would make them unsuitable for my CS2 course, which uses Java (and will continue to use Java). But I see that there are some Java APIs, and I expect that the Java APIs will make it easier for us to write small projects. It may also help students get used to reading and using libraries.

GIMP - ScriptFu is an awful implementation of Scheme, but it's an implementation.

Can I contribute?

Ushahidi/SwiftRiver - I don't know, but I'd like to try.

GIMP - GIMP clearly needs DBus support and a better Scheme implementation (even if they don't believe the latter). I have sufficient knowledge of GIMP's PDB and internals, of DBus, and of PLT Scheme that I can probably provide those things (working with my research students, of course).

WIll I learn something?

Certainly!

Course Planning, Phase 2

CS1 Activity: Contribute a Plug-In to GIMP

Students will write a small plug-in for the GIMP. The plug-in might serve as a filter (manipulating the image) or as an image-builder (e.g., creating stylized text). Students will work in teams of two or three.

1. Identify the type of activity. Three-part activity. Part one is a lab exercise that demonstrates how they write a plug-in and how they submit it to a repository. Part two is a short reading/reflection on open-source (and not so open-source) licenses. Part three is a homework assignment in which they build a more extensive plug-in and submit it.
2. Identify some possible learning outcomes that should be fulfilled with the activities/task. Using a repository. Being part of a community. Understanding open-source licenses. Writing code that others will use.
3. Describe any pre-requisite knowledge needed to complete the activity. This does not need to be a complete list.
   • GIMP PDB functions. Already covered in the course.
   • Most of the remaining issues (writing plug-ins, using a repository, etc.) are covered in the lab exercise.
4. Estimate the time required for instructor prep, for student completion and elapsed calendar time. Are you going to have to synchronize your activity with the community or can the activity/topic be covered independent of the HFOSS community schedule.
   • Instructor time: Writing infrastructure: Basic infrastructure 8-12 hours, Full infrastructure (add a RacketFu plug-in to GIMP, add functions to ease student use) 2-4 weeks.
   • Instructor time: Writing sample plug-ins: 8-12 hours
   • Instructor time: Writing laboratory: 3 hours
   • Instructor time: Writing long assignment: 4 hours
   • Instructor time: Writing short assignment on licenses: 2 hours
   • Instructor time: Writing grading rubric: 2 hours
   • Student time: Laboratory: 1 hour, in class
   • Student time: Homework: 4 hours
   • Student time: Reading about licenses: 1 hour
   • Does not require synchronization with the HFOSS community, except maybe for assessment. I think I'll try doing it for a year or two before trying to involve the community.
5. Think about possible input required from the HFOSS community. How much input is required and what kind? I can see some benefits from having the HFOSS community reflect on the quality of the plug-ins (code or utility). I'm not sure that I can get a panel of reviewers, though. Over the long term, I'd hope that a growing repository might create enough of its own community.
6. If the result of the activity is contributed back to the HFOSS project, describe the contribution and its usefulness. I would hope that anything that extends the GIMP will make it more attractive, even if only marginally so. Having students build a small page that illustrates the plug-in could also serve as a form of advertisement (and might even give me an excuse to include some form of 'blogging in the course).
7. Describe the assessment/grading approach - What will the basis for grading be? Will this be a team activity or individual? Is there a role for the HFOSS community in helping assess student work? For instance, must the work be committed or otherwise accepted by the community?
   • The in-class lab will not be graded.
   • The short assignment in reading about licenses will likely be short answers that I can grade on a plus/check/minus scale.
   • The longer, group, assignment will likely require two rubrics - one for the aesthetic or utility value of the plug-in and one for the code. For the code, my focus will be efficiency and elegance. For the aesthetics/utility, I may rely on an external evaluator, whether it is someone from the community or simply a member of our studio art faculty.
8. List any questions or concerns that you have about the activity/task.
   • What do I give up from the class to fit in this project?
   • Am I putting too much in the assignment?
   • Any suggestions for novel and simple plug-ins?
   • Should I have students do peer assessment of these projects?
   • How should I deal with the "provide documentation" issue? Maybe just a README and a sample image? Should I then write a small program to convert those into a Web page?
   • What follow-on activities should I think about providing in future years?
   • What repository should I use? (github is my current repository of choice, but we do run a Subversion server in the department and some projects I work with use Bazaar)
   • What model should I use? Is each plug-in a separate project, or is there a single repository that contains all of the plug-ins that students have developed?
   • If I do plug-ins as separate projects, how do I manage them as a collection? One possibility is to have a shared "Table of Contents" project.
9. List any stumbling blocks or barriers to carrying out the activity/task.
   • If I teach repositories in this class, what happens to our other classes that teach git, particularly since students take different paths through the major?
   • What if students object to making their work publicly available? Is this a potential FERPA violation? I guess I'll need to provide an alternative.
   • If the repository is public, should I worry about students copying? (I tend to feel that professional programmers should be skilled in code reuse, but perhaps that's just me.)

CS2 Activity: Develop a Small Application using Ushahidi or SwiftRiver

Students will meet with a local (or alumni) client and develop a small data gathering, analysis, and/or visualization application. Students will work in teams of two or three.

1. Identify the type of activity. Two-week, group project.
2. Identify some possible learning outcomes that should be fulfilled with the activities/task. Working with a client. Using the theoretical knowledge gained about algorithms and data structures to more practical use. Working with a library.
3. Describe any pre-requisite knowledge needed to complete the activity. This does not need to be a complete list.
   • Using the API
   • Programming phone apps (perhaps)
   • Working with a repository
4. Estimate the time required for instructor prep, for student completion and elapsed calendar time. Are you going to have to synchronize your activity with the community or can the activity/topic be covered independent of the HFOSS community schedule.
   • Instructor: Designing (and implementing?) a reasonable set of sample project: 25-40 hours
   • Instructor: Setting up a repository for the projects: 2 hours
   • Instructor: Writing the assignment: 3 hours
   • Instructor: Writing the grading rubric: 3 hours
   • Instructor: Identifying potential local clients: 10 hours (prep time for meeting with outreach coordinator, meeting with outreach coordinator, meeting with potential clients, etc.)
   • Student: Meeting with client: 4 hours (preliminary meeting, demo meeting, meeting for feedback)
   • Student: Software development: 15 hours
   • Student: In-class lightning presentation: 5 minutes
5. Think about possible input required from the HFOSS community. How much input is required and what kind? Perhaps advice. I'm not sure what else.
6. If the result of the activity is contributed back to the HFOSS project, describe the contribution and its usefulness. Not sure. Perhaps simply showing new applications for the software will be useful.
7. Describe the assessment/grading approach - What will the basis for grading be? Will this be a team activity or individual? Is there a role for the HFOSS community in helping assess student work? For instance, must the work be committed or otherwise accepted by the community? Joint assessment: Some on
8. List any questions or concerns that you have about the activity/task.
   • Is it possible to come up with projects of this size?
   • What are some good small projects of this size?
   • Some of the questions above, particularly in terms of how I organize the collection of projects.
9. List any stumbling blocks or barriers to carrying out the activity/task.
   • May not be possible to have projects this small. I'll figure that out by writing some of my own.
   • Making sure that algorithms, ADTs, and data structures get involved
   • It will take me awhile to learn how to use the system well
   • Thinking creatively about example uses may be hard.
   • Java seems secondary in Ushahidi and SwiftRiver. How much of an issue will that be?
   • Some of the stumbling blocks I mentioned above, such as privacy of student work and potential for copying.

Reflection: Building a Course Community

Warning! Rambling thoughts in progress.

Both of my projects emphasize not just contributing to a FOSS project, but also building a community of folks who do a certain kind of contribution. Over the long term, I hope that this allows students to see what past students have done and to allow alumni (of the course or the College) have the opportunity to provide feedback to current students. Will that happen? Who knows.

So let's think about technical matters. As I've noted in my questions (or perhaps barriers), there's a question of how to arrange the various contributions. I could treat everything as a single repository. Students would then fork that repository, add their own subproject, and then send a pull request. Alternately, I could let each student project be its own repository. In that case, the best way to keep track of it all seems to be to have a "Table of Contents" repository. I'm leaning toward the second model.

Hmmm ... what goes in the table of contents besides the list of projects and short descriptions? Could I put reviewers in there, too?

Checklist of Activities

A way for me to keep track of what I've done and what I'm supposed to do before heading off to Philly, taken from the list of Stage 1 Activities

Part A

1. Intro to FOSS (Activity) - Done
2. Teaching Open Source (Activity) - Done
3. Intro to Wiki (Activity) - Overdone - Beyond the basic work, I added this checklist, updated various pages on the Wiki (fixed links, reordered names), and more.
4. Intro to IRC (Activity) - Done
5. IRC Meeting 1 - Done
6. Intro to FOSS Project Anatomy (Activity) - Forthcoming - A quick check suggests that while I've already met the learning objectives from past experience, it's still worth delving into the particular projects suggested. I'll do this second of the remaining three tasks.

Part B

1. FOSS Field Trip (Activity) - Done - Part 1, Part 2. Ohloh was my favorite part. It's nice to learn something new.
2. Blogging Activity - Overdone - Posted some random things because I wasn't planning to write about my field trip, then wrote about the field trip anyway. Then realized there was a part 2.
3. FOSS in Courses 1 (Instructors) - Done - See above.
4. Evaluate a Project (Activity) - Forthcoming - Looks like a very useful, but also very time consuming if I do it right. I'll do this third of the three remaining tasks, but might look at the SIGCSE paper in the mean time.
5. 'Project Survey - Filled out twice. Whee!

Part C

1. IRC Meeting - Thursday a.m.
2. Intro to Bug Trackers (Activity) - Forthcoming - Looks very useful. I don't do enough about bug tracking with my own software (other than text files). Since I use github, I should probably explore github's, which they call "Issue Tracking". I'll do the activity first of the three remaining ones and will try not to get too distracted playing with github's issue tracker.
3. Intro to GitHub (Activity) - Done - Well, waiting for Heidi to accept my pull request
4. FOSS in Courses 2 (Instructors) - Done - See above. Could still use some updating.