It's really more like this version of the image: http://i.imgur.com/DqKXPF3.png
2,041 karma · joined November 29, 2010
No, money wasn't being stolen, but the validation error meant that clients' money was being spent and not being tracked. The company had to eat the costs.
Liberals tend to favor equality of outcome while conservatives tend to favor equality of opportunity.
These kinds of diversity reports usually show that "white people are overrepresented" and "hispanic and black people are underrepresented". They usually do not mention that asians are GROSSLY overrepresented. It doesn't fit the agenda because, despite being the most successful ethnic group in the US in terms of income, they are not considered "powerful".
>Suggestions welcome.
Keep looking for a new job. I guarantee this is the tip of the nightmare iceberg you're about to hit.
I hope I am wrong, but I've seen this enough times before to know that I'm probably not.
$50,000/day is an expensive lesson!
The most ridiculous one I've seen was "dragon slayer".
It's sadly safer to just not reject candidates at all. Don't hate the player, hate the game.
Just remember that the port argument to `scp` is -P and not -p like it is for `ssh`. :p
His official Twitter account said he'll be signing it: https://twitter.com/POTUS/status/605841647193030657
Maxmind - good. Not like there's many choices here, though. :)
Instead of "waking up to sync logs", consider using something like NSQ to emit events as they happen. You can scale the number of servers/processes generating messages and the number of workers consuming those messages (and committing them to your database) very easily.
You could also replace the writing of the transaction log with a NSQ event. It lets you avoid having to write and scale the log shipping stuff.
We precalculated which ads a given user was eligible for and a separate process was contacted when a bid request came in to get the info for the ad to show. We never had to do anything funky to do geotargeting exclusion at scale.
Instead of having your adserver connect to a database, have a separate process generate a working set (as JSON or whatever you fancy), compress it, and ship it to the adserver periodically. The adserver can just do a straight load from the file every minute or whatever interval you'd like. If the file's mtime is too old, raise an alert and stop serving ads if necessary. Keeping things separate and simple lets you scale more simply. Our working sets were on average about 2gb uncompressed and they could be loaded in a few seconds (C++/JSON and later Go + JSON).
Seems like it was a fun project and I hope you learned a lot!
We didn't use anycast, though. I suggested it to our CTO many times and it would have saved us over $5,000/mo in DNS costs, but it never got done.