What is "SoloTimer"?

[Brian G]

SoloTimer is a name I made up while creating this Google group because
I didn't have a name (nor a product) to pull from. The purpose of
this group is to explore what a next-generation autocross and
rallycross timing and scoring software solution might look like. I'm
hoping that the people who have been in the trenches of T/S software
development for various clubs across the country will come together to
contribute their expertise and their challenges that we can align with
the desires and wishlists from timing and scoring volunteers.

To start with, I know of at least the following projects that exist
today and who are using them:

NRSCCA - Mark Walker - Nebraska Region SCCA
Autocross Scorekeeper - Brett Wilson - WWSCC and SCCA NWR
Konez - Shawn Metheny - in design phase
OpenCross - Brad Clarke - idle (http://sourceforge.net/projects/
opencross)
???? - Glenn Wilson - currently unused

There are also some commercial products:

AxWare - Vitek, Windows
AutoX T/S - Seems dead (autoxts.com is squatted on), DOS based
Accucros - Gary Poole, DOS based

Anyone know of others?

I'm going to draft up a high-level system architecture to use as a
baseline for discussion. I hope to serve as a catalyst here but have
no intentions of being a project lead per se. In that respect,
everything is up for discussion as far as I'm concerned and I only
hope that I might be able to herd our group of cats into one
particular direction (towards that of producing tested, functioning
software! :)


Brian

[digitalseance]

I pulled OpenCross out of SF CVS and poked around. Seems it's got an
'ok' basis and I see the direction Brad was going in. It was
certainly not a SOA approach but interesting none-the-less. I'm also
more of a MDD type of guy vs TDD though. :)


