Craftsmanship without the Man


Recently on the Devchix mailing list, aimee brought up the software craftsmanship movement and asked whether other women felt awkward about being labeled “craftsmen.”

Some of our members were fine with it, while others said they felt alienated by the term. Beth explained that it was because of its usage in the movement—“master craftsman” is held up as an ideal that everyone should aspire to, but its male bias makes it difficult for some women to relate to it.

We discussed alternatives like craftsperson, crafter, and artisan. After a bit of brainstorming, Tess came up with “codesmith.” Many of us were excited about this term—it has a fun and geeky vibe that captures the enthusiasm we have about our work, while having the same emphasis on creation present in “craftsman.”  While it’s certainly based on words like blacksmith, I like to think of it as more similar to wordsmith—a person who is skilled at using language to make something great.

As the sort of programmers who get into debates over small differences in syntax and rack our brains to come up with the most appropriate name for some variable, we know language is important. It’s a shortcut for identifying something, but over time it can create expectations and beliefs. Making changes to language can be difficult, but in the case of being inclusive to women in a women-starved field, I think it’s worth it.

Pair programming Issues


“Pair programming is a software development practice in which two programmers work together at one work station”


I’ve worked with pair programming at just 1 company for 9 months, the results were both good and bad.

During the time when you are pairing you share your computer with another person. You also share your virtual life details, such as:

  • organization: how you organize your documents, projects, music, etc.
  • choice: which applications you use and how you use it, like: themes, hotkeys and configurations.
  • skills: typing velocity, how much you know about the application that you’re developing.

Off course, when these pairs get along with each other sharing information becomes productive.

The one billion dollar question is: “What happens when the pair does not get along?


If both people aren’t open to learning with from the experience, the day by day can become difficult.

Pair programming doesn’t work when one party feels the result could be better if the work was done alone. In this case, pair programming is an intrusive and negative experience.

Some people doesn’t understand this situation. To make it easier to understand I usually like to compare pair programming to driving a car and having someone beside you.

First case: Going by a known path.

Imagine you’re going to a party, you’re driving your car and you know the way to go there. Beside you is someone, a friend or just an acquaintance.

If you have some doubt how to get the place or make some mistake this person can help you, suggest a better way or street.

When you arrive in the party you’ve learned something or at least both of you have had a great time together.

Second case: Learning new path.

Now, imagine you’re going to another party. Beside you is another friend or acquaintance.

During the way you ask for some help. That person helps you as best as possible.

When you arrive in the party you’ve learned a good path and both had a great experience.

Third case: The beginning of the end.

Now, imagine you’re going to a party, doesn’t matter if you know how to get there. Beside you have someone again.

You are driving but now this person prefers to do the driving. If you make some mistake that person says “It would be better if I was driving.” or “If I was driving it wouldn’t have happened.”. What would you do?

Probably both of you arrive at the party in a bad mood and will try to avoid sharing the same the car again.

Maybe if you were in the car a debate would start. But, during pair programming you’re in a company and some words wouldn’t and shouldn’t be said.

Think about it, before sharing your computer with someone.
It’s better to both if you enjoy it.


PS: Thank you Desi for reviewing this post. I’m a english learner and Desi have been helping me.
PS1: To read in portuguese click here.

Satchmo: Python Storefront out-of-the-box


Satchmo is turning out to be an interesting project. The first true Python contender to challenge the plethora of PHP CMS tools used for the de facto net store front, it fares quite well in the face of this challenge. .

Satchmo is based on the Django framework. More accurately, it is loosely coupled to Django through several external Django plugins. For example, registration functionality is extended through the django_registration external interface, installed as a separate egg in the Python distribution directory. Satchmo makes calls to this extension, leaving Django code untouched.

Compare this to Drupal registration changes, where source code is wedged into the existing framework, applying deep back end database schema changes, as well as code changes throughout the framework. The changes are irreversible, and if they fail, you’re SOL. Look under the hood of Drupal, and you see a tangle of database calls, auth and group checking calls, intertwined around back end logic. It’s not pretty, which is why it’s so hard to maintain and upgrade over time.

The Satchmo/Django coupling is not perfect. If you mismatch incompatible versions of Django plugins to Satchmo, or other applications, cryptic messages can appear from either side, pointing back to code compiled elsewhere and placed in your Python distro. This makes it difficult to trace back, even if you vaguely know where the failure point is.

But this is the worst problem Satchmo has presented to me so far. I can certainly live with that, compared to digging through many chunks of Drupal framework source code and database schema backups to figure out why a recent patch broke authentication, how group permissions were changed, etc.

Satchmo takes full advantage of all of the juicy Django goodness that makes web framework development fun again: built-in internationalization and localization all the way down to currency handling and language choices in templates, built-in registration, email verification and customer account management, built-in form data validation, seamless form-to-database data entry.

This is a revolutionary, much needed improvement in the Open Source store front choices. Now all we need is an Open Source back end inventory system, and a very functional Open Source phone bank system based on Asterisk, with Python wrappers, and life would be wonderful.


PyCon 2010 talk proposal deadline: Oct 1st


Want to give a tutorial or talk about what you’re doing in Python? Submit your proposal!

Want to get more familiar with Python? Want to participate in shaping this community, and helping to drive the effort behind new libraries and modules? Want to do something fun and new in the Open Spaces and code sprints? Be sure to be there in 2010. I think it’s going to be a unique, interesting and most spectacular year for PyCon, and I’d really like many women on this list to be a part of this great event.

I know, it’s late for my time zone, and you must be thinking that I’m juiced up on Club Mate right now. Maybe I am, but I was excited about this well before the Mate. I am a bit more involved this year, reviewing talks, discussing some possibilities for new types of Open Space events and code sprints, poking my head into various discussions, etc. It’s getting exciting, but it will be even better if more women show up this year, I guarantee this (HINT HINT).

If you want to come, but can’t afford it, don’t let this stop you! Contact me and I’ll put you in touch with organizers who may be able to help you get to PyCon this year.

Yes, I’m flying. How? No, not Mate. You know how:


Fun at PyOhio: SqlAlchemy, MongoDB, and Google Maps API

ThoughtsTips and Tricks

This was my first year attending PyOhio, and I really enjoyed it. It was small enough to have the time to catch up with fellow Python geeks, yet large enough to offer interesting and wide-ranging topics.

I did a tutorial on browser-to-database web development in Python, using components from various packages instead of one framework. I found myself and Mark Ramm giving our audiences a common message about frameworks in general, which was (1) each framework has limitations, (2) know these limitations before running off to use them. It was comforting to know that I am not the only one trying to convey this message.

I wasn’t quite sure how long my tutorial would run, so the PyOhio folks were kind enough to give me a room for an entire afternoon. It took about three hours, and was great fun.

I’ll attach all slides, links, and code. But there’s the summary of it all.

I took weather data from the University of Delaware, air temperatures from around the world ranging from 1900 to 2008. I pulled the data into both SqlAlchemy/Postgres, and MongoDB (a BSON-based key-value object store).

I then used CherryPy to serve up the data. My templates are written in template, generating Google Map data.

The first CherryPy daemon takes longitude and latitude, and allows you to choose between Postgres or Mongo:

The second daemon provided a simple form, accepting zip codes, and referencing a database which maps zip codes to longitude and latitude.

Feel free to play with the links for a bit longer. They will be coming down in the next month or so.

The code and data, including all CSV load code and scripts, exists here:

Shoot me an email for the login and password: gloriajw_66 at yahoo dot com

This is an excellent web app example for learning purposes.

The tutorial is also somewhere on BlipTV, I am told.

Enjoy, play, ask questions.