DEV Community: Tyler Scott Williams

Duplicate Zeros - Optimal Solution in Ruby

Tyler Scott Williams — Mon, 19 Apr 2021 00:47:55 +0000

Description

Given a fixed length array arr of integers, duplicate each occurrence of zero, shifting the remaining elements to the right.

Note that elements beyond the length of the original array are not written.

Do the above modifications to the input array in place, do not return anything from your function.

Solution

It took me a few days to wrap my head around this solution, which modifies the array in-place. I understood the naive solution a little easier to start. The naive solution takes up extra space by using a reference array to reconstruct the array.

But we can solve it without using extra space, which is good, because using a reference array would use twice the space.

First, think about what the array might look like if we extended it to contain all the elements, including the duplicate zeros. It would be an array of length arr.length + number_of_zeros_in_the_array.

Take this example:

[1,0,2,3,0,4,5,0]

If we had an array that could contain the dulicate zeros and the existing elements, it would look like this:

[1,0,0,2,3,0,0,4,5,0,0]

The length of the first array is 8. The length of the second array is 11. There are 3 zeros in the original array, and 11 - 8 = 3.

So the "return" value (in quotes, since we're modifying in place and not really returning anything), would look like this:

[1,0,0,2,3,0,0,4]

Which is the first 8 (remember: the length of the input array) elements of our thought-exercise array #2 (the one that was 11 elements long).

So we can modify the array in-place without overwriting values by walking backwards from the "end" of our "imaginary array". We have to keep track of three things:

An iterator that starts at the "end" of the "imaginary" array and moves towards the beginning of the input array. Call that j
An iterator that starts at the end of the input array. Call that i.
For convenience, let's keep track of the length of the original array.

We'll set up a loop that decrements i, and writes to the array in position j, but only if j is pointing to an position that exists within the input array. It will write the value at arr[i].

Each time we perform this action, we check if that value is 0. If it is, we need to duplicate the 0 value in our writing to the original array. We can do that by decrementing the j iterator one more time. This means that j will move faster than i (assuming there are 1 or more 0s in the array), and eventually catch up with it - writing the appropriate duplicate 0 values.

All along the way, we use n to make sure we never try and write to the array at a position in the longer, imaginary array. We decrement both i and j each time to keep moving backwards through the array until we hit position 0.

I found it a little hard to keep the two iterators straight in my head, so here's a table that illustrates the process for [1,0,2,3,0,4,5,0]:

Iteration	i	j	Write to arr[j]?	Decrement j twice?	Write 0 twice?
0	7	10	No, j > 7	Yes, arr[7] == 0	No, j >
1	6	8	No, j > 7	No, arr[6] != 0	No, arr[6] != 0
2	5	7	Yes, j == 7	No, arr[5] != 0	No, arr[5] != 0
3	4	6	Yes, j < 7	Yes, arr[4] == 0	Yes, arr[4] == 0 && j < 7
4	3	4	Yes, j < 7	No, arr[3] != 0	No arr[3] != 0
5	2	3	Yes, j < 7	No, arr[2] != 0	No arr[2] != 0
6	1	2	Yes, j < 7	Yes, arr[1] == 0	Yes, arr[1] == 0 && j < 7
7	0	0	N/A	N/A	N/A

Two things to notice in the last row of this table:

i == j, which is important. Since j moves faster than i, but we move through the array backwards with i which started at a position closer to the beginning, we eventually need the two of these values to converge.
We don't actually need to take any action in the final iteration, because the first element of the array will always be the same. We can loop until we hit that first element with j.

Code

# @param {Integer[]} arr
# @return {Void} Do not return anything, modify arr in-place instead.
def duplicate_zeros(arr)
    # Determine the number of zeros in the array 
    number_of_zeros = arr.count(0)

    # Set up a variable to represent the length of the array
    n = arr.length

    # Initialize iterator i to the end of the array
    i = n - 1

    # Initialize iterator j to be the end of the array + number of zeros
    j = n + number_of_zeros - 1

    # Count backwards from j to the beginning of the array
    while j > 0 do 
    # arr[j] = arr[i] if j is within the range of the array (less than n)
        arr[j] = arr[i] if j < n
        # If that number is 0, decrement j an extra time
        # This means j will move faster than i until they meet
        if arr[i] == 0 
            j -= 1
            # This is where we duplicate the zero - 
            # write to arr[j] if j is within the range of the array.
            arr[j] = arr[i] if j < n
        end
    # Decrement both i and j during each loop - 
    # we want both of them to be counting down.
    i -= 1
    j -= 1
    end
end

Duplicate Zeroes, Naive Solution

Tyler Scott Williams — Sun, 18 Apr 2021 18:27:41 +0000

Problem

Given a fixed length array arr of integers, duplicate each occurrence of zero, shifting the remaining elements to the right.

Note that elements beyond the length of the original array are not written.

Do the above modifications to the input array in place, do not return anything from your function.

Solution

This is the brute force solution, expressed in Ruby.

I figured this out by doing a few examples by hand and thinking to myself what was going on in my brain. Since I wrote the original input, and then wrote to a "new" array, I realized I needed to duplicate the input array and use it as a reference.

Once you duplicate the array for reference, you'll want two iterators:

i iterates through the input array, modifying its values
j iterates through the reference array, providing values for reference.

For ease of use, I also set the variable n to equal arr.length. We'll use that in the while loop.

Start both at 0. Make arr[i] = reference[j] to start. Each step of the way, check if reference[j] is 0. If it is, you want to do that again, because the solution tells you to duplicate zeros. In order to do it again, we increment i by 1, and we leave j alone. I originally had trouble wrapping my head around which iterator to increment and how to "duplicate" the 0.

Next, you'll want to increment both i and j by 1. You need to do this regardless of whether or not the number was 0, because we need to keep moving through both arrays.

The one gotcha to look out for is that in the 0 check, we increment i, but it's possible that the last element is 0, in which case you'll end up with a larger array (in languages like Ruby, which have dynamically-resizing arrays. In other languages, you may have actual runtime errors). So we can check that i < n

The while loop should terminate when i == n.

Code

# @param {Integer[]} arr
# @return {Void} Do not return anything, modify arr in-place instead.
def duplicate_zeros(arr)
    # Create a reference array 
    reference = arr.dup

    # Set up iterator i, to move through the input array
    i = 0 
    # Set up iterator j, to move through the reference array
    j = 0
    # Set up n as a convenience to represent the length of the input array
    n = arr.length

    # Loop and increment `i` until we've gone through the entire input array.
    while i < n do 
        # First up, overwrite the array at position i with our reference value at position j
        arr[i] = reference[j] 
        # Then, check if that value was 0.
        if reference[j] == 0 
            # If so, increment i by one. This is how we "duplicate" the zero.
            i+= 1 
            # You'll need to write that 0 to arr[i]. But be careful - if reference[j] == 0, and j == n -1 (i.e. the last reference value is 0)
            # then you'll overflow. So use `unless` to make sure `i < n`.
            arr[i] = reference[j] unless i >= n
        end
        # We will always need to increment i and j at each step, to continue moving the loop forward.
        i += 1
        j += 1
    end
end

Analysis

This solution take O(n) time and O(n^2) space, since you have to loop through the input array just once, but you'll need to duplicate it in the reference variable. There's a better way that uses constant space, but I wanted to explore the naive solution in depth, because it honestly threw me for a loop for a bit!

Heuristics for Object-Oriented Design in Ruby

Tyler Scott Williams — Fri, 04 Dec 2020 04:39:26 +0000

Any Rubyist should read and study Practical Object Oriented Design, An Agile Primer Using Ruby (POODR), by Sandi Metz.

Personally, I've read through the book three times. Each time I read it, I find new insights that improve my work as a Ruby programmer, and as a software engineer in general. POODR walks through fundamental object-oriented concepts and pairs them with practical examples in Ruby. Over the course of the book, Metz builds and refactors a sample program that demonstrates these principles.

Despite the book's clarity and practicality (it's a short, to-the-point read), it's hard to keep all of the lessons in your head when you sit down to apply them in your own work. To help myself accomplish that very task, I put together a checklist I call Heuristics for Object-Oriented Design in Ruby. Here's how I use it:

I do my work and solve the challenge at hand
I take a break, and step away from the code I've written
Before making a pull request, I go over my changes and run through this checklist, evaluating my code against each item.

It's not always clean and simple, and not all of the checklist always applies, hence "heuristics". But overall, this systematic review of my Ruby code has given me a more concrete understanding of the lessons contained in POODR. I hope it will be of similar value to you.

