Tag Archives: one-time announcements

Creating a Ruby gem for one-time announcements, part 4 – performance, views

I’m developing a gem to deliver one-time announcements to users in Rails apps. See the previous parts of this series for some background.

Now, in part 4, we’ll test performance performance and add a view to show the current announcement.

Measuring performance

How much work does the gem have to do in order to retrieve the latest announcement for the current user?

Database calls are often a performance culprit. Queries should be small in number (see N + 1 problem) and minimally taxing on the database.

The gem runs only one query to retrieve the latest announcement.

To see how long that query lasts, we’ll run the method that calls it in the Rails console. The current method of the Announcement model checks for an announcement for the current user.

What if we have 1,000 announcements and 50,000 users? There are a few ways to test performance of a specific method, one of which is a benchmarking gem from Viget Labs. I used Ruby’s built-in benchmark module.

The call to Announcement still comes in at under 1 ms with 10,000 users and 5,000 announcements.

Showing announcements

A view helper called current_announcement will call the current announcement from the model.

Then, the developer using the gem can pull in the current announcement through a view partial.

We still need to let the user close the announcement, and remember the announcements that each user has read.

Integrating with Foundation and Bootstrap

At Cook Smarts, we use Zurb Foundation, and it’s served us well.

The gem will include templates for announcements using Foundation’s and Bootstrap’s existing styles.

It will also include a template for sites that do not use either framework. In that case, it is up to the developer to style the announcements in the app’s CSS.

What’s next

Next, we’ll talk about remembering which announcements have been read by the current user, security, and how site administrators can add announcements.

Creating a Ruby gem for one-time announcements, part 3 – targeting messages to users

This is part 3 of building a gem for targeted, one-time announcements to users in Rails. See part 2 and part 1.

We’ll focus on targeting announcements to certain types of users. For instance, the admin may want to deliver an announcement only to users who have subscriptions.

A field in the Announcements table called limit_to_users will specify which types of users should receive the announcement.

limit_to_users can contain multiple conditions, so we’ll make it an array of hashes. ActiveRecord allows objects like these to be stored in text fields in the database, using the serialize method in a model.

This test validates that the field works as intended, storing conditions and allowing them to be retrieved. Here, we are sharing the announcement only with users who do not have a subscription.

Querying serialized fields is tough

It’s risky to query serialized fields in a relational database. MongoDB and similar noSQL databases are tuned for fast queries of free-form information, while Postgres and its SQL siblings are not.

We need to figure out which announcement to serve to which user, even though the conditions are stored in a query-resistant serialized field.

Houston, we’ve got loops

Maybe we should grab all active announcements that the current user has not read, and cycle through them to find the latest one that is relevant to the user.

My first try at this includes two loops, one inside the other, which:

  1. Cycle through each active, unread announcement
  2. For each announcement, cycle through each condition

Loops carry potential performance issues, especially when nested. In this case, we came as far as we could with a query, and used loops for the rest.

The loops do not re-query the database, thus avoiding an n+1 query problem, so they should be pretty quick. We’ll test performance in past 4, coming soon.

Creating a Ruby gem for one-time announcements, part 2 – TDD, marking as read

In part 1, I talked about the need to announce things to users in a Rails app. The announcements should be scheduled, shown to each user only once, and targeted to particular types of users.

We’re building a Ruby gem to enable this.

Tests

I started by writing tests, describing what the one-time announcements gem should do. Test driven development (TDD) can be controversial, but I find that it helps me plan and identify issues earlier in development.

I learned how to test from Everyday Rails Testing with RSpec. The author continually updates it as new versions of Rails and RSpec are released.

The first tests confirm, at the model level, that announcements can be:

  1. Created
  2. Scheduled
  3. Marked as read

These tests pass with the current Announcement model:

Marking announcements as read

Each user should see a particular announcement only once, so I needed a way to mark announcements as read.

The unread_by scope above shows only those announcements which the user has not read. It uses the AnnouncementView model to see who has read which announcements:

The current method chains the ready_for_delivery, unread_by, and in_delivery_order scopes to determine which announcement to deliver.

This StackExchange thread helped, and I took inspiration from a gem specifically for marking messages as read.

What’s next

In part 3, we’ll look at how to target announcements to particular types of users. For instance, what if you have an announcement just for users on a particular subscription plan?

Creating a Ruby gem for one-time announcements – part 1

At Cook Smarts we need a way to provide one-time announcements to customers, right inside our Rails app.

For instance, we may want to notify our paying users of a new feature when they log in.

Once the customer reads the announcement, he or she can close it and will never see it again.

The closest Ruby gem I could find is thoughtbot’s paul_revere. It’s elegant and simple, providing one-off announcements to an app.

It does not, however, support:

  • Start and end dates for an announcement What if an announcement is relevant only for a period of time?
  • Announcements to a subset of users What if an announcement is relevant only to some users?
  • Remembering across devices that a user closed a message If the user already read a message on desktop, why should they see it again on mobile?

What about keeping it simple?

One-off announcements may seem simple at first, but in practice, they benefit from more granularity.

Showing people only the announcements they need, at the right time, and only once, increases the messages’ potency.

Filtering announcements by user characteristics

Each announcement will be filtered based on conditions about the current user. For instance, is the user on a free trial or paid plan? When they did they sign up?

Perhaps we need to grab all announcements the user has not read with a simple database query, and then use some logic to see which of those is relevant to the user.

In any case, I’m looking for a safe, customizable way to target one-time messages.

What’s next

Next, I’ll take you through the process of creating a Ruby gem for one-time announcements. Stay tuned for part 2…