Recently, Joe and I have been doing some performance work on causes.com to
speed up the time it takes to generate a page on the server. Most of that work
meant reducing the number of database queries we make. Take the profile page
for example. On that page, we list the most important campaigns you’ve
participated in. Before we started optimizing it, we were making more than 10
queries per campaign listed. We added some pre-loading and caching and
managed to take all those database queries down by 90%. That in turn brought
the time it took to generate this page down from about a second to 200
milliseconds.

Are you worried that your CSS changes will break the current design in
unexpected ways? Do you want to show a designer a page you’ve been working on,
before and after your changes? Do you want to be able to quickly look back at
how things looked a month or a year ago?

Diffux [dɪˈfjuːz] is a tool that generates and manages visual diffs of web
pages, so that you can easily see even the subtlest effects of your code
modifications.

Sally has been tasked with making the commenting feature in her company’s
webapp be threaded up to 5 levels instead of only 2 levels. As she makes
adjustments to the code, she collects an unprecedented number of browser tabs.
Some of them point at her company’s production site, while others point at her
development environment. In many of them, she enabled “super-user” mode, so she
could more freely play with her app while making her changes.

So she goes on coding and messing with the data for most of the afternoon.
She’s about ready to wrap up and head home for the evening when her boss walks
in and asks, “Sally, lots of comments have gone missing. Do you know what
happened?” Sally felt like she had swallowed a sack of doorknobs. In the midst
of her coding spree, she mixed up some of her browser tabs and accidentally
deleted live data. A lot of live data.

We tend to prefer convention over configuration, so when we first began using
Bower to manage our front-end dependencies, we started with minimal
configuration. While this nicely put the files in the expected places, it was a
hassle actually using the assets in our Rails app.

Our basic initial approach was to symlink the assets that we wanted to
reference from the bower_components directory into vendor/assets where
Sprockets would notice them. While this worked in the short term, it was
tedious to set up new packages, and was likely to break if the required assets
were moved when upgrading dependencies.

Ultimately, this felt like a hack. We decided that there must be a better way.
Thankfully there is.

A mobile-first approach to design can be good: it helps you focus and
potentially simplify your requirements, which can translate into a better user
experience. Likewise, a mobile-first approach to implementation can be good: it
puts the more expensive tasks on the shoulders of clients that are more likely
to be able to handle the extra load, which can also translate to a better user
experience.

At Causes, we have been building things with a mobile-first approach both
in terms of design and implementation with a goal of progressive enhancement.
Since switching to this mode on the technical side, we have noticed that our
code is easier to write and more coherent to read, both of which are big
benefits for the engineering team.

So we’ve put together a little project that helps us write readable media
queries in this way. We call it sass-enhance.

“How fast are your tests?”. Have you ever had that question? Probably not.
Does performance matter for tests? Yes, and here’s why: The time it takes from
you changing a bit of code until you get feedback on whether or not that code
works is crucial in knowing if your code is good or not. Let me illustrate by
two scenarios.

Giving structure to an agile engineering team is hard. You want people to work
on the things that they are most interested in without losing focus on the main
goal of building a great product. No matter how you split your organization
into teams, you will miss covering certain areas of interest. This is where
working groups can come into play.

I recently had an experience I expect is common for designers who work at startups: I presented a well-polished mockup to a key stakeholder late in the design phase of a project and he told me flat out that the design didn’t address his users’ needs. This, after I’d met with him twice before.

This was my first project at my new company and I was still getting to know everybody and their roles, but excuses aside, I quickly realized this happened because my team never got our business stakeholders together at the beginning of the project. Because we didn’t make time to discuss the problem we were trying to solve, everybody was operating under their own assumptions. If we were going to improve communication on our next project, my product manager and I needed to discuss how to set expectations about our design process; we needed to be more intentional about when we got feedback from which groups of stakeholders, and what kind of feedback we were seeking from each group. If we were successful, we’d be able to get consensus quicker and reduce iterations needed to get to a solution that was ready to be specced.

In object-oriented code, there are several choices for where to put a
new function, and each choice has its pros and cons. These choices
repeat themselves over and over in a codebase, so it’s worth reviewing
the tradeoffs we make on a daily basis.

Over time, large-scale object-oriented systems tend to produce God
Objects. These are classes which know
too much or do too much. They have connections to disparate and varied parts of
the system. They depend on everything, and everything depends on them. They make
systems slow to work with, intractable and hard to modify. They insidiously
undermine and resist our efforts to carry out our core task as engineers:
decomposing complex problems into smaller subproblems that are more easily
solved.

At Causes there are some concepts that are
front-and-center in our product: users, their campaigns and the actions
they create to make an impact (things like petitions, fundraisers and pledges).
The concepts are so core that they have a tendency to become God Objects unless
we diligently work to prevent them accruing more and more functionality.

We’ve lately applied the
Pub-Sub
(Publish-Subscribe) model to our Ruby code, applying the familiar event-based
patterns that we know from JavaScript to the server side, in an effort to reduce
the tight coupling that some of these God Objects have to other parts of the
system. With a simple, framework-agnostic Ruby library, we’ve been able to
significantly tame some of the complexity around these classes, and we’ve
released it as a Ruby gem, PubSubHub.