DEV Community: Fredie Aponte

ShowGO: The Concert App

Fredie Aponte — Fri, 22 Dec 2023 03:49:13 +0000

As my capstone project, ShowGO emerges as a monument to the harmonious integration of backend robustness through Ruby on Rails and the sleek responsiveness of React on the frontend. This full-stack application is not just a platform for event discovery and band exploration; it's a carefully crafted ecosystem that prioritizes user security, personalization, and an intuitive interface. Let's delve into the intricacies of ShowGO, exploring its core technologies, user-centric features, and the seamless blend of form and function.

The Tech Behind the Curtain:

At the heart of ShowGO lies the power of Ruby on Rails for the backend, providing a solid foundation for data management, routing, and authentication. Bcrypt, an encryption algorithm, takes center stage for password authentication, ensuring user data remains secure. This combination forms the backbone of ShowGO's reliability and performance.

Active Storage, another key technology in the ShowGO toolkit, brings a dynamic element to user profiles. This feature enables users to effortlessly upload their profile pictures, personalizing their experience and fostering a sense of identity within the platform. As users sign up, they are greeted with a secure and seamless onboarding process, setting the stage for a rich and engaging user journey.

Admin Power and User Privileges:

One of ShowGO's distinctive features is the implementation of user roles. The first user to join the platform is bestowed with the coveted title of admin. This strategic decision opens the door to exclusive capabilities, allowing the admin to shape the platform's content and functionality. From creating and deleting venues and bands, to exercising full CRUD (Create, Read, Update, Delete) control over events, the admin role provides a curated and organized experience.

Subsequent users, while not adorned with admin privileges, enjoy the full spectrum of ShowGO's features. This deliberate segregation ensures that the platform remains user-friendly and accessible, catering to both casual users and those with a more vested interest in managing the platform's content.

Profile-Centric Design:

ShowGO recognizes the importance of personalization in creating a meaningful user experience. Upon signing in, users are ushered into their personalized space—their profile page. This space becomes a canvas for self-expression, displaying the user's chosen profile picture alongside their unique username.

The profile page is not just a static display; it's an interactive hub. Sections dedicated to attending events and favoriting bands empower users to curate their ShowGO experience based on their interests. This profile-centric design adds a layer of intimacy to the platform, fostering a connection between the user and the vibrant world of events and music.

Intuitive Navigation for Seamless Exploration:

Navigating through ShowGO is an intuitive and visually appealing experience, thanks to its well-designed navbar. The home page serves as a dynamic gateway, featuring a curated selection of three random venues and bands. This thoughtful presentation ensures that each visit to ShowGO unveils new and exciting possibilities for exploration.

The navbar's design goes beyond aesthetics; it serves as a roadmap for users to navigate the platform effortlessly. The Venues, Bands, and Events routes provide a comprehensive overview of the local music scene. The Venues page unfolds a list of venues, each a portal to a world of musical experiences. Clicking on individual venues reveals detailed information, including upcoming events hosted at that location.

Similarly, the Bands page showcases a diverse array of musical acts. Users can explore each band, gaining insights into their upcoming performances and events. The Events page performs the same way. ShowGO transforms the exploration of the local music scene into a visually stimulating and informative adventure, making the platform not just a utility but an engaging destination in itself.

Standing Ovation:

In the symphony of ShowGO, Ruby on Rails and React harmonize to create an unparalleled experience in event discovery and band exploration. From the solid foundation of backend technologies to the seamless frontend interactions, ShowGO is a testament to the fusion of form and function.

Whether you're an admin shaping the platform's content or a user immersing yourself in the local music scene, ShowGO invites you to explore the future of event discovery. With its emphasis on security, personalization, and intuitive navigation, ShowGO stands as a beacon of innovation in the ever-expanding landscape of digital experiences. As you embark on your ShowGO journey, prepare to be captivated by the dynamic fusion of technology and user-centric design, creating a platform that resonates with both casual users and music enthusiasts alike.

Arcadia: A Full-Stack App

Fredie Aponte — Thu, 09 Nov 2023 01:04:59 +0000

Riding the Rails

Learning the core fundamentals of both front-end and back-end languages has been a rollercoaster of trial and error. Ultimately though, I have made it to this current point: creating a full-stack web app that I am proud to call "Arcadia"! The program utilizes Ruby on Rails back-end server side and React front-end UI to provide an arcade rating experience.

Creating the Back-End

