PragDave

Why We Don't Take American Express

When we first started taking credit cards, we had a menu of options. We chose to take Visa, Mastercard, and Discover. But I’d heard some merchants saying American Express were difficult to deal with, so we chose not to accept their card.

Folks have been asking us about this, so I recently went through the paperwork and signed up to become an American Express merchant. We were accepted, and everything seemed fine. Then, on the same day we received our agreement, we got a second letter, unilaterally amending that agreement. It said “if any customer disputes a Charge at your establishment claiming the transaction was fraudulent, American Express will immediately chargeback your merchant account for the full amount of the Disputed Charge without contacting your or sending you an inquiry. You will not have the opportunity to present any written substantive response to Disputed Charges…”.

We’ve never had anyone claim a fraudulent transaction against us, but we understand that cards can get stolen. We work hard with the card companies to help whenever a transaction is queried. But think about what American Express is saying.

If someone believes a transaction is fraudulent, then clearly they have a right to get their card credited immediately. That’s how all the card companies work, and we support it 100%. But then the other companies contact us and say “so-and-so says this. Do you have any records that will help in the invesigation?” We work with them to resolve the situation. By doing so, everyone benefits.

Not so with American Express. If someone makes a claim, not only do we not get told about it, but we have no ability to add any information to the situation. Everyone suffers, because no one can determine what really happened. We end up with a fraudulent transaction on our record. And we have no ability to correct the situation.

Visa and Mastercard are a pain to deal with. That’s as it should be. They want to protect the consumer. So do we. And that protection comes from transparency and the exchange of information. American Express doesn’t seem to be bothered with these details.

I spoke with managers there today. Because we don’t have a store front, they aren’t prepared to drop the clause. Instead, I dropped the card.

Second Friday: Google Maps API

Another diversion for Thanksgiving. I don't know about you, but I tend to collect a backlog of fun things I mean to play with. And Thanksgiving's a good time to work through some of these. High on my list is experimenting with the Google Maps API.

Scott Davis has produced a wonderful (and concise) guide to all aspects of the API, showing how to add mapping and geocoded data to your web site. Check out our latest Pragmatic Friday, Google Maps API, and whip up the next killer web app between the turkey and the game.

Weighty Matters

A link on digg gets us to a page about Germany’s new Water Bridge, an impressive aquaduct.

So, today’s Thanksgiving dinner question: what happens to the load on the bridge’s supporting columns as traffic enters an empty bridge? Do they feel additional weight? Does the load on them stay the same? (Please don’t e-mail me: just a question to get the family thinking.)

The First Rails Studio

It was an intense three days, but it's over! We just finished the very first Rails Studio in sunny (if chilly) Reston, VA. The site couldn't have been better. FGM, Inc hosted us, and they did us proud. The meeting room was great (it even had windows :), and they laid on a network and plenty of power (we were initially surprised at how many folks came with laptops, but FGM came to the rescue with additional power strips and we just squeaked by).

The course itself seemed to go really well. We learned a lot along the way (Dave now knows not to start a new topic and delay lunch). We also adapted the presentation style as we proceeded based on the prior day's feedback. This lead to probably the biggest overall lesson learned. We originally had people coding along with us as we developed our Rails application, but at some point or other just about everyone went down a rabbit hole and had a hard time catching back up. Next time we'll have checkpoint versions of the application available so everyone can sync back up before we move on to the next topic.

I think everyone came away having picked up a lot about Rails coding (not to mention the “I'd Rather Be on Rails” bumper sticker and the exclusive Golden Spike T-Shirt). On the final day, everyone coded their own Rails application—some of these had components and Ajax support!

We'll be announcing the next studio shortly: we're probably looking at the west coast next, with a possible return to the east coast shortly thereafter. In the meantime, there's a bunch of pictures up on flickr which give a pretty good idea of the fun atmosphere.

Thank you, golden spike members, for coming along and making this a success...

Symbol#to_proc

The Ruby Extensions Project contains an absolutely wonderful hack. Say you want to convert an array of strings to uppercase. You could write

  result = names.map {|name| name.upcase}

Fairly concise, right? Return a new array where each element is the corresponding element in the original, converted to uppercase. But if you include the Symbol extension from the Ruby Extensions Project, you could instead write

  result = names.map(&:upcase)

Now that’s concise: apply the upcase method to each element of names. So, how does it work?

It relies on Ruby doing some dynamic type conversion. Let’s start at the top.

When you say names.map(&xxx), you’re telling Ruby to pass the Proc object in xxx to map as a block. If xxx isn’t already a Proc object, Ruby tries to coerce it into one by sending it a to_proc message.

Now :upcase isn’t a Proc object—it’s a symbol. So when Ruby sees names.map(&:upcase), the first thing it does is try to convert the Symbol :upcase into a Proc by calling to_proc. And, by an incredible coincidence, the extension project has defined a to_proc method for class Symbol. It looks like this:

    def to_proc
      proc { |obj, *args| obj.send(self, *args) }
    end

It creates a Proc which, when called on an object, sends that object the symbol itself. So, when names.map(&:upcase) starts to iterate over the strings in names, it’ll call the block, passing in the first name and invoking its upcase method.

It’s an incredibly elegant use of coercion and of closures.

Enterprise Integration with Ruby goes Beta

Maik Schmidt's writing a wonderful book on using Ruby to knit together real-world enterprise applications. He's making a really good case for using Ruby to speed the creation of new enterprise functionality by gluing together all the existing enterprise applications and data using Ruby's power with XML, databases, directory services, and web services. I certainly learned a bunch while reading it. And yesterday, it launched as a beta book.