Aptible’s UX Engineering team has recently launched version 1.0 of our in-house design system, 

 (Arrow DS for short). In this post, I’m going to walk you through some of the frameworks and tools we use and show off one of our more complicated components.

At Aptible, we place a lot of emphasis on creating high-quality and consistent experiences for our users. Each page, dropdown, tooltip, and modal should feel like they are part of a cohesive system. Building with a design system helps our users recognize and understand patterns throughout our products. Having a consistent, high-quality front-end experience makes our software easier to use and gives users more reason to trust our products.

We also want to be able to build and learn quickly. A design system gives engineers the building blocks they need to assemble pages and features at a quick pace, taking some of the more repeatable, tedious UI work out of their hands.

The reason for building Arrow as a standalone repository is that it creates a definitive line of separation between the product (owned by Product Managers and Engineering) and the design system (owned by Product Designers and UX Engineers). Product Managers and Engineering primarily control the direction of our user-facing product while Product Designers and UX Engineers control the direction of Arrow. By treating the design system as a separate, standalone service, we are able to properly invest in it independently of product feature requests.

Side note: If you aren’t sure what a UX Engineer is, check out our 

Arrow DS is a big library with a lot of moving parts. Aptible’s UX Engineering team leveraged many different frameworks, tools, and libraries to construct version 1.0. Here are a few of the most important.

 listed React.js as the second most popular web framework. It has widespread adoption, is great for single-page applications, and has an excellent ecosystem of libraries and other tooling to help us build our products.

 is a CSS framework that comes with lots of utility classes that can be leveraged in Arrow’s CSS (using the `@apply` directive with PostCSS) or used directly on elements. These utility classes are generated from a configuration file within Arrow that we can customize. For example, the class `m-2` will add a margin level 2 (which we currently have defined as `8px`) to the element. Most styling in our front-end applications can be done with these utility classes, resulting in very little actual CSS being written outside of Arrow.

 is an open-source tool for developing components outside of any application. It also serves as a documentation platform with the 

. Storybook is a dev dependency of our core `arrow-ds` repository and is automatically published with every new release. Check out our published 

 is a library we use to fully automate our Arrow DS releases. Each commit to `arrow-ds` is labeled with the type of changes contained within. Some examples are “fix” for a bug fix, “feat” for a new feature, and “chore” for changes related to the build process. A full list of the types of commits can be found within 

 (which Semantic Release uses by default). When changes are merged to the master branch, Semantic Release looks at what types of changes are involved, determines what type of release to make (major, minor, patch, if any at all), and puts the new version of our package onto 

 is a tool that gives UX Engineers the ability to link the arrow-ds package to another repository locally. This is helpful for testing new features before publishing a new version of the `arrow-ds` library.

The Drawer component is one of our most complex components. It slides a menu of filters in and out of the viewport from the edge of the page while pushing over existing page content (usually a Table with as many as 250 rows), and it has to do this as close to 60 frames per second as possible. Before digging into some of the details, 

The biggest challenge with this component was achieving high animation performance. As you can see from the demo, there’s a lot going on as the Drawer slides in from the left side of the page. The TopBar component above the Table shrinks to accommodate the Drawer, but the Table does not. Animating the width of a complex component like a Table isn’t possible without significant performance issues. This is because the browser is having to repaint the entire Table with each animation frame, and the machine just can’t keep up, leading to low animation frames per second (FPS).

To solve this problem, we first lock the width of the Table before the animation starts. This prevents the browser from constantly repainting the Table as it changes width. Then we use the GPU-accelerated CSS `transform` property to move the table. When using `transform`, the browser takes a snapshot of the element and hands it off to the machine’s GPU for animation (a task that graphics processors are specifically made for), resulting in much higher animation FPS. 

For more information on CSS GPU animation, check out 

 from Smashing Magazine. The article is a few years old at this point, but it is still helpful in illustrating how CSS leverages your computer’s GPU.

While we’re excited about Arrow’s 1.0 release, we know there are still a lot of ways we can improve our design system. Here are a few things we’d like to do soon:

Want to see Arrow DS in action? Check out the 

Aptible’s UX Engineering team has recently launched version 1.0 of our in-house design system, Arrow Design System (Arrow DS for short). In this post, I’m going to walk you through some of the frameworks and tools we use and show off one of our more complicated components.

Building Aptible’s Design System

