| Home | | | Techie Talk | | | Story Time | | | About | | | Contact |
Tuesday, September 09, 2008
Tuesday, December 04, 2007
Alae.. Alae.. Alae.. Alae..
Few months back, when I had nothing to do, posted a blog on Debugging. Few of my friends said it was interesting - not to mention they all have a good sense of humor.Today, Brian Whaley, a blogger from US, says the afore mentioned post in one of the great articles on the Methodology of Debugging!!!! (Link to his post HERE)
Alae.. Alae.. Alae.. Alae..
Labels: Daily Life, debugging, software engineering
Thursday, May 17, 2007
A simple mistake can take your whole day, away!!!
Today I had to implement a small task related to Windows Active Directory in our product. The base for this had already been implemented in C language, few months ago. Just a wrapper code was to be written in Java, today.
The input for this would be 1. Domain Name, 2. login Name 3. Password.
Everything worked fine if all these parameters were passed as individual texts - i,e. login name without the domain prefix
Its normal for few Windows users to enter the login name with the domain prefix i,e. something like "DomainName\LoginName"
So to handle such cases, I wanted to
1. check if the character '\' is present in the login name,
2. If present, split the string and take the login name alone
This is what I used from Java for step (2)
//*** Assume oldLoginName = domainName\loginName
int i = oldLoginName.indexof('\');
//*** this should be '\\'. Using '\' for better understanding
int l = oldLoginName.length();
String newLoginName = oldLoginName.substring(i,l);
and then pass the newLoginName as the parameter to the native implementation.
Bhooooom!!!! Nothing happened as expected. When I looked at the logs, the input paremeters were right.
So I assumed the problem should somewhere be in the C implentation - especially while converting the Java String to C String.
Analyzed the C code that was written several months ago - Nothing helped!
Browsed through several sites to find if Java to C conversion of Strings had any problem - even this didn't help!!
Starred at my computer monitor for sometime, as if it would obey my words - This toooo didnt HELP!!!
Again thinking the problem should be in conversion, printed the length of C String in the log files.
This time A BIG BHOOOOOOOM!!!
The length was one more than the actual length of login name, that was expected.
Now I got where the problem was. The substring(...) method in Java would return a string extrated from the parent string - from the start Index to the End Index. My falut is that I had passed the index of '\' as the start index which means that character will also be present in the new extracted string.
All I wanted was "loginName" but by a very simple mistake i had extracted "\loginName"
Then why didn't the debug messages in the log show me this???
Very simple - '\' is an escape sequence and the hence the log file had skipped it while displaying.
I love the challenges in the software profession but never thought so much of efforts would be required to understand just two lines of code.
Good learning - alas a very costly one!!!
The input for this would be 1. Domain Name, 2. login Name 3. Password.
Everything worked fine if all these parameters were passed as individual texts - i,e. login name without the domain prefix
Its normal for few Windows users to enter the login name with the domain prefix i,e. something like "DomainName\LoginName"
So to handle such cases, I wanted to
1. check if the character '\' is present in the login name,
2. If present, split the string and take the login name alone
This is what I used from Java for step (2)
//*** Assume oldLoginName = domainName\loginName
int i = oldLoginName.indexof('\');
//*** this should be '\\'. Using '\' for better understanding
int l = oldLoginName.length();
String newLoginName = oldLoginName.substring(i,l);
and then pass the newLoginName as the parameter to the native implementation.
Bhooooom!!!! Nothing happened as expected. When I looked at the logs, the input paremeters were right.
So I assumed the problem should somewhere be in the C implentation - especially while converting the Java String to C String.
Analyzed the C code that was written several months ago - Nothing helped!
Browsed through several sites to find if Java to C conversion of Strings had any problem - even this didn't help!!
Starred at my computer monitor for sometime, as if it would obey my words - This toooo didnt HELP!!!
Again thinking the problem should be in conversion, printed the length of C String in the log files.
This time A BIG BHOOOOOOOM!!!
The length was one more than the actual length of login name, that was expected.
Now I got where the problem was. The substring(...) method in Java would return a string extrated from the parent string - from the start Index to the End Index. My falut is that I had passed the index of '\' as the start index which means that character will also be present in the new extracted string.
All I wanted was "loginName" but by a very simple mistake i had extracted "\loginName"
Then why didn't the debug messages in the log show me this???
Very simple - '\' is an escape sequence and the hence the log file had skipped it while displaying.
I love the challenges in the software profession but never thought so much of efforts would be required to understand just two lines of code.
Good learning - alas a very costly one!!!
Labels: debugging, software engineering
Saturday, April 14, 2007
Debugging tips for New software engineers
I feel Debugging is the toughest part of the software profession. One will have to spend lots of hours breaking the head to trace these bugs. At the same time, the satisfaction that we get when a bug is solved has no limit.
Now with some exprience in the field of software developement, I wanted to share some my learninings with the new software engineers. This isn't going to be a professional detailed procedure for the Debugging process. These are just the things that needs to be done before debugging an unexpected behaviour.
# 1 : Understand the code.
This is the most important tip for the best debugging process. Only when you clearly know what is happening at the base level, you ll be able to trace the cause of the problem. As far as possible avoid BLINDLY copying the code. I m not against reusing the codes, I stress not to use the codes without understanding what its functionlity and dependency.
# 2 : Do not panic.
I see many people get tensed when a bug is found in their code. Bugs aren't bane, infact they are one of the beauties of this field. Everyone puts bug - hence do not panic when there is a bug in the code you had written.
Now with some exprience in the field of software developement, I wanted to share some my learninings with the new software engineers. This isn't going to be a professional detailed procedure for the Debugging process. These are just the things that needs to be done before debugging an unexpected behaviour.
# 1 : Understand the code.
This is the most important tip for the best debugging process. Only when you clearly know what is happening at the base level, you ll be able to trace the cause of the problem. As far as possible avoid BLINDLY copying the code. I m not against reusing the codes, I stress not to use the codes without understanding what its functionlity and dependency.
# 2 : Do not panic.
I see many people get tensed when a bug is found in their code. Bugs aren't bane, infact they are one of the beauties of this field. Everyone puts bug - hence do not panic when there is a bug in the code you had written.
Be happy that the bug had come out at an earlier stage. When it is solved, the users will not be facing the problem again. Always take it as a learning oppurtunity and see to that such things never happen again.
# 3 : Prioritise the complexity and time availability.
This is another important decision to be taken. Carefully analyze the bug and prioritise the bug. Lets have two basic level for this:
Type 1 - Bug to be solved immediately,
Type 2 - Bug that can be solved slowly, i,e. Not an urgent issue and time can be taken for solving the problem.
# 4 : Do Not run for help Immediately.
Yes I really mean this. This is the most common mistake we do very often. When there is a bug DO NOT approach the seniors immediately. One main reason is that this habbit will never make you learn in your own.
Software Engineering isn't a spoon-feeding profession. Your senior will not always be there to solve your bugs - hence it is very important to make attempt to stand in your own.
Hence whenever there is a problem, think, analyze and try to check if you could solve it in your own. Browse the discussion forums in the internet for help. Even if the problem isn't solved, this will make you learn new things related to your task.
#5 : Seek the seniors for Help at the right time.
Well this might be a little contradict to the previous one. If the bug is to be solved immediately, you may spend 15-30 mins (say apprx. 1 hour for type 2 bug) to check if you could solve it in your own. If it takes more time, then approach the seniors for help immediately. Their experi ence will help you or they might redirect you to the right source.
Whats more interesting here is, sometimes while explaining the problem to others, you yourself might get the resolution flashing in you mind. [;-)]
#6 : Discuss with the senior engineers.
This is more important if you had solved the problem in your own. Tell the senior about the problem and the solution you had applied. Sometimes he might have a better solution than the one you had applied. If his is a better one, do not worry about the efforts you had put. A discarded effort is always better learning than the unattempted efforts.
After all life is a learning process. Isn't it? [;-)]
This is another important decision to be taken. Carefully analyze the bug and prioritise the bug. Lets have two basic level for this:
Type 1 - Bug to be solved immediately,
Type 2 - Bug that can be solved slowly, i,e. Not an urgent issue and time can be taken for solving the problem.
# 4 : Do Not run for help Immediately.
Yes I really mean this. This is the most common mistake we do very often. When there is a bug DO NOT approach the seniors immediately. One main reason is that this habbit will never make you learn in your own.
Software Engineering isn't a spoon-feeding profession. Your senior will not always be there to solve your bugs - hence it is very important to make attempt to stand in your own.
Hence whenever there is a problem, think, analyze and try to check if you could solve it in your own. Browse the discussion forums in the internet for help. Even if the problem isn't solved, this will make you learn new things related to your task.
#5 : Seek the seniors for Help at the right time.
Well this might be a little contradict to the previous one. If the bug is to be solved immediately, you may spend 15-30 mins (say apprx. 1 hour for type 2 bug) to check if you could solve it in your own. If it takes more time, then approach the seniors for help immediately. Their experi ence will help you or they might redirect you to the right source.
Whats more interesting here is, sometimes while explaining the problem to others, you yourself might get the resolution flashing in you mind. [;-)]
#6 : Discuss with the senior engineers.
This is more important if you had solved the problem in your own. Tell the senior about the problem and the solution you had applied. Sometimes he might have a better solution than the one you had applied. If his is a better one, do not worry about the efforts you had put. A discarded effort is always better learning than the unattempted efforts.
After all life is a learning process. Isn't it? [;-)]
Labels: debugging, software engineering

