DEV Community: Eleni Papanicolas

uploading images using cloudinary: a comparison between ruby/rails and node/express

Eleni Papanicolas — Mon, 25 Apr 2022 21:56:54 +0000

Uploading images on the front end, using a form in React, is fairly easy, when compared with the back end set up. I learned how to do it in Ruby on Rails first, and now using Node.js and Express. In both, despite pouring over numerous tutorials and tons of documentation, I found it wasn't exactly as straightforward as all these resources made it look. Through tons of debugging though, I finally found my solution. I wanted to share some thoughts and some of the differences I found when learning how to configure Cloudinary with different back end languages and frameworks.

FRONT END FIRST

<form onSubmit={handleSubmitNewImage} encType="multipart/form">
          <label htmlFor="image">
            <input
              type="file" name="image" accept="image/*"
            />
          </label>
          <input type="submit" value="submit" />
</form>

Here I have set up up a form which will render a file chooser. The enctype="multipart/form" is necessary because when we are attaching an image to the request object, we lose the ability to use JSON.stringify(), and we must use new FormData() and append our image file. Then in the body we just send the formData as it is.

    const formData = new FormData();
    formData.append("image", image);

    const response = await fetch(`<your-endpoint>`, {
      method: "POST",
      body: formData,
    });

    await response.json().then((data) => {
      console.log(data);
    });

CLOUDINARY

Cloudinary is an exceptionally easy to use cloud storage solution for uploading images and storing a url path in a database. I used postgreSQL, a relational database, when I uploaded images using Rails, and I used mongoDB, a non relational database, when I did the same with Node and Express. Cloudinary worked great in both environments. I created an account for free on Cloudinary's website, and they even provide a large amount of storage for free! After that I was navigated to my dashboard where I found the SDK Setup, which gave you code snippets for many languages, that help the configuration process.

RAILS

For our Rails setup, I ran gem install cloudinary, and then in a storage.yml file, added cloudinary: service: Cloudinary. Rails comes fully loaded with Active Storage as a built in method for handling image uploads, and running rails active_storage:install and rails db:migrate, abstracts away the set up for a polymorphic join table between active_storage_blobs and active_storage_attachments, which you will notice now exists in the schema. We won't touch these tables going forward, but this stores lots of information about the upload, and an attachment to it.

In the model, we will use this reference to an attachment, where we set has_one_attached :image instead of creating a column in the database. We add Rails.application.routes.url_helpers to the code at the top of the model, which can be used to generate URLs given a set of parameters. In the serializer, I will call the get_image_url method as an attribute to send the client a url generated for self.image.

class User < ApplicationRecord
  include Rails.application.routes.url_helpers

  has_one_attached :image

  def get_image_url
    url_for(self.image)
  end
end

Then on my React front end, I can simply set an <img src={user.get_image_url}>!

NODE & EXPRESS

Using Node, Express, and MongoDB (with Mongoose) has been a fun process. I ran into a lot of errors and got to have some fun debugging by going over lots of juicy documentation. I landed on using a few packages: npm install cloudinary multer multer-storage-cloudinary.

In a non relational database, we still use a Schema to organize and validate data. Using mongoose seemed like a good way to go. A new Schema is quickly available by importing mongoose and {Schema}. The same way we only stored information about the uploaded image, instead of the image data in the database, we set the image object to contain a url, with a type of String.

const UserSchema = new Schema({
image: {
    url: {
      type: String,
    },
  },
});

After creating the Schema, we are ready to configure Cloudinary. In the code below, cloudinary.config refers to the section above on the SDK Setup.

Multer is a piece of middleware for handling multipart/form-data, primarily for uploading files. It creates a body object, and a file object and adds them to the request object. The file object is what we will use to upload the image, but the body will make sure that other pieces of data sent in the request are processed properly for their data types as well. Multer-storage-cloudinary is a storage engine that easily allows you to configure storage, using options passed in as params. Choose from an extensive list of optional parameters. Params itself is also optional, so the only requirement is the Cloudinary API object.

const multer = require("multer");
const cloudinary = require("cloudinary").v2;
const { CloudinaryStorage } = require("multer-storage-cloudinary");

cloudinary.config({
  cloud_name: "eleni",
  api_key: "<your-api-key>",
  api_secret: "<your-api-secret>",
});

const storage = new CloudinaryStorage({
  cloudinary: cloudinary,
  params: {
    folder: "users",
  },
});