The Heuristics

Starting with (what I consider) the simplest items, work you way towards the more complex and philosophical line items.

Code smells

These items can be identified in any Ruby file. They are often the most straightforward to resolve. At the very least, these items may prompt you to consult with an item further down in the list.

Use named args to remove order dependencies (Metz, 2019, p. 48).
Hide all instance variables behind methods (Metz, 2019, p. 24).
Isolate new instances of objects behind methods (Metz, 2019, p. 44).
If an object must send messages to any object other than self, isolate sending that message in one single method (Metz, 2019, p. 45).
Obey the Law of Demeter (Metz, 2019, p. 81).

Code organization

These items are harder to identify in code alone, but looking for them will help you find opportunities to improve the structure of your program holistically.

Use the private keyword to create intentionally designed public interfaces (Metz, 2019, p. 64).
Use simple dependency injection by passing collaborating objects as arguments to methods (Metz, 2019, p. 43).
Use duck typing when you see: case statements that switch on class, or methods that ask is_a? or kind_of? (Metz, 2019, p. 95).
Use inheritance when you are conditionally sending messages to self based on some attribute of self (Metz, 2019, p. 134).
Promote code up to superclasses rather than down to subclasses (Metz, 2019, p. 143).

Abstraction considerations

These items are concerned with the way in which your code models the problem domain at hand. They are more subjective, but remain useful even in quick code reviews.

Every class should have a one sentence description, no conjunctions allowed (Metz, 2019, p. 22).
If you rephrase your class methods as questions to the object, each question should make sense; it should be related to the purpose of the class (Metz, 2019, p. 22).
Messages should ask for "what" instead of dictating "how" (Metz, 2019, p. 70).
Enforce good dependency direction (Metz, 2019, p. 55).
Depend on abstractions before depending on concrete classes (Metz, 2019, p. 57).
Default to composition over inheritance (Metz, 2019, p. 209).
Create shallow hierarchies (Metz, 2019, p. 183).

Use named args to remove order dependencies

Knowing the required ordering of method arguments is a type of dependency, and it's an easy dependency to avoid.

# Bad 
def deal_cards(cards, player) 
    player.update!(cards: cards)
end

# Good 
def deal_cards(cards:, player:)
    player.update!(cards: cards)
end

In the first example, if you pass the arguments in the incorrect order, bad or unexpected things might happen, and it could be unclear why. More importantly - if the argument order changes (or you add more, etc.), changing the code where you use the old version gets messy.

In the second example, you can change the ordering of the arguments any way you like, and it will work. You get the added nicety that Ruby will tell you precisely what arguments you're missing, should you forget to pass them.

Hide all instance variables behind methods

When a class accesses an instance variable directly, that's a dependency. If the instance variable has to change, you have to change many lines of code.

Ruby provides an excellent solution for this, attr_accessor, and its siblings: attr_reader, and attr_writer.

# Bad 
class BettingRound
    def initialize
        @bets = [0, 0, 0, 0, 0, 0, 0, 0, 0]
    end

    def pot 
        @bets.sum
    end

    def high_bet
        @bets.max
    end
end

# Good
class BettingRound
    attr_reader :bets

    def initialize
        @bets = [0, 0, 0, 0, 0, 0, 0, 0, 0]
    end

    def pot 
        bets.sum
    end

    def high_bet
        bets.max
    end
end

It's a subtle change, but by wrapping the @bets instance variable in an accessor, we get the option to override the method should we wish to, like so:

def bets 
    @bets.map { |bet| bet.to_f }
end

The idea here is that now bets is a message to which BettingRound responds, rather than being a piece of data BettingRound knows about and manipulates.

Isolate new instances of objects behind methods

When an object knows the name of another object, that's a dependency we can avoid. When an object also knows the names of methods on a different object, that's an additional dependency.

Still, objects need to collaborate with other objects. Sometimes you can't avoid it, like if a Game needs to know about a BettingRound. Instantiating a new instance of BettingRound has to happen somewhere. You may choose to do so inside the Game class. Regardless of the best possible decision, if you have existing code where this happens, you can provide some good abstraction by wrapping instantiation in method calls.

# Bad
class Game
    attr_accessor :current_betting_round

    def start_new_hand
        current_betting_round = BettingRound.new
    end
end

# Good
class Game
    attr_accessor :current_betting_round

    def create_new_betting_round
        current_betting_round = BettingRound.new
    end

    def start_new_hand
        create_new_betting_round
    end
end

If the constructor signature changes for BettingRound, now Game only needs to make a change in one place. Or if we change out to a different object from BettingRound entirely, we only need to change it once. When an instance of Game wants a betting round, it just asks itself to create_new_betting_round, and we hand wave the details of precisely how that gets done.

If an object must send messages to any object other than `self`, isolate sending that message in one single method

As an extension of the previous point, any time an object sends a message to another object, other than self, consider wrapping that behind a method.

# Bad
class Game
    attr_accessor :current_betting_round

    def create_new_betting_round
        current_betting_round = BettingRound.new
    end

    def start_new_hand
        create_new_betting_round
    end

    def pot_odds
        current_betting_round.pot / current_betting_round.high_bet
    end
end

# Good
class Game
    attr_accessor :current_betting_round

    def create_new_betting_round
        current_betting_round = BettingRound.new
    end

    def pot
        current_betting_round.pot
    end

    def high_bet
        current_betting_round.high_bet
    end

    def start_new_hand
        create_new_betting_round
    end

    def pot_odds
        pot / high_bet
    end
end

Here, we turn pot and high_bet into messages to which Game will respond, even though they represent messages sent to the current_betting_round. Game can still collaborate with BettingRound, but those collaboration points are isolated, which protects us from dependency problems.

Obey the Law of Demeter

The Law of Demeter instructs us that objects should really only talk to themselves, or, in limited capacity, to their direct collaborators. They should not send messages to objects that collaborate with their collaborating objects.

# Bad 

class Game 
    attr_accessor :players

    def initialize(players:)
        @players = players
    end

    def player_ranks
        players.map { |player| player.performance_history.rank }
    end
end

class Player 
    attr_accessor :performance_history

    def initialize(performance_history:)
        @performance_history = performance_history
    end
end

class PerformanceHistory 
    def rank 
        # Maybe some database queries for determining rank
    end
end

# Good

class Game 
    attr_accessor :players

    def initialize(players:)
        @players = players
    end

    def player_ranks
        players.map { |player| player.rank }
    end
end

class Player 
    attr_accessor :performance_history

    def initialize(performance_history:)
        @performance_history = performance_history
    end

    def rank
        performance_history.rank
    end
end

class PerformanceHistory 
    def rank 
        # Maybe some database queries for determining rank
    end
end

Here, in the bad example, the Game object violates the Law of Demeter by reaching beyond its direct collaborator, an instance of Player, and asking the player's PerformanceHistory to provide some ranking.

By allowing Player to respond to the request for rank, if we ever change the implementation of those rankings, we only have to change it in PerformanceHistory, and adapt to it in Player (notice the message to its collaborator is isolated in a method). Game never needs to know the change has happened.

Use the `private` keyword to create intentionally designed public interfaces

One of the easiest things you can do to improve your overall design is communicate your public interfaces clearly. Ruby provides the private keyword to aid you in this pursuit. Any methods defined after private can only be called by an instance of that class. This simple delineation in your class definition tells other developers (including yourself-from-the-future) that the following methods are internal only, and should not be used or depended upon elsewhere in the codebase.

# Bad
class Dealer
    attr_reader :deck

    def initialize
        # Assume we set the deck to some full set of playing cards
        deck = [card1..card52]
    end

    def next_card
        deck.pop
    end

    def shuffle_deck
        # Shuffle deck with Fisher-Yates
        (0..deck.size - 1).each do |i|
            j = rand(deck.size - 1)
            tempi = deck[i]
            tempj = deck[j]
            deck[i] = tempj
            deck[j] = tempi
        end
    end
end 

# Good
class Dealer
    attr_reader :deck

    def initialize
        # Assume we set the deck to some full set of playing cards
        deck = [card1..card52]
    end

    def next_card
        deck.pop
    end

    private 

    def shuffle_deck
        # Shuffle deck with Fisher-Yates
        # https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle
        (0..deck.size - 1).each do |i|
            j = rand(deck.size - 1)
            tempi = deck[i]
            tempj = deck[j]
            deck[i] = tempj
            deck[j] = tempi
        end
    end
end

