Recently, at a Ruby conference, there was a presentation that was none too considerate to women in our trade. Much has been said and written about this incident. The most troubling aspects are that (1) the presenter (who I shall not name so as to continue to give him undeserved hits on his blog) continues to rationalize his offense as a non-offense and (2) that some “leaders” in our community, DHH among them, are telling us that we need to grow up and accept that this is the way of things.
I have written several twitters on this matter over the past week but it was Nick Sieger’s call to arms that finally convinced me to make myself heard more publicly. That and this reminder of a discussion that I had with Bryan Liles while at Ruby DCamp last year.
As a Jew, I learned early in life that evil must be met with action and wisdom. When ignored, evil grows a little stronger, encouraged by its new found boundaries. Ignorance and bigotry are evils. It is the obligation of every individual to nonviolently confront these evils, in their many forms, wherever they should appear.
However, DHH, and others, have made it de rigeur in at least the Rails community to be a profane insensitive hipster.
What is society? Among other things, it is an unspoken contract among people to live and let live. Yes, we all have the right to say or do as we please. However, in so doing, there are consequences. In society, when the peace is disturbed, justice is meted out by society. However, DHH’s cavalier attitude toward civility stands in direct opposition to society: a great big…
When those who would presume to be our leaders attempt to lead us down the wrong path, it is our responsibility to pick the right path despite them and find new leaders.
How do we get better? Simple: be professional, be sincere within reason yet polite, and, for crying out loud, have a care for the other guy.
Do not be casually indifferent to ignorance and bigotry.
Do not support ignorant or bigoted perspectives.
Ignore our “leaders”. You have a right to be offended.
Posted by evan on Apr 30, 2009
Recently, I had the opportunity to write a full green-field eCommerce implementation. I was, at the time, very excited! I had never done so before and believed that it would prove challenging.
I had no idea how true that would prove to be–and for all of the wrong reasons.
We chose Authorize.Net as our vendor because it seemed to best meet our requirements and ActiveMerchant as our preferred route to interact with the Authorize.Net Payment Gateway.
The first sign of trouble came when I made a support phone call to Authorize.Net asking them about their test environment for their recurring billing API. The customer service representative insisted that (1) the recurring billing API (known as “ARB”) is not actually an API and (2) as such, test environment support for it is minimal. When I say “minimal” I mean that most of the time it would acknowledge a request had been sent to it – and I say “most” specifically because our integration tests to this day still sporadically fail because of a connectivity issue to their test environment. When we asked about more support, we, quite literally, received a tone from the representative that made plain how little the customer service person was interested in providing us with good service.
Despite the customer service representative’s insistence that their so-called non-API API (if I can invoke it remotely, you tell me on or more URLs to use to communicate with it, they all take XML data and return data in XML, then it’s an API) test environment does not perform any validation, I found that the ARB test environment in fact seemed to perform some small modicum of validation of test credit card data supplied to it. Cool! It’s not necessarily the most performant way to validate a credit card but, at least initially, it saves some time, right? Therefore, my implementation expected that same behavior from their production environment.
How foolish of me to assume consistency…
As soon as I began integrating my code against their production system, many problems appeared:
When a user attempts to create a recurring payment (i.e., a “subscription”), validations performed by the test environment are not performed in the production environment. Therefore, the credit card data that we supplied to the production environment was entirely unvalidated.
Authorize.Net does not provide a way to attempt to re-bill a failed payment. It would be a simple matter to provide another API call to ask the recurring payment system to attempt to re-bill the latest failed charge. When I spoke to their customer support about this, they said that they thought that this sounded like a useful feature. Duh. Instead, you have to use another interface, the so-called Merchant Integration interface (AIM), to perform an authorize and capture operation immediately to bill the user. Thanks, Authorize, for making still more work for me that you could have fairly easily automated.
Authorize.Net also provides a simple shared-key encrypted method for POSTing to an application real-time information about payment successes and failures. The API that they expect is even reasonably well documented (I believe… but I’ll know full well shortly when Authorize.Net actually begins to use it). However, they don’t provide a test consumer of the API! Of course, being a good BDDer, I rolled my own. That still doesn’t give me the least bit of assurance that they actually implement to their own API.
Because, in the ARB guide, on page 13, they claim that you can update a customer’s subscription start date so long as the customer has yet to make a single payment. Guess what? Complete and utter bullshit. That’s right. Can’t be done. But their documentation says that it can.
ActiveMerchant itself actually got in the way. By attempting to provide a payment gateway-agnostic interface for speaking eCommerce, ActiveMerchant had to attempt to map all of Authorize.Net’s arcane arguments and return values to its own API. Essentially, ActiveMerchant attempts to fit a square peg into a round hole. After a couple of months of using both, had I to do it again, with Authorize.Net, I would have written my own Authorize.Net-specific abstraction layer to marshal and unmarshal their XML data into Ruby objects. ActiveMerchant, ultimately, proved to be a net loss for me.
In conclusion, given the bevy of eCommerce gateways out there, I would never ever recommend Authorize.Net to anyone. As far as I can tell, they basically hate eCommerce. Just don’t use it. Please. For the sake of whatever higher power you may believe in. Don’t.
Update 4/30/09: Add to my list of grievances that, should you have a technical question regarding integrating with Authorize.Net, your only recourse is to mail the developers at Cybersource, the parent company, who tend to have a turnaround time of approximately 24 hours. All of this while you could conceivably losing money!
Of the customer service representatives that I have dealt with at Authorize.Net, approximately half have been between rude or grossly incompetent. My second-most-recent (I called a second time today simply because this guy was so awful) would listen to what I said, type something, and then several seconds to a minute later ask a question. He was having more dialog with his keybaord than me!
Posted by evan on Apr 24, 2009