So who's really at fault here? The students? The hospital for not securing their computers and network? Or the adware companies for providing the incentive?
Now, that would be a good show. Hire a bunch of contestants, and tell them that the whole thing is actually a hoax, and to pretend that they believe that they're actually being launched into space, and then (here's the tricky part) actually launch them into space.
I competed and coached for several years in the ACM Scholastic programming competitions. To this day, my school (the University of Central Florida) routinely places all three of their teams in the top ten of every regional, so it's safe to say that our method is tried and true.
Some of the major facets that we coach:
1. Easiest problems first. Appropriately applying a concept from computer science itself, the goal of a contest is to maximize your throughput. Since easy problems are worth as much as hard ones, effort should be made to discern which problems are easiest (as opposed to most interesting!).
2. Team roles. Back when contests had four people to a team, we had two people as "bangers" (i.e. people who sit at the terminal and quickly compose solutions to the easier problems) and two were "software engineers", who sat away from the terminal and worked on paper. Note that after the first hour or two of the competition, EVERYONE is a software engineer.
3. Specialize. In addition to roles, team members would typically have a specialty. Some people are good at algorithms; others at text processing; others at math problems, etc... This should all be worked out during practice to the point where every member of the team should be able to read a problem set and immediately tell who on the team will likely end up working on each problem.
4. Do as much work away from the terminal as possible. Since you only have one terminal (in the ACM contests), it should be considered a scarce resource. Priority should be placed on entering new code; if you are debugging and someone has written out new code that's ready to enter, take a printout of your program and let the other person on. An exception is made when the person debugging feels they are within five minutes of a solution.
5. Test extensively. This is the difference between a good team and a great team, in our experience. It is extremely tempting to submit your code once your program produces the correct output for the sample data. But it is not worth a failed submission.
6. Consistency. We didn't mandate particular coding conventions, but we did mandate that team members at least HAVE coding conventions. E.g. array names -- are they the plural or singular form of the word (node[i] vs. nodes[i])? Similarly for variables that keep count, method names, etc. Recalling such things while typing wastes valuable minutes.
7. Have practices that are genuine contest simulations. We even went so far as to shine lights in team member's faces and make lots of distracting noises, to simulate contest environments. On occasion we would even intentionally make mistakes in the problem sets and judging, just to prepare people for that (since it ALWAYS happens in the actual competition!).
There were others, but I can't give away all our secrets! Well, okay, maybe I just don't remember them all.
In our experience, it's the teams that consider contests to be all about "hacking" or "typing fast" that typically do very poorly. Those that apply good coding practices, and are consistent and organized are the ones that come out on top.
I'm now in Australia (where they also have DST), working on a project that involves entering important patient information, which can occur around the clock.
In the course of writing the handler for DST, we came to realise that any standard UI widget that only lets you enter a date and a time is fundamentally flawed for dealing with critically important dates and DST. This is because every possible time that occurs between 1am and 2am on the "fall back" night (in the current system) actually occurs twice that night, an hour apart from each other, and there's no way to disambiguate which one it is given only the date and the time.
I suspect this is not accounted for at all in a LOT of systems. We haven't come across any kind of standard way for the user to indicate whether they mean 1:30am before the "fall back" (for instance) or 1:30am after.
I hate Micro$oft as much as the next guy. However (and mod me down for flame-bait if you must), my message to Mr. Sorkin is "Boo fucking hoo". So they invited you in for an interview, refused to kiss your ass, and decided to see whether you could actually think on your feet. You're right, they should have just read your CV on-line and decided to hire you based on that. Somebody is being arrogant here, and it's not M$.
...is to have everyone assume that you were able to create this great original application because you have Asperger's, as opposed to crediting your creativity or perseverence.
A little narrative to go with your pictures -- check out this gripping account of this very earthquake by author Jack London (of Call Of The Wild fame).
Slashdot Mirror
So who's really at fault here? The students? The hospital for not securing their computers and network? Or the adware companies for providing the incentive?
I blame the sick people.
EA Sports presents: "Extreme Shuffleboard".
I was making a joke about the fact that Slashdotters do this, which you would have realized if you had two neurons to rub together, moron.
There's an obligatory joke whenever Sony is mentioned these days. Hmmm, let's see... Got it!
It comes with the rootkit pre-installed!
Now, that would be a good show. Hire a bunch of contestants, and tell them that the whole thing is actually a hoax, and to pretend that they believe that they're actually being launched into space, and then (here's the tricky part) actually launch them into space.
In your estimation, how close are we to the real thing?
We are climbing trees to try to reach the moon.
"Singapore: It's Not Just The Heat That's Oppressive."
It's surprising that the US has not chosen to celebrate World Standards Day on the 12th or something instead.
I think I might have to pick up a copy.
Uh, dude, I think you already did.
My solution -- I changed all my passwords to "passw0rd". Notice that the "oh" is actually a "zero". No one will ever guess that!
I competed and coached for several years in the ACM Scholastic programming competitions. To this day, my school (the University of Central Florida) routinely places all three of their teams in the top ten of every regional, so it's safe to say that our method is tried and true.
Some of the major facets that we coach:
1. Easiest problems first. Appropriately applying a concept from computer science itself, the goal of a contest is to maximize your throughput. Since easy problems are worth as much as hard ones, effort should be made to discern which problems are easiest (as opposed to most interesting!).
2. Team roles. Back when contests had four people to a team, we had two people as "bangers" (i.e. people who sit at the terminal and quickly compose solutions to the easier problems) and two were "software engineers", who sat away from the terminal and worked on paper. Note that after the first hour or two of the competition, EVERYONE is a software engineer.
3. Specialize. In addition to roles, team members would typically have a specialty. Some people are good at algorithms; others at text processing; others at math problems, etc... This should all be worked out during practice to the point where every member of the team should be able to read a problem set and immediately tell who on the team will likely end up working on each problem.
4. Do as much work away from the terminal as possible. Since you only have one terminal (in the ACM contests), it should be considered a scarce resource. Priority should be placed on entering new code; if you are debugging and someone has written out new code that's ready to enter, take a printout of your program and let the other person on. An exception is made when the person debugging feels they are within five minutes of a solution.
5. Test extensively. This is the difference between a good team and a great team, in our experience. It is extremely tempting to submit your code once your program produces the correct output for the sample data. But it is not worth a failed submission.
6. Consistency. We didn't mandate particular coding conventions, but we did mandate that team members at least HAVE coding conventions. E.g. array names -- are they the plural or singular form of the word (node[i] vs. nodes[i])? Similarly for variables that keep count, method names, etc. Recalling such things while typing wastes valuable minutes.
7. Have practices that are genuine contest simulations. We even went so far as to shine lights in team member's faces and make lots of distracting noises, to simulate contest environments. On occasion we would even intentionally make mistakes in the problem sets and judging, just to prepare people for that (since it ALWAYS happens in the actual competition!).
There were others, but I can't give away all our secrets! Well, okay, maybe I just don't remember them all.
In our experience, it's the teams that consider contests to be all about "hacking" or "typing fast" that typically do very poorly. Those that apply good coding practices, and are consistent and organized are the ones that come out on top.
Using the search feature, I found:
Heywood Jablome 103982 2005-08-09 21:04:33
Hugh G. Rection 241557 2005-08-29 17:34:56
Mike Hunt 77369 2005-06-29 23:41:56
Homer Sexual 38139 2005-04-24 06:31:23
But not one Phil McCracken!
Years ago, I built my Lisa into the wall of my kitchen.
She was a good wife, but she nagged me one too many times.
I'm now in Australia (where they also have DST), working on a project that involves entering important patient information, which can occur around the clock.
In the course of writing the handler for DST, we came to realise that any standard UI widget that only lets you enter a date and a time is fundamentally flawed for dealing with critically important dates and DST. This is because every possible time that occurs between 1am and 2am on the "fall back" night (in the current system) actually occurs twice that night, an hour apart from each other, and there's no way to disambiguate which one it is given only the date and the time.
I suspect this is not accounted for at all in a LOT of systems. We haven't come across any kind of standard way for the user to indicate whether they mean 1:30am before the "fall back" (for instance) or 1:30am after.
I hate Micro$oft as much as the next guy. However (and mod me down for flame-bait if you must), my message to Mr. Sorkin is "Boo fucking hoo". So they invited you in for an interview, refused to kiss your ass, and decided to see whether you could actually think on your feet. You're right, they should have just read your CV on-line and decided to hire you based on that. Somebody is being arrogant here, and it's not M$.
...how many here still haven't gotten through the termination shock of Star Trek Voyager?
...is to have everyone assume that you were able to create this great original application because you have Asperger's, as opposed to crediting your creativity or perseverence.
More info, and the complete manuscript, can be found here. Be sure to check out chapter 34, which is the computer-generated one.
Solo Han writes: ...pr0n...
Suitable nickname you have...
Q. What's the difference between a rooster and a lawyer?
A. The rooster clucks defiance.
Competitors should design their products to accept any properly formatted database file of players and stats.
This would allow you to enter in your child's own Pop Warner teams to play against each other.
Of course, there's always a chance that some naughty person might start spreading around a database listing all the real NFL players.
That would certainly be tragic. But it's a risk we might have to take.
A little narrative to go with your pictures -- check out this gripping account of this very earthquake by author Jack London (of Call Of The Wild fame).
Ken Jennings was that annoying kid from the old Encyclopedia Britannica commercials.
Jesus, the democratic process doesn't allow for "the most important election", it allows for "ELECTIONS" in general.
Maybe we should have a vote, to see which election was the most important.
> Linus Torvalds (pronounced LEE-nus)
Hmm, does that mean Linux should be pronounced LEE-nux?