Conversation

At Versa, we have a code style guide. I didn't start it, I just forked AirBnB's because it seemed pretty good (and it was based on GitHub and Bozhidar Batsov's).

While reading through the section on Method Definitions, I saw a pattern for dealing with optional method arguments that I really liked:

# bad def obliterate(things, gently = true, except = [], at = Time.now) # implementation omitted end # good def obliterate(things, options = {}) default_options = { :gently => true, # obliterate with soft-delete :except => [], # skip obliterating these things :at => Time.now, # don't obliterate them until later } options.reverse_merge!(default_options) # implementation omitted end

We have numerous situations where methods take optional arguments (mostly date ranges), so we use this pattern quite frequently.

Like good programmers, any time we see a pattern get used multiple times, we start thinking about cleaner and more efficient ways to implement it.

I'd like to say that we were proactive and turned this pattern into a gem straight away…but that isn't how it went down. Instead, we spent the better part of a day tracking down a bug in an internal reporting system - which we determined was essentially caused by the destructive reverse_merge! call (and our implementation of the parent method).

Hurray, bug fixed! Unfortunately, we then needed to go through all the other places in the code were we use this pattern and see if we were vulnerable to this particular bug. In the end, there were no other instances of the bug, but the whole exercise took up valuable engineering time.

Spending time double checking non-DRY (wet?) code leaves a particular sting: If I had extracted this out into a class or gem, I would only have to fix this in one place! It is with that sting still fresh that I built the DefaultOptions gem. Sorry for the name, all the cool ones were taken already :(

The DefaultOptions is basically a glorified OpenStruct. Using DefaultOptions the above example would look like this:

#better def obliterate(things, opts = {}) options = defaults_for opts do gently true # obliterate with soft-delete except [] # skip obliterating these things at Time.now # don't obliterate them until later end # You can access the options with dot notation. I.e.: # options.gently # options.except # options.at end

With the above setup, you define default values for any of the options your implementation passes in. The rest of your method code can rely on options having all the values required.

The team at Versa is so pleased to welcome April Harding to our family! April joins us as the founding member of our Washington, DC-based office. She will serve as SVP of Politics and Advocacy and run our rapidly growing beltway practice.

April’s work over the past decade spans the public and private sectors, with digital communications and strategy at the heart of every experience. In addition to her years both in-house and consulting for a variety of digital clients from technology start-ups to multi-billion-dollar foundations, she spent a cycle as a political campaign field director, added a public policy graduate degree from Georgetown to her B.A. from Yale...and she can code, too!

Most recently, April was a VP and creative technologist at GMMB, a marketing and communications agency specializing in nonprofit, political and advocacy work. In that role, she was deeply involved in crafting and producing digital strategies across the firm’s core issue areas of education, health care, global health, and corporate social responsibility.

To Versa, April brings a civic heart, a scientific mind, a keen product eye, a passion for public affairs, and a deep understanding of political thought leadership, messaging and advertising.

by Dan

Manya Scheps, our head of product, recently wrote a blog post on Versa’s efforts to simplify the way we teach new users how to use our products. Her post reminded me of an old mantra I used to hear: K.I.S.S. -- it’s a middle-school acronym which stands for “Keep it Simple Stupid,” and it’s helpful to say out loud when you’re tasked with solving a problem that seems overwhelmingly large and complex, but that is actually best resolved by a simple, direct solution.

This week, David Segal of The New York Times published an exposé on digital video advertising, 'The Great Unwatched,' which sent a collective shiver down the spines of many in the digital marketing world. In the piece, Segal reveals that out of 2 billion video ads surveyed by ad management company Vindico, 57% were deemed “unviewable,” meaning not seen by human eyes. Similarly, in a recent report for client Blue Chip Marketing, video verification company BrandAds discovered that many of Blue Chip’s video ads were auto-playing at the bottom of an article before a reader scrolled down, and others were appearing in 3 inch x 2 inch, easily ignorable players. Most horrifying to the BCM team was the discovery that some of their ads were appearing on pornographic websites without their knowledge.

The digital advertising ecosystem has become so intricate and complex that marketers are rapidly losing control of their campaigns, and brands are the victims. And when advertisers are spending over 100 billion dollars annually on online advertising, this is a big problem. This is where K.I.S.S. comes in.

by John

This week at Versa, we worked on optimizing our analytics system. In doing so, we've been presented with a problem where we want to increment certain model attributes as fast as possible (and we don't need any callbacks to run).

In Mongo, we can use the $inc command to achieve this out of the box. With ActiveRecord, however, we could not find a baked-in solution. So today I wanted to go through what we came up with, along with some refactorings to make it more flexible.

Note: ActiveRecord CounterCaches are close, but we aren't basing these totals on the number of relations, so they are out.

Let's say we have an ActiveRecord model, Foo, which has an attribute called bars. At a certain point in the code we want to increment bars.

It seems very Rails-y to do something like this:

class Foo < ActiveRecord::Base # other model stuff… def increment self.bars += 1 end def increment! increment save! end end

Then our app (in a controller for example) can do something like:

f = Foo.find(params[:id]) f.increment!

Which works fine for most cases. Huzzah.

At Versa, we need to do lots of operations like this throughout the day, so we wanted to see if it could be optimized.

The first thing we noticed is that the implementation above makes two calls to the DB (one for the find and one for the save).

Sidebar: one of the great things about Rails (and frameworks in general) is that it abstracts away the db interaction, making your app database agnostic (as long as it's SQL-based). This is great in theory and it makes prototyping an app pretty simple. You can start out with SQLite, make a prototype, then easily switch to something like PostgreSQL for production.

Realistically though, once you've got a production db (especially in the relational DB world), the odds of you switching are pretty low. And if you do, it is probably so you can access DB-specific functionality.

I say all of this to bring up the point that once you are "locked" into a database, you should not be afraid to drop down to the DB layer when necessary. It's ripe with optimizations you can use when the abstractions don't do exactly what you need. /sidebar

Rails people should look at our example above and see that it is essentially doing:

SELECT * FROM foos WHERE id = params[:id];

Loading the result into a Foo model, getting the bars attribute (let's say it's 4). Then it hits the DB with an update like

UPDATE foos SET bars = 5 WHERE id = params[:id];

This isn't bad for most cases, but people familiar with PostgreSQL (it might work in all SQL flavors, I didn't confirm) will see those two queries and say, why don't you just one-line it with:

UPDATE foos SET bars = bars + 1 WHERE id = params[:id]

Which produces exactly the same result, but only involves one call to the db. Postgres, ftw.

The problem here is that (as far as I could tell) the one-liner isn't possible with ActiveRecord. So let's think through how we could refactor the model.

First, we don't need to instantiate an instance of Foo, so let's make increment! a class method that accepts an ID.

class Foo < ActiveRecord::Base # other model stuff… # I know, I know, we shouldn't have a bang (!) method without a # corresponding non-bang method, but the whole point of this method # is that it does the lookup and update in one shot. So I thought # it appropriate to make a bang-only method (since it persists to the DB). def self.increment!(foo_id) the_sql = "UPDATE foos SET bars = bars + 1 WHERE id = %d" % foo_id self.connection.execute(the_sql) end end

This is pretty good and fulfills all of our stated requirements.

I would, however, like to refactor increment! so that can accept an array of IDs (our particular use case requires this).

class Foo < ActiveRecord::Base # other model stuff… def self.increment!(foo_ids) # Note: we know that the IDs in our table are integers, so we # `to_i` everything to sanitize the values we plug into SQL. # Also, I would normally one-line this, but it becomes too # wide for blogging :) if foo_ids.is_a?(Array) query_ids = foo_ids.map(&:to_i).join(',') else query_ids = foo_ids.to_i end the_sql = "UPDATE %s SET bars = bars + 1 WHERE id IN (%s)" % [self.table_name, query_ids] self.connection.execute(the_sql) end end

As you can see, I also changed the SQL string so that the table name is derived from the current class.

Let's go one step further and make the attribute being incremented an argument to the method. Then we can increment bars with

Foo.increment!(123, :bars)

and increment some other attribute, say loads with

Foo.increment!([123, 124], :loads)

The class would then look like:

class Foo < ActiveRecord::Base # other model stuff… def self.increment!(foo_ids, attr_name) # Note: we know that the IDs in our table are integers, so we # `to_i` everything to sanitize the values we plug into SQL. # Also, I would normally one-line this, but it becomes too # wide for blogging :) if foo_ids.is_a?(Array) query_ids = foo_ids.map(&:to_i).join(',') else query_ids = foo_ids.to_i end # This line was getting too long so I broke it up. the_fields = [self.table_name, attr_name, attr_name, query_ids] the_sql = "UPDATE %s SET %s = %s + 1 WHERE id IN (%s)" % the_fields self.connection.execute(the_sql) end end

At this point we've abstracted all of the Foo-specific code from the method. That makes this a perfect candidate for a module (or a concern) that would allow us to drop increment! into any ActiveRecord model in our app…but I'll leave that as an exercise for the reader ;)