The idea of taking an SOA approach is a good one, however utilizing
REST may be a bit much overhead unless the software was ment to run in
a server/slave type of setup (ie announcement both and/or T&S station
are seperate pc's). I know axware can have the seperate announcement
window and be accessed with the master/slave type of setup. The
software must be able to perform at a reasonable speed even on 4yr old
laptops.

As for UI, we could even explore the path of an ajax controlled UI.
Dojo is open source and is fully capable of providing extreme power
for just about anything needed from a UI perspective. However, I do
think the troubles of running within a browser window would prove it
to be an ill advised path. I just downloaded the Android SDK so
perhaps it can provide some sort of insight.

Before we think too hard into the software architecture, we must
figure out where the data will be stored. Derby is an option, albeit
not a good one (IMO). Bundling SQLExpress or MySQL could work. MySQL
would be the better of the two for licensing reasons but it's been a
long time since I've played with bundling the db into a product.


-Philip C.

[Nick Hallman]

Philip, you're such a geek.... why did you have to leave us? ;-)

Since stability has to be a top priority for any T&S software, I think
you can just about rule out a browser-based app. Browser frameworks
are a lot better than they used to be, but I can't imagine them being
stable enough to create a "crash-free" environment.

Selecting a database backend is, IMO, one of the key components to the
project. My biggest beef with AXWare is that all the data is stored
in flat text files, which can be (and have been) corrupted.

While I don't think that a full browser-based solution is ideal, I do
think that constructing reports with XML and CSS would give users full
control over the style and layout of the program's output, without the
need to waste time building a GUI report-customizer. So there are
some tools from the browser world that would prove useful...

--Nick Hallman

[Shawn Metheny]

I would agree that a database driven back end is important as it opens up scalability for larger events and makes things like reports much easier to create. With a database you can have 3 people doing registration, scoreboards showing timing info, people could look up their sector times via wifi etc all at the same time. A flat file just won't scale like that. Functions like registration can easily be done via a browser as well as reports as mentioned above. But I am in agreement that a browser is not the answer for the main timing function. If you have ever seen a browser hang for a period of time that is just one of the reasons why it doesn't seem very practical.

jvillain

[Brian G]

Nick Hallman wrote:
> Since stability has to be a top priority for any T&S software, I think
> you can just about rule out a browser-based app. Browser frameworks
> are a lot better than they used to be, but I can't imagine them being
> stable enough to create a "crash-free" environment.

Agreed, although let's separate out the timing and scoring bits from
the user interface bits. I have some decently fleshed out thoughts on
this, but in a client-server arrangement, the clients could crash (and
you know they will eventually, on some hardware combination,
somewhere) without interfering with the data. Restart the client,
resume your business.

> Selecting a database backend is, IMO, one of the key components to the
> project. My biggest beef with AXWare is that all the data is stored
> in flat text files, which can be (and have been) corrupted.

I know Philip mentioned MySQL or SQLite; I'm going to throw in
Postgres. There's one specific reason which I discussed with the
Shawn Metheny previously: it has really extensive date/time support
unlike any other (free) database I'm aware of. Postgres has the
concept of "intervals" which are units of time that can be added and
subtracted from dates and timestamps and I think could offer a simple
but very flexible data model:

http://www.postgresql.org/docs/8.3/interactive/datatype-datetime.html
http://www.postgresql.org/docs/8.3/interactive/functions-datetime.html

You can do date/time math in any database and any programming language
but I don't think another database is quite as flexible in this area.
There is also a significant difference between Postgres and MySQL in
licensing that makes Postgres a bit more friendly to work with but
these are details to be debated soon.

If you guys have blogs, facebook, twitter, websites, etc, it would
great to throw a call out for anyone who is interested to come join
the group. Even if they just want to observe, the more input and the
earlier we get it will make this better.

Shawn Metheny wrote:
> With a database you can have 3 people doing registration,
> scoreboards showing timing info, people could look up their sector times via
> wifi etc all at the same time. A flat file just won't scale like that.

When I had my consulting company, we wrote a real-time display for the
DARPA Grand Challenge project. It was a race of autonomous vehicles
sponsored by the government where teams entered cars controlled by
laser, GPS and other sensors with software to navigate an unknown
desert course. We built a flash-based leaderboard and map that was
shown on big plasma TVs at the event headquarters with status updates
and background material. While this would be priority #993230, I
wouldn't put it past some of the bigger Divisional or Regional events
from hauling out a big screen with fun stuff like those sector times
and so forth.


Brian

[digitalseance]

It seems the consensus is that a browser based app is out of the
question. Agreed that is probably a bad idea for all the reasons
stated. I think HTML/XSLT/CSS reports would be the only way to go with
a .csv and .pdf option available for those who like those formats for
results posting.

I'm most certainly not a DBA and the stored procedures I write are of
the elementry level, so as long as the license allows us to use it how
we would like to then I'm game for Postgres provided a bundled
installation is feasible.

Twitter was mentioned as a way of getting folks in on the discussion,
but could that type of technology be incorporated into the app?
Perhaps when someone trips the finish lights the app could broadcast
SMS (or whatever) to any registered devices within its system? Phone
number is something we capture during the registration process and we
could add a flag to allow (insert message type here) messages to be
sent to the number. This may not be feasible, I'm just throwing that
out there because so often the time display has died or was forgotten
during setup. Plus, it could (potentially) broadcast to all registered
devices so course workers and people in the paddock/grid could recieve
the time of the person that just crossed the lights... that would be
cool :)

So what UML tool does everybody use?? I'm a sparx enterprise architect
guy myself but could do design work in RAD/Eclipse if necessary.

What open-source language do we want to use for this bad boy? As a
java developer, I'm partial to the java 1.5 flavor ;-)

[Brett Wilson]

I might as well make myself known as well then. One correction to the
initial list. Autocross Scorekeeper is Scott Chytil's (retired). My
stuff doesn't really have a name other than NWR Scorekeeper. Its all
GPL and I have an online Trac site. NWR-SCCA still uses the old
stuff. We use my stuff for WWSCC and the NWR regional ProSolo series.

Some choices I made:

