DEV Community: Anya Brun

My first week as a web developer

Anya Brun — Fri, 08 Jul 2022 01:14:46 +0000

Today officially concludes the first week of my new job. I know it’s only Thursday, but I started last week on Thursday, so technically it’s been a full week. At least, I think it has but I’m not good with elapsed time. I digress…

I’m working for btwb, a company that connects CrossFit gyms across the US and provides workout programs, trackers, and analytics for both athletes and gym owners. For now, I’ll be working on their web app, using Rails and Bootstrap 5.

I haven’t gotten to know any of my coworkers very well yet, but they seem cool. It feels weird to call them coworkers, honestly. They’ve all been doing this for probably more than 10 years (not trying to offend anyone but they’re all at least 30, I’m pretty sure). I feel more like a kid on a soccer team, except I’m the only person on the soccer team and I have like 4 different coaches. And I only just started playing soccer and I’m terrible at it because I’m an asthmatic nerd (true story).

A flawed analogy, maybe, but that’s what I could think of in the moment. Honestly, my brain is fried from trying to get my machine set up for work.

It’s been a saga…

First, I downloaded the source code to my machine and tried to set up my dev environment with all the gems and tools I’d need. A couple gems in particular (first it was idn-ruby then solr) weren’t playing nicely with the M1 chip on my new laptop, so it took an entire day of reading error messages, looking up pull requests and Stack Overflow posts, trying commands that returned new errors, rinse and repeat. The senior engineer who’s basically mentoring me—Corey—did most of the legwork, of course. At one point, we had to go into the solr bin files and delete a bunch of VM options.

I could write a blog post going in-depth into what the actual errors were and how we fixed them, but it’s too soon to revisit the trauma…

On Tuesday, one of the backend devs—Ben—made a devcontainer for the dev environment, so I spent the rest of the week setting it up. In my efforts to get that working, I learned about git stash , discovered Cmd+Shift+G in Finder, and poked through the mysql folder on my machine in search of the my.cnf file. Fun Fact: it’s not provided in the mac OS installation of mysql.

Aside from technical stuff, I’ve also learned to ask stupid questions. When I was setting up my machine that first time, I deliberated for a good 10 minutes whether or not to send a message in the Slack channel. I thought that I was asking a super obvious question and my boss would figure out how dumb I was and fire me. You could say I’m a bit of a catastrophizer.

Turns out my question wasn’t that dumb, seeing as it took me and Corey (and Ben, a little) an entire day (and then some) to figure it out. If I hadn’t asked, I would be completely stuck. Kudos to the dev team for being super welcoming and willing to answer my questions; that definitely mitigates the apprehension to ask for help.

Other than trying to get my environment up and running, I’ve just been reading docs and attending meetings. I don’t have much to contribute at the moment since I’m still getting my bearings, so I mostly listen and take notes. I’m trying to absorb as much knowledge via osmosis as I can.

As for learning outside of work, I bought Justin Weiss’ book—Practicing Rails. I’ve gone through two chapters, so far, and I’ve already gotten some valuable insights.

For one, Justin suggests having a list of app types that you refer to whenever you need to quickly spin up an app to test a concept. That way, you have a list of apps that you’re familiar with (because you’ve used them to practice over and over again) so you know exactly what features you need and how to build them. He also emphasizes writing exactly the code you need for whatever feature you’re working on right now and nothing more.

The book’s overall philosophy on learning is very hands-on, which works well with my brain.

I’m also working through UCSD’s Data Structures and Algorithms specialization on Coursera—slowly, but surely.

All in all, it’s been a good first week and I’m excited for what comes next.

My first tech conference

Anya Brun — Wed, 22 Jun 2022 19:03:00 +0000

On June 16th, I attended CodeLand 2022 – my first tech conference. I was a bit nervous but it was a great experience!

The convention was streamed live on the CodeNewbie Community platform. Nearly every speaker also had a post on CodeNewbie where you could watch their talk on-demand and post comments for them to respond to during the live questions panel.

