DEV Community: Carl-Lundgren

"Dessert" and How To "Eat" It

Carl-Lundgren — Tue, 22 Feb 2022 08:28:18 +0000

Today, we're talking cookies. Something something, joke about tasty baked goods... No. Even if you don't have much experience with programming, you likely have heard about cookies, if only because websites keep asking if they can use them. Even if you've already heard about them, it's good to have a proper understanding of what they do. Cookies are used by websites to store information on the user's side of the website experience. This allows the website to do things like; keep you logged in on return visits, remember your password, track what you're viewing, etc. Since HTTP (the go to language for websites) doesn't have a way of keeping track of any of this information by itself, cookies lets it hold onto all this information and more for use in the web browsing experience.

Baking the Cookie

I know I said no to the baking joke earlier, but I had to. Now that a basic understanding is established, we're going to be getting into the more technical side of things. For this blog post, I'll be using Ruby on Rails and React, although Rails will be the focus, but if you're going to be following along with me in an actual app, you'll need to do some things first. In order for a fresh Rails application to use cookies, you will need to go into config/application.rb. Once there, you'll need to remove config.api_only = true and replace it with the following:

config.middleware.use ActionDispatch::Cookies
config.middleware.use ActionDispatch::Session::CookieStore

You'll also want to add in config.action_dispatch.cookies_same_site_protection = :strict for security.

Now that the basic setup is done, we'll move onto properly utilizing cookies.

Authentication

One of the main uses for cookies is logins, so lets cover it. When you first visit a site, you log into it. Makes sense, but it would really suck if every time you leave the page, or even reload it, you'd have to re-sign in. That's where authentication comes in. Once you've logged in, the site remembers who you are, so that when it sees you again, it doesn't have to ask. Now all the annoyances of logging in over and over are gone, but how do we do that?

Let's start out really easy. We'll create a path we can post to for logging in.

post "/login", to: "sessions#create"

Looks great, but the place we're posting to, "sessions#create", doesn't actually exist yet. So let's make it and walkthrough what it means. (# indicates that the line is a comment)

# lets setup the thing in charge of session as a whole first

class SessionsController < ApplicationController

  # now onto the create part of "sessions#create"
  # this is the thing that directly handles making new users
  def create

    # now we'll establish the user that is currently logging in,
    # set that as the current user this session, and send that 
    # info back to the frontend.
    user = User.find_by(username: params[:username])
    session[:user_id] = user.id
    render json: user
  end
end

That's our backend all sorted. Now our front end just needs to send a POST fetch request to "/login" with our username and we're good to go... except not quite. While this does log us in and our backend will remember us when we come back, our frontend won't. This is because our frontend and backend don't have a way of telling each that information. Let's fix that.

Just like before, we'll add in a new path that our frontend can fetch to.

get "/me", to: "users#show"

Since we're getting info instead of sending info, we use get this time instead of post. Now we set up our User Controller to handle "users#show".

class UsersController < ApplicationController
  def show
    # same as before we establish the current user
    user = User.find_by(id: session[:user_id])

    # but this time we check whether user exists
    # if it does we send that, if not we send an error
    if user
      render json: user
    else
      render json: { error: "Not authorized" }, status: :unauthorized
    end
  end
end

Now that our backend is set up, we'll add in the following to our frontend so that it can get all that info;

useEffect(() => {
    fetch("/me").then((response) => {
      if (response.ok) {
        response.json().then((user) => setUser(user));
      }
    });
  }, []);

With our application now able to remember us, we can finally do things with it... Like restrict people from doing certain things.

Authorization

Time to make a VIP room! Now that our cookies established who everyone is, we can have it where only certain people are authorized to do certain things. Authorization can be used to give special features to premium members, enable admin powers, or in our case, make a VIP page that only some people can view.

Rails has a lovely beautiful tool called before_action that allows us to filter out who can do or view whatever we choose. So in our case, if we only want authorized people to be able to "enter" our VIP room, we simply put before_action :authorize before our VIP code. Now what if we wanted everyone to see a little bit of how much they were missing out? We can simply add skip_before_action :authorize, only: [:preview].

While this is just the tip of the iceberg, I hope that I've helped you understand the power of cookies and just how delicious dessert is.

Paths in Ruby Rack

Carl-Lundgren — Mon, 20 Sep 2021 08:51:24 +0000

I don't know about you guys but my life has been pretty crazy recently, so lets go over something pretty simple but crucial to backend programming. Today we'll be going over the topic of paths, specifically in the context of Ruby Rack, but the knowledge can be applied more generally as well.

Paths. What are they?

