DEV Community: Drew Bragg

New Episode! Chris Oliver on Code and the Coding Coders who Code it

Drew Bragg — Thu, 09 Jun 2022 01:34:29 +0000

Episode 7 - Chris Oliver

Code and the Coding Coders who Code it

Your browser does not support the audio element.

1x initializing... ×

Chris Oliver joins the show to discuss all the adventures he's been having. He tells us about the various projects he has going on, including: rewriting Hatchbox, hiring his first employee, and what the future of learning Rails could look like. He also is building a house which definitely takes some time to put together! There was so much to talk about this episode that it's certainly getting the 1st place spot for longest episode!

Links:

The Curious Case of the DATA Constant

Drew Bragg — Fri, 03 Dec 2021 17:44:33 +0000

If you're unfamiliar with Ruby's DATA constant don't feel too bad, it's an easy one to miss. Not only is it rare to see in the wild but out of the 9 Ruby books I own (and have actually read) only 2 of them even mention this global constant, "Programming Ruby" by Dave Thomas, commonly known as the pickaxe book, and "The Ruby Programming Language" by David Flanagan and Yukihiro Matsumoto (you know, the guy who created the language).

To understand the DATA constant we first must understand the __END__ token. If the Ruby interpreter finds an __END__ token it will stop running the program code. The first time I heard about this the presenter said that the interpreter will "ignore" anything after the token and demoed it by using it to "comment" out a chunk of code at the end of the file. This was a neat trick but unfortunately inaccurate and completely ignored the coolest part of the __END__ token.

