DEV Community: Alexander Rovang

2D arrays vs. Nested arrays

Alexander Rovang — Fri, 11 Feb 2022 16:36:04 +0000

At some point in the Leetcode/Hackerrank code challenges you start to see the phrase "2D array" a lot (also known as 2-Dimensional arrays). We learned a lot about nested arrays at my bootcamp, but this other naming convention never came up, so it was a little confusing to see the first time. This post is about clarifying the connection for myself (and maybe you?).

The idea of a nested array is pretty simple. You have an array, and inside that array you have one or more arrays as elements.

let myArray = [[1,2,3],[4,5,6]]

If we were to access an element in that outer array, we would call it via single bracket notation and the appropriate index.

myArray[1]     // [4,5,6]

To call an element inside one of the inner arrays, we would need to add a second bracket.

myArray[1][2]     // 6

For months I had visualized these nested arrays exactly as you're seeing them above: in a linear fashion. And, yes, I realize that computers don't care about the optics of arrays, but being a highly visual person it was an easy way for me to understand them. Even a nested array with a lot of elements I thought of in a straight line.

let longArray = [[a,f,x,d],[q,l],[m,c,u,t,i],[w],[b,g,o]]

(Also, I took way too long deciding which letters looked good together just now.)

But when I started seeing the new and scary 2D array problems they were often shown like this.

This was usually the point at which my mind shut down and I went for a run.

There were 3 problems I had with this structure.

1) No brackets [scare factor: 10]
2) Perfect square structure
(Can't nested arrays have different numbers of elements in each internal array? How could these possibly be the same thing??)
3) Non-linear [Heart stops].

Let's go ahead and solve these one at a time.

Brackets.

[
  [1, 6, 3, 4],
  [2, 8, 5, 0],
  [9, 2, 7, 7],
  [3, 5, 0, 2]
]

Great. Done.
[insert huge sigh of relief here]

Square structure.
YES. Nested arrays CAN have a different numbers of elements. Technically I suppose it's possible for a 2D array to have different numbers of elements, but 99% of the code challenges I've seen are geared toward grid structures like you see above because they are 1000 times easier to access and manipulate. It's like color theory. All pinks are in the red family, but reds aren't considered part of the pink family. Just because a 2D array happens to have a square or rectangular structure doesn't mean it's not still a nested arrayed at heart.

Non-linear pattern.

[
  [1, 6, 3, 4],
  [2, 8, 5, 0],
  [9, 2, 7, 7],
  [3, 5, 0, 2]
]

[[1, 6, 3, 4],[2, 8, 5, 0],[9, 2, 7, 7],[3, 5, 0, 2]]

Literally the same thing.

So why write it like a grid? Here's where it gets interesting. My guess is that grid notation is used to help you better visualize (oh, the irony) the methods of access.

Let's look at a pretty common javascript algorithm: the nested for-loop.

for(let i = 0; i < myArray.length; i++){
     for(let j = 0; j < myArray.length; j++{
          //your code here
     }
}

Note that this particular loop starts at the very beginning of the first nested array and works its way through each internal array from left to right. If we visualize this is in a linear pattern, the loop access would look something like this.

let myArray = [[1, 6, 3, 4],[2, 8, 5, 0],[9, 2, 7, 7],[3, 5, 0, 2]]
//1st element:  myArray[i][j] = myArray[0][0] = 1
//2nd element:  myArray[i][j+1} = myArray[0][1] = 6
//3nd element:  myArray[i][j+2} = myArray[0][2] = 3

Not terrible. But what if for some reason we needed to start at the end of each internal array and search backwards? Then the loop would look like this...

for(let i = 0; i < myArray.length; i++){
     for(let j = myArray.length; j >=0; j--{
          //your code here
     }
}

... and the corresponding results would look like this.

let myArray = [[1, 6, 3, 4],[2, 8, 5, 0],[9, 2, 7, 7],[3, 5, 0, 2]]
//1st element:  myArray[i][j] = myArray[0][3] = 4
//2nd element:  myArray[i][j+1} = myArray[0][2] = 3
//3nd element:  myArray[i][j+2} = myArray[0][1] = 6

Starting to get a little confusing. Now let's say you wanted to check the first element in the first array, the second element in the second array, the third in the third, and so on?

for(let i = 0, j = 0; i < myArray.length; i++, j++){
     //your code here
}
let myArray = [[1, 6, 3, 4],[2, 8, 5, 0],[9, 2, 7, 7],[3, 5, 0, 2]]
//1st element:  myArray[i][j] = myArray[0][0] = 1
//2nd element:  myArray[i][j+1} = myArray[1][1] = 8
//3nd element:  myArray[i][j+2} = myArray[2][2] = 7

If you're thinking about your nested arrays in a linear fashion, that looks like a hot mess. But turn it into it's 2D cousin...

[
  [1, 6, 3, 4],
  [2, 8, 5, 0],
  [9, 2, 7, 7],
  [3, 5, 0, 2]
]

...and suddenly it becomes very obvious that you're just going along a diagonal in a square.

Now, if you google tutorials on 2D arrays you'll find that they consistently talk about "rows" and "columns". Which makes perfect sense when you're looking at a grid. But again, it's a little confusing when thinking about nested arrays. Let's take another look at the original example of javascript nested for-loops.

for(let i = 0; i < Arr.length; i++){
     for(let j = 0; j < Arr.length; j++{
          //your code here
     }
}

Remember that the "i" in this algorithm represents the indices of the OUTER array. Those are the rows.

// Arr[i]
     [                                
          [1,   6,   3,   4],         // Arr[0]
          [2,   8,   5,   0],         // Arr[1]
          [9,   2,   7,   7],         // Arr[2]
          [3,   5,   0,   2]          // Arr[3]
     ]

The columns, the indices of the INNER arrays, are the "j".

//                 [j]        [j]        [j]        [j]
//           Arr[i][0]  Arr[i][1]  Arr[i][2]  Arr[i][3]
           [                                           
                  [1,        6,        3,        4],   
                  [2,        8,        5,        0],   
                  [9,        2,        7,        7],   
                  [3,        5,        0,        2]    
          ]

The thing that took me awhile to wrap my head around is that the data types for "i" and "j" are NOT the same. The data type for "i" is an array. The data type for "j" are the elements (usually numbers with these coding challenges) inside the arrays. You can't see that in an open grid structure. They all just look like numbers.

I hope this helps a little? It's definitely helped me solidify my own understanding of 2-Dimensional arrays, so thanks for letting me put it all down somewhere. :)

Best of luck!

Notes to Myself (Rails:Entry#2a - Nested Forms)

Alexander Rovang — Sat, 06 Nov 2021 22:00:00 +0000

This is a step-by-step instructional doc to use when creating nested forms. It will cover belongs_to, has_many, and has_many_through associations.

The example models I will be using are Author, Posts, and Categories.

class Author < ApplicationRecord
  has_many :posts
  has_many :categories, through: :posts
end

class Post < ApplicationRecord
  belongs_to :category
  belongs_to :author
end

class Category < ApplicationRecord
  has_many :posts
  has_many :authors, through: :posts
end

BELONGS_TO

The first scenario is when you have a child instance that has a belongs_to relationship with a parent class (in this example the child is the Post class which has 2 parent classes: Author & Category), and we would like to create a new instance of the child object that is automatically associated with it's parent class.

There are 3 methods that will achieve this form. The first assumes that a parent class already exists. The second assumes that it does not exist. The third assumes that there are potential parent classes which exist, but the user may want to create their own.

The Parent Class Exists

1) In the child controller, create a 'dummy' instance to trigger the form_for builder. This will be the same for all three scenarios.

  def new
    @post = Post.new
  end

2) On the child form page, use text_field for the child attributes and collection_select for the parent attributes.

<%= form_for @post do |f| %>
<div><%= f.label "Post Content" %>
     <%= f.text_field :content %></div>
<div><%= f.label "Author" %>
     <%= f.collection_select author_id, Author.all, :id, :name %></div>
<div><%= f.label "Category" %>
     <%= f.collection_select category_id, Category.all, :id, :name %></div>
     <%= f.submit %>
<% end %>

3) In the child controller, define strong params.

  private

  def post_params
    params.require(:post).permit(
      :content, 
      :category_id, 
      :author_id
    )
  end

4) In the child controller, create the child object. This will also be the same for all three scenarios.

 def create
    Post.create(post_params)
    redirect_to posts_path
  end

