Forem: Martin Souza

Rescue Me: Techniques for Active Record Error Handling in Ruby on Rails

Martin Souza — Thu, 05 Jan 2023 20:15:11 +0000

Active Record provides many mighty tools to streamline the work of building a backend API, including for when things go wrong. In this post, we'll walk through three error-handling techniques, getting more sophisticated and powerful as we go.

For the sake of simplicity, our examples will deal with failing to find a record in our database, which we'll illustrate in the context of a standard, RESTful show controller action. However, these techniques are applicable to other types of errors as well.

Basic Error-Handling with Conditional Logic

The simplest way to handle Active Record errors is just to use conditional logic in your controller actions to specify what your API should do if an error arises. We might write our show action like this:

def show
  dingus = Dingus.find_by(id: params[:id])
  if dingus?
    render json: dingus, status: :ok
  else
    render json: {error: "Dingus not found"}, status: :not_found
  end
end

Let's break down what's happening here. First, we initialize a variable to refer to the Dingus record we want from the database, and we use find_by to retrieve it with the id provided by the params hash. (Read more about the params hash here.) Then, the conditional statement if dingus? checks whether that variable has a truthy or falsey value. This works because if the find_by operation locates a record and assigns it to the variable, dingus is truthy. If no record is found, the value of dingus is nil, which is falsey. Accordingly, if the condition is met, the API sends the data in its response, along with the successful :ok status code. Otherwise, it sends an error message, which we've produced manually as a simple hash, along with the appropriate :not_found status.

Handling errors like this has certain advantages. For one thing, this approach is easy to understand, and all the code for it exists in one place. It gives you very specific control over how an individual controller action responds to a certain error, and for that reason this technique can sometimes be useful even if you're using other more sophisticated methods elsewhere—particularly if you're creating custom controller actions.

However, for common errors, this technique is inefficient and clunky. You don't want to have to write separate if/else logic everywhere, and you definitely shouldn't compose your own error messages for every single case.

Basic Error-Handling with Rescue Blocks

Fortunately, Active Record gives us more tools and a better way to do things. In our first example, we used a simple logical condition to check whether or not our show action found a record, but we can take advantage of some built-in functionality instead.

Certain Active Record methods return instances of special classes called exceptions in the event of failure. For instance, the find method takes an id and returns a RecordNotFound exception if there's no record with a matching id attribute. It is less flexible than the find_by method in our first example, which can search using whatever attribute we like, but returning an exception instead of just nil when it doesn't find a matching record is a major advantage. For one thing, exceptions come with their own error messages, which we can access and send to the frontend rather than having to compose them ourselves. More importantly, they also enable us to use rescue blocks to define how we want to handle errors.

The rescue keyword is kind of like special conditional logic that looks out for exceptions of the specified type. When the right kind of exception occurs, the code block runs, doing whatever we've written to deal with the error.

Let's rewrite our show action to use a rescue block:

def show
  render json: Dingus.find(params[:id]), status: :ok
rescue ActiveRecord::RecordNotFound
  render json: {error: "Dingus not found"}, status: :not_found
end

Now we're using find to retrieve the requested record, and simply sending it to the frontend without assigning it to a variable first (though you can certainly still do so, and might have reason to in certain cases). If no record exists with a matching id, find returns an ActiveRecord::RecordNotFound exception—and when that happens, our rescue block kicks in and runs the same code we used in the else part of our first example.

This is a step in the right direction, but we still have to write a rescue block for each controller action. Maybe that's fine if we want to deal with a certain kind of exception for a single action, but it's annoying if we want to handle the same kinds of errors in multiple places.

Intermediate Error-Handling with `rescue_from`

Fortunately, we can entirely separate our error-handling from our controller actions. Just like rescue, rescue_from defines a response to a specific type of exception. However, rather than being attached to a particular action, a rescue_from is independently defined, and applies any time the specified exception occurs, no matter what action it comes from.

With a rescue_from, our whole example controller now looks like this:

class DingusesController < ApplicationController
  rescue_from ActiveRecord::RecordNotFound, with: :render_not_found

  def show
    render json: Dingus.find(params[:id]), status: :ok
  end

  private
  def render_not_found
    render json: {error: "Dingus not found"}, status: :not_found
  end
end

Now the show action doesn't need to include anything concerned with potential errors. We've refactored the error response into a separate method called render_not_found, which our rescue_from will use whenever a RecordNotFound exception occurs.

At this point, since our error-handling is separated from our controller actions, we can make it even more generally performant by relocating it to our top-level controller, like so:

class ApplicationController < ActionController::API
  rescue_from ActiveRecord::RecordNotFound, with: :render_not_found

  private
  def render_not_found(exception)
    render json: {exception.model: "Not found"}, status: :not_found
  end
end

Since DingusesController inherits from ApplicationController, it will use the rescue_from defined there—as will all our other controllers. We've also adjusted the private render_not_found method in order to generalize and reuse our error response whenever a RecordNotFound exception occurs anywhere. Now it takes the exception instance as a parameter so we can call exception.model to get whatever kind of resource wasn't found. In our example case, this would give us {Dingus: "Not found"}.

TLDR

The best approach for handling most Active Record errors in to use rescue_from in your top-level application controller. It's a bit more abstract, but it's the most effective and efficient way to cover common types of errors for multiple database resources. Once you understand how to use rescue_from, there's probably little reason to ever use an individual rescue block.

However, there may be still be times where good old if/else logic can provide a good one-off solution to deal with errors in special cases.

Whose Params Are They Anyway? Using the Params Hash in Rails

Martin Souza — Tue, 13 Dec 2022 21:33:26 +0000

Note: This post discusses the params hash in the context of Ruby on Rails, but the essential details also apply if you're using Sinatra for your Ruby API.

In learning about writing server APIs and setting up backend routing over the last few weeks, one of the trickiest concepts to pin down was the params hash. In dynamic routing, this special little data structure somewhat mysteriously performs a dual role in accessing information from incoming requests. Like most things I've encountered in programming that behave differently in different contexts, I took note of the params hash as a potential source of confusion for new programmers like myself (or simply anyone new to Ruby APIs).

To hopefully alleviate or avoid such confusion, let's look at what the params hash does and how to use it for handling different types of client requests.

What Even Is This?

First off, of course: what is the params hash? As the name tells us, it's a hash (a collection data structure with key-value pairs) that contains certain parameters. What exactly those parameters are and where they come from is what varies from case to case, and thus where confusion is likely to arise.

Broadly speaking, the params hash contains information included with HTTP requests. Depending on the type of request, it may include dynamic path information from the request URL, information from the request body, or both.

Using the Params Hash with Dynamic Routes

We see the first and plainest of the params hash's two faces when we write dynamic backend routes like this:

# in config/routes.rb
get '/dinguses/:id', to 'dinguses#show'

This is one of the basic RESTful routes most Rails APIs will have for typical CRUD operations. In this case, a request to this route should return a single record from our database for the dingus resource matching a specified id. So if our API receives a GET request to /dinguses/3, it should return the dingus from our database with an id of 3.

The params hash is how our API accesses the actual value provided for that id in a given request. Specifically, we can refer to the params hash in the appropriate controller to get this value:

class DingusesController < ApplicationController
  def show
    render json: Dingus.find(params[:id]), status: :ok
  end
end

When our API receives that request to /dinguses/3 and runs this controller action, the params hash contains the value of the dynamic part of the route indicated by the symbol :id as a key-value pair. The symbol is just a placeholder; the actual value for that placeholder from the request becomes the value, while the symbol becomes the key: {id: '3'}. That's why we can access it with bracket notation in our controller's #show method.

This works the same way in other methods for accessing a particular record by its id, like #update (for PATCH requests) and #destroy (for DELETE requests).

Using the Params Hash with Request Bodies

The other face of the params hash is revealed when our API receives a request with information in its body, like a POST or PATCH request.

Say our frontend has a form so a user can create a new dingus and add it to our database. When they submit that form, the frontend performs a fetch request like this:

fetch("https://www.dingusdomain.com/dinguses", {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({
    name: "Spade's Obsession",
    magnitude: 8
  })
})

The body of that POST request contains the information our API needs to create a new instance of the Dingus model and save it to the database. Conveniently, that information will end up as tidy key-value pairs in the params hash, which we can access in our controller:

# in config/routes.rb
post '/dinguses', to 'dinguses#create'

# in DingusesController
def create
  render json: Dingus.create(
    name: params[:name],
    magnitude: params[:magnitude]
  ),
  status: :created
end

Note: This very simplistic way of writing this controller action does work, but we're only using it for the sake of example. It's much better to write a private method for strong params and use mass assignment in actions like #create... but that's a topic for another time.

Double Your Params, Double Your Fun

Finally, the params hash can provide both dynamic route information and request body information in the case of a PATCH request.

Consider the following:

# in config/routes.rb
patch '/dinguses/:id', to 'dinguses#update'

