[PaQSO] RE: [CQ-Contest] Repeating an idea from the 7QP soapbox...

[Ron Notarius W3WN]

Goody,

Let me amplify one comment you made.

Many moons ago, I was the MIS Manager for a small real estate & title
insurance firm.  One of my jobs was to maintain and update the software
package that the company ran on.

The original version of the code was actually written as two separate
applications... one for PA, one for OH.  So a change made to one wouldn't
affect the other, obviously; but a change to both (such as a rate
computation change) had to be made to both, making double work.

During my tenure, the original programmer & I rewrote the package to be more
flexible (Color, pop-up windows, and so on... and this was back in the "Good
Old Days" of DOS 5.0!).  It was one application instead of two.  In those
cases where something state-specific changed, the code was written to see
what state the application was from, and load the appropriate module.  This
way, as we expanded into other states (GA originally, when Billy went home;
others happened, well, after I was gone, but that's another story) we simply
copies of the generic set of modules and tweaked them as needed.

Thus it can be with a well written contesting application.  The state and
regional QSO parties for the most part are pretty identical... the only
major differences are the exchange, the point value, the multiplier set, and
whether in-state & out-of-state (or region) stations are treated the same or
differently.  NONE of that is hard to program; challenging, sure, but not
THAT difficult.  Hell, if I could do it in dBase III+ with a Clipper '87
compiler then... why can't it be done now?

Now some software writers may not want to bother.  They may not feel the
demand for the modules for a particular state are worth their while.  Fine,
but that's a business decision that they can make and that they'll have to
live with.  Why should we have to homogenize our contest because they made a
business decision not to bother?

...which reminds me.  I do need to offer an apology to the group.  2 years
ago, I set up a set of modified files for both in- and out-of-state
stations, so that the famed CT application could be easily used for the Pa
QSO Party.  I tested them, they worked, and I shipped them off (and arranged
for the announcement that they would soon be available).  And then nothing
happened; when I finally asked my contact, he first yolf mr he never had
them, then claimed he lost them.  By that time, a few days before the
contest, I never had time to rebuild & test the files.  I've since changed
jobs, and I could never find the files again.  One of these days, though,
I'll do the work and do it again... and this time, I'll make sure that the
backup copies don't get misplaced!

73

-----Original Message-----
From: paqso-bounces at mailman.qth.net
[mailto:paqso-bounces at mailman.qth.net]On Behalf Of Goody K3NG
Sent: Wednesday, May 07, 2008 10:03 PM
To: PA QSO Party Reflector
Subject: Re: [PaQSO] RE: [CQ-Contest] Repeating an idea from the 7QP
soapbox...


I agree with you, Ron.  The participants in the contest should drive the
rules and the exchange, not the software programmers.  While amateur
radio is a hobby, imagine if your business had to change how it does
business because the programmers or IT department wanted to do something
an easier way.

I find the mention below of cost/benefit ratio interesting.  I get the
feeling the original poster is saying this from the point of view of a
commercial pay software author....what is the cost/benefit ratio for the
generous hams who author free software like several of our PAQP
authors?  :-) But I digress.

Being somewhat of a programmer, I see the problem with handling
different contest exchanges as mainly a problem of how many of these
contest programs are architected.  Modern software should be able to
handle new and different contests using a definition language,
scripting, or flexible configuration options.  You write the engine to
handle the rule definitions, not the contests themselves, and allow the
user community to create new contest definitions for your software.  All
too often the handling of the rules and scoring of individual contests
are handled within compiled code or non-user modifiable binary files.
We can take this concept one step further and have the contest
definition language standardized so that all programs can support it,
similar to what ADIF is to logging data.  This would make more sense
than homogenizing and arguably wrecking our unique contests.

We can launch satellites, build software defined radios, and invent new
digital modes that work down into the noise floor, yet we still can't
seem to write flexible software to handle unique contests....

73
Goody
K3NG

Ron Notarius W3WN wrote:
>
> Sorry.  I don't buy the argument.  And I don't believe we need to
homogenize
> our contest exchanges just to make them "easy."
>
>
> -----Original Message-----
> From: cq-contest-bounces at contesting.com
> .
>
>
> I saw an early post in the 7QP soapbox[0] from Bob K0RC, and kind of
> thought it should see the light of comments from here.  Quoting...
>
>
>> I propose the State QSO Party organizers begin serious consideration to
>> standardize their contest exchange. There are 39 different QSO Party
>> modules in my contesting program. One program author has discontinued
>> support for these parties because of the cost/benefit ratio can't be
>> justified. Support in the remaining programs is not stellar.
>>
>>
>>
>
>
>
> Does it make things "easier"?  Yes.  Maybe it lessens the skill needed
> to copy an exchange in CW, or log things properly.  C'est la vie.  But I
> contend that it'll make things a little more friendly for 'newbies' to
> enter.  And, when they day is done and we're all sitting down to dinner
> together at the next banquet, isn't Amateur Radio, in its highest form,
> about fellowship and camaraderie?
>
>
>


--
Blog: http://thek3ngreport.blogspot.com/

_______________________________________________
PaQSO mailing list
PaQSO at mailman.qth.net
http://mailman.qth.net/mailman/listinfo/paqso