*special note - Author.all and Category.all (used on the form page) can & should be refactored in view helper

The Parent Class Does Not Exist

1) see Ex.1

2) In the child model, define a setter/getter method for the parent. This will be the same in the 3rd scenario.

def author_name=(name)
  self.author = Author.find_or_create_by(name: name)
end

def author_name
   self.author ? self.author.name : nil
end

def category_name=(name)
  self.category = Category.find_or_create_by(name: name)
end

def category_name
   self.category ? self.category.name : nil
end

3) On the child form page, use text_field for all attributes of both child and parent.

<%= form_for @post do |f| %>
<div><%= f.label "Post Content" %>
     <%= f.text_field :content %></div>
<div><%= f.label "Author" %>
     <%= f.text_field :author_name %></div>
<div><%= f.label "Category" %>
     <%= f.text_field :category_name %></div>
     <%= f.submit %>
<% end %>

4) In the child controller, define strong params. This will be the same for the 3rd scenario.

  private

  def post_params
    params.require(:post).permit(
      :content, 
      :category_name, 
      :author_name
    )
  end

5) see Ex.1

A Parent Class Exists, But You Want The Option To Create As Well

1) see Ex.1

2) see Ex.2

3) On the child form page, use text_field for the child attributes, and datalist for the parent.

<%= form_for @post do |f| %>
<div><%= f.label "Post Content" %>
     <%= f.text_field :content %></div>

<div><%= f.label "Author" %>
     <%= f.text_field :author_name, list: "authors_autocomplete" %>
          <datalist id="authors_autocomplete">
               <% Author.all.each do |author| %>
                 <option value="<%= author.name %>">
               <% end %>
          </datalist></div>

<div><%= f.label "Category" %>
     <%= f.text_field :category_name, list: "categories_autocomplete" %>
          <datalist id="categories_autocomplete">
               <% Category.all.each do |category| %>
                 <option value="<%= category.name %>">
               <% end %>
          </datalist></div>

     <%= f.submit %>
<% end %>

4) see Ex.2

5) see Ex.1

Notes to Myself (Rails:Entry#3 - select_tag)

Alexander Rovang — Sat, 06 Nov 2021 21:59:32 +0000

My goal here was to associate a movie review with a particular movie via a dropdown list of movie titles.

This is the movie show page:

<h1>Movies#show</h1>

<div>
<p>Name: <%= @movie.name %></p>
<p>Year: <%= @movie.year %></p>
<p>Genre: <%= @movie.genre %></p>
<p>Director: <%= @movie.director %></p><br>
Reviews:
<% @movie.reviews.each do |review|%>
<p> "<%= review.post %>"</p>
<% end %>
<button><%= link_to "Add a Review!", new_review_path %></button>
</div>

The link_to method has 3 components.

1) the method name "link_to"
2) the element that the user will click on, here the words "Add a Review!" followed by a comma
3) the route path of the link, in this case the "new_review_path" which is the new method in the reviews controller

Once we arrive at the new_review_path we are given this code:

  def new
    @review = Review.new
  end

...which simply sets up the ability of the new.html.erb page to create a new review.

This is the new.html.erb form page:

<h1>Review this movie</h1>

<%= form_for(@review) do |review| %>
<%= select_tag(:name, options_for_select(Movie.all.collect{ |u| [u.name]})) %>
<p>Post: <%= review.text_area :post %></p>
<p><%= review.submit %></p>
<% end %>

I'll gloss over the form_for method since I covered that in a previous blog post, but it is important to note that the select_tag should go inside of the form so that it's parameters can be submitted to the create path.

The select_tag also has 3 components.

1) the method name "select_tag"
2) an argument whose first part is the symbol for the params hash, in this case :name
3) the options_for_select method

The way I've ordered my options_for_select argument is via a class iteration of Movie that returns all of the movies in the database by name.

Once this form is submitted, if you were to inspect the params that is sent to the create method in the Reviews controller, you would see this:

 #<ActionController::Parameters {"authenticity_token"=>"g5hKHV_DHRaR6THLAbvsnXAuaK_ZBIoyQKTVLldgaUxOt0eJ60yXOc1qyQDdqRIuNUAIZ7O-RdCb-zeLynjwdg", "name"=>"Jaws", "review"=>{"post"=>"I can't stand it"}, "commit"=>"Create Review", "controller"=>"reviews", "action"=>"create"} permitted: false>