by Dan  

Versa's NYC team works in a startup co-working space called WeWork, located just below the West Village. For those unfamiliar with WeWork, it's a co-working empire, with 11 office locations in NYC, and a dozen others in San Francisco, Los Angeles, Seattle, Boston, and D.C. They offer a lot of great amenities for a growing company, but there's one in particular that I always hear praised when we have visitors at the office: 

The water at WeWork is flavored with fresh slices of lemon, lime, orange, cucumber, and ginger (in different combinations depending on the day). I've decided this fruity water is blog-worthy for three reasons:

1. I think it's a great example of a company's conscious decision to deliver happiness to its customers in an area they control directly. Specifically, WeWork knew that all co-working spaces must include water fountains, but decided they would go the extra mile and offer an unexpected delight to its members each time they go to get a drink of water (which 99% of members are sure to do at some point during the day).

2. Fruity water provides another way for WeWork to differentiate itself from the dozens of other co-working spaces in NYC, at a relatively low cost. 

3. The flavored water is earning them Tweets and Instagrams:

The fruit-infused water at #wework is my lifeblood

— Κatie Maser (@Katie_Maser)

April 18, 2014

I love the water fruit infused water at work. Today it's cranberry & lemon water. #water #wework… http://t.co/mWyNE19p

— Jo (@JoJoSpeaks)