In redux, a slice is a "slice" of your redux state object.

 is an import concept in redux where we compose multiple reducers into one big reducer using 

. For every slice, there is a single corresponding reducer. When building store data inside redux, it is very common to build a set of actions and a reducer that responds to those actions.

createSlice is a higher-order function that accepts the slice name (e.g. token, user, todos), a set of reducers, and returns a single reducer along with the action creators for that reducer. The goal of createSlice is to reduce the boilerplate required to add data to redux the canonical way.

 we know of today from redux-toolkit was inspired by 

 and have been using it for every redux project since. It is a powerful helper function that has gained a ton of popularity in the redux community.

However, it is common for engineers learning redux for the first time to be completely overwhelmed by the terms and phrases used by the redux community. This is exacerbated by the fact that every reducer is now wrapped by createSlice.

So let's build it from the ground up to really understand it!

In order to build our own createSlice we need to build a couple of other helper functions first.

Note: as a learning guide, all of these implementations are simplified versions of the official ones. If you dig into the redux-toolkit source code, you'll see that most of the code are typings and embellishments on top of the code written in this article.

For our example usage we will be recreating redux's 

createAction is a simple helper function that accepts a string and returns an action creator.

createReducer is a function that accepts an object where the keys are the action type and the values are the reducer.

The redux-toolkit version of createReducer leverages 

 to handle state updates. I won't go into the details of how immer works but just know that it is a clever way for the end-developer to appear to mutate their state object while under-the-hood immer actually handles updates to the state in an immutable, redux-friendly manner.

For the purposes of our demonstration, we will not be using immer.

Okay, now that we have our implementation for createAction and createReducer built, we can move onto building our createSlice.

This article demonstrates how leveraging a few simple helper functions significantly reduces the amount of boilerplate code required to add state and reducer logic to your redux app. All three of these functions can be used independently of each other. I also hope this article demystifies createSlice, which is now considered the canonical way to use redux.

Recreating redux-toolkit’s createSlice

If you have a product and customers, then you also have members of your team who need access to critical systems in order for your company to function. Safeguarding credentials that can access these systems via mechanisms like 2FA, U2F, and key rotation is necessary but not sufficient. You must also monitor for key security events and review each to ensure your protections are working as intended.

Here at Aptible, we’ve solved the problem of monitoring and requesting approval for security events via a lightweight Slack integration we built called Powertrip. With Powertrip, we are able to send Slack notifications to relevant team members about key security events within minutes of the event happening.

To get a better picture of how this works, let’s review how Aptible tackled monitoring SSH login activity using Powertrip.

The first step is setting up monitoring for the logins. This can take two forms:

At Aptible we use both approaches across our security program, but for alerts that benefit from being as real time as possible we’ve opted to rely on webhooks where possible. There are a few reasons for this:

Our monitoring needs to provide us with enough information to successfully determine who triggered an event, when the event happened, and what the event actually was. For SSH logins, this means knowing who logged in, which server they logged into, and when the login happened.

OpenSSH logs a message for each successful SSH connection. Using webhooks offered by our logging provider, our application can be notified about each successful connection logged by OpenSSH. The notification sent by our logging provider looks something like this:

Conveniently, this log message contains much of the contextual information we need to create a useful notification - in a standard format - that’s easy to parse. With one simple regex, we now know who logged in, and from what IP address:

Our logging provider also provides some extra contextual information, including the timestamp of the event and the hostname of the server that logged the message, so that we can answer the major questions the log line can’t: which server was logged into and when.

By setting up one webhook and using one regex, we now have a useful security event! We can now tell that oswaldo logged in from IP 10.0.0.1 to the server bastion.test at 1:02 UTC.

Now that we know an event happened, we need to tell someone about the event. For SSH events, it probably makes the most sense to send a private message directly to the Slack user associated with the login event, since hopefully that person knows whether or not the SSH activity is legitimate. To do this, we keep a map of unix username to the associated Slack user.

Events can’t always be tied back to a specific person, however. In this example, oswaldo is a bot, not a person. That said, oswaldo is a bot with a wide range of access, so it’s still important to monitor oswaldo’s activity. Since there’s not a single person we can DM to approve oswaldo’s activity, we instead push the Slack notification to a channel monitored by our entire security team.

We don’t want to assume that just because we sent a message via DM or to a channel that someone saw the notification. Instead, we require approval of each notification using Slack's message buttons feature.

