The starter always confirms the starting car's number at the starting line. So if someone gets into the wrong grid spot, it doesn't matter because their car number would be still correct at the starting line. If someone is driving someone else's car and doesn't inform timing appropriateyl, then you would have that problem anyway.

Reruns are not an issue because they are just like regular runs, except done again for a special reason. Cars still line up at the starting line in a certain order to run a re-run.

Double-driver cars are not an issue with sequencing--with any other solution, the club needs to know which driver is at the starting line.

The order that's the same is the order of cars that have been launched from the starting line, not the order of cars lining up for that line.

It doesn't, because at that point, the car that spun is considered a "DNF." The car that spun can be instructed to not to trip the timing lights and if they do, it can be fixed.

In autocross, cars are not allowed to pas each other. If someone spins and the car behind gets too close (within 10 seconds), it gets red-flagged and gets a re-run.

I autocross and I've been thinking about the same problem. I even thought about writing my own free software and building plans for off-the-shelf/cheap-to-make transponders ($1200 for a wireless transmitter unit? jesus).

The problem is that if a car doesn't finish and misses the timing mark--the software shoudl just let you to fix it up. You should be able to say "this car didn't finish" (has a missing tick) or "ignore this tick" (some corner worker tripped the lights accidentally). Then it shoudl be able to just recalculate the times affected. It seems so simple to me, I am baffled that it hasn't been implemented.

All the cars starts in the same order, all the numbers are known at hte start time and cars never pass each other. So you have always same-sequence travel of cars. All you need to do is fix occassional lacks of ticks or extra ticks. No need to re-run the cars.

Verizon/AT&T probably do not keep historical data, even if they can pinpoint my location at law enforcement's request.

The problem is that we have traffic laws with unrealistic speed limits in this country, towns that will raise revenue through ticket writing and red light cameras, all now with access to your OnStar data without your consent or a warrant. Drivers that go with the flow of traffic are safer due to a smaller speed differential--but your insurance company may be glad to force you to do 65 on a road designed for 75mph in the 70's (MassPike) or 55 on a newly widened 3-lane widely-divided highway (rt 3 Greater Boston).

towns shorten yellow lights to get more red light tickets--increase in rear-end accidents be damned. Wouldn't it be nice to corroborate that data with the onstar gps log?

Shh, Slashdot heads might explode.

Unless the TFA is talking about SFTP (which it isn't), there is no reason to laud anything positive about FTP. Other than it was a straightforward protocol and it served us well, back in the day.

Oops, accidental A/C post

This is a plea for anyone who thinks object-orientation won't do anything for them to stop and back away from that view for a second. Give me a minute to explain.

Read this great article called Why are you still using C?. I think it explains very well what OO can do for it.

Did you know that the Linux kernel, despite NOT using C++, is actually doing bonafide object-oriented programming?

Just one example is the Linux VFS. A filesystem passes in a struct with function pointers to read, write inodes, etc. The I/O kernel code only knows about each VFS in the generic terms, but ends up calling specific implementations via the function pointers. This is called polymorphism.

That's right, the Linux kernel is doing real, meaningful object-oriented programming. In contrast, if you put a few functions together under a class (like many people do that "have to" write OO), then you ain't doing jack shit worth of object oriented programming. However, because the kernel is using C, it has to do a lot of messy things with pointers. C++ helps take care of that mess (polymorphism is supported in the compiler), so you don't have to write it by hand.

Problem is, object-oriented programming is useful when it is applied on an as-needed basis.

Design patterns? Same thing. People got a design patterns boner when the book came out (I know I did). The academic/enterprise/fancypants software architect approach was: "What if? What if?! Why not use a pattern here, just in case you ever need to do it this other way?" So, you end up seeing patterns and flexibility and layers of abstraction (variations on a theme) built everywhere, where you end up not using them.

So you end up with a ton of code that never really does you any good. Worse, when you suddenly realize that you need some kind of flexibility, you already probably sliced the code the wrong way, so now it's actually *harder* to make things flexible. All because you made them flexible ahead before you knew what you actually needed.

There's a concept of emergent design, which basically says: don't come up with any frameworks, let frameworks emerge from the code. That is, if you find yourself needing to copy/paste the code or find yourself repeating something that's awful similar to this other thing, well, *now* -- only now is the time to use a technique to eliminate the duplication. Maybe you make a little framework. Maybe you just make a class or two to help you out. Maybe you use a bit of a larger design pattern, well, 'cause you don't need to use the whole thing. And that's great! You've taken care of the duplication, so now all the code you have has purpose, has a real need.

WE have been made to feel stupid, by all these academic and UML software architect wankers that are removed from real-world coding and proclaim the need for design patterns everywhere and "careful architecture" beforehand. Turns out that we weren't stupid, we were just being practical.

I don't know whether you've gotten caught up in the UML/"design lots of patterns"/"writing code is for suckers" hoopla of the late 90's early 2000's--as if you didn't, you'll have a much easier time learning state of the art in development, while being able to apply enough experience from your younger days. (Consider everything that has to do with J2EE Enterprise Java of early 2000's as an example of what not to do.)

If you want to become current, you are going to need to learn to do:

1) Test-driven development
2) Write clean, expressive code (with much less need for comments and documentation)
3) Object-oriented design, as used to solve actual problems (not just putting functions into classes)
4) Design for what you need now or in the immediate future and refactor only as needs change
5) The Do Not Repeat Yourself principle. No duplication or copy/pasting.

The best advice I give to any starting out developer these days is to read Robert Martin's book Clean Code. It distills the wisdom of many an experienced programmer into a clear, well-explained format. It's Java-centric, but principles apply everywhere. Read it and see why separation of concerns is good, why keeping your functions at the same level of abstraction is good, why the single responsibility principle is good.

That book is the first book that explained to me properly why I should give a crap about the Law of Demeter. That law has been around since 1987 and yet I rarely came across anything but explanations with sterile, academic examples. Yet, "Clean Code" showed me why it's bad in closer-to-home terms AND, best of all, instantly provided a rewritten version that didn't violate the law and was clearly better.

One important point: it's not the languages you know, it's whether you know how to code well, design well and analyze problems well. All languages are just tools.

Modern development has finally stopped pissing over code and began respecting code. Gone are the days of trying to make UML diagrams generate Java (Model-Driven Architecture seems to have successfully passed us by without doing too much damage). In the web apps world, I think Ruby on Rails exemplifies latest thinking in software engineering, namely the thinking of "less code = better" and how to add abstraction layers without imposing code overhead in your application (e.g. convention over configuration).

Just because something is easier to use and works right without having to FK with it, doesn't mean it sucks for the advanced user.