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

Re: Libertarian Toastmasters club officers -- Where to start?

Expand Messages
  • Jeff Grigg
    ... Libertarian Toastmasters; now that s bound to be interesting. Being a CTM myself, I d recommend even more strongly against prematurely putting dates into
    Message 1 of 23 , Jan 1, 2004
      --- Wayne Dawson <YahooGroups@L...> wrote:
      > [...] http://LibertarianToastmasters.org/ [...]

      Libertarian Toastmasters; now that's bound to be interesting.

      Being a CTM myself, I'd recommend even more strongly against
      prematurely putting dates into the officers table. All Toastmasters
      clubs I've seen elect all the officers at once, to serve the same
      term. And rarely does anyone care who the officers were last year or
      the year before. (And if they cared, they would probably already
      know. ;-) Generally, the only question of relevance is, "Who are
      the officers /now/?" (IE: today)

      (And I'm a "card carrying Libertarian" too. ;-)


      > Regarding tools, I'm just using a plain text editor (WordPad
      > on Windows) [...].

      (Anyone for the "Visual Notepad" IDE? ;-)


      > I'm using a database for a couple of reasons: [...]

      The XP approach is to "Do The Simplest Thing That Could Possibly
      Work." And then enhance it later, if needed. So one could start
      with a text file, or a serialized stream of Java objects, and later
      refactor it to use the relational database.

      > [...] I've decided that the "future use" thing is really
      > against the XP philosophy.

      (...and that's why people are challenging the database. You can go
      ahead and do use the database if you really want, but you'll
      not /really/ be following the "true" XP philosophy. Try doing
      without it. See what happens. ;-)


      > I'm currently reading Extreme Programming Explained, but
      > in the mean time, which XP practice is the most important
      > one to implement? Ie. which one should I start using first?

      Testing. I recommend starting with testing. I find that a number of
      the other practices tend to follow from that, like simple design and
      refactoring, if you start by focusing on testing. And the longer you
      go without Test Driven Development style testing, the harder it will
      be to get it going once you start.
    • Charlie Poole
      Hi Wayne, ... It s relatively simple to install a copy of php - preferably the same version as your host s - on Windows. Then you can create some defines based
      Message 2 of 23 , Jan 1, 2004
        Hi Wayne,

        > Regarding tools, I'm just using a plain text editor (WordPad on Windows)
        > and uploading my php code to a linux box running Apache and mySQL.

        It's relatively simple to install a copy of php - preferably the same
        version as your host's - on Windows. Then you can create some defines
        based on the url on which you are called and base all your other accesses
        on those defines.

        For example, my sites listed below are also available to me on my
        local machine. That allows me to make small changes very quickly,
        then deploy the changed files to my host where they almost always
        work the first time.

        Charlie Poole
        cpoole@...
        www.pooleconsulting.com
        www.charliepoole.org
      • William E Caputo
        ... Two things I want to note before I answer your question: 1) Many (most?) people start out with XP by themselves, learning it and then trying to apply it.
        Message 3 of 23 , Jan 1, 2004
          Wayne Dawson:
          >I'm currently reading Extreme Programming Explained, but in the mean time,

          >which XP practice is the most important one to implement? Ie. which one
          >should I start using first?

          Two things I want to note before I answer your question:

          1) Many (most?) people start out with XP by themselves, learning it and
          then trying to apply it.

          2) XP is fundamentally a team software methodology. As such, you will not
          really understand XP until you do it as part of a team of programmers
          working with a customer (I know I didn't).

          I introduce these two caveats, not to discourage you, but so that you have
          the proper expectations of what you can accomplish alone. You can learn a
          lot of the practices of XP alone, and some of them will be useful to you
          even if you never work as part of a team -- but you will not really be
          learning (or practicing) XP.

          OK, caveats aside, Here's what I feel are the best practices for starting
          out alone, using Ron's ever-helpful "What is XP?" page for the definition
          of the practices
          (found here: http://www.xprogramming.com/xpmag/whatisxp.htm):

          *Simple Design*

          For more on this, there are probably hundreds of pages at the c2 wiki,
          here is a good starting point:
          http://www.c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork)

          *Test-Driven Development*

          IMO Kent's book "Test-Driven Development by Example" is the best resource
          for learning this

          *Design Improvement*

          aka Refactoring. Although the definition of TDD includes refactoring, its
          still valuable to keep it as a separate concept ("TDD" was originally
          "write tests before writing code", and "design improvement" was
          "refactor". Since Test, Code, Refactor is the smallest period of work in
          XP, its natural that these two practices have moved closer together over
          the last few years). Martin Fowler's book "Refactoring: Improving the
          Design of Existing Code is practically the canonical source for learning
          this technique. Please don't confuse Refactoring, with Rewriting. Its an
          overused buzzword. People here tend to use the term correctly.

          These three practices are probably enough to get you started. From here,
          you can really only approximate what XP is like since the other practices
          all involve interactions with other people (and some like Pairing make no
          sense when working alone). Probably the most accessible when working alone
          are the story and planning practices:

          *Planning Game*

          Writing and estimating stories even by yourself is often useful, if for no
          other reason than that the act of doing so is a good way to help you
          determine the scope of the project you have set yourself. While its also a
          good way to practice the technique, its *not* a very accurate substitute
          for having a Customer write the stories, and then having the Programmers
          estimate them (because the real practice involves two people trying to
          come to a common understanding). Kent and Martin's book "Planning eXtreme
          Programming" is a good (if possibly a little dated) place to start. I
          learned XP planning before that book came out so its the last book I read
          on the topic. Others may be able to provide other references.

          *Small Releases*

          Getting your stuff in front of people who will use it is always the best
          way to find out what you missed, and to pierce that bubble of
          self-delusion that we create around our ideas when no one else is
          involved. Get your stuff "live" as quickly as is practical (when working
          alone, you could probably release after nearly every work session).

          *Customer Tests*

          aka Acceptance Tests, Story Tests, Functional Tests, etc -- are important,
          but really hard to understand when working alone. The idea is that you
          should write (and automate) tests that are oriented to your stories and
          thus demonstrating functionality from the perspective of the Customer
          (hence the name). They also generally test more end-to-end functionality
          than TDD tests (nee XP unit tests, or programmer tests). Finally, they
          (and not the TDD tests!) take on a verification role that you are building
          the right thing. TDD is a *design* activity; TDD tests play only a
          secondary role in regression, and nearly nothing in the way of saying we
          built the right thing (but they do say we built the thing the way we
          expected to). In short, Customer Tests are really necessary, but you
          probably won't get them right working alone, so you might want to put off
          learning this practice until you are comfortable working with the ones
          listed above. If you do try to write some, I suggest checking out the tool
          fit (http://fit.c2.com)

          Hope that helps. That should certainly keep you busy for several months
          (years?). I still feel like I am learning how to do these six practices,
          so don't let their apparent simplicity fool you. OTOH, you can get
          competent/productive with the first three in a couple of weeks, and get
          working versions of the second three in a similar amount of time, and find
          yourself with a productive personal process that may be totally
          satisfactory for you. Regardless, I hope you enjoy the experience.

          Best,
          Bill

          William E. Caputo
          ThoughtWorks, Inc.
          http://www.williamcaputo.com
          --------
          idia ktesis, koine chresis
        • Ron Jeffries
          ... Great report, Bill! Well done, thanks! Would you like to convert that to an XProgramming article, by the way? Ron Jeffries www.XProgramming.com I could be
          Message 4 of 23 , Jan 1, 2004
            On Thursday, January 1, 2004, at 2:58:02 PM, William E Caputo wrote:

            > OK, caveats aside, Here's what I feel are the best practices for starting
            > out alone,

            Great report, Bill! Well done, thanks!

            Would you like to convert that to an XProgramming article, by the way?

            Ron Jeffries
            www.XProgramming.com
            I could be wrong, of course. It's just not the way to bet.
          • Charlie Poole
            Hi Bill, I m saving this one! Charlie Poole cpoole@pooleconsulting.com www.pooleconsulting.com www.charliepoole.org
            Message 5 of 23 , Jan 1, 2004
              Hi Bill,

              I'm saving this one!

              Charlie Poole
              cpoole@...
              www.pooleconsulting.com
              www.charliepoole.org



              > -----Original Message-----
              > From: William E Caputo [mailto:wecaputo@...]
              > Sent: Thursday, January 01, 2004 11:58 AM
              > To: extremeprogramming@yahoogroups.com
              > Subject: Re: [XP] club officers (was "strictly minimal")
              >
              >
              > Wayne Dawson:
              > >I'm currently reading Extreme Programming Explained, but in the
              > mean time,
              >
              > >which XP practice is the most important one to implement? Ie. which one
              > >should I start using first?
              >
              > Two things I want to note before I answer your question:
              >
              > 1) Many (most?) people start out with XP by themselves, learning it and
              > then trying to apply it.
              >
              > 2) XP is fundamentally a team software methodology. As such, you will not
              > really understand XP until you do it as part of a team of programmers
              > working with a customer (I know I didn't).
              >
              > I introduce these two caveats, not to discourage you, but so that
              > you have
              > the proper expectations of what you can accomplish alone. You can learn a
              > lot of the practices of XP alone, and some of them will be useful to you
              > even if you never work as part of a team -- but you will not really be
              > learning (or practicing) XP.
              >
              > OK, caveats aside, Here's what I feel are the best practices for starting
              > out alone, using Ron's ever-helpful "What is XP?" page for the definition
              > of the practices
              > (found here: http://www.xprogramming.com/xpmag/whatisxp.htm):
              >
              > *Simple Design*
              >
              > For more on this, there are probably hundreds of pages at the c2 wiki,
              > here is a good starting point:
              > http://www.c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork)
              >
              > *Test-Driven Development*
              >
              > IMO Kent's book "Test-Driven Development by Example" is the best resource
              > for learning this
              >
              > *Design Improvement*
              >
              > aka Refactoring. Although the definition of TDD includes refactoring, its
              > still valuable to keep it as a separate concept ("TDD" was originally
              > "write tests before writing code", and "design improvement" was
              > "refactor". Since Test, Code, Refactor is the smallest period of work in
              > XP, its natural that these two practices have moved closer together over
              > the last few years). Martin Fowler's book "Refactoring: Improving the
              > Design of Existing Code is practically the canonical source for learning
              > this technique. Please don't confuse Refactoring, with Rewriting. Its an
              > overused buzzword. People here tend to use the term correctly.
              >
              > These three practices are probably enough to get you started. From here,
              > you can really only approximate what XP is like since the other practices
              > all involve interactions with other people (and some like Pairing make no
              > sense when working alone). Probably the most accessible when
              > working alone
              > are the story and planning practices:
              >
              > *Planning Game*
              >
              > Writing and estimating stories even by yourself is often useful,
              > if for no
              > other reason than that the act of doing so is a good way to help you
              > determine the scope of the project you have set yourself. While
              > its also a
              > good way to practice the technique, its *not* a very accurate substitute
              > for having a Customer write the stories, and then having the Programmers
              > estimate them (because the real practice involves two people trying to
              > come to a common understanding). Kent and Martin's book "Planning eXtreme
              > Programming" is a good (if possibly a little dated) place to start. I
              > learned XP planning before that book came out so its the last book I read
              > on the topic. Others may be able to provide other references.
              >
              > *Small Releases*
              >
              > Getting your stuff in front of people who will use it is always the best
              > way to find out what you missed, and to pierce that bubble of
              > self-delusion that we create around our ideas when no one else is
              > involved. Get your stuff "live" as quickly as is practical (when working
              > alone, you could probably release after nearly every work session).
              >
              > *Customer Tests*
              >
              > aka Acceptance Tests, Story Tests, Functional Tests, etc -- are
              > important,
              > but really hard to understand when working alone. The idea is that you
              > should write (and automate) tests that are oriented to your stories and
              > thus demonstrating functionality from the perspective of the Customer
              > (hence the name). They also generally test more end-to-end functionality
              > than TDD tests (nee XP unit tests, or programmer tests). Finally, they
              > (and not the TDD tests!) take on a verification role that you are
              > building
              > the right thing. TDD is a *design* activity; TDD tests play only a
              > secondary role in regression, and nearly nothing in the way of saying we
              > built the right thing (but they do say we built the thing the way we
              > expected to). In short, Customer Tests are really necessary, but you
              > probably won't get them right working alone, so you might want to put off
              > learning this practice until you are comfortable working with the ones
              > listed above. If you do try to write some, I suggest checking out
              > the tool
              > fit (http://fit.c2.com)
              >
              > Hope that helps. That should certainly keep you busy for several months
              > (years?). I still feel like I am learning how to do these six practices,
              > so don't let their apparent simplicity fool you. OTOH, you can get
              > competent/productive with the first three in a couple of weeks, and get
              > working versions of the second three in a similar amount of time,
              > and find
              > yourself with a productive personal process that may be totally
              > satisfactory for you. Regardless, I hope you enjoy the experience.
              >
              > Best,
              > Bill
              >
              > William E. Caputo
              > ThoughtWorks, Inc.
              > http://www.williamcaputo.com
              > --------
              > idia ktesis, koine chresis
              >
              >
              >
              >
              > To Post a message, send it to: extremeprogramming@...
              >
              > To Unsubscribe, send a blank message to:
              > extremeprogramming-unsubscribe@...
              >
              > ad-free courtesy of objectmentor.com
              >
              > Yahoo! Groups Links
              >
              > To visit your group on the web, go to:
              > http://groups.yahoo.com/group/extremeprogramming/
              >
              > To unsubscribe from this group, send an email to:
              > extremeprogramming-unsubscribe@yahoogroups.com
              >
              > Your use of Yahoo! Groups is subject to:
              > http://docs.yahoo.com/info/terms/
              >
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.