And when that doesn’t work, notify again

Sometimes, one notification isn’t enough. Maybe oswaldo has a task to run at 1 AM, when the entire security team is asleep, or a person’s account is compromised while they are on vacation. In these cases, it’s even more important that the notifications aren’t missed. This is why we periodically re-send Slack notifications for any events that haven’t been approved. When re-sending notifications, we always send to the channel monitored by the security team, even if we can map activity to a specific user. This allows us to not miss malicious activity just because someone is on vacation.

One monitoring source isn’t always enough

With the few easy steps above, Powertrip sends us Slack notifications for all SSH activity across all of our critical systems, which is a huge boost to our security program. But all of this falls apart if we receive a log message Powertrip can’t process or Slack is down. It’s difficult to cover every possible failure condition, but in areas where the risk is high, it’s useful to have a backup plan.

 also records every successful login. We track approvals that happen through Powertrip, and any approvals recorded by Powertrip are auto-approved in HIDS. Having the additional monitoring from HIDS means that if for some reason a Slack notification is missed, a member of our security team will still see and sign off on the SSH activity as part of the regular HIDS event review process.

Using Powertrip to track and approve SSH logins is easy to set up, is easy for team members to approve activity, and is a huge boost to our security program. Since it’s so easy, why stop with SSH activity? The same approach will work for monitoring a wide range of other activities, including CloudTrail events, 

, and anything you can write a custom log line for.

Going on a Powertrip

An approach using simple Rails configurations

We recently rolled out updated HTTP security headers for Comply. Following best practices with HTTP security headers can be a quick way to add an additional layer of security to a website, so we wanted to share our work here in hopes that others might find it helpful.

When a visitor makes a web request to a server, the server will respond with the requested content, as well as with response headers. A subset of those response headers have to do with security. Specifically, they tell browsers how to behave when communicating with the server and handling its content.

Screenshot of the security headers returned from Aptible Comply's API

 (HSTS, discussed below), websites can force the browser to communicate with it solely over HTTPS.

HSTS and other security headers can ensure that a website’s content is being used in a secure manner by the browser, thus reducing exposure to security vulnerabilities.

Strict-Transport-Security: max-age=31536000

As mentioned earlier, this tells browsers to access a website using only HTTPS. HTTPS is HTTP run via a 

 connection, which is a secured, bidirectional tunnel for data between two parties. TLS (the successor to SSL) makes three guarantees:

Non-HTTPS websites do not have the above guarantees, and are thus vulnerable to 

. This allows an attacker to eavesdrop or alter information without the victim realizing.

Forcing browsers to visit via HTTPS eliminates the risk of unencrypted requests being intercepted. Simply redirecting HTTP requests to HTTPS is not enough - a man-in-the-middle attacker could intercept the response, strip the redirect, and impersonate the server on subsequent requests. Comparatively, setting the Strict-Transport-Security will cause the browser to immediately make the request over HTTPS.

One caveat here is that browsers only know to visit a specific website via HTTPS if they have received the HSTS header from that website in the past. And since the HSTS header has to be sent over HTTPS, visitors are still vulnerable to MITM attacks the very first time they visit a website (if done via HTTP). A solution here is to submit the website’s domain to the 

, which is a list of websites that browsers will know to visit via HTTPS by default, so that even initial visits will be done via HTTPS.

We have set our Strict-Transport-Security header’s max-age to one year (31,536,000 seconds). The max-age duration is reset upon each visit to the website. If the user has not visited the website for that entire duration, then the browser would be allowed to visit the HTTP version again.

This configures what referrer information will be sent in the Referer header (reference 1). It is possible a website has data in various urls that it does not want sent elsewhere as a Referer (e.g. IDs, password reset URLs), so configuring this reduces the risk of leaking information.

With our setting of strict-origin, we are enforcing only sending the origin domain in the Referer header, and only if the destination is just as secure (i.e. going from HTTPS to HTTPS). Going from HTTPS to HTTP would result in the Referer being omitted.

Expect-CT: max-age=31536000; report-uri=<reporting-uri>

This configures how a website reports or enforces 

 (CT) requirements. Certificate Transparency is a system of public logs that aims to record all certificates issued by publicly trusted certificate authorities, with the goal of helping domain owners identify mistakenly or maliciously-issued certificates.

