DEV Community: Joe McCann

Using Ruby to Translate Roman Numerals to Integers

Joe McCann — Tue, 06 Sep 2022 20:43:38 +0000

Spoiler Alert: This post reveals a solution to a common coding problem. Here is a link to the problem on leetcode with instructions if you'd like to solve it your own way first before reading on. Otherwise, join me below!

Introduction

Recently, I have been trying to maintain my coding chops by regularly submitting leetcode and codewars solutions. I thought I'd start with the 'easy' ones first to warm up. This one was categorized as easy but only has a 58% acceptance rate.

Defining the problem

Basically, the goal is to write a function, that, given a Roman numeral string as an input, outputs the equivalent integer, e.g., "MCMXCIV" => 1994.

Thinking about data structures.

My first thought was that I should map the fundamental Roman numerals to their equivalent values using a hash map, like so:

def numerals
  {
    'I' => 1,
    'V' => 5,
    'X' => 10,
    'L' => 50,
    'C' => 100,
    'D' => 500,
    'M' => 1000
  }
end

I noted I am also dealing with a string and likely an array.

Manipulating strings and arrays

I realized I will also need to evaluate the characters of the string. Ruby has a handy string#each_char method that iterates over each individual character of a string, so 'VIII' would be split into an array of characters as ['V', 'I', 'I', 'I' ]. Now that I am working with an array, I have access to the array#map method, which can be used to map each numeral character to its value:


['V', 'I', 'I', 'I'].map { |n| numerals[n] }
# => [5, 1, 1, 1]

# using built-in array#sum method
['V', 'I', 'I', 'I'].map { |n| numerals[n] }.sum

# => [5, 1, 1, 1].sum
# => 8

So we're done right? We've basically covered the process we already do in our head (5 + 1 + 1 + 1 = 8)

Gotchas

However, the tricky part comes when Roman numerals signify a number that is one factor less than a multiple of 5 or 10, e.g. IV is one less than V and means subtract one from five and return four. From the exercise instructions linked above:

I can be placed before V (5) and X (10) to make 4 and 9.
X can be placed before L (50) and C (100) to make 40 and 90.
C can be placed before D (500) and M (1000) to make 400 and 900.

This throws a wrench in our plans to simply sum the mapped characters of the string, because the above method does not "group" the numerals in anyway. Perhaps there is a way to extract those special cases, e.g. IX and CM.

First, let's also define them in a hash like the one above:

def special_numerals
  {
    'IV' => 4,
    'IX' => 9,
    'XL' => 40,
    'XC' => 90,
    'CD' => 400,
    'CM' => 900
  }
end

The scan method

Now we need a way to scan the string and check for these special numerals. Thankfully, Ruby makes it easy with the string#scan method which returns an array of matches found in the string:

  s = "MCMXCIV" # 1994
  special_matches = s.scan(/IV|IX|XL|XC|CD|CM/)
  # => ["CM", "XC", "IV"]

This allows us to use the same "map and sum" logic used above. But what to do with the remaining "non-special" characters. This will potentially result in counting some numerals twice. This can be prevented with a simple check.

First, check if there are any special numerals used in the string. If so, map them to their values and sum them. Record this sum in a variable.

The gsub method

Second, remove those "special" numerals from the string so that the remaining numerals can be summed accurately. This is where the handy string#gsub method comes in:

  s = "MCMXCIV" # 1994
  special_matches = s.scan(/IV|IX|XL|XC|CD|CM/)
  # => ["CM", "XC", "IV"]
  special_sum = special_matches.map { |m| special_numerals[m]}.sum
  # => 900 + 90 + 4 == 994
  special_matches.each { |m| s.gsub!(m, '') }
  # s is modified in place with its special numerals removed.
  # => s == "M"
  # we still need to add 1000 to our result

And so, the input string is now "M" and can be summed using the same logic. In this case, there is only one character, but the logic is the same for multiple characters:

  normal_sum = s.each_char.map { |c| numerals[c] }.sum  
  # => numerals['M'] == 1000
  # => [1000].sum
  # => 1000