Here, the Dealer object is responsible for maintaining the deck, shuffling the deck, and providing the next_card. However, we don't want to allow other objects to instruct a Dealer to shuffle the deck. The Dealer should be fully in charge of when it shuffles the deck. By defining shuffle_deck after private, we make this intention clear, and we set up some language-level restrictions on which objects can send the shuffle_deck method to a Dealer.

Moreover, we communicate to other developers not to rely on the logic in shuffle_deck elsewhere. Today we shuffle using Fisher-Yates. Tomorrow we may choose some new method of doing so. Regardless of those implementation details, a Dealer's public interface should always respond to next_card. That's much less likely to change, and other developers can rest easy asking Dealer objects for the next_card long into the future.

Use dependency injection by passing collaborating objects as arguments to methods

The term "dependency injection" is a loaded one. I'll be honest - I've avoided reading about it whenever it comes up. Sandi Metz makes the concept approachable. I hope to do the same. Here's what dependency injection means to me.

If a Game object needs to collaborate with a Dealer object, the Game object shouldn't directly instantiate the Dealer. Rather, we should pass some object to the Game object that represents the Dealer object.

# Bad
class Game
    attr_reader :dealer, :players

    def create_dealer
        @dealer = Dealer.new
    end

    def deal_hole_cards
        create_dealer
        players.each do |p|
            first_card = dealer.next_card
            second_card = dealer.next_card
            p.update!(hole_cards: [first_card, second_card])
        end
    end
end

# Good
class Game
    def deal_hole_cards(dealer:, players:)
        players.each do |p|
            first_card = dealer.next_card
            second_card = dealer.next_card
            p.update!(hole_cards: [first_card, second_card])
        end
    end
end

In the bad example, we follow an earlier directive by wrapping an object instantiation inside a method. That's good. But then we set that instance as an instance variable, and access it directly from the deal_hole_cards method. However, this approach leaves us with a dependency. Game needs to know about the dealer object it stored in the instance variable. It also needs to know about the players it stores as an instance variable

In the good example, we design Game to expect some dealer and players arguments to its deal_hole_cards method. Now we can call that method and provide any objects that respond to next_card (for the dealer argument) and update! (for the players). It provides us with flexibility, and we inject those object dependencies into the Game class.

Use duck typing when you see: case statements that switch on `class`, or methods that ask `is_a?` or `kind_of?`

Duck typing is useful for designing different classes that respond to the same message in order to treat them similarly. "Duck" comes from the saying "if it looks like a duck, walks like a duck, and quacks like a duck", with the implication being "it's a duck".

Sometimes you want similar classes to respond to a message slightly differently based on what they are. Say you have a TexasHoldEm class, which deals two cards to each player for their hole cards, and a FiveCardDraw class, which deals five cards. Here are two ways you could implement that:

# Bad
class Table 
    attr_accessor :game

    def begin_hand
        if game.kind_of?(TexasHoldEm)
            game.deal_two_hole_cards
        elsif game.kind_of(FiveCardDraw)
            game.deal_five_hole_cards
        end
    end
end

# Good
class Table 
    attr_accessor :game

    def begin_hand
        game.deal_hole_cards
    end
end

Here we replaced two different, but similar, methods with one duck type. In the bad example, we ask the game object to deal_two_hole_cards if it's a TexasHoldEm object, or to deal_five_hole_cards if it's a FiveCardDraw object. We can make that cleaner by defining one method on each class, with the same name: deal_hole_cards, and deal the appropriate number of cards in each class-specific implementation.

Use inheritance when you are conditionally sending messages to `self` based on some attribute of `self`

Duck typing is good way to improve your design when you already have multiple objects that respond to similar messages. But sometimes you end up with a class that could benefit from inheritance. One sign your design might be in need of inheritance is when messages are being conditionally sent based on some internal attribute.

# Bad
class Game 
    attr_reader :dealer, :game_type, :players

    def deal_hole_cards
        if game_type == 'texas_hold_em'
            number_of_cards = 2
        elsif game_type = 'five_card_draw'
            number_of_cards = 5
        end
        players.each do |player|
            cards = dealer.deal_cards(number_of_cards)
            player.update!(hole_cards: cards)
        end
    end
end

# Good 
class Game 
    attr_reader :dealer, :players
end

class TexasHoldEm < Game
    def deal_hole_cards
        players.each do |player|
            cards = dealer.deal_cards(2)
            player.update!(hole_cards: cards)
        end
    end
end

class FiveCardDraw < Game
    def deal_hole_cards
        players.each do |player|
            cards = dealer.deal_cards(5)
            player.update!(hole_cards: cards)
        end
    end
end

Here, we start with a Game class that could benefit from some refactoring. It conditionally deals a different number of cards based on whether or not its game_type is texas_hold_em or five_card_draw. By creating a TexasHoldEm class and a FiveCardDraw class, we can implement their respective deal_hole_cards methods appropriately for each type of game, and track one less instance variable in the Game superclass.

Promote code up to superclasses rather than down to subclasses

In the previous example, I hand-waved the restructuring of the classes. If you're going through the process of creating inheritance in your project where there was none to begin, keep in mind it is much easier to identify shared functions from subclasses and move them up, rather than figure out what might be different for subclasses by looking at the parent class.

All that to say, if you're creating inheritance, build out one new empty abstract class and move up what you need instead of adapting an existing class to be the superclass.

Every class should have a one sentence description, no conjunctions allowed

The first of the SOLID design principles is the single-responsibility principle. Volumes have been written about this principle alone. For these object-oriented heuristics, here's what you should ask yourself while reviewing your code:

"Can I describe what this class does in one sentence, without using any conjunctions?"

If the answer is no, your class could likely benefit from being split up into separate objects. It is probably responsible for too many things.

If you rephrase your class methods as questions to the object, each question should make sense; it should be related to the purpose of the class

Once you feel confident your class can be described with a single sentence, you can take the single-responsibility principle one step further by inspecting each method and rephrasing the method as a question to that class. Say it out loud and ask yourself: "does it make sense for me to ask this specific question of this specific object, given its purpose?"

If the answer is no, you should consider moving this method to a different class. Or perhaps your class could still benefit from being separated into different objects.

Messages should ask for "what" instead of dictating "how"

The prior exercise, rephrasing methods into questions, sets us up for this next item: methods should represent messages sent to the object. The object should receive the method call, and then answer the question. T

In order for your object to determine the response, it should have freedom to do so however it likes. Method calls should not dictate the internal behavior of the object. They should work as interfaces for other objects to retrieve relevant information. Keep in mind the distinction between public and private methods. An object's public methods should represent a set of questions it will respond to. Its private methods are an appropriate place to store implementation details, which are more likely to change than the kinds of questions the object will be asked.

Enforce good dependency direction

In earlier heuristics, we've looked at how to eliminate dependencies, or manage them responsibly. In any non-trivial software, it's impossible to eliminate all dependencies. Objects must collaborate and rely on one another. When you identify these necessary dependencies (and put safe guards around them), you will need to decide which object depends on which. This is the direction of your dependencies.

Generally speaking, objects should not depend on other objects that are likely to change more than themselves. When you use a framework liek Rails, you can remain somewhat assured that framework APIs will change less frequently than your code. It's responsible for your models to inherit from ActiveRecord.

Evaluate your own objects and determine which seem most stable. Have other objects depend on them, and so forth.

Depend on abstractions before depending on concrete classes

For a more practical application of good dependency direction, consider the difference between abstract classes and concrete classes. In Game inheritance example, we had TexasHoldEm and FiveCardDraw depend on Game, rather than one another. If you are having trouble identifying which classes are most stable and best to depend on, look for the superclasses in your inheritance hierarchy to guide you.

Default to composition over inheritance

Duck typing and other methods of composition are easier to maintain and reason about than inheritance. When you are refactoring your code and splitting up objects into smaller pieces, you should strive to create small, composable objects, rather than an overly-nested inheritance tree.

Create shallow hierarchies

When you do find that inheritance is the right choice for your design, do your best to keep your inheritance hierarchy shallow. As a general guideline, it's good to stop at one or two levels of inheritance. Any deeper should be an indication to you that you may have missed some opportunity for composition somewhere along the line.

Thanks

Thanks for reading! I hope my heuristics are useful to you. I find that by rigorously applying them during code review, I've developed a better sensibility around object oriented design. And a special thanks to Sandi Metz, for all her thought leadership and pioneering in object oriented design and Ruby programming.

A Nifty Use Case for Rails Virtual Attributes

Tyler Scott Williams — Mon, 17 Aug 2020 19:26:50 +0000

I work on a Rails project uses models to represent some front end components, which gives us access to clever tricks, including using virtual attributes for custom styling.

