DEV Community: emmacohanim

Reflections

emmacohanim — Fri, 28 Oct 2022 19:41:44 +0000

The past four months have been a WHIRLWIND. Over the course of my time in Flatiron's Software course, I learned so much and met many incredible people. Read on to hear more about my experience with Flatiron.

I'll start off by talking about why I chose to do a tech bootcamp. My introduction to programming was somewhat unconventional. It occurred early on in my life and accidentally while playing the computer game MarbleBlast Gold. I had completed all of the levels and wanted a new challenge, so, at ten years old, I turned to the internet in hopes of finding additional levels. I unfortunately did not find any new levels, but I did find a Youtube tutorial demonstrating how to modify the levels that already existed.

After following the tutorial, I had written my first lines of code. But I didn't know this at the time. All I knew was that I had typed some weird-looking words and symbols into a big black box, and had been able to customize the levels in my favorite game.

Fast forward 10+ years, and I found myself feeling unchallenged at work. I missed using my brain to solve complex problems, and knew that no amount of crossword puzzling would fill that void. I learned about tech bootcamps from a family friend who had completed one, and I started looking into them. I took the plunge and enrolled at Flatiron after dipping my toe into the programming pool through some free courses, and I'm so glad that I did.

Going into a tech bootcamp, I had some expectations and tons of questions. I knew that I would come out of the bootcamp with the ability to conceptualize, design, and build websites, but I really had no idea what that entailed. What was a backend? How did it communicate with a frontend? When would I start cracking cringey coding jokes? (The answer to that last one was two weeks in. What's a ghost's favorite data type? A BOOlean! Awful, I know)

Now, four months later, I have answers to all of those questions and so many more. I learned that JavaScript can be vanilla, which I guess makes frameworks such as React spicy? And I learned that Semantic UI can be both a help and a hinderance. Most importantly, though, I learned which parts of the app-building process I enjoy most and which parts make me want to escape from reality by blasting pop-punk.

Angst aside, I have enjoyed these past four months so much. I feel empowered and prepared to enter the job market, hiring freezes be damned. I plan to take the skills I gained over the past several months to a career focused on bridging the gap between tech and business, and I am excited to do so.

Rails Generators

emmacohanim — Mon, 10 Oct 2022 04:26:01 +0000

Introduction

When building a rails application, we, as developers, must build the structure of our database as well as actions that allow the client to interact with our database and retrieve our data for the user. This requires us to create migrations, models, controllers, and routes. We can accomplish these tasks one of two ways: manually or using rails resource. Read on to learn about both of these methods and why developers generally prefer to use the second method.

Manual Method

In order to build our rails application, we first must create our migration. We can do so by cding into our application and entering the following in the terminal:

rails g migration manual_method

Once we have our migration, we must build our table by specifying our attribute names and data types.

class ManualMethod < ActiveRecord::Migration[7.0]
  def change
    create_table :manual_methods do |t|
      t.string :attribute_1
      t.integer :attribute_2

  end
end

Now that we have structured our table, we need to create the schema for our database. We can do so by migrating our new migration.

rails db:migrate

With our table created, we can turn our attention to creating our model.

rails g model manual_method

In addition to our migration, schema, and model, we will also need a controller to hold our actions as well as a resource route that our front end can send requests to.

rails g controller manual_methods controller

Rails.application.routes.draw do
    resources :my_resources
    # Define your application routes per the DSL in https://guides.rubyonrails.org/routing.html
  end

Whew, that's done. Now, imagine that we have an application with multiple models. In that case, we would need to repeat this entire tedious process for each of those models. Sounds like a lot of work, right? Well, it doesn't have to be. Thanks to rails' handy-dandy generate resource task, we can focus on the functionality of our application while rails handles the creation of our resources under the hood!

Resource Method

Let's utilize the rails g resource task to achieve the same end result as in our previous example.

rails g resource resource_method attribute_1 attribute_2:integer

Rails will now do the work of creating our migration, model, controller, and resource routes. Pretty cool!

Once our migration has been created, we can see that it contains our attribute names and data types. All that's left for us to do is send our migration up.

rails db:migrate

Conclusion