When we enable the Expect-CT header on our website, we are telling the browser to check its certificate against public CT logs. We monitor certificates issued for our domains in the CT logs to check for erroneous or malicious certificates. Hence, if the certificate cannot be found on the public CT logs, it means it is a mistaken or malicious certificate. For Comply, we are using the third-party service 

 for reporting, so if this happens we will be alerted. If an issued certificate is found on the public CT logs (which we monitor), then there is no cause for alarm. Note that though Google Chrome 

, the report-uri configuration is still valuable to us.

Currently, we set the max-age to one year (31,536,000 seconds). Since the Expect-CT security header intends to guarantee the authenticity of HTTPS connections, the Expect-CT security header is only useful if requests are being made over HTTPS. Thus, implementing the Expect-CT security header with the Strict-Transport-Security security header is a sensical approach.

This indicates whether or not a browser should allow rendering of the requested page in <frame>, <iframe> or <object> tags. This helps mitigate 

 attacks, by ensuring that the requested page is not embedded into other websites. In fact, by setting it as DENY (as opposed to SAMEORIGIN), we prevent it from being embedded even on other pages of the same domain.

This configures how the browser treats the Content-Type header. If unset, browsers perform “

”, which is the browser attempting to guess the correct MIME type by looking at the resource.

This is important because handling a resource incorrectly could become an attack vector. To take advantage of this, attackers upload malicious code in files that could be misinterpreted and run by the browser as a different content type. For example, processing what the server thinks is an innocuous text file, csv, or image as a text/html file embedding harmful javascript.

Setting nosniff here, as we have done, prevents browsers from attempting that guess, though the website should make sure all of its assets actually have a proper Content-Type returned. Note that while configuring this header is relevant only if a website accepts uploads, it is cheap to implement and can prove useful in case the website allows uploads down the road.

X-XSS-Protection: 1; report=<reporting-uri>

This configures how the browser should act if it detects a 

 (XSS) attack. XSS attacks occur when attackers inject client-side scripts into websites that are viewed by others, and potentially access sensitive information that is stored, for example, in cookies. By setting this with a value of 1; report-uri=<reporting-uri>, we are telling the browser to sanitize the page if an XSS attack is detected, while also alerting us when it happens via our third-party reporting service.

Since we are using Rails as our backend, we added the following to config/application.rb:

Our Comply app is deployed using Deploy, so we 

 simply by setting the environment variable FORCE_SSL to ‘true’.

We hope you found some of these tips useful (or maybe even enjoyable)! Adding another layer of security to a website via HTTP security headers is a simple and effective way to further minimize security vulnerabilities. If you are as passionate as we are about data security, 

Securing websites via HTTP Security Headers

The landscape of front-end engineering has changed drastically in the last few years. In the past, front-end engineers were depended upon to translate design comps into functioning HTML, CSS and JavaScript. More recently, with the explosion of the JavaScript ecosystem, front-end engineers are now expected to work more broadly across the entire stack, and in some cases, have more of a traditional computer science background. So is there still a place for front-end engineers who still enjoy writing CSS?

UX Engineers sit between product design and front-end engineering and help facilitate collaboration between the two. They usually maintain similar technical skills as the front-end engineer, but they are more specialized in their knowledge of UX design principles and have a keen eye for design.

At Aptible, UX Engineers play an important role in helping shape the user experience of our products. For this reason, UX Engineers are members of the design team and regularly collaborate with product designers to review and scope new UX features. UX Engineers determine the technical feasibility of implementing the proposed UX and conceptualize how it should be built.

Aptible’s UX Engineers focus their efforts primarily on translating design assets into functioning prototypes, patterns, or components which can then be implemented in the product or added to the design system. They advise when to apply an existing pattern or component versus creating new ones.

Usually, the work of implementing a new feature within the product is the responsibility of our front-end engineers, but sometimes UX Engineers are tasked with building or improving upon existing UX within our products themselves, which depends on the scope, timeline, and type of feature being implemented. In these cases, UX Engineers and front-end engineers may collaborate together to ship the feature.

Another main responsibility of UX Engineers is to build and maintain our design system, which we call Arrow. Arrow is a collaborative effort between product designers and UX Engineers to normalize design patterns, styles, and language. However, UX Engineers own Arrow and develop it as a separate product by maintaining a roadmap, grooming and planning sprints, building the architecture, and implementing features. Aptible UX Engineers split their time 50/50 between Arrow and product feature development.

