EZWinScore in the real world

[LChico]

If users are rising up in protest - and I don't know that they are - maybe a middle ground is to open it up to a project by members in parallel and may the best product win. An incumbent developer obviously has a vested interest in continuing the project, and even if their motives are pure, also tends to get tunnel vision. Supply the group of software slaves with the current technical documentation and wish-list and a contact in USPSA, then turn them loose and see what they produce by x date. On x date, review the product and make a decision - Throw it away and banish the slaves, keep it as-is, make further modifications using the slaves, or turn the source over to a software house to refine.

The users are not rising up in protest. For the most part, the program does what we want it to do - score matches. Inevitably, when you have users scattered across the US, we will have a preference for little tweaks to the program that would make our lives easier, and want our particular bias fulfilled. Opening it up to allow "everyone add your favorite features" would result in the chaos that currently exists in scoring non-USPSA multigun, or the allowance of a variety of self designed programs versus semi-official proprietary program (like IDPA).

Even in this small sample, it is easy to see that we do not agree on the features that are the most important. Bill does not consider the use of the mouse for registration annoying. Others, including me, would like to change that. Bill would like to make better use of the network features, while I have no problem assigning stages to specific slave machines and transferring data on a USB drive. I doesn't mean I am right & he is wrong or vice versa; it is just a different preference.

Clubs get the program free from USPSA. That's a feature we all like. Some other shooting disciplines charge clubs for the official scoring program or do not offer one at all.

Linda Chico (L-2035)

Columbia SC

[Rob Boudrie]

There are things that can be done outside the EZWinScore to ease your life if there is really something that needs to be done. I’ve written apps that pre-populate the database with names, exported to SQL databases, run reports, etc. Since the database is accessible, there isn’t much you can’t do.

I can't promise a timeframe, but one of the things on my 2do list is adding "registration data import" so that a standard (probably TSV) format may be used to import registration data. Of course, this has to not only be bullet proof but has to absolutely validate data so, for example, you can't import a Production shooter with Major power factor or do anything else to create any database setup not possible using the GUI.

The real problem is manpower. I do a bunch of work on a volunteer basis, and Roger Maier has done an incredible job of learning how the development environment works which gives us some actual on-staff in house expertise. The various web projects, the Steel Challenge, the Scholastic Steel challenge, and keeping EzWinScore up2date (using the current program as a base) and the "for the free or on-staff" resources tapped out. I don't have time to start another major project, and I don't think Roger has the time to learn a new development system and start a new program either.

Hiring someone to develop a program is pricey and risky (what do you do if it doesn't work well and you've paid for time as it is developed... the answer is nothing except consider spending more money, or try to fix it yourself).

If someone wants to start an open source project, or volunteer to do a new program, please let me know. BUT..... the historical problem with volunteers is that they do not hold themselves to the performance standard of a paid person. If you can keep commitments, and deliverable dates mean something when you are volunteering - great. If you think that "anything is better than nothing if I am donating my time" then it's probably not going to be a successful project.

Powerbuilder is still pretty expensive, and I've looked at it, and the only good reason I can think of to stay with it is the time and expense required to write it again in something else.

That is the only good reason that I have found, and I expect the folks at central command would agree.

[Byrons]

Are there formal business rules available, or does the developer just "know" what they are? If they exist, could I get a copy?

There are things that can be done outside the EZWinScore to ease your life if there is really something that needs to be done. I’ve written apps that pre-populate the database with names, exported to SQL databases, run reports, etc. Since the database is accessible, there isn’t much you can’t do.

I can't promise a timeframe, but one of the things on my 2do list is adding "registration data import" so that a standard (probably TSV) format may be used to import registration data. Of course, this has to not only be bullet proof but has to absolutely validate data so, for example, you can't import a Production shooter with Major power factor or do anything else to create any database setup not possible using the GUI.

The real problem is manpower. I do a bunch of work on a volunteer basis, and Roger Maier has done an incredible job of learning how the development environment works which gives us some actual on-staff in house expertise. The various web projects, the Steel Challenge, the Scholastic Steel challenge, and keeping EzWinScore up2date (using the current program as a base) and the "for the free or on-staff" resources tapped out. I don't have time to start another major project, and I don't think Roger has the time to learn a new development system and start a new program either.

