Back in November 2015, one of the Envato Market developers made a
startling discovery - our exception tracker was overrun with occurrences
of undefined method exceptions with the target classes being
NilClass and FalseClass. These type of exceptions are often a
symptom that you’ve written some Ruby code and not accounted for a
particular case where the data you are accessing is returning nil or
false. For our users, this would manifest itself as our robot error
page letting you know that we encountered an issue. This was a
particularly hairy scenario to be in because the exceptions we were
seeing were not legitimate failures and replaying the requests never
reproduced the error and code inspection showed values could never be
set to nil or false.

Background

Since the end of 2015, the Envato Front End team has been working on bringing a modern development workflow to our stack. Our main project repo powers sites like themeforest.net and serves around 150 million Page Views a month, so it is quite a challenge to re-architect our front end while maintaining a stable site. In addition, the codebase in 9 years old, so it contains the code from many developers and multiple approaches.

We recently introduced our first React based component into the code base when we developed an autosuggest search feature on the homepage of themeforest.net and videohive.net. The React component was written with ES6, and uses Webpack to bundle the JavaScript code.

As I mentioned above, it’s a 9 year old code base and nobody can guarantee that introducing something new won’t break the code, so we began all the work with tests in mind. This post documents our experiences developing the framework for testing the React based autosuggestion component.

CloudFormation is an Amazon (AWS) service for provisioning infrastructure as
“stacks”, described in a JSON template. We use it a lot at Envato, and
initially I hated it. Typing out JSON is just painful (literally!), and the
APIs exposed in the AWS CLI are very asynchronous and low level. I wanted
something to hold my hand and provide more visibility into stack updates.

Today I’d like to introduce a project we’ve recently open-sourced: StackMaster
is a tool to make working with multiple CloudFormation stacks a lot simpler. It
solves some of the problems we’ve experienced while working with the
CloudFormation CLI directly. The project is a refinement of some existing
tooling that we have been using internally at Envato for most of this year, and
it was built during one of Envato’s previous “Hack Fortnights”.

The Envato development team has always had a strong sense of what we stand for, how we work together and what we expect of each other … at least that is what many of us thought. Around 9 months ago our company participated in the Great Places to Work survey, which gauges how our employees feel about Envato as a place to work. Each department received a breakdown of their feedback, and whilst much of our feedback was great, one statement was a clear outlier “Management makes its expectations clear”. This was a trigger to question our assumptions about those expectations. This post tells the story of that journey.

I’ve written before about Working with Locales and Time Zones in
Rails, but I often feel the i18n library (short for
internationalisation) is underused (appreciated?). Perhaps it is even avoided
because of the perception it is more effort to develop with and harder to
maintain.

This article will, I hope, open your mind to the idea that you will be better
off using i18n in your application (even for a single language) and that it
can be maintainable with some simple organisational pointers.

A Structure Styleguide is a special breed of living styleguide, designed to document an application’s UI logic and all of the possible permutations of the UI.

The goal is to have a complete and shared understanding of how an application behaves in any situation, even in the most uncommon edge cases, without having to laboriously recreate each scenario by hand.

Let me paint you a picture. At some point in time someone said ‘hey, wouldn’t it be great if we could manage our servers with that new puppet thing’. ‘Great’, said everyone, ‘Let’s do that and the way we have always done it.’. And that, my friends, is how you end up where we are.

Reading our puppet code base reads much like a bad folding story. Everyone had a plot line and tried to weave into a flowing narrative. And like all badly written stories it has many dead ends, twists, continuity issues and obscure meanings. You get that from many different authors - all code bases face the same problem.

You might have heard of “fat models” referring to (mostly) ActiveRecord models
turning into huge classes responsible for everything from user authentication to
accepting attributes for entirely different models. This violates one of my
favourite rules of [SOLID][solid], the single responsibility principle.

One of the patterns you can use to help balance your SOLID karma is with form
objects. We use form objects extensively to back our forms and encapsulate the
data submitted by a user.

It’s often tempting to reach for the ever ready ActiveRecord model when
building forms in Rails because it Just Works™ with the Rails Form
Helpers. I’m going to show you how to have your cake and eat it by backing
your forms with objects.

Envato is becoming a large company, with several teams working on many different products spread across various technology stacks.

Each of our teams are responsible for their own deployment process, which means each has ended up with its own way to deploy changes. It’s complicated to grant a new developer access to all the tools and services they need to deploy a single project, let alone multiple projects.

About a year ago the Tuts team encountered an issue with our Rails codebases becoming more unwieldy as they got bigger. Our development pace was slowing down and new features and fixes would cause regressions in unexpected parts of the system. This is a problem that many of us have encountered before, and we often treat it as part and parcel of doing business. This time, however, we decided to see if we could find ways to improve the situation.