Some of the other areas of focus for an Aptible UX Engineer include:

As the landscape of JavaScript continues to evolve, there will be a need for specialists all along the spectrum of front-end engineering. UX Engineers at Aptible are an important part of the product development process by blending UX knowledge with technical skills to fill the gap between product design and front-end engineering.

What is a UX Engineer at Aptible?

Existential checks are when we have to detect whether or not a variable has a value - that is, checking to see if a variable exists. If the value is null, undefined or otherwise falsy, then it fails the check. This usually takes the form of an if-statement.

What's the problem with existential checks?

It sets poor expectations for other developers and makes it harder for them to grok the codebase.

Existential checks are a natural - and often necessary - part of codebases. However, their over abundance can make the readability of the codebase difficult. Where they are used has a dramatic effect on code reuse, readability, and maintainability.

When objects can be empty, it sets terrible expectations for the end developer. Here are some questions it can raise:

Working with many developers across multiple squads at Aptible, it is important for us to set clear expectations with our code. Setting expectations leads to more readable and manageable code. Because we use TypeScript at Aptible, we set expectations through our interfaces. When interfaces are littered with optional or nullable properties, we set terrible expectations. Therefore, we make a concerted effort to minimize the number of optional or nullable properties in our front-end codebase.

As code structure determines its function, the graphic design of code determines its maintainability. Indentation - while necessary for visualizing the flow control a program - is often assumed to be merely an aesthetic appeal. However, what if indentation can help determine unnecessary code complexity? 

 Linus Torvalds thinks that greater than three levels of indentation is a code smell which is part of a greater design flaw.

Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

Jeff Atwood thinks that nesting code has a high 

 value which is a measure of how many distinct paths there are through code. 

I started my career in software engineering by trying many different programming languages. I took something along with me after diving into writing pragmatic and ideomatic code for each language. For example, when I started learning python, I stumbled upon Python Enhancement Proposals (PEP). From PEP 01:

A PEP is a design document providing information to the Python community, or describing a new feature for Python or its processes or environment.

There are a couple PEP's that are cited very often, one of which is 

. It describes a set of design principles that every python developer should think about when architecturing a codebase. There's one line in this principle that I think about all the time:

This guiding principle has led me to what I believe is more maintainable, readable code. When we apply this principle to data structures, that means we should avoid deeply nested data structures. Deeply nested structures are difficult to understand -- even when strongly typed -- and they tend to promote cases where a nested object could be empty. This has the consequence of requiring developers to make many existential checks, especially if the data is used often. Redux also has an great set or recommendations for organizing application state that also 

, but the tldr is to think of an application's state like a relational database: each object is a database table where the key is the id and the value is the object data. This makes data easier to query, update, and reuse. If you inspect Aptible's redux state, it is very flat and scales very well.

Forgetting the 'transform' step in our data pipeline.

When it comes to web development, we regularly have to build a pipeline to consume an API that is usually a separate service, constructed by a set of HTTP endpoints that we have to 

 into our front-end application. When I first started building front-end web applications, I got into a really bad habit of skipping the transform step. I would take the API response and load it directly into my application state. By ignoring the transformation step, it made it harder to make updates to the codebase when an API endpoint changed. APIs are not always built with the consumers in mind. They are built in terms of being RESTful, with strict rules on how data should be formed and sent to their consumers. Another side-effect of ignoring the transformation step is pushing optional properties to the view layer (e.g. react components). There's no quicker way to complicate a react component than to make a bunch of existential checks inside the render body even if it uses the new syntax sugar of 

This example is meant to demonstrate how code can become more complicated when there are existential checks inside our react components. We have made no guarantees for the data we are sending to the view layer and as a result we have to make many existential checks and fallbacks to accommodate.

Make optional properties the exception, not the rule

Instead of accepting what the backend sends us, we should instead create a consistent and reliable set of data structures that our app uses. Optional properties should be an exception, not the rule. Let's build some ideal interfaces without optional or nullable properties and then figure out how to build our state with it.

It's a pretty simple exercise, we go through and remove the possibility of a property not existing or the property being null. Already I'm feeling more confident about these entities and what I can expect from them. This is great, but how do we make this interface a reality with the data we are being provided?

The general approach to retrieving data from our redux store is to always send the object that the user is requesting. Instead of our selector potentially returning null or undefined, we can return a default blog object, with sane defaults for each property. This is a concept inspired by golang. Variables without an initial value are 