The base component class

All of these components inherit from a Component model that looks like this:

class Component < ApplicationRecord
  def css_class_list
    class_string = "#{self.class}"
    self.style_list.each { |style| class_string << (" " + style.to_s) if self.send(style) }
    class_string
  end
end

The css_class_list method spits out a class list for use in our ERB templates, like so:

<div class="<%= component.css_class_list %>"></div>

If we want to build out some EventComponent that inherits from the Component class, its rendered template would come out like this:

<div class="EventComponent"></div>

Customize the event component styles

Let's say we want to add some different flavors to the EventComponent. We can add additional CSS classes using the style_list method:

class EventComponent < Component
  belongs_to :page

  def style_list
    [
      :description_enabled
    ]
  end
end

The parent class, Component, grabs style_list and sends each symbol to the instance of the EventComponent. If it returns true, it adds the symbol to the final class list.

In this case, if we have an EventComponent with description_enabled, the rendered template would be:

<div class="EventComponent description_enabled"></div>

Generate CSS classes with virtual attributes

This works well for model attributes that are boolean values, but what if we want to style based on a non-boolean attribute? This is where virtual attributes really shine.

Here's a version of EventComponent that we can style based on the number of attendees:

class EventComponent < Component
  belongs_to :page

  def over_capacity # This is the virtual attribute
    rsvp_count > 1000
  end

  def style_list
    [
      :description_enabled
      :over_capacity
    ]
  end
end

Now if we render out an EventComponent with more than 1000 RSVPs, the output will look like:

<div class="EventComponent description_enabled over_capacity"></div>

And we can go on to target .EventComponent, .description_enabled, and .over_capacity with our CSS!

Clients, Servers, and the Single Responsibility Principle

Tyler Scott Williams — Sat, 15 Aug 2020 21:31:29 +0000

I'm working on a poker application and just found a nice refactor that taught me a little bit about the single responsibility principle in practice.

Modelling the desired behavior

Say you're playing a game of poker. The flop has just been dealt and it's your action. In this position, you can fold, check, or bet. Let's focus on betting.

If you've got 300 chips and bet 100, the action moves to the next player and they have to fold, call 100, or raise. If everyone calls your bet of 100, the turn will be dealt, and your action comes around again. Now you can fold, check, or bet (up to 200).

But if you had originally bet 300 chips after the flop, everyone called, and it became your turn again, you would be skipped over. A player who is all in has no action to take - they just wait until the hand wraps up and the showdown happens.

Since an all_in player has a restricted set of actions, we want to set up some indicators to represent when players go all in.

The `bet` function

Consider a bet method that looks something like this:

def bet(amount) 
  @player.chips.decrement!(amount)
  @game.pot.increment!(amount)
  move_to_next_player
end

This is a simple version of what a bet function might need to accomplish. If a players has 300 chips and calls bet(100), everything works out great.

But what if they call bet(300)? We have to mark them all_in.

So maybe we do something like:

def bet(amount) 
  @player.update(all_in: true) if amount == @player.chips 
  @player.chips.decrement!(amount)
  @game.pot.increment!(amount)
  move_to_next_player
end

That might work if going all in only happened on bets. But it can also happen when calling or raising. There are also a few other pieces of data we want to track, like which betting round a player went all in on, and how much they went all in with. So we can abstract it out to something like:

def go_all_in
  @game.pot.increment!(@player.chips)
  @player.update(all_in: true, all_in_round: 1, all_in_amount: @player.chips, chips: 0)
  move_to_next_player
end

So now our bet function could look like:

def bet(amount) 
  if amount == @player.chips 
    go_all_in
  else
    @player.chips.decrement!(amount)
    move_to_next_player
  end
end

The front end code

The game client is built with React. The betting button looks something like this:

<div>
  <input onChange={(e) => updateBetValue(e.target.value)} />
  <button onClick={() => handleClick()}>Bet {betValue}</button>
</div>

It's an input that changes the value of the bet, and a button that fires off a betting action to the server through the handleClick function.

When handleClick does too much

Here's where I went wrong. Initially, I duplicated my server-side logic that checked for an all in bet in the front end as well. It looked like this:

const handleClick = () => {
  if (betValue === player.chips) {
    goAllIn(); // Fires off a websocket action to run the `go_all_in` ruby function 
  } else { 
    bet(betValue); // Fires off a websocket action to run the `bet` ruby function. 
  } 
}

It works, and when I first made this choice, I decided it was a good idea to have duplication of the chip check. I figured it couldn't hurt to have additional checks around it. But I ran into two problems that the single responsibility principle would have warned me of:

One change, two files

Checking for chip equality isn't enough. It's possible that a user might try to be more chips than they have, not just the actual number. To catch this, I had to update the amount == @player.chips check to amount >= @player.chips.

I forgot to update the JS equivalent, and unit tests began to fail.

Confusing signals

When a player clicks the BetButton, they're indicating to the server "I would like to make a bet, here is the amount I'd like to bet".

Even if their desired bet amount is invalid, it's important to see what users are trying to do, because it keeps fidelity of information when I'm debugging.

With logic checks in the front end, if the user attempts to submit an invalid bet amount to the server, their message to the server gets intercepted and changed to a goAllIn() call. I lose the full set of information and it makes tracking bugs harder.

A pretty quick fix

The fix on this one was pretty quick. I refactored handleClick() to something like:

const handleClick = () => {
  bet(betValue);
}

It cleaned up my BetButton component and helped me track user activity with ease. I also know now that when I get bugs related to invalid bets, I can get the full information about what React was sending to the server, and if I need to adjust my logic around when a bet turns into a go_all_in call, I know that it lives in the ruby bet function and nowhere else.

It was a fun lesson in clean code for me. A simple change made my code easier to reason about, debug, and maintain.

Build a Rails Engine to Accept Stripe One-time Payments

Tyler Scott Williams — Wed, 13 May 2020 15:52:00 +0000

I maintain a handful of Ruby on Rails applications for my clients. Most of them need to handle payments. My go-to payment processor is Stripe. Stripe makes payments easy, but still requires some setup and configuration. I've written the same one-time payment feature about five times with slight variations, so I wanted to make it easier to repeat.

This sort of abstraction is a good candidate for a Rails engine.

Engines are basically sub-applications that provide functionality to a host application. They're great if you have some set of features that could reasonably be separated into their own application, but require a high amount of interoperability with your main application. (Thanks to Noah Gibbs for the phrasing on that one).

I wrote a proof-of-concept engine that:

Takes custom payment amounts
Takes credit cards from customers
Creates charges using Stripe

With that engine in hand, I can include it in any future project, provide the Stripe credentials, and save quite a bit of time.

Here's how you can do something similar.

Generate the engine

In the command line, run the rails plugin generator with the --mountable flag.

rails plugin new payments --mountable 
cd payments

Update the gemspec

The engine gemspec will have some TODO items in payments.gemspec. Fill them in:

# payments.gemspec
# . . . other config here
  spec.homepage    = "https://ogdenstudios.xyz"
  spec.summary     = "Adds Stripe one-time payment capability"
  spec.description = "Adds Stripe one-time payment capability"
# . . . the rest of the gemspec

Then run bundle. Once the installation is complete, check the engine is running by running rails s in the console and visiting localhost:3000. The standard Rails welcome page should appear.

Add the Stripe gem

Adding gems to a Rails engine is a little different than adding them to a Rails app. We have to use the gemspec instead of a Gemfile. To add the Stripe gem to the engine, update payments.gemspec.

# payments.gemspec 
# . . . other configuration here
  spec.add_dependency "stripe"
# . . . the rest of the gemspec

Then bundle again.

Create the payment_intents controller

Stripe uses PaymentIntents to process payments. The idea is to take some information from the customer, combine it with your credentials, and pass back an object that represents an intent to make a payment. Then we submit that intention to Stripe. Stripe verifies all the information is correctly formatted, and handles the final processing.

Let's make a PaymentIntentsController. This controller will only have one method for now, the create method. We'll use it to create a PaymentIntent and return it as a JSON response to our engine's view, which will then pass that PaymentIntent to Stripe for processing.

Create a file at app/controllers/payments/payment_intents_controller.rb. Inside:

# app/controllers/payments/payment_intents_controller.rb
require 'Stripe'
module Payments
    class PaymentIntentsController < ApplicationController
        def create 
            Stripe.api_key = Rails.configuration.x.stripe.secret
            @intent = Stripe::PaymentIntent.create({
                amount: params[:amount],
                currency: 'usd',
            })
            render json: @intent
        end
    end
end

