I went through my 2nd Python teaching session today, with the same students than last time. Some improvements and still, so-so-so many things to improve. Teaching is something I really want to get better at so I'm really motivated to debug my process.

Having prepared more exercises to hand out worked really well, until it sort of backfired on me. Since we last met about 3 weeks ago, what I had in mind was quickly recap what we did last time, then do some revisions exercises to really remember what we did. My plan for the exercises was to have several for each concept, and move on to the next concept when everyone has completed at least one exercise. That way I had time to walk around the class and help students having trouble, while the more advanced students can still keep busy and learn more/get more familiar with the concepts. This worked very well at the beginning, until students kinda refused/didn't pay attention when I tried to move on because the competition spirit had kicked in and most of them wanted to finish all of the exercises (even working through break time to get it done!).

So once again we only went through half of what I had prepared, except this time it's more because of my unability to lead the class (it's also very awesome to see students so motivated to learn to program :D) than because I wasn't sure how much to fit in a session. I will need to control the schedule more if I want to get to some of the REALLY cool stuff (or at least get through all the basics!). I need to allocate more time to introduce new concepts and introduce them better. I suspect I kind of suck at explaining programming, and because I was looking forward too much to helping out students individually I kinda went too fast or just didn't try hard enough to explain in many different ways (it's really hard to explain programming concepts. I'm much better at helping people debug their programs, so far.)

3 hours is very damn long, but I don't have a lot of control over that for this group of students. I might try 1h15 / 30 mins break / 1h15 next time. What happened today was that after the initial burst of energy and working through the first break, students just started losing focus, being distracted and having a hard time getting interested. I'll have to write lesson plans that take this into account better.

Or if I get better at understanding what teenagers find cool I can sprinkle that toward the end ;) I completely underestimated how much of a killer "import random" would be. Suddenly their while loop with 'if' giving hints and 'if' limiting attempts, became a real game! (It was a "Guess the number" game.) That definitely woke people up. They were delighted to have made a small program they could actually use and play with. I was postponing introducing "random" because I wasn't sure it was a good time to introduce libraries. In the end I don't think whether it was a library or not mattered or registered. Maybe that just goes back to me not being great at explaining concepts, or maybe seeing really is just a hell of a lot better than talk.

I'm still processing today's session, to figure out where to improve in my preparations and the actual teaching. I think the handouts worked well as part of the recap. As usual, tips, advice and "ew can't believe you tried to teach it this way" very welcome! In the meantime, I'm moving next week and need to learn pygame so I can teach it in two or three weeks... :) Fun and busy!

I'm very glad I was able to attend Python Ireland's March talks meet-up last night, it's the first time (at last!) that I got to hear the Python chaps presenting, some very interesting stuff. Apparently they're doing a "return to the sources" with more introductory talks, after some time of in-depth technical talks that very few people were actually able to get. I think it worked well.

The first presentation was about Jython. Until then I hadn't thought much about it, besides "yeah, Python on the JVM. Why not." Turns out there's some really cool stuff going on there! The seamless Java <-> Python integration evokes a realm of possibilities I hadn't considered before (I thought it simply ran pure Python, I didn't know about it talking with Java and the use of java.lang.reflect.) Jython also integrates with a few Java containers, like JBoss and WebSphere and that's something I definitely want to look into and see how useful it could be in work to help script our build environment. Learning Python version 2.1 should prove interesting...!!

Jython doesn't use the GIL, enabling real multi-threading. Web frameworks can run on it too, some of them tested and confirmed like Django. The thought of Django running on a heavy weight "enterprise" Java container/server brings up a smile, for some reason. All in all a very informative talk, that not only made me want to try out Jython but also dig deeper into the Python language to find out more about some of the concepts that were mentioned.

The second talk was a summary of some sessions from PyCon 2010, quite interactive with the audience asking questions. Some interesting discussions about performance, the GIL (serious case of busy wait on multicore, fixing-in-progress), Unladden Swallow (aiming at 5x better performance and actually getting there, huh. Cool!), an interest in NoSQL databases (tending toward Cassandra and MongoDB rather than CouchDB, interesting), some packaging discussions (highlighting that it was often easier to install (using easy_install) than remove (manually :)). There must be something to learn from the way Linux distributions have been doing it for 15 years now. They're getting there.) Having "poster sessions" for people to present a project without doing an actual presentation is quite an interesting concept. I wonder if this would work for other local conferences, like OSS Bar Camp.