February 5, 2013

First ever strawberries in the @WeWork fruit water. I love the new creation by Ivan! @mikeeisenberg @WeWork pic.twitter.com/vuWl5gUO

— Joshua N Weisbord (@JNWeisbord)

January 18, 2013

WeWork also, cleverly, includes a daily 'water flavor' update in their mobile app:

The lesson here, one which all the hippest CEOs also emphasize, is to sweat the details on customer service, and specifically, the details that you control directly.

Note: Just before I started writing this, I noticed that the Feedzirra gem had 1) changed it's name to Feedjira (explanation here) and 2) had pushed a bunch of updates. Everthing I talk about below worked on 0.2.4, and appears to work just fine on 1.2.0. Also, looking at the CHANGELOG, none of the updates should mess with what I talk about here.

Web feeds (RSS, Atom, etc. - but I tend to call them all "RSS feed"), while sometimes viewed as unfashionable/antiquated, are ubiquitous among web publishers. When you are building a system that needs to know when new content is published, RSS feeds are a perfect low-bar method for programmatically discovering new content.

In the Ruby world, Feedjira (formerly, Feedzirra) is the most popular tool for fetching and parsing web feeds. It does a great job out of the box; just give it a feed url (or an array of feed urls) and it will return a Feed object with an entries method to access all the feed entries with standardized method names. The documentation explains this well, so I'll stop there.

What I'd like to talk about are the times when you want to customize the feed parsing a little bit further. When you find yourself in a position where you are constantly doing some kind of transformation on the fields of a particular RSS feed.

Maybe you want to save the url for an article, but (because of your business logic) you don't want to save the query string. Or maybe you want to use Feedjira to fetch and parse non-standard feeds; or even just some rando XML residing at an api endpoint.

Thankfully, SAX Machine makes defining parsers dead easy and Feedjira (which uses SAX Machine) exposes a method to simply add parsers to it's internal stack.

The rest of this post walks through an example of creating a custom RSS feed parser and offers a way to organize your code in a Rails app.

Let's take this RSS feed:

We want to build a parser that:

Removes the query string from the article URL

Gets the published timestamp from pubDate instead of dc:created.