Solution

Putting it all together we return the "special" numeral sum plus the "normal" numeral sum if there are any "special" numerals in the string. Otherwise, we return the "normal" sum. In code, I translated this logic to the following solution:

def roman_to_int(s)
  special_matches = s.scan(/IV|IX|XL|XC|CD|CM/)
  if special_matches
    special_sum = special_matches.map { |m| special_numerals[m]}.sum
    special_matches.each { |m| s.gsub!(m, '') }
  end
  normal_sum = s.each_char.map { |c| numerals[c] }.sum  
  return (special_sum + normal_sum) if special_sum

  normal_sum
end

def numerals
  {
    'I' => 1,
    'V' => 5,
    'X' => 10,
    'L' => 50,
    'C' => 100,
    'D' => 500,
    'M' => 1000
  }
end

def special_numerals
  {
    'IV' => 4,
    'IX' => 9,
    'XL' => 40,
    'XC' => 90,
    'CD' => 400,
    'CM' => 900
  }
end

roman_to_s("MCMXCIV")
# => 1994

Conclusion

I do not think this is the fastest solution on leetcode, but I personally find it readable. This is a testament to the power of the hash data structure, which made it straighforward to map a numeral to its integer value.

How did you solve this problem or what could I do differently? Let me know in the comments below!

Adding a Users Search to a Rails Facebook Clone

Joe McCann — Sun, 16 Jan 2022 06:38:40 +0000

Photo by Andreas Wagner on Unsplash

Introduction

I recently completed the core functionality of my Rails Facebook clone project, Gembook. I recently decided to add a rudimentary search form to the Users#index page, allowing users to search for other users by name. I knew this would involve playing around with routes.rb, and that I would need a form to submit a get request to the route created in routes.rb.

What does this post cover?

We will cover the steps necessary to implement a basic search feature. This will make it easier for users to find their friends, but the approach used here can be applied to any application where a user might want to search a collection.

This post will cover the following:

Adding a route to handle search requests
Creating the User.search method
Handling the search request in the UsersController
Submitting the Search Form and Displaying Results
Testing this behavior with RSpec

Step 1 | Adding a Route to Handle Search Requests

I am using resourceful routes for this application. Since we are searching for users it makes sense to nest the search route within resources :users. For an excellent guide to routing in Rails, see the official guide.

Let's break down get 'search', to: 'users#index', on: :collection. The snippet below allows get requests to /users/search and dispatches those requests to the index action of the UsersController. It will also create the search_users_url and search_users_path route helpers, which we will use later.

  # config/routes.rb
  resources :users, only: [:index, :show] do
    get 'search', to: 'users#index', on: :collection
    resource :profile
  end

Before submitting search requests, we need a way for requests to be processed. We are searching for users, so it makes sense that we involve the User model, as that is the model that knows everything about a given user, including their name, which is how a user will search for other users.

Step 2 | Creating the Search method

My User model includes both a first_name and last_name column. The User.search method will perform an Active Record query using the query argument. Unnecessary database calls are prevented by the guard clause return unless query. The query argument is assigned to name, stripped away of any whitespace, converted to lower-case, and split into an array. Users can then search by first or last name and the method will return matches for either or both. The lower function is an SQL function that converts a string to lower-case.

  # app/models/user.rb
  def self.search(query)
    return unless query

    name = query.strip.downcase.split
    where('lower(first_name) = ? OR lower(last_name) = ?', name.first, name.last)
  end

Step 3 | Handling the search request in the UsersController

Because Rails' controllers handle all incoming requests from the router, when a get request is submitted to /users/search, the request will be dispatched to the users#index action as shown above. The controller also can create an instance variable, in this case @results, that is accessible to the View.

Below, the controller sends a message to the User class (:search) with an argument from the params hash, params[:query] and assigns the results to the @results instance variable.

  # app/controllers/users_controller.rb
  def index
    # other instance variables etc...
    @results = User.search(params[:query])
  end

