DEV Community: cole-flournoy

What Do I Need To Know About React Native Coming From React JS?

cole-flournoy — Thu, 24 Jun 2021 22:57:18 +0000

This post is for the people who are interested in React Native because they have experience with React JS. People who know that being able to develop for mobile and web helps their job prospects but who also want to know how easy it's going to be before they sink in too much time wading through the documentation (which is actually really good, you should check it out).

Getting Started

Getting React Native set up is incredibly easy, so definitely don't let that stop you. In less than five minutes you can be building out an app that you can see displayed on your own phone.

We'll be using Expo CLI to get rolling quickly (more on the differences between the two here and the limitations of using Expo here). As long as you're on Node 12+, you can install using npm, and create a new project.

npm install -g expo-cli

expo init MyFirstProject
cd MyFirstProject
npm start

For your most basic setup, that's really it. You're ready at this point to start developing your app (after you read the rest of this post so you know the basic differences between React JS and React Native).

Display Options

Running npm start (or expo start) works just like with React JS, except the browser window that opens gives you some options for how to render your project.

You'll see these menu options

As well as a QR code

Quickest but least fun option: Run in web browser
This is exactly the same as React JS. A new tab will open and display the welcome message from App.js or whatever you choose to render. Saving automatically updates the code in the browser.
Still pretty quick, definitely really fun option: QR code
If you download the Expo Go app on your mobile device, you can use the QR code scanner in the app (as long as the two devices are on the same network) to display your project on your phone. Once you've scanned it, the app will remember that project so you can go back to it in the future. Honestly, this is my favorite option
Slower setup but probably most practical option: iOS/Android Simulator
The novelty of having it on your own phone is really cool, but for long-term development, looking down at your phone just isn't as efficient as having a simulator/emulator up on the screen right next to your code. To make that happen though you'll need Xcode and Android Studio, which can take a significant amount of time to install and configure for the first time.

Pick the option that's right for your goals, and let's get to the important bit: Is this just React JS with a couple new twists, or do I have to learn a whole new syntax?

What's Different In React Native?

This is by no means a complete list, but the following are four big differences from React JS that we need to address to get comfortable quickly in React Native. Once you're starting to branch out from the basics, if you need something, there's probably a component for it here.

No HTML syntax

This is how a basic Welcome component might look in React JS

function Welcome(){
  return(
    <div>
      <h1>Welcome to my React App!</h1>
      <h3>Log in below</h4>
      <UserLoginForm />
    </div>
  )
}

Now, I know that everything here that looks like HTML is actually JSX, but the point is that this JSX is trying really hard to match the syntax of HTML. React Native still uses JSX, but none of the HTML-like components are permitted.

This makes sense since we're no longer developing for the web, but it can still be a bit of an adjustment. To recreate the above function in React Native, we'll have to use some of its core components.

Note: All of the following components need to be imported by name in order to be used. Don't forget your imports!

Div Becomes View / ScrollView

The simple React Native equivalent for a <div> tag is a <View> component. They behave almost exactly the same (in terms of nesting, styling, etc.), and for our example, switching out the <div> is pretty quick and painless.

import {View} from 'react-native'

function Welcome(){
  return(
    <View>
      <h1>Welcome to my React App!</h1>
      <h3>Log in below</h4>
      <UserLoginForm />
    </View>
  )
}

One distinction here is that Views are not scrollable, so if we wanted all, or part, of this Welcome component to be scrollable, we would have to wrap that part of the component in a <ScrollView> or replace the <View> altogether.

Note: ScrollViews must have a bounded height to function properly. More on that here

The Text Component

We've fixed our <div> error, now what do we do about these <h1> and <h3> tags? Enter <Text>: the simple solution to basically everything text in React Native. The closest straight comparison for <Text> would be a <p> tag.

import {View, Text} from 'react-native'

function Welcome(){
  return(
    <View>
      <Text>Welcome to my React App!</Text>
      <Text>Log in below</Text>
      <UserLoginForm />
    </View>
  )
}

No more errors! At least, no errors assuming I have a UserLoginForm component written elsewhere and properly imported/exported. But you've probably noticed a small problem. In our original Welcome, we had two different header sizes, but now we just have two identical text components. That's because there is no separate header text component in React Native. We have to add one little extra step and style them ourselves.

The StyleSheet Component

Just like there's no HTML in React Native, there's also no CSS. But don't worry, the StyleSheet component is so similar you'll hardly even notice the difference. Inline styles are still an option:

import {View, Text} from 'react-native'

function Welcome(){
  return(
    <View>
      <Text style={{fontSize: 40}}>Welcome to my React App!</Text>
      <Text style={{fontSize: 20}}>Log in below</Text>
      <UserLoginForm />
    </View>
  )
}

But the most common way you'll see styling is by creating an object under the constant styles with keys for the appropriate elements.

import {View, Text, StyleSheet} from 'react-native' // NEW IMPORT

const styles = StyleSheet.create({
  title: {
    fontSize: 40
  },
  subTitle: {
    fontSize: 20
  }
})