Well I'm glad you asked, hypothetical person from the internet. Paths are, as the name suggests, the roads through which information travels to and from a server. If a user wants to ask a database how many cats there are in the universe, then they are routed through a path, so that the server knows what they are asking for and from where, and therefore, how to react to that request. After all, showing someone a cat and letting someone post a picture of a cat are two very different things. So, what are some different paths and routes you can take?

Let's talk cat herding

There are a whole lotta' different ways you can interact with internet cats and we're going to go over a few.

GET

So what if you want to look at all the cat pictures? GET would be your path of choice.

if req.path.match(/cats/) && req.get?
   #  gives you cat pics
end

So for a quick walkthrough of the above, req is short for Rack Request (if you were putting this in your own code you'd need to make sure that's declared) and I'll be using that shorthand from here on. The above code reads, if the requested path matches /cats/ AND it's a get request, you get given cat pics (# like that indicates a comment in ruby). Sadly, that code doesn't actually give cat pics.

What if you only want to see pictures of tabby cats? Well, for this hypothetical cat haven, all you'd have to do is change /cats/ to /cats/tabby. Paths can change a lot, even if they're the same request, but what about if it's a different request?

POST

If you want to upload new cat pictures then GET simply would not do, but fortunately, POST exists.

if req.path.match(/cats/) && req.post?
   #  lets you upload cat pics
end

Thanks to the code above, you can always add more cat photos to the world. Even though the path is to /cats/ just like the GET request, POST allows you do something completely different than the last request. Such is the power of paths. But what if your cat has made a new cat friend and you want to let people know?

PUT

PUT lets you do just that.

if req.path.match(/cats/) && req.post?
   #  allows updates to already existing cats
end

POST and PUT are a lot alike, but unlike POST, PUT allows you to update and change preexisting information and profiles, not just add new ones. Now, I know what you're thinking, what if your arch nemesis Mr. Mittens challenges you to a duel and you sadly have to defeat the fluffy little monster?

DELETE

DELETE allows you to do just that.

if req.path.match(/cats/mittens) && req.delete?
   #  enables you to dispatch of your nemesis once and for all
end

Truly a powerful tool.

As I said at the start, paths are a very simple, but very crucial part of any good backend. I hope our little cat-venture helped you to understand them a little bit better. Until next time, happy coding and may the cats be with you.

React. Let's talk Forms.

Carl-Lundgren — Sat, 24 Jul 2021 07:17:46 +0000

So, I've been learning React recently and it is interesting. It is built off of JavaScript and most of it behaves like JS, with some extra bells and whistles. In this post though, we'll be talking about something that is pretty different between the two. Forms.

JavaScript Forms (well, HTML I guess)

Forms are an HTML thing that allows for users to input information. Have you ever logged into a website? That was probably using a form. JavaScript is able to interact with Forms, which shouldn't be surprising given it's HTML, but because the information that forms gives changes based on user input, you can do a bit more with it. You can use JS with Forms to, for example, make sure a password has 8 or more characters, a number, and a special character. Overall, though, Forms is still a pretty simple tool that works, more or less, like any other use of HTML in JS.

React Forms

React forms work a bit differently. They're still technically HTML elements, but they are a bit special. Before we get into that though, some context. Classes, which most files in React are, have a thing called state. State is an object that allows you to store information that can be accessed from anywhere inside the class. Now that we have some context, how does this connect to forms? Forms in React basically have their own state. This state can be accessed when you call upon the form, but there's something else special you can do with it. You can link the forms state to the state that the class has. This makes what is called a Controlled Component and it looks like this:

state = {
    value: ""
}

<input value={this.state.value} onChange={() => (this.setState({value: event.target.value}))} />

(This is an example that leaves out some important things but gets across this broad strokes)

Controlled Components don't erase the class' state, but instead intermingle the two so the class state is the one true state. It's a simple thing, but something very useful and good to know.

While a lot of this post was working more in theory than practice, I hope that this gave you some practical knowledge that you can use down the line.

For Loops and Beyond (in JavaScript)

Carl-Lundgren — Mon, 17 May 2021 23:58:49 +0000

This may seem obvious but loops are a very useful tool for code. They allow you to do things that you wouldn't be able to do at all otherwise and let you do other things far easier than you could using other methods. While there are many different types of loops and they all have uses, we'll be focusing on for loops and it's many variations in this post.

So, lets get started with the basics

let i = 0;
for (i; i < 4; i++){
  console.log(i);
}

So what does the code mean? Basically, in English, it's saying "This is what i is. For as long as i is less than 4, print out in the console what i is. After i has been printed increase i by 1". When this code runs it would print out 0, 1, 2, and 3, each on separate lines. This is about the bare minimum you can do with and for a basic for loop, but is a good example for understanding the basics. Now lets break it down a bit more.

A for loop requires that you put in three different parts.

The first part (which in this case is i) establishes the variable (i) that we're using to determine how many times the loop is running. The variable being used in this part has to have it's value be a number but it doesn't have to be declared beforehand. If the variable's value hasn't been declared then you can declare it here (ex. for (i = 0; ...)) and even if the variable's value has been declared you can change it's value to something else here (ex. for (i = 3; ...)). You can even declare a variable that hasn't been declared anywhere else and you don't even have to use let or var (ex. for (num = 0; ...)). One quick side note, you can't use any variable declared with const because the variable will be being changed in the for loop.
The second part (i < 4) determines in what instances the code in the loop runs. For the example above the code only runs if i < 4 but you could have it only run if i <= 4, or if i = 0, or if i > 6, etc. Be mindful that if the situation is something that never will occur (like i = 4 even though i is declared as 0) then the code in the loop will never run, and if the situation is something that will always be the case (like i > 2 when i is 4 and is increasing in value) then the loop will run forever, although this is something that also ties into the third part.
Part three is how you are modifying the variable (i++ for our example). You can modify the variable in a bunch of ways, but some of the most common ones are ++ which increases the variable by one, and -- which decreases it by one. You can even change the variable inside of the loop. Whenever you're changing the variable, make sure that it doesn't make the loop go infinite and more generally check that you're both modifying the variable and going through the loop the number of times that you're wanting.

While for loops allow you to do a lot of things there are some tools related to for loops that are designed for iteration (aka going through a thing for each thing inside that thing) and, even though for loops can work in their place, they do it a lot cleaner. The ones will be going over here are: for...in, for...of, and forEach().

for...in

for...in is used for iterating over objects. A very simple, but very useful thing to do so efficiently.

const object = {things: "stuff", number: 7, color: "blue"};

for (const key in object) {
  console.log(key);
}

The above will log in order: things, number, and color, but it will not log stuff, 7, or blue. In order for it to print the latter you'd need it to be console.log(object[key]); because of how sorting through objects works (we'll not be getting into that here). Technically, for...in can iterate over arrays, but you do not want to do this as it can cause various problems including, but not limited to, mixing up the order of the array. If you're working with an array then you'll want one of the following two instead.