CodeLand markets itself as a convention for early-career developers, and I definitely felt comfortable and welcomed as an individual relatively new to the tech industry looking for my first job. The talks were geared perfectly to the audience and I learned a lot.

What really impressed me about CodeLand 2022 was 1) the diversity of speakers and 2) the amazing captions.

Seriously, though—it’s shocking how bad captions can be for popular streaming services like Netflix or even live television. Not only are they poorly formatted so that it’s difficult to tell which person said what, but they often completely omit sentences or paraphrase instead of transcribing the dialogue.

In contrast, CodeLand’s captions were clear, accurate, and any mistakes in the transcription were corrected promptly.

I almost always have captions on because sometimes it’s difficult for me to interpret the sounds people make into words (weird, I know), especially when I’m not used to how they speak or I’m not with the person face-to-face. That’s part of the reason why I absolutely hate phone calls, lol.

The importance of diversity, accessibility, and inclusion was a major theme throughout the conference and it’s clear that the organizers of CodeLand 2022 practice what they preach.

My favorite talks were definitely Kelsey Hightower’s keynote speech and Silvia’s España’s talk on pseudocode. I’ve yet to watch the on-demand videos from Friday’s speakers, but I plan to do that at latest by this weekend.

Here are some particularly wise tidbits gleaned from my notes:

Kelsey Hightower — Fireside Chat

“Opportunities are not given; they’re taken”
“Make me respect me tomorrow morning”
Become a T-shaped developer: breadth of knowledge, depth in one area

Tracy P. Holmes — Redefining Your Programming Purpose

“I decided to be myself and people responded to it.”
“If what you want doesn’t exist, create it… Sometimes people don’t know what they need.”

Joe Glombek — Celebrate Your Misteaks

Turn mistakes into a learning experience
Share your mistakes with other people as often as possible

Haimantike Mitra — Next-Gen Inclusivity: How Gen Z Can Make Real Change in Tech

Be (or initiate) the change you want to see
Reach out 1:1 on social media to network and look for mentors, even if you’re shy or hesitant

Derek Binkley — Live Q&A Panel, in response to my question about getting feedback on your code as a solo developer

Get into a community, develop relationships, and ask if people are willing to look over your code
Open up a pull request and give yourself a code review. Just the act of explaining what you’re doing out loud is helpful

Raymond Chung — A Programmer’s Guide to Mental Health

When you get stuck, take a break! (emphasis mine, lol)
Make a list of positive affirmations and keep it visible
Take the initiative to reach out to your mentor / tech lead

Silvia España — I Think, Therefore I Code

Pseudocode allows you to think through the algorithm before you code it
Don’t “contaminate” your pseudocode with the language you’re going to use to code the solution

I’m glad I was able to attend CodeLand 2022. Definitely check out the on-demand talks on CodeNewbie Community if you’re just starting out your career in tech, or if you want to learn more about facilitating diversity and inclusion within the industry.

Advice I’d give my younger self

Anya Brun — Wed, 15 Jun 2022 18:52:10 +0000

These are things I wish someone had told me 2 years ago, when I started learning how to code in earnest…

Start learning data structures and algorithms as early as possible, not right after bootcamp when you have to get ready for interviews.

Not only do many (if not most) interviewers ask DSA questions, but practicing data structures and algorithms will help you learn to think like a programmer and fast-track your ability to build and debug useful software.

The resources I’m using are Leetcode, Crack the Coding Interview, the BaseCS podcast (I listen on Spotify), as well as the CS50 and MIT Courseware lectures.

Some alternatives are HackerRank, AlgoExpert, The Imposter’s Handbook, and the numerous videos and lectures on DSAs available on Youtube.

Build projects that solve real-world problems.

It might be easy to think that what you build doesn’t necessarily matter, as long as it demonstrates your skills or shows that you learned something. However, an interviewer doesn’t just want to know that you can code. They want to know whether you can write code that fills their needs.

This is where coming into tech from a different career—like teaching or marketing, for example—comes in handy. Your background gives you insight into real-world problems within your industry that an application (your application) can solve.

It also helps to build clones of popular types of applications. If you’re a web developer, for example, you can code a clone of an online store like Etsy.