. This means that every entity in our front-end codebase has an entity creation function that accepts a partial of that entity and does a simple merge.

This concept of creating default entities or 

 is a concept used in ruby, primarily for specs but also can be used for anything.

By spending a little up-front time building entity factories, we save a ton of time for every end-developer that needs to create a new entity. It seems tedious, but we've been able to scale this concept to even massive entities with good ROI. Our human labor will pay off. We're not using a library to do this for us - it's straight-forward and easy to copy/paste.

Back to the fundamentals of ETL, it is imperative that we do not skip building the T in ETL. The way we do this is by creating a deserializer for each entity in our API responses. You can see in our responses where our original interfaces came from: this is what the API is sending us. We shouldn't continue the trend of maybe having properties or maybe having an object.

This seems tedious, but a developer writes it once and now we have:

This ETL structure is the basis of our front-end business logic and has scaled well to date.

All of the work in the previous sections should pay off now, let's see what it looks like.

This last point is interesting: we don't need a loader to prevent this code from throwing an error, it's safe to use while data is being fetched. We can defer implementing loading states until later. One could argue we are overloading the meaning of body by placing the error message inside it. I think that's fair, but ultimately this has rarely been an issue and it really cleans the code up. I personally don't see an issue with it, but if we want, we could instead do a single existential check on the id of the blog entity and then return early:

One more thing: Flat is better than nested

I really like how we simplified our react component, there's virtually no logic involved because we pushed all of that complexity into our transform step. We do the leg-work once and now everything downstream of it can enjoy type and render safe entities without any optional or missing properties.

We're not done yet. I really do not like how we have nested objects in our entities. I want to normalize this data so we can query for them separate of querying for the entire blog object. Maybe I want a page where I list all authors using the same card we built for the blog article. It seems silly to traverse all blogs first, then deduplicate the list of authors, and then render the authors.

Is it more code? Absolutely. The goal of flattening our objects is not to save on lines of code; rather, it's to build a scalable, readable, and maintainable architecture that is predictable to use.

Architecting code is hard. With a little planning and by pushing a few existential checks to the transform layer of ETL, we end up with a repeatable pattern for dealing with optional or nullable properties, and making our view layer easier to build.

Death by a thousand existential checks

Let’s say you’ve created a SaaS application that lets customers keep track of their vendors. Things are going well and you’re adding many customers. One day, a curious customer starts messing around with the IDs in URLs and stumbles across a vendor they shouldn’t have access to. This is Very Bad™, especially if your customers are relying on your application to store sensitive information!

You have now entered the wide world of Authorizations. We’ll spend this blog post looking at one piece of the Authorization puzzle: using the Finder pattern to ensure users only see the things they’re allowed to.

Let’s say you’re building the application we alluded to in the previous paragraph. One may begin with a naive implementation such as:

This may work fine and dandy at first, but as soon as you add your second customer you’re going to have a problem: every user has access to every vendor. Let’s say you foresee this problem. You create a User model that users authenticate with, add a user_id column to Vendors, and update your controller like so:

Great! You also remembered to add scoping to your show route. A+, problem solved, ship it. All is well, for a time...

A month later you’ve moved on to other features in the application. A new engineer on the team is tasked with adding an Agreement model to keep track of the obligations between customers and each customer's vendors. She implements the route for creating a new Agreement like so:

The team is busy, as startups are, and the change slips through to production. The support tickets start streaming in with customers asking about strange vendors showing up. No bueno. What’s an engineer to do?

The Finder pattern is a simple concept: when you want to show something to a user, use a Finder. Finders implement a base scope upon initialization so that users only see what they’re allowed to. Subsequent methods chain off of that main scope, to ensure only a subset of the authorized scope is returned.

Let’s take a look at what a simple finder might look like for Vendors:

And how it might be used in our controllers:

Finders are most frequently used in controllers, but they can - and should - be used everywhere you are scoping to an authorized subset of records. Part of the security benefit is that when it is used everywhere as a convention, engineers are less likely to customize their own scoping and make an error.

While this was a simple implementation, it illustrated a few key benefits. The Finder pattern:

Some might say that in lieu of the Finder pattern, authorization problems could be mitigated with better code review, documentation, or in our specific case, using a /users/:id/vendors route. But, without the Finder pattern, engineers will always need to be thinking through the complexities of each individual scenario: “What vendors can this customer see?” or “Is this User an admin that can see all Agreements?”, etc. With the Finder pattern, you can instead use the simple heuristic of “Will the user see this?” when writing or reviewing code.

