DocuSign Dev Blog

Brought to you by the development teams at DocuSign

Americano, made with an improved Espresso machine.

by Stephen Parish

Today we are publishing Americano, an open source Android library of helpers to build on top of Espresso, an Android API by Google for writing reliable UI tests. Along with the release of Americano, we also want to cover the useful improvements we’ve made to our own fork of Espresso.

The two are meant to be used together, but if need be, Americano can be used completely with the current version of Espresso released by Google.

more »

Jeeves, an Open Source Webdriver

by C.J. Winslow

Our previous post covered a high-level overview of the tech stack behind the New DocuSign Experience (or as it’s still called internally, Martini). Today, we’re excited to announce the release of our open source webdriver, Jeeves, a tool that helps ease the pain of writing automated browser UI tests. This tool is the cornerstone of our test framework and drives nearly all of our UI automation for the New DocuSign Experience. This post explains the reasons why we built it, and how it differs from other currently available tools.

more »

The new DocuSign experience, all in Javascript

by Ben Buckman

Screenshot of The New DocuSign Experience

We recently launched The New DocuSign Experience, a reimagining of our primary web application used by 45 million users.

The app is built in Node.js and uses the REST API as its data store. We’re proud to have built the entire app on an open-source stack, and plan to share a lot of our code in the coming months.

We aimed to follow best practices throughout: DRY modular code; automated deployment, provisioning, and continuous integration; (a goal of) 100% automated front-end testing; two-week sprints and releases, with scrums combining dev+QA+UX+product; utilizing the latest browser capabilities while degrading gracefully for older browsers; and using Git-flow and Github-style workflows.

The project first began in June 2012 with one developer and a vision of building the next-generation web app as a front-end layer on top of the API. After a period of prototyping and setting the groundwork, the project (codenamed “Martini”) kicked into high gear around a year ago. The team now consists of twelve developers, including three dedicated to QA automation; a team of designers, two product managers, and all the other amazing support (ops, program management, facilities) that keep the servers humming and the stars aligned.

We launched a public beta in September, and became DocuSign Beta; now we’re official, but we still affectionately call the project and team Martini.

Ubiquitous Javascript

Martini is built on an all-Javascript (actually CoffeeScript) stack. On the backend that includes Node.js, Express, Request, and Winston, among many other libraries. Ubiquitous JS means we can share code and patterns between the front- and back-ends: Backbone.js handles models, views, and routing client-side, as well as parallel models server-side. All our coffee/js files use the same module pattern, bundled by Stitch for the browser. Templates on both sides are in Jade. Stylus preprocesses our CSS. We use Redis for sessions and caching. The app uses the DocuSign REST API (a highly scalable, carrier grade system built on the .NET stack) as its data store, so we don’t need a full database.

To support the entire new experience, our API grew from serving a relatively narrow set of third-party use cases to supporting every customer-facing application function. Not all of these API features are public yet, but they will be soon.

more »

Absolutely Relatively, Floatless

by Derek Bredensteiner

Or how I learned to stop using floats and love absolute positioning.

Part 1: Bootstrap style floats without floats

Lets say you want to have some things.

10 things.

Each thing has “words and stuff” in it.


more »

Chrome DevTools Tips

by Eric Levin

Or what I wish I had known when I began my journey as a web developer

Learning how to use the Google Chrome dev tools marked the inflection point in my journey towards becoming a web developer. When I started learning web development, I had heard vague rumblings of these tools, but didn’t put in too much time researching them, as I believed it was more important to first learn the “basics.” What is the DOM? How does it relate to HTML? How does CSS style an HTML element? And how does Javascript fit into all of this? I regret to report that I spent a lot of time reading through w3schools articles.

I don’t think it’s an exaggeration to say that if I had just dove right in and started learning and playing with the dev tools, I would have learned so much more about all of these topics, and in a much more powerful, experiential way to boot. The dev tools don’t just tell you how the DOM works, they show you.

For today’s post, I’d like to walk you through some of the tips I learned after having used dev tools for a while that I’d wish I’d been shown on day one.

more »

Custom Scalable CSS Radio Buttons

by Azat Mardanov

Radio buttons are essential when building forms and dialogs. Sadly enough, there are limited options for styling them. Developers might use one of the following methods to a certain degree of success:

However, at DocuSign we have a very specific requirement — the user needs to be able to “zoom in” on the document and the radio buttons need to get bigger.

We call this “scalable” css buttons, because we need many things to increase in size as we “zoom in” (such as the border thickness).

We use CSS to re-draw the default HTML radio buttons. We did it by hiding the default <input> field, using <label>s with the for attribute and a nested div with border-radius. This way developers can control radio buttons to a pixel (presumably with server-side or front-end width/top/left manipulation).

more »

Building a Redis Sentinel Client for Node.js

by Ben Buckman

We use Redis for sessions and for a short-lived data cache in our node.js application. Like any component in the system, there’s a potential risk of failure, and graceful failover to a “slave” instance is a way to mitigate the impact. We use Redis Sentinel to help manage this failover process.

As the docs describe,

Redis Sentinel is a distributed system, this means that usually you want to run multiple Sentinel processes across your infrastructure, and this processes will use agreement protocols in order to understand if a master is down and to perform the failover.

Essentially, each node server has its own sentinel corresponding to each redis cluster [master and slave(s)] that it connects to. We have one redis cluster, so for N node servers, there are N sentinels. (This isn’t the only way to do it - there could be only one sentinel, or any other configuration really, but the 1:1 ratio seems to be the simplest.) Each sentinel is connected to the master and slaves to monitor their availability, as well as to the other sentinels. If the master goes down, the sentinels establish a “quorum” and agree on which slave to promote to master. They communicate this through their own pub/sub channels.

The sentinel is not a proxy - the connection to the sentinel doesn’t replace the connecton to the master - it’s a separate instance with the sole purpose of managing master/slave availability. So the app connects to the sentinel in parallel with the master connection, and listens to the chatter on the sentinel channels to know when a failover occurred. It then has to manage the reconnection to the new master on its own.

Redis Sentinel Client flow diagram

We’re using the standard node_redis library, which is robust, easy to use, and works “out of the box” for things like sessions. But a year ago, when Sentinel started to gain adoption, the best approach for adding Sentinel awareness to node_redis clients wasn’t clear, so a thread started on Github to figure it out.

One simple approach was for the application to simply hold two connections, for sentinel and master, and when the sentinel reports a failover, to reconnect the master. But the way node_redis works, any data in transit during the failover is lost. Also with this approach, the code listening to the Sentinel’s pub/sub chatter lived in the application, and wasn’t as encapsulated as we thought it should be.

So we decided to create a middle tier, a redis sentinel client, that would handle all this automatically.

more »


DocuSign Hackathon 2013

For two days last month, all the DocuSign engineering, design, and product development teams converged on San Francisco for a company hackathon. It was an opportunity to put aside sprint goals and product roadmaps for a little while, think completely out of the box, work with people we don’t usually work with, and build some awesome new features and prototypes.

Some teams built internal tools to streamline our workflows and automate previously-manual processes. Many of the proofs-of-concept were customer-facing features that will be put on the product roadmap. One team imagined ways HTML5 camera support and real-time chat could be integrated into the product. Another project added real-time editing to our Send flow. There was a visualization of DocuSign usage with dots all over a 3D globe, that we hope to put on a big screen in the office soon.

One of the projects was creating this dev blog. So, welcome! We hope to introduce you to our great teams, show you all the cool stuff we build, open-source some of our code, and stimulate many interesting conversations.