Old Develop activity

The Develop Activity is the "Activity for making Activities" in Sugar. In the spirit of Constructivism, OLPC needs a collaborative, intuitive and simple mechanism for fledgling hackers to write software in the same class as the officially supplied activities. It needs to be accessible for both educators who need implement a solid early computer science curriculum and young people who simply wish to play with their computer to make things for making's sake.

Early screenshot of Develop

Purpose and Features

Minimalistic and Intuitive Interface for Writing Activities

Develop needs to abstract away many of the logistical complexities of software development, including collaboration and version control. It needs to Just Work. If we expect the young people to manage their source control systems and bug trackers, they simply won't (this is actually true of most people; unless it is given to them on a silver platter they will simply not bother until it is too late). As the people writing this system, we can impart a little project management wisdom in Turing-complete form.

It is important to note that develop-activity makes a significant departure from traditional IDE design; it will consider a "project" to be little more than a directory. It does not persist any sort of "Project" meta-data between sessions beyond what is stored in the .info file mandated for Activity Bundles, and the .bzr (or .git) directory of the Bazaar (or GIT) version control system. Develop may, however, persist activity-specific settings in Develop's own configuration directory. It would be best to avoid this as much as possible.

Develop will provide a means for viewing and editing Python packages other than Sugar activities. If Develop does not detect activity metadata on a reopened project, it will simply not provide Sugar specific features. The same goes for version control; if a reopened directory does not contain a bazaar branch (".bzr") or a GIT database, the version control and some collaboration features will not be available either.

Where activities currently under development will be stored has not yet been decided (journal integration?). See the Version Control section for more info.

Version Control

This is a very important component, as this will provide the basis for collaborative work as well as Journaling. We should try to implement this in the spirit of the Journal (and as tightly integrated with the Journal as physically possible).

Most version control actions should be as abstracted away from the user as possible. Develop should take care of all routine aspects of source control; newly created files shall be automatically added, deleted ones removed, etc.

The only VCS features that will be directly exposed to the user will be:

• Commit ("Write a journal entry" or similar language might be appropriate)

• A history viewer ("View Journal")

• The collaboration features. How this will work is as yet unclear as it will require a lot of sugar infrastructure.

Version control *may* be implemented by Bazaar.

Choice of VCS system

I originally considered git, thanks to its speed and simplicity. However, I am now equivocating, as documented below:

Git

pros:

• Has all the features we need (I think)
• Integrates beautifully with upstream (ie. laptop.org) which is very important for the features I describe above.
• Fast (the kernel developers use it very hard and performance and reliability bugs get fixed very quickly)
• Simple in that there aren't multiple repository types like in bzr,which can be a bit confusing.

cons:

• Not Python, so it can't be cracked apart as readily
• Embedding it in Develop might be a little harder than bzr, but not too much I think (I'd need to write my own git porcelain in Python)

Bazaar-ng

pros:

• Feature rich (except tagging, which Develop might need for marking releases automatically, I haven't thought ahead that far)
• Written in Python, which means it can be cracked apart readily
• ... and embedded in Develop readily too.
• Ivan wants it...

cons:

• Won't talk to upstream (I don't think the foreign branch feature really cuts it here).
• Slower.

Now I am considering git again, because all of the OLPC projects (including Develop itself) are tracked by git and git appears to be faster and lighter on memory than bzr. Suddenly forking and exec'ing doesn't seem so bad. --Orospakr 17:40, 18 January 2007 (EST)

Collaboration

Mockup of the Community View

Collaboration is of paramount importance, especially when people are working on things that can be as large and complex as computer programs.

Develop will expose the version control branch over the mesh (at the author's option, of course) for branching, even when Develop is not running. The Presence system would permit other Develop instances on the mesh to present users with the option to create branches of their peers' activities. The peer could then push her changes back to the original person she branched from. This way, the tree originator could be prompted with a message asking if they would like to accept a change from a buddy on the mesh. This basically would permit Linux kernel style distributed version control in a very kinetic way for young people, integrated and implemented within the OLPC mesh networking system.

Activity bundles will need contain a repository pointer (a URI) in the metadata either pointing to a repository hosted on the public Internet or on the mesh. Thus, when a user presses the View Source key for an activity written by someone else, Develop will be able to branch the Activity. This offers up many possibilities, described below. This feature will need to deal with the situation of origin unavailability (either lack of Internet connectivity or unavailable buddy on the mesh) and fail gracefully.

Naturally, a different URI formatting will be required for branches either on or off the mesh. --Orospakr 22:08, 20 January 2007 (EST)

By using the origin information in the branch, Develop will be able to plot the development hierarchy of the Activity, giving the user a "bird's eye" view of most if not all of the community surrounding that activity's development (see mockup at right). This feature may also query Presence for the existence of any "sister" branches on the mesh.

We can not rely on the Activity's name being a suitable unique identifer given this kind of ecosystem. Activity bundles will need to be identifiable between different people publishing them; for instance, if someone modifies TamTam and shares the bundle on the mesh, the other laptops must be able to distinguish it from the upstream release of TamTam.

The Activity bundle should contain either an author field of some kind, or even a GUID (bleh). --Orospakr 22:08, 20 January 2007 (EST)

This feature is particularly intriguing!

Bug and Task Tracker

A little bug tracker facility would not be amiss either. This too should be integrated into the collaboration features.

The View Source key

Keys

Pressing the View Source key will instruct Sugar (would this be d-bus magic because Activities are dbus services?) to invoke Develop on the currently active running activity. Develop will then create a copy for them to change as they like (a "fork", or "branch").

Activity Bundle Creation and Sharing

Develop will provide a means to allow an activity author to set sugar activity-specific metadata (most of which is persisted in the activity/activity.info file)

Develop will also provide UI for Activity Bundle creation (only available when the currently open project is actually a Sugar Activity, of course), and interaction with both Sugar's activity sharing features and the public repository hosted by the OLPC project. This should almost certainly interact in some way with the Version Control features.

User Stories

These little anecdotes describe what people might do with Develop.

Story #1 (changing an existing activity)

This documents what a user would do to create their own version of an activity, either from laptop.org or someone else on the mesh.

1. Sally starts TamTam and plays with it.
2. She decides (or perhaps as part of a project in programming class) that it would be really awesome if she could make TamTam play instruments backwards (ok, I'm reaching here... ;)
3. She presses the View Source button on the XO keyboard.
4. Develop pops up (I am not sure how this bit of UI should be designed visually yet) and asks something like:

You pressed the View Source button.  Would you like to just look at the source code of TamTam, or would you
like to create your own version to change and give to others?

1. She clicks the second button.
2. She enables tree sharing so that others may branch her version off her laptop just as she branched it off the original TamTam.
3. Hack, hack hack.
4. She can then press the Run button to run her modified TamTam (Run will serve as the 'publish' function as well, because when you run an Activity and share it, others can click it in the Sugar mesh view and download it. Pretty intuitive, eh? :D )

Story #2 (creating a new activity)

This documents what a user would do to create their own activity from scratch.

1. Maurice wants to write a simple game, entitled "Super Cat Protect!"
2. He clicks the Develop icon at the bottom of the frame, and Develop asks if he would like to continue working on an existing activity, or if he would like to create a new one. He chooses the latter.
3. Develop creates the new Activity, initialises an empty version control repository, and displays a screen to allow Maurice to enter the properties of his new project (Name, Description, Enable Sharing).
4. Hack, hack, hack.
5. Expose the repository for branching over the network if Maurice opted for it.

Human Language and Culture Concerns

Unfortunately, language keywords, identifiers, docstrings and comments are almost exclusively English or based upon English terms. This means that fledgling developers are forced to learn at least some subset of English in order to read and write both code and documentation.

There are no feasible technical solutions to this problem, because attempting to maintain translations of even one aspect (such as docstrings) is a prohibitively expensive endeavour.

There is no evidence that this is unfeasable or prohibitively expensive. Given that modern IDEs do syntax colouring and that a language like Python has a small number of English keywords, it seems very feasable to provide some mapping to native language keywords for display purposes. And since this mapping requires a dictionary to do the mapping, it would seem a fairly small job to extend that mapping to built-in function, class, module and attribute names. The system can always fallback to making the English name visible if no mapping exists. In addition to built-in mappings, this IDE could read additional mappings from specially formatted comments in the source as long as the source is in UTF-8 and arguably, for the OLPC projects, it should always be in UTF-8.

This is not an insurmountable problem. And the mapping is only needed for keywords and for identifiers with fairly clear English names. For instance, it makes sense to translate 'String' which has a fairly transparent English meaning but it does not make sense to translate 'httplib' which is an obscure technical term whose meaning must be learned, even in English.

No. I didn't suggest that in the original of this document because it would break everything. Code snippets, collaboration, everything. The only way one could sort of make this work is via some hacktacular string munging. Naturally, that would earn a stack of about 50 "Considered Harmful" documents. The best way to deal with this issue is just to consider the English-esque keywords simply part of the Python language, not the English language. (actually, as I mentioned before a docstring translation matrix is an idea, but it would be very hard to maintain.) -- Andrew Clunis (Orospakr)

Get the Code (such as it is)

Although it's very early in the development cycle, you can:

git-clone git://dev.laptop.org/projects/develop-activity

to see how it looks right now.