I had all but forgotten about __END__ until @schwad brought it up at his awesome RubyConf talk (I'll post a link once the videos are publicly available). I wont spoil his talk but Nick gave me enough additional information to spark my curiosity and send me down a rabbit hole of Ruby Archaeology.

Turns out the ruby interpreter does just "ignore" anything after the token but will actually treat any after the __END__ token as data and will take the content and assign it to the DATA constant. Armed with this information, the DATA constant becomes a lot easier to understand. DATA is an IO steam. Just like opening a file and reading its contents, you can do the same thing with DATA.

So what does this look like in practice? Something like this:

# end_data_demo.rb
puts DATA.read.tr("\n", " ")

__END__
Look
at
this
data

If you run ruby end_data_demo.rb in your terminal you'll get "Look at this data" returned.

Pretty cool, right? No? Well I think it is. Look, you can even store YAML in there:

Now you may be thinking, "Ok fine, that kinda cool, but why or when would I actually use this?". Well given the time of the year let me give you a more practical demo.

Many of you are doing Advent of Code. If you're doing it or have done it in Ruby you've probably done something like this to get your puzzles input:

input = File.readlines('.puzzle_input.txt')

# Your logic here

this works but requires a separate file for you input. Here's how I'm doing AoC this year:

input = DATA.readlines

# My logic here

__END__
My
puzzle
input

One day, one file.

DATA is a pretty cool trick but unfortunately isn't set in a multi-file application... BUT all is not lost. There are still some cool things we can do with __END__ stay tuned for the post where we'll abuse __END__ for fun and profit.

Using the new `weekday_select` in Rails 7

Drew Bragg — Wed, 22 Sep 2021 18:45:00 +0000

In most of the Rails apps I've built over the years I've had to add my own helpers for a weekday select. Normally Rails is great at providing most of the helpers you could ever want, so this omission has always been a little surprising to me. At Within3 I recently had to work on this again, and another engineer on my team shared my surprise at the omission. So I thought it was time for a Rails PR.

The bulk of this PR adds the weekday_options_for_select method but you'll still need to wrap that in a select tag so I also added a weekday_select tag to the form builder. Now there are a few ways to build your weekday select so let start with an overview of the weekday_options_for_select method.

weekday_options_for_select accepts a few arguments, all of which have a default, for you to customize your options:

selected (defaults to nil) if you provide this argument the value passed will be used to mark that option as selected:

weekday_options_for_select("Friday")
# => "<option value=\"Sunday\">Sunday</option>\n
# <option value=\"Monday\">Monday</option>\n
# <option value=\"Tuesday\">Tuesday</option>\n
# <option value=\"Wednesday\">Wednesday</option>\n
# <option value=\"Thursday\">Thursday</option>\n
# <option selected=\"selected\" value=\"Friday\">Friday</option>\n
# <option value=\"Saturday\">Saturday</option>"

index_as_value (defaults to false) if true will set the value of each option to the index of that day

weekday_options_for_select(index_as_value: true)
# => "<option value=\"0\">Sunday</option>\n
# <option value=\"1\">Monday</option>\n
# <option value=\"2\">Tuesday</option>\n
# <option value=\"3\">Wednesday</option>\n
# <option value=\"4\">Thursday</option>\n
# <option value=\"5\">Friday</option>\n
# <option value=\"6\">Saturday</option>"

NOTE: "Sunday" will always be 0 even if you start on a different day (more on that in a minute) to stay consistent. In Ruby, if you call wday on a Date "Sunday" will always return 0 and I18n.translate("date.day_names") will return an array where "Sunday" is the first item. So we keep the value of "Sunday" 0 regardless of where it falls in the array.

day_format (defaults to :day_names) passing this a different I18n key will use different formats for the option display names and values.

weekday_options_for_select(day_format: :abbr_day_names)
# => "<option value=\"Sun\">Sun</option>\n
# <option value=\"Mon\">Mon</option>\n
# <option value=\"Tue\">Tue</option>\n
# <option value=\"We\">Wedn</option>\n
# <option value=\"Thu\">Thu</option>\n
# <option value=\"Fri\">Fri</option>\n
# <option value=\"Sat\">Sat</option>"

NOTE: :abbr_day_names is built into Rails but you could define your own Array and use that key if desired. Example:

en:
  date:
    alt_day_names: [Sun, Mon, Tues, Weds, Thurs, Fri, Sat]

weekday_options_for_select(day_format: :alt_day_names)
# => "<option value=\"Sun\">Sun</option>\n
# <option value=\"Mon\">Mon</option>\n
# <option value=\"Tues\">Tues</option>\n
# <option value=\"Weds\">Weds</option>\n
# <option value=\"Thurs\">Thurs</option>\n
# <option value=\"Fri\">Fri</option>\n
# <option value=\"Sat\">Sat</option>"

Bonus Option I recently made another PR that adds a beginning_of_week option so you can specify which day the select starts on. This defaults to Date.beginning_of_week so as long as you have that set you're good to go, if you don't or you want to override it, here's how:

Date.beginning_of_week
# => :sunday
weekday_options_for_select(beginning_of_week: :monday)
# => "<option value=\"Monday\">Monday</option>\n
# <option value=\"Tuesday\">Tuesday</option>\n
# <option value=\"Wednesday\">Wednesday</option>\n
# <option value=\"Thursday\">Thursday</option>\n
# <option value=\"Friday\">Friday</option>\n
# <option value=\"Saturday\">Saturday</option>\n
# <option value=\"Sunday\">Sunday</option>"

Like I said you'll still need to wrap weekday_options_for_select in a select tag so I also added a weekday_select tag to the form builder. Lets take a look at how to use that.

Lets say we have a newsletter that we send our to our users and we want our users to be able to set what day they receive that newsletter. We can add a newsletter_send_day column to our User and then update the form to look a little something like this:

<%= form_with model: @user do |form| %>
  <%= form.label :newsletter_send_day %>
  <%= form.weekday_select :newsletter_send_day %>
<% end %>

And that's it!

You'll get something that looks like this in your form:

<select name="user[newsletter_send_day]" id="user_newsletter_send_day">
  <option value="Sunday">Sunday</option>
  <option value="Monday">Monday</option>
  <option value="Tuesday">Tuesday</option>
  <option value="Wednesday">Wednesday</option>
  <option value="Thursday">Thursday</option>
  <option value="Friday">Friday</option>
  <option value="Saturday">Saturday</option>
</select>

You can use any combination of the weekday_options_for_select arguments to modify your selects options.

You can try weekday_select and weekday_options_for_select for yourself in Rails 7, which at the time of this writing is in an alpha prerelease. Let me know what you think about these new form options and if you get a chance to use them in any of your projects!

Using Mail Interceptors in Rails

Drew Bragg — Thu, 19 Aug 2021 01:51:34 +0000

I stumbled upon a super neat feature of ActionMailer the other night. If you scroll all the way to the bottom of the Rails Guide for ActionMailer you'll find a section on Intercepting and Observing Emails. Intercepting an email allows you to modify your email before sending it. Why would you want to do this you might ask? Well, take the following real life production code in my companies app (slightly modified for confidentiality and brevity):

class ApplicationMailer < ActionMailer::Base
  def self.deliver_mail(mail)
    if Rails.env.development? || Rails.env.staging?
        rerouted_email_address = "#{Rails.env}@email.com"
        original_to = mail.header[:to].to_s
        original_subject = mail.header[:subject].to_s

        if mail.cc
          original_cc_emails = mail.cc.dup
          mail.cc = []

          original_cc_emails.each do |email_str|
            other_cc_emails = original_cc_emails.select { |cc| cc != email_str }
            mail.to = rerouted_email_address
            mail.subject = "This is an email with copied folks [cc: #{email_str} +
                             #{other_cc_emails.length} others, to: #{original_to}]"
            super(mail)
          end
        end

        logger.info "Rerouted '#{original_to}' to '#{rerouted_email_address}'."
        mail.subject = "#{original_subject} [originally to: #{original_to}]"
        mail.to = rerouted_email_address
      end
    end

    super(mail)
  end
end

That's a lot of code to have in our base mailer that really only runs in some environments. Also, I've found that code like this, where we're actually overriding a core method, makes it hard to debug problems. It also adds a lot of unneeded complexity when trying to understand what our mailers actually do.

Enter Interceptors.

An interceptor is a special class that has a delivering_email(mail) method. The delivering_email method is what will be called before the email is actually sent. Inside the method we'll be able to interact and modify our email before it is sent by the original mailer. So simple but so awesome.

I created an interceptors directory in app/mailer (if you think there's a better place to stash them I'm all ears) and added a reroute_email_interceptor.rb file that looks a little something like this:

module Interceptors
  class RerouteEmailInterceptor
    def self.delivering_email(mail)
        original_to = mail.header[:to].to_s
        original_subject = mail.header[:subject].to_s

        mail.to = rerouted_email_address
        mail.subject = "#{original_subject} [originally to: #{original_to}]"

        if mail.cc.present?
          original_cc_emails = mail.cc.dup.join(", ")
          mail.cc = []
          mail.subject = "This is an email with copied folks [cc: #{original_cc_emails}, to: #{original_to}]"
        end

        Rails.logger.info "Rerouted '#{original_to}' to '#{rerouted_email_address}'."
      end
    end

    def self.rerouted_email_address
      @rerouted_email_address ||= "#{Rails.env}@email.com"
    end
  end
end

Aside from the slight changes to how we handle CC's (which the team is happy with) this will do the same thing as the original code but allows our ApplicationMailer do go back to:

class ApplicationMailer < ActionMailer::Base

end

In order to make the interceptor actually do it's thing we need to add an initializer to add it to ActionMailer::Base

# config/initializers/mailer_interceptor.rb
if Rails.env.development? || Rails.env.staging?

 ActionMailer::Base.register_interceptor(Interceptors::RerouteEmailInterceptor)
end

And we're done! This is a far better, cleaner, and OOP way of handling our development/staging emails.

I can't believe that I've been working in Rails as long as I have and just now learning about Mail Interceptors but I'm sure glad I did!

Rails Design Patterns: Form Object

Drew Bragg — Wed, 02 Jun 2021 17:04:47 +0000

Form Object Pattern

There are a number of design patterns that will help improve your Rails app. One such pattern is the Form Object. At its core a Form Object is just a Plain Old Ruby Object (PORO), but we can design the object in such a way that it will help us to maintain a consistent API in our code. Let's dive in and see how we can leverage a Form Object to improve our Rails App.

The messaging feature

Let's say our boss asks us to add a messaging feature to our application. They tell us the message shouldn't be a database table, so no model. It just needs to be a form where a user can select another user, add a subject and body, and then send out an email. Sounds easy enough, let's get that added. (for simplicity let's say our app already has a User model with first_name, last_name, and email attributes, and a DummyMailer with a message method that takes to, subject, and body as keyword arguments)