Here you'll see that a 🔑 of "name" has been set to the movie title "Jaws", as well as the actual review hash params which contains a key of "post" (the name of the review attribute in the database) which is set to the value "I can't stand it"... the actual review.

So we end up with 2 things. A review, and a movie. Both identifiable, and therefore easy to associate in the Review controller's create method.

 def create
    review = Review.new(accept_params)
    movie = Movie.find_by(:name => params[:name])
    review.movie_id = movie.id
    review.save
    redirect_to movie_path(movie.id)
  end

In the create method I

-instantiate a new Review
-find a movie by it's title via the params[:name] key
-set the movie id of that movie to the foreign key of my new review
-save the review
-redirect to the show page of this movie

And there you have it! Only thing to mention: due to strong params in this program, I defined a private method for both my normal form information and my "imported" form info (the movie names/ids).

private

  def accept_params
    params.require(:review).permit(:post)
  end

  def movie_params
    params.require(:movie).permit(:name)
  end

If you fail to do this, the review won't be saved in the database because it won't accept the movie_id.

Binary Search in Ruby ###(part i)

Alexander Rovang — Sat, 06 Nov 2021 21:54:14 +0000

Binary search is one of the simpler algorithms in computer science, and there are certainly many blog posts & YouTube videos to peruse on the subject, but I had some difficulty finding a source that systematically described exactly how Binary search works in Ruby. So I thought I would give it a go.

To implement a search, you need only 2 things: a sorted array, and an item to find. To construct the search, however, you need to establish 5 variables.

the array
the target
the array's left index
the array's right index
the array's midpoint index

For the purposes of this post, we will assume the array and its target to be integers, but strings will work as well and Ruby will take the value of the first letter of each string as its sorting method.

Since the index points rarely defined for us in a search query, we need to create them.

  left = 0
  right = array.length - 1
  mid = array.length/2

Keep in mind that these values are INDICES, not values. Left is the index of the first element in the array, right is the index of the last element, and mid is the halfway point.

The next step is to create a recursive loop that will run until the target is found. Since the process of a Binary Search involves continually redefining the array you are searching, we can call a while loop on the position of the left and right indices as they move closer and closer together.

while left<= right

(if statements here)

end

Next, we need to construct an if statement that will check our target value against the array (or whatever portion of the array the code is examining). We'll check if it's equal to, less than, or greater than the midpoint. Remember that these numbers are actually VALUES, so we need to compare the target - an integer - to the value of an index in the array. That value is found via array[mid].

    if array[mid] == target
      (do something)
    elsif array[mid] < target
      (do something else)
    elsif array[mid] > target
      (do something else)
    end

Should we find the target in the initial statement (where it is equal to array[mid]), fantastic! Depending on your goal, you may return mid (the index), "true", or whatever you like. Once this occurs, the while loop will finish and exit the function. If no target is found, you can likewise choose to return either "false" or -1, etc. after the while loops "end" clause.

If array[mid] does NOT equal the target, the loop will try and find it on the right side of mid (in our example). At this point we need to redefine what "left" and "mid" actually are. Since we are examining ONLY the right side of the array, our new left is mid + 1. And our new mid is left + right (which has not changed) divided by 2.

    elsif array[mid] < target
      left = mid +1
      mid = (left + right)/2

The other option will be the reverse of this equation.

    elsif array[mid] > target
      right = mid -1
      mid = (left + right)/2

And that's it! Here's the full function.

def search(array, target)
  left = 0
  right = array.length - 1
  mid = array.length/2

  while left <= right

    if array[mid] == target
      return mid
    elsif array[mid] < target
      left = mid +1
      mid = (left + right)/2
    elsif array[mid] > target
      right = mid -1
      mid = (left + right)/2
    end

  end
 return -1

end

Part ii of this blog will examine the concept of Big O and how run times are talked about in Algorithm circles. There's a nice blog about this on Medium - https://medium.com/@acodercalledcole/big-o-notation-breakdown-c7e12dc3778, but I'll be tackling it on my own in the near future.

Using React-Redux to create the illusion of has_many

Alexander Rovang — Thu, 17 Jun 2021 20:47:47 +0000

So here was the problem: I had a single deck of cards and I wanted to remember the card(s) I pulled out at any given time, even AFTER putting the card(s) back in the deck.

My original thought was that this was a backend issue. A Draw has_many Cards, and a Card belongs_to a Draw.

class Draw < ApplicationRecord
   has_many :cards
end

class Card < ApplicationRecord
   belongs_to :draw
end

create_table "draws", force: :cascade do |t|
   t.string "card"
end

create_table "cards", force: :cascade do |t|
   t.string "name"
   t.integer "draw_id"
end

But what if I didn't want a single Card to be permanently tied to a Draw? What if I wanted that relationship, but also wanted it to part of other Draws? So I added 'optional' to the relationship.

class Card < ApplicationRecord
   belongs_to :draw, optional:  true
end

Which was closer... but it still made me uncomfortable thinking that the pristine deck of Cards sitting in my database would ever have a relationship with a single Draw. Enter React-Redux.

My thought was that a Draw doesn't need a specific Card, exactly, it needs the ID of a Card. So the first thing I did was change the schema.

create_table "draws", force: :cascade do |t|
   t.integer "card"
end

Then on my frontend I created a method that give me a random number based on the length of an array and convert that number to an index in the array.

getRandomItem = (arr) => {
   const randomIndex = Math.floor(Math.random) * arr.length);
   const item = arr[randomIndex];
   return item.id;
}

The, when submitting my form for a new Draw, I could call on this method and for the argument use the Card Array.

handleSubmit = (e) =>{
   e.preventDefault()
   let formData = {
      card: this.getRandomItem(this.props.cards)
   }
   this.props.createDraws(formData)
}

This populated my Draw instance on the backend with a number that I saved as Draw.card. Then, when rendering a Draw back on the frontend I could just access that number and find the Card associated with it.

