[Dev] PyCon Report

[Katie Capps Parlante]

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