Step 4 | Submitting the Search Form and Displaying Results

Submitting the Search Form

Here is where all the above setup pays off. Using the form_with helper, we can submit a get request to the search_users_path, triggering the index action of the UsersController (remember our route: get 'search', to: 'users#index', on: :collection). As seen in Step 3, the index action includes a call to the User.search method.

  <%= form_with(url: search_users_path, method: :get) do |f| %>
    <%= f.text_field :query, placeholder: 'Search for users by name.', required: true %>
    <%= f.submit 'Search' %>
  <% end %>

Upon submission of the form, the UsersController will have access to the params hash, specifically params[:query]. For example, consider a user named John Hancock. His friend, Thomas Jefferson, wants to search for him using Gembook. Mr. Jefferson enters 'John' into the text field. The query of 'John' gets passed to the UsersController as {"query"=>"John"} and an Active Record query is performed in the User model.

Displaying Results

To display the search results, we can create a partial: app/views/users/_result.html.erb. This allows utilization of the :collection option. For more on this, see the official guide.

<!-- app/views/users/index.html.erb -->
<% if params[:query].present? %>
  <h2>Search Results</h2>
  <ul>
    <%= render partial: 'result', collection: @results %>
  </ul>
  <%= content_tag(:em, "No users found") if @results.none? %>
<% end %>

What you display in your result partial will depend on your application.

Mine looks like this:

 <!-- app/views/users/_result.html.erb -->
  <% if current_user.friends.include?(result) %>
    <%= render partial: 'friend', locals: { friend: result } %>
  <% else %>
    <%= render partial: 'user', locals: { user: result } %>
  <% end %>

The result object is sent to a different partial depending on whether or not the current user is friends with the search result. If they are friends, an "unfriend" button will appear. If they are not friends, an "Add Friend" button will appear.

Step 5 | Testing with RSpec

Unit testing User.search

Before writing a system spec, let's make sure this method behaves as expected with a unit test in user_spec.rb. A variable called expected results holds an Active Record relation returned from the test database. A variable called search_results holds the ActiveRecord relation returned by the User.search method. We then assert that user, who is a member of expected_results, is included in search_results.

 # spec/models/user_spec.rb
  RSpec.describe User, type: :model do
    before do
      Rails.application.load_seed
    end

    let!(:user) { User.first }

    # several other specs etc...

    describe '.search' do
      it 'accepts a query string and returns user results' do
        expected_results = User.where(first_name: user.first_name, last_name: user.last_name)
        search_results = User.search(user.full_name)
        user = expected_results.first
        expect(search_results).to include(user)
      end
    end
  end

Writing a System Spec

For the system spec, we want to simulate user interaction with the application. To achieve this, we can create two test users, Thomas and John, and have Thomas search for John. We will then assert our expectation that a valid search returns a matching user and that a search for a non-existent user comes up empty.

# spec/system/search_users_spec.rb

require 'rails_helper'

RSpec.describe "SearchUsers", type: :system do
  before do
    driven_by(:rack_test)
  end

  let!(:user) { User.create(first_name: 'Thomas', last_name: 'Jefferson', email: 'thomas@jefferson.com', password: 'foobar') }
  let!(:other_user) { User.create(first_name: 'John', last_name: 'Hancock', email: 'john@hancock.com', password: 'foobar') }

  describe 'searching for a user' do
    context 'a user is logged in at users#index' do
      before do
        login_as(user, scope: :user)
        visit users_path
      end

      it 'allows them to enter a query and shows them results' do
        query = other_user.first_name
        fill_in 'query', with: query
        click_on 'Search'
        expect(page).to have_content('Search Results')
        expect(page).to have_content(other_user.full_name)
      end

      it "Shows 'No users found' if there are no matches" do
        query = 'Joe'
        fill_in 'query', with: query
        click_on 'Search'
        expect(page).to have_content('Search Results')
        expect(page).to have_content('No users found')
      end
    end
  end