function Welcome(){
  return(
    <View>
      <Text style={styles.title}>Welcome to my React App!</Text>
      <Text style={styles.subTitle}>Log in below</Text>
      <UserLoginForm />
    </View>
  )
}

So there we go, we've fixed all of our errors and matched the same code we started with in React JS (although the font size numbers may not precisely match an <h1> and an <h3>). The docs do a great job with explaining more about styling, so I won't go deeper into that here.

Note: One easy-to-overlook difference in React Native is that there are no units (such as 'px') on the stylesheet numbers.

What's The Same In React Native?

The short answer: a lot! Obviously there are different challenges that arise and need to be addressed building native applications, especially as the projects get more complex, but the good news is that the fundamentals are the same.

I won't go through and list every single thing that's the same (the differences tend to be a lot more significant anyways), but there are a couple fundamental things I think React JS developers will be relieved to discover they already know how to do in React Native without even trying.

Building out components has to be the biggest, because components are the heart of React and significant changes to how they're structured or used in React Native would be a big pain. Not that anyone was expecting a major difference here (they're obviously made by the same people and made to work together), but that's the kind of thing that makes deciding to learn a lot less intimidating.

Can I still build class components? Yes.
Functional components? Yes.
Local state and props? Exactly the same.
Hooks? Of course.
Event handling? Slightly different syntax but works the same.
Fetch requests? The same.
What if I want to use Async/Await? Feel free!

You get the point. You already know way more React Native than you thought you did!

There are a ton of great tutorials out there if you don't have a specific idea for a project to try things out, so if you're coming from a React JS background and thinking about React Native, there's no reason not to give it a shot. The setup is super easy, and it's a lot of fun even just to play around with.

Breaking Down Javascript Sort() And Sorting By Multiple Criteria

cole-flournoy — Mon, 07 Jun 2021 21:20:21 +0000

First off, let's take a look at the Array.sort() method and see how it works. sort() takes in a callback function with two arguments and iterates over the array, using those two arguments as placeholders for each element and the element after it. Then, in the body of the callback function, it makes a comparison between the two, moving the element forward or backward in the array according to the logic of that comparison.

Yikes, that sounds way more complicated in English... How about we just look at some code. Here's a prototype:

Array.sort(function(currentElement, nextElement) {
    return <sortingLogic> 
    // e.g. currentElement - nextElement returns numerical Array in ascending order
}

// OR with ES6 arrow function (preferable)
Array.sort((currentElement, nextElement) => <sortingLogic>)

It compares Array[0] to Array[1], moves Array[1] forward or backward according to the logic of your condition, then starts over, comparing Array[1] to Array[2], and so on.

Note: You'll commonly see currentElement and nextElement referred to as a and b respectively in most documentation, so that's what I'll be using. But you're declaring the function, so call it whatever you want.

By default, sort() assumes ascending order, and for simple arrays of strings you have the option to call it without any callback function.

const myBestFriends = ["Tom", "Jerry", "Popeye", "Brutus"]
myBestFriends.sort()
// => ["Brutus", "Jerry", "Popeye", "Tom"]

Nice, much better in alphabetical order. Same should go for numbers, right?

const luckyNumbers = [7, 64, 16, 44]
luckyNumbers.sort()
// => [16, 44, 64, 7]

Ok, well that doesn't look right. Turns out, sort() by default compares array elements by turning them into strings and comparing their sequences of UTF-16 code units values. What that means exactly is outside the scope of this article, but what you need to know is this:

If you are sorting numbers in Javascript, always pass a callback function! 7 < 64 returns true but "7" < "64" returns false

Fortunately, we can still get the desired result from another one-liner:

const luckyNumbers = [7, 64, 16, 44]
luckyNumbers.sort((a, b) => a - b) // ascending
// => [7, 16, 44, 64]
 ---
const luckyNumbers = [7, 64, 16, 44]
luckyNumbers.sort((a, b) => b - a) // descending
// => [64, 44, 16, 7]

Note: sort() is a destructive method, meaning that the original array itself is being replaced with the sorted version. If you need to continue to use your original array, make sure to save the sorted array in a new variable - e.g. let sortedNums = luckyNumbers.sort((a, b) => a - b)

The last thing to cover before sorting by multiple criteria is what the default sort method is doing behind the scenes when we call something like myBestFriends.sort(). These two are equivalent:

const myBestFriends = ["Tom", "Jerry", "Popeye", "Brutus"]
myBestFriends.sort()
// => ["Brutus", "Jerry", "Popeye", "Tom"] 

const myBestFriends = ["Tom", "Jerry", "Popeye", "Brutus"]
myBestFriends.sort((a, b) => a > b ? 1 : -1)
// => ["Brutus", "Jerry", "Popeye", "Tom"]

And in case the ternary operator is throwing you off, these are also equivalent:

const myBestFriends = ["Tom", "Jerry", "Popeye", "Brutus"]
myBestFriends.sort((a, b) => a > b ? 1 : -1)
// => ["Brutus", "Jerry", "Popeye", "Tom"]

const myBestFriends = ["Tom", "Jerry", "Popeye", "Brutus"]
myBestFriends.sort((a, b) => {
    if (a > b){
        return 1
    } else{
        return -1
    }
// => ["Brutus", "Jerry", "Popeye", "Tom"]

We return 1 if the element needs to be moved up the array, -1 if it needs to move down, and don't do anything if the elements are the same (they stay where they are).

Multiple Criteria

So now that we understand how it works with simple arrays, we can easily extend that out to more complex structures. All we have to do is combine the pieces above in whatever way fits our use case. For example, in a win / loss column:

const teams = [
    {name: "Bruins", wins: 32, losses: 20},
    {name: "Islanders", wins: 32, losses: 18},
    {name: "Capitals", wins: 33, losses: 19},
    {name: "Penguins", wins: 33, losses: 13}
]
teams.sort((a, b) => a.wins === b.wins ? a.losses - b.losses : b.wins - a.wins)

// => [{name: "Penguins", wins: 33, losses: 13}, 
//     {name: "Capitals", wins: 33, losses: 19},
//     {name: "Islanders", wins: 32, losses: 18},
//     {name: "Bruins", wins: 32, losses: 20}]

We're prioritizing wins over losses in descending order (more wins on top makes the most sense) as our default, but if the two teams have the same number of wins, we're then sorting losses in ascending order.

Or say we have a list of our favorite Steves:

const steves = [
    {first: "Steve", last: "Harvey"},
    {first: "Steven", last: "Spielberg"},
    {first: "Stephen", last: "Colbert"},
    {first: "Steve", last: "Carell"}
]
steves.sort( (a, b) => {
    if (a.first > b.first){return 1}
    if (a.first < b.first){return -1}
    if (a.last > b.last){return 1}
    if (a.last < b.last){return -1}
})

// => [{first: "Stephen", last: "Colbert"},
//     {first: "Steve", last: "Carell"},
//     {first: "Steve", last: "Harvey"},
//     {first: "Steven", last: "Spielberg"}]

This one looks a little weirder with all the if statements, but we don't actually ever have to check whether the values for our primary criterion -first- are the same (as we did in the previous example). If they are, the first two if statements will be ignored.

You can see how through this process we could continue to add on additional criteria to sort in whatever quantity and order we wish with more and more conditional statements. Hopefully this has helped demystify sort() and how to use it.

A Beginner's Guide to Dealing With Classes and Object Relationships in Javascript

cole-flournoy — Tue, 11 May 2021 11:50:10 +0000

Today I wanted to take a look at creating Javascript class instances and recreating the class relationships from the backend (database, models, etc.) on the frontend (Javascript in our case). I'm a student, so I'm still learning the ins and outs of Javascript, and what's worse I'm coming to it from Ruby. Don't get me wrong, I've been super excited to get to JS the whole time. It's such a big part of how we experience the internet (and it's got all the fun flashy stuff), but there's just something about the simplicity and intuitiveness of Ruby that I'm really missing right now trying to learn JS.

One of the big adjustments for me was being separated from the backend and having to mirror its structure and objects in a way that you just never have to think about when you're using something like Ruby on Rails. So am I writing this mostly for my own benefit as an attempt to hammer this into my brain and prevent future headaches? ...Maybe, but hopefully this can also make it easier for y'all the first time around.

So where do we start? There's no database schema or migrations to guide our associations, so we'll have to build our own. As usual, the magic happens in our class.

class Pizza {

}

Specifically the constructor method:

class Pizza {
  constructor(pizza) {
    this.name = pizza.name
    this.toppings = pizza.toppings
    this.deliciousness = pizza.deliciousness
  }
}

What's going on there? I won't get too much into this because it could be, and already is I'm sure, a full post itself, but more on that (...this?) here if you want a deeper look. For our purposes, suffice it to say that this is going to be our new instance of the Pizza class. What we're doing in the constructor is telling our class how to build instances of itself and what attributes to give them. If you've worked with another Object Oriented language this should look familiar. In Ruby, for example, the initialize method works essentially the same way.

So what's that pizza argument? pizza is what we've decided to call the object that's being passed in from our backend. Say, for example, we're getting a JSON object back from a pizza API. That object might look something like this:

[
  {
    "id": 1,
    "name": "Margherita",
    "deliciousness": 9,
    "toppings": ["Mozzarella", "Tomato", "Basil"]
  },
  {
    "id": 2,
    "name": "Hawaiian",
    "deliciousness": 3,
    "toppings": ["Ham", "Pineapple"]
  }
  ...

So we'd want to iterate through each of those objects and make new Pizza instances out of them. It's not very intuitive at first (why would we take one perfectly good object and then make a different identical object out of it?), but that's where our object relationships come in. Speaking of which, let's add some.

For our example, we'll say that Pizzas belong to a Human and a Human can have many Pizzas. That relationship would need to be reflected wherever we're getting our objects from (in this example, the database of our API), but so long as it is, we can represent it on the frontend by adding additional attributes in our constructors.

class Pizza {
  constructor(pizza) {
    this.name = pizza.name
    this.toppings = pizza.toppings
    this.deliciousness = pizza.deliciousness
    this.human = pizza.human
  }
}

class Human {
  constructor(human) {
    this.name = human.name
    this.pizzas = human.pizzas
  }
}

This code works; in our JSON object there would be something from the database indicating which human owns which pizza {"name": "Margherita", "human": {"name": "Cole"}} and we can call our constructor method on a pizza object at any time to create a new class instance new Pizza(pizza). But there are a couple potential issues with that. The most common one for me had to do with class functions. I was getting errors left and right saying TypeError: <myFunc> is not a function when it was clearly defined right there in my code.

Same classes as before, but let's create new instances and add a function this time.

// add function to Human class 
class Human {
  constructor(human) {
    this.name = human.name
    this.pizzas = human.pizzas
  }
  haveASlice(){
    console.log("Pizza is the best!")
  }
}

// our pretend backend objects 
let pizza = {
  "name": "Margherita",
  "deliciousness": 9,
  "toppings": ["Mozzarella", "Tomato", "Basil"],
  "human": {"name": "Cole"}
}
let human = {"name": "Cole"}

// instantiating new class objects
let newPizza = new Pizza(pizza)
let newHuman = new Human(human)

Great! All set up, now we have new instances of each class and we can call the function haveASlice on any instance of the Human class. So if we hop in the console and call

newHuman.haveASlice()
// returns
Pizza is the best!

Perfect, just like we expected! What about we go the round about way?

newPizza.human.haveASlice()
// returns
Uncaught TypeError: newPizza.human.haveASlice is not a function

What happened? newPizza.human is a human just like newHuman, right? In fact, they look exactly the same. The problem here is that even though they have the same attributes, newPizza.human is just a regular old javascript object, where as newHuman is an instance of a the Human class, which means that it has access to the functions defined in that class.

This was a big source of frustration in a recent project before I figured out the difference between the two and where in my code I still had regular objects floating around. The solution here is to always create instances, to associate them with the other classes they have relationships with in the constructor of that class, and to pay attention to the order that you're creating instances. For example, as long as I'm creating the Human instance first, I can do this:

class Pizza {
  static all = []

  constructor(pizza) {
    this.name = pizza.name
    this.toppings = pizza.toppings
    this.deliciousness = pizza.deliciousness
    this.human = Human.all.find(human => human.name === pizza.human.name)
    Pizza.all.push(this)
  }
}

class Human {
  static all = []

  constructor(human) {
    this.name = human.name
    this.pizzas = human.pizzas.map(pizza => new Pizza(pizza))
  }
}

I know there might be a lot of new stuff there, but the idea is to create Pizza instances inside of the Human constructor and search for an existing Human instance when we're back in the Pizza constructor, so that the relationship between the classes is always being maintained by class instances. Here's a commented version:

class Pizza {
  // initialize an array for all my instances to live
  static all = []

  constructor(pizza) {
    this.name = pizza.name
    this.toppings = pizza.toppings
    this.deliciousness = pizza.deliciousness
    // find an existing Human from the Human.all array below
    this.human = Human.all.find(human => human.name === pizza.human.name)
    // add 'this' (the new Pizza instance) to the Pizza.all array 
    Pizza.all.push(this)
  }
}

class Human {
  // initialize an array for all my instances to live
  static all = []

  constructor(human) {
    this.name = human.name
    // create new Pizza instances, collect them in an array
    // and make that array of instances an attribute on the new Human instance  
    this.pizzas = human.pizzas.map(pizza => new Pizza(pizza))
  }
}

I hope this has been helpful. Thanks for reading, go forth and create pizzas!

Unsolicited Advice After My First Rails Project

cole-flournoy — Thu, 25 Mar 2021 21:28:54 +0000

If you've seen any of my other posts, you might know that I'm doing the full-time Software Engineering (really Web Dev) bootcamp at Flatiron School. We've been building up to Rails for a couple months now, and we finally got our first crack at building a Rails app completely on our own. For my final project I chose to build a site for tracking allergies and dietary restrictions in schools (for use by teachers taking field trips, cafeterias with students that have nut allergies, etc.). If you're interested, or have any advice, feel free to check that out here.

So let's get into it. These are four things I would go back and tell my past self to save a lot of time and headache building my first project with Rails. I won't claim to have the perfect list for the most common issues, but hopefully I can at least help y'all avoid some frustration in these particular areas.

(1) Use A Sandbox

There are specific sandbox services or full virtual environments that programmers use, particularly for security reasons, but all I mean by a sandbox here is a place to play around and test code. That can be as simple as creating a second Rails app with the same structure as your main project.

This is especially useful for sorting out the associations between models and testing out database seeds. If you're starting with only a few basic has-many/belongs-to relationships, maybe it's straightforward enough to skip a test project, but as the relationships get more and more complex, I can't recommend a tester pancake enough. When I haven't used a sandbox in the past, I've ended up accidentally committing a bunch of changes back and forth in the beginning of my project, thinking I had it all figured out before I did. It helps keep your main project code way cleaner by replicating only what worked and was well-tested in the sandbox, and it gives you an isolated, identically-structured database to go back to if you want to try something out as the project progresses.

(2) Name Your Join Table

In any many-to-many relationship, you'll need a join table (more on ActiveRecord Associations here). But why is this

class Assignment < ActiveRecord::Base
  belongs_to :programmer  # foreign key - programmer_id
  belongs_to :project     # foreign key - project_id
end
class Programmer < ActiveRecord::Base
  has_many :assignments
  has_many :projects, through: :assignments
end
class Project < ActiveRecord::Base
  has_many :assignments
  has_many :programmers, through: :assignments
end

better than this?

class Programmer < ActiveRecord::Base
  has_and_belongs_to_many :projects       # foreign keys in the join table
end
class Project < ActiveRecord::Base
  has_and_belongs_to_many :programmers    # foreign keys in the join table
end

What gives? I thought as programmers we were supposed to value our time and always go for the easiest, most concise code possible? Yes, while the second option is cleaner looking and takes half the code, it's also significantly less flexible (and speaking as a beginner in Rails, potentially a lot more confusing).

First off, it doesn't allow us to work with the join table in any way. Since we don't have a model for it, we don't have the option to add any attributes or validations to it later if we want. And maybe that's just fine for your use case. Using has_and_belongs_to_many and creating the corresponding join table in a migration is a perfectly legitimate option, but for beginners I'd recommend starting with has_many_through. Experienced programmers probably will have a better idea of their end product when they're setting everything up initially, but for me at this stage it's still pretty common to think halfway through a project "Oh, of course I should have added 'x' attribute to my join table". Starting my projects with has_many_through relationships gives me the flexibility to just add a single migration with the attribute I missed, rather than rolling back my entire database and changing all the models.

Ok, so if we're going to associate our models with has_many_through why not just use a standard join table name (for example, programmers_projects? Again, you totally can, it's just not as clear. Rails is great; it has so many things built into it that do magic for programmers and make our lives easier. But that Rails magic relies a lot on, among other things, naming conventions. Like many parts of the framework, Rails expects join tables' names and filenames to have a particular word order and pluralization. I would go back and forth a lot between programmer_projects vs programmers_projects vs projects_programmers, etc. trying to figure out the problem before I finally just named my join table something else entirely.

(3) Don't Rely Too Much On Your Sandbox

Ok, so I know the very first thing I said was 'Use A Sandbox', but just like with anything else, there's a limit. Having a test project to get started cleanly and try stuff out is one thing, but depending on it so much that every time you make a change you try it there first is obviously too much. It doesn't even have to be that extreme.

For example, I wanted my users to be able to log in through Google, but I was having trouble getting Omniauth to work properly. Maybe it was interacting weirdly with some other part of my code and having a more simplified set up that looks the same would make it easier to spot the bad interaction, or maybe I just needed to start fresh because I missed something in the setup. Either way, perfect candidate for the sandbox! But even when I got it figured out there, I still couldn't get it to transfer over to my real project...

I spent way too long trolling Google and Stack Overflow for answers about what could be interfering with Omniauth (and commenting out different parts of my code), only to find that I had copied all but one gem into my real project's Gemfile from the sandbox. And Omniauth was working just fine!

WOW! -- SUPER IRRITATING!

As programmers, we want to keep our code as DRY (Don't Repeat Yourself) as possible, and the same principle applies here. It's not just about efficiency (although typing every new thing into a sandbox before you add it to your project does eat up a lot of extra time); it's mostly about protecting yourself from stupid mistakes like I made. The more times you type the same code in different places, the more likely you are to overlook something or make a mistake. So be careful with your sandboxes!

(4) Write Some Janky Code

Rails has a ton of crazy useful tools to make programming faster and easier. Trust me, I spent a lot of time during my project on this page trying to leverage the power of Form Helpers. But sometimes there can be a little too much Rails magic. If you're a student like me, you probably learned and practiced a lot with these helper methods and not a lot with building out similar things yourself. Of course, why would we do it the slow, hard way when there's a fast, easy way?? Well, those helpers are made to solve the most common problems, so what happens when you run into an uncommon problem?

My advice while you're learning, especially with form helpers but across the board, is to get as comfortable as possible throwing out the magic and learning how the common stuff works behind the scenes a bit more. I ended up spending a lot of time searching for syntax solutions to try to make a more complex set of associations work with form helpers in the way I learned them, when really they were problems that could probably have been solved a different way with 10-15min of creative thinking.

It's really tempting to always go for the most abstract option ("How do I simplify this as much as possible and let Rails magic do the work for me"), but my experience so far has been that just because it's the 'easiest' solution or a really common problem that Rails has built in a method for, doesn't mean it's the right solution for your project (or that it'll save you any time). This project is the most creative and adaptable that I've had to be as a programmer, and I was most successful when I was willing to have it look ugly for a while and just make it work. Code that works is better than code that looks clean and concise but doesn't work. We'll always look back on old code and be embarrassed about how we used to do things, but the shortcuts are easier to use correctly if you spend time on the fundamentals.

That's probably enough unsolicited advice for now. If anyone wants to check out my janky code to see if you should even listen to a word I say, the link to the repo is up at the top (also, feel free to watch the walk through video). Thanks for reading, and happy coding!

Workaround for Storing Arrays in Databases With No Array Type

cole-flournoy — Thu, 25 Feb 2021 21:53:58 +0000

I was recently working on building my first web app with Sinatra and ran into the issue that I needed to store an array/hash in my database. I should mention that there are certainly databases (like Postgres) that support an Array datatype; unfortunately, I was using SQLite3, which does not. That led me down a rabbit hole to find the simplest workaround, and I found that it was actually a pretty common question.

Here's what I want to be able to do:

class CreatePandas < ActiveRecord::Migration
  def change
    create_table :pandas do |t|
      t.string :name
      t.integer :age
      t.array :favorite_foods   # obviously can't do this because there's no array datatype
    end 
  end
end

Serialize the data

The most prominent answer by far was to serialize using the ActiveRecord method serialize. The idea here is that #serialize uses YAML to turn our array or hash into a string, so that it can be stored in the database and reconstructed later. For an idea of how that's working behind the scenes, we can take a look at this totally unbiased list of vegetables:

veggies = ["carrots", "peas", "mushrooms"].to_yaml 
#=> "---\n- carrots\n- peas\n- mushrooms\n"
preferences = {great: ["carrots"], gross: ["peas", "mushrooms"]}.to_yaml
#=> "---\n:great:\n- carrots\n:gross:\n- peas\n- mushrooms\n"

YAML.load(veggies) #=> ["carrots", "peas", "mushrooms"]
YAML.load(preferences) #=> {:great=>["carrots"], :gross=>["peas", "mushrooms"]}

So that's how serialize works, but how do I use it? Well, now that we know our list of favorite foods will actually be stored as a string, we can change our datatype in the migration.

...
create_table :pandas do |t|
  t.string :name
  t.integer :age
  t.text :favorite_foods 
end

We also need to tell our model to encode and decode favorite_foods so that we can interact with it as an array in our program.

class Panda < ActiveRecord::Base 
  serialize :favorite_foods, Array  
end

The second argument is optional, but helps to specify what type of coder you'd like to use or what type of object to expect when entering or retrieving data in the database. Here we're using Array as our object type to expect, but we could also use Hash (if we were working with hashes instead of arrays) or JSON (if we wanted to use JSON instead of YAML as our coder).

Now we're off to the races. We can create and edit Pandas to our hearts' content, without worrying about the favorite_foods attribute being an array.

fluf = Panda.create(name: "Fluffy", age: 13, favorite_foods: ["pizza", "bamboo"]) 
#=> #<Panda:0x00007fc39e0d7960 id: 1, name: "Fluffy", age: 13, favorite_foods: ["pizza", "bamboo"]>

fluf.favorite_foods.first #=> "pizza"
fluf.favorite_foods << "pasta" #=> ["pizza", "bamboo", "pasta"]
fluf.save #=> true

Drawbacks to using serialize

For a lot of situations, this is the perfect simple solution, and we don't need to go any further. But if you play around with serialize you'll notice there are a couple of limitations that keep it from being the one-size-fits-all, perfect tool.

The biggest drawback is querying. If I want to find Fluffy at any time, I can simply...

fluf = Panda.find_by(name: "Fluffy")
#=> #<Panda:0x00007fc39e0d7960 id: 1, name: "Fluffy", age: 13, favorite_foods: ["pizza", "bamboo", "pasta"]>

And if we want to see what food Fluffy likes...

fluf.favorite_foods.include?("pizza") #=> true
fluf.favorite_foods.include?("gyros") #=> false

But what if we want to find all the pandas in my database that like pizza? Even assuming that my array is ordered by preference, and we just want to know who has pizza as their top choice, we would need something like this:

Panda.find_by(:favorite_foods.first => "pizza") # or
Panda.find_by(:favorite_foods[0] => "pizza") # or maybe even
Panda.find_by(:favorite_foods.include?("pizza"))

None of that's going to work though, and the reason is pretty simple. If we remember back to the beginning, the whole point of using serialize was to enable us to turn our arrays into strings. Now our database is very confused (and going to send all kinds of errors) because we're trying to call Array methods on something that we've explicitly asked to be stored as text. For pandas and pizza that may not matter very much, especially at a small scale (we can simply request all the pandas from our database – turning our favorite_foods back into an array and allowing us to iterate over it with no problems). But what if instead of pandas we had a dataset of thousands of social media users... that method quickly becomes impractical.

That takes us to the other potential drawback: performance. The reason the above situation isn't practical is because for every user we pull from the database, Ruby will create a new object. We can see that even when we retrieve the same database entry more than once.

Panda.find_by(name: "Fluffy")
#=> #<Panda:0x00007fbb8b0881c8 id: 1, name: "Fluffy", age: 13, favorite_foods: ["pizza", "bamboo", "pasta"]>
Panda.find_by(name: "Fluffy")
#=> #<Panda:0x00007fbb877f69e0 id: 1, name: "Fluffy", age: 13, favorite_foods: ["pizza", "bamboo", "pasta"]>

Also, because of the serialization process, if we update a user's name (or any other attribute), the serialized column will also be updated, even if we didn't change anything about it. That's a lot of extra work for our program.

What if I need to query the data?

If you do need to query based on the information in an array-like structure (and it's not practical to switch the database you're using), an easy option is to create another table and model for the data previously held in your array/hash. Let's update our simple example, starting with the migrations.

# /db/migrate/001_create_pandas.rb
...
create_table :pandas do |t|
  t.string :name
  t.integer :age
  # t.text :favorite_foods  # no longer necessary
end

# /db/migrate/002_create_favorites.rb
...
create_table :favorites do |t|
  t.string :food
  t.belongs_to :panda   
end

Now we can create a standard has_many/belongs_to relationship between the two models. I'm assuming a familiarity with ActiveRecord Associations here, but if this is new or not making sense, check out the Rails Guide for a good explanation.

# /app/models/pandas.rb
class Panda < ActiveRecord::Base 
  has_many :favorites
end

# /app/models/favorites.rb
class Favorites < ActiveRecord::Base 
  belongs_to :panda
end

And that about does it. We wanted to be able to search for pizza, and now we can.

pizza_luvers = Favorite.where("food = 'pizza'")
#=> [#<Favorite:0x00007fbb8aa5b1b0 id: 1, food: "pizza", panda_id: 1>, 
     #<Favorite:0x00007fbb8aa5afd0 id: 5, food: "pizza", panda_id: 3>]

  ## To get the pandas' names ##
pizza_luvers.collect{|p| p.panda.name}   
#=> ["Fluffy", "Mei Xiang"]

  ## To see a panda's favorite foods ##
Panda.find_by(name: "Fluffy").favorites   
#=> [#<Favorite:0x00007fbb8771e018 id: 1, food: "pizza", panda_id: 1>, 
     #<Favorite:0x00007fbb8771ded8 id: 3, food: "bamboo", panda_id: 1>,
     #<Favorite:0x00007fbb875f7c98 id: 4, food: "pasta", panda_id: 1>]

Obviously our array of favorite panda foods has a limited utility, but even with an overly-simplistic example, I like the added functionality of an additional table over serialized data. For my real-life use case, this was a much better solution, because I needed to be able to query and sort by hash data. I was actually surprised to see that serialize was recommended so much, so if I'm missing something here, definitely let me know.

Hopefully this is helpful for anyone who finds themself in the same position I did working on my project!

Beautifully Spaced Columns in Ruby

cole-flournoy — Tue, 19 Jan 2021 04:51:19 +0000

Recently I was working on a CLI application (nothing crazy, just a fun little Superhero API project), and I wanted to spruce up the way I was outputting my list of all the available heroes.

I'm still new to programming, so I try to focus on function over form as much as possible while I'm learning. I'm also not trying to shout from the rooftops about my training wheels though, you know?

And that'd pretty much what this feels like:

...pretty rough, especially considering there are over 700 characters in that list.

So obviously I needed to take advantage of a little more horizontal real estate, but I was having trouble finding a straight-forward way to accomplish that without really knowing what to search for. I get that there are tons of command line tools out there that will format everything up and make it look dynamite, but I'm trying to learn the fundamentals. What's a guy gotta do to get a basic column out here??

So that brings us here, to .rjust and .ljust, two super easy methods (which for some reason are hiding in the comments of Stack Overflow with not enough upvotes) to help format your output into columns in regular ol' Ruby.

As you probably guessed, those stand for 'right justify' and 'left justify', and there are a couple key things to note here if you're having trouble using them.

These methods take an argument for the desired length of the new string not how much whitespace to add

If you try an example in IRB, you can see that .rjust is actually just padding the left side of the string and .ljust is padding the right ride of the string:

:001 > "apple".rjust(10)
 => "     apple"
:002 > a = "apple".ljust(10)
 => "apple     "
:003 > a.length
 => 10

These methods also take the optional second argument of a string to use for padding instead of whitespace

:004 > "banana".rjust(10, "*")
 => "****banana"

# You can also use a pattern for padding
:005 > "apple".rjust(20, "!?") + "peach".rjust(20, " -")
 => "!?!?!?!?!?!?!?!apple - - - - - - - peach"

Honestly, I can't think of too many practical applications for using something other than whitespace, but at least we're getting closer to understanding how to build out our columns.

NOTE: Make sure you aren't asking your string to be shorter than it started.

Calling "Grapefruits".rjust(10) isn't going to get you anywhere, because you're telling an 11 character string to pad itself on the left with enough spaces to become a 10 character string...

Now, if you're working with an array of arrays, this is pretty much as far as you need to go, since it's easy enough to iterate over your group and right or left justify each one.

dynamic_duos = [ ["Tom", "Jerry", "1940"], ["Scooby", "Shaggy", "1969"], ["Ketchup", "Mustard", "1812"] ] 

dynamic_duos.each{ |duo| 
    puts duo[0].rjust(10) + duo[1].rjust(10) + duo[2].rjust(10)
}

    # Prints these columns
       Tom     Jerry      1940
    Scooby    Shaggy      1969
   Ketchup   Mustard      1812

Not bad! Why are my years strings though? That's not very realistic, especially if I wanted to order my columns by year or something. That's because of the second common mistake with these methods.

`.rjust` and `.ljust` are methods from the String class

Calling these methods on an integer (like those years up there should be) will raise an error, but this actually isn't a big deal. There are plenty of easy solutions, like...

Interpolation

dynamic_duos = [ ["Tom", "Jerry", 1940], ["Scooby", "Shaggy", 1969], ["Ketchup", "Mustard", 1812] ]

dynamic_duos.each{ |duo| puts duo[0].rjust(10) + duo[1].rjust(10) + "#{duo[2]}".rjust(10)}

    # Prints the same columns from before
       Tom     Jerry      1940
    Scooby    Shaggy      1969
   Ketchup   Mustard      1812

If your arrays have a mixture of data types, you can interpolate all of the elements to be safe. There are lots of other options, like explicitly converting your value to a string first with .to_s.rjust(10), but I won't get into all those here.

What if I'm working with a normal array?

That's right, I almost forgot that the whole reason we're doing this is to print out a list of 731 superheroes without making our users scroll for five straight minutes.

Here's a shorter example of what I ended up doing:

fifteen_hockey_players = ["Lemieux", "Crosby", "Jágr", "Malkin", "Fleury", "Murray", "Jarry", "Letang", "Kessel", "Guentzel", "Rust", "McCann", "Dumoulin", "Hagelin", "Pettersson"]   
    # Totally not biased for any particular team  

count = 0
number = (fifteen_hockey_players.length/3) 
    # Divided by three because I want three columns

number.times do
    puts fifteen_hockey_players[count].rjust(15) + fifteen_hockey_players[count+1].rjust(15) + fifteen_hockey_players[count+2].rjust(15)
    count += 3
end         

    # Prints these lovely, lovely columns 
        Lemieux         Crosby           Jágr
         Malkin         Fleury         Murray
          Jarry         Letang         Kessel
       Guentzel           Rust         McCann
       Dumoulin        Hagelin     Pettersson

As long as I up my counter by the number of columns I have, I can print out as long a list as I like, in as many columns as I like.

Thanks to everyone who read this far! It's a little long, but I hope this will help some people like myself, who didn't have much experience with .rjust and .ljust. If anyone has anything to add or critique, please let me know in the comments.

Things to play around with on your own if you're interested: .center, chaining .rjust.ljust, and using the length of your string as the argument ex. .rjust(x.length + 5).

Decided to Start Programming

cole-flournoy — Mon, 21 Dec 2020 01:17:38 +0000

I’m pretty new to the blogging world, so you’ll have to give me a little leeway. The reason I’m here is that I recently started a full-time online software engineering bootcamp at Flatiron School, and one of their requirements is to keep track of the journey a bit through blog posts. So since this is the first one, I’ll just give a little introduction and how I got here.

I studied Spanish in college …and French, and linguistics, and translation, and religious studies, and philosophy, and Latin American history. You might say I was a little all over the place, but I have a wide variety of interests, what can I say? So if I have all these liberal-arts-y social science interests, what am I doing trying to get into programming? Well I’ll spare everyone a sob story about how my first grade teacher told me I was bad at math, but the cliff notes version is that my K-12 education was great for a lot of things (shout out to my first grade teacher), but STEM was not one of them. The emphasis at every school I went to was arts, humanities, writing, social sciences, language, etc. so I thought that’s what I was good at and what I should do. And I actually think it’s a super common thing that doesn’t get that much press: kids grow up thinking they’re bad at math because their math education just wasn’t very good, or being good at it was stigmatized.

Well, turns out my brain’s definitely wired for engineering, and not knowing that at the time, college was a pretty big struggle for me. I ended up dropping out after several years’ worth of valiant attempts to fight my natural brain to help my mom run the family small business (equipment rentals for events). Anyone surprised that most of what I did for the next two years there was a combination of carpentry, electrical repairs, building renovations, accounting, profitability, and financial projections? …Because I definitely was! Fixing stuff and crunching numbers in excel isn’t exactly what 18 year old me thought would be my favorite part of my future job. And teenage me definitely wouldn’t have thought I’d spend my free time taking apart traffic lights, building giant operation tables, and scrolling through Python tutorials.

So now here I am, looking to switch careers to a field that aligns better with my natural abilities. And for me, as much as I love to research stuff on my own and go down deep random project rabbit holes in my free time, if I’m going to really commit to something and prioritize it, I need more of an external structure. Huge respect to the people that can learn to program completely on their own (the resources are definitely out there to do it), but that can be a long lonely road.

We’re just wrapping up the first month of a six-month full-time program and starting to get into some exciting stuff with Ruby. Hopefully future posts will be a little more technical as we dive a little deeper into the code, but since this is just the beginning, that’s about it for now.

Thanks to anybody that read this far!