Backend database is sqlite. Great for speed. Easy to transport the
database around (even for computer illiterate chiefs/chairs) as its a
single file and pretty much every hosting site has support in some
fashion.

Type support for things like datetime have to be agreed upon between
different languages reading the same file as its not specific in the
database itself. Also have to build your own remote support if you
wish to access it across systems. Both of these can be quite the
pain.

All of my primary applications are written in Java. Partly I'm
familiar with it and the apps can run on multiple platforms. Thought
about some of the scripting interfaces such as jython, grovvy, but
never went there yet.

The web backend is written in python. The web backend is used for
online registration/admin as well as onsite wireless results. As more
handheld 802.11 devices show up, this becomes a more used feature if
the timing van is close enough to grid. I know some people at a
previous regional ProSolo event where checking results while they were
in the staging lines. I'd be worried about my next runs but that's
just me.

Also side from scoring software, you might want to consider simple
timing as well. For one of the WW clubs, I build a super simple
little hardware device that takes timer light inputs and converts them
into timestamps and communicates that over a USB port. Think
Accucross with the timing done on a little Atmel board and no need for
DOS. The software takes care of matching time stamps and creating
times. The chip I used has 8 external interrupt pins which can
provide a course with 7 segments. We've only run a couple due to
site/cable issues. As the wireless systems become cheaper and better
tested, this is less useful but its nice for a small club that wants a
cheap timer for practices and the like. I believe the RA Wireless
systems send timestamps as well.

Also something else that was useful is simple multicast announcement
setups to announce services so clients can discover where to connect.
For us, services include the main database server (two data entry
machines for a Pro), the pro solo timer, etc.

Brett

[Shawn Metheny]

Well that does bring up the question of what hardware to run. I was originally looking at doing an open hardware design where any club could download the plans and build it themselves. Unfortunately I have moved from my house to a condo in another city and prototyping hardware here isn't going to be possible.

But you can side step the issue of what hardware to run as long as you have an API for the timing hardware to talk to the timing software that is flexible enough. That would leave you with a small program to write for each different type of timing hardware you wanted to use. That way any one in theory could keep using what they owned if they wanted to.

We had looked at using battery powered segment timers and syncing the time via GPS. The segment timers could then wifi the time back to the base station. You wouldn't have to worry about latency over wifi as the time capturing would have allready happened out at the segment timer. If that makes sense.

While I am at it we also thought of attaching RFIDs to peoples helmets so you didn't need some one writing down car numbers or running a bar code reader.

[Alan Pozner]

Hi All,

Alan Pozner here. I am a Windows platform developer (MS C++, C#)
although I have extensive experience in Oracle, J2EE, XML, Web
Services.

I do not see the need for a DB that supports complex date/time
functionality. All timers that I know of produce times as 6 discreet
integers. They can be stored as strings or an int or a double. The
only math operations that need to be performed are addition of cone
penalties, comparison for placement and PAX calculations. All are best
performed as simple math operations against a double.

I am of the KISS school. I do agree that a relational DB backend is a
requirement. But some of the other capabilities be considered but only
as a "how do we leave an interface for future expansion?" rather than
a "we could do this" I think a multiuser relational dbms gives us the
interface and no need to focus on bells and whistles.

I have two versions of T/S software (VB and Windows SDK C++) both
using a MS Access backend (flame away). I would not make the same
platform decisions I made again but the important thing here is I have
used the software for years and have watched others use it. I know the
problems they have had, the errors they have made and the difficulties
in training.

After stability and extensibility, the most important aspect of any T/
S software is usability. And that is what we must focus on.

That said, a feature not mentioned yet that our architecture should
allow is the ProSolo format. The National staff has been struggling
for years to get reliable software. Darren DiSimo has been their
developer and it would be very interesting to get him in these
discussions.

[Alan Pozner]

Timers - I have seen two basic types:

1) The Tag Heuer type sends a message at each start and each stop, The
message consists of a time stamp and a flag to indicate start/stop.
Its up to the timing software to store them in a FIFO buffer and
convert them into run times when a stop message arrives.

