Re: AW: [Pyogp] Design and Coding Process [bayes]
I wholeheartedly agree on all counts. Let's take my office hours on Friday to come up with a strategy (reviewing Tao's proposal as a starting point), and start looking at what's up next (that as yet undefined roadmap). Tess Chu wrote: One thing that I'd like to discuss is some sort of peer programming, like having pairs of developers collaborating on specific problems. While I have no idea yet on how to handle that technically in an intercontinental way (some VNCserver looking-over-the-shoulder-approch we use here might raise security issues), I could imagine that this gives valuable output and esp. two people building up know-how on the same issue. This way someone could be off for a time and still there is someone else able to answer questions. +1 In Icehouse, and now in Open Platform group, we find it very valuable to pair program for these very reasons. Best Regards, Dirk/Bartholomew -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Locklainn Gesendet: Dienstag, 5. August 2008 15:28 An: pyogp@lists.secondlife.com Betreff: Re: [Pyogp] Design and Coding Process [bayes] I like this proposal. We were talking and had realized that we were not collectively making design decisions. We DO make overall architectural decisions, but the design aspect got left out. We seem to take the "GET IT DONE" design process. We were talking about having some way to make sure our design is sound before we just bust in and start coding. This isn't to say to use the waterfall method. We should most certainly do some iterations of the design. It is more or less making ourselves more aware of needing to assist each other in a design before we each independently start coding what we want to code. I think this is a great proposal. I would also like to add that we need a way to determine what decisions need the round table for design. Right now, it seems the round table is used for architectural dependencies only. Is this the level we want to keep or should we all be discussing more detailed decisions, like how a component might be coded. Thanks Christian! TJ Christian Scholz wrote: Hi there! Locklainn and I had a little discussion yesterday about a process we don't yet have, which is about how we do design discussions etc. So in order to kickstart this I thought I come up with some proposal we can start to discuss. So here it goes: 1. Identify a problem to solve. This should not be too difficult as we have many to solve ;-) 2. Identify what's blocking a solution like before handling packets we might want to have some component which receives them. 3. Understand and document the problem domain In order to come up with a good design/architecture everybody should at least roughly understand the problem. That means we need to work through the specs (if they are available) or pressure people to make them or walk through code and write it down ourselves. As said, maybe we don't need to go down to the smallest bit here but e.g. for event queue stuff it might mean having some documentation what roughly happens with that queue. What is sent, what is received, when, why, what are the special cases we need to take care of (in case of UDP it might be retries, acks and such). 4. Optional: Play around with some rough code to show how it could work. This might be very valuable as for many people (like me) it's then easier to understand and could be run with debug prints etc. to see what's happening. Sort of like the stuff in examples/ 5. Identify the components Based on the example script or the spec we might identify some components which we can model then. In case of the Event Queue it might be some Queue class. It also might need some communications endpoint. 6. Write an example As I like the top-down/test-driven approach I usually start with some example on how I would use that component, e.g. by adding it to some example code based on the library we already have. This makes the interfaces clearer IMHO. It can also directly be written as a doctest (login.txt was the one I wrote for implementing the login procedure which meant dissecting the example script and "cutting" it into components. The good thing about a doctest is that it also can be tested. 7. Implement all the components used in the doctest and break them up into smaller components again. Basically the same method could apply, so you repeat 5,6,7 until the component is small enough and e.g. a UDP socket. It depends on how much you want to have low level components in the end in how much you cut them into pieces. For login we e.g. have some high level API in api.py, some medium level is what is used in api.py (Credentials, IPlaceAvatar etc.) and lowlevel would be the actual capabilities implementation and networking code. Of course while you do 7 you should ad
Re: AW: [Pyogp] Design and Coding Process [bayes]
One thing that I'd like to discuss is some sort of peer programming, like having pairs of developers collaborating on specific problems. While I have no idea yet on how to handle that technically in an intercontinental way (some VNCserver looking-over-the-shoulder-approch we use here might raise security issues), I could imagine that this gives valuable output and esp. two people building up know-how on the same issue. This way someone could be off for a time and still there is someone else able to answer questions. +1 In Icehouse, and now in Open Platform group, we find it very valuable to pair program for these very reasons. Best Regards, Dirk/Bartholomew -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Locklainn Gesendet: Dienstag, 5. August 2008 15:28 An: pyogp@lists.secondlife.com Betreff: Re: [Pyogp] Design and Coding Process [bayes] I like this proposal. We were talking and had realized that we were not collectively making design decisions. We DO make overall architectural decisions, but the design aspect got left out. We seem to take the "GET IT DONE" design process. We were talking about having some way to make sure our design is sound before we just bust in and start coding. This isn't to say to use the waterfall method. We should most certainly do some iterations of the design. It is more or less making ourselves more aware of needing to assist each other in a design before we each independently start coding what we want to code. I think this is a great proposal. I would also like to add that we need a way to determine what decisions need the round table for design. Right now, it seems the round table is used for architectural dependencies only. Is this the level we want to keep or should we all be discussing more detailed decisions, like how a component might be coded. Thanks Christian! TJ Christian Scholz wrote: Hi there! Locklainn and I had a little discussion yesterday about a process we don't yet have, which is about how we do design discussions etc. So in order to kickstart this I thought I come up with some proposal we can start to discuss. So here it goes: 1. Identify a problem to solve. This should not be too difficult as we have many to solve ;-) 2. Identify what's blocking a solution like before handling packets we might want to have some component which receives them. 3. Understand and document the problem domain In order to come up with a good design/architecture everybody should at least roughly understand the problem. That means we need to work through the specs (if they are available) or pressure people to make them or walk through code and write it down ourselves. As said, maybe we don't need to go down to the smallest bit here but e.g. for event queue stuff it might mean having some documentation what roughly happens with that queue. What is sent, what is received, when, why, what are the special cases we need to take care of (in case of UDP it might be retries, acks and such). 4. Optional: Play around with some rough code to show how it could work. This might be very valuable as for many people (like me) it's then easier to understand and could be run with debug prints etc. to see what's happening. Sort of like the stuff in examples/ 5. Identify the components Based on the example script or the spec we might identify some components which we can model then. In case of the Event Queue it might be some Queue class. It also might need some communications endpoint. 6. Write an example As I like the top-down/test-driven approach I usually start with some example on how I would use that component, e.g. by adding it to some example code based on the library we already have. This makes the interfaces clearer IMHO. It can also directly be written as a doctest (login.txt was the one I wrote for implementing the login procedure which meant dissecting the example script and "cutting" it into components. The good thing about a doctest is that it also can be tested. 7. Implement all the components used in the doctest and break them up into smaller components again. Basically the same method could apply, so you repeat 5,6,7 until the component is small enough and e.g. a UDP socket. It depends on how much you want to have low level components in the end in how much you cut them into pieces. For login we e.g. have some high level API in api.py, some medium level is what is used in api.py (Credentials, IPlaceAvatar etc.) and lowlevel would be the actual capabilities implementation and networking code. Of course while you do 7 you should add tests as it fits. It makes always sense to write them first and implement the code then. At least for me it makes it clearer what I am actually trying to write. In the 5-6-7 loop you could even implement some mockup code first which simulates th
