As our user base at Peloton continues to grow we’ve found some interesting opportunities to connect members to each other. We think that creating more opportunities for shared, real-time workout experiences is an important initiative and something we wanted to invest in. The first large feature based around this goal was something we called Working Out Now, which involved letting members know in real-time that another member they had followed on our platform was currently working out. To support this, we wanted a mechanism that could easily notify members anywhere in the product. We wanted it to be minimally invasive while still providing detailed information when needed.

Real-Time Messaging Integration

We were already using PubNub to send real-time updates for our user activity feed, which shows members their friends’ activity. We decided to continue using PubNub for our real-time messaging and simply expand on what we had in place.

For each member we create a PubNub channel that their device subscribes to upon login. Whenever we need to send a real-time update to that member, we publish a message on that member’s channel. Each message has a type which we use to identify the schema of the payload. This allows us to easily create and consume new messages types.

On the client side, we encapsulate the ability to connect to PubNub and receive messages in our Messaging Service, which can easily be injected throughout the app for use. This Service exposes a Rx Observable that supports filtering the message stream by type. This gives clients a simple way to only get messages they care about and know how to consume.

Know When Your Friends Are Working Out

In order to know which of a member’s friends are currently working out, we need to know every time one of those members joins or leaves a workout. We defined two types of messages: “Someone you follow joined a workout” and “Someone you follow left a workout”. Whenever a member joins or leaves a workout, the Peloton API publishes a message to the PubNub channel of each of the member’s followers.

After defining these message, we hooked up the client to receive them in our bottom navigation component. We decided to build a cache that would update every time we received one of these messages from the server and then request additional information as needed. This worked well while a member was on their Bike or Tread, but we still needed a way to know who was in a workout when the member first started their session.

We created a new API endpoint that allowed us retrieve all the data for a member’s followers that we could leverage when our cache was stale or needed to be initialized. There was also a risk that the client’s local list of friends who were working out got out of date for a number of reasons. Instead of the client incrementally updating their local list, they request the full list of friends in classes each time they receive a message. Once the client has this information we use it render our Working Out Now dialog that members see when clicking on a notification.

Conclusion

As we added more types of messages that were used by different parts of the app, it became more important to document the schema of these messages. We use an OpenAPI specification to document the schema of our REST API and applied this same pattern to real-time messages by treating them like endpoints. This allowed for all client teams to easily consume any new messages that were added and understand how they could be used.

After allowing members to see which classes their friends were in, we built on top of this by allowing them to see their friends while they were in any class, including On Demand classes. We were then able to work with our Leaderboard team to provide an experience that better connected members to friends in class as well. This real-time messaging infrastructure gives us a base to expand upon for new features in the future.

Using Real-time Messaging at Peloton was originally published in Peloton-Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

We gave this talk at Droidcon 2018.

The Android team at Peloton has grown a lot recently. Our team has grown to 5 times the number of engineers it was 18 months ago, and what we have learned during this rapid growth is that teams need to work differently at different sizes. This is evident in both the ideal workflow and communication patterns of teams.

Small Teams

Smaller teams are often concerned with the rapid delivery of new features. They are trying to get new things shipped and are often only focused on one or two features at a time. Communication is easy and direct within the team as well as with other stakeholders such as product or QA.

Larger Teams

Larger teams may find themselves broken into sub-teams and working in parallel on a diverse set of features, often on different timelines. Communication is no longer direct across the greater team and yet is even more important since sub-teams can develop their own patterns that could end up clashing.

So, how do you grow while remaining productive?

First, we have to define what we mean by a team being “productive.” For us, this includes engineers being efficient when developing, having features be of a high enough quality to be releasable, and delivering said features to our end users. All of this needs to be done while not overloading any personnel or tooling involved in the process. Being able to make technical and process decisions as a group is part of being able to stay productive as a team.

Make a space where open discussions are held.

At the core of the process for making decisions together is a space where members of a team can have honest and open discussions. It needs to be an inclusive venue where any member of the team can contribute as little or as much as they are comfortable with. Individual seniority doesn’t matter in this venue, except for when it is used to backup a particular line of reasoning with examples and experience. No question or issue is too small to bring up either, including team processes..

