Back to Venmo.Com

A Weekend at BattleHack Boston

· by Cassidy Williams

By Cassidy Williams

Hello!

So, this weekend was my first big event during my time at Venmo: BattleHack Boston.

Now, I've done a lot of hackathons, on the participating, planning, and sponsoring side.

This hackathon beat almost every single one. The PayPal/Braintree team that put it together (and lovingly allowed me to join them) was so organized and well-prepared, I can't say anything negative about the event!

It all started with the set up the night before.

There was TONS of swag.

It felt like the swag and props were never ending. Which is a good thing.

When I first heard the term, "BattleHack," I admit I was afraid it'd be a little cheesy. But this was far from it. This hackathon was epic. Even just from prep day, I could tell that it was going to be a really smooth, impactful event.

So, on the day of the event, we all got to our stations early. I was in charge of the swag table. For those of you who know me well, you know just how perfect that position was for me. Few people really appreciate good swag. I thrive on it.

From the beginning, we were loaded up with absolutely delicious food. It was actually shocking how well they fed us. We started with bagels (with a wide variety of toppings) on the first day, and throughout the event we had a waffle bar, a grilled cheese bar, lobster rolls, clam chowder, Italian food, Asian cuisine, candy, beer, pop, juices and teas, coffee... I could actually make a whole post about the food, but we have more important things to discuss. But seriously. Well done on the food, BattleHack team.

Before we kicked off the event, Matt Hamilton (also a Venmo rep) and I struck a pose. Because you simply couldn't resist those costumes.

The room got crowded fast. This hackathon was geared towards anyone 18 or older, so we had a really wide range of people. The intros to the event were pretty standard, but well done. They talked about the importance of hacking for social good, and the structure of BattleHack (it's a global competition, you can check out their website here).

And of course, we had to talk about the prizes. Throughout the event there would be smaller prizes for Best Progress and for Best Tweet, but the big prizes for hacks consisted of PS4s, cameras, and a chance to win $100,000 after being flown out to California on PayPal/Braintree's dime.

Once people settled down about the awesomeness of the prizes, we got to demos and rules. In order to be eligible for the big prizes, one had to use a PayPal, Braintree, or Venmo API. One could still win partner prizes from the companies Twilio, Mashery, SendGrid, and Context.io if you used their technologies. I had the pleasure of demoing the Venmo iOS SDK.

Once demos were done, it was lunchtime. Everyone was eating and pitching ideas and putting together teams. Hackers had been able to pitch ideas on video before the event started, so some people knew what they were doing, and others were starting completely clean.

Finally, just before 1PM, we had a big countdown to start. We banged the gong, and we were off! Teams quickly started sketching out ideas and setting up their stations.

Over the next few hours, Matt and I were approached several times about using the Venmo API, which was great. The PayPal/Braintree dev evangelists kept thanking us on the side for coming. They said that Venmo has been one of the most popular APIs of the entire BattleHack competition so far, and they loved having us there to help.

Time went on, more food was served throughout the night. The BattleHack team brought in professional masseuses (holy crap, am I right?) and soon Matt's and my shift was over. We were able to leave at about 9, as long as we got back by 4AM. That was one of the things I appreciated about the planning that went into BattleHack; designated shifts aren't always thought of for the staff of hackathons.

After a nearly sleepless night, I got back at 4 and started circling the room looking for the Best Progress award. Teams had been working hard. Some included hardware components, some were trying to use every API available. It was very impressive to see the work being done. Eventually, the team we decided had the Best Progress was FundRunner, an application that assisted those running and those donating to people running in various races for charity. It checked when certain milestones were hit using geolocation, it texted donors when their maximum donation amount was hit, it sent emails... their work so far was pretty darn solid.

Throughout the morning, Matt and I were hit up with Venmo questions. Some were pretty technical, some were simply, "why would I use Venmo over PayPal?" But overall, we were kept busy. Matt and I took notes of flaws on our end and desires on the developers' end for future reference.

Rehearsals were another big part of Sunday morning. Every team practiced their pitches (which were going to be 2 minutes long) and got feedback from the BattleHack team. This is another part of the hackathon that I appreciated and don't often see. People in general, without feedback, aren't successful without an outside perspective.

And finally, after a lip-smacking lunch of lobster rolls and a grilled cheese bar, it was time for presentations. There were some really cool ones, and quite a few using Venmo! A few cool ones where:

  • AgriGate, an "Etsy for farmers" that allowed farmers to post their produce for people to buy, and included a hardware component of a packing slip being printed
  • Street Music is a platform that connects users to street performers to legitimize their profession and allows donation through Venmo and PayPal (they kicked off their presentation by singing, I was impressed)
  • HaveKnow proves your identity for emergency rescue payments when you've lost your ID and/or wallet, and lets you pay people with PayPal/Venmo after they give you cash
  • Honk is a license plate-based messaging app that allows users to send compliments and constructive criticism to drivers (sent in the form of a Venmo charge/payment)
  • FundMatch is a web-based platform dedicated to efficient giving for nonprofits and allows donations through PayPal (the cool part of this one was they took in organization emails and information and parsed them into an easy-to-read form for donors to understand)
  • Pothole Sonar app uses audio to enhance the awareness of mobile users to the dangerous potholes nearby and compiles pothole data
  • Nome (short for "metronome") is a "git for music" where people can collaborate on music projects and donate to other musicians with Venmo

There were a bunch more, and overall the event was so cool. The winners of the event made "Late Night Safety Kit," an app with tools that allows a user to stay safe by sending alerts for crime and to the police station in the area.

And so, as the BattleHack saying goes: City Conquered! I had to run off after the presentations for my train back to NYC. Overall, I genuinely enjoyed my time at BattleHack Boston. The planning team was a well-oiled machine, on top of every single nuance. I loved helping them and being a part of such an impressive event.

Until next time! :)

