one more pycon report: (http://wiki.osafoundation.org/bin/view/Journal/KatiePyConReport20050330)
Sprints
-------
I found the sprints to be very rewarding, a good use of two days. We split up into two groups, where we had one or two volunteers and one or two osaf helpers in each group. One pair worked on a delicious parcel and one pair worked on a flickr parcel.
Lessons learned about writing chandler parcels ----------------------------------------------
(+) Debugging xml is a real pain. Watching people try and find a typo in a namespace really makes one wince.
(+) xml is not the right solution for defining Kinds and Attributes. It may be the case that we still want to use xml for block instances. If so, we could consider using an xml format more suited for UI layout. (Alec has been thinking about this: AlecFlettXulVsCpia).
(+) We have too much boilerplate for common tasks. Part of this is a consequence of splitting out data definition in xml and then associated python code in a separate python file, which would go away if we get rid of parcel xml. If we do keep parcel xml as a format for defining some items, we should make better use of defaults. (John has been pointing this out all along.)
(+) Some of our names are rather awkward, including WakeupCaller and DetailTrunkSubtree.
(+) Python folks are not excited about our too-deep parcel/package hierarchy. "import osaf.framework.blocks.yadayada" smells like Java to them (not a good smell in their opinion). Note that "flat is better than nested" is a Python value. While we had talked about flattening the hierarchy overall, I'd now also like to consider getting rid of the "osaf".
(+) We needed feedback at each step of the process that step was successful. For the menu and the detail view, this was pretty easy. For defining new kinds and noting whether or not we populated the repository with new items, we found Morgen's web repository viewer essential. We should update the tutorial with explanations of how to verify that each step has been successful. The full credit answer would be to have unit tests for each step.
(+) Both parcels used some dialog code that Morgen had written some time earlier. Both parcels wanted a reasonable URL type for certain attributes. Both parcels would want a preference panel. To really support parcel development well we'll want a better set of utilities and apis to support things a parcel will want to do.
We had talked about many of the problems noted above before the sprint, and had talked about various options to fix them, but there was something about standing over someone's shoulder and watching someone struggle through it that really sealed the deal for me. I have completely accepted that the parcel xml experiment was a failure. Mea culpa. Alec had a good story to describe how many of us felt at the sprint: We've been living in a room full of tacks. We've learned to step around them and can manage ok, but when we invited friends over they kept stepping on tacks. It would be a lot nicer to live in a room without tacks; its worth the effort to pick them up. I already knew about most of the tacks; the sprint experience strengthened my resolve to fix them sooner rather than later.
Lessons learned about sprinting
-------------------------------
(+) The ideal setup (imho) would be to divide the sprint work into projects, and then have two person pairs for each project (pair programming). In this case, a good pairing would be one person already familiar with writing parcels, and one person new to parcels.
(+) It would be valuable to do sprint projects where both people were already working on chandler, not just as an exercise in exposing new people to chandler. Most of the other sprints seemed to have this flavor. It was great to spend time working directly on code with remote folks.
(+) It would be valuable to do pair programming to sprint on projects back at osaf. We might consider doing pair programming sprints at osaf (no conference needed), particularly when remote folks come to visit.
Other notes about the sprint
----------------------------
(+) The flickr and delicious schemas motivated the use of "global attributes" -- the first example we've seen. One can see wanting the "tag" attribute on both to be semantically the same attribute, without forcing their Kind classifications into the same hierarchy that defines the tag attribute. We had a lightbulb moment where Alec understood that we wanted to support that for the first time -- and the concomitant realization that other folks new to the project might also be unaware of that goal.
Extending Chandler Talk and Chandler BOF
----------------------------------------
The talk didn't exactly go smoothly from my perspective: we had demo troubles, I didn't really practice my part of the talk effectively, and I didn't sleep the night before (jet lag catching up with me). I managed to crash my mac when trying to use it as a backup demo (plugging in my display dongle while launching Chandler seemed to make my mac very unhappy). That said, we managed to accomplish these things:
* We demonstrated that Chandler isn't vapor.
* We showed stamping in action, and people got it.
* We showed a working parcel that people had written during the sprints. People understood that with a little bit of code and xml you could extend Chandler with new item types and pick up interesting features like stamping.
* Between the BOF and the talk, we demo'd Chandler on both Mac and XP -- people were interested to see a cross platform widgets app in python.
From that perspective, it was a success. The BOF ended up being a fairly informative QA session (which we didn't get to have at the talk, as it was short). Alas, I didn't take notes.
Other Notes
-----------
I didn't go to many talks, as I left the conference early and spent much of the time I was there catching up with folks.
(+) Immediately after our talk there was a talk on developing cross platform apps in python with wxPython, given by ... Nathan R Yergler of Creative Commons! (Nathan works in Indiana, apparently). I missed most of his talk, but talked to him briefly afterwards. He too has been struggling with mac issues, and was happy to hear that Stefan was making progress actively fixing mac problems.
(+) Cross platform app development in general, and wxPython in particular (including some frustration with the wxMac port not being on par with the others yet), was a common topic of discussion. Nick Bastin was talking about ways to use swt in python, including gcj tricks similar to what Andi did with Lucene, or recreating the java layer in python. I ran into several people using wxPython -- I think folks who aren't too worried about os x are fairly happy. Some folks are going the route of using the X11 port on os x. I'm sort of curious what Chandler would feel like on the X11 port.
Cheers, Katie
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