const Draw = props =>{
   let draw = props.draws.draws[props.match.params.id - 1]

   return(
      <div>
         Card Name: {draw && (props.cards.length > 0) ? <props.cards[draw.card - 1].name} : null
      </div>
   )
}

And there you have it! A faux has_many relationship built almost entirely on the frontend of my app. Pretty sneaky React. Pretty sneaky.

Notes to Myself (React-Redux: entry#1a - Architecture)

Alexander Rovang — Sat, 05 Jun 2021 18:05:14 +0000

Working with React-Redux for the first time is a little bit like walking into a House of Mirrors. It's very cool, but also very disorienting. My intent in these next few blog posts is to gain a top-level view of this framework to aid in the creation of further React-Redux projects.

The framework consists of 6 distinct parts, and while one could argue how these parts work sequentially, I'm going to propose we mentally organize them like so:

1) Index
2) App
3) Container(s)
4) Component(s)
5) Action(s)
6) Reducer(s)

From a user's perspective, the first 3 of these are responsible for what it actually rendered to the page, and they do so in a nested fashion.

Index

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';
ReactDOM.render(
  <React.StrictMode>
        <App />
  </React.StrictMode>,
  document.getElementById('root')
);

App

import React from 'react';
class App extends React.Component {
  render(){
    return (
        <Container />
    )
  }
}
export default App

Container

import React from 'react'
class Container extends React.Component{
  render(){
      return(
         <MyComponent/>
      )
   }
}
export default Container

The Container (or Containers, depending on the size of your program) has several responsibilities, but its primary function is to group together Components of a similar nature.

Components can be thought of like Partials in Rails. They are pieces of a page that can be lifted out and replaced without damaging the integrity of the base structure.

In another blog I will be writing at length about the relationship between the API's database and what React-Redux calls the Store, but for now suffice it to say that this framework depends on 2 databases. One way to access this information (which are called props) is in the Container via the componentDidMount() function.

import React from 'react'

class Container extends React.Component{
componentDidMount(){
  this.props.fetchTable()
}
    render(){
      return(
        <div>
        </div>
      )
    }
}

export default Container

This function only runs one time, at the beginning of your program, and calls an Action method (more on this later) to gather information from the backend. By adding 2 other functions (connect(), and mapStateToProps()), the Container has access to & is able to send that information to whichever Component needs it. Components also have this ability - accessing the store & passing on Props - which is the beauty of Redux (see: the Dangers of Prop Drilling).

import React from 'react'
import { connect } from 'react-redux'
import { fetchTable } from '../actions/fetchTable'
import { MyComponent } from '../components/MyComponent'

class Container extends React.Component{
componentDidMount(){
  this.props.fetchTable()
}
    render(){
      return(
        <div>
          <MyComponent attributes={this.props.attributes}/>
        </div>
      )
    }
}
const mapStateToProps = (state) =>{
  return {
    table: state.table,
  }
}
export default connect(mapStateToProps, {fetchTable})(Container)

Component

When sending Props to a Component, you have the option of creating a class component (which has the ability to define its own state, thus allowing for possible changes to that state) or a functional component like the one below. Functional components do not render anything, since their primary function is to implement logic on the Props that have been sent to them by the Container.

import React from 'react'

const MyComponent = props =>{
  let myInstance = props.allInstances[props.match.params.id - 1]

    return(
      <div>
          {myInstance ? myInstance.attribute: null}
      </div>
    )
  }
  export default MyComponent

If, on the other hand, you know that your state could change (as in the case of a Form), it is possible to create a Class Component.

import React from 'react'
import { connect } from 'react-redux'
import { createInstances } from '../actions/createInstances'

class InstanceForm extends React.Component{
  state = {
    key: value
  }
  handleSumbit = (e) =>{
    e.preventDefault()
    let formData = {
      value: this.state.value
    }
    this.props.createInstances(formData)
  }  
  handleChange = (e) =>{
    this.setState({
      [e.target.name]: e.target.value
    })
  }
  render() {
    return(
      <div>
        <form onSubmit={e => this.handleSumbit(e)}>
          <input onChange={this.handleChange} 
            name="value" value={this.state.value}>
          <button>Submit</button>
        </form>
      </div>
    )
  }
}

export default connect(null,{createInstances})(InstanceForm)

Class Components are similar to Containers in that they both utilize the connect() function, they both render something to the page, and they both rely on an Action to send information to the backend.

Action

export function fetchInstances(){
  return (dispatch) => {
    fetch('http://127.0.0.1:3000/api/v1/instances')
    .then(r=>r.json())
    .then(instances=> dispatch({
      type: "FETCH_INSTANCES", 
      payload: instances
    }))
  }
}

Action files contain fetch requests. As far as the request itself goes, they are identical to how one would use fetch in Rails. The difference in a React-Redux app is what we do with the converted JSON on the frontend. Through a Redux library called Thunk (which is imported in the index.js file) we have access to a method called dispatch(). Dispatch invokes our final piece - the Reducer - and sends that function the React Store & an Action. The Action is an object which typically has two keys: a type and a payload, which will be discussed in the following section.

Reducer

export default function cardReducer(state = [], action){
  switch(action.type){
    case "FETCH_CARDS":
      return action.payload
    default:
        return state
  }
}

The Reducer, invoked by dispatch(), creates a new State for the React store, using switch statements to determine what new information has been acquired by the fetch request in the Action file. The "type" key in the Action Object becomes the determining factor in the switch statements, and the "payload" key represents the new information. If no new information has been sent it simply returns the original state, but if there is new information it merges that with the current state and sends it back to the app for rendering.

Obviously this is a deeply simplified roadmap, and in the next several blogs we'll be digging more deeply into how all of these pieces are connected by various imports, routes, and the Provider... but hopefully it's a useful reference for your next React-Redux project!

A Rose by any Other Name

Alexander Rovang — Sat, 08 May 2021 17:32:16 +0000

When I first started learning basic HTML, I hated that I had to name everything. "What a waste of time," I thought. "Who cares if it's a < p > or a < div >?," I thought.

Man was I dumb.

Now, as I wade through the swamp of Javascript, I'm dropping < div >s and < p >s like I'm the freakin' Johnny Appleseed of HTML! And to date, my all-time favorite drop has to do with...

classList.toggle

"classList" itself is already pretty fascinating. According to MDN Web Docs,