const parser = multer({ storage: storage });

We created the parser which is the last part of our middleware, and it is inserted into the route, where it will capture the incoming request, attach a file, and pass it along. Here in the route we create an image object, and set the url (which we created in the Schema) to one of the properties of the file object, the path, which is a url pointing to where the image is stored on Cloudinary! And then we create the rest of the new user and send it to the client, where it can be accessed by adding <img src={user.image.url}>

router.post("/<your-endpoint>", parser.single("image"), (req, res, next) => {
  const image = {};
  image.url = req.file.path;
  const user = new User({ ...req.body, image });
  user.save();
  res.json(user)

ONE LAST TIP

My biggest & silliest hang up working this, was because in my server.js file, I was using body-parser and running app.use(bodyParser.urlencoded({ extended: false })). When I switched to using app.use(bodyParser.urlencoded({ extended: true })) ... it was a pretty glorious moment!

THE RESULTS

I honestly don't know which I prefer. I wrote this with hopes that it would help me decide if I preferred either, and the answer to that is still undefined 😂. Both languages and environments handle image uploads beautifully. Rails and Active Storage require less packages and configuration, but Node and Express allowed more flexibility as far as control of the data. Comment and let me know which you like better!

using actioncable for websockets with a streaming api endpoint

Eleni Papanicolas — Fri, 25 Mar 2022 14:18:59 +0000

What are websockets?

Firstly, we know that HTTP is a unidirectional communication protocol that uses a request and response cycle. Each time a new request or response is sent, a new connection must be established. We see this often in fetch calls to RESTful APIs.

Just like HTTP protocol uses http:// and https://, websockets use ws:// and wss://. This diagram shows the major difference between HTTP and websocket connections.

After the request is sent in a websocket connection, instead of the connection closing and a response being initiated, the client and server have a handshake that allows the connection to be upgraded to websocket. This communication link is bidirectional, or full-duplex, and remains open so that messages can freely be exchanged between server and client without interruption until the connection is closed by either side.

What can we do with them?

Websockets are used in all sorts of real-time applications. I recently developed a full stack application that lets users create event boards to follow hashtags, and use those boards to stream live tweets from Twitter by connecting to Twitter's Streaming API endpoint. I wanted to share how I got started using Ruby on Rails ActionCable for websockets on the back end and @rails/actioncable npm package for the React front end.

Ruby on Rails comes with a built in package called ActionCable which provides seamless websocket integration on the back end. Once a channel has been established, we are able to easily call on ActionCable to broadcast anything we'd like!

To create this project I signed up for Twitter Developer Credentials and stored my API Keys in an config/application.yml file which I hid with a .gitignore file. I had decided on using Twitter's Filtered Stream endpoint, so I went to the Twitter-API-v2-sample-code repo to get started. The repo contains examples of all of the different streaming endpoints and sample code in multiple languages.

The filtered stream endpoint group enables developers to filter the real-time stream of public Tweets. This endpoint group’s functionality includes multiple endpoints that enable you to create and manage rules, and apply those rules to filter a stream of real-time Tweets that will return matching public Tweets. This endpoint group allows users to listen for specific topics and events in real-time, monitor the conversation around competitions, understand how trends develop in real-time, and much more.
developer.twitter.com

The sample Ruby code for connecting to the streaming endpoint looks like this:

# Connects to the stream and returns data (Tweet payloads) in chunks
def stream_connect(params)
  @options = {
    timeout: 20,
    method: 'get',
    headers: {
      "User-Agent": "v2FilteredStreamRuby",
      "Authorization": "Bearer #{@bearer_token}"
    },
    params: params
  }

  @request = Typhoeus::Request.new(@stream_url, @options)
  @request.on_body do |chunk|
    puts chunk
  end
  @request.run
end

At this point I was able to connect to the stream in my Rails console by running TwitterStream.stream_connect() which was very exciting. Further configuration is required to make use of the raw data our connection is receiving.

First we need to create the TweetChannel, which can be done manually or by running rails g channel tweet to have Rails generate one for you. Then we need to add in a little more information to let the channel know where to stream from. I go over this more below in the section on the front end setup.

class TweetChannel < ApplicationCable::Channel
  def subscribed
   stream_from "tweet_#{params[:rule]}"
  end
end

In my EventsController, I have an action that is triggered by a front end fetch request, that calls TwitterStream.stream_connect(event) and passes in an event object with some properties that I use to modify the way this application connects to the Twitter streaming endpoint. The starter docs provided by Twitter are a great place to start but of course every application will have unique needs, and there is so much more we can add in ourselves.

 def self.stream_connect(event)
    puts "Connecting to Twitter Stream"
      params = {
          "expansions": "attachments.media_keys,author_id,entities.mentions.username,geo.place_id,in_reply_to_user_id,referenced_tweets.id,referenced_tweets.id.author_id",
          "tweet.fields": "author_id,created_at,entities,attachments,geo,id,in_reply_to_user_id,lang,public_metrics",
          "user.fields": "name,username,verified,profile_image_url",
          "media.fields": "preview_image_url,alt_text,url"

      }

      options = {
          timeout: event.timeout,
          method: 'get', 
          headers: {
              "User-Agent": "v2FilteredStreamRuby",
              "Authorization": "Bearer #{BEARER_TOKEN}"
          },
          params: params
      }

      request = Typhoeus::Request.new(STREAM_URL, options)
      request.on_body do |chunk|
        ActionCable.server.broadcast("tweet_#{event.rule_id}", { body: chunk});
      end
      request.run
  end

So we can see that above in the original sample code, Twitter had puts chunk which printed to the console any incoming data, which I replaced with ActionCable.server.broadcast("tweet_#{event.rule_id}", { body: chunk});, which is sending the params event.rule_id to the TweetChannel we created above, and also sending the chunk of raw data out to make its way to our front end. That single line of code is the game changer here, allowing us to simply broadcast anything coming through the websocket from Twitter, directly to the TweetChannel, and then on to our React front end.

Lastly, let's make sure to put mount ActionCable.server => '/cable' into our config/routes.rb to make sure we have somewhere to send a request for a websocket connection.

The Ruby on Rails docs has a lot of great information on how to use ActionCable in different parts of your application. But lets move over to the front end to see how all of this fits together.

Front end

The first step is to install the @rails/actioncable npm package so that we can connect the front end with our rails back end. Run npm install @rails/actioncable and we are ready to go.

import { createConsumer } from "@rails/actioncable";
import { useRef } from "react";

export default function Event() {
  const cable = useRef();

  useEffect(() => {
    if (!cable.current) {
      cable.current = createConsumer("ws://localhost:3000/cable");
    }

    // lets the back end know the channel to broadcast on
    const channelObj = {
      channel: "TweetChannel",
      rule: event.rule_id,
    };

  const handlers = {
      received(data) {
      // here you can add code to do something with
      // the data received from the websocket connection
         },
      connected() {
        console.log("connected");
         },
      disconnected() {
        console.log("disconnected");
        cable.current = null;
         },
      };

    const subscription = 
      cable.current.subscriptions.create(
      channelObj,
      handlers
    );

    return function cleanup() {
      subscription.unsubscribe();
      cable.current = null;
    };
}, []);

Above is some very basic boilerplate code for getting started. Consumers require an instance of the connection on the client side. Using createConsumer() will get a connection to /cable ready on the server by default. But it won't actually do anything until you have specified a subscription. With our handlers and our channel object we are getting our parameters ready to be passed in to cable.current.subscription.create(). At the top of the file we create a variable cable and assign it to useRef(). This, combined with the code checking for !cable.current, ensure that we do not create a new subscription every time the component is re-rendered. This is going to help avoid glitchy behavior, and especially if in use with a chat style app, this will help avoid duplicate or out of order messages. The useEffect will make sure that this subscription is created, or found, on component renders.

The channelObject has 2 key/value pairs channel: "TweetChannel" and rule: event.rule_id, which correspond to the TweetChannel that we created earlier. When the subscription is created on the front end, it sends the information to the TweetChannel which it uses to stream_from the correct websocket connection.

class TweetChannel < ApplicationCable::Channel
  def subscribed
   stream_from "tweet_#{params[:rule]}"
  end
end

In the received method of the handlers variable, I take the incoming data, create a new Tweet object, where it is then added to a Tweets array, and animated onto the screen.

This project was the absolute most fun to create, and if you would like to see more details about it, check out this demo video.

Github repositories:
Front end: https://github.com/e-papanicolas/tweet-front-end
Back end: https://github.com/e-papanicolas/tweet-back-end

the full stack && how it all comes together

Eleni Papanicolas — Wed, 26 Jan 2022 22:12:28 +0000

So, back end + front end = full stack ...right?

It's not as simple as that. A quick google search got this as the definition of full stack:

In technology development, full stack refers to an entire computer system or application from the front end to the back end and the code that connects the two. The back end of a computer system encompasses “behind-the-scenes” technologies such as the database and operating system.

Ok, so let's break this down together.

There is a great analogy of a restaurant that helps in understanding the concept of front and back ends in development. As a former industry member, this one is fun for me to talk about! In a restaurant, the kitchen is considered the back of house and the dining area is the front of house, and so those who work in the kitchen work in back of house positions, and those who work in the dining area work in front of house positions. The whole restaurant in this situation would be our full stack application. In the restaurant, a server is going to take the order of the guest and send it to the kitchen, then receive the food when it is ready, and bring it back to the guest. In the same way, our front end, or our client, is the guest. Our back end is the kitchen. Our restaurant server is the middleware, or the code that connects the two ends. So from this we can see why back end + front end = full stack isn't so simple. We have lots of other moving parts as we get further into what each end fully encompasses.

The code on the front end, or the client side, handles what users interact with. Front end languages include HTML, CSS, and JavaScript and there are even more frameworks to go along with them.

The back end is everything that is not visible to the client. The server and the database are two separate pieces of the back end. Some popular back end languages are Python, Ruby and PHP, as well as corresponding frameworks. Popular databases include MySQL, PostgreSQL, and MongoDB.

It can be a bit daunting to just get started with so many options and so many different pieces to fit together. Today we are going to go over a quick and easy way to get a full stack application up and running using JavaScript and React.js for the front end, and SQLite for our database. For the back end we are going to use Ruby, and the Sinatra library.

front end

Let's get started! The front end seems like a good place to start, it has a little bit less going on. So first, in your terminal you will want to run $ npx create-react-app <my-app-name-here>. Note: Make sure you use npx and not npm to make sure that you are getting the latest version. This command will install packages and create a new folder with a basic file structure to help you get started. $ cd <my-app-name-here> and run $ npm start.

You should see success messages in the terminal, and if you open http://localhost:3000 your app should be up and running with the initial files provided by React.

React has robust documentation here, as well as a great guide to quickly getting started.

After the creation of the project the file structure should look like this:

my-app-name-here/
  README.md
  node_modules/
  package.json
  public/
    index.html
    favicon.ico
  src/
    App.css
    App.js
    App.test.js
    index.css
    index.js
    logo.svg

With the exception of public/index.html and src/index.js, the rest is ours to change, edit, build, add to! Make sure to run $ npm install to install any dependencies in the package.json file, and again anytime you add new ones. Once you have built out the front end some more, added components, used some hooks...it's time to get the back end up and running.

back end

Let's take a look at the file structure first.

app/controllers is where we store the code for writing the web server
app/models is where we store the models, which are responsible for accessing and updating data in the database
config folder will hold our environment setup, is where we require files and gems, and establish a connection to the database
config/database.yml is where we will establish a connection to the database
db/migrate is where our database migrations are stored, of which are responsible for creating and altering the structure of the database
db/schema.rb is auto-generated by the current state of the database and gives an overview of the structure of the database
db/seed.rb lets us easily add sample data to the database while it is being developed and tested
config.ru is the file that runs the code for writing the web server that is stored in the controllers
Gemfile is where we list all the gems our application depends on
Rakefile is where we can store code for common tasks so we can easily run them from the command line

To get started, in a Gemfile, we are using the following gems:

sinatra, thin, rack-contrib, rack-cors, activerecord, sinatra-activerecord, rake, sqlite3, and require_all

Run $ bundle install to install all the dependencies. Anytime we add a gem we will need to rerun that command.

In the config folder we will need an environment.rb which will require all of our files and gems and ensure that everything is connected properly.

# config/environment.rb

require 'bundler/setup'
Bundler.require(:default, ENV['RACK_ENV'])

# Requires in all files in 'app' directory
require_all 'app'

database

The database.yml file is where we will give Active Record, one of our gems, all the details it needs to establish a connection to the database. We are using SQLite for this demo but Active Record also has support for other databases.

# config/database.yml

default: &default
  adapter: sqlite3
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  timeout: 5000

development:
  <<: *default
  database: db/development.sqlite3

test:
  <<: *default
  database: db/test.sqlite3

production:
  <<: *default
  database: db/production.sqlite3

Once we have established a connection to the database, we can begin to create migrations that will create and alter the structure of our database. Rake will help run our migrations when we run $ bundle exec rake db:create_migration NAME="<table-name>. A new file will appear in the db/migrate folder. The names of the files should not be modified because they are created with a timestamp so that Active Record knows the proper order to run the migrations in. Once we have created our migration file we will need to add the necessary information to create the actual table and then we can run $ bundle exec rake db:migrate to migrate those changes to the database.

db/seeds.rb is where we will create dummy data to populate the database during development. It will be helpful for us to have this information to test out our models next.

app/models will hold one file for each table in the database. In here we will define the class that will represent the model, and it will inherit from ActiveRecord::Base to gain all of the methods the gem gives us. We can also add custom methods and associations to other tables.

# app/models/Item.rb

class Item < ActiveRecord::Base
  belongs_to :location
end

server

The config.ru will require the environment file, and will run our application controllers and write our server, which you can see above next to the file structure overview.

Using Sinatra for this is quick and easy, as we did above, adding the gem "sinatra", "~> 2.1" to our Gemfile. Then we can start defining our routes in app/controllers. It is convention to separate the application_controller routes into a single controller file for each model. So if there was a model named Item in a table items, the corresponding controller file would be items_controller.rb.

In this file, when defining the class for the controller, it is convention to use the capital case version of the file name; it will inherit from Sinatra::Base so that we can use all of the methods included in the gem. As we can see, there are a few examples of CRUD actions using our new routes.

The Rakefile is where we can define processes that are repetitive during development, but we do not want to have to do manually each time. Currently in this file there is a server command and a console command.

Now we get to connect everything with the front end. Once we have our back end server running, on the front end, in our React components we can define a quick get request to an endpoint on our back end which will get the list of all items that we defined in our controller file.

fetch(`http://localhost:9292/items`)
.then(res => res.json())
.then(console.log)

We have success! A list of items is returned back to our front end. Now we can build out more endpoints on the back end, so that our front end can request more data, can request more organized, sorted, up to date data. So many possibilities!

As you can see, the full stack is a lot more complex than just 1 + 1 = 2. This tutorial was made to provide a quick, straightforward way to get the bare bones of a full stack application up and running. Happy coding :)

REACT-ing gracefully with controlled components

Eleni Papanicolas — Tue, 21 Dec 2021 15:49:19 +0000

I'm just a girl, searching for the single source of truth.

What are controlled components, and why? React form elements are similar to regular HTML forms in setup, but they are able to perform some extras for us when we use State. Unlike HTML forms where elements would typically maintain and update their own state based on user input, React uses mutable state that is kept in the state variable and is updated with setState(). But, using these methods together, is what brings us to that glorious single source of truth. When we tie the value of the element form to the state controlled by React, we form a controlled component. A controlled component derives its input values from state.

We are able to use state with HTML elements like <input />, <select />, and <textarea /> when we pass it a value prop of the current state.

Let's start with a quick form setup with two inputs below.

import React, { useState } from "react";

function myControlledForm() {
  const [name, setName] = useState("");
  const [favoriteColor, setFavoriteColor] = useState("");

  return (
    <form>
      <input type="text" value={name} />
      <input type="text" value={favoriteColor} />
      <button type="submit">Submit</button>
    </form>
  );
}

export default Form;

Here we have set up a state variable name and it's setter function setName. It has an initial state declared as an empty string, but which will be updated as soon as, and every time setName is called.

In the form elements themselves, we are tying the first input to the name state and the second input to the favorite color state. But we still need to wire up the onChange event listener to an event handler callback function.

<input type="text" onChange={handleNameChange} value={firstName} />
<input type="text" onChange={handleColorChange} value={lastName} />

By adding this event listener to an input as a prop, it will listen for change events. Each change, a callback function will fire to capture the user input value, and update its state variable.

It is typical naming convention for your callback function to be named corresponding to the state variable it is handling the change for.

function handleNameChange(event) {
  setFirstName(event.target.value);
}

function handleColorChange(event) {
  setLastName(event.target.value);
}

These functions use the event.target.value, which is being provided by the inputs onChange event handler to update the state variable using its corresponding setState function, which we declared above. When we update the state, we cause a re-render, and a cycle is completed.

Why use controlled components though? Here are some key benefits:

Controlled inputs allow for more control over inputs and data.
When we use state to store form input values, we can then share state with other components, and make changes in our applications. All components using this value will always have access to the exact same, current value.
When we set up a form component, we can set the state in its parent component, and pass down variables and event handlers as props. This setup can allow for more dynamic changes in other parts of the application.
We can also send the form data to other parts of our application for storage or for posting to a database.
Controlled inputs can be validated.

There are some really cool implementations of controlled inputs; I like to think about filtering search results as you type. Just the same way we controlled this simple input form with onChange and a callback, we can use these search values derived from state in a more scalable, expansive application to search and filter through all sorts of data.

how to prepare for flatiron school // resources i used

Eleni Papanicolas — Tue, 30 Nov 2021 14:32:04 +0000

Looking over the Flatiron School website and reading about the Software Engineering Live program, I felt a sense of excitement alongside a sense of dread. Questions swirled around my head for days as I pondered my decision to do this. Is it right for me? Is it wrong for me? Am I smart enough? Will I be able to absorb all of this information? But the one question that was above all other questions: Am I prepared enough?

I wouldn't be able to answer this question though, until I had begun the program. As I pored over the pre-work, I felt a sense of relief. I seemed to have a grasp on what was being asked of me. And as I power through Phase-1, that feeling, albeit unsteady, persists.

That being said, I wanted to share some of the resources I used in my journey towards Flatiron School.

Years ago, a friend had made a career change into tech by teaching herself and using Codecademy. So this year, when I decided myself to make a similar leap, this seemed like a natural starting point. After taking a few free lessons on the Codecademy website, I decided to upgrade to the Pro version. The options were simple: $40/month on a monthly subscription, or $20/month for a full year subscription. I immediately sprung for the yearly subscription and it was 100% worth the purchase. Codecademy has seemingly endless courses, ranging from Intro level, Skill Paths and even Career Paths.

The courses I dabbled in:

Build A Website with HTML, CSS, and Github Pages
Learn Javascript
Front-End Engineer Career Path

And these were only a few of the possibilities and options available. Subjects such as Data Science, Machine Learning, Game Development and Cyber Security are offered as Career and Skill Paths. Python, JavaScript, SQL, Ruby, PHP and Swift are among the many languages they also offer courses in. Learning on Codecademy certainly set me up for success in my continuing education and I plan to keep my subscription for further learning in the future.

As I got more and more into the development community, I began listening to a few coding podcasts to hear from others in the coding community and try and understand how to relate the information to my own path forward. The Code Newbie Podcast quickly became a favorite of mine. I loved listening to the host Saron interview her guests about their own journeys into tech, discuss the subject of the day, and then relate it to code newbies like myself. Listening to this podcast gave me different bits of information on various aspects of breaking into the tech world, and also led me to my next learning resource.

One guest on the Code Newbie podcast, was someone I had previously read about and heard talk on another podcast, so when Wes Bos was featured on my favorite podcast I knew it was time to check his stuff out. They discussed a popular free mini-course that he had released called JavaScript 30, a 30 day code challenge making projects using vanilla JavaScript. That seemed a little daunting to me, but then I discovered he had released a Beginner Javascript course on wesbos.com. It seemed like a no brainer for me, as I was trying to find ways to level up. And I am so so glad I went for it. His course includes 88 video files or the option to stream the course, as well as a full Github repo containig starter files and solutions. The videos are separated by distinct subject for ease of use when re-watching or trying to find certain information. What I liked was the ability to pause the videos or code along with him. He is a fantastic teacher, and projects sprinkled in throughout the course really help show how much you are learning. I took the premium Beginner JavaScript course, but he also offers free courses on CSS Grid and Flexbox, CLI, Markdown and Redux. Some of his premium courses include Learn Node, React for Beginners, Advanced React and GraphQL, and Master Gatsby. This course left me hungry for even more learning. Which led me to... you guessed it! FLATIRON!

By this time in my personal journey, I was really feeling like I had a precarious grasp on the fundamentals, but no idea how to tie it all together. Upon a recommendation from a friend who had been through Flatiron's Software Engineering Live, I decided to pursue the Full Stack route, with hopes that I could utilize everything I'd learned and once again, level up.

Some other great resources that I have found helpful along the way:

I can't wait to share more with you about my Flatiron coding journey. Stay tuned.