At Peloton, this is a weekly one hour meeting where all Android team members are invited. A document is created after each of these for the next week’s agenda, and anyone can contribute to it throughout the week. The first thing we do in this gathering is review the previous week’s action items in order to keep everyone accountable for tasks that they signed up for. The rest of the meeting is spent in discussing issues on the agenda and making decisions as a group.

Your decisions must be actionable.

The decisions you arrive at as a team need to apply to all the members of your team. If individuals or groups are excluded, you risk creating tiers within your group. Some decisions can be made in the room with just a short discussion while others will require investigative work or a proof-of-concept project to back up the decision. Assigning this work to volunteers in the group as action items helps move the work forward. Remember, you will review these action items in following meetings and receive progress reports from the assigned volunteers. Once they are done and present their work, you can make a decision to proceed or not as a group.

Communicate your decisions…

The decisions you make won’t matter much if people are not aware of them. What convinces the rest of your group that the right thing is being done is knowing the “what” and the “why” of each decision. Documenting these improves communication and has the extra benefit of making onboarding of new team members much easier.

…and enforce them

The trust behind this process is that the decisions you make are enforced by the entire group. It shows your team that if they follow the process and bring up an issue or suggestion, it will be discussed and any outcome will be communicated and enforced.

Where possible, you should use tooling to do this. It is easier with things like code style since a simple lint rule can cause pull requests to be flagged. Enforcement becomes a bit harder with things like patterns (e.g. MVVM) or usages of specific libraries.

For decisions that are more difficult to automatically enforce, use code reviews. Your entire team is aware of the rules and should comment on code when these are violated. This is also a great way for new members of the team to learn the “right way” to do things. They are simply pointed to the right pieces of documentation as they go through their code review comments.

When things change, iterate.

While trust behind the process is enforcement, the real power of it is in iteration. The reality is that your environment will change over time. This can include the makeup of your team, your requirements, the ecosystem you are developing in, or all of the above.

Use your discussion venue to revisit previous decisions and check if they are still applicable to your current situation. Questioning your past decisions can also lead you to find better ways to solve the problem. A good sign that it is time to revisit a decision is when the original reasoning behind it no longer applies. Basically, if the answer to the question of “why did we do this” is something that may no longer apply, it is time to revisit that decision.

Iteration also allows you to make a good decision, and not wait to make a perfect one. Any move in your team that improves your current situation is a positive move. It also allows you to question the process itself. If the way you setup your discussion venue is no longer working out, discuss it, and see if the group can come up with a better solution.

Example: The `googleJavaFormat` plugin

Just like most growing teams, our Android team at Peloton had issues deciding exactly what code style we should follow. As most readers will know, this means religious arguments on the number of spaces to indent a line, where do curly braces go, and most of all what should be your the maximum line length. Just like most teams we used our discussion forum to work through these one by one.

However, during one of our weekly team meetings a team member suggested we use a highly opinionated formatter instead of trying to decide and enforce every formatting rule. We investigated what this would look like in practice and realized that while no one will be 100% happy with the outcome, the formatter completely removed the ambiguity. There is one way to format your code and that’s it. This completely removed the cognitive overhead that was connected to Java code styling and formatting.

Example: Github CODEOWNERS

At Peloton our Android team ran into the problem that all growing teams face. One engineer made a minor change and a fellow team member reviewed the change and approved it. This is not an issue of course, this is the regular course of work, but for the reviewer, the change did not include enough context to flag issues that may arise. The story then follows a very predictable course, ending with a bug in production. All of a sudden, a tiny change in the code base causes unexpected behavior somewhere else. The underlying cause has to do with the structure of the code base and the component changed. No component should be able to cause this big of an unexpected change.