Here is the full code for a custom parser that achieves these goals (there are explanatory comments in the code):

We can see the class in action by firing up a irb console and parsing our actual feed.

Our custom feed parser is complete! If you are using Feedjira in a Rails application, you'll need to include your parser in an initializer. At Versa, our custom parsers live in a parsers folder in our app folder. Then we use an initializer like the one below:

With our custom parser(s) added to Feedjira's parser stack, it will automatically parse the feeds it is supposed to.

The last thing I wanted to mention on this is that obviously we should be writing tests for our parsers. I won't go into great detail, as it could be a post by itself, but I did write a spec for this example parser.And with that, we've built a custom feed parser for Feedjira and integrated it into our Rails app. Go forth an consume yee feeds.

by Keya

Ask any founder of an early stage tech startup about their engineering process, and you are likely to hear one or more of any number of defined, perfected, named methodologies: maybe Agile or Scrum, perhaps supported by principles borrowed from Kanban or Lean practices.

Ask the follow-up question of why these processes are so important, and you’re likely to hear some version of: internal communication and the ability to plan and project. In other words: outcomes fundamental to running a business.

But what do the answers to that same initial question tend to look like on the business side of a tech startup? I was in a conversation the other day with a group of CEOs, none of whom could articulate their sales process. Some named Salesforce, or Pipedrive (would an engineer ever answer “Pivotal Tracker” to that same question?). Others talked about pipeline conversions or quarterly revenue targets. But in no case were activities hustled through those containers undergirded with an articulated approach.

From the very beginning at Versa, the whole team, not just engineers, has operated on weekly sprints -- writing stories, staying in sync daily standups, and retrospecting together at the end. We are nothing if not all about process. 

Recently though, after a few pivots, we found product-market fit. It was time to get serious about sales. 

So we did all the things we thought we were supposed to do. We moved off google spreadsheets to a paid CRM. We put together a super slick keynote presentation. We consolidated all the questions and push-back from customer development and committed carefully scripted answers to memory. We got laser-focused on the close.

We had structure! We had activities! And, yet, time and again, super enthusiastic first pitches replete with the (prospective) customer feedback of “We love this!” and “Why is no one else doing this?” and “You are geniuses!!,” would wallow in months of rescheduled meetings, non-decisions, and, ultimately, only few and very long and hard-fought closes.

We did not have many deals. And I know now that it's because in this new realm we had lost sight of the all-important underlying process.

As so many good things do, process came to us via beers at a bar one night with a fellow founder, who responded to my frustrated retelling of our early struggles with sales by recommending a coach. Lucky for me, Scott Messer came with an approach.

Scott calls it Guess-Free Selling and it is very much a business corollary to Agile. It values individuals and interactions, customer collaboration, and mutual understanding and decisions. And it values all of the preceding over closes. And, like in the Agile manifesto, while it of course recognizes value in the close, it values the preceding items more.

Or, How Versa Learned to Stop Worrying and Love HTML Mock Ups.

by John

tl;dr - HTML/CSS mock ups ae good, HAML/SASS mock ups are better. We built a gem called Potatochop to make building HAML/SASS mock ups easier.

A few months ago, the Versa product team watched Julie Ann Horvath's talk, Because F%$k Photoshop. She made many points that we were thinking but not yet discussing as a team. It was decided: we immediately switched to building our mock ups in markup.

We've been doing this for a wee while now and we've learned three main lessons:

Markup mock ups are awesome. No more Photoshop discrepancies or "how does it scale" questions. If we want to know what it looks like in different browsers or different devices, we just boot them up.

Great opportunity to spread knowledge. We put our mock ups under version control, so if a designer had a question about a bug in their code or wanted to see how an interaction would work, they could just push it to GitHub and a developer could take a look and submit a pull request with a fix or suggestion. The designer could then look at the pull request and see exactly how it was done. Small bits of learning, ftw.

There was still a conversion step. The mock up was built in HTML/CSS, but our app uses HAML/SASS. This mean developers needed to translate it into HAML/SASS before bringing it into the app.

That third point wasn't that big of a deal, but it was non-trivial, so that's where we optimized.