# in DingusesController
def update
  dingus = Dingus.find(params[:id])
  dingus.update(magnitude: params[:magnitude])
  render json: dingus, status: :accepted
end

Here we have a dynamic endpoint for requests to update a specific dingus. Like the example #show method above, the #update method in our controller gets the actual value of :id from the params hash and uses it to retrieve the matching record from the database. Then it also accesses the params hash to get information from the body of the PATCH request (in this case just changing the value of the magnitude attribute).

Params Demystified

The params hash has even more uses than what we've outlined here (like containing query string parameters), but these two cases are the most basic. Knowing how it carries dynamic route information and request body information, and how to access each kind in your controller actions, is fundamental to implementing typical RESTful routing in a Rails API. With those two essential uses clarified, hopefully this multivarious little data collection is a bit less of a mystery.

Self Exploration: Self in Ruby Class and Instance Methods

Martin Souza — Wed, 07 Dec 2022 04:28:08 +0000

In learning Ruby and Active Record over the past couple weeks, I found self one of the most useful yet also most potentially confusing tools in the language. Figuring out how to correctly use self can become especially tricky depending on whether you're writing class methods or instance methods—so in this post, we'll walk through how self works in each situation.

Knowing Thine Self

First off, it helps to know what self is in general. In Ruby, self is a keyword that can refer to different things depending on the context in which you use it. Calling self returns the current object—but what that object is, i.e. the value of self, varies. This is exactly why it can be hard to keep track of what self means in any given situation.

For our purposes, we'll focus on how to use self in class and instance methods, and how it behaves differently in each. Also, while we'll look at Active Record model classes as examples here, the specific behavior of self and the overall concepts are applicable to Ruby classes in general.

Note: Remember that by convention, documentation and other writing about Ruby differentiates class and instance methods by representing them with different punctuation. Class methods are referred to as they actually appear when invoked in code, with dot notation: ClassName.class_method_name. However, instance methods are shown with an octothorpe # in place of the dot: instance_name#instance_method_name. Just remember that in actual code they're both invoked with dot notation.

Self in Instance Methods

Let's begin with instance methods, where self is the most straightforward. Say we have a class (in this case, an Active Record model) like this:

class Dingus < ActiveRecord::Base
  has_many :things

  def count_things
    self.things.size
  end
end

Our instance method #count_things returns the number of things that belong to the instance of Dingus on which we call #count_things. That last part is key: because #count_things is an instance method, we'll always call it on a particular instance of the Dingus class—and that specific instance is what self refers to in the context of the method.

Thus if Dingus instance d1 happens to have 10 Thing instances associated with it, and Dingus instance d2 has 20, the return values of d1.count_things and d2.count_things will be 10 and 20, respectively.

In instance methods, the self keyword is extremely useful. The example above only illustrates it in terms of basic Active Record association functionality, but it enables you to access any attribute of the instance, as well as any other instance methods the class has, inside the execution context of an instance method.

Self in Class Methods

Class methods are where self tends to become more potentially confusing. First of all, the keyword must be used in the definition of a class method, like this one added to our Dingus class:

class Dingus < ActiveRecord::Base
  has_many :things

  def count_things
    self.things.size
  end

  def self.has_most
    self.all.sort_by {|dingus| dingus.count_things}.last
  end
end

This class method .has_most iterates over every instance of the Dingus class and sorts them in order of how many Things they have by calling #count_things on each one. Finally, it returns the last instance of Dingus from that sorted collection, which will be the one with the most Thing instances because the sort order is ascending by default.

We can immediately tell .has_most is a class method because it has self in the definition. This is simply the necessary syntax to define a class method, but it also makes sense: in the execution context of the class, self refers to the class itself.

Moreover, within the class method, self still refers to the class, not any particular instance thereof. Thus, in this class method, self.all is equivalent to Dingus.all.

TLDR

Most simply put, just remember: Inside instance methods, self refers to the specific instance the method is called on.

Meanwhile, self is used in the definition of class methods, and inside class methods, self refers to the class itself, not any particular instance.

Keep these distinctions in mind, and it'll be much clearer when and how to use self in different situations.

Single-Handedly Handling React Forms

Martin Souza — Thu, 17 Nov 2022 16:37:57 +0000

Like most other things it offers, React provides a streamlined way to implement forms. Not only does the declarative syntax of JSX make building forms easier, but by leveraging state in combination with form elements, React allows us to control our forms' inputs. This enables easy collection of input data as well as other useful wizardry like input validation.