This method configures the Stripe object, available through the Stripe gem, with the secret key. It creates a PaymentIntent from the supplied params hash and returns the intent as a JSON response.

Add the PaymentIntent create route

We have to provide access to the controller method through our routing. In config/routes.rb, add the create route for payment_intents. Like this:

# config/routes.rb
Payments::Engine.routes.draw do
    resources :payment_intents, only: [:create]
end

Add a checkout controller

PaymentIntentsController only handles creating the PaymentIntent. We also need a view for users to interact with the engine and make payments. We can call that a Checkout, and manage it through a CheckoutsController. Create a file at app/controllers/payments/checkouts_controller.rb.

# app/controllers/payments/checkouts_controller.rb
module Payments
    class CheckoutsController < ApplicationController
        def new 
        end
    end
end

This controller is only responsible for rendering the view that creates a new checkout, so we only need the new method.

Route to the checkouts controller

Update config/routes.rb so it looks like this:

#config/routes.rb
Payments::Engine.routes.draw do
    resources :checkouts, only: [:new]
    resources :payment_intents, only: [:create]
end

Create a view for new checkout

This is where users will make payments. Create a file at app/views/payments/checkouts/new.html.erb and use the boilerplate form provided through the Stripe docs. Stripe assumes you have hard-coded prices for your one-time payments. This engine allows users to provide a custom amount, so we add the amount input, which we'll use to create the PaymentIntent. It also has a custom pattern to format the input and require only numbers (with up to two decimal places).

<!-- app/views/payments/checkouts/new.html.erb -->
<form id="payment-form">
  <div>
    <label for="amount">Amount (USD)</label>
    <input
        id="amount"
        type="tel"
        placeholder="100.00"
        required=""
        autocomplete="tel"
        pattern="(?=.*?\d)^\$?(([1-9]\d{0,2}(\d{3})*)|\d+)?(\.\d{1,2})?$"
    />
    </div>
    <div id="card-element">
      <!-- Elements will create input elements here -->
    </div>
    <!-- We'll put the error messages in this element -->
    <div id="card-errors" role="alert"></div>
    <button id="submit">Pay</button>
</form>

Add Stripe Elements to the application layout

In order for Stripe to work on the client side, we need to include Stripe Elements in the view. We can set that up in app/views/layouts/payments/application.html.erb

<!-- app/views/layouts/payments.application.html.erb -->
<!DOCTYPE html>
<html>
  <head>
    <title>Payments</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>
    <%= stylesheet_link_tag "payments/application", media: "all" %>
    <script src="https://js.stripe.com/v3/"></script>
    <meta name="stripePublishableKey" content="<%= Rails.configuration.x.stripe.publishableKey %>" />
  </head>
  <body>
    <%= yield %>
  </body>
</html>

We also add a meta tag to embed the Stripe publishable key. We'll use that in our client-side JavaScript.

The client-side JavaScript

We'll add a script tag at the bottom of app/views/payments/checkouts/new.html.erb. The script will provide a basic user story for the checkout:

Get the publishable key from the meta tag
Get the CSRF token
Initialize Stripe Elements
Mount Stripe Elements to the card element
Set up error checking on the card-element to provide feedback if users don't provide well formatted card information
Set up an event listener for the form submit event
Tell the submit handler to POST to the /payments/payment_intents
Receive the PaymentIntent from the PaymentIntentsController
Submit the PaymentIntent to Stripe
Alert the user based on errors or successes

After the closing form tag, add:

<script>
  var publishableKey = document.getElementsByName('stripePublishableKey')[0].content
  var csrftoken = document.getElementsByName("csrf-token")[0].content;
  var stripe = Stripe(publishableKey);
  var elements = stripe.elements();
  var style = {
      base: {
          color: "#32325d",
      }
  };

  var card = elements.create("card", { style: style });
  card.mount("#card-element");

  document.getElementById('card-element').addEventListener('change', function (event) {
      var displayError = document.getElementById('card-errors');
      if (event.error) {
          displayError.textContent = event.error.message;
      } else {
          displayError.textContent = '';
      }
  });

  var form = document.getElementById('payment-form');

  form.addEventListener('submit', function (ev) {
      ev.preventDefault();
      // Get the data from the form
      var data = {
          amount: document.getElementById('amount').value * 100
      }
      // Get the client secret
      fetch('/payments/payment_intents', {
          method: 'POST',
          headers: {
              "Content-Type": "application/json",
              "X-CSRF-Token": csrftoken,
          },
          body: JSON.stringify(data),
      }).then(function (response) {
          response.json().then(function (data) {
              confirmPayment(data.client_secret);
          })
      })
      // Confirm the payment
      function confirmPayment(clientSecret) {
          stripe.confirmCardPayment(clientSecret, {
              payment_method: {
                  card: card
              }
          }).then(function (result) {
              if (result.error) {
                  // Show error to your customer (e.g., insufficient funds)
                  window.alert(result.error.message);
              } else {
                  // The payment has been processed!
                  if (result.paymentIntent.status === 'succeeded') {
                      window.alert('Succeeded!')
                      // Show a success message to your customer
                      // There's a risk of the customer closing the window before callback
                      // execution. Set up a webhook or plugin to listen for the
                      // payment_intent.succeeded event that handles any business critical
                      // post-payment actions.
                  }
              }
          });
      }
  });
</script>

Notice when we set the amount, we multiply it by 100:

amount: document.getElementById('amount').value * 100

This is because Stripe handles amounts as integer values in cents. The input is formatted for dollars, so we multiply by 100 to get the correct amount of cents to pass to the create method in PaymentIntentsController.

Try it out in a host application

Make a new Rails application. In the console:

cd ..
rails new hostapp
cd hostapp

Mount the engine. In hostapp/Gemfile:

gem 'payments', path: 'full/path/to/payments'

Run bundle in the command line to install everything.

Set up the engine routes

In hostapp/config/routes.rb, add the routes:

# hostapp/config/routes.rb
Rails.application.routes.draw do
  # For details on the DSL available within this file, see https://guides.rubyonrails.org/routing.html
  mount Payments::Engine, at: "/payments"
end

Link the engine stylesheet

The stylesheet from the engine needs to be linked to the hostapp for asset compilation. In hostapp/app/assets/stylesheets/application.css, add //= link payments/application.css.

The file should look like this entirely:

/*
 * This is a manifest file that'll be compiled into application.css, which will include all the files
 * listed below.
 *
 * Any CSS and SCSS file within this directory, lib/assets/stylesheets, or any plugin's
 * vendor/assets/stylesheets directory can be referenced here using a relative path.
 *
 * You're free to add application-wide styles to this file and they'll appear at the bottom of the
 * compiled file so the styles you add here take precedence over styles defined in any other CSS/SCSS
 * files in this directory. Styles in this file should be added after the last require_* statement.
 * It is generally better to create a new file per style scope.
 *
 *= require_tree .
 *= require_self
 //= link payments/application.css
 */

Securely store your Stripe API keys

Use Rails credentials to store your Stripe keys. For now, we can just the the test publishable key and the test secret key.

In the command line:

EDITOR="vim" rails credentials:edit

Then edit the file to add the following YAML:

stripe:
    test_publishable_key: your_key_here
    test_secret_key: your_key_here

Add the test keys to the development environment

In hostapp/config/environments/development.rb:

# `hostapp/config/environments/development.rb`
# . . . other configuration here
  config.x.stripe.publishableKey = Rails.application.credentials.stripe[:test_publishable_key] 
  config.x.stripe.secret = Rails.application.credentials.stripe[:test_secret_key]

Test it out

From within the hostapp directory:

Run rails s
Visit localhost:3000/payments/checkouts/new
Input an amount, fill in a test card number,
Submit the form and check your Stripe dashboard for the test charges.

Next steps

This engine isn't quite ready for primetime. This is mostly a proof-of-concept that I plan to expand on for personal use. Here are some things I might do to make it a little more versatile:

Create an installation rake task to handle the routing and asset linking with a command like rails generate payments:install
Create some generators to render the views and controllers for further configuration, like Devise does.
Handle the client-side JavaScript more gracefully. I don't love writing it inline, but I had trouble including the JavaScript correctly through the generator. I need to learn how to do that, or consider packaging it up separately to drop in as a separate JS dependency.

A Use Case for CSS Parent Selectors

Tyler Scott Williams — Fri, 10 Apr 2020 15:58:42 +0000

At some point, Chris Coyier suggested people write blog posts presenting why they might need parent selectors. Here's mine.

I've got some form that looks like this:

<form>
    <fieldset>
        <label for="category_1">Category 1</label>
        <input type="checkbox" id="category_1" name="category_1"><span></span><br><br>
    </fieldset>
    <fieldset>
        <label for="category_2">Category 2</label>
        <input type="checkbox" id="category_2" name="category_2"><span></span><br><br>
    </fieldset>
    <fieldset>
        <label for="category_3">Category 3</label>
        <input type="checkbox" id="category_3" name="category_3"><span></span><br><br>
    </fieldset>
    <input type="submit" value="Show results">
</form>

It allows people to select some grouping of filters: category 1, category 2, and category 3. When they hit Show results, they get some results back based on these filters.

I want to give a visual cue for which filters they've used. Maybe something like a background color on each associated fieldset that contains checked checkboxes. That feels somewhat straightforward.

But right now if I want to style the fieldset based on its child, I have to use JavaScript to maybe listen for a change or click event, find the correct fieldset, and update its styles through JS.

Alternatively, I could set up a pseudo-element to do the job. But wait! input elements can't have pseudo-elements. So now I have to add an empty span as a sibling and style its pseudo-elements. The markup changes to this:

<form>
    <fieldset>
        <label for="category_1">Category 1</label>
        <input type="checkbox" id="category_1" name="category_1"><span></span><br><br>
    </fieldset>
    <fieldset>
        <label for="category_2">Category 2</label>
        <input type="checkbox" id="category_2" name="category_2"><span></span><br><br>
    </fieldset>
    <fieldset>
        <label for="category_3">Category 3</label>
        <input type="checkbox" id="category_3" name="category_3"><span></span><br><br>
    </fieldset>
    <input type="submit" value="Show results">
</form>

And then I write these styles:

fieldset {
    position: relative;
}

input:checked + span:before {
  content: '';
    position: absolute;
    height: 100%;
    width: 100%;
    top: 0;
    left: 0;
    z-index: -1;
    background-color: green;
}

It's workable. It's only a little extra code. But it would be really slick if I could write some CSS that looked like:

input:checked PARENT_SELECTOR_SYMBOL_HERE fieldset {
    background-color: green
}

Here's a codepen with the sample code so you can play around with it and see what I mean

Wrapping nuxt-links to make your Vue.js components Nuxt.js agnostic.

Tyler Scott Williams — Mon, 23 Mar 2020 22:48:54 +0000

At work we've got a component library built in Vue.js. It's great because we can take the components our designers create, build them once, and then ship them to any project.

Most, but not all, of our projects use Nuxt.js. We like it because it gives us the ability to build sites with server-side rendering, static site generation, or single-page applications as needed.

Building the components for Nuxt

We have navigational components in our library like a Navbar component and a Footer component. Since these components typically direct users around internal pages on our Nuxt projects, we want to use the nuxt-link component to get the most out of the framework.

nuxt-link allows users to navigate the application like they might expect with a router-link. It is itself an extension of router-link.

But to use nuxt-link, the component needs to be used inside a Nuxt project. In Nuxt projects that's fine, but what do we do when we aren't using Nuxt? In those cases, we may want to use a regular HTML a tag.

Wrapping nuxt-link

So we built a utility component to wrap our links. It's aptly named AnchorLinkOrNuxtLink. Here's what that looks like:

<template>
    <nuxt-link v-if="nuxt" :to="to">
        <slot></slot>
    </nuxt-link>
    <a v-else :href="to">
        <slot></slot>
    </a>
</template>

<script>
export default {
    props: ['nuxt', 'to']
}
</script>

We pass two props to the AnchorLinkOrNuxtLink component:

nuxt: a boolean value which makes the component act as a nuxt-link or an a tag.
to: some string that acts as the to prop on a nuxt-link, or the href attribute on an a tag.

We use conditional rendering to check if nuxt is true. If so, we use nuxt-link. Otherwise, the component renders as an a tag. If the nuxt prop isn't passed in, the expression will evaluate to false and we default to the safe fallback of an a tag, which will work in either a Nuxt project or something else.

Finally, since both nuxt-links and a tags are able to wrap things, we provide a slot component inside either to contain any wrapped content.

Putting it together

We want to be able to create a flexible component that can take links and render out either nuxt-links or a tags. Let's look at a quick example. Say we want a Navbar component with three links:

The brand element that navigates to /
A secondary About page
Some link to an external resource like Partner site.

We can build that like this:

<template>
    <nav>
        <ul>
            <li>    
                <AnchorLinkOrNuxtLink to="/" :nuxt="brandIsNuxtLink">
                    <img src="some-logo.jpg" />
                </AnchorLinkOrNuxtLink>
            </li>
            <li v-for="item in navbar.links" :key="item.link">
                <AnchorLinkOrNuxtLink :to="item.link" :nuxt="item.nuxt">
                    {{ item.title }}
                </AnchorLinkOrNuxtLink>
            </li>
        </ul>
    </nav>
</template>

<script>
import AnchorLinkOrNuxtLink from './AnchorLinkOrNuxtLink.vue';

export default {
    components: {
        AnchorLinkOrNuxtLink
    },
    props: ["brandIsNuxtLink", "navbar"]
}
</script>

This component takes two props:

brandIsNuxtLink: since the brand element is a bit different than the rest of the links in the nav, we call this out separately. We can pass a boolean to determine nuxt-link vs a tag behavior.
navbar: we can pass an object as this prop to set up the links. It might look something like this:

navbar: {
    links: [
        {
            link: '/about',
            nuxt: true,
            title: 'About'
        },
        {
            link: 'https://www.partner.com',
            nuxt: false,
            title: 'Partner site'
        }
    ]
}

The /about link will act as a Nuxt link, and the https://www.partner.com link will act like a normal anchor link.

Fun!

Troubleshooting Devise Redirects with Multiple Models and Turbolinks

Tyler Scott Williams — Tue, 18 Feb 2020 20:27:00 +0000

Using two Devise Models

I pretty much always default to using Devise for my Ruby on Rails authentication.

For my current side project built in Rails 6, I've got two authenticating models: Author and Reader. It makes sense for me to keep these two models entirely separate. It's made my life a lot easier, in general. Using multiple models is supported out of the box with Devise, with some custom configuration.

Preventing Cross-model Visits with Devise

Devise provides a sample solution to prevent a logged in Author from concurrently logging in as a Reader, and vice-versa.

I modified the sample code a little bit when I first implemented this. I didn't have anywhere to send them since I built it out early in the development process, so I had each model redirect_to the root_path. This laid the groundwork for two days of troubleshooting down the road.

My custom Accessible module was initially written like this:

# ../controllers/concerns/accessible.rb
module Accessible
  extend ActiveSupport::Concern
  included do
    before_action :check_user
  end

  protected
  def check_user
    if current_admin
      flash.clear
      # if you have rails_admin. You can redirect anywhere really
      redirect_to(root_path) and return
    elsif current_user
      flash.clear
      # The authenticated root path can be defined in your routes.rb in: devise_scope :user do...
      redirect_to(root_path) and return
    end
  end
end

The Turbolinks Red Herring

As time went on, I built out most of the functionality of the application. I got the MVP working, built out some seed data, and deployed to a staging environment. I did some manual testing and played around with everything, and noticed that whenever I logged in as a sample Author or Reader, I got redirected to the home page. I assumed I had misconfigured something, so I followed this wiki article to redirect users back to their last visited page.

The wiki article provides two different implementations. I tried both and couldn't get it to work for the life of me. I dug in to the helper methods, hard coded returns, ran byebug sessions, and couldn't quite figure out waht wasn't working.

But I noticed that both of the methods provided by Devise checked if the request was an XHR. I thought I had identified the bug: I was using turbolinks out of the box with Rails 6. I don't know precisely what Turbolinks is doing under the hood, but my understanding is that it uses client-side requests to pre-render pages from the same origin, providing an SPA-like experience.

I figured Turbolinks navigation was breaking the expected Devise behavior. I found semi-recent blog posts about this phenomenon. I saw a few issues across the Turbolinks and Devise repositiories. I figured I was on to something.

Building a Reduced Test Case

So after I latched on to this idea, I decided I would write a blog post about it. To demonstrate the problem, I spun up a sample Rails app with Turbolinks and Devise. I duplicated my issue. As I went to turn off Turbolinks and demonstrate the root cause, I found this snippet in config/initializers/devise.rb:

# ==> Turbolinks configuration
# If your app is using Turbolinks, Turbolinks::Controller needs to be included to make redirection work correctly:
#
#  ActiveSupport.on_load(:devise_failure_app) do
#    include Turbolinks::Controller
#  end

