Tag Archives: code

conference, postgres, postgresql , , , , 2 Comments

Training lessons learned: Code dojo, whiteboards, interactivity

Training can be an incredibly boring, frustrating exercise. Often, I have friends who don’t bother to attend sessions or tutorials during conferences. Instead, they cherry-pick friends and colleagues that they can work on code, gossip or brainstorm with in the hall while others sit passively in lectures. When I think about it now, knowing this about my friends is what motivated me to start Open Source Bridge.

The PostgreSQL training I gave to Ondo State was specifically targeted at developers. I used material End Point had from previous trainings, and added few new things designed to meet the needs of fledgling database developers. The high points I wanted to hit were: schema design basics, user defined function development and highlight developer-friendly features of Postgres that they should be aware of.

One big obstacle for me was that they would all be using Windows as their primary operating system. I develop exclusively on UNIX-based platforms, and so I had to spend a little time getting re-acquainted with Windows tools. pgAdmin III was essential, and I was happy that a new version was released along with version 8.4 of Postgres.

Also, while the concepts are the same, the built-in monitoring tools for Windows are quite a bit different, and I used freely available material from my Postgres colleagues who support Windows for a couple hour tutorial on interactive troubleshooting.

When trying to explain concepts – like replication, or basic database terms – it really helps to have a whiteboard. I was working with a group of people with diverse IT backgrounds, and often, I asked individuals to try to explain in their own words various terms (like “transaction”). This helped engage the students in a way that simply stating definitions can’t. Observing their fellow students struggling with terminology helped them generate their own questions, and I saw the great results the next day – when students were able to define terms immediately, that took five minutes the day before to work through.

Finally, one important request from the client was that some time be spent mentoring developers on standards, best practices for development and coding style. To accomplish this task with fourteen students in such a limited period of time, I decided to conduct a series of coding sessions where students and I took turns at the keyboard programming as a group. We call this coding dojo, a concept built on the Coding Katas from Dave Thomas.

Overall, I prefer interactive training, where students are not only encouraged, but forced to interact with each other and the instructor.

When I sent out the CFP for MySQL Conf yesterday, lots of people asked me for suggestions on talk topics. In general, I recommend that speakers focus on a particular take-away for the audience, and mention specifically what a person sitting in is going to learn *and* apply immediately. Not every talk can be interactive, or give people chunks of code. But *every* talk should have a clear goal, and leave the audience educated. The best leave them inspired!

postgres, postgresql , , , , 2 Comments

PostgreSQL 9.0: contributions!

New releases are opportunities for reflection!

As PostgreSQL grows, I would like to know how many people are contributing at any time. This is difficult to measure, given how many people contribute in ways not visible to the internet – advocating for PostgreSQL at work, sharing information about PostgreSQL offline in any way, or developing code related to PostgreSQL that isn’t shared directly back.

PostgreSQL developers have a habit of mentioning the people involved in the development of features in the commit logs. This includes people who discuss topics on the mailing list, who report bugs, provide test cases or send in patches. I spent a bit of time digging through the commit logs and pulling out unique names that are mentioned. This is a lossy process, as the log files are long, names are not always easy to spot, and I only spent 6 hours going through it.

I’ve made it through the 9.0 (16163 lines of logs) and 8.4 logs (21257 lines of logs) so far.

Here’s some basic information about them:

  • 8.4 logs mention about 230 unique people (11 committers)
  • 9.0 logs mention about 275 unique people (16 committers)
  • 8.4 development contained 2293 commits with commits per author broken down below (click for a bigger version):
  • 9.0 development contained 1703 commits, and the commits per author broken down below (click for a bigger version):

I’m working on graphs about number of lines inserted or deleted by each author, but need more time to work out the information presentation. Some interesting trends emerge about what the role of each committer is – particularly that there are a couple people who seem to be “gardeners” of the code – removing a lot of lines, sometimes more than they are adding. With a project as old as ours (first commit in 1996!), this maintenance work is critical.

I also did some grepping for key words in the commit messages:

word times mentioned
in 8.3		 times mentioned
in 8.4		 times mentioned
in 9.0
review 24 14 49
cute 29 26 25
tom lane 904 901 635
gripe 37 48 26
hot standby 0 5 48
replication 18 4 52

You’re welcome to explore our git repo at git.postgresql.org. Thanks to all the folks who worked on the git migration over the past few months, and finally made our transition from CVS to git complete last night!

community, conference, leadership, open source, oscon, user groups, volunteering , , , , , , 1 Comment

Pluggable architecture, not just for code

hands

photo from Chris Zakorchemny

One OSCON session that made me think was “Does Open Source need to be organic?” The panel contained Brian Aker (MySQL), Rob Lanphier (Linden Lab), Stephen O’Grady (Redmonk), Theodore Ts’o (Linux Foundation). The session was less about business vs. community, and more about how to increase community involvement in your projects.

Brian Aker mentioned Launchpad, and the way that it handles code forks. Forks are integrated into the system using a new revision control system – Bazaar. The forks are front and center – allowing all developers on the project to add forks and update them, incorporating them in with the primary code distribution point. This model reinforces the idea that forks are natural and can be positive evolutions in open source projects.

My big take-away: If you want to increase community contribution to open source projects, provide public and easy-to use interfaces. Publish your API early and create pluggable interfaces! Let developers add functionality and publish their add-ons easily, both in your project’s development space and on their own.

The same principal can be applied to the people side of open source projects. In your organization, make roles, tasks and responsibilities transparent. Let everyone – inside AND outside the project – know what they could be doing to get things done. The mistake that many projects make is assuming that people know what they could be doing.

Think of the people-side of projects the same way as you think about the code. Documented APIs are the same as public mailing lists, blog entries and wikis that reveal what your organization is actually doing, and how new people can get involved. Roles and titles that are meaningful let people know who they should bring their ideas to. And that lowers barriers to participation.

Leadership is not just telling people what to do – it’s inspiring, facilitating and then getting out of the way of people who are willing and capable of doing things on their own. Community grown from inspiration, and then fed by encouragement, fun and recognition of accomplishment, are the ones that last. And these communities are the ones that I want to be part of.