end

Conclusion

In this post, I attempted to show the process of adding a user search feature. In retrospect, I think a feature like this would be an excellent candidate for TDD. If I were to use TDD to implement this feature, I would probably start with the unit test and then write the method until the test passed, refactoring where appropriate. Next, I would write the system specs, and finally, write the form and view code to make them pass.

Writing your own search method is a good way to grapple with core Rails functionality. This feature utilizes the Rails router, Model, View, and Controller, all of which are working hard to display search results to your users.

I hope you enjoyed this post. If there is anything I did incorrectly or that could be improved, please let me know in the comments! I love to see different and better approaches to the same problem. Thanks and happy coding!

Extracting a Database Query from a Rails View

Joe McCann — Thu, 30 Dec 2021 06:47:55 +0000

Introduction

While some logic in Rails views is inevitable, recently I have been trying to move any unnecessary logic in the view to the model or controller--especially if it's a database query. This problem came into view while I was coding a Friendship "Accept" button in a Rails Facebook clone.

I had it setup so that users could accept or decline friend requests from the Notifications#index page. The problem was I had to locate the respective friendship object from within Notifications#index. This required a database query. Once I wrote the correct database query in the view to find the Friendship object associated with a notification, I started thinking of ways to remove it from the view. Below is how I approached the problem.

Every notification references a sender and a receiver, both belonging to the User class. Similarly, a Friendship object is initiated with a sender and a receiver. If a user has many friend requests on their notifications page, it is necessary to determine which specific friend request is being accepted or declined when the receiver clicks "Accept" or "Decline", respectively.

Therefore, when rendering the notifications collection, we can find the soon-to-be-accepted or soon-to-be-declined Friendship with notification.sender and
notification.receiver. The "Accept" button is as follows:

Initial "Accept" Button

  <% friendship = Friendship.find_by(sender_id: notification.sender.id,
                                     receiver_id: notification.receiver.id) %>
<%= button_to "Accept",
              friendship_path(friendship),
              method: :put,
              params: { friendship: { status: 'accepted' } } %>

We can eliminate the need for the local variable by creating a hash of all friend requests sent to the current user, mapped to the sender_id. The current user will always be the receiver in this situation and to find the Friendship request sent to the current user, we only need the sender_id. I thought it made sense to make this method an instance method on User but there are probably better ways to do this. Let me know in the comments! Here are the relevant models and associations.

Relevant Models

User, Friendship, Notification

  class User < ApplicationRecord
    has_many :sent_notifications,
            class_name: 'Notification',
            foreign_key: 'sender_id',
            dependent: :destroy
    has_many :received_notifications,
            class_name: 'Notification',
            foreign_key: 'receiver_id',
            dependent: :destroy

    has_many :sent_pending_requests, -> { friendship_pending },
            class_name: 'Friendship',
            foreign_key: 'sender_id',
            dependent: :destroy
    has_many :received_pending_requests, -> { friendship_pending },
            class_name: 'Friendship',
            foreign_key: 'receiver_id',
            dependent: :destroy
    # ...
  end

class Notification < ApplicationRecord
  belongs_to :sender, class_name: 'User'
  belongs_to :receiver, class_name: 'User'
  #...
end

class Friendship < ApplicationRecord
  enum status: %i[pending accepted declined]

  belongs_to :sender, class_name: 'User'
  belongs_to :receiver, class_name: 'User'

  scope :friendship_pending, -> { where(status: :pending) }
  #...
end

And now the method that maps a sender id to a Friendship object:

  class User
  #...associations, etc.
    def requests_via_sender_id
      requests = received_pending_requests
      sender_ids = requests.pluck(:sender_id)
      sender_ids.to_h do |id|
        [id, requests.find_by(sender_id: id)]
      end
    end
  end

Let's say received_pending_requests.count == 1 at the moment. A user with an id of 3 has sent current_user a request.