for...of

for...of has basically the same formatting as for...in, but is used for arrays and not objects.

const array = ["red", "blue", "green"];

for (const element of array) {
  console.log(element);
}

This would log red, then blue, then green. Interesting thing about for...of is that it can be used on more than just arrays, it can also be used on strings. for (const element of "red") {console.log(element);} would log r, e, d.

forEach()

forEach() is different from the other two as far as formatting, but like for...of, it iterates through arrays.

const array = ["red", "blue", "green"];

array.forEach(function (element){
  console.log(element);
});

forEach() passes in a function and runs that function for each element (aka thing) in the array. For those of you familiar with arrow functions, below is another, probably more common, way to write this. For those of who aren't, the above and below are the same and both log the same thing as the for...of did.

const array = ["red", "blue", "green"];

array.forEach(element => console.log(element));

As far as the differences between for..of and forEach() there are a handful, with for...of being able to be affected in a handful of ways that forEach() can't, but for the most part the choice between the two comes down to comfort and personal preference for the specific instance. Basically, most the time just use what you're more confident with.

You should now have a basic understanding of for loops and some of it's variants (assuming I've done my job right). I challenge you to use some of these in your own code, and if you want you can even push yourself by messing around with nesting for all of these different concepts, although that will make it more complicated. Good luck and have fun.

Aight. Here we go.

Carl-Lundgren — Thu, 06 May 2021 05:41:39 +0000

Time to do something I may or may not have been mildly putting off, writing something that isn't code. I know it sounds silly, but making a blog was intimidating to me. Finding the balance between being professional while still showing my personality, making sure my information is clear and informative, but not too dry. Stuff like that kinda' scared me. I'm still trying to figure out that balance but for now we'll start out with something that is (hopefully) easy, why I decided to become a software engineer.

In middle school I started playing a game with a couple of friends that, looking back at it now, has shaped my life in a huge way. That game was Halo 3 and it was my first real exposure to the world of video games. Halo 3 got me hooked, but from there I played a lot more in a bunch of different genres and started to develop a love and passion for the making of games. By the time graduation rolled around, I didn't know what I was going to do with my life, and while the dream to become a game developer was still there, it wasn't something I made any moves to actually do. It wasn't until recently that I decided it was time to act.

Knowing that the games industry is incredibly challenging and competitive, I decided that I should start by learning some more universal skills. That's why I decided to start attending Flatiron for software engineering so that I could learn important skills that can apply to any type of coding, and while I haven't given up on my dreams of becoming a game developer, I'm confident that this is the right first step for me.