To start off process, Rails had to be configured to not only initialize with the prefix client, but also accept cookies and store in sessions with middleware. Once configured I can move on to creating the database. The first to get created are my models. There are three of them: User, Arcade, and Review. Each model will have their own attributes pertaining to themselves, such as 'name', or 'username', with the join table of reviews containing a 'body' attribute along with 'user_id and arcade_id'.

Here, the Arcade is the resource that will be joined to Users via the Reviews table. Arcade has many reviews, and has many users through reviews. Users has many reviews, and has many arcades through reviews. Once the attributes are declared, I run the migrations to create the database table.

To return specific JSON I'll need to create some routes for each of the models. In this application, my intention is to have full CRUD capability in the Reviews model, with only Create & Read functionality to the rest which the exception of Session(more on that later). I can return specific JSON in the response to the request by the client with what are called Serializers. Serializers allow me to literally pick and choose which attributes I want to return, or add to, to return as JSON. This is especially useful for omitting automatic attributes like timestamps when models are created, and so on.

I can now move on to creating controllers. Each controller will belong to a model and be responsible for providing methods associated with the model's routes. These methods are called 'actions' and are what drives the logics behind client requests and server responses. Here, you can provide the validations (in the models) and handle error logic as well. What this means is, whenever a user is looking to create data with bad input, the controllers responsible can reject the submission, provide an error in response, and it also will not persist that bad data to the backend.

Diving into controllers, we can create a "sessions controller" which is responsible for logging in a 'User' to the app through cookies and sessions. When a user submits through a login form their username and password, the sessions controller will run an authenticate check to see if the password hash provided matches that of the users login info. This is thanks to the ruby gem 'BCrypt'. This gem provides us a way to safely store user login information without it being compromised.

The way my application controller is set up, I made it so that all the error handling logic can be contained in the applicationController and all those actions can be inherited by the rest of the controllers. This allows for cleaner non repetitive code. Once the authorization and authentication protocols were established, I can move towards the front-end UI side of things.

The way I tested my api without a proper front-end in place was by using Postman. I've had to "skip before actions" of authorizations just to test that that JSON I requested responded as such as the way I intended them to. Once I ran my migrations and seeds I felt everything was good to go.

Login & Authentication

The authentication/ authorization logic is mainly housed in the back-end. However, thats not to say you could not hold conditional rendering into the components you render on the front-end! For instance. There are URL routes that will lead to lists of Arcades and or Reviews. Unless you are actually logged in, you cannot ( or should not ) be able to even see the data that belongs there. A better case is saying, when in the home page of the app, if you are not logged in, will see a message stating to signup or login to use features. When you log in, that same home page will display different data; Like your Username and maybe the reviews you have written.

Ive Learned how important it is to protect your URL routes as well as back-end routes from unauthorized querying. It is critical to understand how forgetting to cover your tracks can lead to unwanted exploits from malicious users.

Front-End UI

The UI was relatively simple. I first started with using a react hook called 'useContext'. The way I understand it, basically, is a way to provide "props" to any child component without the need to prop drill. That is FANTASTIC! With that said, I created the a context file for User that will hold in state whether or not a user is 'logged in' or not. I can then pass that state to any child component that needs it.

I started with the Navbar. Once I made a route to home ('/') the Navbar will decide whether tho show the Login, and Signup buttons. Once a User does either, the User object will be in state and a boolean of "loggedIn' will set to true. This simple state passed down to children easily allows for ternary or conditional rendering! When a user is 'logged in' the context keeps the current logged in user object in state. As soon as they log in, the Navbar will show a 'log out' button that will reset the context to empty objects and false boolean values.

All that was left to be done was to tidy up the rest of my components. I made routes to the arcades that you can only access when logged in. If you were to enter into the URL bar:'.../arcades' to try and access that route manually, you will be met with not only an unauthorized error message in console log, but also the /arcade route rendered will display in UI that you must be logged in. That is the magic of the conditional rendering on the front-end!

The Full-Stack

It was tricky to completely code the UI after completing the back-end as I should have used a more vertical approach to its development. It would be best to work on the login/signup features first. This way saves a ton of error messages and angry exceptions...All in all, its relieving to see Arcadia in its finality and realize the potential for future apps to come.

Core Ruby

Fredie Aponte — Thu, 17 Aug 2023 01:37:26 +0000

