At 03:34 PM 3/27/2009 -0300, Andre Roberge wrote:
On Fri, Mar 27, 2009 at 2:26 PM, David MacQuigg <<mailto:macquigg@ece.arizona.edu>macquigg@ece.arizona.edu> wrote:
At 11:30 AM 3/27/2009 -0500, kirby urner wrote:
So Croquant is like a delivery tool, where the lesson plans accumulate. PyWhip is similar but more static (making the content Wiki based is likely to promote organic growth).
Not quite sure what you mean here. Could you be more specific?
Anyone can contribute problems to PyWhip, including students. I expect we will have a huge accumulation, and the final quality will be determined by how well we chose the best, and how well get these collections organized into a good learning sequence.
Currently PyWhip more like Citizendium than Wikipedia. Teachers (editors) control the content. We are talking about expanding this to allow anyone to be a teacher, and register a setup. Students who select that setup, will then see whatever problems their teacher wants them to see.
Since what I said in my talk is at the origin of Kirby's post, perhaps I should be the one to clarify.
In my talk about Crunchy, I mentioned and showed (very superficially) both PyWhip and Croquant. Croquant is a MoinMoin extension that allows to add additional markup which Crunchy can recognize and insert the requested interactive element (e.g. Python interpreter, doctest, unittest, editor, etc.) inside the browser window. Because Croquant == MoinMoin, it is a purely collaborative media where no one is the single author (with exclusive editing rights) of any example. Someone setting a Croquant server could create a site where doctest-based problems would accumulate organically (like Wikedia). But Croquant is static - you need to view it with Crunchy to have the interaction.
PyWhip, by contrast, includes both the editing and interacting features in one app/site. However, to use your expression, it is more like Citizendium than Wikipedia - which is essentially what I attempted to convey in my talk.
I think the essential question here is - should we allow one author to edit another's work, or preserve the original and ask the new author to submit a new problem, even if it just a minor edit of the original. We're going with the latter for now, but at this point, anything is open for discussion. If the new problem is a variation on the original, different numbers, etc., then we can include them both. These are exercises. Repetition is OK. At some point we may want to limit the number of problems, but we are no where near that limit now. If the new problem is a correction of some deficiency in the original - an ambiguous question, etc., then the original author has the option of including the correction in his original. If the original author chooses not to include the correction, then the editors will have to decide whether to use the original or the corrected version. There will never be a Wikipedia-style "edit war".
And I did invite everyone (I would say over 100 people present) in my talk to go to PyWhip and contribute at least one problem!
Just so everyone understands, Andre is a contributor to PyWhip with full SVN access. If there is any "competition" between PyWhip and Crunchy, it is entirely friendly. I'm assuming all code will be available under GPL, but that is actually for Athar to decide, since he wrote it. I think this answers Kirby's question in the next message. 99% of the value will be in the content, not the website coding. Among the developers, I have proposed, and nobody has objected, that we use the Creative Commons license. If this is acceptable, we will have something like this in a pop-up which appears when an author clicks SUBMIT: By clicking ACCEPT, you are certifying 1) The problem you are submitting is your own work, or is a derivative work consistent with the original author's license. 2) You agree that your submission will be licensed under the Creative Commons Attribution-Share Alike license <http://creativecommons.org/licenses/by-sa/3.0>http://creativecommons.org/licenses/by-sa/3.0 This means that others may modify and share your work under the same license. [ACCEPT] [DECLINE] -- Dave
As Andre remarked in his talk, PyWhip is still quite new, just appeared in the last couple months. I'm glad we're getting more of a vision statement here from David, as that'll help any one of us promote the site accurately. My goal is to sustain a high degree of realism. Crunchy, to me, seems far more ambitious in scope. You can evaluate your code with a number of testers, there's the optional turtle module, the editor goes into full page mode... it's not an IDE, as Andre emphasized, but it's not just about writing code snippets either. Since it lives on your local machine, in your browser, you're able to load and save files right there on your file tree, plus boot up external threads (Pyglet demoed, VPython wouldn've worked just as well no doubt). Pywhip runs on a server, isn't about launching local processes or accessing one's local file tree. It doesn't go out over the web and "eat" Python code segments in <pre></pre> tags. It's more a repository of challenges, submitted from various sources, to a client looking for specific markup from external sites. So: apples and oranges in my book. These initiatives are not aimed to do the same thing. Given the creative commons approach, I'm thinking it'd be easy to translate any PyWhip repository into a Crunchy compatible wiki site. Probably it'd be possible to go in the other direction just as easily. Kirby
On Fri, Mar 27, 2009 at 3:44 PM, kirby urner <kirby.urner@gmail.com> wrote: << SNIP >>
Pywhip runs on a server, isn't about launching local processes or accessing one's local file tree. It doesn't go out over the web and "eat" Python code segments in <pre></pre> tags. It's more a repository of challenges, submitted from various sources, to a client looking for specific markup from external sites.
Sorry: "... more a repository of challenges, submitted from various sources, [not] a client looking..." I've been blogging about Pycon in addition to posting here. We're having an edu-sig dinner this evening, plus I think there's a BOF. I'll try to capture some of the discussion. Good seeing Jeff (he's pumped about teaching algebra with Python). Steve Holden says "dunder" for "under under" (i.e. "double under") e.g. "dunder init" means __init__. He's now heard my alternative, so say "the init rib", i.e. we thing in terms of a "__rib__ cage", referring to special names. This is a metaphoric approach, first unveiled in Vilnius. Steve booted Wing IDE and used "code folding" to show all the __ribs__ as one-liners -- makes the "backbone" all the more obvious. Using these "creaturely" metaphors is a hallmark of the early curriculum. Ships also have ribs, reinforcing the idea that a class is a blueprint for a kind of "container" (an object space, like a namespace in terms of having a __dict__ and so forth). One of the best talks so far in addition to Andre's (for me) was by Jeff Rush, helping us sort out the differences between a "namespace" and a "code object". I blogged about the talk in a sort of short hand, but it's the slides themselves that I'm looking forward to seeing again, very enlightning. http://mybizmo.blogspot.com/2009/03/about-python-namespaces.html I sat next to Jeff at the PSF meeting, yakked about how Portland and Austin feel some affinity, because of the "Keep [ Portland | Austin ] weird" campaigns. I also confessed never having been to Austin. http://controlroom.blogspot.com/2009/03/connected-campaigns.html Kirby
participants (2)
-
David MacQuigg -
kirby urner