Permalink

Bind in JavaScript

· by Sarah Ransohoff

By Sarah Ransohoff

The web team here at Venmo works almost entirely in JavaScript. One function we use often is bind. Let's take a look at what's going on here.

Here's a simple example of how you might use bind:

var obj = { foo: function() { console.log(this); this.name = 'baz'; (function() { console.log('inside func'); console.log(this.name); }.bind(this))(); } } obj.foo(); // Object {foo: function} // inside func // baz 

In the example above, bind allows the function inside of foo's outer function to have access to this.name. If we did not bind then this.name would return undefined. And it would do so because this now refers to the global object. No good if we want to be able to work with the same this in a nested function.

So what is going on behind the scenes with bind? What's this sneaky guy doing? Well, bind returns a function with new or added context, optionally adding any additional supplied parameters to the beginning of the arguments collection. Let's take a look at a rewrite below.

Function.prototype.bind = function(ctx) { var fn = this; var args = arguments.slice(1);

return function() { return fn.apply(ctx, args.concat(arguments)); }; }; 

So, let's go through it:

  1. Bind takes a context (ctx).
  2. The function on which bind will be called is this
  3. The arguments (args) passed into the function include everything but the first argument, ctx
  4. bind returns a new function that applies ctx and args to the original fn

This is essentially how bind returns a function that will execute in a given context.

To really hammer it home, let's take a look at an instance where we do not use bind:

$('.gist-author img').click(function() { // my avatar image on gist.github.com :-P
  console.log(this);
  (function() {
    console.log('inside');
    console.log(this);
  })();
});
// if you click that image, you'll get the following...
// <img src="https://avatars1.githubusercontent.com/u/4968408?s=140" width="26" height="26">
// inside
// Window {top: Window, window: Window, location: Location, external: Object, chrome: Object…}

Yikes. If we want to perform a function on the original this -- in this case, img -- we can't. Inside the inner function, this refers to the window because this defaults to window when inside a jQuery function. This is the problem that bind tries to solve: to allow us to be specific with our context.

Awesome. I hope that's helpful. It certainly helps us at Venmo.

Until next time,

Sarah Ransohoff

Permalink

Introducing Background Nearby with iBeacons

· by Dasmer Singh, iOS Engineer

Beacons are game-changing. Ever since Apple extended its developer API to support beacons in iOS 7, articles and blog posts have inundated the web to extol their use-cases in retail. Apple has pioneered this initiative by placing beacons throughout its stores, to notify and educate customers about the products they are standing next to as they walk around.

At Venmo, we were eager to learn more about how beacons work and excited to explore their potential. We wrote and open-sourced VENPromotionsManager, an iOS library that schedules in-app promotions that trigger when a user enters specified regions created by beacons. To experiment, we loaded our offices with Estimote beacons which triggered fun little messages on internal builds of Venmo.

When Apple introduced its iOS 7.1 update, we noticed that they had vastly improved beacon scanning by moving this responsibility from the app-level to the core OS-level. To our surprise, our devices were notifying us of entering a beacon’s region even if Venmo was not running in the background. In addition, our iPhones were detecting these beacons much faster than before (in fewer than 2 seconds on average).

In February, we introduced Venmo Nearby, which utilizes Apple’s MultiPeer Connectivity (MPC) framework to discover nearby users over Bluetooth Low Energy (BLE) and WiFi Bonjour networks. We’ve received more positive feedback and press about Nearby than any other feature we had ever released.

Our users loved Nearby, but one thing prevented the feature from being as useful as we would have liked it to be: both users needed to have the Venmo app open in order to discover one another. This limitation is inherent in Apple’s MPC framework, which only allows devices to broadcast and listen for unique peer identifiers when the app is foregrounded. However, with Apple’s recent enhancements in iOS 7.1, we discovered that we could finally detect nearby Venmo users even when the Venmo app has been terminated and a user's phone is in standby.


How did we do this?