How could we build our mock ups using HAML and SASS? What would it take? Basically, you'd need the haml and sass gems hooked up to a web server. So that's what we built. And now, after using this internally for a few months, we've pulled the core functionality into a Ruby gem and open sourced it as Potatochop.

Potatochop is a super simple web server (built with Sinatra) that processes and serves up web pages written in HAML/SASS (or vanilla HTML/CSS). Start up the server with the potatochop command and it will process and render any HAML, SASS, HTML, CSS, JavaScript or image file in the folder at http://localhost:4567.

We just released version 0.0.1, so the gem is feature-light (it just does what it says on the tin). Features that we are actively working on include:

Integration with GitHub so that you can do things like push this gem up to Heroku as a Sinatra app and have it serve mock ups from a repo on GitHub (public or private).

Including Compass to take advantage of what it brings to SASS.

Adding other syntactic sugar libraries (CoffeeScript, anyone?).

by Manya

Anything, when explained fully enough, can go from a simple task to a monstrous ordeal, on par with solving the diophantine quintuple or justifying why Nickelback is still making albums. Let’s take the instructions you’d need to give a new user to explain how to put a dollop of ketchup on a pile of French fries:

First, select the packet of ketchup. (You may have to explain where the user would find this, how they would identify it, what to do if there aren’t packets readily available, and what to do in case there’s just one of those squeezey-tub dispensaries of ketchup).

Open the packet. Using one hand, hold the packet and with the other, try to rip the top corner off.

If you’ve already eaten a fry or two, your hands may be too greasy to accomplish this. You’ll attempt it anyway, hopelessly mangling the top of it.

Don’t use too much force here. That would tear the top too much, and could result in a spray of red condiment everywhere except for your fry basket.

Don’t use too little force. You’ll never get it open. These things are engineered to withstand natural disasters.

You should aim for an opening force of 32 PSI.

If you can’t get it open, use your teeth. Place the top corner of the packet firmly between your top and bottom front teeth, and using a hand, tear the packet away from your mouth. Spit out the plastic corner in a nearby waste bin.

Pour ketchup on your fries. Some users prefer to pour it all over their fries. Some prefer to pour a pile of pure ketchup on a nearby plate or napkin. Let your unique style shine!

Don’t pour too much — it’ll make the fry soggy and overly sweet, and you’ll run out of your packet too quickly, meaning you’ll have to repeat the previous steps all over again.

Don’t pour too little either. Fries without ketchup are sad.

You should aim for a 4:1 fry-to-ketchup ratio.

Eat fries. Don’t eat too many, you’ll feel bloated from all the salt.

Don’t eat too few. And really, isn’t it always too few?

You should aim to eat at a rate of 4-5 per minute.

We haven’t even explained to a user how to select ketchup for an at-home version of this procedure, or how to purchase the fries, or cleanup (hardware shutdown). And we certainly didn’t get into troubleshooting, like what to do if you get ketchup onto nearby objects like a white tablecloth or growling cat. But by this point, the user has started wondering why fries and ketchup ever seemed like a good idea and has been daydreaming about mustard and potato chips since step 4.

So if assembling the simplest (and most delicious) of snack foods can seem like a hassle when we explain it to someone new, what hope is there for bringing unfamiliar users onboard to service-oriented products with moving parts like dashboards, emails, alerts, and a support system? In the example above, we didn’t even get into best practices like chewing (32 chews before you swallow!), or fry selection (curly > waffle > shoestring) — how can we tell a new user not only how to do something, but also to do it in the best possible way, from the beginning?

The answer is we can’t. At least not if we want to make our users happy. Initially, every new piece of information about the product makes it seem that much more complicated. So what we’ve developed at Versa is something we call responsive onboarding, a process where the user’s behavior informs what product information we present, how, and when.

Instead of a big, all-encompassing onboarding process with listed steps, video demonstrations, and PDF tutorials, the only thing we make sure our new clients understand before they use the product is how they will most often interact with it at the highest level. For Featured Perspectives, this is “alert, write, publish.” For ketchup, it’s “open, pour, eat.”