Hiring someone to develop a program is pricey and risky (what do you do if it doesn't work well and you've paid for time as it is developed... the answer is nothing except consider spending more money, or try to fix it yourself).

If someone wants to start an open source project, or volunteer to do a new program, please let me know. BUT..... the historical problem with volunteers is that they do not hold themselves to the performance standard of a paid person. If you can keep commitments, and deliverable dates mean something when you are volunteering - great. If you think that "anything is better than nothing if I am donating my time" then it's probably not going to be a successful project.

Powerbuilder is still pretty expensive, and I've looked at it, and the only good reason I can think of to stay with it is the time and expense required to write it again in something else.

That is the only good reason that I have found, and I expect the folks at central command would agree.

[JThompson]

There is plenty of money in the kitty to put on a programmer or two. I don't see why we can't hire a couple of good programmers to get the job done. They can use open source and those with time can also help out. That way you could have the best of both, and you don't burn out the two guys that have a copy of Power. The key to make it work would be oversight, and the people who are programming now could fill that roll without adding to their workload. Also, you have a bunch of programmers out here that would help if they could, but it's not possible now.

I applaud the people who have donated their time to get the program where it is, but it really needs an overhaul. It's not anyone's fault, it's more like you were building a bicycle and and along the way you keep strapping on parts. At some point, you have a motorcycle with a bicycle frame. There's a point where you figure out you need to start with a motorcycle frame from the beginning. Some of the old parts will get used, some won't, but at least now you know what the end product is going to be... something that was less clear when the project was started.

Again, not to belittle or besmirch what you guys have done, but at this point, it may be time to start with a new frame.

JT

Edited April 18, 2010 by JThompson

[Byrons]

What would you think about a screen that populated a list of shooters from the past x matches with all their info populated?

For instance, choose to use the last 3 matches. The list of shooters would populate with a unique list of names from those matches - eliminating duplicates - and pull all the class, power-factor, address etc, from the most recent match. A check would be made of the current classification file against the class of the most recent match in case the shooter had moved up since the last match and the class from the classification file would be used. If a shooter had attended 2 of the past 3 matches their name would be pre-checked in the list to add to the new match. Once all the shooters to copy are checked in the list, you click a button and they are added to the current match.

There would be details like someone sometimes shooting a different division and that change could either be made before adding them, or edited after the mass-population. There are probably few enough exceptions that it would be easier just to edit the few people where that was an issue. This would also simplify the programming.

There would be issues with people that had changed USPSA numbers, and those without a number, since that would be the only unique key to match people between matches. I don't know how big an issue that would be.

Yes it is, too. It's NOT tedious, it's NOT a hassle. I've already demonstrated that. (10 seconds to register one guy is far from tedious!) It works well, and it works fast.

You don't need masternames? Really? So when you start typing in a name, where's he going to fill in the information from?

