announcing the first (annual?)

	     ---------------------------------
		 CODE AMELIORATION CONTEST
	     ---------------------------------

	      presented under the auspices of
		   Ruby Conference 2001


                  Organizer and contact:

                     David Alan Black
                dblack / candle.superlink.net



Introduction

      Amelioration means "improvement" or "making better."
      Accordingly, participation in this contest involves making
      improvements to badly designed, obscurely written (but working!)
      Ruby code.

      As a first, non-competitive step, there will be a submission
      period for examples of "bad" code.  These examples will then be
      publicly posted for downloading and rewriting -- amelioration --
      by contestants.

      So there are two ways you can participate: submitting "bad" code
      examples, or doing ameliorations, or both.  The only restriction
      is that any ameliorations you submit must be of bad code
      examples written by someone else, not your own.

      All of this will take place *before* Ruby Conference 2001.  *At*
      the conference, the results of the judging will be announced.

      Matz, Andy Hunt, and Dave Thomas have most kindly agreed to
      judge the contest.  (See "Judges and judging", below.)


Why a Code Amelioration Contest?

      Inspired originally by some irc banter about the idea of
      "reverse obfuscation," the Code Amelioration Contest is designed
      as a challenging and enjoyable showcase for Ruby strengths.

      Ruby shines when it comes to conciseness, readability, and
      clarity.  Programming in Ruby has a lot to do with recognizing
      and coaxing the simple and the transparent.  The Contest aims to
      provide Ruby users a way to exercise and develop these skills,
      in a context which will appeal to anyone who enjoys a coding
      puzzle or challenge.


Overview and timeline

      1. Between now and August 20, people (you!) submit examples of
         badly written, but working, Ruby code.  (See below for
         details.)  These "bad" examples will be publicly posted.

      2. Other people (or the same people, as long as they don't
         rewrite their own code) submit code ameliorations: improved,
         cleaned up, refactored, polished versions of one or more of
         the bad code examples.  (Through September 10.)

      3. The judges judge these rewrites, based on clarity,
         efficiency, and resourcefulness with the Ruby language.

      4. The contest culminates at the conference, where the judges
         announce the winners, who get glory and possibly some small
         tangible reward.


Judges and judging

      The judges for the first annual Code Amelioration Contest will
      be Matz, Andy Hunt, and Dave Thomas.

      Judging will be on the basis of precision (the rewrite must do
      what the original code did), conciseness combined with
      readability (not keystroke golf!), and whatever general,
      mystical, elusive Ruby-esque qualities the judges feel they have
      spotted.

      Winner(s) will be mentioned, and possibly given something, at
      Ruby Conference 2001.  Judges will also present and discuss the
      judging process and the rationale for their selection(s).


Submit your examples of bad code!

      The first thing needed is examples of poorly designed, badly
      written code.  You are invited to write and submit such
      examples.  There's definitely room to have fun with this part of
      the contest.

      Deadline for submission of examples of bad code: August 20.


      Please follow these guidelines:

	1. The code you submit must be your own.  Do NOT take
	   something off of ruby-talk that you think is poorly
	   written.  We are not out to embarass anyone.

	2. Your "bad" code must actually work.  Its "badness" should
	   reside in its design, appearance, lack of elegance,
	   inefficiency, and unidiomatic approach to the Ruby
	   language.  (Getting the idea? :-)

	3. Along with your code, submit some tests or demos to show
	   what your code does.  These tests will be re-used to judge
	   the ameliorations of your code for compliance.  They can be
	   in RubyUnit format, or just made up of test methods with a
	   clearly predicted output.

	4. Send your code and tests to <dblack / candle.superlink.net>.


      Try to think of imaginative ways to write unattractive Ruby.
      Perhaps there's a language or two out there whose style you
      could imitate?  Or ways to circumvent object-oriented design?
      Or... you decide!