Coding Projects for the First Hackathon
Here are three coding projects. I would like us to make progress on at least one of them in our first hackathon.
- Visualizing Program State (the first step in a debugger).
- Realtime Collaboration Experiment.
- Visualizing Geometric Measurements.
Project 1: Visualizing Program State
A top request of kids using Pencil Code is to get help understanding "which parts of the program drew which thing on the screen?" In a single hour, kids can quickly get to the point where they have a 30-line program with a bug that they cannot find. They can identify where the problem is on the screen, but then they have trouble finding it inside their program.
A second request of kids is understanding "what should I do next" to get the drawing to go the way they imagine. We sometimes hold up protractors or imagine "rulers" - but maybe those should come with Pencil Code.
In the future, this debugger will grow to be more full-featured. The inspiration is http://pythontutor.org.
- As the turtle animates, corresponding lines of code in the editor highlight.
- After the run is done, you can enter a "debug mode" where you can highlight locations on the screen and see the line of code responsible (and maybe vice-versa).
- Designing a Debugger interface to make available to the running program. Ideally we do not inject massive amounts of debugging code into the student's running code except when running in "debug" mode inside the IDE. There should be a simple little Debugger interface that the turtle library looks for.
- Forking CoffeeScript to provide source maps (line number maps) in the browser. CoffeeScript can already do this, but when running in browser on-demand mode, it does not save the source maps in any place accessible to code. So the first task is to make a fork of (Iced) CoffeeScript that does provide accessible source maps.
- In the IDE, highlighting lines as they are run. We use the ace editor - for an example highlighting lines, see https://gist.github.com/chrispitt/2577836
Project 2: Realtime Collaboration
In a classroom, kids often work together, but then they struggle to deal with the logistics of copying files from one account to another.
The modern alternative is to give students a "Share" mode where other students in the class (or the teacher) can bring up their page and edit their code collaboratively in realtime. The student might be able to control whether the sharing is read-only or read-write - but the key is that they should be able to have several people directly edit, run, and debug the same program, with everybody seeing the same thing on their screen.
- A proof-of-concept demo using one of the off-the-shelf libraries.
- A design for a collaboration model that that would be helpful in classrooms while still being safe on the open internet.
- A list of bugs and coding tasks, and as much progress as we can make through the implementation tasks.
- Try out http://togetherjs.com/ and http://sharejs.com/ and other alternatives, and choose one.
- Build a list of bugs, and start working through them - what do these libraries solve and what remains unsolved?
- Design a user model for collaboration. Should sharers be allowed to save? Should the original user be able to control whether sharers can edit or not?
- Port or implement the node.js server-side support for the chosen library.
Because of the existing open-source libraries, realtime collaboration may be easier to get started on than it sounds.
Project 3: Visualizing Measurements in Turtle Geometry
Young kids who are just learning about angles and measurement have a difficult time visualizing whether the angle they want is "100 degrees" or "160 degrees". Kids should be able to measure angles and distances directly on the screen, and ideally "reach in and twist" the turtle to learn about what code corresponds to the motion that they imagine.
The "debug mode" that provides geometry help should probably be the same "debug mode" described in Project 1.
- "Measuring tools" that can be brought up in debug mode - an on-screen protractor and an on-screen ruler.
- A "turtle motion maker" that translates gestures (e.g., "twisting the turtle") into code that can be appended to a program.
- A "turtle motion changer" that can preview the effect of changing a motion in the middle of a program.
- Implement the UI for drawing a protractor and ruler on the screen, in a layer on top of the turtle.
- Integrate with the debugger to place the protractor and ruler based on the turtle's current position.
- Build a "measurer" UI that helps with interactive measurements and generating corresponding code.
- Replace the drawing model of the turtle library with a library that keeps a scene graph.
- Allow the "measurer" to visualize and interact with the scene graph in debug mode.
There are really two related projects here. One is to build a measurer UI, and the other is to replace the drawing model of the turtle library in a way that makes it possible to interact with the drawn scene as line art.
What Other Areas Could I Help Build?
Anything you are interested in! Make a fork, and experiment.
Here are several other ideas that have been suggested that could be done in this or future hackathons:
- An activity and hinting system. You should be able to browse for "activities to do" and then load a template script that guides you through a goal-oriented exercise where you write a program to solve a problem. It should be easy for programmers - either students or teachers - to create new activities.
- Community version control. What would it mean for young students to manage their versions using git? Every save would be a commit, and you could roll back your code. But you could also edit a different student's code and save to a branch, then send a pull request so that they could see a diff.
- A screenshot server. Programs should be listed visually, with a snapshot of the output of each program. Although security prevents us from grabbing a screenshot of a browser session on the client side, it is possible to screenshot in a headless webkit on the server.
- A block language. The scope here still needs to be decided on: we could integrate blockly, or implement something more novel and ambitious, depending on interest. The dual goals are to improve tablet usability, and to make the language more accessible to non-keyboarding beginners.
Or your own ideas! Email firstname.lastname@example.org
if any of these capture your imagination, or if you think there is another project that would improve a key aspect of teaching programming.