As much as I want to defend PHP a bit as a PHP coder who at least _tries_ and is kind of sick of the pile-on (while understanding the rationale), I'm reminded of the thousand odd reasons that PHP sometimes makes me just want to cry into my coffee.
I think it's both bad code and PHP.. specifically bad code written on old versions of php on crap shared hosts where that's the only server-side language available. It should be harder to write insecure code with PHP but it isn't. A language whose entire purpose is to process requests and return content should have security baked into its core. I shouldn't have to wake up one day and find out that "oh, anyone who adds an ?-s flag to their queries can maybe read your source code or whatnot." Now granted, it wasn't that common, but it should never have existed. PHP may not be the great evil some claim it is but there are parts of it that jump out of the dark and bite you, no doubt.
The security vulnerability occurred because of Rails models' mass attribute assignment, which you wouldn't have in a less dynamic language. So yes, that's a problem at least partially attributable to the language.
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)
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.
This all started with the first supplement the FFIEC put out regarding authentication in an internet environment in 2005[1]. This initial supplement was put out to clarify what was expected of banks especially with regards to the FFIEC examination handbooks regarding e-banking[2] and information security[3]. (This all began with 12CFR30B[4][5])
Are you familiar with reading federal regulator-ese? They do not ever come out and make blanket statements such as use XYZ, ensure X bit keys and so on. The entire process is based on the banks and the examiner's interpretation of the bank's risk profile. If you are interested in learning more about this reading some of the banking industry press coverage at the time may be easier to digest.
[5] I say 12cfr30b because that is what got the ball rolling for OCC regulated banks and at the time I worked for an OCC regulated bank. Depending on who the regulator (OTS, NCUA, etc) is the "ball rolling document" will be different.
This is a PHP bug: http://www.networkworld.com/news/2011/010511-php-floating-po...
Everything else? Bad code.