User:Srebelsky

Revision as of 23:49, 29 May 2013

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 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 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. Two-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.
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 sample plug-ins: 8-12 hours
   • Instructor time: Writing laboratory: 3 hours
   • Instructor time: Writing long assignment: 3 hours
   • Instructor time: Writing short assignment on licenses: 2 hours
   • Student time: Laboratory: 1 hour
   • Student time: Homework: 4 hours
   • Student time: Reading about licenses: 1 hour
   • Does not require synchronization with the HFOSS community, except maybe for assessment.
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 to fit in this project?
   • Am I putting too much in the assignment?
   • How should I deal with the "provide a sample" issue? Maybe just a README and a sample image? Should I then write a small program to convert those into a Web page?
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?

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?
9. List any stumbling blocks or barriers to carrying out the activity/task.
   • May not be possible to have small projects. 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?

Activities

Checklist of activities completed (and not completed), taken from the list of Stage 1 Activities

Part A

1. Introduction to FOSS - Done
2. Join TOS - Done
3. Introduction to Wikis - Overdone - Beyond the basic work, I added this checklist, updated various pages on the Wiki (fixed links, reordered names), and more.
4. Introduction to IRC - Done
5. IRC Meeting -Done
6. Anatomy of a FOSS Project - Forthcoming

Part B

1. FOSS Field Trip - Half Done - (Didn't see part 2; Will do that later.)
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.
3. FOSS in Courses Planning 1 - Done
4. Project Evaluation Activity - Forthcoming
5. 'Project Survey - Filled out twice. Whee!

Part C

1. IRC Meeting - Thursday a.m.
2. Bug-Tracker Activity - Forthcoming
3. Source Code Management/Control Activity - Done - Well, waiting for Heidi to accept my pull request
4. FOSS in Courses Planning 2 - Done - But could still use some updating.