Your puppet code base makes you fear the apocalypse

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.

Creating Form Objects with ActiveModel and Virtus

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.

Push Button Deployments

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.

A Better Way to do Rails with Aldous

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.

Making the Most of BDD, Part 2

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. In Part 1 of this 2-part series I described what BDD is and explained how it is more than simply a way to improve code quality. Today, let’s look at how BDD becomes the living documentation of your system, and how it informs your system architecture.

Chainable BEM modifiers

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.

A Case For Use Cases

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.

Making the Most of BDD, Part 1

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.

Behaviour Driven Testing consists of cycles inside cycles. For BDD, The inner TDD loop (Write a failing unit test -> Make it pass -> Refactor) is wrapped inside a slower BDD loop (Write a failing feature test -> TDD until it passes)

Styleguide Driven Development

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.

Formtastic: Creating and Maintaining a Popular Open Source Plugin

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.