2) Race America / JA Circuits type sends finish times only. The
message is an actual time. This means that an operator need to adjust
the timer box and the software when false finish trips happen.

Both types will engender very different UIs and must be accounted for
in our design of a timer interface.

[Dave Heinig]

The newer JACircuits boxes will also do timestamps: http://www.jacircuits.com/news.htm

 

I think that is the way to go, as it allows correction of false triggers on the fly, without stopping the event and without granting reruns to every car on course.  I'd also like to see a way for that process to be reversible, and for the gui to give the operator a very clear picture of the timestamps, which car they are related to, and which ones are flagged as invalid.  I'm not sure how many clubs are using a timer that sends finishes only, but the type of functionality I described would be impossible if our software supported those.  Like Alan alluded to, we may end up writing different UIs for the different timer types.

 

Another format to consider is a doublecross format.  In Atlanta they interrupted the first finish with a manual switch, but if the software could be programmed to ignore finishes before a set time interval, it would automate that piece of it.

[Brian G]

It strikes me that we should start a wiki or kb to document "What is
Autocross" from a functional perspective. I'll work to get something
set up. For example, capturing details on common timing hardware,
identifying the various event "styles", etc. This will also help
solicit input from non-programmers I think.

Anyone have a rec for Google code, Github, Launchpad or another?

I also posted my thoughts around a high-level architecture last night
in a new thread.

[Brian G]

On Jun 26, 3:37 am, Alan Pozner <alanpoz...@gmail.com> wrote:
>  I do not see the need for a DB that supports complex date/time
> functionality. All timers that I know of produce times as 6 discreet
> integers. They can be stored as strings or an int or a double. The
> only math operations that need to be performed are addition of cone
> penalties, comparison for placement and PAX calculations. All are best
> performed as simple math operations against a double.

I disagree here - while you *can* do all of the mathematical
calculations yourself (and so could the next developer and the next
developer and so on), by using a database that already has these
mechanisms in place, you relieve yourself of writing, testing and
maintaining that code. That is a win all the way around. Since we
can choose any database we like, why not start with one that
jumpstarts our effort?

My two cents is we're better off using our limited resources (e.g.,
nights and weekends) on writing code specific to timing and scoring
and not rewriting base libraries for things like datetime manipulation
(or SQL abstraction or UI controls or Network communications, etc,
etc).


Brian

[digitalseance]

The need for common libraries is unavoidable. In my years of
programming, I've written several frameworks to handle said utilities.
In fact, I prefer the conversions to be handled in code to eliminate
the dependency on a particular dbms. By storing the "timestamps" in
the db as bigint's, ints, double, or even string, you will always be
able to manipulate the output as you see fit utilizing Calendar or
Date objects, or even with simple int math.

To stick to the true platform independent concept, the dbms should not
be tied to the product and the user should be able to pick the db they
want to use (with a jdbc limitation).

I agree that all autox type formats should be able to be handled,
prosolo and doublecross. I do see the need for normal autox over
prosolo over doublecross in priority. There are far more prosolo
events than doublecross events (that I know of at least).

I also agree we should not limit the user to a certain type of timer
and we should have support for the two major implementations.

I'm also a huge fan of the KISS concept. There's no need to over-
complicate something that really doesn't need it. We need to be
careful not to over-engineer where it is not needed.

On-demand results via wireless devices is a neat idea. I still like
the idea of "twittering" a message as the finish lights are triggered
to any registered (or available) devices. Just not sure of the "how-
to" there though...

We must remember that most smaller clubs will only have one, perhaps
two, pcs that are used for T&S. I know for a fact, both Buccaneer
region clubs and the Dixie region all use 1 computer for T&S. Most
annoucements use the paper backup and radio transmissions. The
Champaign County Sports Car Club and the Central Illinois Region use
two computers, but the second is just for announcement and for walkup
questions regarding timing.