Ruby is an object-oriented programming language, crafted by Yukihiro Matsumoto in the mid-1990s. Ruby is driven by a philosophy that prioritizes developer happiness and productivity. With its clean and intuitive syntax, Ruby enables developers to write code that reads almost like spoken language, making it an ideal choice for both beginners and experienced programmers. Known for its versatility, Ruby finds application in a multitude of domains, from web development and scripting to scientific computing and more. Whether you're a seasoned developer or just starting your coding journey, Ruby's welcoming and intuitive nature makes it an ideal choice for crafting powerful and elegant solutions.

Ruby involves classes & objects; In Ruby, everything is an object.

Classes, Instances; Methods & Variables:

Ruby utilizes what are called ‘classes’. These classes are responsible for acting as a ‘factory’, providing a ‘blueprint’ to create objects (or instances). When creating a class, methods (like a function) are defined to perform a specific task on any instances (objects belonging to its pertaining class) and are respectively called ‘instance methods’.
Like instance methods, ‘class methods’ may be declared to provide some functionality to the class as a whole.

For example: we can create a Car class to create Car instances (objects) with instance variables such as make and model.

Let’s declare a class variable @@wheels to equal 4.
What this means is, any car instance created can have their own make and model when instantiated (and arguably, same makes and models if were so the case) but ALL car instances will have the wheels attribute already set to 4.

We can then add these setter and getter methods:

Instance variables are variables(or attributes) within an instance that can contain different data values when instantiated. Of course, these values may be accessed and manipulated if need be with setter methods and getter methods.

There is a useful shortcut for writing cleaner code:

With this handy macro attr_accessor :make, :model, Ruby automatically generates both getter and setter methods for the make and model instance variables. This simplifies the code and reduces redundancy. You can then use these generated methods to retrieve and update the values of the instance variables. If you only wish to read the data, then you must use attr_reader :attribute. The symbol to refer instance variable is @

Class variables, are like instance variables, with the exception that they are variables containing the same value across the whole class. Instance and class variables can be instantiated without a value, and that value can be added or removed at any time from within an individual instance, or the class itself; provided the methods to do so are defined. While that is possible, take caution manipulating class variables in individual instances for that may bear unwanted side effects. These side effects will only happen to parent or sub classes that may be inherited/inheriting.
The symbol to refer class variable is @@

Active Record

There are powerful libraries that simplify the ruby experience. One such library is called Active Record .

One can create an instance belonging to a class without having to hard code many of the the methods required to create it. While Active Record does a lot of the heavy lifting for you, it is still most important to know how to do it yourself and understand what processes are being performed under the hood!

Active Record is compatible with SQLite3, a database engine. Active Record is an Object-Relational Mapping (ORM) layer responsible for managing the interaction between your Ruby code and the database, provides an elegant and intuitive way to interact with your database by representing database tables as Ruby classes and individual table rows as instances of those classes. This abstraction allows you to manipulate database records using familiar Ruby syntax, without having to write raw SQL queries.

Sinatra is a lightweight Ruby web framework.
This is the response cycle between React, Ruby, Active Record, and Sinatra, and how these technologies interact to build a web application:

User Interaction:
The process begins when a user interacts with the frontend, built using React. User interactions might include clicking buttons, submitting forms, or any action that triggers a request for data or changes in the application's state.

Frontend Sends Request:
When a user interacts with the frontend, React sends an HTTP request to the backend server. This request could be sent using a Fetch GET request to retrieve data or a POST/PUT/DELETE request to send data to the backend.

Sinatra Backend Receives Request:
The Sinatra backend receives the incoming HTTP request. Sinatra is a lightweight web framework that simplifies routing and handling requests in a Ruby application. It routes the request to the appropriate route handler based on the URL and HTTP method defined in the application_controller.

Route Handling in Sinatra:
The route handler in Sinatra processes the request. This might involve interacting with a database, performing logic, or fetching data from external APIs. If the request involves working with a database, this is where Active Record comes into play.

Active Record Interacts with the Database:
Active Record, as the ORM library, interacts with the database on behalf of the Sinatra application. It abstracts away the details of the database and provides a more Ruby-like interface to work with the data. Active Record retrieves or modifies the required data from the database using models and associations.

Sinatra Sends Response:
Once Sinatra and Active Record have processed the request and gathered the necessary data, the Sinatra route handler generates an HTTP response. This response contains the data or information that needs to be sent back to the frontend.

Frontend (React) Receives Response:
The React frontend receives the HTTP response from the Sinatra backend. The response often includes JSON data or other relevant information that the frontend can use to update the user interface.

Updating the UI:
Based on the data received in the response, React updates the user interface. This might involve rendering new components, updating state, or modifying the DOM to reflect changes.