However, in learning how to make controlled forms with React, I found there's a sizable leap from the basics of setting up form inputs, each connected to its own independent state variable and each with a separate handler function, to the much more elegant and slick technique of using a single state variable and one handler function to manage an entire form. In this post, I'll walk through how to set up that trick.

Note: This post assumes familiarity with the concept of controlled inputs and how to build a basic form in React.

For a very small form with just a couple of inputs, having a separate state variable and change handler function for each input isn't that much trouble. The more inputs you have, though, the more unwieldy your code becomes—and fast. If each input in our form component is set up like this:

const [formNameInput, setFormNameInput] = useState("")
// ...
const handleNameInput = (e) => {
  setFormNameInput(e.target.value)
}
// ...
return (
  <form onSubmit={handleSubmit}>
    <input 
      type="text"
      value={formNameInput}
      onChange={handleNameInput}
    />
    // ...
  </form>
)

...We'll accumulate a large collection of state variables and state setter functions. We could cut some lines of code by invoking each input's respective setter function in-line inside the onChange, rather than writing individual handler functions, but even so the code for managing our form data will rapidly get out of hand. We can avoid this entire headache by using a single state variable to hold all our form data and one handler function that can tell which input it's being called from, and can accordingly update the right part of the form data in state.

Objectify Your Data

The key to this (pun intended) is to store all our form data in an object, rather than in separate pieces. Let's say our form has three inputs: name, description, and number. We can initialize one state variable and keep all three pieces of data there inside an object:

const [formData, setFormData] = useState({
  name: "",
  description: "",
  number: 0
})

When we invoke useState, we set its initial value to an object with keys that match our form's inputs (more on that later), and assign each key a default value (empty strings for name and description, and 0 for number).

As an aside, we could save this object to a separate variable, and use that to set our initial state:

const initialFormState = {
  name: "",
  description: "",
  number: 0
}

const [formData, setFormData] = useState(initialFormState)

This isn't necessary, but it might look a little neater. It also comes in handy for resetting the form later.

Input Names are Valuable

The second key part (strained pun still intended) of our setup is giving each of our form inputs a name attribute that exactly matches the corresponding key in the formData object:

return (
  <form onSubmit={handleSubmit}>
    <input 
      type="text"
      value={formData.name}
      name="name"
      onChange={handleInput}
    />
    <input 
      type="textarea"
      value={formData.description}
      name="description"
      onChange={handleInput}
    />
    <input 
      type="number"
      value={formData.number}
      name="number"
      onChange={handleInput}
    />
    <input type="submit" />
  </form>
)

This is essential! Each input element must have a name attribute with a value exactly the same as one of the keys in the formData object. These matching name attributes are how our single handler function will be able to know which key/value pair to update in formData.

Note also that we're now setting the value attribute of each input with a reference to the corresponding key in the formData object.

Handling It All

With our formData object in a single state variable and our controlled inputs given matching name attributes, we can finally write our handler function:

const handleInput = (e) => {
  const nameInput = e.target.name
  const valueInput = e.target.value

  setFormData({
    ...formData,
    [nameInput]: valueInput
  })
}

Let's break down what's going on here. First of all, notice we're still passing in the event object from whichever onChange invokes the function. Then we pull two pieces of information out of that event object, and assign them to variables: the name attribute of the input element from which handleInput was invoked, and the value the user has just entered into that input, which triggered the onChange.

Next, we invoke our state setter function setFormData so we can update state with the newly entered information. Since our state variable formData contains an object, we have to replace the whole object when we use the setter function to update it. Thus, we use the spread operator ... to copy the entire current contents of formData, then specify which key/value pair to change in that copy using our variables nameInput and valueInput.

Note the square brackets around nameInput. This is just the syntax required to interpolate a variable for the name of an object's key in this case. This detail tripped me up when I first learned to write this kind of handler function.

Because we're pulling the name attribute from the input element, and because we made sure that name exactly matches a key in the formData object, our handler function can use the name attribute to specify which key/value pair to update with the state setter function. The other key/value pairs will remain unchanged—so whichever input the user interacts with, only that input's corresponding information in formData will change. Our one function can handle every input element in our form, no matter how many we add.

Finally, a further benefit of managing forms this way is that all your form information will already be packaged in a nice, neat object, ready to be taken in and passed on by your submit handler function. This obviates the work of building such an object from the data in separate state variables for each input element.

Smoothing Things Out

We can refactor our single handler function to make it more compact. For one thing we could use a little object destructuring to simplify the variable assignment part:

const handleInput = (e) => {
  const {name, value} = e.target

  setFormData({
    ...formData,
    [name]: value
  })
}

Here we're just taking e.target.name and e.target.value and assigning them to variables also called name and value, then using those in the state setter function as before.

However, we can still do one better, and eliminate the variable assignment entirely:

const handleInput = (e) => {
  setFormData({
    ...formData,
    [e.target.name]: e.target.value
  })
}

Turns out we don't even need those helper variables! Our handler function can just invoke the state setter function and directly use the name attribute and input value from the event object.

React makes forms pretty easy, but there's definitely a pronounced learning curve to go from the basic idea of connecting each input element to its own state to managing a whole form with one piece of state and one handler function, no matter how many inputs it has. However, not only is it worth doing so simply to make your code less cumbersome, but ultimately this approach is all but necessary to deal with forms with more than a tiny number of inputs.

Hopefully walking through each step of how to set up a React form like this helps you make that level-up.

Connecting Things in React

Martin Souza — Mon, 07 Nov 2022 18:17:05 +0000

When I first read the official documentation as a preliminary to studying React in earnest, I quickly became dismayed. HTML-looking elements commingling amidst JS? This ubiquitous props object, which comes from where? The mysteriously recorded information kept in state, necessary for dynamic behavior—but how? And on top of all of this, the new overarching concept of information flow across a component hierarchy! I closed the React docs without making it to the end.

However, after my head stopped spinning, I found at least one thing had made sense: components—or rather, the idea of modularity. As I started actually studying each piece of React and learning its declarative syntax, I began to form an analogy for how it all works, which ended up helping me immensely to wrap my mind around the basic concepts and how to use them to build things. If you're also having a hard time with React, maybe my analogy will help you too.

It has to do with what it was like to set up old computer hardware like this:

My first computer, long ago, was a Mac Plus like that one (though I don't think I ever had one of those additional external floppy drives). The other hand-me-down computers I used afterward were similar desktop setups: a tower, a monitor, a keyboard, a mouse, maybe eventually a Wacom tablet or a Zip disc drive. Unlike the unitary laptop I use now, back then my computer as a whole system was cobbled together from physically separate pieces of hardware that had to be correctly connected to each other in order to function. Of course, before the advent of USB, that meant several different kinds of cables had to be matched with the right kinds of ports in the right places to successfully make those connections.

Perhaps you already see where this is going: my old computer was a collection of components, linked together by specific kinds of connections. When I starting thinking of React apps in the same way, visualizing React components as if they were physical pieces I had to plug into each other with the right figurative cables, it felt like the whole framework suddenly opened up to me.

A Series of Tubes

Take props, for starters. At first, I struggled to understand how props were defined for any given component, and also how specific values were passed as props to a particular component instance. But it all became clear once I saw examples of destructured props. Say we have some child component like this in App.js:

<ChildComponent firstProp={someValue} secondProp={anotherValue} />

I understood that we were passing someValue and anotherValue as props to our child component from its parent component, but I didn't understand how the connection worked until I saw the incoming props destructured in the child component like this:

const ChildComponent = ({firstProp, secondProp}) => {
  //...
}

Now it was as if I could see both ends of the cable: each prop is like a wire I had to plug into the right 'port' of the component tag in the parent component, and into the corresponding 'port' in the component declaration down the hierarchy in ChildComponent.js.

It didn't matter that I didn't entirely understand how object destructuring works, or even that this was an example of that. I just accepted this was the applicable syntax, and understood that only with those figurative cables properly connected can the child component get the specified values of those props from its parent, and access those values with the specified variable references passed down to it.

Once that much clicked, I retroactively understood what it meant if things were instead written like this:

const ChildComponent = (props) => {
  const firstProp = props.firstProp
  const secondProp = props.secondProp
  //...
}

Without destructuring, it's as if the individual prop 'wires' are bundled together, enclosed inside a tube. We have to pull them out and connect each one individually to use them within the child component.

One Thing Leads to Another

Having embraced this notion of plugging components into each other, the basic idea of state became much more easily comprehensible in turn. Say I have some state like this in a component:

const [isToggled, setIsToggled] = useState(false)

Again, accepting this is just the syntax for setting things up (rather than worrying about how this clever array destructuring actually works when we initialize state like this), I thought about what's going on here as physically as possible: isToggled, the state variable, is just a little container that holds some value I want to store (in this example, just a true/false Boolean). The setter function setIsToggled is a convenient tool React provides for the sole purpose of changing the contents of that state variable container to whatever value we pass it.

Within the component where this state is kept, I can connect whatever pieces I need to the state by having them use the setter function to change what's in the state variable, or by using a reference to the state variable to look at its current value. It's almost like another pair of little wires I can link up inside the component itself to create functionality—in this case probably a button that uses the setter function to toggle the value of the state variable between true and false, like this:

<button onClick={setIsToggled(!isToggled)}>ON/OFF</button>

In this example, it's as if I'm attaching a wire to my button to connect it to the state setter function, building a circuit that'll be completed when the onClick event listener fires.

And Another Thing

With the essentials of state in hand, I could combine it with my understanding of props as cables running between components to get a grip on the bizarre concept of inverse data flow. To expand upon our toggle example, what if the toggle button turns dark mode styling on and off for the whole page? In that case, the button itself might exist in a child component (like a navbar or a header), but we need to keep the isToggled state higher up, in App.js, so we can use it to control which CSS is applied to everything in the App.

With my understanding of props as cables to connect components together, I was finally able to understand how to pass down a handler function as a prop from the parent component App.js to the child component. That function would look like this:

const handleToggle = () => {
  setIsToggled(!isToggled)
}

We'd pass it like any other prop, connecting both ends of the prop 'cable' in the parent component and the child component:

// Somewhere in the return of App.js:
  <ChildComponent handleToggle={handleToggle} />

//Meanwhile, in ChildComponent.js:
const ChildComponent = ({handleToggle}) => {
  //...
}

And finally, our revised button would be able to call the handler function in its event listener, like this:

<button onClick={handleToggle}>ON/OFF</button>

Since we've passed handleToggle as a prop, we can call it in the child component, but when we do, it runs at the level of the parent component where it's actually declared—and where it has access to the state setter function setIsToggled to change the value we're storing in the state variable isToggled. Passing a handler function as a prop in this way is like plugging in a special type of cable that allows us to send information back up the component hierarchy, unlike regular prop cables, which only carry information between components going down the hierarchy.

All this is really basic stuff, but when I first started with React, the paradigm underlying the library and its whole approach to building a frontend was overwhelming at first—to say nothing of the unfamiliar syntax of JSX, functional components, props, and state. Finding a way to visualize React was the breakthrough that enabled me to understand these fundamentals. Once I found and plugged in that first figurative cable, the rest started coming much more easily. Now I feel I already have a decent grasp on how to build things with React, and I'm excited to see what I can do with it.

Hello W—

Martin Souza — Sat, 05 Nov 2022 18:21:50 +0000

I never liked that phrase, those two inescapable words every new programmer is instructed to use in their first console.log, for their first function's return value, as the content of their first HTML element, or what have you.

My earliest encounter with the immortal phrase came from my cousin, a childhood friend, always (and still) much more savvy and capable with tech than myself. I don't recall exactly when I first beheld the words, but presumably I saw them in some bit of programming my cousin showed me, probably when we were in middle school. Something about it always struck me as silly or frivolous in a way I found off-putting—though I never could put my finger on exactly why.

Now, many years later, I am the new programmer, typing those words myself as I begin to learn JavaScript, React, and other things in rapid succession at the Flatiron School. As I do, I can't help but feel that phrase take on new meaning for me. I'm acquiring new skills to take a new tack professionally, and in so doing I will re-introduce myself as something of a new person. Despite my lingering dislike for the phrase, I am indeed saying a new hello to the world.

Or at least here I am saying hello to you.

For the record, though, any test console.log of mine will always say 'oink'.

Forem: Martin Souza

Rescue Me: Techniques for Active Record Error Handling in Ruby on Rails

Basic Error-Handling with Conditional Logic

Basic Error-Handling with Rescue Blocks

Intermediate Error-Handling with rescue_from

TLDR

Whose Params Are They Anyway? Using the Params Hash in Rails

What Even Is This?

Using the Params Hash with Dynamic Routes

Using the Params Hash with Request Bodies

Double Your Params, Double Your Fun

Params Demystified

Self Exploration: Self in Ruby Class and Instance Methods

Knowing Thine Self

Self in Instance Methods

Self in Class Methods

TLDR

Single-Handedly Handling React Forms

Objectify Your Data

Input Names are Valuable

Handling It All

Smoothing Things Out

Connecting Things in React

A Series of Tubes

One Thing Leads to Another

And Another Thing

Hello W—

Intermediate Error-Handling with `rescue_from`