Rails g resource is a powerful tool for developers to utilize as it streamlines the process of building our database structure. Thanks to the work that rails does under the hood, we can spend less time structuring our database and more time working on the functionality of our application.

Breaking Down Variable Types in Ruby

emmacohanim — Mon, 19 Sep 2022 08:47:31 +0000

Introduction

There are four types of variables in Ruby: local variables, global variables, instance variables, and class variables. With so many variable types to choose from, it can be difficult to know which type should be used when assigning values to variables in Ruby code. Read on to learn about the behaviors and constraints of these different types of variables.

What are sigils?

Sigils are special characters attached to the beginning of some Ruby variables to indicate the variable's type. The two sigils you will encounter in Ruby code are @ and $. We use the @ sigil to identify instance variables and class variables. In Ruby code, @ indicates that the type of variable we have encountered is an instance variable, while the appearance of @@ indicates that we are dealing with a class variable. We can use the other sigil, $, to identify global variables in our code.

Local Variables

Local variables in Ruby are variables that are defined within a local scope. This scope can be within a class, module, or method. Local variables can begin with a lowercase letter or underscore. Because local are only defined in the local scope, these variables can only be used within their class, module, or method.

def my_method
    variable_type = "local"
    puts "This method accesses a #{variable_type} variable!"
end

Global Variables

Global variables are variables that are defined within the global scope. These variables can be used and accessed anywhere within an application. This type of variable is preceded by a $. Global variables are convenient as they can be used to allow one class, method, or module in your application to easily access the value of a variable defined within another without the use of props. Although global variables may seem simple, they can result in unwanted complexities in your code and should therefore be used with caution.

def my_method
    $variable_type = "global"
end

def other_method_in_application
    puts "This method accesses a #{variable_type} variable!"
end

Instance Variables

Instance variables are variables that act on a particular instance within a class. As mentioned above, these variables begin with the @ sigil. The example below illustrates the initialization of instance variables within a class.

class MyClass
    def initialize(instance_variable, other_instance_variable)
        @instance_variable = instance_variable
        @other_instance_variable = other_instance_variable
    end
end

Class Variables

Class variables are variables that act on an entire ruby class. As described above, we can use two @ sigils to indicate that we are dealing with a class method. The example below demonstrates the initialization of class variables.

class MyClass
    def initialize
        @@class_variable = class_variable
        @@other_class_variable = other_class_variable
    end
end

Conclusion

When deciding which type of variable to utilize in your Ruby program, it is important to consider two things. First of all, we must take into account which part(s) of our application will need to access our variable. Second, we must ask ourselves whether or not we would like the value of our variable to be consistent throughout our program. In general, it is best practice to avoid the use of global variables and instead utilize local variables. Additionally, sigils allow us to easily identify our variable types as global, instance, or class variables.

Reacting to Big Div Energy

emmacohanim — Mon, 29 Aug 2022 05:22:52 +0000

React makes creating complex, interactive applications a relatively pain-free process. It accomplishes this by straying from Vanilla JavaScript's use of imperative programming, which requires developers to tell JavaScript both what to render and how to render it. React utilizes declarative programming to handle the how of rendering under the hood, which leaves developers free to focus on what an app can do.

Like most good things though, React's convenience comes at a price, and that price is pedantry. React holds developers to high syntactical standards, and, in exchange, it does the dirty work on the DOM side. If its standards are not met, React will complain by raising an error. Let's consider the example below:

function MyBrokenComponent() {
    return (
        <h1>Beware!</h1>
        <p>I will return an error</p>
    )
}

In this example, we are telling React to return a h1 element and a p element when MyBrokenComponent is rendered by its parent component. This will result in the following error:

This error is telling us that React cannot render a component with more than one parent element. We are getting this error because React requires that return statements be wrapped in a parent element, and the return statement above does not meet this requirement. Let's look at another example:

function MyOtherBrokenComponent() {
    return (
        <p>Try again!</p>
        <p>I will also return an error</p>
    )
}

This example will result in the same syntax error as our previous example. Although our return statement only contains one type of element, p, it still contains two elements, and thus fails to meet React's one-parent standard. Let's examine an example that will not return an error:

function MyWorkingComponent() {
    return (
        <div>
            <h1>You're in the clear!</h1>
            <p>I will not return an error</p>
        </div>
    )
}