"The Element.classList is a read-only property that returns a live DOMTokenList collection of the class attributes of the element. This can then be used to manipulate the class list."

In OTHER words: calling classList on an element gives you access to 12 awesome methods that you can use to play around with the classes of that element.

Looking at the DOMTokenList proto, you'll see: add; contains; entries; forEach; itemkeys; remove; replace; supports; toString; toggle(!!!!), &values.

A little background. My project deals with the concept of a Mind Palace (also known as the "method of loci"). It's basically a memory technique that uses familiar spaces to attach lists of thing you want to remember.

Pick a place you know well, like your apartment/house. Mentally create a path from one end of the house to the other, and along the way, write down objects or spaces that don't change. These are known as Loci. In my case I would choose something like:

1) doorknob, 2) coatrack, 3) bookshelf, 4) mirror, 5) couch,
6) table, 7) window, 8) painting, 9) guitar, 10) lamp

Then, when you have a list you'd like to remember (like my 1000 nieces/nephews) you assign each of them to a Loci.

1) doorknob -Haley
2) coatrack -Derek
3) bookshelf -Torrie
4) mirror -Pepper
5) couch -Maya
6) table -Dillon
7) window -Julianna
8) painting -Jessa
9) guitar -Jarod
10) lamp -Leonora

"WHAT DOES THIS HAVE TO DO WITH CLASSLIST???"

I'm getting there, I swear.
So, my app needed 2 things. A word representation of both the Loci/their list items. And a visual view of the Palace.

I choose an aerial view of an apartment where the walls were black and the rooms/hallways were grey. The black room I created like this.

function loadRoom(){
  const rc = document.getElementById("RightContainer")

  for(let j=0; j< 20; j++){
    const tr = document.createElement("tr")

    tr.innerHTML = ""
    rc.append(tr)
    for(let i = 0; i < 20; i++){
      const td = document.createElement("td")
      td.setAttribute("class", "block firstColor")
      td.setAttribute("onclick", "changeColor(this)")
      td.innerHTML = ""
      tr.append(td)
    }
   }
  }

Using a nested for loop allowed me to create a black box where each table data had a class of "block", a class of "firstColor", and an eventlistener that triggered the function changeColor(tdObj).

function changeColor(tdObj){
  tdObj.classList.toggle("secondColor")
}

changeColor(tdObj) takes in an argument of an element (in this case a table data object) & calls classList and toggle on it. toggle CHANGES the name of the class ("firstColor") to another name ("secondColor").

In my CSS file, they look like this:

.firstColor{
  background-color: black;
}
.secondColor{
  background-color: grey;
}

And BOOM! Black goes to grey, or grey goes to black whenever you click on a small square of table data - allowing you to 'draw' an aerial view of your house that you can start attaching Loci to.

I know for experienced coders this probably seems small & funny, but it seriously blew my mind. :)

Rails Project: A 12-step Guide

Alexander Rovang — Fri, 02 Apr 2021 22:31:49 +0000

Organization, organization, organization.

The deeper I get into programming the more I envy my father-in-law's ability to pack his car for summer camping trips.

It's impossible (particularly given the 4-week timeframe we had) to even begin to scratch the surface of the Rails 190,000 line Framework ... but what we were able to do is start to see the elegance of it's organizational capacities. The real challenge, though, is in structuring how we CREATE the project in the first place. So, in true "Notes to Myself" fashion, that's what I'd like to focus on in this blog post.

Step One: Create your App

Pretty basic.

rails new app-name

Rails convention is to hyphenate multi-word names. After everything is loaded you can add whatever you like to your Gemfile (gem 'pry', gem 'bcrypt') and then bundle.

bundle install

Step Two: GIT!

The number of times I forget to do this... woof! Crazy important, though. Create a new repository and commit constantly. A couple of tips:

a) Don't worry about adding a README, gitignore, or license. The first two are generated when you created the Rails app, and the last one you can do later.
b) You are creating a new repository (not pushing).
c) Skip "echo # asdf".
d) Do "git add ." instead of "git add README.md".

Also remember how to commit.

git add .
git commit -m 'some pithy comment'
git push

Step Three: Create Models

I like to use the model generator here. The great thing about it is that it creates your migrations for you.

rails g model model_name model_attribute:attribute_type --no-test-framework

The syntax here: rails, g (for "generate"), model, the name of the model, and then each attribute you would like in that model. You can add as many attributes here as you like (name, email, gender), just make sure that each one is followed by a colon and it's corresponding type (integer, string, text). Rails will automatically create tests when you use the generate method, so if you don't want them, add "--no-test-framework" to the end of each command.

Step Four: Migrate

Just because Rails gave you some beautiful migrations doesn't mean you have anything going on in the database!

rake db:migrate

Step Five: Create Controllers

Again, I really like to use Rails to generate my controllers because they will automatically give you some empty actions, routes and corresponding views.

rails g controller users index show create --no-test-framework

The syntax here: rails, g (for "generate"), controller, the name of the controller, and then each action you would like in that controller. It's pretty awesome.

Step Six: Fix or Create Routes

As I mentioned, Rails will create routes for you when you use the controller generator, but they're pretty messy. Each route is written individually instead of using resources, and if you want anything custom you'll have to do it yourself anyway. So, I recommend jumping into your config/routes.rb file and doing some cleaning.

resources :users, only: [:index, :show, :create]

The syntax here: resources, the name of the controller. If that's all you put, you'll get the full 7 RESTful routes, but you can also specify "only" or "except" to limit which routes are added.

Step Seven: Model Associations & Validations

Before you can start any real work on your controller or views, you need to set up your associations (has_many, belongs_to), and while you're there you might as well start getting some validations together.

class User < ApplicationRecord
  include ActiveModel::Validations
  has_secure_password

  validates_presence_of :username, :email
  validates_uniqueness_of :username, :email

  has_many :instruments
  has_many :makers, through: :instruments
end

has_secure_password belongs to the Bcrypt gem, so be sure to add that to your Gemfile if you haven't already and create a migration for your users table that adds a column for 'password_digest'.

class AddColumnToUser < ActiveRecord::Migration[6.1]
  def change
    add_column :users, :password_digest, :string
  end
end

Step Eight: Controller Basics