User Interaction Continues:
With the updated user interface, the user can continue to interact with the application. This interaction can trigger additional requests to the backend, starting the cycle again.

The response cycle between Ruby-based backends and frontend frameworks like React host dynamic, interactive, and user-friendly web experiences. Ruby's syntax, combined with the structure provided by Sinatra and the data management offered by ActiveRecord, promotes the creation of seamless, well-organized, and maintainable web applications.

In conclusion

Ruby, along with its powerful tools like ActiveRecord and Sinatra, provides a robust foundation for building web applications that seamlessly integrate with frontend frameworks. ActiveRecord serves as an efficient Object-Relational Mapping (ORM) library, simplifying database interactions and allowing developers to work with data using object-oriented principles. Sinatra, a lightweight Ruby web framework, is great for building RESTful APIs and small to medium-sized applications.

React Fundamentals

Fredie Aponte — Tue, 04 Apr 2023 07:08:37 +0000

REACTion

As a novice coder, getting into React felt like stepping into a whole new world hidden in your backyard. It was as relatable as it was astonishing to see JavaScript used in a new versatile way! Having a base knowledge of JavaScript may give you a jumpstart, but React has some tricks up its library to simplify how you develop web apps!

JSX & Functional Components

React typically utilizes a special syntax called JSX (JavaScript EXtensible Markup Language) that combines html and Javascript. The code is rendered in such a way that it will create html elements with whatever properties (and/or other elements) that are inside, and ultimately append to a main container in the html body div called 'root'.

This is done by compiling chunks of JSX written into what are called components; the building blocks of writing React apps!

These components can be separate reusable bits of code, that can potentially be useful in other implementations within the app!

Only one component is responsible for appending your application to the 'root' div, and that is 'index.js'.

Now, you might be thinking: if only one component can render my whole application to this div, why do I need other components? Well, besides versatility, the magic of components is that you can connect them via importing and exporting their data to be sent and received by other components!

The first 'external' component to be imported by 'index.js' will always be 'App' ( or whatever you want to call it, really). This 'App' component is what will contain other components that are being exported by importing them.

Much like the DOM tree, React displays what is called the React Tree! While it may sound so similar, the React tree displays the order of which components are ordered by a hierarchy-

The 'App' component is the highest, or 'parent' component in your application, with lower sub-level 'children' components; they may be siblings by means of sharing a common 'parent', or even be parents to other 'children' components.

Here, the 'QuestionItem' component is the child of the 'QuestionList' component, that is the sibling of the 'AdminNavBar' component, and are respectively both children of the App component.

Props

Components can only send data downwards into their children via properties, or props. These props are 'passed down' from parent and received by child as their arguments.

The 'ClipBoard' component will iterate this array with the .map() method and for every element in that array will return a child component with the prop of 'name = {name}'.

The 'List' component will take in that prop of 'name' in the form of an argument and now has access to that data! With this data, 'List can return an h4 tag with the content of 'name'.

Whenever an iteration takes place, you will always want to include a 'key' prop to equal some sort of unique id; this will prevent error messages!

Prop Drilling

Sometimes, there will be cases where you need to send down information to a child of a child (or grandchild) or even deeper rooted children. this method is known as 'prop drilling'.

Prop drilling simply means passing down the same props to the children components, and from those children to their children, and so on.. This is incredibly useful for receiving data from the children up to the parent via callback functions within the children!

Inverse Data Flow

Parents can only send down data to their children via props or prop drilling. Children send data back up through the parent(s) via a callback function. This is how components work together.

For example: A child form component can contain a handleSubmit function that contains a callback function within it- which was passed down as a 'prop' from the parent, send data up to the parent component by invoking that function with the data in its argument. You will notice the data in the console log traveling from child to parent.

Be sure to be mindful of your variable names, as other developers may one day look into your code, and may be overwhelmed by how lengthy the declarations are!
The overly detailed variable names are for you, the reader to grasp the concept of react code!

State

'UseState()' is a React {Hook} that allows you to add state to a component. It returns an array with two values: the current state variable and a setter function to update it. UseState is key to utilizing and maintaining data that will eventually change within the state variable.

The {Hook} takes an initial state value as an argument and returns an updated state value whenever the setter function is called. React Hooks are JavaScript functions that are responsible for isolating the reusable part from a component.

Here, 'twins' is declared along with 'setTwins'. 'UseState' is set to an empty array. What this means is, the variable 'twins' is an empty array. 'SetTwins' is a function that takes in an argument to change/or update 'twins'.

