User:SRebelsky

Revision as of 22:02, 29 May 2013

Samuel A. Rebelsky

Samuel A. Rebelsky, known to most of his students as SamR (alternately pronounced "Sam-Are" and "Sammer"), is a Professor 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 mail 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 page, 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 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.

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
4. Introduction to IRC - Done
5. IRC Meeting -Done
6. Anatomy of a FOSS Project - Forthcoming

Part B

1. FOSS Field Trip - Done
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 - Forthcoming
4. Project Evaluation Activity - Forthcoming
5. 'Project Survey - Filled out twice. Whee!

Part C

1. IRC Meeting - Thursday
2. Bug-Tracker Activity - Forthcoming
3. Source Code Management/Control Activity - Forthcoming, but I use git a lot
4. FOSS in Courses Planning 2 - Forthcoming