First let's add the messages controller.



# app/controllers/messages_controller.rb
class MessagesController < ApplicationController
  def show; end

  def create
    DummyMailer.message(message_params).deliver_later
    redirect_to messages_path, notice: "Your message was sent!"
  end

  private

  def message_params
    params.permit(:to, :subject, :body)
  end
end

Then we can add our view/form



# app/views/messages/show.html.erb
<h1>New Message</h1>

<h3><%= notice %></h3>

<%= form_with url: messages_path do |form| %>
  <div class="field">
    <%= form.label :to %>
    <%= form.select :to, User.all.pluck(:email), include_blank: "Select a recipient" %>
  </div>

  <div class="field">
    <%= form.label :subject %>
    <%= form.text_field :subject %>
  </div>

  <div class="field">
    <%= form.label :body %>
    <%= form.text_area :body %>
  </div>

  <div class="actions">
    <%= form.submit "Create Message" %>
  </div>
<% end %>

After we add resource :messages, only: %i[show create] to our routes file we can start up our server and checkout our new form (forgive the lack of styling).

If we select a user, add a subject, and a body

We'll see things work out pretty well.

Close but no cigar.

That is until we show it to our boss. First thing she does is to try submitting the form with no details and frowns when she sees "Your message was sent!" on the screen. She asks us to show an error message if any of the information is missing. Ok, slightly more complicated but still doable. Let's update our controller.

