Failures and Flash Errors

A Ruby on Rails blog.

Photo by Austin Chan on Unsplash

This is a coding blog, where I will explore some insights from failure. My relationship with failure has been a respectful one with a lot of distance. I forget how long we’ve been dancing this dance together, but that’s how you know we go way back! I’ve been in a room with failure and that is to say I’ve seen it and noticed it’s presence. In order to avoid it, I have approached problems and tasks with a fear that has always guided me towards a safe routes. I know what failure looks like on other people, and spend a good chunk of my time ensuring I can keep failure off me. However, if anyone knows anything about coding (and life), they know that failure is a part of the job description. No, one likes failure, least of all me, but it’s world where getting accustomed to it will serve you in the long run. As a programmer in fact, if there were no failures there would be no need for us. I want to assert that when it comes to failure there is nothing to actually fear.

We are all human and failure is a part of growth. So in my time at Flatiron I’ve been stepping into a new understanding and outlook of failure and what it means to me. Also, I have really been wanting to write about failure.

Failures and Errors are one of the primary ways that tell us as software engineers where to go next. Getting errors is like getting feedback and is one of the main ways we communicate with our programs and applications. That is a very important point, because we are essentially communicating with the programs we build and we want our programs to tell us what is working and what is not working. Not because we want to be hard on ourselves, and not because we have the best interest of our program at heart(I mean we do). We really just want the things we build to work at the end of the day. So whether something works or does not work, it is of the utmost importance to us that we understand why.

If our applications break on us without telling us why, we’ll spend our precious time playing a complex game of digital charades. Thankfully our fellow peers and coders who’ve come before us and traversed these digital paths, have designed tools to help us find these errors quicker. And beyond that scope, they have create tools to help our users avoid the same pitfalls.

Flash Messages and Controllers.

Inside of our applications, we are working with many working parts. Let’s take our controllers, for instance. I like to make connections between Controllers and the human brain and spinal cord (aka the central nervous system). The Controller, much like our brain, is what passes messages to the rest of our application, it is the central network between how our user interacts with the models and views. Flash is a method that we call inside of our controller to tell our user what behavior is needed to interact with the application. It also helps us the programmers connect what’s going on behind the scenes to what we can expect users will see.

We want flash to tell us clearly what is working and what isn’t working. Similarly, we humans have built in responses in our central nervous system that give us clear messages on behaviors that work and don’t work. For instance, we have pain sensors that tell us “ouch” when something hurts. Flash works very similarly to that. Flash is actually a fail safe messenger.

Programmers learn quickly that failures and errors will happen inside and out of the work we do. One of our goals is to ensure that we create a good user experience, we want to make the lives of users as easy as possible and hit them with error messages that won’t hurt. And how we do this, is by telling our user what exactly they need to accomplish when interacting with the application. For instance. When a person enters a username wrong, they most likely get a message on their screen that reads something like: “Username not found, or incorrect password, please try again, or create a new account!” This is one of the many ways flash works behind the scenes.

Below I will walk you through an error use case for Flash. Flash is how programmers can send a message to the user letting them know the result of their action.

def create
   @user = User.create(user_params)
   if @user.valid?
      redirect_to user_path(@user.id)
   else
      flash[:my_errors] = @user.errors.full_messages
      redirect_to new_user_path
   end
end

Here, I defined a create method inside of a controller for users. The “.create” method saves the user that is created. However, we don’t want to just allow our users to create and save whatever they want into our database. For instance it would be a problem if we had 7 users with the same usernames, let’s say “Drake” for example. And it would be a problem even if we had two, especially if what we were building would increase in scale overtime. So outside of this method and controller, we will need to build validations inside of our User model. The validations that live inside of our model contain messages in the event that the required actions/behaviors are not met.

Validations

#--> if @user_valid? 
<!-- Let's look at this inside of our Models folder for user.rb -->
Class User
   validates :username, presence: true
   validates :username, uniqueness: true 
end 

With validations set, if the instance put in by the user is valid, we celebrate and send the user on their way into the application. They get redirected to a web page that contains their user.id information, yay! Sadly, we don’t live in a world where everyone can have the same User ID and be called “Drake” — it would just be too time consuming for Drake’s friends to find him. So sadly if our user failed in their attempt to create a unique name it just means that name is not available. On the brightside, our controller tells us what happened and to try a different name. Or if we already have an account, our browser will tell us “Hey, you misspelled your name or password silly.” And we get to try again despite the failure. And next time, hopefully we learn to not fumble our fingers when we type in our login information.

In conclusion

Errors and failures, other than the emotional pain they cause, they are great teachers. They are messengers that help us identify the walls we hit, and they don’t just stop there. The road in life is riddled with all sorts of pitfalls and blindspots. Thankfully with coding, there are, as I continue to learn, many tools at our disposal to get over, through and around these obstacles. Challenges will get you stumped and you’ll think you are at the end of your problem solving rope. The truth is, we are bound to fail more than we do succeed, but those successes are never reached without the steps of failure that brought us there. The best lessons are disguised in failure.