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.
Monday, October 03, 2005
Convention over configuration...but of course!
I have been reading and working out examples in the book Agile Web Development with Rails, written by Dave Thomas and David Heinemeier Hansson. I discovered rails about 6 months ago and started reading about it. I was fascinated by the simplicity and the ease of development that it offered in quickly putting together a fully functional web application. Needless to say, in just over a year after its creation, it has captured the hearts and minds of programmers and web designers alike.
There are many facets to rails that make it worthy of being the one of the foremost choices in developing web applications, like clear separation of model view controller functionality and in-built testing support - besides the inherent advantage of having a dynamic language like Ruby at its core. However, there is one more rarely-exploited paradigm that it uses that really struck a chord with me - the fact that it stresses "convention over configuration". Rails does not have XML files for specifying the configuration aspects of the application. It assumes certain values and uses those to power the rest of the application.
What does this exactly mean? It means that configuration information is already predetermined by rails and it urges the programmer to name objects a certain way and put files and resources in specific predetermined directories. One would think that this is very restrictive, but the fact is that it doesnt seem restrictive at all when most of it is done by the framework itself! It creates the directories, creates the templates for the files, so that what falls on the shoulders of the programmer is the actual business logic. It is like it says, "Dont worry about maintaining configuration info, I will lay it out and make sure its all in place. You just worry about implementing the requirements in code."
Imagine what this means in terms of application maintenance. A new programmer entrusted with making changes to a rails application coded by another developer already knows where everything is, and how the basic components are named. No flailing around trying to make sense of variable and object names!
It definitely is worthwhile trying out and working on a framework that works on the "convention over configuration" principle. This may not be for all, but is perfect for a framework if it has to be true to its promise of blazing speed in putting together a working application. And Rails does a great job there, no question.
There are many facets to rails that make it worthy of being the one of the foremost choices in developing web applications, like clear separation of model view controller functionality and in-built testing support - besides the inherent advantage of having a dynamic language like Ruby at its core. However, there is one more rarely-exploited paradigm that it uses that really struck a chord with me - the fact that it stresses "convention over configuration". Rails does not have XML files for specifying the configuration aspects of the application. It assumes certain values and uses those to power the rest of the application.
What does this exactly mean? It means that configuration information is already predetermined by rails and it urges the programmer to name objects a certain way and put files and resources in specific predetermined directories. One would think that this is very restrictive, but the fact is that it doesnt seem restrictive at all when most of it is done by the framework itself! It creates the directories, creates the templates for the files, so that what falls on the shoulders of the programmer is the actual business logic. It is like it says, "Dont worry about maintaining configuration info, I will lay it out and make sure its all in place. You just worry about implementing the requirements in code."
Imagine what this means in terms of application maintenance. A new programmer entrusted with making changes to a rails application coded by another developer already knows where everything is, and how the basic components are named. No flailing around trying to make sense of variable and object names!
It definitely is worthwhile trying out and working on a framework that works on the "convention over configuration" principle. This may not be for all, but is perfect for a framework if it has to be true to its promise of blazing speed in putting together a working application. And Rails does a great job there, no question.
Tuesday, September 13, 2005
The Craft of Classification
Ravi mohan writes another thought-provoking post on this blog in response to the notion of classifying programmers into 3 categories - apprentice, journeyman and master.
I have to admit I was a bit swayed by Pete mcBreen's book when I first read it - mainly because I had read about that idea for the first time. But then Ravi is onto something when he shows how that classification may have no real value. The book talks about a situation where it says its okay for a "master" to learn a new language from an "apprentice" and that this doesnt invalidate him of his current category of "master". How is this possible? A student is always supposed to see himself as lower in that relative situation when he learns something from a teacher.
When Pete McBreen and others advocate this idea, I suspect they have an underlying assumption about the quality of the learning. Maybe they are saying that the master already has the fundamental concepts down(which is a higher quality of learning) and he just learns another language syntax which is of a lower quality of learning. But will this always be the case?
Imagine a UNIX guru in the league of Eric Raymond or Richard Stallman. Lets call him Mr X. He has been working on UNIX for years and written dozens of open-source tools, is very active in communities and is usually approached when his UNIX peers have issues. According to McBreen, he would be a master. Lets say he is hired by a shop that does development mostly in UNIX tools but also have a smattering of applications in Scheme. He starts working with a candidate who has a good knowledge of Scheme but is not active in the public domain (as a result of which he is not well-known). Now, I am sure Mr X will definitely not breeze through Scheme, since its not just a new language - it requires a different way of thinking. Now in this situation, there is a lot of "higher" quality learning involved where the "master" learns from the "apprentice". Whos the master here then?
All my thoughts are based on the following premise:
There are too many varied things in software for them to be grouped into a "general" category that somebody can be said to be good at.
If somebody has sound concepts of OO design, he may be quick to pick up Java, C, C++, C#, etc but it may not be easy to pick up Python or Ruby or Smalltalk. That is to say, it will not be easy to think "the Ruby way". And also by the same token, sound programming concepts in even Python or Ruby or any language will not make you a good webdesigner, adept at CSS, HTML or Flash.
I guess then what can conclude is:
1. The only thing one can categorize a person is with respect to a particular paradigm and/or language ("OO programming", "Functional programming" is a paradigm - "Java", even ".NET" is a language for purposes of explaining). If he has to work on another area he doesnt know, he is a novice there and there is nothing wrong with that fact. So Mr X is a UNIX "master" but an "apprentice" in Scheme. There is nothing wrong with a classification which relates to a particular technology/paradigm/language/framework.
2. The only way to categorize a person with respect to a technology is by seeing his work.
There can be no other parameter. No writings, no talks, or drawing on the board. Now, the question is, how do you know if his work is good? Sadly, it cant be judged right away. This can only be decided over a period of time. Say over a course of 2,3,5 years, how many times was it changed? How easy was it to change? Has he constantly delivered running, "not-getting-in-the-way" software to the users?
After reading McBreens book, I started thinking, "I am an apprentice now..I want to be a journeyman in X years, and then a master in a another Y years." Looks like it wont work. I am now going to say - "I know java and I want to learn Python this year. Next year I will dig into Scheme. And hey, OCAML looks interesting, why not try it after that?" And when I get that job in the Python firm that wants me to maintain some apps in Erlang on the side, I will seek out the "Erlang guy" and become his "apprentice"!
I have to admit I was a bit swayed by Pete mcBreen's book when I first read it - mainly because I had read about that idea for the first time. But then Ravi is onto something when he shows how that classification may have no real value. The book talks about a situation where it says its okay for a "master" to learn a new language from an "apprentice" and that this doesnt invalidate him of his current category of "master". How is this possible? A student is always supposed to see himself as lower in that relative situation when he learns something from a teacher.
When Pete McBreen and others advocate this idea, I suspect they have an underlying assumption about the quality of the learning. Maybe they are saying that the master already has the fundamental concepts down(which is a higher quality of learning) and he just learns another language syntax which is of a lower quality of learning. But will this always be the case?
Imagine a UNIX guru in the league of Eric Raymond or Richard Stallman. Lets call him Mr X. He has been working on UNIX for years and written dozens of open-source tools, is very active in communities and is usually approached when his UNIX peers have issues. According to McBreen, he would be a master. Lets say he is hired by a shop that does development mostly in UNIX tools but also have a smattering of applications in Scheme. He starts working with a candidate who has a good knowledge of Scheme but is not active in the public domain (as a result of which he is not well-known). Now, I am sure Mr X will definitely not breeze through Scheme, since its not just a new language - it requires a different way of thinking. Now in this situation, there is a lot of "higher" quality learning involved where the "master" learns from the "apprentice". Whos the master here then?
All my thoughts are based on the following premise:
There are too many varied things in software for them to be grouped into a "general" category that somebody can be said to be good at.
If somebody has sound concepts of OO design, he may be quick to pick up Java, C, C++, C#, etc but it may not be easy to pick up Python or Ruby or Smalltalk. That is to say, it will not be easy to think "the Ruby way". And also by the same token, sound programming concepts in even Python or Ruby or any language will not make you a good webdesigner, adept at CSS, HTML or Flash.
I guess then what can conclude is:
1. The only thing one can categorize a person is with respect to a particular paradigm and/or language ("OO programming", "Functional programming" is a paradigm - "Java", even ".NET" is a language for purposes of explaining). If he has to work on another area he doesnt know, he is a novice there and there is nothing wrong with that fact. So Mr X is a UNIX "master" but an "apprentice" in Scheme. There is nothing wrong with a classification which relates to a particular technology/paradigm/language/framework.
2. The only way to categorize a person with respect to a technology is by seeing his work.
There can be no other parameter. No writings, no talks, or drawing on the board. Now, the question is, how do you know if his work is good? Sadly, it cant be judged right away. This can only be decided over a period of time. Say over a course of 2,3,5 years, how many times was it changed? How easy was it to change? Has he constantly delivered running, "not-getting-in-the-way" software to the users?
After reading McBreens book, I started thinking, "I am an apprentice now..I want to be a journeyman in X years, and then a master in a another Y years." Looks like it wont work. I am now going to say - "I know java and I want to learn Python this year. Next year I will dig into Scheme. And hey, OCAML looks interesting, why not try it after that?" And when I get that job in the Python firm that wants me to maintain some apps in Erlang on the side, I will seek out the "Erlang guy" and become his "apprentice"!
Wednesday, August 24, 2005
This may work...
I think writing and keeping an online journal does help in quite a few ways. This weblog is to explore, refine, clarify and elucidate ideas in software development - a profession that has helped me earn a living, and by virtue of doing which continuously for a few years, I have developed a deep interest and love for. This interest is the result of a cycle that has been set in motion by a yearning to learn more about it so that one can be better, which in turn infuses in one an enthusiasm to learn more just because they enjoy their achievements attained by learning.
The interesting about this is now I feel that I am in a different plane of existence. Seems like the constant spinning of the cycle has catapulted me into a different mental state, where I feel there is so much more to learn and knowledge seems never-ending. This is different from my previous plane of existence, where I was doing just what was supposed to be done, limiting myself to only knowledge of my specialization.
I must admit that at first, this new mental state left me more insecure, as its like exposing a huge waterfall to a camel thats happy drinking just the small amounts of water available in the desert. But then I realized that it is necessary to see the waterfall so that you can get an idea of how small the desert water sources are. And it is necessary to know that the water sources are small. It is necessary to know that you are ignorant....because only then can you think about achieving mastery.
The interesting about this is now I feel that I am in a different plane of existence. Seems like the constant spinning of the cycle has catapulted me into a different mental state, where I feel there is so much more to learn and knowledge seems never-ending. This is different from my previous plane of existence, where I was doing just what was supposed to be done, limiting myself to only knowledge of my specialization.
I must admit that at first, this new mental state left me more insecure, as its like exposing a huge waterfall to a camel thats happy drinking just the small amounts of water available in the desert. But then I realized that it is necessary to see the waterfall so that you can get an idea of how small the desert water sources are. And it is necessary to know that the water sources are small. It is necessary to know that you are ignorant....because only then can you think about achieving mastery.
Subscribe to:
Posts (Atom)