129 karma · joined June 3, 2012
Got out, had no way to get back to our truck, nor to our house an hour outside Austin. Called Uber, figuring we'd at least get a ride back to the truck to get our stuff, and see if any friends could take us the rest of the way home.
Despite nothing going on in town that night, and only being about 8:30pm, the app warned me of surge pricing, saying it would be 1.5x the usual fare. Didn't have many other options, and had been happy with Uber in the past, so went ahead.
Driver was cool, and not only took us back to the truck, but drove us all the way home, complete with a flat tire we helped him change on the side of a busy, dark toll road, and running out of gas.
Wound up being $98, and that guy really earned his tip. I still wonder if the fact that we called from the exit of the ER triggered surge pricing, though. Not a great time to experiment, but I could've probably walked a few blocks and tried again, if my wife wasn't in the shape she was in at the time.
They may be valued at $1B+, but they're not worth that much.
I just use timestamps for when the migration was created, like 201509010034, and for the most part, things are great. Until we got a high priority ticket, and a migration with a later timestamp got pushed ahead of an earlier one, so it never gave us the option to migrate the earlier one.
Easy fix was just to update the timestamp of the earlier migration when it finally got through QA, since they weren't dependent on each other, but things could've gotten really messy, so I'm not 100% happy with the way migrations currently work.
That one pissed me off enough to ask for a supervisor, which caused the guy to immediately hang up.
"What if we invest in training and our employees leave?"
"What if we don't, and they stay?"
PasswordA SomeOtherPassword1 PasswordB SomeOtherPassword2 PasswordC SomeOtherPassword3
Just iterate on every other change, and you've beaten the requirement.
For the second, I'd probably just do something like compute the Levenshtein distance between the username and password, and reject it if it passed some threshold.
They wanted at least 10 characters, and at least one uppercase, one lower, one digit, and one special character. Easy enough with .NET's built-in membership stuff by setting:
passwordStrengthRegularExpression="(?=.{10,})(?=(.\p{Lu}){1,})(?=(.\d){1,})(?=(.*\W){1,})"
The "\p{Lu}" part handles uppercase characters even in Unicode chars, but Javascript has no equivalent, so I couldn't do client-side validation of that. Should be validating on both ends anyway, but it's still a pain.
The real part I hated was having to keep track of users' last N passwords to make sure they didn't re-use them. Since everything's hashed and salted, I just kept a table of previous hashes by user. Seems simple, but MS didn't see fit to include a HashPassword(string plainTextPassword, byte[] userSalt) method in the membership provider, so I had to reverse engineer their password-hashing method to check when they change passwords if it's something that's been used before.
Then I realized that they could just change their password N+1 times in about a minute, then re-use their expired password anyway, so we wound up having to set a minimum age of N weeks before a password could be reused as well.
The whole problem is an exploding requirements nightmare that could easily be solved by saying "Must be >32 characters and don't write it down anywhere, idiot."
The worst part is as much as I hate these types of requirements, I now perfectly understand why these systems are the way that they are.
All of them were offers from realtors wanting to re-list our house and try to sell it, and it wasn't until I got two identical letters, in identical handwriting, from two separate realtors, that I realized they were computer-generated.
"Women" doesn't mean "white women", and as Haul4ss pointed out, all women won the right to vote in the U.S. years after minority men did.