The important concepts here are that applications grow complex, models can be accessed from a variety of contexts, expertise in a system is spread unevenly across a team, and humans just make mistakes sometimes. It’s up to us as engineers to put in guardrails and conventions to prevent these mistakes when we can, and the Finder pattern is yet another tool at our disposal at Aptible.

“Finding” Your Way to Better Security in Multitenant Rails Applications

This is Part 3 of a 3-Part Series. If you missed our last post, 

It was 2014, and our CEO (Chas) and CTO (Frank) had been working side-by-side in New York, NY on the beginnings of Aptible. They were ready to grow the business and found a talented Product Designer to join. The only challenge was that said Product Designer lived in San Diego, CA, and he wasn’t planning on moving any time soon. Could an early stage startup successfully get off the ground with over 2,000+ Miles between its founding members?

The answer, we’ve learned, is a resounding yes. Not only did we hire that Product Designer (Skylar), but over six years later, he’s had an outsized positive impact on the business and now leads our Design Team at Aptible. Throughout that time, he’s also gotten married, had two children, and moved cross-country (not once, but twice)! Today, Aptible is proudly “Remote-First,” with fifty team members based in forty cities across North America. In retrospect, had we not prioritized people over geographical centralization since our earliest days, Aptible would be a completely different company today.

The Aptible Team at our Virtual Onsite, May 2020

We're passionate about building a diverse team of talented people who accomplish great things together, regardless of where they are. We know that our ability to achieve our mission is contingent on ensuring our team performs at a high level and making Aptible the best environment to support that kind of team. We can’t control what’s happening outside of Aptible, but we can be certain that we have a greater chance at long-term success if our center holds. This means that the core of Aptible—our team and its culture—must be strong, through every phase of growth.

But how do you create that center when there’s technically no center at all — no headquarters, and practically no physical assets? We believe it begins with being intentional about the culture we're trying to create, and taking the time to explicitly articulate what we mean by "us". Here, we share three tactics for scaling culture on a rapidly growing, distributed team.

Part 3 | Communications Architecture: Establish Norms for How You Come Together

If you’ve been following along in this three-part series, perhaps you’ve started to pick up on a theme: We believe that intentional culture design is necessary for creating a center that holds on a distributed team. And a large part of that design work lies in establishing clear expectations around what work needs to be done, and how it should be done.

At Aptible, we often refer to a set of “how we’ll work together” expectations as a social contract. And in establishing that social contract, we lean towards explicit expectations — those that are based on conversation and instruction, rather than those that are based on inferences and interpretations, or on assumptions and past experiences. As members of a fully distributed company, we have limited opportunities to develop inferences and assumptions about how we work (i.e. I can’t casually peek into a conference room to get a feel for how meetings are conducted here), so setting explicit expectations becomes critical to our success as collaborators. 

For teams that are transitioning to a distributed model for the first time — or teams that are looking to improve the way they work remotely — here, we offer our advice for establishing expectations and norms around how you come together as a company.

It’s one thing to give a new employee Slack and Zoom accounts, but it’s quite another to document and have a conversation about how they should use Slack and Zoom. Social contracts exist any time you interact with another person on these platforms — the variation in social contracts is in how explicit they are.

 represents our collection of expectations, and in it, we establish an explicit Communications Architecture:

For example, we’ve established a norm that everyone has their video on during all calls. On distributed teams where the most high-frequency communication is often textual, it’s critical to hash things out face-to-face on video calls — where you can read facial expressions and body language. We advise Aptilians that if they find themselves writing long messages in Slack or multiple exchanges over email, it may be an opportune time to get on a video call.

With that said, we’re sensitive to the fact that teammates are working across multiple time zones, and might not always be available to join a synchronous meeting. As such, we encourage everyone to record conversations in Gong.io or Zoom, and/or capture minutes in Google Docs or other shared resources. This helps us keep key stakeholders in the loop, while minimizing the number meetings overall.

In the absence of a ritual around gathering daily at a physical office, we work to create a predictable rhythm around how we come together at Aptible. We use a variety of meetings with different cadences and different scopes to help teammates feel connected, empowered, focused, and informed.

A Sampling of Recurring Meetings at Aptible