The two engineers involved brought this up in one of our weekly team gatherings and the group proceeded to discuss long term solutions. Something that came out of the conversation was the usual “how can we prevent this for now?” question. Someone on the team had experience with GitHub’s CODEOWNERS feature and we decided to immediately add code owner definitions to sensitive parts of the code base. This means that team members with context on specific areas get added to pull requests and get a chance to glance at them to ensure strange side effects don’t happen. We also instituted a rule that if the author and the reviewer do not have full context on a component, and the code owners set up isn’t suggesting a reviewer, it is up to the author to find who to add in order to get a thorough review.

Considerations

We’ve had plenty of success using this process, but as we all know nothing is perfect. There will always be some things that require thought and consideration with any process, including this one.

Continued Growth

We’ve successfully scaled this process from 5 to roughly 20 engineers and found that it worked well within that range. There is the feeling that as we keep growing, it might be difficult to get everything done in one meeting. The plan here is to start to split up to more concentrated town squares and go from there.

Minority Opinions

It is nearly impossible to get a group of engineers to all agree on something. Even if we have a majority opinion we may end up with dissenters who are passionate about their point of view. One of the most important parts of this process is that everyone needs to be heard. All ideas need to be considered and we need to be ready to explain why something is not right for our team. Be sure to document the “why” here as this alleviates the stress of explaining these decisions to new team members.

Action Items With No Progress

Not having forward progress on action items can lead to losing trust in the process. Team members need to be held accountable for tasks assigned to them to ensure we maintain momentum. Remember to review these items at the start of each town hall and ask for assignees to provide an explanation for why certain tasks have not been completed.

Time

The town halls and all the work that comes out of them take time. It is imperative that the rest of the organization buys into the process and understands that time spent now is better than having to spend even more time later on. Every action item we complete should help diminish how long things take down the road.

But it’s worth it!

This process has allowed us to adapt to a growing team, with changing requirements, in an evolving ecosystem while delivering consistent, high quality work, with a low defect rate. Everyone has a voice and engineers are empowered to push for positive change. Finally, we have a clear process to improve and learn.

Growing While Remaining Productive was originally published in Peloton-Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Strava is a new integration we recently launched that brings the best of social networking and the quantified self movement to the Peloton community. Launching the Strava integration was a group effort that required the coordination of three teams: developers, product and design. We took some time to talk to our team to understand the collaborative effort that brought this project to life.

Why is the new Strava integration such an exciting launch?

Dave, Product Manager: The launch of our Strava integration is a step toward holistic fitness tracking for our users. Since Peloton riders are active beyond the bike (they are runners, outdoor cyclists, etc), we are excited to give them a way to track all of their fitness activities in one place.

How are the riders able to use this? What are the specific features?

Dave: Peloton riders can now use Strava to track and measure their progress and ride results. This creates a fun new way to see and share the history of your workouts, further enhancing the Peloton riding experience.

A really cool feature that was actually Ben’s idea was the ability to auto-post any future rides to Strava. So, rather than having to worry about sharing to Strava at the end of your ride, there’s a setting that you can activate that will automatically share your ride to Strava.

How will this impact Peloton riders?

Dave: I think for existing Strava users they’re going to be really excited to have this data be in sync with their fitness activities. For users who don’t know what Strava is, this is going to really turn them onto a really exciting fitness platform. This is just another reason to get out there and be active!

What was the interaction like between each team for this feature to come alive?

Swarna, Software Engineer: The communication between the product, dev and design is crucial in all projects. The communication is very effective when product and design understand the technical challenges involved and then dev understands the actual rationale behind the requirement.

​The coordination between design, product and Android was clear and that helped us to create smooth animations during the Strava upload. ​For example, a 45 minute Peloton ride takes approximately nine seconds to upload. It would be a bad experience for t​he ​user if ​Android’s default ​infinite loading bar ran during the upload.

​Eric, our multimedia creative director, came up with a loading progress bar that provides the status for the upload. This was challenging due to Android’s limitations. Android only knows if the upload is completed successfully or not. By setting up a max time limit and by animating the progress status, we were able to overcome this obstacle and create a pleasing user experience.

What was the most exciting part about this project from your personal perspective?

