Loading ...
Sorry, an error occurred while loading the content.

unsubscribe

Expand Messages
  • Helmut Krendl
    unsubscribe
    Message 1 of 20 , Aug 23, 2000
    • 0 Attachment
      unsubscribe
    • Mark Haack
      unsubscribe
      Message 2 of 20 , Sep 10, 2000
      • 0 Attachment
        unsubscribe
      • Chris Fleming
        unsubscribe -- Chris Fleming phone: (513) 576-5906 SDRC FAX: (513) 576-7592 2000 Eastman Dr.
        Message 3 of 20 , Feb 8, 2001
        • 0 Attachment
          unsubscribe

          --
          Chris Fleming phone: (513) 576-5906
          SDRC FAX: (513) 576-7592
          2000 Eastman Dr. Milford, OH 45150 email: chris.fleming@...
          GO RED WINGS!!!
        • Bretz, Matt
          ... From: extremeprogramming@yahoogroups.com [mailto:extremeprogramming@yahoogroups.com] Sent: Monday, April 30, 2001 2:22 PM To:
          Message 4 of 20 , May 1 5:31 AM
          • 0 Attachment
            -----Original Message-----
            From: extremeprogramming@yahoogroups.com
            [mailto:extremeprogramming@yahoogroups.com]
            Sent: Monday, April 30, 2001 2:22 PM
            To: extremeprogramming@yahoogroups.com
            Subject: [XP] Digest Number 1064


            To Post a message, send it to: extremeprogramming@...

            To Unsubscribe, send a blank message to:
            extremeprogramming-unsubscribe@...

            Don't miss XP UNIVERSE, the first US conference on XP and Agile Methods.
            Early registration discounts EXTENDED until May 1, 2001. www.xpuniverse.com
            for details and registration.
            ------------------------------------------------------------------------

            There are 25 messages in this issue.

            Topics in this digest:

            1. Re: Reuseability
            From: "Nick Fortescue" <nick@...>
            2. Re: Reuseability
            From: davechaplin@...
            3. Re: XP/R - Extreme Programming/Remote
            From: kentbeck@...
            4. Re: Re: Reuseability
            From: Dan Palanza <dan@...>
            5. Re: XP/R - Extreme Programming/Remote
            From: Ron Jeffries <ronjeffries@...>
            6. Re: Reusability
            From: Ralph Johnson <johnson@...>
            7. Studies on XP searched
            From: Astrid Schroeder <schroeda@...-muenchen.de>
            8. Re: Reuseability
            From: Kenneth Tyler <kentyler@...>
            9.
            From: "Moss, D" <dmoss@...>
            10. Re: Reuseability
            From: "Nick Fortescue" <nick@...>
            11. Re: all OO programmers should learn design patterns
            From: Andrew Hunt <andy@...>
            12. Re: Refactorings Paper
            From: lindstrom@...
            13. Developing a secure link
            From: Angus Mezick <amezick@...>
            14. Re: Reusability
            From: Kevin Smith <sent@...>
            15. Re: Developing a secure link
            From: Ron Jeffries <ronjeffries@...>
            16. Re: Developing a secure link
            From: Angus Mezick <amezick@...>
            17. Re:
            From: Ron Jeffries <ronjeffries@...>
            18. Re: Developing a secure link
            From: "Paul Gunn" <pgunn@...>
            19. Re: Re:
            From: Angus Mezick <amezick@...>
            20. Re: Reuseability
            From: azami@...
            21. Re: Studies on XP searched
            From: "Lee" <lvbis@...>
            22. Re: Studies on XP searched
            From: "Lee" <lvbis@...>
            23. Re: Re: secure programming
            From: "Nick Fortescue" <nick@...>
            24. Re: Re:
            From: wecaputo@...
            25. How to use design patterns.
            From: rmartin@...


            ________________________________________________________________________
            ________________________________________________________________________

            Message: 1
            Date: Mon, 30 Apr 2001 10:28:11 +0100
            From: "Nick Fortescue" <nick@...>
            Subject: Re: Reuseability


            From: <mattias@...>


            > Hi!
            >
            > I am currently working with a project which is working out how
            > reusability and design patterns would increase the value of the
            > defense software projects in Sweden.
            >
            > Of course I will try to trick them into adopting some agile software
            > development process (not straight XP because of the size of the
            > projects and the addiction to a certain amount of paperwork), but the
            > thing is how to do that when the very main subject on the study is
            > REUSE.

            First comment: XP should never be about tricking (I wouldn't know about
            Defense Department politics) XP values are communication (ie honesty) and
            courage. Every project should have buy in. Present the facts, and if someone
            makes a different decision so be it.

            > One tip is to reuse the tests.
            >
            > How have you done? Are there never one single reused code-line in
            > your different XP projects?
            >
            > Can the refactorings lead to objects that are easier to reuse?
            > Or can you reuse a few objects and refactor them into a new design
            > (reuse of tests included here)?

            I'd be interested in others' feedback here. I believe refactoring and reuse
            are fundamentally opposed, which is tricky because I believe strongly in
            both of them. In much refactoring, like factoring out some functionality you
            have to change every dependence on the original code. In cases where that
            code is used in many projects that can lead to huge amounts of work, ie
            reuse makes refactoring much harder. On the other hand refactored code tends
            to be of cleaner design, and so reuse is easier.

            My attitude at the moment is that when code is first written constant
            refactoring is good, as it improves the design based on lessons learnt about
            implementation. When code reuse starts, interfaces become hardened and
            cannot be refactored. Of course, the implementation can be, but some
            flexibility is lost. What do others think?

            Nick Fortescue





            ________________________________________________________________________
            ________________________________________________________________________

            Message: 2
            Date: Mon, 30 Apr 2001 09:20:32 -0000
            From: davechaplin@...
            Subject: Re: Reuseability

            Mattias,

            In my view Design Patterns are essential knowledge for anyone doing
            OO projects. They are the language of communicating part of the
            design. I consider them analogous to building roads - you use a bunch
            of designs (roundabouts, junctions, tunnels etc). If you have to keep
            explaining what a tunnel is to other programmers it takes too long
            and you can suffer from poor communication.

            In terms of re-use of code: If you are using a tiered architecure,
            then you should be able to re-use any data Providers at the back end,
            together with any utility libraries. In terms of re-using code from
            the domain model - I would not bother, other than ripping it out and
            pasting it into newly designed code. I've found this useful for
            serilaisation/deserialisation code.

            In my view, the best form of re-use is a common architectural
            framework. e.g. One I swear by is: Presentation, Process, Business
            Model, Commands, Providers, Data sources.

            Good luck....!

            Dave Chaplin

            --- In extremeprogramming@y..., mattias@s... wrote:
            > Hi!
            >
            > I am currently working with a project which is working out how
            > reusability and design patterns would increase the value of the
            > defense software projects in Sweden.
            >
            > Of course I will try to trick them into adopting some agile
            software
            > development process (not straight XP because of the size of the
            > projects and the addiction to a certain amount of paperwork), but
            the
            > thing is how to do that when the very main subject on the study is
            > REUSE.
            >
            > One tip is to reuse the tests.
            >
            > How have you done? Are there never one single reused code-line in
            > your different XP projects?
            >
            > Can the refactorings lead to objects that are easier to reuse?
            > Or can you reuse a few objects and refactor them into a new design
            > (reuse of tests included here)?
            >
            > Any suggestions are welcome
            > /Mattias
            >
            > P.S. I have been following the discussion on design patterns, and
            it
            > was very helpful. Lots of good thoughts. Thanks! D.S.



            ________________________________________________________________________
            ________________________________________________________________________

            Message: 3
            Date: Mon, 30 Apr 2001 09:51:30 -0000
            From: kentbeck@...
            Subject: Re: XP/R - Extreme Programming/Remote

            --- In extremeprogramming@y..., "Chris McKinstry" <kcmckinstry@h...>
            wrote:
            > I don't believe there is any such thing as creep. As soon as I hear
            > someone who claims to get XP say creep, I know they don't.

            Please don't hand me straight lines like this. Please. Jeffries, you
            owe me one.

            Kent



            ________________________________________________________________________
            ________________________________________________________________________

            Message: 4
            Date: Mon, 30 Apr 2001 06:27:30 -0400
            From: Dan Palanza <dan@...>
            Subject: Re: Re: Reuseability

            At 09:20 AM 4/30/01 -0000, Dave Chaplin wrote:

            >In my view Design Patterns are essential knowledge for anyone doing
            >OO projects. They are the language of communicating part of the
            >design. I consider them analogous to building roads - you use a bunch
            >of designs (roundabouts, junctions, tunnels etc). If you have to keep
            >explaining what a tunnel is to other programmers it takes too long
            >and you can suffer from poor communication.

            You have described precisely how Alexander first approached pattern study.
            That type of focus on things led him, and his group, to write the book, "A
            Pattern Language." Then he found a deeper pattern image. e.g., Every
            roundabout has certain categories of concern:
            (1) each pattern has a body made up of 'resources';
            (2) resources get worked-generated--into a 'product';
            (3) construction, design, and use describe a 'history';
            (4) history's best interests are decided in rules of 'policy'.

            Clearly, 'junction' and 'tunnel' and indeed all 'patterns' have these same
            four categories of concern that a roundabout has. All patterns, in that
            patterns are both a thing and an idea, are implemented as resources made
            into product by ideas. Ideas that move resources to product generate a real
            history worth recording, to enable reuse. What's more, history will
            influence policy that will decide how each pattern is to be constructed and
            used.

            Universals offer a different way to look at pattern discovery.

            >In my view, the best form of re-use is a common architectural
            >framework. e.g. One I swear by is: Presentation, Process, Business
            >Model, Commands, Providers, Data sources.

            I think you are headed in the same direction--toward universal
            patterns--with the categories you have found useful to differentiate, and
            follow, above.

            In bookkeeping the 'architectural framework' that best served reuse became
            a small number of universal categories. The framework that these categories
            created then became the test framework for the application of accounting.
            IOW bookkeeping is the test for accounting.

            My guess is that when the XP dust settles there will emerge a universal
            test framework for the application of computer programs.

            Dan




            ________________________________________________________________________
            ________________________________________________________________________

            Message: 5
            Date: Mon, 30 Apr 2001 07:19:41 -0400
            From: Ron Jeffries <ronjeffries@...>
            Subject: Re: XP/R - Extreme Programming/Remote

            Responding to kentbeck@... (09:51 AM 4/30/2001 +0000):
            >--- In extremeprogramming@y..., "Chris McKinstry" <kcmckinstry@h...>
            >wrote:
            > > I don't believe there is any such thing as creep. As soon as I hear
            > > someone who claims to get XP say creep, I know they don't.
            >
            >Please don't hand me straight lines like this. Please. Jeffries, you
            >owe me one.

            I owe you many, Kent, but not for this one AFAICS.

            R




            ________________________________________________________________________
            ________________________________________________________________________

            Message: 6
            Date: Mon, 30 Apr 2001 06:25:03 -0500 (CDT)
            From: Ralph Johnson <johnson@...>
            Subject: Re: Reusability

            The customer has said that reusability is a requirement, so
            I suppose by the rules of XP, it is OK to assume it is needed.
            But that fact is that a lot of people say they want reusability
            when it is not cost-effective.

            Here is how to do it. Come up with a set of applications that
            would be built with your reusable software. This will be your
            "user stories". It is good if they span the range of applications
            that will eventually be built, but usually you will miss some.
            Then build applications, one at a time. Separate the software
            into the part that is shared by the applications, and the part
            that is not. Each new application will require refactoring the
            shared part, which will require refactoring the non-shared part.
            This is just part of the cost of developing reusable software.
            After you have made three or four applications on one code base,
            you'll discover that the amount of changes to the reusable part
            goes way down. The software is now in fact reusable. Build
            some more applications, and you can now do them in parallel.

            Note that refactoring the reused code will force you to refactor
            the old applications. The alternative is to have several versions
            of the reused code, and that is worse, because you do not know for
            sure whether your new version "runs the old tests", i.e. is really
            compatible with the requirements of the old applications. Keep
            one version of the code as long as possible, and just keep refactoring
            your old applications. Once you send the code to other groups, you
            won't have the luxury of only supporting one version.

            -Ralph Johnson



            ________________________________________________________________________
            ________________________________________________________________________

            Message: 7
            Date: Mon, 30 Apr 2001 13:40:43 +0200 (MEST)
            From: Astrid Schroeder <schroeda@...-muenchen.de>
            Subject: Studies on XP searched


            Hello!

            I'm a student of Computer Science at Munich University of Technology,
            Germany. I'm doing my master's thesis about Extreme Programming (XP).

            For this reason I'm searching for studies on XP and its techniques. I
            already found a study on Pair Programming by Laurie Williams, but I'm
            searching for more, so if perhaps anyone knows a study or has an idea
            where to find one, I'd appreciate if you could tell me.

            Furthermore, as a focus of my thesis is to find out how XP is applied in
            fact and how it can be improved, I would be glad, if you do an X Project
            or you are an XP consultant, if you could fill in the little questionnaire
            found at

            http://www4.informatik.tu-muenchen.de/~rumpe/questionnaire.txt
            respectively
            http://www4.informatik.tu-muenchen.de/~rumpe/questionnaire.doc

            and email it to schroeda@... as soon as possible.

            Thanks!

            Astrid





            ________________________________________________________________________
            ________________________________________________________________________

            Message: 8
            Date: Mon, 30 Apr 2001 06:42:49 -0700
            From: Kenneth Tyler <kentyler@...>
            Subject: Re: Reuseability

            ...
            >My attitude at the moment is that when code is first written constant
            >refactoring is good, as it improves the design based on lessons learnt
            about
            >implementation. When code reuse starts, interfaces become hardened and
            >cannot be refactored. Of course, the implementation can be, but some
            >flexibility is lost. What do others think?
            Nick,
            Have you looked at generative programming. If you have parallel or
            similar code it is a candidate for being generated, then you refactor the
            generator and all the generated code is updated in all the applications that
            use it. It means defining some rules about how the generated code will work
            that the other code in the applications have to live by, but it gives you
            reuse...

            Kenneth Tyler www.tinyxp.com berkeley, ca



            ________________________________________________________________________
            ________________________________________________________________________

            Message: 9
            Date: Mon, 30 Apr 2001 10:01:28 -0400
            From: "Moss, D" <dmoss@...>
            Subject:




            ________________________________________________________________________
            ________________________________________________________________________

            Message: 10
            Date: Mon, 30 Apr 2001 15:12:42 +0100
            From: "Nick Fortescue" <nick@...>
            Subject: Re: Reuseability

            From: "Kenneth Tyler" <kentyler@...>
            > ...
            > >My attitude at the moment is that when code is first written constant
            > >refactoring is good, as it improves the design based on lessons learnt
            > about
            > >implementation. When code reuse starts, interfaces become hardened and
            > >cannot be refactored. Of course, the implementation can be, but some
            > >flexibility is lost. What do others think?
            > Nick,
            > Have you looked at generative programming. If you have parallel or
            > similar code it is a candidate for being generated, then you refactor the
            > generator and all the generated code is updated in all the applications
            that
            > use it. It means defining some rules about how the generated code will
            work
            > that the other code in the applications have to live by, but it gives you
            > reuse...

            I think this affects a different issue (as an aside, I do use code
            generators in my current project).
            Maybe an example would help. One common redesign, which might be done
            through a sequence of refactorings is in io. Suppose you want to be able to
            write a certain type of data (with a representative class) as XML and read
            it in again. One design is to have the reading and writing done by the
            class. One design is to have the reading and writing done by a separate
            object. There are strengths and weaknesses to both designs, and in different
            situations different designs will be the "simplest thing possible".

            While coding orignally you may switch between the designs, possible more
            than once, especially if this is quick to do through refactoring. Once you
            release the code to other users and it is being reused it is very hard to
            change this design as it would require the users to change all their code.
            Of course, in this case you put it behind the interface, but you still
            always have to support the old methods in your interface.
            Reuse has lost you a bit of flexibility. This is shown well by Martin's
            paper

            http://www.objectmentor.com/publications/oodmetrc.pdf

            The most interesting thing I found it showed indirectly is that the more
            people reuse code, the more reusable it is. This is because the more people
            who use it, the more static it is, so the more people can depend on it not
            changing from underneath them.

            Nick Fortescue





            ________________________________________________________________________
            ________________________________________________________________________

            Message: 11
            Date: Mon, 30 Apr 2001 11:33:54 -0400
            From: Andrew Hunt <andy@...>
            Subject: Re: all OO programmers should learn design patterns

            azami@... reports:

            >We also had someone for whom a computer would never fail. We could
            >consistently generate a program crash until she came and stood near
            >the computer - then it would work. If someone brought us a file that
            >caused the software to crash when trying to print, we'd have her come
            >stand by the computer so the print would go through. I don't know why
            >it worked.

            Magnetic personality, I guess. You don't want these people standing
            around while you're unit testing!!

            >Incidentally, I told my (now) wife about the printer dance while she
            >was an undergrad (oh, around '95). She also had success using the
            >"printer dance" with her department's finnicky printer. She did have
            >some explaining to do, however, when a fellow student walked in on
            >her! :-)

            Forget XP, what we need is a good totem pole...

            :-)

            /\ndy


            ________________________________________________________________________
            ________________________________________________________________________

            Message: 12
            Date: Mon, 30 Apr 2001 15:38:58 -0000
            From: lindstrom@...
            Subject: Re: Refactorings Paper

            I had to go to http://www.cs.utexas.edu/users/schwartz/ first and
            then click on Publications



            --- In extremeprogramming@y..., "Glen B. Alleman" <galleman@n...>
            wrote:
            > For those of you who may be like me and want to see some more
            deatils about
            > a topic. Either to put to use or to improve understanding there is
            a nice
            > paper on Refactoring in a real world environment at
            > http://www.cs.utexas.edu/users/schwartz/pub.htm.
            > This paper is a case study of how refactoring has been studied in
            the
            > SEMATEC project, which is a very large scale CORBA based system for
            the
            > semiconductor industry.
            >
            >
            > Glen Alleman
            > Niwot Ridge Consulting
            >
            > "You can never judge the future by the past" - Edmund Burke
            >
            >
            > [Non-text portions of this message have been removed]



            ________________________________________________________________________
            ________________________________________________________________________

            Message: 13
            Date: Mon, 30 Apr 2001 11:55:45 -0400
            From: Angus Mezick <amezick@...>
            Subject: Developing a secure link

            Right now I am designing a security protocol for transmitting financial
            transactions over the internet. This is something where the design of the
            item really has to be thought through and closely examined for holes. I
            was wondering how something like this could be developed using XP and where
            in the process it would fit? Somewhere in the stories? Or when the
            developers create tasks? Or generated using spikes? If we get this wrong,
            we get in BIG trouble. (Your accounts numbers out there for all to see.)
            --Angus
            P.S. I had no idea that a question about MVC could go so far :)


            ________________________________________________________________________
            ________________________________________________________________________

            Message: 14
            Date: Date header was inserted by mta7.pltn13.pbi.net
            From: Kevin Smith <sent@...>
            Subject: Re: Reusability

            Ralph Johnson wrote:
            >The customer has said that reusability is a requirement, so
            >I suppose by the rules of XP, it is OK to assume it is needed.
            >But that fact is that a lot of people say they want reusability
            >when it is not cost-effective.

            Excellent point. I've been pondering this myself
            recently, and it seems that reuse is a tool, not
            a goal in itself. I'm really thinking of reuse
            across projects here, not within a project which
            would relate to OAOO and DRY.

            Generally, I think the perceived benefits of
            reuse across projects are:
            - Lower costs
            - Easier maintenance
            - Higher reliability

            Within the XP model, I suspect that cross-project
            reuse actually costs more and makes maintenance
            more difficult, while adding nothing to
            reliability.

            I guess I'm also not talking about creating
            generic tools that can be reused. And I'm not
            talking about libraries that naturally evolve out
            of several related projects. I'm talking about
            actual production code that is shared in just two
            or three projects.

            Am I way off base, here?

            Kevin


            ________________________________________________________________________
            ________________________________________________________________________

            Message: 15
            Date: Mon, 30 Apr 2001 12:09:40 -0400
            From: Ron Jeffries <ronjeffries@...>
            Subject: Re: Developing a secure link

            Responding to Angus Mezick (11:55 AM 4/30/2001 -0400):
            >Right now I am designing a security protocol for transmitting financial
            >transactions over the internet. This is something where the design of the
            >item really has to be thought through and closely examined for holes. I
            >was wondering how something like this could be developed using XP and where
            >in the process it would fit? Somewhere in the stories? Or when the
            >developers create tasks? Or generated using spikes? If we get this wrong,
            >we get in BIG trouble. (Your accounts numbers out there for all to see.)

            I don't know much about the problem or solution. Why isn't it sufficient to
            do a strong encryption on each message? How do secure sites already do
            this? Isn't it a well-known technology (even though I personally don't know
            it)?

            Regards,



            Ronald E Jeffries
            http://www.XProgramming.com
            http://www.objectmentor.com


            ________________________________________________________________________
            ________________________________________________________________________

            Message: 16
            Date: Mon, 30 Apr 2001 12:25:41 -0400
            From: Angus Mezick <amezick@...>
            Subject: Re: Developing a secure link

            Let me simplify my question: How do you use XP to Design something whose
            design HAS to be bullet proof? Using a security protocol as an example.

            BTW:
            We are thinking about a system that uses public key encryption to pass a
            symmetric encryption algorithm's key. (symmetric is faster than public
            key) This symmetric key is generated for each client/server
            communication. Client is Java. Server is legacy C++.
            --Angus

            Ron Jeffries wrote:
            >
            > Responding to Angus Mezick (11:55 AM 4/30/2001 -0400):
            > >Right now I am designing a security protocol for transmitting financial
            > >transactions over the internet. This is something where the design of
            the
            > >item really has to be thought through and closely examined for holes. I
            > >was wondering how something like this could be developed using XP and
            where
            > >in the process it would fit? Somewhere in the stories? Or when the
            > >developers create tasks? Or generated using spikes? If we get this
            wrong,
            > >we get in BIG trouble. (Your accounts numbers out there for all to see.)
            >
            > I don't know much about the problem or solution. Why isn't it sufficient
            to
            > do a strong encryption on each message? How do secure sites already do
            > this? Isn't it a well-known technology (even though I personally don't
            know
            > it)?
            >
            > Regards,
            >
            > Ronald E Jeffries


            ________________________________________________________________________
            ________________________________________________________________________

            Message: 17
            Date: Mon, 30 Apr 2001 12:36:05 -0400
            From: Ron Jeffries <ronjeffries@...>
            Subject: Re:

            Responding to Angus Mezick (12:25 PM 4/30/2001 -0400):
            >Let me simplify my question: How do you use XP to Design something whose
            >design HAS to be bullet proof? Using a security protocol as an example.

            Not to seem opaque, but what part of incremental development and merciless
            refactoring and relentless testing seems inadequate to your needs?



            Ronald E Jeffries
            http://www.XProgramming.com
            http://www.objectmentor.com


            ________________________________________________________________________
            ________________________________________________________________________

            Message: 18
            Date: Mon, 30 Apr 2001 12:37:29 -0400
            From: "Paul Gunn" <pgunn@...>
            Subject: Re: Developing a secure link

            > BTW:
            > We are thinking about a system that uses public key encryption to pass a
            > symmetric encryption algorithm's key. (symmetric is faster than public
            > key) This symmetric key is generated for each client/server
            > communication. Client is Java. Server is legacy C++.
            > --Angus

            I seem to recall from college that this approach is one commonly used by SSL
            and possibly other protocols - ie. after initial negotiation, the encryption
            is handled symetrically. Unless you have other unique requirements, you may
            be able to find an existing protocol that meets your needs.

            (Agreeing that the underlying question is one interesting of discussion)

            Paul Gunn



            ________________________________________________________________________
            ________________________________________________________________________

            Message: 19
            Date: Mon, 30 Apr 2001 12:54:10 -0400
            From: Angus Mezick <amezick@...>
            Subject: Re: Re:

            Those practice, to me, will generate working/bug free/pretty code that will
            do exactly what is needed. Security protocols, in my mind, need to be
            picked apart and dissected by many people because there will be someone out
            there trying to get through them to the juicy data within. To me,
            incremental development does not seem as reassuring as having a group of
            people (~4-6 smart ones) think about ways in and out of this protocol. I
            agree that the solution itself will be a story, broken up into tasks, pair
            programmed, incrementally developed, unit/feature tested, and mercilessly
            refactored. I also agree that my particular problem has been solved
            before, but where would XP solve it for a yet to be determined problem?
            --Angus

            Ron Jeffries wrote:
            >
            > Responding to Angus Mezick (12:25 PM 4/30/2001 -0400):
            > >Let me simplify my question: How do you use XP to Design something whose
            > >design HAS to be bullet proof? Using a security protocol as an example.
            >
            > Not to seem opaque, but what part of incremental development and merciless
            > refactoring and relentless testing seems inadequate to your needs?
            >
            > Ronald E Jeffries


            ________________________________________________________________________
            ________________________________________________________________________

            Message: 20
            Date: Mon, 30 Apr 2001 16:54:52 -0000
            From: azami@...
            Subject: Re: Reuseability

            --- In extremeprogramming@y..., "Nick Fortescue" <nick@o...> wrote:
            > My attitude at the moment is that when code is first written
            constant
            > refactoring is good, as it improves the design based on lessons
            learnt about
            > implementation. When code reuse starts, interfaces become hardened
            and
            > cannot be refactored. Of course, the implementation can be, but some
            > flexibility is lost. What do others think?

            I think that is precisely the difference between a "public" interface
            and a "published" interface.

            -Matthew
            azami@...




            ________________________________________________________________________
            ________________________________________________________________________

            Message: 21
            Date: Mon, 30 Apr 2001 17:27:21 -0000
            From: "Lee" <lvbis@...>
            Subject: Re: Studies on XP searched

            --- In extremeprogramming@y..., Astrid Schroeder <schroeda@i...>
            wrote:
            > I'm a student of Computer Science at Munich University of
            Technology, Germany. I'm doing my master's thesis about Extreme
            Programming (XP). For this reason I'm searching for studies on XP
            and its techniques. I already found a study on Pair Programming by
            Laurie Williams, but I'm searching for more, so if perhaps anyone
            knows a study or has an idea where to find one, I'd appreciate if you
            could tell me.

            === Trying contacting Linda Werner, a member of AAUW.ORG. According
            to the University of Carolina - Santa Cruz web site, "...work in
            progress under the leadership of Linda Werner, a lecturer in
            computer science, who received a National Science Foundation
            grant to explore the use of pair programming with students in
            introductory-level computer science courses." If you send me an
            off-line email, I'll send you her direct email address.

            Lee in Las Vegas



            ________________________________________________________________________
            ________________________________________________________________________

            Message: 22
            Date: Mon, 30 Apr 2001 17:38:46 -0000
            From: "Lee" <lvbis@...>
            Subject: Re: Studies on XP searched

            --- In extremeprogramming@y..., Astrid Schroeder <schroeda@i...>
            wrote:
            > ... but I'm searching for more, so if perhaps anyone knows a study
            or has an idea where to find one, I'd appreciate if you could tell me.

            === According to the National Science Foundation, "This CISE
            Information Technology Workforce (ITW) proposal requests funds to
            examine the effects of pair-programming on female students'
            perceived self-confidence and interest in computer science as
            well as their retention and achievement in these courses.
            Approximately, 400 students enrolled in introductory computer
            science courses will complete a series of programming
            assignments in pairs (same and mixed gender pairs) or i
            independently. It is hypothesized that women who program in pairs
            will produce better programs in terms of functionality and
            readability, report greater confidence in their solutions, enjoy
            programming more, and have higher retention rates in computer
            science and related areas than women who program independently.
            This project has the potential to provide valuable insights into
            the retention of women in computer science."

            Check it out by going to the NSF home page and searching for:
            AWARD 0089989. It's title is: ITW: Retaining Women in Computer
            Science Programs: The Impact of Pair-Programming.

            Lee in Las Vegas



            ________________________________________________________________________
            ________________________________________________________________________

            Message: 23
            Date: Mon, 30 Apr 2001 18:58:15 +0100
            From: "Nick Fortescue" <nick@...>
            Subject: Re: Re: secure programming

            From: "Ron Jeffries" <ronjeffries@...>
            > Responding to Angus Mezick (12:25 PM 4/30/2001 -0400):
            > >Let me simplify my question: How do you use XP to Design something whose
            > >design HAS to be bullet proof? Using a security protocol as an example.
            >
            > Not to seem opaque, but what part of incremental development and merciless
            > refactoring and relentless testing seems inadequate to your needs?

            My understanding of the question is the question of adequate testing. XP
            says test everything that can go wrong. In normal programming, what can go
            wrong is in forgetfulness of the programmer, and slightly more for user
            input, but it usually is not malicious. For security protocols what can go
            wrong is everything. Funny spoofed packets, the lot. This is why you cannot
            test everything that can go wrong, because this set is infinite, so testing
            is not enough in these circumstances.

            A good discussion of these issues can be found in the secure programming
            list archive. Go to www.securityfocus.com and click on lists,secprog on the
            sidebar. See the FAQ and read the archive.

            It's a good question that Angus asks. I can think of four part answers, but
            no whole ones.
            1) Make sure that someone on the team knows about protocol security issues
            and make sure he pairs the protocol parts and especially the tests. The XP
            pairing should lead to a better result than normal where the advice is to
            get the Expert to inspect your code.
            2) Make the protocol part of the story. Designing your own protocols is one
            of the most common security mistakes. Make the story "Use the public
            standard protocol wibblespoo.311". As well as the benefit of all that expert
            checking and inspection it is much easier to write tests for conformance to
            a published protocing, ol design than an abstract "secure".
            3) Segregate the secure code into it's own area, and make the tests in this
            area far more extensive than normal. You might want to use monte-carlo
            testing (with fixed seed for repeatability) even if you don't normally do
            this.
            4) Use a protocol security testing tool as part of your tests, such as FDR2
            http://www.formal.demon.co.uk/FDR2.html

            Any more?

            Nick Fortescue




            ________________________________________________________________________
            ________________________________________________________________________

            Message: 24
            Date: Mon, 30 Apr 2001 13:15:17 -0500
            From: wecaputo@...
            Subject: Re: Re:


            Angus:
            >Those practice, to me, will generate working/bug free/pretty code that
            will
            >do exactly what is needed.

            And part of what is needed is bulletproof code so...

            >To me, incremental development does not seem as reassuring as having a
            group of
            >people (~4-6 smart ones) think about ways in and out of this protocol.

            Why not have these 4-6 smart ones helping to define tests?

            How long do they get to think their way through the protocol?
            3 weeks? 6 months?

            What if they spent that time improving an implementation of the initial
            best guess?

            Which one would be better? Why?

            Best,
            Bill



            ________________________________________________________________________
            ________________________________________________________________________

            Message: 25
            Date: Fri, 27 Apr 2001 19:52:42 GMT
            From: rmartin@...
            Subject: How to use design patterns.

            There has recently been a conjecture placed on the extreme programming
            mail group that Design Patterns are harmful. The complaint is that
            designers try to force patterns into a design rather than trying to
            determine the best structure for the design.

            I am sympathetic to this view. However I don't think design patterns
            are harmful. Indeed, I consider lack of knowledge of design patterns
            a mark of irresponsibility in a software professional. Design
            Patterns represent an invaluable body of knowledge that describes how
            past engineers have solved common problems. This cannot help but be
            of aid to future engineers facing those problems.

            Still, patterns are not a panacea. They do not solve all design
            problems. Nor do they represent a tool, method, or recipe for solving
            design problems. Rather they are simply descriptions of what has
            worked in a few situations in the past.

            How should designers employ design patterns? In my opinion they
            should not *try* to employ them at all. Rather designers need to
            become so intimately familiar with design patterns that they simply
            know when a given pattern fits into their design or not.

            This notion of "fit" is a tricky one. It is easy to face a design
            problem and leap to a pattern that solves it. But does that pattern
            provide a solution that is appropriate to the context? Or might there
            be a simpler solution?

            Design patterns should not be used in lieu of finding the best design.
            A designer might consider a particular pattern to help solve a
            problem; but should not assume that the pattern is the best solution.
            A pattern is not "best" simply because it is a pattern.

            One can view the choice of a pattern as a hypothesis: "I hypothesize
            that the observer pattern is a good solution to this problem." A good
            designer will then set about to choose a set of experiments that will
            verify this hypothesis. Those experiments are likely to be tiny
            stepwise implementations if test cases that, bit by bit, implement the
            problem to be solved. At any time during this implementation, the
            pattern should be viewed only as a vague direction, not as the law.
            And should the experiments show that the pattern is not optimal, the
            pattern should be abandoned.

            I have an article that demonstrates this technique appearing in my
            column in an upcoming Java Report.


            Robert C. Martin | "Uncle Bob" | Software Consultants
            Object Mentor Inc. | rmartin@... | We'll help you get
            PO Box 5757 | Tel: (800) 338-6716 | your projects done.
            565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
            Suite 135 | | www.XProgramming.com
            Vernon Hills, IL, | Training and Mentoring | www.junit.org
            60061 | OO, XP, Java, C++, Python|

            "One of the great commandments of science is:
            'Mistrust arguments from authority.'" -- Carl Sagan


            ________________________________________________________________________
            ________________________________________________________________________



            Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          • Bretz, Matt
            ... From: extremeprogramming@yahoogroups.com [mailto:extremeprogramming@yahoogroups.com] Sent: Monday, April 30, 2001 5:24 PM To:
            Message 5 of 20 , May 1 5:32 AM
            • 0 Attachment
              -----Original Message-----
              From: extremeprogramming@yahoogroups.com
              [mailto:extremeprogramming@yahoogroups.com]
              Sent: Monday, April 30, 2001 5:24 PM
              To: extremeprogramming@yahoogroups.com
              Subject: [XP] Digest Number 1065


              To Post a message, send it to: extremeprogramming@...

              To Unsubscribe, send a blank message to:
              extremeprogramming-unsubscribe@...

              Don't miss XP UNIVERSE, the first US conference on XP and Agile Methods.
              Early registration discounts EXTENDED until May 1, 2001. www.xpuniverse.com
              for details and registration.
              ------------------------------------------------------------------------

              There are 25 messages in this issue.

              Topics in this digest:

              1. Re: Re:
              From: Ron Jeffries <ronjeffries@...>
              2. RE: Re: Refactorings Paper
              From: "Arrizza, John" <john.arrizza@...>
              3. RE: Re: secure programming
              From: "Gareth Reeves" <reevesg@...>
              4. Re: secure programming
              From: azami@...
              5. Re: Re: secure programming
              From: "Nick Fortescue" <nick@...>
              6. Re: How to use design patterns.
              From: "Lee" <lvbis@...>
              7. Re: Refactorings Paper
              From: "Lee" <lvbis@...>
              8. Re: Re: secure programming
              From: "Nick Fortescue" <nick@...>
              9. YAGNI
              From: Brian Christopher Robinson <brian@...>
              10. Re: YAGNI
              From: Phlip <pplumlee@...>
              11. Re: secure programming
              From: azami@...
              12. Re: Developing a secure link
              From: Art Taylor <reeses@...>
              13. Re: YAGNI
              From: azami@...
              14. Re: YAGNI
              From: Phil Goodwin <phil.goodwin@...>
              15. Re: YAGNI
              From: Ron Jeffries <ronjeffries@...>
              16. (OTUG) How to use design patterns.
              From: rmartin@...
              17. Re: YAGNI
              From: "Brian C. Robinson" <brian.c.robinson@...>
              18. FW: (OTUG) XP and Rocket Guidance
              From: "Ken Boyer" <ken@...>
              19. Re: FW: (OTUG) XP and Rocket Guidance
              From: "Lee" <lvbis@...>
              20. Re: YAGNI
              From: Ron Jeffries <ronjeffries@...>
              21. Re: YAGNI
              From: Phil Goodwin <phil.goodwin@...>
              22. Re: Developing a secure link
              From: jbrewer@...
              23. Re: Developing a secure link
              From: jbrewer@...
              24. (OTUG) How to use design patterns.
              From: rmartin@...
              25. (OTUG) How to use design patterns.
              From: rmartin@...


              ________________________________________________________________________
              ________________________________________________________________________

              Message: 1
              Date: Mon, 30 Apr 2001 14:26:48 -0400
              From: Ron Jeffries <ronjeffries@...>
              Subject: Re: Re:

              Responding to Angus Mezick (12:54 PM 4/30/2001 -0400):
              >Those practice, to me, will generate working/bug free/pretty code that will
              >do exactly what is needed.

              Defense rests.

              >Security protocols, in my mind, need to be
              >picked apart and dissected by many people because there will be someone out
              >there trying to get through them to the juicy data within.

              If you believe that, you should do design sessions and/or code reviews.

              >To me,
              >incremental development does not seem as reassuring as having a group of
              >people (~4-6 smart ones) think about ways in and out of this protocol. I
              >agree that the solution itself will be a story, broken up into tasks, pair
              >programmed, incrementally developed, unit/feature tested, and mercilessly
              >refactored.

              If you need this reassurance this way, then you should get it this way.

              >I also agree that my particular problem has been solved
              >before, but where would XP solve it for a yet to be determined problem?

              I hate to admit it, but I cannot say in advance how I'd solve an as yet
              undetermined problem.

              Regards,


              Ronald E Jeffries
              http://www.XProgramming.com
              http://www.objectmentor.com


              ________________________________________________________________________
              ________________________________________________________________________

              Message: 2
              Date: Mon, 30 Apr 2001 14:28:35 -0400
              From: "Arrizza, John" <john.arrizza@...>
              Subject: RE: Re: Refactorings Paper


              > -----Original Message-----
              > From: lindstrom@... [mailto:lindstrom@...]
              > I had to go to http://www.cs.utexas.edu/users/schwartz/ first and
              > then click on Publications

              I tried this as well. I get a [x] instead of the doc. (I do have adobe
              acrobat installed). I also tried ftp and then acrobat, still no luck. anyone
              else with this problem?

              John


              ________________________________________________________________________
              ________________________________________________________________________

              Message: 3
              Date: Mon, 30 Apr 2001 13:43:53 -0500
              From: "Gareth Reeves" <reevesg@...>
              Subject: RE: Re: secure programming

              > In normal programming, what can go
              > wrong is in forgetfulness of the programmer, and slightly more for user
              > input, but it usually is not malicious. For security protocols what can go
              > wrong is everything. Funny spoofed packets, the lot. This is why
              > you cannot
              > test everything that can go wrong, because this set is infinite,
              > so testing
              > is not enough in these circumstances.

              Interesting, what other techniques would you use to ensure your design was
              good in the face of infinite possibilities?

              Gareth



              ________________________________________________________________________
              ________________________________________________________________________

              Message: 4
              Date: Mon, 30 Apr 2001 18:50:04 -0000
              From: azami@...
              Subject: Re: secure programming

              --- In extremeprogramming@y..., "Gareth Reeves" <reevesg@p...> wrote:
              > Interesting, what other techniques would you use to ensure your
              design was
              > good in the face of infinite possibilities?

              I would open the design and code to inspection by anyone. Security
              that relies on secrets in the code is not security. I would
              absolutely not be satisfied by 4-6 experts reviewing and blessing the
              security design.

              It is possible that in the realm of security, provable correctness may
              have lots of value. You would still want to hammer it with tests.
              You want the tests to show that the thing you are doing is the thing
              you proved correct, and you want tests that do weird corruptions and
              such. Any time anyone comes up with a new possible breach, write the
              test for it. In keeping with "openness", allow anyone in the world to
              submit new test cases for you. Run massive monte carlo tests.

              Regarding the general issue, what do you do if code NEEDS to be
              BULLETPROOF? IMO, testing is even more important, and your tests need
              to hurl bullets at the code. In general, if XP practices lead to more
              reliable code, why wouldn't an XP project more closely approach the
              bulletproof ideal than would a more traditional project?




              ________________________________________________________________________
              ________________________________________________________________________

              Message: 5
              Date: Mon, 30 Apr 2001 20:02:11 +0100
              From: "Nick Fortescue" <nick@...>
              Subject: Re: Re: secure programming


              > > In normal programming, what can go
              > > wrong is in forgetfulness of the programmer, and slightly more for user
              > > input, but it usually is not malicious. For security protocols what can
              go
              > > wrong is everything. Funny spoofed packets, the lot. This is why
              > > you cannot
              > > test everything that can go wrong, because this set is infinite,
              > > so testing
              > > is not enough in these circumstances.
              >
              > Interesting, what other techniques would you use to ensure your design was
              > good in the face of infinite possibilities?

              As I said this is something that is discussed a lot on the secure
              programming list, so
              I'm reluctant to go too much into it here, as I won't get it all right,
              those who have
              seen it all before will be bored, and I won't say it as well. However a
              brief summary of some well known techniques:

              1) Formal (mathematical) methods allow you prove a limited amount given a
              limited set of assumptions. There is a lot of writing about this. As I was
              trained in this at Oxford, I'd biasedly suggest you look there
              www.comlab.ox.ac.uk, but there are a lot of books on the subject.
              2) In security you tend to make the default "disallowed", and only do
              something if it is explicitly allowed. This prevents you having to think
              about the infinite disallowed cases. However, you can't easliy test you are
              doing this.
              3) Limit scope. If you make the "secure" portion of your code as restricted
              as possible, then the smallest amount of your code is infinitely hard to
              test.
              4) Security professionals know several patterns of well known attacks, eg
              buffer overflow, the zero case, etc.) A lot of attacks are just variations
              on these common mistakes. So there are an infinite number of Word Macro
              viruses, but most can be tested for by checking you prompt before running
              Macros.Code inspections by such a professional or professionals can point
              out flaws, and advice from them may help produce a wide coverage of test
              cases with a small number of tests.
              5) Making code open-source can help get as many eyes on the code as
              possible, making it more likely flaws will be found.

              How all of these integrate into XP is something I really don't know. Does
              anyone have any thoughts on this?

              Nick Fortescue







              ________________________________________________________________________
              ________________________________________________________________________

              Message: 6
              Date: Mon, 30 Apr 2001 18:53:21 -0000
              From: "Lee" <lvbis@...>
              Subject: Re: How to use design patterns.

              --- In extremeprogramming@y..., rmartin@o... wrote:
              > One can view the choice of a pattern as a hypothesis: "I
              hypothesize that the observer pattern is a good solution to this
              problem." A good designer will then set about to choose a set of
              experiments that will verify this hypothesis. Those experiments are
              likely to be tiny stepwise implementations if test cases that, bit by
              bit, implement the problem to be solved. At any time during this
              implementation, the pattern should be viewed only as a vague
              direction, not as the law. And should the experiments show that the
              pattern is not optimal, the pattern should be abandoned.

              === Robert, you make some great observations here regarding the use
              of design patterns. Let me add one item for thought to the
              process -- design patterns help keep a team focused.

              I agree that patterns should *always* be reviewed. Flaws in
              the process can usually be identified by the team and corrected
              by the paired programmers. Once the corrections are made, a
              new design can be generated to properly track these changes. I
              know the XP community as a whole have an natural dislike for
              designs as they do not contribute to code generation. However,
              I find them a useful tool for helping keep everyone on track and
              focused on the process at hand.

              Lee in Las Vegas



              ________________________________________________________________________
              ________________________________________________________________________

              Message: 7
              Date: Mon, 30 Apr 2001 18:56:28 -0000
              From: "Lee" <lvbis@...>
              Subject: Re: Refactorings Paper

              --- In extremeprogramming@y..., "Arrizza, John" <john.arrizza@m...>
              wrote:
              > I tried this as well. I get a [x] instead of the doc. (I do have
              adobe acrobat installed). I also tried ftp and then acrobat, still no
              luck. anyone else with this problem?
              >
              > John

              === Here it is: ftp://ftp.cs.utexas.edu/pub/predator/ase2000.pdf

              Lee in Las Vegas



              ________________________________________________________________________
              ________________________________________________________________________

              Message: 8
              Date: Mon, 30 Apr 2001 20:09:31 +0100
              From: "Nick Fortescue" <nick@...>
              Subject: Re: Re: secure programming


              From: <azami@...>
              > Regarding the general issue, what do you do if code NEEDS to be
              > BULLETPROOF? IMO, testing is even more important, and your tests need
              > to hurl bullets at the code. In general, if XP practices lead to more
              > reliable code, why wouldn't an XP project more closely approach the
              > bulletproof ideal than would a more traditional project?

              I agreed with everything you wrote that I have cut out. I think the risk is
              that XP projects tend not to have design up front, and detailed design
              documents. If you are working on a security protocol and constantly
              refactoring with no code ownership it might be very difficult to write tests
              which prevent flaws being introduced. For example, a good general security
              rule is "Never write user input controlled strings to printf etc as you
              might get format string vulnerabilities". But it is hard to write test cases
              which prevent two novices pairing together introducing such bugs into your
              code.
              In this case XP might not be the best way of working. On the other hand,
              writing test cases first and constant pairing is fantastic for security.

              Nick Fortescue






              ________________________________________________________________________
              ________________________________________________________________________

              Message: 9
              Date: Mon, 30 Apr 2001 15:05:46 -0500
              From: Brian Christopher Robinson <brian@...>
              Subject: YAGNI

              A question about YAGNI. Let's say I'm creating a class for my program. I
              have two possible ways of doing it that AFAICT are equally good in terms of
              the story I'm working on now. However, I know that one way will be better
              for some future story I'm not working on yet. Is it wrong to work with
              that future knowledge?



              ________________________________________________________________________
              ________________________________________________________________________

              Message: 10
              Date: Mon, 30 Apr 2001 12:14:12 -0700
              From: Phlip <pplumlee@...>
              Subject: Re: YAGNI

              Proclaimed Brian Christopher Robinson from the mountaintops:

              > A question about YAGNI. Let's say I'm creating a class for my program.
              > I have two possible ways of doing it that AFAICT are equally good in
              > terms of the story I'm working on now. However, I know that one way
              > will be better for some future story I'm not working on yet. Is it
              > wrong to work with that future knowledge?

              YAGNI does not mean you pretend you know nothing about the project except
              the past and current UserStories.

              It means you don't waste gobs of time investing in speculative code. No
              gold-plating, or adding "flexibility". The correct way to add flexibility
              is to let further UserStories flex the design!

              If you say the two ways are equally "good", let's take that to mean they
              will be around the same line count. Or maybe even the predictive version
              is 5% longer. Go ahead and code it. This is not the same as the Bad Old
              Days, when folks would hole up and code, hand over fist, entire packages
              entirely on speculation.

              http://c2.com/cgi/wiki?JobSecurity

              --
              Phlip phlip_cpp@...
              ============== http://phlip.webjump.com ==============
              This signature was automatically generated with
              Signify v1.06. For this and other cool products,
              check out http://www.debian.org/


              ________________________________________________________________________
              ________________________________________________________________________

              Message: 11
              Date: Mon, 30 Apr 2001 19:29:05 -0000
              From: azami@...
              Subject: Re: secure programming

              --- In extremeprogramming@y..., "Nick Fortescue" <nick@o...> wrote:
              > rule is "Never write user input controlled strings to printf etc as
              you
              > might get format string vulnerabilities". But it is hard to write
              test cases
              > which prevent two novices pairing together introducing such bugs
              into your
              > code.

              Good point. I'd suggest making rules like that explicit in a coding
              standard, and occasionally brainstorming for ways to test it. (How
              about a string object with a "user input" attribute? Ensure that
              string objects can only be printed through their own methods? I'm not
              actually trying to solve it, but I do think a team that needs it
              should occasionally try.)

              Although not normally required for XP, I'd definitely subject the
              security-critical work of a pair of novices to review.

              In fact, I'd probably subject all security-critical work to review. I
              suppose this is effectively the purpose of opening the source.


              -Matthew
              azami@...




              ________________________________________________________________________
              ________________________________________________________________________

              Message: 12
              Date: Mon, 30 Apr 2001 12:30:15 -0700
              From: Art Taylor <reeses@...>
              Subject: Re: Developing a secure link

              Angus Mezick (amezick@...) wrote:
              > Right now I am designing a security protocol for transmitting financial
              > transactions over the internet. This is something where the design of the
              > item really has to be thought through and closely examined for holes. I
              > was wondering how something like this could be developed using XP and
              where
              > in the process it would fit? Somewhere in the stories? Or when the
              > developers create tasks? Or generated using spikes? If we get this
              wrong,
              > we get in BIG trouble. (Your accounts numbers out there for all to see.)
              > --Angus

              We have done something very similar to this, using XP, in the past
              month or so. Someone else in this thread mentioned the exact thing we
              did.

              We needed to build a remote API that didn't depend on external
              libraries, yet was reasonably secure. We decided to use asymmetric
              keys for the client->server communication, and include a symmetric key
              with each client request. The response would be encrypted with this
              symmetric key, saving us the hassle of storing client public keys on
              the server. The resource advantage of the symmetric key algorithms
              was a nice little side benefit.

              The way we approached this in an incremental fashion, was to build a
              client that would communicate via unencrypted http, to a server API
              that understood unencrypted messages via http. At first, it was
              just,"Hi Mom!"

              The User Stories read "Client can connect to server via sockets",
              "Client can send a message to the server", "Client message can be
              xml-formatted", "Client request will be encrypted", etc.

              Over the next week (pair programming is amazing for the speed at which
              you move using it), we added the xml messaging parsers and generators
              (special-case serialisers, since we didn't want to use outside
              libraries), the encryption/decryption and compression filters, and a
              large number of API call handler classes.

              Each of these features was tidily composed with test drivers, and
              integrated within a day, which is why we structured them in that way.
              We used accepted standard encryption protocols, but we used them from
              the Crypto++ library, and repackaged that open-source library to
              include only the protocols we needed, saving a lot of space.

              You know that you're not going to get your financial application
              hacked up in a day, but you can pick little chunks of it that can be
              done in a day, to grow a tiny,"Look, this much of it works!" seed into
              the full application. We used a string-of-filters metaphor and built
              it into our application, which made that stepwise development easy and
              not frustrating. You might need to find a different metaphor, but
              you'll know when you come up with it, because you won't be worried any
              more.

              As for specific protocol implementations, I would really recommend
              using something standard, rather than developing your own. Take
              something right out of Schneier, because it has been reviewed by
              people who do that for a living.

              If you want more details about how we solved our particular problem,
              feel free to email me.

              -a.


              [Non-text portions of this message have been removed]



              ________________________________________________________________________
              ________________________________________________________________________

              Message: 13
              Date: Mon, 30 Apr 2001 19:36:58 -0000
              From: azami@...
              Subject: Re: YAGNI

              --- In extremeprogramming@y..., Brian Christopher Robinson
              <brian@d...> wrote:
              > A question about YAGNI. Let's say I'm creating a class for my
              program. I
              > have two possible ways of doing it that AFAICT are equally good in
              terms of
              > the story I'm working on now. However, I know that one way will be
              better
              > for some future story I'm not working on yet. Is it wrong to work
              with
              > that future knowledge?

              Suppose you solve the problem with the informed design (the way that's
              better for the future story). Then, that story gets dropped. How do
              you feel about the state of the code? Is it as simple as it can
              possibly be?

              Now, suppose you solve the problem the other way. The future story
              becomes current, and you begin working on it by refactoring from the
              design you used to the design you considered. How much does this
              hurt?

              -Matthew
              azami@...




              ________________________________________________________________________
              ________________________________________________________________________

              Message: 14
              Date: Mon, 30 Apr 2001 12:36:58 -0700
              From: Phil Goodwin <phil.goodwin@...>
              Subject: Re: YAGNI

              At 03:05 PM 4/30/01 -0500, Brian Christopher Robinson wrote:
              >A question about YAGNI. Let's say I'm creating a class for my program. I
              >have two possible ways of doing it that AFAICT are equally good in terms of

              >the story I'm working on now. However, I know that one way will be better
              >for some future story I'm not working on yet. Is it wrong to work with
              >that future knowledge?

              The impulse to kill two birds with one stone is a distraction that is best
              avoided. If you are thinking about two different stories while you are
              writing code then you aren't writing the best code you can. Think about one
              story at a time and let the tests force you to complicate your thinking if
              and when that becomes necessary.


              ----------------------------------------------------------------------------
              --------------------------------
              Phil Goodwin, Java Software, Sun Microsystems, 408-517-6951, or x66951

              "If everything you try works, you aren't trying hard enough." -- Gordon
              Moore



              ________________________________________________________________________
              ________________________________________________________________________

              Message: 15
              Date: Mon, 30 Apr 2001 15:41:36 -0400
              From: Ron Jeffries <ronjeffries@...>
              Subject: Re: YAGNI

              Responding to Brian Christopher Robinson (03:05 PM 4/30/2001 -0500):
              >A question about YAGNI. Let's say I'm creating a class for my program. I
              >have two possible ways of doing it that AFAICT are equally good in terms of
              >the story I'm working on now. However, I know that one way will be better
              >for some future story I'm not working on yet. Is it wrong to work with
              >that future knowledge?

              Is one of them simpler than the other? I always go with the simplest. But I
              try not to do things that would obviously work.

              Can you think of a specific example?



              Ronald E Jeffries
              http://www.XProgramming.com
              http://www.objectmentor.com


              ________________________________________________________________________
              ________________________________________________________________________

              Message: 16
              Date: Fri, 27 Apr 2001 19:52:42 GMT
              From: rmartin@...
              Subject: (OTUG) How to use design patterns.

              There has recently been a conjecture placed on the extreme programming
              mail group that Design Patterns are harmful. The complaint is that
              designers try to force patterns into a design rather than trying to
              determine the best structure for the design.

              I am sympathetic to this view. However I don't think design patterns
              are harmful. Indeed, I consider lack of knowledge of design patterns
              a mark of irresponsibility in a software professional. Design
              Patterns represent an invaluable body of knowledge that describes how
              past engineers have solved common problems. This cannot help but be
              of aid to future engineers facing those problems.

              Still, patterns are not a panacea. They do not solve all design
              problems. Nor do they represent a tool, method, or recipe for solving
              design problems. Rather they are simply descriptions of what has
              worked in a few situations in the past.

              How should designers employ design patterns? In my opinion they
              should not *try* to employ them at all. Rather designers need to
              become so intimately familiar with design patterns that they simply
              know when a given pattern fits into their design or not.

              This notion of "fit" is a tricky one. It is easy to face a design
              problem and leap to a pattern that solves it. But does that pattern
              provide a solution that is appropriate to the context? Or might there
              be a simpler solution?

              Design patterns should not be used in lieu of finding the best design.
              A designer might consider a particular pattern to help solve a
              problem; but should not assume that the pattern is the best solution.
              A pattern is not "best" simply because it is a pattern.

              One can view the choice of a pattern as a hypothesis: "I hypothesize
              that the observer pattern is a good solution to this problem." A good
              designer will then set about to choose a set of experiments that will
              verify this hypothesis. Those experiments are likely to be tiny
              stepwise implementations if test cases that, bit by bit, implement the
              problem to be solved. At any time during this implementation, the
              pattern should be viewed only as a vague direction, not as the law.
              And should the experiments show that the pattern is not optimal, the
              pattern should be abandoned.

              I have an article that demonstrates this technique appearing in my
              column in an upcoming Java Report.


              Robert C. Martin | "Uncle Bob" | Software Consultants
              Object Mentor Inc. | rmartin@... | We'll help you get
              PO Box 5757 | Tel: (800) 338-6716 | your projects done.
              565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
              Suite 135 | | www.XProgramming.com
              Vernon Hills, IL, | Training and Mentoring | www.junit.org
              60061 | OO, XP, Java, C++, Python|

              "One of the great commandments of science is:
              'Mistrust arguments from authority.'" -- Carl Sagan

              -----------------------------------------------------------------
              To unsubscribe from OTUG, send an email to majordomo@...
              with the word 'unsubscribe' in the body of the message.


              ________________________________________________________________________
              ________________________________________________________________________

              Message: 17
              Date: Mon, 30 Apr 2001 15:58:11 -0500
              From: "Brian C. Robinson" <brian.c.robinson@...>
              Subject: Re: YAGNI

              At 02:41 PM 4/30/01, you wrote:
              >Can you think of a specific example?

              Actually this is something that has almost but not quite come up a couple
              of times in our project. Basically, I will be thinking about something and
              one of the options I am considering looks like it might be useful in the
              future but then when I think about it some more I realize that it probably
              won't. But it did lead me to the hypothetical situation I originally
              described.



              ________________________________________________________________________
              ________________________________________________________________________

              Message: 18
              Date: Mon, 30 Apr 2001 16:08:07 -0400
              From: "Ken Boyer" <ken@...>
              Subject: FW: (OTUG) XP and Rocket Guidance

              ----- Original Message -----
              From: "Ron Jeffries" <RonJeffries@...>
              Sent: Friday, April 27, 2001 3:36 PM
              > Responding to Ken Boyer (10:03 AM 4/27/2001 -0400):
              > >OK. Now we're getting somewhere. We can boil this down to a few
              questions:
              > >1. Where is the boundary of XP? I.e. how much can you modify it before it
              > >becomes ~XP?
              >
              > However ... every time I coach any team, there's something different about

              > their situation. There are tweaks always, and sometimes important changes.

              > I do my best to advise them, and don't worry too much about whether
              they're
              > doing XP ... the important thing is to do well.

              I'm trying to get to these tweaks. What are the axes along which the tweaks
              are made, or is that why people like you are hired? :-)

              > >What I'm trying to do, probably like many people, is discern the
              continuum
              > >that
              > >ties the Agile processes together, and that goes from them "up" a little
              to
              > >processes which could be used for, say, rocket guidance. If we try to
              work
              > >through this, we're dispelling the confusing messages from DeMarco and
              > >Beck, which don't really tell us anything about evolving or enhancing XP.
              >
              > Mostly we don't know that much, and [I think] that what we do know is that

              > one shouldn't just set off to enhance XP without contact with the pure
              quill.

              Well, OK, but one might want to add a few carefully selected areas to
              enhance specific attributes, such as peer review and requirements
              management.

              > I keep saying this, and the evidence is that I won't stop: I've done a lot

              > of software over a lot of years. The XP practices, I believe, put you in
              > touch with your code, your project, and your colleagues, in a way that
              I've
              > not reproducibly experienced in the past. It seems to have all the good
              > aspects of the "garage shop", without the bad ones.

              OK, I'm not doubting that, at least not anymore. As someone steeped in
              the realm of life-critical software, I am viewing XP with one of the most
              critical gazes of anyone. I see little specks which make it, in its out-of-
              the-box form, somewhat lacking in direct applicability to my realm. We've
              touched on these things, and I'm trying to formulate an enhancement
              which may remain nothing but an intellectual exercise for me. Or, I may
              ask you to review it for publication in a journal...

              Kenneth W. Boyer Jr. <><
              ASQ Certified Software Quality Engineer
              VASCOR, Inc. - Pittsburgh, PA USA




              ________________________________________________________________________
              ________________________________________________________________________

              Message: 19
              Date: Mon, 30 Apr 2001 20:16:40 -0000
              From: "Lee" <lvbis@...>
              Subject: Re: FW: (OTUG) XP and Rocket Guidance

              --- In extremeprogramming@y..., "Ken Boyer" <ken@v...> wrote:
              > OK, I'm not doubting that, at least not anymore. As someone steeped
              in the realm of life-critical software, I am viewing XP with one of
              the most critical gazes of anyone. I see little specks which make it,
              in its out-of-the-box form, somewhat lacking in direct applicability
              to my realm. We've touched on these things, and I'm trying to
              formulate an enhancement which may remain nothing but an intellectual
              exercise for me. Or, I may ask you to review it for publication in a
              journal...
              >
              > Kenneth W. Boyer Jr. <><
              > ASQ Certified Software Quality Engineer
              > VASCOR, Inc. - Pittsburgh, PA USA

              === As discussed in previous threads, XP is one of the most agile
              methodologies in use today. However, it is not without its slight
              flaws and minor shortcomings. I'm working to bring the majority
              of XP processes online in our company, with a few corrections or
              internal enhancements that will allow it meet governmental needs.
              All in all, I've been very impressed with it as a development
              methodology.

              Lee in Las Vegas



              ________________________________________________________________________
              ________________________________________________________________________

              Message: 20
              Date: Mon, 30 Apr 2001 16:28:10 -0400
              From: Ron Jeffries <ronjeffries@...>
              Subject: Re: YAGNI

              Responding to Ron Jeffries (03:41 PM 4/30/2001 -0400):
              >But I
              >try not to do things that would obviously work.

              Actually I try not to do things that would obviously NOT work ... ;->



              Ronald E Jeffries
              http://www.XProgramming.com
              http://www.objectmentor.com


              ________________________________________________________________________
              ________________________________________________________________________

              Message: 21
              Date: Mon, 30 Apr 2001 13:29:58 -0700
              From: Phil Goodwin <phil.goodwin@...>
              Subject: Re: YAGNI

              At 03:05 PM 4/30/01 -0500, Brian Christopher Robinson wrote:
              >A question about YAGNI. Let's say I'm creating a class for my program. I
              >have two possible ways of doing it that AFAICT are equally good in terms of

              >the story I'm working on now. However, I know that one way will be better
              >for some future story I'm not working on yet. Is it wrong to work with
              >that future knowledge?

              I think that it depends on how you use it. If it's deepening your
              understanding of your current story then it's good. If it's distracting you
              with considerations that aren't pertinent to your current story then it's
              not so good.

              Trying to figure out which is which is a distraction itself.

              When I'm working on a particular story I try to make sure that I focus on
              that story. If I find myself thinking about another story I check to see
              whether my thoughts are getting clearer and more focused or whether I'm
              starting to get distracted (this comes out as either worry or fascination).
              If I'm distracted I write down my thought on a card and re-focus on the
              current story. If I'm getting clarity I go with it.

              The original question assumes that you are working on a pretty course
              grained level of design: which class to use. If you are thinking about what
              method to write next the problem pretty much goes away for a while. When it
              comes back it will be in the form of how to refactor the methods into
              classes that make more sense. At that point the other story you were
              worrying about probably won't enter into the picture. Unless of course
              you've started to implement it by the time this refactoring wants to happen.
              Thinking this way makes the original question seem less relevant: if you
              aren't planning your classes ahead of implementing them it doesn't make
              sense to ponder about how that planning should be done.

              ----------------------------------------------------------------------------
              --------------------------------
              Phil Goodwin, Java Software, Sun Microsystems, 408-517-6951, or x66951

              "If everything you try works, you aren't trying hard enough." -- Gordon
              Moore



              ________________________________________________________________________
              ________________________________________________________________________

              Message: 22
              Date: Mon, 30 Apr 2001 21:03:13 -0000
              From: jbrewer@...
              Subject: Re: Developing a secure link

              --- In extremeprogramming@y..., Angus Mezick <amezick@e...> wrote:
              > Let me simplify my question: How do you use XP to Design something
              whose
              > design HAS to be bullet proof? Using a security protocol as an
              example.

              Get a security expert. XP is not a replacement for domain expertise.

              Nothing is bullet proof, given a big enough bullet. Security experts
              measure the security of a system in terms of estimated effort
              required to compromise it, usually measured in dollars. Your
              customer would probably prefer a system that cost millions rather
              than dozens of dollars to breach, but that's really his call to make.

              Security is about the whole system, not just the software. All the
              formal software verification in the world isn't going to help you if
              your sysadmin chooses "aardvark" as the root password. Or if a
              criminal decides the easiest way in is to bribe your $5/hour security
              guard.

              The good news is that computer criminals are lazy, and you're one of
              literally millions of targets. To avoid attacks, you just have to be
              a little less convenient than the other targets. That's not too
              hard, since there are a lot of unpatched IIS servers out there.

              > We are thinking about a system that uses public key encryption to
              pass a
              > symmetric encryption algorithm's key. (symmetric is faster than
              public
              > key) This symmetric key is generated for each client/server
              > communication. Client is Java. Server is legacy C++.

              Unless you have a _very_ good reason not to, by all means use an
              off-the-shelf protocol (like SSL), and an off-the-shelf library.
              It's been tested more than your home-grown stuff ever could be, and if
              it's ever breached, you'll likely hear about it in the news.

              John Brewer
              Jera Design

              XP FAQ: http://www.jera.com/techinfo/xpfaq.html



              ________________________________________________________________________
              ________________________________________________________________________

              Message: 23
              Date: Mon, 30 Apr 2001 21:14:14 -0000
              From: jbrewer@...
              Subject: Re: Developing a secure link

              --- In extremeprogramming@y..., Angus Mezick <amezick@e...> wrote:
              > Let me simplify my question: How do you use XP to Design something
              whose
              > design HAS to be bullet proof? Using a security protocol as an
              example.

              Hire a security expert. XP is not an replacement for required
              domain expertise.

              Nothing is bulletproof, given a large enough bullet. Security
              experts typically evaluate the security of a system in terms of how
              much effort (usually expressed in dollars) it would take to breach
              it. Your customer would probably prefer a system that would costs
              millions, rather than dozens, of dollars to breach, but that's
              largely his decision.

              Remember that security is about the whole system, not just the
              program. All the formal verification methods and design reviews in
              the world aren't going to help you if your sysadmin makes the root
              password "aardvark". Or if a criminal decides that the cheapest way
              in is to bribe your $5/hour security guard.

              The good news is that computer criminals are lazy. Your security
              doesn't have to be perfect, just good enough so that a criminal gets
              discouraged and looks for an easier target.

              > BTW:
              > We are thinking about a system that uses public key encryption to
              pass a
              > symmetric encryption algorithm's key. (symmetric is faster than
              public
              > key) This symmetric key is generated for each client/server
              > communication. Client is Java. Server is legacy C++.

              Unless you have a _very_ good reason not to, you should use an
              existing protocol (like SSL), and a well-known existing
              implementation (like RSA's). That way, you take advantage of a huge
              existing body of testing and verification, and you'll likely hear
              about it in the news if there's been a breech.

              John Brewer
              Jera Design

              XP FAQ: http://www.jera.com/xpfaq.html



              ________________________________________________________________________
              ________________________________________________________________________

              Message: 24
              Date: Fri, 27 Apr 2001 19:52:42 GMT
              From: rmartin@...
              Subject: (OTUG) How to use design patterns.

              There has recently been a conjecture placed on the extreme programming
              mail group that Design Patterns are harmful. The complaint is that
              designers try to force patterns into a design rather than trying to
              determine the best structure for the design.

              I am sympathetic to this view. However I don't think design patterns
              are harmful. Indeed, I consider lack of knowledge of design patterns
              a mark of irresponsibility in a software professional. Design
              Patterns represent an invaluable body of knowledge that describes how
              past engineers have solved common problems. This cannot help but be
              of aid to future engineers facing those problems.

              Still, patterns are not a panacea. They do not solve all design
              problems. Nor do they represent a tool, method, or recipe for solving
              design problems. Rather they are simply descriptions of what has
              worked in a few situations in the past.

              How should designers employ design patterns? In my opinion they
              should not *try* to employ them at all. Rather designers need to
              become so intimately familiar with design patterns that they simply
              know when a given pattern fits into their design or not.

              This notion of "fit" is a tricky one. It is easy to face a design
              problem and leap to a pattern that solves it. But does that pattern
              provide a solution that is appropriate to the context? Or might there
              be a simpler solution?

              Design patterns should not be used in lieu of finding the best design.
              A designer might consider a particular pattern to help solve a
              problem; but should not assume that the pattern is the best solution.
              A pattern is not "best" simply because it is a pattern.

              One can view the choice of a pattern as a hypothesis: "I hypothesize
              that the observer pattern is a good solution to this problem." A good
              designer will then set about to choose a set of experiments that will
              verify this hypothesis. Those experiments are likely to be tiny
              stepwise implementations if test cases that, bit by bit, implement the
              problem to be solved. At any time during this implementation, the
              pattern should be viewed only as a vague direction, not as the law.
              And should the experiments show that the pattern is not optimal, the
              pattern should be abandoned.

              I have an article that demonstrates this technique appearing in my
              column in an upcoming Java Report.


              Robert C. Martin | "Uncle Bob" | Software Consultants
              Object Mentor Inc. | rmartin@... | We'll help you get
              PO Box 5757 | Tel: (800) 338-6716 | your projects done.
              565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
              Suite 135 | | www.XProgramming.com
              Vernon Hills, IL, | Training and Mentoring | www.junit.org
              60061 | OO, XP, Java, C++, Python|

              "One of the great commandments of science is:
              'Mistrust arguments from authority.'" -- Carl Sagan

              -----------------------------------------------------------------
              To unsubscribe from OTUG, send an email to majordomo@...
              with the word 'unsubscribe' in the body of the message.


              ________________________________________________________________________
              ________________________________________________________________________

              Message: 25
              Date: Fri, 27 Apr 2001 19:52:42 GMT
              From: rmartin@...
              Subject: (OTUG) How to use design patterns.

              There has recently been a conjecture placed on the extreme programming
              mail group that Design Patterns are harmful. The complaint is that
              designers try to force patterns into a design rather than trying to
              determine the best structure for the design.

              I am sympathetic to this view. However I don't think design patterns
              are harmful. Indeed, I consider lack of knowledge of design patterns
              a mark of irresponsibility in a software professional. Design
              Patterns represent an invaluable body of knowledge that describes how
              past engineers have solved common problems. This cannot help but be
              of aid to future engineers facing those problems.

              Still, patterns are not a panacea. They do not solve all design
              problems. Nor do they represent a tool, method, or recipe for solving
              design problems. Rather they are simply descriptions of what has
              worked in a few situations in the past.

              How should designers employ design patterns? In my opinion they
              should not *try* to employ them at all. Rather designers need to
              become so intimately familiar with design patterns that they simply
              know when a given pattern fits into their design or not.

              This notion of "fit" is a tricky one. It is easy to face a design
              problem and leap to a pattern that solves it. But does that pattern
              provide a solution that is appropriate to the context? Or might there
              be a simpler solution?

              Design patterns should not be used in lieu of finding the best design.
              A designer might consider a particular pattern to help solve a
              problem; but should not assume that the pattern is the best solution.
              A pattern is not "best" simply because it is a pattern.

              One can view the choice of a pattern as a hypothesis: "I hypothesize
              that the observer pattern is a good solution to this problem." A good
              designer will then set about to choose a set of experiments that will
              verify this hypothesis. Those experiments are likely to be tiny
              stepwise implementations if test cases that, bit by bit, implement the
              problem to be solved. At any time during this implementation, the
              pattern should be viewed only as a vague direction, not as the law.
              And should the experiments show that the pattern is not optimal, the
              pattern should be abandoned.

              I have an article that demonstrates this technique appearing in my
              column in an upcoming Java Report.


              Robert C. Martin | "Uncle Bob" | Software Consultants
              Object Mentor Inc. | rmartin@... | We'll help you get
              PO Box 5757 | Tel: (800) 338-6716 | your projects done.
              565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
              Suite 135 | | www.XProgramming.com
              Vernon Hills, IL, | Training and Mentoring | www.junit.org
              60061 | OO, XP, Java, C++, Python|

              "One of the great commandments of science is:
              'Mistrust arguments from authority.'" -- Carl Sagan

              -----------------------------------------------------------------
              To unsubscribe from OTUG, send an email to majordomo@...
              with the word 'unsubscribe' in the body of the message.

              -----------------------------------------------------------------
              To unsubscribe from OTUG, send an email to majordomo@...
              with the word 'unsubscribe' in the body of the message.


              ________________________________________________________________________
              ________________________________________________________________________



              Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            • Fabio Armani
              unsubscribe [Non-text portions of this message have been removed]
              Message 6 of 20 , May 4 12:27 AM
              • 0 Attachment
                unsubscribe


                [Non-text portions of this message have been removed]
              • Karen Chetrit
                extremeprogramming-unsubscribe@eGroups.com
                Message 7 of 20 , Jul 27, 2001
                • 0 Attachment
                • Molitor, Stephen
                  unsubscribe
                  Message 8 of 20 , Jul 28, 2001
                  • 0 Attachment
                    unsubscribe
                  • Jim.Hyslop
                    ... Welcome to the Hotel California... You can check out any time you like, but you can never leave. :-) Seriously, though, Åsa, I found that it can take a
                    Message 9 of 20 , Dec 12, 2001
                    • 0 Attachment
                      Lee Armstrong <lee_armstrong39@...> wrote:
                      > --- Åsa Berggren <asa.berggren@...> wrote:
                      > > Hi,
                      > >
                      > > I have tried several times to unsubscribe to this
                      > > mailling list
                      >
                      > Why would you want to do that? I don't think we
                      > should tell you...
                      Welcome to the Hotel California... You can check out any time you like, but
                      you can never leave. :-)

                      Seriously, though, Åsa, I found that it can take a while for the yahoogroups
                      server to process an unsubscribe request after the verification. If you're
                      still having problems, try emailing the list owners at
                      extremeprogramming-owner@yahoogroups.com

                      --
                      Jim
                    • Rob Myers
                      Jim, ... Thank you! You may have just given me a metaphor for our latest XP project. (It certainly beats the vacuum cleaner metaphor, which simply sucked.)
                      Message 10 of 20 , Dec 12, 2001
                      • 0 Attachment
                        Jim,

                        > Welcome to the Hotel California... You can check out any time you
                        > like, but
                        > you can never leave. :-)

                        Thank you! You may have just given me a metaphor for our latest XP project.

                        (It certainly beats the vacuum cleaner metaphor, which simply sucked.)

                        Rob

                        Rob Myers
                        XP Coach/Programmer
                        Mindful Software
                        www.mindfulsoftware.com
                      • Chris Young-InteractiveTV
                        This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have
                        Message 11 of 20 , Apr 14, 2002
                        • 0 Attachment
                          This e-mail (and any attachments) is confidential and may contain personal
                          views which are not the views of the BBC unless specifically stated.
                          If you have received it in error, please delete it from your system, do not use,
                          copy or disclose the information in any way nor act in reliance on it and notify
                          the sender immediately. Please note that the BBC monitors e-mails sent
                          or received. Further communication will signify your consent to this.
                        • Arun Kaushik
                          unsubscribe __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
                          Message 12 of 20 , May 22 8:39 AM
                          • 0 Attachment
                            unsubscribe

                            __________________________________________________
                            Do You Yahoo!?
                            LAUNCH - Your Yahoo! Music Experience
                            http://launch.yahoo.com
                          • Arun Kaushik
                            unsubscribe __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
                            Message 13 of 20 , May 22 8:39 AM
                            • 0 Attachment
                              unsubscribe

                              __________________________________________________
                              Do You Yahoo!?
                              LAUNCH - Your Yahoo! Music Experience
                              http://launch.yahoo.com
                            • Molitor, Stephen
                              unsubscribe
                              Message 14 of 20 , Oct 2, 2002
                              • 0 Attachment
                                unsubscribe
                              • Rodel P. Hipolito
                                Rodel P. Hipolito Ecommsite Solutions, Inc. A: 30th Floor IBM Plaza Eastwood City Cyberpark E. Rodriguez Jr. Avenue Libis, Quezon City T: +632-4219406 F:
                                Message 15 of 20 , Oct 30, 2003
                                • 0 Attachment
                                  Rodel P. Hipolito
                                  Ecommsite Solutions, Inc.
                                  A: 30th Floor IBM Plaza
                                  Eastwood City Cyberpark
                                  E. Rodriguez Jr. Avenue
                                  Libis, Quezon City
                                  T: +632-4219406
                                  F: +632-9122788 loc 110
                                  W: http://www.ecommsite.com
                                  http://www.sysads.org
                                  E: rhipolito@...
                                  M: +639209060595
                                • Rodel P. Hipolito
                                  Rodel P. Hipolito Ecommsite Solutions, Inc. A: 30th Floor IBM Plaza Eastwood City Cyberpark E. Rodriguez Jr. Avenue Libis, Quezon City T: +632-4219406 F:
                                  Message 16 of 20 , Nov 6, 2003
                                  • 0 Attachment
                                    Rodel P. Hipolito
                                    Ecommsite Solutions, Inc.
                                    A: 30th Floor IBM Plaza
                                    Eastwood City Cyberpark
                                    E. Rodriguez Jr. Avenue
                                    Libis, Quezon City
                                    T: +632-4219406
                                    F: +632-9122788 loc 110
                                    W: http://www.ecommsite.com
                                    http://www.sysads.org
                                    E: rhipolito@...
                                    M: +639209060595
                                  • Ivan Tomek
                                    unsubscribe
                                    Message 17 of 20 , Feb 22, 2004
                                    • 0 Attachment
                                      unsubscribe
                                    • Harald Svensson
                                      Hello, I want to unsubscribe to this mail group, I have tried to send a blank message to the suggested mail address but to no use. What must I do to stop
                                      Message 18 of 20 , Jan 13, 2006
                                      • 0 Attachment
                                        Hello, I want to unsubscribe to this mail group, I have tried to send a
                                        blank message to the suggested mail address but to no use.

                                        What must I do to stop recieve all these mail from the extreme programming
                                        group!?



                                        Best regards
                                        Harald
                                      • Ian Collins
                                        ... Go to the url and unsubscribe there. Ian
                                        Message 19 of 20 , Jan 13, 2006
                                        • 0 Attachment
                                          Harald Svensson wrote:

                                          >Hello, I want to unsubscribe to this mail group, I have tried to send a
                                          >blank message to the suggested mail address but to no use.
                                          >
                                          >What must I do to stop recieve all these mail from the extreme programming
                                          >group!?
                                          >
                                          >
                                          >
                                          >
                                          Go to the url and unsubscribe there.

                                          Ian
                                        • Ron Jeffries
                                          ... I ve removed you. Good luck! Ron Jeffries www.XProgramming.com The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
                                          Message 20 of 20 , Jan 13, 2006
                                          • 0 Attachment
                                            On Friday, January 13, 2006, at 7:36:54 PM, Harald Svensson wrote:

                                            > Hello, I want to unsubscribe to this mail group, I have tried to send a
                                            > blank message to the suggested mail address but to no use.

                                            > What must I do to stop recieve all these mail from the extreme programming
                                            > group!?

                                            I've removed you. Good luck!

                                            Ron Jeffries
                                            www.XProgramming.com
                                            The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
                                          Your message has been successfully submitted and would be delivered to recipients shortly.