current_user.requests_via_sender_id =>
{3=>
  #<Friendship:0x000055f71022ec20
   id: 16,
   status: "pending",
   sender_id: 3,
   receiver_id: 1 }

The good thing about doing it this way is that the controller can now request this information from the User model prior to rendering the Notifications#index view:

  class NotificationsController < ApplicationController
    def index
      @notifications = current_user.received_notifications.includes(%i[sender receiver])
      @friendships = current_user.requests_via_sender_id # => returns a hash
    end
  end

Finally, we can return to our "Accept" button which has access to the current notification being rendered.
Note the absence of the friendship local variable:

Final "Accept" Button

<%= button_to "Accept",
              friendship_path(@friendships[notification.sender.id]),
              method: :put,
              params: { friendship: { status: 'accepted' } }%>

Conclusion

Another added benefit of this approach is improved readability. Which friendship are we updating? The one the sender of a notification requested -->
friendship_path(@friendships[notification.sender.id]). This is arguably more expressive than friendship_path(friendship), because it provides the context in which we are searching for a Friendship object.

Balancing responsibilities between the Model, View, and Controller is sometimes challenging, but making your way towards a solution piece by piece can be very educational and rewarding.

This was my first blog post. Thank you so much for reading. Having finished it I realize the benefit it has in regards to understanding. I hope to write more posts in the near future.

Photo by Lawrence Hookham on
Unsplash

Setting Up OmniAuth Authentication in Development

Joe McCann — Thu, 30 Dec 2021 06:08:41 +0000

Introduction

"Who are you?" may be the line sung by Roger Daltrey of The Who in their 1978 hit Who Are You, but it is also the fundamental question that Authentication answers.

Authentication is the process of determining whether or not a user is who they claim to be. You are likely familiar with the basic process. You sign up on a website with an email and password. The next time you log in you will be prompted for your email and password. If both your email and password are correct, the application verifies or authenticates your identity.

But what if we've already gone through this process on another site? Wouldn't it be nice if we could somehow communicate with that site's authentication system and use it to authenticate the users on our site? This is precisely what OmniAuth allows us to do, specifically through the use of community-built strategies, or code that allows one to authenticate to a given provider, e.g. Facebook or GitHub. You know those "Login with Facebook" buttons? Yep, that's what we're talking about here.

What does this post cover?

In this post, I will go over the steps I took to authenticate to GitHub in a Rails development environment using the omniauth-github gem, "the official OmniAuth strategy for authenticating to GitHub", along with Devise, and the figaro gem.

For some OAuth providers, you will need to install something like ngrok, a nifty tool that exposes your local WebHost to the internet.

This guide will assume you already have Devise authentication setup for your app. See the link above for installation instructions.

Outline

We will go over the following steps in more detail below.

Installing the figaro gem to securely store our OAuth Client ID and Client Secret.
Registering a new OAuth app with GitHub to use the GitHub API.
Configuring Omniauth GitHub and Devise.
(Optional) Installing ngrok to expose localhost to the internet and obtain a functional callback URL.

Note: setting up an ngrok tunnel is only necessary if your OAuth provider does not allow local callback URLs.
GitHub does allow localhost callback URLs, so I will include this step as a courtesy if your OAuth provider disallows localhost callback URLs.

Step 1 | Installing Figaro

The first step is fairly straightforward. We need a method for securely storing the keys we will obtain in Step 2. Figaro does this by creating a config/application.yml file and adding it to .gitignore. This way your secret key will never be pushed to GitHub and will stay on your local machine.

To install Figaro:

Add it your Gemfile: gem 'figaro'
Run bundle install
Install figaro: bundle exec figaro install

See the gem documentation for more details. We will return to the config/application.yml file generated by bundle exec figaro install after we register a new OAuth app on GitHub (Step 2).

Step 2 | Registering an OAuth App with GitHub