Something like:



class MessagesController < ApplicationController
  def show; end

  def create
    if message_params[:to].present? && message_params[:subject].present? && message_params[:body].present?
      DummyMailer.message(message_params).deliver_later
      redirect_to messages_path, notice: "Your message was sent!"
    else
      flash.now[:notice] = "Please include all fields"
      render :show
    end
  end

  private

  def message_params
    params.permit(:to, :subject, :body)
  end
end

Form Object to the rescue!



# app/models/message.rb
class Message
  include ActiveModel::Model

  attr_accessor :to, :subject, :body

  validates :to, :subject, :body, presence: true
  validates :subject, length: { maximum: 255 }
end

You'll notice I put this in the models directory. This is personal preference. It could have just as easily have been placed in a forms directory in app or even models. There's absolutely nothing wrong with having "models" (which this arguably is) in your models directory. They don't all have to be database-backed.

Armed with our new form object, let's update our form.



<h1>New Message</h1>

<h3><%= notice %></h3>

<%= form_with model: @message, url: messages_path do |form| %>
  <div class="field">
    <%= form.label :to %>
    <%= form.select :to, User.all.pluck(:email), include_blank: "Select a recipient" %>
  </div>

  <div class="field">
    <%= form.label :subject %>
    <%= form.text_field :subject %>
  </div>

  <div class="field">
    <%= form.label :body %>
    <%= form.text_area :body %>
  </div>

  <div class="actions">
    <%= form.submit %>
  </div>
<% end %>

Notice that we added model: @message to our form_with call. This is what will help give us all the form behavior that we've come to expect with Rails. It also allows us to remove the specific "Create Message" label from the submit action since passing in a model will populate this for us. To make this actually work though we'll need to make some updates to our controller.



class MessagesController < ApplicationController
  def show
    @message = Message.new
  end

  def create
    @message = Message.new(message_params)

    if @message.valid?
      DummyMailer.message(message_params).deliver_later
      redirect_to messages_path, notice: "Your message was sent!"
    else
      flash.now[:notice] = @message.errors.full_messages.join(", ")
      render :show
    end
  end

  private

  def message_params
    params.require(:message).permit(:to, :subject, :body)
  end