After that, we let them loose. Based on a client’s use of the product, we’ll guide them in the areas of Featured Perspectives where they demonstrate insufficient initial understanding, and leave out explanations of processes that they clearly get. For example, one user might start with fantastic content for their perspectives, but might not know how integral the CTA link is to make that content actionable. In that case, we’d skip the “here’s how to write good content" and "here are our submission guidelines" and "here’s what readers want to be reading” spiels entirely, and solely give them tips around CTA links. 

With responsive onboarding, we’ve been able to cut out 63% of the features, how-to’s, and tips that we’d normally share well before the client ever published a Featured Perspective.

63%! Without a responsive process, that 63% would have been useless knowledge, no-duh moments, and glazed-over eyes that we dumped on the user, in turn making our product seem (at least) 63% more complicated.

by Dan   

For today's publishers, convincing readers to click through to their content from social media is a business imperative. Traffic to news sites generated from social media has increased by 57% since 2009, and this boost in traffic referrals means that all publishers are waged in a 24/7 battle for readers' attention on Facebook, Twitter, Linkedin, etc.

The problem? Sexy, enticing headlines designed to win clicks are rapidly replacing honest ones, and readers are the victims. 

When a reader clicks on a sensationalist headline about kitchen tools that promises "you won't believe you ever lived without them!," they're unlikely to experience an epiphany as the headline teaser suggests (if anyone is impacted by a story about new kitchen gadgets in this way, shame on me). 

You might be thinking, "So what? All readers have probably already learned to ignore the absurd sensationalism of social media headlines and can now 'read between the lines' to determine what stories they actually want to read."

Fair argument. But I see a greater problem here, which is that the more that a news publisher sets incorrect expectations for readers, the more they risk losing their trust. And since the primary role of news media is to be a truth-teller and watchdog on current events, trust should be priority #1.

As many have documented, the use of exploitative, flashy headlines is even more rampant in the sponsored content world, where the number of impressions and engaged readers has been driving strong revenue in the new-ish ad category of promoted links (content discovery). And in content advertising, as with publishing, the temptation to make article headlines shocking, sexy, and irresistible is hard to resist.

But the longterm impact of failed expectations is as problematic for the advertiser-reader relationship as it is for the publisher-reader relationship. The moment you've lost readers' trust, you've lost your audience! (and your revenue).

At Versa, we believe that the relationship between the publisher, reader, and advertiser is sacred, and should be built upon trust and a well-defined practice of setting correct expectations. Our sponsored opinions product, Featured Perspectives, is designed to provide readers with relevant, factual, and substantive content that is conversant with the topical articles it lives below. Our contributors focus on real issues and raise their brand authority and affinity by creating and sharing real content. As David Zax of Fast Company states, it's a "win-win-win for publishers, brand, and readers." 

by Dave

I’ve played soccer for most of my life. In high school, we had two coaches, the senior of which was German. He would routinely scream “mach schnell” as we completed our drills and built the muscle memory necessary to react with confidence when the time came. And while I don’t appreciate being screamed at in German (let’s be honest, being screamed at in Italian is way more fun!), I do appreciate coaches.

I’ve had coaches for team sports, for academic pursuits, and for a fellowship. I’ve also been a coach. Coaching is about creating a structure for teaching one to achieve the goals they’ve set for themselves. It’s important and it can often be the difference between success and failure.

At Versa, each member of the business development team has a coach, someone to help build the muscle memory necessary to react with confidence. Whether it’s a conversation with a major publisher or the founder of a leading strategic communication firm, it’s important to be capable in the moment and as confident in your communication as you are in your product and team.

Coaching and practice (lots of practice!) has enabled us to be confident in our ability to focus on the TRUE conversation: A conversation in which you learn about organizational goals and personal motivations, a conversation in which you establish expectations and concrete next steps.

The TRUE conversation is hard; it’s more than a pitch deck and a rehearsed script. It’s more than the metrics you memorize or the hours you work. The TRUE conversation is the one in which you create the foundation for a productive business relationship. It’s about listening and learning and it’s about results and revenue. It’s the difference between success and failure and it’s certainly worth the practice.

by John

Update: very similar email preview functionality has been integrated into Rails 4.1

Here in the Versa Nerdery, we send HTML emails. We also build our mailers via Test Driven Development (TDD).

One way we've tried to limit the effects of context switching between building email logic and implementing the email design (we are full stack engineers, so we do both) is to use our tests to build easily accessible previews of our HTML emails.