I think the RFID idea is neat, but I think you'd run into instances
where the rfid scanner would pickup multiple tags. I'm yet to see an
event where there's only one car at the line and one staged. It's
usually several cars deep in the staging line. Perhaps this could be
addressed somehow, but off the top of my head I can't think of one.

[Brett Wilson]

2009/6/26 Alan Pozner <alanp...@gmail.com>:

>  I do not see the need for a DB that supports complex date/time
> functionality. All timers that I know of produce times as 6 discreet
> integers. They can be stored as strings or an int or a double. The
> only math operations that need to be performed are addition of cone
> penalties, comparison for placement and PAX calculations. All are best
> performed as simple math operations against a double.

Times were stored as doubles. Date time was used for actual date
time information like day of an event, when registration opens/closes,
etc.

[Brett Wilson]

2009/6/26 Brett Wilson <dryto...@gmail.com>:

Also, cached calculated result information (points, etc) in another
table so that wireless results don't have to perform the same table
lookups/processing over and over. This had a date time value as well
so that the announcer screen, that periodically probes the database,
can determine if there is new data to display. This used a date time
though a simple long would work as well.

[Glenn L. Austin]

Plus, the challenges come when you have to do PAX/RTP calculations.
Yes, you can use integer multiplication to do the calculations, but
why would you want to when even a float has enough precision to store
the values.

Yes, you do need to be careful when working with floating-point
values, but as long as you're always working within the display bounds
of 1/1000 of a second, it shouldn't be an issue since that's all the
resolution that we need to have -- at this time, at least. I can't see
a requirement to go to 1/10000 of a second resolution any time soon.

--
Glenn L. Austin, Computer Wizard and Race Car Driver <><
<http://www.austin-soft.com>

[Brian G]

On Jun 26, 10:00 am, digitalseance <pmc...@yahoo.com> wrote:
> To stick to the true platform independent concept, the dbms should not
> be tied to the product and the user should be able to pick the db they
> want to use (with a jdbc limitation).

The two most common progress killers in open source projects:

* Database abstraction (the "use any database you like" type)
* UI Theming

Think of this from the viewpoint of the Timing and scoring team. They
don't care that there is a database, only that there is data reliably
stored. They almost certainly do not care that it is MS Access,
Postgres or SQLite. And with the exception of a hardcore geek
somewhere who wants to tinker, they definitely will not want swap out
the underlying system (assuming they all store data reliably).

In the spirit of KISS, is maximum abstraction is really a benefit?
Think specifically from the users point of view - the cross-platform
nature ensures that clubs could use the program on whatever hardware
they have available without worrying about a specific version of
Windows, for example. That is a benefit. Being able to change
databases? I struggle to see how that aids them.

From a developer's point of view, let's say we decide to make the
database pluggable. Now to reach a version 1.0, you need to pick
which databases will be supported. And then each time you run a test,
you need to maintain an environment that tests all of those systems.
It exponentially drives up the complexity of the development process
and at the same time restricts your freedom as a developer to get
things done. Writing any kind of complex SQL in a cross-database
manner is usually less performant and more verbose than if you agree
to standardize on a single system. I've worked on several open source
projects where they were designed to sit on your existing database and
it really makes development a PITA because Programmer A, who is
implementing a feature, rarely has equal skills or experience in all
of the databases. And this is JUST the database we're talking
about. :) Now extrapolate this same development, testing and
maintenance nightmare out to the rest of the application, including
places where we MUST have abstraction (like the hardware timing for
example) and we've turned what is a fairly straightforward effort into
a massive engineering project.

So I make this pitch to you, my fellow compatriots! :) Let us build
things in an iterative manner, making reasonable assumptions and
dependencies that enable us to quickly get to a functioning product
(like only one database). Let us write as little code as possible to
get there (like not rewriting library-like functionality). And then
let us refactor as necessary as we learn that our assumptions and
decisions no longer work. At the end of the day, if we produce
nothing, then we are benefiting nobody. So our project philosophy
should be to prioritize getting things done well over never getting
them done perfectly. Does that sound like a fair guiding principle?

