DEV Community: Scott Dudley

Ranked_Model: A Rails Gem for Multiple Data Sets

Scott Dudley — Tue, 30 Oct 2018 23:03:22 +0000

Recently we ran into an issue on a client Rails application where we wanted to customize the order in which certain items would appear on various pages. The admin users would log in to a CMS built with active_admin, create a widget with information about a company, and then either manually set the position in the list while creating or editing the widget, or use a 'move up and down' feature on the index page.

Originally, we utilized the acts_as_list gem to implement this feature as it allowed us to quickly and painlessly add all the functionality we needed.

I ran into an issue, though, when our client requested that each widget have two separate rankings, depending on which page the user was visiting. If the user was on the Foo product page, the widget might appear at position 2, but on the Bar page the widget would render in position 3.

My initial instinct was to create a new position attribute on the widget model and pass in both the new attribute and the existing position column into the acts_as_list method. However, I hit a roadblock since acts_as_list is not capable of handling two different attributes on a single model.

This was a time sensitive request and as I dove into the possible solutions of using associations and join tables to add this feature with acts_as_list, I couldn't help but feel that there should be a quicker solution that could handle having two different ranking systems for a single model.

My search led me to discover ranked_model, a gem with a similar goal to acts_as_list but with a different implementation and functionality, most of which fit our criteria with much more ease than the acts_as_list approach.

After installing the gem and including RankedModel in the class file, you can simply declare which attributes will be handled by ranked_model with the following lines:

ranks :foo
ranks :bar

This would work fine on a greenfield project or a new attribute but I was adding this to an attribute that already had position-oriented ranking applied. Both gems use integers as their data types, but for the most part, the similarities end there.

acts_as_list uses sequential numbers in its assigned attribute, incrementing and decrementing multiple objects as necessary with each change in the order. For example by taking a list of widgets with positions of A: 1, B: 2, C: 3, & D: 4, then moving D to the first position, D would become 1 but B, C, and A would all be incremented to fully reorder the list. There are more methods to run each time but it’s simple to glance at any given object and understand its exact position.

Ranked_model on the other hand, utilizes relatively large numbers, both positive and negative, to more quickly and efficiently order objects. Creating the same 4 objects with ranked_model looks far different, that acts_as_list, being more like this:

A: -2342567, B: -1437689, C: 1289078, D: 2165876

Since ranked_model generally deals with larger integers, it can cause more difficulty in development and debugging, particularly in the console. Once a sizable number of objects is reached, finding the relative place in the ranking from only its position attribute would require notable attention to detail. However, calling a method to actually move these positions is simple enough.

To mimic the same widget repositioning as the acts_as_list example, moving D to the first position, the code would require a call of:

D.update_attribute :foo_ranking_position, :first

which would result in something like:

D: -2465876, A: -2342567, B: -1437689, C: 1289078

So you can see, using these large integers allowed us to reorder D to the front and only modify a single object! This becomes especially valuable in situations with large datasets. As mentioned earlier, ranked_model also allows us to call rankings on multiple attributes, so using:

D.update_attributes {
  foo_ranking_position: :first,
  bar_ranking_position: :last
}

would be completely acceptable.

Migrating from acts_as_list to ranked_model did take a little bit of work, though. Since we already had an ordered attribute from acts_as_list, attempting to just write in and start using ranked_model on it outright led to some strange interactions and incorrect sorting. My solution was to add the following to a database migration:

reversible do |direction|
  direction.up do
    Widget.order(:foo_position).each do |widget|
      widget.update_attribute :foo_position, :last
    end
    Widget.rank(:foo_position).each do |widget|
      widget.update_attribute :bar_position, :last
    end
  end
end

This is probably a little overkill and almost certainly could be refactored to look more elegant or efficient (and also should probably be a rake task) but it worked with our need for a quick turnaround. It's essentially going through our original order from acts_as_list and telling ranked_model to order it at the end of the list, making sure all positions now have a ranked_model compatible position.

After using some of the syntax particular to the gem, in order to modify the methods and controllers that were updating position in the class file, ranked_model proved to be an efficient way to sort and rank multiple datasets for Rails.

How to Estimate Small Tasks for a Big Client

Scott Dudley — Wed, 05 Sep 2018 22:05:25 +0000

There’s a plethora of articles, books, and blogs on how to accurately estimate large software projects. Something that’s going to take multiple developers a decent chunk of a week, month, or year will almost always have meetings between developers, project managers, and other staff where estimates will be checked and challenged.