Here is a piece of code we have in our spec_helper.rb file:

# Helper method for generating HTML emails to test. # @email_name - Name for the email. This is what the html file will be named. # By convention, we use the mailer action that creates the email. # # @message_html - a string of html, usually the result of calling '.body' on an ActionMailer object. def generate_html_email(email_name, message_html) email_path = File.join(Rails.root,"public","emails","#{email_name}.html") IO.write(email_path, message_html) puts "Preview email at: #{root_url}emails/#{email_name}.html" end

Then, in our mailer test we call this method just before we leave the test, passing in the name of the mailer action we are testing and the message body generated by the test.

# Contrived example of a UserMailer that sends the user # a "Welcome to the Versa platform!" email describe UserMailer do describe 'welcome_to_platform' do before :each do user = FactoryGirl.create :user, :email => '[email protected]' @message = UserMailer.welcome_to_platform(user) end it 'should set the reciever email' do @message.to.should eq ['[email protected]'] generate_html_email('welcome_to_platform', @message.body.encoded) end ...real tests... end end

Helpful blog post: How to test mailers in Rails 3 / 4 with Rspec

When this spec runs, it will generate an HTML file in the public/emails/ folder. This means that to preview the email you just need to point your browser to http://your_app.url/emails/welcome_to_the_platform.html and see the email in all its HTML goodness!

As you implement the email's design you can get an updated preview by just running your spec. If you've got automated specs (using something like guard), you don't need to do anything; the specs will build your preview automatically - just hit refresh.

The Internet is polarized when it comes to digital advertising. These diametric diatribes take some form of the following:

Either… 

1) AdVERTISING is evil. It’s annoying, disruptive, sneaky, and unrelenting. It’s simply the worst, as evidenced by sharp drops in engagement and the increased reliance on adblocking software by internet users.

Or…

2) Ad-BLOCKING is evil. It’s annoying, thieving, sneaky, and self-righteous. It’s simply the worst, as evidenced by its contribution to the sharp declines in online revenue for publishers and content-providers. 

Accusations, finger-pointing, and apocalyptical warnings come from both sides. Situated between those who scream “click!” and those who shout “block!”, at Versa we wondered — might there be a middle way? One that privileges a delightful user experience while keeping publishers in the black? 

So, we’re on a mission to do just that by channeling high quality stakeholder discussion to news articles. Discussion that is, yes, sponsored, but that, first and foremost, is conversant with the article and most importantly additive. Can we help organizations spotlight their views through paid content and content that users might actually want to read?

We’ve spent the past few months in the earliest stages of our product testing that very question. And, so far, we’re so buoyed by the strong support for our product that we’ve seen from the crowd. From you. From the people who care about the commons of the internet. Especially if you’re one of the 65 million people who use AdBlock Plus (ABP).

If you're a participant of this vast browser extension community, through your ABP shield you’ll now still be able to our sponsored content. We are so proud to report that we’ve earned your trust as an Acceptable Ad.

AdBlock Plus is an organization that we like to think of as the gatekeeper of the internet. Like us, they are also battling a dichotomy – yes, most advertising is terrible and yes, great content ultimately must be ad-supported…so, why not incentivize innovation in advertising that delivers value to BOTH the publisher and the audience? AdBlock believes in an internet that can have it both ways.

That’s why in 2011 they began an “acceptable ads” program in which a certain set of advertisements that meet do particular criteria will be seen even by those who have ABP activated.

So what are those criteria? There’s a preference for text, and labeling and separation from any non-sponsored content among other criteria. But, much more importantly to ABP and to us, even those ads that pass the “criteria” test must be approved by the entire AdBlock Plus community in their forum. In other words, the decision about which ads are “acceptable” isn’t up to an executive, but the millions of users who make the conscious choice to let an ad into their browsers.

Above and beyond anything else, that’s what excites us about our acceptance into Acceptable Ads. It’s incredible validation that we are meeting our mission to deliver great content for you and a meaningful impact to the bottom line for publishers.

by John

A lot has been written about paying down technical debt. We all know that we are better off making the effort to regularly pay it down then to let it grow until it becomes unmanageable and you are forced to stop pushing features. Unfortunately, software is built by humans, a species not known for acting responsibly with regards to debt.