To make this work, if a user opts-in to Nearby, their device not only advertises a unique peer identifier over Apple’s MPC network, but also broadcasts a beacon region with a UUID unique to Venmo whenever the app is open and active. Devices that have Background Nearby enabled are always scanning for this Venmo beacon region, even if they are locked and their screens are off (this scan uses extremely low battery power because it utilizes Bluetooth LE). Whenever a device enters a beacon region, it briefly launches the Venmo app into the foreground in order to broadcast its peer identifier over the MPC framework, thus establishing a Nearby connection. In other words, whenever our users open Venmo to pay or charge the people they are around, they can instantly emit a beacon signal that momentarily wakes up their friends’ devices to connect and populate the user's Nearby drawer. This makes Nearby more powerful and useful than ever before.

We released Background Nearby in our latest update to the Apple App Store and are extremely excited for our users to try it out! At Venmo, we believe that in order to create an extraordinary experience for our users, we need to provide a service that enables them to spend more time cherishing the moments they value with the ones they are with and less time figuring out how to settle the bill. With solutions like Background Nearby, we hope to keep innovating and do just that.

Permalink

Meet Our Partner, Waves for Water

· by Shira Brettman

This past New Year's, Venmo resolved to double down on our mission to connect the world and empower people through payments. A half-year later, we might have dropped the ball on our gym memberships and gluten-free paleo diets, but we are still very much committed to this resolution.

This month, our partner, non-profit Waves for Water, in conjunction with our friends at PayPal, launched an international giving contest between nations. Waves for Water helps provide communities around the world with access to clean drinking water. Donations from this particular challenge will be used to purchase clean water filters for communities in Brazilian cities hosting the soccer games. Every $50 donated provides one million gallons of clean water—that means each dollar you donate will provide two people with clean water for up to five years.

Make waves through Venmo: donate here.

Permalink

Blissful UI programming with ReactiveCocoa

· by Ben Guo


By Ben Guo

We've recently started using ReactiveCocoa in the Venmo iOS app, and we've found that it provides an expressive, unified alternative to patterns like callback blocks, delegate methods, target-action, notifications, and KVO. If you haven't heard of ReactiveCocoa or Functional Reactive Programming (FRP), we recommend starting with this awesome post by Josh Abernathy and the official introduction. In this post, we'll walk through implementing a simple reactive user interface, with and without ReactiveCocoa. Hopefully, we'll inspire you to start experimenting with FRP on your own!

We'll be working on a simple signup form that looks like this:

Let's start with the top of the form, where the user can add or change their profile photo.

// SignupViewController.h // ... @property (weak, nonatomic) IBOutlet UIImageView *imageView; @property (weak, nonatomic) IBOutlet UIButton *photoButton; // ... 

The photoButton's text should be either "Add photo" or "Change photo", depending on whether or not a photo has been added, and the imageView's image should be the currently chosen photo. Here's a reasonable imperative implementation:

(1a) Imperative

// SignupViewController.m

# import "SignupViewController.h"

@interface SignupViewController ()

@property (strong, nonatomic) UIImage *photo;

@end

@implementation SignupViewController

* (void)viewDidLoad { [self.photoButton addTarget:self action:@selector(photoButtonAction) forControlEvents:UIControlEventTouchUpInside]; }
* (void)setPhoto:(UIImage *)photo { _photo = photo; self.imageView.image = photo; if (photo) { [self.photoButton setTitle:@"Change photo" forState:UIControlStateNormal]; } else { [self.photoButton setTitle:@"Add photo" forState:UIControlStateNormal]; } }
* (void)photoButtonAction { UIImagePickerController *imagePicker = [UIImagePickerController new]; imagePicker.delegate = self; [self presentViewController:imagePicker animated:YES completion:nil]; }
* (void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary *)info { self.photo = [info objectForKey:UIImagePickerControllerOriginalImage]; [self dismissViewControllerAnimated:YES completion:nil]; }


Imperative programming involves describing how to do something. Reactive programming, on the other hand, involves describing what something is, using streams of values. Here's an equivalent implementation, with ReactiveCocoa.

(1b) Reactive

 // SignupViewController.m

# import "SignupViewController.h"

# import


<reactivecocoa reactivecocoa.h=""></reactivecocoa>

# import


<libextobjc extscope.h=""></libextobjc>

@interface EditProfileViewController ()

@property (strong, nonatomic) UIImage *photo;

@end

@implementation SignupViewController

* (void)viewDidLoad { [super viewDidLoad]; [self configureImageView]; [self configurePhotoButton]; }
* (void)configureImageView { RAC(self.imageView, image) = RACObserve(self, photo); }
* (void)configurePhotoButton { @weakify(self); [RACObserve(self, photo) subscribeNext:^(UIImage *image) { @strongify(self); if (image) { [self.photoButton setTitle:@"Change photo" forState:UIControlStateNormal]; return; } [self.photoButton setTitle:@"Add photo" forState:UIControlStateNormal]; }]; [[self.photoButton rac_signalForControlEvents:UIControlEventTouchUpInside] subscribeNext:^(UIButton *button) { @strongify(self); UIImagePickerController *imagePicker = [UIImagePickerController new]; imagePicker.delegate = self; [self presentViewController:imagePicker animated:YES completion:nil]; }]; }
* (void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary *)info { self.photo = [info objectForKey:UIImagePickerControllerOriginalImage]; [self dismissViewControllerAnimated:YES completion:nil]; }