To authenticate to GitHub, we must tell GitHub who we are and that we will be requesting information from its API. To do this, we must register our application as a new OAuth app. Navigate to GitHub. Login and under your profile picture, click on Settings. Scroll down a bit and click on Developer Settings. Click on OAuth Apps, and finally "New OAuth App".

Name your application
Under "Homepage URL", enter http://localhost:3000 as this is the homepage of your application in development.
For "Authorization callback URL", enter http://localhost:3000/users/auth/github/callback
Click "Register Application".
Take note of your client id and client secret.

Saving client id and secret with Figaro

In your Rails application, navigate to config/application.yml and save your client id and secret:

development:
  GITHUB_ID: < client id >
  GITHUB_SECRET: < client secret >

Step 3 | Configuring Omniauth GitHub and Devise

Follow the directions in the Devise Wiki.

Some notes:
- The examples use omniauth-facebook, but you can essentially replace any occurrence of 'facebook' with 'github', or 'twitter', etc.
- scope entails the permissions you request of the authenticated user. "Access to email, profile info, etc." scope: 'user,public_repo' below grants access to basic profile information and all public repo information. GitHub provides these scopes in their docs
- Don't forget to add a "Sign in with GitHub" link.
- for the config/initializers/devise.rb part, your entry is accessing the environment variables set by Figaro:
```
  config.omniauth :github, ENV['GITHUB_ID'], ENV['GITHUB_SECRET'], scope: 'user,public_repo'
```

Step 4 (Optional) | Installing Ngrok

why install ngrok?

ngrok is a tool that exposes a local web server to the internet. The colloquial term for this is a tunnel.
ngrok allows us to use a callback URL in development when an OAuth provider does not allow local callback URLs.
The callback URL is essentially where a user is redirected after authenticating to a third party service.
Some OAuth providers require that this URL be public, thus the need for a tool like ngrok.
After an application, located at localhost:3000 sends a request for authentication to the OAuth provider's API, the OAuth provider "calls back" the publicly exposed WebHost's URL and the application now has an authenticated user.
For GitHub, we did not need to publicly expose our localhost server. We simply used http://localhost:3000/users/auth/github/callback in Step 2 above.

To install ngrok follow the instructions:

snap install ngrok (Ubuntu) or brew install ngrok/ngrok/ngrok (Mac)
Sign up for an account to get your authtoken.
From your home directory: ngrok authtoken <token>
Start a tunnel. For a Rails app, use port 3000. ngrok http 3000

The final command, ngrok http 3000, will bring up the ngrok UI:

Note the forwarding URL.
Return to your application's settings and add /users/auth/< insert_provider_name >/callback to the end of the forwarding URL.

Final Steps

Navigate to localhost:3000, or, if you're using ngrok, your ngrok forwarding URL (Ctrl+click from terminal), and click the "Sign in with GitHub" link you made earlier.
You should now be able to authenticate a GitHub user in your application in Development. Try it out with your own GitHub account!
If you're using ngrok for your Authorization callback URL, it may be necessary to add your ngrok domain to your list of allowed hosts in config/environments/development:

  config.hosts << "0e30-73-119-170-171.ngrok.io"

This will need to be changed if you close the terminal session that holds your ngrok session.

To move this setup to Production

Return to Step 2:
- On GitHub application page, update your "Homepage URL" to < your app's production domain name >
- Update "Authorization callback URL" to < your app's production domain name >/users/auth/github/callback.
Update your config/application.yml file to include a production environment.
Set Heroku config variables so Heroku can access your application keys
- heroku config:set GITHUB_ID=github_id_key_here
- heroku config:set GITHUB_SECRET=github_secret_key_here
Deploy to Heroku

Reflection

I was quite happy when I saw the "Successfully authenticated from Github account." flash message. Getting this to work was an exercise in patience and reading documentation slowly and carefully. Authentication is a deep topic and I feel I have only scratched the surface. I hope this post was a helpful guide on how to setup OmniAuth in a development environment. Before we walk, we must crawl. Before we deploy to production, we must struggle in development.

Photo by Brett Jordan on Unsplash