Dave: For me, it was taking my first ride that I could share to Strava. Doing pre-launch testing and being able to see what it looked like and having people like it on Strava. That was cool and exciting.This is Strava’s first experience in the indoor cycling market so having them be just as pumped up about this project was a huge bonus.

Ben, Software Engineer Manager: The most exciting part about this is that I’ve never used Strava before. Dave got me into Strava and it’s something that I’ll be able to use myself, so that’s pretty awesome!

Want to learn more on our Strava launch? Click here.

Talking Strava / How our teams came together for a successful launch was originally published in Peloton-Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

We see so much of Peloton’s action on the bike and in the studio but what is at the core of our operations is our amazing tech team making it all happen. We got to talk more with one of our software engineers, Cezar Cocu, to learn more about his role and experience in the Peloton tech space.

1. What is your role at Peloton? What does your job entail?

I mostly maintain the iOS app on both the retail side and on the consumer side. That’s how we refer to it internally. We have a consumer app used for viewing live streaming and on-demand rides, and then we have an internal app for POS (point-of-service) transactions like buying the bike and apparel items, which our retail stores use.

2. How did you get into this field?

I’ve always enjoyed computer science in school. I enjoyed making stuff with computers. When it comes to iOS, I think I just fell into it. I wanted to do something cool, and probably the easiest way to get started is either to create something on the web or create something on a mobile native interface, like Android or iOS. I happen to have an iPhone, so I was like, “I’m going to start doing the iPhone.” That was really it. I had an iPhone, and I wanted to do something on mobile natively.

3. What attracted you to working at Peloton?

After college I joined an agency. I did that for a little bit, working on different projects, like three months here, three months there. I thought I would enjoy that, and I really didn’t. I wanted to work at least on one project for a longer duration of time. Some people really enjoy jumping from project to project to project. I didn’t particularly enjoy it. When it comes to software, if you jump from project to project to project, sometimes you don’t have to deal with the consequences of your decisions. When you work on something more long term, you deal with that constantly. You’re always making trade offs. “Let me fix this. Let me do this. Let me put in the time to get that.”

4. How is Peloton different than any other tech company?

We own the entire stack. From creating the content all the way to the bike itself. It’s incredibly motivating as an engineer to be seen as value creator instead of a cost center. Because we’re still small, the way everything works is just based on trust. Our Project Managers trust that you’re going to get it done however you’re going to get it done, so you don’t have to deal with politics, which I appreciate because it’s more natural. It’s a natural way to do things. It’s not about what I appear to be doing, it’s what I pump out on the other end. My work is about the results. Teamwork is huge as well. There has to be that trust there where you have to make sure that it can be possible or it can’t be possible. It’s a little bit more high-stakes. There’s less of a fail-safe system, which is cool. I like that. Working at a startup is more about learning and growing as a developer than it is for pumping out stuff. You have to go at a faster pace and you get to learn more because you’re handling so many things.

5. What was your first project?

The iPad app. We made it cooler. We added more rides and improved the customer experience, resulting in a near 5-star app.

6. Why are you excited about the iPhone app launch?

The amount of devices and people who own and use an iPhone is much greater than the iPad. The iPhone is a more personal device. We’re able to reach a broader audience. The users are engaged and we get tons of feedback. It’s a better experience!

7. How important is the TECH aspect of Peloton to the company as a whole?

Very important. That’s one of the reasons why I picked this company. A lot of other fitness companies the tech aspect doesn’t really enable them produce the bulk of their product. Obviously, for us we manage the tech side, hardware, and produce the content all in-house.

8. What are you most looking forward to building/making next year at Peloton?

We can’t talk about a lot of the things we have planned. However, we are looking forward to adding more exciting features to iOS and bringing Peloton content to an even greater audience.

9. What sort of personal software or hardware project do you work on outside of Peloton?

I made a Metro-North train schedule app plus some other open source components.

10. Finally, what 3 words would you use to describe the work you do at Peloton?

Fun, challenging and collaborative.

Tech Stories / Cezar Cocu was originally published in Peloton-Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

From Static to Rich : The Obstacles