end

Nice. This is looking a lot more like a controller we'd expect to see in a Rails app. We're leveraging Strong Params correctly and letting our "model" take care of all the validation logic. With no other changes our form is now working as our boss requested:

Bonus round: Making a really expected controller.

Theres one small part of our controller that may stick out. The call of valid? vs save is different than what we'd expect to see in a "normal" Rails controller. I'm also not a fan of having the mailer call in the controller (but that may just be me).



class MessagesController < ApplicationController
  def show
    @message = Message.new
  end

  def create
    @message = Message.new(message_params)

    if @message.save
      redirect_to messages_path, notice: "Your message was sent!"
    else
      flash.now[:notice] = @message.errors.full_messages.join(", ")
      render :show
    end
  end

  private

  def message_params
    params.require(:message).permit(:to, :subject, :body)
  end
end

If we try this now you'll get a "NoMethodError" error because, though ActiveModel::Model give us a lot of model logic, it does not give us a save message. No worries though, the simple act of adding a save method to our "model" will fix that, with the added bonus of giving us a good place for our mailer call (if you're into that kinda stuff).



class Message
  include ActiveModel::Model

  attr_accessor :to, :subject, :body

  validates :to, :subject, :body, presence: true
  validates :subject, length: { maximum: 255 }

  def save
    return false unless valid?

    DummyMailer.message(to: to, subject: subject, body: body).deliver_later
  end
end

If we try it again now every thing will work. 🎉

Though this was a fairly simple example I hope it illustrated the awesomeness of a Form Object. Allowing our controllers to look, function, and behave in an expected way is a huge win and paramount to keeping our application stable and easily upgrade/expandable. We also now have a much more familiar form design. Validation is performed using battle-tested and well-known methods, not by recreating that logic. Any additional changes to our "Message" feature is now incredibly easy and will feel no different than adding features to a model backed by the database.

for/in vs. each in Ruby: More than just syntax

Drew Bragg — Tue, 06 Apr 2021 20:31:38 +0000

During a recent PR review I found myself having to explain why we would want to use each over for/in in Ruby. Turns out most people think it's just more idiomatic to use each over for but it's much more than that.

With for, the variable you use will be available outside of the loop, while the variable you use in each will only be available in that block.

x = [1, 2, 3]

x.each do |i|
  puts i
end
#...
puts i #=> NameError: undefined local variable or method `i' for main:Object

for i in x
  puts i
end
#...
puts i #=> 3

This is because for does not introduce a new scope but each does via the block you pass it. It’s important to understand scope here because you can really make a mess with for if you’re not careful. ie:

def num
  puts 4
end

num #=> 4

x = [1, 2, 3]

x.each do |num|
  puts num
end
#...
num #=> 4

for num in x
  puts num
end
#...
num #=> 3

I hope this clears up why you should use each over for while working with Ruby. It's a simple thing that can have a rather large impact.

Introducing the Rails class_names method

Drew Bragg — Mon, 22 Mar 2021 16:43:11 +0000

New to Rails 6.1 is a method called class_names, from the ActionView::Helpers::TagHelper module. This handy new view helper brings one of may favorite features from Vue.js to Rails.

In Vue.js (or React via the classnames library) we can do something like this:

<div class="{item: true, item__complete: item.complete, item__over_due: !item.complete && item.overDue }">
  {{ item.name }}
</div>

Which, assuming we have the proper css classes and item object, will give us something like this:

<!-- item.complete == false -->
<div class="item">Incomplete Item</div>

<!-- item.complete == false && item.overDue == true -->
<div class="item item__over_due">Incomplete Item</div>

<!-- item.complete == true && item.overDue == true -->
<div class="item item__complete">Complete Item</div>

Obviously this is an overly simplified example but you get the idea. To do the same thing in Rails used to require something like this:

<%= tag.div class: "item #{item.completed? ? 'item__complete' : ''} #{!item.completed? && item.over_due? ? 'item__over_due' : ''}" do %>
  <%= item.name %>