Last week, we decided to not act like humans and spend a few days paying down the interest on our technical debt. Specifically, we focused on a subset of technical debt: removing unused code.

I'll start with some numbers. After the code cull, reckoning, whatever you want to call it, we were left with:

~180k fewer lines of code

63 fewer models

50 fewer PostgreSQL tables

3 fewer gems

1 less (enormous) MongoDB collection

Numbers are fun, but I'd also like to explain our reasoning behind the cull and why now seemed like a good time to do it.

Every pivot leaves a scar

Here at Versa, we've experimented with a variety of different products to help people have access to the information they need to be engaged, effective citizens. We've pivoted... a few times. During last week's cull, we successfully removed 3 products from our codebase that we no longer support. Whew.

Onboarding

We are growing our engineering team and one of the more awkward moments of on-boarding someone is saying "oh, see those 63 models (or controllers, views, stylesheets, etc.)? Don't worry about them. We don't use them anymore."

This is akin to saying "use a percentage of your cognative resources to remember to forget about these 180k lines of code." I know it sounds ridiculous to say that, but it's essentially what we are doing whenever we tell someone to ignore chunks of old code.

Reliable Testing

Around the end of the last Mayan baktun we started taking testing seriously. Sure, we'd had tests around some of the more important processes in the system, but it was in December 2012 when made tests first order citizens in our codebase (side note: here's an awesome AirBnB blog about getting their team to this place).

The problem with this, though was that our test suite took forever to run - in part because we lots of tests around complex logic in code we no longer used. The solution at the time was simply rspec spec/ --tag new_baktun and we added the new_baktun tag to all new tests.

Tagging like this works fine until you want to get an idea of your test coverage. Again, we're to a place where we've got to use precious mental resources to remember which code we actually use and which we don't.

Post-cull, we can just run rspec spec/. All our tests run and our test coverage is accurate (even if it's not 100%).

Catharsis / Reflection

Deleting old code is a lot like burning a pile of love letters to an ex. You poured your heart and soul into them - you really meant it at the time, but now you are a different person they represent the old you (2 or 3 products ago). Time for a new dress. Say an incantation and torch the lot of 'em. Cleanse.

Decoupling and removing old products also brought to our attention a few bits and pieces we didn't even know existed. This included a lightweight billing system and a sweet helper for adding/removing foreign keys in Rails migrations. That last helper also showed me an awesome gem from my predecessor that we will start using again.

Unlike the love letter analogy, we can always go back and see our old code on GitHub - because who puts love letters on GitHub? (Oh, wait, this Korean dude did)

What's next?

After all this work we aren't technical debt-free, but now that we've paid down all the interest in the "unused code" category we get back into build mode.

As fun as it is to have more deletions than additions on our main app, it's time to get back to iterating on our JS app to serve smoothly over 1.5M times a day, to refine and expand our predictive models (which analyze thousands of news articles a day) and to add features to our internal & client-facing services to keep our clients & publishing partners excited to work with us.

Welcome to Versa!

We’re thrilled to announce that the company formerly known as ElectNext (can we get a symbol for that?) is now Versa, where we’re re-imagining the sponsored editorial.

We began our journey two years ago, fueled by a belief in an informed and engaged public and with a single product that focused specifically on empowering voter choice in elections. Since that time we have vastly expanded our reach and our offerings, with a suite of products designed to embed directly in news stories and bolster your understanding of news-making people, issues and events.

So, why “Versa”? In Latin, “versa” originates in the verb “to turn,” or shift your gaze, as in “vice versa.” And, “versa” is also the building block of the word conversation -- a fairly fundamental feature of an active and mindful public, we thought.

From our origins in a quiz that revealed candidates you didn’t know you agreed with, to Featured Perspectives, a new category of sponsored editorial that elevates stakeholder voices around the most salient issues of the day, as Versa, we’re continuing a long tradition of showcasing a diversity of viewpoints, facilitating inclusive dialogue, and getting ever closer to a world that meets our vision, in which every person is equipped to be an informed, engaged citizen.

To those who made this journey possible, rewarding and so. much. fun: THANK YOU. All of you. We could not have done it without you.