> On-demand results via wireless devices is a neat idea. I still like
> the idea of "twittering" a message as the finish lights are triggered
> to any registered (or available) devices. Just not sure of the "how-
> to" there though...

Agreed, would be great. There are a few ways to go about this. Most
likely is for someone to have one of the WLAN cards like Verizon or
Sprint. We have a lot of customers who use these on site to do
registration via MotorsportReg.com and writing something to pump
results to the Twitter API is trivial (for example, our deployment
process automatically sends notifications to http://twitter.com/pukkasoft
whenever we have a maintenance window and it took about 15 minutes to
write it). Twitter will SMS anyone who follows you if they opt for
it, so it would be a way to pump out the text messages without paying
for it.

> I think the RFID idea is neat, but I think you'd run into instances
> where the rfid scanner would pickup multiple tags. I'm yet to see an
> event where there's only one car at the line and one staged. It's

RFID, without really large-scale readers, has a small range of
pickup. Think contactless credit cards and or access cards which you
effectively have to "touch" to the reader to work. It's not much
different from a barcode in implementation. Barcodes are typically
less finicky but RFID can hold more information and is more
environment resistant (rain, etc).


Brian

[digitalseance]

Sold. ;-)

> So I make this pitch to you, my fellow compatriots! :)   Let us build
> things in an iterative manner, making reasonable assumptions and
> dependencies that enable us to quickly get to a functioning product
> (like only one database).  Let us write as little code as possible to
> get there (like not rewriting library-like functionality).  And then
> let us refactor as necessary as we learn that our assumptions and
> decisions no longer work.  At the end of the day, if we produce
> nothing, then we are benefiting nobody.  So our project philosophy
> should be to prioritize getting things done well over never getting
> them done perfectly.   Does that sound like a fair guiding principle?

Nothing is perfect, ever. That said, if you can get it to 7/10ths the
first shot, why not? Thinking ahead about these libraries and seeing
the need for them to be utilized in each "client" just emphasizes the
need for them and brings you closer to 7/10s vs 3/10s of just
"working". See my post in the other thread regarding MDD vs TDD.


-Philip

[Shawn Metheny]

On a final note, I have stressed cross-platform here even though I
think it's something of a red herring.  Mac's comprise around 8% of
the market (although probably more of the laptop market?) but I
sincerely doubt anyone is going to bring out their Mac Book Pro for
use as a T/S computer.  Realistically Windows is the target platform
of choice.  However, Java is a solid, common language with a LOT of
third party support and one that I think we can successfully rally
around for the relatively small core server.

I think choosing to make this a Windows only app is short sited. The vast majority of embedded devices run Linux now and the new arm based net tops could turn out to be very popular with the clubs as they are dirt cheap and have all day battery life. Windows will not run on them at all. But it does bring up the question of how is this going to be licensed?


As for the question of how many computers do clubs have at events you need to ask the question are clubs bringing one computer because they only have one computer or are they bringing one computer because the software only works with one computer and that is all they are licensed for?


From a database perspective I agree that being able to handle time in the query is cleaner and easier. One question that needs to be asked is if the time format of the database is precise enough for your needs. In other words when you capture a time, store it and pull it back out again has it lost enough of it's precision that it wouldn't be usable for your needs. I had found a link to a chart comparing the precision of different databases that support time stamps and I was coming to the conclusion that most databases would not be accurate enough to use that way. The issue was that you could input a time stamp with microseconds and pull it out with microseconds but you may not get the same answer as you put in. If you guys have databases up and running some simple insert and select statements should be able to verify it.  I have that link in my documentation that is on a computer that is still in storage. I will see if I can get it out this weekend.