@end 

Our reactive code is more linear than our imperative code, but also arguably more difficult to parse. It's hard to see the value of reactive programming at this level of complexity, but as we add more functionality, we'll begin to see the benefits of choosing ReactiveCocoa.

To finish our form, we'll need a username field, a password field, and a submit button. The submit button should only be enabled when we've added a photo and entered a username and password. For some extra reactivity, let's make each text field's text turn orange while editing.

// SignupViewController.h // ... @property (weak, nonatomic) IBOutlet UITextField *usernameTextField; @property (weak, nonatomic) IBOutlet UITextField *passwordTextField; @property (weak, nonatomic) IBOutlet UIButton *submitButton; /// ... 

First, let's try updating our imperative implementation from (1a).

(2a) Imperative

- (void)viewDidLoad {

    // ...
    
    [self.usernameTextField addTarget:self 
                               action:@selector(textFieldDidChange:)
                     forControlEvents:UIControlEventEditingDidBegin | UIControlEventEditingChanged | UIControlEventEditingDidEnd];
    [self.passwordTextField addTarget:self 
                               action:@selector(textFieldDidChange:)
                     forControlEvents:UIControlEventEditingDidBegin | UIControlEventEditingChanged | UIControlEventEditingDidEnd];
    [self updateSubmitButton];

}

* (void)setPhoto:(UIImage *)photo {


// ...

[self updateSubmitButton]; }

// ...

* (void)textFieldDidChange:(UITextField *)sender { [self updateSubmitButton]; [self updateTextFieldColors]; }
* (void)updateSubmitButton { self.submitButton.enabled = self.photo && self.usernameTextField.text.length > 0 && self.passwordTextField.text.length > 0; }
* (void)updateTextFieldColors { self.usernameTextField.textColor = self.usernameTextField.editing ? [UIColor orangeColor] : [UIColor blackColor]; self.passwordTextField.textColor = self.passwordTextField.editing ? [UIColor orangeColor] : [UIColor blackColor]; }

Dealing with state is messy in the imperative world. Our code has become rather difficult to understand — we update the submit button in three different places, setPhoto: has three side effects, and in general, things seem to be happening all over the place. Also, notice that modifying our imperative implementation required touching nearly everything we'd written in (1a). Adding functionality usually means adding new events and states. In the imperative world, we have to respond to discrete events and state changes and make sure everything stays up to date, resulting in less linear, more tightly coupled code that's more difficult to understand and update.

Let's try updating our reactive implementation.

(2b) Reactive

- (void)viewDidLoad {

    // ...
    
    [self configureTextFields];
    [self configureSubmitButton];

}

// ...

* (void)configureTextFields { RAC(self.usernameTextField, textColor) = [RACObserve(self.usernameTextField, editing) map:^UIColor *(NSNumber *editing) { return editing ? [UIColor orangeColor] : [UIColor blackColor]; }];


RAC(self.passwordTextField, textColor) = [RACObserve(self.passwordTextField, editing) map:^UIColor *(NSNumber *editing) { return editing ? [UIColor orangeColor] : [UIColor blackColor]; }]; } * (void)configureSubmitButton { RAC(self.submitButton, enabled) = [RACSignal combineLatest:@[RACObserve(self, photo), self.usernameTextField.rac_textSignal, self.passwordTextField.rac_textSignal] reduce:^NSNumber *(UIImage *photo, NSString *username, NSString *password){ return @(photo && username.length > 0 && password.length > 0); }]; } 

Updating our reactive implementation hardly required any changes to what we wrote in (1b), and the resulting code is much more linear. Because state changes propagate automatically, we can define the flow of state rather than responding to discrete events. Even in this simple example, reactive programming has empowered us to write code that's easier to understand and maintain.

We've only scratched the surface of ReactiveCocoa, but hopefully we've given you a more concrete sense of the power of reactive programming. So go forth, compose signals, minimize state, and put away that spaghetti — let's make lasagna ;)

If you're interested, you can check out the complete example project here.

Permalink

Testing React.js

· by Julian Connor

By Julian Connor

Testing With React

At Venmo, we’ve started using React on our front-end. React is a javascript library for building reactive (dynamic) user interfaces. We use React for our view layer and Backbone for our data layer. Here you can find a blog post by my colleague Thomas Boyt on how we leverage both of these awesome libraries.

Why React?