<% end %>

However, the introduction of class_names simplifies this and makes it work very similarly to Vue. Now we can do something like this:

<%= tag.div class: class_names(item: true, item__complete: item.completed?, item__over_due: !item.completed? && item.over_due?) do %>
  <%= item.name %>
<% end %>

Additionally, class_names can take mixed argument types so the above could also be done as:

<%= tag.div class: class_names("item", { item__complete: item.completed?, item__over_due: !item.completed? && item.over_due? }) do %>
  <%= item.name %>
<% end %>

NOTE: The above example explicitly calls class_names for illustrative purposes. The tag (and content_tag) method uses class_names under the hood already so the above can actually be done like this:

<%= tag.div class: ["item", { item__complete: item.completed?, item__over_due: !item.completed? && item.over_due? }] do %>
  <%= item.name %>
<% end %>

I like this a lot and it will make building more complex conditional css class lists in Rails so much easier and cleaner. class_names is an alias of token list and you can view its documentation here.

Giving credit where credit is due

Drew Bragg — Tue, 23 Jun 2020 16:59:09 +0000

About a month ago I wrote an article on an issue I had run into a few times and the solution I eventually came up with.

By 'came up' with I mean:

review various documentation
read numerous articles
search StackOverflow for similar issues
then compile everything I've read/learned into a single place where I or anyone else could access the information.

What resulted was my take on all of these sources put together and tested in a few of my personal and work apps.

Since I had worked on the problem for sometime and used countless resources I didn't think to include a credit section in the article. But recently someone left a comment on my article saying I should give credit to another article with extremely similar code to what I used and that was posted well before mine. Interestingly enough, I did not come across this article when I was working on my original solution. So, if I did have a credit section, I wouldn't credit that particular article but it did raise an interesting question.

When should I include links to other articles, docs, or StackOverflow questions I used in researching my problem?

Naturally, if my solution is pulled directly from or heavily influenced by 1 or 2 other articles I would state that but in this case the 'credit' section would end up looking something like this:

(this is just based on my browser history as far back as it will go)

Which seems... excessive and would also mean that everything I write from here on out would need links to every article, SO question, or doc I've read on the topic. I want to make sure I give credit where credit is due and not receive comment essentially accusing me of stealing someone else's article. I guess I just don't know when my code starts being mine and stops being a culmination of everything I've learned or read.

What do you think? When do you include a 'credit' section and what sources do you include in it?

Reset Postgres ID sequence in Rails

Drew Bragg — Thu, 18 Jun 2020 16:22:19 +0000

Today I had to restore backup data from one of our SQL dumps to my local development database. For one reason or another the table id sequences didn't reset after the restore. So I was getting errors in my terminal like this:

PG::UniqueViolation: ERROR:  duplicate key value violates unique constraint "track_events_pkey"
DETAIL:  Key (id)=(3673) already exists.
: INSERT INTO "track_events" ("track_session_id", "action", "created_at", "updated_at") VALUES ($1, $2, $3, $4) RETURNING "id" excluded from capture: DSN not set

Manually resetting it is actually quite easy.

Hop into your rails console and run:

ActiveRecord::Base.connection.tables.each do |t|
  ActiveRecord::Base.connection.reset_pk_sequence!(t)
end

I hope this helps someone else who runs into a similar issue!

TIL: alias in Ruby

Drew Bragg — Tue, 02 Jun 2020 16:19:51 +0000

Today I learned (learnt?) about the alias keyword in Ruby. I'm not sure how I've gone this long working with ruby without hearing about it but better late than never.

If this is also your first time hearing about alias, let me give you a short intro.

Ruby is a very expressive language. It lets you write code that looks like plain english. Keeping with that trend it's not uncommon for me to do something like this in a class:

class Todo
  attr_accessor :name, :complete

  def initialize(name)
    @name = name
    @complete = false
  end

  def done?
    complete
  end

  def mark_complete=(arg)
    complete=(arg)
  end
