Flickr Badge

Sunday, September 24, 2006

Export django database to an xml file

Here is a simple python script to export your django database to an XML file. I haven't tested it out very thoroughly. It seems to work for the fields that I have in my model - CharField, TextField, DateField, IntegerField, PositiveIntegerField and ForeignKey. If you find any bugs, add a comment to this post.
# setup the environment
import os, sys
sys.path.append(os.pardir)
os.environ["DJANGO_SETTINGS_MODULE"] = "settings"

class XMLWriter:
"""Helper class to write out an xml file"""
def __init__(self, pretty=True):
"""Set pretty to True if you want an indented XML file"""
self.output = ""
self.stack = []
self.pretty = pretty

def open(self, tag):
"""Add an open tag"""
self.stack.append(tag)
if self.pretty:
self.output += " "*(len(self.stack) - 1);
self.output += "<" + tag + ">"
if self.pretty:
self.output += "\n"

def close(self):
"""Close the innermost tag"""
if self.pretty:
self.output += "\n" + " "*(len(self.stack) - 1);
tag = self.stack.pop()
self.output += "</" + tag + ">"
if self.pretty:
self.output += "\n"

def closeAll(self):
"""Close all open tags"""
while len(self.stack) > 0:
self.close()

def content(self, text):
"""Add some content"""
if self.pretty:
self.output += " "*len(self.stack);
self.output += str(text)

def save(self, filename):
"""Save the data to a file"""
self.closeAll()
fp = open(filename, "w")
fp.write(self.output)
fp.close()

import django.db.models

writer = XMLWriter(pretty=False)
writer.open("djangoexport")
models = django.db.models.get_models()
for model in models:
# model._meta.object_name holds the name of the model
writer.open(model._meta.object_name + "s")
for item in model.objects.all():
writer.open(model._meta.object_name)
for field in item._meta.fields:
writer.open(field.name)
value = getattr(item, field.name)
if value != None:
if isinstance(value, django.db.models.base.Model):
# This field is a foreign key, so save the primary key
# of the referring object
pk_name = value._meta.pk.name
pk_value = getattr(value, pk_name)
writer.content(pk_value)
else:
writer.content(value)
writer.close()
writer.close()
writer.close()
writer.close()
writer.save("export.xml")
Note to self: Find a better way to colorize the source code

This post is a part of the selected archive.

Friday, September 22, 2006

Handling conflict

Conflict. It's that word again. We have all faced it and most of us would rather not discuss it, but sooner or later you will be faced with such a situation and it's helpful to be able to understand it. In this article, I will discuss what I understand by conflict, and how we can handle it.

Conflict - good or bad?

Let's face it. People are different - that's what makes us people rather than machines. People with different viewpoints will naturally see things differently, inevitably leading to conflict.

A complete lack of conflict represents a dangerous situation. One possibility is that everyone thinks and behaves the same way. This represents a lack of diversity in the group that can easily lead to not exploring alternate viewpoints and 'groupthink'. Another possibility is even worse - that team members are afraid to speak up, due to some underlying fear. Most commonly, those who present alternate viewpoints are told that they are not 'team players', and the person in question stops raising objections from then on.

To a certain extent then, conflict is essential. It represents the heterogeneity of the group and leads to the exploration of alternate viewpoints.

It is all too easy however, to get caught up in a situation where you are forever arguing with someone with no end in sight. This happens when good conflict degenerates into dysfunctional conflict. After a point, the arguments are no longer on the merits of each case, but tied into the egos of the participants. A decision at that point takes political connotations and is perceived as an attack against the 'loser' of the conflict, which in turn leads into rapidly deteriorating relationships between all those involved.

Thus we see that conflict can be both good and bad. If you have no conflicts at all, then that is a sign that you need more diversity. In the rest of this article I will only talk about dysfunctional conflict.

Alignment

The first step in conflict resolution is alignment. The most obvious form of conflict is when two individuals/teams/groups are working in opposite directions. There are two possible reasons for this. One reason is that the groups are deliberately sabotaging each other due to political reasons. If this is case, the conflict is just a symptom or some other root cause, and you need to go fix that root cause. You have bigger problems.

The other reason is where both teams think that they are doing the right thing, but because there is no common vision, they are going in opposite directions. Both are convinced that they are doing the right thing and wondering what is going on with the other group. The result is a conflict where both sides are convinced about their righteousness. Resolving these conflicts is simply a matter of aligning both groups to a common vision, which of course is easier said than done and is left as an exercise to the reader :)

Handling conflict

Even when you have two people working to the same goals, it is likely that there will be conflicts in the various ways to get to that target. How can these conflicts be handled?

Acknowledge the conflict: The first step is to acknowledge the conflict. Acknowledge both sides in the conflict. Listen to both sides and make sure that they both get heard. The worst possible course of action is to pretend that a conflict does not exist or ignore it and hope that it goes away. First, it will not go away. Second, people want to be heard. It makes then feel empowered and feel that they are valued. Ignoring the individuals in the conflict sends a message that you don't care for their issues. Simply acknowledging the conflict says that you care about what they are feeling.

Separate the problem from the person: The next step is to separate the problem from the person. In any conflict, both sides have something invested in their position, which ties in their viewpoint with their ego. As long as that exists, it is impossible to solve the problem without making it seem personal. By separating the problem from the person, you can attack the problem without attacking the person.

