If you are playing with Python and eager to get the feel of this wonderful language, you might be already using the interpreter and the in-built GUI "IDLE". I have been using the interpreter to explore the language's various commands and features and its been very easy to use. However, I tried to use the debugging feature of the IDLE tool a few days ago and struggled with it. To me it seemed like someone who has a background of using debuggers in PowerBuilder, Eclipse etc, would find it rather hard to grasp. So if you think you dont know your way around the IDLE bugger, here are the steps. Once you follow these, it will actually be quite easy to debug your favorite Python script. The hard part is getting used to it, but I am sure we can suffer through a little discomfort - just for the sake of Python!
1. Start up IDLE and as soon as the shell launches, click on 'Debug' menu and then 'Debugger'. This will open up the Debug popup. Do not close this throughout the session.
2. Make sure to check all 4 checkboxes, including 'Source' and 'Globals' (Why this is necessary is explained further below)
3. Open up the file you want to debug using 'File/Open'.
4. Right-click on the line you want to set a breakpoint on and click 'Set Breakpoint'.
5. On the menu of the window on which you have opened the file, click 'Run' and then 'Run module'.
This should start the debug process.
This debug feature also debugs any code you enter through the interpreter! So if you start the debugger as outlined above in steps 1 and 2, and then type commands on the interpreter, it will open up the relevant file and walk you through the source. Cool huh??
A couple of glitches: If you dont check the 'Source' checkbox on the debug popup, you will not be able to see the interpreter going through each line of the code. Also, even if you check the 'Source' checkbox, you will be able to see the lines being highlighted only if you take the focus away from the debug popup and set the focus on the window with the source file (say by clicking on the titlebar of the window)
Other than that, the IDLE debugger is very handy in giving you a picture of how the code progresses. As any good developer would say, debugging should NOT be the only way to explore a program but its a good thing to switch back to sometimes!
Tuesday, November 22, 2005
Tuesday, November 15, 2005
What makes a good IT manager?
Sometime back while commenting on a blog entry by Ravi, I managed to elucidate what my idea was of a good IT manager.
1. Someone who makes every team member comfortable in his presence. This is actually very difficult to achieve and has to be done only by letting one's guard down, admitting there are areas which the manager doesn't himself understand, and is very eager to go a developer for help.
2. If the developer is having a technical problem the manager says "hmm cmon lets see how this will work" and actually sits down, pairs with him to do a tracer bullet - a small proof of concept.
3. The manager should show by his actions that he is concerned by the well-being of the team. This means hes genuinely interested in the developers career growth and to some extent personal issues.
4. Last but most important, he sits with the team and all the team members sit together. I am a very strong proponent of this and really cringe when I see people isolated in cubes.
This might be in conflict with some people that think managing is removed from the technical aspect of what the manager manages, but I believe that the opinion is flawed. In short, if the manager has not had adequate technical history, he will always be found wanting regardless of how good he is at dealing with people. This of course assumes that the role of the manager is to make sure that the product or service developed by the "workers" is delivered on time to the customers and reasonably within budget.
1. Someone who makes every team member comfortable in his presence. This is actually very difficult to achieve and has to be done only by letting one's guard down, admitting there are areas which the manager doesn't himself understand, and is very eager to go a developer for help.
2. If the developer is having a technical problem the manager says "hmm cmon lets see how this will work" and actually sits down, pairs with him to do a tracer bullet - a small proof of concept.
3. The manager should show by his actions that he is concerned by the well-being of the team. This means hes genuinely interested in the developers career growth and to some extent personal issues.
4. Last but most important, he sits with the team and all the team members sit together. I am a very strong proponent of this and really cringe when I see people isolated in cubes.
This might be in conflict with some people that think managing is removed from the technical aspect of what the manager manages, but I believe that the opinion is flawed. In short, if the manager has not had adequate technical history, he will always be found wanting regardless of how good he is at dealing with people. This of course assumes that the role of the manager is to make sure that the product or service developed by the "workers" is delivered on time to the customers and reasonably within budget.
Subscribe to:
Posts (Atom)