end

Ok, I wouldn't actually do that but I'm just illustrating a point.

This works just fine and lets us keep writing our plain english-like syntax

my_todo = Todo.new('Learn about the alias keyword')

my_todo.done? # => false

my_todo.mark_complete = true

my_todo.done? # => true

But, just like most things in Ruby, there is a shorter and better(?) way to do this.

Enter the alias keyword:

class Todo
  attr_accessor :name, :complete

  def initialize(name)
    @name = name
    @complete = false
  end

  alias done? complete
  alias mark_complete= complete=
end

So much shorter and cleaner. I also think it's just as expressive as (if not more than) the original example. And it still works as expected:

my_todo = Todo.new('Learn about the alias keyword')

my_todo.done? # => false

my_todo.mark_complete = true

my_todo.done? # => true

I found the alias keyword to be pretty great and definitely something I'm going to start using in the future.

How about you? What do you think about the alias keyword in Ruby?

taco_tuesday gem, now with more tacos

Drew Bragg — Tue, 02 Jun 2020 13:30:22 +0000

Thanks to Colin Bartlett's awesome contribution to the taco_tuesday gem version 0.2.0 has been released!

In 0.2.0 you can now run 🌮? on Date and Time classes to know if it's a Taco Tuesday.

require 'taco_tuesday'

# May 26th 2020 is a Tuesday
tuesday = Date.new(2020, 5, 26)
tuesday.taco_tuesday? #=> true
tuesday.🌮? #=> true

# May 25th 2020 is a Monday
monday = Date.new(2020, 5, 25)
monday.taco_tuesday? #=> false
monday.🌮? #=> false

# Check if today is Taco Tuesday
Date.today.taco_tuesday? #=> Same result as Date.today.tuesday?
Date.today.🌮? #=> Same result as Date.today.taco_tuesday?

Or with the Time class:

require 'taco_tuesday'

# May 26th 2020 is a Tuesday
tuesday = Time.new(2020, 5, 26)
tuesday.taco_tuesday? #=> true
tuesday.🌮? #=> true

# May 25th 2020 is a Monday
monday = Time.new(2020, 5, 25)
monday.taco_tuesday? #=> false
monday.🌮? #=> false

# Check if today is Taco Tuesday
Time.now.taco_tuesday? #=> Same result as Time.now.tuesday?
Time.now.🌮? #=> Same result as Time.now.taco_tuesday?

With the power of both taco_tuesday? AND 🌮? you and your ruby apps are sure to never miss another Taco Tuesday!

The taco_tuesday gem, cause Tacos

Drew Bragg — Mon, 01 Jun 2020 13:08:20 +0000

For years I've had to add:

class Date
  def taco_tuesday?
    tuesday?
  end
end

to my ruby projects so I could easily check if it was Taco Tuesday.

But No More!

Introducing the taco_tuesday gem!

Simply add this line to your application's Gemfile:

gem 'taco_tuesday'

And then execute:

$ bundle install

Now you can easily check if it's taco tuesday.

With the Date class:

require 'taco_tuesday'

# May 26th 2020 is a Tuesday
tuesday = Date.new(2020, 5, 26)
tuesday.taco_tuesday? #=> true

# May 25th 2020 is a Monday
monday = Date.new(2020, 5, 25)
monday.taco_tuesday? #=> false

# Check if today is Taco Tuesday
Date.today.taco_tuesday? #=> Same result as Date.today.tuesday?

With the Time class:

require 'taco_tuesday'

# May 26th 2020 is a Tuesday
tuesday = Time.new(2020, 5, 26)
tuesday.taco_tuesday? #=> true

# May 25th 2020 is a Monday
monday = Time.new(2020, 5, 25)
monday.taco_tuesday? #=> false

# Check if today is Taco Tuesday
Time.now.taco_tuesday? #=> Same result as Time.now.tuesday?

Yes, this is a real gem and yes, you can contribute (though I'm not sure what we could add... ideas?).

I hope this post and gem gives you as good of a chuckle as it did for me.