As our client-side apps grew in size, maintaining and testing our Backbone views became a burden. React ships with JSX, Javascript XML Syntax Transform, which greatly reduces the amount of complexity that large views incur over time by providing a new way to construct your app’s markup. Backbone views rely on templating and selectors for inserting elements into the DOM, while React components are declarative.

If you're looking for more information on why you should consider replacing Backbone.View with React, check out Clay Allsopp's awesome blog post- From Backbone to React.

Here’s an example of how both libraries approach constructing app markup.

// Backbone define(['./view'], function(View) {

var BackboneView = Backbone.View.extend({

    render: function() {
      this.$el.html(_.template($('#skeleton_template').html()));
      this.$('.container').html(new View().render().el);
    
      return this;
    }

});

});

// React define(['./view'], function(View) {

var ReactComponent = React.createClass({

    render: function() {
      return (
        <div className='container'>
          <View />
        </div>
      );
    }

});
return ReactComponent; }); 

At first glance, the difference may seem trivial. But over time your views will gain complexity and a simple Backbone view like the one above may end up manually populating several containers, each with its own markup. The React approach is much easier to reason about and moves the concerns of markup construction into the JSX block.

Testing

Why does this point matter? Well, a test that would have looked like this:

it('renders 3 comments', function() { 
    var comments = new CommentsCollection(commentFixtures); 
    var commentList = new CommentsListView({ collection: comments }).render();
    expect(commentList.$('.comment').length).to.be(3); }); {% endhighlight %}

Now looks like this:

var TU = React.addons.TestUtils;

it('renders 3 comments', function() { 
    var commentList = TU.renderIntoDocument(new CommentsComponent({
        collection: new CommentsCollection(commentFixtures) }));

    var commentList = TU.scryRenderedDOMComponentWithType(commentList,      CommentComponent); expect(commentList.length).to.be(3); }); 

Testing with React allows your tests to be markup agnostic. This means that React is only concerned with whether or not three instances of CommentComponent exist rather than their markup. The example test written in React is much less brittle because it does not rely on the class name .comment. Thus, if someone were to swoop through the codebase and change a bunch of class names and DOM structure, your tests would still make all the proper assertions. This is a massive step towards building a rock-solid app and test suite.

Here’s another example:

var TU = React.addons.TestUtils;