Another bonus is that having a robust project allows you to take the lead in an interview. If you show the interviewer your project and it’s something that catches their attention, then they’ll start asking you questions—questions you can answer confidently and competently because you (hopefully) know the ins and outs of your project after working on it so diligently.

Apply for internships during bootcamp, if your schedule allows.

This point is especially relevant if you’ve been practicing data structures and algorithms early on. CS students in traditional universities don’t wait until they graduate to apply for internships. In fact, many apply within their freshman or sophomore years.

Likewise, don’t wait until you’ve graduated your bootcamp to apply for an internship. An internship will help you gain relevant experience to put on your resume that can shorten your timeline for getting a job after you graduate. There are several companies that offer internships to candidates from non-traditional backgrounds, so don’t worry about needing a CS degree.

On that note, make sure your LinkedIn profile is up to par.

It’s key that your profile has a picture and links to your Github, personal website, and your dev blog. Update your profiles and portfolio with projects that you build as you’re learning.

Start blogging as early as possible…

…Even if it’s not about anything deeply technical. Just chronicle your journey of learning how to code.

It will help you sharpen your written communication (a key soft-skill, especially in the age of remote work) and allow you to build a professional presence and community online. People may even reach out to you for opportunities if they like your work.

Take advantage of the community.

Reach out to people on LinkedIn who have a similar professional background as you or who are in the roles you want to be in. Ask for informational interviews or offer to buy them a coffee and chat about what it’s like to be in the industry.

Doing so will get you talking about code and making professional connections (i.e., networking) that will serve you well in your future job search.

Consistency is key - slow down if you need to and ask for help!

Don’t stress out if you can’t dedicate 10 hrs a day to coding. Even if all you can do is work on a project for 1 hour, it counts. Each hour is another cobblestone on the path to becoming a software developer. You’ll get there eventually—if you don’t burn yourself out.

Also, please don’t be afraid to ask for help when you need it. Leave comments on blog posts about concepts you’re struggling with and post questions to Stack Overflow. People in general are really nice and more than willing to help you out.

No programmer is an island; whether or not you identify as self-taught, no one can learn how to code alone.

Hopefully these insights can help you avoid some of the mistakes I made in the 2 years since I’ve been learning to code. If you have any experiences or recommendations, feel free to share them in the comments.

The more we share, the easier it gets for the next batch of self-taught and bootcamp developers to navigate the often difficult and confusing process of becoming a software engineer.

Quick life update

Anya Brun — Mon, 13 Jun 2022 20:25:30 +0000

I’ve been trying to structure my DSA study, and this video by Maya Bello where she ranks the resources she used to study for technical interviews was immensely helpful.

I’m going to use the Technical Interview Study Guide by Eric Duran to track my progress, and I’ll tackle one DSA each week. The schedule I’ve worked out is as follows:

Monday - watch lectures / videos (MIT Open Courseware, HackerRank, etc) + read relevant chapter of Crack the Coding Interview
Tuesday - do 2-3 problems on Leetcode
Wednesday - use practice questions from Crack the Coding Interview chapter to practice whiteboarding
Thursday - practice answering JS and React-specific interview questions
Friday - do more Leetcode problems
Saturday - practice writing DSAs from scratch

I still have to work on my portfolio projects, so I’ll focus on DSAs in the morning and do project work in the afternoon.

My first mini-project is to create my personal website with React and host it on a cloud service, like AWS Amplify. I had actually planned on completing that this past weekend, but there was an unforeseen setback. My MacBook sustained liquid damage and is being repaired right now, so I probably won’t have access to it until Wednesday… 😭

Even without my laptop, I can still watch videos on Youtube, read CCI, and do practice questions. The first topic on Duran’s study guide is Big O and that’s scary and intimidating, so I’ll start with the topic right after — strings, lmho.

As far as my job search goes, I’ve been applying to software engineering internship programs (specifically ones that don’t require CS degrees), so hopefully I’ll hear something soon.

rails new task-team

Anya Brun — Mon, 06 Jun 2022 22:32:38 +0000