jvillain

[Glenn L. Austin]

On Jun 26, 2009, at 11:31 AM, Shawn Metheny wrote:

On a final note, I have stressed cross-platform here even though I
think it's something of a red herring.  Mac's comprise around 8% of
the market (although probably more of the laptop market?) but I
sincerely doubt anyone is going to bring out their Mac Book Pro for
use as a T/S computer.  Realistically Windows is the target platform
of choice.  However, Java is a solid, common language with a LOT of
third party support and one that I think we can successfully rally
around for the relatively small core server.

I think choosing to make this a Windows only app is short sited. The vast majority of embedded devices run Linux now and the new arm based net tops could turn out to be very popular with the clubs as they are dirt cheap and have all day battery life. Windows will not run on them at all. But it does bring up the question of how is this going to be licensed?

While Java has been discussed as a way of going cross-platform, it's also one of the more difficult forms to talk directly to hardware -- even to just access the serial port. Also, it's not included on Windows, and may have resource requirements that make it difficult to run well on netbooks.

Since the user interface will need to be geared more towards the functionality rather than the OS that is running the application(s), I'm more in favor of using one of the many cross-platform frameworks out there (wxWidgets, QC, GNUstep, Cocotron).

As for the question of how many computers do clubs have at events you need to ask the question are clubs bringing one computer because they only have one computer or are they bringing one computer because the software only works with one computer and that is all they are licensed for?

There are probably a mix of both. Computers are expensive, but with the advent of netbooks (which also seem to be a bit more robust than your standard laptop), we might see more "multiple machine" implementations.

Also, there is the issue of getting all of the machines to recognize each other. An inexpensive 802.11g access point (that could easily be converted to run on 12V dc, since most already have the wall warts to convert 120VAC to some form of DC) would be ideal for centralized communications, plus using ZeroConf/Avahi/Bonjour for service recognition would eliminate the need for a more robust DHCP server.

From a database perspective I agree that being able to handle time in the query is cleaner and easier. One question that needs to be asked is if the time format of the database is precise enough for your needs. In other words when you capture a time, store it and pull it back out again has it lost enough of it's precision that it wouldn't be usable for your needs. I had found a link to a chart comparing the precision of different databases that support time stamps and I was coming to the conclusion that most databases would not be accurate enough to use that way. The issue was that you could input a time stamp with microseconds and pull it out with microseconds but you may not get the same answer as you put in. If you guys have databases up and running some simple insert and select statements should be able to verify it.  I have that link in my documentation that is on a computer that is still in storage. I will see if I can get it out this weekend.

While exact values would be nice (simply use an INT(6) for storage and convert to/from floating point on load/save), it may not matter that 60.000100 and 60.000900 are different, devices generally truncate to the nearest thousandth-of-a-second, they would both appear as 60.000 on the timer and display.

Adding a column for keeping the final time including penalties is a good use of resources. Yes, it does mean that you need to make sure that the final time is correctly stored, but that is a one-time operation and the can be used in your database query directly -- both for display and for order.

[Brett Wilson]

I think people may have gotten confused about my time statement.

I used datetime for real date time things like when something was
modified or a time of day when registration closes.

For run times, I use a double/float. I'm pretty sure all recent
databases have both of these formats. sqlite is 'special' in that you
can put whatever you want in any column (minus a primary int column)
which leads to the need to check all the output in case somebody
putting stuff in doesn't do it correctly.

Another downside to sqlite is that committing a transaction requires
that the entire file is written to disk before it returns okay. Small
delay but enough that the user sometimes wonders what it's doing when
using a directly connected application. Users over something like
HTTP already have a delay to deal with and won't know the difference.

So, how do we agree on a general database schema? Can we use
something like google files to provide a shared 'whiteboard'? Or
start a code repository somewhere and put ideas/docs in there?

Also Java serial port access is pretty easy with RXTX. It requires
recompilation for each platform (JNI) but you'd have to do that with
other languages as well.

