Huffman Blog

After completing Flatiron’s curriculum, I have found myself spending a lot of time wondering, ‘What’s next?’. The obvious answer is the career search; that’s the next step in everyone’s path. When I say; “what’s next?”, though, I mean what do I LEARN next? Things are constantly changing in this world. Languages rise and fall. Frameworks have their days and are soon replaced. In a climate that’s ever-changing, how do you decide what the next best thing is? Software engineering, as we all know, is a neverending path of learning.

Posted by Tyler Huffman on February 22, 2021

Have you ever thought about measuring performance of a function? How would you go about doing that? Would you measure it in milliseconds? What if a function on takes .00000000000000001 second? That would round to 0 milliseconds. So how much time did it take?

Posted by Tyler Huffman on February 15, 2021

For my React project I wanted to stretch what we’ve learned and implement user authentication into an application containing seperate front and back ends. While this sounds fairly straightforward in theory it is a bit more complicated in practice. First, while rails has a very good authentication system through ActiveRecord and bcrypt, you won’t be able to use it if you load your rails backend as an api. Creating an api-only backend will disable rails sessions (and in turn disable cookies from being passed between the browser and server.) Without this cookie, there is the possibility of being logged in on the backend but not on the front, and vice-versa. It took a while to get set up, but the basics are this:

1. When a user signs up, the user is created in the database. This information is then saved to the rails session, and sent to the frontend to be saved into the redux store. Now, the user is logged in in both front and back end.
2. When a user is logs in, a POST fetch request is made to the backend. At this point the User controller searches the database for a matching email, and then once one is found it checks the password given against the salted-hashed version stored by bcrypt. (I used the .authenticate method for this.) If the passwords match the database sends the users information back to the front end and the user information is stored into the redux store.
3. Everytime the app component is mounted, I send a check to the backend to see if anyone is signed in there. This means that when every time the application is loaded it is looking at the cookie data to determine if someone was previously logged in on this browser. If so, the backend sends that user back to the front and stores it in the redux store. This is how a user statys logged in even after closing the application through the use of cookies.
4. Logout is the simplest action to create here, it does two things. First, it send a delete request to the sessions controller. The controller then clears the session data associated with the current user. When this is successful, it sends a response to the front-end, which in turn clears the redux store of any user related information.

Posted by Tyler Huffman on December 26, 2020

Today, December 9th 2020, is a day in history for me. Today, I walked into my first ever interview for a position as a Software Engineer.

Posted by Tyler Huffman on December 9, 2020

Do you remember seeing that in the Javascript lessons here on Learn? I do. I remember seeing it, noting it, and moving on. Until, in my Javascript-Rails project, I ran into a situation where an HTML collection is NOT an array! I was baffled. I had a bunch of cards, all with an h4 tag that I wanted to add an event listener. Easy Right? Grab them all, iterate them, add a click listener to each. Done.

Posted by Tyler Huffman on November 21, 2020