Within Peloton’s webapp, we provide our users the ability to see their performance for each class they take. Included within this report is a chart that maps their cadence, power, distance, calories burned, and heart beat. Users can opt to “Share” this report to Facebook, but doing so simply provides a link back to our webapp, with no visual representation of the workout, just a static brand image that we feared was becoming redundant.

While brainstorming ways to extend our features abilities, we proposed a system that allowed the user to share a “snapshot” of this graph — the only problem was, the graph wasn’t an image, but a living-breathing SVG based data representation that had no home on a server. Thus, no URL to access with an image MIME type.

As far as Facebook’s JavaScript SDK documentation goes, the only mention of sharing images to a user’s feed assumes the passing of a URL where said image resides. Facebook will then transload the image, run their own compression processes, and publish it accordingly. As such, the initial proposal for our post-graph-to-Facebook process included creating our own PNG snapshot and uploading it to S3, then returning that newly-created image URL to Facebook. That sounded perfectly fine, but we knew there had to be a better, faster way.

Leveraging Technologies : Canvas to the Rescue

“[The HTML5 canvas element] is part of HTML5 and allows for dynamic, scriptable rendering of 2D shapes and bitmap images. It is a low level, procedural model that updates a bitmap and does not have a built-in scene graph.” This element has many uses including: web game development, graph and chart rendering, and interactive applications, to name a few.

Though our performance graphs are SVG-based (vector) and not drawn in canvas, we knew we could load SVG’s onto canvas or use a similar process to extract our Base64 encoded image data. The first step was getting that Base64 encoded data from our canvas element:

var canvas = document.getElementById(‘canvas’);
var dataURI = canvas.toDataUrl();

Then, we needed to find what we cared about:

var imgdata = dataUrl.match(/data:(image\/.+);base64,(.+)/);

From there, we converted the data to a Blob: “A Blob object represents a file-like object of immutable, raw data. Blobs represent data that isn’t necessarily in a JavaScript-native format. The File interface is based on Blob, inheriting blob functionality and expanding it to support files on the user’s system.”

function dataURItoBlob(dataURI, mime) {
  var byteString = window.atob(dataURI);
  var ia = new Uint8Array(byteString.length);

  for (var i = 0; i < byteString.length; i++) {
  ia[i] = byteString.charCodeAt(i);
  }

 var blob = new Blob([ia], { type: mime });
 return blob;
}

var blob = dataURItoBlob(imgdata[2], imgdata[1]);

Once our data was represented as a Blob, the last step was to use the the FormData object which we could send to Facebook in our POST:

var fd = new FormData();
fd.append(‘access_token’, $scope.facebook.authToken);
fd.append(‘source’, blob);
fd.append(‘message’, $scope.canvas.background.getCaption());

Above, you might notice Angular $scope variables as we used AngularJS for this application. Below, is the final piece that uses Angular’s $http to POST and pull the thread through:

$http.post(‘https://graph.facebook.com/me/photos?access_token=' + $scope.facebook.authToken, fd, {
 transformRequest: angular.identity,
headers: {
‘Content-Type’: undefined
   }
})
.success(function (res) { // Success logic })
.error(function (res) { // Error logic });

The Prototype : Precursor to Implementation

As with any new feature, we thought it best to test the waters and see how this approach would work in the wild, without a complete rewrite our our existing implementation. It just so happened with Valentine’s Day around the corner, our social and marketing teams were dreaming up ways to engage our users on social media. The idea was to create an interactive Valentine’s Day app that allowed the user to customize a Peloton-themed candy heart, as well as tag their friends, and share their own message.

Using HTML5 Canvas to Post Directly to Facebook was originally published in Peloton-Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today, SQL NYC will be hosting a meet-up event in our office from 6:30–8:30pm.

This evening’s topic is about “Database Architecture & Scaling Strategies, in the Cloud & on the Rack”. Pizza and beer will be provided (as always), so please feel free to grab a slice and listen in!

For more information, please RSVP here. Hope to see you there!

Time synchronization is a hard problem to solve. Layer on various ways to handle leap second, issues might be even more obscure. AWS and Akamai both use a technique called time smear. Make sure all your services agree on how to handle that extra second!

Happy Leap Second Day! was originally published in Peloton-Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

$scope Broadcasts

To be perfectly honest, these are messy. We avoid broadcasting through $scope like the plague. We believe that the point of these events are for very high level angular operations to broadcast their events as an API. Take the ‘$destroy’ event for example, it is provided as a piece of an API so that the developer has a convenient hook to destroy their directive in the appropriate fashion. So then how do we broadcast information across our angular application? Our solution involves rolling our own isolated PubSub mixing throughout our angular services.

Service Broadcasts

Services/Factories/Providers do not come built with any method of broadcasting information. Our first attempt to solve this was to namespace $rootScope broadcasts and send information around that way. While this was the easier solution, we quickly abandoned this approach because we preferred a more explicit way of communicating from services. The solution then became to roll our own PubSub into our service layer via a mixin. The basic PubSub mixin looks like this:

angular.module(‘app’)
  .factory(‘PubSub’, [‘$rootScope’, function($rootScope) {

    function PubSub() {

      this.observers = {};

    }

    PubSub.prototype.on = function(name, fn) {

      this.observers[name] = this.observers[name] || {};

      var key = Object.keys(this.observers[name]).length + '';

      this.observers[name][key] = fn;

      return key;

    };

    PubSub.prototype.off = function(name, id) {

      if (this.observers[name] && this.observers[name][id]) {

        delete this.observers[name][id];

      }

    };

    PubSub.prototype.broadcast = function(name, event) {

      if (!this.observers[name]) {
      
        return;
      
      }

      var observers = this.observers[name];

      Object.keys(this.observers[name]).forEach(function(key) {

        if (!observers[key]) {
          return;
        }

        observers[key](event);

      });

      if (!$rootScope.$$phase) {

        $rootScope.$apply();
      
      }

    };

    return PubSub;

}]);

To extend this, we include it when we create our service like so:

angular.module(‘app’)
  .factory(‘SomeService’, [‘PubSub’, function(PubSub) {

    // constructor, implemented like you would an angular service
    var SomeService = function() {

      PubSub.call(this);

    }
    
    angular.extend(SomeService.prototype, PubSub.prototype);

    return new SomeService();

}]);

This then allows us to listen to the broadcast in other locations that would import this.

angular.module(‘app’)
  .controller(‘SomeController’, [‘$scope’, ‘SomeService’,   
    function($scope, SomeService) {

    var listener = SomeService.on(‘update’, function(data) {

      $scope.data = data;

    });

    $scope.$on(‘$destroy’, function() {

      SomeService.off(listener);

    });

}]);

The above approach works very well if you like a more explicit way of listening to services. The approach however does not work very well when listening to controllers.

Directive Controllers

The approach we take to listening to controllers came about when we figured out why we would listen to controllers. We wanted to listen to controllers specifically when communicating between directives. It was then that we realized that angular already had this functionality built in. They have done a good job of documenting this implementation here.

The concept is that instead of using $broadcast/$emit, you would rely on your controller to update your dependent directives in the fashion of the mediator pattern.

Using these three types of communication in conjunction with angular’s built-in two-directional bindings should decouple and clean up most cases where you would otherwise have messy events and watches flying around in all directions. For a higher level view of keeping your applications scalable, I suggest reading through this link in order to inform yourself of the many ways to design pieces of your application.

Communication within Angular was originally published in Peloton-Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

The talk touched upon a lot of things, such as: learning how distributed databases can serve as a solid foundation for massively-parallel and instantly-scaleable distributed computing, leveraging NoSQL technologies, and its community, as it contributes to the architecture of a ‘future computer,’ and practical matters of large-scale distributed system design.

There were nearly 250 people in attendance, and we were happy to make some new friends! Check out more photos from the event here. We will update this post once the live-stream recording is available.

EVENT RECAP: The Future of Cloud Computing and Databases was originally published in Peloton-Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

You can read all about the event in detail on Meetup.com.

The Future of Cloud Computing and Databases NoSQL Meetup was originally published in Peloton-Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.