Menu Sidebar
Menu

In defense of fat tools

Rails has this thing called the “flash”. It’s like a special subset of the session hash. It’s a key/value store with an enforced short lifespan. Stuff you put in the hash lasts for exactly one render or redirect, and then goes away. It’s handy for stuff like notifications. You can set it in the controller:

# ...
flash[:notice] = "Your order has been submitted."
# ...

…and then you can reference it in a view:

<div class="notice"><%= flash[:notice] %></div>

You can then be confident that after the view is shown, the message will go away and not be seen again.

Recently on the Ruby Rogues we talked to Michel Martens about keeping libraries small and simple. It was a good show and he had a lot of good things to say. You should give it a listen.

Read More

PayPal wants to know when I stopped beating my customers

First of all I want to say I have amazing customers. Like, seriously fantastic customers who go above and beyond to show their appreciation of what I do for a living. I’ve had people cancel their subscriptions because they needed to focus their finances elsewhere, notice that they still had access to some episodes in iTunes, and email me to let me know that there might be a bug and offering to pay for any extra videos they got to watch as a result of the error. My customers are the best.

So fortunately, I don’t have to resolve many customer complaints. Still, every couple of months I get a notification that someone has disputed a charge. Sometimes it’s an honest mistake; they didn’t realize what the charge was for. In those cases we sort things out and everything’s fine.

But every now and then, someone apparently decides that the best way to cancel their subscription is to dispute a charge, rather than getting in touch with me.

When such a dispute comes through Stripe, it’s not a big deal. They have a perfectly rational dispute resolution process. I try to contact the customer, provide my evidence to Stripe, and wait for a conclusion. Usually the bank decides in the customer’s favor, because that’s how banks are biased. Which is not unreasonable. That’s just part of life for an online seller of products.

With PayPal, it’s a whole different story.

Here’s what I get from PayPal when there’s a dispute:

Selection_101

 

When I log in to “resolve” the dispute, here are the options I’m presented with:

Selection_100

None of these options make any sense in this context.

  • It’s an online video subscription, so there’s no shipping information to be provided.
  • The customer has used their account and watched videos, so the product was “shipped” in that sense.
  • No, I have not refunded the payment. The customer could have cancelled their account at any time. They could have contacted me asking for their account to be cancelled. Instead, they just disputed a charge.

The last time I got one of these notifications I decided to reply directly to it:

Selection_102

 

You can probably guess what happened next: I got an auto-response informing me that the email address they mailed me from is not monitored.

PayPal goes out of their way to be unreachable and to make their “dispute resolution” process opaque and unusable. Their approach toward sellers boils down to the business version of “when did you stop beating your wife?”

And it’s not just disputes. I could provide dozens of other examples of why PayPal makes up 90% of my payment processing headaches.

This is why, despite presently processing thousands of dollars a month through PayPal, I plan on eventually phasing out PayPal completely from my product and subscription sales. They are simply not worth the hassle.

Two years of RubyTapas (free episode!)

It took a tweet from Noel Rappin to remind me, but it seems that today marks two years since the first episode of RubyTapas went live. I started RubyTapas with a simple concept: that Ruby developers might enjoy frequent, short, focused videos on intermediate to advanced Ruby and OO concepts. One new idea, distilled into short enough period to watch during a coffee break.

The other, riskier part of the formula was that developers might value this service enough to pay me $9/month for it in and thus make such a time-intensive product sustainable. Two years and 240 episodes(!) later, it seems they did. At over 2,000 paying subscribers, RubyTapas has been my full-time job for over a year.

So: happy birthday RubyTapas, and thanks to everyone who makes it possible! In honor of the occasion, here’s one of my favorite episodes (#190), now free to watch. It’s about an advanced feature of Ruby’s String#gsub method, and as you’ll see I had some fun making this one.

Also, if you’re not already a subscriber, today you can sign up and get the first two months for the price of one. EDIT: Sorry, this deal is now over!

Older Posts

Virtuous Code

"The three virtues of a programmer: laziness, impatience, and hubris" — Larry Wall

Books and Screencasts

RubyTapas Screencasts

RubyTapas Screencasts

Small plates of gourmet Ruby code.

Confident Ruby

Confident Ruby cover

32 Patterns for joyful coding.

The Making of Cowsays.com

Confident Ruby cover

Watch me build an app in Sinatra and Rails

Objects on Rails

Objects on Rails

A developer notebook on applying classic Object-Oriented principles to Ruby on Rails projects.

Exceptional Ruby

Exceptional Ruby

The definitive guide to exceptions and failure handling in Ruby.

Archives

Categories