NOTE: I wrote this blog post some time ago for Phase 3 of my Flatiron School SE program.

My goal for this project was to refine my process for building apps, in order to do so more efficiently. I came up with the following list of steps + questions to guide the development process:

Brainstorm app idea

What problem do you want to solve?
What experience do you want to provide?
Is there something your app can make more convenient or less confusing/time-intensive?
Why should a user choose your app over another?

Write up User Stories

Who is going to use your app? What is your target audience?
What exactly will members of that audience want to do with your app?

Draft a list of features

What features make the app? What are the MVP (minimum viable product) features?
What stretch features will you add if the MVP is completed ahead of schedule?
What features can you omit from the first version? What features will be added with subsequent releases of your app?

Backend, pt. 1 - Schema, Models, and Associations

What models does your app need? What attributes do those models have?
How are those models related? What associations are necessary to make these relationships work?
Create a detailed schema diagram.

Backend, pt. 2 - bin/rails console

Write out seed data based on your user stories.
Test associations in the Rails console. Be thorough and use the seed data to exercise your models & associations in a similar manner to how they'll be used in-app.
Make any changes to models or schema, if necessary.

NOTE: go feature by feature (i.e., build vertically).

Frontend, pt. 1 - views

Make mock-ups (e.g., wireframes) of every page (or the most important ones, at least) your app will need.
Note how a user will get from one page to another, and consider a nav menu for getting to frequently-used pages quickly.
Generate dummy views (e.g., a login form that isn't connected to the backend).

Frontend, pt. 2 - controllers

Generate controllers and routes needed for the feature you're working on.
Make the "dummy" views "smart" by grabbing and/or manipulating the data you need and displaying them to the user.

DRY things up

Consider ways you can slim down your controllers by extrapolating logic into class/instance methods on models.
Write helper methods for actions you perform repeatedly, such as grabbing the current user from the session user id.

Finishing touches

Style your app, maybe using a framework or some simple HTML & CSS.

NOTE: I have yet to start writing tests. However, I plan on incorporating this into my development process in the future. As of now, I'm relying on manually testing stuff like models, views, &c.

The aspect of the development process with which I had the most difficulty was creating the backend--namely, creating and associating models in a way that made sense for my app.

The (relatively) final version of my app ended up with 4 models: User, Team, List, and Task.

Initially, though, I didn't have the Task model. I was trying to associate the remaining as follows:

User has_many lists and has_many teams through lists
Team has_many lists and has_many users through lists
List belongs_to user and belongs_to team

That wasn't working because it didn't make sense for List to be the join-table, as it were, between User and Team. And building the association the other didn't make sense because a List can't have_many teams. No matter how I tried to make it work, it wouldn't--because that's not the relationship between these models "in real life."

Outside the context of a Rails database, a User can work independently of a Team, as well as collaborate with other people. A person belongs to a Team, and the people on that team may be grouped into sub-teams (which I simplified into Lists) to work on different tasks.

A User (optionally) belongs to a team, has many tasks, and has many lists through tasks. The tasks are directly associated to the user because many different users can have assigned tasks on the same list.
A Team has many users and lists, and has many tasks through lists. Tasks are associated through lists because a user may leave a team, yet the list is "stuck" to the Team and will still have the task (that was formerly assigned to the user).
A List has many tasks, has many users through tasks, and belongs to a team.
A Task belongs to a list and (optionally) to a user (allowing for tasks to be 'unassigned').

Structuring the relationships this way made much more sense and allowed me to proceed with considerably less confusion and headache.

I knew designing the database was (arguably) the most important part of building the MVP, but I underestimated how much time I should spend brainstorming/planning/testing my models and associations. On my next project, I'll dedicate more time to this step of the process so that subsequent steps can progress smoothly.

Routing and Sessions with Sinatra

Anya Brun — Mon, 06 Jun 2022 22:32:31 +0000

NOTE: I wrote this blog post some time ago for Phase 2 of my Flatiron School SE program.

Rubber-ducking doesn't just work for debugging. One of the best ways to learn is to teach others. Doing so can help you solidify your understanding of new/difficult concepts. In fact, there's even a fancy German term for it--Lernen durch Lehren. That's how you know it's legit.

Two new concepts I learned in the Sinatra project phase of my Flatiron course were routing and sessions. Since they were a bit difficult for me to wrap my head around, what better way to make sure I understand them than to teach the nebulous void of the interwebs?

What is Routing?

Routing is basically the method / process by which resources are sent to browser clients in response to HTTP requests. This process can be explained with the request/response cycle.

Let's take my Sinatra Plot Manager app as an example.

First, the user types the url of the resource they want--say... the plot of their sci-fi WIP, "Robots in Space"--into the browser. Next, the browser client builds a request based on that url and addresses it to the correct server (i.e., the server hosting my app).

Requests contain 1) a path that specifies the requested resource and 2) an HTTP verb that indicates what the server should do with the response. In this instance, the verb would be GET--instructing the server to retrieve (or, 'get') the Robots in Space plot resource and send it to the client.