Where I have definitely struggled to improve, though, has been estimating the all-too-common ‘small’ tickets: ones that are large enough that an estimate is expected but too small to necessitate bringing in additional help or conferring with other developers.

For me these are tickets typically are somewhere in the 4-15 hour range. Anything less is likely a simple enough solution to go on gut instinct, and anything more might affect my schedule for the week, so I’d likely need to run it by someone else.

Here are some tips and tricks I’ve found help me independently estimate this type of task

Compare to Completed Tickets

This one is a bit obvious, but if you can compare the current task to a completed task, you can get a really great baseline with which to work. For example, if a client is looking to mimic the analysis of another report but reference a new set of data, seeing how many hours were put into the ticket regarding the original report feature can help give you a ballpark.

This also speaks to the importance of labeling and linking tickets and issues. Institutional knowledge of a project and specific tickets is great for experienced developers but without some sort of trail or documentation of past work, newer developers will have a hard time knowing that previous efforts might be applicable to new problems. While it can feel tedious, be sure to fully learn and utilize all the various tools of your ticketing or project management system.

Think Work Days, not Hours

Sometimes trying to assign specific hours to a task can be daunting. Will figuring out this specific loop I know I’ll need take an hour? Three? Maybe three and a half? Estimating specific elements of a ticket can start feeling especially nebulous and arbitrary, which can easily lead to spinning your wheels while estimating.

When I find myself in that situation I’ll often ask myself the following question:

If I was given an entire work day, am I confident I could get this task done?

This question can help set the boundaries for tickets. If your answer is a quick and resounding ‘yes’ then you know the estimate can be narrowed down to somewhere in the 2-8 hour range. If your answer is a resounding ‘no’ then it’s likely time to talk with a project manager or at least take some time to figure out why exactly this will be a multi-day task.

If your answer is a less solid ‘yes’ or a ‘maybe’, some other considerations should come into play. Context switching is likely to become an issue in these instances as urgent bugs and meetings are extremely likely to interrupt your work in this type of ticket. When I am estimating a ticket with a ‘maybe’ on completion in a single work day, I tend to add about 10-20% more time on whatever my final estimate is purely for context switching. That way stepping away from a ticket does not have any additional pressure to try and make up for the time from context switching.

Rubber Ducky Your Pseudo Code

This is a way I double-check my level of confidence in an estimate. If I can write down my pseudo code and then talk my way through how that pseudo code will complete the requirements, I can feel confident that my estimate will be accurate. If I have trouble talking out the whole process or feel shaky about where exactly certain parts of the solution would fit, then I know I should add some padding to my estimate.

I recently had an example where this method led me to more accurately estimate a ticket. I initially estimated a ticket taking four hours based on previous similar tickets but I decided to step back and actually write out some pseudo code for the solution. As I walked through the process in my head, I floundered a bit on whether a particular part of the planned code should live in a controller or the model. I bumped the estimate on the ticket to five hours because of my hesitation and the final tally of time spent on the issue was four hours and forty seven minutes.

Retrospectives

Whenever I go ten percent or more over my estimate on a ticket, I try to take some time and figure out why I underestimated it. Was it a communication issue? Did I not fully understand the requirements? Did I forget to include time for writing tests? Was context switching or catching up on project changes an issue? Maybe I just plain old thought one specific method would not be as complex as expected.

Estimating is a skill and skills take time, effort, and experience to improve. Taking time and really digging into the specific causes of an inaccurate estimate can sharpen your estimating skills dramatically.

Gut Instinct and Willingness to Fail

In the end, your gut instinct is often one of the most important parts of estimating tickets. Sometimes a feature is entirely new and does not have a relatable, completed ticket. Maybe it will require interacting with a newer framework, so you are unsure if something will take a day or a week! Those kind of situations can be especially nerve-wracking as estimating those can feel like exposing yourself to a situation where you will be way off base. The reality is that you likely will be from time to time. Remember that learning from mistakes is always one of the best ways to improve at something!

All the Pieces Matter

Estimating small tickets may not seem to be as essential or dramatic as estimating large projects, but consistently giving more accurate estimates for large numbers of small tickets can be a major boon for both developers and clients. Being half an hour to an hour more accurate on small tickets can quickly add up to significant numbers.

It gives clients more confidence in what they can tell their stakeholders to expect and it allows for better forecasting and resourcing for developers.