Brett

[Brad Clarke]

Wow, this thread got big fast :)

Just to give some background on myself, I work for a software company.
Our primary application is a C++ FastCGI program that runs behind
Apache and keeps its data in PostgreSQL. It's unit tested with CppUnit
and integration/acceptance tested with Java/JUnit/HtmlUnit. We make
pretty good use of Test Driven Development and Continuous Integration,
to the point that we can release on any given day.

(in no particular order)

PostgreSQL is a very powerful tool, but it is not easy to manage. One
of my biggest problems is keeping our two laptops with a consistent
configuration. A PostgreSQL database cluster cannot be picked up from
the file system of one machine and placed on another without some
issues popping up. The ease with which I am able to pick up a Firefox
profile and move it between machines makes me think SQLite would be
more appropriate. You might also look at HSQLDB if Java is the
language of choice.

Power and efficiency should be secondary concerns. Even 2000+ drivers
at a national event wouldn't be that much data to crunch.

We use a database schema version number in the database and ship SQL
files that can upgrade the database to the version that the app
requires (automatically or with a single click). This allows the
schema to evolve through TDD with the code. Takes a little setup but
it really worked out well for us.

TDD need not be related to your design process, but having TDD and CI
in place as well as a culture that encourages merciless refactoring
allows you to focus less on getting the perfect design up front and
more on getting working software out the door.

For the timing control server I think Java would work just fine, and
it seems like most people already know the language. It's got lots of
great libraries and development tools available for free.

C++ is a really bad language for web development. If you're going to
do HTTP, use something else :)

I know WxWidgets or swt can make some pretty and responsive GUIs, but
that's not my area of expertise.

Communication with different timing and display hardware could have a
huge impact on language choice. I suggest doing a few spikes for
talking to different hardware before making a decision.

I'd stay away from XSLT/XML. XML is primarily a way of talking to
other software that you have no control over and is almost always the
least efficient way to get something done. XSLT is just painful to
use, and I can't imagine that anyone would ever really do any of their
own customizations with it. Think of the last person you taught to do
timing at one of your events. Do they know XSLT? Do they even know
HTML? I'd rather just let the few technically savvy people who want to
tweak things do their own builds from source.

I think the easy way out would be to start a Jetty server in the
timing control server. Let a J2EE app get at the data with Java and
report it through HTTP to whatever would like to consume it. A fairly
simple browser based announcer client means people with wifi enabled
phones, netbooks, or even a NDSi would be able to see exactly what the
announcer sees without having to develop anything special. It won't be
ideal for everyone, but I think it's definitely a good 80/20 place to
start. There are plenty of J2EE template engines out there that can be
added on later for the last 20%.

"Cloud app" integration is a sexy idea, but I don't think the
connectivity will be there for very many people. Our two timing
laptops see an internet connection about twice a year. I pull the
online regs to a flash drive the night before the event and put them
on the laptop at the event site. Another region near us has
permanently installed computers into their trailer.

Linux support should be a priority, cheap netbooks are the future :)
And since nobody likes Linux desktops you don't have to worry about
someone taking the timing computer home and infecting it with [insert
random malware]. Personally, I'd like to replace our laptops with a
couple of netbooks with SSD drives just so I can treat them a little
rougher.

Brad

[digitalseance]

I've created a wiki on my website (gotta love those installed free
features). We can use it, or not, but it's there if we'd like to.
It's setup so I have to approve user registrations so forgive me if it
takes a day to get you approved...I'm the event chair for this
weekend's event. :)

http://www.digitalseance.com/solotimerwiki/tiki-index.php

[Brian G]

I uploaded a couple of screenshots from Scorekeeper and Autocron to
the group for reference. If you guys have additional screen shots,
feel free to upload them. If you don't have access, just fire them
over to me and I'll post them. It would be good to have some
screenshots to get a feel for how people approached the problem from
the UI perspective.


Brian