Get it? wink, wink

The router--wherever in the app you've defined routes, like config/routes.rb--processes the request and maps it to the correct controller and action (get '/plots/robots-in-space' in the PlotsController). The action receives the request and passes it to the view, which subsequently renders the embedded ruby (ERB) file as html. Our Plots Controller sends this response back to the browser client and it is displayed as a web page for the user.

My plot manager app requires a user to login to see the resources they've created, such as plots, characters, summaries, etc. How does the server know what resources a client has access to? That's where sessions come in...

Why Use Sessions?

HTTP is stateless, so it's up to the server and client to store their own data about one another from one request to another. Clients use cookies and servers use sessions.

The server sends a cookie when it responds to the client's first request. In my app, that cookie stores the user_id so that each client session has a unique identifier. The server stores a session hash that includes session data, including that user id.

When the client makes requests, the app compares the id in the cookie to the id in the session to make sure the client has access to the resources they're requesting.

A Note on Security

When enabling / configuring sessions within your application, Sinatra gives you the option to set a session secret. According to this article by Martin Fowler, the session secret is "used for signing and/or encrypting cookies set by the application to maintain session state."

The secret makes sure that no one can change the value of their cookies and, for example, sign into your website as an administrator and have access to sensitive information.

This is why it's important to set the session secret securely, according to the guidelines in the Sinatra documentation. Doing so involves--among other things--making sure the secret is a random number with a length of, at least, 32 bytes and storing that secret in an environment variable.

A little bit about me

Anya Brun — Mon, 06 Jun 2022 19:30:25 +0000

Hello :)

My name is Anya and I'm currently living in the upstate New York area. Meeting me for the first time, you'd think I'm quiet and shy. And, at least initially, that's true. However, once I get comfortable with someone (which can take a while--admittedly), my true nature is revealed and you'll be begging me to stop running my motor mouth.

I've always been very curious and driven to learn and try new things. While I can get distracted by details, I'm largely a big picture person and like to have a "ground, up" understanding of concepts.

Growing up, my family moved quite a bit, exposing me to a diverse array of people and cultures. We started out in the northeast, but I've lived in the sandy desert of New Mexico and the steamy beaches of the Dominican Republic.

Living in so many places, I also picked up a few different languages--the strongest of which are Haitian Creole and Spanish. I can also understand written French pretty well, but I haven't practiced speaking it in a long while.

In my free time, I'm more than likely:

crocheting
training for a 5k
reading articles on nutrition or psychology
watching Chicago Fire/PD/Med on Hulu (in that order)
attempting to play bass (not well, sadly)

My interest in programming was sparked early in my life. When I was little, my father bought my sister and I a computer game that involved hacking through a company’s computer system and piecing together evidence of corruption and corporate espionage. Later, he bought us a Raspberry Pi computer and helped us install an Ubuntu operating system.

This led me to sign up for an introductory web development course in high school, wherein I learned the fundamentals of HTML and CSS. My final project was a website that displayed summaries and links to my favorite book series. I remember tinkering with a dropper tool and free graphics-editing software to get just the right gradient for the website’s background.

