Listen in Your Browser
Play this episode directly in your browser — just click the orange “play” button below:
Download this Episode
You can download this episode as a standalone MP3 file. Here’s the link:
Louis: Hello and welcome to another episode of the SitePoint Podcast, my guest on the show today is Ross Boucher; hi, Ross.
Louis: Ross is a web developer; the co-creator of the popular Cappuccino Framework for creating browser based web applications, and is currently working at Stripe. So, do you want to talk a bit about what you’re currently working on, Ross?
Ross: Sure. So I’m working at a company called Stripe, stripe.com, and we are payment processors, so we try to make it easy, as easy as possible to come and signup on our site and be able to start processing credit cards on your own site right away. And at the end of the day like this is kind of similar to what a lot of other people are doing, obviously you can do this with PayPal or a number of other companies, but we think that our software is both better, it’s easier to use than a lot of these other companies, and also we place a lot of importance on eliminating the amount of sort of manual effort involved, making integration as quick and painless as possible, and, as I mentioned, making signup really easy; you can come to our site and fill out the online form in probably just about two minutes and start charging real credit cards right away.
Louis: Right. Having recently spent, well, I didn’t personally, but another developer on our team has spent I think more or less the last month trying to get recurring payments working with PayPal; I can say that a one day or even a few hour turnaround sounds very impressive.
Ross: Yeah, we’ve heard a lot of similar stories, and a lot of people here come from backgrounds were they were doing other startups or working at other companies and experienced the same problems themselves, so I think a lot of the motivation for Stripe is born out of our own internal frustration.
Louis: Right. It’s always interesting to me; I talked with one of the guys from Shopify on the podcast last year. For those of us who develop web applications where we might sell products or just provide an online application for people, it does seem like stepping it up to another level when you’re dealing with credit cards because you have a lot of concerns that maybe other app developers don’t have to worry about so much.
Ross: Yeah, I think that’s definitely true. Stripe is even a bit different in that because we are essentially offering a piece of infrastructure for other companies, you know our primary product is our API; we’ve got an even different set of problems to worry about. I think API driven products tend to just have different problems, and, for example, reliability is paramount to us; we don’t want other people to ever have to worry about not being able to accept payments because our servers are down.
Louis: Yeah, absolutely. How long has Stripe been in operation?
Ross: Stripe has been processing payments for just about two years now, in fact, I was the first user of Stripe at my last company, but it’s only been public for about four months now, five months, September of last year.
Louis: Okay, so it’s fairly new on the market if anyone was looking for a payment gateway.
Ross: Yeah, it’s fairly new. And we also, I guess I didn’t mention this before, but Stripe integrates both the traditional payment gateway and merchant account features into one, so when you come to Stripe you don’t need to bring with you a separate gateway or merchant account, we just package that all into one simple product.
Louis: Right, so the payment that you receive, for example, go into a Stripe account?
Ross: When you get paid with us we hold your funds, actually our partner Wells Fargo holds the funds in your name, we’re never actually in control of them.
Ross: And then we transfer those funds to you to any bank account after seven days, seven days after each payment is made.
Louis: Alright. Yeah, I mean it’s really interesting, especially in a market where I think a lot of people tend to think a big player like PayPal is sort of the only option out there, and given the experience that most people have had dealing with PayPal’s support and API, I think it’s definitely a good space to have a bit more competition in.
Ross: Yeah, we’re excited about growing and about the challenges ahead.
Louis: I’m really looking forward t seeing it grow. I guess the thing you’re probably better known for is as co-creator of Cappuccino. Now, I think Cappuccino when it was first released was probably discussed on the SitePoint Podcast, though I was not doing the show at that time, but for anyone who’s unfamiliar with Cappuccino do you want to talk about what it is and how it came about?
Ross: Sure. So, to start out with a quick overview, Cappuccino is, as you said at the intro, a framework for building browser based apps, and what we mean by that is what’s I think come to be now known as like single page apps, or some people call them like fat client web apps, things like that. And the idea is an application like Google Docs or our own 280 Slides, or even to some extent Google Maps, is really something that you load once and most of the logic of running the app is happening in the client and it goes to the server just to fetch new data to act on that data. So that whole model of apps which I think we’ve seen become really popular over the last two years or so is what Cappuccino is really designed to build. And Cappuccino itself was started, well, it started in our college dorm room about 2005, but that was just really a hobby for a while, and then in 2008 we started working on it full time and started a company called 280 North to do that, and then we released it to the public I believe in August of 2008. So it’s been out for just a little over three years now.
Louis: Right. And it’s worth mentioning Cappuccino is open sourced software.
Ross: Yes, it’s open source, it’s on GitHub, it’s currently on version 0.9.5 I believe, and it’s licensed under the LGPL.
Louis: Right. So the idea behind Cappuccino was sort of from what I understand to somewhat recreate the experience of developing native apps in Cocoa and Objective-C for the desktop Mac environment —
Louis: — inside the browser.
Ross: The same set of features that Objective-C added to C. And so after he’d done that we set to work on porting a lot of the actual Cocoa framework, and so that’s where Cappuccino is today.
Louis: Right. And you said that the compiling happens in the browser, happens on the fly, something like CoffeeScript where you put it through a pre-processor.
Ross: It’s actually extremely similar to CoffeeScript. We have the capability to do it both in the browser or ahead of time on the command line, which is something CoffeeScript has as well, I believe. And so typically the development cycle for a Cappuccino app will be to make changes to your .j files and refresh your browser just like you would normally and those changes will be compiled on the fly in your browser. But then when you deploy we recommend compiling ahead of time and running all of our various optimization scripts to get stuff as tight and fast as possible so that you’re not doing repetitive work every time one of your users loads your app.
Ross: So, officially I believe we’re supporting pretty much any browser, IE7 or newer. I think Cappuccino works in IE6 as well, but we don’t really support it because we used a lot of transparent PNG’s and not really interested in that problem.
Louis: It’s weird; it’s been long enough that until you brought that up right now I had forgotten that IE6 didn’t do transparencies.
Louis: And it was just like oh, wow, that thing was really archaic.
Ross: Yeah. Yeah, when we actually released, or when we wrote our first Objective-J, IE6 was the newest Internet Explorer, so we spent a lot of time figuring out how to make compiling this language in IE6 fast enough to be realistic.
Louis: So big props to you guys for not doing what I think I would’ve done in your shoes.
Louis: Are you still working with Cappuccino in your day-to-day work or on any of your projects you’re working on at the moment?
Ross: I keep active on the Cappuccino mailing list and with some of our bug and pool requests, but I haven’t really had a lot of time in the last year or so to do Cappuccino development myself. At Stripe I’ve been working on a lot of different things, including a lot of backend code, but we also re-wrote our front-end recently, and we chose to go with CoffeeScript and Backbone, and then a custom framework that we built on top of that.
Ross: So, I’m not actually developing Cappuccino stuff at Stripe.
Louis: Right. I was actually going to ask you how you felt that Cappuccino played against or sat in relation to something like Backbone, because it seems like they’re both sort of in a way trying to solve a similar problem, although I guess Cappuccino has a lot of UI components that Backbone doesn’t really concern itself with.
Louis: But the idea of dealing with sort of more complex apps that run in the browser.
Louis: Right. And does Cappuccino work in a way that’s similar to say jQuery UI where you’ve got this set of interface components but they can be switched out with whatever other custom set you might come up with?
Ross: And Cappuccino does lose some flexibility there because you lose the expressiveness of CSS to declare like static visual style, which can be nice, but Cappuccino does have a theme system that we added that lets you do — that adds some of those features back in so you can use standard view components but modify the way they look with our theme system.
Louis: Right, yeah. You mentioned that in your work at Stripe you’ve also been doing some backend stuff, what sort of server side code are you working with at Stripe?
Ross: Most of code is written in Ruby, usually on top of Sinatra, though not always. And I’ve been doing a lot of work on our API and designing sort of the structure of the API and the actually interface that we expose to the users, not so much the implementation of specific functionality, I’ve done some of that, but a lot more of that was there before I started.
Ross: The most recent thing that I’ve been working on is we just released this week a new Webhook feature which works pretty similarly to GitHub’s post-receive hooks, if you’re familiar with that. So you can just signup and arbitrary number of URLs in your Stripe account, and we’ll send events to those URLs anytime something interesting happens, so you can, without having to pull us, track the history of changes across all your Stripe objects.
Louis: Can you give an example of what kind of thing that would be used for or how that plays into a regular use case?
Ross: Sure, so one of the things that people use it for most commonly is we have a recurring billing system, and a lot of people will want to add usage charges at the end of the month, so you charge your user for some month, let’s say you’re charging cell phone minutes, and then they use all of their cell phone minutes plus another 60 minutes, so you want to add an additional charge based on that extra 60 minutes, so we will send you a web hook telling you that their billing period is over, we’ve created an invoice for them, and all the details about that invoice and sort of the dates that it’s affected for, and we give you an opportunity to send a message back to us saying, okay great, add this amount of money to the invoice before you try and pay it.
Louis: Right. Yeah, that sounds really good. And so in your work with Ruby you said you’re working a lot with Sinatra, and I guess because you don’t have to deal with as much of a full ViewStack as a traditional web app because you’re working more with an API, or since your main product is an API, as you were saying earlier, it made sense to go with something light like Sinatra instead of a fuller framework like Rails?
Ross: Yeah, I mean I think that’s an accurate description. Rails definitely has some nice features I think even if you’re writing an API, but for us, both in terms of what we’re working on and our own needs, it just wasn’t the direction we wanted to head in. So we used Sinatra for our API, and we also use it for our website, our management website, and we actually use our API for that management website, so, as I said, it was written in Backbone, Backbone is actually just calling out to our regular API, the same API that our customers use. So, most of the features that we expose on the website we expose in a way that would let users build their own competing dashboards if they wanted to, and that’s actually been really helpful for us in understanding the right features to build in the API, and also where the biggest performance problems are.
Ross: Yeah, that was our goal, the first verson of the site was not written that way, it was a much more traditional website, and when we did this rewrite as a single page app one of the things we thought we could really win out of doing that, on top of just sort of the standard, you know, make it more responsive, make it faster loading, etcetera, was this ability to communicate directly with the API and use the same JSON data exchange to really make sure that our users would have a good experience using the API.
Louis: And so you mentioned in there accessibility and screen reader software getting better, is that something you guys have played around with and tested a bit?
Louis: Right. Yeah, I did have a look at ARIA when I was working with SitePoint on the HTML5 and CSS3 book, and it seemed like it was definitely a really good step in that direction, of course it remains to be seen how quickly browsers and screen readers are able to adopt that.
Ross: Yeah, I’m not sure what the state of adoption is, but I definitely know that it’s getting better than it was two years ago.
Louis: Yeah, and I think with all of the browsers moving as quickly as they are now it’s something that’ll really be moving along a lot faster than those of us who’ve been working in the Web for any length of time are accustomed to.
Louis: Yeah, finally. Yeah, I mean that’s been sort of the opinion of everyone I’ve spoken to on the podcast over the past year is just that level of excitement about not only the movement in the browser space, but also in the specifications and in the kind of playfulness in general experimentation that’s going on in the Web.
Ross: Yeah, and at the same time I think we may be headed for some rocky times ahead because there’s a lot of fragmentation I think going on, not necessarily in a bad way, but like you said, playfulness, there’s a lot of experimentation with things that Google’s putting into Chrome and stuff that Firefox is putting into Mozilla, and those don’t always match up. And I think that there’s been more sort of negative opinion of standards bodies, which I can’t really blame people for because they are part of the reason why things move so slowly, though I guess there’s pretty good reasons for why they move so slowly. But, yeah, I don’t want to — I worry a little bit that we’ll end up in a world where the Web will go back to a sort of ‘works best in this browser’ mode, and I definitely don’t want to see that happen.
Ross: But there’s a lot of pressure obviously from native apps on mobile platforms like iPhone and Android, so, it’ll be an interesting next few years.
Louis: Yeah, definitely. Although it feels to me like there’s some movement towards that kind of thing on the more experimental edge, you know people will make a demo of something that only works in Firefox, only works in WebKit, because they’re using some new feature that’s just been added. But it doesn’t seem like it has the potential to spread out into the broader Web in the same way you saw those kinds of built for Netscape Navigator 4 banners on actual clients’ sites, right?
Louis: Yeah, definitely. Speaking of the speed of browser releases, as we record this the latest release of Firefox came out yesterday; have you had a chance to look at the new developer features in it?
Ross: I actually have not looked at it at all.
Ross: Truthfully I haven’t.
Louis: I only ask because it happened to come out yesterday and I happened to have you on the line, and it’s a big leap because previously there were no built-in, or very few built-in developer tools, and it was sort of relying on Firebug to provide that.
Ross: Yeah, I know they’ve been away from the Firebug model I think for a lot of reasons, one is that all these other — or a lot of other browsers are coming with built-in tools that are really good, and I think Firebug was also having trouble sort of getting resources to keep working on it.
Louis: Yeah, and keeping up with the faster release schedule.
Ross: Right. Truthfully, though, I haven’t been a big Firebug user since Chrome came out, and in particular I think the developer tools in Chrome are really great, I’m really impressed with how far they’ve come in the last few years. I can remember a time when there was no other option but alert to bugging, and now I think Chrome is really a better debugging experience than Ruby, and then really most of the things I’m doing on the server side.
Ross: Yeah, I’m actually definitely interested in looking at it because definitely more competition in the tool space is what’s helped us to get as far as we’ve come now, so it definitely will be exciting to see that pick up.
Louis: Yeah, absolutely.
Ross: I’ve always actually been really surprised by how little people know about the tools that are available in the Chrome debugger and the general Web Inspector; people have been using Firebug for so long I think they may not have been looking at how much stuff has happened in Chrome and Safari, and they’ve got a keep analyzer, they’ve got all kinds of tools to tell you about memory problems that you’re having, to tell you about performance problems, it’s sort of like a YSlow equivalent that’s sort of built-in, and you know you’ve got the CPU profiler, there’s really just actually a lot of great stuff in there.
Louis: Yeah, I remember again back working on the HTML5 book for SitePoint that I was using Chrome a lot because at that point Firebug didn’t have any way of looking at local storage, or is it the — does it have Web DB access in the Web Inspector, I think it does.
Ross: I think they do, yeah, and you can inspect definitely all of local storage and session storage if that’s still in there, and cookies; you can also set like breakpoints on events now, like on DOM events, so you can say like break on events of this type, or break on like HXR’s to this URL, it’s really flexible.
Ross: Yeah, you should.
Louis: Well, it’s been a pleasure having you on the show, Ross.
Ross: Yeah, it’s definitely been great to talk to you.
Louis: And so if listeners want to find you online what are the main points of contact?
Ross: You can find me on Twitter at my last name, so that’s @boucher, if you can’t spell it it’s b-o-u-c-h-e-r.
Ross: I don’t know if you want to put that in at all. I have a website, rossboucher.com, I don’t really put very much up there but I’m working on rebuilding that, so hopefully some day I’ll do that. So, yeah, I guess Twitter is the main way, my email address, and any multiple ways of getting in touch with me are on my website.
Louis: Alright, well, thanks very much, again, we look forward to seeing what comes out of Stripe, and I’m very excited about having other alternatives for payment online because it’s as I mentioned something that we’ve definitely struggled with, so yeah, best of luck going forward with that, and I look forward to seeing what comes out of it.
Louis: And thanks for listening to this week’s episode of the SitePoint Podcast. I’d love to hear what you thought about today’s show, so if you have any thoughts or suggestions just go to Sitepoint.com/podcast and you can leave a comment on today’s episode, you can also get any of our previous episodes to download or subscribe to get the show automatically. You can follow SitePoint on Twitter @sitepointdotcom, that’s sitepoint d-o-t-c-o-m, and you can follow me on Twitter @rssaddict. The show this week was produced by Karn Broad and I’m Louis Simoneau, thanks for listening and bye for now.
Louis joined SitePoint in 2009 as a technical editor, and has since moved over into a web developer role at Flippa. He enjoys hip-hop, spicy food, and all things geeky.
7 Habits of Successful CTOs
"What makes a great CTO?" Engineering skills? Business savvy? An innate tendency to channel a mythical creature (ahem, unicorn)? All of the above? Discover the top traits of the most successful CTOs in this free guide.