This next step is a matter of preference. Because a lot of the controller actions are the same or VERY similar between models, I like to do some of the simple logic that I know they all could use. Instance variables, strong params. That sort of thing. These can be adjusted later, but if I have several controllers with identical actions I'll fill one of them in, copy it, paste it into the other controllers and simply change the model name.

class UsersController < ApplicationController
before_action :set_user, only: [:show, :edit, :update, :destroy]

  def index
    @users = User.all
  end

  def new
    @user = User.new
  end 

  def create 
    @user = User.new(user_params)
  end

  def show
  end

  def edit
  end

  def update
  end

  def destroy
  end

  private

  def set_user
    @user = User.find_by(id: params[:id])
  end

  def user_params
    params.require(:user).permit(:username)
  end
end

Step Nine: Forms & Partials

Now that all of the pieces are in place, it's time to set up our forms. And because the "new" and "edit" forms are often identical, it's worth creating a partial or two to save yourself from some unnecessary code. I have a few other blog posts I'm writing that cover forms in Rails, so I'm not going to go too deeply into that here, but I will copy a fairly comprehensive form page that I have in my project.


<%= form_for @instrument do |form| %>

<div><%= form.label "Type"%></div>
  <%= form.collection_select :category_id, banjo_categories, :id, :name %>

<div><%= form.label "Maker" %></div>
<%= form.text_field :maker_name, list: "makers_autocomplete" %>
<datalist id="makers_autocomplete">
<% Maker.all.each do |maker| %>
<option value="<%= maker.name %>">
<% end %>
</datalist> 

<div><%= form.label "Price"%></div>  
<%= form.number_field :price%>
<div><%= form.label "Year"%></div>
<%= form.number_field :year%>
<div><%= form.label "Description"%></div>
  <%= form.text_area :description%>

<div><%= form.submit "Add Instrument"%></div> 
<% end %>

This page utilizes 3 types of input: collection_select, datalist, and the normal input for a form_for page. Most of this (excluding the opening and closing tags) can be encapsulated in a partial. Partials are named beginning with an underscore and then followed by the name of the view folder they're in.

_instruments.html.erb

The repetitive information is put into this file and then the view file has a render method that essentially yields to the partial.

<%= render partial: "instruments", locals: { form: form, family: @family, instrument: @instrument } %>

The syntax here: "render partial:", the name of the partial, "locals:" and then a hash with key/value pairs linking established variables from the controller to local variables in the partial.

Step Ten: Controller Logic

This is the big one. Get into a comfy chair. Lock the door. Put the 6-pack of Dr.Pepper next to you and get to work. If 20% of your time is spent setting everything up, and another 20% is cleaning up/refactoring, then 60% will be figuring out how everything actually needs to work. I also have some blog posts dedicated to routes and what I call the "Client's Journey", but the pattern I feel I use for every Controller action is this:

-What's coming in?
-What would you like to do here?
-Where is it going after?

The first question is a params issue. Whether it's coming from the database, a form, or just a GET query ... there always seems to be useful information right at the top of any action. The second piece is how you want to manipulate that data. Most of the time that question is answered for you by which action you're in. I'm in the index? I must want to show some information, so I probably need an instance variable. I'm in the update action? I need to connect with the database and use what's coming in to alter it. And finally, where do you want to redirect the user to after? This tends to be the most malleable of the decisions. Some of them are fairly obvious (edit will go to the edit view), but others are a matter of choice. When you finish updating a User's info you could go to their page, but you could also go to a homepage, or really anywhere you want to take them. It can get a little overwhelming when you start to add in validations and protections against bad data, but sticking with those 3 steps will get you pretty far!

Step Eleven: Helper Methods

There are several types of helper methods. Some go in the model, some in the controller, and some in the helpers folder (which are specific to views). But at the end of the day, helper methods are simply ways to clean up your code so that looking at your controller doesn't feel like you're seeing the Matrix for the first time.

View helpers keep SQL queries out of of your actual view pages. This helper is in my instruments helper folder and is accessed in my instruments "new" page.

  def banjo_categories
    Category.where(id: [1...5])
  end

This is a scope method helper that I have in my Maker class which is accessed in the index of my Makers Controller.

scope :search, ->(name) { where("name LIKE ?", name) }

And then, of course, you have regular helper methods like this one in my Instrument Controller to help alleviate repetition.

  def set_instrument
    @instrument = Instrument.find_by(id: params[:id])
  end

There's also a helper_method that you can use to expose Controller methods to your views. Apparently it's not ideal, but it is useful in certain situations such as accessing a current users params.

class ApplicationController < ActionController::Base
  helper_method :current_user

  def current_user
    @current_user = User.find_by(id: session[:user_id])
  end

  def require_login
    redirect_to "/login" if !current_user
  end
end

Step Twelve: Error Messages

Last but not least! Well, it is actually kind of least. But still important because it has to do with user experience. Most of these steps were either to get an app up and running or to clean up an app so that 10yrs down the line you (or another coder) can look at it and easily understand what's going on and fix things quickly and efficiently. Error Messages are our way of guiding the user through our program. It took me awhile to grasp the concept of an error being an object, but there it is. And as with all other objects, errors have attributes that we can call upon and display. This is a pretty common error syntax.

 <% if instrument.errors.any? %>
  <div id="error_explanation">
    <h2>Oops!  We noticed  
      <%= pluralize(instrument.errors.count, "error") %>
      when trying to process your information.
    </h2>
    <ul>
    <% instrument.errors.full_messages.each do |msg| %>
      <li><%= msg %></li>
    <% end %>
    </ul>
  </div>
<% end %>

The first line checks to see if our instrument object had any errors. If it did, there will be a hash containing messages about those errors. In the h2 we count the number of errors committed, and in the ul we display each of them with the full_messages method.

I wish I could say "And that's it!". Hahaha Remember: 190,000 lines of code. We haven't even scratched the surface. But these 12 steps will hopefully help guide you (and me!) through our next Rails adventure with a little less sweat than the first one.

Peace

Notes to Myself (Rails:Entry#1b - Routes)

Alexander Rovang — Sun, 21 Feb 2021 23:41:48 +0000

Picking up where I left off, the other option for a Client is to change something on a page. There are 3 possible routes for such an action: New, Edit, and Delete.

New & Edit are similar in several ways. Each begins with a GET request that takes the Client to a Form page, and once the Form is submitted, each has a corresponding POST request that takes them back to the Controller to be executed. This connection between the GET route & POST route is fundamental to understanding the Client's Journey, and worth highlighting.

Let's start with the New route.

 "The NEW route (GET) passes through a Form page & continues on to a CREATE route (POST)."

1) config/routes.rb
2) app/controllers/movies_controller.rb
3) app/views/movie/new.html.erb
4) app/controllers/movies_controller.rb
5) app/views/movie/1

