January 19, 2012 § Leave a comment
PayPal can be a pain in the butt to integrate in with your website. I sit next the guy on our team tasked with doing PayPal integration. I swear I can see the wrinkles and gray hair starting in on him. One of the biggest pains you’ll run into is testing the callbacks and web hooks. If you are doing anything more than putting a little donate button on you site, you’ll be dealing with IPN callbacks to keep your database in sync with PayPal. Typically your doing your development on a local machine that isn’t exposed to the outside world so you can’t have them post directly your dev machine. Bummer. There are a number of ways one can go about dealing with, I’ll mention two that we have tried before we found the third.
Test it on Prod
Nothing ever goes wrong when you do this right? A better solution here is to set up a separate staging machine that is hooked up to the PayPal sandbox, but setting up boxes just to do some sporadic testing really sucks. What if there was a service you could just point PayPal at to and just showed you what PayPal was posting, would that be better?
postbin.org is a nice little service that provides web hook endpoints. It’ll give you a url to give PayPal as a callback url. When PayPal post to this url you’ll be able to inspect the request it sends. Unfortunately you’ll then have to manually parse it and figure out a way to post that info locally on your machine. But hey, no extra machines floating around in your cloud just wasting space and money! But there still has to be a better way to do this. I really would rather all of this just go to my local dev machine. Please tell me this can be done!
Enter localtunnel. localtunnel is a ruby gem that does what the name implies. It hooks your local server up to the world wide web by tunneling to a subdomain of localtunnel.com. You simply install and run the gem giving it your public key and a port and BOOM.
http://as2js.localtunnel.com now points to your local dev machine. The PayPal IPN’s can now trigger all that nice sync code you have written.
I am currently working on some GitHub continuous integration web hook stuff, so this tool has been invaluable. Priceless even. The only additional thing I would like to see with this gem would be a way to deploy the server side to your own machine. While localtunnel.com is fine and dandy, I’d feel better if I controlled all the stops of the data. Anyways, get you localtunnel up and you web hooks on!
January 17, 2012 § 2 Comments
I was working on a project a while ago that required the use of custom variable subdomains. If you have ever had to develop a site that used user specified subdomains, you quickly realize that editing your local
/etc/hosts file over and over again sucks. A lot. You end up setting up half a dozen subdomains on a dummy domain that points to
localhost. Not an ideal setup. Thanks to Railscast I tracked down a pretty cool solution to the problem.
The basic idea is to set up a live domain to point
127.0.0.1 and let DNS take care of everything for you. Tim Pope wrote about it nearly two years ago using
smackaho.st. In the Railscast Ryan Bates mentions another domain setup for this,
lvh.me, which was registred by Matthew Hutchinson.
lvh.me do the same thing, just on different domains. And because two isn’t enough, I went and registered
lvho.st and configured it to do the same thing as well. The
lvho.st domain comes from local virtual host, which I took from
lvh.me and the fact that I liked the thought of using a
.st domain like
smackaho.st so I could use
ho.st. Shove the two together and you get
Even though I don’t work with subdomains currently, I still use
lvho.st for local development. Anyways, feel free to use if you have the need.
Interesting side note, this same project is the one that inspired me to write my first ruby gem, tld-cookies. It’s a nice little gem that makes it easy to set a cookie that works across all subdomains instead of just the current one.