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

Re: [XP] The baseball project (Re: Re: Re: Easy things first)

Expand Messages
  • Ron Jeffries
    ... I thought I fixed that. Isn t the report right? Even if it isn t, it s not an interesting problem, since I ll just have to reverse the guys on opposite
    Message 1 of 15 , May 1, 2002
    • 0 Attachment
      Around Wednesday, May 1, 2002, 11:34:55 AM, J. B. Rainsberger wrote:

      > Quoting extremeprogramming@yahoogroups.com:

      >> From: Ron Jeffries <ronjeffries@...>
      >>
      >> Around Monday, April 29, 2002, 1:42:54 PM, J. B. Rainsberger wrote:
      >>
      >> > Team W L Pct GBL
      >> > Toronto 6 2 .750 --
      >> > Baltimore 5 3 .625 1
      >> > Boston 5 4 .556 1 1/2
      >> > New York 3 5 .375 3
      >> > Tampa Bay 1 6 .143 4 1/2
      >>
      >> Here's the next installment. It's a long one, not least because it has
      >> a complete listing.
      >>
      >> ==========================================
      >>
      >> Well, OK, what shall I do now? There aren't really any interesting
      >> problems left that I can see.

      > OK, this is an interesting statement. Let's review what you have so far -- even
      > by the end of this session:

      > * Games back is computed, although the sign is wrong. Trailers are currently
      > negative-n games back, rather than n games back.

      I thought I fixed that. Isn't the report right? Even if it isn't, it's
      not an interesting problem, since I'll just have to reverse the guys
      on opposite sides of a subtract ...

      > * Sort by winning percentage works.
      > * Leader is correctly identified.
      > * Can process a file that's not quite the format required.

      >>From your comment, what's not done is not "interesting" to you. I think if you
      > can describe why, that would be the central thing to learn from you in this
      > exercise. What makes the things you haven't done yet "uninteresting" compared
      > to the things you've already done which are "interesting". Thanks!

      > What is not done:

      > * Categorizing teams into divisions and leagues.

      This isn't interesting for two reasons: first and foremost, I don't
      have the data defining divisions and leagues. Second, whatever it is,
      it'll be a partition or two on the input data, so the ultimate report
      will consist, I expect, of a loop over league, loop over division,
      select members, print the standard report. Note that my report reports
      on any collection of teams, so I'm sure it'll work if fed with the
      right teams.

      > * Reporting on the leaders within each division.

      I don't have a story for this, do I?

      > * Correct formatting.

      Nitty-gritty grunt work. Nothing to learn, just screw with it. It's
      all about padding the fields to the right size, and some messing
      around to get 1.5 to print as 1 1/2.

      > * Process the original input format requested.

      Grunt work. As defined the input looks irritating to parse, since
      there is no punctuation. The input looks like team name score-score
      team name, and for all I know the team name can have numbers in it. If
      it's really <alphaspaced><number><dash><number><alphaspaced> it won't
      be too hard. It's about a regex away from easy.


      I'll comment here on what I did. I was chatting with Chet about it at
      lunch today. I'm not sure whether or not there was great (but hidden)
      skill in deciding what to attack.

      It might have been more XPish to have started from an input file and
      produced the report test first. Instead, I zeroed in on the Team
      concept as a holder for the win/loss record. Once that was done, there
      were a few interesting things to do: get enough data into teams to
      create them; compare them to get games back; compute their percentage
      of wins. Then the report's interesting issues are finding the leader,
      and sorting in the right order. The rest of reporting is iterate over
      the collection print the line, just like every other report in the
      universe.

      What I was trying to do ... what I'm always trying to do ... is to see
      what part of the problem meets two criteria:

      1. I don't know how to do it.
      2. It looks bite-size.

      In this case I was sure that "collection of teams", which is an
      instance of a pattern "collection of detail objects", was close enough
      to a good answer to go ahead with it. That surely takes some kind of
      experience and skill to get right. It seemed obvious to me, but it's
      not clear to me whether it would seem obvious to other programmers of
      differing experience.

      In other times or problems, I might have started with a straight "fake
      it till you make it" off the original input, but I don't think so.

      Another way to go might have been to build teams that just knew their
      games back by magic, but that didn't occur to me until now and I'm not
      sure it would have made sense. It seemed natural to create a team with
      what I knew (win/loss) and go from there.

      So, was it a good way, one that I'd write a book about? Maybe not. It
      was my way, and I hope it's interesting and/or useful to people to
      observe and think about.

      Comments and questions are welcome ...

      ===================
      >> That looks about right. Now let's see about getting GBL. That'll be
      >> tricky, I will have to pass in the leader team. (I don't know which
      >> team is leader ... never tested that feature. I guess I'm about to.)

      > Why not a separate unit test for this feature?

      Well, probably there should be one. I expect that it'll come out in a
      later acceptance test. Generating weird data for this thing is beyond
      me as a non-lover of baseball. The code for leader is simple, so at
      the time I thought it worked. Applied the principle of testing
      everything that could possibly break. Worth noting, since those are
      the places that break. ;->

      > PS: I apologize for not providing better AT data. I'm still learning to be a
      > customer, too. :)

      Chet remarked at California Pizza Kitchen that he thought the
      conversation / negotiation between customer and programmer was an
      interesting part of this exchange. Chet, say more about that?

      Ron Jeffries
      www.XProgramming.com
      Adapt, improvise, overcome.
      --Gunnery Sergeant Tom Highway (Heartbreak Ridge)
    • J. B. Rainsberger
      ... Quoting from an earlier message, you gave this report: Toronto 2 0 1.000 0.0 Chicago 2 0 1.000 0.0 New York 1 1 .500 -1.0 Tampa Bay 1 1 .500 -1.0 Boston 0
      Message 2 of 15 , May 2, 2002
      • 0 Attachment
        Quoting extremeprogramming@yahoogroups.com:

        > Subject: Re: The baseball project (Re: Re: Re: Easy things first)
        >
        > >> Around Monday, April 29, 2002, 1:42:54 PM, J. B. Rainsberger wrote:
        > >>
        > >> > Team W L Pct GBL
        > >> > Toronto 6 2 .750 --
        > >> > Baltimore 5 3 .625 1
        > >> > Boston 5 4 .556 1 1/2
        > >> > New York 3 5 .375 3
        > >> > Tampa Bay 1 6 .143 4 1/2
        > >>
        > > OK, this is an interesting statement. Let's review what you have so
        > far -- even
        > > by the end of this session:
        >
        > > * Games back is computed, although the sign is wrong. Trailers are
        > currently
        > > negative-n games back, rather than n games back.
        >
        > I thought I fixed that. Isn't the report right? Even if it isn't, it's
        > not an interesting problem, since I'll just have to reverse the guys
        > on opposite sides of a subtract ...

        Quoting from an earlier message, you gave this report:
        Toronto 2 0 1.000 0.0
        Chicago 2 0 1.000 0.0
        New York 1 1 .500 -1.0
        Tampa Bay 1 1 .500 -1.0
        Boston 0 2 .000 -2.0
        Baltimore 0 2 .000 -2.0

        Baltimore is 2 GB, not -2 GB, for example.

        > >>From your comment, what's not done is not "interesting" to you. I
        > think if you
        > > can describe why, that would be the central thing to learn from you in
        > this
        > > exercise. What makes the things you haven't done yet "uninteresting"
        > compared
        > > to the things you've already done which are "interesting". Thanks!
        >
        > > What is not done:
        >
        > > * Categorizing teams into divisions and leagues.
        >
        > This isn't interesting for two reasons: first and foremost, I don't
        > have the data defining divisions and leagues. Second, whatever it is,
        > it'll be a partition or two on the input data, so the ultimate report
        > will consist, I expect, of a loop over league, loop over division,
        > select members, print the standard report. Note that my report reports
        > on any collection of teams, so I'm sure it'll work if fed with the
        > right teams.

        Good point.

        > > * Reporting on the leaders within each division.
        >
        > I don't have a story for this, do I?

        Maybe I miswrote: I meant, in each division, each team's GB number is shown
        relative to the leader of the division. If I omitted that, I'm adding it now. :)

        > > * Correct formatting.
        >
        > Nitty-gritty grunt work. Nothing to learn, just screw with it. It's
        > all about padding the fields to the right size, and some messing
        > around to get 1.5 to print as 1 1/2.

        OK.

        > > * Process the original input format requested.
        >
        > Grunt work. As defined the input looks irritating to parse, since
        > there is no punctuation. The input looks like team name score-score
        > team name, and for all I know the team name can have numbers in it. If
        > it's really <alphaspaced><number><dash><number><alphaspaced> it won't
        > be too hard. It's about a regex away from easy.

        That's what I was thinking. The format does have a simple context-free grammar
        and the team name will never have anything except alpha/space/punctuation. An
        exhaustive list of the exact strings is available on demand.

        > I'll comment here on what I did. I was chatting with Chet about it at
        > lunch today. I'm not sure whether or not there was great (but hidden)
        > skill in deciding what to attack.

        This is the heart of what I'm interested to know.

        > It might have been more XPish to have started from an input file and
        > produced the report test first. Instead, I zeroed in on the Team
        > concept as a holder for the win/loss record. Once that was done, there
        > were a few interesting things to do: get enough data into teams to
        > create them; compare them to get games back; compute their percentage
        > of wins. Then the report's interesting issues are finding the leader,
        > and sorting in the right order. The rest of reporting is iterate over
        > the collection print the line, just like every other report in the
        > universe.
        >
        > What I was trying to do ... what I'm always trying to do ... is to see
        > what part of the problem meets two criteria:
        >
        > 1. I don't know how to do it.
        > 2. It looks bite-size.
        >
        > In this case I was sure that "collection of teams", which is an
        > instance of a pattern "collection of detail objects", was close enough
        > to a good answer to go ahead with it. That surely takes some kind of
        > experience and skill to get right. It seemed obvious to me, but it's
        > not clear to me whether it would seem obvious to other programmers of
        > differing experience.

        Likely it would have been more instructive to me if I'd accepted the challenge
        myself first, then compared your approach to mine.

        > In other times or problems, I might have started with a straight "fake
        > it till you make it" off the original input, but I don't think so.
        >
        > Another way to go might have been to build teams that just knew their
        > games back by magic, but that didn't occur to me until now and I'm not
        > sure it would have made sense. It seemed natural to create a team with
        > what I knew (win/loss) and go from there.

        I might have started here. I have a tendency to fake data from the outside,
        then "push the fake stuff inward". Each time I push it one step more inward, I
        implement some things until, eventually, the fake stuff is as far in as it will
        go -- then I implement it for real.

        As an example, I'm working on a web application. The project is at the point
        where adding more application features boils down to:

        1. Design an XML format for the output.
        2. Create an XSL stylesheet to present the output.
        3. Create a Service class to print the output in XML format.
        4. Create Value Objects to store the data for the Service to present.
        5. Create a Store class to perform the usual CRUD operations on the Value
        Objects.

        My general approach is to:

        1. Fake out the XML data in the Service, concentrating on getting the format
        right.
        2. Create the XSL stylesheet to pretty up the output.
        3. Push the fake data into the Value Objects; make the Service talk to the
        Value Objects.
        4. Push the fake data from the Value Objects into the Store; make the Service
        talk to the Store to get the Value Objects. Now the Service should work.
        5. Implement the Store for real. Now the whole thing should work.

        Your approach on this little problem was essentially the reverse of my approach
        on my current project. I used to build the Store and Value Objects first, the
        Service/XML/XSL next, then integrate the two last. I would say that now that I
        understand the implementation patterns, I prefer my current approach, although
        in the beginning, I liked the approach I was using at the time. That is a
        measure of experience factoring into deciding on an approach, whether it's
        experience in the broader sense or simply experience within the current
        programming model.

        > >> That looks about right. Now let's see about getting GBL. That'll be
        > >> tricky, I will have to pass in the leader team. (I don't know which
        > >> team is leader ... never tested that feature. I guess I'm about
        > to.)
        >
        > > Why not a separate unit test for this feature?
        >
        > Well, probably there should be one. I expect that it'll come out in a
        > later acceptance test. Generating weird data for this thing is beyond
        > me as a non-lover of baseball.

        Bite your tongue! What are you a lover of, then?

        > The code for leader is simple, so at
        > the time I thought it worked. Applied the principle of testing
        > everything that could possibly break. Worth noting, since those are
        > the places that break. ;->

        Indeed.

        > > PS: I apologize for not providing better AT data. I'm still learning
        > to be a
        > > customer, too. :)
        >
        > Chet remarked at California Pizza Kitchen that he thought the
        > conversation / negotiation between customer and programmer was an
        > interesting part of this exchange. Chet, say more about that?

        Yes, Chet. Please, do. I would be interested in learning more about this aspect
        of XP, since I have very little good experience with customers.

        J. B. (Joe) Rainsberger
        President, Diaspar Software Services
        http://www.diasparsoftware.com
        Let's write software that people understand.
      • Ron Jeffries
        ... Your report looked like it was broken out by division, n est pas? So each group is relative to the group? Ron Jeffries www.XProgramming.com XP says: Don t
        Message 3 of 15 , May 2, 2002
        • 0 Attachment
          Around Thursday, May 2, 2002, 1:35:32 PM, J. B. Rainsberger wrote:

          >> I don't have a story for this, do I?

          > Maybe I miswrote: I meant, in each division, each team's GB number is shown
          > relative to the leader of the division. If I omitted that, I'm adding it now. :)

          Your report looked like it was broken out by division, n'est pas? So
          each group is relative to the group?

          Ron Jeffries
          www.XProgramming.com
          XP says: Don't just sit on your DUF, do something. Get some feedback.
        • Ron Jeffries
          ... I guess this test is wrong then? def testAB teamA = Team.new( a , 5,2) teamB = Team.new( b , 4,4) back = teamA.gamesBack(teamB) assert_equal(1.5, back)
          Message 4 of 15 , May 2, 2002
          • 0 Attachment
            Around Thursday, May 2, 2002, 1:35:32 PM, J. B. Rainsberger wrote:

            >> I thought I fixed that. Isn't the report right? Even if it isn't, it's
            >> not an interesting problem, since I'll just have to reverse the guys
            >> on opposite sides of a subtract ...

            > Quoting from an earlier message, you gave this report:
            > Toronto 2 0 1.000 0.0
            > Chicago 2 0 1.000 0.0
            > New York 1 1 .500 -1.0
            > Tampa Bay 1 1 .500 -1.0
            > Boston 0 2 .000 -2.0
            > Baltimore 0 2 .000 -2.0

            > Baltimore is 2 GB, not -2 GB, for example.

            I guess this test is wrong then?

            def testAB
            teamA = Team.new("a", 5,2)
            teamB = Team.new("b", 4,4)
            back = teamA.gamesBack(teamB)
            assert_equal(1.5, back)
            assert_equal('1.500', Team.formatBack(back))
            end

            B is 1.5 games back from A, not the way I have it? I guess I needed an
            acceptance test.

            Ron Jeffries
            www.XProgramming.com
            The Great and Powerful Oz has spoken.
          • Ron Jeffries
            ... I m not entirely sure I understand the problem. Of course what I would really do would depend on what happened, but I d think this way: I know how to do
            Message 5 of 15 , May 2, 2002
            • 0 Attachment
              Around Thursday, May 2, 2002, 1:35:32 PM, J. B. Rainsberger wrote:

              > As an example, I'm working on a web application. The project is at the point
              > where adding more application features boils down to:

              > 1. Design an XML format for the output.
              > 2. Create an XSL stylesheet to present the output.
              > 3. Create a Service class to print the output in XML format.
              > 4. Create Value Objects to store the data for the Service to present.
              > 5. Create a Store class to perform the usual CRUD operations on the Value
              > Objects.

              > My general approach is to:

              > 1. Fake out the XML data in the Service, concentrating on getting the format
              > right.
              > 2. Create the XSL stylesheet to pretty up the output.
              > 3. Push the fake data into the Value Objects; make the Service talk to the
              > Value Objects.
              > 4. Push the fake data from the Value Objects into the Store; make the Service
              > talk to the Store to get the Value Objects. Now the Service should work.
              > 5. Implement the Store for real. Now the whole thing should work.

              > Your approach on this little problem was essentially the reverse of my approach
              > on my current project. I used to build the Store and Value Objects first, the
              > Service/XML/XSL next, then integrate the two last. I would say that now that I
              > understand the implementation patterns, I prefer my current approach, although
              > in the beginning, I liked the approach I was using at the time. That is a
              > measure of experience factoring into deciding on an approach, whether it's
              > experience in the broader sense or simply experience within the current
              > programming model.

              I'm not entirely sure I understand the problem. Of course what I would really
              do would depend on what happened, but I'd think this way:

              I know how to do XML->XSLT->HTML. It's nitty and a pain, but not
              challenging. Therefore I need to get objects with the right data. I'll
              format them last. (I might reverse this decision if I thought the
              styling would be difficult or time-consuming, or if I wanted to show
              the customer what it would look like so they could change their mine.
              On the other hand, I once watched a company go down the tubes while
              the big guys tweaked a GUI that didn't have enough function under it.)

              So I might create some value objects by hand and hook them up. I don't
              know quite what "hook them up to the service" means, since I've never
              done that. Another reason to do it early.

              You then said you would push the fake guys into the Store and make the
              Service get them. I'm not sure how it got them the first time through,
              but I guess this means Service makes some kind of a call on Store and
              my fake value guys come back. That sounds like a good next step: I'd
              basically stub the Store to just answer the canned guys.

              Then work on the retrieval of real guys by the Store. Don't know what
              that would mean, I guess it would depend on what the Store already
              knows and what it doesn't. Is this like an RDB that is retrieving some
              junk from the DB and making objects? (If so, are these really records
              rather than objects? Do they have any behavior? Oh well, doesn't
              matter ...)

              Then I'd have the right guys coming out of Store and going to Service,
              formatted in a rough way. I'd ship the ******, then fiddle with
              formatting until time ran out.

              Probably. Depends on a lot of things I don't know, and a few things I
              don't even know about.

              Ron Jeffries
              www.XProgramming.com
              Sorry about your cow ... I didn't know she was sacred.
            • J. B. Rainsberger
              ... is ... adding it ... That parsed, but I didn t understand right away. I think the answer is Yes . Within each group, teams should report against the
              Message 6 of 15 , May 2, 2002
              • 0 Attachment
                > From: Ron Jeffries <ronjeffries@...>
                >Subject: Re: Re: The baseball project (Re: Re: Re: Easy things first)
                >
                >Around Thursday, May 2, 2002, 1:35:32 PM, J. B. Rainsberger wrote:
                >
                >>> I don't have a story for this, do I?
                >
                >> Maybe I miswrote: I meant, in each division, each team's GB number
                is
                >shown
                >> relative to the leader of the division. If I omitted that, I'm
                adding it
                >now. :)
                >
                >Your report looked like it was broken out by division, n'est pas? So
                >each group is relative to the group?

                That parsed, but I didn't understand right away. I think the answer is
                "Yes". Within each group, teams should "report against" the leader of
                the group. The different groups have nothing to do with each other,
                from a reporting standpoint.

                J. B. Rainsberger,
                President, Diaspar Software Services
                Let's write software that people understand.
                http://www.diasparsoftware.com/
                telephone: +1 416 791-8603
              • J. B. Rainsberger
                ... it s ... guys ... Correct. As for the acceptance test: Example: Team A has 5 wins, 2 losses; Team B has 4 wins, 4 losses. Team B is 1-1/2 games back of
                Message 7 of 15 , May 2, 2002
                • 0 Attachment
                  > From: Ron Jeffries <ronjeffries@...>
                  >Subject: Re: Re: The baseball project (Re: Re: Re: Easy things first)
                  >
                  >Around Thursday, May 2, 2002, 1:35:32 PM, J. B. Rainsberger wrote:
                  >
                  >>> I thought I fixed that. Isn't the report right? Even if it isn't,
                  it's
                  >>> not an interesting problem, since I'll just have to reverse the
                  guys
                  >>> on opposite sides of a subtract ...
                  >
                  >> Quoting from an earlier message, you gave this report:
                  >> Toronto 2 0 1.000 0.0
                  >> Chicago 2 0 1.000 0.0
                  >> New York 1 1 .500 -1.0
                  >> Tampa Bay 1 1 .500 -1.0
                  >> Boston 0 2 .000 -2.0
                  >> Baltimore 0 2 .000 -2.0
                  >
                  >> Baltimore is 2 GB, not -2 GB, for example.
                  >
                  >I guess this test is wrong then?
                  >
                  > def testAB
                  > teamA = Team.new("a", 5,2)
                  > teamB = Team.new("b", 4,4)
                  > back = teamA.gamesBack(teamB)
                  > assert_equal(1.5, back)
                  > assert_equal('1.500', Team.formatBack(back))
                  > end
                  >
                  >B is 1.5 games back from A, not the way I have it? I guess I needed an
                  >acceptance test.

                  Correct. As for the acceptance test:

                  "Example: Team A has 5 wins, 2 losses; Team B has 4 wins, 4
                  losses. Team B is 1-1/2 games back of Team A: 1/2 ((5-2) - (4-4)) =
                  1.5." -- April 23, from the first "little" problem I posed.

                  I'm sorry that I didn't automate it for you. :)

                  J. B. Rainsberger,
                  President, Diaspar Software Services
                  Let's write software that people understand.
                  http://www.diasparsoftware.com/
                  telephone: +1 416 791-8603
                • J. B. Rainsberger
                  ... the ... present. ... the ... to ... the ... work. ... my ... now ... approach, ... is ... whether ... current ... The Servlet maps the incoming request to
                  Message 8 of 15 , May 2, 2002
                  • 0 Attachment
                    > From: Ron Jeffries <ronjeffries@...>
                    >Subject: Re: Re: The baseball project (Re: Re: Re: Easy things first)
                    >
                    >Around Thursday, May 2, 2002, 1:35:32 PM, J. B. Rainsberger wrote:
                    >
                    >> As an example, I'm working on a web application. The project is at
                    the
                    >point
                    >> where adding more application features boils down to:
                    >
                    >> 1. Design an XML format for the output.
                    >> 2. Create an XSL stylesheet to present the output.
                    >> 3. Create a Service class to print the output in XML format.
                    >> 4. Create Value Objects to store the data for the Service to
                    present.
                    >> 5. Create a Store class to perform the usual CRUD operations on the
                    >Value
                    >> Objects.
                    >
                    >> My general approach is to:
                    >
                    >> 1. Fake out the XML data in the Service, concentrating on getting
                    the
                    >format
                    >> right.
                    >> 2. Create the XSL stylesheet to pretty up the output.
                    >> 3. Push the fake data into the Value Objects; make the Service talk
                    to
                    >the
                    >> Value Objects.
                    >> 4. Push the fake data from the Value Objects into the Store; make
                    the
                    >Service
                    >> talk to the Store to get the Value Objects. Now the Service should
                    work.
                    >> 5. Implement the Store for real. Now the whole thing should work.
                    >
                    >> Your approach on this little problem was essentially the reverse of
                    my
                    >approach
                    >> on my current project. I used to build the Store and Value Objects
                    >first, the
                    >> Service/XML/XSL next, then integrate the two last. I would say that
                    now
                    >that I
                    >> understand the implementation patterns, I prefer my current
                    approach,
                    >although
                    >> in the beginning, I liked the approach I was using at the time. That
                    is
                    >a
                    >> measure of experience factoring into deciding on an approach,
                    whether
                    >it's
                    >> experience in the broader sense or simply experience within the
                    current
                    >> programming model.
                    >
                    >I'm not entirely sure I understand the problem. Of course what I would
                    >really
                    >do would depend on what happened, but I'd think this way:
                    >
                    >I know how to do XML->XSLT->HTML. It's nitty and a pain, but not
                    >challenging. Therefore I need to get objects with the right data. I'll
                    >format them last. (I might reverse this decision if I thought the
                    >styling would be difficult or time-consuming, or if I wanted to show
                    >the customer what it would look like so they could change their mine.
                    >On the other hand, I once watched a company go down the tubes while
                    >the big guys tweaked a GUI that didn't have enough function under it.)
                    >
                    >So I might create some value objects by hand and hook them up. I don't
                    >know quite what "hook them up to the service" means, since I've never
                    >done that. Another reason to do it early.

                    The Servlet maps the incoming request to a Service class, then the
                    Service handles the request and prints an XML document as the response.
                    First, I code the Service to print a valid XML document with the format
                    I want, but fake data. Next, I create Value Objects to store the fake
                    data, then code the Service to extract the data from the (fake) Value
                    Objects.

                    That's what I meant.

                    >You then said you would push the fake guys into the Store and make the
                    >Service get them. I'm not sure how it got them the first time through,
                    >but I guess this means Service makes some kind of a call on Store and
                    >my fake value guys come back. That sounds like a good next step: I'd
                    >basically stub the Store to just answer the canned guys.

                    Before, the Service was using Value Objects with canned data. After,
                    the Service calls the Store to get the data.

                    >Then work on the retrieval of real guys by the Store. Don't know what
                    >that would mean, I guess it would depend on what the Store already
                    >knows and what it doesn't. Is this like an RDB that is retrieving some
                    >junk from the DB and making objects? (If so, are these really records
                    >rather than objects? Do they have any behavior? Oh well, doesn't
                    >matter ...)

                    The Store talks to an RDB and creates Value Objects from the data.

                    >Then I'd have the right guys coming out of Store and going to Service,
                    >formatted in a rough way. I'd ship the ******, then fiddle with
                    >formatting until time ran out.

                    The UI design is dictated to us by months of upfront nonsense (I mean
                    analysis). We used to start our customer with a blank canvas and design
                    the UI together, but when we got new customers, the new guys just point
                    to the big-book-of-cr1p and say, "Give us that." (They're good guys,
                    but they feel a little overwhelmed by the positions into which they
                    have been thrust.) We just code to the documentation until the
                    customers tell us they want something different.

                    J. B. Rainsberger,
                    President, Diaspar Software Services
                    Let's write software that people understand.
                    http://www.diasparsoftware.com/
                    telephone: +1 416 791-8603
                  • Ron Jeffries
                    ... It wasn t my best work. Anyway, the leader is unique to the group and so I don t find the leader/division/league problem interesting . Ron Jeffries
                    Message 9 of 15 , May 2, 2002
                    • 0 Attachment
                      Around Thursday, May 2, 2002, 9:31:31 PM, J. B. Rainsberger wrote:

                      >>Around Thursday, May 2, 2002, 1:35:32 PM, J. B. Rainsberger wrote:
                      >>
                      >>>> I don't have a story for this, do I?
                      >>
                      >>> Maybe I miswrote: I meant, in each division, each team's GB number
                      > is
                      >>shown
                      >>> relative to the leader of the division. If I omitted that, I'm
                      > adding it
                      >>now. :)
                      >>
                      >>Your report looked like it was broken out by division, n'est pas? So
                      >>each group is relative to the group?

                      > That parsed, but I didn't understand right away. I think the answer is
                      > "Yes". Within each group, teams should "report against" the leader of
                      > the group. The different groups have nothing to do with each other,
                      > from a reporting standpoint.

                      It wasn't my best work. Anyway, the leader is unique to the group and
                      so I don't find the leader/division/league problem "interesting".

                      Ron Jeffries
                      www.XProgramming.com
                      Sorry about your cow ... I didn't know she was sacred.
                    Your message has been successfully submitted and would be delivered to recipients shortly.