As per our "See" requests, the Journey begins in routes.rb where the resources method sends our Client to the /movies/new path in the Controller.

 def new
    @movie = Movie.new
  end

Once there we instantiate a new Movie and set it to an instance variable. One interesting sidenote: Unlike our respective "See" pages, this instance variable needs to exist for the Form page to be created, but it does not actually create/save a new Movie. That happens later in the POST route when we instantiate a new Movie with the params from this Form.

The program again implicitly renders the new.html.erb page from within the appropriate views sub-folder.

<h1>New Movie Form</h1>
<%= form_for(@movie) do |movie| %>

<p>Name: <%= movie.text_field :name %></p>

<p>Year: <%= movie.text_field :year %></p>

<p>Genre: <%= movie.text_field :genre %></p>

<p>Director: <%= movie.text_field :director %></p>

<p><%= movie.submit %></p>
<% end %>

Once this form is submitted, the information is stored in the params hash and sent to the Create route.

  def create
    movie = Movie.new(accept_params)
    movie.save
    redirect_to movie_path(movie)
  end

In this method the params are vetted via a private method called "accept_params" that protects against malicious use, the movie is saved to the database, and we are redirected to a different route that contains a view (here the movie "show" page).

The second option for "Change" in the Client's Journey is the Edit route which is matched to the Update route.

 "The EDIT route (GET) passes through a Form page & continues on to a UPDATE route (PATCH)."

1) config/routes.rb
2) app/controllers/movies_controller.rb
3) app/views/movie/edit.html.erb
4) app/controllers/movies_controller.rb
5) app/views/movie/1

As before with our "See" routes (index & show), this sequence is virtually identical to it's sister route (new). In this case our resources method sends our Client to the /movies/:id/edit path in the Controller.

  def edit
    @movie = Movie.find(params[:id])
  end

Once this instance variable has been set we are directed to the appropriate view, edit.html.erb.

<h1>Edit Movie Form</h1>
<%= form_for(@movie) do |movie| %>

<p>Name: <%= movie.text_field :name %></p>

<p>Year: <%= movie.text_field :year %></p>

<p>Genre: <%= movie.text_field :genre %></p>

<p>Director: <%= movie.text_field :director %></p>

<p><%= movie.submit %></p>
<% end %>

After submission, it goes back to the controller as a PATCH request to the Update method...

  def update
    movie = Movie.update(accept_params)
    redirect_to movie_path(movie)
  end

... and redirected back to it's show page.

The only other option left for the user is to Delete an entry, but this is a slightly unique route in that conventionally there is no "delete" page to view. More often than not the Delete method is accessed via a link (on the Edit Form page or the Show page). Once activated, however, it follows a very simple path.

1) config/routes.rb
2) app/controllers/movies_controller.rb
3) app/views/movies

The routes file sends a request to the controller...

  def delete
    movie = Movie.find(params[:id])
    movie.destroy
    redirect_to movies_path
  end

... the movie is deleted and the Client is redirected to a page (in this case the index).

Notes to Myself (Rails:Entry#1a - Routes)

Alexander Rovang — Sun, 21 Feb 2021 23:41:35 +0000

I think the first major step in understanding the Rails framework is to break down how Routes, Controllers, Route Helpers, and Views all interact with one another.

Up till now we've spent quite a bit of time contemplating C.R.U.D. functionality ("Create", "Read", "Update", "Delete") and the 7 RESTful routes (index, new, create, show, edit, update, delete).

I'd like to reorganize these concepts into a flowchart I'm calling the "Client's Journey" which will trace the steps a program must take to render one of the 4 possible views a user could see.

The first split-point of the Journey could be phrased this way -

 "Do I want to see something, or do I want to change something?"

Beginning with the path of "seeing" there are two primary routes available. 1) You can see many things, or 2) you can see a single thing. Choosing to "see" a grouping of many similar things is the simplest route available in Rails. When the Client types a URL into their browser, three things happen:

1) config/routes.rb
2) app/controllers/movies_controller.rb
3) app/views/movie/index.html.erb

The Client's Journey begins in the routes.rb file, where the program checks for the availability of the URL path. If the routes.rb file has been set up with a "resources" method...

Rails.application.routes.draw do
  resources :movies
end

...then the Client will be redirected to the appropriate controller with a GET request in the index method. Resources, in its unfiltered form, produces all seven of the RESTful routes for whatever controller you have specified. It can also be configured (via only: or except:) to limit which routes are available.

class MoviesController < ApplicationController
  def index
    @movies = Movie.all
  end
end

In Rails, the index method implicitly calls the index.html.erb view from the sub-folder in views that has the same name as the model (in this case, "movie"). Note that both the model and the view sub-folder are the singular form of the controller class name. Typically the only information needed in the index method is an instance variable that stores all instances of a particular class, which can then be accessed in the view.

Once there, it renders any information the programmer has allowed to be seen.

<h1>Movies#index</h1>
<p><% @movies.each do |movie|%></p>
<div class="box">
<p>Name: <%= movie.name %></p>
<p>Year: <%= movie.year %></p>
<p>Genre: <%= movie.genre %></p>
<p>Director: <%= movie.director %></p>
</div>
<% end %>

The other path out of the "seeing" option is to see a single thing. This is called the "show" method in the controller, and has a similarly named view file. The Client's Journey to the show.html.view file would look like this:

1) config/routes.rb
2) app/controllers/movies_controller.rb
3) app/views/movie/show.html.erb

As you can see, it's identical to the index method in terms of sequence.

The change occurs in the controller where instead of the index method, the Client is directed to the show method.

  def show
    @movie = Movie.find(params[:id])
  end

Again, an instance variable needs to be set in order to access information on the view page, but here we only gather information about a single object via it's id.

From there we are implicitly guided to the appropriate view, show.html.erb...

<h1>Movies#show</h1>

