Firehed

And ding your credit history? No thanks.

I would definitely charge back every unauthorized charge they make, and charge it back again if they fight it and win (yes, you can do this, and yes, it does work). It's not worth their time to fight small chargebacks at all[1], and the damage multiple chargebacks can do for even relatively large payments often makes it not worth going through multiple rounds.

Although at that point, I'd consider simply reporting the card as stolen. In effect, at that point it is. Once the PAN is marked as invalid by the issuing bank, those recurring charges should definitely not be able to go through (exception: some sort of wacky bill-pay system that bypasses the credit networks entirely; yes, these exist, although normally go the other way)

[1] As a merchant, your chargeback rate is unaffected by winning chargebacks, and the fee (typically starting at $15, and often marked up) is per-incident. Meaning if the customer fights the charge a second time after you win the chargeback, you're out $30 and now have two chargebacks in your history, not just one. Between the hard costs and whatever the human factor is in fighting the charges, it quickly becomes non-economical to fight them.

Is it unreasonable? I'd recommend Hover too, and also would have used my affiliate link. If I didn't have one I'd still happily recommend them, but if it doesn't cost you anything why shouldn't I get a cut? That's kind of the point of affiliate codes.

Gearman is pretty solid once you have it working, but it can be a huge pain to get to that point. We spent probably two years (on-and-off, of course) tweaking code to get our framework talking nicely to gearman. PHP's gearman-manager library is a little... wonky, and we were seeing no shortage of bizarre APC interference.

Although in this case, I imagine the real problem is portability. Curl is available pretty much everywhere. exec (or more directly, pcntl/posix extensions) aren't in any out-of-the-box installation, and anything that needs to be further daemonized to get up and running (such as gearmand and gearman-manager) are even harder to use in a one-click solution.

People questioned and attacked his intelligence because of his actions, not because of his race and/or gender. I'd suggest that people who want to attack someone for whatever reason will go after low-hanging fruit (being some sort of statistical outlier), and should that not exist they'll have to go after something of actual substance. When your goal is belittling someone, an attack that requires people to actually think tends not to be terribly effective.

And contrary to your suggestion, I've certainly received plenty of harassment based on my body as a white male. Less these days as I refuse to work with people who can't act like adults, but I've taken plenty of crap about my height and physical appearance (I'm 25; lots of "oh, when do you finish high school?" kind of stuff)

I imagine most developers can tell the difference between 'pursuing' and 'stalking'.

Being confrontational also brings the issue to light and may take us one step closer to solving the problem. Simply ignoring the matter (as uncomfortable as it would be to deal with both as a victim and as someone who doesn't want to put their company in a bad light; I can only imagine) quietly indicates that we're ok with this kind of behavior.

I suppose this is one of those "there's a time and place" issues. I wouldn't likely call out such an asshole while I'm on stage (unless this person tried to humiliate me while I was presenting, in which case I'd simply state that's not an appropriate comment for the conference and move on to the next person), but I'd certainly escalate[1] the issue privately.

We need to look into some sort of zero-tolerance[2] policies for this kind of thing until the message that this isn't okay is clearly understood. Certainly if I'm hosting or attending a conference and witness this kind of behavior, I'll be going out of my way to get this person removed from the conference and will also bring it up with their employer.

[1] In the "I'd like to speak with a manager" sense, not throwing a loud tantrum. [2] Not that I generally support zero-tolerance policies, or find them effective. But I think the concept is directionally correct; any attendee making another attendee (including speakers) feel uncomfortable or unsafe should be removed form the event. Maybe they get one strict warning; it depends how obviously offensive they were being.

Are you writing this for yourself or to share? If the latter, optimize readability for people who don't understand regexes.

As for commenting the end of loops - that too just improves readability, especially in long functions. If your editor doesn't show invisible characters, it can be easy to lose track if some indent is part of the 'i' loop or the 'j' loop, for example (yes, that can indicate a bigger problem, but that's not the point. I'm talking about real-world code, not idealistic academic nonsense)

$3000 is quite low in my experience (depends on your processing volume; I've seen high tens to mid hundreds of thousands of dollars) - although reserves typically aren't applied as 100% of your transactions until you meet them. Normally it's filled slowly over time, say 1-5% per transaction until the reserve is met.

Moreover, you generally won't get it back until several months after you stop processing, since that's when the real risk of chargebacks goes away. Depending on your contracts and agreements, the timeframe can change significantly, including having several smaller payouts.

I skimmed the PDF and didn't see what you're referring to; however, I did see it explicitly point out the ineffectiveness of "security" questions.

It's a trade off between that and allowing some random stranger to transfer your money if you get up and forget to lock your computer. Our first alpha didn't have the auto-logout and by far the most common piece of feedback we got was that we needed it.

Why have speed limits at all then? I've heard anecdotes of professional drivers getting out of massive speeding tickets because they know how to handle a vehicle at that speed (and presumably had the good sense not to be driving way faster than traffic if there even was any) and its certainly possible to get a speeding ticket when traveling under the limit if conditions do not permit.

Seems to me that they should be treated as good-weather guidelines (legally; that's already more or less the case in practice), and focus on the people driving recklessly - weaving in and out of traffic, going 10mph+ faster than everyone else, tailgating, etc.

Uh, no - this is more of a "don't execute code in a textbox" thing.

Likewise.

I got a similar message several months back, but that wasn't part of a larger leak; apparently some website I'd used a while ago had been compromised and I was using my throwaway password on Twitter at the time. Suffice to say, it's using a real one now - fifty-some-odd characters of random garbage generated and stored by 1Password. It's never been used anywhere else, so getting this email a second time just now was quite a shock (this time, my reaction was "really guys, again?" rather than "wtf?")

To their credit, they caught the first instance crazy-fast (my password had been reset automatically within about five mintes of a rogue tweet, though not before a friend texted me about it). This time I didn't see any activity at all, so I assume it was more proactive.

I'd still like an MFA option, especially with how infrequently I actually log in to twitter. However, I do like the "check your OAuth grants" page you're taken to after changing your password.

My understanding is that ntpd corrects clock drift by replaying milliseconds consecutively, not by actually jumping back.

However I can't remember where I read that and could be totally wrong.