Forem: Melinda MacKenzie

My biggest take aways as a brand new full stack software developer

Melinda MacKenzie — Tue, 06 Aug 2024 14:11:00 +0000

HI! If you're reading this, it means that I have officially reached the end of my year(ish) long journey as a student at Flatiron school's software engineering program.

insert big sigh of relief here

I stepped into this field with absolutely no background whatsoever in tech or computers. I have a bachelor's degree in Psychology, which has absolutely no direct overlap with any form of software tech. My knowledge for computers and software was only as about as extensive as my ability to navigate Facebook and Instagram (which I'm pretty proficient at ;) ).

Upon completion of this program, I have learned not only many many technical skills, but many things about myself and my work ethic, discipline, and what really actually motivates me.

First of all- I will NEVER look at another web page or mobile application the same. I will forever now be analyzing all the work that went into building these things and their complex functionality. As a user, it's so easy not to think of what went into the creation of the particular website or app that you are using. That's the point, right? building something so flawless that a user never HAS to think about what's going on behind the scenes. Now that I have been fully submerged in the other side of things, I have come to understand the hard work and planning that goes into the development of these applications and for lack of a better word, am amazed.

Secondly, I have learned that imposter syndrome is SO real and it must be acknowledged as such, or the success rates of these programs probably wouldn't even be half of what they are currently. My mindset coming into this program was an "I can do anything", "No background in tech? No problem". The amount of times that I questioned my decision within the first month or so of the program is unquantifiable. As soon as I would finally start to grasp a new concept, I was knocked right back down by the next one. Many times, I questioned if I was really able to do this. Was it some dream that I just couldn't achieve? Psychology brains surely don't think this way- and now I see it. I had been told that imposter syndrome would creep in from time to time, but mine didn't creep- it barged in. It took a lot of positive self-talk, some tears of frustration, and lots of reaching out for support to realize that as hard as it may be, I could do it. This psychology brain of mine could make a shift. After passing each phase, I would gain a new sense of confidence and enter the next phase with an unwavering feeling of motivation and drive. Would I lose momentum gradually throughout the phase until I reached a point of nearly total defeat? Yes. Did I work through it every time? Yes. If you're questioning if you're cut out for this, the answer is yes. You can do it.

Third, if I could tell any one who is standing in the shoes that I was a year ago I would say, fake it til you make it. I know this doesn't sound like the best advice but for me, it really made all the difference. You don't know the exact answer? Give me your best shot and I'm sure you'll wind up on the right path eventually. Talk out loud as if you know what you are talking about, speak through your code, build things with confidence. The more you do this, the more you will realize that you will make it. Eventually the fake becomes your reality!

All this being said, remember that I am a full stack developer, not seasoned, but very fresh in my journey and have much to learn so if you choose to take my advice, take it lightly. Let it encourage you to really go after it, and don't let anyone- including yourself, tell you that it's not possible!

RESTful routes

Melinda MacKenzie — Wed, 31 Jul 2024 14:45:40 +0000

As we as developers begin to build our applications, whether they be small or large, we aim to create an experience that is user friendly and interactive. In order to not only make an application that is desirable to users, it's also beneficial to build something that when shared with other programmers has code that is easy to understand, and decipher for effective and simple collaboration. One common practice to follow when developing these apps is following the convention of RESTful routes.

What are RESTful routes?

REST stands for representational state transfer, which put simply is just a blueprint for defining the routes within our app. It provides a way to map our CRUD (create, read, update, delete) actions with our HTTP verbs (GET, POST, PUT, DELETE).

For the sake of giving you a real life example, I have created a fitness finder app that allows authenticated users to interact with gyms and their workout classes. Users can view all (GET) gyms, edit (PUT) a gym, delete (DELETE) a gym, add (POST) a gym, as well as write (POST) a review, view (GET) all reviews for specific gyms, and view (GET) all of their own gyms. All of these different features require specific routes. While building out these routes, I followed the RESTful routes conventions, or standard set of rules to complete these CRUD actions using HTTP verbs to make a request to my server.

A few examples of the REST API endpoints for that specific application are as follows:

VIEW (GET) ALL GYMS - '/gym'
VIEW (GET) ONE GYM - '/gym/int:gym_id'
VIEW (GET) ALL WORKOUT CLASSES - '/workout_classes'
EDIT (PUT) ONE WORKOUT CLASS - '/workout_classes/int:workout_class_id'
DELETE (DELETE) A GYM - '/gym/int:gym_id'

RESTful routes are stateless, they do not hold state from one request to another. The information needed for each request is held in that specific request only. It is a stateless transaction of data.