So I un-commented the piece of configuration, but no luck. There was still a problem.

Removing the `current_user` Check

In the first StoreLocation example, I noticed that store_location_for(:user, request.fullpath) was only being triggered if current_user.present? returned true.

But that doesn't track for me. I want to store the location for a User (or Author, or Reader, or whomever) before they log in. So I removed that check. In my sample app, with just one User Devise model, and with Turbolinks::Controller turned on, I implemented the following:

# This example assumes that you have setup devise to authenticate a class named User.
class ApplicationController < ActionController::Base
  before_action :store_user_location!, if: :storable_location?
  # The callback which stores the current location must be added before you authenticate the user 
  # as `authenticate_user!` (or whatever your resource is) will halt the filter chain and redirect 
  # before the location can be stored.
  before_action :authenticate_user!

  private
    # Its important that the location is NOT stored if:
    # - The request method is not GET (non idempotent)
    # - The request is handled by a Devise controller such as Devise::SessionsController as that could cause an 
    #    infinite redirect loop.
    # - The request is an Ajax request as this can lead to very unexpected behaviour.
    def storable_location?
      request.get? && is_navigational_format? && !devise_controller? && !request.xhr? 
    end

    def store_user_location!
      # :user is the scope we are authenticating
      store_location_for(:user, request.fullpath)
    end
end

And it worked! I figured I had solved my problem. All I needed to do to make it work in my actual application was:

Turn on Turbolinks::Controller
Implement the first store_user_location! method
Remove checks for current_author and current_reader
???
Profit!

Hubris. Pure Hubris.

I made those changes to my application. No luck. I tried the second implementation of store_user_locaiton!... no luck. I turned Turbolinks on and off again. No luck. I yelled a little bit into a pillow. No luck, but it felt good.

I started digging into the differences between the sample application and my real application. I figured the biggest difference was using one Devise model vs. using many. So I started looking at the generated controllers and views for my multiple Devise models. I wrote some experimental code, tried to override after_sign_in_path_for from Devise, and still no luck.

But, if you'll recall, I was preventing cross-model visits with my Accessible module. For laughs, I turned off the module. Things started working.

The Real Culprit: Hardcoded Redirects

Remember how I told my Accessible module to redirect_to(root_path) and return in check_user? Yeah - me neither. I forgot I had written that method long ago before the application had taken shape. Forgot that I was hardcoding a redirect to the root path.

So I tapped into the stored_location_for method from Devise. I rewrote the Accessible module to look like:

module Accessible
  extend ActiveSupport::Concern
  included do
    before_action :check_user
  end

  protected

  def check_user
    if current_author
      flash.clear
      redirect_to(stored_location_for(:author)) and return
    elsif current_reader
      flash.clear
      redirect_to(stored_location_for(:reader)) and return
    end
  end
end

And everything started working. Now:

Authors can't log in as Readers without signing out first
Readers can't log in as Authors without signing out first
When a person signs in to either an Author or a Reader account, they will then be redirected to the last page they were viewing before signing in
Turbolinks are still working.

Refactoring Personal Data out of a Devise Model

Tyler Scott Williams — Sun, 16 Feb 2020 23:00:18 +0000

I'm working on Ruby on Rails application. It's an ecommerce platform for print creators. My minimum viable product is working, and it's time to roll up my sleeves and refactor the code to get it production-ready.

What needs to change about my Reader Model?

The basic authentication model is the Reader. It represents what you might consider to be a User in other applications.

This model is built with Devise. When I first wrote it, I also used it to store profile information for each reader.

After some great conversations in the Ruby on Rails Link Slack, I've come to understand that my authentication model shouldn't be responsible for managing user data. It sort of violates the single responsibility principle. And practically speaking, every attribute follows the current_reader object in controllers and views. So if I have a logged-in Reader on the home page, the view knows all of its attributes. In my case, that only includes a first_name and last_name column, but this approach can lead to problems down the road.

If I continue to add reader data in the Reader model, I will be loading a lot of unnecessary data in each request with the current_reader object.

I want to contain these attributes in a new class called ReaderProfile, of which each Reader object will have_one.

The Current Reader Model

This is my current ApplicationRecord subclass:

# frozen_string_literal: true

class Reader < ApplicationRecord
  # Include default devise modules. Others available are:
  # :confirmable, :lockable, :timeoutable, :trackable and :omniauthable
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :validatable
  has_many :works, :through => :purchases
  has_many :followings
  has_many :purchases
  has_many :reading_list_items
  has_many :works_to_read, through: :reading_list_items, source: :work
  has_many :reviews
end

And the relevant schema from db/schema.rb.

create_table "readers", force: :cascade do |t|
    t.string "email", default: "", null: false
    t.string "encrypted_password", default: "", null: false
    t.string "reset_password_token"
    t.datetime "reset_password_sent_at"
    t.datetime "remember_created_at"
    t.datetime "created_at", precision: 6, null: false
    t.datetime "updated_at", precision: 6, null: false
    t.string "first_name"
    t.string "last_name"
    t.index ["email"], name: "index_readers_on_email", unique: true
    t.index ["reset_password_token"], name: "index_readers_on_reset_password_token", unique: true
end

The Current Reader Tests

I'm using RSpec to test my Rails application, along with FactoryBot for my factories.

I have unit tests in spec/models/reader_spec.rb. Here's what I test for:

# frozen_string_literal: true

require 'rails_helper'

RSpec.describe Reader, type: :model do
  it 'has a valid factory' do
    expect(build(:reader)).to be_valid
  end
  describe 'associations' do
    it { should have_many(:followings) }
    it { should have_many(:purchases) }
    it { should have_many(:reading_list_items) }
    it { should have_many(:reviews) }
    it { should have_many(:works) }
  end
end

The ReaderProfile Model

I can create my new ReaderProfile model with the command:

rails g model ReaderProfile first_name:string last_name:string reader:references

This creates the relevant ActiveRecord class, Rails migration, and tests for the class.

Testing the ReaderProfile

I'm going to make first_name and last_name information optional for readers, so all I want to do is make sure I've got a test in spec/models/reader_profile_spec.rb that checks for a valid factory and it belongs to a Reader object. Here's what that unit test looks like:

RSpec.describe ReaderProfile, type: :model do
  it 'has a valid factory' do
    expect(build(:reader_profile)).to be_valid
  end
end

My factory in spec/factories/reader_profiles.rb looks like:

FactoryBot.define do
  factory :reader_profile do
    first_name { "MyString" }
    last_name { "MyString" }
    reader { create(:reader) }
  end
end

I add the belongs_to code in my ReaderProfile model like so:

# app/models/reader_profile.rb
class ReaderProfile < ApplicationRecord
    belongs_to :reader
end

And when I run rspec spec/models/reader_profile_spec.rb, my tests pass.

Adding to the Reader Tests

I want every Reader object to have one ReaderProfile. To test that, I add the following to spec/models/reader_spec.rb:

it { should have_one(:reader_profile) }

And I update the Reader model to look like:

# frozen_string_literal: true

class Reader < ApplicationRecord
  # Include default devise modules. Others available are:
  # :confirmable, :lockable, :timeoutable, :trackable and :omniauthable
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :validatable
  has_many :works, :through => :purchases
  has_many :followings
  has_many :purchases
  has_many :reading_list_items
  has_many :works_to_read, through: :reading_list_items, source: :work
  has_many :reviews
  has_one :reader_profile
end

When I run rspec spec/models/reader_spec, everything passes.

Updating the impacted Views and Controllers

I've been focusing on the model layer of this refactoring. It's worth noting that I have current_reader.first_name and current_reader.last_name strewn through my application. I'll need to find-and-replace those instances to current_reader.reader_profile.first_name and current_reader.reader_profile.last_name.

I'll also need to drop the first_name and last_name parameters from the ReadersController, and create endpoints for readers to create, update, and delete their profiles.

Conclusion

Aside from my remaining TODOs, I've made good progress today. Now I have a ReaderProfile model to encapsulate personal information associated with each Reader. This makes it easier to add more pieces of Reader data without bloating the authentication class. It also means I can extend my authentication class to include different types of profiles if I like. Here's what my refactoring is really saying:

The Reader model handles authentication and authorization for readers. When a reader signs in, they can access their associated ReaderProfile.
The ReaderProfile model stores personal information about the Reader it belongs to.

Sort Array by Parity

Tyler Scott Williams — Tue, 11 Feb 2020 16:35:29 +0000

This post is part of my "LeetCode for 1x Developers" series, in which I struggle through LeetCode problems. Sometimes I figure it out, other times I don't. Either way, I give each problem my best shot, and write up my thought process through the challenges