In an effort to create as clear of a drumbeat as possible, we work to hold meetings that stakeholders feel a strong need to attend. To this end, we encourage everyone to get clear on the goal of every get-together, distribute and review collateral in advance, identify clear roles (e.g. MC, Scribe, Timekeeper, etc.), minimize distractions and maximize focus on the conversation at hand.

Lastly, we recommend setting the expectation that all of this is, ultimately, is an experiment. If a recurring meeting is no longer serving its purpose, we want people to surface feedback and change what isn’t working — or to cancel it altogether and give people their time back.

A Snippet (Anonymized) of a Real Conversation at Aptible (via Slack)

Consider sending a short survey to solicit feedback from participants as soon as possible after “expensive” company-wide meetings like All-Hands or Offsite/Onsite Workshops: Was the information presented useful? Was the information presented engaging? What did you like about this? How could we have improved this? Then, use that feedback to continually refine how you come together as a team and ensure the highest signal-to-noise ratio.

At Aptible, we’ve seen meaningful returns on taking the time to establish explicit “how we’ll work together” expectations. While we’re proud of the 

, we know that this is really just the beginning. Establishing explicit expectations is a practice we continue to learn at Aptible — and the act of forming and continuously updating them brings us in closer alignment, even and especially when we’re physically apart.

Checklist: Create your own Communications Architecture

Intentional & Explicit Culture, Part 3: 3 Tools for Creating a “Center that Holds” on a Fully Distributed Team

This is Part 2 of a 3-Part Series. If you missed our last post, 

Part 2 | Values Interviews: Identify People Who'll Expand Your Culture

At Aptible, we believe that culture isn’t created through shiny offices and unlimited perks, but by building a team of people with whom our values resonate. That’s why we actively seek teammates who demonstrate alignment with the behaviors and skills we care about most — and make the difficult decision to let go of those who don’t.

To be clear, “alignment” here doesn’t imply that our personal values completely align with Aptible’s Values, nor does it imply that they are objectively superior to any other set of values. What we are seeking in prospective teammates is a willingness to commit themselves within the context of work to our mission to build trust on the internet, as well as the way in which we seek to pursue it as a team.

We believe that alignment with Aptible’s Values doesn’t imply a homogenous culture, either, but rather a dynamic one. We know that there are an infinite number of ways in which our colleagues can embody them, and celebrate the fact that each person will shape our culture with their own unique perspectives and experiences. This is how you scale culture on a rapidly growing, distributed team.

Aptible Team Members (From Left to Right): Albert Wong, Sarah Veirs, Chris Gomes

To this end, we incorporate a “Values Interview” into the recruitment process for every single open position at Aptible. Regardless of where the open position sits within the organization, no hiring decision can be made at Aptible without a Values Interview. Assuming that a candidate has met or exceeded our expectations for role-related knowledge/skills earlier in the recruitment process, a successful Values Interview is a strong indicator that they’ll receive an offer from Aptible. Here’s how we’ve built a Values Interview Program at Aptible, and how you can, too.

We conduct Structured Interviews at Aptible — which means that we use the same methods to assess candidates who are being considered for the same role — because 

. For each open position, we use the same interview questions, grade candidate responses on the same scale, and make hiring decisions based on consistent, predetermined qualifications.

Structured Interviews ensure that any variation in candidate assessment is a result of the candidate’s performance — not because an Interviewer has higher or lower standards, or asks easier or harder questions. We’ve also found that they create a better experience for candidates.

Unlike other stages of our interview process that focus on role-related knowledge, the Values Interview is a discussion focused on a candidate’s motivations and alignment with 

. After co-creating three “Core Values” — Pillars, Cultural Tools, Operating Frameworks — our People Operations and Leadership Teams developed a bank of 2-3 behavioral questions for each.

Blog

Building Aptible’s Design System

Recreating redux-toolkit’s createSlice

Going on a Powertrip

Securing websites via HTTP Security Headers

What is a UX Engineer at Aptible?

Death by a thousand existential checks

“Finding” Your Way to Better Security in Multitenant Rails Applications

Intentional & Explicit Culture, Part 3: 3 Tools for Creating a “Center that Holds” on a Fully Distributed Team

Intentional & Explicit Culture, Part 2: 3 Tools for Creating a “Center that Holds” on a Fully Distributed Team

Building a developer
platform is a thing of
the past.

Product

Resources

Support