it('renders a FooForm', function() { 
    var app = TU.renderIntoDocument(new App());

// TU.findRenderedComponentWithType will throw an exception if it’s unable to // find any children that have type `FooForm` expect(TU.findRenderedComponentWithType).withArgs(app, FooForm)         .to.throwException(); }); 

This test is amazing. It simply asserts that our App component contains a FooForm component. We don’t care about how FooForm behaves or what it contains (that’s what spec_foo_form.js is for); we simply care about its existence.

Conclusion

We’re huge fans of tests. Having a solid test suite has helped us avoid regressions, sleep better, and cool our conscience. In an ideal world, regardless of what library you use, your Javascript app would be composed of many small, modular, extendable and test-covered units. By allowing us to write markup-agnostic tests, React brings us a step forward in our never-ending quest for Javascript testing nirvana.

Permalink

Testing React.js

· by Julian Connor

At Venmo, we’ve started using React on our front-end. React is a javascript library for building reactive (dynamic) user interfaces. We use React for our view layer and Backbone for our data layer. Here you can find a blog post by my colleague Thomas Boyt on how we leverage both of these awesome libraries.

Why react?

Read the rest of this post at the Venmo engineering blog.

Permalink

Thoughts from F8: Move Fast, But Don’t Break Things

· by Ayaka Nonaka

Last Wednesday, our mobile engineering team at Venmo attended F8, Facebook’s developer conference.

At some point during the kick-off, Mark Zuckerberg stood on stage with the famous phrase “Move Fast And Break Things” projected in the background. Many cameras went up to capture this iconic moment. Moments later, a new phrase was projected: “Move Fast With Stable Infra[structure].” Zuckerberg sheepishly admitted that this isn’t as catchy sounding as their previous phrase, but it was a much needed change. I always thought the right phrase was “Move Fast, But Don’t Break Things” so this was a very welcome announcement that made me excited for the following sessions.

move_fast_and_break_things
move_fast_with_stable_infra

There were four separate tracks that an attendee could follow during the conference: Build, Grow, Monetize, and Hacker Way. Although you could switch tracks at any point during the conference, I ended up staying on the Hacker Way track for the entire day.

At first, I was hesitant to register for all of the “hacker” sessions, because I was there to learn about engineering best practices; not how to “hack” things together and break things. But after reading the descriptions for each of the sessions, it sounded like this track was the right one. As a cynic of the “#shipit” culture, I thought this was a little ironic.

The sessions, as promised, took us through Facebook’s engineering process—everything from UI prototyping to continuous integration, and even performance optimization using subtree pre-compositing. For UI prototyping, they use Origami, a tool that they built in-house. To speed up testing, they built xctool for iOS, and Buck for Android. To achieve the level of seamlessness in Paper’s gestures and animations, they built Pop. These tools are available to everyone. The best part? They’re all open-source, with active contribution from developers all over the world.

Facebook’s developers showed us all the processes and tools that work for them to “Move Fast” while shipping stable, quality software (i.e. not “Break Things”).

In hindsight, the name “Hacker Way” isn’t actually ironic. Facebook seems to be redefining the “hacker” culture. “Hacker” doesn’t mean the too common definition of “one who breaks into computers” or the slightly newer definition of “one who ships stuff quickly (and probably with bad code).” To be a hacker is to build and ship quality products while knowing what tools and processes can help do this faster. Afterall, good software engineering practices like using proper design patterns and testing were invented not to slow you down, but to enable you to move fast and not worry that you might have broken something.

Overall, we really enjoyed F8. Not only did Facebook announce cool new products like Anonymous Login and App Links (which we’re super excited to be integrating in the coming weeks), but they took it one step further and offered sessions that enable hackers (in the newest sense of the word) to go out and build the best products to delight their users.

Thank you for having us there, Facebook!

P.S. You can go here to watch all of the sessions from F8. The videos with the blue backdrop are the ones from Hacker Way.

Permalink

VCR.py at Venmo

· by Simon Weber

We've been improving our Python test suite at Venmo. Three months ago, builds were flaky and took 45 minutes; now they’re robust and run in 6 minutes. This is the first in a series of posts about how we achieved this.

Our goal at Venmo is to connect the world and empower people through payments. We interact with a variety of external services to accomplish this, including social networks, credit card processors and identity providers.

Over time, our test suite accumulated unmocked interactions with these services. This slowed down builds and introduced flaky tests. While we occasionally mocked problematic interactions manually, this was error-prone and annoying for test authors. We needed an automatic solution -- something that would let us easily mock old and new tests.

Read the rest of this post at the Venmo engineering blog.

Permalink

DryDock. An open-source internal installer for iOS

· by Chris Maddern

What is DryDock?

DryDock is an open-source internal installer for iOS that enables rapid-deployment of experimental builds to the team and allows (permitted) users to install internal product releases on demand while remaining on a supported internal update track! Huzzah.

You can check it out on GitHub here

Why?

At Venmo, we try to experiment as broadly and continually as we can. As we've gotten better (and faster) at this, we've also had to get better at getting builds in to teammates, users and stakeholders' hands quickly & efficiently.

On average, we're typically working on 4-5 new features at any given time and engineers & stakeholders don't want to wait for the next internal 'release' to get a functional prototype in their hands. (This could be for user testing or just general 'touch-testing'.)

Old Solution

Plug their device in to Xcode and build to it. Simple, but it has a few downsides:

Any device you directly build to is then on an 'unsupported' build without updates. Team members would come to us with issues because they were still stuck on an Xcode-built version of 4.4.0a2 (or something similar) which had a half-baked version of Nearby, for example.

We then have to manage 'UDIDs' in the developer portal as builds aren't release signed.

New Solution


DryDock

An internal installer to rapidly share builds with the team on, be able to easily re-install them if anything goes wrong and where we can get people back on to supported builds. As we built the first version of DryDock, we also realized that this could solve a problem for our support team; being able to install any past version of the app to reproduce issues.

Build Versioning

DryDock works with VENVersionTracker to make sure that users don't get crossed-over between individual experimental builds, but that they get upgraded to later versions of the main internal releases. We do this with a build versioning system..

Assuming a two week sprint which targets a minor-version release, builds will be versioned as follows:

Week 1 Development & Experimental builds: 4.x.0ax
Week 1 Internal releases : 4.x.0a(1-9)

i.e. any internal development and 'experimental builds' of Venmo are bucketed to the 4.x.0ax version, meaning they're isolated from releases on Crashlytics & tracking tools. Meanwhile, any release that's broadly distributed has clear usage & crash reporting.

Week 2 Development & Experimental builds: 4.x.0bx
Week 2 Internal releases : 4.x.0b(1-9)

--- Cut release branch here ---

End of Week 2: 4.x.0rc(1-9) // Bugfixes only at this point

VENVersionTracker will upgrade any 4.x.0ax build to 4.x.0bx or 4.x.0b(1-9) when it becomes available, so we effectively stop orphaned builds from development branches. This gives experimental one-offs a life-span of 'until the next internal release', which is fine.. they should be in that release if they're intended to be long-lived experiments.

We've been using DryDock for a few weeks internally now & love it so we thought we'd open source it so that anybody can easily create an internal installer app.

Built on Parse

DryDock is our first internal tool supported by the Parse backend.

Why Parse? It was the simplest way to get the backend up and running and was an easy way to ensure that whatever we made would easily be able to be used by others. The simplicity of building on Parse is impressive & their client SDK is intuitive to use. They also have SDKs / libraries for a broad array of languages & platforms, so extending this to work on Android or to be updated from a build tool to push from CI would not be too difficult.

Try it out & feel free to extend it

We're sharing this pretty early & have lots of improvements that we want to make; things ranging from automatic updates from build scripts to test-status for each app on a details screen, not to mention access controls to have different groups of users.

If you think of something that you'd like it to do for your team, feel free to fork & extend DryDock and if it's something that seems useful generally we'll merge it and everybody can benefit!

Let us know what you think!

Permalink

Introducing Nearby Payments

· by Chris Maddern

Introducing Nearby Payments

We're really excited to launch nearby payments for Venmo today. Nearby payments let you do exactly what it sounds like -- pay other Venmo users who are close to you.

Read More →

Using React Components as Backbone Views

· by Thomas Boyt

By Thomas Boyt This post was originally published at thomasboyt.com.

At Venmo, we've begun rewriting and redesigning our front-end into clean, idiomatic Backbone code. Backbone is an unopinionated framework that provides structure to your code. However, its view layer is purposefully lacking, providing only a few basic lifecycle hooks. Unlike Ember components or Angular directives, it does not hook your data up to your views for you, and does little to enforce separation between your layers.

While we've gotten surprisingly far using only vanilla Backbone views, we've begun exploring more advanced options for architecting our UI. My goal was to find something that could interface with Backbone views that gave me the data binding and scoping that I was used to from views in larger frameworks. Thankfully, my friend Scott pointed me at React, and after a few hours of wrestling with it, I came away very impressed.

Overview

React is a relatively new library by Facebook for creating isolated components. In many ways, it's similar to Angular directives or Polymer web components. A React component is essentially a custom DOM element with its own scope. It cannot directly interact with other portions of your application's state, whether in JavaScript or in the DOM.

The most unique - and most controversial - part of React is its use of JSX, which transforms HTML written inline with your code into parseable JavaScript. Here's an example React component that uses JSX to render a link:

        /* @jsx React.DOM */
       var component = React.createClass({
         render: function() {
           return Venmo
         }
       });
This gets transformed into:
       /* @jsx React.DOM */
       var component = React.createClass({
         render: function() {
           return React.DOM.a( {href:"http://venmo.com"}, "Venmo")
         }
       });

  • require-jsx, is a RequireJS plugin for loading JSX files
  • reactify is a Browserify transform for JSX files
  • grunt-react compiles JSX files through Grunt

JSX is optional - you can write your templates using the React.DOM DSL if you'd like, though I'd only recommend this for simple templates.

Instead of teaching the basics of React in this post, I'll pass that responsibility to the excellent React tutorial. It's a bit long, but give it a skim before continuing!

Rendering a component from a Backbone view

Let's create a very basic component: a link that fires an event when clicked. We'd like to render this component as part of a Backbone view, rather than use it on its own. The component is easy enough to create:

       var MyWidget = React.createClass({
         handleClick: function() {
           alert('Hello!');
         },
         render: function() {
           return (
             Do something!
           );
         }
       });

This is almost the same as the above example, except for the addition of a handleClick handler for the link's click event. Now, all we need to do is add a Backbone View to render this in:

       var MyView = Backbone.View.extend({
         el: 'body',
         template: '
       ',        render: function() {        this.$el.html(this.template);         React.renderComponent(new MyWidget(), this.$('.widget-container').get(0));         return this;         }        }); new MyView().render();

Here's our completed new component:

Component -> Backbone communication

Of course, to really take advantage of React components, we'll need to be communicate changes from React to Backbone. For a very arbitrary example, let's say that we want to display a bit of text if the link in our component has been clicked. Not only that, but we want the bit of text to be outside the component's DOM element.

While the React docs are very good at explaining how to have different components communicate, it's not super obvious how a child component could interact with a parent Backbone view. However, there's a single, easy way to communicate: we can bind an event handler through the component's properties.

Here's an example of this pattern, in JSX:

function anEventHandler() { ... }
React.RenderComponent(,
                      this.$('body').get(0));
                      

We can do the same from our Backbone view, but instead of using JSX, we'll use the class itself:

var MyView = Backbone.View.extend({
  el: 'body',
  template: '
' + '
', render: function() { this.$el.html(this.template);

React.renderComponent(new MyWidget({
  handleClick: this.clickHandler.bind(this)
}), this.$('.widget-container').get(0));

return this;

}, clickHandler: function() { this.$(".outside-container").html("The link was clicked!"); } });

And, inside the component, let's bind onClick to the new handler:

var MyWidget = React.createClass({
  render: function() {
    return (
      Do something!
    );
  }
});

Here's our full, updated example:

Again, this is a very contrived example, but it shouldn't be hard to envision a more practical use case.

For example, at Venmo, we've remade our "Connect with Facebook" button with React. The actual Facebook API calls happen within the component, but the views in which the component are used bind different handlers to the component's events. These events (such as "authenticated with Facebook" or "logged out of Facebook") are essentially the component's "public API." React can also pass arguments with events, so that when a user connects with Facebook, the Backbone view gets the user's Facebook ID and attaches it to the user model.

Backbone -> Component communication

Now that we know how to get communication from a component, the next step is to be able to update the component's state from a Backbone model - as a concrete example, we'll make a view that reacts to a changed field on a model. This requires a bit of boilerplate (though no more than your usual manually-connected Backbone view), but is quite easy in practice.

First, we create a tiny model class:

var ExampleModel = Backbone.Model.extend({
  defaults: {
    name: 'Backbone.View'
  }
});

And a simple React component that displays the name field:

var DisplayView = React.createClass({
  render: function() {
    return (
      

{this.props.model.get('name')}

); } });

However, this component on its own can't react to the model's field being changed. Instead, we can add a listener for the model's change event that tells the component to re-render:

var DisplayView = React.createClass({
  componentDidMount: function() {
    this.props.model.on('change', function() {
      this.forceUpdate();
    }.bind(this));
  },

render: function() { // ... } });

Then, we add another component that will actually change the name field:

var ToggleView = React.createClass({
  handleClick: function() {
    this.props.model.set('name', 'React');
  },
  render: function() {
    return (
      
    );
  }
});

Finally, we create a model and render both components using JSX:

var model = new ExampleModel();

React.renderComponent((

), document.body);

And the completed example:

Conclusion

Backbone + React is a fantastic pairing. There's several other blog posts that discuss it:

React also has an example Backbone+React TodoMVC app that's worth checking out.

While React is still immature, it's a very exciting library that seems ready for production use. It makes it very easy to share and reuse components, and I'm excited that it integrates so well with Backbone, making up for the default of view logic.

Permalink

Our approach to mobile engineering

· by Chris Maddern

Our approach to mobile engineering

At Venmo, we're in it for the long game. That means that we need a maintainable codebase which is easily extendable and flexible to ever-changing company goals. While our product is social, we're also a finance app and so we have to take a very serious approach to software quality and security. Users feel safe using Venmo because they trust us -- part of this trust is creating a stable & enjoyable experience.

Read More →

GiveDirectly on Venmo

· by Andrew Kortina

GiveDirectly on Venmo

Our mission at Venmo is to connect the world and empower people through payments.  We love to see users connect when they add personal notes to each payment and share with friends, and in 2014 we hope to better serve the empowerment part of our mission.

Read More →

Introducing the Recents Drawer for iOS

· by Chris Maddern

Introducing the Recents Drawer for iOS

As part of our iOS 7 redesign release, we added some new features, made lots of changes and removed a few features that we weren't totally convinced about too.

One feature that we removed, was the 'Recents Friends Bar', which allowed users to pay some of their friends with one tap from the main feed.

User Feedback
We received a lot of feedback about removing this.

I really liked my "favorites" at the bottom. Now it seems I have to search for the few people I pay every day? Am I missing something?
-Venmo User

Read More →

Performance Tuning On Android

· by Robert Cheung

Performance Tuning On Android

Earlier this summer, we released a major update to our Android app. It shipped with a revamped UI, a new robust networking layer, and plenty of awesome. Our users loved the new experience and responded with a lot of positive feedback. It was a great release, but we were a little unhappy with how smooth the UI was. Scrolling on the feed seemed choppy, especially when scrolling quickly. 

So let’s talk about UI performance.

Read More →

Designing the Drawer

· by Ayaka Nonaka

Designing the Drawer

This week, we launched an update to Venmo for iOS, introducing a drawer-based navigation pattern. You can download it from the App Store here.

Recently, side-drawer designs have been going out of vogue. Most notably Facebook, who spent a lot of effort educating the broad user population about the side-drawer metaphor, moved to using a tab bar based design citing increased engagement.

We spent a lot of time (and user testing) investigating if the side-drawer was right design for Venmo for iOS. We landed on a solid 'yes'.

Read More →

Simon Weber is at Venmo

· by Venmo

Simon Weber is at Venmo

Simon hails from the sweetest place on earth: Hershey, Pennsylvania. After graduating from the University of Rochester last spring, he spent the summer at Hacker School.

Read More →

Thomas Boyt is at Venmo

· by Venmo

Thomas Boyt is at Venmo

Thomas is a Hacker School (Winter 2013) alum. He's a contributor to Ember.js and various other open source JavaScript projects. He cares deeply about build tools and foundations for creating web applications, and believes that a solid front-end is just as important for an app as a solid back-end.

Read More →

Introducing Our Status Page

· by James Turnbull

Introducing Our Status Page

Green lights make engineers (and users!) happy. Unfortunately failure is always lurking, especially when your user base grows at the exciting (and sometimes frightening!) rate Venmo’s does. During our outages in the past, we lacked a public facing way to inform our users about potential issues on the platform. In short, we lacked a status page. We're sorry for holding off on shipping one for so long, but the good news is, we finally have one in place.

Read More →