It is apparent when comparing our error-free component to previous examples that MyWorkingComponent has something the others lack: one parent element. In this case, as in many others, that parent element is a div. Wrapping elements within one parent element enables React to make sense of our declarative statements, and using divs is an easy for developers to ensure that React's syntactical needs are being met.

While divs are a useful tool for repairing syntax, they are not the only one we as developers have at our disposal. Let's consider the two examples below:

function MyDivlessComponent() {  
    return <p>I will not return an error either!</p>
}

function MyHappyComponent() {
    <div>
        <h1>Divs</h1>
        <h2>keep</h2>
        <p>React</p>
        <p>happy!</p>
    </div>
}

Our first component, MyDivlessComponent, has a working return statement but no div. How can this be? Well, a div is just one example of a parent component. The key to following React's strict syntax rules is to keep everything in the return statement contained inside of one box, or parent element. In the case of MyDivlessComponent, our parent element is a p element without any child elements. On the other hand, MyHappyComponent contains 4 child elements, and thus requires a parent element to be wrapped around those children.

Learning the ins and outs of a new framework can be tricky, but divs provide developers with an easy fix to one of React's most common errors.

innerHTML v. innerText

emmacohanim — Mon, 08 Aug 2022 02:29:00 +0000

If you've ever found yourself unsure whether to use .innerHTML or .innerText, you're not alone! Distinguishing between the two is something that many beginning developers struggle with when attempting to manipulate the DOM. Read on to learn about the differences between the two properties and why seasoned developers approach innerHTML with caution.

`.innerHTML`

InnerHTML is a JavaScript property that allows developers to dynamically manipulate an element's HTML information within the DOM. This property can be used to set an element's inner text, but it can also be used to set attributes and provide formatting instructions. Let's look at the example below.

const div = document.createElement("div")
div.innerHTML = "<p id="p1" class="paragraph">innerHTML is a powerful tool!</p>"

Here, we are using document.createElement to create a <div> element. We then use innerHTML to tell JavaScript to create a <p> element with the id "p1" within our <div>. We are also using innerHTML to set the text content of our newly-created <p> element.

When our page loads, the innerHTML property will allow JavaScript to recognize everything that we would like to include in our <div>. JavaScript will render innerHTML is a powerful tool! as "innerHTML is a powerful tool!"

`.innerText`

InnerText is a JavaScript property that enables developers to dynamically manipulate an element's inner text information within the DOM. This property can be used to set an element's inner text content, but it cannot be used to set attributes or provide formatting instructions. Let's revisit our example above using innerText.

const div = document.createElement("div")
const p = document.createElement("p")
div.append(p)
p.id = "p1"
p.className = "paragraph"
p.innerText = "innerHTML is a powerful tool!"

Here, we are using document.createElement to create both a <div> element and a <p> element. We then use div.append to append our <p> element to our <div> element and p.id to set the id of our <p> element. Finally, we are using innerText to set the text content of our <p> element.

When our page loads, innerHTML is a powerful tool! will be rendered as "innerHTML is a powerful tool!".

Comparison

You may notice that our innerText example accomplished the same goal as our innerHTML example but required a few more steps to do so. Let's explore why this is the case.

In our innerHTML example, we used innerHTML to create a <p> element, set its class and id, append it to our <div>, and set our <p>'s text content. Because we used innerHTML to create our <p> directly within our <div>, we did not need to use div.append as we did in our innerText example.

Similarly, we used innerHTML to set the class name and id of our <p> value by placing these attributes directly inside our <p> tag as they would appear in an HTML file. Because of this, we did not need to use p.id or p.className as we did in our innerText example.

Takeaways

We have seen how innerText and innerHTML can be used to manipulate the DOM. We have also seen the limitations of the innerText property and explored why this property requires extra steps when compared the innerHTML property. Now, let's discuss why developers do not always opt for the use of innerHTML.

As we have learned, innerHTML has the unique ability to create elements and set attributes. Unfortunately, it can just as easily remove them, whether you want it to or not! Remember, innerText only modifies the text content of an element, but innerHTML modifies an element's inner text, child nodes, and attributes. Because of this, it is important to exercise caution when using innerHTML and to opt for innerText when you are unsure where your data is coming from.