Now, DOS EzScore did do something that would be nice, and that was you could go into masternames and tag names to enter (run up and down the list and space-bar the people you wanted to select them, then hit "okay" or some such and they were registered one after the other in order of selection as a batch. But that was in the days when you only had one division. I don't see how that would work now with 6 divisions. You see, you make a big deal about being able to just start typing a name and he goes and gets all the info and that sounds all well and good, but how would you select the division without going back to the hated reviled mouse? For that matter, what about powerfactors? Law? Military? Age? Foreign? Squad number? Squad-with number? Female?

I'm not against what you want, but once again, there are more pressing things to be done (steel challenge, match director's awards script, and you're jumping around about something that just simply, in my opinion, isn't broken.

*SNIP*

and I've already shown that a typical selection of someone off masternames.db takes (animated timed example I have shown) around 10 seconds, and let's say at the most twice that? I don't think that's a big deal. Assume 20 seconds for a shooter off masternames. 3 a minute. You can populate a 90-man show in a half hour. (I'm more careful than that and thus slower, since I'm making sure I haven't skipped anyone on the paper signup sheet, as I enter scores by competitor number.) "Timeconsuming"? "Painstaking"? Come on, now.   

Entering people into a match is horrifically time consuming and annoying. Yeah, your animated timed examples may take 10-20 seconds. That's when you are effectively "racing" through the UI to time it and portray it in a positive light. you yourself close off with the fact it takes you longer per shooter. 

I mean seriously, why do I have to leave the screen where you type in new people. Autocomplete with a pull down menu right on that screen would mean I can cruise. It would also mean clicking save would make sense. Alternately, allowing me to control click to select multiple people on the masternames screen, even with it oddly separated by letter, would speed things up considerably for the regular attendees of monthly matches. Also, even when picking them off of the masternames list, just assume I want to save the person. I'm not selecting them and clicking add for my health. 

If you are signing up people to an ad hoc monthly match of reasonable size where everyone is a walk on, the UI is pretty slow and tedious. 

Also, being able to shift click or control click to move more than one person on the squadding screen would make squadding a WHOLE lot faster.  That is ESPECIALLY painful on a laptop with a track pad.  With control click, squadding our smaller indoor match would go form taking a few minutes to taking probably 15-20 seconds. 

Jim's not embellishing.  I was doing the scoring for our twice a month indoor match.  EZ-winscore was slow and tedious enough it constantly had people bitching at me for how long it takes to get things going, and consequently I quit attending and doing anything for the match. 

EZ-winscore is obviously set up for a match where you register ahead of time, have multiple people scoring, and will likely be entering part of a shooters match results rather than all at once.  It's not a particularly good fit for the one man show doing scoring for a whole match at once at the end of the match, and where signups are all walking on at the beginning of the match day. 

I moved this form the other thread due to window confusion and having multiple thereads open in multiple windows. 

But I'll add an answer  to the complaint of how would you handle division, senior, military, etc. It's simple. Handle it like the squadding screen. Except have shift and control click to drag and drop. For example, hav ea division screen. On the left are the registered shooters. On the right are all the divisions.  there you go. That's a mouse and tab centric way of doing it. 

Better yet, eliminate select form master names, and have all match entry done from the user info tab. Except have the first field be the last name, and have an autocomplete pull down list.  I type in N, and i hav ea choice of all N names, follow on with o, and there's Jim Norman X people down.  Then you have divsion work similar. Class is type a single letter, have the next few tabbings take you through senior, super senior, etc. Then tab takes you to SAVE. THEN tab takes you to all the record keeping and contact stuff you don't need to score a match, but might want only once or twice per shooter over a long period of time. There, that's a keyboard-centric way of achieving faster data entry.  (ohyeah, and when you click save, just save, put the cursor back in the last name field, and blank all the fields. that way I can get moving again ASAP without a mouse involved). 

Feature creep makes things a mess. It has made EZ-winscore a mess, and doubly so for certain types of users. It needs to be torn down and rebuilt by someone. When I use it, I can see for the most part how and why it wound up like it is. but that doesn't mean what sucks to use doesn't suck. 

As to the OPs questionnaire.  

As the former scorekeeper(for years) and guy who did lots of work for our 2x a month indoor match:

Do you pre-register days/weeks before the match, or do you enter competitors the day of the match?

No. the match is geared towards easing new shooters into the sport, and we don't want to place barriers there for them like pre-reg.

Do you use Palm's?

Yes. 

If you use Palm's do they go with the squad or stay on the stage? 

Stay on the stage

Do you use multiple machines (master/slave) to enter scores?

One Machine

Does somebody enter scores while the match is going?

No.

Does somebody take home all the scoresheets and enters all of the scores after the match?

Yes.

Do you use the checkboxes in the verification for stats pages?

no.

Do you use a mouse often or try to keep your hands on the keyboard?

I'd like to be able to just key stuf in as fast as possible. But the program makes it impossibel to not be mousing every other minute. 

Do you handle DQ's as they come in, or only at the end of the match?

end of the match. 

Do you have to be paranoid about matching entry forms with shooter numbers because of EZWinScore's issues with RE-ENTRY?

When scoring paper only, we do all the data entry at once after the match is over, so we don't have much issue with re-entry unless we fat finger someone. 

As the co-director of the Central Jersey match.

Do you pre-register days/weeks before the match, or do you enter competitors the day of the match?

No. 

Do you use Palm's?

No.

If you use Palm's do they go with the squad or stay on the stage?

N/A

Do you use multiple machines (master/slave) to enter scores?

No.

Does somebody enter scores while the match is going?

No.

Does somebody take home all the scoresheets and enters all of the scores after the match?

Yes.

Do you use the checkboxes in the verification for stats pages?

no.

Do you use a mouse often or try to keep your hands on the keyboard?

I'd like to be able to just key stuf in as fast as possible. But the program makes it impossibel to not be mousing every other minute. 

Do you handle DQ's as they come in, or only at the end of the match?

End of the match.

Do you have to be paranoid about matching entry forms with shooter numbers because of EZWinScore's issues with RE-ENTRY?

We score paper only, we do all the data entry at once after the match is over, so we don't have much issue with re-entry unless we fat finger someone. 

[Rob Boudrie]

Are there formal business rules available, or does the developer just "know" what they are? If they exist, could I get a copy?

There are no formal "business rules" for contributed software. I've been doing volunteer work for USPSA since the time when everyone thought I was insane because everyone knew the web would not amount to anything. The original EzScore (Dos) and EzWinScore were developed on a semi-volunteer basis. The amount the developer was paid for full rights was about the cost of an open gun at the time - not the "well into five figure" quotes I have seen for similar work. Too bad he died over a decade ago (cancer).

If you are interested in starting a project, PM me with a # and time to call. We have had several false starts with volunteer projects. Usually, the outcome is:

- Initial enthusiasm, followed by nothing ever getting done

- Determination to get paid - which will only happen if USPSA has made a decision to invest not only the money, but the management manpower to monitor the process, figure out contract milestones, etc.

You will find that USPSA would be very interested in a scoring program, but you need to be clear about your expectations at the start. Would it be a volunteer project or something you would expect to sell? Please be up front and don't be vague with an "aw shucks, I just want to help the sport" if you intend to ask for a large chunk of cash when you're done.

Any scoring program supported as an official USPSA product must be built from source code by HQ staff. This requirement is in place to assure that USPSA can maintain any such program.

There is plenty of money in the kitty to put on a programmer or two. I don't see why we can't hire a couple of good programmers to get the job done. They can use open source and those with time can also help out. That way you could have the best of both, and you don't burn out the two guys that have a copy of Power. The key to make it work would be oversight, and the people who are programming now could fill that roll without adding to their workload. Also, you have a bunch of programmers out here that would help if they could, but it's not possible now.

The one part with which I strongly disagree is the comment "without adding to their workload". Someone at HQ has to make sure all critical features work properly, that the input formats used (classification update) are processed properly, and that the output files (classification, results upload file and Palm transfer files) are totally compatible. Sure, most of it is obvious - but there will still be questions to be answered, issues to be resolves, and design issues to be worked out.

Unfortunately, the world needs its share of REMFs on any project. If that were not the case, the hardware and software development industry would not be wasting money hiring one manager for every 6 to 12 developers. Assuming that a project can happen without HQ involvement to make sure the new program is fully compatible, and the user experience meets the needs of a broad spectrum of users, is not realistic. Well, maybe it is but only if Bill Noyes has a bunch of free time on his hands.

[Skydiver]

Any scoring program supported as an official USPSA product must be built from source code by HQ staff. This requirement is in place to assure that USPSA can maintain any such program.

Do you mean "can be built" or "must be built"? If it is the latter, I'm not an open source license expert, but I think the precludes the use of some open source libraries.

I can foresee the code being open for everybody, to see, tweak and contribute, but each branch has a signature in it's output files. This way, when match results and classifiers are uploaded, USPSA can filter which ones to accept for major matches for example.

[Byrons]

Whether "can" or "must" build, the effect would be the same, and it should be a requirement. This ensures that if everyone pulls out the code is still available and maintainable, and ensures that the source can be examined for any backdoors and easter eggs. Whether other open source code could be used within the application is another question, but I would avoid it if possible. I would also not use a strictly open source approach, since this implies anyone can make changes. The features and builds should be retained at the USPSA level to ensure consistency.

Rewiting into another language would be clean up the application and change to free, or much lower cost and more mainstream tools to widen the potential developer base and speed delivery of changes. I would vote for Microsoft .NET (C# in particular) and Microsoft SQL Server 2008 Express.

I would not advocate willy-nilly versions that could be used locally. Most developers do not have the knowledge or discipline to make changes that don't affect unpredictable parts of the overall application, and even if they did, rolling changes from multiple simultaneous developers building on various code bases using their own style is not an easy thing.

Any scoring program supported as an official USPSA product must be built from source code by HQ staff. This requirement is in place to assure that USPSA can maintain any such program.

Do you mean "can be built" or "must be built"? If it is the latter, I'm not an open source license expert, but I think the precludes the use of some open source libraries.

I can foresee the code being open for everybody, to see, tweak and contribute, but each branch has a signature in it's output files. This way, when match results and classifiers are uploaded, USPSA can filter which ones to accept for major matches for example.

[raz-0]

Any scoring program supported as an official USPSA product must be built from source code by HQ staff.  This requirement is in place to assure that USPSA can maintain any such program.

Do you mean "can be built" or "must be built"? If it is the latter, I'm not an open source license expert, but I think the precludes the use of some open source libraries.

I can foresee the code being open for everybody, to see, tweak and contribute, but each branch has a signature in it's output files. This way, when match results and classifiers are uploaded, USPSA can filter which ones to accept for major matches for example.

My opinion on the above is the following: 

Screw any perceived rules by uspsa. The sum total of their interaction with a club's scoring system is a flat file for classifier updates, and the output to send in classifiers, etc. It's not like you submit encrypted serialized binaries or something. Everything else is inertia and the rulebook. After seeing the process with them acquiring rights to distribute the steel scoring program, I certainly wouldn't want to have that process in between me and getting work done.  HQ isn't filled with copyright attorneys, it also isn't filled with software project managers either.  A project like this is way outside their area of expertise, and their approach to being organized about it could very easily kill off any volunteery enthusiasm pretty easily. 

My take on it is if something is going to be done, to just go open source, make a product, and let someone else worry about if it is officially associated with any particular organization.  It might also be nice if we could take steps to solve the problem that the palm platform is essentially dead too. There's a lot of really cheap (around the $100  mark), small (screens between 4" and 7"), tablets on the way in theory, they might be worth looking at.  One thing I can safely say is that none of them will be running microsoft OSes, it might not be the best choice to go MS centric on the development tools either. 

As for paranoia about back doors and forking when going OSS, I'll argue that USPSA HQ doesn't really have the resources to do a code audit on something closed source. Is that something they honestly do now? Also in general, I don't think anyone is running a persistent networked scoring system that is worth hacking. Heck, why would I bother with that much effort when I can just alter flat files with a text editor?  Flat files are what come in and out of HQ, not encrypted serialized binaries.  As for forking, that happens when you have too many volunteers who argue with each other.  This is a one or two man sized project that will be lucky to get one or two volunteers.  You make one of them the dictator for life, and that person passes on being dictator for life when they find someone stupid enough to take that job. Or run screaming. Or die. 

[Rob Boudrie]

Do you mean "can be built" or "must be built"? If it is the latter, I'm not an open source license expert, but I think the precludes the use of some open source libraries.

"Built from source" means using the standard tools - virtually every program uses standard libraries not compiled as part of the program.

And it's not "can be built from source", but "IS built from source". Until you actually do it, you don't know if it will compile - something as trivial as an include directive that references a file by absolute rather than relative path (pointing to a file not in the distribution) can prevent a build and be totally unintentional.

After seeing the process with them acquiring rights to distribute the steel scoring program, I certainly wouldn't want to have that process in between me and getting work done. HQ isn't filled with copyright attorneys, it also isn't filled with software project managers either. A project like this is way outside their area of expertise, and their approach to being organized about it could very easily kill off any volunteery enthusiasm pretty easily.

Were you involved in the process? Did you review the contracts? I was and did. And yes, USPSA has contracts reviewed by a qualified attorney before signing.

Do you understand that the Steel Scoring Program, while expertly written and of decent quality, was something that USPSA had to license usage rights for? If you are considering volunteering and don't mind giving source rights, you don't have to deal with all that pesky contract negotiation, lease vs. buy pricing, pre-negotiated consulting fee for changes, etc. The standard contract process negotiation process will always be between you and getting work done if you wish to make a sale to USPSA.

It's not like you submit encrypted serialized binaries or something

Great idea. I'll add it to the list. Just kidding

Heck, why would I bother with that much effort when I can just alter flat files with a text editor?

The real issue with OSS is not "hackery" but a proliferation of versions each with a special feature a club wanted. First problem - people start calling Sedro for support on these unofficial versions. Then, the cute code introduces a bug that causes a hickup in the process and USPSA staff has to track it down. If that's not enough, consider what happens if USPSA fixes a bug or changes the output file format to add more data, and a club ups the file format version without incorporating the bug fix or adding the new data. If OSS ever became popular, and MD5 checksum (or one of the newer better ones) could be added to the output files, and the version distributed by USPSA would use an undisclosed seed value.

I've seen it happen. It's possible to attach to the EzWinScore database via ODBC and shove data in. We've had some cases where bugs are reported, we find data constructs we don't think the code has any way to create - and later learn that the club's technoweenie shoved data directly into the database. Ooops.

I'll argue that USPSA HQ doesn't really have the resources to do a code audit on something closed source. Is that something they honestly do now?

No, but when someone calls in and reports a bug with version 3.1415 or whatever, Roger knows EXACTLY what code they are running.

[Skydiver]

Do you mean "can be built" or "must be built"? If it is the latter, I'm not an open source license expert, but I think the precludes the use of some open source libraries.

"Built from source" means using the standard tools - virtually every program uses standard libraries not compiled as part of the program.

I understand that virtually ever program uses standard libraries not compiled as part of the program. What I was trying to allude to was that a lot of open source licenses specifically say that anybody should be able to get the source and be able to build the same product. The sentence "Any scoring program supported as an official USPSA product must be built from source code by HQ staff." from which I pulled the source from made it sound like only USPSA HQ would be the only one allowed to build and distribute the product.

And it's not "can be built from source", but "IS built from source". Until you actually do it, you don't know if it will compile - something as trivial as an include directive that references a file by absolute rather than relative path (pointing to a file not in the distribution) can prevent a build and be totally unintentional.

Oh, yeah, I completely agree. I remember old projects I worked on where I sync'd up to the latest code and the build would fail. The last person who checked in simply says "Works on my machine". Argh! Then the hair pulling begins as I try to unravel what changed in the build that suddenly put a dependency on the last person's checkin. If we go open source, we definitely want to be like most open source projects out there than can be built from scratch after enlisting in the project.

It's not like you submit encrypted serialized binaries or something

Great idea. I'll add it to the list. Just kidding

Actually in all seriousness, digitally signed XML would be a good way to exchange the data between the club and USPSA. The data would be mostly human readable, but the digital signature attached would prevent any hacking of the data. Anybody who wants to do special post processing of the data for display on a club web page, or do trend analysis can parse the XML, but the data will be secure from tampering.

The real issue with OSS is not "hackery" but a proliferation of versions each with a special feature a club wanted. First problem - people start calling Sedro for support on these unofficial versions. Then, the cute code introduces a bug that causes a hickup in the process and USPSA staff has to track it down.

USPSA's first question to the person should be, "What is the MD5 hash of osswinscore.exe? ... Oh, we only support the main trunk build and not branches. Please export your match data, and import it into a main trunk build of osswinscore.exe. ... Oh, osswinscore.exe crashes due to division by zero error? That must mean your private branch inserted invalid data to solve Flexmoney's 'Noodle on this problem.' So sorry, we can't help you. ... Oh, but you should be using the main trunk build when you are running a level II match, I'm sorry that you just lost a day and a half's worth of match data from 200 shooters."

If that's not enough, consider what happens if USPSA fixes a bug or changes the output file format to add more data, and a club ups the file format version without incorporating the bug fix or adding the new data.

Funny, I've been thinking about this exact problem. Part of my solution for this is what has been steering me to recommend using Mercurial for source control instead of git or subversion. Mercurial considers history to be sacred, and so each branch knows it's full lineage. If somebody fails to pick up a set of changes it won't be in their branch, and their revision ID will be different from everybody else who does pick up the changes. If the product is built with the current revision ID built into binaries, and when that binary generates a file, the pedigree of the program that generated the file can be examined, much like the way digital signatures and certificates can be examined.

Yes, a determined hacker who wants to spoof the revision ID can do so (since they'll have the full source including the build scripts), but if somebody is good enough to spoof USPSA, they should be good enough to write code that doesn't blow up, and ensures that their code doesn't generate data that will make other branches of the code to blow up when that data is imported. Otherwise what would have been the point of spoofing if you can't get code to run?

If OSS ever became popular, and MD5 checksum (or one of the newer better ones) could be added to the output files, and the version distributed by USPSA would use an undisclosed seed value.

Good idea. Let me recommend instead of using an MD5 checksum, using real x.509 certificates for digitally signing the data. As you know, these use public key encryption for signing, you are suppose to keep the private part of the key secret.

The only thing that never gets checked into source control will be the public and private keys. If somebody downloads the source, the code is written such that if it given a key-value pair, it'll use it for digitally signing the XML. If it's not given such a pair, then it just generates the XML without a digital signature.

Going with certificates will also open up the possibility of USPSA signing a club's certificate, so that when a club uploads it's data, the club password doesn't need to be entered, the digital signature just needs to be checked for validity.

No, but when someone calls in and reports a bug with version 3.1415 or whatever, Roger knows EXACTLY what code they are running.

See my comments above about what is steering me towards suggesting Mercurial as the source control system, as well as the "What is the MD5 hash of osswinscore.exe?"

[JThompson]

Rob... the USPSA staff has to track down some bug? Hell, if that were the case we wouldn't be talking about this now. That's like saying MS must track down every bug a driver has with regard to the MS OS. Their answer is, reload it. USPSA would have a standard version and any mod for local stuff or betas would NOT be supported.

We go from not being able to pay one or two code people to supervising a team of '"7-8 devolpers?" Where do you get that from? What I was talking about is those who have been working on it in the past, watch over a couple of coders and guide them. Since they no longer have to code, their work load should be less than coding. If that is too much for them to handle, perhaps, we need to bring in some fresh blood.

A wise man once said, from the time you take on a project, you should be training your replacement...........

If we can take on something like the Steel Challenge, we can figure a way to get this done. Instead of thinking of five reasons we can't do it, let's agree it needs to be done and find a way to do it.

Edited April 20, 2010 by JThompson

[LChico]

Any chance we could split the developer techno jargon into it's own thread & take this one back to "EZWinScore in the real world" as asked by the original poster?

I was asking a friend in another state (with a club that uses Palms) why she had not posted in this thread. She said it had evolved into a discussion about software revision.

Linda Chico (L-2035)

Columbia SC

Edited April 20, 2010 by LChico

[Skydiver]

Thanks for keeping us on track, Linda. I'll kick off another thread.

[wgnoyes]

...The following links are to the licensing documents for Microsoft SQL Server 2008 Express, and Oracle Database 10G Express products. Both are free, and freely redistributable. Microsoft requires that you register to redistribute though.

http://www.microsoft.com/sqlserver/2008/en/us/express/redistregister.aspx

http://www.oracle.com/technology/products/database/xe/index.html

There's also IBM DB2 Express: http://www-01.ibm.com/software/data/db2/express/

[Rob Boudrie]

Rob... the USPSA staff has to track down some bug? Hell, if that were the case we wouldn't be talking about this now. That's like saying MS must track down every bug a driver has with regard to the MS OS.

Certain types of bugs WILL be tracked down. Report a problem that blocks a critical function, and it will be investigated.

Even Microsoft tracks down bugs (in fact, they have thousands of KB fixes, some generally available, and some available upon request, for specific bugs.

We can't deal with "unoffical" spins of the released products, however, there are signaturing techniques that can be used to assure only files generated by official drops would be accepted by USPSA's server.