By the time I graduated high school, I had finished a decent percentage of freeCodeCamp’s front-end development curriculum. Hence, it was an easy decision to make web development my career. I applied for Flatiron School’s software engineering program soon after graduation.

During my time at Flatiron School, I developed skills in Ruby on Rails, JavaScript, React.js, and Redux.js through a series of project-based modules. Debugging was often my favorite aspect of completing the portfolio project. I would get stuck on a seemingly impossible bug and spend hours (even days) scouring the internet for answers. At last, I would find it–a blog post, a pull request on Github, a reply to a Stack Overflow question, or some example code in the documentation–that helped me understand the problem and craft a solution.

Currently, I am working on building a solid foundation in computer science fundamentals by studying data structures and algorithms. I am also expanding and strengthening my project portfolio in order to better showcase my skills and to gain experience in user-interface design and front-end technologies, like Node.js. Eventually, I want to learn Swift and get into developing iOS applications.

Feel free to connect with me through the comments or on LinkedIn if you want to share your latest projects, 5k training plans, book recs, or anything in between.

My misadventures with the useSelector hook

Anya Brun — Fri, 03 Jun 2022 16:47:28 +0000

One of the more interesting aspects of completing my React/Redux project was learning about the mechanics of state.

What is state and why did I need it?

React state is a JavaScript object that contains information that is private and fully controlled by the component. The Redux library allows for a global application state. Instead of (or, sometimes, in conjunction with) each component's local state, there is one object that contains all the state for the application. This object is located in the Redux store.

I decided to use Redux Toolkit to help set up the global state of my application. While all the information contained in the state is located in the store, an individual component may not need the entire state object, but only a piece of the information it contains.

Redux Toolkit conceptualizes these "pieces of state" as slices and provides the createSlice function as a way to assemble the application state one slice at a time. Slices are organized by the different features of the application, so that each slice contains only the initial state that is relevant to a specific feature.

Physically organizing the slices that make up state into features helped me understand what information was better stored in local vs. global state. This separation also made it easier to visualize the discrete steps of each feature and the corresponding actions + reducers I needed to write.

When it comes down to using data from the global state, it is best practice to write selector functions. The React-Redux library provides the useSelector hook, allowing you to use the selector function within a component. The selector takes the entire Redux store state as its argument, reads (and/or derives) some value from the state, and returns the result. According to the Redux docs, using selector functions keeps state minimal and easy to read, while making sure that original state is not being replaced.

How did I implement state?

In my React/Redux app, the two major features, for which I need access to the global store, are loading the levels on the Home page and letting users submit their own levels.

To implement these features, I created two slices: levelsSlice.js and formSlice.js. The former GETs game levels from the API and stores them in the state object, while the latter handles POSTing user-submitted data. State is structured thus:

{
    levels: 
        {loading: false, hasErrors: false, levels: []},
    form: 
        {loading: false, hasErrors: false, message: ""}
}

In addition to generating and exporting actions, the thunk action, and the reducer itself--I decided to create the selector functions in these files, as well. Here is the code for levelsSlice.js:

export const levelsSelector = state => state.levels

Frankly, the levelsSlice was the first slice I created, so I relied heavily on the Redux Toolkit "Getting Started" guide. In other words, I knew what this code was supposed to do, but I didn't know how it worked.

Well, this initial setup got my app to work perfectly insofar as it fetched the correct data and saved it to the store, so users could choose and play levels.

My next task was to make it possible for users to submit their own levels. On to formSlice.js. I more or less followed the same process for writing the thunk, the reducers, etc as in levelsSlice--with one small change:

export const formSelector = state => state.message

My reasoning: I would need the message to display as a validation to the user, so I should read it from the state with a selector.

Again, everything worked perfectly. A user could submit a hint and a word, this data would be POSTed to the API, and--upon returning to the Home page, where all the levels are displayed--the user-submitted level would appear, ready to play.

However, in the console I was getting an error to the effect of unable to deconstruct property 'message' (something, something) undefined. The error pointed to the following line:

const { message, loading, hasErrors } = useSelector(formSelector)

What went wrong?