<div>
<p>Name: <%= @movie.name %></p>
<p>Year: <%= @movie.year %></p>
<p>Genre: <%= @movie.genre %></p>
<p>Director: <%= @movie.director %></p>
</div>

..which really only differs from the index view by lack of an iteration method.

In the next post I'll address the other side of the Client's Journey: The "change".

Sinatra Project for Flatiron

Alexander Rovang — Wed, 10 Feb 2021 19:34:42 +0000

Oh, Frankie. Still light as a feather.

After 2 months of the mental gymnastics that always seem to accompany a new skill, we FINALLY got to work on something that has the look of a real live website!

It's nothing fancy, but it WORKS. And that is pretty amazing.

My project was for Art Collectors. The intention was to have a place where a Collector could store information about their collection and browse through the names of artists and artworks that were in other people's collections as well (although with a more limited scope).

From a technical aspect, this project seemed fairly straightforward at the beginning. Create your ActiveRecord Migrations, set up the associations in your Models, map out the various CRUD routes in your controllers, and then add a little bit of CSS magic to doll the whole thing up.

For me, where it started getting interesting was when I began thinking about what I as a USER would want from the website. As I began to wander around the localhost:9393, I kept finding myself thinking "Hm. I wish I could edit something on this page." And then I would go back into the code and see how that desire could be achieved. It was crazy to see how many different parts of the code needed to be addressed by a single change on the website. And a good reminder that as interesting as coding is, the user experience is really the focus of this work.

A good example of this was when I tried to delete an Artist for the first time. Getting rid of the artist was easy, but suddenly there were artworks with no owner! Solved this via a block that also deleted artworks when their owner was gone.

  delete '/artists/:id/delete' do #destroy
    if !logged_in?
      redirect '/login'
    else
      artist = Artist.find_by_id(params[:id])

      if artist.collector == current_user
        art = artist.artworks 
        art.each do |work|
          work.delete
        end
        artist.delete
        redirect to "/artists"
      else
        redirect to "/artworks/error"
      end
    end
  end

Another thing I found fascinating was the amount of work it took to validate a user. I have a suspicion that as we learn more at Flatiron there are going to be methods & filters that will make this process a lot simpler, but under the hood it's a lot of work! This is a snippet of my validation for a user to have a unique name and email:

post '/collectors' do

    if params[:name] == "" || params[:email] == "" || params[:password] == ""
      redirect "/signup"
    else
        if Collector.find_by(name: params[:name]) || Collector.find_by(email: params[:email])
          redirect "/signup"
        else
          @collector = Collector.new
          @collector.name = params[:name]
          @collector.email = params[:email]
          @collector.password = params[:password]
          if @collector.save
            redirect '/login'
          else
            erb :"/collectors/new"
          end
        end
      end

First I had to check to ensure that they'd filled in all the fields, THEN I had to check the Collector class to see if the email or username that the person signing up had entered (via params[:name] and params[:email]) was already in use... THEN create a new collector with all the params and save it to the database!

Ruby, you and Sinatra make a lovely couple, but from now on we're splitting the bill. :)

CLI Project (or "What Santa left under the Flatiron tree.")

Alexander Rovang — Fri, 08 Jan 2021 22:56:48 +0000

Whew! That was VERY cool.

Just finished my first CLI project for Flatiron. SO satisfying to be able to use everything we've learned in the past few weeks on a single app!

I guess I'll walk you through some highlights?

We had a choice between scraping and working with an API. I know that in the future I'll probably have more work that involves API's, but I really wanted to figure out the whole Nokogiri business. So I picked a project that I could actually use: a NJ hike finder. My wife's family lives out in NJ and have an extremely energetic Doberman named Bellatrix. Hike's are GOLD to that dog. And to that wife, come to think of it.

I found a great website (or so I thought...) called "NJHiking.com". A couple hundred hikes, lots of information. I was ready to roll.

The first thing I wanted to do was find out how far any of these hikes were from my in-laws house. A little research led me to an awesome Gem called Geocoder which, among other things, can take any two sets of coordinates and calculate the distance between them. But there were issues with the website I was scraping. Many, many issues.

Problem #1 - NOTHING was labeled! Virtually no classes, no ID's. Nothing. Just a bunch of h3's, href's, and p's. But I was determined! The first set of coordinates were hidden in an href:

N40.88787° W74.81405°

Naturally there were other href's on the page, but none in which the SECOND char of .text was a number. Thus my first bit of search code:

results1.each do |r|
  if r.text[1] != nil && r.text[1].match(/\d/)
    @new_hike.coordinates = r.text
  end
end

First problem solved! Sort of.

Problem #2 - Geocoder doesn't like this format: N40.88787° W74.81405°. It likes THIS format: ["40.88787, -74.81405"]. Which is a hassle. I needed to get rid of the N, get rid of the W, get rid of the degrees, convert the second number to a negative, AND put them in an array. Which I did like so:

one = location[0].scan(/\d{2}[.]\d{5}/)
two = location[1].scan(/\d{2}[.]\d{5}/)
two_minus = (two.join.to_f * -1).to_s.split
final_location = [one, two_minus].join(" ").split

And then...

Problem #3 - This was the worst. Unfortunately, the coordinates for all of these hikes were on each hikes PERSONAL page. Which meant that looking at the first page (where all the hikes were listed) was useless for anything except knowing what the hike was called. At first I tried a sort of "double" scrape where I got all of the hike names and their coordinates and put them into an array of hashes. Then I used Geocoder to see which of those hash values (the coordinates) were within a 50mile radius of my in-laws. Totally worked, BUT...it took forever. Nokogiri had to scrape the original page for the first website, then go to that website, scrape that page, then go BACK and do it all over again. 200 times. The first time I ran it I thought there was an open loop somewhere in my code because it took so long to finish.

Eventually I just scrapped the idea of figuring out the distance prior to picking the hike.

After that it was pretty smooth sailing! The lack of labeling was super annoying, and relegated my choices of hike attributes to some pretty simple things: the length of the hike, it's website, and whether it had a restroom or not. But in the end I was pretty happy with the turnout.

The real prize in the cereal box, though, was how it all fit together. Seeing the separation of classes. Calling instance methods of one class inside another class. It was like watching a game of Jenga in reverse. I know for you coders out there that have been doing it for years it must seem pretty boring, but me?

I was jazzed as hell. :)