Envato Market has been using a css naming convention loosely based on BEM block__element--modifier syntax for the past two years and it has been instrumental in helping us update our front-end codebase and freeing us from legacy constraints.

About a year in, a problem was still bugging us. We had two different ways of using modifiers: single class and multiple classes.

Whilst both techniques are valid, they lend themselves for use in different scenarios. Plus, having two conventions using identical syntax in the same codebase is a recipe for confusion.

What’s the problem?

Most Ruby on Rails applications start off as simple web applications with simple requirements. As a developer, you take those requirements, map out the business domain and then implement it using the MVC pattern of models, views and controllers.

Over time, more requirements are added and simple controllers can become bloated with complex logic. The obvious next step is to create public methods on your models and move the logic into them, thus keeping the controllers simple. However, this inevitably leads to fat models.

One of the guiding principles of Software Design is the Single Responsibility Principle and fat models have too many responsibilities. In fact, you could argue an empty model that extends ActiveRecord::Base already has multiple responsibilities: persistence and data validation/manipulation. Furthermore, an empty ActiveRecord model contains 214 methods (not counting any of the methods on Object). So these classes are already tightly coupled to the Rails framework and if you put your logic in them too, they’re also coupled to the business domain.

Hi, I’m Mary-Anne. I’m a senior Ruby developer here at Envato. One of the things that I love about my job is that it gives me the opportunity to use one of the practices I am most passionate about - Behaviour Driven Development, or BDD.

BDD is the practice of writing functional tests before you write unit tests. It incorporates the older practice of test driven development (TDD), the art of writing unit tests before you write code. At Envato, our code is written in Ruby, our unit tests in RSpec and our functional tests are in Cucumber, but many of these principles can be applied to other languages and frameworks.

Styleguide Driven Development (SDD) is a practice that encourages the separation of UX, Design & Frontend from Backend concerns. This is achieved by developing the UI separately in a styleguide.

By separating the UI and backend tasks so they don’t rely on each other, it allows teams to iterate fast on prototypes and designs without having to make changes to the backend. With careful planning they should plug-and-play together nicely.

SDD isn’t just limited for big teams working on large applications, but the core concepts of developing UI elements separately in a styleguide (living or static) can still benefit a sole developer working on a single page app.

Interview by Natasha Postolovski.

Justin French heads up the Design & UX team at Envato. In addition to being a product mastermind, Justin is an accomplished Rails developer, passionate contributor to open source, and frequent wearer of black T-shirts. In the open source community he is best known as the creator of Formtastic, a super popular plugin for the Ruby on Rails framework that helps Rails developers build better forms faster, with less boiler plate code. The repository has more than 4,400 stars in Github, and over 180 contributors.

In this post we’ll delve into Justin’s experiences creating Formtastic, from idea to public release. We’ll also learn about what it takes to maintain and grow a popular open source project.

One of the things I really enjoy about working in the Envato Marketplace development team is the opportunity to learn and to teach via pull requests (PRs) and code reviews. Although the main reason we use pull requests is to obtain approval for production deployment, a useful indirect benefit is the transfer of knowledge within the development team.

Pull Request Lifecycle

In the development team we use GitHub to manage our code and the pull request functionality is a large part of our process. Every change in the codebase is put up for review on GitHub before it is merged into the master codebase and deployed to the web servers.

The main reason we use PRs is to get other developers’ approval for the code to go into production. This approval is usually given via a “plus one” (+1). It is up to the developer to decide how many +1s they need before they merge and deploy their code. Generally, the more large and complex the piece, the more +1s are required.

How does one get a +1? When a developer comments with a +1, they are saying “I am willing to support this code in production”. It must meet their idea of quality. From the overall architectural decisions made in your code, right down to whitespace formatting - everything is up for comment.

This graph is of our PR comments, the thickness of the lines reflect the number of comments from one developer to another’s pull request.

However, what it represents is of more importance. It represents knowledge sharing, teaching and learning.

Envato is a fast growing company and we’re expanding both our Melbourne, Australia office and our remote team. Check the job listings below or visit our Careers page to learn about working at Envato.

We are especially interested in talking to Ninjas, Rock Stars, and Clerics. In addition, we’re also looking for Ruby developers, devops, UX, and more!

The first Envato Marketplace was started in 2006 (and 7 others have followed since then) and now we’re a good sized online business with a lot of traffic (well over 100m page views per month). Over the same period the mobile revolution has and continues to happen and like many other online businesses we want the user experience of our sites to be far better on mobile devices by making them responsive.

While broadly this is not a unique challenge, we do have some nuances that we think make us a little bit different. In addition to a fairly large and evolving code base, some of the key pages on our sites like our item page (the equivalent of a product page on a typical e-commerce site and thus super important for conversion) are based around user generated content and assets.

Although we are a while off being fully responsive I’d like to share our journey and some solutions we have developed to progressively convert the Marketplaces to be responsive.

I recently presented to the Bankwest Solutions Delivery Group on the processes and technology we use that allows us to deploy our sites up to 10 times a day.

A couple of months ago I presented at LoneStarRuby 2013 in Austin, Texas. While I’ve done a few presentations for work and locally in the past, I’ve never presented at a proper developer conference before. I knew from experience that the standard of presentations at Ruby conferences will tend to be pretty high, so rather than risk being the token crappy presenter (that you occasionally see - and feel sorry for), I set out to do a bunch of research on what makes a decent presentation. Watching videos by such presentation luminaries as Ben Orenstein and Scott Hanselman, as well as reading old favourites like Presentation Zen and Confessions of a Public Speaker. In the next few paragraphs, I’ll show you my talk as well as try to distill everything I learned and hopefully save some fortunate developers hours of effort in the future.