The setter function is invoked via a callback from a child component containing 'addTwin' as a prop. It uses the spread operator to retrieve the whole array, and adds the newTwin from information sent up.

A general rule of thumb is to always keep your setter functions contained in the same component the state variable is in!

UseState can be used to contain ANY form of data and is a perfect memory bank for validating forms, sending data, and displaying items on the DOM!

These are just some of the many amazing things about React. If you're an avid coder with JavaScript, React will be a Breeze!

Dream Garage: My First Project

Fredie Aponte — Mon, 09 Jan 2023 03:39:50 +0000

Hello, I will be discussing my first coding project that I like to call, "Dream Garage". To start, it is a simple web application that allows you to add "cars" to your "garage". Hence the name, it is an app for the users to fill their garage with their dream cars.

Dream garage uses a localized API (Application Programming Interface) that I've created with four default vehicles to aggregate into the DOM (Document Object Model). Once loaded, the user can enter the name of any vehicle they wish into the 'Name" form. The user may also enter an image URL(Uniform Resource Locator) into the "Image" form.

Your garage awaits you

Below, my 'fetchCars' function fetches the car data from my local server, then takes the "(res)ponse" and invokes .json() to return an object from the servers response data. It then takes the obj (carsData), iterates each obj within and runs it through my 'renderCarCard' function. Once the 'card' is created, it will prominently display onto the DOM.

The way it works:

Fetch() is an 'asynchronous function'. Keep in mind, most code are 'synchronous'- meaning they are read and executed in order. No matter the length of your code(s), your machine still reads them in an orderly fashion. Contrary to seeing a webpage loading instantaneously, that is not the case. Longer code still, respectively, takes more time to be read and executed.

Being an asynchronous method, Fetch will 'acknowledge' its execution, but will continue to run and execute the rest of the programs code that is written. It is not bound to the order of typical code execution. This way, it returns what is called a 'promise'. If the data that is to be fetched is large (or small), time is not wasted waiting for all of that data to be received, and will continue to execute the rest of the written code.

Fetch is a global method that essentially "fetches" a resource from the network, and returns a "promise" that is fulfilled once the response is available. This method takes at least one parameter, which would be the URL of your 'resource' (an array of objects or only one object) which is where you are making the request to.

The request can be of any type of API that returns data in JSON (JavaScript Object Notation) or XML (eXtensible Markup Language). Once the data has been 'fetched' or 'requested, the method .json() converts the raw data into versatile information that can be used. This data can be used to create, read, update, or delete (colloquially referred to as CRUD)- some of the basic types of requests you can make to the server!

After the data requested has been returned into a usable format, the fetch block of code will invoke my 'renderCarCard' function, that creates a card to display the individual objects in my API.

It was not too difficult to take the parsed carsData and assemble a card. All I had to do was declare a variable with querySelector to my 'car-container' -div. I then declared a few other variables such as 'vehicle'- to contain the text content of cars.name; and 'img' to relate to an image source of cars.imgURL and created their respective elements.

Appending Cars to the DOM

The Event Listener DOMContentLoaded, will load the rest of the webpage before initializing the fetchCars function as the callback. It might sound a bit redundant, but so far the page runs as desired.

A callback function is basically a function defined within a function. Instead of writing the same code over and over again, the best practice is to save that function into a variable, and then invoking it from within another function if needed.

Here, the renderCarCard function will take all of that data, iterate through carsData using the .forEach() method. and creates a card for each object in my returned JSON. To do so, some elements must be selected, created, and then appended to the parent element that is to be displayed onto the DOM.

I took an extra moment to add a delete feature called 'TOW AWAY', which erases your car(s) from the DOM and updates the db.json by sending a delete request from the same button to update the server with the deleted 'car'.

In the form field, the 'submit' event listener will fire once the user enters their car and image of choice and hit the 'Add Car' button.

Both Functions of renderCarCard and createNewCar utilize either a POST or DELETE method to update the servers database file- or db.json. The newCar variable targets the forms inputs and creates a new car object to append to the DOM as well as the database.

Now that the desired functionality has been achieved, I took some time to play with the CSS (Cascading Style Sheets) file.
CSS is a powerful tool to control the way any developer wants their HTMl to be displayed. It is how you would want to design your webpage to appeal to the client. This includes the background, font styles, font sizes, borders of particular elements and so on. The possibilities are virtually endless.

This was a very challenging yet extremely rewarding project to build. Overcoming this hurdle is only the first step to what's to come!

-sources:
developer.mozilla.org