Rants, musings, and [sometimes] useful articles from Greg Taylor.
Rants, musing, and [sometimes] helpful stuff
PyATL is having a Jam Session this Tuesday at 7PM, for those inthe area and interested. In addition to a presentations for getting started with a few web frameworks (Django, Bottle), there will be some hackage on various projects. I’ll be there, looking to help people with, or work on boto.
If you’re interested in coming, RSVP on the Meetup page. If you’re wanting to hack on, or get help with boto, shoot a tweet at me and let me know so I can be ready for you.
To top January up, boto 2.2.0 has been released, bringing in, amongstother things, DynamoDB support. See the full release notes for the nitty-gritty. Feedback is actively being sought for the DynamoDB module, so please do open an issue on the tracker if you run into issues or have suggestions.
Also, we’re making a ton of progress on the documentation front. If you’d like to help, check out the documentation issues in the tracker, and/or hop in #boto in FreeNode. We’re in need of people familiar with various boto sub-modules to step up and contribute their knowledge, or give their respective module’s tutorials/api references some love.
There has been a good deal of progress made towards getting boto’sdocumentation up to snuff. We’ve been working on cleaning up what is there, and have even added some new content (like the new DynamoDB tutorial). However, there is much left to be done.
We would greatly appreciate some outside eyes on this. We’d love to see what you think we could do to improve the boto documentation. Please feel free to visit the boto issue tracker and fire away. If you mention @gtaylor in the body of your issue, I’ll be sure to get it, and can label and route it.
If you’re feeling particularly motivated, we’d love to have your pull requests. The boto documentation is all in reStructuredText, compiled by the excellent Sphinx. You can expect to be reasonably productive with about 30 minutes of peeking at the Sphinx documentation and looking at what we have.
In particular, we need tutorials covering some of the modules we lack tutorials for. If you know any of these modules pretty well, please consider throwing something our way.
On a post in the Amazon Web Services blog yesterday, AWS hasannounced that it has brought Mitch Garnaat (maintainer of the excellent Boto) on board:
[…] Building on this model, Mitch Garnaat has also joined the team. Mitch has been a member of the AWS community for over 6 years and has made over 2,000 posts to the AWS Developer Forums. He is also the author of boto, the most popular third-party library for accessing AWS, and of the Python and AWS Cookbook.
Great news, but what are they going to do with Mitch, and what will his involvement with Boto be?
Boto will continue to exist as an open source project and we will be making official contributions to it.
They go on to list a few related job openings, one of which is a Python engineer (AWS Developer Resources). This looks, to me, like a great “official” endorsement of Boto and Python. As someone who uses Boto (and Python) extensively for work and play, this looks exciting.
A big congratulations goes out to Mitch, for nabbing a great job, and for being able to work on Boto within Amazon directly.
A recent backwards-incompatible change to the PayPal Adaptive API led toour web application being unable to accept new users for about five days a while back. We were getting a very vague “Session has expired” error, and PayPal support couldn’t figure out what was wrong. Nothing in that section of the codebase had changed for months, the breakage randomly started.
It ended up being that a recent PayPal API update had made a previously optional field required, and they only updated their PDF documentation (I use their HTML docs). There was no communication of the change in requirements leading up to the breakage, and we were alerted to the issue by frustrated customers calling support (instead of PayPal).
This was the second such breakage during our year or so of using PayPal’s Adaptive API. Granted, we use some of their more advanced split payments and invoicing features, this should not happen. Additionally, we weren’t happy with the user experience during checkout, which featured:
A combination of being unhappy with customer support and the disruption of our checkout process with redirects led to us searching for alternatives.
Initially, we looked at other similar (but more simple) services. WePay was at the top of our list. This is a young but promising service that makes collecting payments much easier than PayPal. They have a Python API (that we contributed some to), and good documentation. However, they still needed us to redirect our customer to WePay’s site, which ultimately led to their being scratched from the list.
We investigated some traditional payment processors like Braintree and Authorize.net, and while they looked like great services, we needed our customers (schools and businesses) to be able to get set up to receive payments quickly. A lot of traditional gateways have long, complicated setup processes, often involving sales calls and working with banks. Each of our customers would have had to go through this process, which would have presented a huge barrier in the setup process. They also typically require you to send credit card data through your servers, which means obtaining a level of PCI Compliance (not that we aren’t already security-conscious).
Another service we had heard great things about was Stripe. Like WePay, Stripe is a relatively new service, but has backing from former PayPal execs, along with some other great names. Diving in to figure out what the excitement about, we weren’t disappointed.
The refreshing thing about Stripe is that they weren’t afraid to break convention. Instead of redirecting customers to Stripe, or sending their credit card data to their servers from ours (which you can still do if you want), they wrote a nifty bit of javascript called stripe.js. This little guy sends credit card data from a form on your site directly to Stripe’s servers (over SSL), which returns a unique token for that credit card. Said token is then submitted to your server via GET/POST/whatever, and your server uses the token instead of the user’s credit card number.
No redirects are necessary, we avoid having to hassle with monetary and time expense of PCI compliance, and the checkout experience is seamless for our user. We condensed everything down to one click of a button, staying 100% on our branded site.
The other thing that really shocked us after dealing with PayPal is Stripe’s customer support. We navigated to their support page to see where we could ask some questions early in the process. Imagine our shock when we saw a Campfire chatroom linked there. I cautiously entered the room, not sure what to expect. As the room loaded and I listened in on conversations, I realized that this chatroom has the Stripe developers in it, as well as the business-oriented staff.
Encouraged, I started my deluge of questions to determine whether Stripe would be an option for us. The Stripe staff answered everything consistently, thoroughly, and quickly. I stopped by a good number of times during the two weeks we were researching alternatives, and they were patient every time.
Let’s contrast this to our PayPal setup process during our early development:
And then our more recent complete service outage:
PayPal’s mindshare and feature list are huge, but support is such a critical consideration. If we had been in anything but our current closed beta state, this would have been a major catastrophe.
Another handy tidbit is that Stripe does have an officially maintained and supported Python library, stripe-python. You can talk to the same developers who maintain this in the aforementiponed Campfire chatroom, as well.
I’m going to get on my podium here for a second, so feel free to navigate somewhere else if this kind of thing bothers you.
A year ago, I usually brushed most harsh criticism of PayPal off. They had been good enough for my personal and professional use. We didn’t really have any reason to deal with their support before our current project, so it was a nice, cozy, detached relationship.
Dealing with their signup process, and later having to deal with their awful support during a service interruption soured me to them quite a bit. Hearing about how they have increasingly taken to freezing accounts for silly reasons has made the negative light I view them in even more intense.
Do consider alternatives before taking your business to this bloated, slow, and unsupportive behemoth. The small guys are going to want your business more, and do more to keep it. Few can go toe-to-toe with PayPal on a per-feature basis, but rarely do you use even the majority of the feature set.
Rants, musings, and [sometimes] informative stuff from Greg Taylor.