Another benefit to using RESTful routes when building an application is the HTTP status codes. Simple, clear status codes are effective in helping developers and clients to more clearly understand where the error in the request may be occurring.

(image from https://appmaster.io/blog/the-six-rules-of-rest-apis)

RESTful routes also follow a few basic naming conventions such as, using nouns and not verbs ('/gyms' vs '/getgyms') and using plurals to show a collection instead of singular item, keeping clear definition of parent/child relationships ('/gym/int:gym_id/reviews' to access a specific gym's reviews only, and many other conventions.

While this is only scraping the surface on RESTful routes, I hope it can give you a better understanding of the benefits to using RESTful routes when building any application.

Relationships in Python

Melinda MacKenzie — Tue, 23 Apr 2024 14:24:59 +0000

One thing that we can all be certain of when it comes to relationships of any kind in life is that chances are, they will be complicated. Complicated isn't to say the relationship itself is bad, inappropriate, or won't flourish; it just means it may take some extra work.

This simple fact remains true for Python and the different relationships we encounter when building a complex yet effective applications.

Types of Relationships in Python

There are many different relations in python but I will be touching on the two that I've encountered most as I'm finishing up my first python CLI application.

Many-to-many

In order to describe a many-to-many relationship, I will use the model from the CLI application that I built. In my particular CLI which was kept simple and to the point, I used a one-to-many relationship (which I will cover next) but for the sake of this example I will change my tables slightly. I created an "event manager" application that displays data for athletes, and their corresponding events. If I were to use a many-to-many relationship for this, I would say an athlete can participate in *many events(or races) and an event(or race) can have many athletes. The data for these tables is interacted with and queried using SQL and SQL explorer. (For the sake of this blog I will not cover that in depth, but here's a good reference blog if you're interested https://dev.to/harperdb/sql-and-relational-databases-explained-by-a-non-developer-e3a. The tables would be: an event table which would hold the data for each event(or race) such as name, date, and location, and an athlete table which would hold the data for each athlete, such as name, age, and gender. A third table, called an association table, which we will call Athlete_event in this example, would hold the data for the specific athlete(by ID) and the corresponding event(by ID).
This table is used to show the many-to-many relationship between athletes and events, which may also be referred to as a "joint table".

for Example:

CREATE TABLE Athlete (
athlete_id INT PRIMARY KEY,
name VARCHAR(100),
age INT,
gender CHAR(1)
);

CREATE TABLE Event (
event_id INT PRIMARY KEY,
name VARCHAR(100),
date DATE,
location VARCHAR(100)
);

CREATE TABLE Athlete_Event (
athlete_id INT,
event_id INT,
FOREIGN KEY (athlete_id) REFERENCES Athlete(athlete_id),
FOREIGN KEY (event_id) REFERENCES Event(event_id),
PRIMARY KEY (athlete_id, event_id)
);

This would effectively display a one-to-many relationship.

One-to-Many

One-to-many is a little less complex, yet still a slightly mind boggling to think about. In my Event Manager application, an athlete could participate in one event(or race) and an event(or race) could have many athlete's participating in it(obviously, or else, what kind of race would that be?!)

CREATE TABLE Event (
event_id INT PRIMARY KEY,
name VARCHAR(100),
date DATE,
location VARCHAR(100)
);

CREATE TABLE Athlete (
athlete_id INT PRIMARY KEY,
name VARCHAR(100),
age INT,
gender CHAR(1),
event_id INT,
FOREIGN KEY (event_id) REFERENCES Event(event_id)
);

The 'Foreign key' is the event_id in the Athlete table, which references the event that the athlete participated in. In the event table, this specific event_id is a primary key. When it is referenced in another table, in this case the athlete table, it is referred to as the foreign key.

While this particular blog just skims the surface of One-to-Many and Many-to-Many relationships, I hope it has given you a basic understanding of the types of relationships we can explore and build in order to handle data as efficiently and easily as possible.

SOURCES:

React Component Hierarchy

Melinda MacKenzie — Tue, 16 Jan 2024 20:27:08 +0000

If you've found yourself on my page, chances are you're learning the very very basics of React- just like myself. At the 'root' (😉 ) of building a react application , you will find one very important concept- the react component hierarchy.

In order to understand react component hierarchy, we must first understand what a component in react is. I prefer to think of components as the individual building blocks of the entire application itself. Components are individual 'parts' of the app, that will return the react elements that will become what appears on the screen for the user.

In the beginning stages of building a react app, developers must make a rough "frame work" of the way they would like to break their app down into "components". Typically the 'root' or base of the app itself will be the component titled "App" which encapsulates the application as a whole, the outermost layer as I think of it in my mind. Depending on what kind of application you're building, other components could be things such as "header", "search bar", "nav bar", "links", "link container", "form", "form container", etc; all things which make up the application.

How do we bring all of these separate components together in order to make the application function as a whole? That is where the component hierarchy comes into play. Information can be shared, and passed down to children in the form of "props" or passed up to a parent using a callback function. Developers must follow the rules and guidelines for sharing information amongst components. Most prefer to visualize the component hierarchy as a "tree", with the parent component at the top and children and neighboring components flow down from the parent.

More specific to our example is this..

We are in the top component "app", which has the children components of "header", and "main container". Information can be passed directly down to the children in the form of props. The children "header" and "main container" may also have children, which can then also be passed down the information that came from "app".

As we know, not all data is static data. More often than not a user can interact with the application, causing a change in the data, or change in "state". At the very basic level, if two components need access to the same state, the state must be "lifted up" to the most common ancestor of both of the child components.

For example

In this particular example, the parent component is "app" which has multiple children, "Home", "Bath", "Car", "Feeding", and "Sleep". All of these children need access to the data, in this case an array of "items" and the state of this data will change depending on which category (corresponding components) a user clicks on. Due to the fact that these sibling components ALL need access to the same state, we have "lifted up state" and stored the state in the common ancestor component "app". Now all children components have access to that state.

The more complex an application becomes, the more difficult it is to share information and data amongst components. In order to develop code that has readability and is easily shared amongst developers, it is important to have a well thought out and designed component hierarchy.

This particular article has just grazed the surface on react components and all that many many layers, but as a new and learning developer, I find it to be one of the most crucial concepts to understand when beginning to work with react!

Thanks for reading!

Step by step coding

Melinda MacKenzie — Wed, 11 Oct 2023 18:35:18 +0000

Welcome!

If you have somehow stumbled across my blog you're probably one or all of these few things:

A fellow Flatiron software engineer student (👋 👋 )
new to the coding world (👨‍💻 👩‍💻 )
becoming frustrated staring at the same code and errors for hours on end and now browsing the web for some comedic relief until you feel mentally ready to be defeated by JS over & over again.. (the reason I have stumbled upon 95% of the blogs that I have read 🙋‍♀️)

and if you're none of those, I hope this blog post finds you well!

As a 30(some 😉 ) year old career changer leaving the world of psychology to become a software engineer, you can imagine I've encountered many frustrating moments have caused me to question my ability to really succeed as a software engineer. In order to learn the many different languages, and concepts of SE, I have had to retrain the way that my brain approaches and solves problems. (Hello, imposter syndrome!)

I am now nearing the completion of the first phase of the five phase curriculum at Flatiron school and through it all the most useful takeaway (besides the JS knowledge) that I have found is to break the problem down, or break the code down. I found myself feeling completely defeated before even attempting to code a solution to a specific lab multiple times throughout the past 3 months.

So what do I mean by break it down? For me, it involves a lot of talking out loud. The more I speak out loud the exact problem that I am attempting to solve, the more I could understand it in "non-technical" terms. (Bonus: the more you speak in technical programming language, the more natural it comes which will be imperative to your career) I've been told many times "to be a developer, you have to speak like a developer", what better way to master this skill than repeatedly doing so?

Once I am able to comprehend what I am being asked to do, I use "pseudocode" to translate the problem into singular steps using non programming language that does not follow any particular syntax guidelines. Make sure to keep your pseudocode short and to the point. Your pseudocode should be able to describe the functionality of your code in terms that someone without extensive programming background could understand. Once you have written out your pseudocode, you can then use this to write out your code.

For a simple example, let's pretend you're creating an app that will take someones info, age, name, occupation, and decide if they're legally able to vote. You need to write a function that takes age as an argument, and will return voting eligibility.

// Write a function that will check voting age of applicant
function checkVotingAge(age) {

// If applicants age is above 17 years old, return "vote!"
    if (age >= 18) {
        return "vote!";
    } 

// If applicants age is below 18 years old, return "no vote!"

else {
        return "no vote!";
    }
}
// Example usage:
const personAge = 20;
const result = checkVotingAge(personAge);
console.log(result); // Output will be "vote!"

The task of writing code and developing can seem quite daunting and overwhelming. To me, it felt as though I was trying to solve multiple problems at once. By breaking the problem down into smaller steps and utilizing pseudocode, I am able to work the problem out step by step and the task becomes less of a mountain to conquer and more of a molehill.

As a beginner in the software development world, I hope these small bits of advice can also help you in those frustrating moments. Happy coding!

Sources

IMAGE : https://medium.com/codex/10-best-programming-memes-1-cec344afc19a

CONTENT REFERENCE : https://www.geeksforgeeks.org/how-to-write-a-pseudo-code/