First, I compared formSlice and levelsSlice, looking for any syntactical errors I may have made that would cause the code to break. Finding none, I tried to assign each property to a constant individually and see if it was just one not being assigned properly (meaning the problem could be in one of the reducers). All three lines gave the same error. After a couple more fruitless attempts at debugging, I googled the error and looked through some Stack Overflow posts.

One such post in particular (titled UseSelector State is Undefined)--while not directly answering my question--gave me an idea that sparked my understanding of the problem (and, subsequently, its solution). A reply suggested that OP should "[a]dd a console for debugging and check the state object." I did so with the following line of code:

useSelector((state) => console.log(state))

Thereafter, I (as expected) saw logged to the console the state object, whereupon I realized my folly.

I hadn't realized that the selector function accepts the entire state. In levelsSlice.js, I mistakenly assumed that the state object I used in the selector was the specific slice of state represented by the initial state I had defined in levelsSlice.js. I must have gotten confused by the fact that the name of the slice (and, hence, the key in the global state that points to the slice's properties) was the same as the key for the levels array.

The line in which I deconstruct the properties message, loading, and hasErrors returned undefined because state.message does not exist. What I really meant was state.form.message.

How did I fix it?

At this point, I understood that the actual point of the selector in formSlice.js was to select the slice of state that stores the properties relevant to the form feature (i.e., state.form). Using the object destructuring syntax, I can then assign the value of each of those properties to a constant in my form component. With that newfound knowledge, I refactored formSlice like so:

export const formSelector = state => state.form

Using this selector function in the useSelector hook would return the following object:

{ message: "", loading: false, hasErrors: false }

And logging message, loading, and hasErrors to console would allow me to see those values and how they change before, during, and after a user submits the form.

Debugging this error was one of the more fun parts of building my project. Having recently watched the film "Murder on the Nile", I felt like Hercule Poirot, following the clues until I eventually caught the culprit and solved the mystery. Thankfully, the only thing killed in this case was time.

Disable Request-Forgery Protection

Anya Brun — Fri, 03 Jun 2022 16:47:18 +0000

NOTE: I wrote this blog post some time ago for Phase 4 of my Flatiron School SE program.

While setting up the api for my project, I came across an interesting bug. Naturally, for my JS front-end to be able to make fetch requests to the Rails back-end, I needed to enable cross-origin resource sharing. Now, I'd typically just go into the CORS config file and allow all origins with the wildcard:

# config/initializers/cors.rb

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*'

    resource '*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options, :head]
  end
end

Interestingly, I was still getting errors saying that fetch requests from my front-end were being blocked. After a great deal of googling and digging through Rails pull requests on github, I stumbled upon section 7.2 of the Action Cable Rails guide—wherein I discovered the following piece of code:

# config/environment/development.rb

config.action_cable.disable_request_forgery_protection = true

This line of code disables and allows requests from any origin. An array of strings can also be passed in to specify from which origins requests may be accepted.

So enabling CORS requires not only adjusting the cors.rb file, but also going into development.rb and setting disable_request_forgery_protection equal to true.

Tangentially-related side note: some time ago, I came across an article talking about the need to keep a "developer journal." For now, my developer journal is just a document with a list of errors I come across and links to articles that helped me fix them. It helps prevent the same bugs from occurring again and provides a repo of information I can dig into later for deeper understanding of certain topics.

Once my backend was set up, I was able to start making AJAX requests. AJAX stands for Asynchronous Javascript And XML—although AJAX requests can be formatted as plain text or JSON.

When an event occurs (e.g., pressing a button), JS creates an XMLHttpRequest object that is sent to the web server (i.e., the Rails api). The server processes the request, and sends the response which is read and acted on by JavaScript.

JSON, by the way, is JavaScript Object Notation. Our Rails api "speaks" Ruby and the browser "speaks" JavaScript. Hence, the api converts Ruby objects into JSON (using serializers) before sending them to the frontend, so that the JS-speaking browser can then understand and use the data.

That's a pretty simplified understanding, but it was what I needed to enable back-and-forth communication between the client-side of my application and the server.