Given he's not interested in security but uniqueness, a Rabin Fingerprint would be both faster and better for this purpose than any of the security hashes.
May as well compare the first 8 bytes, you can do that in a single instruction, and the cost to read 8 should be the same as 4. If you're clever enough you can probably do a 32 byte comparison in a single op.
I find it odd that in your discussion of programming tests your examples are all DBA oriented.
Programming tests are most useful for weeding out the large numbers of incompetent candidates. The incompetent candidate can't finish in the time allowed, and their code is often an obvious mess. A competent candidate breezes through it, their code is well organized and readable. A rockstar finishes the 45 minute interview problem after 10 minutes, and his solution covers all the edge cases it took you a year of familiarity with the problem to discover.
The problem of course is that it takes a rockstar manager to tell the two apart BEFORE the project falls apart during the maintenance years. And rockstar managers are rarer than rockstar programmers.
Yeah, my point was only that traditional client server typically didn't have failover, particularly not geographically dispersed failover in case of local things like earthquake or hurricane (client server failover would have meant 'within the building'), whereas I think that's an essential part of what cloud is really supposed to mean.
If you want to have a yacht, that takes a certain amount of mass for the boat, and a certain volume of ocean to sail it on. There isn't enough mass on earth to provide that lifestyle to the majority. And that's just for that aspect of being wealthy. The list of things not everyone can have goes on and on.
If you're talking what most people would consider 'true' cloud computing, it's client server with transparent failover redundancy with backup nodes in geographically dispersed regions.
I'd definitely agree it's not for everyone or every team, or every project. It's really a technique that should be used only where a low bug rate / high quality is near the top of the list of requirements. If you aren't getting the long-term maintenance cost reduction, there's no point in paying the upfront price.
That's not a realistic worry. The gargantuan share of all trips is people to the office or stores. All of these cars are going to be sufficiently large to make all of those trips without need for repetition.
#2 is considered one of the main benefits of pair programming. You're making the other coder better, and the value of having two good programmers on staff in the long run is much more valuable than the delta in productivity due to pairing.
We make enterprise software for fortune 500 insurance companies using agile and pair programming, and we've delivered new versions year after year for a decade now.
Code reviews are out of context. By the time you execute one, the cost to make a change is potentially very high, and will incur resistance (/the temptation not to fix something because of the high cost of doing so). Pair programming catches those same issues at the time they are created, and offers the opportunity to fix said problems at a much lower cost. Code reviews also deal with a potentially unmanageably large batch of code. The reviewer can get tired, lose focus, etc, particularly since he's not invested in the development of the code.
Bottom line, there are all kinds of human factors going on there that 'be disciplined' can only fight to a minimal extent.
No, implying that useful capital requires a minimum number of atoms to provide said lifestyle. There aren't enough atoms, no matter how you arrange them.
Slashdot Mirror
Given he's not interested in security but uniqueness, a Rabin Fingerprint would be both faster and better for this purpose than any of the security hashes.
May as well compare the first 8 bytes, you can do that in a single instruction, and the cost to read 8 should be the same as 4. If you're clever enough you can probably do a 32 byte comparison in a single op.
$19.95 for a beta of something you can whip up in an hour of shell scripting.
If the poster were you, they wouldn't have had to 'ask slashdot'.
I find it odd that in your discussion of programming tests your examples are all DBA oriented.
Programming tests are most useful for weeding out the large numbers of incompetent candidates. The incompetent candidate can't finish in the time allowed, and their code is often an obvious mess. A competent candidate breezes through it, their code is well organized and readable. A rockstar finishes the 45 minute interview problem after 10 minutes, and his solution covers all the edge cases it took you a year of familiarity with the problem to discover.
The problem of course is that it takes a rockstar manager to tell the two apart BEFORE the project falls apart during the maintenance years. And rockstar managers are rarer than rockstar programmers.
Yeah, my point was only that traditional client server typically didn't have failover, particularly not geographically dispersed failover in case of local things like earthquake or hurricane (client server failover would have meant 'within the building'), whereas I think that's an essential part of what cloud is really supposed to mean.
If you want to have a yacht, that takes a certain amount of mass for the boat, and a certain volume of ocean to sail it on. There isn't enough mass on earth to provide that lifestyle to the majority. And that's just for that aspect of being wealthy. The list of things not everyone can have goes on and on.
If you're talking what most people would consider 'true' cloud computing, it's client server with transparent failover redundancy with backup nodes in geographically dispersed regions.
Cloud computing is most definitely affected by the weather. Rain, lightning, and hurricanes can all easily cause outages.
I'd definitely agree it's not for everyone or every team, or every project. It's really a technique that should be used only where a low bug rate / high quality is near the top of the list of requirements. If you aren't getting the long-term maintenance cost reduction, there's no point in paying the upfront price.
Double-woosh!
That's exactly my point.
It also appears to be true for two highly skilled coders, and one skilled and one mediocre.
That's not a realistic worry. The gargantuan share of all trips is people to the office or stores. All of these cars are going to be sufficiently large to make all of those trips without need for repetition.
It's always the fittest who survive, you're just unhappy about who that turns out to be.
People do this. Most management decisions at my company are made with at least two, if not more, managers involved.
#2 is considered one of the main benefits of pair programming. You're making the other coder better, and the value of having two good programmers on staff in the long run is much more valuable than the delta in productivity due to pairing.
We make enterprise software for fortune 500 insurance companies using agile and pair programming, and we've delivered new versions year after year for a decade now.
Go google human centipede. I assume you just didn't get the reference.
Code reviews are out of context. By the time you execute one, the cost to make a change is potentially very high, and will incur resistance (/the temptation not to fix something because of the high cost of doing so). Pair programming catches those same issues at the time they are created, and offers the opportunity to fix said problems at a much lower cost. Code reviews also deal with a potentially unmanageably large batch of code. The reviewer can get tired, lose focus, etc, particularly since he's not invested in the development of the code.
Bottom line, there are all kinds of human factors going on there that 'be disciplined' can only fight to a minimal extent.
If you can make those decisions at design time, it's time to write a code generator.
As is getting pointed out all over the place, XP is more than just PP.
Seems like for work that you just need to knock out, you might be even better off offshoring, or at least hiring new grads instead of seniors.
I'd be very curious to know how you're measuring productivity. Our experience has been that pairing results in more than 200% productivity.
(For our definition of productivity, which includes the long-term maintenance effort on the resulting code).
No, implying that useful capital requires a minimum number of atoms to provide said lifestyle. There aren't enough atoms, no matter how you arrange them.
That's only because the brain doesn't remain pliable, and we're closing in on understanding how to fix that.