Through a series of kinda mind boggling coincidences, meeting people and talking about what I have in mind and am passionate about, earlier this month I ended up with commit access to the Pippy activity (a Sugar application). Wow! Awesome. A few weeks back, I had decided to fix as many of the broken examples as I could after getting a bit embarrassed showing off Sugar to a teenager, last October. He was very interested but as we were using Pippy it felt like we were getting stack traces a bit too often (they weren't that many really, they just happen to be more memorable.)

So I fixed them and the patches sat there for weeks (I didn't set the "need review" flag to be fair, which I just discovered in a corner of the wiki last week), along with a patch not-from-me in #347 which I think should really-really make it into the next release because Pippy is completely unusable on my (all?) netbook without it.

Now, I've been granted the Power Of The Commit so it should all be fine, with me committing away and happily making the world a better place... but it's not so simple, because really, I'm still living too far away from the community to understand how they work and notably here, the interactions with and within the bug tracker. For instance, I didn't realise you were supposed to add the "r?" keyword when submitting a patch, I found it accidentally when looking for something else in the wiki. I'm not a maintainer either, so it's not entirely clear what I should be doing with the bug report after submitting a patch or the process to follow.

Although my patches are tested and too small (I believe!) to actually do great damage, I didn't commit them... which ended up being a good idea since one of them was incorrect :) Someone kindly commented on the bug report saying it didn't work, with details. Turns out I was so keen on removing the stack traces I didn't check if the error messages provided by other Pippy examples were actually correct (so I display "install this" instead of showing a stack trace, but the "install this" doesn't actually solve the issue for that example, nor for the example I took it from.) I've now attached a new, better patch to the report (...and set the proper review flag!)

It's probably a tad too early for me to have those commit rights, just yet. I need a mentor still, except individually everybody is incredibly busy being awesome already, which is fair. The truth is, I already have a mentor if I reach out to it: the community. So this is always something I will be working on in parallel, I really want to integrate with the community. It just takes time for someone not so comfortable with the "public speaking effect" of pouring thoughts, mistakes and ideas on public, sometimes archived mailing lists and channels. I'll figure it out, at my own pace. I have access to some pretty cool people individually in the meantime if I really need help. My first area of focus is grokking the bug tracker so I can contribute effectively there.

Sugar stuff I want to figure out:

• How to know when a patch is big enough to warrant the "r?" flag, or really should they all have it?
• The complete process for submitting a patch. Right now, I think, a lot of the information I am looking for is under the "Code review" wiki page which makes it not obvious to find, and it's still not a clear step-by-step process. As I progressively get a better understanding of how things work I'd like to improve on it and/or eventually make a case for a "Submitting patches" page aimed at brand-new contributors, ideally "drive by" contributors too. I'm thinking of something along the lines of Gnome's "Submitting patches" page, or Gnome's project specific guidelines, which I found really useful when I was getting ready to make my first open-source contribution.
• Find out what developers do with bug reports, the best practices. How keywords and the 5.000 status/milestones/etc fields are being used and who gets to set them. I suspect there's probably an established set of guidelines for Sugar core, and that activity maintainers kinda do their own things, but still, I'm sure a set of best practices has emerged, somehow, somewhere. Usually triaging guides are pretty good at indicating how the status field should be used and what it means up to a certain point (usually, up to when the developer takes charge of the bug which is when I started getting stuck) but for Sugar, what I've seen so far doesn't seem to match the wiki (for instance there are a lot of bug marked assigned that aren't being worked on, and I suspect they just automatically get assigned to the maintainer or something like this. To be investigated further.) Also for the non-creator/non-main-maintainer of a component, is it ok to simply close off a bug after pushing a patch, even if no one else confirmed it worked? (I guess any problem will bubble back up to the bug tracker anyway, eventually...)
• Code freezes. We're in one now, but I'm not sure how this impacts activities or if this is mostly about Sugar core, and when/which/how a version of an activity is selected to be shipped with the current release (and does that differ for "main"/fructose activities like Pippy?)