Problem description

Problem on leetcode

Given an array A of non-negative integers, half of the integers in A ar odd, and half of the integers are even.

Sort the array so that whenever A[i] is odd, i is odd. And when A[i] is even, i is even.

You may return any answer array that satisfies this conditions.

Examples

Input: [4,2,5,7]
Output: [4,5,2,7]
Explanation: [4,7,2,5], [2,5,4,6], [2,7,4,5] would also have been accepted.

Solution

Intuition

OK, so it looks like we don't have to actually sort the array in any meaningful way. We can probably do something with it in-place. We also know we'll always have enough numbers to fill the pattern, since half of the integers are odd and half are even.

Can we do this in place? Let's look at the example:

[4, 2, 5, 7]

Check A[0]. It's 4. OK, it's all good since i and A[i] are both even.

Now check A[2], it's 2. i is odd, but A[i] is even. We need to move it. I almost want to just swap it with the next value, but I am pretty sure that won't work all the time so I'm going to leave it alone.

What if we stored all of the even numbers in an array called even and all the odd numbers in an array called odd? We could then rebuild an array and pull a number from each depending on the parity of the number.

I'm worried about basically running two loops and using three arrays. But I think it's still technically O(n), and the space constraints will only ever be 2n. Maybe that's reasonable. Let's find out.

Here's my first pass at expressing this solution in JavaScript (ES6):

var sortArrayByParityII = function(A) {
    let even = [];
    let odd = [];
    let result = [];
    for (let i=0; i<A.length; i++) {
        if (A[i] % 2 === 0) {
            even.push(A[i]);
        } else {
            odd.push(A[i]);
        }
    }
    for (let j=0; j<A.length; j++) {
        if (j % 2 === 0) {
            result[j] = even.pop();
        } else {
            result[j] = odd.pop();
        }
    }    
    return result;
};

It passed, faster than 51.97% of JS solutions, and with less than 27.27% of JS solutions. I wonder where I can optimize it. It feels like I should be able to do something in one loop, but I can't really reckon with it.

Answer

After checking the discussion section, I found there is a one-loop solution. It's not too far off from my first pass.

First, you set up an empty array, which you'll use as the result. Call it result.

Then you set an evenIndex to 0, and an oddIndex to `.

You loop through the input array A. If A[i] is even, you set result[evenIndex] to the value and increment evenIndex by two. If it's odd, you set result[oddINdex] to the value and increment oddIndex by two.

You can express it like this:

var sortArrayByParityII = function(A) { let result = []; let evenIndex = 0; let oddIndex = 1; for (let i=0; i<A.length; i++) { if (A[i] % 2 === 0) { result[evenIndex] = A[i]; evenIndex += 2; } else { result[oddIndex] = A[i]; oddIndex += 2; } } return result; }

And it runs faster than 86% of JS solutions with less memory than 36% of other solutions. Nice!

After having done a dozen or so easy problems, I'm really starting to see most Leetcode easy problems as array mapping solutions.

Find the K-th Symbol in Grammar

Tyler Scott Williams — Mon, 10 Feb 2020 18:24:14 +0000

Problem description

Problem on leetcode

On the first row, we write a 0. Now in every subsequent row, we look at the previous row and replace each occurence of 0 with 01, and each occurrence of 1 with 10.

Given row N and index K, return the K-th indexed symbol in row N. The values of K are `-indexed.

Examples

Input: N = 1, K = 1
Output: 0

Input: N = 2, K = 1
Output: 0

Input: N = 2, K = 2
Output: 1

Input: N = 4, K = 5
Output: 1

Explanation:

row 1: 0
row 2: 01
row 3: 0110
row 4: 01101001

Solution

Intuition

Based on the generating of the rows, I have a feeling there's a mathematical solution to this that's faster than a data structure based algorithm.

To get a feel for what's going on and how I might express it mathematically, I'm going to manually write out the pattern.

Looking at four rows:

0
01
0110
01101001
0110100110010110

I notice that the number of items in each row is 2^N. Which suggests to me there might be some bitwise solution here, which also feels right considering all the 0 and 1 values.

What's more, looking at the way that the pattern stacks (every row N is the beginning of the next row N+1), I don't think N really matters. I think there's something I can do with K.

I'm feeling really good about there being an existing binary operation I can do, but I just can't quite find it or reason about it. I've mentioned this in other posts, but I'm definitely weak when it comes to binary operations and using them for problem solving. This probably comes from my day-to-day in web development, where I'm just not using that kind of problem-solving tool.

So I looked up the discussion answer and I was absolutely on the right track. There is a single arithmetic I can do, in binary, and ignoring N completely.

Answer

Here's a Python one-liner which converts K-1 into its binary representation, counts how many times 1 appears in that representation, and runs a bitwise AND operation on the result.

I couldn't quite grok what was going on and why, but I found this explanation which helps more.

Basically, since we know the prefix of every row N is the same, we only care about how the new row N+1 is going to generate its new string up to K, which will depend on the number K-1.

If we know what K-1 in binary is, we'll know how many times the 01 and 10 pattern toggles back and forth before the number we care about, K.

So we convert it over, count up the 1s, and convert that number into binary. We then run bitwise AND against it to determine the Kth value.

We don't have all the syntactic sugar that comes along with Python, Java, and C++ for bitwise operations, so here's a way to represent it in JavaScript:

var kthGrammar = function(N, K) { let binary = (K-1).toString(2); let array = binary.split(''); let count = 0; for (let i=0; i<array.length; i++) { if (array[i] === '1') { count++; } } return count & 1; };

DEV Community: Tyler Scott Williams

Duplicate Zeros - Optimal Solution in Ruby

Description

Solution

Code

Duplicate Zeroes, Naive Solution

Problem

Solution

Code

Analysis

Heuristics for Object-Oriented Design in Ruby

The Heuristics

Code smells

Code organization

Abstraction considerations

Use named args to remove order dependencies

Hide all instance variables behind methods

Isolate new instances of objects behind methods

If an object must send messages to any object other than self, isolate sending that message in one single method

Obey the Law of Demeter

Use the private keyword to create intentionally designed public interfaces

Use dependency injection by passing collaborating objects as arguments to methods

Use duck typing when you see: case statements that switch on class, or methods that ask is_a? or kind_of?

Use inheritance when you are conditionally sending messages to self based on some attribute of self

Promote code up to superclasses rather than down to subclasses

Every class should have a one sentence description, no conjunctions allowed

If you rephrase your class methods as questions to the object, each question should make sense; it should be related to the purpose of the class

Messages should ask for "what" instead of dictating "how"

Enforce good dependency direction

Depend on abstractions before depending on concrete classes

Default to composition over inheritance

Create shallow hierarchies

Thanks

A Nifty Use Case for Rails Virtual Attributes

The base component class

Customize the event component styles

Generate CSS classes with virtual attributes

Clients, Servers, and the Single Responsibility Principle

Modelling the desired behavior

The bet function

The front end code

When handleClick does too much

One change, two files

Confusing signals

A pretty quick fix

Build a Rails Engine to Accept Stripe One-time Payments

Generate the engine

Update the gemspec

Add the Stripe gem

Create the payment_intents controller

Add the PaymentIntent create route

Add a checkout controller

Route to the checkouts controller

Create a view for new checkout

Add Stripe Elements to the application layout

The client-side JavaScript

Try it out in a host application

Set up the engine routes

Link the engine stylesheet

Securely store your Stripe API keys

Add the test keys to the development environment

Test it out

Next steps

A Use Case for CSS Parent Selectors

Wrapping nuxt-links to make your Vue.js components Nuxt.js agnostic.

Building the components for Nuxt

Wrapping nuxt-link

Putting it together

Troubleshooting Devise Redirects with Multiple Models and Turbolinks

Using two Devise Models

Preventing Cross-model Visits with Devise

The Turbolinks Red Herring

Building a Reduced Test Case

Removing the current_user Check

Hubris. Pure Hubris.

The Real Culprit: Hardcoded Redirects

Refactoring Personal Data out of a Devise Model

What needs to change about my Reader Model?

The Current Reader Model

The Current Reader Tests

If an object must send messages to any object other than `self`, isolate sending that message in one single method

Use the `private` keyword to create intentionally designed public interfaces

Use duck typing when you see: case statements that switch on `class`, or methods that ask `is_a?` or `kind_of?`

Use inheritance when you are conditionally sending messages to `self` based on some attribute of `self`

The `bet` function

Removing the `current_user` Check