Attack the problem together: Having got the problem in front of you, you can all discuss the problem together. By solving the problem together, you ensure that both parties will find the final solution acceptable. This is in contrast to mandating a solution, where one party might not like the solution but might accept it in order to close the issue. Remember, resolving a conflict is not about closing the issue, but about a solution that everyone feels good about. If one or both of the groups involved is not satisfied with the solution, you can be sure that the conflict is still simmering under the surface and will come out with more force the next time.

Example: How not to handle conflict

Amy: We need some way to bring new team members up to speed
Bob: We need some documentation
Chris: NO! We don't need more documentation

Amy: Chris, Bob has a lot of experience at this, maybe you should listen to him
Later...
Amy: Chris, you are always arguing with the team. You need to be a team player, not a disrupter
Chris: #$@!#$

The above is a case of attacking the person. Chris is likely to be extremely unhappy at the 'resolution'. Relationships are going to go downhill.

Example: A better way

Amy: We need some way to bring new team members up to speed
Bob: We need some documentation
Chris: NO! We don't need more documentation

Amy: Why do you say that?
Chris: Nobody reads documentation
Amy: Okay, that could be a problem. Bob, what do you think?
Bob: Yes, but the current situation is even worse
Amy: What other alternatives can we think of?
Chris: How about mentoring?
Bob: I'm not sure. We don't have the time to mentor each new person
Chris: Mentoring is the only way to teach the details that get lost in documents
Amy: Maybe we can have a small light document that covers the core areas, and we have mentoring to transfer knowledge of the details?
Chris: Yeah, we could do that
Bob: Good idea

In this case, Amy acknowledges both the team members positions, then attacks the problem, not the person. This allows all three parties to work together as a team to solve the problem.

Handling deep conflict

In some cases, the conflict has already been going on for a while. Both sides have already developed deep mistrust for each other and have their positions firmly entrenched. Solving such a conflict is much harder. The same principles apply as above, but because of the mistrust between parties, they do not want to talk to each other. More effort is expended towards preserving their position than towards resolving the conflict. In such cases, the you will probably need to work with the parties individually, as they will probably not see eye to eye together. The key goal is to change the mindset from defending a position to working towards a resolution. Once that happens, the above principles can be used again.

Most deep conflicts are rooted in certain past events. By understanding the history, it is possible to understand the viewpoints of the two sides and bring them to a resolution.

Example of deep conflict

Developer: The management is out to squeeze every ounce of work out of us. They make us work overtime for no particular reason. I refuse to work this weekend.

Manager: The developers are so unreliable. They keep giving excuses about why something cannot be done. We need to monitor them closely and keep pushing them or nothing would get done.

Another example

Widget team: The application team gets all the support. All the good programmers are there. We never get any support from them. It's better not to work with them if possible.

Application team: The widget teams keep asking us for support. How are we to support them and still get our work done? We need to minimize interaction with those teams.

Conclusion

The next time you face a conflict, keep in mind these three guidelines
  • Acknowledge the conflict
  • Separate the problem from the person
  • Attack the problem together

This post is a part of the selected archive.

Tuesday, September 19, 2006

Testing is...

James Bach provides a great definition:

Testing is the infinite process
of comparing the invisible
to the ambiguous
so as to avoid the unthinkable
happening to the anonymous

Sunday, September 17, 2006

Keep a lookout for these languages

some articles are doing the rounds about the languages to learn, so I decided to add my two cents to the discussion. These are the languages that I have on my radar -
  • Python: I've been using Python for my side projects for the last few years. Needless to say that I like it a lot.
  • JavaScript: Essential if you are going to do anything related to browser client-side coding. With the popularity of AJAX, JavaScript is quickly becoming a language that you need to know.
  • Ruby: Many of the ex-Java coders are moving to Ruby in a big way. The language has gotten another big push with the popularity of Rails. This is on my to-learn list.
  • A functional language: Scheme and Haskell are popular choices. Even if you don't actually use it regularly, learning a functional language is great for completely changing the way you think about programming. One of those experiences was when I got hold of a Scheme interpreter and followed along SICP and HTDP. Both Scheme and Haskell are on my to-learn-more list.
  • Erlang: This is on my to-learn list. I think concurrent programming is going to increase in importance and I've heard a lot about Erlang.
  • Perl: I find it useful as glue in *nix environments, especially if I need to use it's awesome regex capabilities, but don't use it all that often. The syntax is a pain to remember.
  • C/C++/Java/C#: Chances are that your organization uses one of these languages, so you need to know it. That's about the only reason I can think of. Java has some useful libraries and frameworks for it, so that's a plus. Not sure about C#.
  • Maybe someday: Smalltalk !!

Thursday, September 14, 2006

Factory factory factory

Hilarious spoof on over-engineered frameworks. I was literally rolling on the floor laughing, and the best part is that it is all just so true!

Monday, September 11, 2006

What skills do I need to be a good scrummaster?

Based on my experiences, my list would go like this -

Have empathy. This is the most important. Learn continuously. This is the second most important. Apart from these, you need
  • Understanding of the organization and its culture
  • Understanding of the team and its dynamics
  • Understanding of the people on the team
  • Facilitation skills
  • Conflict resolution skills
  • Ability to work with people
  • Ability to coordinate with teams
  • Ability to work with management
  • Ability to solve problems and get things done
What does you list look like?