Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!

Sowmya Karmali

+ Follow
since Mar 30, 2001
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Sowmya Karmali

I am trying to connect to a secure site from a java application (not browser) on a redhat linux 7.2 machine.
The linux machine is behind a firewall.
when i specify the proxyHost and proxyPort (https.proxyHost,https.proxyPort) in my application i
get an IOException saying -
Exception in thread "main" Unable to tunnel through <proxy>.
Proxy returns "HTTP/1.1 200 Connection established"
at URLTunnelReader.main(
This is bcos JSSE currently accepts http/1.0 response only from the proxy.
I found an article on javaworld (tip 111) and did what the article said:
Create a class SSLTunnelSocketFactory that extends SSLSocketFactory, and in that have a method which works around this by looking for the string "200 connection established" instead of "HTTP/1.0 200", which the DefaultSSLSocketFactory does.
Now, the SSL handshake is happening, but the createSocket() method from the proxy to the secure site still fails.

Can anyone tell me why is this happening and is there a workaround available?
thanks and Regards
I have a client that sends HTTP a request to a server. This server is a ServerSocket. I use the HTTPUrlConnection class to connect to the url where the ServerSocket is listening ( http://localhost:12299 ). I send my POST request ( containing an XML.. can I do this??)using the outputstream of the HTTPUrlConnection. Since it is HTTP, I also do a getInputStream on the connection. On the server side, I only seem to be getting the header info ( as a raw stream). I have a feeling that the getInputStream is blocking somewhere, bcos if I forcefully terminate the client (HTTP) the XML reaches the server (ServerSocket).
Anybody enlighten me on this... please

Okay, so we are saying that user stories need not be numbered like inmates of an asylum. I'd love to have the flexibility that comes along with it, but I am worried about a few things.
Dont we need to be able to get all the user stories ( across release plans) together when needed? Don't index cards get misplaced? I mean, dont we need to organise the cards in [I]some[I] way?
When you are ISO/SEI certified, you need to keep a record of all the project documentation and requirements doc is an important one. If these index cards ( the only carriers of the reqs) are not part of the project documentation, then what goes to the audits as a req spec?
Frank,Martin, I would specially appreciate your comments on this.
What I would like to share a way to organise user stories more effectively. Number each sheet, something like MODULENAME/1. There are also user stories that link modules, e.g., A customer may avail only 3 accounts of type 'loan' from a bank. This is a link between the customer and account modules. These user stories would look different from the "independent" stories. Could be a different colour or shape. These would be numbered as CUST-ACC/1, with possible references to the specific user stories(the numbers) in each of the two modules. So a person designing one user story would look at his sheet for references to other user stories, not to code for them, but to make sure that he's on track.
Why doesn't somebody write a tool to write and manage user stories so that XP can be more environment friendly?

[This message has been edited by Sowmya Karmali (edited April 05, 2001).]

Originally posted by Frank Carver:
I feel that the XP "40 hour" rule is partly about balancing work and play,

I completely agree with you, Frank. If I know upfront that I have a fixed number of hours to finish a task then I would probably schedule my activities accordingly. Else, I would say to myself, I'll do it later in the evening or night. I feel the 40 hours is only an issue of managing time professionally. No other methodology lays any emphasis on actual manhours put in, other than XP. Working seven days a week is not going to make things faster for us; if there were 10 days in a week, we'd probably stretch 7 days work to 10.
Configuration Mgmt:
I am talking of using a CM tool. I believe in refactoring, but I'm afraid that we end up with too many unused ( used in the future?) configurable items. Consider that you have a class which you shelf, but it is still a configurable item as per the tool. And if you have a client who wants the source, try explaining to him why these classes are not being used/delivered. It could be that we're not following a proper refactoring methodology and that's how we ended up in this situation. Can anyone suggest a refactoring approach?
I think a inputs to refactoring could arise during a review process. Even with pair programming, it would be effective to have a designer review the code at least once. I feel that PP is not the answer to reviews, they should go hand-in-hand. Moreover, quality audits ( like ISO and SEI) do look for review records.
Confessions of a pair programmer
I have worked as part of a pair in two projects so far, and I place my observations here.
The first thing that arises out of PP is synergy. Within weeks, I found that I was learning more by way of discussion than I would have had I been on my own. Pairing a fresher with an experienced guy sounds ideal, but there is often a "thinking lag" on the part of the fresher, which can be irritating to the pro. What we did was pair freshers, and also get their code reviewed by a more experienced guy. This eases the situation in that the freshers learn from the pro without affecting his productivity.
One more obvious benefit of PP that we found was that we could manage well even if a person was on leave.We did move people around, but that was only on a couple of occasions.
One benefit that I have noticed, years after this activity, is that people who have worked in pairs ( and moving around as well) are capable of taking different points of view when approaching a problem. When pair programmers graduate to pair designers and pair architects, you know you have a good thing going. Pair programmers are more open to criticism, newer ideas, etc.(Look at me )
Of course, I've observed the flip side of it too. Ego clashes, lethargic approach are also part of the game. But these things could exist without PP also; it is upto the more rational people to handle such issues.
[This message has been edited by Sowmya Karmali (edited April 04, 2001).]
Me not an XPert myself, but this is where and how I got started
This is the mother of all XP sites, XPlains all the details of XP XPlicitly.
There are links to Uncle Martin's articles on this site itself
For some dramatic effect, go to
( it is demo on XP practices (?), certainly food for thought, or sermon, junilu ?
Last but not the least, keep coming back to this forum for new insights.
I just got aboard the XP ship about a month ago, and I have been wondering about a few things.
XP advocates refactoring of code,changing and throwing away unwanted pieces. One area which takes a beating on this one is configuration management. For instance, you designed a class 3 weeks ago, which is now about to be chucked out, which you may bring back next month. Is there any way to regulate this, so that we utilise the benefits of both?
Another thing is the absence of reviews. Yeah, pair programming is certainly good(and I have seen the benefits myself, being part of a pair), but this does not mean that we don't need walkthroughs. Is there any reason for reviews to have been left out of XP?
The 40 hour week might not happen from the word go. These are my views on how all of us can keep that weekend date :
Monitor the number of user stories, not only at the end of an iteration, but also during it, so that for the next iteration, the number of user stories can be lowered.
Project specific learning is also an activity that should be estimated for.In all our projects, project specific learing (technical or functional) is accounted for in the timesheets. In this way there are lesser chances that the project will be stretched for time.